diff --git a/content/zh/blog/2019/performance-best-practices/index.md b/content/zh/blog/2019/performance-best-practices/index.md
index 8bb639b31f..f976131a97 100644
--- a/content/zh/blog/2019/performance-best-practices/index.md
+++ b/content/zh/blog/2019/performance-best-practices/index.md
@@ -32,7 +32,7 @@ keywords: [performance,scalability,scale,benchmarks]
 
 考虑到 **延迟**，关注数据平面性能也很重要。这是因为大多数应用的请求会通过 Istio 数据平面，而不是通过控制平面。但是，有两个例外：
 
-1. **遥测报告：** 每个代理将原始遥测数据发送到 {{<gloss>}}Mixer{{</gloss>}}，Mixer 将其处理为度量，跟踪和其他遥测。原始遥测数据类似于访问日志，因此要付出一定的代价。访问日志处理会消耗 CPU，并使工作线程无法处理下一个工作单元。在更高的吞吐量场景下，下一个工作单元更有可能在队列中等待被工作者接走。这可能导致 Envoy 的长尾延迟（99%）。
+1. **遥测报告：** 每个代理将原始遥测数据发送到 Mixer，Mixer 将其处理为度量，跟踪和其他遥测。原始遥测数据类似于访问日志，因此要付出一定的代价。访问日志处理会消耗 CPU，并使工作线程无法处理下一个工作单元。在更高的吞吐量场景下，下一个工作单元更有可能在队列中等待被工作者接走。这可能导致 Envoy 的长尾延迟（99%）。
 1. **自定义策略检查：** 当使用[自定义 Istio 策略适配器](/zh/docs/concepts/observability/)时，策略检查位于请求路径上。这意味着数据路径上的请求 header 和 metadata 将被发送到控制平面（Mixer），从而导致更高的请求延迟。**注意：** 这些策略检查[默认情况下处于禁用状态](/zh/docs/reference/config/installation-options/#global-options)，因为最常见的策略用例（[RBAC](/zh/docs/reference/config/security/istio.rbac.v1alpha1)）完全由 Envoy 代理执行。
 
 当 [Mixer V2](https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s) 将所有策略和遥测功能直接移到代理中时，这两个例外都会在将来的 Istio 版本中消失。
diff --git a/content/zh/docs/reference/glossary/adapters.md b/content/zh/docs/reference/glossary/adapters.md
deleted file mode 100644
index 4001bb62e4..0000000000
--- a/content/zh/docs/reference/glossary/adapters.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Adapters
----
-
-适配器（adapter）是 Istio [策略和遥测](/zh/docs/reference/config/policy-and-telemetry/)组件
-[Mixer](/zh/docs/reference/glossary/#mixer) 的插件，可使其与一组开放式基础架构后端交互，
-这些后端可提供核心功能，例如日志记录、监控、配额、ACL 检查等等。运行时所使用的精确的适配器集合是通过配置确定的，
-并可以针对新的或定制的基础架构后端轻松扩展。
-
-[了解更多关于适配器的信息](/zh/docs/reference/config/policy-and-telemetry/adapters)。
diff --git a/content/zh/docs/reference/glossary/mixer.md b/content/zh/docs/reference/glossary/mixer.md
deleted file mode 100644
index fb02bae8b2..0000000000
--- a/content/zh/docs/reference/glossary/mixer.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Mixer
----
-Mixer 是 Istio 里的一个组件，它负责增强[服务网格](/zh/docs/reference/glossary/#service-mesh)里的访问控制和使用策略。它还负责收集来自 [envoy](/zh/docs/reference/glossary/#envoy) 和其他服务的遥测数据。
-[了解更多关于 Mixer](/zh/docs/reference/config/policy-and-telemetry)。
diff --git a/content/zh/docs/tasks/security/cert-management/dns-cert/index.md b/content/zh/docs/tasks/security/cert-management/dns-cert/index.md
deleted file mode 100644
index fa0d79caf4..0000000000
--- a/content/zh/docs/tasks/security/cert-management/dns-cert/index.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-title: Istio 的 DNS 证书管理
-description: 如何在 Istiod 中配置和管理 DNS 证书。
-weight: 90
-keywords: [security,certificate]
-aliases:
-    - /zh/docs/tasks/security/dns-cert/
-owner: istio/wg-security-maintainers
-test: yes
----
-
-此文档主要说明如何使用 [Chiron](/zh/blog/2019/dns-cert/) 配置和管理 DNS 证书。
-Chiron 是一个与 Istiod 相连的轻量型组件，使用 Kubernetes 的 CA API 签发证书，
-无需管理私钥。优势如下：
-
-* 与 {{< gloss >}}Istiod{{< /gloss >}} 不同, 这种方式无需维护签发的私钥，增强了安全性。
-
-* 简化了将根证书分发到 TLS 客户端。客户端不再需要等待 Istiod 生成和分发其 CA 证书。
-
-## 开始之前{#before-you-begin}
-
-* 通过 `istioctl` 安装 Istio，并配置 DNS 证书。当 Istio 启动后会读取该配置。
-
-{{< text bash >}}
-$ cat <<EOF > ./istio.yaml
-apiVersion: install.istio.io/v1alpha1
-kind: IstioOperator
-spec:
-  meshConfig:
-    certificates:
-      - secretName: dns.example1-service-account
-        dnsNames: [example1.istio-system.svc, example1.istio-system]
-      - secretName: dns.example2-service-account
-        dnsNames: [example2.istio-system.svc, example2.istio-system]
-EOF
-$ istioctl install -f ./istio.yaml
-{{< /text >}}
-
-## DNS 证书的提供和管理{#DNS-certificate-provisioning-and-management}
-
-Istio 根据用户的配置，为 DNS 证书提供 DNS 名称和 Secret 名称。
-DNS 证书 通过 Kubernetes CA 签发，并根据配置保存到 Secret 中。
-Istio 也管理 DNS 证书的生命周期，包括证书的滚动和重新生成。
-
-## 配置 DNS 证书{#configure-DNS-certificates}
-
-在 `istioctl install` 命令中使用 `IstioOperator` 自定义资源用于配置 Istio。
-`IstioOperator` 自定义资源包括 DNS 证书配置的例子。其中，`dnsNames`
-字段定义证书中 DNS 名称，`secretName` 字段定义用于存储证书和私钥的
-Kubernetes Secret 名称。
-
-## 检查 DNS 证书的提供{#check-the-provisioning-of-DNS-certificates}
-
-在配置 Istio 生成 DNS 证书和保存证书到 Secret 后，您可以校验证书是够已经生成并正常运行。
-
-为了校验例子中 Istio 的配置 `dns.example1-service-account` 生成的 DNS
-证书，和校验证书是否包含 配置的 DNS 名称，需要获取 Kubernetes 的 Secret
-进行解析解码，通过以下命令查看具体内容：
-
-{{< text bash >}}
-$ kubectl get secret dns.example1-service-account -n istio-system -o jsonpath="{.data['cert-chain\.pem']}" | base64 --decode | openssl x509 -in /dev/stdin -text -noout
-{{< /text >}}
-
-输出内容包括：
-
-{{< text plain >}}
-            X509v3 Subject Alternative Name:
-                DNS:example1.istio-system.svc, DNS:example1.istio-system
-{{< /text >}}
-
-## 重新生成 DNS 证书{#regenerating-a-DNS-certificate}
-
-Istio 还可以在重新生成被误删的 DNS 证书。接下来，将会演示如何删除最近配置的证书，
-并校验 Istio 自动重新生成证书。
-
-1. 删除前面保存的配置 DNS 证书的 Secret：
-
-    {{< text bash >}}
-    $ kubectl delete secret dns.example1-service-account -n istio-system
-    {{< /text >}}
-
-1. 校验 Istio 重新生成已删除 DNS 证书，且证书包含配置的 DNS 名称，
-   您需要获取 Kubernetes 的 Secret进行解析解码，通过以下命令查看详细内容：
-
-    {{< text bash >}}
-    $ sleep 10; kubectl get secret dns.example1-service-account -n istio-system -o jsonpath="{.data['cert-chain\.pem']}" | base64 --decode | openssl x509 -in /dev/stdin -text -noout
-    {{< /text >}}
-
-输出内容包括：
-
-{{< text plain >}}
-            X509v3 Subject Alternative Name:
-                DNS:example1.istio-system.svc, DNS:example1.istio-system
-{{< /text >}}
-
-## 清理{#cleanup}
-
-*   移除 `istio-system` Namespace：
-
-    {{< text bash >}}
-    $ kubectl delete ns istio-system
-    {{< /text >}}