Диаграмма Helm, застрявшая в состоянии подинициализации на неопределенный срок

ProgramBox

Диаграмма Helm, застрявшая в состоянии подинициализации на неопределенный срок

Post author:admin
Запись опубликована:3 мая, 2023
Post category:Вопросы по программированию

#kubernetes #kubernetes-helm #kubernetes-pod #kubernetes-service #kubernetes-deployment

#kubernetes #kubernetes-helm #kubernetes-pod #kubernetes-сервис #kubernetes-развертывание

Вопрос:

Я запускаю кластер microk8s на домашнем сервере Ubuntu, и он подключен к локальному серверу NAS для постоянного хранения. Я использовал ее в качестве своего личного испытательного полигона для изучения Kubernetes, но, похоже, я сталкиваюсь с проблемой за проблемой практически на каждом этапе пути.

У меня установлен Helm chart от NFS Client Provisioner, который, как я подтвердил, работает — он будет динамически предоставлять PVCS на моем сервере NAS. Позже я смог успешно установить диаграмму Helm Postgres, или я так думал. После ее создания я смог подключиться к ней с помощью SQL-клиента, и я чувствовал себя хорошо.

Пока пару дней спустя я не заметил, что модуль показывает готовность контейнеров 0/1. Хотя интересно, что модуль nfs-client-provisioner по-прежнему показывал 1/1. Короче говоря: я удалил / очистил диаграмму Helm Postgres и попытался переустановить ее, но теперь она больше не работает. На самом деле, ничего нового, что я пытаюсь внедрить, не работает. Все выглядит так, как будто это сработает, но затем просто зависает либо при инициализации, либо при создании контейнера навсегда.

В частности, с Postgres команда, которую я выполнял, заключается в следующем:

 helm install --name postgres stable/postgresql -f postgres.yaml

И мой postgres.yaml файл выглядит следующим образом:

 persistence:
    storageClass: nfs-client
    accessMode: ReadWriteMany
    size: 2Gi

Но если я сделаю kubectl get pods , я все еще вижу это:

 NAME                    READY  STATUS    RESTARTS  AGE
nfs-client-provisioner  1/1    Running   1         11d
postgres-postgresql-0   0/1    Init:0/1  0         3h51m

Если я выполняю kubectl describe pod postgres-postgresql-0 , это результат:

 Name:               postgres-postgresql-0
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               stjohn/192.168.1.217
Start Time:         Thu, 28 Mar 2019 12:51:02 -0500
Labels:             app=postgresql
                chart=postgresql-3.11.7
                controller-revision-hash=postgres-postgresql-5bfb9cc56d
                heritage=Tiller
                release=postgres
                role=master
                statefulset.kubernetes.io/pod-name=postgres-postgresql-0
Annotations:        <none>
Status:             Pending
IP:                 
Controlled By:      StatefulSet/postgres-postgresql
Init Containers:
  init-chmod-data:
    Container ID:  
    Image:         docker.io/bitnami/minideb:latest
    Image ID:      
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
      chown -R 1001:1001 /bitnami
      if [ -d /bitnami/postgresql/data ]; then
    chmod  0700 /bitnami/postgresql/data;
      fi

    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        250m
      memory:     256Mi
    Environment:  <none>
    Mounts:
      /bitnami/postgresql from data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-h4gph (ro)
Containers:
  postgres-postgresql:
    Container ID:   
    Image:          docker.io/bitnami/postgresql:10.7.0
    Image ID:       
    Port:           5432/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:      250m
      memory:   256Mi
    Liveness:   exec [sh -c exec pg_isready -U "postgres" -h localhost] delay=30s timeout=5s period=10s #success=1 #failure=6
    Readiness:  exec [sh -c exec pg_isready -U "postgres" -h localhost] delay=5s timeout=5s period=10s #success=1 #failure=6
    Environment:
      PGDATA:             /bitnami/postgresql
      POSTGRES_USER:      postgres
      POSTGRES_PASSWORD:  <set to the key 'postgresql-password' in secret 'postgres-postgresql'>  Optional: false
    Mounts:
      /bitnami/postgresql from data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-h4gph (ro)
Conditions:
  Type              Status
  Initialized       False 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  data-postgres-postgresql-0
    ReadOnly:   false
  default-token-h4gph:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-h4gph
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
             node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

И если я сделаю kubectl get pod postgres-postgresql-0 -o yaml , это результат:

 apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2019-03-28T17:51:02Z"
  generateName: postgres-postgresql-
  labels:
    app: postgresql
    chart: postgresql-3.11.7
    controller-revision-hash: postgres-postgresql-5bfb9cc56d
    heritage: Tiller
    release: postgres
    role: master
    statefulset.kubernetes.io/pod-name: postgres-postgresql-0
  name: postgres-postgresql-0
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: StatefulSet
    name: postgres-postgresql
    uid: 0d3ef673-5182-11e9-bf14-b8975a0ca30c
  resourceVersion: "1953329"
  selfLink: /api/v1/namespaces/default/pods/postgres-postgresql-0
  uid: 0d4dfb56-5182-11e9-bf14-b8975a0ca30c
spec:
  containers:
  - env:
    - name: PGDATA
      value: /bitnami/postgresql
    - name: POSTGRES_USER
      value: postgres
    - name: POSTGRES_PASSWORD
      valueFrom:
    secretKeyRef:
      key: postgresql-password
      name: postgres-postgresql
    image: docker.io/bitnami/postgresql:10.7.0
    imagePullPolicy: Always
    livenessProbe:
      exec:
    command:
    - sh
    - -c
    - exec pg_isready -U "postgres" -h localhost
      failureThreshold: 6
      initialDelaySeconds: 30
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5
    name: postgres-postgresql
    ports:
    - containerPort: 5432
      name: postgresql
      protocol: TCP
    readinessProbe:
      exec:
    command:
    - sh
    - -c
    - exec pg_isready -U "postgres" -h localhost
      failureThreshold: 6
      initialDelaySeconds: 5
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5
    resources:
      requests:
    cpu: 250m
    memory: 256Mi
    securityContext:
      procMount: Default
      runAsUser: 1001
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /bitnami/postgresql
      name: data
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-h4gph
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostname: postgres-postgresql-0
  initContainers:
  - command:
    - sh
    - -c
    - |
      chown -R 1001:1001 /bitnami
      if [ -d /bitnami/postgresql/data ]; then
    chmod  0700 /bitnami/postgresql/data;
      fi
    image: docker.io/bitnami/minideb:latest
    imagePullPolicy: Always
    name: init-chmod-data
    resources:
      requests:
    cpu: 250m
    memory: 256Mi
    securityContext:
      procMount: Default
      runAsUser: 0
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /bitnami/postgresql
      name: data
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-h4gph
      readOnly: true
  nodeName: stjohn
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext:
    fsGroup: 1001
  serviceAccount: default
  serviceAccountName: default
  subdomain: postgres-postgresql-headless
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: data-postgres-postgresql-0
  - name: default-token-h4gph
    secret:
      defaultMode: 420
      secretName: default-token-h4gph
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2019-03-28T17:51:02Z"
    message: 'containers with incomplete status: [init-chmod-data]'
    reason: ContainersNotInitialized
    status: "False"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2019-03-28T17:51:02Z"
    message: 'containers with unready status: [postgres-postgresql]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2019-03-28T17:51:02Z"
    message: 'containers with unready status: [postgres-postgresql]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2019-03-28T17:51:02Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - image: docker.io/bitnami/postgresql:10.7.0
    imageID: ""
    lastState: {}
    name: postgres-postgresql
    ready: false
    restartCount: 0
    state:
      waiting:
    reason: PodInitializing
  hostIP: 192.168.1.217
  initContainerStatuses:
  - image: docker.io/bitnami/minideb:latest
    imageID: ""
    lastState: {}
    name: init-chmod-data
    ready: false
    restartCount: 0
    state:
      waiting:
    reason: PodInitializing
  phase: Pending
  qosClass: Burstable
  startTime: "2019-03-28T17:51:02Z"

Я не вижу в них ничего очевидного, чтобы иметь возможность точно определить, что может происходить. И я уже перезагрузил сервер, просто чтобы посмотреть, может ли это помочь. Есть мысли? Почему мои контейнеры не запускаются?

Ответ №1:

Похоже, что ваш initContainer застрял в состоянии подинициализации. Наиболее вероятный сценарий заключается в том, что ваши PVCS не готовы. Я рекомендую вам использовать describe ваш data-postgres-postgresql-0 PVC, чтобы убедиться, что том действительно подготовлен и находится в READY состоянии. Возможно, ваш NFS provisioner работает, но этот конкретный PV / PVC не был создан из-за ошибки. Я сталкивался с подобными явлениями с EFS provisioner в AWS.

1. Выполнение этой команды describe показывает, что PVC находится в Bound состоянии. Можете ли вы пролить свет на то, что это может означать?

2. Какие-либо другие события в PVC? Если она привязана, то она должна работать правильно. Мне понадобится дополнительная информация, чтобы помочь в отладке.

3. Я в полном замешательстве. Кажется, мой кластер находится в состоянии, когда я не могу запустить какие -либо новые модули, полная остановка. Все они застревают в подинициализации. Даже попытка запустить эту невероятно простую команду застревает: kubectl run --restart=Never alpine --image=alpine --command -- tail -f /dev/null . У нее вообще нет PVCS! Запуск kubectl get events --all-namespaces=true не показывает ничего необычного, запуск a kubectl describe pod/alpine не показывает никаких проблем, и даже просмотр всех сообщений журнала с помощью kail также ничего не показывает.

4. Я думаю, мне просто придется перерисовывать компьютер, на котором работает этот кластер, и начинать с нуля. Я просто надеюсь, что в конечном итоге она не вернется в это же состояние!

5. Вы проверили причину PodInitializing состояния? Вы можете найти некоторые журналы с kubectl get events --sort-by=.metadata.creationTimestamp и выяснить, почему именно ваши модули не запускаются по расписанию. Если вы используете cluster-autoscaler , вы также можете следить за журналами pod, чтобы увидеть, есть ли что-нибудь, блокирующее переход состояния pod!

Ответ №2:

Вы можете использовать команду event в kubectl. Это выдаст вам событие для вашего модуля.

Для фильтрации по определенному модулю вы можете использовать селектор полей:

kubectl получает событие —пространство имен abc-namespace —field-selector involvedObject.name=my-pod-zl6m6