Kubernetes ingress

Kubernetes ingress는 애플리케이션 계층(L5-7)에서 로드 밸런싱을 담당하는 구성 요소예요. HTTP/HTTPS 요청을 도메인이나 URL 기준으로 서비스에 연결해 주고, SSL/TLS 종료도 맡을 수 있죠. 이 문서는 ingress의 개념, 종류, 그리고 네트워크 정책과의 상호작용을 친절하게 풀어줘요.

출처: 문서

본문

SECONDARY: 이 가이드는 Calico에 국한되지 않는 교육 자료를 제공해요.

이 가이드에서 배울 내용은 다음과 같아요.

• Kubernetes ingress란 무엇일까요?
• 왜 ingress를 사용할까요?
• 서로 다른 ingress 구현은 어떻게 다를까요?
• ingress와 네트워크 정책은 어떻게 상호작용할까요?
• ingress와 서비스는 내부적으로 어떻게 맞물릴까요?

Kubernetes ingress란 무엇일까요?

Kubernetes Ingress는 Kubernetes 서비스 위에 쌓여 애플리케이션 계층에서 로드 밸런싱을 제공해요. HTTP와 HTTPS 요청을 특정 도메인이나 URL에 따라 Kubernetes 서비스에 매핑하죠. Ingress는 서비스로 로드 밸런싱하기 전에 SSL / TLS를 종료하는 용도로도 사용할 수 있어요.

Ingress가 구현되는 방식의 세부 사항은 어떤 Ingress Controller를 사용하는지에 달려 있어요. Ingress Controller는 Kubernetes Ingress 리소스를 감시하고, 원하는 로드 밸런싱 동작을 구현하도록 하나 이상의 ingress 로드 밸런서를 프로비저닝/구성하는 책임을 져요.

네트워크 계층(L3-4)에서 처리되는 Kubernetes 서비스와 달리, ingress 로드 밸런서는 애플리케이션 계층(L5-7)에서 동작해요. 들어오는 연결은 로드 밸런서에서 종료되기 때문에 개별 HTTP / HTTPS 요청을 들여다볼 수 있어요. 그런 다음 요청은 로드 밸런서에서 선택된 서비스의 백킹 pod들로, 별도의 연결을 통해 포워딩돼요. 그 결과 백킹 pod에 적용한 네트워크 정책은 로드 밸런서로부터의 연결만 허용하도록 접근을 제한할 수 있지만, 특정 원본 클라이언트를 제한할 수는 없어요.

왜 Kubernetes Ingress를 사용할까요?

Kubernetes 서비스가 이미 클러스터 외부에서 서비스 접근을 로드 밸런싱하는 메커니즘을 제공하는데, 왜 Kubernetes Ingress를 쓰고 싶어질까요?

대표적인 사용 사례는 여러 개의 HTTP / HTTPS 서비스를 하나의 외부 IP 주소로 노출하고 싶을 때예요. 서비스마다 URL 경로를 다르게 줄 수도 있고, 여러 도메인으로 나눌 수도 있죠. Kubernetes 서비스로 각 서비스를 클러스터 밖에 따로 노출하면 서비스마다 별도의 외부 IP 주소가 생기니까, 클라이언트 구성 입장에서는 Ingress 쪽이 훨씬 단순해요.

반대로 애플리케이션 아키텍처가 하나의 "프론트엔드" 마이크로서비스로 시작된다면 Kubernetes 서비스만으로도 충분할 가능성이 높아요. 이런 경우에는 단순성 때문에, 그리고 네트워크 정책으로 특정 클라이언트 접근을 더 쉽게 제한할 수 있으니 Ingress를 굳이 추가하지 않는 편을 선호할 수도 있어요. 사실상 "프론트엔드" 마이크로서비스가 아래에서 다룰 클러스터 내부 ingress 솔루션과 크게 다르지 않은 방식으로 Kubernetes Ingress의 역할을 이미 하고 있는 거예요.

Ingress 솔루션의 종류

대체로 ingress 솔루션은 두 가지 타입으로 나눌 수 있어요.

• 클러스터 내부 ingress - ingress 로드 밸런싱을 클러스터 안의 pod가 수행해요.
• 외부 ingress - ingress 로드 밸런싱을 클러스터 밖의 어플라이언스나 클라우드 제공자 기능으로 구현해요.

클러스터 내부 ingress 솔루션

클러스터 내부 ingress 솔루션은 클러스터 안의 pod에서 실행되는 소프트웨어 로드 밸런서를 사용해요. 이 패턴을 따르는 ingress 컨트롤러는 NGINX ingress controller를 예로 들 수 있을 만큼 다양해요.

이 방식의 장점은 다음과 같아요.

• Kubernetes가 허용하는 한도까지 ingress 솔루션을 수평으로 확장할 수 있어요.
• 특정 로드 밸런싱 알고리즘이나 보안 옵션처럼 여러분의 필요에 가장 잘 맞는 ingress 컨트롤러를 고를 수 있어요.

ingress 트래픽을 클러스터 내부 ingress pod로 보내려면, 보통 ingress pod를 Kubernetes 서비스로 외부에 노출해요. 그래서 클러스터 밖에서 서비스에 접근하는 표준 방법 중 무엇이든 사용할 수 있어요. 흔한 방법은 externalTrafficPolicy:local과 함께 외부 네트워크 로드 밸런서나 서비스 IP 광고를 쓰는 거예요. 이렇게 하면 네트워크 홉 수가 최소화되고 클라이언트 소스 IP 주소가 유지되기 때문에, 원한다면 네트워크 정책으로 ingress pod에 대한 접근을 특정 클라이언트로 제한할 수도 있어요.

외부 ingress 솔루션

외부 ingress 솔루션은 클러스터 밖의 애플리케이션 로드 밸런서를 사용해요. 세부 사항과 기능은 어떤 ingress 컨트롤러를 쓰는지에 따라 달라지지만, 대부분의 클라우드 제공자는 클라우드 제공자의 애플리케이션 로드 밸런서를 자동으로 프로비저닝/관리해 ingress를 제공하는 ingress 컨트롤러를 포함하고 있어요.

이 타입의 ingress 솔루션 장점은 클라우드 제공자가 ingress의 운영 복잡성을 대신 떠안아 준다는 거예요. 단점은 풍부한 클러스터 내부 ingress 솔루션에 비해 기능이 제한적일 수 있고, ingress로 노출할 수 있는 서비스의 최대 개수가 클라우드 제공자별 한도에 묶인다는 점이에요.

대부분의 애플리케이션 로드 밸런서는 트래픽을 해당 서비스의 node port를 통해 선택된 서비스의 백킹 pod로 포워딩하는 기본 동작 방식을 지원해요.

이 기본 방식 외에도 일부 클라우드 제공자는 두 번째 애플리케이션 계층 로드 밸런싱 모드를 지원해요. 이 모드는 node port나 다른 kube-proxy 서비스 처리를 거치지 않고 서비스를 백킹하는 pod들로 직접 로드 밸런싱해요. node port가 다른 노드의 pod로 로드 밸런싱할 때 생기는 잠재적인 두 번째 네트워크 홉을 없애는 게 장점이에요. 잠재적인 단점은 매우 큰 규모(예: 서비스를 백킹하는 pod가 수백 개)로 운영할 때 이 모드에서 애플리케이션 계층 로드 밸런서가 로드 밸런싱할 수 있는 IP의 최대 한도를 넘길 수 있다는 거예요. 그런 경우라면 클러스터 내부 ingress 솔루션으로 전환하는 게 더 잘 맞을 거예요.

Show me everything!

지금까지의 다이어그램은 ingress와 서비스의 연결 수준(L5-7) 표현에 초점을 맞췄어요. 연결을 처리할 때 어떤 시나리오에서 클라이언트 소스 IP 주소가 유지되는지를 포함해, 네트워크 수준(L3-4) 상호작용은 Kubernetes 서비스 알아보기 가이드에서 더 배울 수 있어요.

서비스의 내부 동작을 이미 잘 안다면, 네트워크 계층(L3-4)에서 서비스가 어떻게 로드 밸런싱되는지 보여주는 더 완전한 다이어그램들도 준비했어요.

SECONDARY: 이 다음 단계의 세부 사항을 몰라도 ingress를 충분히 잘 사용할 수 있어요! 서비스와 ingress가 내부적으로 어떻게 맞물리는지 더 깊이 파고들고 싶지 않다면 이 다이어그램들은 넘어가도 괜찮아요.

클러스터 내부 ingress 솔루션이 externalTrafficPolicy:local과 함께 서비스 타입 LoadBalancer로 노출된 형태

node port를 통하는 외부 ingress 솔루션

pod로 직접 가는 외부 ingress 솔루션

더 알아보기 (Learn more)

ingress 뒤에 있는 네트워크 수준(L3-4) 동작이 궁금해지면 Kubernetes 서비스 가이드를 함께 읽어보세요. Calico 네트워크 정책으로 ingress pod 접근을 제한하는 방법도 NetworkPolicy 문서에서 살펴볼 수 있어요.