이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

쿠버네티스 클러스터 내에서 실행되는 애플리케이션들을 외부 세계에 노출하는 방법은 여러 가지가 있습니다. 앞서 살펴본 서비스(Service)의 NodePort나 LoadBalancer 타입도 그중 하나입니다. NodePort는 각 노드의 특정 포트를 통해 서비스를 노출하지만, 고가용성이나 사용자 친화적인 접근을 위해서는 별도의 외부 로드 밸런서가 필요합니다. LoadBalancer 타입은 클라우드 환경에서 외부 로드 밸런서를 자동으로 생성해주지만, 이는 주로 L4(TCP/UDP) 레벨에서 동작하며, 각 서비스마다 별도의 로드 밸런서와 공인 IP 주소가 할당되어 비용 효율성이 떨어질 수 있다는 단점이 있습니다. 특히 HTTP(S) 기반의 웹 서비스가 많아질수록 이러한 문제점은 더욱 두드러집니다.

바로 이러한 상황에서 인그레스(Ingress)가 그 진가를 발휘합니다. 인그레스는 클러스터 외부에서 들어오는 HTTP 및 HTTPS 트래픽을 관리하고, 이를 클러스터 내부의 적절한 서비스로 라우팅하는 API 오브젝트입니다. 마치 클러스터의 정문에 위치한 매우 지능적인 안내 데스크와 같아서, 방문객(HTTP 요청)의 목적지(URL 경로, 호스트 헤더 등)를 파악하여 가장 적절한 부서(서비스)로 안내해주는 역할을 합니다.

인그레스는 단순히 트래픽을 전달하는 것을 넘어, L7(애플리케이션 계층) 레벨의 다양한 라우팅 규칙, SSL/TLS 암호화 처리, 가상 호스팅 등 웹 서비스 운영에 필수적인 고급 기능들을 제공함으로써, 서비스 노출을 훨씬 더 유연하고 효율적이며 비용 효과적으로 만들어줍니다.

그렇다면 인그레스가 구체적으로 어떤 역할들을 수행하며, 다른 서비스 노출 방식에 비해 어떤 장점들을 가지고 있는지 자세히 살펴보겠습니다.

쿠버네티스 환경에서 개발되고 운영되는 애플리케이션들은 종종 다수의 마이크로서비스로 구성되어 각기 다른 기능을 수행합니다. 이러한 각 마이크로서비스를 외부 세계에 노출해야 할 때, 전통적인 방식이나 쿠버네티스의 LoadBalancer 타입 서비스를 개별적으로 사용한다면 여러 가지 비효율과 관리의 복잡성에 직면하게 됩니다. 바로 이 지점에서 인그레스(Ingress)가 제공하는 가장 핵심적인 장점 중 하나인 “단일 외부 IP 주소(또는 단일 로드 밸런서)를 통해 클러스터 내의 여러 다양한 서비스들을 통합적으로 외부로 노출”할 수 있는 능력이 빛을 발합니다. 이는 마치 하나의 거대한 백화점 건물(단일 외부 IP 주소를 가진 진입점)이 정문 하나만을 가지고 있으면서도, 그 안에는 의류, 식품, 가전제품 등 수많은 종류의 독립된 상점(클러스터 내부의 개별 마이크로서비스)들이 입점해 있고, 방문객들은 이 정문을 통해 들어와 안내판이나 내부 경로(인그레스 라우팅 규칙)에 따라 원하는 상점을 찾아갈 수 있는 것과 매우 유사한 개념입니다.

만약 우리가 쿠버네티스의 LoadBalancer 타입 서비스를 사용하여 클러스터 내의 각 마이크로서비스(예: 사용자 인증 서비스, 상품 정보 서비스, 주문 처리 서비스, 고객 지원 서비스 등)를 개별적으로 외부 인터넷에 노출한다고 가정해 봅시다. 이 경우, 각 서비스마다 별도의 외부 로드 밸런서 인스턴스가 프로비저닝되고, 각 로드 밸런서에는 고유한 공인 IP 주소가 할당됩니다. 예를 들어, 10개의 독립적인 마이크로서비스를 LoadBalancer 타입으로 노출한다면, 이론적으로 10개의 서로 다른 외부 로드 밸런서와 10개의 공인 IP 주소가 필요하게 됩니다. 이러한 방식은 다음과 같은 명확한 단점들을 야기합니다.

1. 클라우드 비용 증가: 대부분의 퍼블릭 클라우드 제공업체(AWS, GCP, Azure 등)는 외부 로드 밸런서 인스턴스 사용 및 공인 IP 주소 할당에 대해 시간당 또는 월별 요금을 부과합니다. 서비스의 수가 증가함에 따라 이러한 비용은 선형적으로, 때로는 그 이상으로 증가하여 전체 클라우드 인프라 운영 비용에 상당한 부담을 줄 수 있습니다.
2. 공인 IP 주소 고갈 및 관리 복잡성: IPv4 주소는 이미 고갈 상태에 가까워지고 있으며, 각 서비스마다 공인 IP를 할당하는 것은 귀중한 IP 자원의 낭비로 이어질 수 있습니다. 또한, 이렇게 다수의 공인 IP 주소를 관리하고, 각 IP 주소에 대한 DNS 레코드(예: A 레코드 또는 CNAME 레코드)를 설정하며, 방화벽 규칙을 개별적으로 적용하는 것은 매우 번거롭고 오류가 발생하기 쉬운 운영 작업입니다.
3. 확장성 및 유연성 저하: 새로운 마이크로서비스를 추가하거나 기존 서비스를 변경할 때마다 새로운 로드 밸런서를 프로비저닝하거나 기존 설정을 수정해야 하므로, 시스템의 확장성과 변경에 대한 민첩성이 떨어질 수 있습니다.

하지만 인그레스를 도입하면 이러한 문제점들을 효과적으로 해결할 수 있습니다. 인그레스는 일반적으로 단 하나의 외부 로드 밸런서(이 로드 밸런서는 실제로는 인그레스 컨트롤러 파드가 외부로 노출되는 지점 역할을 합니다)를 통해 클러스터로 들어오는 모든 HTTP 및 HTTPS 트래픽을 수신합니다. 그리고 인그레스 리소스에 정의된 다양한 라우팅 규칙(예: 호스트 이름, URL 경로 기반)에 따라 이 수신된 트래픽을 내부의 각기 다른 서비스로 지능적으로 분배하고 전달합니다. 즉, 외부에서 볼 때는 단일한 진입점(IP 주소 또는 도메인 이름)만이 존재하지만, 내부적으로는 이 진입점을 통해 수많은 개별 서비스들이 마치 독립된 것처럼 외부에 서비스를 제공할 수 있게 되는 것입니다.

이러한 “단일 IP 주소(또는 단일 로드 밸런서)를 통한 다수 서비스 노출” 방식은 다음과 같은 구체적이고 강력한 이점들을 제공합니다.

• 획기적인 비용 절감: 가장 직접적인 효과는 필요한 외부 로드 밸런서 인스턴스와 공인 IP 주소의 수를 극단적으로 줄일 수 있다는 점입니다. 이론적으로 단 하나의 로드 밸런서와 IP 주소만으로도 수십, 수백 개의 HTTP(S) 기반 마이크로서비스를 외부로 노출할 수 있으므로, 클라우드 인프라 비용을 크게 절감할 수 있습니다. 이는 특히 예산이 제한적인 스타트업이나 비용 최적화가 중요한 대규모 시스템에서 매우 중요한 고려 사항입니다.
• IP 주소 및 DNS 관리의 단순화: 관리해야 할 외부 IP 주소의 수가 현저히 줄어들기 때문에, DNS 레코드 설정(예: 와일드카드 DNS 레코드 *.example.com을 단일 인그레스 IP로 향하게 설정) 및 IP 주소 할당/회수 관리가 훨씬 단순하고 용이해집니다. 이는 운영팀의 업무 부담을 줄이고, 설정 오류로 인한 서비스 장애 가능성을 낮추는 데 기여합니다.
• 통합된 단일 진입점(Single Entry Point) 제공: 클러스터로 들어오는 모든 웹 서비스 트래픽이 하나의 논리적인 지점(인그레스 컨트롤러)을 통해 유입되므로, 이 지점에서 트래픽 모니터링, 실시간 로깅, 접근 제어, 웹 애플리케이션 방화벽(WAF) 적용, DDoS 공격 방어 등과 같은 보안 및 운영 관련 정책을 중앙에서 일관되게 적용하고 관리하기가 매우 용이해집니다. 각 서비스별로 이러한 정책을 개별적으로 설정하고 관리하는 것보다 훨씬 효율적이고 강력한 통제력을 확보할 수 있습니다.
• TLS/SSL 인증서 관리의 중앙화: 여러 도메인 또는 하위 도메인에 대한 TLS/SSL 인증서도 인그레스 컨트롤러 한 곳에서 중앙 집중적으로 관리하고, TLS 종료(Termination)를 수행할 수 있습니다. 이를 통해 인증서 발급, 갱신, 적용 과정을 단순화하고, 각 백엔드 서비스는 암호화/복호화 부담에서 벗어나 핵심 비즈니스 로직 처리에 집중할 수 있게 됩니다. (이는 8.3.1.3에서 더 자세히 다룰 예정입니다.)

이처럼 인그레스는 여러 개의 독립적인 서비스를 마치 하나의 통합된 애플리케이션처럼 외부 사용자에게 효율적으로 제공할 수 있도록 지원함으로써, 인프라 자원의 효율적인 사용을 극대화하고 운영의 복잡성을 크게 낮추는 데 핵심적인 역할을 합니다. 이는 특히 오늘날과 같이 수많은 마이크로서비스로 구성된 복잡하고 동적인 애플리케이션 환경에서 그 가치가 더욱 빛을 발하는 매우 유용한 특징이라고 할 수 있습니다. 따라서 쿠버네티스에서 HTTP(S) 기반 서비스를 외부로 노출할 때는 LoadBalancer 타입의 서비스보다는 인그레스를 우선적으로 고려하는 것이 일반적인 모범 사례로 여겨지고 있습니다.

쿠버네티스에서 서비스를 외부로 노출하는 방법 중 하나인 LoadBalancer 타입의 서비스는 매우 유용하지만, 주로 OSI 7계층 모델의 L4(전송 계층) 수준에서 동작합니다. 이는 주로 IP 주소와 TCP/UDP 포트 번호만을 기준으로 들어오는 트래픽을 백엔드 파드들로 분배하는 역할을 한다는 의미입니다. L4 로드 밸런서는 빠르고 효율적이지만, 애플리케이션 자체의 내용이나 HTTP(S) 프로토콜의 세부적인 정보(예: URL 경로, HTTP 헤더)를 이해하고 이를 기반으로 트래픽을 지능적으로 제어하는 데는 한계가 있습니다.

반면, 인그레스(Ingress)는 OSI 모델의 L7(애플리케이션 계층)에서 동작하며, 바로 이 L4 로드 밸런서의 한계를 극복하고 훨씬 더 정교하며 유연한 로드 밸런싱 및 라우팅 규칙을 제공합니다. 인그레스는 HTTP(S) 프로토콜의 구조와 내용을 깊이 이해하고, 들어오는 각 요청의 헤더 정보(예: 요청된 호스트 이름, 접근하려는 URL 경로, 쿠키, 사용자 에이전트 등)를 분석하여, 이 정보를 바탕으로 어떤 내부 서비스로 트래픽을 전달할지 결정할 수 있는 능력을 갖추고 있습니다. 이는 마치 우편물을 단순히 주소지만 보고 배달하는 것이 아니라, 편지 봉투 안에 적힌 수신 부서나 담당자 이름까지 확인하여 정확한 목적지로 전달하는 것과 같습니다.

인그레스가 제공하는 대표적이면서도 매우 강력한 L7 라우팅 기능은 다음과 같습니다.

이 기능은 동일한 외부 IP 주소와 동일한 포트(일반적으로 HTTP의 경우 80번, HTTPS의 경우 443번)로 여러 개의 서로 다른 웹사이트나 애플리케이션 서비스를 동시에 호스팅할 수 있게 해줍니다. 인그레스 컨트롤러는 들어오는 HTTP 요청의 Host 헤더 값을 확인하여, 이 헤더에 명시된 도메인 이름(예: api.example.com, blog.example.com, shop.example.com)에 따라 요청을 각각 다른 내부 쿠버네티스 서비스로 라우팅합니다.

예를 들어, 다음과 같은 시나리오를 상상해 볼 수 있습니다.

• 사용자가 웹 브라우저에 https://api.example.com/users를 입력하면, 인그레스 컨트롤러는 Host 헤더가 api.example.com인 것을 확인하고 이 요청을 api-service라는 내부 서비스로 전달합니다.
• 다른 사용자가 https://blog.example.com/latest-posts를 입력하면, 인그레스 컨트롤러는 Host 헤더가 blog.example.com인 것을 보고 이 요청을 blog-service라는 다른 내부 서비스로 전달합니다.
• 또 다른 사용자가 https://shop.example.com/products/123을 입력하면, Host 헤더 shop.example.com에 따라 shop-service로 요청이 전달됩니다.이는 마치 하나의 물리적인 웹 서버에서 여러 개의 서로 다른 도메인 이름을 가진 웹사이트들을 동시에 운영하는 전통적인 가상 호스팅 기술과 유사한 개념을 쿠버네티스 환경에서 구현하는 것입니다. 이 기능을 통해 기업은 단일 외부 로드 밸런서와 IP 주소만으로도 여러 부서의 웹사이트, 다양한 마이크로서비스 엔드포인트, 또는 서로 다른 고객사를 위한 애플리케이션 인스턴스들을 효율적으로 관리하고 서비스할 수 있게 됩니다. 이는 IP 주소 자원의 절약뿐만 아니라 DNS 관리의 단순화라는 부수적인 이점도 가져다줍니다.

호스트 기반 라우팅이 서로 다른 도메인 이름을 구분하는 것이라면, 경로 기반 라우팅은 동일한 도메인 이름으로 들어오는 요청이라도 URL의 경로(path) 부분에 따라 요청을 서로 다른 내부 서비스로 분기시키는 기능입니다. 인그레스 컨트롤러는 요청 URL에서 호스트 이름 뒤에 오는 경로 문자열을 분석하고, 미리 정의된 규칙에 따라 가장 적합한 백엔드 서비스를 선택합니다.

예를 들어, www.example.com이라는 단일 호스트 이름을 사용하는 애플리케이션이 있고, 이 애플리케이션은 여러 마이크로서비스로 구성되어 있다고 가정해 봅시다.

• https://www.example.com/api/users 와 같이 /api/users로 시작하는 모든 요청은 사용자 정보를 처리하는 user-api-service로 전달됩니다.
• https://www.example.com/api/products 와 같이 /api/products로 시작하는 모든 요청은 상품 정보를 처리하는 product-api-service로 전달됩니다.
• https://www.example.com/blog/ 와 같이 /blog/로 시작하는 모든 요청은 블로그 콘텐츠를 제공하는 blog-app-service로 전달됩니다.
• 그리고 위 규칙들에 해당하지 않는 https://www.example.com/ (기본 경로 또는 루트 경로) 요청은 메인 웹사이트를 제공하는 main-website-service로 전달될 수 있습니다.이는 마치 대형 쇼핑몰의 안내 데스크에서 고객이 찾고자 하는 물품의 종류(경로)를 듣고, “가전제품은 3층, 의류는 2층, 식품은 지하 1층으로 가세요”라고 각기 다른 매장(서비스)으로 안내하는 것과 같습니다. 이 기능을 통해 개발팀은 하나의 통합된 애플리케이션 도메인 주소 체계 내에서도 각 마이크로서비스들을 기능별로 논리적으로 분리하고, 독립적으로 개발, 배포, 확장할 수 있는 유연성을 확보하게 됩니다. 또한, API 게이트웨이 패턴을 구현하는 데 있어 핵심적인 역할을 수행하기도 합니다.

이러한 정교한 L7 라우팅 기능은 특히 마이크로서비스 아키텍처(MSA)를 채택한 현대적인 애플리케이션 환경에서 그 중요성이 더욱 커집니다. MSA에서는 수많은 작고 독립적인 서비스들이 각자의 고유한 기능과 API 엔드포인트(URL 경로)를 가질 수 있는데, 인그레스는 이러한 개별 서비스들을 외부 사용자에게 일관되고 체계적인 방식으로 노출하는 통합된 관문 역할을 수행합니다. 사용자는 복잡한 내부 서비스 구조를 알 필요 없이, 잘 정의된 외부 URL을 통해 필요한 기능에 접근할 수 있게 되는 것입니다.

뿐만 아니라, 인그레스의 L7 라우팅 기능은 A/B 테스팅, 카나리 배포(Canary Release), 블루/그린 배포(Blue/Green Deployment)와 같이 특정 사용자 그룹이나 특정 비율의 트래픽만을 새로운 버전의 서비스로 점진적으로 전환하여 테스트하거나 배포하는 고급 배포 전략을 구현하는 데도 매우 효과적으로 활용될 수 있습니다. 예를 들어, 특정 HTTP 헤더(예: User-Agent 또는 커스텀 헤더) 값을 기준으로 트래픽을 분기하거나, 요청의 가중치(weight)를 두어 일부 트래픽만 새로운 버전으로 보내는 등의 복잡한 시나리오를 인그레스 규칙과 인그레스 컨트롤러의 기능을 통해 구현할 수 있습니다.

결론적으로, 인그레스가 제공하는 L7 로드 밸런싱 및 라우팅 기능은 단순한 트래픽 전달을 넘어, 애플리케이션의 구조를 반영하고, 사용자 경험을 향상시키며, 배포 전략의 유연성을 높이는 등 쿠버네티스 환경에서 웹 서비스를 운영하는 데 있어 핵심적인 가치를 제공합니다. 이는 쿠버네티스를 단순한 컨테이너 오케스트레이션 도구를 넘어, 지능적인 애플리케이션 딜리버리 플랫폼으로 만들어주는 중요한 요소 중 하나라고 할 수 있습니다.

오늘날 우리가 인터넷을 통해 주고받는 정보의 민감성과 중요성이 그 어느 때보다 강조되면서, 웹 서비스에서의 보안은 선택이 아닌 필수가 되었습니다. 특히 사용자의 개인 정보, 금융 정보, 로그인 자격 증명 등과 같이 민감한 데이터가 오가는 통신은 반드시 암호화되어야 하며, 이를 위해 HTTPS(HyperText Transfer Protocol Secure) 프로토콜이 널리 사용됩니다. HTTPS는 HTTP 통신을 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 암호화함으로써, 데이터가 중간에 가로채이거나 변조되는 것을 방지하고 통신의 기밀성과 무결성을 보장합니다.

쿠버네티스 환경에서 이러한 HTTPS 기반의 안전한 웹 서비스를 제공하고자 할 때, 인그레스(Ingress)는 매우 중요한 역할인 SSL/TLS 종료(Termination) 기능을 제공하여 암호화 통신의 관리 효율성과 시스템 성능을 크게 향상시킬 수 있도록 지원합니다.

SSL/TLS 종료란, 외부 클라이언트(예: 사용자의 웹 브라우저)와 쿠버네티스 클러스터의 진입점 역할을 하는 인그레스 컨트롤러 사이의 네트워크 통신은 암호화된 HTTPS 프로토콜을 사용하지만, 인그레스 컨트롤러와 클러스터 내부의 실제 백엔드 애플리케이션 파드(Pod) 사이의 통신은 암호화되지 않은 일반 HTTP 프로토콜을 사용하도록 구성하는 방식을 의미합니다. 다시 말해, 클라이언트로부터 들어오는 암호화된 HTTPS 트래픽은 인그레스 컨트롤러에서 복호화(decryption)되고, 이 복호화된 HTTP 트래픽이 내부 서비스로 전달됩니다. 반대로, 내부 서비스로부터 나오는 응답은 인그레스 컨트롤러에서 다시 암호화(encryption)되어 클라이언트에게 HTTPS로 전달됩니다. 즉, SSL/TLS 핸드셰이크 및 암호화/복호화와 관련된 모든 부담스러운 작업이 인그레스 컨트롤러 레벨에서 처리되고 종료(terminated)되는 것입니다.

인그레스 컨트롤러에서 SSL/TLS 종료를 수행하는 방식은 다음과 같은 실질적이고 강력한 장점들을 제공합니다.

1. SSL/TLS 인증서의 중앙 집중적 관리:웹사이트나 서비스가 HTTPS 통신을 하기 위해서는 공인된 인증 기관(Certificate Authority, CA)으로부터 발급받은 SSL/TLS 인증서(공개키, 개인키 포함)가 필요합니다. 만약 클러스터 내의 여러 마이크로서비스 각각이 개별적으로 HTTPS를 지원해야 한다면, 각 서비스(또는 파드)마다 별도의 인증서를 설치하고, 주기적으로 갱신하며, 보안 설정을 관리해야 하는 엄청난 운영 부담이 발생합니다.하지만 인그레스를 사용하면, 이러한 모든 서비스에 대한 SSL/TLS 인증서를 인그레스 컨트롤러 한 곳에서 중앙 집중적으로 관리할 수 있습니다. 쿠버네티스는 시크릿(Secret)이라는 특별한 오브젝트를 제공하여 SSL/TLS 인증서와 개인키와 같은 민감한 정보를 안전하게 저장할 수 있도록 하며, 인그레스 리소스 명세의 tls 필드를 통해 이 시크릿을 참조하여 특정 호스트 이름(도메인)에 대한 HTTPS 통신을 활성화할 수 있습니다. 이를 통해 인증서 발급, 배포, 갱신(예: Let’s Encrypt와 cert-manager 통합을 통한 자동 갱신) 등의 관리 작업을 훨씬 더 단순하고 효율적으로 수행할 수 있으며, 인증서 관리 오류로 인한 서비스 중단 위험도 줄일 수 있습니다.
2. 백엔드 애플리케이션 파드의 부담 경감 및 성능 향상:SSL/TLS 핸드셰이크 과정 및 데이터 암호화/복호화 작업은 생각보다 상당한 CPU 연산 자원을 소모합니다. 만약 이러한 작업을 클러스터 내부의 모든 백엔드 애플리케이션 파드들이 직접 수행해야 한다면, 각 파드는 자신의 핵심 비즈니스 로직을 처리하는 데 사용할 수 있는 CPU 자원의 일부를 암호화 연산에 할애해야 하므로 전반적인 애플리케이션 성능 저하로 이어질 수 있습니다.인그레스 컨트롤러에서 SSL/TLS 종료를 수행하면, 이러한 계산 집약적인 암호화 관련 작업을 인그레스 컨트롤러가 전담하게 됩니다. 결과적으로, 실제 애플리케이션 로직을 수행하는 백엔드 파드들은 암호화 관련 부담에서 완전히 벗어나, 오직 자신들의 핵심 기능 처리에만 CPU 자원을 집중할 수 있게 되어 애플리케이션의 응답 속도 및 전체 처리량(throughput) 향상에 긍정적인 영향을 미칠 수 있습니다. 특히 트래픽이 많은 대규모 서비스에서는 이러한 성능상의 이점이 더욱 두드러지게 나타날 수 있습니다.
3. 일관된 SSL/TLS 보안 정책 적용 및 관리 용이성:모든 외부 HTTPS 트래픽이 인그레스 컨트롤러라는 단일 지점을 통해 클러스터로 유입되므로, 이 지점에서 SSL/TLS 프로토콜 버전(예: TLS 1.2, TLS 1.3 강제), 허용할 암호화 스위트(cipher suite) 목록, HSTS(HTTP Strict Transport Security) 헤더 설정 등과 같은 보안 관련 설정을 일관되게 적용하고 관리하기가 매우 용이해집니다. 각 서비스별로 보안 설정을 개별적으로 관리하는 것보다 훨씬 더 강력하고 통일된 보안 정책을 유지할 수 있으며, 새로운 보안 취약점이 발견되었을 때도 인그레스 컨트롤러 레벨에서 신속하게 대응할 수 있습니다.
4. 최신 프로토콜(HTTP/2, gRPC 등)로의 유연한 전환 지원:일부 고급 인그레스 컨트롤러(예: Nginx Ingress Controller, Traefik, Envoy 기반 컨트롤러 등)는 SSL/TLS 종료 지점에서 클라이언트와는 HTTP/2 또는 gRPC와 같은 최신 고성능 프로토콜로 통신하면서, 내부 백엔드 애플리케이션과는 기존의 HTTP/1.1 프로토콜로 통신하도록 프로토콜 변환(protocol translation)을 지원하기도 합니다. 이를 통해 백엔드 애플리케이션 코드를 크게 변경하지 않고도, 외부 사용자에게는 최신 프로토콜의 장점(예: 멀티플렉싱, 헤더 압축, 서버 푸시 등)을 제공하여 사용자 경험을 향상시킬 수 있는 유연성을 확보할 수 있습니다.

물론, 모든 상황에서 인그레스에서의 SSL/TLS 종료가 최선의 선택은 아닐 수 있습니다. 예를 들어, 클러스터 내부 네트워크의 보안 수준을 신뢰할 수 없거나, 규제 준수 요구사항 등으로 인해 애플리케이션 서버까지의 엔드-투-엔드 암호화(end-to-end encryption)가 반드시 필요한 경우에는 인그레스에서 SSL/TLS 연결을 그대로 통과(pass-through)시키고, 각 백엔드 파드에서 직접 SSL/TLS를 처리하도록 구성해야 합니다. 이러한 방식을 SSL/TLS 패스스루(pass-through)라고 하며, 이 경우 인그레스 컨트롤러는 L4 레벨에서 TCP 트래픽을 단순히 전달하는 역할만 수행하게 됩니다.

하지만 대부분의 일반적인 웹 서비스 시나리오에서는, 인그레스 컨트롤러에서의 SSL/TLS 종료 방식이 운영의 효율성, 성능상의 이점, 그리고 관리의 편의성 측면에서 훨씬 더 많은 장점을 제공합니다. 이는 쿠버네티스 환경에서 HTTPS 기반의 안전하고 효율적인 웹 서비스를 구축하고 운영하는 데 있어 인그레스가 얼마나 중요한 역할을 하는지를 잘 보여주는 예시라고 할 수 있습니다.