Почему Kubernetes не завершает POD после узла cra sh?

Question

Я использую управляемый кластер Kubernetes 1.18.1. Я развернул несколько модулей с постоянными томами (на основе проекта Longhorn). Теперь, после некоторого тестирования, я наблюдаю следующее поведение:

Если я имитирую жесткое отключение одного узла, через некоторое время (5 минут) Kubernetes распознает потерю и начинает перепланировать POD из мертвого узла в другой.

Из-за того, что мои узлы имели постоянные тома, новый POD никогда не запустится. Причина в том, что старый модуль (на мертвом узле) теперь долговечен в состоянии завершения.

Тот факт, что модули, находящиеся в аварийном узле, не прекращали работу, кажется хорошо известным ограничением Kubernetes. Смотрите также описание проблемы здесь .

Мой вопрос: почему Kubernetes не предоставляет функцию для автоматического завершения старых POD и ресурсов, таких как постоянные тома. Почему я должен вмешиваться вручную как администратор? Мне это поведение кажется нелогичным в отношении обещаний, которые дает Кубернетес.

Вот, например, как выглядит мой файл yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db
  labels: 
    app: db
spec:
  replicas: 1
  selector: 
    matchLabels:
      app: db
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
      - env:
        - name: POSTGRES_DB
          value: office
        image: postgres:9.6.1
        name: db

        livenessProbe:
          tcpSocket:
            port: 5432
          initialDelaySeconds: 30
          periodSeconds: 10

        ports:
          - containerPort: 5432        
        resources: {}
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: dbdata
          subPath: postgres
      restartPolicy: Always
      volumes:
      - name: dbdata
        persistentVolumeClaim:
          claimName: office-demo-dbdata-pvc


# Storrage
---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: office-demo-dbdata-pv
spec:
  capacity:
    storage: 2Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  claimRef:
    namespace: default
    name: office-demo-dbdata-pvc
  csi:
    driver: io.rancher.longhorn 
    fsType: ext4
    volumeHandle: office-demo-dbdata
  storageClassName: longhorn-durable
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: office-demo-dbdata-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-durable
  resources:
    requests:
      storage: 2Gi
  volumeName: "office-demo-dbdata-pv"

Как объяснено, том создан на Longhorn. Но вложение не освобождается даже после того, как kubernetes начинает перепланировать модуль на другой узел.

Подвеска, находящаяся в состоянии завершения, может быть освобождена, если я вручную удаляю «volumeattachment»

$ kubectl delete volumeattachment csi-08d9842e.......

Но в любом случае это ручное действие.

Answer 1

5 минут - время выселения по умолчанию, установленное в компонентах плоскости управления Kubernetes. Если вы хотите настроить, что вы можете использовать выселение на основе заражения и добавить ниже в развертывании yaml

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 60

Обратите внимание, что Kubernetes автоматически добавляет допуск для node.kubernetes.io/not-ready с tolerationSeconds=300, если в конфигурации модуля, предоставленной пользователем, уже есть допуск для node.kubernetes.io/not-ready. Аналогичным образом добавляется допуск для node.kubernetes.io/unreachable с tolerationSeconds=300, если в конфигурации модуля, предоставленной пользователем, уже есть допуск для node.kubernetes.io/unreachable

Answer 2

Согласно документации Longhorn об отказе узла :

Когда происходит сбой узла Kubernetes с установленным драйвером CSI (все перечисленное основано на Kubernetes v1.12 с настройкой по умолчанию) :

1. Через одну минуту , kubectl get nodes сообщит NotReady для узла отказа.
2. Примерно через пять минут , Состояния всех модулей в узле NotReady изменятся на Unknown или NodeLost.
3. Если вы развертываете с помощью StatefulSet или Deployment, вам нужно решить, безопасно ли форсировать удаление модуля рабочей нагрузки, выполняемой на потерянном узле. Смотрите здесь .
   1. StatefulSet имеет стабильную идентификацию, поэтому Kubernetes не будет принудительно удалять Pod для пользователя.
   2. У развертывания нет стабильной идентификации, но Longhorn является типом хранилища с возможностью чтения и записи. Это означает, что он может быть подключен только к одному Pod. Таким образом, новый Pod, созданный Kubernetes, не сможет запуститься из-за тома Longhorn, все еще прикрепленного к старому Pod, на потерянном узле.
   3. В обоих случаях Kubernetes автоматически вытеснит модуль (установите удаление отметка времени для модуля) на потерянном узле, затем попытайтесь воссоздать новый со старыми томами . Поскольку высохший модуль застревает в состоянии Terminating, а подключенные тома Longhorn не могут быть освобождены / использованы повторно, новый модуль застревает в состоянии ContainerCreating. Вот почему пользователям нужно решить, безопасно ли принудительно удалять модуль.

Это текущее состояние LongHorn (которое все еще находится в бета-версии).

Существует открытая проблема на Github: Улучшение обработки сбоя узла # 1105 для точного решения этой проблемы, но пока, как указано в документации, администратор должен вмешаться вручную.

В Kubernetes Github есть больше проблем, таких как этот , который, как я считаю, лежит на грани между kubernetes и CSI, это взаимная проверка: CSI является читаемым и записываемым один раз и устанавливает хранение как стабильное и запирает хранение. В части kubernetes он видит, что в модулях есть финализаторы (как в проблеме выше), и не удалит их, пока задача не будет завершена.

К сожалению, в любом случае на сегодняшний день требуется ручное вмешательство.

• С точки зрения Longhorn вы должны запустить delete volumeattachment.
• Со стороны kubernetes вы можете удалить финализаторы pod , позволяющие удалить стручки, здесь является примером того, как изменить финализаторы.

Редактировать:

Github Kubernetes Issue # 69697 Пример удаления финализаторов :

kubectl patch pvc <PVC_NAME> -p '{"metadata":{"finalizers":null}}'
kubectl patch pod <POD_NAME> -p '{"metadata":{"finalizers":null}}'

Вы можете создать скрипт для удаления финализаторов, чтобы вам не приходилось делать это вручную, как предложено в другом открытом выпуске Kubernetes # 77258 :

Вот одна строка для удаления финализаторов из всех PV в системе:

kubectl get pv | tail -n+2 | awk '{print $1}' | xargs -I{} kubectl patch pv {} -p '{"metadata":{"finalizers": null}}'

Великая проблема в том, что финализаторы добавляются LongHorn, поэтому в моем понимая, что вы не можете создавать стручки без него б потому что впоследствии он был добавлен LongHorn.

Я добавил документацию и Открытые выпуски от Github, чтобы показать вам, что это актуальная проблема, и которую еще предстоит решить разработчикам как из Longhorn, так и из Kubernetes.