XNUMX가지 Kubernetes 성능 팁

모두 안녕! 제 이름은 Oleg Sidorenkov이고 DomClick에서 인프라 팀 리더로 일하고 있습니다. 우리는 판매용 큐브를 XNUMX년 이상 사용해 왔으며 이 기간 동안 다양한 흥미로운 순간을 경험했습니다. 오늘 저는 올바른 접근 방식으로 클러스터의 바닐라 쿠버네티스에서 훨씬 더 많은 성능을 끌어낼 수 있는 방법을 알려드리겠습니다. 준비 꾸준한 이동!

여러분 모두 Kubernetes가 컨테이너 오케스트레이션을 위한 확장 가능한 오픈 소스 시스템이라는 것을 잘 알고 계실 것입니다. 또는 서버 환경에서 마이크로서비스의 수명 주기를 관리하여 마술을 부리는 5개의 바이너리. 또한 이것은 다양한 작업에 대한 최대 사용자 정의를 위해 레고 생성자처럼 조립할 수 있는 상당히 유연한 도구입니다.

그리고 모든 것이 괜찮은 것 같습니다. 장작을 화실에 넣는 것처럼 서버를 클러스터에 던지고 슬픔을 모릅니다. 그러나 환경을 생각한다면 "어떻게 스토브에 불을 피우고 숲을 후회할 수 있습니까? "라고 생각할 것입니다. 즉, 인프라를 개선하고 비용을 절감하는 방법을 찾는 방법입니다.

1. 팀 및 애플리케이션 리소스 추적

가장 진부하지만 효과적인 방법 중 하나는 요청/제한을 도입하는 것입니다. 애플리케이션을 네임스페이스별로, 네임스페이스를 개발 팀별로 구분합니다. 프로세서 시간, 메모리, 임시 스토리지 소비에 대한 값을 배포하기 전에 애플리케이션을 설정하십시오.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

경험상 우리는 결론에 도달했습니다. 한도에서 요청을 두 배 이상 부풀릴 가치가 없습니다. 클러스터 크기는 요청을 기반으로 계산되며 애플리케이션을 리소스 차이(예: 5-10배)로 설정한 경우 노드가 포드로 채워지고 갑자기 로드가 수신될 때 노드에 어떤 일이 발생할지 상상해 보세요. 좋은 건 없어. 최소한 스로틀링하고 최대로 작업자에게 작별 인사를 하고 팟(Pod)이 이동하기 시작한 후 나머지 노드에서 주기적 로드를 얻습니다.

게다가 도움을 받아 limitranges 최소, 최대 및 기본값과 같이 시작할 때 컨테이너의 리소스 값을 설정할 수 있습니다.

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

하나의 명령이 클러스터의 모든 리소스를 사용할 수 없도록 네임스페이스 리소스를 제한해야 합니다.

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

설명에서 알 수 있듯이 resourcequotas, ops 명령이 다른 10 cpu를 소비하는 팟(Pod)을 배치하려는 경우 스케줄러는 이를 허용하지 않고 오류를 발행합니다.

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

유사한 문제를 해결하기 위해 예를 들어 다음과 같은 도구를 작성할 수 있습니다. 이, 명령 리소스의 상태를 저장하고 커밋할 수 있습니다.

2. 최상의 파일 저장소 선택

여기서는 Kubernetes 작업자 노드의 영구 볼륨 및 디스크 하위 시스템에 대한 주제를 다루고자 합니다. 아무도 프로덕션에서 HDD의 "Cube"를 사용하지 않기를 바랍니다. 하지만 때로는 일반 SSD로도 충분하지 않습니다. 우리는 로그가 I/O 작업으로 디스크를 죽이는 문제에 직면했으며 여기에는 해결책이 많지 않습니다.

• 고성능 SSD를 사용하거나 NVMe로 전환하십시오(자체 하드웨어를 관리하는 경우).

• 로깅 수준을 낮춥니다.

• 디스크를 강간하는 포드의 "스마트" 밸런싱을 수행합니다(podAntiAffinity).

위의 스크린샷은 access_logs가 활성화된 경우(~12k 로그/초) 디스크가 있는 nginx-ingress-controller에서 발생하는 상황을 보여줍니다. 물론 이러한 상태는 이 노드의 모든 애플리케이션 성능 저하로 이어질 수 있습니다.

PV에 관해서는 아쉽게도 모든 것을 시도하지 않았습니다. 종 영구 볼륨. 자신에게 가장 적합한 옵션을 사용하십시오. 역사적으로 우리나라에서는 서비스의 일부에 RWX 볼륨이 필요한 일이 있었으며 오래 전에 이 작업을 위해 NFS 스토리지를 사용하기 시작했습니다. 싸고 ... 충분합니다. 물론 우리는 그와 함께 똥을 먹었습니다. 건강하지만 그를 조정하는 방법을 배웠고 그의 머리는 더 이상 아프지 않습니다. 그리고 가능하면 S3 객체 스토리지로 전환하십시오.

3. 최적화된 이미지 구축

Kubernetes가 이미지를 더 빠르게 가져오고 더 효율적으로 실행할 수 있도록 컨테이너 최적화 이미지를 사용하는 것이 가장 좋습니다. 

최적화는 이미지가 다음을 의미합니다.

• 하나의 응용 프로그램만 포함하거나 하나의 기능만 수행합니다.

• 작은 크기, 큰 이미지는 네트워크를 통해 더 잘 전송되지 않기 때문입니다.

• 다운타임 발생 시 Kubernetes가 조치를 취하는 데 사용할 수 있는 상태 및 준비 엔드포인트 보유

• 구성 오류에 더 강한 컨테이너 친화적인 운영 체제(예: Alpine 또는 CoreOS)를 사용합니다.

• 함께 제공되는 소스가 아닌 컴파일된 애플리케이션만 배포할 수 있도록 다단계 빌드를 사용합니다.

즉석에서 이미지를 확인하고 최적화할 수 있는 많은 도구와 서비스가 있습니다. 항상 최신 상태로 안전하게 유지하는 것이 중요합니다. 결과적으로 다음을 얻습니다.

1. 전체 클러스터의 네트워크 부하 감소.

2. 컨테이너 시작 시간이 감소했습니다.

3. 전체 Docker 레지스트리의 더 작은 크기.

4. DNS 캐시 사용

높은 부하에 대해 이야기하면 클러스터의 DNS 시스템을 조정하지 않으면 삶이 매우 형편 없습니다. 옛날 옛적에 Kubernetes 개발자는 kube-dns 솔루션을 지원했습니다. 우리나라에서도 구현되었지만이 소프트웨어는 특별히 조정되지 않았고 필요한 성능을 제공하지 못했지만 작업은 간단 해 보입니다. 그런 다음 우리가 전환하고 슬픔을 알지 못하는 coredns가 나타 났으며 나중에 K8s의 기본 DNS 서비스가되었습니다. 어느 순간 DNS 시스템까지 40만 rps까지 성장했는데 이 솔루션도 만만치 않았다. 그런데 운좋게 Nodelocaldns가 나오게 되었고, 일명 노드 로컬 캐시, 일명 노드 로컬 DNS 캐시.

왜 우리는 그것을 사용하고 있습니까? Linux 커널에는 UDP를 통한 conntrack NAT를 통한 다중 액세스가 conntrack 테이블에 쓰기 위한 경쟁 조건으로 이어지고 NAT를 통한 트래픽의 일부가 손실되는 버그가 있습니다(서비스를 통한 각 이동은 NAT임). Nodelocaldns는 NAT를 제거하고 업스트림 DNS에 대한 TCP 연결로 업그레이드하고 업스트림 DNS 쿼리를 로컬로 캐싱(짧은 5초 네거티브 캐시 포함)하여 이 문제를 해결합니다.

5. 포드를 수평 및 수직으로 자동 확장

모든 마이크로서비스가 XNUMX~XNUMX배의 부하 증가에 대비하고 있다고 자신 있게 말할 수 있습니까? 애플리케이션에 리소스를 적절하게 할당하는 방법은 무엇입니까? 워크로드를 초과하여 몇 개의 포드를 실행하는 것은 중복될 수 있으며 연속적으로 유지하면 서비스에 대한 트래픽이 갑자기 증가하여 다운타임이 발생할 위험이 있습니다. 황금 평균은 다음과 같은 서비스와 같은 곱셈의 주문을 달성하는 데 도움이 됩니다. 수평형 포드 자동 크기 조정기 и 수직형 포드 자동 확장 처리.

VPA 실제 사용량에 따라 팟(Pod)에 있는 컨테이너의 요청/제한을 자동으로 높일 수 있습니다. 어떻게 유용할 수 있습니까? 어떤 이유로 수평으로 확장할 수 없는 Pod가 있는 경우(완전히 신뢰할 수 없음) VPA를 신뢰하여 해당 리소스를 변경할 수 있습니다. 그 기능은 메트릭 서버의 과거 및 현재 데이터를 기반으로 하는 추천 시스템이므로 요청/제한을 자동으로 변경하지 않으려면 컨테이너에 대한 권장 리소스를 모니터링하고 설정을 최적화하여 CPU 및 메모리를 절약할 수 있습니다. 클러스터에서.

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231에서 가져온 이미지

Kubernetes의 스케줄러는 항상 요청을 기반으로 합니다. 어떤 값을 입력하든 스케줄러는 이를 기반으로 적합한 노드를 찾습니다. 제한 값은 팟(Pod)을 제한하거나 종료할 시기를 알기 위해 kublet에 필요합니다. 유일한 중요한 매개변수는 요청 값이기 때문에 VPA가 이를 사용합니다. 애플리케이션을 수직으로 확장할 때마다 어떤 요청이 되어야 하는지 정의합니다. 그러면 한계는 어떻게 될까요? 이 매개변수도 비례적으로 조정됩니다.

예를 들어 일반적인 포드 설정은 다음과 같습니다.

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

추천 엔진은 애플리케이션이 제대로 실행되기 위해 300m CPU와 500Mi가 필요하다고 판단합니다. 다음 설정을 얻게 됩니다.

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

위에서 언급한 바와 같이 이는 매니페스트의 요청/제한 비율을 기반으로 하는 비례 조정입니다.

• CPU: 200m → 300m: 비율 1:1.75;

• 메모리: 250Mi → 500Mi: 1:2 비율.

...에 관하여 고전력 증폭기, 작동 메커니즘이 더 투명합니다. 프로세서 및 메모리와 같은 메트릭에 대한 임계값이 설정되며, 모든 복제본의 평균이 임계값을 초과하면 값이 임계값 아래로 떨어지거나 최대 복제본 수에 도달할 때까지 애플리케이션이 +1 pod로 확장됩니다.

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231에서 가져온 이미지

CPU 및 메모리와 같은 일반적인 메트릭 외에도 사용자 지정 Prometheus 메트릭에 대한 임계값을 설정하고 이것이 애플리케이션을 확장할 시기를 결정하는 가장 정확한 방법이라고 생각하는 경우 작업할 수 있습니다. 애플리케이션이 지정된 메트릭 임계값 아래로 안정화되면 HPA는 최소 복제본 수로 또는 로드가 지정된 임계값을 충족할 때까지 포드를 축소하기 시작합니다.

6. Node Affinity와 Pod Affinity를 잊지 마세요

모든 노드가 동일한 하드웨어에서 실행되는 것은 아니며 모든 포드가 컴퓨팅 집약적인 애플리케이션을 실행할 필요는 없습니다. Kubernetes를 사용하면 다음을 사용하여 노드 및 포드의 전문화를 지정할 수 있습니다. 노드 선호도 и 포드 선호도.

컴퓨팅 집약적인 작업에 적합한 노드가 있는 경우 최대 효율성을 위해 애플리케이션을 적절한 노드에 바인딩하는 것이 좋습니다. 이렇게 하려면 다음을 사용하십시오. nodeSelector 노드 레이블.

두 개의 노드가 있다고 가정해 보겠습니다. CPUType=HIGHFREQ 많은 수의 빠른 코어, 다른 하나는 MemoryType=HIGHMEMORY 더 많은 메모리와 더 빠른 성능. 가장 쉬운 방법은 포드 배포를 노드에 할당하는 것입니다. HIGHFREQ섹션에 추가하여 spec 다음과 같은 선택기:

…
nodeSelector:
	CPUType: HIGHFREQ

이를 수행하는 더 비용이 많이 들고 구체적인 방법은 다음을 사용하는 것입니다. nodeAffinity 현장에서 affinity 섹션 spec. 두 가지 옵션이 있습니다.

• requiredDuringSchedulingIgnoredDuringExecution: 하드 설정(스케줄러는 특정 노드에만 포드를 배포합니다(다른 노드에는 없음)).

• preferredDuringSchedulingIgnoredDuringExecution: 소프트 설정(스케줄러는 특정 노드에 배포를 시도하고 실패할 경우 다음 사용 가능한 노드에 배포를 시도합니다).

예를 들어 노드 레이블을 관리하기 위한 특정 구문을 지정할 수 있습니다. In, NotIn, Exists, DoesNotExist, Gt 또는 Lt. 그러나 긴 레이블 목록의 복잡한 방법은 중요한 상황에서 의사 결정 속도를 늦출 수 있음을 기억하십시오. 즉, 지나치게 복잡하게 만들지 마십시오.

위에서 언급했듯이 Kubernetes를 사용하면 현재 포드의 바인딩을 설정할 수 있습니다. 즉, 동일한 가용 영역(클라우드 관련) 또는 노드에서 특정 포드가 다른 포드와 함께 작동하도록 할 수 있습니다.

В podAffinity 여백 affinity 섹션 spec 의 경우와 동일한 필드를 사용할 수 있습니다. nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. 유일한 차이점은 matchExpressions 해당 레이블이 있는 포드를 이미 실행 중인 노드에 포드를 바인딩합니다.

Kubernetes는 필드를 제공합니다. podAntiAffinity반대로 특정 포드가 있는 노드에 포드를 바인딩하지 않습니다.

표현식 정보 nodeAffinity 동일한 조언이 제공될 수 있습니다. 규칙을 단순하고 논리적으로 유지하고 복잡한 규칙 세트로 포드 사양을 과부하하지 마십시오. 클러스터의 조건과 일치하지 않는 규칙을 생성하여 스케줄러에 추가 부하를 가하고 전반적인 성능을 저하시키는 것은 매우 쉽습니다.

7. 오염 및 허용

스케줄러를 관리하는 다른 방법이 있습니다. 수백 개의 노드와 수천 개의 마이크로 서비스가 있는 대규모 클러스터가 있는 경우 특정 포드가 특정 노드에서 호스팅되는 것을 방지하기가 매우 어렵습니다.

오염의 메커니즘(금지 규칙)이 이에 도움이 됩니다. 예를 들어 특정 시나리오에서 특정 노드가 포드를 실행하지 못하도록 할 수 있습니다. 특정 노드에 오염을 적용하려면 옵션을 사용하십시오. taint kubectl에서. 키와 값을 지정한 다음 다음과 같이 오염 NoSchedule 또는 NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

오염 메커니즘이 세 가지 주요 효과를 지원한다는 점도 주목할 가치가 있습니다. NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule 포드 사양에 해당 항목이 있을 때까지 tolerations, 노드에 배포할 수 없습니다(이 예에서는 node10).

• PreferNoSchedule - 단순화된 버전 NoSchedule. 이 경우 스케줄러는 일치하는 항목이 없는 포드를 할당하지 않으려고 합니다. tolerations 그러나 이것은 하드 제한이 아닙니다. 클러스터에 리소스가 없으면 포드가 이 노드에 배포되기 시작합니다.

• NoExecute - 이 효과는 일치하는 항목이 없는 포드의 즉각적인 대피를 트리거합니다. tolerations.

흥미롭게도 이 동작은 허용 메커니즘을 사용하여 실행 취소할 수 있습니다. 이는 "금지된" 노드가 있고 인프라 서비스만 배치해야 하는 경우에 편리합니다. 그것을하는 방법? 적절한 허용 오차가 있는 포드만 허용합니다.

포드 사양은 다음과 같습니다.

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

이것은 다음에 재배포하는 동안 포드가 정확히 이 노드에 도달한다는 것을 의미하지 않습니다. 이것은 노드 선호도 메커니즘이 아니며 nodeSelector. 그러나 여러 기능을 결합하면 매우 유연한 스케줄러 설정을 얻을 수 있습니다.

8. Pod 배포 우선 순위 설정

포드-노드 바인딩을 구성했다고 해서 모든 포드가 동일한 우선 순위로 처리되어야 한다는 의미는 아닙니다. 예를 들어 일부 포드를 다른 포드보다 먼저 배포할 수 있습니다.

Kubernetes는 Pod 우선 순위 및 선점을 설정하는 다양한 방법을 제공합니다. 설정은 다음과 같은 여러 부분으로 구성됩니다. PriorityClass 및 필드 설명 priorityClassName 포드 사양에서. 예를 고려하십시오.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

우리는 생성 PriorityClass, 이름, 설명 및 값을 지정합니다. 더 높이 value, 우선순위가 높을수록. 값은 32보다 작거나 같은 1비트 정수일 수 있습니다. 더 높은 값은 일반적으로 선점할 수 없는 미션 크리티컬 시스템 포드용으로 예약되어 있습니다. 제거는 우선 순위가 높은 포드가 돌릴 곳이 없는 경우에만 발생하며 특정 노드의 일부 포드가 제거됩니다. 이 메커니즘이 너무 딱딱한 경우 옵션을 추가할 수 있습니다. preemptionPolicy: Never그러면 선점이 없을 것이며 포드는 대기열의 첫 번째가 되고 스케줄러가 사용 가능한 리소스를 찾을 때까지 기다립니다.

다음으로 이름을 지정하는 포드를 만듭니다. priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

원하는 만큼 우선순위 클래스를 만들 수 있지만, 이것에 휩쓸리지 않는 것이 좋습니다(예: 낮음, 중간 및 높음 우선순위로 제한).

따라서 필요한 경우 nginx-ingress-controller, coredns 등과 같은 중요한 서비스 배포의 효율성을 높일 수 있습니다.

9. ETCD 클러스터 최적화

ETCD는 전체 클러스터의 두뇌라고 할 수 있습니다. "Cube"의 작업 속도가 데이터베이스에 달려 있기 때문에 이 데이터베이스의 작업을 높은 수준으로 유지하는 것이 매우 중요합니다. 상당히 표준적이며 동시에 좋은 솔루션은 kube-apiserver에 대한 지연을 최소화하기 위해 마스터 노드에 ETCD 클러스터를 유지하는 것입니다. 이것이 가능하지 않다면 ETCD를 참가자들 사이에 충분한 대역폭을 가지고 가능한 한 가깝게 배치하십시오. 또한 클러스터에 해를 끼치지 않고 ETCD에서 얼마나 많은 노드가 떨어질 수 있는지 주의하십시오.

클러스터의 참가자 수가 과도하게 증가하면 성능이 저하되는 대신 내결함성이 증가할 수 있으므로 모든 것이 적절해야 합니다.

서비스 설정에 대해 이야기하면 몇 가지 권장 사항이 있습니다.

1. 클러스터 크기에 따라 좋은 하드웨어를 갖추십시오(다음을 읽을 수 있음). 여기에).

2. 한 쌍의 DC 또는 네트워크와 디스크 사이에 클러스터를 분산시킨 경우 몇 가지 매개변수를 조정하여 원하는 대로 남겨둡니다(읽을 수 있음). 여기에).

결론

이 문서는 우리 팀이 준수하려고 하는 사항을 설명합니다. 이것은 작업에 대한 단계별 설명이 아니라 클러스터의 오버헤드를 최적화하는 데 유용할 수 있는 옵션입니다. 각 클러스터는 고유한 방식으로 고유하며 조정 솔루션은 크게 다를 수 있으므로 Kubernetes 클러스터를 모니터링하는 방법, 성능을 개선하는 방법에 대한 피드백을 받는 것이 흥미로울 것입니다. 의견에 귀하의 경험을 공유하십시오. 아는 것이 흥미로울 것입니다.

출처 : habr.com