네트워크 단절을 위해 AWS Outposts 로컬 Amazon EKS 클러스터 준비하기
네트워크 단절을 위해 AWS Outposts 로컬 Amazon EKS 클러스터 준비하기
로컬 네트워크가 AWS Cloud와의 연결을 잃은 경우에도 Outpost의 로컬 Amazon EKS 클러스터를 계속 사용할 수 있어요. 이 주제에서는 네트워크 단절에 대비해 로컬 클러스터를 준비하는 방법과 관련 고려 사항을 다룹니다.
출처: 문서
본문
로컬 클러스터는 일시적이고 계획되지 않은 네트워크 단절 중에도 안정성과 지속적인 운영을 가능하게 해요. AWS Outposts는 데이터 센터의 AWS Cloud 확장판 역할을 하는 완전 연결형 제공물로 남아 있습니다. Outpost와 AWS Cloud 사이에 네트워크 단절이 발생하면 연결 복원을 시도하는 것이 좋습니다. 지침은 AWS Outposts 사용 설명서의 AWS Outposts 랙 네트워크 문제 해결 체크리스트를 참고하세요. 로컬 클러스터의 문제를 해결하는 방법에 대한 자세한 내용은 AWS Outposts 로컬 Amazon EKS 클러스터 문제 해결을 참고하세요.
Outposts는 ConnectedStatus 메트릭을 내보내며, 이를 사용해 Outpost의 연결 상태를 모니터링할 수 있어요. 자세한 내용은 AWS Outposts 사용 설명서의 Outposts 메트릭을 참고하세요.
로컬 클러스터는 Kubernetes용 AWS Identity and Access Management 인증자를 사용해 IAM을 기본 인증 메커니즘으로 사용해요. 네트워크 단절 중에는 IAM을 사용할 수 없습니다. 따라서 로컬 클러스터는 네트워크 단절 중에 클러스터에 연결하는 데 사용할 수 있는 x.509 인증서를 사용하는 대체 인증 메커니즘을 지원합니다. 클러스터의 x.509 인증서를 얻고 사용하는 방법에 대한 정보는 네트워크 단절 중 로컬 클러스터 인증을 참고하세요.
네트워크 단절 중에 Route 53에 액세스할 수 없다면 온프레미스 환경에서 로컬 DNS 서버 사용을 고려하세요. Kubernetes 제어 플레인 인스턴스는 정적 IP 주소를 사용합니다. 로컬 DNS 서버를 사용하는 대신 사용하는 호스트를 엔드포인트 호스트 이름과 IP 주소로 구성할 수 있어요. 자세한 내용은 AWS Outposts 사용 설명서의 DNS를 참고하세요.
네트워크 단절 중 애플리케이션 트래픽 증가가 예상된다면 클라우드에 연결된 상태에서 클러스터에 예비 컴퓨팅 용량을 프로비저닝할 수 있어요. Amazon EC2 인스턴스는 AWS Outposts 가격에 포함됩니다. 따라서 예비 인스턴스를 실행해도 AWS 사용 비용에는 영향을 미치지 않습니다.
네트워크 단절 중 워크로드의 생성, 업데이트, 확장 작업을 활성화하려면 애플리케이션의 컨테이너 이미지가 로컬 네트워크를 통해 액세스 가능해야 하고 클러스터에 충분한 용량이 있어야 해요. 로컬 클러스터는 사용자를 위해 컨테이너 레지스트리를 호스팅하지 않습니다. Pod가 이전에 해당 노드에서 실행된 적이 있다면 컨테이너 이미지가 노드에 캐시되어 있어요. 일반적으로 애플리케이션 컨테이너 이미지를 클라우드의 Amazon ECR에서 가져온다면 로컬 캐시 또는 레지스트리 실행을 고려하세요. 네트워크 단절 중 워크로드 리소스에 대한 생성, 업데이트, 확장 작업이 필요하다면 로컬 캐시 또는 레지스트리가 유용해요.
로컬 클러스터는 퍼시스턴트 볼륨의 기본 스토리지 클래스로 Amazon EBS를 사용하고 Amazon EBS CSI 드라이버가 Amazon EBS 퍼시스턴트 볼륨의 수명 주기를 관리합니다. 네트워크 단절 중에는 Amazon EBS가 지원하는 Pod를 생성, 업데이트, 확장할 수 없어요. 이러한 작업에는 클라우드의 Amazon EBS API 호출이 필요하기 때문입니다. 로컬 클러스터에 스테이트풀 워크로드를 배포하고 네트워크 단절 중 생성, 업데이트 또는 확장 작업이 필요하다면 대체 스토리지 메커니즘 사용을 고려하세요.
AWS Outposts가 관련 AWS 리전 내 API(예: Amazon EBS 또는 Amazon S3 API)에 액세스할 수 없으면 Amazon EBS 스냅샷을 생성하거나 삭제할 수 없습니다.
ALB(Ingress)를 AWS Certificate Manager(ACM)와 통합하면 인증서가 AWS Outposts ALB Compute 인스턴스의 메모리에 푸시되어 저장됩니다. 현재의 TLS 종료는 AWS 리전과 연결이 끊어져도 계속 작동합니다. 이 컨텍스트에서의 변경 작업(새 인그레스 정의, 새 ACM 기반 인증서 API 작업, ALB 컴퓨팅 확장, 인증서 교체 등)은 실패합니다. 자세한 내용은 AWS Certificate Manager 사용 설명서의 관리형 인증서 갱신 문제 해결을 참고하세요.
Amazon EKS 제어 플레인 로그는 네트워크 단절 중에 Kubernetes 제어 플레인 인스턴스에 로컬로 캐시됩니다. 재연결 시 로그는 상위 AWS 리전의 CloudWatch Logs로 전송됩니다. Prometheus, Grafana 또는 Amazon EKS 파트너 솔루션을 사용해 Kubernetes API 서버의 메트릭 엔드포인트를 통해 클러스터를 로컬로 모니터링하거나 Fluent Bit를 로그에 사용할 수 있어요.
Outposts에서 AWS Load Balancer Controller를 애플리케이션 트래픽에 사용한다면 AWS Load Balancer Controller가 프론트엔드하는 기존 Pod는 네트워크 단절 중에도 계속 트래픽을 받습니다. 네트워크 단절 중 생성된 새 Pod는 Outpost가 AWS Cloud에 다시 연결될 때까지 트래픽을 받지 못해요. 네트워크 단절 중 확장 요구를 수용하려면 AWS Cloud에 연결된 상태에서 애플리케이션의 복제본 수를 설정하는 것을 고려하세요.
Kubernetes용 Amazon VPC CNI 플러그인은 기본적으로 보조 IP 모드를 사용합니다. WARM_ENI_TARGET=1로 구성되어 플러그인이 사용 가능한 IP 주소의 "전체 탄력적 네트워크 인터페이스" 하나를 유지할 수 있게 해줘요. 단절 상태 중 확장 요구에 따라 WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET 값을 변경하는 것을 고려하세요. 자세한 내용은 GitHub의 플러그인 readme 파일을 참고하세요. 각 인스턴스 유형이 지원하는 최대 Pod 수 목록은 GitHub의 eni-max-pods.txt 파일을 참고하세요.
Kubernetes Pod 장애 조치 동작 튜닝
네트워크 단절 중 Kubernetes 노드 수명 주기 컨트롤러는 NoExecute 효과의 node.kubernetes.io/unreachable 테인트로 도달할 수 없는 노드를 표시해요. 기본적으로 일치하는 톨러레이션이 없는 Pod는 300초(5분) 후 축출됩니다. DaemonSet을 사용하거나, 애플리케이션 Pod에 tolerationSeconds를 구성하거나, 사용자 지정 컨트롤러를 구현해 이 동작을 튜닝할 수 있어요. 이를 통해 임시 단절 중에 불필요한 축출 없이 Pod가 노드에 남아 있을 수 있습니다. 자세한 지침과 예시는 Amazon EKS 모범 사례 가이드의 Kubernetes Pod 장애 조치 동작 튜닝을 참고하세요.
네트워크 단절 중 로컬 클러스터 인증
네트워크 단절 중에는 AWS Identity and Access Management(IAM)를 사용할 수 없어요. 연결이 끊긴 동안 IAM 자격 증명으로 로컬 클러스터에 인증할 수 없습니다. 그러나 단절 중에는 x509 인증서를 사용해 로컬 네트워크를 통해 클러스터에 연결할 수 있어요. 단절 중 사용할 클라이언트 X509 인증서를 다운로드해 저장해야 합니다. 이 주제에서는 클러스터가 단절 상태일 때 인증하는 데 사용할 인증서를 만들고 사용하는 방법을 알아봅니다.
인증서 서명 요청 생성
openssl req -new -newkey rsa:4096 -nodes -days 365 \
-keyout admin.key -out admin.csr -subj "/CN=admin"
Kubernetes에서 인증서 서명 요청 생성
BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: admin-csr
spec:
signerName: kubernetes.io/kube-apiserver-client
request: ${BASE64_CSR}
usages:
- client auth
EOF
kubectl로 인증서 서명 요청 생성
kubectl create -f admin-csr.yaml
인증서 서명 요청 상태 확인
kubectl get csr admin-csr
출력 예시는 다음과 같습니다.
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Pending
Kubernetes가 인증서 서명 요청을 생성했습니다.
인증서 서명 요청 승인
kubectl certificate approve admin-csr
승인을 위해 인증서 서명 요청 상태 재확인
kubectl get csr admin-csr
출력 예시는 다음과 같습니다.
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Approved
인증서 검색 및 검증
kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
인증서를 검증합니다.
cat admin.crt
admin 사용자용 클러스터 역할 바인딩 생성
kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
--user=admin --group=system:masters
단절 상태용 사용자 범위 kubeconfig 생성
다운로드한 admin 인증서를 사용해 kubeconfig 파일을 생성할 수 있어요. 다음 명령에서 my-cluster와 apiserver-endpoint를 바꾸세요.
aws eks describe-cluster --name my-cluster \
--query "cluster.certificateAuthority" \
--output text | base64 --decode > ca.crt
kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
--certificate-authority=ca.crt --server apiserver-endpoint --embed-certs
kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
--client-certificate=admin.crt --client-key=admin.key --embed-certs
kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
--cluster my-cluster --user admin
kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster
kubeconfig 파일을 봅니다.
kubectl get nodes --kubeconfig admin.kubeconfig
Outpost에서 이미 프로덕션에 서비스가 있다면 이 단계를 건너뛰세요. Amazon EKS가 Outpost에서 실행되는 유일한 서비스이고 Outpost가 현재 프로덕션용이 아니라면 네트워크 단절을 시뮬레이션할 수 있어요. 로컬 클러스터로 프로덕션에 들어가기 전에 단절을 시뮬레이션해 단절 상태에서 클러스터에 액세스할 수 있는지 확인하세요.
- Outpost를 AWS 리전에 연결하는 네트워킹 장치에 방화벽 규칙을 적용합니다. 이렇게 하면 Outpost의 서비스 링크가 단절됩니다. 새 인스턴스를 생성할 수 없어요. 현재 실행 중인 인스턴스는 AWS 리전 및 인터넷과의 연결을 잃습니다.
x509인증서를 사용해 단절 중 로컬 클러스터에 대한 연결을 테스트할 수 있어요.kubeconfig를 이전 단계에서 만든admin.kubeconfig로 변경해야 합니다.my-cluster를 로컬 클러스터의 이름으로 바꾸세요.
kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
로컬 클러스터가 단절 상태에 있을 때 문제가 발견되면 지원 티켓을 여는 것이 좋습니다.