mirror of https://github.com/istio/istio.io.git
cleanup some waste zh docs (#13987)
Signed-off-by: guiyong.ou <guiyong.ou@daocloud.io>
This commit is contained in:
Hiven Ou
GitHub
parent
48ce7e1c00
commit
364ff319ac
|
|
@ -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 版本中消失。
|
||||
|
|
|
|||
|
|
@ -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)。
|
||||
|
|
@ -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)。
|
||||
|
|
@ -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 >}}
|
||||
Loading…
Reference in New Issue