Amazon EKS에서 Amazon Application Recovery Controller(ARC) 존 시프트 알아보기
Amazon EKS에서 Amazon Application Recovery Controller(ARC) 존 시프트 알아보기
Kubernetes에는 애플리케이션을 가용 영역(AZ)의 성능 저하나 손상 같은 이벤트에 더 저항력 있게 만드는 네이티브 기능이 있어요. Amazon EKS 클러스터에서 워크로드를 실행할 때 Amazon Application Recovery Controller(ARC) 존 시프트 또는 존 오토시프트로 애플리케이션 환경의 장애 허용도와 애플리케이션 복구를 더 개선할 수 있어요.
출처: 문서
본문
ARC 존 시프트는 임시 조치로 설계됐어요. 존 시프트가 만료되거나 취소할 때까지 리소스의 트래픽을 손상된 AZ에서 옮길 수 있어요. 필요하면 존 시프트를 연장할 수 있어요.
EKS 클러스터에 대해 존 시프트를 시작하거나, 존 오토시프트를 활성화해 AWS가 대신 트래픽을 옮기게 할 수 있어요. 이 시프트는 클러스터의 동서(east-to-west) 네트워크 트래픽 흐름을 업데이트해 정상 AZ의 워커 노드에서 실행되는 파드의 네트워크 엔드포인트만 고려하도록 해요. 또한 EKS 클러스터의 애플리케이션 인그레스 트래픽을 처리하는 모든 ALB 또는 NLB가 정상 AZ의 대상으로 트래픽을 자동으로 라우팅해요. 최고 가용성 목표를 추구하는 고객의 경우 AZ가 손상되면 복구될 때까지 모든 트래픽을 손상된 AZ에서 멀리 보내는 것이 중요할 수 있어요. 이를 위해 ARC 존 시프트로 ALB 또는 NLB를 활성화할 수도 있어요.
파드 간 동서 네트워크 트래픽 흐름 이해하기 (Understanding east-west network traffic flow between Pods)
다음 다이어그램은 Orders와 Products 두 예시 워크로드를 보여줘요. 이 예시의 목적은 서로 다른 AZ의 워크로드와 파드가 어떻게 통신하는지 보여주는 거예요.
Orders가 Products와 통신하려면 먼저 대상 서비스의 DNS 이름을 해석해야 해요. Orders는 CoreDNS와 통신해 해당 서비스의 가상 IP 주소(Cluster IP)를 가져와요. Orders가 Products 서비스 이름을 해석한 후 해당 대상 IP 주소로 트래픽을 보내요.
kube-proxy는 클러스터의 모든 노드에서 실행되며 서비스의 EndpointSlices를 지속적으로 감시해요. 서비스가 생성되면 EndpointSlice 컨트롤러가 백그라운드에서 EndpointSlice를 만들고 관리해요. 각 EndpointSlice에는 일부 파드 주소와 실행 중인 노드가 포함된 엔드포인트 목록 또는 테이블이 있어요. kube-proxy는 노드에서 iptables를 사용해 각 파드 엔드포인트에 대한 라우팅 규칙을 설정해요. 또한 kube-proxy는 기본적인 부하 분산을 담당해 서비스의 Cluster IP 주소로 향하는 트래픽을 파드의 IP 주소로 직접 보내도록 리다이렉트해요. kube-proxy는 아웃바운드 연결의 대상 IP 주소를 다시 쓰는 방식으로 이를 수행해요.
그런 다음 네트워크 패킷은 각 노드의 ENI를 사용해 AZ 2의 Products 파드로 전송돼요.
Amazon EKS의 ARC 존 시프트 이해하기 (Understanding ARC zonal shift in Amazon EKS)
환경에 AZ 손상이 있다면 EKS 클러스터 환경에 대해 존 시프트를 시작할 수 있어요. 또는 존 오토시프트로 AWS가 대신 트래픽을 옮기게 할 수 있어요. 존 오토시프트를 사용하면 AWS가 전체 AZ 상태를 모니터링하고 잠재적 AZ 손상에 응답해 클러스터 환경의 손상된 AZ에서 자동으로 트래픽을 옮겨요.
EKS 클러스터가 ARC로 존 시프트를 활성화한 후에는 ARC 콘솔, AWS CLI, 또는 존 시프트 및 존 오토시프트 API로 존 시프트를 시작하거나 존 오토시프트를 활성화할 수 있어요.
EKS 존 시프트 중 다음이 자동으로 수행돼요:
- 영향받는 AZ의 모든 노드가 cordon(격리)됩니다. 이는 Kubernetes Scheduler가 비정상 AZ의 노드에 새 파드를 스케줄링하지 못하도록 방지해요.
- EKS Auto Mode를 사용한다면 EKS Auto Mode가 손상된 AZ에서 새 노드 프로비저닝을 자동으로 중지해요. EKS Auto Mode는 손상된 AZ에 영향을 줄 통합(consolidation)과 드리프트 같은 자발적 중단 작업도 중단해, 손상된 AZ의 자발적 인스턴스 종료를 멈춰 재시도 폭풍을 방지해요. 손상된 AZ를 대상으로 하는 엄격한 스케줄링 요구 사항(영구 볼륨 바인딩, 노드 선호도, 엄격한 토폴로지 분산 제약 등)이 있는 파드는 그 AZ에 새 노드 시작 시도를 만들지 않아요.
- Managed Node Groups를 사용한다면 가용 영역 재균형이 중단되고, 새 EKS 데이터 플레인 노드가 정상 AZ에서만 시작되도록 Auto Scaling 그룹이 업데이트돼요.
- 비정상 AZ의 노드는 종료되지 않고 파드도 노드에서 축출되지 않아요. 이렇게 하면 존 시프트가 만료되거나 취소될 때 트래픽을 안전하게 AZ로 전체 용량 반환할 수 있어요.
- EndpointSlice 컨트롤러가 손상된 AZ의 모든 파드 엔드포인트를 찾아 관련 EndpointSlices에서 제거해요. 이를 통해 정상 AZ의 파드 엔드포인트만 네트워크 트래픽을 받도록 보장해요. 존 시프트가 취소되거나 만료되면 EndpointSlice 컨트롤러가 복원된 AZ의 엔드포인트를 포함하도록 EndpointSlices를 업데이트해요.
다음 다이어그램들은 EKS 존 시프트가 클러스터 환경에서 정상 파드 엔드포인트만 대상으로 하도록 보장하는 방법에 대한 개요를 제공해요.
EKS 존 시프트 요구 사항 (EKS zonal shift requirements)
중요: 존 시프트는 모든 클러스터 내 트래픽을 가용 영역에서 옮겨요. 워크로드가 충분한 replica로 여러 AZ에 분산되지 않았다면, 수신할 정상 엔드포인트가 없기 때문에 존 시프트 시작 자체가 애플리케이션에 가용성 영향을 줄 수 있어요. 존 오토시프트를 활성화하거나 수동 존 시프트를 시작하기 전에 클러스터 환경이 AZ 하나 없이도 운영될 수 있는지 검증해야 해요.
존 시프트가 EKS에서 성공적으로 작동하려면 AZ 손상에 저항력 있도록 클러스터 환경을 미리 설정해야 해요. 복원력을 보장하는 데 도움이 되는 구성 옵션 목록은 다음과 같아요:
- 클러스터의 워커 노드를 여러 AZ에 걸쳐 프로비저닝
- 단일 AZ 제거를 수용할 충분한 컴퓨트 용량 프로비저닝
- CoreDNS를 포함한 파드를 모든 AZ에 미리 확장
- 여러 파드 replica를 모든 AZ에 걸쳐 분산해 단일 AZ에서 시프트할 때 충분한 용량을 확보하도록 보장
- 상호 의존적이거나 관련된 파드를 같은 AZ에 공동 배치
- AZ에서 수동 존 시프트를 시작해 클러스터 환경이 AZ 없이도 예상대로 작동하는지 테스트. 또는 존 오토시프트를 활성화하고 오토시프트 연습 실행(practice runs)에 의존할 수 있음. 수동 또는 연습 존 시프트로 테스트하는 것은 EKS에서 존 시프트가 작동하는 데 필수는 아니지만 강력히 권장됨.
EKS 워커 노드를 여러 가용 영역에 걸쳐 프로비저닝하기 (Provision your EKS worker nodes across multiple Availability Zones)
AWS 리전에는 물리적 데이터 센터가 있는 여러 개의 분리된 위치인 가용 영역(AZ)이 있어요. AZ는 전체 리전에 영향을 줄 수 있는 동시 충격을 피하도록 물리적으로 서로 격리되도록 설계됐어요. EKS 클러스터를 프로비저닝할 때 워커 노드를 리전의 여러 AZ에 걸쳐 배포할 것을 권장합니다. 이렇게 하면 단일 AZ 손상에 클러스터 환경이 더 저항력 있게 되고, 다른 AZ에서 실행되는 애플리케이션에 대한 고가용성을 유지할 수 있어요. 영향받은 AZ에서 존 시프트를 시작하면 EKS 환경의 클러스터 내 네트워크가 정상 AZ만 사용하도록 자동으로 업데이트되어 클러스터의 고가용성을 유지하는 데 도움을 줘요.
EKS 환경을 다중 AZ로 설정하면 시스템의 전반적인 안정성이 향상돼요. 하지만 다중 AZ 환경은 애플리케이션 데이터가 전송·처리되는 방식에 영향을 주며, 이는 환경의 네트워크 요금에 영향을 미쳐요. 특히 빈번한 이그레스 크로스 존 트래픽(AZ 간 분산 트래픽)은 네트워크 관련 비용에 큰 영향을 줄 수 있어요. EKS 클러스터의 파드 간 크로스 존 트래픽 양을 제어하고 관련 비용을 줄이는 다양한 전략을 적용할 수 있어요. 고가용성 EKS 환경 실행 시 네트워크 비용을 최적화하는 방법은 이 모범 사례를 참고해 주세요.
단일 가용 영역 제거를 견딜 충분한 컴퓨트 용량 프로비저닝하기 (Provision enough compute capacity to withstand removal of a single Availability Zone)
EKS 데이터 플레인의 컴퓨트 인프라에 대한 리소스 활용과 비용을 최적화하려면 컴퓨트 용량을 워크로드 요구 사항에 맞추는 것이 모범 사례예요. 하지만 모든 워커 노드가 최대 용량이면 새 파드가 스케줄링되기 전에 EKS 데이터 플레인에 새 워커 노드가 추가되는 것에 의존하게 돼요. 중요 워크로드를 실행할 때는 일반적으로 부하의 급증과 노드 상태 문제 같은 시나리오를 처리하기 위해 중복 용량을 온라인으로 실행하는 것이 좋은 관행이에요. 존 시프트를 사용할 계획이라면 손상이 있을 때 AZ 용량 전체를 제거할 계획을 세우는 것과 같아요. 즉 AZ 중 하나가 오프라인인 상태에서도 부하를 처리할 수 있도록 중복 컴퓨트 용량을 조정해야 해요.
컴퓨트 리소스를 확장할 때 EKS 데이터 플레인에 새 노드를 추가하는 과정은 시간이 걸려요. 이는 특히 존 손상 시 애플리케이션의 실시간 성능과 가용성에 영향을 줄 수 있어요. EKS 환경은 최종 사용자나 클라이언트의 성능 저하 없이 AZ 하나를 잃는 부하를 흡수할 수 있어야 해요. 즉 새 파드가 필요할 때와 실제로 워커 노드에 스케줄링되는 때 사이의 지연을 최소화하거나 없애야 해요.
또한 존 손상이 있을 때 정상 AZ의 EKS 데이터 플레인에 새로 필요한 노드를 추가하지 못하게 하는 컴퓨트 용량 제약에 부딪힐 위험을 완화해야 해요.
이런 잠재적 부정적 영향의 위험을 줄이기 위해 각 AZ의 일부 워커 노드에서 컴퓨트 용량을 초과 프로비저닝할 것을 권장합니다. 이렇게 하면 Kubernetes Scheduler가 새 파드 배치에 사용할 수 있는 기존 용량을 확보하며, 이는 환경에서 AZ 중 하나를 잃을 때 특히 중요해요.
여러 파드 replica를 가용 영역에 걸쳐 실행하고 분산하기 (Run and spread multiple Pod replicas across Availability Zones)
Kubernetes를 사용하면 단일 애플리케이션의 여러 인스턴스(파드 replica)를 실행해 워크로드를 미리 확장할 수 있어요. 애플리케이션에 대해 여러 파드 replica를 실행하면 단일 실패 지점이 제거되고 단일 replica의 리소스 부담을 줄여 전반적인 성능이 향상돼요. 하지만 고가용성과 더 나은 장애 허용도를 모두 얻으려면 애플리케이션의 여러 replica를 실행하고 토폴로지 도메인이라고도 하는 서로 다른 실패 도메인에 분산할 것을 권장합니다. 이 시나리오의 실패 도메인은 가용 영역이에요. 토폴로지 분산 제약을 사용하면 애플리케이션에 기존의 정적 안정성을 설정할 수 있어요. 그런 다음 AZ 손상이 있을 때 정상 AZ에 충분한 replica가 있어 트래픽의 급증이나 급등을 즉시 처리할 수 있어요.
다음 코드 스니펫은 Kubernetes에서 워크로드를 여러 replica로 설정하는 방법의 예시예요.
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app: orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
가장 중요한 것은 DNS 서버 소프트웨어(CoreDNS/kube-dns)의 여러 replica를 실행하고, 기본적으로 구성되어 있지 않다면 유사한 토폴로지 분산 제약을 적용해야 한다는 거예요. 이렇게 하면 단일 AZ 손상이 있을 때 클러스터의 다른 통신 파드를 위한 서비스 검색 요청을 계속 처리할 정상 AZ에 충분한 DNS 파드가 확보됩니다. CoreDNS EKS add-on은 CoreDNS 파드에 대한 기본 설정을 갖고 있어, 여러 AZ에 노드가 있으면 클러스터의 가용 영역에 걸쳐 분산되도록 보장해요. 원한다면 이 기본 설정을 직접 만든 사용자 지정 구성으로 바꿀 수 있어요.
Helm으로 CoreDNS를 설치할 때 values.yaml 파일의 replicaCount를 업데이트해 각 AZ에 충분한 replica가 있도록 할 수 있어요. 또한 이 replica들이 클러스터 환경의 서로 다른 AZ에 분산되도록 같은 values.yaml 파일의 topologySpreadConstraints 속성을 업데이트해야 해요. 다음 코드 스니펫은 CoreDNS를 이렇게 구성하는 방법을 보여줘요.
CoreDNS Helm values.yaml
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
AZ 손상이 있으면 CoreDNS용 오토스케일링 시스템을 사용해 CoreDNS 파드의 증가된 부하를 흡수할 수 있어요. 필요한 DNS 인스턴스 수는 클러스터에서 실행되는 워크로드 수에 따라 달라져요. CoreDNS는 CPU 바운드이므로 Horizontal Pod Autoscaler(HPA)로 CPU에 기반해 확장할 수 있어요. 다음은 요구에 맞게 수정할 수 있는 예시예요.
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
또는 EKS add-on 버전의 CoreDNS에서 EKS가 CoreDNS 배포의 오토스케일링을 관리할 수 있어요. 이 CoreDNS 오토스케일러는 노드 수와 CPU 코어를 포함한 클러스터 상태를 지속적으로 모니터링해요. 그 정보를 바탕으로 컨트롤러가 EKS 클러스터의 CoreDNS 배포 replica 수를 동적으로 조정해요.
CoreDNS EKS add-on에서 오토스케일링 구성을 활성화하려면 다음 구성 설정을 사용하세요:
{
"autoScaling": {
"enabled": true
}
}
NodeLocal DNS 또는 클러스터 비례 오토스케일러를 사용해 CoreDNS를 확장할 수도 있어요. 자세한 내용은 Scaling CoreDNS horizontally 참고.
상호 의존적인 파드를 같은 가용 영역에 공동 배치하기 (Colocate interdependent Pods in the same Availability Zone)
일반적으로 애플리케이션에는 종단 간 프로세스를 성공적으로 완료하기 위해 서로 통신해야 하는 개별 워크로드가 있어요. 이 개별 애플리케이션이 서로 다른 AZ에 분산되어 있고 같은 AZ에 공동 배치되지 않았다면, 단일 AZ 손상이 종단 간 프로세스에 영향을 줄 수 있어요. 예를 들어 애플리케이션 A가 AZ 1과 AZ 2에 여러 replica를 두고 있지만 애플리케이션 B의 모든 replica가 AZ 3에 있다면, AZ 3의 손실은 두 워크로드(애플리케이션 A와 B) 간의 종단 간 프로세스에 영향을 줍니다. 토폴로지 분산 제약을 파드 선호도(pod affinity)와 결합하면 파드를 모든 AZ에 분산시켜 애플리케이션의 복원력을 향상시킬 수 있어요. 또한 특정 파드 간의 관계를 구성해 같은 위치에 공동 배치되도록 보장할 수 있어요.
파드 선호도 규칙으로 워크로드 간의 관계를 정의해 Kubernetes Scheduler가 파드를 같은 워커 노드나 같은 AZ에 공동 배치하도록 동작에 영향을 줄 수 있어요. 스케줄링 제약이 얼마나 엄격해야 하는지도 구성할 수 있어요.
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
template:
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
클러스터 환경이 AZ 손실을 처리할 수 있는지 테스트하기 (Test that your cluster environment can handle the loss of an AZ)
이전 섹션에 설명된 요구 사항을 완료한 후, 다음 단계는 AZ 손실을 처리할 충분한 컴퓨트와 워크로드 용량이 있는지 테스트하는 거예요. EKS에서 존 시프트를 수동으로 시작해 할 수 있어요. 또는 존 오토시프트를 활성화하고 연습 실행을 구성하는데, 이것도 클러스터 환경에서 AZ 하나가 적은 상태로 애플리케이션이 예상대로 작동하는지 테스트해요.
자주 묻는 질문 (Frequently asked questions)
- 이 기능을 왜 사용해야 하나요? EKS 클러스터에서 ARC 존 시프트 또는 존 오토시프트를 사용하면 손상된 AZ에서 클러스터 내 네트워크 트래픽을 옮기는 빠른 복구 과정을 자동화해 Kubernetes 애플리케이션 가용성을 더 잘 유지할 수 있어요. ARC를 사용하면 손상된 AZ 이벤트 중 복구 기간을 연장할 수 있는 길고 복잡한 단계를 피할 수 있어요.
- 이 기능은 다른 AWS 서비스와 어떻게 함께 작동하나요? EKS는 AWS에서 복구 작업을 수행하는 기본 인터페이스를 제공하는 ARC와 통합돼요. 클러스터 내 트래픽이 손상된 AZ에서 적절히 라우팅되도록 EKS는 Kubernetes 데이터 플레인에서 실행되는 파드의 네트워크 엔드포인트 목록을 수정해요. Elastic Load Balancing으로 외부 트래픽을 클러스터로 라우팅한다면 로드 밸런서를 ARC에 등록하고 존 시프트를 시작해 손상된 AZ로 트래픽이 흐르지 않게 할 수 있어요. EKS Auto Mode를 사용한다면 EKS Auto Mode가 노드 프로비저닝을 정상 AZ로 자동 제한해요. 존 시프트는 EKS 관리형 노드 그룹이 만든 Amazon EC2 Auto Scaling 그룹과도 작동해요. 새 Kubernetes 파드나 노드 시작에 손상된 AZ가 사용되지 않도록 EKS는 Auto Scaling 그룹에서 손상된 AZ를 제거해요.
- 이 기능은 기본 Kubernetes 보호와 어떻게 다른가요? 이 기능은 고객 애플리케이션의 복원력을 돕는 여러 Kubernetes 내장 보호와 함께 작동해요. 파드가 언제 트래픽을 받아야 하는지 결정하는 파드 준비 및 활성 프로브(readiness/liveness)를 구성할 수 있어요. 이 프로브가 실패하면 Kubernetes는 이 파드를 서비스의 대상에서 제거하고 더 이상 파드로 트래픽을 보내지 않아요. 유용하지만, AZ가 저하됐을 때 확실히 실패하도록 고객이 이 상태 확인을 구성하는 것은 간단하지 않아요. ARC 존 시프트 기능은 Kubernetes 네이티브 보호로 부족할 때 손상된 AZ를 완전히 격리하는 데 도움이 되는 추가 안전망을 제공해요. 존 시프트는 또한 아키텍처의 운영 준비와 복원력을 쉽게 테스트할 수 있는 방법을 제공해요.
- AWS가 사용자를 대신해 존 시프트를 시작할 수 있나요? 네, ARC 존 시프트를 완전히 자동화된 방식으로 사용하려면 ARC 존 오토시프트를 활성화할 수 있어요. 존 오토시프트를 사용하면 EKS 클러스터의 AZ 상태를 모니터링하고 AZ 손상이 감지되면 자동으로 존 시프트를 시작하도록 AWS에 의존할 수 있어요.
- 이 기능을 사용할 때 워커 노드와 워크로드가 미리 확장되어 있지 않으면 어떻게 되나요? 미리 확장되어 있지 않아 존 시프트 중 추가 노드나 파드를 프로비저닝하는 데 의존한다면 복구가 지연될 위험이 있어요. Kubernetes 데이터 플레인에 새 노드를 추가하는 과정은 시간이 걸리며, 특히 존 손상 시 애플리케이션의 실시간 성능과 가용성에 영향을 줄 수 있어요. 또한 존 손상 시 정상 AZ에 새로 필요한 노드를 추가하지 못하게 하는 잠재적 컴퓨트 용량 제약에 부딪힐 수 있어요.
- EKS Auto Mode를 사용한다면 EKS Auto Mode가 스케줄할 수 없는 파드 수요를 충족하기 위해 정상 AZ에 새 노드를 자동으로 프로비저닝해요. 하지만 새 노드가 시작되고 준비되기까지 여전히 시간이 걸려요. 가장 빠른 복구를 위해 워크로드를 여러 AZ에 미리 확장할 것을 권장합니다.
- 워크로드가 미리 확장되지 않고 클러스터의 모든 AZ에 분산되지 않았다면, 존 손상이 영향받는 AZ의 워커 노드에서만 실행되는 애플리케이션의 가용성에 영향을 줄 수 있어요. 완전한 가용성 중단의 위험을 완화하기 위해 EKS는 해당 워크로드의 모든 엔드포인트가 비정상 AZ에 있다면 손상된 존의 파드 엔드포인트로 트래픽을 보내는 안전 장치(fail safe)를 갖고 있어요. 하지만 존 문제 시 가용성을 유지하도록 애플리케이션을 모든 AZ에 걸쳐 미리 확장하고 분산할 것을 강력히 권장합니다.
- 상태 저장 애플리케이션을 실행한다면 어떻게 되나요? 상태 저장 애플리케이션을 실행한다면 사용 사례와 아키텍처에 기반해 장애 허용도를 평가해야 해요. 활성/대기 아키텍처나 패턴이 있다면 활성이 손상된 AZ에 있는 경우가 있을 수 있어요. 애플리케이션 수준에서 대기가 활성화되지 않으면 애플리케이션에서 문제가 발생할 수 있어요. 새 Kubernetes 파드가 정상 AZ에서 시작될 때도 문제가 발생할 수 있는데, 손상된 AZ에 바인딩된 영구 볼륨에 연결할 수 없기 때문이에요.
- 이 기능은 EKS Auto Mode와 작동하나요? 네. EKS Auto Mode 클러스터에서 존 시프트를 활성화하면 EKS Auto Mode가 존 시프트 이벤트에 자동으로 응답해요. 존 시프트 중 EKS Auto Mode는 손상된 AZ에서 새 노드 프로비저닝을 중지하고, 손상된 AZ에 영향을 줄 자발적 중단 작업(통합과 드리프트 등)을 중단하며, 손상된 AZ를 대상으로 하는 엄격한 스케줄링 요구 사항이 있는 파드에 대한 용량 시작을 피해요. 클러스터에서 존 시프트를 활성화하는 것 외에 추가 구성이 필요 없어요.
- 이 기능은 자체 관리 Karpenter와 작동하나요? Karpenter 버전 1.12 이상에서 EKS의 ARC 존 시프트와 존 오토시프트로 자체 관리 Karpenter 지원을 사용할 수 있어요.
- 이 기능은 EKS Fargate와 작동하나요? 이 기능은 EKS Fargate에서 작동하지 않아요. 기본적으로 EKS Fargate가 존 상태 이벤트를 인식하면 파드는 다른 AZ에서 실행하는 것을 선호해요.
- EKS 관리형 Kubernetes 제어 플레인은 영향을 받나요? 아니요. 기본적으로 Amazon EKS는 고가용성을 보장하기 위해 Kubernetes 제어 플레인을 여러 AZ에 걸쳐 실행하고 확장해요. ARC 존 시프트와 존 오토시프트는 Kubernetes 데이터 플레인에만 작동해요.
- 이 새 기능과 관련된 비용이 있나요? EKS 클러스터에서 ARC 존 시프트와 존 오토시프트를 추가 비용 없이 사용할 수 있어요. 하지만 프로비저닝된 인스턴스에 대한 비용은 계속 지불하며, 이 기능을 사용하기 전에 Kubernetes 데이터 플레인을 미리 확장할 것을 강력히 권장합니다. 비용과 애플리케이션 가용성 사이의 균형을 고려해야 해요.
추가 리소스 (Additional resources)
- 존 시프트가 어떻게 작동하는지 (How a zonal shift works)
- ARC의 존 시프트 모범 사례 (Best practices for zonal shifts in ARC)
- 존 시프트와 존 오토시프트에 지원되는 리소스와 시나리오 (Resources and scenarios supported for zonal shift and zonal autoshift)
- Amazon EKS에서 복원력 있는 워크로드 운영 (Operating resilient workloads on Amazon EKS)
- 파드 우선순위와 초과 프로비저닝으로 Kubernetes 노드 스케일링 지연 제거 (Eliminate Kubernetes node scaling lag with pod priority and over-provisioning)
- 높은 DNS 트래픽을 위해 CoreDNS 파드 확장 (Scale CoreDNS Pods for high DNS traffic)