Kubernetes Pod 리소스에 액세스하는 방법

Tohad의 보상

Kubernetes를 시작할 때 컨테이너 리소스 설정을 잊어버리는 것이 일반적입니다. 이 시점에서는 Docker 이미지가 작동하고 Kubernetes 클러스터에 배포될 수 있는지 확인하는 것으로 충분합니다.

그러나 나중에 애플리케이션을 다른 애플리케이션과 함께 프로덕션 클러스터에 배포해야 합니다. 이렇게 하려면 컨테이너에 리소스를 할당하고 해당 리소스가 애플리케이션을 시작하고 실행하는 데 충분한지, 실행 중인 다른 애플리케이션에 문제가 발생하지 않는지 확인해야 합니다.

팀 Mail.ru의 Kubernetes aaS 컨테이너 리소스(CPU 및 MEM), 요청 및 리소스 제한 사항에 대한 기사를 번역했습니다. 이러한 설정의 이점과 설정하지 않으면 어떤 일이 발생하는지 알아봅니다.

컴퓨팅 리소스

다음 단위를 포함하는 두 가지 유형의 리소스가 있습니다.

• 중앙 처리 장치(CPU) - 코어
• 메모리(MEM) - 바이트.

각 컨테이너마다 리소스가 지정됩니다. 다음 Pod YAML 파일에는 요청된 리소스와 제한 리소스가 포함된 리소스 섹션이 표시됩니다.

• 요청된 포드 리소스 = 모든 컨테이너의 요청된 리소스 합계.
• 포드 리소스 제한 = 모든 포드 리소스 제한의 합계입니다.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

요청된 자원과 제한된 자원의 예

분야 resources.requested 사양에서 Pod는 원하는 노드를 찾는 데 사용되는 요소 중 하나입니다. 이미 Pod 배포를 계획할 수 있습니다. 적합한 노드를 어떻게 찾나요?

Kubernetes는 마스터 노드 또는 마스터 노드(Kubernetes Control Plane)를 포함한 여러 구성 요소로 구성됩니다. 마스터 노드에는 kube-apiserver, kube-controller-manager 및 kube-scheduler 등 여러 프로세스가 있습니다.

kube-scheduler 프로세스는 새로 생성된 포드를 검토하고 요청된 리소스 수를 포함하여 모든 포드 요청과 일치하는 가능한 작업자 노드를 찾는 일을 담당합니다. kube-scheduler가 찾은 노드 목록의 순위가 지정됩니다. Pod는 점수가 가장 높은 노드에 예약됩니다.

보라색 포드는 어디에 배치되나요?

그림에서 kube-scheduler가 새로운 보라색 포드를 예약해야 함을 볼 수 있습니다. Kubernetes 클러스터에는 A와 B라는 두 개의 노드가 포함되어 있습니다. 보시다시피 kube-scheduler는 노드 A에서 Pod를 예약할 수 없습니다. 사용 가능한(요청되지 않은) 리소스가 보라색 Pod의 요청과 일치하지 않습니다. 따라서 보라색 Pod에서 요청한 1GB 메모리는 노드 A에 맞지 않습니다. 사용 가능한 메모리가 0,5GB이기 때문입니다. 하지만 노드 B에는 충분한 리소스가 있습니다. 결과적으로 kube-scheduler는 보라색 Pod의 대상이 노드 B라고 결정합니다.

이제 요청된 리소스가 포드를 실행할 노드 선택에 어떤 영향을 미치는지 알았습니다. 그러나 한계 자원의 영향은 무엇입니까?

리소스 제한은 CPU/MEM이 넘을 수 없는 경계입니다. 그러나 CPU 리소스는 유연하므로 CPU 한도에 도달한 컨테이너로 인해 포드가 종료되지는 않습니다. 대신 CPU 조절이 시작됩니다. MEM 사용 제한에 도달하면 OOM-Killer로 인해 컨테이너가 중지되고 RestartPolicy 설정에서 허용되는 경우 다시 시작됩니다.

요청된 리소스 및 최대 리소스 세부정보

Docker와 Kubernetes 간의 리소스 통신

리소스 요청과 리소스 제한이 어떻게 작동하는지 설명하는 가장 좋은 방법은 Kubernetes와 Docker 간의 관계를 소개하는 것입니다. 위 이미지에서 Kubernetes 필드와 Docker 시작 플래그가 어떻게 관련되어 있는지 확인할 수 있습니다.

기억: 요청과 제한

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

위에서 언급했듯이 메모리는 바이트 단위로 측정됩니다. 기반 쿠버네티스 문서, 메모리를 숫자로 지정할 수 있습니다. 일반적으로 이는 정수(예: 2678, 즉 2678바이트)입니다. 접미사를 사용할 수도 있습니다. G и Gi, 가장 중요한 것은 그것들이 동일하지 않다는 것을 기억하는 것입니다. 첫 번째는 8진수이고 두 번째는 XNUMX진수입니다. kXNUMXs 문서에 언급된 예와 같습니다. 128974848, 129e6, 129M, 123Mi - 실질적으로 동일합니다.

쿠버네티스 옵션 limits.memory 국기와 일치한다 --memory 도커에서. 다음의 경우 request.memory Docker는 이 필드를 사용하지 않으므로 Docker에 대한 화살표가 없습니다. 이것이 꼭 필요한가?라고 물으실 수도 있습니다. 네, 필요해요. 앞서 말했듯이, Kubernetes에서는 현장이 중요합니다. kube-scheduler는 이 정보를 기반으로 포드를 예약할 노드를 결정합니다.

요청에 대해 메모리를 부족하게 설정하면 어떻게 되나요?

컨테이너가 요청된 메모리 한도에 도달한 경우 노드에 메모리가 충분하지 않을 때 중지되는 포드 그룹에 포드가 배치됩니다.

메모리 제한을 너무 낮게 설정하면 어떻게 되나요?

컨테이너가 메모리 제한을 초과하면 OOM-Killed로 인해 종료됩니다. 기본값은 RestartPolicy에 따라 가능한 경우 다시 시작됩니다. Always.

요청된 메모리를 지정하지 않으면 어떻게 되나요?

Kubernetes는 제한 값을 가져와 기본값으로 설정합니다.

메모리 제한을 지정하지 않으면 어떻게 되나요?

컨테이너에는 제한이 없으며 원하는 만큼의 메모리를 사용할 수 있습니다. 노드의 사용 가능한 메모리를 모두 사용하기 시작하면 OOM이 그를 죽입니다. 그런 다음 가능한 경우 RestartPolicy에 따라 컨테이너가 다시 시작됩니다.

메모리 제한을 지정하지 않으면 어떻게 되나요?

이는 최악의 시나리오입니다. 스케줄러는 컨테이너에 필요한 리소스 수를 알지 못하며 이로 인해 노드에 심각한 문제가 발생할 수 있습니다. 이 경우 네임스페이스에 대한 기본 제한(LimitRange로 설정)을 두는 것이 좋습니다. 기본 제한은 없습니다. Pod에는 제한이 없으며 원하는 만큼 메모리를 사용할 수 있습니다.

요청된 메모리가 노드가 제공할 수 있는 것보다 많으면 포드가 예약되지 않습니다. 그것을 기억하는 것이 중요합니다 Requests.memory - 최소값이 아닙니다. 이는 컨테이너를 지속적으로 실행하는 데 충분한 메모리 양에 대한 설명입니다.

일반적으로 동일한 값을 설정하는 것이 좋습니다. request.memory и limit.memory. 이렇게 하면 Kubernetes가 포드를 실행하기에 충분한 메모리가 있지만 실행하기에는 충분하지 않은 노드에서 포드를 예약하지 않습니다. 명심하세요: Kubernetes Pod 계획은 오직 고려 사항만 고려합니다 requests.memory과 limits.memory 고려하지 않습니다.

CPU: 요청 및 제한

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

CPU를 사용하면 모든 것이 조금 더 복잡해집니다. Kubernetes와 Docker의 관계 그림으로 돌아가면 다음을 알 수 있습니다. request.cpu 일치 --cpu-shares반면에 limit.cpu 국기와 일치한다 cpus 도커에서.

Kubernetes가 요청하는 CPU에는 CPU 주기의 비율인 1024를 곱합니다. 1개의 전체 코어를 요청하려면 다음을 추가해야 합니다. cpu: 1위에 표시된 대로.

전체 커널(비율 = 1024)을 요청한다고 해서 컨테이너가 이를 수신한다는 의미는 아닙니다. 호스트 머신에 코어가 하나만 있고 둘 이상의 컨테이너를 실행하는 경우 모든 컨테이너는 사용 가능한 CPU를 서로 공유해야 합니다. 어떻게 이런 일이 발생하나요? 사진을 보자.

CPU 요청 - 단일 코어 시스템

컨테이너를 실행하는 단일 코어 호스트 시스템이 있다고 가정해 보겠습니다. 엄마(Kubernetes)가 파이(CPU)를 구워 아이들(컨테이너)에게 나눠주고 싶어 합니다. 세 명의 어린이는 파이 전체를 원하고(비율 = 1024), 다른 어린이는 파이 절반을 원합니다(512). 엄마는 공정하길 원하셔서 간단한 계산을 하십니다.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

계산에 따르면 세 명의 어린이는 코어 전체가 아닌 코어의 28%를 받게 됩니다. 네 번째 자식은 전체 커널의 절반이 아닌 14%를 받습니다. 하지만 멀티코어 시스템이 있다면 상황은 달라집니다.

CPU 요청 - 멀티 코어(4) 시스템

위 이미지에서 세 명의 어린이는 파이 전체를 원하고 한 명은 절반을 원하는 것을 볼 수 있습니다. 엄마가 파이 네 개를 구웠으니, 엄마의 아이들은 각자 원하는 만큼 파이를 먹을 것이다. 멀티 코어 시스템에서는 프로세서 리소스가 사용 가능한 모든 프로세서 코어에 분산됩니다. 컨테이너가 전체 CPU 코어 100개 미만으로 제한되는 경우에도 여전히 XNUMX%로 사용할 수 있습니다.

위의 계산은 CPU가 컨테이너 간에 어떻게 분산되는지 이해하기 위해 단순화되었습니다. 물론 컨테이너 자체 외에도 CPU 리소스를 사용하는 다른 프로세스도 있습니다. 한 컨테이너의 프로세스가 유휴 상태이면 다른 프로세스가 해당 리소스를 사용할 수 있습니다. CPU: "200m" 일치 CPU: 0,2, 이는 코어 20개의 약 XNUMX%를 의미합니다.

이제 이야기하자 limit.cpu. Kubernetes가 제한하는 CPU에 100을 곱합니다. 결과는 컨테이너가 100μs마다 사용할 수 있는 시간입니다(cpu-period).

limit.cpu Docker 플래그와 일치합니다. --cpus. 이것은 오래된 것의 새로운 조합입니다. --cpu-period и --cpu-quota. 이를 설정하면 제한이 시작되기 전에 컨테이너가 최대로 사용할 수 있는 사용 가능한 CPU 리소스 수를 나타냅니다.

• CPU를 - 조합 cpu-period и cpu-quota. cpus = 1.5 설정과 동일 cpu-period = 100000 и cpu-quota = 150000;
• CPU 기간 - 기간 CPU CFS 스케줄러, 기본값은 100마이크로초입니다.
• CPU 할당량 - 내부의 마이크로초 수 cpu-period, 이는 컨테이너에 의해 제한됩니다.

요청한 CPU가 부족하게 설치되면 어떻게 되나요?

컨테이너에 설치된 것보다 더 많은 것이 필요한 경우 다른 프로세스에서 CPU를 훔치게 됩니다.

CPU 제한을 너무 낮게 설정하면 어떻게 되나요?

CPU 리소스는 조정 가능하므로 조절 기능이 켜집니다.

CPU 요청을 지정하지 않으면 어떻게 되나요?

메모리와 마찬가지로 요청 값은 제한과 같습니다.

CPU 제한을 지정하지 않으면 어떻게 되나요?

컨테이너는 필요한 만큼의 CPU를 사용합니다. 기본 CPU 정책(LimitRange)이 네임스페이스에 정의된 경우 이 제한은 컨테이너에도 사용됩니다.

요청이나 CPU 제한을 지정하지 않으면 어떻게 되나요?

메모리와 마찬가지로 이는 최악의 시나리오입니다. 스케줄러는 컨테이너에 필요한 리소스 수를 알지 못하며 이로 인해 노드에 심각한 문제가 발생할 수 있습니다. 이를 방지하려면 네임스페이스에 대한 기본 제한(LimitRange)을 설정해야 합니다.

기억하세요: 노드가 제공할 수 있는 것보다 더 많은 CPU를 요청하면 포드가 예약되지 않습니다. Requests.cpu - 최소값은 아니지만 Pod를 시작하고 오류 없이 작동하기에 충분한 값입니다. 응용 프로그램이 복잡한 계산을 수행하지 않는 경우 가장 좋은 방법은 설치하는 것입니다. request.cpu <= 1 필요한 만큼 복제본을 실행합니다.

요청된 리소스의 이상적인 양 또는 리소스 제한

우리는 컴퓨팅 자원의 한계에 대해 배웠습니다. 이제 다음 질문에 대답할 시간입니다. “내 포드가 문제 없이 애플리케이션을 실행하려면 얼마나 많은 리소스가 필요합니까? 이상적인 금액은 얼마입니까?

불행하게도 이러한 질문에 대한 명확한 답은 없습니다. 애플리케이션이 어떻게 작동하는지, 얼마나 많은 CPU나 메모리가 필요한지 모르는 경우 가장 좋은 방법은 애플리케이션에 많은 메모리와 CPU를 제공한 다음 성능 테스트를 실행하는 것입니다.

성능 테스트 외에도 일주일 동안 모니터링을 통해 애플리케이션의 동작을 모니터링합니다. 그래프에 애플리케이션이 요청한 것보다 적은 리소스를 소비하고 있는 것으로 나타나면 요청된 CPU 또는 메모리 양을 줄일 수 있습니다.

예를 들어 이것을 참조하십시오 Grafana 대시보드. 요청한 리소스 또는 리소스 제한과 현재 리소스 사용량 간의 차이를 표시합니다.

결론

리소스를 요청하고 제한하면 Kubernetes 클러스터를 정상 상태로 유지하는 데 도움이 됩니다. 적절한 제한 구성은 비용을 최소화하고 애플리케이션을 항상 실행 상태로 유지합니다.

간단히 말해, 명심해야 할 몇 가지 사항이 있습니다.

1. 요청된 리소스는 시작 시(Kubernetes가 애플리케이션을 호스팅할 계획인 경우) 고려되는 구성입니다. 대조적으로, 애플리케이션이 이미 노드에서 실행 중인 런타임에는 리소스를 제한하는 것이 중요합니다.
2. 메모리에 비해 CPU는 규제된 리소스입니다. CPU가 충분하지 않으면 포드가 종료되지 않고 조절 메커니즘이 켜집니다.
3. 요청한 리소스와 리소스 제한은 최소값과 최대값이 아닙니다! 요청된 리소스를 정의하면 애플리케이션이 문제 없이 실행될 수 있습니다.
4. 좋은 방법은 메모리 요청을 메모리 제한과 동일하게 설정하는 것입니다.
5. 알겠습니다. 설치를 요청했습니다. CPU <=1, 애플리케이션이 복잡한 계산을 수행하지 않는 경우.
6. 노드에서 사용할 수 있는 것보다 더 많은 리소스를 요청하면 포드가 해당 노드에 예약되지 않습니다.
7. 요청된 리소스의 정확한 양/리소스 제한을 확인하려면 부하 테스트 및 모니터링을 사용하십시오.

이 글이 자원 제한의 기본 개념을 이해하는 데 도움이 되기를 바랍니다. 그리고 당신은 이 지식을 당신의 업무에 적용할 수 있을 것입니다.

행운을 빕니다!

그 밖에 읽을 내용:

1. SRE 관찰 가능성: 네임스페이스 및 메트릭 구조.
2. Kubernetes를 위한 90개 이상의 유용한 도구: 배포, 관리, 모니터링, 보안 등.
3. Telegram의 Kubernetes 주변 채널.

출처 : habr.com