쿠버네티스의 Network Solution에 대하여

 

쿠버네티스는 컨테이너 애플리케이션을 제어할 수 있는 컨테이너 오케스트레이션 프로그램 중 하나이다. 현재 컨테이너 오케스트레이션 도구 중에서 독보적인 위치를 지니고 있으며, MSA를 사용하는 기업들은 거의 다 쿠버네티스를 사용하고 있다.

 

쿠버네티스는 각 컨테이너를 다루는 도구이므로, 당연히 그와 관련된 네트워크 설정들이 있을 것이다. 쿠버네티스에서 기본적으로 제공하는 네트워크에 대해서 간단히 알아보자.

 

쿠버네티스의 기본 네트워크

---

쿠버네티스의 구조에 대해서 간단히 알아보자. 쿠버네티스의 가장 작은 단위는 파드이다. 한 개의 도커 컨테이너라고 보면 된다. 파드들을 관리하는 상위 단위는 노드이다. 노드는 한 대의 pc라고 생각하면 된다. 이러한 노드들을 관리하는 것이 쿠버네티스 클러스터이다. 그림으로 보면 다음과 같다.

육각형으로 되어있는 것이 노드이고, 원으로 둘러싸인 것이 파드라고 보면 된다. 대부분 한 개의 노드가 하나의 애플리케이션 단위라고 생각하면 된다. 트래픽이 늘어나게 되면 노드 안의 파드들의 숫자가 늘어나면서 트래픽을 병렬로 처리하는 예시가 있을 수 있다.

 

여하튼, 쿠버네티스는 자체적인 네트워크가 있긴 하다. 바로 service 네트워크, ingress 네트워크, networkPolicy 등의 기본적으로 제공되는 도구들이 있다. 하지만 이러한 도구들은 파드 또는 컨테이너가 업데이트 될 때 네트워크 구성을 수동으로 변경해야 하고, 네트워크 구성을 변경할 때 모든 컨테이너를 수동으로 업데이트해야 하는 번거로움이 있다. 이를 해결하기 위해서 쿠버네티스에서는 CNI (Container Network Interface) 라는 표준 인터페이스를 제공한다. CNI를 사용해서 보다 수월하게 네트워크 관리(보안, 격리, 트래킹 등등)를 할 수 있다.

 

Service Mash

---

CNI보다는 비슷한 솔루션을 먼저 정리해 보겠다. 직관적으로 생각했을 때 각 파드의 트래픽을 모니터링 하기 위해서는 각 파드에 트래킹하는 무언가를 설치해야 한다. 쿠버네티스에서는 이를 위해서 사이드카 패턴을 사용한다. 간단히 말하면, 하나의 파드 안에 메인 컨테이너를 제외한 1개 이상의 프록시(모니터링) 기능을 하는 컨테이너를 하나 더 추가해서 사용하는 것이다. 이는 yaml파일에서 근거를 찾아볼 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

파드를 만드는 예시 yaml 파일이다. containers 항목이 배열로 이루어진 것을 알 수 있다. 즉 하나의 파드에 여러개의 컨테이너가 있을 수 있다는 것이다. 

 

여하튼 이러한 사이드카 패턴을 사용해서 각 파드의 네트워크 관리나 리소스 모니터링 등의 작업을 할 수 있다는 것이다. 이를 통해서 서비스 계층에서 트래픽 제어를 수행해서 자유도가 높아지는 장점이 있다. 하지만 파드의 리소스를 차지하므로 어플리케이션의 성능이 낮아질 수 있다. 하지만 단점보다는 장점이 더 많기에 이러한 패턴을 사용하고, 이에 대한 전반적인 구조를 서비스 매쉬라고 부른다.

 

이러한 서비스 매쉬의 예시 중 하나로 istio가 있다. istio는 사이드카 패턴으로 프록시를 설치하고, istio controlplane에서 트래픽을 제어할 수 있게 한다. istio는 두 가지의 통신 방법이 있다. data plane과 control plane이다.

data plane : 서비스 간의 통신이다. 

control plane : 프록시 서버를 동적으로 프로그래밍해 규칙이나 환경이 변경되면 업데이트한다.

 

CNI

---

CNI를 말하기 전에 BPF에 대해서 먼저 알아봐야 할 것 같다. BPF는 Berkeley Packet Filter의 약자인데, 리눅스 커널 단위에서 실행되는 가상 머신이며 주로 패킷 모니터링에 대해 사용되었다. 여기서 eBPF라는 확장된 개념이 나오는데, 기존의 BPF에서 확장 기능이 추가되었다고 생각하면 된다. process에서 systemCall이 scheduler에 가기 저넹 eBPF가 중간에 가로채는(?) 방식으로 작동이 된다. BPF는 오래 전에 나온 개념이고 요즘에는 컨테이너 기술이 활성화되면서 eBPF로 이전한 추세인 것 같다. 

CNI와 Service Mesh의 차이점을 알아보자. 만약 Service Mesh 네트워킹을 사용하면 다음과 같은 노드의 모양이 나올 것이다.

각 파드에 사이드카가 달려 있는 형태가 나오게 된다. 하지만 여기서 cilium을 사용하게 되면 다음과 같이 사용할 수 있다.

해당 아키텍쳐는 사이드카 없이 네트워크 트래킹이 가능하다! 사이드카리스 프록시 모델이라고 하며, 이렇게 사용하면 사이드카 패턴에 비해서 각 파드에서 사용 가능한 리소스가 더 많아지게 된다. 요거는 eBPF 패턴을 사용했다.

 

여하튼 각 서비스마다 장단점이 있고, 네트워크를 관리하기 위한 훌륭한 도구임에는 틀림없다. cilium과 istio를 둘 다 활용한 방법도 있어 보였다. 이러한 네트워크 솔루션을 사용하여 grafana 또는 kibana 같은 모니터링 툴을 활용하여 클러스터의 상태를 확인하게 할 수도 있다. 여하튼 각자 상황에 맞는 네트워크 서비스가 있으니 적당히 맞는 솔루션을 활용하여 사용하면 될 것 같다.

 

만약 특정 파드에서 다른 파드로의 네트워크 연결을 확인하기 위해서는 하드의 /etc/hosts 를 확인하거나 kubectl get service <podName> -o yaml 명령어를 통해서 서비스명을 확인한 후 curl 또는 telnet을 날려서 확인한다.

 

참고자료

---

https://thenewstack.io/how-ebpf-streamlines-the-service-mesh/

How eBPF Streamlines the Service Mesh

https://docs.cilium.io/en/stable/network/istio/

Getting Started Using Istio — Cilium 1.13.1 documentation