약 2개월 전 (2026년 4월 18일)

EKS Workshop - ALB Not Creating 실습

18 views

블로그 불러오는 중...

이 블로그는 NextJS 14, Strapi를 이용해 만들었습니다

문의사항은 admin@devchanki.com 으로 주시면 감사 하겠습니다.

Blog

LinkedIn GitHub

문의 보내기

남겨주면 블로그 주인에게 바로 전달돼요.

AWS EKS Workshop 실습 (1): 기본 환경 셋팅하기

오늘은 EKS Workshop 실습을 해 본다.

공식 워크샵 링크를 클릭하면 실습을 따라 해 볼 수 있다.

하지만 처음에 이 링크만 보고 바로 시작하려다 보니 많이 헤맸다. 본격적인 실습에 앞서 먼저 환경 셋팅을 진행해야 한다.

본인의 AWS 계정으로 자원을 만들어 실습하는 기본적인 방법은 아래 가이드 링크에서 확인할 수 있다.

👉 AWS 계정 셋팅 가이드 링크

아래는 가이드 페이지의 캡쳐 사진이다

나는 하단의 링크를 통해 실습용 자원을 직접 생성했다. (us-west-2 리전 기준)

👉 us-west-2 리전 생성: Launch Stack

1. CloudFormation 스택 생성

AWS에 로그인한 상태에서 위 링크를 클릭하면 CloudFormation 생성 화면이 나온다.

화면 하단에서 동의에 체크하고 스택을 생성한다. 내 경우 스택이 모두 만들어지는 데 약 8분 정도가 소요되었다.

2. 웹 IDE 접속 및 비밀번호 확인

자원 생성이 완료되었으면, CloudFormation의 '출력(Outputs)' 탭에 들어가서 출력된 결과를 확인한다.

출력된 키값 중에서 IdePasswordSecret이라고 적힌 Secrets Manager 링크를 클릭하여 접속한다.

해당 링크로 접속 시 나오는 보안 암호 값을 복사한다. (빨간 상자로 표시된 복사 버튼을 누르면 된다.)

이후 다시 CloudFormation 출력 탭으로 돌아와, 이번에는 IdeUrl이라고 적힌 링크로 접속한 뒤 방금 복사한 비밀번호를 입력해 준다.

3. 쿠버네티스 클러스터 환경 셋팅

비밀번호를 입력하고 들어가면 웹 브라우저 화면에 VS Code가 나타난다. 이제 하단 터미널에 아래 명령어를 입력하여 EKS 쿠버네티스 환경을 셋팅한다.

bash

export EKS_CLUSTER_NAME=eks-workshop
curl -fsSL https://raw.githubusercontent.com/aws-samples/eks-workshop-v2/stable/cluster/eksctl/cluster.yaml | \
envsubst | eksctl create cluster -f -

위 사진과 같이 입력해 준 다음 클러스터 생성이 완료 될 때가지 기다린다(약 20분 소요) 여기까지 잘 따라왔다면 EKS Workshop을 진행하기 위한 기본 셋팅은 모두 마무리되었다.

이제 본격적인 실습을 진행해 보면 된다.

ALB Controller 실습

https://www.eksworkshop.com/docs/troubleshooting/alb/ 페이지로 접속 해 본다.

시작 전 명령어를 입력하라고 한다, 우리도 입력해서 실습 환경을 구축한다.

bash

prepare-environment troubleshooting/alb

해당 명령어를 입력하게 되면 아래와 같은 사진이 나오면서 기본 환경을 셋팅 해 준다.

ALB가 생성되지 않음

AWS 로드 밸런서 컨트롤러가 인그레스 리소스에 대한 애플리케이션 로드 밸런서(ALB)를 생성하지 못하는 이유를 조사하는 것이 이번 실습의 목표이다.

애플리케이션 상태 확인 및 인그레스 확인

kubectl get pod -n ui 명령어를 이용해 ui 네임스페이스에 pod 를 확인해 본다.

bash

ec2-user:~/environment:$ kubectl get pod -n ui
NAME                  READY   STATUS    RESTARTS   AGE
ui-5989474687-nlgj6   1/1     Running   0          72s

파드는 정상적으로 동작중인 것을 볼 수 있다. kubectl get ingress/ui -n ui 명령어를 이용해 ingress 도 확인 해 본다.

bash

ec2-user:~/environment:$ kubectl get ingress/ui -n ui
NAME   CLASS   HOSTS   ADDRESS   PORTS   AGE
ui     alb     *                 80      113s

정상적인 경우엔 주소에 alb 주소가 나와야 하는데 나오지 않아 문제가 있는 것을 확인 할 수 있다.

상태 확인 및 서브넷에 태그 추가

kubectl describe ingress/ui -n ui 명령어를 이용해 상태를 확인한다. 문제의 원인은 로드밸런서가 생성될 서브넷은 태그가 있어야 하는데, 찾지를 못해서 생기는 이슈이다.

aws ec2 describe-subnets --filters "Name=tag:alpha.eksctl.io/cluster-name,Values=${EKS_CLUSTER_NAME}" --query 'Subnets[].SubnetId[]' 명령어로 서브넷을 확인해 본다.

bash

ec2-user:~/environment:$ aws ec2 describe-subnets --filters "Name=tag:alpha.eksctl.io/cluster-name,Values=${EKS_CLUSTER_NAME}" --query 'Subnets[].SubnetId[]'
[
    "subnet-097baf0c8c8fd6492",
    "subnet-00f89ccad467dcfb4",
    "subnet-0d25b9ede0b0ccead",
    "subnet-03601fc2cd885d785",
    "subnet-0aa1a833fa35e9c21",
    "subnet-08e2092879cd35dfd"
]

어느 서브넷이 Public subnet 인지 확인 해본다. 아래 명령어로 확인한다.

bash

for subnet_id in $(aws ec2 describe-subnets --filters "Name=tag:alpha.eksctl.io/cluster-name,Values=${EKS_CLUSTER_NAME}" --query 'Subnets[].SubnetId[]' --output text); do \
    echo "Subnet: ${subnet_id}"; \
    aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=${subnet_id}" \
      --query 'RouteTables[].Routes[].[DestinationCidrBlock,GatewayId]' --output text; \
done

위 사진과 같은 결과가 나오는데, 0.0.0.0/0 이 igw 로 연결된 것이 퍼블릭 서브넷이다. 태그가 있는지 한번 확인 해 본다

aws ec2 describe-subnets --filters 'Name=tag:kubernetes.io/role/elb,Values=1' --query 'Subnets[].SubnetId'

해당 태그가 있는 서브넷이 없다. 아래와 같이 태그 값을 만들어 준다. 위의 public subnet 값을 변경해서 입력하도록 한다.

bash

aws ec2 create-tags --resources subnet-097baf0c8c8fd6492 subnet-0d25b9ede0b0ccead subnet-0aa1a833fa35e9c21 \
      --tags 'Key="kubernetes.io/role/elb",Value=1'

aws ec2 describe-subnets --filters 'Name=tag:kubernetes.io/role/elb,Values=1' --query 'Subnets[].SubnetId' 로 확인한다.

bash

ec2-user:~/environment:$ aws ec2 describe-subnets --filters 'Name=tag:kubernetes.io/role/elb,Values=1' --query 'Subnets[].SubnetId'
[
    "subnet-097baf0c8c8fd6492",
    "subnet-0d25b9ede0b0ccead",
    "subnet-0aa1a833fa35e9c21"
]

정상 적용이 된 것을 확인 가능하다.

load balancer controller 재시작 및 로그 확인

kubectl -n kube-system rollout restart deploy aws-load-balancer-controller 로 재시작한다. 추가로 다시 ingress 확인한다. kubectl describe ingress/ui -n ui 명령어를 입력한다.

위와 같이 권한 문제가 나왔다. 권한 문제를 아래서 해결 해 보자.

AWS LoadBalancer IAM Debug

kubectl get serviceaccounts -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller -o yaml 명령어를 기용해 ServiceAccount 를 확인한다.

bash

ec2-user:~/environment:$ kubectl get serviceaccounts -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller -o yaml
apiVersion: v1
items:
- apiVersion: v1
  automountServiceAccountToken: true
  kind: ServiceAccount
  metadata:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::975372933996:role/alb-controller-20260418125456121100000003
      meta.helm.sh/release-name: aws-load-balancer-controller
      meta.helm.sh/release-namespace: kube-system
    creationTimestamp: "2026-04-18T12:55:00Z"
    labels:
      app.kubernetes.io/instance: aws-load-balancer-controller
      app.kubernetes.io/managed-by: Helm
      app.kubernetes.io/name: aws-load-balancer-controller
      app.kubernetes.io/version: v2.7.1
      helm.sh/chart: aws-load-balancer-controller-1.7.1
    name: aws-load-balancer-controller-sa
    namespace: kube-system
    resourceVersion: "3195"
    uid: f636d808-c433-432c-9b4a-37b97d2b55b2
kind: List
metadata:
  resourceVersion: ""

eks.amazonaws.com/role-arn: arn:aws:iam::975372933996:role/alb-controller-20260418125456121100000003 해당 롤을 가지고 있는데, 해당 롤에 권한이 없다.

사전 정의 된 환경변수가 있어서 아래 명령어를 사용해서 role 에 policy 를 붙여 준다.

bash

aws iam attach-role-policy \
    --role-name ${LOAD_BALANCER_CONTROLLER_ROLE_NAME} \
    --policy-arn ${LOAD_BALANCER_CONTROLLER_POLICY_ARN_FIX}

kubectl -n kube-system rollout restart deploy aws-load-balancer-controller 로 ALB Controller 를 재시작한다.

ALB 생성까지는 시간이 조금 소요되므로, 조금 기다렸다가 kubectl get ingress -n ui 명령어를 입력해 ALB 가 제대로 바인딩 되었는지 확인한다. 해당 트러블 슈팅은 다음과 같이 마무리 되었다.

서비스가 엔드포인트를 등록하지 못함

위에 alb 주소로 접속하게 되면 아래와 같은 사진을 볼 수 있다. 뭔가 정상적이지 않다.

서비스를 확인 해 본다. kubectl -n ui get service/ui -o yaml

bash

ec2-user:~/environment:$ kubectl -n ui get service/ui -o yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/component":"service","app.kubernetes.io/created-by":"eks-workshop","app.kubernetes.io/instance":"ui","app.kubernetes.io/managed-by":"Helm","app.kubernetes.io/name":"ui","helm.sh/chart":"ui-0.0.1"},"name":"ui","namespace":"ui"},"spec":{"ports":[{"name":"http","port":80,"protocol":"TCP","targetPort":"http"}],"selector":{"app.kubernetes.io/component":"service","app.kubernetes.io/instance":"ui","app.kubernetes.io/name":"ui-app"},"type":"ClusterIP"}}
  creationTimestamp: "2026-04-18T12:52:40Z"
  labels:
    app.kubernetes.io/component: service
    app.kubernetes.io/created-by: eks-workshop
    app.kubernetes.io/instance: ui
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: ui
    helm.sh/chart: ui-0.0.1
  name: ui
  namespace: ui
  resourceVersion: "3403"
  uid: d3713ac0-6eb6-4150-954e-319ab00eedb4
spec:
  clusterIP: 172.16.81.69
  clusterIPs:
  - 172.16.81.69
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  selector:
    app.kubernetes.io/component: service
    app.kubernetes.io/instance: ui
    app.kubernetes.io/name: ui-app
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

인그레스도 확인 해 본다. kubectl get ingress/ui -n ui -o yaml

bash

ec2-user:~/environment:$ kubectl get ingress/ui -n ui -o yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /actuator/health/liveness
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.ingress.kubernetes.io/healthcheck-path":"/actuator/health/liveness","alb.ingress.kubernetes.io/scheme":"internet-facing","alb.ingress.kubernetes.io/target-type":"ip"},"name":"ui","namespace":"ui"},"spec":{"ingressClassName":"alb","rules":[{"http":{"paths":[{"backend":{"service":{"name":"service-ui","port":{"number":80}}},"path":"/","pathType":"Prefix"}]}}]}}
  creationTimestamp: "2026-04-18T12:55:34Z"
  finalizers:
  - ingress.k8s.aws/resources
  generation: 1
  name: ui
  namespace: ui
  resourceVersion: "8271"
  uid: e73de185-eb46-43c5-99ac-cef11f54f78b
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - backend:
          service:
            name: service-ui
            port:
              number: 80
        path: /
        pathType: Prefix
status:
  loadBalancer:
    ingress:
    - hostname: k8s-ui-ui-5ddc3ba496-1821313371.us-west-2.elb.amazonaws.com

백엔드 ingress 부분에 서비스 이름이 서비스의 이름과 달라서 매핑이 안되고 있는 상태이다. kubectl edit 으로 수정해도 되고, 실습 내용을 기준으로 똑같이 진행해보려고 한다.

kubectl apply -k ~/environment/eks-workshop/modules/troubleshooting/alb/creating-alb/fix_ingress

해당 파일을 조회 해 보면 결국은 이름을 맞춰 주었다.

bash

ec2-user:~/environment:$ cat ~/environment/eks-workshop/modules/troubleshooting/alb/creating-alb/fix_ingress/ingress.yaml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ui
  namespace: ui
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/healthcheck-path: /actuator/health/liveness
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: ui
                port:
                  number: 80

다 될 줄 알았는데, 조회해 보면 503 에러가 발생한다.

503 이슈 해결

kubectl -n ui get endpoints ui 입력한다.

bash

NAME   ENDPOINTS   AGE
ui     <none>      30m

엔드포인트가 없다. 디플로이와 서비스를 조회한다. kubectl -n ui get deploy/ui -o yaml

kubectl -n ui get svc ui -o yaml 해당 서비스는 해당 부분이 ui-app 으로 되어 있다. 그러므로 서비스가 선택이 되지 않은 상태이다.

kubectl apply -k ~/environment/eks-workshop/modules/troubleshooting/alb/creating-alb/fix_ui 명령어로 사전에 수정된 파일을 적용한다. 적용 이후에, 정상적으로 서비스가 접속이 되는 것을 확인 할 수 있다.

자원 전체 제거

bash

delete-environment
eksctl delete cluster $EKS_CLUSTER_NAME --wait
aws cloudformation delete-stack --stack-name eks-workshop-ide

eksctl delete cluster $EKS_CLUSTER_NAME --wait aws cloudformation delete-stack --stack-name eks-workshop-ide 나는 해당 명령어가 되지 않아서, root 로 들어가서 콘솔에서 계속 삭제 했다.

실습 이후 중요한 정보들

실습을 마치면서 페이지에 정리 된 내용을 AI 를 이용해 정리 해 보았다.

1. 보안 및 운영 핵심 체크리스트

보안(Security)

KMS 키 정책: 암호화를 구현할 때 KMS 키 정책을 올바르게 구성한다.
권한 확인: 서비스 역할(Service Role)에 필요한 권한이 제대로 부여되었는지 확인한다.
배포 전 검증: 실제 환경에 배포하기 전에 보안 구성을 반드시 검증한다.

기본 문제 해결(Troubleshooting) 접근법

리소스 체인 추적: 문제가 발생하면 노드 → 노드 그룹 → Auto Scaling Group(ASG) → 런치 템플릿의 체인을 따라가며 확인한다.
단계별 점검: 각 단계에서 리소스의 건강 상태(Health)와 오류 메시지를 확인하고, 서비스 역할 권한의 누락 여부를 체크한다.

운영 모범 사례(Best Practices)

보안 구현 및 변경 사항은 항상 비운영 환경에서 먼저 테스트한다.
서비스 역할에 필요한 권한은 명확하게 문서화한다.
적절한 오류 처리 및 모니터링 시스템을 구축한다.

2. AWS Load Balancer Controller 아키텍처 복습

컨트롤러가 애플리케이션 로드 밸런서(ALB)와 어떻게 연동되는지 핵심 구성 요소를 살펴본다.

컨트롤러(Controller) 작동 방식
- Kubernetes API 서버에서 발생하는 Ingress 이벤트를 지속적으로 감시한다.
- 적합한 Ingress 리소스를 감지하면 해당 AWS 리소스 생성을 시작하며, 전체 수명 주기를 관리한다.
ALB (Application Load Balancer)
- 각 Ingress 리소스에 대해 하나의 ALB가 생성된다.
- 인터넷 연결형(Internet-facing) 또는 내부 연결형(Internal)으로 구성할 수 있다.
- 서브넷 배치는 Ingress의 어노테이션(Annotation)을 통해 제어하며, 생성 및 관리를 위해서는 적절한 IAM 권한이 필수적이다.
대상 그룹 (Target Group)
- Ingress에 정의된 각 고유한 Kubernetes 서비스(Service)에 대해 생성된다.
- Pod IP로 직접 트래픽을 전달하는 'IP 모드' 타겟팅을 지원한다.
- 상태 점검(Health Check)은 어노테이션을 통해 구성할 수 있으며, 여러 서비스에 대해 여러 대상 그룹을 활용할 수 있다.
리스너 (Listener) & 규칙 (Rules)
- 리스너: 어노테이션에 지정된 포트(기본 80/443)에 대해 생성되며, SSL/TLS 인증서 첨부 및 HTTP/HTTPS 트래픽 구성을 지원한다.
- 규칙: Ingress 리소스의 경로(Path) 사양을 기반으로 생성되어 트래픽을 적절한 대상 그룹으로 유도한다. 경로 기반 및 호스트 기반 라우팅을 지원하며 우선순위 지정이 가능하다.

3. 자주 발생하는 문제 및 해결 방법

ALB 구성 시 자주 발생하는 문제점과 확인해야 할 사항은 다음과 같다.

서브넷(Subnet) 구성

퍼블릭 서브넷에는 반드시 kubernetes.io/role/elb=1 태그가 있어야 한다.
프라이빗 서브넷에는 반드시 kubernetes.io/role/internal-elb=1 태그가 있어야 한다.
각 서브넷이 라우팅 테이블과 올바르게 연결되어 있는지 확인한다.

IAM 권한

K8s 서비스 계정(Service Account)에는 적절한 IAM 역할(IRSA)이 연결되어야 한다.
해당 역할에는 로드 밸런서 및 대상 그룹을 생성하고 수정할 수 있는 권한이 포함되어야 한다.

서비스(Service) 구성

서비스의 셀렉터(Selector)는 타겟이 되는 Pod의 레이블(Label)과 정확히 일치해야 한다.
서비스 포트는 컨테이너 포트와 일치해야 하며, 서비스 이름은 Ingress 백엔드 구성과 동일해야 한다.

4. ALB 운영 모범 사례 및 팁

AWS Load Balancer Controller를 사용할 때 다음 사항들을 권장한다.

인터넷에 연결되는 ALB를 생성하기 전, 서브넷 태그를 항상 먼저 확인한다.
ALB의 동작을 명확하게 제어하려면 명시적인 어노테이션을 사용한다.
문제 해결 시 최우선으로 컨트롤러의 로그를 모니터링하고, 서비스 엔드포인트 등록 상태를 확인한다.
서비스와 Pod에는 직관적이고 의미 있는 레이블을 사용한다.
💡 Tip: 복잡한 사용자 지정 구성이나 심층적인 문제 해결이 필요할 때는 AWS Load Balancer Controller 공식 문서가 가장 유용한 참고 자료다. 꼭 즐겨찾기 해두고 참고하자.