Kubernetes 네트워킹 101

Kubernetes를 프로덕션 등급으로 만드는 것에 대해 고객 및 커뮤니티와 이야기할 때 가장 일반적인 질문 중 하나는 Ingress Controller가 필요한가요? 이 질문에 대한 대답은 간단한 예 또는 아니오가 아니라 대신 Pod로 트래픽을 얻을 수 있는 다양한 방법에 대한 약간의 교육이 포함됩니다. 이 모범사례에서는 Kubernetes 네트워킹의 기본 사항을 다루므로 Ingress Controller가 필요한지 여부와 시기에 대해 정보에 입각한 결정을 내릴 수 있습니다.

Kubernetes는 외부 트래픽을 Pod로 라우팅하기 위한 몇 가지 가능한 접근 방식과 계층을 지원하지만 모두 동일하게 생성되지는 않습니다. 기본 모델은 kube-proxy, 실제로 프록시가 아니며 트래픽을 로드 밸런싱하거나 API를 제어하거나 서비스 동작을 모니터링 하도록 설계되지 않았습니다.

다행스럽게도 외부 트래픽을 관리하는 다른 방법이 있지만 계속하기 전에 Kubernetes 구성 요소를 빠르게 검토해 보겠습니다.

  • Kubernetes 배포는 물리적 또는 가상 머신(VM)인 Nodes로 구성됩니다.
  • Node가 함께 결합하여 클러스터를 형성합니다 .
  • 각 클러스터는 Kubernetes의 네트워킹 및 인프라 수준에서 가장 낮은 공통 분모인 Pod를 관리합니다. 하나 이상의 Pod가 함께 Service를 구성합니다 .
  • 각 Pod 내부에는 애플리케이션 크기에 따라 하나 이상의 컨테이너가 있습니다.

Kubernetes는 Service를 구성하는 Pod를 관찰하고 앱 요구 사항에 맞게 필요에 따라 확장합니다. 그러나 어떻게 Pod로 트래픽을 전달할 수 있습니까? 여기에서 두 가지 유형의 Kubernetes Object(Service 및 Ingress Controller)가 제공됩니다.

목차

1. 쿠버네티스 서비스란?
  1-1. ClusterIP
  1-2. NodePort
  1-3. Load Balancer
2. Kubernetes Ingress Controller란 무엇입니까?
3. Ingress Controller가 있는 Load Balancer 배포

1. 쿠버네티스 서비스란?

Kubernetes 문서에 따르면 Service는 “Pod 세트에서 실행되는 앱을 노출하는 추상적인 방법”입니다. Service는 특정 Node에서의 위치가 관련이 없도록 클러스터 또는 컨테이너 네트워크의 Pod를 연결합니다. 즉, 위치가 변경되거나 파괴되고 다시 시작되는 경우에도 외부 트래픽이 특정 Pod로 라우팅될 수 있습니다. 이러한 방식으로 Service는 매우 기본적인 Reverse Proxy처럼 작동합니다.

외부 트래픽을 Kubernetes로 라우팅하는 것과 관련된 여러 유형의 Service 및 Service Object 유형이 있습니다. 그들은 종종 서로 혼동되지만 실제로 각각은 매우 다른 일을 하므로 기능, 용도 및 단점을 살펴볼 가치가 있습니다.

1-1. ClusterIP

ClusterIP는 클러스터 내의 다른 Service가 액세스할 수 있는 Kubernetes 내의 Service를 제공하는 기본 Service입니다. 클러스터 외부에서 액세스할 수 없습니다. ClusterIP Service를 노출하는 유일한 방법은 kube-proxy와 같은 것을 사용하는 것이지만 이것이 의미가 있는 시나리오는 거의 없습니다. 제한된 예에는 laptop computer에서 Service에 액세스하거나 Service를 디버깅하거나 일부 모니터링 및 메트릭을 확인하는 것이 포함됩니다.

1-2. NodePort

NodePort Service는 클러스터의 모든 Node에서 특정 포트를 열고 해당 포트의 Node로 전송된 모든 트래픽을 해당 앱으로 전달합니다. 이것은 앱으로 트래픽을 가져오는 매우 기본적인 방법이며 실제 트래픽 관리 사용 사례에는 많은 제한이 있습니다. NodePort당 하나의 Service만 가질 수 있으며 30000에서 32767 범위의 포트만 사용할 수 있습니다. 2768 포트가 많은 것처럼 들릴 수 있지만 대규모 Kubernetes를 실행하는 조직은 빠르게 고갈됩니다. 또한 NodePort는 Layer 4 라우팅 규칙과 Layer 7 라우팅을 제한하는 Linux iptables 유틸리티를 사용합니다.

라우팅 제한 외에도 NodePort 사용에는 세 가지 다른 큰 단점이 있습니다.

  • 다운스트림 클라이언트는 연결하려면 Node의 IP 주소를 알아야 합니다. 이는 Node의 IP 주소 또는 가상 머신 호스트가 변경되면 문제가 됩니다.
  • NodePort는 여러 IP 주소로 트래픽을 Proxy 할 수 없습니다.
  • 다이어그램에서 볼 수 있듯이 NodePort는 Kubernetes 클러스터 내에서 로드 밸런싱을 제공하지 않으므로 트래픽이 서비스 간에 무작위로 분산됩니다. 이로 인해 서비스 과부하 및 포트 고갈이 발생할 수 있습니다.

1-3. Load Balancer

LoadBalancer Service는 외부 트래픽을 허용하지만 해당 트래픽에 대한 인터페이스로 외부 Load Balancer가 필요합니다. 이는 외부 Load Balancer가 실행 중인 Pod에 매핑되도록 적절하게 조정 및 재구성되는 경우 Layer 7 라우팅(포드 IP 주소로)을 지원합니다. LoadBalancer는 Service를 외부에 노출하는 가장 널리 사용되는 방법 중 하나입니다. 클라우드 플랫폼에서 가장 자주 사용되며 소규모의 정적 배포에 적합합니다.

관리형 Kubernetes 서비스를 사용하는 경우 클라우드 공급자가 선택한 Load Balancer를 자동으로 가져옵니다. 예를 들어 Google Cloud Platform에서는 LoadBalancer 서비스 유형을 사용하여 Network Load Balancer를 가동할 수 있지만 AWS에서는 ALB(Application Load Balancer)가 기본값입니다. 노출하는 각 서비스는 필터링이나 라우팅 없이 모든 트래픽을 전달하는 고유한 공용 IP 주소를 얻습니다. 즉, 거의 모든 유형의 트래픽(HTTP, TCP/UDP, WebSocket 등)을 보낼 수 있습니다.

예를 들어 더 많은 기능이나 플랫폼에 구애받지 않는 도구가 필요한 경우와 같이 클라우드 공급자의 도구를 사용하고 싶지 않다면 대안은 NGINX Load Balancer와 같은 것으로 교체하는 것입니다.

LoadBalancer를 사용하여 앱을 노출하는 것은 변화하는 수요 수준에 맞게 앱 Pod를 확장해야 하는 동적 환경에서 어려운 일이 됩니다. 각 Service에는 고유한 IP 주소가 있기 때문에 인기 있는 앱에는 수백 또는 수천 개의 IP 주소를 관리할 수 있습니다. 대부분의 경우 외부 Load Balancer는 다음 다이어그램과 같이 NodePort를 통해 Service에 연결합니다. 이렇게 하면 트래픽이 Node 전체에 고르게 분산되지만 Service에 대한 Load Balancing은 여전히 ​​불가능하므로 Service 과부하 및 Port 고갈이 계속 발생합니다.

2. Kubernetes Ingress Controller란 무엇입니까?

Kubernetes 문서에 따르면 “Controller는 클러스터의 상태를 관찰한 다음 필요한 경우 변경을 수행하거나 요청하는 제어 루프입니다. 각 Controller는 현재 클러스터 상태를 원하는 상태에 더 가깝게 이동하려고 합니다.” Controller는 리소스를 적절하게 할당하고, 영구 저장소를 지정하고, cron 작업을 관리하는 등 많은 작업을 위해 Kubernetes에서 상태를 관리하는 데 사용됩니다.

라우팅의 맥락에서 Ingress Controller는 NodePort 및 LoadBalancer의 한계를 극복하는 방법입니다.

Ingress Controller는 특정 Service에 레이블이 지정된 파드(Pod)와의 외부 상호작용을 구성하고 관리하는 데 사용됩니다. Ingress Controller는 동적 Layer 7 라우팅을 일급 시민으로 취급하도록 설계되었습니다. 이는 Ingress Controller가 적은 수고로 훨씬 더 세분화된 제어 및 관리를 제공한다는 것을 의미합니다. Ingress Controller를 사용하여 Ingress 트래픽을 제어할 뿐만 아니라 보안 정책의 일부로 Service 수준 성능 메트릭을 제공할 수도 있습니다. Ingress Controller에는 TLS Termination, 다중 도메인 및 네임스페이스 처리, 트래픽 Load Balancing과 같은 기존 외부 Load Balancer의 많은 기능이 있습니다. Ingress Controller는 Service 수준이 아닌 요청별로 트래픽을 Load Balancing할 수 있으며, Layer 7 트래픽에 대한 보다 유용한 보기와 SLA를 적용하는 훨씬 더 나은 방법입니다.

그리고 또 하나의 보너스가 있습니다! Ingress Controller는 특정 Pod에서 특정 외부 Service로만 나가는 트래픽을 허용하거나 mTLS를 사용하여 트래픽이 상호 암호화되도록 하는 송신 규칙을 시행할 수도 있습니다. mTLS가 필요한 것은 의료, 금융, 통신, 정부와 같은 산업에서 규제 서비스를 제공하는 데 중요하며 종단 간 암호화(E2EE) 전략의 핵심 구성 요소 입니다 . 동일한 도구에서 나가는 트래픽을 제어하면 Service에 대한 비즈니스 로직의 적용도 간소화됩니다. 수신과 송신이 모두 동일한 제어 평면에 연결되어 있으면 적절한 리소스 규칙을 설정하는 것이 훨씬 쉽습니다.

다음 다이어그램은 Ingress Controller가 더 이상 Service의 IP 주소나 포트를 알 필요가 없는 클라이언트의 복잡성을 줄이는 방법을 보여줍니다. Service 전반에 걸친 트래픽 분산이 보장됩니다. 일부 Ingress Controller는 더 많은 유연성과 제어를 위해 여러 Load Balancing 알고리즘을 지원합니다.

3. Ingress Controller가 있는 Load Balancer 배포

많은 조직에는 Ingress Controller(또는 대부분의 경우 여러 Ingress Controller 인스턴스)가 있는 외부 Load Balancer를 배포하는 데 도움이 되는 사용 사례가 있습니다. 이는 조직이 Kubernetes를 확장하거나 높은 규정 준수 환경에서 운영해야 하는 경우에 특히 일반적입니다. 이 도구는 일반적으로 여러 팀에서 관리하며 다양한 목적으로 사용됩니다.

  • Load Balancer:
    • 소유자: NetOps(또는 SecOps)팀
    • 사용 사례: Kubernetes 외부는 클러스터 외부의 사용자에게 제공되는 Service 및 앱에 대한 유일한 공개 EndPoint입니다. 보안을 용이하게 하고 더 높은 수준의 네트워크 관리를 제공하도록 설계된 보다 일반적인 어플라이언스로 사용됩니다.
  • Ingress Controller:
    • 소유자: Platform Ops 또는 DevOps 팀
    • 사용 사례: north-south 트래픽(HTTP2, HTTP/HTTPS, SSL/TLS Termination, TCP/UDP, WebSocket, gRPC), API Gateway 기능, 중앙 집중식 보안 및 ID의 세분화된 Load Balancing을 위한 Kubernetes 내부.

이 다이어그램은 여러 클러스터에 걸쳐 트래픽 분산을 처리하는 Load Balancer를 보여주며 클러스터에는 Service에 대한 균등한 분배를 보장하기 위해 Ingress Controller가 있습니다.