istio sidecar 的envoy進程在kubernetes job中如何優(yōu)雅退出？

istio 是service mesh的一個流行框架，提供了很多服務(wù)網(wǎng)格相關(guān)的功能，在安全方面，流量控制方面都有很多很實用的功能，這篇文檔重點不在于討論istio的功能多么強大，主要是解決使用istio過程中遇到的一些問題，以及如何解決。

istio在cloud 環(huán)境，主要是指kubernetes環(huán)境，它會為每一個microservice的pod注入一個sidecar，這樣子來把微服務(wù)加入到服務(wù)網(wǎng)格的治理中。它通過攔截配置，重導(dǎo)pod的進出網(wǎng)絡(luò)到它的sidecar，也就是envoy，達(dá)到控制整個服務(wù)網(wǎng)格網(wǎng)絡(luò)的目的。

對deployment，statulset等常駐進程而言，istio的sidecar可以正常運行，并伴隨著pod的生命周期終止和結(jié)束。

但是對于job這種類型的資源，在job completed時候，只有主進程退出，但是istio給job注入的sidecar卻無法退出，這樣job就永遠(yuǎn)處于執(zhí)行過程中，而無法退出，job也永遠(yuǎn)無法completed。

這篇文檔就是提供一種解決思路，假設(shè)我們有一個如下的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執(zhí)行完成之后，退出envoy sidecar的進程

首先我們的想法轉(zhuǎn)換成代碼可能就是大概如下：

bash -c "sleep 10; <quit envoy>"

關(guān)鍵在于如何quit envoy？首先想到的就是kill envoy的進程號，但是sleep進程和envoy進程在不同容器里面，如何kill到另一個容器的進程號呢？

一番查找之后發(fā)現(xiàn)k8s的這個功能
shareProcessNamespace

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

打開這個功能之后，進程對容器中的其他容器可見。這包括中的所有可見信息/proc，例如作為參數(shù)或環(huán)境變量傳遞的密碼。這些僅受常規(guī)Unix權(quán)限保護。

因此打開這個開關(guān)之后，可以在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進程結(jié)束后，但是sidecar還沒起來，這樣子pkill就kill了個寂寞。

所以我們還需要優(yōu)化一下命令，就是在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"]

這里我們調(diào)用envoy的api 接口ready來判斷envoy是否已經(jīng)running并且ready

看到這里，是不是覺得已經(jīng)夠了

其實實際上還有一個問題，這里的退出都是正常退出，如果遇到異常情況，比如這里的命令不是sleep 10，而是其它腳本，那有可能執(zhí)行出錯，如果這時候還是正常退出，那就會有問題了，因為這樣job就會表現(xiàn)執(zhí)行成功并完畢，但是不會重新執(zhí)行出錯的任務(wù)。

因此需要判斷主要命令的exitcode是0還是非0，然后再以相應(yīng)的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命令用$@來執(zhí)行命令后面附加的所有命令，最后記錄命令執(zhí)行的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

最后就實現(xiàn)了這個優(yōu)雅等待并且退出 istio sidecar的功能