Kubernetes Network

Overview

Kubernetes Network 트래픽 흐름에 대해서 알아본다.

출처 : https://opensource.com/article/22/6/kubernetes-networking-fundamentals

 

 

 

---

 

Kubernetes Network

Kubernetes 클러스터의 트래픽 흐름은 CSP(클라우드 서비스 제공업체) 환경과 온프레미스(On-premise) 환경은 차이점이 있다. 각 환경에서의 트래픽 흐름을 설명하려고 한다.

 

---

 

 

CSP 환경에서의 트래픽 흐름

1. 외부 Load Balancer: 클라우드 제공업체는 외부 트래픽을 클러스터 내로 라우팅하기 위한 Load Balancer를 제공한다. 이는 클러스터 밖에 위치하며, 외부에서 들어오는 요청을 서비스나 인그레스 컨트롤러에 전달한다.
2. Ingress Controller/Service: Ingress Controller는 HTTP/HTTPS 트래픽을 처리하고, `type: LoadBalancer`인 서비스는 그 외의 프로토콜을 처리한다. 이들은 클라우드 Load Balancer로부터 트래픽을 받아 적절한 Pod으로 라우팅한다.
3. Pods: Pod은 애플리케이션의 컨테이너를 실행하는 최소 단위이다. Service 또는 Ingress를 통해 트래픽이 이들에게 전달된다.

 

 

온프레미스 환경에서의 트래픽 흐름

1. 외부 Load Balancer/Router: 온프레미스 환경에서는 자체적으로 구성된 Load Balancer 또는 라우터가 외부 트래픽을 클러스터 내로 라우팅한다. 이는 온프레미스 데이터 센터 내에 위치한다.
2. Ingress Controller/Service: 이 단계는 CSP 환경과 유사하다. Ingress Controller는 HTTP/HTTPS 트래픽을 처리하고, `type: LoadBalancer`인 서비스는 그 외의 프로토콜을 처리한다. 이들은 외부 Load Balancer/Router로부터 트래픽을 받아 적절한 Pod으로 라우팅한다.
3. Pods: 온프레미스 환경에서도 Pod은 애플리케이션의 컨테이너를 실행하는 최소 단위로 동일하다.

 

---

 

 

CSP 환경에서의 인그레스 컨트롤러

CSP 환경에서 인그레스 컨트롤러는 종종 클라우드 제공 업체의 로드 밸런서 서비스와 통합된다.

 

인그레스 컨트롤러 서비스 유형이 LoadBalancer로 설정되면, 클라우드 제공 업체는 자동으로 외부 IP 주소(일반적으로 공용 IP)를 할당하고, 이 IP는 클라우드 로드 밸런서의 IP 주소가 된다.

 

이렇게 할당된 IP 주소를 통해 외부 트래픽은 클라우드 로드 밸런서를 거쳐 인그레스 컨트롤러로 라우팅되고, 최종적으로 적절한 파드로 전달된다.

​

 

 

CSP (Cloud Service Provider) 환경에서의 인그레스 컨트롤러와 로드 밸런서 컨트롤러의 관계를 설명한다.

 

1. 인그레스 컨트롤러 (Ingress Controller)
   • 인그레스 컨트롤러는 쿠버네티스 클러스터 내에서 실행되는 소프트웨어이다. 인그레스 리소스를 관찰하고, 이 리소스에 정의된 라우팅 규칙을 구현한다.
   • 인그레스 컨트롤러는 트래픽을 적절한 서비스와 파드로 전달하는 역할을 한다.
2. 로드 밸런서 컨트롤러 (Load Balancer Controller)
   • 클라우드 환경에서 로드 밸런서 컨트롤러는 보통 클라우드 제공 업체가 관리하는 별도의 서비스이다.
   • 이 서비스는 외부 트래픽을 쿠버네티스 클러스터로 라우팅하는 역할을 한다.
3. 통합 작업:
   • 쿠버네티스 서비스가 LoadBalancer 유형으로 생성될 때 (예: 인그레스 컨트롤러를 위해), 클라우드 제공 업체는 자동으로 외부 IP 주소를 할당하고 로드 밸런서를 구성한다.
   • 이 로드 밸런서는 외부 트래픽을 받아 인그레스 컨트롤러로 전달한다. 인그레스 컨트롤러는 그 후 쿠버네티스 내의 적절한 서비스나 파드로 트래픽을 라우팅한다.
4. CSP 환경의 특징:
   • CSP 환경에서는 일반적으로 인그레스 컨트롤러와 로드 밸런서가 긴밀하게 통합되어 있으며, 사용자는 로드 밸런서를 별도로 관리할 필요가 없다.
   • 대신, 쿠버네티스 서비스를 구성하고 인그레스 리소스를 정의함으로써, 자동으로 클라우드 제공 업체의 로드 밸런싱 기능을 활용할 수 있다.

 

결론적으로, CSP에서의 인그레스 컨트롤러는 클라우드 제공 업체의 로드 밸런서와 긴밀하게 통합되어 있으며, 이를 통해 외부 트래픽을 클러스터 내의 적절한 서비스나 파드로 효율적으로 라우팅할 수 있다.

 

 

온프레미스 환경에서의 인그레스 컨트롤러

온프레미스 환경에서는 LoadBalancer 유형의 서비스가 자동으로 외부 IP를 할당받지 않는다.

대신, 일반적으로 온프레미스 네트워크에서 관리하는 외부 로드 밸런서 또는 라우터를 사용해야 한다.

이 경우, 외부 로드 밸런서 또는 라우터에 수동으로 IP 주소를 설정하고, 해당 IP를 인그레스 컨트롤러 또는 서비스로 트래픽을 라우팅하도록 구성한다.

 

온프레미스 환경에서는 NodePort 또는 ClusterIP 서비스 유형을 사용하여 인그레스 컨트롤러에 접근할 수 있으며, 외부 로드 밸런서가 이 서비스 유형에 맞게 트래픽을 라우팅한다.

따라서, 온프레미스 서버에서 인그레스 컨트롤러가 외부 IP(로드 밸런서 IP)를 가지고 있는 경우, 이는 보통 네트워크 구성 또는 수동 설정의 결과다. CSP 환경과 달리, 온프레미스 환경에서는 자동 IP 할당이 일반적이지 않다.

​

 

---

 

 

MetalLB(Onpremise LoadBalancer)

MetalLB는 온프레미스 쿠버네티스 클러스터에서 LoadBalancer 서비스 유형을 지원하도록 설계된 솔루션이다. 일반적으로 클라우드 환경에서 제공되는 로드 밸런서 기능을 온프레미스 환경에서 사용할 수 있게 해준다.

 

MetalLB 설정에서 IP 주소 풀을 지정하면, MetalLB는 이 풀에서 IP 주소를 동적으로 할당하여 쿠버네티스의LoadBalancer 유형 서비스에 IP 주소를 제공한다. 이렇게 할당된 IP 주소는 외부에서 쿠버네티스 클러스터로의 접근 지점으로 사용한다.

​

 

 

예를 들어, MetalLB 설정에서 다음과 같이 IP 주소 범위를 지정할 수 있다.

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

• MetalLB는 192.168.1.240에서 192.168.1.250 사이의 IP 주소를 LoadBalancer 서비스에 할당할 수 있다.
• 인그레스 컨트롤러를 LoadBalancer 서비스로 배포하면 MetalLB가 이 IP 풀에서 IP 주소를 자동으로 할당하여 인그레스 컨트롤러에 제공한다. 이 IP 주소는 외부에서 인그레스 컨트롤러로 트래픽을 라우팅하는 데 사용된다.
• 결론적으로, MetalLB를 사용하면 온프레미스 환경에서도 클라우드와 유사한 방식으로 LoadBalancer 서비스를 사용할 수 있게 되어, 인그레스 컨트롤러에 자동으로 IP 주소를 할당받을 수 있다.

 

---

 

Component간 Kubernetes Network

Kubernetes 네트워킹은 Kubernetes 내의 다양한 엔터티 유형이 통신할 수 있도록 설계되었다.

• Container-to-container networking
• Pod-to-Pod networking
• Pod-to-Service networking
• Internet-to-Service networking

 

---

 

Container-to-container networking

단일 Pod 내에서 Kubernetes를 사용하면 여러 컨테이너가 동일한 네트워크 네임스페이스를 공유할 수 있다. 이는 동일한 Pod 내의 컨테이너가 동일한 IP 주소와 포트 공간을 공유하므로 localhost를 사용하여 서로 통신할 수 있음을 의미한다.

이러한 Pod 내 통신은 긴밀하게 함께 작동해야 하는 컨테이너(예: 기본 애플리케이션 컨테이너 및 기본 애플리케이션을 기록하거나 모니터링하는 사이드카 컨테이너)에 매우 중요하다.

 

 

Pod-to-Pod networking

Kubernetes를 사용하면 모든 노드에 파드용으로 지정된 CIDR IP 범위가 있다. 이렇게 하면 모든 파드가 클러스터의 다른 파드에서 볼 수 있는 고유한 IP 주소를 수신하게 된다.

Kubernetes는 NAT(Network Address Translation) 없이 파드가 노드 간에 서로 통신할 수 있도록 보장한다. 각 파드는 고유한 IP 주소를 가져오므로 모든 파드가 어떤 노드에 있는지에 관계없이 이 IP 주소를 사용하여 클러스터의 다른 파드와 통신할 수 있다.

이는 CNI(컨테이너 네트워크 인터페이스) 표준을 구현하는 기본 네트워크 플러그인을 통해 달성되며, 다양한 구현(예: Calico, Flannel 또는 Cilium)은 이 노드 간 파드 간 통신을 활성화하는 다양한 방법을 제공한다.

 

 

Pod-to-Service networking

쿠버네티스에서 서비스(Service)는 파드(Pod)들에 대한 안정적인 인터페이스를 제공한다. 서비스는 특정 파드의 집합에 대한 요청을 중재하고, 트래픽을 적절한 파드로 라우팅하는 역할을 합니다. 각 서비스는 ClusterIP라고 불리는 고유한 IP 주소를 가지며, 이 주소는 서비스를 안정적으로 유지한다.

1. 파드(Pod): 각 파드는 쿠버네티스 클러스터 내에서 실행되는 애플리케이션의 인스턴스이다. 파드는 자체 IP 주소를 가지고 있으며, 다른 파드와 통신할 수 있다.
2. 가상 브릿지(Virtual Bridge): 파드 내의 eth0과 veth 페어를 통해 연결된다. 이 브릿지는 파드가 노드의 네트워크와 통신할 수 있도록 하는 중간 통신 역할을 한다.
3. 노드(Node): 클러스터의 물리적 또는 가상의 머신이다. 각 노드는 여러 파드를 호스팅하며, kube-proxy를 통해 네트워크 트래픽을 관리한다.
4. kube-proxy: 노드 내에서 실행되며, iptables 또는 IPVS를 사용하여 트래픽을 서비스의 ClusterIP로 라우팅하고, 서비스의 파드 선택 알고리즘(예: 라운드 로빈)에 따라 트래픽을 적절한 파드에게 전달한다.
5. 서비스(Service): 파드의 논리적 집합을 대표하고, 클라이언트가 파드의 개별 IP를 알 필요 없이 일관된 방법으로 파드에 접근할 수 있게 한다. ClusterIP를 사용해 클러스터 내부에서 파드에 접근할 수 있으며, 필요에 따라 외부로 노출될 수도 있다 (예: NodePort, LoadBalancer).
6. 클러스터 네트워크(Cluster Network): 클러스터 전체에서 통신을 가능하게 하는 네트워크이다. 노드 간 통신 및 파드 간 통신이 이 네트워크를 통해 이루어진다.

 

 

Internet-to-Service networking

두 가지 방법으로 외부 네트워크에 애플리케이션을 노출할 수 있다.

1. Egress: Kubernetes Service에서 인터넷으로 트래픽을 라우팅하려는 경우 이를 사용한다. 이 경우 iptables는 소스 NAT를 수행하므로 트래픽이 Pod가 아닌 노드에서 나오는 것처럼 보인다.
2. Ingress: 외부 세계에서 서비스로 들어오는 트래픽이다. Ingress는 또한 연결 규칙을 사용하여 서비스와의 특정 통신을 허용하고 차단한다. 일반적으로 서로 다른 네트워크 스택 지역에서 작동하는 두 가지 ingress 솔루션, 즉 서비스 Load Balacner와 Ingress Controller가 있다.

 

 

 

---

Reference

https://opensource.com/article/22/6/kubernetes-networking-fundamentals

https://learn.microsoft.com/ko-kr/azure/virtual-network/kubernetes-network-policies

https://www.researchgate.net/figure/Kubernetes-Network-routing-to-export-the-services_fig1_337362475

https://serverfault.com/questions/1078161/kubernetes-setup-with-different-networks-for-intra-and-inter-cluster-communicati

https://kubernetes.io/ko/docs/concepts/cluster-administration/networking/