AWES 2주차 - EKS Networking: Service의 iptables, Ingress

AWES 2주차로, EKS Networking에 대한 내용을 학습 후 정리하였습니다.

참고: AWS EKS Overview Youtube

Youtube - "이게 돼요? 도커 없이 컨테이너 만들기"를 참고하여 실습한 내용도 정리해두었으니 참고하시기 바랍니다. - Link

Container VS Pod

• Bridge
  : 일반적으로 서버에 Docker를 설치하게되면, 가상의 Bridge 네트워크가 생성됩니다.
  물리 IP 주소와 전혀 다른, 가상 IP가 생성되게 되는 것이며, Default 옵션입니다.

• Host
  : Container가 Host의 IP를 공유해서 사용하게 됩니다.
  장점은 구조가 심플한 것이지만, 하나의 IP를 사용하기에 Port가 충돌하는 경우가 발생 가능합니다.

• Container
  : Container 1/2 각각 존재하는 경우, 각 container 1번이 가진 네트워크 인터페이스에 대해 공유가 가능합니다. 즉, Pod와 동일한 개념입니다.

• None
  : LoopBack 인터페이스를 위한 옵션으로 내부에서만 통신이 이루어지도록 사용됩니다.

A와 B 서버에 각각 Contaienr 2개씩 있다고 생각해보겠습니다.
A서버의 container 1, 2번은 이전에 말했다 싶이, 정상적으로 통신이 가능합니다.

❓그럼, A와 B 서버의 각 container 들끼리는 통신이 가능할까요?
당연히 통신이 불가능합니다.
왜? 서버 내의 컨테이너들은 상대방의 가상 IP를 알 수 있는 방법이 없기 때문입니다.

Overlay Network

❗서로 다른 서버에 존재하는 컨테이너들끼리 IP를 알 수 있도록 사용되는 기술
: Overlay Network -> VXLAN or IPIP

• 가상 IP 들은 서로를 모르기 때문에, 옆에 Outer IP를 추가해서 통신이 필요할 때, 해당 Outer IP를 통해서 출/입을 하도록 하는 방식

예를 든 통신 구조: Container 1 -> A 서버 -> Outer IP -> B 서버 -> Container 4

• Container 1에서 B서버로 접근만 되면, B서버에서는 각 컨테이너의 IP를 알기 때문에 가능한 것

Kubernetes에서 Overlay Network를 사용하려면?

• Calico, Cillium등과 같은 CNI(Container Network Interface) 툴을 사용하면 됩니다.

CNI를 사용하면 장점이 뭔가요?

CNI을 사용하기 전과 달리, CNI를 사용하면 Secondary IP라는 VPC IP를 추가로 노드에 할당받을 수 있게 됩니다.
즉, Container 1번과 container 4번이 각각 VPC IP를 사용하기 때문에, 통신을 위해서 Outer IP가 필요하지 않습니다.

• Source와 destination IP만 각각 지정해주면 됨

VPC CNI에는 L-IPAM이라는 IP Pool이 존재하며, 이는 IP를 사용하지 않고 있더라도, 상시적으로 IP가 Pod에 할당될 수 있도록 합니다.

K8S Service

Pod는 각각의 IP를 할당받습니다. 이때, Pod가 제거되거나, 다른 곳으로 이동하는 경우 언제든 IP가 바뀔 수 있습니다.

• 서버측에서도 당연히 문제가 되겠지만, 클라이언트 입장에서도 접근이 되지 않습니다.

Service는 특정 Pod를 그룹으로 묶어서 LoadBalancer 처럼 대표 IP를 만드는 역할을 합니다.
즉, 클라이언트는 Service를 통해서 Pod가 죽든 말든 정상적으로 접근이 가능합니다.

• Cluster IP
  : 예를 들어, Server to Server 경우 외부 통신이 필요없는 경우가 대표적 사례입니다.
  Cluster IP를 사용하는 경우 Cluster 내부에서만 통신이 가능하게 됩니다.

• Node Port
  : 외부와 통신이 필요한 경우 Port를 오픈해야하는 경우에 EC2에 Port를 오픈하는 방식으로 사용됩니다.

• LoadBalancer
  : 단어 그대로 LoadBalancer를 사용하여 여러 노드에 접근이 가능하도록 합니다.

Service는 LoadBalancer처럼 동작한다고 언급했었습니다.
그렇다면, LoadBalancer를 만들지 않았는데 어떻게 비슷한 동작이 가능한 것일까요?

• 정답은 iptables에 있습니다.

Service의 iptables - 매우 중요❗

• Cluster IP

Cluster IP의 경우 172.16.1.11로 현재 설정되어 있습니다. 이는 가상 IP이며, 실제로 VPC등에서 존재하지 않는 IP입니다.

Cluster IP의 iptables 네트워킹 동작 순서

1. 172.16.20.10과 같은 외부 트래픽이 Cluster IP 내부로 들어오면, 서버 내부의 iptables를 확인합니다.
2. iptables는 가장 먼저, PREROUTING chain을 거치게 됩니다.
   target에 대한 정보 확인 시, 모든 트래픽의 소스 및 목적지에 대해서 PREROUTING을 거치도록 설정되어 있습니다.
   

3. 다음 chain인 Service(KUBE-SERVICES)를 확인하니, "172.20.253.88" IP가 목적지로 설정되어 있습니다.
   ❗해당 IP는 Service의 대표 IP입니다. 그렇기에, 내가 설정한 Service에 대해서 특정하여 접근하도록 하는 것이 가능한 것입니다.
   

4. Service chain을 타고 들어가니, 3개의 규칙이 또 발견됩니다.
   이는 Pod의 IP로 설정해둔 Replica에 따라 규칙이 늘거나 줄어듭니다.
   ❗중요한 점은 probability로 표시된 규칙 항목이며, 해당 규칙은 위에서 아래로 순차적으로 흐릅니다.
   3개의 규칙은 0.33333, 0.5, *로 설정되어 있으며, 이는 트래픽이 타고 들어갈 수 있는 확률을 의미합니다.

• 맨 처음 규칙으로 가장 위의 규칙이 걸리지만, 0.33333의 확률을 통해 해당 chain으로 접근되게 됩니다.
• 맨 처음 규칙의 chain이 확률적으로 걸리지 않았다면, 두 번째, 규칙은 0.5의 확률로 다시 chain 접근을 시도합니다.
• 두 번째 규칙까지 접근이 되지 않았다면, 마지막 규칙에서 반드시 chain 접근이 발생됩니다.
  

5. 위의 probability 확률을 통해서 하나의 Pod로 접근이 되었다면, 아래와 같이 DNAT라는 규칙을 확인 가능합니다.
   ❗DNAT는 Destination NAT이며, "패킷의 목적지 주소를 바꿔라"라는 뜻을 가지고 있습니다.
   즉, 원래는 노드로 목적지가 되어 있었는데, tcp to:10.11.0.207:80과 같이 Pod IP로 목적지를 바꿔서 트래픽이 전달되게 합니다.
   

--> 해당 과정들을 통해 Service만으로도, LoadBalancer의 트래픽 분산 효과를 누릴 수 있는 것입니다.

probabilitt 확률은 Pod의 개수에 비례하여 줄어듭니다.
예) Pod가 2개일 경우 0.5와 * 으로 표시됨

위의 일련의 과정들이 정리된 구조이니 참고하시기 바랍니다.

NodePort의 iptables 네트워킹 동작 순서

• NodePort의 경우 위에서 설명된 Cluster IP와 동작이 똑같습니다.
  다만, NodePort의 특성이 가미되어 Port를 통해 접근된 트래픽이 iptables를 통해 특정 Pod로 접근 동작한다고 생각하시면 됩니다.
• 아래 그림을 예로 들면, 8080 port로 접근 시, 30080 NodePort를 가진 node로 접근하게 되는 것입니다.

참고 - NodePort의 Port Range = 30000~ 32767

❗중요한 사항이 있는데, 사용자가 아래 그림과 같이 가장 위의 node에 트래픽을 보낼 때, 사용자가 원하는 파드가 없을 수 있습니다. (예: 사용자가 원하는 파드는 IP = 172.16.10.12)
이때, 신기하게도 트래픽은 사용자가 원하는 파드로 트래픽을 보낼 수 있게 되는데, 이는 iptables에 규칙이 명시되어 있어 가능한 것입니다.

kubernetes에서 해당 역할을 하는 것은?

• kube-proxy입니다. kube-proxy는 Service의 정보가 바뀌면, 노티를 받아 일괄로 iptables의 rule을 수정하게 됩니다.

LoadBalancer의 iptables 네트워킹 동작 순서

• Service type을 NodePort로 하는 경우, 클라이언트가 각각의 서버 IP를 다 알아야하는 상황이 발생하는데, 너무 비효율적입니다.
  LoadBalancer는 이를 개선하기 위한 방식입니다.

Service는 IP와 Port를 통해 주로 L4 Layer 트래픽을 송수신합니다.
그렇다면, K8S에서 L7 Layer를 담당하는 오브젝트는 무엇일까요?

• Ingress 이며, 호스트명, 경로(Path)기반 라우팅을 처리합니다.

Ingress

Ingress는 L7 Layer영역의 호스트명, Path기반 등의 관리자 정의 규칙을 기반으로 서비스를 공개할 때, 사용됩니다.

예: foo.example.com → A 서비스, bar.example.com → B 서비스, /api/* → C 서비스 등
TLS 종료나 리다이렉션, 인증, 레이트 리밋 같은 Application Level의 정책이 적용 가능합니다.

EKS NLB Provisioning - annotations

실제 Load Balancer type을 사용하는 경우, CLB가 기본적으로 생성됩니다.
CLB는 권장되지 않으며, NLB or ALB를 사용하는 것이 좋습니다.

이를 설정할 수 있는 것이 바로 annotations 입니다.
annotations에 관심이 있는 특정 컴포넌트가 참조해서 사용하는 방식입니다.

예) AWS에서 사용되는 정보들을 K8S Spec에 넣어야하는 경우가 있습니다.
이때, AWS의 기능들이 추가/수정될 때마다, K8S Spec을 수정해야할 것이며, 비효율적이라고 할 수 있습니다.

❗그래서, 아래 이미지와 같이 annotations와 spec 항목을 분리하여서, AWS와 K8S에서 필요한 항목들을 따로 관리할 수 있도록 하는 역할을 합니다.

아래 annotations를 살펴보면 위와 다른 항목이 하나 있는데, "nlb-target-type: "instance""라는 타겟 타입을 정할 수 있는 옵션이 있습니다.

• 타겟 타입에는 Instance, IP가 있으며, IP 타입의 경우 AWS LB Controller Add-on을 따로 설치가 필요합니다.

Target Type - Instance

Instance 타입의 경우 이전에 설명했던 통신 방식과 동일하게, iptables를 활용하여 NodePort를 통해서 Pod로 접근하게 됩니다.

Target Type - IP

IP 타입의 경우 Port가 필요없이 Pod의 IP로 다이렉트 통신이 가능해집니다.
❗iptables를 활용하지 않는 방식이기에, 복잡성이 줄어듭니다.

• 해당 방식이 가능한 이유는 LB에서 IP 타입을 지원하기 때문입니다.

EKS ALB Provisioning - Ingress

Manifest 파일을 살펴보면, /* Path로 접근 시, Backend의 echoserver-svc로 보내라는 설정이 담겨 있습니다.

• 아래 아키텍처와 같이 Ingress도 AWS LB Controller가 필요합니다.
  하나 참고하시면 좋은 옵션은 group.name입니다.
  Ingress 파일 하나에 모든 Path를 넣는 것이 아닌, 각 Path별로 Ingress를 생성하되, group.name만 각 파일내에 동일하게 설정해두면, 같은 LB를 바라보도록 설정이 가능합니다.