istio部署-sidecar注入

参考

• fleeto/sleep
• fleeto/flaskapp

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