쿠버네티스 운영의 재미있는 시스템 버그 6가지 [및 해당 솔루션]

수년간 프로덕션에서 Kubernetes를 사용하면서 우리는 다양한 시스템 구성 요소의 버그가 어떻게 컨테이너와 포드의 작동에 영향을 미치는 불쾌하고 이해할 수 없는 결과를 초래했는지에 대한 많은 흥미로운 이야기를 축적했습니다. 이 기사에서 우리는 가장 일반적이거나 흥미로운 것들 중 일부를 선택했습니다. 그런 상황에 직면할 만큼 운이 좋지 않더라도, 그러한 짧은 탐정 이야기, 특히 "직접"에 대해 읽는 것은 항상 흥미롭지 않습니까?..

이야기 1. Supercronic과 Docker hanging

클러스터 중 하나에서 정기적으로 고정된 Docker를 수신하여 클러스터의 정상적인 기능을 방해했습니다. 동시에 Docker 로그에서 다음이 관찰되었습니다.

level=error msg="containerd: start init process" error="exit status 2: "runtime/cgo: pthread_create failed: No space left on device
SIGABRT: abort
PC=0x7f31b811a428 m=0

goroutine 0 [idle]:

goroutine 1 [running]:
runtime.systemstack_switch() /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420026768 sp=0xc420026760
runtime.main() /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200267c0 sp=0xc420026768
runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200267c8 sp=0xc4200267c0

goroutine 17 [syscall, locked to thread]:
runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1

…

이 오류에 대해 가장 흥미로운 점은 다음 메시지입니다. pthread_create failed: No space left on device. 빠른 학습 선적 서류 비치 Docker는 프로세스를 포크할 수 없기 때문에 프로세스가 주기적으로 정지된다고 설명했습니다.

모니터링에서 다음 그림은 무슨 일이 일어나고 있는지에 해당합니다.

다른 노드에서도 비슷한 상황이 관찰됩니다.

동일한 노드에서 다음을 볼 수 있습니다.

root@kube-node-1 ~ # ps auxfww | grep curl -c
19782
root@kube-node-1 ~ # ps auxfww | grep curl | head
root     16688  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root     17398  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root     16852  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root      9473  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root      4664  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root     30571  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root     24113  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root     16475  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root      7176  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>
root      1090  0.0  0.0      0     0 ?        Z    Feb06   0:00      |       _ [curl] <defunct>

이 동작은 포드가 다음 작업을 수행한 결과인 것으로 밝혀졌습니다. 초음속의 (Pod에서 cron 작업을 실행하는 데 사용하는 Go 유틸리티):

 _ docker-containerd-shim 833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 /var/run/docker/libcontainerd/833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 docker-runc
|   _ /usr/local/bin/supercronic -json /crontabs/cron
|       _ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true
|       |   _ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true -no-pidfile
|       _ [newrelic-daemon] <defunct>
|       _ [curl] <defunct>
|       _ [curl] <defunct>
|       _ [curl] <defunct>
…

문제는 다음과 같습니다. 작업이 슈퍼크로닉으로 실행될 때 해당 작업에 의해 프로세스가 생성됩니다. 올바르게 종료할 수 없습니다.,로 변하는 좀비.

주의: 더 정확하게 말하면 프로세스는 cron 작업에 의해 생성되지만 supercronic은 초기화 시스템이 아니므로 해당 하위 항목이 생성된 프로세스를 "채택"할 수 없습니다. SIGHUP 또는 SIGTERM 신호가 발생하면 하위 프로세스로 전달되지 않으므로 하위 프로세스가 종료되지 않고 좀비 상태로 유지됩니다. 예를 들어, 이 모든 것에 대한 자세한 내용을 읽을 수 있습니다. 그런 기사.

문제를 해결하는 방법에는 몇 가지가 있습니다.

1. 임시 해결 방법 - 단일 시점에서 시스템의 PID 수를 늘리십시오.

          /proc/sys/kernel/pid_max (since Linux 2.5.34)
                 This file specifies the value at which PIDs wrap around (i.e., the value in this file is one greater than the maximum PID).  PIDs greater than this  value  are  not  allo‐
                 cated;  thus, the value in this file also acts as a system-wide limit on the total number of processes and threads.  The default value for this file, 32768, results in the
                 same range of PIDs as on earlier kernels

2. 또는 직접적으로가 아닌 동일한 방법을 사용하여 supercronic에서 작업을 시작합니다. TINI, 프로세스를 올바르게 종료하고 좀비를 생성하지 않을 수 있습니다.

이야기 2. cgroup을 삭제할 때 "좀비" 발생

Kubelet은 많은 CPU를 소비하기 시작했습니다.

이건 누구도 좋아하지 않을 테니 우린 무장했어 반환 한 그리고 문제를 다루기 시작했습니다. 조사 결과는 다음과 같았다.

• Kubelet은 모든 cgroup에서 메모리 데이터를 가져오는 데 CPU 시간의 XNUMX/XNUMX 이상을 소비합니다.

  

• 커널 개발자 메일링 리스트에서 다음을 찾을 수 있습니다. 문제에 대한 토론. 요컨대 요점은 다음과 같습니다. 다양한 tmpfs 파일 및 기타 유사한 파일이 시스템에서 완전히 제거되지 않습니다. cgroup을 삭제할 때 소위 memcg 좀비. 조만간 페이지 캐시에서 삭제되지만 서버에 많은 메모리가 있고 커널은 삭제에 시간을 낭비할 이유가 없다고 생각합니다. 그렇기 때문에 계속해서 쌓이게 됩니다. 왜 이런 일이 일어나는 걸까요? 이는 지속적으로 새로운 작업을 생성하는 크론 작업과 새로운 포드를 포함하는 서버입니다. 따라서 컨테이너에 대해 새로운 cgroup이 생성되며 곧 삭제됩니다.
• kubelet의 cAdvisor가 왜 그렇게 많은 시간을 낭비하나요? 이는 가장 간단한 실행으로 쉽게 확인할 수 있습니다. time cat /sys/fs/cgroup/memory/memory.stat. 정상적인 머신에서 작업이 0,01초 걸리면 문제가 있는 cron02에서는 1,2초가 걸립니다. 문제는 sysfs에서 데이터를 매우 느리게 읽는 cAdvisor가 좀비 cgroup에서 사용되는 메모리를 고려하려고 한다는 것입니다.
• 좀비를 강제로 제거하기 위해 LKML에서 권장하는 대로 캐시를 지워 보았습니다. sync; echo 3 > /proc/sys/vm/drop_caches, -하지만 커널이 더 복잡해져서 자동차가 충돌했습니다.

무엇을 해야 할까요? 문제를 해결하는 중입니다(저지르다, 설명은 다음을 참조하세요. 릴리스 메시지) Linux 커널을 버전 4.16으로 업데이트합니다.

역사 3. Systemd와 그 마운트

다시 말하지만, kubelet은 일부 노드에서 너무 많은 리소스를 소비하고 있지만 이번에는 너무 많은 메모리를 소비하고 있습니다.

Ubuntu 16.04에서 사용하는 systemd에 문제가 있는 것으로 확인되었으며, 연결을 위해 생성된 마운트를 관리할 때 발생합니다. subPath ConfigMap 또는 비밀에서. Pod가 작업을 완료한 후 systemd 서비스와 해당 서비스 마운트는 그대로 유지됩니다. 시스템에서. 시간이 지남에 따라 엄청난 수의 것들이 축적됩니다. 이 주제에는 다음과 같은 문제도 있습니다.

1. #5916;
2. 쿠버네티스 #57345.

...마지막은 systemd의 PR을 나타냅니다. #7811 (systemd의 문제 - #7798).

Ubuntu 18.04에서는 더 이상 문제가 존재하지 않지만 Ubuntu 16.04를 계속 사용하려는 경우 이 주제에 대한 해결 방법이 유용할 수 있습니다.

그래서 우리는 다음과 같은 DaemonSet을 만들었습니다.

---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  labels:
    app: systemd-slices-cleaner
  name: systemd-slices-cleaner
  namespace: kube-system
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: systemd-slices-cleaner
  template:
    metadata:
      labels:
        app: systemd-slices-cleaner
    spec:
      containers:
      - command:
        - /usr/local/bin/supercronic
        - -json
        - /app/crontab
        Image: private-registry.org/systemd-slices-cleaner/systemd-slices-cleaner:v0.1.0
        imagePullPolicy: Always
        name: systemd-slices-cleaner
        resources: {}
        securityContext:
          privileged: true
        volumeMounts:
        - name: systemd
          mountPath: /run/systemd/private
        - name: docker
          mountPath: /run/docker.sock
        - name: systemd-etc
          mountPath: /etc/systemd
        - name: systemd-run
          mountPath: /run/systemd/system/
        - name: lsb-release
          mountPath: /etc/lsb-release-host
      imagePullSecrets:
      - name: antiopa-registry
      priorityClassName: cluster-low
      tolerations:
      - operator: Exists
      volumes:
      - name: systemd
        hostPath:
          path: /run/systemd/private
      - name: docker
        hostPath:
          path: /run/docker.sock
      - name: systemd-etc
        hostPath:
          path: /etc/systemd
      - name: systemd-run
        hostPath:
          path: /run/systemd/system/
      - name: lsb-release
        hostPath:
          path: /etc/lsb-release

... 그리고 다음 스크립트를 사용합니다.

#!/bin/bash

# we will work only on xenial
hostrelease="/etc/lsb-release-host"
test -f ${hostrelease} && grep xenial ${hostrelease} > /dev/null || exit 0

# sleeping max 30 minutes to dispense load on kube-nodes
sleep $((RANDOM % 1800))

stoppedCount=0
# counting actual subpath units in systemd
countBefore=$(systemctl list-units | grep subpath | grep "run-" | wc -l)
# let's go check each unit
for unit in $(systemctl list-units | grep subpath | grep "run-" | awk '{print $1}'); do
  # finding description file for unit (to find out docker container, who born this unit)
  DropFile=$(systemctl status ${unit} | grep Drop | awk -F': ' '{print $2}')
  # reading uuid for docker container from description file
  DockerContainerId=$(cat ${DropFile}/50-Description.conf | awk '{print $5}' | cut -d/ -f6)
  # checking container status (running or not)
  checkFlag=$(docker ps | grep -c ${DockerContainerId})
  # if container not running, we will stop unit
  if [[ ${checkFlag} -eq 0 ]]; then
    echo "Stopping unit ${unit}"
    # stoping unit in action
    systemctl stop $unit
    # just counter for logs
    ((stoppedCount++))
    # logging current progress
    echo "Stopped ${stoppedCount} systemd units out of ${countBefore}"
  fi
done

... 그리고 앞서 언급한 supercronic을 사용하여 5분마다 실행됩니다. Dockerfile은 다음과 같습니다.

FROM ubuntu:16.04
COPY rootfs /
WORKDIR /app
RUN apt-get update && 
    apt-get upgrade -y && 
    apt-get install -y gnupg curl apt-transport-https software-properties-common wget
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable" && 
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - && 
    apt-get update && 
    apt-get install -y docker-ce=17.03.0*
RUN wget https://github.com/aptible/supercronic/releases/download/v0.1.6/supercronic-linux-amd64 -O 
    /usr/local/bin/supercronic && chmod +x /usr/local/bin/supercronic
ENTRYPOINT ["/bin/bash", "-c", "/usr/local/bin/supercronic -json /app/crontab"]

Story 4. 포드 예약 시 경쟁력

다음과 같은 사실이 발견되었습니다. 노드에 포드가 배치되어 있고 해당 이미지가 매우 오랫동안 펌핑되면 동일한 노드에 "적중"하는 다른 포드가 단순히 새 포드의 이미지를 가져오기 시작하지 않습니다.. 대신 이전 Pod의 이미지를 가져올 때까지 기다립니다. 결과적으로 이미 예약되어 있고 단 XNUMX분 만에 이미지를 다운로드할 수 있었던 포드는 다음 상태가 됩니다. containerCreating.

이벤트는 다음과 같습니다.

Normal  Pulling    8m    kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal  pulling image "registry.example.com/infra/openvpn/openvpn:master"

그것은 밝혀 그 느린 레지스트리의 단일 이미지로 인해 배포가 차단될 수 있음 노드당.

불행히도 상황에서 벗어날 수 있는 방법은 많지 않습니다.

1. Docker 레지스트리를 클러스터에서 직접 사용하거나 클러스터(예: GitLab Registry, Nexus 등)에서 직접 사용해 보십시오.
2. 다음과 같은 유틸리티를 사용하십시오. 크라켄.

이야기 5. 메모리 부족으로 인해 노드가 중단됩니다.

다양한 애플리케이션이 작동하는 동안 노드에 대한 액세스가 완전히 중단되는 상황도 발생했습니다. SSH가 응답하지 않고 모든 모니터링 데몬이 작동하지 않으며 로그에 이상이 없는 경우(또는 거의 없는 경우)입니다.

MongoDB가 작동했던 한 노드의 예를 사용하여 그림으로 말씀드리겠습니다.

꼭대기는 이렇게 생겼어요 에 사고:

그리고 이렇게 - 후 사고:

모니터링 중에 노드 사용이 중단되는 급격한 점프도 있습니다.

따라서 스크린샷을 보면 다음과 같은 사실이 분명합니다.

1. 머신의 RAM이 거의 다 찼습니다.
2. RAM 소비가 급격히 증가한 후 전체 시스템에 대한 액세스가 갑자기 비활성화됩니다.
3. DBMS 프로세스가 더 많은 메모리를 사용하고 디스크에서 적극적으로 읽도록 하는 대규모 작업이 Mongo에 도착합니다.

Linux에 사용 가능한 메모리가 부족하고(메모리 압력이 설정됨) 스왑이 없는 경우 에 OOM 킬러가 도착하면 페이지 캐시에 페이지를 넣는 것과 디스크에 다시 쓰는 것 사이에 균형 조정 작업이 발생할 수 있습니다. 이는 후속 배포를 위해 가능한 한 많은 메모리 페이지를 용감하게 확보하는 kswapd에 의해 수행됩니다.

불행하게도, 적은 양의 사용 가능한 메모리와 결합된 대규모 I/O 로드로 인해 kswapd는 전체 시스템의 병목 현상이 됩니다, 그것에 묶여 있기 때문에 모든 시스템의 메모리 페이지 할당(페이지 폴트) 프로세스가 더 이상 메모리를 사용하지 않으려고 하지만 OOM-killer 심연의 가장자리에 고정되어 있는 경우 이는 매우 오랜 시간 동안 계속될 수 있습니다.

자연스러운 질문은 OOM 킬러가 왜 그렇게 늦게 나타나는가입니다. 현재 반복에서 OOM 킬러는 매우 멍청합니다. 메모리 페이지 할당 시도가 실패할 때만 프로세스를 종료합니다. 페이지 폴트가 실패하는 경우. kswapd가 용감하게 메모리 페이지를 해제하고 페이지 캐시(사실 시스템의 전체 디스크 I/O)를 디스크로 덤프하기 때문에 이런 일은 꽤 오랜 시간 동안 발생하지 않습니다. 커널에서 이러한 문제를 제거하는 데 필요한 단계에 대한 자세한 설명을 읽을 수 있습니다. 여기에.

이 행동 개선되어야 한다 Linux 커널 4.6+ 사용.

이야기 6. Pod가 Pending 상태에서 멈춤

실제로 많은 Pod가 작동하는 일부 클러스터에서는 대부분이 상태에서 매우 오랫동안 "중지"되는 것을 발견하기 시작했습니다. Pending단, Docker 컨테이너 자체는 이미 노드에서 실행 중이며 수동으로 작업할 수 있습니다.

이것으로 describe 아무 문제가 없다:

  Type    Reason                  Age                From                     Message
  ----    ------                  ----               ----                     -------
  Normal  Scheduled               1m                 default-scheduler        Successfully assigned sphinx-0 to ss-dev-kub07
  Normal  SuccessfulAttachVolume  1m                 attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  SuccessfulMountVolume   1m                 kubelet, ss-dev-kub07    MountVolume.SetUp succeeded for volume "sphinx-config"
  Normal  SuccessfulMountVolume   1m                 kubelet, ss-dev-kub07    MountVolume.SetUp succeeded for volume "default-token-fzcsf"
  Normal  SuccessfulMountVolume   49s (x2 over 51s)  kubelet, ss-dev-kub07    MountVolume.SetUp succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
  Normal  Pulled                  43s                kubelet, ss-dev-kub07    Container image "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" already present on machine
  Normal  Created                 43s                kubelet, ss-dev-kub07    Created container
  Normal  Started                 43s                kubelet, ss-dev-kub07    Started container
  Normal  Pulled                  43s                kubelet, ss-dev-kub07    Container image "registry.example.com/infra/sphinx/sphinx:v1" already present on machine
  Normal  Created                 42s                kubelet, ss-dev-kub07    Created container
  Normal  Started                 42s                kubelet, ss-dev-kub07    Started container

약간의 조사 끝에 우리는 kubelet이 포드 상태 및 활성/준비 테스트에 대한 모든 정보를 API 서버로 보낼 시간이 없다고 가정했습니다.

도움말을 연구한 후 다음 매개변수를 발견했습니다.

--kube-api-qps - QPS to use while talking with kubernetes apiserver (default 5)
--kube-api-burst  - Burst to use while talking with kubernetes apiserver (default 10) 
--event-qps - If > 0, limit event creations per second to this value. If 0, unlimited. (default 5)
--event-burst - Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10) 
--registry-qps - If > 0, limit registry pull QPS to this value.
--registry-burst - Maximum size of bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10)

보시다시피 기본값은 매우 작습니다, 그리고 90%에서는 모든 요구 사항을 충족합니다... 그러나 우리의 경우에는 이것이 충분하지 않았습니다. 따라서 다음 값을 설정했습니다.

--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40

... 그리고 kubelet을 다시 시작한 후 API 서버 호출 그래프에서 다음 그림을 확인했습니다.

... 그리고 네, 모든 것이 날기 시작했습니다!

PS

버그를 수집하고 이 기사를 준비하는 데 도움을 준 우리 회사의 수많은 엔지니어, 특히 R&D 팀의 동료인 Andrey Klimentyev(주주).

PPS

블로그에서도 읽어보세요.

• «Kubernetes 포드에서 디버깅을 위한 kubectl-debug 플러그인".
• Kubernetes 팁 및 요령 루프:
  • «클러스터에서 실행 중인 리소스를 Helm 2 관리로 전송";
  • «웹 애플리케이션의 노드 할당 및 로드 정보";
  • «개발 사이트에 대한 액세스";
  • «대규모 데이터베이스의 부트스트랩 속도 향상".

출처 : habr.com