Question

我们最近开始使用istio Istio在Kubernetes范围内建立服务网格。

我们现在遇到的问题是，如果将istio istio-proxy sidecar容器注入到作业中，作业和cronjobs不会终止并且永远运行。 istio-proxy应该被注入，尽管它可以建立正确的mTLS与工作所需交谈的服务的连接并遵守我们的安全法规。

我还注意到Istio（istio/issues/6324）和kubernetes（kubernetes/issues/25908）内部存在未解决的问题，但似乎两者都无法在短期内提供有效的解决方案。

起初，停止前挂钩似乎很适合解决此问题，但是这种概念本身存在一些困惑：kubernetes/issues/55807

lifecycle:
  preStop:
    exec:
      command: 
        ...

底线：如果容器成功完成，则不会执行这些钩子。

GitHub上还有一些相对较新的项目试图使用专用控制器（我认为这是最可取的方法）来解决这个问题，但是对于我们的团队来说，他们还不够成熟，无法立即将它们投入生产： / p>

同时，我们自己完成了以下变通方法，该变通方法可以执行到边车中并发送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

因此，对大家来说，最终的问题是：您是否知道任何更好的解决方法，解决方案，控制器…………这样，它的安全性就会降低/更适合一次终止istio-proxy容器主容器完成了工作？

Answer 1

- command:
  - /bin/sh
  - -c
  - |
    until curl -fsI http://localhost:15021/healthz/ready; do echo \"Waiting for Sidecar...\"; sleep 3; done;
    echo \"Sidecar available. Running the command...\";
    <YOUR_COMMAND>;
    x=$(echo $?); curl -fsI -X POST http://localhost:15020/quitquitquit && exit $x

Answer 2

这不是配置错误，这是上游Kubernetes的错误。截至2019年9月，此has been resolved由Istio通过将/quitquitquit端点引入到Pilot代理来实现。

不幸的是，Kubernetes已经not been so steadfast自己解决了这个问题。因此它仍然确实存在于某些方面。但是，Istio中的/quitquitquit端点应该已经解决了此特定用例的问题。

Answer 3

我已经找到了解决方法，方法是按照链接Istio文档编辑istio-sidecar-injector的configmap

https://istio.io/docs/setup/additional-setup/sidecar-injection/

apiVersion: v1 kind: ConfigMap metadata: name: istio-sidecar-injector data: config: |- policy: enabled neverInjectSelector: - matchExpressions: - {key: job-name, operator: Exists} 但是随着这种变化，我们的cronjob sidecar将不会注入，并且istio策略将不适用于cronjob工作，在我们的案例中，我们不希望istio强制执行任何策略

注意：-默认情况下，作业名称是在广告连播创建中添加的标签

Answer 4

在本文中处理它的4种方法 https://medium.com/redbox-techblog/handling-istio-sidecars-in-kubernetes-jobs-c392661c4af7

Answer 5

你试过scuttle吗？它似乎以更干净的方式完成了您正在寻找的工作。

scuttle Is a wrapper application that makes it easy to run containers next to Istio sidecars. It ensures the main application doesn't start until envoy is ready, and that the istio sidecar shuts down when the application exits. This particularly useful for Jobs that need Istio sidecar injection, as the Istio pod would otherwise run indefinitely after the job is completed.

为kubernetes作业/ cronjob终止istio sidecar istio-proxy

5 个答案: