Kubernetes 조정 이론

노드와 이탈률 비교

Kubernetes의 확장성에 대해 논의할 때 단일 클러스터에 있는 노드의 수에 대해 논의하는 경우가 많습니다. 흥미롭게도 확장성을 이해하는 데 가장 유용한 지표는 거의 없습니다. 예를 들어 포드 수가 많지만 고정된 5,000개의 노드 클러스터는 초기 설정 후 컨트롤 플레인에 많은 스트레스를 주지 않습니다. 그러나 1,000개의 노드 클러스터를 가져와서 1분 이내에 10,000개의 짧은 수명이 있는 작업을 생성하려고 하면 컨트롤 플레인에 상당한 지속적인 부담을 줄 수 있습니다.

노드 수를 사용하여 조정을 이해하는 것만으로도 오해의 소지가 있을 수 있습니다. 특정 기간 내에 발생하는 변경 속도를 고려하는 것이 좋습니다(이 논의에는 일반적으로 Prometheus 쿼리에서 사용하는 5분 간격을 사용). 변경 속도 측면에서 문제를 프레이밍하면 원하는 규모를 달성하기 위해 조정해야 할 사항을 더 잘 파악할 수 있는 이유를 살펴보겠습니다.

초당 쿼리로 생각하기

Kubernetes에는 Kubernetes 체인의 다음 링크가 압도되지 않도록 Kubelet, Scheduler, Kube Controller Manager, API 서버 등 각 구성 요소에 대한 여러 보호 메커니즘이 있습니다. 예를 들어 Kubelet에는 특정 속도로 API 서버에 대한 호출을 제한하는 플래그가 있습니다. 이러한 보호 메커니즘은 일반적으로 초당 또는 QPS로 허용되는 쿼리로 표현되지만 항상 표현되는 것은 아닙니다.

이러한 QPS 설정을 변경할 때는 각별히 주의해야 합니다. Kubelet에서 초당 쿼리와 같은 하나의 병목 현상을 제거하면 다른 다운스트림 구성 요소에 영향을 미칩니다. 이렇게 하면 시스템이 특정 속도 이상으로 부담을 받을 수 있으므로 Kubernetes에서 워크로드를 성공적으로 확장하려면 서비스 체인의 각 부분을 이해하고 모니터링하는 것이 중요합니다.

참고

API 서버에는 API 우선 순위와 공정성이 도입된 보다 복잡한 시스템이 있으며, 이에 대해서는 별도로 설명하겠습니다.

참고

주의, 일부 지표는 적합한 것 같지만 실제로 다른 지표를 측정하고 있습니다. 예를 들어는 Kubelet에서 apiserver로의 요청 수가 아니라 Kubelet의 지표 서버와만 kubelet_http_inflight_requests 관련이 있습니다. 이로 인해 Kubelet에서 QPS 플래그를 잘못 구성할 수 있습니다. 특정 Kubelet에 대한 감사 로그 쿼리는 지표를 확인하는 보다 신뢰할 수 있는 방법입니다.

분산 구성 요소 조정

EKS는 관리형 서비스이므로 Kubernetes 구성 요소를 etcd, Kube Controller Manager, Scheduler(다이어그램의 왼쪽 부분)를 포함하는 AWS 관리형 구성 요소와 Kubelet, Container Runtime, 네트워킹 및 스토리지 드라이버(다이어그램의 오른쪽 부분)와 같은 AWS APIs를 호출하는 다양한 연산자와 같은 고객 구성 가능한 구성 요소의 두 가지 범주로 분할해 보겠습니다. 고객이 API 우선 순위 및 공정성 설정을 구성할 수 있으므로 AWS 관리형이더라도 API 서버는 중간에 둡니다.

업스트림 및 다운스트림 병목 현상

각 서비스를 모니터링할 때는 병목 현상을 찾기 위해 지표를 양방향으로 살펴보는 것이 중요합니다. 예를 들어 Kubelet을 사용하여이 작업을 수행하는 방법을 살펴보겠습니다. Kubelet은 API 서버와 컨테이너 런타임에 대해 모두 설명합니다. 두 구성 요소 중 하나에 문제가 있는지 여부를 탐지하기 위해 모니터링해야 할 사항과 방법은 무엇입니까?

노드당 포드 수

노드에서 실행할 수 있는 포드 수와 같은 조정 번호를 살펴볼 때 업스트림이 얼굴 값으로 지원하는 노드당 포드 110개를 가져올 수 있습니다.

참고

https://kubernetes.io/docs/setup/best-practices/cluster-large/

그러나 워크로드는 업스트림의 확장성 테스트에서 테스트한 것보다 더 복잡할 수 있습니다. 프로덕션 환경에서 실행하려는 포드 수를 서비스할 수 있도록 Kubelet이 Containerd 런타임과 함께 "유지" 중인지 확인해 보겠습니다.

간소화를 위해 Kubelet은 컨테이너 런타임(이 경우 Containerd)에서 포드의 상태를 가져옵니다. 상태를 너무 빨리 변경하는 포드가 너무 많으면 어떻게 해야 하나요? 변경 속도가 너무 높으면 [컨테이너 런타임에 대한] 요청 시간이 초과될 수 있습니다.

참고

Kubernetes는 지속적으로 진화하고 있으며,이 하위 시스템은 현재 변경 중입니다. https://github.com/kubernetes/enhancements/issues/3386

위 그래프에는 포드 수명 주기 이벤트 생성 기간 지표의 제한 시간 값에 도달했음을 나타내는 평면이 표시됩니다. 자체 클러스터에서 이를 보려면 다음 PromQL 구문을 사용할 수 있습니다.

increase(kubelet_pleg_relist_duration_seconds_bucket{instance="$instance"}[$__rate_interval])

이 제한 시간 동작을 보면 노드가 가능한 한도 이상으로 푸시된 것을 알 수 있습니다. 계속 진행하기 전에 제한 시간의 원인을 해결해야 합니다. 이는 노드당 포드 수를 줄이거나 재시도량이 많아질 수 있는(따라서 이탈률에 영향을 미치는) 오류를 찾아냄으로써 달성할 수 있습니다. 중요한 점은 지표가 노드가 할당된 포드의 이탈률을 처리할 수 있는지 아니면 고정된 수를 사용할 수 있는지 파악하는 가장 좋은 방법이라는 것입니다.

지표별 규모 조정

지표를 사용하여 시스템을 최적화하는 개념은 오래된 개념이지만 사람들이 Kubernetes 여정을 시작할 때 간과되는 경우가 많습니다. 특정 숫자(예: 노드당 포드 110개)에 초점을 맞추는 대신 시스템에서 병목 현상을 찾는 데 도움이 되는 지표를 찾는 데 노력을 집중합니다. 이러한 지표에 적합한 임계값을 이해하면 시스템이 최적으로 구성되어 있다는 높은 신뢰도를 얻을 수 있습니다.

변경 사항의 영향

문제를 일으킬 수 있는 일반적인 패턴은 의심되는 첫 번째 지표 또는 로그 오류에 초점을 맞추는 것입니다. Kubelet이 이전에 시간 초과된 것을 보면 Kubelet이 전송할 수 있는 초당 속도 증가 등과 같은 무작위 작업을 시도할 수 있습니다. 그러나 먼저 발견된 오류의 모든 다운스트림에 대한 전체 그림을 보는 것이 좋습니다. 용도에 따라 데이터를 기반으로 각 변경을 수행합니다.

Kubelet의 다운스트림은 컨테이너식 런타임(포드 오류), 스토리지 드라이버(CSI)와 같은 DaemonSets 및 EC2 API와 통신하는 네트워크 드라이버(CNI) 등이 됩니다.

런타임을 따라가지 않는 Kubelet의 이전 예를 계속 살펴보겠습니다. 노드를 너무 밀집하여 오류를 트리거할 수 있는 여러 지점이 있습니다.

워크로드에 적합한 노드 크기를 설계할 때 이러한 신호는 시스템에 불필요한 압력을 가하여 규모와 성능을 제한할 수 있는 easy-to-overlook 신호입니다.

불필요한 오류의 비용

Kubernetes 컨트롤러는 오류 조건이 발생할 때 재시도하는 데 뛰어나지만 비용이 발생합니다. 이러한 재시도는 Kube Controller Manager와 같은 구성 요소에 대한 부담을 높일 수 있습니다. 이러한 오류를 모니터링하는 것은 규모 테스트의 중요한 테넌트입니다.

오류가 더 적게 발생하면 시스템에서 스팟 문제가 더 쉽게 발생합니다. 주요 작업(예: 업그레이드) 전에 클러스터에 오류가 없는지 주기적으로 확인하면 예상치 못한 이벤트가 발생할 때 로그 문제 해결을 간소화할 수 있습니다.

보기 확장

수천 개의 노드가 있는 대규모 클러스터에서는 병목 현상을 개별적으로 찾고 싶지 않습니다. PromQL에서는 topk라는 함수를 사용하여 데이터 세트에서 가장 높은 값을 찾을 수 있습니다. K는 변수이므로 원하는 항목 수를 배치합니다. 여기서는 세 개의 노드를 사용하여 클러스터의 모든 Kubelets가 포화 상태인지 여부를 확인합니다. 지금까지 지연 시간을 살펴보았습니다. 이제 Kubelet에서 이벤트를 삭제하는지 살펴보겠습니다.

topk(3, increase(kubelet_pleg_discard_events{}[$__rate_interval]))

이 문을 분석합니다.

• Grafana 변수를 사용하여 필요한 4개의 샘플을 $__rate_interval 가져오도록 합니다. 이렇게 하면 간단한 변수를 사용한 모니터링에서 복잡한 주제를 우회할 수 있습니다.

• topk는 최상위 결과만 제공하고 숫자 3은 해당 결과를 3으로 제한합니다. 이는 클러스터 전체 지표에 유용한 함수입니다.

• {} 필터가 없다고 알려주세요. 일반적으로 스크레이핑 규칙의 작업 이름을 입력하지만 이러한 이름은 다르기 때문에 비워 둡니다.

문제를 절반으로 분할

시스템의 병목 현상을 해결하기 위해 업스트림 또는 다운스트림에 문제가 있음을 보여주는 지표를 찾는 접근 방식을 취합니다. 이렇게 하면 문제를 절반으로 분할할 수 있기 때문입니다. 또한 지표 데이터를 표시하는 방법의 핵심 원칙이기도 합니다.

이 프로세스를 시작하는 좋은 방법은 API 서버입니다. 클라이언트 애플리케이션 또는 컨트롤 플레인에 문제가 있는지 확인할 수 있기 때문입니다.