mirror of https://github.com/istio/istio.io.git
[zh] fix typo in `docs/ops` (#14102)
Signed-off-by: guiyong.ou <guiyong.ou@daocloud.io>
This commit is contained in:
Hiven Ou
GitHub
parent
9d0076ef2e
commit
5135d7a233
|
|
@ -47,7 +47,7 @@ Kubernetes 集群内的时间同步服务是否正确运行，以及 Web 客户
|
|||
Istio CNI 插件在 Kubernetes Pod 生命周期中的网络配置阶段执行 Istio
|
||||
网格 Pod 流量重定向，从而消除了用户将 Pod 部署到 Istio 网格中的
|
||||
[`NET_ADMIN` 和 `NET_RAW` 的需求](/zh/docs/ops/deployment/requirements/)。
|
||||
Istio CNI 插件取代了 `Istio-init` 容器提供的功能。
|
||||
Istio CNI 插件取代了 `istio-init` 容器提供的功能。
|
||||
|
||||
1. 验证 `istio-cni-node` Pod 正在运行：
|
||||
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ webhooks:
|
|||
Istio 有意识地使用 `istio-validation` `configmap` 和根证书，调整了
|
||||
webhook 配置。
|
||||
|
||||
1. 验证 `istio-pilot` Pod 是否在运行：
|
||||
1. 验证 `istiod` Pod 是否在运行：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl -n istio-system get pod -lapp=istiod
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Istio 的高级[负载均衡能力](/zh/docs/concepts/traffic-management/#load-b
|
|||
和[无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services)。
|
||||
* 在一组静态 IP 地址上进行负载均衡。这种情况适用于 `resolution: STATIC`
|
||||
类型的 `ServiceEntry`，这将使用 `spec.endpoints` 中的所有地址，
|
||||
或者对于标准 `Service` 将使用其所有 `Endpoint` 地址。
|
||||
或者对于标准 `Services` 将使用其所有 `Endpoints` 地址。
|
||||
* 使用 DNS 定期解析地址，并在所有结果中进行负载均衡。这种情况适用于
|
||||
`resolution: DNS` 类型的 `ServiceEntry`。
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Istio 代理从不执行同步 DNS 请求。配置 `resolution: DNS`
|
|||
的网格而言，尤其是在使用较低 `TTL` 时，可能会导致 DNS 服务器的负载很高。
|
||||
在这些情况下，以下行为有助于减轻负载：
|
||||
|
||||
* 将 `ServiceEntry` 切换为 `resolution: NONE` 类型以完全避免代理 DNS 查找，
|
||||
* 将 `ServiceEntries` 切换为 `resolution: NONE` 类型以完全避免代理 DNS 查找，
|
||||
这适用于许多使用场景。
|
||||
* 如果您可以控制正在解析的域，请适当增加它们的 TTL。
|
||||
* 如果您的 `ServiceEntry` 只有少量工作负载，请使用 `exportTo`
|
||||
|
|
@ -85,7 +85,7 @@ Istio 代理从不执行同步 DNS 请求。配置 `resolution: DNS`
|
|||
|
||||
Istio 提供了[代理 DNS 请求](/zh/docs/ops/configuration/traffic-management/dns-proxy/)的功能。
|
||||
这允许 Istio 捕获客户端发送的 DNS 请求并直接返回响应。这可以改善 DNS 延迟，
|
||||
减少负载，并解决了 `ServiceEntry` 无法通过 `kube-dns` 解析的问题。
|
||||
减少负载，并解决了 `ServiceEntries` 无法通过 `kube-dns` 解析的问题。
|
||||
|
||||
请注意，此代理仅适用于用户应用程序发送的 DNS 请求；当使用 `resolution: DNS`
|
||||
类型的 `ServiceEntry` 时，DNS 代理对 Istio 代理的 DNS 解析没有影响。
|
||||
类型的 `ServiceEntries` 时，DNS 代理对 Istio 代理的 DNS 解析没有影响。
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ $ istioctl analyze --use-kube=false samples/bookinfo/networking/*.yaml
|
|||
|
||||
从 Istio 1.5 开始，可以通过 `istiod.enableAnalysis` 标志将 Galley
|
||||
设置为与其主要负责的配置分发一起执行配置分析。
|
||||
此分析使用与 `istioctl analysis` 相同的逻辑和错误消息。
|
||||
此分析使用与 `istioctl analyze` 相同的逻辑和错误消息。
|
||||
来自分析的验证消息被写入受影响的 Istio 资源的状态子资源。
|
||||
|
||||
例如：如果您的 "ratings" VirtualService 上网关配置错误，运行
|
||||
|
|
@ -113,11 +113,11 @@ status:
|
|||
{{< /text >}}
|
||||
|
||||
`enableAnalysis` 在后台运行，并将保持资源的状态字段与其当前验证状态保持同步。
|
||||
请注意，这不是`istioctl analysis`的替代品：
|
||||
请注意，这不是`istioctl analyze` 的替代品：
|
||||
|
||||
- 并非所有资源都有自定义状态字段（例如 Kubernetes `namespace` 资源），
|
||||
因此附加到这些资源的消息不会显示验证消息。
|
||||
- `enableAnalysis` 仅适用于从 1.5 开始的 Istio 版本，而 `istioctl analysis`
|
||||
- `enableAnalysis` 仅适用于从 1.5 开始的 Istio 版本，而 `istioctl analyze`
|
||||
可用于旧版本。
|
||||
- 虽然可以轻松查看特定资源的问题，但很难全面了解网格中的验证状态。
|
||||
|
||||
|
|
@ -138,7 +138,7 @@ Info [IST0102] (Namespace frod) The namespace is not enabled for Istio injection
|
|||
{{< /text >}}
|
||||
|
||||
由于您无权更新命名空间，因此无法通过注解命名空间来解析消息。相反，
|
||||
您可以使用 `istioctl analysis` 来抑制资源上的上述消息：
|
||||
您可以使用 `istioctl analyze` 来抑制资源上的上述消息：
|
||||
|
||||
{{< text syntax=bash snip_id=analyze_suppress0102 >}}
|
||||
$ istioctl analyze -k --namespace frod --suppress "IST0102=Namespace frod"
|
||||
|
|
@ -157,7 +157,7 @@ $ istioctl analyze -k --all-namespaces --suppress "IST0102=Namespace frod" --sup
|
|||
### 通过注解忽略特定的分析器消息 {#ignoring-specific-analyzer-messages-via-annotations}
|
||||
|
||||
您也可以使用资源上的注解忽略特定的分析器消息。例如，要忽略资源
|
||||
`deployment/my deployment` 上的代码IST0107（`MisplacedAnnotation`）：
|
||||
`deployment/my-deployment` 上的代码IST0107（`MisplacedAnnotation`）：
|
||||
|
||||
{{< text syntax=bash snip_id=annotate_for_deployment_suppression >}}
|
||||
$ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST0107
|
||||
|
|
|
|||
|
|
@ -179,7 +179,7 @@ $ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
|
|||
## 验证流量路由{#verifying-traffic-routes}
|
||||
|
||||
`istioctl describe` 命令还可以展示流量的分隔权重。
|
||||
例如，运行如下命令将 90% 的流量路由到 `revis` 服务的 `v1` 子集，将
|
||||
例如，运行如下命令将 90% 的流量路由到 `reviews` 服务的 `v1` 子集，将
|
||||
10% 路由到 `v2` 子集：
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
|
|||
|
|
@ -95,9 +95,9 @@ istiod.istio-system.svc.cluster.local 15014 - outbound EDS
|
|||
|
||||
## 自动注册 {#automatic-registration}
|
||||
|
||||
当虚拟机连接到 Istiod 时，会自动创建一个 `workloadEntry`。
|
||||
这使得虚拟机成为 `service` 的一部分，类似于 Kubernetes
|
||||
中的 `endpoint`。
|
||||
当虚拟机连接到 Istiod 时，会自动创建一个 `WorkloadEntry`。
|
||||
这使得虚拟机成为 `Service` 的一部分，类似于 Kubernetes
|
||||
中的 `Endpoint`。
|
||||
|
||||
检查这些配置是否正确创建:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ $ kubectl apply -f {{< github_file >}}/samples/addons/jaeger.yaml
|
|||
Jaeger 与 Istio 一起使用时无需特殊的配置。
|
||||
|
||||
安装 Jaeger 完毕后，需要指定 Istio 代理向 Deployment 发送流量。
|
||||
在安装时，可以使用 `--set values.global.tracer.zipkin.address=<jaeger-collector-address>:9411`
|
||||
在安装时，可以使用 `--set meshConfig.defaultConfig.tracing.zipkin.address=<jaeger-collector-address>:9411`
|
||||
进行配置。参考更多 [`ProxyConfig.Tracing`](/zh/docs/reference/config/istio.mesh.v1alpha1/#Tracing)
|
||||
高级配置，如 TLS 设置。
|
||||
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ Chart 提供的配置。
|
|||
|
||||
* 您需要使用 TLS 收集指标。
|
||||
* 您的应用程序暴露的指标与 Istio 暴露的指标重名。例如，
|
||||
您的应用程序暴露一个叫做 `istio_request_total` 的指标。
|
||||
您的应用程序暴露一个叫做 `istio_requests_total` 的指标。
|
||||
如果应用程序本身正在运行 Envoy，这就有可能发生。
|
||||
* 您的 Prometheus Deployment 没有配置通过 `prometheus.io` 注解抓取指标。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue