0. 실습 환경 배포
이번에 실습하는 환경에서는 두 개의 VPC를 사용한다.
1. myeks-vpc: AZ 3개를 사용하고, Public, Private Subnet을 구성한다.
2. operator-vpc: AZ1만 사용하며 Public, Private Subnet을 구성한다.
VPC 간 내부 통신을 위해 VPC Peering을 구성되어 있다.
[플러그인 설치]
편의성을 위해 필요한 플러그인을 설치한다.
# Install awscli
brew install awscli
aws --version
# Install eksctl
brew install eksctl
eksctl version
# Install kubectl
brew install kubernetes-cli
kubectl version --client=true
# Install Helm
brew install helm
helm version
# krew 툴 및 플러그인 설치
brew install krew
kubectl krew version
krew install neat get-all df-pv stern
kubectl krew list
# 편리성 툴 설치
brew install kube-ps1
brew install kubectx
# kubectl 단축 및 하이라이트 설정
brew install kubecolor
echo "alias k=kubectl" >> ~/.zshrc
echo "alias kubectl=kubecolor" >> ~/.zshrc
echo "compdef kubecolor=kubectl" >> ~/.zshrc
# AWS 세션매니저로 관리 노드 EC2 접속 시 사용
brew install --cask session-manager-plugin
# Install sshpass
brew install sshpass
# Install Wireshark : 패킷 캡쳐 및 캡쳐된 파일에서 패킷 내용 확인
brew install --cask wireshark[AWS CloudFormation 을 통해 기본 실습 환경 배포]
구성도에 나온 operator-vpc를 먼저 배포한다.
# yaml 파일 다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/myeks-2week.yaml
# 배포
# aws cloudformation deploy --template-file ~/Downloads/myeks-1week.yaml --stack-name mykops --parameter-overrides KeyName=<My SSH Keyname> SgIngressSshCidr=<My Home Public IP Address>/32 --region <리전>
aws cloudformation deploy --template-file ~/Downloads/myeks-2week.yaml \
--stack-name myeks --parameter-overrides KeyName=aews SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2
터미널에서 Successfully created/updated stack가 뜨면 AWS 콘솔에서도 확인 CREATE_COMPLETE로 상태가 바뀐 것을 확인할 수 있다.
구성도에서 설명했던 VPC Peering 옵션도 확인할 수 있다.
# CloudFormation 스택 배포 완료 후 운영서버 EC2 IP 출력
aws cloudformation describe-stacks --stack-name myeks --query 'Stacks[*].Outputs[*].OutputValue' --output text
출력값 --> 52.79.248.197
# 운영서버 EC2 에 SSH 접속
예시) ssh ec2-user@52.79.248.197
ssh -i <ssh 키파일> ec2-user@$(aws cloudformation describe-stacks --stack-name myeks --query 'Stacks[*].Outputs[0].OutputValue' --output text)
[eksctl 을 통해 EKS 배포]
# 클러스터 이름 지정
export CLUSTER_NAME=myeks
# myeks-VPC/Subnet 정보 확인 및 변수 지정
export VPCID=$(aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" --query 'Vpcs[*].VpcId' --output text)
echo $VPCID
export PubSubnet1=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet2=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet2" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet3=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet3" --query "Subnets[0].[SubnetId]" --output text)
echo $PubSubnet1 $PubSubnet2 $PubSubnet3필요한 환경변수를 저장하고, 저장된 환경변수 기반으로 dry-run한 내용을 myeks.yaml 파일에 작성한다.
eksctl create cluster --name $CLUSTER_NAME --region=ap-northeast-2 --nodegroup-name=ng1 --node-type=t3.medium --nodes 3 --node-volume-size=30 --vpc-public-subnets "$PubSubnet1","$PubSubnet2","$PubSubnet3" --version 1.31 --with-oidc --external-dns-access --full-ecr-access --alb-ingress-access --node-ami-family AmazonLinux2023 --ssh-access --dry-run > myeks.yamlvi myeks.yaml다른건 다 수정되어 있던 상태라 ssh public key name만 변경해주었다.
# kubeconfig 파일 경로 위치 지정 :
export KUBECONFIG=$HOME/kubeconfig
# 배포
eksctl create cluster -f myeks.yaml --verbose 4
20분정도 기다리면 생성이 완료된다.
생성된 클러스터를 확인할 수 있고, Add-ons 설정도 확인이 가능하다.
[실습에서 자주 사용하는 변수들]
#
export KUBECONFIG=$HOME/kubeconfig
export CLUSTER_NAME=myeks
# myeks-VPC/Subnet 정보 확인 및 변수 지정
export VPCID=$(aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" --query 'Vpcs[*].VpcId' --output text)
echo $VPCID # vpc-082890642812b23f6
export PubSubnet1=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet2=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet2" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet3=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet3" --query "Subnets[0].[SubnetId]" --output text)
echo $PubSubnet1 $PubSubnet2 $PubSubnet3 # subnet-034c2be31c75ed50c subnet-0c81674e4853e0834 subnet-0990a5c2230f25ae3
# 인스턴스 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{InstanceID:InstanceId, PublicIPAdd:PublicIpAddress, PrivateIPAdd:PrivateIpAddress, InstanceName:Tags[?Key=='Name']|[0].Value, Status:State.Name}" --filters Name=instance-state-name,Values=running --output table
# 인스턴스 공인 IP 변수 지정
#export N1=<az1 배치된 EC2 공인 IP>
#export N2=<az2 배치된 EC2 공인 IP>
#export N3=<az3 배치된 EC2 공인 IP>
export N1=3.39.195.63
export N2=3.38.151.246
export N3=43.202.112.195
echo $N1, $N2, $N3 # 3.39.195.63, 3.38.151.246, 43.202.112.195
# 노드 정보 확인
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i hostnamectl; echo; done
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo ip -c addr; echo; done
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo ip -c route; echo; done
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo iptables -t nat -S; echo; done
# 파드 이름 변수 지정
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}')
# 파드 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}')
# 자신의 도메인 변수 지정 : 소유하고 있는 자신의 도메인을 입력하시면 됩니다
MyDomain=<자신의 도메인>
MyDomain=gasida.link
MyDnzHostedZoneId=`aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text`
echo $MyDnzHostedZoneId
# A 레코드 값 반복 조회
while true; do aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']" | jq ; date ; echo ; sleep 1; done
여기에서 노드 정보를 조회하다 아래 에러 메세지처럼 Permission denied가 발생했다.
>> node 3.39.195.63 <<
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
>> node 3.38.151.246 <<
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
>> node 43.202.112.195 <<
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).pem키 위치도 같이 넣어주면 잘 동작한다.
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh -o StrictHostKeyChecking=no -i ~/.ssh/aews.pem ec2-user@$i hostname; echo; done
>> node 3.39.195.63 <<
ip-192-168-3-127.ap-northeast-2.compute.internal
>> node 3.38.151.246 <<
ip-192-168-1-97.ap-northeast-2.compute.internal
>> node 43.202.112.195 <<
ip-192-168-2-181.ap-northeast-2.compute.internal
ssh -i ~/.ssh/aews.pem ec2-user@$N1
ssh -i ~/.ssh/aews.pem ec2-user@$N2
ssh -i ~/.ssh/aews.pem ec2-user@$N3[(옵션) AWS EC2 System Manager - Session Manager 로 관리형 노드 그룹(EC2) 접속]
# 인스턴스 ID 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{InstanceID:InstanceId, PublicIPAdd:PublicIpAddress, PrivateIPAdd:PrivateIpAddress, InstanceName:Tags[?Key=='Name']|[0].Value, Status:State.Name}" --filters Name=instance-state-name,Values=running --output text
# Session Manager 를 통한 접속
aws ssm start-session --target i-08de73b8e3d968f24
--------------------------------------------------
# 기본 사용자 정보 확인
whoami
pwd
# bash shell 적용
bash
whoami
pwd
# 기본 정보 확인
hostnamectl
# sudo 권한 사용 확인 >> 가능한 이유는? ChatGPT 등에 물어보시라!
sudo cat /etc/passwd
# 빠져나오기
exit
exit
--------------------------------------------------
기본은 ssm-user로 접속되고, bash 입력하면 bash shell로 사용이 가능하다.
웹 콘솔로 접근해서 사용이 가능하다.
1. AWS VPC CNI 소개
K8S CNI : Container Network Interface의 약자로, 인터페이스처럼 명세만 해두고 실제 구현은 플러그인이 하는 것
AWS에서는 AWS VPC CNI를 사용한다.
[AWS VPC CNI]
파드에 IP를 할당해주며, 파드의 IP 네트워크 대역 = 노드의 IP 대역이기 때문에 직접 통신이 가능한게 가장 큰 특징이다. (Calico CNI 같이 다른 CNI의 경우에는 대부분 네트워크 대역이 불가능하다)
2가지 컴포넌트 기능을 가진다.
1. CNI Binary: 파드 간 통신을 도와주기 위해
2. ipamd: Pod의 IP를 할당해주는 Pool을 관리한다.
- Warm IP Pool: 적절한 수준의 IP Pool을 가지기 때문에 Fater Pod startup이 가능하게 만들어준다.
[AWS VPC CNI의 동작 과정]
- 노드에 새로운 파드가 스케줄링 된다.
- kubelet에서 VPC CNI에게 IP 추가 요청을 한다.
- VPC CNI에서 L-IPAM에게 Pod IP를 요청한다.
- L-IPAM은 Pool에 있는 IP를 반환한다.
- Kernel API를 통해 Network Namespace를 세팅한다 (Pause 컨테이너)
- Pod Ip를 반환한다.
- Pod Ip를 assign한다.
[워커 노드에 생성 가능한 최대 파드 갯수]
- Secondary IPv4 Addresses: 인스턴스 유형과 최대 ENI 갯수와 할당 가능 IP 수를 조합하여 선정 (Max Pods = ENI (ENI 당 지원하는 IPv4 개수 - 1) + 2)
2, IPv4 Prefix Delegation : IPv4 28bit (prefix)를 위임하여 할당 가능 IP 수와 인스턴스 유형에 권장하는 최대 갯수로 선정 (Max Pods = ENI (ENI 당 지원하는 IPv4 개수 - 1) * 16) - AWS VPC CNI Custom Networking : 노드와 파드 대역 분리, 파드에 별도 서브넷 부여 후 사용
[다른 CNI vs AWS VPC CNI]
Calico CNI의 경우에는 Pod1, Pod2간 통신을 할 때 오버레이 통신을 한다. 왜냐하면 Pod1, Pod2 간 통신을 할 때 Pod1의 노드는 Pod2의 IP를 모르기 때문이다. => 따라서 오버헤드가 발생할 수 밖에 없다.
AWS VPC CNI의 경우에는 바로 통신이 가능하다. 왜냐하면 노드와 파드의 IP 대역이 동일하기 때문에 파드 간 직접 접근이 가능한 것이다. => 따라서 다른 CNI보다 더 효율적으로 접근이 가능하다.
[실습] 네트워크 기본 정보 확인
# CNI 정보 확인
**kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2**
# kube-proxy config 확인 : 모드 iptables 사용 >> ipvs 모드로 변경 해보자!
**kubectl describe cm -n kube-system kube-proxy-config
...**
mode: "iptables"
**...**
# 노드 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**
# 파드 이름 확인
kubectl get pod -A -o name
# 파드 갯수 확인
**kubectl get pod -A -o name | wc -l**
같은 대역을 사용하는 것을 볼 수 있다 (AWS VPC CNI의 특징!)
kube-proxy를 보면 node의 ip와 같은 것을 볼 수 있는데, 같은 네트워크 네임스페이스를 공유하기 때문이다.
2. 노드에서 기본 네트워크 정보 확인
- Network Namespace는 호스트(Root)와 파드 별(Per Pod)로 구분된다.
- aws-node, kube-proxy 같은 파드들은 노드와 동일한 IP를 사용하는데, (192.168.1.64) Host Nework 옵션이기 때문이다.
[워커 노드1 인스턴스의 네트워크 정보 확인 : 프라이빗 IP와 보조 프라이빗 IP 확인]
Private IP 주소 1개마다 보조 Private IPv4 주소가 5개씩 할당된다.
[[실습] 보조 IPv4 주소를 파드가 사용하는지 확인]
# coredns 파드 IP 정보 확인
kubectl get pod -n kube-system -l k8s-app=kube-dns -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
coredns-6777fcd775-57k77 1/1 Running 0 70m 192.168.1.142 ip-192-168-1-251.ap-northeast-2.compute.internal <none> <none>
coredns-6777fcd775-cvqsb 1/1 Running 0 70m 192.168.2.75 ip-192-168-2-34.ap-northeast-2.compute.internal <none> <none>
# 노드의 라우팅 정보 확인 >> EC2 네트워크 정보의 '보조 프라이빗 IPv4 주소'와 비교해보자
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo ip -c route; echo; done
[[실습] 테스트용 netshoot-pod 디플로이먼트 생성 - nicolaka/netshoot]
# [터미널1~3] 노드 모니터링
ssh ec2-user@$N1
watch -d "ip link | egrep 'ens|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"
ssh ec2-user@$N2
watch -d "ip link | egrep 'ens|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"
ssh ec2-user@$N3
watch -d "ip link | egrep 'ens|eni' ;echo;echo "[ROUTE TABLE]"; route -n | grep eni"
# 테스트용 netshoot-pod 디플로이먼트 생성
cat <<EOF | kubectl apply -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
warm pool을 가지고 있기 때문에 pod가 뜨면 ip와 연결하고, ENI를 확인할 수 있다.
노드 라우팅 정보도 마찬가지로 나오는 것을 확인할 수 있다.
[테스트용 파드 eniY 정보 확인 - 워커 노드 EC2]
# 노드3에서 네트워크 인터페이스 정보 확인
ssh ec2-user@$N3
----------------
ip -br -c addr show
ip -c link
ip -c addr
ip route # 혹은 route -n
# 네임스페이스 정보 출력 -t net(네트워크 타입)
sudo lsns -t net
# PID 정보로 파드 정보 확인
PID=<PID> # PID 높은 것 중 COMMAND가 pause 인것
sudo nsenter -t $PID -n ip -c addr
sudo nsenter -t $PID -n ip -c route
exit
----------------
pause 컨테이너 중에 가장 많이 높은 아이디를 찾아 확인해본다.
서버에서 특정한 Pod에 네트워크 명령어를 확인하면 이런식으로 IP 정보를 확인할 수 있다 (192.168.2.32, netshoot-pod의 IP)
[테스트용 파드 접속(exec) 후 확인]
# 테스트용 파드 접속(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
----------------------------
# 파드2 Shell 실행
kubectl exec -it $PODNAME2 -- ip -c addr
# 파드3 Shell 실행
kubectl exec -it $PODNAME3 -- ip -br -c addr
cat /etc/resolv.conf 에서 나오는 10.100.0.10은 coredns의 IP이다.
3. 노드 간 파드 통신
방금까지는 워커 노드에 파드가 떴을때 IP가 어떻게 구성되었는지 확인했고, 이제 파드 간 통신을 확인해본다.
파드 간 통신 시에는 별도의 오버레이(Overlay) 통신 기술 없이, VPC Native 하게 파드간 직접 통신이 가능하다 (AWS VPC CNI의 특징!)
[[실습] 파드간 통신 테스트 및 확인 : 별도의 NAT 동작 없이 통신 가능!]
# 파드 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 확인
## For Pod to external (outside VPC) traffic, we will program iptables to SNAT using Primary IP address on the Primary ENI.
sudo tcpdump -i any -nn icmp
sudo tcpdump -i ens5 -nn icmp
sudo tcpdump -i ens6 -nn icmp
sudo tcpdump -i eniYYYYYYYY -nn icmp
[워커 노드1]
# routing policy database management 확인
ip rule
# routing table management 확인
ip route show table local
# 디폴트 네트워크 정보를 ens5 을 통해서 빠져나간다
ip route show table main
default via 192.168.1.1 dev ens5
별도로 NAT가 안되고 원본 패킷이 그대로 날라가는 것을 확인되는 것을 확인할 수 있다.
4. 파드에서 외부 통신
내부 통신과는 다르게 외부 통신 시에는 iptable 에 SNAT을 통하여 노드의 eth0(ens5) IP로 변경되어서 통신된다.
[[실습] 파드에서 외부 통신 테스트 및 확인]
# pod-1 Shell 에서 외부로 ping
kubectl exec -it $PODNAME1 -- ping -c 1 www.google.com
kubectl exec -it $PODNAME1 -- ping -i 0.1 www.google.com
kubectl exec -it $PODNAME1 -- ping -i 0.1 8.8.8.8
OUT 192.168.3.127로 SNAT된 것을 확인할 수 있다.
# 퍼블릭IP 확인
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i curl -s ipinfo.io/ip; echo; echo; done
# 워커 노드 EC2
## 출력된 결과를 보고 어떻게 빠져나가는지 고민해보자!
ip rule
ip route show table main
sudo iptables -L -n -v -t nat
sudo iptables -t nat -S
여기에서 라우트 정보를 확인할 수 있다. default rule은 아래에 있는 rule이 걸리지 않을때 기본적으로 적용하는 rule인데, ens5로 나간다는 의미이다. 그래서 아까 구글로 외부 통신을 할 때 ens5로 나간 것을 확인할 수 있는 것이다.
# 파드가 외부와 통신시에는 아래 처럼 'AWS-SNAT-CHAIN-0' 룰(rule)에 의해서 SNAT 되어서 외부와 통신!
# 참고로 뒤 IP는 eth0(ENI 첫번째)의 IP 주소이다
# --random-fully 동작 - 링크1 링크2
sudo iptables -t nat -S | grep 'A AWS-SNAT-CHAIN'
-A AWS-SNAT-CHAIN-0 ! -d 192.168.0.0/16 -m comment --comment "AWS SNAT CHAIN" -j RETURN
-A AWS-SNAT-CHAIN-0 ! -o vlan+ -m comment --comment "AWS, SNAT" -m addrtype ! --dst-type LOCAL -j SNAT --to-source 192.168.1.251 --random-fully
## 아래 'mark 0x4000/0x4000' 매칭되지 않아서 RETURN 됨!
-A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
-A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE --random-fully
...
결과 사진을 보면 192.168.0.0/16 대역과 통신 시에는(내부 통신) AWS SNAT CHAIN을 타라고 되어 있고, 나머지 대역에 대해서는 SNAT을 타라고 조건이 걸려 있다. 이 때 Source IP로는 192.168.3.127로 바꾸라고 되어 있다. (서버의 첫번째 ENI IP) 그래서 구글로 외부 요청을 보낼 때 192.168.3.127로 Source IP가 바뀐 것이고, 내부 통신 시에 IP가 바뀌지 않은 이유도 이것이다.
=> 즉, iptable rule에 의하여 내부 통신에는 NAT를 사용하지 않고, 외부 통신 시에는 NAT를 사용한다. 그래서 네트워크 최적화 기법 중에 하나가 NAT를 사용하지 않게 만드는 것이다.
[[실습] 파드 <-> 운영서버 EC2 간 통신 확인]
# 운영서버 EC2 SSH 접속
ssh <운영서버 EC2 공인 IP>
-----------------------
POD1IP=<파드1 IP 지정>
POD1IP=192.168.1.101
ping -c 1 $POD1IP
exit
-----------------------
# 워커노드1 에서 tcpdump 확인 : NAT 동작 적용 여유 확인
sudo tcpdump -i any -nn icmp
별도의 NAT 없이 통신이 잘 된다.
파드 -> 운영 서버는 어떨까?
# vpc cni env 정보 확인
kubectl get ds aws-node -n kube-system -o json | jq '.spec.template.spec.containers[0].env'
...
{
"name": "AWS_VPC_K8S_CNI_EXTERNALSNAT",
"value": "false"
},
...
# 운영서버 EC2 SSH 접속
kubectl exec -it $PODNAME1 -- ping 172.20.1.100
# 파드1 배치 워커노드에서 tcpdump 확인 : NAT 동작 적용 여유 확인
sudo tcpdump -i any -nn icmp
# 운영서버 EC2 에서 tcpdump 확인 : NAT 동작 적용 여유 확인
sudo tcpdump -i any -nn icmp
-----------------------------------------------------
# 파드1 배치 워커노드 : NAT 적용 정책 확인
sudo iptables -t filter --zero; sudo iptables -t nat --zero; sudo iptables -t mangle --zero; sudo iptables -t raw --zero
watch -d 'sudo iptables -v --numeric --table nat --list AWS-SNAT-CHAIN-0; echo ; sudo iptables -v --numeric --table nat --list KUBE-POSTROUTING; echo ; sudo iptables -v --numeric --table nat --list POSTROUTING'
이때는 서버의 IP (192.168.3.127)로 NAT되어서 통신하는 것을 알 수 있다.
다음 실습을 위해서 디플로이먼트 삭제: kubectl delete deploy netshoot-pod
5. 노드에 파드 생성 갯수 제한
# 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 service.main.type=LoadBalancer --set env.TZ="Asia/Seoul" --namespace kube-system
# 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"}'
출력되는 URL에 접근하기 위해서는 조금 기다려야 한다.
helm으로 배포하게 되면 EC2 - LB가 생성 되는 것이다.
노드 상태를 가시화해서 볼 수 있다.
EC2의 스펙에 따라 할당할 수 있는 IP가 정해져 있기 때문에 그 만큼만 파드 할당이 가능하다.
# t3 타입의 정보(필터) 확인
aws ec2 describe-instance-types --filters Name=instance-type,Values=t3.\* \
--query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
--output table
t3.medium 경우 : ((3 * (6 - 1) + 2 ) = 17개 >> aws-node 와 kube-proxy 2개 제외하면 15개 사용이 가능한 것이다.
[최대 파드 생성 및 확인]
# 워커 노드 3대 EC2 - 모니터링
while true; do ip -br -c addr show && echo "--------------" ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; done
# 터미널1
watch -d 'kubectl get pods -o wide'
# 터미널2
## 디플로이먼트 생성
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:alpine
ports:
- containerPort: 80
EOF
# 파드 확인
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=8
# 파드 증가 테스트 >> 파드 정상 생성 확인, 워커 노드에서 eth, eni 갯수 확인 >> 어떤일이 벌어졌는가?
kubectl scale deployment nginx-deployment --replicas=15
# 파드 증가 테스트 >> 파드 정상 생성 확인, 워커 노드에서 eth, eni 갯수 확인 >> 어떤일이 벌어졌는가?
kubectl scale deployment nginx-deployment --replicas=30
# 파드 증가 테스트 >> 파드 정상 생성 확인, 워커 노드에서 eth, eni 갯수 확인 >> 어떤일이 벌어졌는가?
kubectl scale deployment nginx-deployment --replicas=50
50개로 증가시키면 ENI가 추가되고 계속 배치되다가 몇 개의 파드가 배포에 실패한 것을 확인할 수 있다.
# 파드 생성 실패!
kubectl get pods | grep Pending
nginx-deployment-7fb7fd49b4-d4bk9 0/1 Pending 0 3m37s
nginx-deployment-7fb7fd49b4-qpqbm 0/1 Pending 0 3m37s
...
kubectl describe pod <Pending 파드> | grep Events: -A5
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 45s default-scheduler 0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 Too many pods. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod.
IP 할당이 안되어서 에러가 나는 것이다. => 이것이 제약 사항!
이 문제를 해결하기 위해 인스턴스 스펙을 올리거나 Prefix Delegation, WARM & MIN IP/Prefix Targets, Custom Network 방법을 사용하면 된다.
# 디플로이먼트 삭제
kubectl delete deploy nginx-deployment5. EKS Persistent Volumes for Instance Store & Add NodeGroup
Storage IOPS가 높게 필요한 Pod가 필요하지만, 디스크에 유실이 나도 괜찮은 경우 => EC2 인스턴스 스토어(임시 블록 스토리지)를 사용한다.
단점: 데이터 손실(기본 디스크 드라이브 오류, 인스턴스가 중지됨, 인스턴스가 최대 절전 모드로 전환됨, 인스턴스가 종료되는 경우 ...)
장점 : 로컬에 있기 때문에 IO가 매우 빠르다
# 인스턴스 스토어 볼륨이 있는 c5 모든 타입의 스토리지 크기
aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=c5*" "Name=instance-storage-supported,Values=true" \
--query "InstanceTypes[].[InstanceType, InstanceStorageInfo.TotalSizeInGB]" \
--output table
--------------------------
| DescribeInstanceTypes |
+---------------+--------+
| c5d.large | 50 |
| c5d.12xlarge | 1800 |
...
사용 가능한 인스턴스 스토어. 빠르고 싸지만 데이터 유실 될 수 있다.
#
export PubSubnet1=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet2=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet2" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet3=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-Vpc1PublicSubnet3" --query "Subnets[0].[SubnetId]" --output text)
echo $PubSubnet1 $PubSubnet2 $PubSubnet3
#
SSHKEYNAME=<각자 자신의 SSH Keypair 이름>
SSHKEYNAME=aews
cat << EOF > myng2.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: myeks
region: ap-northeast-2
version: "1.31"
managedNodeGroups:
- amiFamily: AmazonLinux2
desiredCapacity: 1
instanceType: c5d.large
labels:
alpha.eksctl.io/cluster-name: myeks
alpha.eksctl.io/nodegroup-name: ng2
disk: instancestore
maxPodsPerNode: 110
maxSize: 1
minSize: 1
name: ng2
ssh:
allow: true
publicKeyName: $SSHKEYNAME
subnets:
- $PubSubnet1
- $PubSubnet2
- $PubSubnet3
tags:
alpha.eksctl.io/nodegroup-name: ng2
alpha.eksctl.io/nodegroup-type: managed
volumeIOPS: 3000
volumeSize: 30
volumeThroughput: 125
volumeType: gp3
preBootstrapCommands:
- |
# Install Tools
yum install nvme-cli links tree jq tcpdump sysstat -y
# Filesystem & Mount
mkfs -t xfs /dev/nvme1n1
mkdir /data
mount /dev/nvme1n1 /data
# Get disk UUID
uuid=\$(blkid -o value -s UUID mount /dev/nvme1n1 /data)
# Mount the disk during a reboot
echo /dev/nvme1n1 /data xfs defaults,noatime 0 2 >> /etc/fstab
EOFmyng2.yaml 파일 작성이 완료되면 apply한다.
# 신규 노드 그룹 생성 전 정보 확인
eksctl create nodegroup --help
eksctl create nodegroup -c $CLUSTER_NAME -r ap-northeast-2 --subnet-ids "$PubSubnet1","$PubSubnet2","$PubSubnet3" --ssh-access \
-n ng2 -t c5d.large -N 1 -m 1 -M 1 --node-volume-size=30 --node-labels disk=instancestore --max-pods-per-node 100 --dry-run > myng2.yaml
cat <<EOT > nvme.yaml
preBootstrapCommands:
- |
# Install Tools
yum install nvme-cli links tree jq tcpdump sysstat -y
# Filesystem & Mount
mkfs -t xfs /dev/nvme1n1
mkdir /data
mount /dev/nvme1n1 /data
# Get disk UUID
uuid=\$(blkid -o value -s UUID mount /dev/nvme1n1 /data)
# Mount the disk during a reboot
echo /dev/nvme1n1 /data xfs defaults,noatime 0 2 >> /etc/fstab
EOT
sed -i -n -e '/volumeType/r nvme.yaml' -e '1,$p' myng2.yaml
```
```
# 확인
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
kubectl get node -l disk=instancestore
# ng2 노드 그룹 *ng2-remoteAccess* 포함된 보안그룹 ID
aws ec2 describe-security-groups --filters "Name=group-name,Values=*ng2-remoteAccess*" | jq
export NG2SGID=$(aws ec2 describe-security-groups --filters "Name=group-name,Values=*ng2-remoteAccess*" --query 'SecurityGroups[*].GroupId' --output text)
aws ec2 authorize-security-group-ingress --group-id $NG2SGID --protocol '-1' --cidr $(curl -s ipinfo.io/ip)/32
aws ec2 authorize-security-group-ingress --group-id $NG2SGID --protocol '-1' --cidr 172.20.1.100/32
# 워커 노드 SSH 접속
N4=<각자 자신의 워커 노드4번 공인 IP 지정>
N4=3.37.44.222
ssh ec2-user@$N4 hostname
# 확인
ssh ec2-user@$N4 sudo nvme list
ssh ec2-user@$N4 sudo lsblk -e 7 -d
ssh ec2-user@$N4 sudo df -hT -t xfs
ssh ec2-user@$N4 sudo tree /data
ssh ec2-user@$N4 sudo cat /etc/fstab
# (옵션) max-pod 확인
kubectl describe node -l disk=instancestore | grep Allocatable: -A7
# (옵션) kubelet 데몬 파라미터 확인 : --max-pods=29 --max-pods=110
ssh ec2-user@$N4 cat /etc/eks/bootstrap.sh
ssh ec2-user@$N4 sudo ps -ef | grep kubelet
root 3012 1 0 06:50 ? 00:00:02 /usr/bin/kubelet --config /etc/kubernetes/kubelet/kubelet-config.json --kubeconfig /var/lib/kubelet/kubeconfig --container-runtime-endpoint unix:///run/containerd/containerd.sock --image-credential-provider-config /etc/eks/image-credential-provider/config.json --image-credential-provider-bin-dir /etc/eks/image-credential-provider --node-ip=192.168.2.228 --pod-infra-container-image=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/eks/pause:3.5 --v=2 --hostname-override=ip-192-168-2-228.ap-northeast-2.compute.internal --cloud-provider=external --node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=myeks,alpha.eksctl.io/nodegroup-name=ng2,disk=instancestore,eks.amazonaws.com/nodegroup-image=ami-0fa05db9e3c145f63,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=ng2,eks.amazonaws.com/sourceLaunchTemplateId=lt-0955d0931c1d712c1 --max-pods=29 --max-pods=110
c5d.large 타입이 인스턴스 스토어이다.
[local-path 스토리지 클래스 재생성 : 패스 변경]
# 기존 local-path 스토리지 클래스 삭제
kubectl delete -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml
#
curl -sL https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml | sed 's/opt/data/g' | kubectl apply -f -
kubectl describe cm -n local-path-storage local-path-config
...
"nodePathMap":[
{
"node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
"paths":["/data/local-path-provisioner"]
}
]
...
# 모니터링
watch 'kubectl get pod -owide;echo;kubectl get pv,pvc'
ssh ec2-user@$N4 iostat -xmdz 1 -p nvme1n1
# [운영서버 EC2] Read 측정
kubestr fio -f fio-read.fio -s local-path --size 10G --nodeselector disk=instancestore
...
read:
IOPS=20309.355469 BW(KiB/s)=81237
iops: min=17392 max=93872 avg=20316.857422
bw(KiB/s): min=69570 max=375488 avg=81268.023438
Disk stats (read/write):
nvme1n1: ios=2432488/9 merge=0/3 ticks=7639891/23 in_queue=7639913, util=99.950768%
아까 테스트한 결과보다 IOPS 성능이 훨씬 높게 나오는 것을 확인할 수 있다.
일반 EBS(기본값 3000 IOPS) vs 인스턴스 스토어 평균 IOPS 속도 비교 with kubestr ← 인스턴스 스토어가 7배 빠르다. => 성능 면에서 월등하다.
# local-path 스토리지 클래스 삭제
kubectl delete -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml
# ng2 노드그룹 삭제
eksctl delete nodegroup -c $CLUSTER_NAME -n ng26. 노드 그룹
[[운영서버 EC2] docker buildx 활성화 : Multi(or cross)-platform 빌드]
우분투는 플랫폼별로 제공해주고 있다.
#
arch
x86_64
# CPU Arch arm64v8 , riscv64 실행 시도
docker run --rm -it riscv64/ubuntu bash
docker run --rm -it arm64v8/ubuntu bash
# Extended build capabilities with BuildKit - List builder instances
docker buildx ls
NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS
default * docker
default default running v0.12.5 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386
# docker buildx 활성화 (멀티 아키텍처 빌드를 위해 필요)
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
docker images
docker buildx create --use --name mybuilder
docker buildx ls
# Buildx가 정상 동작하는지 확인
docker buildx inspect --bootstrap
...
Platforms: linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
...
docker buildx ls
NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS
mybuilder * docker-container
mybuilder0 unix:///var/run/docker.sock running v0.19.0 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
default docker
default default running v0.12.5 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386, linux/arm64, linux/riscv64, linux/ppc64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fa8773b87c70 moby/buildkit:buildx-stable-1 "buildkitd" About a minute ago Up About a minute buildx_buildkit_mybuilder0
docker buildx를 활성화하면 멀티 아키텍처에서 실행이 된다.
Platforms에 지원하는 플랫폼이 나와있다 (x86_64 기반인데 arm 기반의 이미지를 빌드할 수 있도록 지원해준다)
[(샘플) 컨테이너 이미지 빌드 및 실행 - 윈도우PC(amd64)와 macOS(arm64)]
#
mkdir myweb && cd myweb
# server.py 파일 작성
cat > server.py <<EOF
from http.server import ThreadingHTTPServer, BaseHTTPRequestHandler
from datetime import datetime
import socket
class RequestHandler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
self.send_header('Content-type', 'text/plain')
self.end_headers()
now = datetime.now()
hostname = socket.gethostname()
response_string = now.strftime("The time is %-I:%M:%S %p, VERSION 0.0.1\n")
response_string += f"Server hostname: {hostname}\n"
self.wfile.write(bytes(response_string, "utf-8"))
def startServer():
try:
server = ThreadingHTTPServer(('', 80), RequestHandler)
print("Listening on " + ":".join(map(str, server.server_address)))
server.serve_forever()
except KeyboardInterrupt:
server.shutdown()
if __name__ == "__main__":
startServer()
EOF
# Dockerfile 생성
cat > Dockerfile <<EOF
FROM python:3.12
ENV PYTHONUNBUFFERED 1
COPY . /app
WORKDIR /app
CMD python3 server.py
EOF
# 빌드, 실행 후 삭제
docker pull python:3.12
docker build -t myweb:1 -t myweb:latest .
docker images
docker run -d -p 8080:80 --name=timeserver myweb
curl http://localhost:8080
docker rm -f timeserver
# 멀티 플랫폼 빌드 후 푸시
docker images
docker login
DOCKERNAME=<도커허브 계정명>
DOCKERNAME=gasida
docker buildx build --platform linux/amd64,linux/arm64 .
docker images
docker manifest inspect $DOCKERNAME/myweb:multi | jq
docker buildx imagetools inspect $DOCKERNAME/myweb:multi
# 컨테이너 실행 해보기 : 윈도우PC(amd64)와 macOS(arm64) 두 곳 모두 동일한 컨테이너 이미지 경로로 실행해보자!
docker ps
docker run -d -p 8080:80 --name=timeserver $DOCKERNAME/myweb:multi
docker ps
# 컨테이너 접속 및 로그 확인
curl http://localhost:8080
docker logs timeserver
# 컨테이너 이미지 내부에 파일 확인
docker exec -it timeserver ls -l
# 컨테이너 이미지 내부에 server.py 파일 확인
docker exec -it timeserver cat server.py
# 컨테이너 삭제
docker rm -f timeserver
아키텍처가 다름에도 둘 다 실행이 된다. => 이게 멀티 플랫폼!
[AWS ECR 프라이빗 저장소 사용하기]
#
export ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
aws ecr get-login-password \
--region **ap-northeast-2** | **docker login** \
--username AWS \
--password-stdin ${ACCOUNT_ID}.dkr.ecr.**ap-northeast-2**.amazonaws.com
cat /root/.docker/config.json | jq
# ECR 프라이빗 저장소 생성
aws ecr **create-repository** --repository-name **myweb**
# ECR 프라이빗 저장소에 푸시
docker buildx build --platform linux/amd64,linux/arm64 **--push** --tag ${ACCOUNT_ID}.dkr.ecr.**ap-northeast-2**.amazonaws.com/**myweb:multi** .
docker images
# 컨테이너 실행 : 윈도우PC(amd64)와 macOS(arm64) 두 곳 모두 동일한 컨테이너 이미지 경로로 실행해보자!
docker run -d -p 8080:80 --name=timeserver ${ACCOUNT_ID}.dkr.ecr.**ap-northeast-2**.amazonaws.com/**myweb:multi**
docker ps
**curl http://localhost:8080**
# 컨테이너 삭제
docker rm -f timeserver
마찬가지로 실행이 잘 된다.
[ARM 노드 그룹]
AWS Graviton 프로세서 : 64-bit Arm 프로세서 코어 기반의 AWS 커스텀 반도체 ⇒ 20~40% 향상된 가격대비 성능
#
kubectl get nodes -L kubernetes.io/arch
# 신규 노드 그룹 생성
eksctl create nodegroup --help
eksctl create nodegroup -c $CLUSTER_NAME -r ap-northeast-2 --subnet-ids "$PubSubnet1","$PubSubnet2","$PubSubnet3" \
-n ng3 -t t4g.medium -N 1 -m 1 -M 1 --node-volume-size=30 --node-labels family=graviton --dry-run > myng3.yaml
cat myng3.yaml
eksctl create nodegroup -f myng3.yaml
# 확인
kubectl get nodes --label-columns eks.amazonaws.com/nodegroup,kubernetes.io/arch,eks.amazonaws.com/capacityType
kubectl describe nodes --selector family=graviton
aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name ng3 | jq .nodegroup.taints
# taints 셋팅 -> 적용에 2~3분 정도 시간 소요
aws eks update-nodegroup-config --cluster-name $CLUSTER_NAME --nodegroup-name ng3 --taints "addOrUpdateTaints=[{key=frontend, value=true, effect=NO_EXECUTE}]"
# 확인
kubectl describe nodes --selector family=graviton | grep Taints
aws eks describe-nodegroup --cluster-name $CLUSTER_NAME --nodegroup-name ng3 | jq .nodegroup.taints
# NO_SCHEDULE - This corresponds to the Kubernetes NoSchedule taint effect. This configures the managed node group with a taint that repels all pods that don't have a matching toleration. All running pods are not evicted from the manage node group's nodes.
# NO_EXECUTE - This corresponds to the Kubernetes NoExecute taint effect. Allows nodes configured with this taint to not only repel newly scheduled pods but also evicts any running pods without a matching toleration.
# PREFER_NO_SCHEDULE - This corresponds to the Kubernetes PreferNoSchedule taint effect. If possible, EKS avoids scheduling Pods that do not tolerate this taint onto the node.
NodeSelector가 Gravition으로 되어 있는 것을 확인할 수 있다.
kubectl delete pod busybox[Spot 인스턴스]
최대 70%의 저렴한 가격으로 EC2 인스턴스를 사용할 수 있다. 다만 언제든지 중단될 수 있다는 단점이 있기 때문에 상태 비저장 API 엔드포인트, 일괄 처리, ML 학습 워크로드, Apache Spark를 사용한 빅데이터 ETL, 대기열 처리 애플리케이션, CI/CD 파이프라인과 같은 워크로드에서 많이 쓰인다.
# [운영서버 EC2] ec2-instance-selector 설치
curl -Lo ec2-instance-selector https://github.com/aws/amazon-ec2-instance-selector/releases/download/v2.4.1/ec2-instance-selector-`uname | tr '[:upper:]' '[:lower:]'`-amd64 && chmod +x ec2-instance-selector
mv ec2-instance-selector /usr/local/bin/
ec2-instance-selector --version
# 적절한 인스턴스 스펙 선택을 위한 도구 사용
ec2-instance-selector --vcpus 2 --memory 4 --gpus 0 --current-generation -a x86_64 --deny-list 't.*' --output table-wide
Instance Type VCPUs Mem (GiB) Hypervisor Current Gen Hibernation Support CPU Arch Network Performance ENIs GPUs GPU Mem (GiB) GPU Info On-Demand Price/Hr Spot Price/Hr (30d avg)
------------- ----- --------- ---------- ----------- ------------------- -------- ------------------- ---- ---- ------------- -------- ------------------ -----------------------
c5.large 2 4 nitro true true x86_64 Up to 10 Gigabit 3 0 0 none $0.096 $0.02837
c5a.large 2 4 nitro true false x86_64 Up to 10 Gigabit 3 0 0 none $0.086 $0.04022
c5d.large 2 4 nitro true true x86_64 Up to 10 Gigabit 3 0 0 none $0.11 $0.03265
c6i.large 2 4 nitro true true x86_64 Up to 12.5 Gigabit 3 0 0 none $0.096 $0.03425
c6id.large 2 4 nitro true true x86_64 Up to 12.5 Gigabit 3 0 0 none $0.1155 $0.03172
c6in.large 2 4 nitro true true x86_64 Up to 25 Gigabit 3 0 0 none $0.1281 $0.04267
c7i-flex.large 2 4 nitro true true x86_64 Up to 12.5 Gigabit 3 0 0 none $0.09576 $0.02872
c7i.large 2 4 nitro true true x86_64 Up to 12.5 Gigabit 3 0 0 none $0.1008 $0.02977
#Internally ec2-instance-selector is making calls to the DescribeInstanceTypes for the specific region and filtering the instances based on the criteria selected in the command line, in our case we filtered for instances that meet the following criteria:
- Instances with no GPUs
- of x86_64 Architecture (no ARM instances like A1 or m6g instances for example)
- Instances that have 2 vCPUs and 4 GB of RAM
- Instances of current generation (4th gen onwards)
- Instances that don’t meet the regular expression t.* to filter out burstable instance types
필요한 세대, 키워드로 필터링을 해서 쉽게 볼 수 있다.
kubectl get nodes -l eks.amazonaws.com/capacityType=ON_DEMAND
kubectl get nodes -L eks.amazonaws.com/capacityType
NAME STATUS ROLES AGE VERSION CAPACITYTYPE
ip-192-168-1-65.ap-northeast-2.compute.internal Ready <none> 75m v1.28.5-eks-5e0fdde ON_DEMAND
ip-192-168-2-89.ap-northeast-2.compute.internal Ready <none> 75m v1.28.5-eks-5e0fdde ON_DEMAND
ip-192-168-3-39.ap-northeast-2.compute.internal Ready <none> 75m v1.28.5-eks-5e0fdde ON_DEMAND
# 노드 그룹 생성
NODEROLEARN=$(aws iam list-roles --query "Roles[?contains(RoleName, 'nodegroup-ng1')].Arn" --output text)
echo $NODEROLEARN
aws eks create-nodegroup \
--cluster-name $CLUSTER_NAME \
--nodegroup-name managed-spot \
--subnets $PubSubnet1 $PubSubnet2 $PubSubnet3 \
--node-role $NODEROLEARN \
--instance-types c5.large c5d.large c5a.large \
--capacity-type SPOT \
--scaling-config minSize=2,maxSize=3,desiredSize=2 \
--disk-size 20
# The command can be used to wait until a specific EKS node group is active and ready for use.
aws eks wait nodegroup-active --cluster-name $CLUSTER_NAME --nodegroup-name managed-spot
# 확인
kubectl get nodes -L eks.amazonaws.com/capacityType,eks.amazonaws.com/nodegroup
NAME STATUS ROLES AGE VERSION CAPACITYTYPE NODEGROUP
ip-192-168-1-229.ap-northeast-2.compute.internal Ready <none> 102s v1.31.5-eks-5d632ec SPOT managed-spot
ip-192-168-1-68.ap-northeast-2.compute.internal Ready <none> 87m v1.31.5-eks-5d632ec ON_DEMAND ng1
ip-192-168-2-138.ap-northeast-2.compute.internal Ready <none> 103s v1.31.5-eks-5d632ec SPOT managed-spot
ip-192-168-2-27.ap-northeast-2.compute.internal Ready <none> 88m v1.31.5-eks-5d632ec ON_DEMAND ng1
ip-192-168-3-183.ap-northeast-2.compute.internal Ready <none> 87m v1.31.5-eks-5d632ec ON_DEMAND ng1
spot 요청을 보내면 요청이 생기고 할당을 받는다.
아까와는 다르게 Spot 타입의 인스턴스가 추가된 것을 볼 수 있다.
#
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
terminationGracePeriodSeconds: 3
containers:
- name: busybox
image: busybox
command:
- "/bin/sh"
- "-c"
- "while true; do date >> /home/pod-out.txt; cd /home; sync; sync; sleep 10; done"
nodeSelector:
eks.amazonaws.com/capacityType: SPOT
EOF
# 파드가 배포된 노드 정보 확인
kubectl get pod -owide
# 삭제
kubectl delete pod busybox
Spot 중단을 처리할 수 있도록 Amazon EC2 Auto Scaling 그룹을 구성하고 다음과 같은 방식으로 Spot 중단을 처리할 수 있다.
[Bottlerocket AMI]
Bottlerocket은 보안에 중점을 두고, 컨테이너 호스팅에 필수적인 소프트웨어만 포함하므로 공격에 대한 노출 위험을 줄인다.
실습 완료 후 자원 삭제
- (실습 했을 경우) AWS ECR 저장소 삭제
- Amazon EKS 클러스터 삭제(10분 정도 소요):
eksctl delete cluster --name $CLUSTER_NAME - (클러스터 삭제 완료 확인 후) AWS CloudFormation 스택 삭제 :
aws cloudformation delete-stack --stack-name myeks - EKS 배포 후 실습 편의를 위한 변수 설정 삭제 : macOS :
vi ~/.zshrc, Windows(WSL2) :vi ~/.bashrc
공블로그