Кластер Kubernetes с нестабильным завершением работЖурналы Kubelet заполнены "http2: не было доступно кэшированное соединение" - PullRequest
Новая
       12

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

0 голосов
/ 19 февраля 2019

Сводка

У меня есть несколько одноузловых кластеров 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 ), которые, похоже, были исправлены очень давно.

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

Минимальное воспроизведение (tbc)

Кажется, я могу воспроизвести эту проблему, создав множество заданий, использующих контейнеры, которые монтируют 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?Что-нибудь еще, что я могу попробовать?

1 Ответ

0 голосов
/ 15 апреля 2019

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

...