zh: updated /ops/common-problems/injection/ (#11599)

This commit is contained in:
Michael 2022-08-12 19:48:25 +08:00 committed by GitHub
parent 6e8e2cdf5d
commit 3faf4c53a2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 28 additions and 26 deletions

View File

@ -1,6 +1,6 @@
---
title: Sidecar 自动注入问题
description: 解决 Istio 使用 Kubernetes Webhooks 进行 sidecar 自动注入的常见问题。
description: 解决 Istio 使用 Kubernetes Webhooks 进行 Sidecar 自动注入的常见问题。
force_inline_toc: true
weight: 40
aliases:
@ -9,15 +9,17 @@ owner: istio/wg-user-experience-maintainers
test: no
---
## 注入的结果和预期不一致{#the-result-of-sidecar-injection-was-not-what-i-expected}
## 注入的结果和预期不一致 {#the-result-of-sidecar-injection-was-not-what-i-expected}
不一致包括 sidecar 的非预期注入和预期未注入。
不一致包括 Sidecar 的非预期注入和预期未注入。
1. 确保您的 pod 不在 `kube-system``kube-public` 名称空间中。这些命名空间中的 pod 将忽略 sidecar 自动注入。
1. 确保您的 Pod 不在 `kube-system``kube-public` 名称空间中。
这些命名空间中的 Pod 将忽略 Sidecar 自动注入。
1. 确保您的 pod 在其 pod 定义中没有 `hostNetworktrue`。`hostNetworktrue` 的 pod 将忽略 sidecar 自动注入。
1. 确保您的 Pod 在其 Pod 定义中没有 `hostNetworktrue`
`hostNetworktrue` 的 Pod 将忽略 Sidecar 自动注入。
sidecar 模型假定 iptables 会拦截所有 pod 中的流量给 Envoy但是 `hostNetworktrue` 的 pod 不符合此假设,并且会导致主机级别的路由失败。
Sidecar 模型假定 iptables 会拦截所有 Pod 中的流量给 Envoy但是 `hostNetworktrue` 的 Pod 不符合此假设,并且会导致主机级别的路由失败。
1. 通过检查 webhook 的 `namespaceSelector` 以确定目标命名空间是否包含在 webhook 范围内。
@ -33,7 +35,7 @@ test: no
- ""
{{< /text >}}
在有 `istio-injection=enabled` 标签的命名空间中创建 pod 就会调用注入 webhook。
在有 `istio-injection=enabled` 标签的命名空间中创建 Pod 就会调用注入 webhook。
{{< text bash >}}
$ kubectl get namespace -L istio-injection
@ -59,7 +61,7 @@ test: no
- ""
{{< /text >}}
在没有标记 `istio-injection=disabled` 标签的命名空间中创建 pod注入 webhook 就会被调用。
在没有标记 `istio-injection=disabled` 标签的命名空间中创建 Pod注入 webhook 就会被调用。
{{< text bash >}}
$ kubectl get namespace -L istio-injection
@ -70,7 +72,7 @@ test: no
kube-system Active 18d disabled
{{< /text >}}
验证应用程序 pod 的命名空间是否已相应地被正确(重新)标记,例如:
验证应用程序 Pod 的命名空间是否已相应地被正确(重新)标记,例如:
{{< text bash >}}
$ kubectl label namespace istio-system istio-injection=disabled --overwrite
@ -93,11 +95,11 @@ test: no
策略允许的值为 `disabled` 或者 `enabled`。仅当 webhook 的 `namespaceSelector` 与目标命名空间匹配时,默认策略才会生效。无法识别的策略值默认为 `disabled`
1. 检查每个 pod 的标签
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
以下标签会覆盖默认策略并强制注入 Sidecar
{{< text bash yaml >}}
$ kubectl get deployment sleep -o yaml | grep "sidecar.istio.io/inject:" -C3
@ -108,11 +110,11 @@ test: no
sidecar.istio.io/inject: "true"
{{< /text >}}
## pods 不能创建{#pods-cannot-be-created-at-all}
## 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}
### x509 证书相关的错误 {#x509-certificate-related-errors}
{{< text plain >}}
Warning FailedCreate 3m (x17 over 8m) replicaset-controller Error creating: Internal error occurred: \
@ -132,7 +134,7 @@ $ kubectl -n istio-system get configmap istio-ca-root-cert -o jsonpath='{.data.r
4b95d2ba22ce8971c7c92084da31faf0 -
{{< /text >}}
CA 证书必须匹配,否则需要重新启动 sidecar-injector pods
CA 证书必须匹配,否则需要重新启动 sidecar-injector pod。
{{< text bash >}}
$ kubectl -n istio-system patch deployment istio-sidecar-injector \
@ -140,9 +142,9 @@ $ kubectl -n istio-system patch deployment istio-sidecar-injector \
deployment.extensions "istio-sidecar-injector" patched
{{< /text >}}
### deployment 状态中出现 `no such hosts``no endpoints available`{#no-such-hosts-or-no-endpoints-available-errors-in-deployment-status}
### 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": \
@ -162,7 +164,7 @@ 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 \
@ -174,7 +176,7 @@ $ for pod in $(kubectl -n istio-system get pod -listio=sidecar-injector -o name)
done
{{< /text >}}
## 如果 Kubernetes API server 有代理设置的话,sidecar 的自动注入功能是不能用的{#automatic-sidecar-injection-fails-if-the-Kubernetes-API-server-has-proxy-settings}
## 如果 Kubernetes API server 有代理设置的话,Sidecar 的自动注入功能是不能用的 {#automatic-sidecar-injection-fails-if-the-Kubernetes-API-server-has-proxy-settings}
当 Kubernetes API server 包含诸如以下的代理设置时:
@ -188,24 +190,24 @@ 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 CIDRs 是没有被代理的。检查 `kube-apiserver` 的运行日志验证是否有请求正在被代理。
根据 `*_proxy` 相关的的环境变量设置,确保 Pod 和 service CIDR 是没有被代理的。检查 `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) 解决。
## 在 pods 中使用 `tcpdump` 的限制{#limitations-for-using-Tcpdump-in-pods}
## 在 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}
## 集不会自动缩小 {#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”`