[Kubernetes] 쿠버네티스 네트워크 개요(CNI, Pod-to-Pod, Service, Ingress)

이번 글은 쿠버네티스의 네트워크에 관해 설명한다.

• CNI, Pod-to-Pod, Service, Ingress

 

 

CNI

CNI는 컨테이너 네트워크 인터페이스의 약자로, 쿠버네티스 안에서 컨테이너들의 네트워크를 설정하기 위한 인터페이스다.

쿠버네티스는 Pod 안의 컨테이너들의 네트워크를 '직접' 설정하지 않는다. Pod는 각자 IP와 볼륨을 필요로 한다는 규칙만 언급할 뿐 구현은 외부 플러그인에 맡기고 있다.

다양한 네트워크 플러그인이 존재하며, 서버와 클러스터의 상황에 따라 적절한 외부 플러그인을 선택할 수 있다.

 

💡 쿠버네티스 네트워크 모델

클러스터의 모든 파드는 고유한 IP 주소를 갖는다. 이는 즉 파드간 연결을 명시적으로 만들 필요가 없으며 또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 이로 인해 포트 할당, 네이밍, 서비스 디스커버리, 로드 밸런싱, 애플리케이션 구성, 마이그레이션 관점에서 파드를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.

파드를 추상화하여 물리 호스트로 다룰 수 있는 네트워크 모델을 만드는 것이 쿠버네티스 네트워크 모델의 핵심이다.

 

쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다. (이를 통해, 의도적인 네트워크 분할 정책을 방지)

• 파드는 NAT 없이 노드 상의 모든 파드와 통신할 수 있다.
• 노드 상의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든 파드와 통신할 수 있다.
• 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다.
• 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
• 서비스 API를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근 할 수 있다.
• 인그레스는 특히 HTTP 애플리케이션, 웹사이트 그리고 API를 노출하기 위한 추가 기능을 제공한다.
• 또한 서비스를 사용하여 서비스를 클러스터 내부에서만 사용할 수 있도록 게시할 수 있다.

많은 요구사항이 있지만 결국 이것은 외부 플러그인으로 하여금 쿠버네티스가 구현해주길 원하는 요구사항이다. 

가장 중요한 건 쿠버네티스는 네트워크에 대한 규칙만 줄 뿐, 세부적인 구현사항은 외부 플러그인마다 다르다.

 

쿠버네티스가 제공하는 모든 클러스터와 노드들은 구축돼있는 네트워크 리소스들을 이용해 통신한다.

 

[출처]

https://kubernetes.io/ko/docs/concepts/services-networking/#%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EB%AA%A8%EB%8D%B8

서비스, 로드밸런싱, 네트워킹

 

 

Pod-to-Pod Communication

그럼 노드안의 Pod들은 서로 어떻게 통신하는 것일까? 

쿠버네티스는 Pod들이 서로 통신할 수 있도록 가상의 리소스를 할당한다. 리소스를 할당할 때 가상의 스위치와 서브넷, 프라이빗 네트워크를 설정한다. 자세히 알아보자.

 

쿠버네티스 Pod 통신 도식 (출처 : https://coffeewhale.com/k8s/network/2019/04/19/k8s-network-01/)

 

📍 기본 통신 구조 - IP

두 Pod가 서로 통신하려면 외부 플러그인을 통해 발급받은 IP가 필요하다. (같은 Pod 안의 컨테이너들은 같은 IP를 사용한다.)

같은 IP를 사용하기 때문에 포트를 컨테이너 하나와 매핑시킬 수 있지만, 이건 쿠버네티스에선 추천하지 않는 방법이다. 

 

API를 만들어 각 API 당 컨테이너 하나씩 할당하는게 쿠버네티스에서 권장하는 네트워크 설정 방법이다. 

이것이 바로 Service와 Ingress라는 추상화 레이어를 사용해 DNS 수준에서 통신하는 방식이다. (나중에 설명한다)

 

 

 

💡 기본 네트워크 구조

쿠버네티스 기본 네트워크 구조

 

쿠버네티스는 실질적인 네트워크 장치를 가지고 있지 않다. 네트워크에 필요한 요소들을 리소스로 구현한다.

대표적인 네트워크 리소스는 다음과 같다.

• 컨테이너, 가상 이더넷, 브릿지, 이더넷 (네트워크 인터페이스), 라우터
• 본 그림에서는 라우터는 존재하지 않는다.

두 컴퓨터가 서로 통신하기 위해 랜선을 스위치에 연결하는 것을 쿠버네티스는 위의 리소스로 추상화한다. 

각 리소스가 어떤 역할을 하는지 간단하게 알아보자.

 

가상 이더넷과 브릿지는 홈 네트워크의 기기와 공유기를 생각하면 된다.

 

1️⃣ 가상 이더넷

가상 이더넷은 컨테이너에 부여하는 가상의 네트워크 인터페이스다. 여러 컨테이너에 공통으로 부여할 수 있다. 

가상 이더넷은 파드 간의 통신을 위해 나온 개념이다. 네임스페이스와 같이 노드 별로, 파드 별로 묶이는 개념은 아니다. 원하는 리소스끼리 묶어 가상 이더넷을 설정할 수 있다.

(처음엔 파드 안의 컨테이너끼리의 통신을 위한 리소스인 줄 알았지만 컨테이너들은 루프백이라고 하는 다른 방법을 이용해 통신한다.)

노드 외부로 부터 오는 통신을 노드 안의 적절한 파드로 전송하기 위해 파드들에 붙이는 네트워크 인터페이스라 보면 된다. 

 

 

2️⃣ 브릿지 

브릿지는 일종의 스위치다. 우리가 스위치에 여러 랜선을 꽂아서 서로 다른 컴퓨터들의 통신을 연결하듯이, 파드들이 가지고 있는 가상 이더넷을 브릿지에 꽂아 노드 내 파드들의 통신 관장하고, 노드 외부에서 온 통신을 적절한 파드로 연결하는 역할을 한다.

브릿지는 노드 안의 '내부 통신 스위치'인 셈이다.

 

 

3️⃣ 이더넷

노드 개념의 네트워크 인터페이스다. 외부에서 노드를 확인하게끔 해주는 네트워크 식별자이다.

가상 이더넷은 노드 내부의 개념, 이더넷은 노드 외부의 개념이라 보면 된다. 외부에서 노드로 전달된 패킷이 라우터를 지나면, 라우터는 자신이 가지고 있는 테이블을 통해 적절한 노드로 전송한다. 이때 사용하는 것이 이더넷이다.

네트워크로 비유하면 노드가 가지고 있는 IP 주소, 네트워크 인터페이스이다.

 

 

4️⃣ 라우터

라우터는 네트워크의 L4 스위치와 같다. 외부에서 온 패킷의 목적지를 확인한 후 적절한 노드로 보내주는 역할을 한다.

 

 

🔑 전송 과정

전송과정을 정리하면 다음과 같다.

 

1. 노드 밖에서 패킷이 전송될 때 : 라우터 -> 이더넷(노드) -> 브릿지(노드 내부 스위치) -> 가상 이더넷(파드)
2. 노드 안에서 패킷이 전송될 때(노드 내부 통신) : 가상 이더넷(파드) -> 브릿지(노드 내부 스위치) -> 가상 이더넷(파드)

 

 

Service & Ingress

Service와 Ingress는 쿠버네티스 네트워크의 거시적인 부분을 담당하는 리소스이다. 두 리소스 모두 하나의 포스팅을 차지하는 거대한 주제지만 대략적인 것만 설명하려고 한다.

 

Service와 Ingress 구조

 

 

1️⃣ Service

파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법이다.

쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고, 그것들 간에 로드-밸런스를 수행할 수 있다.

 

📍  왜 필요한가?

클러스터 상에 프론트엔드 파드와 백엔드 파드가 구현되어있고 서로 정보를 주고받는다고 가정해보자. 파드는 비영구적 리소스이기 때문에 클러스터의 상황에 따라 가동되는 파드가 중지될 수 있고, 삭제될 수 있다. 

만약 백엔드 파드가 사라진다면 프론트엔드 파드 입장에선 자신이 필요한 백엔드 파드를 스스로 찾을 수 없게 된다.

 

이럴 때를 대비해 비슷한 조건의 파드들을 하나의 Cluster IP라고 하는, 고정적인 IP로 묶어 파드의 상태가 변경되어도 다른 파드들이 해당 서비스를 계속 이용할 수 있게 도와주는 리소스가 Service이다.

위의 이야기를 계속한다면 같은 백엔드 서비스를 제공하는 여러 개의 파드들을 Cluster IP로 묶어 고정시킨다면, 각각의 파드가 사라진다고 하더라도 다른 파드들은 같은 IP로 똑같은 백엔드 서비스를 이용할 수 있게 된다.

 

 

2️⃣ Ingress

쿠버네티스 공식 문서를 보자.

URI, 호스트네임, 경로 등과 같은 웹 개념을 이해하는 프로토콜-인지형(protocol-aware configuration) 설정 메커니즘을 이용하여 HTTP (혹은 HTTPS) 네트워크 서비스를 사용 가능하게 한다. 인그레스 개념은 쿠버네티스 API를 통해 정의한 규칙에 기반하여 트래픽을 다른 백엔드에 매핑할 수 있게 해준다.

 

클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리한다.

Service 보다 한 단계 더 위에 있는 네트워크 리소스이다.

 

📍  왜 필요한가?

만약 쿠버네티스 클러스터를 통해 제공하려는 서비스의 개수가 100개라고 해보자. 만약, Service만 존재한다면 각각의 서비스에 대한 Cluster IP를 구축해야 하므로 총 100개의 IP 주소가 필요하게 된다. 만약 Ingress 없이 약 100개의 서비스를 외부로 노출하려면, 클라우드 업체(AWS 등)로부터 약 100개의 로드밸런서를 빌려야 하고 그러면 엄청난 비용이 나온다.

 

Ingress는 바로 이때 필요하다. Ingress는 외부에서 들어오는 HTTP/HTTPS 요청을 도메인이나 경로(Path)에 따라 적절한 Service로 전달해주는 리소스이다. L7의 로드 밸런서인 셈이다.

 

사용자의 입장에서는 외부에 Ingress의 네트워크 주소만 보고 전송하면 된다. 직접 서비스의 각기 다른 IP를 기억할 필요가 없는 것이다. Nginx의 proxy 기능을 생각하면 된다. 그리고 Ingress도 추상화된 리소스일 뿐, 실제 작업은 Ingress Controller하며 Nginx 등이 그 역할을 수행한다.

 

나중에 Service, Ingress 단독으로 쿠버네티스 네트워크에 대해 조사해야겠다.

 

 

https://danawalab.github.io/kubernetes/2020/01/23/kubernetes-service-ingress.html

Kubernetes 서비스와 인그레스 용도구분

https://kubernetes.io/ko/docs/concepts/services-networking/service/

서비스

https://kubernetes.io/ko/docs/concepts/services-networking/ingress/

인그레스(Ingress)