쿠버네티스 네트워킹 입문

Brian Ehlert제품 관리 이사

NodePort, LoadBalancer, Ingress 컨트롤러…세상에!

고객 및 커뮤니티와 Kubernetes를 프로덕션 환경에서 사용할 수 있는 수준으로 구축하는 방법에 대해 이야기할 때 가장 자주 받는 질문 중 하나는 “Ingress 컨트롤러가 필요한가요?”입니다. 이 질문에 대한 답은 단순히 예 또는 아니요로 끝나는 경우가 드뭅니다. 대신 트래픽을 Pod로 전달하는 다양한 방법을 이해해야 합니다. 이 블로그에서는 Kubernetes 네트워킹의 기본 사항을 살펴보고, Ingress 컨트롤러가 필요한지, 필요하다면 언제 필요한지 합리적으로 판단할 수 있도록 도와드립니다.

Kubernetes는 외부 트래픽을 Pod로 라우팅하기 위한 여러 접근 방식과 계층을 지원하지만, 모두 동일한 수준의 기능을 제공하는 것은 아닙니다. 기본 모델은 kube-proxy이며, 실제로는 프록시가 아니고 트래픽 부하 분산, API 제어 또는 서비스 동작 모니터링을 위해 설계되지 않았습니다.

다행히 외부 트래픽을 관리하는 다른 방법도 있습니다. 계속하기 전에 Kubernetes 구성 요소를 간단히 살펴보겠습니다.

• Kubernetes 배포는 물리적 또는 가상 머신인 노드로 구성됩니다.
• 노드가 서로 결합하여 클러스터를 형성합니다.
• 각 클러스터는 Kubernetes의 네트워킹 및 인프라 수준에서 가장 기본적인 단위인 Pod를 관리합니다. 하나 이상의 Pod가 모여 하나의 서비스를 구성합니다.
• 각 Pod 내부에는 애플리케이션 규모에 따라 하나 이상의 컨테이너가 있습니다.

Kubernetes는 서비스를 구성하는 파드를 모니터링하고 애플리케이션 요구 사항에 맞게 필요에 따라 확장하거나 축소합니다. 그렇다면 트래픽은 어떻게 파드로 전달할까요? 이때 서비스와 Ingress 컨트롤러라는 두 가지 유형의 Kubernetes 객체가 사용됩니다.

Kubernetes 서비스란 무엇인가요?

According to the Kubernetes 문서에 따르면 서비스는 “Pod 집합에서 실행되는 앱을 외부에 노출하는 추상적인 방법”입니다. 서비스는 클러스터 또는 컨테이너 네트워크의 Pod를 연결하므로 특정 노드에서의 위치는 중요하지 않습니다. 즉, Pod의 위치가 변경되거나 Pod가 삭제된 후 다시 시작되더라도 외부 트래픽을 특정 Pod로 라우팅할 수 있습니다. 이런 점에서 서비스는 매우 기본적인 리버스 프록시와 유사한 역할을 합니다.

외부 트래픽을 Kubernetes로 라우팅하는 데 사용되는 서비스와 서비스 객체에는 여러 유형이 있습니다. 이들은 서로 혼동되는 경우가 많지만 실제로는 각각 매우 다른 역할을 하므로, 각 유형의 기능과 용도, 단점을 살펴볼 필요가 있습니다.

ClusterIP

ClusterIP는 클러스터 내의 다른 서비스가 액세스할 수 있는 서비스를 Kubernetes 내부에 제공하는 기본 서비스입니다. 클러스터 외부에서는 액세스할 수 없습니다. ClusterIP 서비스를 노출하는 유일한 방법은 kube-proxy와 같은 것을 사용하는 것이지만, 이것이 적합한 경우는 많지 않습니다. 몇 가지 예로는 노트북에서 서비스에 액세스하거나, 서비스를 디버깅하거나, 모니터링 정보와 메트릭을 확인하는 경우가 있습니다.

NodePort

NodePort 서비스는 클러스터의 모든 노드에서 특정 포트를 열고, 해당 포트로 노드에 전송되는 모든 트래픽을 관련 앱으로 전달합니다. 이는 앱으로 트래픽을 전달하는 매우 기본적인 방법으로, 실제 트래픽 관리 사용 사례에서는 많은 제약이 있습니다. NodePort당 하나의 서비스만 사용할 수 있으며, 30000~32767 범위의 포트만 사용할 수 있습니다. 2768개의 포트가 많아 보일 수 있지만, Kubernetes를 대규모로 운영하는 조직에서는 금세 소진됩니다. 또한 NodePort는 레이어 4 라우팅 규칙과 Linux iptables 유틸리티를 사용하므로 레이어 7 라우팅이 제한됩니다.

라우팅 제한 외에도 NodePort를 사용할 때는 다음과 같은 세 가지 큰 단점이 있습니다:

• 다운스트림 클라이언트가 각 노드에 연결하려면 해당 노드의 IP 주소를 알고 있어야 합니다. 노드의 IP 주소나 가상 머신 호스트가 변경되면 문제가 될 수 있습니다.
• NodePort는 여러 IP 주소로 트래픽을 프록시할 수 없습니다.
• 다이어그램에 표시된 것처럼 NodePort는 Kubernetes 클러스터 내에서 부하 분산을 제공하지 않으므로 트래픽이 서비스 전반에 무작위로 분산됩니다. 이로 인해 서비스 과부하와 포트 고갈이 발생할 수 있습니다.
  

로드 밸런서

LoadBalancer 서비스는 외부 트래픽을 수신하지만, 해당 트래픽의 인터페이스 역할을 하는 외부 로드 밸런서가 필요합니다. 외부 로드 밸런서가 실행 중인 Pod에 매핑되도록 적절히 조정되고 재구성되어 있다면 레이어 7 라우팅(Pod IP 주소로)을 지원합니다. LoadBalancer는 서비스를 외부에 노출하는 가장 일반적인 방법 중 하나입니다. 주로 클라우드 플랫폼에서 사용되며, 소규모 정적 배포에 적합합니다.

관리형 Kubernetes 서비스를 사용하는 경우 클라우드 공급자가 선택한 로드 밸런서가 자동으로 제공됩니다. 예를 들어 Google Cloud Platform에서는 LoadBalancer 서비스 유형을 사용하여 네트워크 로드 밸런서를 생성할 수 있으며, AWS에서는 애플리케이션 로드 밸런서(ALB)가 기본값입니다. 외부에 노출하는 각 서비스에는 모든 트래픽을 전달하는 고유한 공용 IP 주소가 할당되지만 필터링이나 라우팅은 수행되지 않으므로 거의 모든 유형의 트래픽(HTTP, TCP/UDP, WebSocket 등)을 전송할 수 있습니다. 또는 더 많은 기능이나 플랫폼에 구애받지 않는 도구가 필요한 경우처럼 클라우드 공급자의 도구를 사용하고 싶지 않다면, 이를 F5 BIG-IP(외부 로드 밸런서 역할) 및 F5 Container Ingress Services(LoadBalancer 역할을 수행하는 오퍼레이터)와 같은 솔루션으로 대체할 수 있습니다. 이 패턴에 대한 자세한 내용은 블로그의 동일한 아키텍처에 BIG-IP 및 NGINX Ingress Controller 배포하기를 참조하세요.

수요 변화에 맞춰 애플리케이션 Pod를 확장해야 하는 동적 환경에서는 LoadBalancer를 사용해 애플리케이션을 외부에 노출하기가 까다로워집니다. 각 서비스에 고유한 IP 주소가 할당되므로 인기 있는 애플리케이션의 경우 관리해야 할 IP 주소가 수백 개, 심지어 수천 개에 이를 수 있습니다. 대부분의 경우 외부 로드 밸런서는 다음 다이어그램과 같이 NodePort를 통해 서비스에 연결됩니다. 이렇게 하면 트래픽이 노드 전체에 고르게 분산되지만, 서비스에 대한 로드 밸런싱은 여전히 불가능하므로 서비스 과부하와 포트 고갈 문제가 계속 발생합니다.

Kubernetes 인그레스 컨트롤러란 무엇인가요?

According to the Kubernetes 문서에 따르면, “컨트롤러는 클러스터의 상태를 감시한 다음 필요한 경우 변경을 수행하거나 요청하는 제어 루프입니다. 각 컨트롤러는 현재 클러스터 상태를 원하는 상태에 더 가깝게 만들려고 합니다.” 컨트롤러는 리소스를 적절히 할당하고, 영구 스토리지를 지정하며, 크론 작업을 관리하는 등 Kubernetes의 다양한 작업에서 상태를 관리하는 데 사용됩니다.

라우팅의 맥락에서 Ingress 컨트롤러는 NodePort와 LoadBalancer의 한계를 극복하는 방법입니다.

Ingress 컨트롤러는 특정 서비스로 레이블이 지정된 Pod와의 외부 상호 작용을 구성하고 관리하는 데 사용됩니다. Ingress 컨트롤러는 동적 레이어 7 라우팅을 핵심 기능으로 취급하도록 설계되었습니다. 따라서 훨씬 적은 수고로 더욱 세분화된 제어와 관리가 가능합니다. Ingress 컨트롤러를 사용하면 인그레스 트래픽을 제어할 수 있을 뿐만 아니라 서비스 수준의 성능 메트릭을 제공하고 보안 정책의 일부로 활용할 수도 있습니다. Ingress 컨트롤러는 TLS 종료, 여러 도메인 및 네임스페이스 처리, 트래픽 부하 분산 등 기존 외부 로드 밸런서의 다양한 기능을 갖추고 있습니다. 또한 서비스 단위가 아닌 요청 단위로 트래픽 부하를 분산할 수 있어 레이어 7 트래픽을 더욱 유용한 관점에서 파악하고 SLA를 훨씬 효과적으로 적용할 수 있습니다.

또 다른 장점도 있습니다! Ingress 컨트롤러는 특정 파드의 아웃바운드 트래픽이 지정된 외부 서비스로만 전송되도록 허용하는 egress 규칙을 적용하거나, mTLS를 사용해 트래픽이 상호 암호화되도록 보장할 수도 있습니다. mTLS를 의무화하는 것은 의료, 금융, 통신, 정부 등의 산업에서 규제 대상 서비스를 제공하는 데 매우 중요하며, 엔드투엔드 암호화(E2EE) 전략의 핵심 요소이기도 합니다. 또한 동일한 도구로 아웃바운드 트래픽을 제어하면 서비스에 비즈니스 로직을 적용하는 과정도 간소화됩니다. ingress와 egress가 동일한 컨트롤 플레인에 연결되어 있으면 적절한 리소스 규칙을 훨씬 쉽게 설정할 수 있습니다.

다음 다이어그램은 Ingress 컨트롤러가 클라이언트의 복잡성을 줄이는 방식을 보여줍니다. 이제 클라이언트는 서비스의 IP 주소나 포트를 알 필요가 없습니다. 서비스 간 트래픽 분산도 보장됩니다. 일부 Ingress 컨트롤러는 유연성과 제어력을 높이기 위해 여러 로드 밸런싱 알고리즘을 지원합니다.

Ingress 컨트롤러를 사용하여 로드 밸런서 배포하기

As we discuss in 동일한 아키텍처에 BIG-IP 및 NGINX Ingress Controller 배포에서 설명한 것처럼, 많은 조직에는 외부 로드 밸런서를 Ingress 컨트롤러(대부분의 경우 여러 Ingress 컨트롤러 인스턴스)와 함께 배포하면 유용한 사용 사례가 있습니다. 이는 조직에서 Kubernetes를 확장하거나 규정 준수 요구 사항이 엄격한 환경을 운영해야 할 때 특히 일반적입니다. 이러한 도구는 일반적으로 서로 다른 팀에서 관리하며 각기 다른 용도로 사용됩니다:

• 로드 밸런서(또는 ADC):
  • 소유자: NetOps(또는 SecOps) 팀
  • 사용 사례: Kubernetes 외부에서 클러스터 외부 사용자에게 제공되는 서비스와 앱을 위한 유일한 공개 엔드포인트로 사용됩니다. 보안을 강화하고 더 높은 수준의 네트워크 관리를 제공하도록 설계된 보다 범용적인 어플라이언스로 사용됩니다.
• 인그레스 컨트롤러:
  • 담당: 플랫폼 운영 또는 DevOps 팀
  • 사용 사례: Kubernetes 내부에서 남북 방향 트래픽(HTTP2, HTTP/HTTPS, SSL/TLS 종료, TCP/UDP, WebSocket, gRPC)의 세밀한 부하 분산, API 게이트웨이 기능, 중앙 집중식 보안 및 ID 관리.

이 다이어그램은 로드 밸런서가 여러 클러스터에 트래픽을 분산하고, 각 클러스터의 Ingress 컨트롤러가 서비스에 트래픽이 균등하게 분산되도록 하는 방식을 보여줍니다.

다음 단계

이 글을 모두 읽고도 여전히 이해가 잘되지 않는다면 Linux Foundation 웨비나 Ingress 컨트롤러가 필요한 이유와 선택 방법을 확인해 보세요. 이 웨비나에서는 NGINX 전문가들이 Kubernetes 네트워킹의 기초를 설명하고, Ingress 컨트롤러를 심층적으로 살펴보며, Ingress 컨트롤러 생태계에 대해 논의합니다.

Ingress 컨트롤러를 활용하는 방법과 요구 사항에 가장 적합한 컨트롤러를 선택하는 방법에 대해 자세히 알아보려면 블로그에서 Ingress 컨트롤러 선택 가이드, 1부: 요구 사항 파악하기를 읽어보세요.

작성자 소개

Brian Ehlert제품 관리 이사

Brian Ehlert의 다른 블로그 게시물