istio部署-sidecar注入

参考

  • fleeto/sleep
  • fleeto/flaskapp

1. Sidecar注入

1.1 对工作负载的一些要求

  • 支持的工作负载类型:JobDaemonSetReplicaSetPodDeployment 等, 对这些工作负载的要求如下:
    • 要正确命名服务端口:
      • Service 对象中的 Port 部分必须以 "协议名" 为前缀,目前支持的协议名包括 httphttp2mongoredisgrpc
      • istio 会命名来确定为端口提供什么样的服务,不符合命名规范的端口会被当做 TCP 服务器,其功能支持范围会大幅缩小。
    • 工作负载的 Pod 必须有关联的 Service:
      • 为满足服务发现的需要,所有 Pod 都必须有关联的服务;
      • 官方建议为 Pod 模板加入两个标签:appversion,分别标注应用名称与版本,虽仅是个建议,但 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-injectorConfigMap资源,来影响注入效果;涉及两个标签(与 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

你可能感兴趣的:(istio部署-sidecar注入)