Кубернетес - стручки, не выселяемые из мертвых узлов - PullRequest
0 голосов
/ 23 марта 2020

У меня есть настройка кластера kube с помощью kubeadm init (в основном по умолчанию). Все работает, как задумано, за исключением того факта, что если один из моих узлов переходит в автономный режим, когда на нем работают модули, они остаются в состоянии Running неопределенно долго. Из того, что я прочитал, они должны иметь статус go до Unknown или Failure, а после --pod-eviction-timeout (по умолчанию 5m) они должны быть перенесены на другой здоровый узел.

Вот мои стручки после 20 + минут, когда Узел 7 находился в автономном режиме (я также оставлял его более двух дней один раз без переназначения):

kubectl get pods -o wide
NAME                                   READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
workshop-30000-77b95f456c-sxkp5        1/1     Running   0          20m   REDACTED       node7   <none>           <none>
workshop-operator-657b45b6b8-hrcxr     2/2     Running   0          23m   REDACTED       node7   <none>           <none>

kubectl get deployments -o wide
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS         IMAGES                                                                                          SELECTOR
deployment.apps/workshop-30000      0/1     1            0           21m   workshop-ubuntu    REDACTED                                                            client=30000
deployment.apps/workshop-operator   0/1     1            0           17h   ansible,operator   REDACTED   name=workshop-operator

Вы можете видеть, что стручки все еще помечены как Running, тогда как их развертывания имеют Ready: 0/1.

Вот мои узлы:

kubectl get nodes -o wide
NAME                STATUS     ROLES    AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE       KERNEL-VERSION     CONTAINER-RUNTIME
kubernetes-master   Ready      master   34d    v1.17.3   REDACTED      <none>        Ubuntu 19.10   5.3.0-42-generic   docker://19.3.2
kubernetes-worker   NotReady   <none>   34d    v1.17.3   REDACTED      <none>        Ubuntu 19.10   5.3.0-29-generic   docker://19.3.2
node3               NotReady   worker   21d    v1.17.3   REdACTED      <none>        Ubuntu 19.10   5.3.0-40-generic   docker://19.3.2
node4               Ready      <none>   19d    v1.17.3   REDACTED      <none>        Ubuntu 19.10   5.3.0-40-generic   docker://19.3.2
node6               NotReady   <none>   5d7h   v1.17.4   REDACTED      <none>        Ubuntu 19.10   5.3.0-42-generic   docker://19.3.6
node7               NotReady   <none>   5d6h   v1.17.4   REDACTED      <none>        Ubuntu 19.10   5.3.0-42-generic   docker://19.3.6

В чем может быть проблема? Все мои контейнеры имеют датчики готовности и живучести. Я пробовал искать в документах и ​​в других местах, но не смог найти ничего, что решило бы это.

В настоящее время, если узел выходит из строя, я могу получить только те модули, которые были на нем. быть перенесенным на живой узел, если я вручную удаляю их с --force и --graceperiod = 0, что противоречит некоторым основным целям Kubernetes: автоматизации и самовосстановлению.

Согласно документам : https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod - время жизни If a node dies or is disconnected from the rest of the cluster, Kubernetes applies a policy for setting the phase of all Pods on the lost node to Failed.

---------- Дополнительная информация ---------------

kubectl describe pods workshop-30000-77b95f456c-sxkp5
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  <unknown>          default-scheduler  Successfully assigned workshop-operator/workshop-30000-77b95f456c-sxkp5 to node7
  Normal   Pulling    37m                kubelet, node7     Pulling image "REDACTED"
  Normal   Pulled     37m                kubelet, node7     Successfully pulled image "REDACTED"
  Normal   Created    37m                kubelet, node7     Created container workshop-ubuntu
  Normal   Started    37m                kubelet, node7     Started container workshop-ubuntu
  Warning  Unhealthy  36m (x2 over 36m)  kubelet, node7     Liveness probe failed: Get http://REDACTED:8080/healthz: dial tcp REDACTED:8000: connect: connection refused
  Warning  Unhealthy  36m (x3 over 36m)  kubelet, node7     Readiness probe failed: Get http://REDACTED:8000/readyz: dial tcp REDACTED:8000: connect: connection refused

Я полагаю, что эти сбои в тесте живучести и готовности были вызваны медленным стартом Кажется, что он не проверяет живучесть / готовность после того, как узел выходит из строя (последняя проверка была 37 минут go).

Это кластер с собственным размещением со следующей версией:

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

Спасибо всем, кто помог.

РЕДАКТИРОВАТЬ: Это была либо ошибка, либо потенциальная неправильная конфигурация при начальной загрузке с kubeadm. Полная переустановка кластера kubernetes и обновление с 1.17.4 до 1.18 решили проблему, и теперь модули переносятся из мертвых узлов.

1 Ответ

1 голос
/ 23 марта 2020

С установленным флагом TaintBasedEvictions true (по умолчанию) после Kubernetes версии 1.13 вы можете установить время выселения ваших стручков в пределах допустимых значений c.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

Если после 300 se c (по умолчанию) или 2 se c (задано в допусках). Стручки не перепланированы, вам нужно kubectl delete node, что приведет к перепланированию стручков на узле.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...