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.yaml

vi 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-deployment

분량이 너무 많아져서 6번부턴 2편에서 작성할 예정이다.

[AWES 3기] 2주차 스터디 내용 정리(1)

댓글