From 63457719df2fa66264d5697b6645263e071670ea Mon Sep 17 00:00:00 2001 From: my-git9 Date: Sun, 23 Apr 2023 09:38:56 +0800 Subject: [PATCH] [zh]sync and improve injection observability-issues (#13092) Signed-off-by: xin.li --- .../ops/common-problems/injection/index.md | 76 ++++++++++++++----- .../observability-issues/index.md | 27 +++++-- 2 files changed, 77 insertions(+), 26 deletions(-) diff --git a/content/zh/docs/ops/common-problems/injection/index.md b/content/zh/docs/ops/common-problems/injection/index.md index 5c0a8ad77c..a546e9e2ea 100644 --- a/content/zh/docs/ops/common-problems/injection/index.md +++ b/content/zh/docs/ops/common-problems/injection/index.md @@ -6,20 +6,21 @@ weight: 40 aliases: - /zh/docs/ops/troubleshooting/injection owner: istio/wg-user-experience-maintainers -test: no +test: n/a --- ## 注入的结果和预期不一致 {#the-result-of-sidecar-injection-was-not-what-i-expected} 不一致包括 Sidecar 的非预期注入和预期未注入。 -1. 确保您的 Pod 不在 `kube-system` 或 `kube-public` 名称空间中。 - 这些命名空间中的 Pod 将忽略 Sidecar 自动注入。 +1. 确保您的 Pod 不在 `kube-system` 或 `kube-public` 命名空间中。 + 这些命名空间中的 Pod 将忽略 Sidecar 自动注入。 1. 确保您的 Pod 在其 Pod 定义中没有 `hostNetwork：true`。 `hostNetwork：true` 的 Pod 将忽略 Sidecar 自动注入。 - Sidecar 模型假定 iptables 会拦截所有 Pod 中的流量给 Envoy，但是 `hostNetwork：true` 的 Pod 不符合此假设，并且会导致主机级别的路由失败。 + Sidecar 模型假定 iptables 会拦截所有 Pod 中的流量给 Envoy，但是 + `hostNetwork：true` 的 Pod 不符合此假设，并且会导致主机级别的路由失败。 1. 通过检查 webhook 的 `namespaceSelector` 以确定目标命名空间是否包含在 webhook 范围内。 @@ -93,11 +94,14 @@ test: no policy: enabled {{< /text >}} - 策略允许的值为 `disabled` 或者 `enabled`。仅当 webhook 的 `namespaceSelector` 与目标命名空间匹配时，默认策略才会生效。无法识别的策略值默认为 `disabled`。 + 策略允许的值为 `disabled` 或者 `enabled`。仅当 webhook 的 `namespaceSelector` + 与目标命名空间匹配时，默认策略才会生效。无法识别的策略值会导致完全禁用注入。 1. 检查每个 Pod 的标签 - 可以使用 pod template spec metadata 中的标签 `sidecar.istio.io/inject` 来覆盖默认策略，如果这样的话，Deployment 相应的 metadata 将被忽略。标签值为 `true` 会被强制注入 Sidecar，为 `false` 则会强制不注入 Sidecar。 + 可以使用 pod template spec metadata 中的标签 `sidecar.istio.io/inject` + 来覆盖默认策略，如果这样的话，Deployment 相应的 metadata 将被忽略。标签值为 + `true` 会被强制注入 Sidecar，为 `false` 则会强制不注入 Sidecar。 以下标签会覆盖默认策略并强制注入 Sidecar： @@ -112,7 +116,8 @@ test: no ## Pod 不能创建 {#pods-cannot-be-created-at-all} -在失败的 Pod 的 Deployment 上运行 `kubectl describe -n namespace deployment name`。通常能在事件中看到调用注入 webhook 失败的原因。 +在失败的 Pod 的 Deployment 上运行 `kubectl describe -n namespace deployment name`。 +通常能在事件中看到调用注入 webhook 失败的原因。 ### x509 证书相关的错误 {#x509-certificate-related-errors} @@ -123,9 +128,11 @@ Warning FailedCreate 3m (x17 over 8m) replicaset-controller Error creating: to verify candidate authority certificate "Kubernetes.cluster.local") {{< /text >}} -`x509: certificate signed by unknown authority` 错误通常由 webhook 配置中的空 `caBundle` 引起。 +`x509: certificate signed by unknown authority` 错误通常由 webhook +配置中的空 `caBundle` 引起。 -验证 `mutatingwebhookconfiguration` 配置中的 `caBundle` 是否与 `istio-sidecar-injector` 中 pod 安装的根证书匹配。 +验证 `mutatingwebhookconfiguration` 配置中的 `caBundle` 是否与 +`istio-sidecar-injector` 中 Pod 安装的根证书匹配。 {{< text bash >}} $ kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml -o jsonpath='{.webhooks[0].clientConfig.caBundle}' | md5sum @@ -134,7 +141,7 @@ $ kubectl -n istio-system get configmap istio-ca-root-cert -o jsonpath='{.data.r 4b95d2ba22ce8971c7c92084da31faf0 - {{< /text >}} -CA 证书必须匹配，否则需要重新启动 sidecar-injector pod。 +CA 证书必须匹配，否则需要重新启动 sidecar-injector Pod。 {{< text bash >}} $ kubectl -n istio-system patch deployment istio-sidecar-injector \ @@ -144,7 +151,8 @@ deployment.extensions "istio-sidecar-injector" patched ### Deployment 状态中出现 `no such hosts` 或 `no endpoints available` {#no-such-hosts-or-no-endpoints-available-errors-in-deployment-status} -注入是失效关闭的（fail-close）。如果 `istio-sidecar-injector` Pod 尚未准备就绪，则无法创建 Pod。在这种情况下，则会出现 `no endpoints available`。 +注入是失效关闭的（fail-close）。如果 `istio-sidecar-injector` Pod 尚未准备就绪， +则无法创建 Pod。在这种情况下，则会出现 `no endpoints available`。 {{< text plain >}} Internal error occurred: failed calling admission webhook "istio-sidecar-injector.istio.io": \ @@ -164,7 +172,8 @@ NAME ENDPOINTS AGE istio-sidecar-injector 10.48.6.108:15014,10.48.6.108:443 3d {{< /text >}} -如果 Pod 或 endpoint 尚未准备就绪，可以通过检查 Pod 日志和状态查找有关 Webhook Pod 无法启动的原因。 +如果 Pod 或 endpoint 尚未准备就绪，可以通过检查 Pod 日志和状态查找有关 +Webhook Pod 无法启动的原因。 {{< text bash >}} $ for pod in $(kubectl -n istio-system get pod -listio=sidecar-injector -o jsonpath='{.items[*].metadata.name}'); do \ @@ -190,24 +199,55 @@ env: value: 127.0.0.1,localhost,dockerhub.foo.com,devhub-docker.foo.com,10.84.100.125,10.84.100.126,10.84.100.127 {{< /text >}} -使用这些设置，Sidecar 自动注入就会失败。相关的报错可以在 `kube-apiserver` 日志中找到： +使用这些设置，Sidecar 自动注入就会失败。相关的报错可以在 `kube-apiserver` +日志中找到： {{< text plain >}} W0227 21:51:03.156818 1 admission.go:257] Failed calling webhook, failing open sidecar-injector.istio.io: failed calling admission webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-system.svc:443/inject: Service Unavailable {{< /text >}} -根据 `*_proxy` 相关的的环境变量设置，确保 Pod 和 service CIDR 是没有被代理的。检查 `kube-apiserver` 的运行日志验证是否有请求正在被代理。 +根据 `*_proxy` 相关的的环境变量设置，确保 Pod 和 service CIDR 是没有被代理的。检查 +`kube-apiserver` 的运行日志验证是否有请求正在被代理。 -一种解决方法是在 `kube-apiserver` 的配置中删除代理设置，另一种解决方法是把 `istio-sidecar-injector.istio-system.svc` 或者 `.svc` 加到 `no_proxy` 的 `value` 里面。每种解决方法都需要重新启动 `kube-apiserver`。 +一种解决方法是在 `kube-apiserver` 的配置中删除代理设置，另一种解决方法是把 +`istio-sidecar-injector.istio-system.svc` 或者 `.svc` 加到 `no_proxy` +的 `value` 里面。每种解决方法都需要重新启动 `kube-apiserver`。 -Kubernetes 与此有关的一个 [issue](https://github.com/kubernetes/kubeadm/issues/666) 已被 [PR #58698](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) 解决。 +Kubernetes 与此有关的一个 [issue](https://github.com/kubernetes/kubeadm/issues/666) +已被 [PR #58698](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) +解决。 ## 在 Pod 中使用 `tcpdump` 的限制 {#limitations-for-using-Tcpdump-in-pods} -`tcpdump` 在 Sidecar 中不能工作 - 因为该容器不以 root 身份运行。但是由于同一 Pod 内容器的网络命名空间是共享的，因此 Pod 中的其他容器也能看到所有数据包。`iptables` 也能查看到 Pod 级别的相关配置。 +`tcpdump` 在 Sidecar 中不能工作 - 因为该容器不以 root 身份运行。但是由于同一 +Pod 内容器的网络命名空间是共享的，因此 Pod 中的其他容器也能看到所有数据包。 +`iptables` 也能查看到 Pod 级别的相关配置。 Envoy 和应用程序之间的通信是通过 127.0.0.1 进行的，这个通讯过程未加密。 ## 集群不会自动缩小 {#cluster-is-not-scaled-down-automatically} -由于 Sidecar 容器安装了本地存储卷，因此节点自动缩放器无法使用注入的 Pod 驱逐节点。这是一个[已知的问题](https://github.com/istio/istio/issues/19395)。解决方法是向 Pod 添加注解 `“cluster-autoscaler.kubernetes.io/safe-to-evict”：“true”`。 +由于 Sidecar 容器安装了本地存储卷，因此节点自动缩放器无法使用注入的 +Pod 驱逐节点。这是一个[已知的问题](https://github.com/istio/istio/issues/19395)。 +解决方法是向 Pod 添加注解 `"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"`。 + +## 如果 istio-proxy 还没有准备好，Pod 或容器会出现网络问题 {#pod-or-containers-start-with-network-issues-if-istio-proxy-is-not-ready} + +许多应用程序在启动期间执行一些需要网络连接命令或检查。此时如果 istio-proxy +Sidecar 容器没有准备好，可能会导致应用程序容器挂起或重新启动。 + +要避免这种情况，可以将 `holdApplicationUntilProxyStarts` 设置为 `true`。 +这将会使 Sidecar 注入器在 Pod 的容器列表中的容器启动之前注入 Sidecar， +并阻止所有其它容器的启动，直到代理就绪。 + +这可以作为全局配置选项添加： + +{{< text yaml >}} +values.global.proxy.holdApplicationUntilProxyStarts: true +{{< /text >}} + +或者在 Pod 的 annotation 中添加： + +{{< text yaml >}} +proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }' +{{< /text >}} diff --git a/content/zh/docs/ops/common-problems/observability-issues/index.md b/content/zh/docs/ops/common-problems/observability-issues/index.md index f8dc2a33fd..c0d8c94ae4 100644 --- a/content/zh/docs/ops/common-problems/observability-issues/index.md +++ b/content/zh/docs/ops/common-problems/observability-issues/index.md @@ -7,14 +7,16 @@ aliases: - /zh/docs/ops/troubleshooting/grafana - /zh/docs/ops/troubleshooting/missing-traces owner: istio/wg-policies-and-telemetry-maintainers -test: no +test: n/a --- ## 在 Mac 上运行 Istio 时，Zipkin 不生效{#no-traces-appearing-in-Zipkin-when-running-Istio-locally-on-mac} -Istio 已经完成安装并且都在正常工作，但是 Zipkin 没有任何信息，但是应该有一些信息。 +Istio 已经完成安装并且都在正常工作，但是 Zipkin 中没有显示任何 trace 信息。 -这可能是由已知的 Docker 问题引起的，容器内的时间可能与主机上的时间有很大偏差。如果是这种情况，当您在 Zipkin 中选择了一个长时间范围时，您可能会发现数据比预期早了一些时间。 +这可能是由已知的 [Docker 问题](https://github.com/docker/for-mac/issues/1260)引起的， +容器内的时间可能与主机上的时间有很大偏差。如果是这种情况，当您在 Zipkin 中选择了一个长时间范围时， +您可能会发现数据比预期早了一些时间。 您还可以通过对比 Docker 容器内和容器外的日期来确认该问题： @@ -32,18 +34,27 @@ Thu Jun 15 02:25:42 UTC 2017 ## 缺少 Grafana 输出{#missing-Grafana-output} -如果从本地 Web 客户端连接到 Istio 端时，无法获取 Grafana 的数据，则应该验证客户端和服务器的日期和时间是否匹配。 +如果从本地 Web 客户端连接到 Istio 端时，无法获取 Grafana 的数据， +则应该验证客户端和服务器的日期和时间是否匹配。 -Web 客户端（例如：Chrome）的时间会影响 Grafana 的输出。此问题的简单解决方案是验证 Kubernetes 集群内的时间同步服务是否正确运行，以及 Web 客户端计算机是否也与目标服务器的时间相同。一些常见的时间同步系统有 NTP 和 Chrony。在有防火墙的实验室中问题比较严重。这种情况可能是 NTP 没有正确配置，指向基于实验室的 NTP 服务。 +Web 客户端（例如：Chrome）的时间会影响 Grafana 的输出。此问题的简单解决方案是验证 +Kubernetes 集群内的时间同步服务是否正确运行，以及 Web 客户端计算机是否也与目标服务器的时间相同。 +一些常见的时间同步系统有 NTP 和 Chrony。在有防火墙的实验室中问题比较严重。 +这种情况可能是 NTP 没有正确配置，指向基于实验室的 NTP 服务。 ## 验证 Istio CNI Pod 正在运行（如果使用）{#verify-Istio-CNI-pods-are-running} -Istio CNI 插件在 Kubernetes Pod 生命周期中的网络配置阶段执行 Istio 网格 Pod 流量重定向，从而消除了用户将 Pod 部署到 Istio 网格中的 [`NET_ADMIN` 和 `NET_RAW` 的需求](/zh/docs/ops/deployment/requirements/)。Istio CNI 插件取代了 `Istio-init`容器提供的功能。 +Istio CNI 插件在 Kubernetes Pod 生命周期中的网络配置阶段执行 Istio +网格 Pod 流量重定向，从而消除了用户将 Pod 部署到 Istio 网格中的 +[`NET_ADMIN` 和 `NET_RAW` 的需求](/zh/docs/ops/deployment/requirements/)。 +Istio CNI 插件取代了 `Istio-init` 容器提供的功能。 -1. 验证 `istio-cni-node` Pod 正在运行: +1. 验证 `istio-cni-node` Pod 正在运行： {{< text bash >}} $ kubectl -n kube-system get pod -l k8s-app=istio-cni-node {{< /text >}} -1. 如果 `PodSecurityPolicy` 在您的集群中正在工作, 确认 `istio-cni` Service Account 可以使用 `PodSecurityPolicy` 的 [`NET_ADMIN` 和 `NET_RAW` 的功能](/zh/docs/ops/deployment/requirements/). +1. 如果 `PodSecurityPolicy` 在您的集群中正在工作，确认 `istio-cni` + Service Account 可以使用 `PodSecurityPolicy` 的 + [`NET_ADMIN` 和 `NET_RAW` 的功能](/zh/docs/ops/deployment/requirements/)。