Amazon VPC CNI란?
Amazon VPC Container Network Interface의 약자로 Pod가 VPC 네트워크의 IP를 사용할 수 있게 해주는 플러그인입니다.
또한, Pod 안의 컨테이너들이 network namespace를 공유하여 local port를 통해 통신할 수 있게 합니다.
VPC CNI는 EKS add-on으로 제공되며 모든 노드에서 실행이 필요하므로 aws-node 라는 DaemonSet이 배포됩니다.
EKS 클러스터 생성 시 기본적으로 설치되지만, 최신 버전을 사용하기 위해서는 별도로 설치가 필요합니다.
구성 요소
- CNI Binary
- Pod network를 구성하여 Pod간 통신을 가능하게 함
- 노드의 root 파일 시스템에서 실행되며, Pod가 추가되거나 노드에서 삭제될 때 kubelet에 의해 호출됨
- ipadm (long-running node-local IP Address Management daemon)
- 노드 ENI 관리
- 가용 IP 주소/prefix의 warm-pool 관리
동작 방식
노드 생성되면, EC2가 primary subnet에 primary ENI를 생성하고 연결합니다. primary subnet은 private/public 모두 가능합니다. honstNetwork 모드로 실행되는 Pod는 primary ENI의 IP를 사용하고 host와 동일한 network namespace를 공유합니다.
또한, 노드가 생성 시 CNI가 자동으로 primary ENI에 primary subnet의 IP 또는 prefix warm pool을 노드의 인스턴스 타입에 따라 사이즈를 결정하여 할당합니다. 그리고 노드에서 실행되는 Pod 수에 따라 secondary ENI를 추가해 나갑니다.
노드 타입에 따라 ENI 수에 제한이 있기 때문에, 노드 타입과 CNI mode에 따라 최대 배포 가능한 Pod 수가 결정됩니다. 최대 Pod 수 관련해서는 이전 포스팅에 설명해두었습니다.
VPC CNI 모드
VPC CNI는 Secondary IP 모드가 디폴트 설정입니다. 이 모드는 ENI 마다 warm pool을 IP로 할당합니다.
노드에 더 많은 수의 Pod를 실행시킬 필요가 있다면 prefix 모드로 변경이 필요합니다. 해당 모드는 IP 대신 /28 CIDR을 각 ENI에 할당해 더 많은 IP를 사용할 수 있습니다.
또한, VPC에 secondary CIDR을 추가하여 Pod IP를 확장하는 방법도 있습니다.
Custom Networking 설정을 통해 RFC 1918 사설 IP가 아닌 100.64.0.0/10, 198.19.0.0/16 대역을 Pod에 할당할 수 있습니다.
이 방식도 동일하게 노드에 secondary ENI가 추가되지만, 기존 노드의 subnet이 아닌 Pod subnet의 IP가 할당됩니다.
다른 CNI
참고로, k8s CNI에는 Cillium, Calico 등등 다양한 종류가 있고, 그 중에는 EKS에서 사용 가능한 것들도 있으나 다른 CNI를 사용한다면 AWS의 기술지원을 받을 수 없습니다. 또한, overlay 네트워크로 구현되기 때문에 다른 노드에 배포된 Pod간 통신 시 추가 단계가 필요하고 네트워크 이슈가 있을 때 VPC flow log로 분석하기에 어려움이 있습니다.
또한, Fargate 노드에는 VPC CNI가 기본적으로 설치되어 있고, 다른 CNI는 사용하지 못한다고 공식 문서에 기재되어 있습니다. (Fargate에서 DaemonSet을 지원하지 않아서 그런지(?))
VPC 및 Subnet 요구 사항
일반적인 사항
EKS에서 사용하는 VPC 및 Subnet에는 확장 및 가용성을 고려하여 IP를 여유롭게 할당해야 합니다.
반드시 EKS용 VPC를 생성할 필요는 없고 기존 VPC를 확장해서 사용할 수도 있습니다.
EKS 생성 후에 subnet을 추가하는 것은 간단하지 않기에 설계 단계에서 많은 고민이 필요합니다.
참고로 EKS 클러스터 생성 시에 선택한 subnet에 EKS managed ENI가 생성되는데, 노드가 반드시 해당 subnet에 위치할 필요는 없습니다. (같은 VPC에는 있어야 합니다.)
태그
EKS나 add-on의 버전에 따라 VPC 또는 subnet에 필요한 태그가 있습니다.
현재는 1.22가 deprecated 예정이기 때문에 그 이상 버전의 클러스터만 고려하면, subnet에 elb를 사용하기 위한 태그가 필요합니다.
보통 elb subnet을 별도로 구성하기 때문에 해당 subnet에만 적절한 태그를 추가하면 됩니다. 해당 태그가 있어야 AWS Load Balancer Controller가 subnet을 찾고 elb를 생성할 수 있습니다.
- internal elb 사용 시 :
kubernetes.io/role/internal-elb: 1추가 - public elb 사용 시 :
kubernetes.io/role/elb : 1추가
실습
이제 실습을 통해 VPC CNI를 조금 더 자세히 알아보겠습니다.
이번주 부터는 CloudFormation yaml을 통해 간편하게 클러스터를 배포하는 방법을 공유 받았습니다.
해당 yaml을 통해 배포를 하면 아래와 같은 환경을 구성할 수 있습니다.
CNI 정보 확인
노드는 아래와 같이 총 3대가 실행 중입니다.
$ kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
NAME STATUS ROLES AGE VERSION INSTANCE-TYPE CAPACITYTYPE ZONE
ip-192-168-1-97.ap-northeast-2.compute.internal Ready <none> 19m v1.24.11-eks-a59e1f0 t3.medium ON_DEMAND ap-northeast-2a
ip-192-168-2-59.ap-northeast-2.compute.internal Ready <none> 19m v1.24.11-eks-a59e1f0 t3.medium ON_DEMAND ap-northeast-2b
ip-192-168-3-7.ap-northeast-2.compute.internal Ready <none> 19m v1.24.11-eks-a59e1f0 t3.medium ON_DEMAND ap-northeast-2c그 중 하나의 노드에서 확인해보면, /var/log/aws-routed-eni 디렉터리 아래에 CNI 관련 로그가 쌓이는 것을 볼 수 있습니다.
$ ssh ec2-user@{node01 ip} tree /var/log/aws-routed-eni
/var/log/aws-routed-eni
├── egress-v4-plugin.log
├── ipamd.log
└── plugin.log또한, aws-node pod들이 노드와 동일한 IP를 사용하고 있음을 알 수 있습니다.
$ k get po -o wide -n kube-system | grep -i node
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-jhvff 1/1 Running 0 7m38s 192.168.1.97 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
aws-node-lj86g 1/1 Running 0 7m45s 192.168.2.59 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
aws-node-mncph 1/1 Running 0 7m45s 192.168.3.7 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>Node01의 nic와 라우팅 정보는 아래와 같습니다.
$ ssh ec2-user@$N1 sudo ip -c addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 02:a4:28:ff:dc:c4 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.97/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 2853sec preferred_lft 2853sec
inet6 fe80::a4:28ff:feff:dcc4/64 scope link
valid_lft forever preferred_lft forever
3: eni5e6078cff03@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
link/ether be:cf:1c:30:c0:27 brd ff:ff:ff:ff:ff:ff link-netns cni-140b08fa-910f-2dfa-9d35-123d5784a675
inet6 fe80::bccf:1cff:fe30:c027/64 scope link
valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 02:c3:54:53:80:64 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.184/24 brd 192.168.1.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::c3:54ff:fe53:8064/64 scope link
valid_lft forever preferred_lft forever
$ ssh ec2-user@$N1 sudo ip -c route
default via 192.168.1.1 dev eth0
169.254.169.254 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.97
192.168.1.248 dev eni5e6078cff03 scope linkNode01의 네트워크 정보를 AWS 콘솔에서 확인하면 아래와 같습니다.
다음으로는 새로운 pod를 생성해서 노드의 route table이 어떻게 변하는지 확인해보겠습니다.
[현재 상태]
$ k get po -A -o wide
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system aws-node-jhvff 1/1 Running 0 26m 192.168.1.97 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
kube-system aws-node-lj86g 1/1 Running 0 26m 192.168.2.59 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
kube-system aws-node-mncph 1/1 Running 0 26m 192.168.3.7 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
kube-system coredns-6777fcd775-mjpj7 1/1 Running 0 22m 192.168.2.178 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
kube-system coredns-6777fcd775-ss2m9 1/1 Running 0 22m 192.168.1.248 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
kube-system kube-proxy-ctd5s 1/1 Running 0 23m 192.168.1.97 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
kube-system kube-proxy-lsgks 1/1 Running 0 23m 192.168.3.7 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
kube-system kube-proxy-mnzw6 1/1 Running 0 23m 192.168.2.59 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
[deployment 배포]
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[deployment 배포 후]
$ k get po -A -o wide
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
default netshoot-pod-7757d5dd99-9n9dc 1/1 Running 0 11s 192.168.1.134 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
default netshoot-pod-7757d5dd99-k2fwp 1/1 Running 0 11s 192.168.3.104 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
default netshoot-pod-7757d5dd99-pm8c4 1/1 Running 0 11s 192.168.2.254 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
kube-system aws-node-jhvff 1/1 Running 0 27m 192.168.1.97 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
kube-system aws-node-lj86g 1/1 Running 0 28m 192.168.2.59 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
kube-system aws-node-mncph 1/1 Running 0 28m 192.168.3.7 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
kube-system coredns-6777fcd775-mjpj7 1/1 Running 0 24m 192.168.2.178 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
kube-system coredns-6777fcd775-ss2m9 1/1 Running 0 24m 192.168.1.248 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
kube-system kube-proxy-ctd5s 1/1 Running 0 25m 192.168.1.97 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
kube-system kube-proxy-lsgks 1/1 Running 0 25m 192.168.3.7 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
kube-system kube-proxy-mnzw6 1/1 Running 0 25m 192.168.2.59 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
pod 생성 후에 각 노드에 네트워크 인터페이스가 추가되었고, route table에는 각 pod ip에 해당하는 룰이 추가된 것을 볼 수 있습니다.
노드 하나에 접속해 네트워크 네임스페이스 정보를 살펴보면 아래와 같습니다.
먼저, 가장 마지막에 생성된 네임스페이스 정보를 확인합니다.
$ sudo lsns -o PID,COMMAND -t net | awk 'NR>2 {print $1}' | tail -n 1
13621
$ 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
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
link/ether 2a:ae:c4:bf:75:1e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.3.104/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::28ae:c4ff:febf:751e/64 scope link
valid_lft forever preferred_lft forever
$ sudo nsenter -t $MyPID -n ip -c route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link참고로 해당 pod(192.168.3.104)에 접속해서 네트워크 정보를 확인하면 위와 동일한 정보를 확인할 수 있습니다.
netshoot-pod-7757d5dd99-k2fwp $ ip -c addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
link/ether 2a:ae:c4:bf:75:1e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.3.104/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::28ae:c4ff:febf:751e/64 scope link
valid_lft forever preferred_lft forever
netshoot-pod-7757d5dd99-k2fwp $ ip -c route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
통신 흐름 확인
pod <-> pod
- 다른 노드
Node01(192.168.1.97)의 pod(netshoot-pod-7757d5dd99-9n9dc)에서 Node02(192.168.3.7)의 pod(netshoot-pod-7757d5dd99-k2fwp) 로 ping을 했을 때 각 pod와 노드에서 tcpdump 결과는 아래와 같습니다. 각 pod와 노드의 eth0 에서 패킷이 보이고, pod간 통신 시에 노드의 eni가 관여하는 것을 알 수 있습니다.
- 같은 노드
같은 노드의 pod 간 통신을 확인하기 위해 deployment의 replica 수를 9개로 늘려보았습니다.
$ k get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
netshoot-pod-7757d5dd99-97f4c 1/1 Running 0 2m15s 192.168.2.120 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-98mp2 1/1 Running 0 2m15s 192.168.1.105 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-9n9dc 1/1 Running 0 44m 192.168.1.134 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-d5zhh 1/1 Running 0 2m15s 192.168.3.43 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-hlhkv 1/1 Running 0 2m15s 192.168.3.81 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-k2fwp 1/1 Running 0 44m 192.168.3.104 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-pm8c4 1/1 Running 0 44m 192.168.2.254 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-q6rgc 1/1 Running 0 2m15s 192.168.2.9 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-zllvw 1/1 Running 0 2m15s 192.168.1.32 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>Node01(192.168.1.97)의 pod(netshoot-pod-7757d5dd99-9n9dc)에서 pod(netshoot-pod-7757d5dd99-98mp2)로 ping을 날려보겠습니다.
tcpdump 결과를 살펴보면, 노드의 eth0, eth1에는 패킷이 도달하지 않고 pod의 네트워크 인터페이스로 통신하는 것을 볼 수 있습니다.
물론 노드에서 sudo tcpdump -i any -nn icmp 명령어로 덤프를 떴을 때는 pod의 인터페이스도 포함되어 패킷을 확인할 수 있습니다.
pod <-> internet
이번에는 Node01(192.168.1.97)의 pod(netshoot-pod-7757d5dd99-9n9dc)에서 인터넷(8.8.8.8)으로 ping을 날려보겠습니다.
다른 노드에 있는 pod간 통신과 동일하게 Node의 primary ENI를 거치는 것을 확인할 수 있습니다.
VPC CNI 모드 변경
prefix mode
이번에는 기본 모드인 Secondary IP mode 대신 prefix mode로 클러스터 설정을 변경해보겠습니다.
prefix 여유분을 두기 위해 WARM_PREFIX_TARGET 설정도 추가했습니다.
$ kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
$ kubectl set env daemonset aws-node -n kube-system WARM_PREFIX_TARGET=1해당 설정 후 Node01을 보면 Secondar private IPv4 addresses가 줄어든 것을 볼 수 있습니다.
192.168.1.248은 prefix 모드로 변경하기 전에 생성된 coredns pod이므로 해당 pod를 재생성하면 Secondar private IPv4 addresses에는 IP가 모두 사라집니다.
대신 해당 노드의 eni를 살펴보면, IPv4 Prefix Delegation에 /28 CIDR 이 추가된 것을 볼 수 있습니다.
Custom Networking 적용
prefix 모드로 변경했어도 VPC IP대역은 한정적이기 때문에 pod 생성에도 제약이 있습니다. 이번에는 추가로 100.64.0.0/16 대역을 활용해서 subnet을 추가해보겠습니다.
1) VPC Secondary CIDR 추가
100.64.0.0/16 대역을 VPC에 추가합니다.
2) subnet 생성 및 라우팅 테이블 연결
AZ 분산을 위해 3개의 subnet을 생성하고 기존 Public subnet에 연결한 라우팅 테이블과 연결했습니다.
3) eniconfig 설정
Custom Network를 enable 합니다.
$ kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true미리 생성한 3개의 subnet을 활용하여 ENIConfig를 만듭니다.
securityGroup은 SGP를 사용한다면 해당 sg로 설정하고 그렇지 않으면 노드의 sg를 설정합니다.
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
name: ap-northeast-2a
spec:
securityGroups:
- sg-045b3640a1ff260aa
subnet: subnet-093bb7f61c3cffcbaapiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
name: ap-northeast-2b
spec:
securityGroups:
- sg-045b3640a1ff260aa
subnet: subnet-0f444021d1e6d3575apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
name: ap-northeast-2c
spec:
securityGroups:
- sg-045b3640a1ff260aa
subnet: subnet-081e5c6a9870c212f생성 후에 아래 명령어로 확인할 수 있습니다.
$ k get eniconfig
NAME AGE
ap-northeast-2a 15m
ap-northeast-2b 5m22s
ap-northeast-2c 5m18s4) pod 생성 테스트
이제 신규 pod가 100.64 대역의 IP로 생성되면 정상적으로 설정된 것입니다.
이전에 활용한 netshoot-pod deployment의 replica 수를 0으로 설정했다가 10으로 변경했습니다.
$ k get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
netshoot-pod-7757d5dd99-7pxfb 1/1 Running 0 12m 100.64.55.192 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-8j2b4 1/1 Running 0 12m 100.64.129.160 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-cfd2h 1/1 Running 0 12m 100.64.129.162 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-nnfkr 1/1 Running 0 12m 100.64.117.65 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-nzhnt 1/1 Running 0 12m 100.64.117.66 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-qgdd2 1/1 Running 0 12m 100.64.41.210 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-sb7vm 1/1 Running 0 12m 100.64.117.64 ip-192-168-2-59.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-th5xd 1/1 Running 0 12m 100.64.129.161 ip-192-168-3-7.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-v4kzp 1/1 Running 0 12m 100.64.41.209 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>
netshoot-pod-7757d5dd99-znbdb 1/1 Running 0 12m 100.64.41.208 ip-192-168-1-97.ap-northeast-2.compute.internal <none> <none>100.64 대역의 IP가 Pod에 정상적으로 할당된 것을 볼 수 있습니다.
또한, 이전에 배포된 Pod들은 신규 대역의 IP를 사용하기 위해 재생성이 필요합니다.
이상으로 EKS Networking 정리를 마치겠습니다.
참고 문서
- Working with the Amazon VPC CNI plugin for Kubernetes Amazon EKS add-on
- Amazon VPC CNI
- pkos 스터디 2주차 2편 - AWS VPC CNI
1) Network namespace
리눅스 OS에서 제공하는 기능으로 네트워크 관련 리소스(eni, ip, iptables 규칙, routing table 등)들을 격리하기 위한 기술을 말합니다.
프로세스를 실행할 때 namespace 별로 분리할 수 있으며, 주로 컨테이너에서 많이 사용됩니다.
'Kubernetes > EKS Study' 카테고리의 다른 글
| [4주차] EKS Observability (0) | 2023.05.21 |
|---|---|
| [3주차] EKS Storage (0) | 2023.05.09 |
| EKS에서 볼륨 snapscheduler 설치하기 (0) | 2023.05.09 |
| EKS에서 pvc로 생성한 ebs에 태그 추가하기 (0) | 2023.05.09 |
| [1주차] EKS 설치 및 기본 사용 (2) | 2023.04.24 |