[AEWS] 스터디 2주차 - EKS Networking

본 게시물은 CloudNet@에서 진행하는 AEWS (Amazon EKS Workshop Study) 스터디에 참여하며 정리한 내용입니다.

 

1. VPC CNI 소개

그 전에 먼저 CNI에 대해 살펴보자. https://cni.dev 홈페이지 내용을 번역기로 해석한 내용을 아래에 붙여본다.

클라우드 네이티브 컴퓨팅 기반 CNI( Container Network Interface ) 프로젝트는 지원되는 여러 플러그인과 함께 Linux 및 Windows 컨테이너에서 네트워크 인터페이스를 구성하기 위한 플러그인을 작성하기 위한 사양 및 라이브러리로 구성됩니다. CNI는 컨테이너의 네트워크 연결과 컨테이너 삭제 시 할당된 리소스 제거에만 관심이 있습니다. 이러한 초점 때문에 CNI는 광범위한 지원을 제공하며 사양 구현이 간단합니다.

 

이러한 CNI를 쓰는 대표적인 오픈 소스가 바로 쿠버네티스(K8s)로, CNI는 K8s 네트워크 환경을 구성해주는 역할을 하며 링크와 같이 다양한 플러그인이 존재한다. Amazon EKS에서는 amazon-vpc-cni-k8s를 사용하여 쿠버네티스에서 AWS에 있는 Elastic Network Interfaces를 통한 파드 네트워킹을 지원한다. amazon-vpc-cni-k8s가 파드 IP를 할당할 때 파드의 IP 네트워크 내역과 노드(워커) IP 대역이 같아서 직접 통신이 가능하다. 아래 그림에서 볼 수 있듯이, AWS VPC CNI에서는 IP 대역이 변화하지 않는다. 또한 Calico CNI 등 일반적으로 K8s CNI는 오버레이(VXLAN, IP-IP 등) 통신을 하고, AWS VPC CNI는 동일 대역으로 직접 통신을 한다. 

 

동일 대역에서 직접 통신이 이루어지므로 사용 가능한 IP 개수에 제약이 있는 점 또한 참고할 필요가 있겠다. 자세한 내용을 링크에 언급되어 있다고 하니 참고하자. 우선 설치된 EKS 환경에서 CNI 기본 정보를 확인해보자. 명령어는 다음과 같다.

# CNI 정보 확인
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

# 노드 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table

# 파드 IP 확인
kubectl get pod -n kube-system -o=custom-columns=NAME:.metadata.name,IP:.status.podIP,STATUS:.status.phase

 

실행 결과는 다음과 같다. 구성된 환경에서 amazon-vpc-cni-k8s는 최신인 v1.16.4를 사용하고 있으며, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24 3개의 VPC가 구성된 환경에서 노드 IP 주소 및 파드 IP 주소가 동일한 IP 대역을 사용하고 있음을 확인할 수 있었다.

2. 노드 기본 네트워크 정보 확인

노드에서 기본 네트워크 정보가 어떻게 되어 있는지를 보도록 하자. 

 

# coredns 파드 IP 정보 확인
kubectl get pod -n kube-system -l k8s-app=kube-dns -owide

# 노드의 라우팅 정보 확인 >> EC2 네트워크 정보의 '보조 프라이빗 IPv4 주소'와 비교해보자
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo ip -c route; echo; done

 

coredns가 총 2 개 pod로 내포된 상태라 AZ1과 2에 존재하며, 파드 IP 주소 및 라우팅 테이블 IP 주소 모두 노드 IP 주소로 된 것을 확인할 수 있다. AWS 콘솔에서 AZ1에 있는 워커 노드의 Secondary private IPv4 주소와 같음을 확인할 수 있다.

 

이번에는 nicolaka/netshoot 테스트용 pod를 생성하여 라우팅 정보를 확인해보도록 하자.

# [터미널1~3] 노드 모니터링
ssh ec2-user@$N1
watch -d "ip link | egrep 'eth|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"

ssh ec2-user@$N2
watch -d "ip link | egrep 'eth|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"

ssh ec2-user@$N3
watch -d "ip link | egrep 'eth|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"

# 테스트용 파드 netshoot-pod 생성
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot-pod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: netshoot-pod
  template:
    metadata:
      labels:
        app: netshoot-pod
    spec:
      containers:
      - name: netshoot-pod
        image: nicolaka/netshoot
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

# 파드 이름 변수 지정
PODNAME1=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[0].metadata.name})
PODNAME2=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[1].metadata.name})
PODNAME3=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[2].metadata.name})

# 파드 확인
kubectl get pod -o wide
kubectl get pod -o=custom-columns=NAME:.metadata.name,IP:.status.podIP

# 노드에 라우팅 정보 확인
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo ip -c route; echo; done

 

파드가 생성되면 워커노드에 eniY@ifN 이 추가되고 라우팅 테이블에도 정보가 추가됨을 확인할 수 있다.

 

이렇게 추가된 eniY에 대해 자세히 정보를 확인해볼 수도 있다. 워커노드에 접속한 다음, 마지막에 생성된 네트워크 인터페이스에 대한 네임스페이스 정보를 파악하여, 해당 네임스페이스로 진입하여 네트워크 정보를 살펴보는 것도 도움이 되겠다.

# 노드3에서 네트워크 인터페이스 정보 확인
ssh ec2-user@$N3
----------------
ip -br -c addr show
ip -c link
ip -c addr
ip route # 혹은 route -n

# 마지막 생성된 네임스페이스 정보 출력 -t net(네트워크 타입)
sudo lsns -o PID,COMMAND -t net | awk 'NR>2 {print $1}' | tail -n 1

# 마지막 생성된 네임스페이스 net PID 정보 출력 -t net(네트워크 타입)를 변수 지정
MyPID=$(sudo lsns -o PID,COMMAND -t net | awk 'NR>2 {print $1}' | tail -n 1)

# PID 정보로 파드 정보 확인
sudo nsenter -t $MyPID -n ip -c addr
sudo nsenter -t $MyPID -n ip -c route

exit
----------------

 

 

또한 직접 테스트용 파드로 접속하여 확인해볼 수도 있다.

# 테스트용 파드 접속(exec) 후 Shell 실행
kubectl exec -it $PODNAME1 -- zsh

# 아래부터는 pod-1 Shell 에서 실행 : 네트워크 정보 확인
----------------------------
ip -c addr
ip -c route
route -n
ping -c 1 <pod-2 IP>
ps
cat /etc/resolv.conf
exit
----------------------------

 

3. 노드 간 파드 통신

AWS VPC CNI를 사용하는 EKS 디폴트 환경에서는 별도의 오버레이 통신 기술 없이, VPC Native하게 파드 간 직접 통신이 가능하다.

테스트를 하기 위해 tcpdump를 각 워커 노드에 실행한 상태에서 ping을 통해 확인해보았다. 여기서 한 가지, 파드 생성시 순서를 atomic하게 보장하지 않으므로 워커노드 1,2,3 번호와 PODIP 1,2,3 순서가 동일하지 않을 수 있다는 점을 꼭 참고하자.

# 파드 IP 변수 지정
PODIP1=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[0].status.podIP})
PODIP2=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[1].status.podIP})
PODIP3=$(kubectl get pod -l app=netshoot-pod -o jsonpath={.items[2].status.podIP})

# 파드1 Shell 에서 파드2로 ping 테스트
kubectl exec -it $PODNAME1 -- ping -c 2 $PODIP2

# 파드2 Shell 에서 파드3로 ping 테스트
kubectl exec -it $PODNAME2 -- ping -c 2 $PODIP3

# 파드3 Shell 에서 파드1로 ping 테스트
kubectl exec -it $PODNAME3 -- ping -c 2 $PODIP1

# 워커 노드 EC2 : TCPDUMP 확인
sudo tcpdump -i any -nn icmp

 

 

이번에는 eniY 어댑터에 tcpdump를 실행해 확인해보면 해당 eniY 어댑터를 통해 패킷이 이동함을 확인할 수 있다. 또한 워커 노드1에서 실제 ip route 경로를 확인해보자. 디폴트 네트워크 정보를 살펴보면 eth0를 통해 빠져나감을 확인할 수 있다.

ifconfig | grep eni
sudo tcpdump -i eniYYYYYYYYYY -nn icmp

[워커 노드1]
# routing policy database management 확인
ip rule

# routing table management 확인
ip route show table local

# 디폴트 네트워크 정보를 eth0 을 통해서 빠져나감을 확인하자.
ip route show table main
default via 192.168.1.1 dev eth0

 

4. 파드에서 외부 통신

파드에서 외부와 통신하는 흐름을 자세히 살펴보면 iptables에 SNAT을 통해 노트의 eth0 IP로 변경되어 외부와 통신이 이루어지는 것을 확인할 수 있다.

(출처: https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md )

 

워커노드 1을 기준으로 하여 확인해보니 외부 ping에 대해 192.168.1.6 IP 주소 요청이 eth0으로 192.168.1.112인 워커노드1 IP 주소로 변환되어 외부로 요청이 이루어지는 것을 확인할 수 있었다. 관련 iptables NAT 정보도 확인해보았다.

# 작업용 EC2 : pod-1 Shell 에서 외부로 ping
kubectl exec -it $PODNAME1 -- ping -c 1 www.google.com
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i curl -s ipinfo.io/ip; echo; echo; done
for i in $PODNAME1 $PODNAME2 $PODNAME3; do echo ">> Pod : $i <<"; kubectl exec -it $i -- curl -s ipinfo.io/ip; echo; echo; done

# 워커 노드 EC2 : TCPDUMP 확인
sudo tcpdump -i any -nn icmp
sudo tcpdump -i eth0 -nn icmp
sudo iptables -t nat -S | grep 'A AWS-SNAT-CHAIN'

 

실습을 다 한 이후에는 다음 실습을 위해 netshoot 파드를 삭제하도록 하자.

kubectl delete deploy netshoot-pod

 

5. 노드에 파드 생성 개수 제한

실습 내용을 쉽게 확인하기 위해 kube-ops-view를 설치하면 좋다. 다음 명령어를 사용해 설치 가능하다.

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'

# kube-ops-view 접속 URL 확인 (1.5 배율)
kubectl get svc -n kube-system kube-ops-view -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "KUBE-OPS-VIEW URL = http://"$1":8080/#scale=1.5"}'

 

이 공식이 제일 중요하다고 생각된다.

 

최대 파드 생성 갯수 : (Number of network interfaces for the instance type × (the number of IP addresses per network interface - 1)) + 2

 

t3.medium 사용할 때 워커 노드의 인스턴스 정보를 확인해보자.

 

# t3 타입의 정보(필터) 확인
aws ec2 describe-instance-types --filters Name=instance-type,Values=t3.* \
 --query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
 --output table
 
 # c5 타입의 정보(필터) 확인
aws ec2 describe-instance-types --filters Name=instance-type,Values=c5*.* \
 --query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
 --output table

 

# 파드 사용 가능 계산 예시 : aws-node 와 kube-proxy 파드는 host-networking 사용으로 IP 2개 남음
((MaxENI * (IPv4addr-1)) + 2)
t3.medium 경우 : ((3 * (6 - 1) + 2 ) = 17개 >> aws-node 와 kube-proxy 2개 제외하면 15개

# 워커노드 상세 정보 확인 : 노드 상세 정보의 Allocatable 에 pods 에 17개 정보 확인
kubectl describe node | grep Allocatable: -A6

 

 

최대 개수 제한이 걸려 생성되지 않는 상황도 직접 확인해보았다.

# 워커 노드 EC2 - 모니터링
while true; do ip -br -c addr show && echo "--------------" ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; done

# 작업용 EC2 - 터미널1
watch -d 'kubectl get pods -o wide'

# 작업용 EC2 - 터미널2
# 디플로이먼트 생성
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/2/nginx-dp.yaml
kubectl apply -f nginx-dp.yaml

# 파드 확인
kubectl get pod -o wide
kubectl get pod -o=custom-columns=NAME:.metadata.name,IP:.status.podIP

# 파드 증가 테스트 >> 파드 정상 생성 확인, 워커 노드에서 eth, eni 갯수 확인 >> 어떤일이 벌어졌는가?
kubectl scale deployment nginx-deployment --replicas=50

 

 

다음 실습 전에 생성한 배포를 삭제하도록 하자.

kubectl delete deployment nginx-deployment

 

이에 대한 해결 방안으로는 Prefix Delegation, WARM & MIN IP/Prefix Targets, Custom Network 등이 있다고 하니 참고하자.

6. AWS LoadBalancer Controller

서비스에 대한 설명은 https://kubernetes.io/ko/docs/concepts/services-networking/service/ 를 참고하는 것으로 하자. AWS LoadBalancer Controller를 사용하는 모드에서는 Load Balancer Controller 파드를 통해 파드 IP 등 지속적인 정보 제공을 하는 역할을 담당하고 EKS Cluster와 상태를 sync하는 역할 또한 수행한다. 다음 그림은 NLB IP 모드로 동작하는 상황을 보여준다.

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html 문서에 언급된 내용에 따라 다음 명령어를 참고하여 IRSA로 AWS LoadBalancer Controller를 배포하자.

# OIDC 확인
aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.identity.oidc.issuer" --output text
aws iam list-open-id-connect-providers | jq

# IAM Policy (AWSLoadBalancerControllerIAMPolicy) 생성
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.5.4/docs/install/iam_policy.json
aws iam create-policy --policy-name AWSLoadBalancerControllerIAMPolicy --policy-document file://iam_policy.json

# 혹시 이미 IAM 정책이 있지만 예전 정책일 경우 아래 처럼 최신 업데이트 할 것
# aws iam update-policy ~~~

# 생성된 IAM Policy Arn 확인
aws iam list-policies --scope Local | jq
aws iam get-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy | jq
aws iam get-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --query 'Policy.Arn'

# AWS Load Balancer Controller를 위한 ServiceAccount를 생성 >> 자동으로 매칭되는 IAM Role 을 CloudFormation 으로 생성됨!
# IAM 역할 생성. AWS Load Balancer Controller의 kube-system 네임스페이스에 aws-load-balancer-controller라는 Kubernetes 서비스 계정을 생성하고 IAM 역할의 이름으로 Kubernetes 서비스 계정에 주석을 답니다
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

## IRSA 정보 확인
eksctl get iamserviceaccount --cluster $CLUSTER_NAME

## 서비스 어카운트 확인
kubectl get serviceaccounts -n kube-system aws-load-balancer-controller -o yaml | yh

# 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 \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

## 설치 확인 : aws-load-balancer-controller:v2.7.1
kubectl get crd
kubectl get deployment -n kube-system aws-load-balancer-controller
kubectl describe deploy -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

 

이 부분이 진행되어야 7번 Ingress 실습이 가능해진다.

7. Ingress

인그레스는 클러스터 내부의 서비스 (ClusterIP, NodePort, Loadbalancer)를 외부로 노출(HTTP/HTTPS)할 수 있도록 돕는 역할을 하며, 일종의 웹 프록시 역할을 수행한다. AWS Load Balancer Controller + Ingress (ALB) IP 모드 동작을 AWS VPC CNI에서 확인해보자.

 

# 게임 파드와 Service, Ingress 배포
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/3/ingress1.yaml
cat ingress1.yaml | yh
kubectl apply -f ingress1.yaml

# 모니터링
watch -d kubectl get pod,ingress,svc,ep -n game-2048

# 생성 확인
kubectl get-all -n game-2048
kubectl get ingress,svc,ep,pod -n game-2048
kubectl get targetgroupbindings -n game-2048
NAME                               SERVICE-NAME   SERVICE-PORT   TARGET-TYPE   AGE
k8s-game2048-service2-e48050abac   service-2048   80             ip            87s

# 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

 

 

8. 추가 과제: Optimize webSocket applications scaling with API Gateway on Amazon EKS

https://aws.amazon.com/ko/blogs/containers/optimize-websocket-applications-scaling-with-api-gateway-on-amazon-eks/ 블로그에 있는 내용을 실습해보았다. Websocket 기술의 경우 클라이언트와 서버간 실시간 양방향 데이터 교환을 용이하게 하기 위해 사용하는 프로토콜 중 하나이다. 원래 애플리케이션을 최소한으로 변경하면서 장기 실행 클라이언트에 대해서도 자동 크기 조정을 달성할 수 있도록 웹 애플리케이션을 활용하는 부분을 확인해보도록 하자.

 

직접 해보았는데 아쉽게 웹 소켓 연결까지는 되는데 "hello"라고 입력하여도 응답이 오지는 않는다. 기록을 위해 아래와 같이 남겨둔다.

 

필요 환경 준비

- EKS 클러스터 및 ECR 레지스트리는 쉽게 준비 가능하며 AWS Load Balancer Controller 또한 위 6번 내용을 참고하면 된다. wscat을 설치하기 위해서는 node를 설치해야 하는지라 아래 부분을 참고하여 진행하도록 하자.

 

wscat 설치하기

- https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/setting-up-node-on-ec2-instance.html 내용에 따라 설치한다. 다만 최신 lts는 현재 AMI에서 동작하지 않을 수 있으므로 17 정도 버전으로 설치하도록 하자.

- wscat 설치는 " npm install -g wscat " 명령어를 통해 설치가 가능하다.

 

IRSA 정책 생성

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/associate-service-account-role.html 내용을 참고하여 생성해보았다. 다만 처음에 생성한 것이 아닌 아래 6번 과정을 통해 생성이 이루어진 API Gateway 리소스에 대해 정책을 만든 후 해당 정책을 연결하였다. 다음 명령어를 사용하였다.

 

eksctl create iamserviceaccount --name my-service-account --namespace default --cluster myeks --role-name my-role --attach-policy-arn arn:aws:iam::$ACCOUNT_ID:policy/APIGatewayAllPolicy --approve

 

실습 과정은 다음과 같다.

 

1. 프로젝트 다운로드

git clone https://github.com/aws-samples/websocket-eks

 

2. ECR 레지스트리 생성하여 URL 가져오기

 

3. 해당 ECR 레지스트리에서 push command 설명을 참고하여 클론한 폴더 내 존재하는 Dockerfile로 컨테이너화한 후 업로드를 시킨다. 이후 레지스트리 URL을 반영하여 서비스를 배포한 후 결과를 확인한다.

Replace <ecr image> with the location of your image in deployment-Service.yml
kubectl apply -f deployment-Service.yml
Run the following command to confirm the deployment was created successfully
kubectl get deployment websocket-microservice

 

4. Nodeport를 생성한다.

kubectl apply -f nodePort-Service.yml
Run the following command to confirm the service was created successfully
kubectl get service websocket-restapp-nodeport-service

 

5. ALB 인그레스를 생성한다.

kubectl apply -f albIngress.yml
Run the following command to get the address for the ALB
kubectl get ingress ingress-websocket-restapp-service

 

6. 위 5번에서 반환된 URL을 사용하여 Cloudformation으로 웹 소켓을 생성한다.

aws cloudformation create-stack --stack-name websocket-api --template-body file://./websocket-api-gateway-cfn.yml  --parameters ParameterKey=IntegrationUri,ParameterValue=http://<ALB Address>

 

7. IRSA 서비스 계정을 생성하고 그 정보를 update-deployment-Service.yml 에 반영한 다음 적용한다.

kubectl apply -f update-deployment-Service.yml

8. 최종 확인을 해보자. CloudFormation에서 웹소켓 URL을 찾고 이 URL을 기반으로 접속을 한다.

wscat --connect wss://<Your API gateway url>

9. 최종 테스트: 블로그 내용대로라면 echo back이 되어야 하는데 그렇게 되지 않는다. 추후 재실행 / 디버깅을 해보고자 한다.

10. 실습 자원 제거

aws cloudformation delete-stack --stack-name websocket-api

kubectl delete -f albIngress.yml
kubectl delete -f nodePort-Service.yml
kubectl delete -f deployment-Service.yml