Karpenter

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Karpenter는 Kubernetes 클러스터 내에서 노드 수명 주기 관리를 개선하도록 설계된 오픈 소스 프로젝트입니다. 포드의 특정 일정 요구 사항에 따라 노드의 프로비저닝 및 프로비저닝 해제를 자동화하여 효율적인 규모 조정 및 비용 최적화를 지원합니다. 주요 기능은 다음과 같습니다.

Karpenter를 사용하면 테인트, 레이블, 요구 사항(인스턴스 유형, 영역 등) 및 총 프로비저닝된 리소스에 대한 제한과 같은 노드 프로비저닝에 대한 제약 조건으로 NodePools를 정의할 수 있습니다. 워크로드를 배포할 때 리소스 요청/제한, 노드 선택기, 노드/포드 친화도, 허용 오차 및 토폴로지 분산 제약 조건과 같은 다양한 예약 제약 조건을 포드 사양에 지정할 수 있습니다. 그러면 Karpenter는 이러한 사양에 따라 적절한 크기의 노드를 프로비저닝합니다.

Karpenter를 사용하는 이유

Karpenter를 시작하기 전에 Kubernetes 사용자는 주로 Amazon EC2 Auto Scaling 그룹과 Kubernetes Cluster Autoscaler(CAS)를 사용하여 클러스터의 컴퓨팅 용량을 동적으로 조정했습니다. Karpenter를 사용하면 Karpenter로 얻을 수 있는 유연성과 다양성을 달성하기 위해 수십 개의 노드 그룹을 생성할 필요가 없습니다. CAS와 달리 Karpenter는 Kubernetes 버전과 긴밀하게 결합되지 않으며 AWS와 Kubernetes APIs 간에 점프할 필요가 없습니다.

Karpenter는 인스턴스 오케스트레이션 책임을 단일 시스템 내에 통합하며, 이는 더 간단하고 안정적이며 클러스터를 인식합니다. Karpenter는 다음과 같은 간소화된 방법을 제공하여 Cluster Autoscaler에서 발생하는 몇 가지 문제를 극복하도록 설계되었습니다.

Karpenter 사용에 대한 자세한 내용과 설명서는 karpenter.sh://https://https://https://https://https://https://https://https://https://https://https://https://https

추천

모범 사례는 Karpenter 자체, NodePools 및 포드 예약에 대한 섹션으로 나뉩니다.

Karpenter 모범 사례

다음 모범 사례에서는 Karpenter 자체와 관련된 주제를 다룹니다.

프로덕션 클러스터에서 AMIs 잠금

Karpenter가 프로덕션 클러스터에 사용하는 잘 알려진 Amazon Machine Image(AMIs 고정시키는 것이 좋습니다. 별칭이 로 설정된 amiSelector 상태에서 @latest를 사용하거나 테스트되지 않은 AMIs가 릴리스될 때 배포되는 다른 방법을 사용하면 프로덕션 클러스터에서 워크로드 장애 및 가동 중지가 발생할 위험이 있습니다. 따라서 비프로덕션 클러스터에서 최신 버전을 테스트하는 동안 프로덕션 클러스터에 대해 테스트된 작동 버전의 AMIs를 고정시키는 것이 좋습니다. 예를 들어 다음과 같이 NodeClass에서 별칭을 설정할 수 있습니다.

amiSelectorTerms
  - alias: al2023@v20240807

Karpenter에서 AMIs 관리하고 고정하는 방법에 대한 자세한 내용은 Karpenter 설명서의 AMIs 관리를 참조하세요.

용량 요구 사항이 변화하는 워크로드에 Karpenter 사용

Karpenter는 Autoscaling Groups(ASGs) 및 Managed Node Groups(MNG)보다 Kubernetes 네이티브 APIs에 더 가까운 규모 조정 관리를 제공합니다. https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/ MNGs ASGs 및 MNGs는 EC2 CPU 부하와 같은 AWS 수준 지표를 기반으로 조정이 트리거되는 AWS 네이티브 추상화입니다. Cluster Autoscaler는 Kubernetes 추상화를 AWS 추상화에 연결하지만 특정 가용 영역에 대한 예약과 같은 유연성 때문에 약간의 유연성을 잃습니다.

Karpenter는 AWS 추상화 계층을 제거하여 일부 유연성을 Kubernetes에 직접 제공합니다. Karpenter는 수요가 많고 급증하는 기간이 발생하거나 컴퓨팅 요구 사항이 다양한 워크로드가 있는 클러스터에 가장 적합합니다. MNGs 및 ASGs는 보다 정적이고 일관된 경향이 있는 워크로드를 실행하는 클러스터에 적합합니다. 요구 사항에 따라 동적 및 정적 관리형 노드를 혼합하여 사용할 수 있습니다.

다음과 같은 경우 다른 Auto Scaling 프로젝트를 고려하세요.

Karpenter에서 아직 개발 중인 기능이 필요합니다. Karpenter는 비교적 새로운 프로젝트이므로 Karpenter에 아직 속하지 않은 기능이 필요한 경우 당분간 다른 오토 스케일링 프로젝트를 고려하세요.

EKS Fargate 또는 노드 그룹에 속하는 작업자 노드에서 Karpenter 컨트롤러 실행

Karpenter는 [Helm chart](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#4-install-karpenter://)를 사용하여 설치됩니다. Helm 차트는 Karpenter 컨트롤러와 Webhook 포드를 배포로 설치합니다. 배포는 컨트롤러를 클러스터 조정에 사용하기 전에 실행해야 합니다. 작업자 노드가 하나 이상 있는 작은 노드 그룹을 하나 이상 사용하는 것이 좋습니다. 또는 karpenter 네임스페이스에 대한 Fargate 프로파일을 생성하여 EKS Fargate에서 이러한 포드를 실행할 수 있습니다. 이렇게 하면이 네임스페이스에 배포된 모든 포드가 EKS Fargate에서 실행됩니다. Karpenter에서 관리하는 노드에서는 Karpenter를 실행하지 마십시오.

Karpenter를 사용하는 사용자 지정 시작 템플릿은 지원되지 않습니다.

v1 APIs. 사용자 지정 사용자 데이터를 사용하거나 EC2NodeClass에서 사용자 지정 AMIs를 직접 지정할 수 있습니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 NodeClasses에서 확인할 수 있습니다.

워크로드에 맞지 않는 인스턴스 유형 제외

클러스터에서 실행되는 워크로드에 필요하지 않은 경우 node.kubernetes.io/instance-type 키가 있는 특정 인스턴스 유형을 제외하는 것이 좋습니다.

다음 예제에서는 대용량 Graviton 인스턴스 프로비저닝을 방지하는 방법을 보여줍니다.

- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
  - m6g.16xlarge
  - m6gd.16xlarge
  - r6g.16xlarge
  - r6gd.16xlarge
  - c6g.16xlarge

스팟 사용 시 중단 처리 활성화

Karpenter는 기본 중단 처리를 지원하며 스팟 인스턴스 중단, 예약된 유지 관리 이벤트, 워크로드를 방해할 수 있는 인스턴스 종료/중지 이벤트와 같은 자발적 중단 이벤트를 처리할 수 있습니다. Karpenter는 노드에 대해 이러한 이벤트를 감지하면 영향을 받는 노드를 사전에 자동으로 테인트, 드레이닝 및 종료하여 중단 전에 워크로드를 정상적으로 정리합니다. 2분 전 공지가 있는 스팟 중단의 경우 Karpenter는 인스턴스를 회수하기 전에 포드를 이동할 수 있도록 새 노드를 빠르게 시작합니다. 중단 처리를 활성화하려면이 용도로 프로비저닝된 SQS 대기열의 이름으로 --interruption-queue CLI 인수를 구성합니다. 여기에 설명된 대로 노드 종료 핸들러와 함께 Karpenter 중단 처리를 사용하지 않는 것이 좋습니다.

체크포인트 또는 기타 형태의 정상적인 드레이닝이 필요하고 종료하기 전에 2분이 필요한 포드는 클러스터에서 Karpenter 중단 처리를 활성화해야 합니다.

아웃바운드 인터넷 액세스가 없는 Amazon EKS 프라이빗 클러스터

인터넷 경로 없이 EKS 클러스터를 VPC에 프로비저닝할 때는 EKS 설명서에 표시된 프라이빗 클러스터 요구 사항에 따라 환경을 구성해야 합니다. 또한 VPC에 STS VPC 리전 엔드포인트를 생성했는지 확인해야 합니다. 그렇지 않으면 아래에 표시된 것과 유사한 오류가 표시됩니다.

{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts.<region>.amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}

Karpenter Controller는 서비스 계정에 대한 IAM 역할(IRSA)을 사용하기 때문에 프라이빗 클러스터에서 이러한 변경이 필요합니다. IRSA로 구성된 포드는 AWS Security Token Service(AWS STS) API를 호출하여 자격 증명을 획득합니다. 아웃바운드 인터넷 액세스가 없는 경우 VPC에서 AWS STS VPC 엔드포인트를 생성하고 사용해야 합니다.

또한 프라이빗 클러스터에서는 SSM에 대한 VPC 엔드포인트를 생성해야 합니다. Karpenter가 새 노드를 프로비저닝하려고 하면 시작 템플릿 구성과 SSM 파라미터를 쿼리합니다. VPC에 SSM VPC 엔드포인트가 없는 경우 다음 오류가 발생합니다.

{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm.<region>.amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}

Price List Query API 에는 VPC 엔드포인트가 없습니다. 따라서 시간 경과에 따라 요금 데이터가 오래됩니다. Karpenter는 바이너리에 온디맨드 요금 데이터를 포함시켜이 문제를 해결하지만 Karpenter가 업그레이드될 때만 해당 데이터를 업데이트합니다. 요금 데이터에 대한 요청이 실패하면 다음과 같은 오류 메시지가 표시됩니다.

{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}

완전 프라이빗 EKS 클러스터에서 Karpenter를 사용하고 생성할 VPC 엔드포인트를 알아보려면이 설명서를 참조하세요.

NodePools 생성

다음 모범 사례에서는 NodePools 생성과 관련된 주제를 다룹니다.

다음과 같은 경우 여러 NodePools를 생성합니다.

서로 다른 팀이 클러스터를 공유하고 서로 다른 작업자 노드에서 워크로드를 실행해야 하거나 OS 또는 인스턴스 유형 요구 사항이 다른 경우 여러 NodePools 생성합니다. 예를 들어 한 팀은 Bottlerocket을 사용하고 다른 팀은 Amazon Linux를 사용할 수 있습니다. 마찬가지로 한 팀은 다른 팀에게 필요하지 않은 비용이 많이 드는 GPU 하드웨어에 액세스할 수 있습니다. 여러 NodePools를 사용하면 각 팀이 가장 적합한 자산을 사용할 수 있습니다.

상호 배타적이거나 가중치가 부여된 NodePools 생성

일관된 예약 동작을 제공하기 위해 상호 배타적이거나 가중치가 부여된 NodePools를 생성하는 것이 좋습니다. 일치하지 않고 여러 NodePools 일치하는 경우 Karpenter는 사용할를 임의로 선택하여 예기치 않은 결과를 초래합니다. 여러 NodePools 생성하는 데 유용한 예는 다음과 같습니다.

GPU를 사용하여 NodePool을 생성하고 이러한 (고가) 노드에서만 특수 워크로드를 실행할 수 있도록 허용:

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    metadata: {}
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - p3.8xlarge
        - p3.16xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      taints:
      - effect: NoSchedule
        key: nvidia.com/gpu
        value: "true"

테인트에 대한 허용 오차가 있는 배포:

# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-gpu
spec:
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"

다른 팀을 위한 일반 배포의 경우 NodePool 사양에 nodeAffinity가 포함될 수 있습니다. 그러면 배포에서 nodeSelectorTerms를 사용하여를 일치시킬 수 있습니다billing-team.

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: generalcompute
spec:
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m5.2xlarge
        - c5.large
        - c5.xlarge
        - c5a.large
        - c5a.xlarge
        - r5.large
        - r5.xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand

nodeAffinity를 사용한 배포:

# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
  name: workload-my-team
spec:
  replicas: 200
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "billing-team"
                  operator: "In"
                  values: ["my-team"]

타이머(TTL)를 사용하여 클러스터에서 노드 자동 삭제

프로비저닝된 노드에서 타이머를 사용하여 워크로드 포드가 없거나 만료 시간에 도달한 노드를 삭제할 시기를 설정할 수 있습니다. 노드 만료는 업그레이드 수단으로 사용할 수 있으므로 노드가 사용 중지되고 업데이트된 버전으로 대체됩니다. 를 사용하여 노드 만료를 구성하는 방법에 대한 자세한 내용은 Karpenter 설명서의 만료를 참조spec.template.spec하세요.

특히 스팟을 활용할 때 Karpenter가 프로비저닝할 수 있는 인스턴스 유형을 지나치게 제한하지 마세요.

스팟을 사용할 때 Karpenter는 Price Capacity Optimized allocation 전략을 사용하여 EC2 인스턴스를 프로비저닝합니다. 이 전략은 EC2에 시작하는 인스턴스 수에 대해 가장 깊은 풀에서 인스턴스를 프로비저닝하도록 지시하며 중단 위험이 가장 낮습니다. 그런 다음 EC2 플릿은 이러한 풀 중에서 가격이 가장 낮은 스팟 인스턴스를 요청합니다. Karpenter가 더 많은 인스턴스 유형을 사용할 수 있을수록 EC2가 스팟 인스턴스의 런타임을 최적화할 수 있습니다. 기본적으로 Karpenter는 클러스터가 배포된 리전 및 가용 영역의 모든 인스턴스 유형 EC2 제안을 사용합니다. Karpenter는 보류 중인 포드를 기반으로 모든 인스턴스 유형 세트 중에서 지능적으로 선택하여 포드가 적절한 크기와 장비를 갖춘 인스턴스에 예약되도록 합니다. 예를 들어 포드에 GPU가 필요하지 않은 경우 Karpenter는 포드를 GPU를 지원하는 EC2 인스턴스 유형으로 예약하지 않습니다. 사용할 인스턴스 유형이 확실하지 않은 경우 Amazon ec2-instance-selector를 실행하여 컴퓨팅 요구 사항에 맞는 인스턴스 유형 목록을 생성할 수 있습니다. 예를 들어 CLI는 메모리 vCPU, 아키텍처 및 리전을 입력 파라미터로 받아 해당 제약 조건을 충족하는 EC2 인스턴스 목록을 제공합니다.

$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium

스팟 인스턴스를 사용할 때 Karpenter에 너무 많은 제약 조건을 두면 애플리케이션의 가용성에 영향을 미칠 수 있으므로 너무 많은 제약 조건을 두면 안 됩니다. 예를 들어 특정 유형의 모든 인스턴스가 회수되고 이를 대체할 수 있는 적절한 대안이 없다고 가정해 보겠습니다. 구성된 인스턴스 유형의 스팟 용량이 보충될 때까지 포드는 보류 상태로 유지됩니다. 스팟 풀은 AZs. 즉, 스팟을 사용할 때 Karpenter가 다양한 인스턴스 유형을 사용하도록 허용하는 것이 일반적인 모범 사례입니다.

포드 예약

다음 모범 사례는 노드 프로비저닝을 위해 Karpenter를 사용하여 클러스터에 포드를 배포하는 것과 관련이 있습니다.

고가용성을 위한 EKS 모범 사례 준수

고가용성 애플리케이션을 실행해야 하는 경우 일반적인 EKS 모범 사례 권장 사항을 따르세요. 노드와 영역에 포드를 분산하는 방법에 대한 자세한 내용은 Karpenter 설명서의 토폴로지 분산을 참조하세요. 중단 예산을 사용하여 포드를 제거하거나 삭제하려는 시도가 있는 경우 유지 관리해야 하는 사용 가능한 최소 포드를 설정합니다.

계층화된 제약 조건을 사용하여 클라우드 공급자가 제공하는 컴퓨팅 기능 제한

Karpenter의 계층화된 제약 조건 모델을 사용하면 복잡한 NodePool 및 포드 배포 제약 조건 세트를 생성하여 포드 일정에 가장 적합한 일치 항목을 얻을 수 있습니다. 포드 사양이 요청할 수 있는 제약 조건의 예는 다음과 같습니다.

결제 경보를 생성하여 컴퓨팅 지출 모니터링

클러스터를 자동으로 확장하도록 구성할 때 지출이 임계값을 초과하면 경고하는 결제 경보를 생성하고 Karpenter 구성에 리소스 제한을 추가해야 합니다. Karpenter로 리소스 제한을 설정하는 것은 Karpenter NodePool에서 인스턴스화할 수 있는 최대 컴퓨팅 리소스 양을 나타낸다는 점에서 AWS Autoscaling 그룹의 최대 용량을 설정하는 것과 유사합니다.

아래 코드 조각은 Karpenter에게 최대 1,000개의 CPU 코어와 1000Gi의 메모리만 프로비저닝하도록 지시합니다. Karpenter는 한도가 충족되거나 초과된 경우에만 용량 추가를 중지합니다. 한도를 초과하면 Karpenter 컨트롤러가 컨트롤러의 로그에 memory resource usage of 1001 exceeds limit of 1000 또는 이와 유사한 메시지를 씁니다. 컨테이너 로그를 CloudWatch 로그로 라우팅하는 경우 지표 필터를 생성하여 로그에서 특정 패턴 또는 용어를 찾은 다음 CloudWatch 경보를 생성하여 구성된 지표 임계값이 위반되면 알림을 받을 수 있습니다.

Karpenter에서 제한을 사용하는 자세한 내용은 Karpenter 설명서의 리소스 제한 설정을 참조하세요.

spec:
  limits:
    cpu: 1000
    memory: 1000Gi

제한을 사용하지 않거나 Karpenter가 프로비저닝할 수 있는 인스턴스 유형을 제한하지 않으면 Karpenter는 필요에 따라 클러스터에 컴퓨팅 용량을 계속 추가합니다. 이러한 방식으로 Karpenter를 구성하면 클러스터를 자유롭게 확장할 수 있지만 비용에 상당한 영향을 미칠 수도 있습니다. 따라서 결제 경보를 구성하는 것이 좋습니다. 결제 경보를 사용하면 계정(들)에서 계산된 예상 요금이 정의된 임계값을 초과할 때 알림을 받고 사전 예방적으로 알림을 받을 수 있습니다. 자세한 내용은 예상 요금을 선제적으로 모니터링하도록 Amazon CloudWatch 결제 경보 설정을 참조하세요.

기계 학습을 사용하여 비용 및 사용량을 지속적으로 모니터링하여 비정상적인 지출을 감지하는 AWS 비용 관리 기능인 비용 이상 탐지를 활성화할 수도 있습니다. 자세한 내용은 AWS 비용 이상 탐지 시작 안내서에서 확인할 수 있습니다. 지금까지 AWS Budgets에서 예산을 생성한 경우 특정 임계값을 위반했을 때 알리도록 작업을 구성할 수도 있습니다. 예산 작업을 사용하면 이메일을 보내거나 SNS 주제에 메시지를 게시하거나 Slack과 같은 챗봇에 메시지를 보낼 수 있습니다. 자세한 내용은 AWS Budgets 작업 구성을 참조하세요.

Karpenter가 노드 프로비저닝을 해제하지 못하도록 하려면 karpenter.sh/do-not-disrupt 주석을 사용합니다.

장기 실행 배치 작업 또는 상태 저장 애플리케이션과 같이 Karpenter에서 프로비저닝된 노드에서 중요한 애플리케이션을 실행 중이고 노드의 TTL이 만료된 경우 인스턴스가 종료되면 애플리케이션이 중단됩니다. 포드에 karpenter.sh/do-not-disrupt 주석을 추가하면 포드가 종료되거나 karpenter.sh/do-not-disrupt 주석이 제거될 때까지 노드를 보존하도록 Karpenter에 지시합니다. 자세한 내용은 Distruption 설명서를 참조하세요.

노드에 남아 있는 유일한 비 데몬 세트 포드가 작업과 연결된 포드인 경우 Karpenter는 작업 상태가 성공 또는 실패인 한 해당 노드를 대상으로 지정하고 종료할 수 있습니다.

통합 사용 시 모든 비 CPU 리소스에 대한 요청=제한 구성

포드 리소스 요청과 노드에서 할당 가능한 리소스의 양을 비교하여 일반적으로 통합 및 예약합니다. 리소스 제한은 고려되지 않습니다. 예를 들어 메모리 요청보다 큰 메모리 제한이 있는 포드는 요청 위로 버스트할 수 있습니다. 동일한 노드의 여러 포드가 동시에 버스트되면 메모리 부족(OOM) 조건으로 인해 일부 포드가 종료될 수 있습니다. 통합을 통해 요청을 고려한 경우에만 노드에 포드를 패키징할 수 있으므로 이러한 상황이 발생할 가능성이 높아질 수 있습니다.

LimitRanges를 사용하여 리소스 요청 및 제한에 대한 기본값 구성

Kubernetes는 기본 요청 또는 제한을 설정하지 않으므로 컨테이너가 기본 호스트, CPU 및 메모리에서 리소스를 소비하는 것은 제한되지 않습니다. Kubernetes 스케줄러는 포드의 총 요청 수(포드 컨테이너의 총 요청 수 또는 포드의 Init 컨테이너의 총 리소스 수 중 높음)를 확인하여 포드를 예약할 작업자 노드를 결정합니다. 마찬가지로 Karpenter는 포드의 요청을 고려하여 프로비저닝하는 인스턴스 유형을 결정합니다. 일부 포드에서 리소스 요청을 지정하지 않은 경우 제한 범위를 사용하여 네임스페이스에 적절한 기본값을 적용할 수 있습니다.

네임스페이스에 대한 기본 메모리 요청 및 제한 구성을 참조하세요.

모든 워크로드에 정확한 리소스 요청 적용

Karpenter는 워크로드 요구 사항에 대한 정보가 정확할 때 워크로드에 가장 적합한 노드를 시작할 수 있습니다. 이는 Karpenter의 통합 기능을 사용하는 경우 특히 중요합니다.

모든 워크로드에 대한 리소스 요청/제한 구성 및 크기 조정을 참조하세요.

CoreDNS 권장 사항

신뢰성을 유지하기 위해 CoreDNS의 구성 업데이트

Karpenter에서 관리하는 노드에 CoreDNS 포드를 배포할 때 수요에 맞게 새 노드를 빠르게 종료/생성하는 Karpenter의 동적 특성을 고려할 때 다음 모범 사례를 준수하는 것이 좋습니다.

CoreDNS lameduck 기간

CoreDNS 준비 프로브

이렇게 하면 DNS 쿼리가 아직 준비되지 않았거나 종료된 CoreDNS 포드로 전달되지 않습니다.

Karpenter 블루프린트

Karpenter가에 대한 컴퓨팅 용량을 Kubernetes 데이터 영역에 프로비저닝하기 위해 애플리케이션 우선 접근 방식을 취하므로, 이를 올바르게 구성하는 방법이 궁금할 수 있는 일반적인 워크로드 시나리오가 있습니다. Karpenter Blueprints는 여기에 설명된 모범 사례에 따른 일반적인 워크로드 시나리오 목록을 포함하는 리포지토리입니다. Karpenter가 구성된 EKS 클러스터를 생성하고 리포지토리에 포함된 각 블루프린트를 테스트하는 데 필요한 모든 리소스를 확보할 수 있습니다. 다양한 블루프린트를 결합하여 워크로드에 필요한 블루프린트(들)를 생성할 수 있습니다.

추가 리소스