기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
EKS 데이터 영역
가용성과 복원력이 뛰어난 애플리케이션을 운영하려면 가용성과 복원력이 뛰어난 데이터 영역이 필요합니다. 탄력적 데이터 영역은 Kubernetes가 애플리케이션을 자동으로 확장하고 복구할 수 있도록 합니다. 복원력이 뛰어난 데이터 영역은 두 개 이상의 작업자 노드로 구성되며 워크로드에 따라 확장 및 축소되고 장애로부터 자동으로 복구될 수 있습니다.
EKS를 사용하는 작업자 노드에는 EKS Auto Mode 관리형 노드, EC2 인스턴스 및 Fargate 등 여러 가지 옵션이 있습니다.
EKS Auto Mode는 복원력이 뛰어난 데이터 영역으로 가는 가장 쉬운 경로를 제공합니다. Auto Mode는 Kubernetes 클러스터의 AWS 관리를 클러스터 자체 이상으로 확장하여 AWS가 워크로드를 원활하게 운영할 수 있는 인프라를 설정하고 관리할 수 있도록 합니다. Auto Mode는 Kubernetes가 포드를 확장하고 클러스터의 노드가 현재 실행 중인 워크로드에 적합하고 비용 효율적으로 크기가 조정되도록 지속적으로 작동하면서 데이터 영역을 자동으로 확장하거나 축소합니다.
EC2 인스턴스를 선택하는 경우 작업자 노드를 직접 관리하거나 EKS 관리형 노드 그룹을 사용할 수 있습니다. 자동 모드, 관리형 자체 관리형 작업자 노드 및 Fargate가 혼합된 클러스터를 보유할 수 있습니다.
Fargate는 격리된 컴퓨팅 환경에서 각 포드를 실행합니다. Fargate에서 실행되는 각 포드는 자체 작업자 노드를 가져옵니다. Fargate는 Kubernetes가 포드를 조정함에 따라 데이터 영역을 자동으로 조정합니다. 가로 포드 오토스케일러를 사용하여 데이터 영역과 워크로드를 모두 조정할 수 있습니다.
EC2 작업자 노드를 조정하는 선호되는 방법(AWS에서 자동으로 수행하는 EKS Auto Mode를 사용하지 않는 경우)은 Karpenter
추천
여러 AZs에 작업자 노드 및 워크로드 분산
여러 AZ에서 작업자 노드와 포드를 실행하여 개별 AZs. 노드를 생성하는 서브넷을 사용하여에서 작업자 노드가 생성되는 AZ를 제어할 수 있습니다.
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를 알고
EKS Auto Mode 또는 Karpenter를 사용하는 경우 NodeClass가 각 AZ에서 서브넷을 선택하는지 확인해야 합니다. 관리형 노드 그룹을 사용하는 경우 각 AZ에 노드 그룹이 있는지 확인해야 합니다.
EBS 스토리지 기능은 EKS Auto Mode에 내장되어 있지만 Karpenter 또는 Managed Node Groups를 사용하는 경우 EBS CSI도 설치해야 합니다.
EKS Auto Mode를 사용하여 작업자 노드 관리
EKS Auto Mode는 운영 오버헤드를 최소화하면서 프로덕션 지원 클러스터를 제공하여 EKS 관리를 간소화합니다. Auto Mode는 클러스터에서 실행 중인 포드에 따라 노드 수를 늘리거나 줄입니다. 노드는 소프트웨어 패치 및 수정 사항을 통해 자동으로 최신 상태로 유지되며, 업데이트는 구성된 NodePool 중단 설정 및 포드 중단 예산에 따라 수행됩니다.
노드 모니터링 에이전트 실행
노드 모니터링 에이전트는 Kubernetes 이벤트를 게시하고 노드에 상태 조건을 업데이트하여 노드 상태 문제를 모니터링하고 이에 대응합니다. 노드 모니터링 에이전트는 EKS Auto Mode 노드에 포함되어 있으며 Auto Mode에서 관리하지 않는 노드에 대한 EKS 추가 기능으로 설치할 수 있습니다.
EKS Auto Mode, Managed Node Groups 및 Karpenter는 모두 노드 모니터링 에이전트가 보고한 치명적인 노드 조건을 감지하고 이러한 조건이 발생할 때 해당 노드를 자동으로 복구할 수 있습니다.
QoS 구현
중요한 애플리케이션의 경우 포드의 컨테이너에 대해 requests=limits를 정의하는 것이 좋습니다. 이렇게 하면 다른 포드가 리소스를 요청하는 경우 컨테이너가 종료되지 않습니다.
컨테이너가 실수로 시스템 리소스를 소비하여 다른 공동 위치 프로세스의 가용성에 영향을 미치는 것을 방지하기 때문에 모든 컨테이너에 대해 CPU 및 메모리 제한을 구현하는 것이 가장 좋습니다.
모든 워크로드에 대한 리소스 요청/제한 구성 및 크기 조정
리소스 요청 크기 조정 및 워크로드 제한에 몇 가지 일반 지침을 적용할 수 있습니다.
-
CPU에 리소스 제한을 지정하지 마십시오. 제한이 없는 경우 요청은 컨테이너가 가져오는 상대 CPU 시간 양
에 대한 가중치 역할을 합니다. 이를 통해 워크로드는 인공적인 제한이나 결핍 없이 전체 CPU를 사용할 수 있습니다. -
비 CPU 리소스의 경우 구성
requests=limits는 가장 예측 가능한 동작을 제공합니다.requests!=limits인 경우 컨테이너의 QOS도 보장에서 버스트 가능으로 감소하여 노드 압력 발생 시 제거될 가능성이 높아집니다. -
비 CPU 리소스의 경우 요청보다 훨씬 큰 제한을 지정하지 마십시오.
limits상대적으로 크기가 클requests수록 노드가 과도하게 커밋되어 워크로드 중단 가능성이 높아집니다. -
올바른 크기의 요청은 Karpenter
또는 Cluster AutoScaler 와 같은 노드 Auto Scaling 솔루션을 사용할 때 특히 중요합니다. 이러한 도구는 워크로드 요청을 검토하여 프로비저닝할 노드의 수와 크기를 결정합니다. 요청이 너무 작아 제한이 큰 경우 노드에 밀접하게 압축된 워크로드가 제거되거나 OOM이 종료될 수 있습니다.
리소스 요청을 결정하는 것은 어려울 수 있지만 Vertical Pod Autoscaler
네임스페이스에 대한 리소스 할당량 구성
네임스페이스는 많은 사용자가 여러 팀 또는 프로젝트에 분산되어 있는 환경에서 사용하기 위한 것입니다. 이름 범위를 제공하며 여러 팀, 프로젝트, 워크로드 간에 클러스터 리소스를 분할하는 방법입니다. 네임스페이스에서 집계 리소스 소비를 제한할 수 있습니다. ResourceQuota
CPU 및 메모리와 같은 컴퓨팅 리소스의 네임스페이스에 리소스 할당량이 활성화된 경우 사용자는 해당 네임스페이스의 각 컨테이너에 대한 요청 또는 제한을 지정해야 합니다.
각 네임스페이스에 대한 할당량을 구성하는 것이 좋습니다. LimitRanges를 사용하여 네임스페이스 내의 컨테이너에 사전 구성된 제한을 자동으로 적용하는 것이 좋습니다.
네임스페이스 내에서 컨테이너 리소스 사용량 제한
Resource Quotas는 네임스페이스가 사용할 수 있는 리소스의 양을 제한하는 데 도움이 됩니다. LimitRange 객체LimitRange 수 있습니다. 이는 컴퓨팅 리소스 제한을 설정하는 것이 조직의 표준 관행이 아닌 경우 유용합니다. 이름에서 알 수 있듯이 LimitRange는 네임스페이스에서 포드 또는 컨테이너당 최소 및 최대 컴퓨팅 리소스 사용량을 적용할 수 있습니다. 또한 네임스페이스에서 PersistentVolumeClaim당 최소 및 최대 스토리지 요청을 적용합니다.
컨테이너 및 네임스페이스 수준에서 제한을 적용ResourceQuota하려면와 LimitRange 함께를 사용하는 것이 좋습니다. 이러한 제한을 설정하면 컨테이너 또는 네임스페이스가 클러스터의 다른 테넌트가 사용하는 리소스에 영향을 주지 않습니다.
NodeLocal DNSCache 사용
NodeLocal DNSCachekube-dns 서비스를 사용하는 대신 이름 확인을 위해 노드에서 실행되는 DNS 캐싱 에이전트를 사용합니다. 이 기능은 EKS Auto Mode에 자동으로 포함됩니다.
Auto Scaling CoreDNS 구성
클러스터 DNS 성능을 개선하는 또 다른 방법은 CoreDNS 포드의 기본 자동 크기 조정을 활성화하는 것입니다.
이 기능은 노드 및 CPU 코어 수를 포함하여 클러스터 상태를 지속적으로 모니터링합니다. 해당 정보를 기반으로 컨트롤러는 EKS 클러스터에서 CoreDNS 배포의 복제본 수를 동적으로 조정합니다.
