기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon EKS Auto Mode를 활성화할 때 NGINX 수신 컨트롤러 마이그레이션
EKS Auto Mode용 NGINX 수신 컨트롤러 마이그레이션
*Olawale Olaleye 및 Shamanth Devagari, Amazon Web Services*
## 요약
Amazon Elastic Kubernetes Service(Amazon EKS)용 [EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html)는 Kubernetes 클러스터에서 워크로드를 실행하는 데 드는 운영 오버헤드를 줄일 수 있습니다. 이 모드를 사용하면 AWS 가 사용자를 대신하여 인프라를 설정하고 관리할 수도 있습니다. 기존 클러스터에서 EKS Auto Mode를 활성화할 때는 [NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/overview/about/) 구성의 마이그레이션을 신중하게 계획해야 합니다. Network Load Balancer를 직접 전송할 수 없기 때문입니다.
기존 Amazon EKS 클러스터에서 EKS Auto Mode를 활성화하면 블루/그린 배포 전략을 사용하여 NGINX Ingress Controller 인스턴스를 마이그레이션할 수 있습니다.
## 사전 조건 및 제한 사항
**사전 조건 **
+ 활성 AWS 계정
+ Kubernetes 버전 1.29 이상을 실행하는 [Amazon EKS 클러스터](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)
+ [최소 버전을](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html#auto-addons-required) 실행하는 Amazon EKS 추가 기능
+ 최신 버전의 [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html#kubectl-install-update)
+ 기존 [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/deploy/#aws) 인스턴스
+ (선택 사항) DNS 기반 트래픽 시프팅을 위한 Amazon Route 53의 [호스팅 영역](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html)
## 아키텍처
*블루/그린 배포*는 두 개의 별개이지만 동일한 환경을 생성하는 배포 전략입니다. 블루/그린 배포는 가동 중지 시간이 거의 없는 릴리스 및 롤백 기능을 제공합니다. 기본 아이디어는 애플리케이션의 다른 버전을 실행하는 두 개의 동일한 환경 간에 트래픽을 이동하는 것입니다.
다음 이미지는 EKS Auto Mode를 활성화할 때 두 개의 서로 다른 NGINX Ingress Controller 인스턴스에서 Network Load Balancer를 마이그레이션하는 방법을 보여줍니다. 블루/그린 배포를 사용하여 두 Network Load Balancer 간에 트래픽을 이동합니다.
![\[블루/그린 배포 전략을 사용하여 NGINX Ingress Controller 인스턴스 마이그레이션\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/57e8c14f-cb50-4027-8ef6-ce8ea3f2db25/images/211a029a-90d8-4c92-8200-19e54062f936.png)
원래 네임스페이스는 *파란색* 네임스페이스입니다. EKS Auto Mode를 활성화하기 전에 원본 NGINX Ingress Controller 서비스 및 인스턴스가 실행되는 곳입니다. 원래 서비스와 인스턴스는 Route 53에 구성된 DNS 이름을 가진 Network Load Balancer에 연결됩니다. [AWS Load Balancer 컨트롤러는](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.11/) 대상 Virtual Private Cloud(VPC)에이 Network Load Balancer를 배포했습니다.
다이어그램은 블루/그린 배포를 위한 환경을 설정하는 다음 워크플로를 보여줍니다.
1. 다른 네임스페이스인 *그린* 네임스페이스에 다른 NGINX Ingress Controller 인스턴스를 설치하고 구성합니다.
1. Route 53에서 새 Network Load Balancer의 DNS 이름을 구성합니다.
## 도구
**AWS 서비스**
+ [Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다.
+ [Elastic Load Balancing(ELB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)은 들어오는 애플리케이션 또는 네트워크 트래픽을 여러 대상에 분산합니다. 예를 들어 하나 이상의 가용 영역에 있는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 컨테이너, IP 주소 전반에 걸쳐 트래픽을 분산할 수 있습니다.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)는 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.
+ [Amazon Virtual Private Cloud(Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사합니다.
**기타 도구**
+ [Helm](https://helm.sh/)은 Kubernetes 클러스터에서 애플리케이션을 설치하고 관리하는 데 도움이 되는 Kubernetes용 소스 패키지 관리자입니다.
+ [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)는 Kubernetes 클러스터에 대해 명령의 실행을 돕는 명령줄 인터페이스입니다.
+ [NGINX 수신 컨트롤러는](https://docs.nginx.com/nginx-ingress-controller/overview/about/) Kubernetes 앱 및 서비스를 요청 처리, 인증, 셀프 서비스 사용자 지정 리소스 및 디버깅과 연결합니다.
## 에픽
### 기존 환경 검토
| 작업 | 설명 | 필요한 기술 |
| --- | --- | --- |
| 원래 NGINX 수신 컨트롤러 인스턴스가 작동하는지 확인합니다. | 다음 명령을 입력하여 `ingress-nginx` 네임스페이스의 리소스가 작동하는지 확인합니다. NGINX 수신 컨트롤러를 다른 네임스페이스에 배포한 경우이 명령에서 네임스페이스 이름을 업데이트합니다.kubectl get all -n ingress-nginx
출력에서 NGINX Ingress Controller 포드가 실행 중 상태인지 확인합니다. 다음은 출력의 예제입니다.NAME READY STATUS RESTARTS AGE
pod/ingress-nginx-admission-create-xqn9d 0/1 Completed 0 88m
pod/ingress-nginx-admission-patch-lhk4j 0/1 Completed 1 88m
pod/ingress-nginx-controller-68f68f859-xrz74 1/1 Running 2 (10m ago) 72m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ingress-nginx-controller LoadBalancer 10.100.67.255 k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com 80:30330/TCP,443:31462/TCP 88m
service/ingress-nginx-controller-admission ClusterIP 10.100.201.176 443/TCP 88m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ingress-nginx-controller 1/1 1 1 88m
NAME DESIRED CURRENT READY AGE
replicaset.apps/ingress-nginx-controller-68f68f859 1 1 1 72m
replicaset.apps/ingress-nginx-controller-d8c96cf68 0 0 0 88m
NAME STATUS COMPLETIONS DURATION AGE
job.batch/ingress-nginx-admission-create Complete 1/1 4s 88m
job.batch/ingress-nginx-admission-patch Complete 1/1 5s 88m
| DevOps 엔지니어 |
### 샘플 HTTPd 워크로드를 배포하여 NGINX 수신 컨트롤러 사용
| 작업 | 설명 | 필요한 기술 |
| --- | --- | --- |
| Kubernetes 리소스를 생성합니다. | 다음 명령을 입력하여 샘플 Kubernetes 배포, 서비스 및 수신을 생성합니다.kubectl create deployment demo --image=httpd --port=80
kubectl expose deployment demo
kubectl create ingress demo --class=nginx \
--rule nginxautomode.local.dev/=demo:80
| DevOps 엔지니어 |
| 배포된 리소스를 검토합니다. | 배포된 리소스 목록을 보려면 다음 명령을 입력합니다.kubectl get all,ingress
출력에서 샘플 HTTPd 포드가 실행 중 상태인지 확인합니다. 다음은 출력의 예제입니다.NAME READY STATUS RESTARTS AGE
pod/demo-7d94f8cb4f-q68wc 1/1 Running 0 59m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/demo ClusterIP 10.100.78.155 80/TCP 59m
service/kubernetes ClusterIP 10.100.0.1 443/TCP 117m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/demo 1/1 1 1 59m
NAME DESIRED CURRENT READY AGE
replicaset.apps/demo-7d94f8cb4f 1 1 1 59m
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress.networking.k8s.io/demo nginx nginxautomode.local.dev k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com 80 56m
| DevOps 엔지니어 |
| 서비스에 연결할 수 있는지 확인합니다. | 다음 명령을 입력하여 Network Load Balancer의 DNS 이름을 통해 서비스에 연결할 수 있는지 확인합니다.curl -H "Host: nginxautomode.local.dev" http://k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com
예상 출력은 다음과 같습니다.It works!
| DevOps 엔지니어 |
| (선택 사항) DNS 레코드를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps 엔지니어, AWS DevOps |
### 기존 클러스터에서 EKS Auto Mode 활성화
| 작업 | 설명 | 필요한 기술 |
| --- | --- | --- |
| EKS Auto Mode를 활성화합니다. | [기존 클러스터에서 EKS Auto Mode 활성화](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html)(Amazon EKS 설명서)의 지침을 따릅니다. | DevOps |
### 새 NGINX 수신 컨트롤러 설치
| 작업 | 설명 | 필요한 기술 |
| --- | --- | --- |
| 새 NGINX Ingress Controller 인스턴스를 구성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | DevOps 엔지니어 |
| 새 NGINX 인스턴스 컨트롤러 인스턴스를 배포합니다. | 다음 명령을 입력하여 수정된 매니페스트를 적용합니다.kubectl apply -f deploy.yaml
| DevOps 엔지니어 |
| 배포 성공 여부를 확인합니다. | 다음 명령을 입력하여 `ingress-nginx-v2` 네임스페이스의 리소스가 작동하는지 확인합니다.kubectl get all -n ingress-nginx-v2
출력에서 NGINX 수신 컨트롤러 포드가 실행 중 상태인지 확인합니다. 다음은 출력의 예제입니다.NAME READY STATUS RESTARTS AGE
pod/ingress-nginx-admission-create-7shrj 0/1 Completed 0 24s
pod/ingress-nginx-admission-patch-vkxr5 0/1 Completed 1 24s
pod/ingress-nginx-controller-757bfcbc6d-4fw52 1/1 Running 0 24s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ingress-nginx-controller LoadBalancer 10.100.208.114 k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com 80:31469/TCP,443:30658/TCP 24s
service/ingress-nginx-controller-admission ClusterIP 10.100.150.114 443/TCP 24s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ingress-nginx-controller 1/1 1 1 24s
NAME DESIRED CURRENT READY AGE
replicaset.apps/ingress-nginx-controller-757bfcbc6d 1 1 1 24s
NAME STATUS COMPLETIONS DURATION AGE
job.batch/ingress-nginx-admission-create Complete 1/1 4s 24s
job.batch/ingress-nginx-admission-patch Complete 1/1 5s 24s
| DevOps 엔지니어 |
| 샘플 HTTPd 워크로드에 대한 새 수신을 생성합니다. | 다음 명령을 입력하여 기존 샘플 HTTPd 워크로드에 대한 새 수신을 생성합니다.kubectl create ingress demo-new --class=nginx-v2 \
--rule nginxautomode.local.dev/=demo:80
| DevOps 엔지니어 |
| 새 수신이 작동하는지 확인합니다. | 다음 명령을 입력하여 새 수신이 작동하는지 확인합니다.curl -H "Host: nginxautomode.local.dev" k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com
예상 출력은 다음과 같습니다.It works!
| DevOps 엔지니어 |
### 전환
| 작업 | 설명 | 필요한 기술 |
| --- | --- | --- |
| 새 네임스페이스로 전환합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) | AWS DevOps, DevOps 엔지니어 |
| 두 수신을 검토합니다. | 다음 명령을 입력하여 샘플 HTTPd 워크로드에 대해 생성된 두 개의 수신을 검토합니다.kubectl get ingress
다음은 출력의 예제입니다.NAME CLASS HOSTS ADDRESS PORTS AGE
demo nginx nginxautomode.local.dev k8s-ingressn-ingressn-abcdefg-12345.elb.eu-west-1.amazonaws.com 80 95m
demo-new nginx-v2 nginxautomode.local.dev k8s-ingressn-ingressn-2e5e37fab6-848337cd9c9d520f.elb.eu-west-1.amazonaws.com 80 33s
| DevOps 엔지니어 |
## 관련 리소스
+ [기존 클러스터에서 EKS Auto Mode 활성화](https://docs.aws.amazon.com/eks/latest/userguide/auto-enable-existing.html)(Amazon EKS 설명서)
+ [Amazon EKS(re:Post 지식 센터)의 Kubernetes 서비스 컨트롤러에서 생성된 로드 밸런서 문제 해결](https://repost.aws/knowledge-center/eks-load-balancers-troubleshooting)AWS
+ [NGINX Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/)(NGINX 설명서)