<div id="readability-page-1" class="page"><div>*본 게시글의 내용은 가시다님의 노션 페이지와 스터디 자료를 기반으로 작성하였습니다.
<h2>AWS VPC CNI</h2>
<img src="https://i.imgur.com/kqfZjhb.png" alt="">
)
<img src="https://i.imgur.com/09eLDUM.png" alt="">
<ul data-ke-list-type="disc">
<li>AWS 환경에서 동작하는 Kops나 EKS를 위한 CNI</li>
<li>온프레미스에 k8s를 구성하면 노드(호스트)의 네트워크 대역과 파드의 네트워크 대역이 다르다.</li>
<li>AWS VPC CNI는 노드와 파드가 같은 네트워크 대역을 사용하며, 각 파드에 eni가 연결되어 독립적인 IP를 할당받아 사용할 수 있다.</li>
<li>단, 파드의 개수가 많아지면 많아질수록 각 서브넷에서 가용한 IP의 수가 그만큼 소모되고, 노드의 역할을 하는 EC2가 가질 수 있는 ENI당 Secondary IP의 리밋도 있기 때문에 사전에 고려가 필요하다.</li>
<li>단, Kops는 아직 PodSecurityGroup을 지원하지는 않는다. 현재는 EKS에서만 가능.</li>
<li>kube-proxy와 aws-node 파드 등 몇몇 파드는 노드와 동일한 IP를 가진다. 때문에 ENI Secondary IP 갯수를 계산할 때 포함하지 않는다.</li>
</ul>
<pre><code>[root@kops-ec2 ~]# kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-01493969e37859769 Ready control-plane 35m v1.24.11 172.30.42.219 3.36.54.165 Ubuntu 20.04.5 LTS 5.15.0-1031-aws containerd://1.6.18
i-0e56757db751fb4e9 Ready node 32m v1.24.11 172.30.63.228 13.209.10.83 Ubuntu 20.04.5 LTS 5.15.0-1031-aws containerd://1.6.18

[root@kops-ec2 ~]kubectl get pod -o wide -A
...
kube-system aws-node-gf6hx 1/1 Running 0 36m 172.30.42.219 i-01493969e37859769 &lt;none&gt; &lt;none&gt;
kube-system aws-node-vxf5r 1/1 Running 0 34m 172.30.63.228 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;

...

kube-system kube-proxy-i-01493969e37859769 1/1 Running 0 35m 172.30.42.219 i-01493969e37859769 &lt;none&gt; &lt;none&gt;
kube-system kube-proxy-i-0e56757db751fb4e9 1/1 Running 0 34m 172.30.63.228 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;
...
...</code></pre>
node의 IP 라우팅 정보를 보면, veth 인터페이스로 걸려있는 IP들이 VPC CNI에 물려있는 파드의 IP이다.
<pre><code>ubuntu@i-01493969e37859769:~$ ip -c route
default via 172.30.32.1 dev ens5 proto dhcp src 172.30.42.219 metric 100 
172.30.32.0/19 dev ens5 proto kernel scope link src 172.30.42.219 
172.30.32.1 dev ens5 proto dhcp scope link src 172.30.42.219 metric 100 
172.30.60.80 dev enif9dc7364ce2 scope link 
172.30.60.81 dev eni4d9edc11021 scope link 
172.30.60.82 dev enia699f5ca146 scope link 
172.30.60.83 dev eni35b0ddd5b59 scope link

---

[root@kops-ec2 ~]# kubectl get pod -A -o wide | grep "172.30.60.80"
kube-system ebs-csi-node-xzdbn 3/3 Running 0 40m 172.30.60.80 i-01493969e37859769 &lt;none&gt; &lt;none&gt;</code></pre>
파드를 생성하면, 파드가 배치된 노드의 라우팅 정보에서도 추가된 파드의 IP를 확인할 수 있다.
<pre><code>(ilikebigmac:default) [root@kops-ec2 ~]# kubectl get pod -o wide
columns=NAME:.metadata.name,IP:.status.podIPNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
netshoot-pod-7757d5dd99-cvggz 1/1 Running 0 88s 172.30.57.181 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;
netshoot-pod-7757d5dd99-r4lnj 1/1 Running 0 88s 172.30.57.182 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;</code></pre>
생성된 파드 내에서 exec으로 접근해도 같은 172.30.57.181 IP를 확인할 수 있다.
<pre><code>netshoot-pod-7757d5dd99-cvggz# ip -c route
default via 169.254.1.1 dev eth0 
169.254.1.1 dev eth0 scope link 
netshoot-pod-7757d5dd99-cvggz# ip -c addr 
1: lo: &lt;LOOPBACK,UP,LOWER_UP&gt; 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@if9: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 9001 qdisc noqueue state UP group default 
 link/ether 7e:9b:0d:58:45:f9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
 inet 172.30.57.181/32 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 fe80::7c9b:dff:fe58:45f9/64 scope link 
 valid_lft forever preferred_lft forever</code></pre>
<h2>파드간 통신</h2>
확인해 본 바와 같이 AWS VPC CNI를 이용하면 파드는 노드와 같은 IP 대역을 할당받게 된다.
노드는 EC2로 구성되어 있으므로 노드와 파드는 동일한 VPC 내에 위치한다는 의미이다.
그리고 VPC의 대역은 앞서 확인한 파드와 노드의 IP 대역인 172.30으로 시작하는 대역이다.
<img src="https://i.imgur.com/qvgWLhT.png" alt="">
따라서 서로 같은 VPC 내에 위치한 모든 파드들은 NAT를 통하지 않더라도 VPC 대역에 해당하는 Private IP로 통신을 할 수 있게 된다.
<h2>파드의 외부 네트워크 통신</h2>
<pre><code>netshoot-pod-7757d5dd99-cvggz# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=104 time=22.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=104 time=22.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=104 time=22.6 ms</code></pre>
파드 내에서 구글 DNS로 ping을 날려보면 정상적으로 응답을 주고받을 수 있다. 그렇다면 외부 통신은 어떻게 될까?
<pre><code>ubuntu@i-0e56757db751fb4e9:~$ sudo iptables -t nat -S | grep 'A AWS-SNAT-CHAIN'
-A AWS-SNAT-CHAIN-0 ! -d 172.30.0.0/16 -m comment --comment "AWS SNAT CHAIN" -j AWS-SNAT-CHAIN-1
-A AWS-SNAT-CHAIN-1 ! -o vlan+ -m comment --comment "AWS, SNAT" -m addrtype ! --dst-type LOCAL -j SNAT --to-source 172.30.63.228 --random-fully</code></pre>
워커 노드에서 확인해보면, 파드가 외부와 통신할 때는 AWS-SNAT-CHAIN 에 의해 EC2의 Public IP로 SNAT되어서 외부와 통신하게 된다.
<h2>k8s Service &amp; AWS LoadBalancer Controller</h2>
<img src="https://i.imgur.com/6QCDmWn.png" alt="">
AWS LoadBalancer Controller는 ELB의 Target Group에 타겟으로 연결된 Pod의 정보를 지속적으로 제공하는 역할을 한다.
k8s Service를 LoadBalancer Type으로 생성하면 타겟을 Instance와 IP 타입 중 선택할 수 있는데, IP 타입으로 구성하게 되면 ELB는 LoadBalancer Controller에 의해 Pod의 IP를 동적으로 제공받게 된다.
따라서 Client-ELB-Pod로 효율적인 네트워크를 구성할 수 있다. 만약 Instance Type을 선택하게 되면 기존에 사용하던 NodePort 방식으로 구성된다.
<a href="https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html">AWS LoadBalancer Conteroller Docs</a>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
 name: deploy-echo
spec:
 replicas: 2
 selector:
 matchLabels:
 app: deploy-websrv
 template:
 metadata:
 labels:
 app: deploy-websrv
 spec:
 terminationGracePeriodSeconds: 0
 containers:
 - name: akos-websrv
 image: k8s.gcr.io/echoserver:1.5
 ports:
 - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
 name: svc-nlb-ip-type
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
 service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
 service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"
 service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
spec:
 ports:
 - port: 80
 targetPort: 8080
 protocol: TCP
 type: LoadBalancer
 loadBalancerClass: service.k8s.aws/nlb
 selector:
 app: deploy-websr</code></pre>
<a href="https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/ingress/annotations/">AWS LoadBalancer Conterller Annotations</a>
Service metadata에 기입된 annotations는 어떤 방식으로 ELB에 서비스와 파드를 매핑하여 구성할 것인지 정의하게 된다.
위 링크에서 NLB/ALB의 각기 다른 annotation을 확인할 수 있다.
위의 서비스는 NLB에 ip타입으로 매핑하며 cross zone load balancing 옵션을 enable 하고, internt-facing 이므로 외부에서 브라우저로 접근해도 위와 같이 서비스에 접근이 가능하다.
이와 같은 구성으로 AWS 환경에 NLB가 생성된다.
<img src="https://i.imgur.com/ccRJzNe.png" alt="">
internet-facing이므로 일반 환경에서도 생성된 NLB의 DNS Name으로 접속해보면 위와 같은 결과를 확인할 수 있다.
<img src="https://i.imgur.com/VWFbwic.png" alt="">
연결된 타겟그룹에는 172.30.57.181, 172.30.57.182 두 개의 IP와 8080포트로 매핑되어 있다.
<pre><code>(ilikebigmac:default) [root@kops-ec2 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-echo-5c4856dfd6-bhvjm 1/1 Running 0 8m25s 172.30.57.181 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;
deploy-echo-5c4856dfd6-g7vht 1/1 Running 0 8m25s 172.30.57.182 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;</code></pre>
그리고 이들 IP는 앞서 echo-server deployment에 의해 배포된 파드의 IP임을 확인 가능하다.
<h2>Ingress</h2>
<img src="https://i.imgur.com/pUKPTcF.png" alt="">
인그레스는 클러스터 내부의 서비스(ClusterIP, NodePort, Loadbalancer)를 HTTP/HTTPS로 외부에 노출시키는 Web Proxy의 역할을 한다.
<pre><code>apiVersion: v1
kind: Namespace
metadata:
 name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: game-2048
 name: deployment-2048
spec:
 selector:
 matchLabels:
 app.kubernetes.io/name: app-2048
 replicas: 2
 template:
 metadata:
 labels:
 app.kubernetes.io/name: app-2048
 spec:
 containers:
 - image: public.ecr.aws/l6m2t8p7/docker-2048:latest
 imagePullPolicy: Always
 name: app-2048
 ports:
 - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 namespace: game-2048
 name: service-2048
spec:
 ports:
 - port: 80
 targetPort: 80
 protocol: TCP
 type: NodePort
 selector:
 app.kubernetes.io/name: app-2048
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 namespace: game-2048
 name: ingress-2048
 annotations:
 alb.ingress.kubernetes.io/scheme: internet-facing
 alb.ingress.kubernetes.io/target-type: ip
spec:
 ingressClassName: alb
 rules:
 - http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: service-2048
 port:
 number: 80</code></pre>
<img src="https://i.imgur.com/mtyDaCH.png" alt="">
마찬가지로 annotation에 의해 ip타입의 internet-facing ALB가 AWS 환경에 생성된다.
<pre><code> [root@kops-ec2 ~]# kubectl get pod -n game-2048 -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deployment-2048-6bc9fd6bf5-c64wr 1/1 Running 0 4m14s 172.30.55.145 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;
deployment-2048-6bc9fd6bf5-ks2v4 1/1 Running 0 4m14s 172.30.55.144 i-0e56757db751fb4e9 &lt;none&gt; &lt;none&gt;</code></pre>
<img src="https://i.imgur.com/0TpwIYD.png" alt="">
타겟 역시 IP타입으로 매핑되어 파드의 IP와 동일하며, 80포트로 매핑되어 있다.
<img src="https://i.imgur.com/Nwiaaqb.png" alt="">
ALB의 DNS Name으로 접근하면 호스팅 중인 웹 서비스에 접근이 가능하다.
<img src="https://i.imgur.com/N3iOmwD.png" alt="">
이와 같은 웹 서비스를 배포하는 상황을 가정하고, 생성된 ALB에 ExternalDNS를 <code>albweb.ilikebigamc.link</code> 로 설정하였으며, 정상 접근됨을 확인하였다.
DNS 레코드와 등록 정보를 살펴보면
<pre><code>(ilikebigmac:default) [root@kops-ec2 ~]# curl albweb.ilikebigmac.link -vvv
* Trying 3.39.77.155:80...
* Connected to albweb.ilikebigmac.link (3.39.77.155) port 80 (#0)
&gt; GET / HTTP/1.1
&gt; Host: albweb.ilikebigmac.link
&gt; User-Agent: curl/7.88.1
&gt; Accept: */*
&gt; 
&lt; HTTP/1.1 200 OK
&lt; Date: Sat, 18 Mar 2023 20:20:08 GMT
&lt; Content-Type: text/html
&lt; Content-Length: 3988
&lt; Connection: keep-alive
&lt; Server: nginx
&lt; Last-Modified: Wed, 06 Oct 2021 17:35:37 GMT
&lt; ETag: "615dde69-f94"
&lt; Accept-Ranges: bytes
&lt; 

...

* Connection #0 to host albweb.ilikebigmac.link left intac

(ilikebigmac:default) [root@kops-ec2 ~]# dig albweb.ilikebigmac.link

; &lt;&lt;&gt;&gt; DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 &lt;&lt;&gt;&gt; albweb.ilikebigmac.link
;; global options: +cmd
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 36674
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;albweb.ilikebigmac.link. IN A

;; ANSWER SECTION:
albweb.ilikebigmac.link. 21 IN A 3.39.208.51
albweb.ilikebigmac.link. 21 IN A 3.39.77.155

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Mar 19 05:20:41 KST 2023
;; MSG SIZE rcvd: 84</code></pre>
<code>3.39.208.51</code> 과 <code>3.39.77.155</code> 라는 두 개의 IP를 돌려주는데 이를 ENI에서 조회해보면 ALB의 Public IP임을 알 수 있다.
<img src="https://i.imgur.com/zAZJJVp.png" alt="">
<div data-ke-size="size16">따라서&nbsp;지금까지&nbsp;확인한&nbsp;내용을&nbsp;바탕으로&nbsp;`albweb.ilikebigmac.link`&nbsp;에&nbsp;접속할&nbsp;때&nbsp;클라이언트는&nbsp;Route53(External&nbsp;DNS)&nbsp;-&gt;&nbsp;ALB&nbsp;-&gt;&nbsp;Pod의&nbsp;흐름으로&nbsp;페이지에&nbsp;접근하게&nbsp;됨을&nbsp;알&nbsp;수&nbsp;있었다.이&nbsp;때&nbsp;Route53에&nbsp;등록되는&nbsp;도메인은&nbsp;ExternalDNS에&nbsp;의헤&nbsp;레코드&nbsp;관리되고,&nbsp;LoadBalancer&nbsp;Controller는&nbsp;동적으로&nbsp;변화하는&nbsp;Pod의&nbsp;IP를&nbsp;지속적으로&nbsp;ELB에&nbsp;제공한다.ELB는&nbsp;k8s&nbsp;Service&nbsp;명세의&nbsp;annotation에&nbsp;매핑된&nbsp;정보를&nbsp;바탕으로&nbsp;생성한&nbsp;ELB에&nbsp;타겟&nbsp;그룹을&nbsp;연결,&nbsp;타겟&nbsp;그룹에는&nbsp;전달받은&nbsp;Pod의&nbsp;IP/Port&nbsp;가&nbsp;타겟으로&nbsp;등록된다.EKS에서&nbsp;VPC&nbsp;CNI를&nbsp;사용하는&nbsp;경우&nbsp;이러한&nbsp;구조&nbsp;덕에Pod에&nbsp;직접&nbsp;보안&nbsp;그룹을&nbsp;적용할&nbsp;수&nbsp;있으며,&nbsp;Node와&nbsp;Pod는&nbsp;동일&nbsp;네트워크&nbsp;대역을&nbsp;가지고&nbsp;이&nbsp;대역은&nbsp;VPC&nbsp;CIDR에&nbsp;해당한다.각&nbsp;Pod의&nbsp;IP는&nbsp;ENI의&nbsp;Secondary&nbsp;IP로&nbsp;등록되는데,&nbsp;EC2의&nbsp;Instance&nbsp;Type에&nbsp;따라&nbsp;등록될&nbsp;수&nbsp;있는&nbsp;Pod&nbsp;IP의&nbsp;갯수에&nbsp;제한이&nbsp;있고,&nbsp;각&nbsp;서브넷에서도&nbsp;available&nbsp;IP에&nbsp;제한이&nbsp;있으므로&nbsp;인스턴스별,&nbsp;서브넷별로&nbsp;배치할&nbsp;파드의&nbsp;갯수가&nbsp;적절한지&nbsp;배포&nbsp;전에&nbsp;검증해볼&nbsp;필요가&nbsp;있다.</div></div></div>

노오력을해라

*본 게시글의 내용은 가시다님의 노션 페이지와 스터디 자료를 기반으로 작성하였습니다.
AWS VPC CNI
)
AWS 환경에서 동작하는 Kops나 EKS를 위한 CNI
온프레미스에 k8s를 구성하면 노드(호스트)의 네트워크 대역과 파드의 네트워크 대역이 다르다.
AWS VPC CNI는 노드와 파드가 같은 네트워크 대역을 사용하며, 각 파드에 eni가 연결되어 독립적인 IP를 할당받아 사용할 수 있다.
단, 파드의 개수가 많아지면 많아질수록 각 서브넷에서 가용한 IP의 수가 그만큼 소모되고, 노드의 역할을 하는 EC2가 가질 수 있는 ENI당 Secondary IP의 리밋도 있기 때문에 사전에 고려가 필요하다.
단, Kops는 아직 PodSecurityGroup을 지원하지는 않는다. 현재는 EKS에서만 가능.
kube-proxy와 aws-node 파드 등 몇몇 파드는 노드와 동일한 IP를 가진다. 때문에 ENI Secondary IP 갯수를 계산할 때 포함하지 않는다.
[root@kops-ec2 ~]# kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-01493969e37859769 Ready control-plane 35m v1.24.11 172.30.42.219 3.36.54.165 Ubuntu 20.04.5 LTS 5.15.0-1031-aws containerd://1.6.18
i-0e56757db751fb4e9 Ready node 32m v1.24.11 172.30.63.228 13.209.10.83 Ubuntu 20.04.5 LTS 5.15.0-1031-aws containerd://1.6.18
[root@kops-ec2 ~]kubectl get pod -o wide -A
...
kube-system aws-node-gf6hx 1/1 Running 0 36m 172.30.42.219 i-01493969e37859769 <none> <none>
kube-system aws-node-vxf5r 1/1 Running 0 34m 172.30.63.228 i-0e56757db751fb4e9 <none> <none>
...
kube-system kube-proxy-i-01493969e37859769 1/1 Running 0 35m 172.30.42.219 i-01493969e37859769 <none> <none>
kube-system kube-proxy-i-0e56757db751fb4e9 1/1 Running 0 34m 172.30.63.228 i-0e56757db751fb4e9 <none> <none>
...
...
node의 IP 라우팅 정보를 보면, veth 인터페이스로 걸려있는 IP들이 VPC CNI에 물려있는 파드의 IP이다.
ubuntu@i-01493969e37859769:~$ ip -c route
default via 172.30.32.1 dev ens5 proto dhcp src 172.30.42.219 metric 100 
172.30.32.0/19 dev ens5 proto kernel scope link src 172.30.42.219 
172.30.32.1 dev ens5 proto dhcp scope link src 172.30.42.219 metric 100 
172.30.60.80 dev enif9dc7364ce2 scope link 
172.30.60.81 dev eni4d9edc11021 scope link 
172.30.60.82 dev enia699f5ca146 scope link 
172.30.60.83 dev eni35b0ddd5b59 scope link
---
[root@kops-ec2 ~]# kubectl get pod -A -o wide | grep "172.30.60.80"
kube-system ebs-csi-node-xzdbn 3/3 Running 0 40m 172.30.60.80 i-01493969e37859769 <none> <none>
파드를 생성하면, 파드가 배치된 노드의 라우팅 정보에서도 추가된 파드의 IP를 확인할 수 있다.
(ilikebigmac:default) [root@kops-ec2 ~]# kubectl get pod -o wide
columns=NAME:.metadata.name,IP:.status.podIPNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
netshoot-pod-7757d5dd99-cvggz 1/1 Running 0 88s 172.30.57.181 i-0e56757db751fb4e9 <none> <none>
netshoot-pod-7757d5dd99-r4lnj 1/1 Running 0 88s 172.30.57.182 i-0e56757db751fb4e9 <none> <none>
생성된 파드 내에서 exec으로 접근해도 같은 172.30.57.181 IP를 확인할 수 있다.
netshoot-pod-7757d5dd99-cvggz# ip -c route
default via 169.254.1.1 dev eth0 
169.254.1.1 dev eth0 scope link 
netshoot-pod-7757d5dd99-cvggz# 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@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default 
 link/ether 7e:9b:0d:58:45:f9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
 inet 172.30.57.181/32 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 fe80::7c9b:dff:fe58:45f9/64 scope link 
 valid_lft forever preferred_lft forever
파드간 통신
확인해 본 바와 같이 AWS VPC CNI를 이용하면 파드는 노드와 같은 IP 대역을 할당받게 된다.
노드는 EC2로 구성되어 있으므로 노드와 파드는 동일한 VPC 내에 위치한다는 의미이다.
그리고 VPC의 대역은 앞서 확인한 파드와 노드의 IP 대역인 172.30으로 시작하는 대역이다.
따라서 서로 같은 VPC 내에 위치한 모든 파드들은 NAT를 통하지 않더라도 VPC 대역에 해당하는 Private IP로 통신을 할 수 있게 된다.
파드의 외부 네트워크 통신
netshoot-pod-7757d5dd99-cvggz# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=104 time=22.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=104 time=22.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=104 time=22.6 ms
파드 내에서 구글 DNS로 ping을 날려보면 정상적으로 응답을 주고받을 수 있다. 그렇다면 외부 통신은 어떻게 될까?
ubuntu@i-0e56757db751fb4e9:~$ sudo iptables -t nat -S | grep 'A AWS-SNAT-CHAIN'
-A AWS-SNAT-CHAIN-0 ! -d 172.30.0.0/16 -m comment --comment "AWS SNAT CHAIN" -j AWS-SNAT-CHAIN-1
-A AWS-SNAT-CHAIN-1 ! -o vlan+ -m comment --comment "AWS, SNAT" -m addrtype ! --dst-type LOCAL -j SNAT --to-source 172.30.63.228 --random-fully
워커 노드에서 확인해보면, 파드가 외부와 통신할 때는 AWS-SNAT-CHAIN 에 의해 EC2의 Public IP로 SNAT되어서 외부와 통신하게 된다.
k8s Service & AWS LoadBalancer Controller
AWS LoadBalancer Controller는 ELB의 Target Group에 타겟으로 연결된 Pod의 정보를 지속적으로 제공하는 역할을 한다.
k8s Service를 LoadBalancer Type으로 생성하면 타겟을 Instance와 IP 타입 중 선택할 수 있는데, IP 타입으로 구성하게 되면 ELB는 LoadBalancer Controller에 의해 Pod의 IP를 동적으로 제공받게 된다.
따라서 Client-ELB-Pod로 효율적인 네트워크를 구성할 수 있다. 만약 Instance Type을 선택하게 되면 기존에 사용하던 NodePort 방식으로 구성된다.
AWS LoadBalancer Conteroller Docs
apiVersion: apps/v1
kind: Deployment
metadata:
 name: deploy-echo
spec:
 replicas: 2
 selector:
 matchLabels:
 app: deploy-websrv
 template:
 metadata:
 labels:
 app: deploy-websrv
 spec:
 terminationGracePeriodSeconds: 0
 containers:
 - name: akos-websrv
 image: k8s.gcr.io/echoserver:1.5
 ports:
 - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
 name: svc-nlb-ip-type
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
 service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
 service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"
 service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
spec:
 ports:
 - port: 80
 targetPort: 8080
 protocol: TCP
 type: LoadBalancer
 loadBalancerClass: service.k8s.aws/nlb
 selector:
 app: deploy-websr
AWS LoadBalancer Conterller Annotations
Service metadata에 기입된 annotations는 어떤 방식으로 ELB에 서비스와 파드를 매핑하여 구성할 것인지 정의하게 된다.
위 링크에서 NLB/ALB의 각기 다른 annotation을 확인할 수 있다.
위의 서비스는 NLB에 ip타입으로 매핑하며 cross zone load balancing 옵션을 enable 하고, internt-facing 이므로 외부에서 브라우저로 접근해도 위와 같이 서비스에 접근이 가능하다.
이와 같은 구성으로 AWS 환경에 NLB가 생성된다.
internet-facing이므로 일반 환경에서도 생성된 NLB의 DNS Name으로 접속해보면 위와 같은 결과를 확인할 수 있다.
연결된 타겟그룹에는 172.30.57.181, 172.30.57.182 두 개의 IP와 8080포트로 매핑되어 있다.
(ilikebigmac:default) [root@kops-ec2 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-echo-5c4856dfd6-bhvjm 1/1 Running 0 8m25s 172.30.57.181 i-0e56757db751fb4e9 <none> <none>
deploy-echo-5c4856dfd6-g7vht 1/1 Running 0 8m25s 172.30.57.182 i-0e56757db751fb4e9 <none> <none>
그리고 이들 IP는 앞서 echo-server deployment에 의해 배포된 파드의 IP임을 확인 가능하다.
Ingress
인그레스는 클러스터 내부의 서비스(ClusterIP, NodePort, Loadbalancer)를 HTTP/HTTPS로 외부에 노출시키는 Web Proxy의 역할을 한다.
apiVersion: v1
kind: Namespace
metadata:
 name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: game-2048
 name: deployment-2048
spec:
 selector:
 matchLabels:
 app.kubernetes.io/name: app-2048
 replicas: 2
 template:
 metadata:
 labels:
 app.kubernetes.io/name: app-2048
 spec:
 containers:
 - image: public.ecr.aws/l6m2t8p7/docker-2048:latest
 imagePullPolicy: Always
 name: app-2048
 ports:
 - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 namespace: game-2048
 name: service-2048
spec:
 ports:
 - port: 80
 targetPort: 80
 protocol: TCP
 type: NodePort
 selector:
 app.kubernetes.io/name: app-2048
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 namespace: game-2048
 name: ingress-2048
 annotations:
 alb.ingress.kubernetes.io/scheme: internet-facing
 alb.ingress.kubernetes.io/target-type: ip
spec:
 ingressClassName: alb
 rules:
 - http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: service-2048
 port:
 number: 80
마찬가지로 annotation에 의해 ip타입의 internet-facing ALB가 AWS 환경에 생성된다.
 [root@kops-ec2 ~]# kubectl get pod -n game-2048 -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deployment-2048-6bc9fd6bf5-c64wr 1/1 Running 0 4m14s 172.30.55.145 i-0e56757db751fb4e9 <none> <none>
deployment-2048-6bc9fd6bf5-ks2v4 1/1 Running 0 4m14s 172.30.55.144 i-0e56757db751fb4e9 <none> <none>
타겟 역시 IP타입으로 매핑되어 파드의 IP와 동일하며, 80포트로 매핑되어 있다.
ALB의 DNS Name으로 접근하면 호스팅 중인 웹 서비스에 접근이 가능하다.
이와 같은 웹 서비스를 배포하는 상황을 가정하고, 생성된 ALB에 ExternalDNS를 albweb.ilikebigamc.link 로 설정하였으며, 정상 접근됨을 확인하였다.
DNS 레코드와 등록 정보를 살펴보면
(ilikebigmac:default) [root@kops-ec2 ~]# curl albweb.ilikebigmac.link -vvv
* Trying 3.39.77.155:80...
* Connected to albweb.ilikebigmac.link (3.39.77.155) port 80 (#0)
> GET / HTTP/1.1
> Host: albweb.ilikebigmac.link
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sat, 18 Mar 2023 20:20:08 GMT
< Content-Type: text/html
< Content-Length: 3988
< Connection: keep-alive
< Server: nginx
< Last-Modified: Wed, 06 Oct 2021 17:35:37 GMT
< ETag: "615dde69-f94"
< Accept-Ranges: bytes
< 
...
* Connection #0 to host albweb.ilikebigmac.link left intac
(ilikebigmac:default) [root@kops-ec2 ~]# dig albweb.ilikebigmac.link
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> albweb.ilikebigmac.link
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36674
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;albweb.ilikebigmac.link. IN A
;; ANSWER SECTION:
albweb.ilikebigmac.link. 21 IN A 3.39.208.51
albweb.ilikebigmac.link. 21 IN A 3.39.77.155
;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Mar 19 05:20:41 KST 2023
;; MSG SIZE rcvd: 84
3.39.208.51 과 3.39.77.155 라는 두 개의 IP를 돌려주는데 이를 ENI에서 조회해보면 ALB의 Public IP임을 알 수 있다.
따라서 지금까지 확인한 내용을 바탕으로 `albweb.ilikebigmac.link` 에 접속할 때 클라이언트는 Route53(External DNS) -> ALB -> Pod의 흐름으로 페이지에 접근하게 됨을 알 수 있었다.
이 때 Route53에 등록되는 도메인은 ExternalDNS에 의헤 레코드 관리되고, LoadBalancer Controller는 동적으로 변화하는 Pod의 IP를 지속적으로 ELB에 제공한다.
ELB는 k8s Service 명세의 annotation에 매핑된 정보를 바탕으로 생성한 ELB에 타겟 그룹을 연결, 타겟 그룹에는 전달받은 Pod의 IP/Port 가 타겟으로 등록된다.
EKS에서 VPC CNI를 사용하는 경우 이러한 구조 덕에Pod에 직접 보안 그룹을 적용할 수 있으며, Node와 Pod는 동일 네트워크 대역을 가지고 이 대역은 VPC CIDR에 해당한다.
각 Pod의 IP는 ENI의 Secondary IP로 등록되는데, EC2의 Instance Type에 따라 등록될 수 있는 Pod IP의 갯수에 제한이 있고, 각 서브넷에서도 available IP에 제한이 있으므로 인스턴스별, 서브넷별로 배치할 파드의 갯수가 적절한지 배포 전에 검증해볼 필요가 있다.

[2주차] VPC CNI와 LoadBalancer Controller

댓글