home..

EKS는 LB를 만들어준다고!

November 2024 (2630 Words, 15 Minutes)

mont-kim Docker Container Pod Container Kubernetes Service

LB는 누가만들어주는데!!!

쿠버네티스를 하면서 제일 많이 쓴 단어입니다.

쿠버네티스에서 관리되는 L4 컴포넌트인 Service의 종류와, LB

그리고 AWS가 만들어주는 LB를 다시 살펴봅니다.

쿠버네티스 Service 와 AWS LB Controller

서비스 종류

ClusterIP

Untitled.png

NodePort

Untitled1.png

LoadBalancer

기본 모드로는 Instace Mode로 동작합니다.

NLB의 인스턴스 유형이라고 볼 수 있습니다.

Untitled2.png

트래픽 흐름은 다음과 같이 되지만, 다른 LB 설정들과 함께 확인하여, 그 차이점들을 살펴보겠습니다.

NLB IP Mode (with AWS VPC CNI)

Type : LoadBalancer 로 프로비저닝 된 컴포넌트중, AWS LoadBalancer Controller의 NLB IP Mode를 활성화 할떄의 네트워크 흐름입니다.

AWS VPC CNI를 이용한 NLB IP mode는, kubernetes의 service endpoint와 동일한 타겟그룹을 LB에서 direct로 pod ip를 호출하는 형태로 동작합니다.

Untitled3.png

NLB Modes 정리해보기

image.png

how-it-works

  • AWS LB는 인스턴스 모드와 IP모드를 지원합니다.
  • K8s의 경우 한 인스턴스(노드)에 여러 POD가 있을수 있겠죠.
  • 인티스턴스모드의 경우 해당 노드로 트래픽이 도달 후 다시 POD를 찾아서 전달하는 방식으로 이를 위해서는 NodePort를 활용하며, LB에는 노드의 대표 IP가 등록됩니다.
  • IP모드의 경우 노드의 대표 IP를 거치지 않고, 바로 PoD의 IP로 트래픽을 전달하며, 따라서 PoD IP가 직접 LB에 등록됩니다.

공식 Document에 나와있는 Design 문서를 보면 두가지 모드를 한번에 설명해주는 그림이 보입니다

인스턴스 유형에서는 각 노드에 있는 pod까지 nodeport를 통해 인입됩니다.

IP 유형에서는 다이렉트로 pod C의 vpc cni를 통해 direct로 ip에 라우팅이 가능하기때문에, 홉이 줄어드는것을 확인 할 수 있습니다.

인스턴스 유형

[https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-aws-load-balancer-controller-on-amazon-eks/](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-aws-load-balancer-controller-on-amazon-eks/)

https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-aws-load-balancer-controller-on-amazon-eks/

인스턴스 유형에서의 LB 트래픽 흐름을 보면서 갖고있는 설정들에 대해 살펴봅니다.

externalTrafficPolicy 설정에 따라 동작방식과, 네트워크 흐름에서 차이가 발생됩니다.

Cluster

LoadBalancer 타입 (기본 모드) 동작

  • 동작 방식: 이 모드에서는 Kubernetes가 NLB에서 들어오는 트래픽을 모든 클러스터 노드로 분산합니다. 이때 트래픽은 노드 내부의 kube-proxy를 통해 클러스터 IP로 NAT (SNAT) 처리가 됩니다.

Local

ClientIP 유지, 워커 노드의 iptables 사용

  • 동작 방식: 이 모드에서는 트래픽을 특정 노드로 직접 전달하여, 해당 노드에서 kube-proxy가 iptables 규칙을 이용해 트래픽을 포드로 전달합니다. 이 경우 Client IP가 유지되며, 각 노드는 자신이 호스팅하는 포드만 트래픽을 받습니다.

요약 : 외부 클라이언트가 ‘로드밸런서’ 접속 시 부하분산 되어 노드 도달 후 iptables 룰로 목적지 파드와 통신됨

Untitled4.png

Untitled5.png

  • 노드는 외부에 공개되지 않고 로드밸런서만 외부에 공개되어, 외부 클라이언트는 로드밸랜서에 접속을 할 뿐 내부 노드의 정보를 알 수 없다
  • 로드밸런서가 부하분산하여 파드가 존재하는 노드들에게 전달한다, iptables 룰에서는 자신의 노드에 있는 파드만 연결한다 (externalTrafficPolicy: local)
  • DNAT 2번 동작 : 첫번째(로드밸런서 접속 후 빠져 나갈때), 두번째(노드의 iptables 룰에서 파드IP 전달 시)
  • 외부 클라이언트 IP 보존(유지) : AWS NLB 는 타켓이 인스턴스일 경우 클라이언트 IP를 유지, iptables 룰 경우도 externalTrafficPolicy 로 클라이언트 IP를 보존

부하분산 최적화 : 노드에 파드가 없을 경우 ‘로드밸런서’에서 노드에 헬스 체크(상태 검사)가 실패하여 해당 노드로는 외부 요청 트래픽을 전달하지 않는다

IP 유형

AWS LB Controller의 정책 설정이 필요합니다.

[https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-aws-load-balancer-controller-on-amazon-eks/](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-aws-load-balancer-controller-on-amazon-eks/)

deploying-aws-load-balancer-controller

  1. Proxy Protocol v2 비활성화 ⇒ NLB에서 바로 파드로 인입, 단 ClientIP가 NLB로 SNAT 되어 Client IP 확인 불가능
  2. Proxy Protocol v2 활성화 ⇒ NLB에서 바로 파드로 인입 및 ClientIP 확인 가능(→ 단 PPv2 를 애플리케이션이 인지할 수 있게 설정 필요)

AWS LoadBalancer Controller 배포 - Link

# Helm Chart 설치
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

## 설치 확인
kubectl get crd
kubectl get deployment -n kube-system aws-load-balancer-controller
kubectl describe deploy -n kube-system aws-load-balancer-controller | grep 'Service Account'
  Service Account:  aws-load-balancer-controller
 
# 클러스터롤, 롤 확인
kubectl describe clusterrolebindings.rbac.authorization.k8s.io aws-load-balancer-controller-rolebinding
kubectl describe clusterroles.rbac.authorization.k8s.io aws-load-balancer-controller-role

image.png

AWS LBC의 Service Account 할당된것과 맵핑된 정보들을 확인해봅니다.

서비스/파드 배포 테스트 with NLB - 링크 NLB

# 작업용 EC2 - 디플로이먼트 & 서비스 생성
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/2/echo-service-nlb.yaml
cat echo-service-nlb.yaml
kubectl apply -f echo-service-nlb.yaml


# (옵션) 빠른 실습을 위해서 등록 취소 지연(드레이닝 간격) 수정 : 기본값 300초
vi echo-service-nlb.yaml
..
apiVersion: v1
kind: Service
metadata:
  name: svc-nlb-ip-type
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: deregistration_delay.timeout_seconds=60
...
:wq!
kubectl apply -f echo-service-nlb.yaml


# AWS ELB(NLB) 정보 확인
aws elbv2 describe-load-balancers | jq
aws elbv2 describe-load-balancers --query 'LoadBalancers[*].State.Code' --output text
ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-default-svcnlbip`) == `true`].LoadBalancerArn' | jq -r '.[0]')
aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq
TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq -r '.TargetGroups[0].TargetGroupArn')
aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN | jq

image.png


# 웹 접속 주소 확인
kubectl get svc svc-nlb-ip-type -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Pod Web URL = http://"$1 }'

# 파드 로깅 모니터링
kubectl logs -l app=deploy-websrv -f

# 분산 접속 확인
NLB=$(kubectl get svc svc-nlb-ip-type -o jsonpath={.status.loadBalancer.ingress[0].hostname})
curl -s $NLB
for i in {1..100}; do curl -s $NLB | grep Hostname ; done | sort | uniq -c | sort -nr
  *52 Hostname: deploy-echo-55456fc798-2w65p
  48 Hostname: deploy-echo-55456fc798-cxl7z*

image.png

  • 실습 리소스 삭제:
kubectl delete deploy deploy-echo; kubectl delete svc svc-nlb-ip-type

(심화) Pod readiness gate : ALB/NLB 대상(ip mode)이 ALB/NLB의 헬스체크에 의해 정상일 경우 해당 파드로 전달할 수 있는 기능 - Link K8S

Pod Readiness Gate는 Pod가 AWS Load Balancer(예: ALB 또는 NLB) Target Group에 등록되었으며, 해당 Target이 Healthy 상태로 전환되어야만 트래픽을 수신할 수 있게 하는 기능입니다.

  • AWS Load Balancer Controller는 Pod가 생성될 때 Mutating Webhook을 통해 Pod Spec에 필요한 readiness gate 구성을 자동으로 삽입합니다.
  • 이를 통해 새로운 Pod가 Target Group에 등록되고 “Healthy” 상태가 될 때까지 Rolling Update 중에도 기존 Pod는 계속 유지됩니다. 따라서 서비스 중단 없이 배포가 가능합니다.

Target Type에 따른 동작 차이

  • target-type: IP 모드: 트래픽이 직접 Pod IP로 전달됩니다. Pod마다 HealthCheck가 가능하며, pod-readiness-gate를 활용해 ALB/NLB의 상태와 동기화하여 트래픽을 관리합니다.
  • target-type: Instance 모드: 노드를 통해 트래픽이 전달됩니다. 이 모드에서는 각 Pod가 아니라 노드 단위로 Target Group에 등록되므로, pod-readiness-gate는 동작하지 않으며 노드의 Health 상태를 기반으로 트래픽을 관리합니다.

NLB 대상 타켓을 Instance mode 로 설정해보기

NLB IP Target & Proxy Protocol v2 활성화 : NLB에서 바로 파드로 인입 및 ClientIP 확인 설정 - 링크 image 참고

Untitled

# 생성
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: montkim-web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: montkim-web
  template:
    metadata:
      labels:
        app: montkim-web
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: montkim-web
        image: art.montkim.com/utility/httpd:pp
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-nlb-ip-type-pp
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  loadBalancerClass: service.k8s.aws/nlb
  selector:
    app: montkim-web
EOF

해당 image는 제 로컬 repo에 업로드했습니다.

mkdir apache && cd apache

# httpd.conf 추출
docker run --rm httpd:2.4.48 cat /usr/local/apache2/conf/httpd.conf > my-httpd.conf

# PPv2 설정
sed -i "s/\#LoadModule remoteip_module/LoadModule remoteip_module/g" my-httpd.conf
echo 'RemoteIPProxyProtocol On' >> my-httpd.conf

# 빌드
cat <<EOT> Dockerfile
FROM httpd:2.4.48
COPY ./my-httpd.conf /usr/local/apache2/conf/httpd.conf
EOT
docker build -t <도커허브계정>/httpd:pp ./

# 푸시
docker login
docker push <도커허브계정>/httpd:pp

해당 과정으로도 직접 build가 가능합니다.


# 확인
kubectl get svc,ep
kubectl describe svc svc-nlb-ip-type-pp
kubectl describe svc svc-nlb-ip-type-pp | grep Annotations: -A5

# apache에 proxy protocol 활성화 확인
kubectl exec deploy/montkim-web -- apachectl -t -D DUMP_MODULES
kubectl exec deploy/montkim-web -- cat /usr/local/apache2/conf/httpd.conf

# 접속 확인
NLB=$(kubectl get svc svc-nlb-ip-type-pp -o jsonpath={.status.loadBalancer.ingress[0].hostname})
curl -s $NLB

# 지속적인 접속 시도 : 아래 상세 동작 확인 시 유용(패킷 덤프 등)
while true; do curl -s --connect-timeout 1 $NLB; echo "----------" ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; done

# 로그 확인
kubectl logs -l app=montkim-web -f

# 삭제
kubectl delete deploy montkim-web; kubectl delete svc svc-nlb-ip-type-pp

image.png

Ingress

HTTP, HTTPS를 적절히 해석하여 쿠버네티스의 Service로 로드밸런싱 해주는 Web Proxy

AWS Load Balancer Controller + Ingress (ALB) IP 모드 동작 with AWS VPC CNI

그림처럼 EKS Cluster 는 없고, AWS kOps 클러스터가 배포되어 있음

그림처럼 EKS Cluster 는 없고, AWS kOps 클러스터가 배포되어 있음

  • 서비스/파드 배포 테스트 with Ingress(ALB) - ALB

      # 게임 파드와 Service, Ingress 배포
  curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/3/ingress1.yaml
  cat ingress1.yaml
  kubectl apply -f ingress1.yaml
    
  # 모니터링
  watch -d kubectl get pod,ingress,svc,ep -n game-2048
    
  # ALB 생성 확인
  aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-game2048`) == `true`]' | jq
  ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-game2048`) == `true`].LoadBalancerArn' | jq -r '.[0]')
  aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN
  TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq -r '.TargetGroups[0].TargetGroupArn')
  aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN | jq
    
  # Ingress 확인
  kubectl describe ingress -n game-2048 ingress-2048
  kubectl get ingress -n game-2048 ingress-2048 -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"
    
  # 게임 접속 : ALB 주소로 웹 접속
  kubectl get ingress -n game-2048 ingress-2048 -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Game URL = http://"$1 }'
    
  # 파드 IP 확인
  kubectl get pod -n game-2048 -owide
    • ALB 대상 그룹에 등록된 대상 확인 : ALB에서 파드 IP로 직접 전달

    Untitled

    • 파드 3개로 증가
      # 터미널1
  watch kubectl get pod -n game-2048
  while true; do aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN --output text; echo; done
    
  # 터미널2 : 파드 3개로 증가
  kubectl scale deployment -n game-2048 deployment-2048 --replicas 3
    • 파드 1개로 감소
      # 터미널2 : 파드 1개로 감소
  kubectl scale deployment -n game-2048 deployment-2048 --replicas 1
    • 실습 리소스 삭제
      kubectl delete ingress ingress-2048 -n game-2048
  kubectl delete svc service-2048 -n game-2048 && kubectl delete deploy deployment-2048 -n game-2048 && kubectl delete ns game-2048

Kubernetes 어플리케이션을 외부노출하기

쿠버네티스 관점에서의 어플리케이션 외부노출하는 경우의 수 입니다.

AWS 블로그에 꽤나 상세한 내용들이 다루어져있고, 문서에 쉽게 이해가 가능한 그림들이 많습니다.

1편 : 서비스와 인그레스

1편:서비스&인그레스

2편 : AWS 로드밸런서 컨트롤러

2편:AWS_로드밸런서_컨트롤러

3편 : 인그레스 NGINX 컨트롤러

3편:인그레스_NGINX_컨트롤러

1편에서는 쿠버네티스의 내부, 외부통신을 구현한 Service와 Ingress, 그리고 GA로 변경되어 사용가능한 Gateway API 등을 이용한 통신을 설명해줍니다.

2편에서는 External LB인 AWS LB Controller를 이용해 통신을 구현하는 방법을 설명해줍니다.,

3편은 가장 보편적인 Ingress Controller인 Ingress Nginx Controller에 대한 내용을 다룹니다.

image.png

ExternalDNS

쿠버네티스의 컴포넌트인 인그레스, 서비스로 도메인 관련 설정이 들어가있을경우, 해당 애드온이

AWS(Route 53), Azure(DNS), GCP(Cloud DNS) 에 A 레코드(TXT 레코드)로 자동 생성/삭제 해줍니다.

[https://edgehog.blog/a-self-hosted-external-dns-resolver-for-kubernetes-111a27d6fc2c](https://edgehog.blog/a-self-hosted-external-dns-resolver-for-kubernetes-111a27d6fc2c)

reference

ExternalDNS CTRL 권한 주는 방법 3가지 : Node IAM Role, Static credentials, IRSA

AWS Route 53 정보 확인 & 변수 지정 :** Public 도메인 필요**

# 자신의 도메인 변수 지정 : 소유하고 있는 자신의 도메인을 입력하시면 됩니다
MyDomain=montkim.org
echo "export MyDomain=montkim.org" >> /etc/profile

# 자신의 Route 53 도메인 ID 조회 및 변수 지정
aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text
MyDnzHostedZoneId=`aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text`
echo $MyDnzHostedZoneId

# (옵션) A 레코드 타입 모두 조회
aws route53 list-resource-record-sets --output json --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']"

# A 레코드 타입 조회
aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']" | jq

ExternalDNS 설치 - 링크

# EKS 배포 시 Node IAM Role 설정되어 있음
MyDomain=montkim.org

# 자신의 Route 53 도메인 ID 조회 및 변수 지정
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)

# 변수 확인
echo $MyDomain, $MyDnzHostedZoneId

# ExternalDNS 배포
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
cat externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# 확인 및 로그 모니터링
kubectl get pod -l app.kubernetes.io/name=external-dns -n kube-system
kubectl logs deploy/external-dns -n kube-system -f

Service(NLB) + 도메인 연동(ExternalDNS) - 도메인체크

# 테트리스 디플로이먼트 배포
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tetris
  labels:
    app: tetris
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tetris
  template:
    metadata:
      labels:
        app: tetris
    spec:
      containers:
      - name: tetris
        image: bsord/tetris
---
apiVersion: v1
kind: Service
metadata:
  name: tetris
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
    #service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "80"
spec:
  selector:
    app: tetris
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  type: LoadBalancer
  loadBalancerClass: service.k8s.aws/nlb
EOF


# 배포 확인
kubectl get deploy,svc,ep tetris

# NLB에 ExternanDNS 로 도메인 연결
kubectl annotate service tetris "external-dns.alpha.kubernetes.io/hostname=tetris.$MyDomain"
while true; do aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']" | jq ; date ; echo ; sleep 1; done

# Route53에 A레코드 확인
aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']" | jq
aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A'].Name" | jq .[]

# 확인
dig +short tetris.$MyDomain @8.8.8.8
dig +short tetris.$MyDomain

# 도메인 체크
echo -e "My Domain Checker = https://www.whatsmydns.net/#A/tetris.$MyDomain"

# 웹 접속 주소 확인 및 접속
echo -e "Tetris Game URL = http://tetris.$MyDomain"

  • 웹 접속(http) → 화살표키, 일시중지(space bar)

    Untitled

  • 리소스 삭제 :

kubectl delete deploy,svc tetris
  • 리소스 삭제할경우 ExternalDNS가 A 레코드를 삭제해줍니다.

(참고) ACM 퍼블릭 인증서 요청 및 해당 인증서에 대한 Route53 도메인 검증 설정 with AWS CLI

# 각자 자신의 도메인 변수 지정
MyDomain="*.montkim.org"

# ACM 퍼블릭 인증서 요청
CERT_ARN=$(aws acm request-certificate \
--domain-name $MyDomain \
--validation-method 'DNS' \
--key-algorithm 'RSA_2048' \
|jq --raw-output '.CertificateArn')

# 생성한 인증서 CNAME 이름 가져오기
CnameName=$(aws acm describe-certificate \
--certificate-arn $CERT_ARN \
--query 'Certificate.DomainValidationOptions[*].ResourceRecord.Name' \
--output text)

# 생성한 인증서 CNAME 값 가져오기
CnameValue=$(aws acm describe-certificate \
--certificate-arn $CERT_ARN \
--query 'Certificate.DomainValidationOptions[*].ResourceRecord.Value' \
--output text)

# 정상 출력 확인하기
echo $CERT_ARN, $CnameName, $CnameValue

Service(NLB + TLS) + 도메인 연동(ExternalDNS)


apiVersion: v1
kind: Service
metadata:
  name: tetris-nlb
  annotations:
    external-dns.alpha.kubernetes.io/hostname: "nlb.montkim.org"
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "80"
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https"
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: ${CERT_ARN}
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  selector:
    app: tetris
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  type: LoadBalancer

Ingress(ALB + HTTPS) + 도메인 연동(ExternalDNS)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tetris-alb-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-name: "alb-tetris"
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'  
    alb.ingress.kubernetes.io/certificate-arn: ${CERT_ARN}
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  ingressClassname: alb
  rules:
    - host: alb.montkim.org
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: tetris
                port:
                  number: 80

image.png

각 LB별로 TLS 인증서가 잘 붙어있는것들을 확인 할 수 있습니다.

© 2024 mont kim   •  Powered by Soopr   •  Theme  Moonwalk