1、istio-允许/禁用sidecar设置
1.1 在namespace设置自动注入:
给 zmc 命名空间设置标签:istio-injection=enabled:
[root@master1 ~]# kubectl create ns zmc namespace/zmc created [root@master1 ~]# kubectl label namespace zmc istio-injection=enabled namespace/zmc labeled [root@master1 ~]# kubectl get namespace -L istio-injection NAME STATUS AGE ISTIO-INJECTION default Active 31h istio-system Active 13h kube-node-lease Active 31h kube-public Active 31h kube-system Active 31h zmc Active 27s enabled
在zmc命令空间下创建如下deployment:
kind: Deployment apiVersion: apps/v1 metadata: name: nginx-v1 labels: app: nginx version: v1 spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: container-rl4wdf image: 'nginx:latest' ports: - name: tcp-80 containerPort: 80 protocol: TCP imagePullPolicy: IfNotPresent
给namespace设置istio-injection=enabled标签后,这样就会在 Pod 创建时触发 Sidecar 的注入过程了,被注入 Sidecar 的 Pod 会有两个容器:
查看被注入的 Pod 的细节。不难发现多出了一个 istio-proxy 容器及其对应的存储卷。注意用正确的 Pod 名称来执行下面的命令:
kubectl describe pod -n=zmc nginx-v1-fb75db6b7-w4n5b
... Events: Type Reason Age From Message ---- ------ ---- ---- ------- ... Normal Created 11s kubelet Created container istio-init Normal Started 11s kubelet Started container istio-init ... Normal Created 10s kubelet Created container sleep Normal Started 10s kubelet Started container sleep ... Normal Created 9s kubelet Created container istio-proxy Normal Started 8s kubelet Started container istio-proxy
禁用zmc命名空间的自动注入功能,然后检查新建 Pod 就不带有 Sidecar 容器了:
[root@master1 ~]# kubectl label namespace zmc istio-injection- namespace/zmc labeled [root@master1 ~]# kubectl delete pod -n=zmc nginx-v1-fb75db6b7-w4n5b pod "nginx-v1-fb75db6b7-w4n5b" deleted [root@master1 ~]# kubectl get pods -n=zmc NAME READY STATUS RESTARTS AGE nginx-v1-fb75db6b7-2f2gl 1/1 Running 0 26s
1.2 控制注入策略:
在1.1示例中,在命名空间级别启用和禁用了注入。通过在 pod 上配置sidecar.istio.io/inject
标签(对于istio1.12.1版本这里一定要注意是标签不是注解),还可以在每个 pod 的基础上控制注入:
资源 | 标签 | 启用值 | 禁用值 |
---|---|---|---|
Namespace | istio-injection |
enabled |
disabled |
Pod | sidecar.istio.io/inject |
"true" |
"false" |
注入的配置如下:
- 如果禁用其中一个标签,则不注入 Pod
- 如果启用其中一个标签,则注入 Pod
- 如果两个标签都没有设置,如果启用
.values.sidecarInjectorWebhook.enableNamespacesByDefault
, 则会注入 Pod。在默认情况下是不启用的,所以 Pod 通常不会被注入。
示例1:istio-injection=disabled,sidecar.istio.io/inject="true":
[root@master1 ~]# kubectl label namespace zmc istio-injection=disabled namespace/zmc labeled [root@master1 ~]# kubectl get pods -n=zmc No resources found in zmc namespace.
在zmc命令空间下创建如下deployment:
kind: Deployment apiVersion: apps/v1 metadata: name: nginx-v1 labels: app: nginx version: v1 spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: sidecar.istio.io/inject: 'true' app: nginx spec: containers: - name: container-rl4wdf image: 'nginx:latest' ports: - name: tcp-80 containerPort: 80 protocol: TCP imagePullPolicy: IfNotPresent
结果如下,由此可以得出结论如果任一标签被禁用,则不会注入 pod:
[root@master1 ~]# kubectl get pods -n=zmc NAME READY STATUS RESTARTS AGE nginx-v1-547569d76b-l8dk4 1/1 Running 0 2s
示例2:namespace无istio-injection=disabled标签,sidecar.istio.io/inject="true":
[root@master1 ~]# kubectl label namespace zmc istio-injection- namespace/zmc labeled [root@master1 ~]# kubectl get pods -n=zmc No resources found in zmc namespace.
在zmc命令空间下创建和示例一配置文件一样的deployment,结果如下,由此可以得出结论如果启用了任一标签,则注入 pod:
[root@master1 ~]# kubectl get pods -n=zmc NAME READY STATUS RESTARTS AGE nginx-v1-547569d76b-58hgv 2/2 Running 0 8s
示例三:启用.values.sidecarInjectorWebhook.enableNamespacesByDefault(目前测试结果与官方文档不一致)
如果两个标签都未设置,不会注入Pod,例如我们新建一个namespace不加任何标签,然后在此namespace下新建一个Pod也不加任何标签,发现创建出来的Pod只有一个容器,由此可以得出默认情况下如果两个标签都未设置,不会注入Pod,此例子比较简单本文就不再测试。
接下来我们启用.values.sidecarInjectorWebhook.enableNamespacesByDefault来验证在此参数启用后默认注入pod。
使用如下命令调整istio注入参数值修改:
kubectl edit configmaps -n=istio-system istio-sidecar-injector
将enableNamespacesByDefault参数值由默认false改成true。
"sidecarInjectorWebhook": { "alwaysInjectSelector": [], "defaultTemplates": [], "enableNamespacesByDefault": false, "injectedAnnotations": {}, "neverInjectSelector": [], "objectSelector": { "autoInject": true, "enabled": true }, "rewriteAppHTTPProbe": true, "templates": {} } } kind: ConfigMap
按照官方文档修改enableNamespacesByDefault参数之后,重启istiod服务,创建新的namespace,在此namespace新建pod,都未指定任何标签,发现创建出来的Pod只有一个容器与预期结果不一致,由于开启enableNamespacesByDefault场景暂时没想到,此示例不再继续测试。
2、Istio Sidecar自动注入配置
Sidecar 自动注入机制是将 sidecar 代理自动添加到用户创建的 pod。
它使用 MutatingWebhook
机制在 pod 创建的时候将 sidecar 的容器和卷添加到每个 pod 的模版里。
用户可以通过 webhooks namespaceSelector
机制来限定需要启动自动注入的范围,也可以通过注解的方式针对每个 pod 来单独启用和禁用自动注入功能。
Sidecar 是否会被自动注入取决于下面 3 条配置和 2 条安全规则:
配置:
- webhooks
namespaceSelector
- 默认策略
policy
- pod 级别的覆盖注解
安全规则:
- sidecar 默认不能被注入到
kube-system
和kube-public
这两个 namespace - sidecar 不能被注入到使用
host network
网络的 pod 里
下面的表格展示了基于上述三个配置条件的最终注入状态。上述的安全规则不会被覆盖。
namespaceSelector 匹配 | 默认策略 | Pod 覆盖 sidecar.istio.io/inject 注解 | Sidecar 是否注入? |
---|---|---|---|
yes | enabled | true (default) | yes |
yes | enabled | false | no |
yes | disabled | true | yes |
yes | disabled | false (default) | no |
no | enabled | true (default) | no |
no | enabled | false | no |
no | disabled | true | no |
no | disabled | false (default) | no |
Istio1.12.1通过istio-revision-tag-default和istio-sidecar-injector这两个mutatingwebhookconfigurations来限定需要启动自动注入的范围,逻辑比较简单,本文不再介绍,注入结果和上述表格一致,想了解更多webhookconfigurations内容请参见:Kubernetes AdmissionWebhook 、 Kubernetes构建自定义admission webhook 和Kubernetes AdmissionWebhook匹配请求这三篇文章。
参考:https://istio.io/latest/zh/docs/setup/additional-setup/sidecar-injection/
参考:https://istio.io/latest/zh/docs/ops/configuration/mesh/injection-concepts/