Kubernetes Cluster с нестабильно выполненными заданиями; Журналы kubelet заполнены "http2: не было доступно кэшированное соединение"

Question

Резюме

У меня есть различные одноузловые кластеры Kubernetes, которые становятся нестабильными после накопления ~300 выполненных заданий.

Например, в одном кластере 303 выполненных задания:

root@xxxx:/home/xxxx# kubectl get jobs | wc -l
303

наблюдения

Я наблюдаю, что

• kubelet журналы заполнены сообщениями об ошибках вроде этого: kubelet[877]: E0219 09:06:14.637045 877 reflector.go:134] object-"default"/"job-162273560": Failed to list *v1.ConfigMap: Get https://172.13.13.13:6443/api/v1/namespaces/default/configmaps?fieldSelector=metadata.name%3Djob-162273560&limit=500&resourceVersion=0: http2: no cached connection was available
• Состояние узла не обновляется, с похожим сообщением об ошибке:kubelet[877]: E0219 09:32:57.379751 877 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:451: Failed to list *v1.Node: Get https://172.13.13.13:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxxxx&limit=500&resourceVersion=0: http2: no cached connection was available
• В конце концов, узел помечается как NotReady и никаких новых стручков не запланировано NAME STATUS ROLES AGE VERSION xxxxx NotReady master 6d4h v1.12.1
• Кластер входит и выходит из режима основного прерывания (из kube-controller-manager журналы): I0219 09:29:46.875397 1 node_lifecycle_controller.go:1015] Controller detected that all Nodes are not-Ready. Entering master disruption mode. I0219 09:30:16.877715 1 node_lifecycle_controller.go:1042] Controller detected that some Nodes are Ready. Exiting master disruption mode.

Настоящим виновником является http2: no cached connection was available сообщение об ошибке. Единственные реальные ссылки, которые я нашел, - это несколько проблем в репозитории Go (например, # 16582), которые, похоже, были исправлены давно.

В большинстве случаев удаление завершенных заданий восстанавливает стабильность системы.

Минимальный репро (тсб)

Кажется, я могу воспроизвести эту проблему, создав множество заданий, которые используют контейнеры, которые монтируют ConfigMaps:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: job-%JOB_ID%
data:
# Just some sample data
  game.properties: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-%JOB_ID%
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(20)"]
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: job-%JOB_ID%
      restartPolicy: Never
  backoffLimit: 4

Запланируйте много этих работ:

#!/bin/bash
for i in `seq 100 399`;
do
    cat job.yaml | sed "s/%JOB_ID%/$i/g" | kubectl create -f -
    sleep 0.1
done

Вопросы

Мне очень любопытно, что вызывает эту проблему, так как 300 выполненных заданий, кажется, довольно мало.

Это проблема конфигурации в моем кластере? Возможная ошибка в Kubernetes/Go? Что-нибудь еще, что я могу попробовать?

Answer 1

Просто, чтобы подвести итог этой проблемы и почему это происходит. На самом деле это была проблема, связанная с 1.12 и 1.13. Как объяснено в проблеме GitHub (возможно, созданной автором), это, похоже, проблема реализации пула соединений http2, или, как объяснено в одном из комментариев, это проблема управления соединением в kubelet. Описанные способы смягчения могут быть найдены здесь. и если вам потребуется дополнительная информация, все ссылки доступны в связанном выпуске GitHub.