BLOG
작년 12월 AWS는 Amazon Elastic Kubernetes Service를 사용하여 AWS Fargate에서 Kubernetes 포드를 실행하는 기능을 출시했습니다. Fargate를 사용하면 Kubernetes 애플리케이션을 위한 EC2 인스턴스를 생성하거나 관리할 필요가 없습니다. 포드가 시작되면 Fargate는 자동으로 주문형 컴퓨팅 리소스를 할당하여 실행합니다.
Fargate는 특히 급증하고 예측할 수 없는 트래픽 패턴이 있는 마이크로 서비스를 실행하고 확장하는 데 유용합니다. Amazon Elastic Load Balancing ABB(Application Load Balancer)는 널리 사용되는 AWS 서비스로, 애플리케이션 계층(계층 7)에서 들어오는 트래픽을 여러 대상(예: Kubernetes 클러스터에서 실행되는 포드)에 걸쳐 로드 밸런싱하는 트래픽이며, 이러한 마이크로 서비스로 트래픽을 얻을 수 있는 효과적인 방법입니다.
오늘 메가존 테크블로그에선 오픈 소스 ALB Ingress Controller를 사용하여 Fargate 포드에 대한 수신 기반로드 밸런싱을 위해 EKS 클러스터와 함께 AWS Application Load Balancer (ALB)를 설정하는 방법을 보여드리겠습니다. ALB Ingress 컨트롤러를 사용한 Kubernetes Ingress에 대한 자세한 내용은 해당 페이지를 참고해 주시기 바랍니다.
시작하기 전, Amazon EKS 클러스터와 Fargate 프로필(Fargate에서 포드를 시작할 수 있도록 함)을 생성하고, 클러스터의 서비스 계정에 대한 IAM 역할을 구현하여 수신 컨트롤러 포드에 세분화된 IAM 권한을 부여해보도록 하겠습니다. 간단한 nginx 서비스를 배포하고 ALB를 사용하여 인터넷에 노출하시면 됩니다.
다음 다이어그램은 최종 아키텍처를 보여주고 있습니다.
전제 조건
이를 성공적으로 실행하려면 EKS 시작 안내서의 각 단계를 따르고(클러스터를 만들지 마세요.), 아래의 구성 요소가 설치되어 있는지 확인해 주셔야 합니다.
- EKS CLI인 eksctl (예를 들어 brew tap weaveworks/tap 및brew install weaveworks/tap/eksctl의 macOS)
- 최신 버전의 AWS CLI
- kubectl(Kubernetes CLI)
참고)Homebrew 설치를 사용하여 macOS에 eksctl을 설치한 경우 kubectl은 이미 시스템에 설치되어 있음 - jq
위의 모든 것이 올바르게 설치되었다면 다음 과정으로 넘어가 보겠습니다.
클러스터 프로비저닝
첫 번째 단계는 eksctl을 사용하여 Amazon EKS 클러스터를 생성하는 것입니다. Amazon EKS용 AWS Fargate는 현재 버지니아 북부, 오하이오, 아일랜드 및 도쿄 리전에서 사용할 수 있으므로 이 지역 중 하나에서 클러스터를 생성하고 있는지 확인해 주십시오
그 후 다음 명령을 실행하여 클러스터를 작성합니다.
참고: <aws_region>을 사용중인 리전으로 바꿔주세요. (예 : us-east-1, us-east-2, eu-west-1 또는 ap-northeast-1)
AWS_REGION=<aws_region>CLUSTER_NAME=eks–fargate–alb–demo
eksctl create cluster —name $CLUSTER_NAME —region $AWS_REGION —fargate
eksctl 도구를 사용하여 클러스터를 생성하고 플래그 –fargate를 전달하면 eksctl 도구는 클러스터뿐만 아니라 Fargate 프로필도 생성 하므로 클러스터 관리자가 Fargate에서 실행할 포드를 지정할 수 있습니다. eksctl에 의해 작성된 기본 프로파일은 기본 및 kube 시스템 네임 스페이스의 모든 항목을 Fargate에 맵핑합니다. 새로운 Fargate 프로파일을 생성하여 실행중인 앱과 컨트롤러를 분리할 수 있습니다. 이렇게 하면 포드가 Fargate에 배포되는 방식을 관리할 수 있는 보다 세분화된 기능이 제공됩니다.
클러스터 생성이 완료되면 다음 명령을 실행하여 모든 것이 제대로 진행되었는지 확인할 수 있습니다.
kubectl get svc
다음과 같은 응답이 나타납니다.
NAME TYPE CLUSTER–IP EXTERNAL–IP PORT(S) AGEkubernetes ClusterIP 10.100.0.1 <none> 443/TCP 16h
이 응답은 클러스터가 실행 중이며 Kubernetes API와 통신할 수 있음을 의미합니다.
클러스터와 함께 OIDC 공급자를 설정하고 ALB 수신 컨트롤러에서 사용하는 IAM 정책을 만듭니다.
이제 클러스터가 시작되어 실행 중이므로 AWS에서 OIDC ID 공급자 (IdP)를 설정해보겠습니다. 이 단계는 서비스 계정용 IAM 기능을 사용하여 클러스터에서 실행중인 Fargate 포드에 IAM 권한을 부여하는 데 필요합니다. 다음 명령을 사용하여 클러스터에 대한 OIDC 제공자를 설정하십시오.
eksctl utils associate–iam–oidc–provider —cluster $CLUSTER_NAME —approve
참고: 서비스 계정의 IAM 역할에 대한 자세한 내용은 다음 블로그 게시물을 참고 부탁 드립니다. .
다음 단계는 ALB Ingress Controller 배포에 사용될 IAM 정책을 생성하는 것입니다. 이 정책은 나중에 Kubernetes 서비스 계정과 연결되며 ALB 수신 컨트롤러 포드가 AWS 계정에서 ALB 리소스를 생성 및 관리할 수 있도록 합니다. IAM 정책 예제 문서를 다운로드 하여 생성하십시오.
wget –O alb–ingress–iam–policy.json https://raw.githubusercontent.com/kubernetes–sigs/aws–alb–ingress–controller/master/docs/examples/iam–policy.json
aws iam create-policy –policy-name ALBIngressControllerIAMPolicy –policy-docume
클러스터 역할, 역할 바인딩 및 Kubernetes 서비스 계정 생성
다음으로 환경 변수를 채워 보도록 하겠습니다.
STACK_NAME=eksctl-$CLUSTER_NAME-clusterVPC_ID=$(aws cloudformation describe–stacks —stack–name “$STACK_NAME“ | jq –r ‘[.Stacks[0].Outputs[] | {key: .OutputKey, value: .OutputValue}] | from_entries’ | jq –r ‘.VPC’)
AWS_ACCOUNT_ID=$(aws sts get–caller–identity | jq –r ‘.Account’)
이제 클러스터 역할 및 역할 바인딩을 작성해 줍니다.
cat > rbac–role.yaml <<-EOF—apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: app.kubernetes.io/name: alb–ingress–controller name: alb–ingress–controllerrules: – apiGroups: – “” – extensions resources: – configmaps – endpoints – events – ingresses – ingresses/status – services verbs: – create – get – list – update – watch – patch – apiGroups: – “” – extensions resources: – nodes – pods – secrets – services – namespaces verbs: – get – list – watch—apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: labels: app.kubernetes.io/name: alb–ingress–controller name: alb–ingress–controllerroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: alb–ingress–controllersubjects: – kind: ServiceAccount name: alb–ingress–controller namespace: kube–systemEOF
kubectl apply –f rbac–role.yaml
clusterrole.rbac.authorization.k8s.io/alb–ingress–controller created
clusterrolebinding.rbac.authorization.k8s.io/alb–ingress–controller created
마지막으로 Kubernetes 서비스 계정을 작성합니다.
eksctl create iamserviceaccount \—name alb–ingress–controller \—namespace kube–system \—cluster $CLUSTER_NAME \—attach–policy–arn arn:aws:iam::$AWS_ACCOUNT_ID:policy/ALBIngressControllerIAMPolicy \
—approve
이 eksctl 명령은 IAM 역할을 가진 새 CloudFormation 스택을 배포합니다. 다음 단계를 계속 실행하기 전에 완료될 때까지 기다리십시오.
ALB 수신 컨트롤러 배포
이제 ALB Ingress 컨트롤러를 클러스터에 배포하겠습니다.
본 예제에서는 ALB Ingress Controller 버전 1.1.4를 사용합니다. 공식 GitHub 리포지토리에서 ALB 수신 컨트롤러 및 배포 프로세스에 대한 자세한 정보를 보실 수 있습니다.
cat > alb–ingress–controller.yaml <<-EOF
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: alb–ingress–controller
name: alb–ingress–controller
namespace: kube–system
spec:
selector:
matchLabels:
app.kubernetes.io/name: alb–ingress–controller
template:
metadata:
labels:
app.kubernetes.io/name: alb–ingress–controller
spec:
containers:
– name: alb–ingress–controller
args:
– —ingress–class=alb
– —cluster–name=$CLUSTER_NAME
– —aws–vpc–id=$VPC_ID
– —aws–region=$AWS_REGION
image: docker.io/amazon/aws–alb–ingress–controller:v1.1.4
serviceAccountName: alb–ingress–controller
EOF
kubectl apply –f alb–ingress–controller.yaml
클러스터에 샘플 애플리케이션 배치
이제 수신 컨트롤러가 실행되었으므로 애플리케이션을 클러스터에 배포하고 ingress를 노출할 리소스를 만들 수 있습니다.
그럼 배포부터 시작하겠습니다.
cat > nginx–deployment.yaml <<-EOFapiVersion: extensions/v1beta1kind: Deploymentmetadata: name: “nginx-deployment” namespace: “default”spec: replicas: 3 template: metadata: labels: app: “nginx” spec: containers: – image: nginx:latest imagePullPolicy: Always name: “nginx” ports: – containerPort: 80EOF
kubectl apply –f nginx–deployment.yaml
출력은 다음과 유사해야 합니다.
deployment.apps/alb–ingress–controller created
그런 다음 NGINX 포드를 노출할 수 있도록 서비스를 만들어 보겠습니다.
cat > nginx–service.yaml <<-EOFapiVersion: v1kind: Servicemetadata: annotations: alb.ingress.kubernetes.io/target–type: ip name: “nginx-service” namespace: “default”spec: ports: – port: 80 targetPort: 80 protocol: TCP type: NodePort selector: app: “nginx”EOF
kubectl apply –f nginx–service.yaml
출력은 다음과 유사합니다.
deployment.extensions/nginx–deployment created
마지막으로 수신 리소스를 만들어 봅겠습니다.
cat > nginx–ingress.yaml <<-EOFapiVersion: extensions/v1beta1kind: Ingressmetadata: name: “nginx-ingress” namespace: “default” annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet–facing labels: app: nginx–ingressspec: rules: – http: paths: – path: /* backend: serviceName: “nginx-service” servicePort: 80
EOF
kubectl apply -f nginx-ingress.yaml
출력은 다음과 같습니다.
ingress.extensions/nginx–ingress created
모든 작업이 완료되면 다음 명령을 실행하여 ALB URL을 얻을 수 있습니다.
kubectl get ingress nginx–ingress
이 명령의 출력은 다음과 유사합니다.
AME HOSTS ADDRESS PORTS AGE
nginx–ingress * 5e07dbe1–default–ngnxingr–2e9–113757324.us–east–2.elb.amazonaws.com 80 9s
ALB URL은 ADDRESS 필드 아래에 표시됩니다. ALB 상태 확인에서 모든 포드를 상태로 표시하고 트래픽을 보내기 시작하는 데 몇 분이 걸립니다. 다음 명령을 사용하면 모든 대상이 정상인지 확인할 수 있습니다.
LOADBALANCER_PREFIX=$(kubectl get ingress nginx–ingress –o json | jq –r ‘.status.loadBalancer.ingress[0].hostname’ | cut –d– –f1)
TARGETGROUP_ARN=$(aws elbv2 describe–target–groups | jq –r ‘.TargetGroups[].TargetGroupArn’ | grep $LOADBALANCER_PREFIX)
aws elbv2 describe–target–health —target–group–arn $TARGETGROUP_ARN | jq –r ‘.TargetHealthDescriptions[].TargetHealth.State’
출력은 다음과 같아야 합니다.
healthy
healthy
healthy
웹 브라우저에서 수신 주소에 액세스하여 NGINX 인터페이스에 액세스 할 수 있는지 확인해주세요. 다음 명령으로 AWS Fargate를 사용하여 모든 포드가 실행 중인지 확인할 수도 있습니다.
kubectl get pods –o wide
애플리케이션의 모든 포드는 Fargate 호스트에서 실행되고 있습니다.
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx–deployment–64fc4c755d–d7cjg 1/1 Running 0 4m23s 192.168.142.15 fargate–ip–192–168–142–15.us–east–2.compute.internal <none> <none>
nginx–deployment–64fc4c755d–gcrgv 1/1 Running 0 4m23s 192.168.121.4 fargate–ip–192–168–121–4.us–east–2.compute.internal <none> <none>
nginx–deployment–64fc4c755d–xdjng 1/1 Running 0 4m23s 192.168.117.179 fargate–ip–192–168–117–179.us–east–2.compute.internal <none> <none>
이를 통해 인프라를 관리하지 않고 AWS Application Load Balancer를 사용하여 인터넷 또는 다른 애플리케이션에 노출시키지 않고도 Amazon EKS가 포함된 컨테이너에서 애플리케이션을 실행할 수 있어야 합니다.
정리
Amazon EKS에서 Fargate와 함께 ALB Ingress Controler를 사용하려면 다음 단계를 수행해야 합니다.
- ALB Ingress 컨트롤러가 클러스터를 통해 AWS 리소스를 관리할 수 있도록 클러스터로 OIDC 공급자를 설정하고 적절한 권한으로 IAM 정책을 생성합니다.
- 포드를 실행하는 ALB 수신 컨트롤러에 연결될 클러스터 역할, 역할 바인딩 및 Kubernetes 서비스 계정을 만듭니다.
- 애플리케이션을 배치하고 서비스 및 수신 자원을 작성합니다.
공식 제품 페이지에서 AWS Fargate 및 공식 GitHub 리포지토리의 ALB Ingress 컨트롤러에 대한 자세한 내용을 확인할 수 있습니다.
원문 URL: https://aws.amazon.com/ko/blogs/containers/using-alb-ingress-controller-with-amazon-eks-on-fargate/
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 개제하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달드리도록 하겠습니다.