5. EKS Service

Update : 2022-10-27 / 1H 30min

Kubernetest에서 서비스를 제공하기 위해 ClusterIP, NodePort, LoadBlancer, Ingress 등의 서비스를 제공합니다.이러한 서비스들을 이해하기 위해 직접 랩을 통해 구성해 봅니다.

Cluster IP 기반 배포

Kubernetes에서는 Pod의 전면에서 Pod로 들어오는 트래픽을 전달하는 service 자원이 제공됩니다. 해당 Service 자원은 Pod의 IP 주소와 관계 없이 Pod의 Label Selector를 보고 트래픽을 전달하는 역할을 담당합니다.

Service의 종류는 아래와 같습니다.

• Cluster IP - Service 자원의 기본 타입이며 Kubernetes 내부에서만 접근 가능

• NodePort - 로컬 호스트의 특정 포트를 Serivce의 특정 포트와 연결

• Loadbalancer - AWS CLB, NLB 등과 같은 로드밸런서가 노드 전면에서 처리하는 방식

아래 그림에서 처럼 Service의 기본은 CLUSTER-IP 방식입니다. 외부로 노출되지 않으며, Service에는 Pod Container의 포트를 기술해 줍니다.

CoreDNS와 Service

1.CoreDNS와 Service 역할 확인을 위한 App배포

아래와 같이 새로운 Namespace와 Pod를 생성합니다.

cd ~/environment/myeks/network-test
kubectl apply -f cluster-test-01.yaml
kubectl -n cluster-test-01 get pods
kubectl -n cluster-test-01 get pods -o wide

정상적으로 Pods가 생성되었는지 확인합니다.

kubectl -n cluster-test-01 get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP             NODE                                             NOMINATED NODE   READINESS GATES
cluster-test-01-b86b9c685-8g7rt   1/1     Running   0          94s   10.11.1.103    ip-10-11-3-14.ap-northeast-2.compute.internal    <none>           <none>
cluster-test-01-b86b9c685-lkm56   1/1     Running   0          95s   10.11.38.204   ip-10-11-40-87.ap-northeast-2.compute.internal   <none>           <none>
cluster-test-01-b86b9c685-vxgxq   1/1     Running   0          94s   10.11.16.103   ip-10-11-28-53.ap-northeast-2.compute.internal  

(Option) shell 연결을 편리하게 접속하기 위해 아래와 같이 cloud9 terminal 의 bash profile에 등록합니다.

export ClusterTestPod01=$(kubectl -n cluster-test-01 get pod -o wide | awk 'NR==2' | awk '/cluster/{print $1 } ')
export ClusterTestPod02=$(kubectl -n cluster-test-01 get pod -o wide | awk 'NR==3' | awk '/cluster/{print $1 } ')
export ClusterTestPod03=$(kubectl -n cluster-test-01 get pod -o wide | awk 'NR==4' | awk '/cluster/{print $1 } ')
echo "export ClusterTestPod01=${ClusterTestPod01}" | tee -a ~/.bash_profile
echo "export ClusterTestPod02=${ClusterTestPod02}" | tee -a ~/.bash_profile
echo "export ClusterTestPod03=${ClusterTestPod03}" | tee -a ~/.bash_profile
source ~/.bash_profile

(option) K9s로 접속하거나 bash profile에 등록한 컨테이너들로 각각의 Pod로 접속해 봅니다.

kubectl -n cluster-test-01 exec -it $ClusterTestPod01 -- /bin/sh

앞서 설치한 K9s에서 container에 접속해 봅니다.

k9s -n cluster-test-01

container에서 IP와 DNS주소를 확인해 봅니다. VPC CIDR 주소와 Core DNS Service를 확인할 수 있습니다.

ip a
cat /etc/resolv.conf

AWS VPC CNI 구성은 Pod 생성할 때 마다 ENI를 생성하므로, Pod간 IP 직접 통신이 가능합니다.

## ClusterTestPod01 컨테이너에서 ClusterTestPod02로 Ping Test

/ # ping 10.11.26.206
PING 10.11.29.107 (10.11.29.107) 56(84) bytes of data.
64 bytes from 10.11.29.107: icmp_seq=1 ttl=253 time=0.951 ms
64 bytes from 10.11.29.107: icmp_seq=2 ttl=253 time=0.655 ms

ClusterIP Type

2.ClusterType 소개

Kubernetes 에서 Service는 Pod들이 실행 중인 애플리케이션을 네트워크 서비스로 노출하는 추상적인 방법입니다. 다양한 Service 들 중에서 ClusterIP는 Service - Type의 기본 값입니다.

ClusterIP 타입은 내부에서 사용하도록 노출되며 , 외부에 노출되지 않습니다.

• ClusterIP 타입 종류 - UserSpace Proxy 모드 , iptables Proxy 모드, IPVS Proxy 모드.

3.ClusterIP Server 시험

아래와 같이 ClusterIP 서비스를 배포합니다.

cd ~/environment/myeks/network-test/
kubectl -n cluster-test-01 apply -f cluster-test-01-service.yaml

ClusterIP Service에 대한 yaml 파일은 아래와 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: cluster-test-01-svc
  namespace: cluster-test-01
spec:
  selector:
    app: cluster-test-01
  ports:
   -  protocol: TCP
      port: 8080
      targetPort: 80

ClusterIP Service가 정상적으로 배포되었는지 확인합니다.

kubectl -n cluster-test-01 get services -o wide

아래와 같이 출력됩니다.

kubectl -n cluster-test-01 get services -o wide
NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE     SELECTOR
cluster-test-01-svc   ClusterIP   172.20.4.192   <none>        8080/TCP   3h26m   app=cluster-test-01

ClusterIP service의 A Record는

"ClusterIP Metadata.name"."namesapce".svc.cluster.local. 의 형식을 사용하게 됩니다.

ClusterTest01 로 접속후, "cluster-test-01-svc" ClusterIP Service A Record를 확인합니다. curl을 통해서 Loadbalancing이 정상적으로 이뤄지는지 curl을 통해서 확인해 봅니다.

k9s -n cluster-test-01

k9s에서 Container 1개에 접속해서, Service Record로 접속해 봅니다.

 $ kubectl -n cluster-test-01 get services -o wide
NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE   SELECTOR
cluster-test-01-svc   ClusterIP   172.20.122.173   <none>        8080/TCP   22s   app=cluster-test-01

/ # nslookup 172.20.122.173
173.122.20.172.in-addr.arpa     name = cluster-test-01-svc.cluster-test-01.svc.cluster.local.

/ # curl cluster-test-01-svc.cluster-test-01.svc.cluster.local.:8080
Praqma Network MultiTool (with NGINX) - cluster-test-01-5d8544cf8f-xnplp - 10.11.8.173

CLB Loadbalancer 서비스 기반 구성

4.CLB 기반 ServiceType

Service Type 필드를 LoadBalancer로 설정하여 프로브저닝합니다. Cloud Service Provider의 기본 로드밸런서 타입을 사용하게 되며, AWS의 경우에는 CLB를 사용합니다. CLB는 내부 또는 외부 로드밸런서로 지정이 가능합니다.

5. CLB Service Type 트래픽 흐름

Traffic 흐름은 다음과 같습니다.

• 외부 사용자는 CLB DNS A Record:Port로 접근

• CLB는 NodePort로 LB 처리 (NodePort는 임의로 할당 됩니다.)

• NodePort는 ClusterIP로 Forwarding되고 IPTable에 의해 분산 처리 됩니다.

6. CLB Service 시험

CLB Loadbalance Service Type 을 시험하기 위해 아래와 같이 namespace와 pod,service를 배포합니다.

## clb-test-01 namespace를 생성하고, pod, service를 배포 
kubectl create namespace clb-test-01
kubectl -n clb-test-01 apply -f ~/environment/myeks/network-test/clb-test-01.yaml
kubectl -n clb-test-01 apply -f ~/environment/myeks/network-test/clb-test-01-service.yaml

정상적으로 배포되었는지 아래 Command로 확인합니다

## clb-test-01 namespace의 pod 확인 
kubectl -n clb-test-01 get pod -o wide

## clb-test-01 namespace의 service 확인
kubectl -n clb-test-01 get service -o wide

다음과 같은 결과를 얻을 수 있습니다

kubectl -n clb-test-01 get pod -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP             NODE                                             NOMINATED NODE   READINESS GATES
clb-test-01-66f4b975ff-25mvk   0/1     Running   0          9s    10.11.3.103    ip-10-11-10-88.ap-northeast-2.compute.internal   <none>           <none>
clb-test-01-66f4b975ff-hmm52   1/1     Running   0          9s    10.11.40.163   ip-10-11-35-39.ap-northeast-2.compute.internal   <none>           <none>
clb-test-01-66f4b975ff-vrmx5   0/1     Running   0          9s    10.11.30.212   ip-10-11-30-67.ap-northeast-2.compute.internal   <none>           <none>
kubectl -n clb-test-01 get service -o wide
NAME              TYPE           CLUSTER-IP       EXTERNAL-IP                                                                    PORT(S)          AGE   SELECTOR
clb-test-01-svc   LoadBalancer   172.20.238.198   a2bb893008047439ba29a8df77944bcf-1758389191.ap-northeast-2.elb.amazonaws.com   8080:30975/TCP   10s   app=clb-test-01

아래와 같이 구성됩니다 . nodeport는 별도의 지정이 없으면 생성할때 자동으로 지정됩니다.

아래와 같이 배포된 pod에 접속을 편리하게 하기 위해 Cloud9 IDE terminal Shell에 등록 합니다. (Option)

export Clb_Test_Pod01=$(kubectl -n clb-test-01 get pod -o wide | awk 'NR==2' | awk '/clb-test-01/{print $1 } ')
export Clb_Test_Pod02=$(kubectl -n clb-test-01 get pod -o wide | awk 'NR==3' | awk '/clb-test-01/{print $1 } ')
export Clb_Test_Pod03=$(kubectl -n clb-test-01 get pod -o wide | awk 'NR==4' | awk '/clb-test-01/{print $1 } ')
echo "export Clb_Test_Pod01=${Clb_Test_Pod01}" | tee -a ~/.bash_profile
echo "export Clb_Test_Pod02=${Clb_Test_Pod02}" | tee -a ~/.bash_profile
echo "export Clb_Test_Pod03=${Clb_Test_Pod03}" | tee -a ~/.bash_profile
source ~/.bash_profile

ClbTestPod01에 접속해서 아래와 같이 확인해 봅니다. K9s에서 접속해도 됩니다.

kubectl -n clb-test-01 exec -it $Clb_Test_Pod01 -- /bin/sh
nslookup {cluster-ip}
# Container tcpdump
tcpdump -i eth0 dst port 80 | grep "HTTP: GET"

Cloud9 IDE Terminal에서 CLB External IP:8080 으로 접속합니다.

## clb-test-01-svc external hostname 변수 등록
kubectl -n clb-test-01 get svc clb-test-01-svc --output jsonpath='{.status.loadBalancer.ingress[*].hostname}'
export clb_test_01_svc_name=$(kubectl -n clb-test-01 get svc clb-test-01-svc --output jsonpath='{.status.loadBalancer.ingress[*].hostname}')
echo "export clb_test_01_svc_name=${clb_test_01_svc_name}" | tee -a ~/.bash_profile
source ~/.bash_profile

## clb-test-01-svc external hostname 으로 접속
curl $clb_test_01_svc_name:8080

Node에서 iptable에 설정된 NAT Table, Loadbalancing 구성을 확인해 봅니다.

aws ssm start-session --target $ng_public01_id
sudo -s
iptables -t nat -nvL --line-number | more
iptables -t nat -nvL --line-number | grep clb-test-01-svc
iptables -t nat -nL KUBE-SERVICES

CLB에서는 아래와 같은 다양한 Annotation을 추가하여 CLB의 속성 또는 AWS 자원을 연결해서 사용할 수 있습니다

metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
        # 로드 밸런서가 연결을 닫기 전에, 유휴 상태(연결을 통해 전송 된 데이터가 없음)의 연결을 허용하는 초단위 시간

        service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
        # 로드 밸런서에 교차-영역(cross-zone) 로드 밸런싱을 사용할 지 여부를 지정

        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"
        # 쉼표로 구분된 key-value 목록은 ELB에
        # 추가 태그로 기록됨

        service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""
        # 백엔드가 정상인 것으로 간주되는데 필요한 연속적인
        # 헬스 체크 성공 횟수이다. 기본값은 2이며, 2와 10 사이여야 한다.

        service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
        # 백엔드가 비정상인 것으로 간주되는데 필요한
        # 헬스 체크 실패 횟수이다. 기본값은 6이며, 2와 10 사이여야 한다.

        service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
        # 개별 인스턴스의 상태 점검 사이의
        # 대략적인 간격 (초 단위). 기본값은 10이며, 5와 300 사이여야 한다.

        service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
        # 헬스 체크 실패를 의미하는 무 응답의 총 시간 (초 단위)
        # 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
        # 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.

        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
        # 생성된 ELB에 설정할 기존 보안 그룹(security group) 목록.
        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체하며,
        # '해당 ELB를 위한 고유 보안 그룹 생성'을 오버라이드한다.
        # 목록의 첫 번째 보안 그룹 ID는 인바운드 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향하도록 하는 규칙으로 사용된다.
        # 여러 ELB가 하나의 보안 그룹 ID와 연결되면, 1줄의 허가 규칙만이 워커 노드 보안 그룹에 추가된다.
        # 즉, 만약 여러 ELB 중 하나를 지우면, 1줄의 허가 규칙이 삭제되어, 같은 보안 그룹 ID와 연결된 모든 ELB에 대한 접속이 막힌다.
        # 적절하게 사용되지 않으면 이는 다수의 서비스가 중단되는 상황을 유발할 수 있다.

        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
        # 생성된 ELB에 추가할 추가 보안 그룹 목록
        # 이 방법을 사용하면 이전에 생성된 고유 보안 그룹이 그대로 유지되므로, 각 ELB가 고유 보안 그룹 ID와 그에 매칭되는 허가 규칙 라인을 소유하여
        # 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향할 수 있도록 한다. 여기에 기재되는 보안 그룹은 여러 서비스 간 공유될 수 있다.

        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
        # 로드 밸런서의 대상 노드를 선택하는 데
        # 사용되는 키-값 쌍의 쉼표로 구분된 목록

7.CLB Application 배포

CLB 로드밸런서를 사용하는 간단한 게임 앱을 배포해 봅니다.

kubectl create namespace mario
kubectl apply -f ~/environment/myeks/sample/super_mario.yml 

정상적으로 배포되었는지 확인해 봅니다.

kubectl -n mario get pods,svc

아래와 같이 배포된 것을 확인 할 수 있습니다.

$ kubectl -n mario get pods,svc
NAME                         READY   STATUS    RESTARTS   AGE
pod/mario-7f947cb549-f6nvj   1/1     Running   0          47m
pod/mario-7f947cb549-jbtwd   1/1     Running   0          30m
pod/mario-7f947cb549-vcbz4   1/1     Running   0          30m

NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                                                                   PORT(S)        AGE
service/mario   LoadBalancer   172.20.239.185   a5464e237441947b081e54bc3d0d6031-347620742.ap-northeast-2.elb.amazonaws.com   80:30436/TCP   47m

실제 deployment에 사용된 YAML 을 확인해 봅니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mario
  labels:
    app: mario
  namespace: mario
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mario
  template:
    metadata:
      labels:
        app: mario
    spec:
      containers:
      - name: mario
        image: pengbai/docker-supermario
      nodeSelector:
        nodegroup-type: "managed-frontend-workloads"
---
apiVersion: v1
kind: Service
metadata:
  name: mario
  namespace: mario
spec:
  selector:
    app: mario
  ports:
  type: LoadBalancer
  ports:
   -  protocol: TCP
      port: 80
      targetPort: 8080

아래 명령을 통해서 게임앱 URL을 확인하고에 브라우저를 통해 접속해 봅니다.

kubectl -n mario get svc mario | tail -n 1 | awk '{ print "mario URL = http://"$4 }'

3~4분 뒤에 웹 브라우저를 통해 위 명령에서 실행된 URL을 접속하면 , CLB를 통해서 아래와 같이 게임이 실행됩니다.

• "s" - 게임시작

• 방향키로 각 스테이지 이동

• "s" - 점프

• 방향키 - 마리오 이동

8. Loadbalancer 확인.

이제 서비스 타입을 확인하기 위해서 EC2 대시보드에서 Loadbalancer를 확인합니다.

NLB Loadbalancer 서비스 기반 구성

9. NLB 기반 Service Type

Service Type 필드를 LoadBalancer로 설정하여 프로브저닝합니다. CLB와 다르게 반드시 annotation을 통해 NLB를 지정해야 합니다. NLB도 내부 또는 외부 로드밸런서로 지정이 가능합니다. 또한 NLB는 외부의 IP를 PoD까지 그대로 전달 할 수 있습니다

• NLB Annotation

  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"

10.NLB Service Type 트래픽 흐름

Traffic 흐름은 다음과 같습니다.

• 외부 사용자는 NLB DNS A Record:Port로 접근합니다.

• NLB는 NodePort로 LB 처리 (NodePort는 임의로 할당 됩니다.)

• NodePort는 ClusterIP로 Forwarding되고 IPTable에 의해 분산 처리 됩니다.

11. NLB Service 시험

NLB Loadbalance Service Type 을 시험하기 위해 아래와 같이 namespace와 pod,service를 배포합니다.

## nlb-test-01 namespace를 생성하고, pod, service를 배포
kubectl create namespace nlb-test-01
kubectl -n nlb-test-01 apply -f ~/environment/myeks/network-test/nlb-test-01.yaml
kubectl -n nlb-test-01 apply -f ~/environment/myeks/network-test/nlb-test-01-service.yaml

정상적으로 배포되었는지 아래 Command로 확인합니다.

kubectl -n nlb-test-01 get pod -o wide
kubectl -n nlb-test-01 get service -o wide

다음과 같은 결과를 얻을 수 있습니다.

kubectl -n nlb-test-01 get pod -o wide
NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE                                             NOMINATED NODE   READINESS GATES
nlb-test-01-7c5cf9bd5-c8qfj   1/1     Running   0          6m15s   10.11.13.246   ip-10-11-10-88.ap-northeast-2.compute.internal   <none>           <none>
nlb-test-01-7c5cf9bd5-d8j76   1/1     Running   0          6m15s   10.11.39.128   ip-10-11-35-39.ap-northeast-2.compute.internal   <none>           <none>
nlb-test-01-7c5cf9bd5-gsxlk   1/1     Running   0          6m15s   10.11.27.219   ip-10-11-30-67.ap-northeast-2.compute.internal   <none>           <none>

kubectl -n nlb-test-01 get service -o wide
NAME              TYPE           CLUSTER-IP     EXTERNAL-IP                                                                          PORT(S)          AGE   SELECTOR
nlb-test-01-svc   LoadBalancer   172.20.18.55   aaa7c67484fd94ea8a2b6bf1fa091017-374347eabaa0875f.elb.ap-northeast-2.amazonaws.com   8080:31965/TCP   28s   app=nlb-test-01

아래와 같이 구성됩니다 . nodeport는 별도의 지정이 없으면 생성할때 자동으로 지정됩니다.

아래와 같이 배포된 pod에 접속을 편리하게 하기 위해 Cloud9 IDE terminal Shell에 등록 합니다.

export Nlb_Test_01_Pod01=$(kubectl -n nlb-test-01 get pod -o wide | awk 'NR==2' | awk '/nlb-test-01/{print $1 } ')
export Nlb_Test_01_Pod02=$(kubectl -n nlb-test-01 get pod -o wide | awk 'NR==3' | awk '/nlb-test-01/{print $1 } ')
export Nlb_Test_01_Pod03=$(kubectl -n nlb-test-01 get pod -o wide | awk 'NR==4' | awk '/nlb-test-01/{print $1 } ')
echo "export Nlb_Test_01_Pod01=${Nlb_Test_01_Pod01}" | tee -a ~/.bash_profile
echo "export Nlb_Test_01_Pod02=${Nlb_Test_01_Pod02}" | tee -a ~/.bash_profile
echo "export Nlb_Test_01_Pod03=${Nlb_Test_01_Pod03}" | tee -a ~/.bash_profile
source ~/.bash_profile

앞서 생성된 NLB 주소로 접속을 시도해 봅니다.Cloud9 IDE Terminal에서 NLB External IP:8080 으로 접속합니다.

## nlb-test-01-svc external hostname 변수 등록
export nlb_test_01_svc_name=$(kubectl -n nlb-test-01 get svc nlb-test-01-svc --output jsonpath='{.status.loadBalancer.ingress[*].hostname}')
echo "export nlb_test_01_svc_name=${nlb_test_01_svc_name}" | tee -a ~/.bash_profile
source ~/.bash_profile

## nlb-test-01-svc external hostname 으로 접속
curl $nlb_test_01_svc_name:8080

NlbTestPod01에 접속해서 아래와 같이 확인해 봅니다.

#Nlb_Test_01_Pod01 Container 접속
kubectl -n nlb-test-01 exec -it $Nlb_Test_01_Pod01 -- /bin/sh

#Nlb_Test_01_Pod01 Container 에서 HTTP 접속 확인
tcpdump -i eth0 dst port 80 | grep "HTTP: GET"

12.NLB Application 배포

NLB 로드밸런서를 사용하는 간단한 게임 앱을 배포해 봅니다.

kubectl create namespace tetris
kubectl apply -f ~/environment/myeks/sample/tetris.yml 

정상적으로 배포되었는지 확인해 봅니다.

kubectl -n tetris get pods,svc

아래와 같이 배포된 것을 확인 할 수 있습니다.

$ kubectl -n tetris get pods,svc
NAME                         READY   STATUS    RESTARTS   AGE
pod/mario-7f947cb549-f6nvj   1/1     Running   0          47m
pod/mario-7f947cb549-jbtwd   1/1     Running   0          30m
pod/mario-7f947cb549-vcbz4   1/1     Running   0          30m

NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                                                                   PORT(S)        AGE
service/mario   LoadBalancer   172.20.239.185   a5464e237441947b081e54bc3d0d6031-347620742.ap-northeast-2.elb.amazonaws.com   80:30436/TCP   47m

실제 deployment에 사용된 YAML 을 확인해 봅니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tetris
  labels:
    app: tetris
  namespace: tetris
spec:
  replicas: 3
  selector:
    matchLabels:
      app: tetris
  template:
    metadata:
      labels:
        app: tetris
    spec:
      containers:
      - name: tetris
        image: bsord/tetris
      nodeSelector:
        nodegroup-type: "managed-frontend-workloads"
---
apiVersion: v1
kind: Service
metadata:
  name: tetris
  annotations:
    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"
  namespace: tetris
spec:
  externalTrafficPolicy: Local
  selector:
    app: tetris
  type: LoadBalancer
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80

아래 명령을 통해서 게임앱 URL을 확인하고에 브라우저를 통해 접속해 봅니다.

kubectl -n tetris get svc tetris | tail -n 1 | awk '{ print "tetris-game URL = http://"$4 }'

브라우저를 통해 접속하면 아래와 같이 게임이 실행됩니다.

NLB는 배포시간이 5분 정도 소요 됩니다.