istio sidecar 的envoy进程在kubernetes job中如何优雅退出？

istio sidecar 的envoy进程在kubernetes job中如何优雅退出？

istio 是service mesh的一个流行框架，提供了很多服务网格相关的功能，在安全方面，流量控制方面都有很多很实用的功能，这篇文档重点不在于讨论istio的功能多么强大，主要是解决使用istio过程中遇到的一些问题，以及如何解决。

istio在cloud 环境，主要是指kubernetes环境，它会为每一个microservice的pod注入一个sidecar，这样子来把微服务加入到服务网格的治理中。它通过拦截配置，重导pod的进出网络到它的sidecar，也就是envoy，达到控制整个服务网格网络的目的。

对deployment，statulset等常驻进程而言，istio的sidecar可以正常运行，并伴随着pod的生命周期终止和结束。

但是对于job这种类型的资源，在job completed时候，只有主进程退出，但是istio给job注入的sidecar却无法退出，这样job就永远处于执行过程中，而无法退出，job也永远无法completed。

这篇文档就是提供一种解决思路，假设我们有一个如下的job定义

apiVersion: batch/v1
kind: Job
metadata:
  name: sleep-job
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      containers:
      - name: busybox
        image: busybox:latest
        imagePullPolicy: IfNotPresent
        command: ["bash", "-c", "sleep 10"]
      restartPolicy: Never
  backoffLimit: 4

这个job的功能很简单，sleep 10秒之后，就退出，这样这个job就算完成了，但是如果istio给这个job注入sidecar之后，这个job就没办法完成了，这个job的pod有两个contaner，一个是envoy sidecar，一个是sleep主进程

因此我们的思路是如何在sleep执行完成之后，退出envoy sidecar的进程

首先我们的想法转换成代码可能就是大概如下：

bash -c "sleep 10; "

关键在于如何quit envoy？首先想到的就是kill envoy的进程号，但是sleep进程和envoy进程在不同容器里面，如何kill到另一个容器的进程号呢？

一番查找之后发现k8s的这个功能
shareProcessNamespace

https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/

打开这个功能之后，进程对容器中的其他容器可见。这包括中的所有可见信息/proc，例如作为参数或环境变量传递的密码。这些仅受常规Unix权限保护。

因此打开这个开关之后，可以在sleep容器里面看到envoy的进程，它的进程名是pilot-agent，因此我们的代码就变成了

apiVersion: batch/v1
kind: Job
metadata:
  name: sleep-job
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      shareProcessNamespace: true
      containers:
      - name: busybox
        image: busybox:latest
        imagePullPolicy: IfNotPresent
        command: ["bash", "-c", "sleep 10; pkill pilot-agent"]
        securityContext:
          capabilities:
            add:
              - SYS_PTRACE
      restartPolicy: Never
  backoffLimit: 4

但是实际运行又遇到新的问题，那就是sidecar和sleep容器的先后顺序，因为image的pull有先后，而且启动也有先后，所以有可能sleep进程结束后，但是sidecar还没起来，这样子pkill就kill了个寂寞。

所以我们还需要优化一下命令，就是在sleep 10之前先等待sidecar ready，就变成了如下

command: ["bash", "-c", "until [[ $(curl -o /dev/null -s -w '%{http_code}' localhost:15000/ready) == '200' ]]; do echo 'Waiting for Envoy Sidecar.' sleep 3 ;done;sleep 10; pkill pilot-agent"]

这里我们调用envoy的api 接口ready来判断envoy是否已经running并且ready

看到这里，是不是觉得已经够了

其实实际上还有一个问题，这里的退出都是正常退出，如果遇到异常情况，比如这里的命令不是sleep 10，而是其它脚本，那有可能执行出错，如果这时候还是正常退出，那就会有问题了，因为这样job就会表现执行成功并完毕，但是不会重新执行出错的任务。

因此需要判断主要命令的exitcode是0还是非0，然后再以相应的exitcode退出进程

封装一个shell命令如下，命名为wait-and-quit-envoy

#!/usr/bin/env bash

ENVOY_READY_URL="localhost:15000/ready"
until [[ $(curl -o /dev/null -s -w '%{http_code}' ${ENVOY_READY_URL}) == '200' ]]; do
   echo "Waiting for Envoy Sidecar."
   sleep 3
done
echo "Envoy Sidecar available."
sleep 5
$@
exitcode=$?;
if [[ ${exitcode} == 0 ]];then
 # Make Sidecar quit normally.
 pkill -15 pilot-agent > /dev/null 2>&1;
else
 # Make Sidecar quit abnormally.
 pkill -9 pilot-agent
fi
exit ${exitcode}

这个shell命令用$@来执行命令后面附加的所有命令，最后记录命令执行的exitcode，最后用这个exitcode退出进程。
然后把这个脚本打包进去image

apiVersion: batch/v1
kind: Job
metadata:
  name: sleep-job
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      shareProcessNamespace: true
      containers:
      - name: busybox
        image: busybox:latest
        imagePullPolicy: IfNotPresent
        command: ["bash", "-c", "wait-and-quit-envoy sleep 10"]
        securityContext:
          capabilities:
            add:
              - SYS_PTRACE
      restartPolicy: Never
  backoffLimit: 4

最后就实现了这个优雅等待并且退出 istio sidecar的功能