我们最近开始使用istio Istio在Kubernetes范围内建立服务网格。
我们现在遇到的问题是,如果将istioistio-proxy
sidecar容器注入其中,作业和cronjobs不会终止并永远运行。尽管要建立正确的mTLS与工作所需交谈的服务并符合我们的安全法规的mTLS连接,但应注入istio-proxy
。
[我也注意到Istio(istio/issues/6324)和kubernetes(kubernetes/issues/25908)内部存在未解决的问题,但似乎两者都不会很快提供有效的解决方案。
起初,停止前挂钩似乎很适合解决此问题,但此概念本身有些困惑:kubernetes/issues/55807
lifecycle:
preStop:
exec:
command:
...
底线:如果容器成功完成,则不会执行这些钩子。
[GitHub上还有一些相对较新的项目试图使用专用控制器来解决此问题(我认为这是最可取的方法,但是对于我们的团队来说,他们还不够成熟,无法立即将其投入生产:
同时,我们自己完成了以下变通方法,该变通方法可以执行到边车中并发送SIGTERM
信号,但前提是主容器成功完成:
apiVersion: v1
kind: ServiceAccount
metadata:
name: terminate-sidecar-example-service-account
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: terminate-sidecar-example-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get","delete"]
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: terminate-sidecar-example-rolebinding
subjects:
- kind: ServiceAccount
name: terminate-sidecar-example-service-account
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: terminate-sidecar-example-role
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: terminate-sidecar-example-cronjob
labels:
app: terminate-sidecar-example
spec:
schedule: "30 2 * * *"
jobTemplate:
metadata:
labels:
app: terminate-sidecar-example
spec:
template:
metadata:
labels:
app: terminate-sidecar-example
annotations:
sidecar.istio.io/inject: "true"
spec:
serviceAccountName: terminate-sidecar-example-service-account
containers:
- name: ****
image: ****
command:
- "/bin/ash"
- "-c"
args:
- node index.js && kubectl exec -n ${POD_NAMESPACE} ${POD_NAME} -c istio-proxy -- bash -c "sleep 5 && /bin/kill -s TERM 1 &"
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
所以,对大家的最终问题是:您知道更好的解决方法,解决方案,控制器... ...这样的做法不太hacky /更适合在主容器完成后终止istio-proxy
容器它的工作?
这不是错误的配置,这是上游Kubernetes中的错误。截至2019年9月,此has been resolved由Istio通过向飞行员代理引入/quitquitquit
端点而实现。
[不幸的是,Kubernetes拥有not been so steadfast自己解决了这个问题。因此它仍然确实存在于某些方面。但是,对于此特定用例,Istio中的/quitquitquit
端点应该已经解决了该问题。