istio部署-sidecar注入

参考

1. Sidecar注入

1.1 对工作负载的一些要求

支持的工作负载类型：Job，DaemonSet，ReplicaSet，Pod，Deployment 等，对这些工作负载的要求如下：
- 要正确命名服务端口：
  - Service 对象中的 Port 部分必须以 "协议名" 为前缀，目前支持的协议名包括 http，http2，mongo，redis 与 grpc；
  - istio 会命名来确定为端口提供什么样的服务，不符合命名规范的端口会被当做 TCP 服务器，其功能支持范围会大幅缩小。
- 工作负载的 Pod 必须有关联的 Service：
  - 为满足服务发现的需要，所有 Pod 都必须有关联的服务；
  - 官方建议为 Pod 模板加入两个标签：app 与 version，分别标注应用名称与版本，虽仅是个建议，但 istio 很多默认策略会引用这两个标签，如果没有会引发很多不必要的麻烦。

1.2 手工注入

# 准备测试用 yaml 文件
cd ~
git clone https://github.com/fleeto/flaskapp.git
cd ~/flaskapp

# istioctl kube-inject 会将 istio 相关容器注入应用，"-o" 参数将注入结果生成 yaml 文件 ，方便观察使用此命令与 "kubectl apply -f" 的区别；
# 新的 yaml 文件中多出了 "Sidecar" 容器， 并且出现了1个初始化容器 (initContainers) "istio-init" ，初始化容器即用来劫持应用通信到 "Sidecar" 容器的工具；
# 可直接 "kubectl apply -f" 生成的 yaml 文件
istioctl kube-inject -f flask.istio.yaml -o flask.istio.injected.yaml

1.3 自动注入

1.3.1 配置自动注入

istio 的自动注入属性可通过 values.yaml 文件调整。

# istio-1.1.7/install/kubernetes/helm/istio/values.yaml

sidecarInjectorWebhook:
  # 开启 "Sidecar" 自动注入特性
  enabled: true
  replicaCount: 1
  image: sidecar_injector
  # "true"：为所有命名空间开启自动注入功能
  # "false"：只有标签为 "istio-injection: enabled" 的命名空间开启自动注入功能
  # 默认值："false"
  enableNamespacesBydefault: false
...
global:
  proxy:
    # 启动自动注入功能后，对于指定命名空间内新建 Pod 是否进行自动注入；
    # "enabled"：命名空间内的 Pod 只要没有被注解为 'sidecar.istio.io/inject: "false"'，就会自动完成注入；
    # "disabled"：需要为 Pod 注解 'sidecar.istio.io/inject: "true"'，才会进行注入；
    # "sidecar.istio.io/inject" 没有所谓的默认值，未注解时，取决于 "autoInject" 的设置，"enabled" 则注入，"disabled" 则不注入
    autoInject: enabled

1.3.2 测试

kubectl create ns auto
kubectl create ns manually

# 为命名空间 auto 注入标签
kubectl label namespaces auto istio-injection=enabled

# 在两个命名空间创建工作负载
cd ~
git clone https://github.com/fleeto/sleep.git
cd ~/sleep
kubectl apply -f sleep.yaml -n auto
kubectl apply -f sleep.yaml -n manually

# 查看命名空间 auto 是否有自动注入
kubectl get pod -n auto
kubectl get pod -n manually

1.3.3 ConfigMap istio-sidecar-injector

1.3.3.1 ConfigMap istio-sidecar-injector

不管是手工注入或自动注入，都可以通过编辑 istio-system 命名空间中名为 istio-sidecar-injector 的 ConfigMap资源，来影响注入效果；涉及两个标签（与 policy 同级）：

neverInjectSelector：不管命名空间及策略如何，对符合标签选择器要求的 Pod 都不进行注入；

# 以下两个元素之间是 "或" 关系
neverInjectSelector:
  - matchExpressions:
    - {key: openshift.io/build.name, operator: Exists}
  - matchExpressions:
    - {key: openshift.io/deployer-pod--for.name, operator: Exists}

alwaysInjectSelector：对符合标签选择器要求的 Pod ，不管全局策略如何，都会被注入 Sidecar。

1.3.3.2 修改 istio-sidecar-injector

istioctl 根据 ConfigMap 获取注入内容，即执行 istioctl 的用户必须能够访问安装了 istio 的 Kubernetes 集群中的这个 ConfigMap ；

# 如果因某些原因不能访问，可以在 "istioctl" 中使用本地的配置文件；
# 采用具备 "ConfigMap" 获取权限的用户身份执行以下命令
kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml

# 可对文件进行修改，并在 "istioctl" 中使用
istioctl kube-inject --injectConfigFile inject-config.yaml

1.3.4 自动注入的优先级

自动注入的评估顺序：
Pod 注解（优先级最高，如 Pod 中含注解 sidecar.istio.io/inject: "true/false"，则会被优先处理） --> neverInjectSelector --> alwaysInjectSelector --> 命名空间策略。
autoInject，命名空间，Pod 注解的关联关系如下表：

命名空间，istio-injection=enabled	autoInject	Pod，sidecar.istio.io/inject	是否注入
是	enabled	true	是
是	enabled	false	否
是	enabled	未注解	是
是	disabled	true	是
是	disabled	false	否
是	disabled	未注解	否
否	enabled	true	否
否	enabled	false	否
否	enabled	未注解	否
否	disabled	true	否
否	disabled	false	否
否	disabled	未注解	否

1.3.5 Sidecar 注入故障排查

查看 sidecar-injector Pod 资源日志；

kubectl logs -f $(kubectl get pods -n istio-system -l istio=sidecar-injector -o jsonpath='{.items[0].metadata.name}') -n istio-system

创建业务 Pod ，查看日志输出；
更详细的日志，可以编辑 sidecar-injector Deployment对象，为其添加 args 参数 --log_output_level=default:debug；
如果在 sidecar-injector Pod 资源日志还是未找到发生问题的原因，则代表 sidecar-injector 没有收到 Pod 创建的通知，也就不会触发自动注入操作，这可能是因为命名空间没有正确设置标签导致的，需要检查命名空间的标签及 MutatingWebhookConfiguration 中的配置：
```
# 命名空间默认设置 "istio-injection=anabled" 标签；
# 可以检查其中的 "namespaceSelector" 字段与内容
kubectl edit MutatingWebhookConfiguration istio-sidecar-injector -n istio-system
```

posted @ 2019-11-29 01:24 Netonline 阅读(2295) 评论(0) 编辑收藏举报

刷新页面返回顶部