[k8s] 네트워크 구성요소

#Kubernetes

아마 k8s의 구성이나 응용에서 뭔가 문제가 생긴다면, 꽤 높은 확률로 범인은 네트워크일 것이다.
네트워크에 대한 문제는 워낙 변수가 많고 계층도 복잡해서 충분한 이해도 없이는 문제를 추적하기 어렵다.

여기서는 k8s에서 네트워크 스택들이 어떤 식으로 쌓여있는지, 어떤 컴포넌트들이 있는지를 나열한다.

기본 계층 구조

쿠버네티스는 모든 리소스를 여러개의 노드에 랜덤하게 분산될 수 있으며, 실제 서버는 Pod라는 가상 컨테이너 단위를 통해 실행된다. 하나의 Pod에는 여러개의 컨테이너가 공존할 수 있다.
그리고 이 Pod를 다른 서비스에서 연결하거나 외부로 개방하는 역할은 Service가 담당한다.

이게 가장 기본적인 구조다.

동일 Pod - 컨테이너 간의 통신

상기했듯이, 하나의 Pod에는 여러개의 컨테이너가 실행될 수 있다. 이를 통해 Sidecar 패턴 등을 손쉽게 적용하곤 한다.
Pod 내의 컨테이너들은 대부분의 리소스를 공유하는데, 네트워크 또한 그 공유 리소스에 속한다.

동일 Pod의 컨테이너끼리는 사실상 같은 네트워크를 사용하고, localhost 또한 공유한다.
그래서 동일 Pod 내의 통신은 항상 추가적인 부하나 레이턴시 없이 매우 빠르게 처리된다.

Pod 간의 통신: CNI

그러면 Pod끼리 통신하는 것은 어떨까?
통신하는 Pod가 같은 노드에 있다면 그나마 괜찮을 수 있지만, 다른 노드에 있다면 결코 쉬운 문제는 아닐 것이다.

이걸 담당하는 것이 CNI라는 컴포넌트의 역할이다.
https://blog.naver.com/sssang97/224173428175
CNI는 Pod 간의 통신을 매개해서 같은 노드에 있다면 노드 내에서만 최적화된 경로를 타게 하고, 다른 노드라면 그걸 알아서 잘 엮어준다. 구현체에 따라서 동작 방식은 많이 다르다.

상세한 것은 별도 포스트를 참조한다.

서버의 외부 개방: Service

서버에 공개된 IP를 할당하고 외부로 여는 것은 Service를 통해 처리된다.
Service는 Pod로 요청을 연결해주며, IP를 할당받아서 실제 인터넷과 통합되게 할 수 있다.
https://blog.naver.com/sssang97/223084158042

그리고 Service를 실제로 외부에 개방하는 것은 Service Proxy의 역할이다.
https://blog.naver.com/sssang97/224174739370

CoreDNS

쿠버는 자체적인 DNS 서버 구성을 통해 내부 통신 과정을 효율화한다.
"test-service"라는 HTTP 서비스가 있다면, 그걸 "http://test-service" 같은 형태로 내부 호출을 할 수 있게 해주는 것이다.

상세한 것은 별도 포스트를 참조한다.
https://blog.naver.com/sssang97/224175706636

NetworkPolicy

Network Policy는 쿠버네티스 내 통신에 대해서 보안 정책을 제공하는 기능이다.
많은 서비스를 운영해야하고, 조직간 보안 통제가 필요하다면 고려를 해야 할 것이다.

상세한 것은 별도 포스트를 참조한다.
https://blog.naver.com/sssang97/223101386886

Ingress

Ingress는 쿠버에서 자체적으로 제공하는 API Gateway의 표준안이다.
다시 말해서 단일 엔드포인트(서비스)에 여러개의 API를 subpath로 붙이는 것이다.

상세한 것은 별도 포스트를 참조한다.
https://blog.naver.com/sssang97/224175723534

참조
https://github.com/kubernetes/design-proposals-archive/blob/main/network/networking.md