노드 및 워크로드 효율성

워크로드 및 노드를 효율적으로 사용하면 성능 및 규모를 높이는 동시에 복잡성/비용을 줄일 수 있습니다. 이러한 효율성을 계획할 때 고려해야 할 요소는 여러 가지가 있으며, 각 기능에 대한 모범 사례 설정 하나와 비교하여 절충 측면에서 생각하는 것이 가장 쉽습니다. 다음 단원에서 이러한 장단점을 자세히 살펴보겠습니다.

노드 선택

약간 더 큰(4~12xlarge) 노드 크기를 사용하면 DaemonSets 및 시스템 구성 요소에 대한 예약과 같은 "오버헤드"에 사용되는 노드의 백분율이 줄어들기 때문에 포드를 실행하는 데 사용할 수 있는 공간이 늘어납니다. 아래 다이어그램에서 2xlarge의 사용 가능한 공간과 중간 수의 DaemonSets.

참고

k8s는 일반 규칙으로 수평적으로 확장되므로 대부분의 애플리케이션에서 NUMA 크기 노드의 성능 영향을 받아들일 필요가 없으므로 해당 노드 크기보다 작은 범위의 권장 사항을 따르는 것이 좋습니다.

노드 크기가 크면 노드당 사용 가능한 공간의 비율이 높아질 수 있습니다. 그러나 노드를 너무 많은 포드로 패킹하여 오류를 일으키거나 노드를 포화시켜이 모델을 극단적으로 만들 수 있습니다. 노드 포화를 모니터링하는 것은 더 큰 노드 크기를 성공적으로 사용하는 데 중요합니다.

노드 선택은 one-size-fits-all인 경우는 거의 없습니다. 매우 다른 이탈률로 워크로드를 서로 다른 노드 그룹으로 분할하는 것이 가장 좋은 경우가 많습니다. 이탈률이 높은 소규모 배치 워크로드는 4xlarge 인스턴스 패밀리에서 가장 잘 제공되는 반면, 8 vCPU를 사용하고 이탈률이 낮은 Kafka와 같은 대규모 애플리케이션은 12xlarge 패밀리에서 더 잘 제공됩니다.

참고

노드 크기가 매우 큰 경우 고려해야 할 또 다른 요소는 CGROUPS가 컨테이너화된 애플리케이션에서 vCPU의 총 수를 숨기지 않기 때문입니다. 동적 런타임은 의도하지 않은 수의 OS 스레드를 생성하여 문제를 해결하기 어려운 지연 시간을 생성하는 경우가 많습니다. 이러한 애플리케이션의 경우 CPU 고정이 권장됩니다. 주제에 대한 자세한 내용은 다음 비디오 https://www.youtube.com/watch?v=NqtfDy_KAqg 참조하십시오.

노드 빈 패키징

Kubernetes와 Linux 규칙 비교

Kubernetes에서 워크로드를 처리할 때 주의해야 할 두 가지 규칙 세트가 있습니다. 요청 값을 사용하여 노드에서 포드를 예약한 다음 포드가 예약된 후 발생하는 Kubernetes 스케줄러의 규칙으로, Kubernetes가 아닌 Linux의 영역입니다.

Kubernetes 스케줄러가 완료되면 새로운 규칙 세트인 Linux 완전 공정 스케줄러(CFS)가 인수됩니다. 핵심은 Linux CFS에 코어 개념이 없다는 것입니다. 코어를 고려하면 워크로드를 규모에 맞게 최적화하는 데 큰 문제가 발생할 수 있는 이유에 대해 살펴보겠습니다.

코어에서 생각하기

Kubernetes 스케줄러에 코어 개념이 있기 때문에 혼동이 시작됩니다. Kubernetes 스케줄러 관점에서 각각 하나의 코어 세트 요청이 있는 4개의 NGINX 포드가 있는 노드를 살펴보면 노드는 다음과 같습니다.

하지만 Linux CFS 관점과 어떻게 다른지 생각해 보겠습니다. Linux CFS 시스템을 사용할 때 기억해야 할 가장 중요한 것은 사용 중인 컨테이너(CGROUPS)가 공유 시스템에 포함되는 유일한 컨테이너라는 것입니다. 이 경우 첫 번째 컨테이너만 사용 중이므로 노드에서 4개의 코어를 모두 사용할 수 있습니다.

이것이 중요한 이유는 무엇입니까? NGINX 애플리케이션이 해당 노드에서 유일하게 사용 중인 컨테이너였던 개발 클러스터에서 성능 테스트를 실행했다고 가정해 보겠습니다. 앱을 프로덕션으로 이동하면 NGINX 애플리케이션에 4개의 vCPU 리소스가 필요하지만 노드의 다른 모든 포드가 사용 중이므로 앱 성능이 제한됩니다.

이 상황으로 인해 애플리케이션이 "`sweet spot"으로 확장되는 것을 허용하지 않았기 때문에 불필요한 컨테이너를 더 추가할 수 있습니다. 의이 중요한 개념"sweet spot"을 좀 더 자세히 살펴보겠습니다.

애플리케이션 오른쪽 크기 조정

각 애플리케이션에는 더 이상 트래픽을 가져올 수 없는 특정 지점이 있습니다. 이 지점을 초과하면 처리 시간이 늘어나고이 지점을 훨씬 초과하여 푸시할 때 트래픽이 떨어질 수도 있습니다. 이를 애플리케이션의 포화 지점이라고 합니다. 크기 조정 문제를 방지하려면 애플리케이션이 포화 지점에 도달하기 전에 크기 조정을 시도해야 합니다. 이 점을 스위트 스팟이라고 부르겠습니다.

각 애플리케이션을 테스트하여 스위트 스팟을 이해해야 합니다. 애플리케이션마다 다르므로 여기에 범용 지침은 없습니다. 이 테스트에서는 애플리케이션 포화 지점을 보여주는 최상의 지표를 이해하려고 합니다. 사용률 지표를 사용하여 애플리케이션이 포화 상태임을 나타내는 경우가 많지만, 이로 인해 규모 조정 문제가 빠르게 발생할 수 있습니다(이 주제는 이후 단원에서 자세히 살펴보겠습니다). 이 "`sweet spot""이 있으면 이를 사용하여 워크로드를 효율적으로 확장할 수 있습니다.

반대로 스위트 스팟 전에 스케일 업하여 불필요한 포드를 만들면 어떻게 될까요? 다음 단원에서 이를 살펴보겠습니다.

포드 스프롤링

불필요한 포드를 생성하는 방법을 빠르게 알아보려면 왼쪽의 첫 번째 예제를 살펴보겠습니다. 이 컨테이너의 올바른 수직 규모는 초당 100개의 요청을 처리할 때 약 2개의 vCPUs 사용률을 차지합니다. 그러나 요청을 코어의 절반으로 설정하여 요청 값을 과소 프로비저닝하려는 경우 이제 실제로 필요한 각 포드에 대해 포드 4개가 필요합니다. 이 문제를 더 강조하면 HPA가 기본값인 50% CPU로 설정된 경우 해당 포드가 절반만큼 비워져 8:1 비율이 생성됩니다.

이 문제를 확장하면이 문제를 어떻게 해결할 수 있는지 빠르게 확인할 수 있습니다. 스위트 스팟이 잘못 설정된 10개의 포드를 배포하면 80개의 포드와 이를 실행하는 데 필요한 추가 인프라로 빠르게 스파이럴될 수 있습니다.

애플리케이션이 스위트 스팟에서 작동하도록 허용하지 않을 경우의 영향을 이해했으므로 이제 노드 수준으로 돌아가 Kubernetes 스케줄러와 Linux CFS 간의 이러한 차이가 왜 중요한지 질문해 보겠습니다.

HPA를 사용하여 스케일 업 및 스케일 다운할 때 더 많은 포드를 할당할 공간이 많은 시나리오가 있을 수 있습니다. 왼쪽에 표시된 노드의 CPU 사용률이 이미 100%이기 때문에 이는 잘못된 결정입니다. 비현실적이지만 이론적으로 가능한 시나리오에서는 노드가 완전히 가득 찼지만 CPU 사용률이 0인 다른 극단적 상황이 발생할 수 있습니다.

요청 설정

해당 애플리케이션에 대한 "스윗 스팟" 값으로 요청을 설정하려고 하지만 아래 다이어그램과 같이 비효율성이 발생합니다. 여기서는 요청 값을 vCPU 2로 설정했지만 이러한 포드의 평균 사용률은 대부분 CPU 1개만 실행합니다. 이 설정을 사용하면 CPU 주기의 50%를 낭비할 수 있으며, 이는 허용되지 않습니다.

이렇게 하면 문제에 대한 복잡한 답변을 얻을 수 있습니다. 컨테이너 사용률은 vacuum에서 고려할 수 없으며 노드에서 실행되는 다른 애플리케이션을 고려해야 합니다. 다음 예제에서 급증하는 컨테이너는 메모리 제약이 있을 수 있는 낮은 CPU 사용률 컨테이너 2개와 혼합됩니다. 이렇게 하면 노드에 세금을 부과하지 않고 컨테이너가 스위트 스팟에 도달할 수 있습니다.

이 모든 것을 해결해야 하는 중요한 개념은 코어의 Kubernetes 스케줄러 개념을 사용하여 Linux 컨테이너 성능을 이해하면 관련이 없으므로 의사 결정이 잘못될 수 있다는 것입니다.

참고

Linux CFS에는 강력한 점이 있습니다. 이는 I/O 기반 워크로드의 경우 특히 그렇습니다. 그러나 애플리케이션이 사이드카 없이 전체 코어를 사용하고 I/O 요구 사항이 없는 경우 CPU 고정은이 프로세스에서 상당한 복잡성을 제거할 수 있으며 이러한 주의 사항에 권장됩니다.

사용률과 포화도 비교

애플리케이션 조정의 일반적인 실수는 조정 지표에 CPU 사용률만 사용하는 것입니다. 복잡한 애플리케이션에서 이는 거의 항상 애플리케이션이 실제로 요청으로 포화되어 있음을 나타내는 잘못된 지표입니다. 왼쪽의 예에서는 모든 요청이 실제로 웹 서버에 도달하는 것을 볼 수 있으므로 CPU 사용률이 포화 상태로 잘 추적되고 있습니다.

실제 애플리케이션에서는 이러한 요청 중 일부가 데이터베이스 계층 또는 인증 계층 등에 의해 서비스될 가능성이 높습니다. 이처럼 일반적인 경우 다른 엔터티에서 요청을 처리하므로 CPU가 포화 상태로 추적되지 않습니다. 이 경우 CPU는 포화 지표가 매우 좋지 않습니다.

애플리케이션 성능에 잘못된 지표를 사용하는 것이 Kubernetes에서 불필요하고 예측할 수 없는 규모 조정의 가장 큰 이유입니다. 사용 중인 애플리케이션 유형에 맞는 올바른 포화 지표를 선택할 때는 각별히 주의해야 합니다. 제공할 수 있는 모든 권장 사항에 맞는 크기가 한 개도 없다는 점에 유의해야 합니다. 사용된 언어와 해당 애플리케이션 유형에 따라 포화도에 대한 다양한 지표 세트가 있습니다.

이 문제는 CPU 사용률에만 있다고 생각할 수 있지만 초당 요청과 같은 다른 일반적인 지표도 위에서 설명한 것과 정확히 동일한 문제가 될 수 있습니다. 요청이 웹 서버에서 직접 서비스되지 않는 DB 계층으로 이동할 수도 있으므로 웹 서버 자체의 실제 포화에 대한 지표가 좋지 않습니다.

안타깝게도 올바른 포화 지표를 선택할 때 쉬운 답변은 없습니다. 다음은 고려해야 할 몇 가지 지침입니다.

언어 런타임 이해 - 여러 OS 스레드가 있는 언어는 단일 스레드 애플리케이션과 다르게 반응하므로 노드에 다르게 영향을 미칩니다.
올바른 수직 규모 이해 - 새 포드를 규모 조정하기 전에 애플리케이션 수직 규모에서 원하는 버퍼의 양
애플리케이션의 포화도를 실제로 반영하는 지표 - Kafka 생산자의 포화 지표는 복잡한 웹 애플리케이션과 상당히 다릅니다.
노드의 다른 모든 애플리케이션은 서로에게 어떤 영향을 미치는가 - 애플리케이션 성능은 노드의 다른 워크로드가 큰 영향을 미치는 vacuum 상태에서 수행되지 않습니다.

이 섹션을 닫으려면 위의 내용을 지나치게 복잡하고 불필요하게 무시하기 쉽습니다. 문제가 발생하는 경우가 많지만 잘못된 지표를 보고 있기 때문에 문제의 실제 특성을 알지 못합니다. 다음 섹션에서는 이러한 일이 어떻게 발생할 수 있는지 살펴보겠습니다.

노드 포화

이제 애플리케이션 포화를 살펴보았으므로 노드 관점에서이 동일한 개념을 살펴보겠습니다. 사용률과 포화도의 차이를 확인하기 위해 100% 사용되는 두 개의 CPUs를 살펴보겠습니다.

왼쪽의 vCPU는 100% 활용되지만이 vCPU에서 실행되기를 기다리는 다른 작업은 없으므로 이론적으로 매우 효율적입니다. 한편, 두 번째 예제에서는 vCPU에서 처리되기 위해 대기 중인 20개의 단일 스레드 애플리케이션이 있습니다. 이제 20개 애플리케이션 모두 vCPU에서 처리되기 위해 차례를 기다리는 동안 일종의 지연 시간이 발생합니다. 즉, 오른쪽의 vCPU는 포화 상태입니다.

사용률을 살펴보는 경우이 문제가 발생하지 않을 뿐만 아니라 네트워킹과 같이 관련 없는 문제로 인해 잘못된 경로로 이어질 수 있습니다.

노드가 과도하게 포화되었다는 사실을 쉽게 놓칠 수 있으므로 언제든지 노드에서 실행되는 총 포드 수를 늘릴 때 사용률 지표뿐만 아니라 포화 지표를 보는 것이 중요합니다. 이 작업의 경우 아래 차트와 같이 압력 스톨 정보 지표를 사용할 수 있습니다.

PromQL - 중지된 I/O

topk(3, ((irate(node_pressure_io_stalled_seconds_total[1m])) * 100))

참고

압력 스톨 지표에 대한 자세한 내용은 https://facebookmicrosites.github.io/psi/docs/overview*를 참조하세요.

이러한 지표를 사용하면 스레드가 CPU에서 대기 중인지 또는 상자의 모든 스레드가 메모리 또는 I/O와 같은 리소스에서 대기 중인지 알 수 있습니다. 예를 들어 인스턴스의 모든 스레드가 1분 동안 I/O를 대기한 비율을 확인할 수 있습니다.

topk(3, ((irate(node_pressure_io_stalled_seconds_total[1m])) * 100))

이 지표를 사용하면 위의 차트에서 상자의 모든 스레드가 높은 워터마크에서 I/O를 기다리는 시간의 45% 동안 중단되었음을 확인할 수 있습니다. 즉, 해당 1분 동안 모든 CPU 주기를 버리고 있었습니다. 이러한 일이 발생하고 있음을 이해하면 상당한 양의 vCPU 시간을 회수하여 규모 조정의 효율성을 높이는 데 도움이 될 수 있습니다.

HPA V2

HPA API의 Autoscaling/v2 버전을 사용하는 것이 좋습니다. HPA API의 이전 버전은 특정 엣지 케이스에서 조정이 중단될 수 있습니다. 또한 각 조정 단계에서 포드가 두 배로만 제한되어 빠르게 확장해야 하는 소규모 배포에 문제가 발생했습니다.

Autoscaling/v2를 사용하면 확장할 여러 기준을 포함할 수 있는 유연성이 향상되고 사용자 지정 및 외부 지표(비 K8s 지표)를 사용할 때 유연성이 크게 향상됩니다.

예를 들어 세 값 중 가장 높은 값을 조정할 수 있습니다(아래 참조). 모든 포드의 평균 사용률이 50%를 초과하는 경우, 사용자 지정 지표가 수신의 초당 패킷 수가 평균 1,000을 초과하거나 수신 객체가 초당 10K 요청을 초과하는 경우 확장됩니다.

참고

이는 Auto Scaling API의 유연성을 보여주기 위한 것입니다. 프로덕션 환경에서 문제를 해결하기 어려울 수 있는 지나치게 복잡한 규칙을 사용하지 않는 것이 좋습니다.


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      target:
        type: AverageValue
        averageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1
        kind: Ingress
        name: main-route
      target:
        type: Value
        value: 10k

그러나 복잡한 웹 애플리케이션에 이러한 지표를 사용할 경우의 위험을 배웠습니다. 이 경우 애플리케이션의 포화도와 사용률을 정확하게 반영하는 사용자 지정 또는 외부 지표를 사용하면 더 나은 서비스를 제공할 수 있습니다. HPAv2는 모든 지표에 따라 확장할 수 있는 기능을 지원하지만, 여전히 해당 지표를 찾아 Kubernetes로 내보내야 사용할 수 있습니다.

예를 들어 Apache에서 활성 스레드 대기열 수를 볼 수 있습니다. 이렇게 하면 "smoother" 조정 프로필이 생성되는 경우가 많습니다(이 용어는 곧 추가됨). 스레드가 활성 상태인 경우 해당 스레드가 데이터베이스 계층에서 대기 중인지 아니면 로컬에서 요청을 처리하는지는 중요하지 않습니다. 모든 애플리케이션 스레드가 사용 중인 경우 애플리케이션이 포화 상태임을 나타내는 좋은 표시입니다.

이 스레드 소진을 신호로 사용하여 완전히 사용 가능한 스레드 풀이 있는 새 포드를 생성할 수 있습니다. 또한 트래픽이 많을 때 애플리케이션에서 흡수할 버퍼의 크기를 제어할 수 있습니다. 예를 들어 총 스레드 풀이 10인 경우 사용된 스레드 4개와 사용된 스레드 8개로 조정하면 애플리케이션 조정 시 사용할 수 있는 버퍼에 큰 영향을 미칩니다. 4로 설정하면 로드가 많을 때 빠르게 확장해야 하는 애플리케이션에 적합할 것입니다.이 경우 시간이 지남에 따라 요청 수가 느리게 증가하거나 급격하게 증가하여 확장할 시간이 많으면 리소스에서 8로 설정하면 더 효율적입니다.

규모 조정과 관련하여 "평활"이라는 용어는 무엇을 의미합니까? CPU를 지표로 사용하는 아래 차트에 유의하십시오. 이 배포의 포드는 50개의 포드에서 잠시 동안 급증하며, 다시 즉시 스케일 다운하기 위해 포드는 최대 250개까지입니다. 이는 클러스터 이탈의 가장 큰 원인입니다.

애플리케이션의 올바른 스위트 스팟(차트의 중간 부분)을 반영하는 지표로 변경한 후 어떻게 원활하게 확장할 수 있는지 확인합니다. 이제 확장이 효율적이며, 요청 설정을 조정하여 제공한 헤드룸에 따라 포드를 완전히 확장할 수 있습니다. 이제 더 작은 포드 그룹이 수백 개의 포드가 이전에 하던 작업을 수행하고 있습니다. 실제 데이터는 이것이 Kubernetes 클러스터의 확장성에서 가장 중요한 요소임을 보여줍니다.

핵심은 CPU 사용률이 애플리케이션과 노드 성능의 한 가지 차원에 불과하다는 것입니다. CPU 사용률을 노드 및 애플리케이션의 유일한 상태 지표로 사용하면 확장, 성능 및 비용에 문제가 발생하며, 이는 모두 밀접하게 연결된 개념입니다. 애플리케이션과 노드의 성능이 높을수록 규모 조정이 덜 필요하므로 비용이 절감됩니다.

특정 애플리케이션의 규모를 조정하기 위해 올바른 포화 지표를 찾고 사용하면 해당 애플리케이션의 실제 병목 현상을 모니터링하고 경보할 수도 있습니다. 이 중요한 단계를 건너뛰면 성능 문제에 대한 보고는 불가능하지 않더라도 이해하기가 어렵습니다.

CPU 제한 설정

오해의 소지가 있는 주제에 대해이 단원을 마무리하기 위해 CPU 제한에 대해 살펴보겠습니다. 즉, 제한은 100ms마다 재설정되는 카운터가 있는 컨테이너와 연결된 메타데이터입니다. 이를 통해 Linux는 100ms 기간 동안 특정 컨테이너가 노드 전체에서 사용하는 CPU 리소스 수를 추적할 수 있습니다.

제한 설정 시 발생하는 일반적인 오류는 애플리케이션이 단일 스레드이고 "`assigned"` vCPU에서만 실행된다고 가정하는 것입니다. 위 섹션에서는 CFS가 코어를 할당하지 않으며, 실제로는 큰 스레드 풀을 실행하는 컨테이너가 상자의 사용 가능한 모든 vCPU에 예약된다는 것을 배웠습니다.

64개의 OS 스레드가 64개의 사용 가능한 코어에서 실행되는 경우(Linux 노드 관점에서) 64개의 모든 코어에서 실행되는 시간이 추가된 후 100ms 기간 동안 사용된 총 CPU 시간을 상당히 크게 청구합니다. 이는 가비지 수집 프로세스 중에만 발생할 수 있으므로 이와 같은 것을 놓치기 쉽습니다. 따라서 제한을 설정하기 전에 시간 경과에 따른 올바른 사용량을 보장하기 위해 지표를 사용해야 합니다.

다행히도 애플리케이션의 모든 스레드에서 사용되는 vCPU의 양을 정확히 확인할 수 있습니다. container_cpu_usage_seconds_total이 목적으로 지표를 사용합니다.

제한 로직은 100ms마다 발생하고이 지표는 초당 지표이므로이 100ms 기간과 일치하도록 PromQL을 사용합니다. 이 PromQL 문 작업을 자세히 알아보려면 다음 블로그를 참조하세요.

PromQL 쿼리:

topk(3, max by (pod, container)(rate(container_cpu_usage_seconds_total{image!="", instance="$instance"}[$__rate_interval]))) / 10

올바른 가치가 있다고 생각되면 프로덕션 환경에 제한을 둘 수 있습니다. 그런 다음 예기치 않은 문제로 인해 애플리케이션이 제한되고 있는지 확인해야 합니다. 다음을 살펴보면이 작업을 수행할 수 있습니다. container_cpu_throttled_seconds_total

topk(3, max by (pod, container)(rate(container_cpu_cfs_throttled_seconds_total{image!=``""``, instance=``"$instance"``}[$__rate_interval]))) / 10

메모리

메모리 할당은 Linux CGroup 동작에 대한 Kubernetes 스케줄링 동작을 혼동하기 쉬운 또 다른 예입니다. 이 주제는 CGroup v2가 Linux에서 메모리를 처리하는 방식이 크게 변경되었고 Kubernetes가 이를 반영하도록 구문을 변경했기 때문에 더 미묘한 차이가 있습니다. 자세한 내용은이 블로그를 참조하세요.

CPU 요청과 달리 메모리 요청은 예약 프로세스가 완료된 후 사용되지 않습니다. 이는 CPU와 동일한 방식으로 CGroup v1의 메모리를 압축할 수 없기 때문입니다. 이렇게 하면 포드를 완전히 종료하여 메모리 누수에 대한 페일 세이프 역할을 하도록 설계된 메모리 제한만 남게 됩니다. 이는 모두 또는 전혀 스타일 제안이 아니지만 이제이 문제를 해결할 수 있는 새로운 방법을 제공했습니다.

먼저 컨테이너에 적절한 양의 메모리를 설정하는 것은 나타나는 것처럼 간단하지 않다는 점을 이해하는 것이 중요합니다. Linux의 파일 시스템은 메모리를 캐시로 사용하여 성능을 개선합니다. 이 캐시는 시간이 지남에 따라 증가하며 캐시에 사용할 수 있는 메모리의 양을 파악하기 어려울 수 있지만 애플리케이션 성능에 큰 영향을 주지 않고 회수할 수 있습니다. 이로 인해 메모리 사용량이 잘못 해석되는 경우가 많습니다.

메모리를 "압축"하는 기능은 CGroup v2의 기본 동인 중 하나였습니다. CGroup V2가 필요한 이유에 대한 자세한 내용은 LISA21에서 Chris Down의 프레젠테이션을 참조하세요.이 프레젠테이션에서는 최소 메모리를 올바르게 설정할 수 없는 것이 CGroup v2 및 압력 스톨 지표를 생성하도록 유도한 이유 중 하나인 이유를 다룹니다.

다행히도 Kubernetes는 이제 memory.high 아래에 memory.min 및 라는 개념을 가지고 있습니다requests.memory. 이렇게 하면 다른 컨테이너에서 사용할 수 있도록이 캐시된 메모리를 적극적으로 릴리스할 수 있습니다. 컨테이너가 메모리 상한에 도달하면 커널은에 설정된 값까지 해당 컨테이너의 메모리를 적극적으로 회수할 수 있습니다memory.min. 따라서 노드에 메모리 압력이 가해질 때 더 많은 유연성을 제공합니다.

핵심 질문은 입니다. 설정할 값은 무엇입니까memory.min? 여기에서 메모리 압력 스톨 지표가 작동합니다. 이러한 지표를 사용하여 컨테이너 수준에서 메모리 "스래싱"을 감지할 수 있습니다. 그런 다음 fbtax와 같은 컨트롤러를 사용하여이 메모리 스래싱을 memory.min 찾아에 대한 올바른 값을 감지하고 memory.min 값을이 설정으로 동적으로 설정할 수 있습니다.

요약

섹션을 요약하기 위해 다음 개념을 쉽게 혼동할 수 있습니다.

사용률 및 포화도
Kubernetes 스케줄러 로직을 사용한 Linux 성능 규칙

이러한 개념을 분리하려면 각별히 주의해야 합니다. 성능과 규모는 심층적으로 연결됩니다. 불필요한 조정으로 인해 성능 문제가 발생하고, 이로 인해 조정 문제가 발생합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

컨트롤 플레인 모니터링

Kubernetes SLOs