helm-使用預定義的流順序運行pod和依賴項-有解無憂

我正在使用帶掌舵的 K8S。

我需要使用預定義的流順序運行 pod 和依賴項。

如何創建僅運行一次 pod 的 helm 依賴項（即 - 第一次填充資料庫），并在第一次成功后退出？

此外，如果我有多個 pod，并且我只想在某些條件發生并且在創建 pod 之后運行 pod。

需要構建 2 個 Pod，如下所述：

我有一個資料庫。

第一步是創建資料庫。

第二步是填充資料庫。

一旦我填充了資料庫，這項作業就需要完成。

第三步是另一個使用該資料庫的 pod（不是 db pod），并且始終處于偵聽模式（永不停止）。

我可以定義依賴項的運行順序（并不總是并行）。

我看到的helm create命令有 deployment.yaml 和 service.yaml 的模板，也許 pod.yaml 是更好的選擇？

這種情況下最好的圖表型別是什么？

此外，需要知道什么是圖表層次結構。

即：當有一個型別的圖表時：監聽器，一個用于創建資料庫的 pod，以及一個用于資料庫填充的 pod（完成后洗掉），我可能有一個圖表樹層次結構來解釋流程。

helm - 使用預定義的流順序運行 pod 和依賴項

主圖表使用填充資料（在所有子圖表和模板正常運行之后 - 順便說一句，我可以為同一個圖表提供多個模板嗎？）。

什么是正確的樹流

謝謝。

uj5u.com熱心網友回復：

helm 創建資源有一個固定的順序，除了hooks之外你無法影響。

根據我的經驗，Helm 掛鉤可能會導致比它們解決的問題更多的問題。這是因為大多數情況下，它們實際上依賴于僅在鉤子完成后才可用的資源。例如，配置映射、機密和服務帳戶/角色系結。引導您將越來越多的東西移動到鉤子生命周期中，這不是 IMO 慣用的。在卸載版本時，它也會讓它們懸空。

我傾向于使用阻塞直到作業完成的作業和初始化容器。

---
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

uj5u.com熱心網友回復：

您可以使用 helm hooks 和 K8s Jobs 來實作這一點，下面是為 Rails 應用程式定義相同的設定。

第一步，定義一個 k8s 作業來創建和填充 db

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- Job 定義有 helm hooks 可以在每個部署上運行并成為第一個任務

    "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- 在 db-connection 啟動之前，作業不會開始（這是通過 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 }}

uj5u.com熱心網友回復：

如果我理解正確，您希望在部署策略中構建依賴鏈，以確保在您的任何應用程式啟動之前準備好某些事情。在您的情況下，您需要在應用程式啟動之前部署和預填充資料庫。

我建議不要構建這樣的依賴鏈，因為它會使您的部署管道中的事情變得復雜，并且如果您將來開始部署多個應用程式，則會阻礙您的部署程序的適當擴展。在 Kubernetes 等高度動態的環境中，每個部署都應該能夠檢查它自己啟動所需的先決條件，而不依賴于部署順序。

這可以通過和的組合來initContainers實作probes。可以為每個部署指定兩者，以防止在不滿足某些先決條件時失敗和/或在服務開始將流量路由到您的部署（在您的情況下為資料庫）之前滿足某些先決條件。

簡而言之：

要在資料庫啟動之前填充資料庫卷，請使用initContainer
要讓資料庫在其初始化和預填充之后為流量提供服務，請定義probes以檢查這些條件。livenessProbe您的資料庫只會在其readinessProbe成功后才開始服務流量。如果需要額外的時間，請保護 pod 不被startupProbe.
為確保您的應用程式部署不會在資料庫準備好之前啟動和失敗，請使用 aninitContainer檢查資料庫是否已準備好在應用程式啟動之前為流量提供服務。

退房

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-探針/

了解更多資訊。

轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/434278.html

標籤：Kubernetes kubernetes-helm 工作

上一篇：oracle減去上一行

下一篇：滾動更新期間無法訪問GKEDjangoMySQL