Kubernetes의 CPU 제한 및 공격적인 조절

메모. 번역: 유럽의 여행 정보 제공업체인 Omio의 놀라운 역사를 통해 독자는 기본 이론부터 Kubernetes 구성의 흥미롭고 실용적인 복잡성까지 안내합니다. 이러한 사례에 익숙해지면 시야가 넓어질 뿐만 아니라 사소한 문제도 예방할 수 있습니다.

애플리케이션이 제자리에 멈춰 있고, 상태 확인에 응답하지 않고, 이유를 알 수 없는 적이 있습니까? 한 가지 가능한 설명은 CPU 리소스 할당량 제한과 관련이 있습니다. 이것이 이 글에서 우리가 이야기할 내용입니다.

TL; DR :
CFS 할당량 버그가 있는 Linux 커널 버전을 사용하는 경우 Kubernetes에서 CPU 제한을 비활성화하거나 Kubelet에서 CFS 할당량을 비활성화하는 것이 좋습니다. 핵심에는 있다 심각하고 잘 알려진 과도한 제한 및 지연을 초래하는 버그.

오미오에서 전체 인프라는 Kubernetes에서 관리됩니다.. 모든 상태 저장 및 상태 비저장 워크로드는 Kubernetes에서만 독점적으로 실행됩니다(Google Kubernetes Engine 사용). 지난 XNUMX개월 동안 우리는 무작위적인 속도 저하를 관찰하기 시작했습니다. 애플리케이션이 정지되거나 상태 확인에 대한 응답이 중지되고, 네트워크 연결이 끊어지는 등의 현상이 발생합니다. 이 행동은 오랫동안 우리를 혼란스럽게 만들었고 마침내 우리는 문제를 심각하게 받아들이기로 결정했습니다.

기사 요약 :

• 컨테이너와 Kubernetes에 대한 몇 마디
• CPU 요청 및 제한이 구현되는 방법
• 멀티 코어 환경에서 CPU 제한이 작동하는 방식
• CPU 조절을 추적하는 방법
• 문제 해결 및 뉘앙스.

컨테이너와 Kubernetes에 대한 몇 마디

Kubernetes는 본질적으로 인프라 세계의 현대 표준입니다. 주요 작업은 컨테이너 오케스트레이션입니다.

컨테이너

과거에는 서버에서 실행하기 위해 Java JAR/WAR, Python Egg 또는 실행 파일과 같은 아티팩트를 만들어야 했습니다. 하지만 이를 작동시키려면 런타임 환경(Java/Python) 설치, 필요한 파일을 올바른 위치에 배치, 특정 운영 체제 버전과의 호환성 보장 등 추가 작업을 수행해야 했습니다. 즉, 구성 관리에 세심한 주의를 기울여야 했습니다(종종 개발자와 시스템 관리자 사이의 논쟁의 원인이 되기도 했습니다).

컨테이너는 모든 것을 변화시켰습니다. 이제 아티팩트는 컨테이너 이미지입니다. 이는 프로그램뿐만 아니라 완전한 실행 환경(Java/Python/...)과 필요한 파일/패키지를 포함하는 일종의 확장 실행 파일로 표현될 수 있습니다. 달리다. 추가 단계 없이 컨테이너를 다른 서버에 배포하고 실행할 수 있습니다.

또한 컨테이너는 자체 샌드박스 환경에서 작동합니다. 자체 가상 네트워크 어댑터, 액세스가 제한된 자체 파일 시스템, 자체 프로세스 계층 구조, CPU 및 메모리에 대한 자체 제한 등이 있습니다. 이 모든 것은 Linux 커널의 특수 하위 시스템인 네임스페이스 덕분에 구현됩니다.

Kubernetes

앞서 언급했듯이 Kubernetes는 컨테이너 오케스트레이터입니다. 작동 방식은 다음과 같습니다. 머신 풀을 제공한 다음 "Kubernetes, 프로세서 2개와 각각 3GB 메모리를 갖춘 내 컨테이너 인스턴스 XNUMX개를 시작하고 계속 실행하자!"라고 말합니다. Kubernetes가 나머지 작업을 처리합니다. 여유 용량을 찾고, 컨테이너를 시작하고 필요한 경우 다시 시작하며, 버전 변경 시 업데이트를 출시합니다. 기본적으로 Kubernetes를 사용하면 하드웨어 구성 요소를 추상화하고 애플리케이션 배포 및 실행에 적합한 다양한 시스템을 만들 수 있습니다.

일반인의 관점에서 본 Kubernetes

Kubernetes의 요청 및 제한이란 무엇입니까?

좋아요, 지금까지 컨테이너와 Kubernetes를 다루었습니다. 또한 여러 컨테이너가 동일한 시스템에 있을 수 있다는 것도 알고 있습니다.

공동 아파트에 비유할 수 있습니다. 넓은 건물(기계/장치)을 가져와 여러 임차인(컨테이너)에게 임대합니다. Kubernetes는 부동산 중개인 역할을 합니다. 세입자가 서로 충돌하지 않도록 하는 방법에 대한 질문이 생깁니다. 예를 들어 그들 중 한 명이 화장실을 반나절 동안 빌리기로 결정했다면 어떻게 될까요?

여기에서 요청과 제한이 적용됩니다. CPU 의뢰 계획 목적으로만 필요합니다. 이는 컨테이너의 '위시리스트'와 같은 것으로, 가장 적합한 노드를 선택하는 데 사용됩니다. 동시에 CPU 한도 임대 계약과 비교할 수 있습니다. 컨테이너에 대한 단위를 선택하자마자 할 수 없을거야. 정해진 한계를 뛰어넘으세요. 그리고 여기서 문제가 발생하는데...

Kubernetes에서 요청 및 제한이 구현되는 방법

Kubernetes는 CPU 제한을 구현하기 위해 커널에 내장된 조절 메커니즘(클록 주기 건너뛰기)을 사용합니다. 애플리케이션이 한도를 초과하면 조절이 활성화됩니다(즉, 더 적은 CPU 주기를 수신함). 메모리에 대한 요청과 제한은 다르게 구성되므로 감지하기가 더 쉽습니다. 이렇게 하려면 포드의 마지막 다시 시작 상태, 즉 "OOMKilled"인지 확인하세요. K8s는 cgroup이 아닌 사용량에 따라 측정항목만 제공하므로 CPU 조절은 그리 간단하지 않습니다.

CPU 요청

CPU 요청이 구현되는 방법

단순화를 위해 4코어 CPU를 갖춘 머신을 예로 들어 프로세스를 살펴보겠습니다.

K8s는 제어 그룹 메커니즘(cgroups)을 사용하여 리소스(메모리 및 프로세서) 할당을 제어합니다. 계층적 모델을 사용할 수 있습니다. 하위 그룹은 상위 그룹의 한계를 상속받습니다. 배포 세부 정보는 가상 파일 시스템(/sys/fs/cgroup). 프로세서의 경우 이는 다음과 같습니다. /sys/fs/cgroup/cpu,cpuacct/*.

K8s는 파일을 사용합니다 cpu.share 프로세서 리소스를 할당합니다. 우리의 경우 루트 cgroup은 4096개의 CPU 리소스 공유를 얻습니다. 이는 사용 가능한 프로세서 성능의 100%입니다(1 코어 = 1024; 이는 고정 값입니다). 루트 그룹은 등록된 자손의 지분에 따라 자원을 비례적으로 분배합니다. cpu.share, 그리고 그들은 차례로 그들의 후손 등에 대해서도 동일한 작업을 수행합니다. 일반적인 Kubernetes 노드에서 루트 cgroup에는 세 개의 하위 항목이 있습니다. system.slice, user.slice и kubepods. 처음 두 하위 그룹은 중요한 시스템 로드와 K8 외부의 사용자 프로그램 간에 리소스를 배포하는 데 사용됩니다. 마지막 - kubepods — 포드 간에 리소스를 배포하기 위해 Kubernetes에서 생성됩니다.

위의 다이어그램은 첫 번째와 두 번째 하위 그룹이 각각 수신한 것을 보여줍니다. 1024 kuberpod 하위 그룹이 할당된 공유 4096 주식 이것이 어떻게 가능합니까? 결국 루트 그룹은 다음에만 액세스할 수 있습니다. 4096 그녀의 후손의 지분 합계가 이 숫자를 크게 초과합니다.6144)? 요점은 이 값이 논리적으로 타당하므로 Linux 스케줄러(CFS)가 이 값을 사용하여 CPU 리소스를 비례적으로 할당한다는 것입니다. 우리의 경우 처음 두 그룹은 680 실제 지분(16,6개 중 4096%), kubepod는 나머지 지분을 받습니다. 2736 주식 가동 중지 시간이 발생하면 처음 두 그룹은 할당된 리소스를 사용하지 않습니다.

다행히 스케줄러에는 사용되지 않는 CPU 리소스 낭비를 방지하는 메커니즘이 있습니다. "유휴" 용량을 글로벌 풀로 전송하고, 여기서 추가 프로세서 성능이 필요한 그룹에 배포됩니다(전송은 반올림 손실을 피하기 위해 일괄적으로 발생합니다). 자손의 모든 자손에 대해서도 유사한 방법이 적용됩니다.

이 메커니즘은 프로세서 성능의 공정한 분배를 보장하고 어느 프로세스도 다른 프로세스의 리소스를 "훔치는" 일이 없도록 보장합니다.

CPU 제한

K8의 제한 및 요청 구성이 비슷해 보이지만 구현은 근본적으로 다릅니다. 가장 오해의 소지가 있는 그리고 가장 문서화되지 않은 부분.

K8이 참여합니다 CFS 할당량 메커니즘 한계를 구현합니다. 해당 설정은 파일에 지정됩니다. cfs_period_us и cfs_quota_us cgroup 디렉토리(파일도 여기에 있음) cpu.share).

같지 않은 cpu.share, 할당량은 다음을 기준으로 합니다. 기간, 사용 가능한 프로세서 전력이 아닙니다. cfs_period_us 기간(에포크)의 지속 시간을 지정합니다. 항상 100000μs(100ms)입니다. K8s에는 이 값을 변경할 수 있는 옵션이 있지만 현재는 알파 버전에서만 사용할 수 있습니다. 스케줄러는 해당 에포크를 사용하여 사용된 할당량을 다시 시작합니다. 두 번째 파일 cfs_quota_us, 각 에포크에서 사용 가능한 시간(할당량)을 지정합니다. 마이크로초 단위로도 지정됩니다. 할당량은 에포크 길이를 초과할 수 있습니다. 즉, 100ms보다 클 수 있습니다.

16코어 컴퓨터(Omio에서 사용하는 가장 일반적인 컴퓨터 유형)에 대한 두 가지 시나리오를 살펴보겠습니다.

시나리오 1: 스레드 2개 및 200ms 제한. 제한 없음

시나리오 2: 스레드 10개 및 200ms 제한. 20ms 후에 조절이 시작되고, 80ms 후에 프로세서 리소스에 대한 액세스가 다시 시작됩니다.

CPU 제한을 다음과 같이 설정했다고 가정해 보겠습니다. 2 커널; Kubernetes는 이 값을 200ms로 변환합니다. 이는 컨테이너가 제한 없이 최대 200ms의 CPU 시간을 사용할 수 있음을 의미합니다.

그리고 이것이 재미가 시작되는 곳입니다. 위에서 언급했듯이 사용 가능한 할당량은 200ms입니다. 병행해서 작업하는 경우 10 12코어 머신의 스레드(시나리오 2의 그림 참조), 다른 모든 포드가 유휴 상태인 동안 할당량은 단 20ms(10 * 20ms = 200ms이므로) 내에 소진되고 이 포드의 모든 스레드가 정지됩니다. » (조절판) 다음 80ms 동안. 이미 언급한 스케줄러 버그, 이로 인해 과도한 제한이 발생하고 컨테이너가 기존 할당량을 충족할 수도 없습니다.

포드의 제한을 평가하는 방법은 무엇입니까?

포드에 로그인하고 실행하면 됩니다. cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - 스케줄러 기간의 총 수
• nr_throttled — 컴포지션의 조절 기간 수 nr_periods;
• throttled_time — 누적 조절 시간(나노초)입니다.

정말 무슨 일이 일어나고 있는 걸까요?

결과적으로 모든 애플리케이션에서 높은 제한이 발생합니다. 가끔 그 사람이 들어와서 XNUMX 회 계산보다 강하다!

이로 인해 준비 확인 실패, 컨테이너 정지, 네트워크 연결 끊김, 서비스 호출 내 시간 초과 등 다양한 오류가 발생합니다. 이로 인해 궁극적으로 대기 시간이 증가하고 오류율이 높아집니다.

결정과 결과

여기에서는 모든 것이 간단합니다. 우리는 CPU 제한을 포기하고 클러스터의 OS 커널을 버그가 수정된 최신 버전으로 업데이트하기 시작했습니다. 우리 서비스의 오류(HTTP 5xx) 수가 즉시 크게 감소했습니다.

HTTP 5xx 오류

하나의 중요한 서비스에 대한 HTTP 5xx 오류

응답시간 p95

중요한 서비스 요청 대기 시간, 95번째 백분위수

운영 비용

사용한 인스턴스 시간 수

캐치는 무엇입니까?

기사 시작 부분에 언급된 바와 같이:

공동 아파트로 비유를 그릴 수 있습니다. Kubernetes는 부동산 중개인 역할을 합니다. 하지만 세입자가 서로 충돌하지 않도록 하는 방법은 무엇입니까? 예를 들어 그들 중 한 명이 화장실을 반나절 동안 빌리기로 결정했다면 어떻게 될까요?

여기에 문제가 있습니다. 부주의한 컨테이너 하나가 시스템에서 사용 가능한 모든 CPU 리소스를 소모할 수 있습니다. 스마트 애플리케이션 스택이 있는 경우(예: JVM, Go, Node VM이 올바르게 구성되어 있음) 이는 문제가 되지 않습니다. 이러한 조건에서 오랫동안 작업할 수 있습니다. 그러나 애플리케이션이 제대로 최적화되지 않거나 전혀 최적화되지 않은 경우(FROM java:latest), 상황이 통제 불능 상태가 될 수 있습니다. Omio에는 주요 언어 스택에 대한 적절한 기본 설정을 갖춘 자동화된 기본 Dockerfile이 있으므로 이 문제는 존재하지 않습니다.

측정항목을 모니터링하는 것이 좋습니다. 사용 (사용량, 포화도 및 오류), API 지연 및 오류율. 결과가 기대에 부합하는지 확인하세요.

참조

이것이 우리의 이야기입니다. 다음 자료는 무슨 일이 일어나고 있는지 이해하는 데 큰 도움이 되었습니다.

• kernel.org → CFS 스케줄러;
• kernel.org → CFS 대역폭 제어;
• Linux 컨테이너 스케줄링 이해;
• Linux 컨테이너에 대해 알아야 할 모든 것, XNUMX부: Linux 제어 그룹 및 프로세스 격리;
• Kubernetes 실패 사례 - "CPU 조절"을 찾으십시오.

Kubernetes 버그 보고서:

• #51135: 보장된 포드에 대한 CPU 제한 설정을 피하세요.;
• #67577: CFS 할당량으로 인해 불필요한 제한이 발생할 수 있습니다.;
• 지나치게 공격적인 CFS.

실무에서 비슷한 문제를 겪은 적이 있거나 컨테이너화된 프로덕션 환경에서 조절과 관련된 경험이 있습니까? 댓글로 여러분의 이야기를 공유해주세요!

번역가의 추신

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

• «Kubernetes의 자동 크기 조정 및 리소스 관리(개요 및 동영상 보고서)";
• «Kubernetes에서 CPU 관리자가 작동하는 방식";
• «kubectl run을 실행하면 Kubernetes에서는 어떤 일이 발생하나요? 2 부".

출처 : habr.com