AWS에서 Kubernetes 클라우드 비용 절감

기사의 번역은 과정 시작 전날에 준비되었습니다. "쿠버네티스 기반 인프라 플랫폼".

Kubernetes로 작업할 때 클라우드 비용을 절약하는 방법은 무엇입니까? 단 하나의 올바른 솔루션은 없지만 이 문서에서는 리소스를 보다 효과적으로 관리하고 클라우드 컴퓨팅 비용을 줄이는 데 도움이 되는 여러 도구에 대해 설명합니다.

저는 AWS용 Kubernetes를 염두에 두고 이 기사를 작성했지만 다른 클라우드 제공업체에도 거의 동일한 방식으로 적용됩니다. 귀하의 클러스터에 이미 자동 확장이 구성되어 있다고 가정합니다(클러스터 자동 크기 조정기). 리소스를 제거하고 배포를 축소하면 작업자 노드(EC2 인스턴스)도 감소하는 경우에만 비용이 절약됩니다.

이 문서에서는 다음을 다룹니다.

• 사용하지 않는 리소스 정리(쿠베 관리인)
• 근무 외 시간에는 스케일링을 줄입니다(큐브 다운스케일러)
• 수평 자동 확장(HPA) 사용
• 과도한 자원 예약 감소 (kube-리소스-보고서, VPA)
• 스팟 인스턴스 사용

사용하지 않는 리소스 정리

빠르게 변화하는 환경에서 일하는 것은 좋습니다. 우리는 기술 조직을 원합니다 가속. 더 빠른 소프트웨어 제공은 더 많은 PR 배포, 미리 보기 환경, 프로토타입 및 분석 솔루션을 의미합니다. 모든 것이 Kubernetes에 배포됩니다. 테스트 배포를 수동으로 정리할 시간이 있는 사람은 누구입니까? 일주일이 지난 실험을 삭제하는 것을 잊어버리기 쉽습니다. 우리가 잊어버린 일로 인해 클라우드 요금이 상승하게 됩니다.

(헤닝 제이콥스:
지자:
(인용문) 코리 퀸:
오해: AWS 계정은 보유한 사용자 수에 따라 결정됩니다.
사실: AWS 점수는 보유한 엔지니어 수에 따라 결정됩니다.

Ivan Kurnosov (대답):
실제 사실: AWS 점수는 비활성화/삭제하는 것을 잊어버린 항목 수의 함수입니다.)

쿠버네티스 관리인 (kube-janitor)는 클러스터 정리에 도움이 됩니다. 관리인 구성은 전역 및 로컬 사용 모두에 유연합니다.

• 클러스터 전체 규칙은 PR/테스트 배포에 대한 최대 TTL(Time-to-Live)을 정의할 수 있습니다.
• 예를 들어 7일 후에 스파이크/프로토타입을 자동으로 제거하도록 개별 리소스에 janitor/ttl로 주석을 달 수 있습니다.

일반 규칙은 YAML 파일에 정의되어 있습니다. 해당 경로는 매개변수를 통해 전달됩니다. --rules-file kube-janitor에서. 다음은 모든 네임스페이스를 제거하는 예제 규칙입니다. -pr- 이틀 후 이름으로:

- id: cleanup-resources-from-pull-requests
  resources:
    - namespaces
  jmespath: "contains(metadata.name, '-pr-')"
  ttl: 2d

다음 예에서는 2020년의 모든 새로운 배포/StatefulSet에 대한 배포 및 StatefulSet 포드의 애플리케이션 라벨 사용을 규제하지만 동시에 일주일 동안 이 라벨 없이 테스트를 실행할 수 있도록 허용합니다.

- id: require-application-label
  # удалить deployments и statefulsets без метки "application"
  resources:
    - deployments
    - statefulsets
  # см. http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

kube-janitor를 실행하는 클러스터에서 30분 동안 시간 제한이 있는 데모를 실행합니다.

kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30m

비용 증가의 또 다른 원인은 영구 볼륨(AWS EBS)입니다. Kubernetes StatefulSet를 삭제해도 해당 영구 볼륨(PVC - PertantVolumeClaim)은 삭제되지 않습니다. 사용되지 않은 EBS 볼륨으로 인해 매월 수백 달러의 비용이 발생할 수 있습니다. Kubernetes Janitor에는 사용하지 않는 PVC를 정리하는 기능이 있습니다. 예를 들어, 이 규칙은 모듈에 의해 마운트되지 않고 StatefulSet 또는 CronJob에 의해 참조되지 않는 모든 PVC를 제거합니다.

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor는 클러스터를 깔끔하게 유지하고 클라우드 컴퓨팅 비용이 천천히 증가하는 것을 방지하는 데 도움을 줄 수 있습니다. 배포 및 구성 지침은 다음을 따르세요. 읽어보기 kube-janitor.

근무 외 시간에는 스케일링을 줄입니다.

테스트 및 스테이징 시스템은 일반적으로 업무 시간 동안에만 작동해야 합니다. 백오피스/관리 도구와 같은 일부 프로덕션 애플리케이션도 제한된 가용성만 필요하며 하룻밤 사이에 비활성화될 수 있습니다.

쿠버네티스 다운스케일러 (kube-downscaler)를 사용하면 사용자와 운영자가 근무 시간 외 시간에 시스템을 축소할 수 있습니다. 배포 및 StatefulSet는 복제본을 XNUMX개로 확장할 수 있습니다. CronJob이 일시 중지될 수 있습니다. Kubernetes Downscaler는 전체 클러스터, 하나 이상의 네임스페이스 또는 개별 리소스에 대해 구성됩니다. "유휴 시간" 또는 반대로 "근무 시간"을 설정할 수 있습니다. 예를 들어 밤과 주말 동안 확장을 최대한 줄이려면 다음을 수행하세요.

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # не отключать компоненты инфраструктуры
  - --exclude-namespaces=kube-system,infra
  # не отключать kube-downscaler, а также оставить Postgres Operator, чтобы исключенными БД можно было управлять
  - --exclude-deployments=kube-downscaler,postgres-operator
  - --default-uptime=Mon-Fri 08:00-20:00 Europe/Berlin
  - --include-resources=deployments,statefulsets,stacks,cronjobs
  - --deployment-time-annotation=deployment-time

다음은 주말에 클러스터 작업자 노드를 확장하는 그래프입니다.

~13개에서 4개의 작업자 노드로 축소하면 확실히 AWS 청구서에 눈에 띄는 차이가 있습니다.

하지만 클러스터 "다운타임" 동안 작업해야 하는 경우에는 어떻게 해야 합니까? downscaler/exclude: true 주석을 추가하여 특정 배포를 확장에서 영구적으로 제외할 수 있습니다. YYYY-MM-DD HH:MM(UTC) 형식의 절대 타임스탬프가 있는 downscaler/exclude-until 주석을 사용하여 배포를 일시적으로 제외할 수 있습니다. 필요한 경우 주석이 포함된 포드를 배포하여 전체 클러스터를 축소할 수 있습니다. downscaler/force-uptime예를 들어 nginx 공백을 실행하면 다음과 같습니다.

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # удалить развертывание через час
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

참조 읽어보기 kube-downscaler, 배포 지침 및 추가 옵션에 관심이 있는 경우.

수평 자동 확장 사용

많은 애플리케이션/서비스는 동적 로딩 패턴을 처리합니다. 때로는 모듈이 유휴 상태이고 때로는 전체 용량으로 작동합니다. 최대 피크 부하에 대처하기 위해 영구적인 포드 제품군을 운영하는 것은 경제적이지 않습니다. Kubernetes는 리소스 전반에 걸쳐 수평 자동 크기 조정을 지원합니다. 수평형PodAutoscaler (HPA). CPU 사용량은 확장에 대한 좋은 지표가 되는 경우가 많습니다.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 100
        type: Utilization

Zalando는 확장을 위해 사용자 정의 지표를 쉽게 연결할 수 있는 구성 요소를 만들었습니다. Kube 지표 어댑터 (kube-metrics-adapter)는 Pod의 수평 자동 확장을 위한 사용자 지정 및 외부 지표를 수집하고 제공할 수 있는 Kubernetes용 일반 지표 어댑터입니다. Prometheus 지표, SQS 대기열 및 기타 설정을 기반으로 한 확장을 지원합니다. 예를 들어 /metrics에서 JSON으로 애플리케이션 자체가 나타내는 사용자 정의 측정항목으로 배포를 확장하려면 다음을 사용합니다.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.<metricType>.<metricName>.<collectorName>/<configKey>
    metric-config.pods.requests-per-second.json-path/json-key: "$.http_server.rps"
    metric-config.pods.requests-per-second.json-path/path: /metrics
    metric-config.pods.requests-per-second.json-path/port: "9090"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: requests-per-second
      target:
        averageValue: 1k
        type: AverageValue

HPA를 사용한 수평 자동 확장 구성은 상태 비저장 서비스의 효율성을 높이기 위한 기본 작업 중 하나입니다. Spotify는 HPA에 대한 경험과 권장 사항을 담은 프레젠테이션을 제공합니다. 지갑이 아니라 배포를 확장하세요.

리소스 초과 예약 감소

Kubernetes 워크로드는 "리소스 요청"을 통해 CPU/메모리 요구 사항을 결정합니다. CPU 리소스는 가상 코어 또는 보다 일반적으로 "밀리코어"로 측정됩니다. 예를 들어 500m는 50% vCPU를 의미합니다. 메모리 리소스는 바이트 단위로 측정되며 500MB를 의미하는 500Mi와 같은 일반적인 접미사를 사용할 수 있습니다. 리소스는 작업자 노드에서 "잠금" 용량을 요청합니다. 즉, vCPU가 1000개인 노드에서 4m CPU 요청이 있는 포드는 다른 포드에서 사용할 수 있는 vCPU를 3개만 남겨둡니다. [1]

Slack(초과 예약) 요청된 리소스와 실제 사용량의 차이입니다. 예를 들어 2GiB의 메모리를 요청하지만 200MiB만 사용하는 포드에는 ~1,8GiB의 "초과" 메모리가 있습니다. 초과 비용이 발생합니다. 1GiB의 중복 메모리 비용은 대략 월 $10 정도라고 추정할 수 있습니다. [2]

Kubernetes 리소스 보고서 (kube-resource-report)는 초과 준비금을 표시하고 절감 가능성을 판단하는 데 도움이 될 수 있습니다.

Kubernetes 리소스 보고서 애플리케이션 및 명령별로 집계된 초과분을 표시합니다. 이를 통해 자원 수요를 줄일 수 있는 장소를 찾을 수 있습니다. 생성된 HTML 보고서는 리소스 사용량에 대한 스냅샷만 제공합니다. 적절한 리소스 요청을 결정하려면 시간 경과에 따른 CPU/메모리 사용량을 살펴봐야 합니다. 다음은 "일반적인" CPU 사용량이 많은 서비스에 대한 Grafana 차트입니다. 모든 포드는 요청된 3개의 CPU 코어보다 훨씬 적은 양을 사용하고 있습니다.

CPU 요청을 3000m에서 ~400m로 줄이면 다른 워크로드를 위한 리소스가 확보되고 클러스터가 더 작아질 수 있습니다.

"EC2 인스턴스의 평균 CPU 사용량은 한 자릿수 백분율 범위에 머무는 경우가 많습니다." 코리 퀸이 쓴다. EC2의 경우 적절한 크기를 추정하는 것은 잘못된 결정일 수 있습니다.YAML 파일에서 일부 Kubernetes 리소스 쿼리를 변경하는 것은 쉽고 막대한 비용 절감 효과를 가져올 수 있습니다.

하지만 우리는 정말로 사람들이 YAML 파일의 값을 변경하기를 원합니까? 아니요, 기계가 훨씬 더 잘할 수 있습니다! 쿠버네티스 수직형 포드 자동 확장 처리 (VPA)가 바로 그 일을 합니다. 즉, 워크로드에 따라 리소스 요청과 제약 조건을 조정합니다. 다음은 시간 경과에 따라 VPA가 조정한 Prometheus CPU 요청(가는 파란색 선) 그래프의 예시입니다.

Zalando는 모든 클러스터에서 VPA를 사용합니다. 인프라 구성요소용. 중요하지 않은 애플리케이션도 VPA를 사용할 수 있습니다.

미역취 속의 일종 Fairwind의는 네임스페이스의 각 배포에 대해 VPA를 생성한 다음 대시보드에 VPA 권장 사항을 표시하는 도구입니다. 이는 개발자가 애플리케이션에 대한 올바른 CPU/메모리 요청을 설정하는 데 도움이 될 수 있습니다.

작게 썼어요 VPA에 관한 블로그 게시물 2019년에 그리고 최근에는 CNCF 최종 사용자 커뮤니티에서 VPA 문제를 논의했습니다..

EC2 스팟 인스턴스 사용

마지막으로 스팟 인스턴스를 Kubernetes 작업자 노드로 사용하면 AWS EC2 비용을 줄일 수 있습니다. [3]. 스팟 인스턴스는 온디맨드 가격에 비해 최대 90% 할인된 가격으로 제공됩니다. EC2 스팟에서 Kubernetes를 실행하는 것은 좋은 조합입니다. 더 높은 가용성을 위해 여러 가지 다른 인스턴스 유형을 지정해야 합니다. 즉, 동일하거나 더 낮은 가격으로 더 큰 노드를 얻을 수 있고 증가된 용량을 컨테이너화된 Kubernetes 워크로드에서 사용할 수 있습니다.

EC2 Spot에서 Kubernetes를 실행하는 방법은 무엇입니까? 여러 가지 옵션이 있습니다. SpotInst(현재는 "Spot"이라고 함. 이유는 묻지 마세요)와 같은 타사 서비스를 사용하거나 ASG(Spot AutoScalingGroup)를 클러스터에 추가하면 됩니다. 예를 들어 다음은 여러 인스턴스 유형이 있는 "용량 최적화" Spot ASG에 대한 CloudFormation 코드 조각입니다.

MySpotAutoScalingGroup:
 Properties:
   HealthCheckGracePeriod: 300
   HealthCheckType: EC2
   MixedInstancesPolicy:
     InstancesDistribution:
       OnDemandPercentageAboveBaseCapacity: 0
       SpotAllocationStrategy: capacity-optimized
     LaunchTemplate:
       LaunchTemplateSpecification:
         LaunchTemplateId: !Ref LaunchTemplate
         Version: !GetAtt LaunchTemplate.LatestVersionNumber
       Overrides:
         - InstanceType: "m4.2xlarge"
         - InstanceType: "m4.4xlarge"
         - InstanceType: "m5.2xlarge"
         - InstanceType: "m5.4xlarge"
         - InstanceType: "r4.2xlarge"
         - InstanceType: "r4.4xlarge"
   LaunchTemplate:
     LaunchTemplateId: !Ref LaunchTemplate
     Version: !GetAtt LaunchTemplate.LatestVersionNumber
   MinSize: 0
   MaxSize: 100
   Tags:
   - Key: k8s.io/cluster-autoscaler/node-template/label/aws.amazon.com/spot
     PropagateAtLaunch: true
     Value: "true"

Kubernetes에서 Spot 사용에 대한 몇 가지 참고 사항:

• 예를 들어 인스턴스가 중지될 때 노드를 병합하여 스팟 종료를 처리해야 합니다.
• Zalando는 다음을 사용합니다. 포크 노드 풀 우선순위에 따른 공식 클러스터 자동 확장
• 스팟 노드 강제로 할 수 있다 Spot에서 실행할 워크로드의 "등록"을 수락합니다.

개요

제시된 도구 중 일부가 클라우드 비용을 줄이는 데 유용하길 바랍니다. 기사 내용의 대부분은 다음에서도 찾을 수 있습니다. YouTube와 슬라이드의 DevOps Gathering 2019에서 제가 한 이야기.

Kubernetes에서 클라우드 비용을 절약하기 위한 모범 사례는 무엇입니까? 다음 주소로 알려주세요. 트위터(@try_Exception_).

[1] 실제로 예약된 시스템 리소스로 인해 노드의 처리량이 감소하므로 3개 미만의 vCPU를 계속 사용할 수 있습니다. Kubernetes는 물리적 노드 용량과 "프로비저닝된" 리소스를 구별합니다(노드 할당 가능).

[2] 계산 예: 5GiB 메모리를 갖춘 m8.large 인스턴스 84개는 월 ~$1 ​​​​(eu-central-1, On-Demand)입니다. 즉, 8/10 노드를 차단하는 데 드는 비용은 대략 월 $XNUMX입니다.

[3] 예약 인스턴스, Savings Plan 등 EC2 청구서를 줄일 수 있는 방법은 다양합니다. 여기서는 해당 주제를 다루지 않겠지만 꼭 살펴보아야 합니다!

과정에 대해 자세히 알아보세요.

출처 : habr.com