helm - 使用预定义的流程顺序运行 Pod 和依赖项

Question

我正在使用带有 helm 的 K8S。

我需要使用预定义的流程顺序运行 Pod 和依赖项。

如何创建仅运行 pod 一次（即首次填充数据库）并在第一次成功后退出的 helm 依赖项？

另外，如果我有多个 pod，并且我只想在某些条件发生时以及创建 pod 之后运行该 pod。

需要构建2个pod，描述如下：

我有一个数据库。

第一步是创建数据库。

第二步是填充数据库。

一旦我填充数据库，这项工作就需要完成。

第三步是另一个使用该数据库的 pod（不是 db pod），并且始终处于监听模式（永不停止）。

我可以定义依赖项运行的顺序（并且并不总是并行的）。

我在 helm create 命令中看到的是，有用于deployment.yaml 和service.yaml 的模板，也许pod.yaml 是更好的选择？

对于这种情况，最好的图表类型是什么？

另外，需要知道什么是图表层次结构。

即：当有一个类型为侦听器的图表、一个用于数据库创建的 pod 和一个用于数据库填充的 pod（完成后删除）时，我可能有一个解释流程的图​​表树层次结构。

主图表使用填充的数据（在所有子图表和模板都正确运行之后 - 顺便说一句，我可以为同一个图表拥有多个模板吗？）。

什么是正确的树流程

谢谢。

Answer 1

helm 创建资源有一个固定的顺序，除了 hooks 之外，您无法影响该顺序。

根据我的经验，Helm hook 引起的问题比它们解决的问题还要多。这是因为大多数情况下它们实际上依赖于只有在挂钩完成后才可用的资源。例如，配置映射、机密和服务帐户/角色绑定。导致你将越来越多的东西移入钩子生命周期，这在我看来并不符合习惯。卸载版本时，它们也会悬而未决。

我倾向于使用作业和初始化容器，这些容器会阻塞直到作业完成。

---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    name: mysql
spec:
  containers:
    - name: mysql
      image: mysql
---
apiVersion: batch/v1
kind: Job
metadata:
  name: migration
spec:
  ttlSecondsAfterFinished: 100
  template:
    spec:
      initContainers:
        - name: wait-for-db
          image: bitnami/kubectl
          args:
            - wait
            - pod/mysql
            - --for=condition=ready
            - --timeout=120s
      containers:
        - name: migration
          image: myapp
          args: [--migrate]
      restartPolicy: Never
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  replicas: 3
  template:
    metadata:
      labels:
        app: myapp
    spec:
      initContainers:
        - name: wait-for-migration
          image: bitnami/kubectl
          args:
            - wait
            - job/migration
            - --for=condition=complete
            - --timeout=120s
      containers:
        - name: myapp
          image: myapp
          args: [--server]

如果您想水平扩展应用程序，则将迁移移至其自己的工作中是有益的。您的迁移只需运行 1 次。因此，为每个部署的副本运行它是没有意义的。

此外，如果 Pod 崩溃并重新启动，迁移不需要再次运行。因此，将其放在单独的一次性工作中是有意义的。

主要图表结构如下所示。

.
├── Chart.lock
├── charts
│   └── mysql-8.8.26.tgz
├── Chart.yaml
├── templates
│   ├── deployment.yaml    # waits for db migration job
│   └── migration-job.yaml # waits for mysql statefulset master pod
└── values.yaml

Answer 2

您可以使用 helm hooks 和 K8s Jobs 来实现这一点，下面为 Rails 应用程序定义相同的设置。

第一步，定义一个 k8s 作业来创建并填充数据库，

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ template "my-chart.name" . }}-db-prepare
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "-1"
    "helm.sh/hook-delete-policy": hook-succeeded
  labels:
    app: {{ template "my-chart.name" . }}
    chart: {{ template "my-chart.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  backoffLimit: 4
  template:
    metadata:
      labels:
        app: {{ template "my-chart.name" . }}
        release: {{ .Release.Name }}
    spec:
      containers:
      - name: {{ template "my-chart.name" . }}-db-prepare
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        command: ["/docker-entrypoint.sh"]
        args: ["rake", "db:extensions", "db:migrate", "db:seed"]
        envFrom:
        - configMapRef:
            name: {{ template "my-chart.name" . }}-configmap
        - secretRef:
            name: {{ if .Values.existingSecret }}{{ .Values.existingSecret }}{{- else }}{{ template "my-chart.name" . }}-secrets{{- end }}
      initContainers:
      - name: init-wait-for-dependencies
        image: wshihadeh/wait_for:v1.2
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        command: ["/docker-entrypoint.sh"]
        args: ["wait_for_tcp", "postgress:DATABASE_HOST:DATABASE_PORT"]
        envFrom:
        - configMapRef:
            name: {{ template "my-chart.name" . }}-configmap
        - secretRef:
            name: {{ if .Values.existingSecret }}{{ .Values.existingSecret }}{{- else }}{{ template "my-chart.name" . }}-secrets{{- end }}
      imagePullSecrets:
      - name: {{ .Values.imagePullSecretName }}
      restartPolicy: Never

请注意以下事项：
1- 作业定义具有在每个部署上运行的 helm 挂钩，并且是第一个任务

    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "-1"
    "helm.sh/hook-delete-policy": hook-succeeded

2- 容器命令将负责准备数据库

command: ["/docker-entrypoint.sh"]
args: ["rake", "db:extensions", "db:migrate", "db:seed"]

3- 作业将在数据库连接启动之前启动（这是实现的）通过 initContainers）

args: ["wait_for_tcp", "postgress:DATABASE_HOST:DATABASE_PORT"]

第二步是定义应用程序部署对象。这可以是常规部署对象（确保您不使用 helm hooks ）示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ template "my-chart.name" . }}-web
  annotations:
    checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum  }}
    checksum/secret: {{ include (print $.Template.BasePath "/secrets.yaml") . | sha256sum  }}
  labels:
    app: {{ template "my-chart.name" . }}
    chart: {{ template "my-chart.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  replicas: {{ .Values.webReplicaCount }}
  selector:
    matchLabels:
      app: {{ template "my-chart.name" . }}
      release: {{ .Release.Name }}
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum  }}
        checksum/secret: {{ include (print $.Template.BasePath "/secrets.yaml") . | sha256sum  }}
      labels:
        app: {{ template "my-chart.name" . }}
        release: {{ .Release.Name }}
        service: web
    spec:
      imagePullSecrets:
      - name: {{ .Values.imagePullSecretName }}
      containers:
        - name: {{ template "my-chart.name" . }}-web
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          command: ["/docker-entrypoint.sh"]
          args: ["web"]
          envFrom:
          - configMapRef:
              name: {{ template "my-chart.name" . }}-configmap
          - secretRef:
              name: {{ if .Values.existingSecret }}{{ .Values.existingSecret }}{{- else }}{{ template "my-chart.name" . }}-secrets{{- end }}
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          resources:
{{ toYaml .Values.resources | indent 12 }}
      restartPolicy: {{ .Values.restartPolicy  }}
    {{- with .Values.nodeSelector }}
      nodeSelector:
{{ toYaml . | indent 8 }}
    {{- end }}
    {{- with .Values.affinity }}
      affinity:
{{ toYaml . | indent 8 }}
    {{- end }}
    {{- with .Values.tolerations }}
      tolerations:
{{ toYaml . | indent 8 }}
    {{- end }}

Answer 3

如果我理解正确的话，您希望在部署策略中构建依赖链，以确保在任何应用程序启动之前准备好某些事情。就您而言，您需要在应用程序启动之前部署和预填充数据库。

我建议不要构建这样的依赖链，因为它会使部署管道中的事情变得复杂，并且如果您将来开始部署多个应用程序，则会阻止部署流程的适当扩展。在像 kubernetes 这样的高度动态环境中，每个部署都应该能够检查自己启动所需的先决条件，而不依赖于部署顺序。

这可以通过结合使用 initContainers 和 probes 来实现。两者都可以在每个部署中指定，以防止在不满足某些先决条件的情况下失败和/或在服务开始将流量路由到您的部署（在您的情况下是数据库）之前满足某些先决条件。

简而言之：

• 要在数据库启动之前填充数据库卷，请使用 initContainer
• 让数据库在初始化和预填充后提供流量，定义 probes > 检查这些条件。您的数据库只有在 livenessProbe 和 readinessProbe 成功后才会开始提供流量。如果需要额外的时间，请使用 startupProbe 保护 Pod 不被终止。
• 为了确保您的应用部署在数据库准备就绪之前不会启动并失败，请使用 initContainer 在您的应用启动之前检查数据库是否已准备好提供流量。

查看

• https://12factor.net/（动态系统的一般指南）
• https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#init-containers
  https://kubernetes.io/docs /tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

了解更多信息。