기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # EKS 데이터 영역 가용성과 복원력이 뛰어난 애플리케이션을 운영하려면 가용성과 복원력이 뛰어난 데이터 영역이 필요합니다. 탄력적 데이터 영역은 Kubernetes가 애플리케이션을 자동으로 확장하고 복구할 수 있도록 합니다. 복원력이 뛰어난 데이터 영역은 두 개 이상의 작업자 노드로 구성되며 워크로드에 따라 확장 및 축소되고 장애로부터 자동으로 복구될 수 있습니다. EKS가 있는 작업자 노드에는 [EKS Auto Mode 관리형 노드](https://docs.aws.amazon.com/eks/latest/userguide/automode.html), [EC2 인스턴스](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 및 [Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html) 등 여러 가지 옵션이 있습니다. EKS Auto Mode는 복원력이 뛰어난 데이터 영역에 가장 쉬운 경로를 제공합니다. Auto Mode는 Kubernetes 클러스터의 AWS 관리를 클러스터 자체 이상으로 확장하여 AWS가 워크로드를 원활하게 운영할 수 있는 인프라를 설정하고 관리할 수 있도록 합니다. Auto Mode는 Kubernetes가 포드를 확장하고 클러스터의 노드가 현재 실행 중인 워크로드에 적합하고 비용 효율적으로 크기가 조정되도록 지속적으로 작동하면서 데이터 영역을 자동으로 확장하거나 축소합니다. EC2 인스턴스를 선택하는 경우 작업자 노드를 직접 관리하거나 [EKS 관리형 노드 그룹을](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) 사용할 수 있습니다. Auto Mode, 관리형 자체 관리형 작업자 노드 및 Fargate가 혼합된 클러스터를 보유할 수 있습니다. Fargate는 격리된 컴퓨팅 환경에서 각 포드를 실행합니다. Fargate에서 실행되는 각 포드는 자체 작업자 노드를 가져옵니다. Fargate는 Kubernetes가 포드를 조정함에 따라 데이터 영역을 자동으로 조정합니다. [가로 포드 오토스케일러](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html)를 사용하여 데이터 영역과 워크로드를 모두 조정할 수 있습니다. EC2 작업자 노드를 조정하는 기본 방법은(AWS에서 자동으로 수행하는 EKS Auto Mode를 사용하지 않는 경우) [Karpenter](https://karpenter.sh/), [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) 또는 [EC2 Auto Scaling 그룹을](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) 사용하는 것입니다. ## 권장 사항 ### 여러 AZs에 작업자 노드 및 워크로드 분산 여러 AZ에서 작업자 노드와 포드를 실행하여 개별 AZs. 노드를 생성하는 서브넷을 사용하여에서 작업자 노드가 생성되는 AZ를 제어할 수 있습니다. AZs 간에 포드를 분산하는 데 권장되는 방법은 [포드에 토폴로지 분산 제약 조건을](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#spread-constraints-for-pods) 사용하는 것입니다. EKS Auto Mode 및 Karpenter와 같은 Auto Scaling 기능은 토폴로지 분산 제약 조건을 인식하며 제약 조건을 충족할 수 있도록 올바른 AZs에서 노드를 자동으로 시작합니다. 아래 배포는 가능한 경우 포드를 AZs에 분산시켜 해당 포드가 실행되도록 합니다. ``` apiVersion: apps/v1 kind: Deployment metadata: name: web-server spec: replicas: 3 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: topologySpreadConstraints: - maxSkew: 1 whenUnsatisfiable: ScheduleAnyway topologyKey: topology.kubernetes.io/zone labelSelector: matchLabels: app: web-server containers: - name: web-app image: nginx resources: requests: cpu: 1 ``` **참고** `kube-scheduler`는 해당 레이블과 함께 존재하는 노드를 통해서만 토폴로지 도메인을 인식합니다. 위의 배포가 단일 영역에 노드만 있는 클러스터에 배포되는 경우 모든 포드는 다른 영역을 인식하지 `kube-scheduler` 못하므로 해당 노드에서 예약됩니다. 이 토폴로지가 스케줄러에서 예상대로 작동하려면 노드가 모든 영역에 이미 있어야 합니다. 토폴로지 분산 제약 조건의 `minDomains` 속성은이 문제를 방지하기 위해 노드가 실행 중인 경우에도 스케줄러에 적격 도메인 수를 알리는 데 사용됩니다. **주의** `whenUnsatisfiable` 로 설정`DoNotSchedule`하면 토폴로지 분산 제약 조건을 충족할 수 없는 경우 포드를 예약할 수 없습니다. 토폴로지 분산 제약을 위반하는 대신 포드를 실행하지 않는 것이 바람직한 경우에만 설정해야 합니다. 이전 버전의 Kubernetes에서는 포드 안티 친화도 규칙을 사용하여 여러 AZs. 아래 매니페스트는 개별 AZs에서 포드를 예약하는 것을 *선호*하도록 Kubernetes 스케줄러에 알립니다. ``` apiVersion: apps/v1 kind: Deployment metadata: name: web-server labels: app: web-server spec: replicas: 4 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - web-server topologyKey: failure-domain.beta.kubernetes.io/zone weight: 100 containers: - name: web-app image: nginx ``` **주의** 개별 AZs에서 포드를 예약할 필요가 없습니다. 그렇지 않으면 배포의 포드 수가 AZs 수를 초과하지 않습니다. ### EBS 볼륨을 사용할 때 각 AZ에서 노드를 시작할 수 있는지 확인 Amazon EBS를 사용하여 영구 볼륨을 제공하는 경우 포드와 연결된 EBS 볼륨이 동일한 AZ에 있는지 확인해야 합니다. 포드는 다른 AZ에 있는 EBS 지원 영구 볼륨에 액세스할 수 없습니다. Kubernetes [스케줄러는 노드에 있는 레이블에서 작업자 노드가 있는 AZ를 알고](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) 있으며 항상 볼륨과 동일한 AZ에 EBS 볼륨이 필요한 포드를 예약합니다. 그러나 볼륨이 위치한 AZ에 사용 가능한 작업자 노드가 없는 경우 포드를 예약할 수 없습니다. EKS Auto Mode 또는 Karpenter를 사용하는 경우 NodeClass가 각 AZ에서 서브넷을 선택하는지 확인해야 합니다. 관리형 노드 그룹을 사용하는 경우 각 AZ에 노드 그룹이 있는지 확인해야 합니다. EBS 스토리지 기능은 EKS Auto Mode에 내장되어 있지만 Karpenter 또는 Managed Node Groups를 사용하는 경우 [EBS CSI](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)도 설치해야 합니다. ### EKS Auto Mode를 사용하여 작업자 노드 관리 EKS Auto Mode는 운영 오버헤드를 최소화하면서 프로덕션 지원 클러스터를 제공하여 EKS 관리를 간소화합니다. Auto Mode는 클러스터에서 실행 중인 포드에 따라 노드 수를 늘리거나 줄입니다. 노드는 소프트웨어 패치 및 수정 사항을 통해 자동으로 최신 상태로 유지되며, 업데이트는 구성된 [NodePool](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption) 중단 설정 및 포드 중단 예산에 따라 수행됩니다. ### 노드 모니터링 에이전트 실행 [노드 모니터링 에이전트](https://docs.aws.amazon.com/eks/latest/userguide/node-health.html)는 Kubernetes 이벤트를 게시하고 노드에 상태 조건을 업데이트하여 노드 상태 문제를 모니터링하고 이에 대응합니다. 노드 모니터링 에이전트는 EKS Auto Mode 노드에 포함되어 있으며 Auto Mode에서 관리하지 않는 노드에 대한 EKS 추가 기능으로 설치할 수 있습니다. EKS Auto Mode, Managed Node Groups 및 Karpenter는 모두 노드 모니터링 에이전트가 보고한 치명적인 노드 상태를 감지하고 이러한 조건이 발생할 때 해당 노드를 자동으로 복구할 수 있습니다. ### QoS 구현 중요한 애플리케이션의 경우 포드의 컨테이너에 대해 `requests`=`limits`를 정의하는 것이 좋습니다. 이렇게 하면 다른 포드가 리소스를 요청하는 경우 컨테이너가 종료되지 않습니다. 컨테이너가 실수로 시스템 리소스를 소비하여 다른 공동 위치 프로세스의 가용성에 영향을 미치는 것을 방지하기 때문에 모든 컨테이너에 대해 CPU 및 메모리 제한을 구현하는 것이 가장 좋습니다. ### 모든 워크로드에 대한 리소스 요청/제한 구성 및 크기 조정 워크로드에 대한 리소스 요청 크기 조정 및 제한에 몇 가지 일반 지침을 적용할 수 있습니다. + CPU에 리소스 제한을 지정하지 마십시오. 제한이 없는 경우 요청은 [컨테이너가 가져오는 상대 CPU 시간 양](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run)에 대한 가중치 역할을 합니다. 이를 통해 워크로드는 인공적인 제한이나 결핍 없이 전체 CPU를 사용할 수 있습니다. + 비 CPU 리소스의 경우 구성 `requests`=`limits`는 가장 예측 가능한 동작을 제공합니다. `requests`\!=`limits`인 경우 컨테이너의 [QOS](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes)도 보장에서 버스트 가능으로 감소하여 [노드 압력](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/) 발생 시 제거될 가능성이 높아집니다. + 비 CPU 리소스의 경우 요청보다 훨씬 큰 제한을 지정하지 마십시오. `limits` 상대적으로 크기가 클수록 `requests`노드가 과도하게 커밋되어 워크로드 중단 가능성이 높아집니다. + 올바른 크기의 요청은 [Karpenter](https://aws.github.io/aws-eks-best-practices/karpenter/) 또는 [Cluster AutoScaler](https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/)와 같은 노드 Auto Scaling 솔루션을 사용할 때 특히 중요합니다. 이러한 도구는 워크로드 요청을 검토하여 프로비저닝할 노드의 수와 크기를 결정합니다. 요청이 너무 작아 제한이 큰 경우 워크로드가 제거되거나 노드에 밀접하게 압축된 경우 OOM이 종료될 수 있습니다. 리소스 요청을 결정하는 것은 어려울 수 있지만 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)와 같은 도구는 런타임 시 컨테이너 리소스 사용량을 관찰하여 요청을 '적합하게 조정'하는 데 도움이 될 수 있습니다. 요청 크기를 결정하는 데 유용할 수 있는 다른 도구는 다음과 같습니다. + [골드록](https://github.com/FairwindsOps/goldilocks) + [Parca](https://www.parca.dev/) + [Prodfiler](https://prodfiler.com/) + [rsg](https://mhausenblas.info/right-size-guide/) ### 네임스페이스에 대한 리소스 할당량 구성 네임스페이스는 많은 사용자가 여러 팀 또는 프로젝트에 분산되어 있는 환경에서 사용하기 위한 것입니다. 이름 범위를 제공하며 여러 팀, 프로젝트, 워크로드 간에 클러스터 리소스를 분할하는 방법입니다. 네임스페이스에서 집계 리소스 소비를 제한할 수 있습니다. [https://kubernetes.io/docs/concepts/policy/resource-quotas/](https://kubernetes.io/docs/concepts/policy/resource-quotas/) 객체는 네임스페이스에서 유형별로 생성할 수 있는 객체의 수량과 해당 프로젝트의 리소스에서 사용할 수 있는 컴퓨팅 리소스의 총량을 제한할 수 있습니다. 지정된 네임스페이스에서 요청할 수 있는 스토리지 및/또는 컴퓨팅(CPU 및 메모리) 리소스의 총합을 제한할 수 있습니다. CPU 및 메모리와 같은 컴퓨팅 리소스의 네임스페이스에 리소스 할당량이 활성화된 경우 사용자는 해당 네임스페이스의 각 컨테이너에 대한 요청 또는 제한을 지정해야 합니다. 각 네임스페이스에 대한 할당량을 구성하는 것이 좋습니다. `LimitRanges`를 사용하여 네임스페이스 내의 컨테이너에 사전 구성된 제한을 자동으로 적용하는 것이 좋습니다. ### 네임스페이스 내에서 컨테이너 리소스 사용량 제한 Resource Quotas는 네임스페이스가 사용할 수 있는 리소스의 양을 제한하는 데 도움이 됩니다. [`LimitRange` 객체](https://kubernetes.io/docs/concepts/policy/limit-range/)는 컨테이너가 요청할 수 있는 최소 및 최대 리소스를 구현하는 데 도움이 될 수 있습니다. 를 사용하면 컨테이너에 대한 기본 요청 및 제한을 설정할 `LimitRange` 수 있습니다. 이는 컴퓨팅 리소스 제한을 설정하는 것이 조직의 표준 관행이 아닌 경우 유용합니다. 이름에서 알 수 있듯이 `LimitRange`는 네임스페이스에서 포드 또는 컨테이너당 최소 및 최대 컴퓨팅 리소스 사용량을 적용할 수 있습니다. 또한 네임스페이스에서 PersistentVolumeClaim당 최소 및 최대 스토리지 요청을 적용합니다. 컨테이너 및 네임스페이스 수준에서 제한을 적용`ResourceQuota`하려면와 `LimitRange` 함께를 사용하는 것이 좋습니다. 이러한 제한을 설정하면 컨테이너 또는 네임스페이스가 클러스터의 다른 테넌트가 사용하는 리소스에 영향을 주지 않습니다. ### NodeLocal DNSCache 사용 [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) 성능을 개선할 수 있습니다. 이 기능은 클러스터 노드에서 DNS 캐싱 에이전트를 DaemonSet로 실행합니다. 모든 포드는 `kube-dns` 서비스를 사용하는 대신 이름 확인을 위해 노드에서 실행되는 DNS 캐싱 에이전트를 사용합니다. 이 기능은 EKS Auto Mode에 자동으로 포함됩니다. ### Auto Scaling CoreDNS 구성 클러스터 DNS 성능을 개선하는 또 다른 방법은 [ CoreDNS 포드의 기본 자동 크기 조정을](https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html) 활성화하는 것입니다. 이 기능은 노드 및 CPU 코어 수를 포함하여 클러스터 상태를 지속적으로 모니터링합니다. 해당 정보를 기반으로 컨트롤러는 EKS 클러스터에서 CoreDNS 배포의 복제본 수를 동적으로 조정합니다.