[쿠버네티스] ALB 생성/ ALB Add-on/ EKS/ Ingress/ OIDC/ 클러스터 삭제 순서

✅ ALB 생성 - 제일 중요

- ALB의 경우엔 따로 애드온을 설치해야 함

-> 애드온(Add-on)이란?

쿠버네티스에서 기본 기능 외에 추가로 설치해서 클러스터에 새로운 기능을 주는 도구임

예를 들어 스마트폰에 카카오톡 같은 앱을 설치하는 것처럼

쿠버네티스 안에 ingress나 alb 같은 걸 하려면 애드온 설치가 필요함

✅그럼 여기서 ALB Add-on이란?

-> AWS ALB(Application Load Balancer)를 쿠버네티스 안에서 자동으로 만들고 관리할 수 있도록 해주는 컨트롤러

✅왜 그냥 되지 않고 애드온을 설치해야 하냐?

쿠버네티스 기본 설치에는 AWS와 통신할 수 있는 기능이 없음.

그래서:

• ALB를 생성하려면 → AWS 리소스를 제어할 수 있는 권한
• ALB 컨트롤러가 이 역할을 하려면 → IAM Role이 필요
• 이 IAM Role을 K8s에 연결하려면 → OIDC 연동 + ServiceAccount 사용

- 온프레미스 local cluster에는 path기반 라우팅을 하려면 ingress-controller를 설치했었는데,

- AWS의 EKS에서는 Load Balancer Controller를 설치해줘야 함(helm으로)

- 우리가 원하는 건, EKS에서 ingress를 생성했을 때 EKS 애드온인 LB Controller가 ALB를 생성하는 것임

- 이를 위해선 LoadBalancer Controller가 AWS에 ALB를 생성할 수 있는 권한이 있어야 함

- 그러려면 IAM에서 생성한 Role(역할)을 EKS의 SA에 부여해야 하는데, 서로 다른 플랫폼이기 때문에 불가능함

- 따라서 OIDC라는 매개체를 통해 AWS IAM Role을 쿠버네티스의 IRSA에 부여(Assume, LB Controller가 마치 AWS의 리소스인 것처럼 동작) 해야 함

 

- OIDC라는 건 결국 서로 다른 인증/ 인가 체계를 갖는 AWS IAM과 EKS IRSA를 묶어주는 개념이라고 생각해도 무방

- Ingress라는 건 외부에서 서버 내부로 유입되는 트래픽을 의미함

layer 4계층에서는 전송계층 기반으로 url을 기반으로 한 서비스유입이 불가능함

그래서 나온게 ingress임 ingress는 layer 7계층에서 http, https 요청을 처리할 수 있음

세부 특징으로는 서비스에 대한 외부 url을 제공하고 트래픽에 대한 로드밸런싱 SSL인증서 처리 도메인 기반 버추얼 호스팅 지정이 가능함(그래서 도메인 요청이나 /h, 같은 경로로 왔을 때 처리가 가능함)

 

앞에서 사용한 방식들을 사용하기 위해서 

외부에서 들어오는 트래픽이 Ingress양식에 맞게 들어오면

이때 Ingress양식에 맞게 들어오는 애들을 분리하는 애가 Ingress  Controller라고 함 

 

이처럼 클러스터에 적합한 컨트롤러를 선택해야되는데

쿠버네티스에서 지원하는 프로젝트는 AWS, GLE, NGINX Controller등이 있음

앞에서 소개한 컨트롤러 중 AWS의 컨트롤러 중 AWS의 컨트롤러인 AWS Load Blancer에 대해 설명하자

 

클러스터의 ingress 지원 생성 시 ALB  및 필요한 자원들이 생성되도록 트리거하는 컨트롤러임

http 또는 https 트래픽을 클러스터네 pod로 라우팅을 해줌

AWS Load Balancer Controller를 사용해주면 Ingress의 경우 Layer 7 로드밸런서인 ALB로 프로비저닝 되고 Layer4 밸런서인 NLB로 프로비저닝 됨

✅EKS에서 Ingress 생성 시 ALB가 자동 생성되기까지의 흐름

✅ 1. 사용자의 목적

"Ingress를 만들면 자동으로 ALB도 만들어져야 해"

이걸 해주는 주인공이 바로 AWS Load Balancer Controller인데,
이 친구는 그냥 K8s 리소스일 뿐이라, AWS 리소스(ALB)를 직접 만들 수 없음.

 

✅ 3. 해결: OIDC (OpenID Connect)

• OIDC는 인증 브릿지로 뭘 연결해 주나?
• aws iam과 쿠버네티스를 연결해 주는데 이때 쿠버네티스가 iam권한을 aws user라고 거짓말을 하고 연결함
  • 이걸 IRSA (IAM Role for Service Account)라고 불러

✅ 2. 문제: 서로 다른 플랫폼

플랫폼 특징

AWS IAM	ALB, EC2, S3 등을 제어
Kubernetes	Pod, Ingress, SA 등만 관리

서로 인증 체계가 다름 → 권한 전달이 불가능함

 

✅ 4. 그림 설명 연결

▶ 위쪽 (AWS 영역)

• Policy: "ALB를 생성할 수 있다", "Target Group을 만들 수 있다" 같은 권한 설정
• Role: 이 정책을 포함한 역할 (예: AmazonEKSLoadBalancerControllerRole)
• ALB Controller가 이 Role을 "Assume"해서 AWS 리소스를 제어함

▶ 아래쪽 (Kubernetes 영역)

• Service Account (SA): LB Controller가 사용할 전용 계정
• SA에 연결된 IAM Role (IRSA)이 있어야 ALB 생성 가능
• LB Controller Pod는 이 SA를 사용해서 AWS Role을 Assume

🔗 중간 연결 (OIDC)

• AWS IAM Role → 조건으로 "이 OIDC 발급자에서 온 요청만 허용"
• EKS 클러스터 생성 시 OIDC 발급자를 등록해야 이게 가능

✅ 전체 흐름 다시 요약

1. 사용자가 Ingress 생성
2. LB Controller가 감지 → ALB 생성 필요!
3. SA를 통해 IAM Role(정책 포함)을 "Assume"
4. 이 과정에서 OIDC 인증으로 연결 허용
5. AWS에 ALB, Target Group, Listener 등이 자동으로 생성

Helm을 사용하여 AWS Load Balancer Controller 설치

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/lbc-helm.html

Helm을 사용하여 AWS Load Balancer Controller 설치 - Amazon EKS

 - AWS LB Controller 생성 가이드

 1. 정책을 생성

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.12.0/docs/install/iam_policy.json

- json 형태의 AWS Policy 다운로드

aws iam create-policy \
	--policy-name AWSLoadBalancerControllerIAMPolicy \
	--policy-document file://iam_policy.json

- iam_policy.json파일로 AWSLoadBalancerControllerIAMPolicy라는 정책(Policy) 생성

aws sts get-caller-identity

- 내 계정 정보 조회

 

export CLUSTER_NAME=<내 클러스터 이름>

export ACCOUNT_ID=<내계정ID>

export VPC_ID=<EKS설치된 vpc의 ID>

export REGION=ap-northeast-2

export CLUSTER_NAME=rapa-cluster
export ACCOUNT_ID=922805825674
export VPC_ID=vpc-08e36ef667e2be2a9
export REGION=ap-northeast-2

eksctl utils associate-iam-oidc-provider --cluster $CLUSTER_NAME --approve

- OIDC 활성화. 내 클러스터의 OIDC를 AWS IAM에 등록

 - OIDC를 활성화하면 AWS IAM에 자격증명공급자가 생성

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

- 위에서 생성한 AWSLoadBalancerControllerIAMPolicy라는 정책으로 AmazonEKSLoadBalancerControllerRole라는 IAM Role을 생성한 다음, 이 IAM Role을 aws-load-balancer-controller라는 IRSA에게 부여하겠음

- 나중에 헬름으로 LB Controller를 설치하면 이 IRSA가 들어갈 것

eksctl utils describe-addon-versions --kubernetes-version 1.32 | grep AddonName

- 설치 가능한 다양한 애드온들을 확인할 수 있음 

- 사전 준비는 끝났고, 이제 헬름으로 로드밸런서 컨트롤러를 설치하면 됨

 

root@aws-cli:~# curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
root@aws-cli:~# chmod 700 get_helm.sh 
root@aws-cli:~# ./get_helm.sh 
Downloading https://get.helm.sh/helm-v3.17.3-linux-amd64.tar.gz

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

- 나는 aws-load-balancer-controller라는 헬름 릴리스를 생성할 예정

- eks/ aws-load-balancer-controller 차트를 기반으로 할 예정이고, 아까 생성한 aws-load-balancer-controller이라는 IRSA를 부여할 예정.

- 이 로드밸런서 컨트롤러는 602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/amazon/aws-load-balancer-controller

이라는 ECR에 push 된 이미지를 통해 생성된 파드다. 따라서, 어카운트아이디를 변경하진 마시오!

helm list -n kube-system

- kube-system ns에 잘 생성된 걸 확인할 수 있음

kubectl describe pod -n kube-system aws-load-balancer-controller | grep -i account

- ALB를 생성 가능한 SA

ingress 설정

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/ingress/annotations/

- ALB의 다양한 설정들을 위 페이지의 annotation을 통해 구성 가능함

- acm 설정, 헬스체크, 서브넷 지정, 여러 개의 ingress를 묶을 수도 있음(group)

 

vi ip-ingress.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: "ip-ingress"
  labels:
    app.kubernetes.io/name: "nginx-ingress"
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    #target-type은 ip와 instance가 존재
    #ip: 직접 pod에 트래픽을 인가(주로 이걸 사용함)
    #instance: 인스턴스의 노드포트를 거쳐서 pod에 인가
 
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - pathType: Prefix
            path: /
            backend:
              service:
                name: test
                port:
                  number: 80

root@aws-cli:~# kubectl apply -f ip-ingress.yml 

root@aws-cli:~# kubectl get ingress

root@aws-cli:~# kubectl describe ingress ip-ingress

- ingress를 특정 서브넷에 생성을 할 텐데, 그 서브넷이 특정되지 않았음

- subnet에 tag를 달아줘야 함

- 애초에 만들어줄 때 달아주면 좋음 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/network-load-balancing.html

kubernetes.io/cluster/pric            shared

kubernetes.io/role/elb                    1

#퍼블릭서브넷

 

kubernetes.io/cluster/pric              shared

kubernetes.io/role/internal-elb          1

#프라이빗서브넷

- ingrees path "/"

- svc

 

결과가 잘 나오는 걸 확인하고 꼭 바로 지워주기!! 돈이 많이 들어서 바로 지우는 걸 추천

root@aws-cli:~# kubectl delete -f ip-ingress.yml 
root@aws-cli:~# kubectl delete svc test1

클러스터를 먼저 지우기 전에  ingress랑 ALB를 먼저 지워줘야 됨

- 없어진 걸 확인할 수 있음

eksctl delete cluster pric

- 마지막으로 내가 만든 클러스터 삭제해 주기

클러스터 삭제 순서

1. svc삭제

kubectl get svc

kubectl delete svc <svc name>

 

2. ingress 삭제

kubectl delete ingress <ingress name>

kubectl delete ingress --all

안 지워지면 aws 콘솔에 가서 지우는 걸 추천

 

3.로드밸런서 컨트롤러 헬름 삭제

helm uninstall aws-load-balancer-controller -n kube-system

 

3.클러스터 삭제

eksctl delete cluster <cluster name>

 

4. nat지우고, 탄력 ip도 지우기