오늘부터는 드디어 온프레미스 쿠버네티스를 벗어나서 AWS의 관리형 쿠버네티스 서비스인 EKS(Elastic Kubernetes Service)를 다뤘다. 직접 마스터노드를 구성하고 관리하던 것과 달리, EKS에서는 컨트롤 플레인을 AWS가 알아서 관리해준다. 덕분에 우리는 워커노드(노드그룹)에만 집중하면 된다.
EKS는 크게 두 부분으로 나뉜다.
eks(VM) ──kubectl──▶ Control Plane (AWS가 관리)
│
Node Group (Worker 1, Worker 2)
EKS를 조작하려면 별도의 VM(여기선 eks 서버)에 아래 4가지가 필요하다.
aws eks update-kubeconfig로 구성하는 파일)eksctl create cluster \
--vpc-public-subnets subnet-xxxx,subnet-yyyy \
--name myc \
--region ap-northeast-2 \
--version 1.35 \
--nodegroup-name mycng \
--node-type t3.small \
--nodes 2 \
--nodes-min 2 \
--nodes-max 5
내부적으로 CloudFormation이 스크립트를 통해 클러스터를 구성해준다. 클러스터 생성까지 보통 10~12분 정도 걸린다. 만약 실패하면 CloudFormation에서 스택 찌꺼기를 먼저 정리해야 한다.
클러스터 생성이 완료되면 kubeconfig도 자동으로 구성해준다.
# 다른 서버에서 kubeconfig 업데이트할 때
aws eks update-kubeconfig --region ap-northeast-2 --name myc
주의: 프라이빗 서브넷에 워커노드를 배치할 경우, 컨트롤 플레인과 통신하려면 NAT Gateway가 반드시 있어야 한다. 또한 인스턴스 유형에 따라 생성 가능한 Pod 수가 제한된다.
온프레미스에서 ingress-controller를 직접 설치했던 것처럼, EKS에서 ALB를 쓰려면 AWS Load Balancer Controller 애드온을 설치해야 한다.
핵심 개념은 IRSA(IAM Role for Service Account)다. EKS의 SA(Service Account)에 AWS IAM Role을 연결해서, 쿠버네티스 리소스가 AWS 리소스(ALB)를 생성할 수 있는 권한을 갖게 하는 방식이다. 서로 다른 플랫폼이기 때문에 OIDC를 매개체로 사용한다.
1. IAM 정책 생성
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy.json
aws iam create-policy \
--policy-name AWSLoadBalancerControllerIAMPolicy \
--policy-document file://iam_policy.json
2. OIDC 등록 및 IRSA 생성
# OIDC를 AWS IAM에 등록
eksctl utils associate-iam-oidc-provider --cluster $CLUSTER_NAME --approve
# IAM Role과 SA를 동시에 생성
eksctl create iamserviceaccount \
--cluster=$CLUSTER_NAME \
--namespace=kube-system \
--name=aws-load-balancer-controller \
--role-name AmazonEKSLoadBalancerControllerRole \
--attach-policy-arn=arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \
--override-existing-serviceaccounts \
--approve
3. Helm으로 Load Balancer Controller 설치
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=$CLUSTER_NAME \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set image.repository=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/amazon/aws-load-balancer-controller \
--set region=ap-northeast-2 \
--set vpcId=$VPC_ID
이후 Ingress를 생성하면 ALB가 자동으로 만들어진다.
annotations:
alb.ingress.kubernetes.io/scheme: internetfacing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
EKS에서 동적 프로비저닝을 하려면 EFS CSI 드라이버 애드온을 설치해야 한다. ALB Controller와 마찬가지로 IRSA를 통해 권한을 부여한다.
# SA 및 Role 생성
eksctl create iamserviceaccount \
--name efs-csi-controller-sa \
--namespace kube-system \
--cluster $CLUSTER_NAME \
--role-name $ROLE_NAME \
--role-only \
--attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--approve
# 애드온 설치
eksctl create addon --cluster $CLUSTER_NAME \
--name aws-efs-csi-driver \
--version latest \
--service-account-role-arn arn:aws:iam::$ACCOUNT_ID:role/$ROLE_NAME \
--force
StorageClass에 EFS ID를 지정하면 PVC 생성 시 PV가 자동으로 만들어진다.
오늘은 EKS의 전반적인 구조부터 클러스터 생성, ALB Controller 설치, EFS 다이나믹 프로비저닝까지 꽤 많은 내용을 다뤘다. 특히 IRSA 개념이 처음엔 복잡해 보였는데, OIDC를 통해 쿠버네티스 SA와 AWS IAM Role을 연결한다는 흐름을 이해하고 나니 훨씬 명확해졌다. 앞으로 EKS에서 뭔가 AWS 리소스를 건드리는 작업을 할 때마다 이 패턴이 반복될 것 같다.
이번 velog는 AWS Kiro를 통해 작성하였다.