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

앞서 우리는 인그레스(Ingress) 리소스가 어떻게 단일 IP 주소로 여러 서비스를 노출하고, L7 레벨의 정교한 라우팅 규칙을 정의하며, SSL/TLS 종료와 같은 중요한 기능을 수행하는지 살펴보았습니다. 하지만 여기서 한 가지 중요한 질문이 생깁니다. 우리가 YAML 파일로 정의한 이 인그레스 리소스의 ‘규칙’들은 과연 누가, 어떻게 실제로 해석하고 적용하여 외부 트래픽을 처리하는 걸까요? 인그레스 리소스 자체는 단지 우리가 “이러한 방식으로 트래픽을 처리해 달라”고 선언한 명세서일 뿐, 그 자체로 네트워크 트래픽을 직접 다루는 능력을 가지고 있지는 않습니다.

바로 이 지점에서 인그레스 컨트롤러(Ingress Controller)라는 핵심적인 컴포넌트가 등장합니다. 인그레스 컨트롤러는 쿠버네티스 클러스터 내에서 실행되면서, API 서버를 통해 인그레스 리소스의 변경 사항을 지속적으로 감시하고, 이 리소스에 정의된 규칙들을 실제 네트워크 트래픽 라우팅 로직으로 변환하여 적용하는 역할을 수행하는 일종의 ‘실행 엔진’ 또는 ‘번역가’와 같습니다. 마치 우리가 작성한 건축 설계도(인그레스 리소스)를 보고 실제로 건물을 짓는 시공사(인그레스 컨트롤러)와 같은 존재라고 생각할 수 있습니다.

인그레스 컨트롤러가 없다면, 우리가 아무리 멋진 인그레스 리소스를 만들어도 그것은 단지 종이 위의 계획에 불과하며, 외부 트래픽은 클러스터 내부의 서비스로 전달될 수 없습니다. 따라서 쿠버네티스 클러스터에서 인그레스를 사용하기 위해서는 반드시 하나 이상의 인그레스 컨트롤러가 설치되고 실행 중이어야 합니다.

쿠버네티스에서 인그레스(Ingress) 리소스는 클러스터 외부에서 들어오는 HTTP(S) 트래픽을 내부 서비스로 어떻게 라우팅할지에 대한 ‘규칙의 집합’ 또는 ‘선언적 명세’를 정의합니다. 하지만 이 인그레스 리소스 자체는 마치 잘 작성된 건축 설계도와 같아서, 그 자체만으로는 실제 건물을 지을 수 없습니다. 이 설계도에 담긴 지시사항들을 실제로 해석하고, 그에 따라 벽돌을 쌓고 창문을 다는 등의 구체적인 작업을 수행하여 건물을 완성하는 시공사가 필요한 것처럼, 인그레스 리소스에 정의된 라우팅 규칙들을 실제로 네트워크 트래픽에 적용하여 원하는 동작을 구현하는 핵심적인 실행 주체가 바로 인그레스 컨트롤러(Ingress Controller)입니다.

인그레스 컨트롤러의 가장 기본적인 역할은 한마디로 쿠버네티스 API 서버를 통해 인그레스 리소스의 생성, 변경, 삭제와 같은 모든 이벤트를 지속적으로 감시(watch)하고, 이 리소스에 명시된 라우팅 규칙, 호스트 이름 설정, TLS(SSL) 구성 정보 등을 자신이 내부적으로 관리하는 실제 로드 밸런서(예: Nginx, HAProxy, Envoy 등)의 설정으로 동적으로 변환하여 적용함으로써, 외부 트래픽이 선언된 규칙에 따라 올바르게 처리되도록 보장하는 것입니다. 이 일련의 과정은 일반적으로 다음과 같은 정교한 단계들을 거쳐 이루어집니다.

1. 인그레스 리소스의 지속적인 감시 (Watching Ingress Resources):인그레스 컨트롤러는 쿠버네티스 클러스터 내에서 데몬셋(DaemonSet)이나 디플로이먼트(Deployment) 형태로 실행되는 하나 이상의 파드(Pod)로 구성됩니다. 이 컨트롤러 파드들은 시작과 동시에 쿠버네티스 API 서버에 접속하여, 클러스터 내에 생성되거나, 내용이 수정되거나, 또는 삭제되는 모든 인그레스 리소스 객체들의 변경 사항을 실시간으로 감시하는 ‘워치(watch)’ 메커니즘을 설정합니다. 이를 통해 인그레스 컨트롤러는 항상 최신의 인그레스 규칙 정보를 유지할 수 있습니다.최신 쿠버네티스 버전에서는 spec.ingressClassName 필드를 사용하여 특정 인그레스 컨트롤러가 어떤 인그레스 리소스들을 담당할지 명시적으로 지정할 수 있습니다. 이를 통해 클러스터 내에 여러 종류의 인그레스 컨트롤러가 공존하면서 각자의 역할을 수행하는 것도 가능해집니다. 인그레스 컨트롤러는 자신이 담당해야 할 ingressClassName을 가진 인그레스 리소스만을 선택적으로 처리하게 됩니다.
2. 라우팅 규칙 및 TLS 구성의 정밀한 해석 (Parsing Rules and TLS Configuration):새로운 인그레스 리소스가 API 서버를 통해 감지되거나 기존 리소스의 내용이 변경되면, 인그레스 컨트롤러는 해당 리소스의 spec 필드에 정의된 복잡한 규칙들을 상세하게 파싱하고 해석합니다. 여기에는 다음과 같은 정보들이 포함될 수 있습니다.
   • 호스트 기반 라우팅 규칙: 특정 호스트 이름(예: api.example.com, blog.example.com)으로 들어오는 요청을 처리할 규칙들.
   • 경로 기반 라우팅 규칙: 특정 URL 경로(예: /api/v1, /images, /admin)로 들어오는 요청을 어떤 백엔드 서비스의 어떤 포트로 전달할지에 대한 정의. 경로 매칭 방식(예: 정확히 일치, 접두사 일치, 정규 표현식 사용 등)도 함께 고려됩니다.
   • 기본 백엔드 (Default Backend): 어떤 규칙에도 해당하지 않는 요청을 처리할 기본 서비스 지정.
   • TLS(SSL) 설정: spec.tls 필드에 정의된 호스트 이름들과 해당 호스트에 사용할 TLS 인증서 및 개인키가 저장된 쿠버네티스 시크릿(Secret)의 이름. 이를 통해 HTTPS 통신을 활성화하고 SSL/TLS 종료를 수행할 수 있습니다.
   • 어노테이션(Annotations): 인그레스 리소스의 metadata.annotations 필드를 통해 인그레스 컨트롤러 종류별로 특화된 추가적인 설정(예: 리다이렉션 규칙, 인증 방식, 요청/응답 헤더 조작, 타임아웃 설정, CORS 설정 등)을 지시할 수 있습니다. 인그레스 컨트롤러는 이러한 어노테이션도 함께 해석하여 로드 밸런서 설정에 반영합니다.
3. 내부 백엔드 로드 밸런서 구성의 동적 업데이트 (Dynamically Updating Backend Load Balancer Configuration):해석된 라우팅 규칙과 TLS 구성, 그리고 어노테이션 정보들을 바탕으로, 인그레스 컨트롤러는 자신이 내부적으로 사용하는 실제 로드 밸런싱 엔진(소프트웨어)의 설정을 동적으로 업데이트합니다. 예를 들어, 가장 널리 사용되는 Nginx Ingress Controller의 경우, 이 정보들을 기반으로 새로운 Nginx 설정 파일(nginx.conf)을 생성하거나 기존 파일을 수정합니다. 이 설정 파일에는 특정 server 블록(가상 호스트 정의), location 블록(경로 매칭 규칙), upstream 블록(백엔드 서비스의 파드 IP와 포트 목록), SSL/TLS 인증서 경로 지정 등이 포함됩니다. 설정 파일이 변경되면, Nginx Ingress Controller는 Nginx 마스터 프로세스에 시그널을 보내어 설정을 안전하게 다시 로드(graceful reload)하도록 하여, 서비스 중단 없이 새로운 라우팅 규칙이 적용되도록 합니다. 다른 인그레스 컨트롤러들(예: Traefik, HAProxy Ingress, Envoy 기반 컨트롤러)도 각자의 방식(API 호출, 내부 설정 관리 메커니즘 등)으로 이러한 동적 구성 업데이트를 수행합니다.
4. 수신된 외부 트래픽의 지능적인 처리 및 라우팅 (Processing and Routing External Traffic):이제 인그레스 컨트롤러 파드(이 파드 자체는 보통 LoadBalancer 타입의 서비스나 NodePort 서비스를 통해 외부 로드 밸런서와 연결되어 외부 트래픽을 수신합니다)로 들어오는 실제 외부 HTTP(S) 요청은, 새롭게 업데이트된 내부 로드 밸런서의 설정을 통해 인그레스 리소스에 정의된 규칙에 따라 적절한 내부 쿠버네티스 서비스로 정확하게 라우팅됩니다. 만약 특정 호스트와 경로에 대해 SSL/TLS 종료가 설정되어 있다면, 인그레스 컨트롤러는 이 단계에서 클라이언트와의 TLS 핸드셰이크를 수행하고, 암호화된 트래픽을 복호화하여 내부 서비스로 전달하며, 내부 서비스로부터의 응답은 다시 암호화하여 클라이언트에게 전송하는 작업을 담당합니다.
5. 백엔드 엔드포인트의 지속적인 추적 및 상태 관리 (Tracking and Managing Backend Endpoints):인그레스 컨트롤러는 단순히 인그레스 리소스에 정의된 정적인 규칙만을 따르는 것이 아닙니다. 인그레스 규칙에서 참조하는 각 백엔드 쿠버네티스 서비스(Service)와, 해당 서비스가 실제로 가리키고 있는 파드들의 IP 주소와 포트 정보가 담긴 엔드포인트(Endpoints) 오브젝트 또는 더 최신 방식인 엔드포인트 슬라이스(EndpointSlices) 오브젝트의 변경 사항도 지속적으로 감시합니다. 만약 특정 서비스의 백엔드 파드 수가 스케일 아웃/인에 따라 변경되거나, 파드가 재시작되어 IP 주소가 바뀌거나, 또는 파드가 비정상 상태가 되어 서비스 엔드포인트 목록에서 제외되면, 인그레스 컨트롤러는 이러한 변화를 즉시 인지하고 자신이 관리하는 내부 로드 밸런서의 업스트림(백엔드) 서버 목록을 실시간으로 업데이트합니다. 이를 통해 항상 건강하고 준비된(Ready) 상태의 파드들로만 트래픽이 지능적으로 전달되도록 보장하며, 서비스의 가용성과 응답성을 높이는 데 기여합니다.

이처럼 인그레스 컨트롤러는 쿠버네티스의 선언적 API 모델(사용자는 “원하는 상태”인 인그레스 리소스를 정의)과 실제 네트워크 트래픽 처리(내부 로드 밸런서가 실제 요청을 라우팅) 사이의 매우 중요한 가교 역할을 수행합니다. 사용자는 복잡한 로드 밸런서 설정이나 동적인 파드 IP 관리에 대해 직접 신경 쓸 필요 없이, 인그레스 리소스를 통해 원하는 L7 라우팅 정책을 선언하기만 하면, 인그레스 컨트롤러가 그 상태를 달성하고 지속적으로 유지하기 위해 필요한 모든 복잡한 작업을 내부적으로 자동화하여 처리해주는 것입니다.

여기서 반드시 기억해야 할 중요한 점은, 쿠버네티스 자체는 기본적으로 어떤 특정한 인그레스 컨트롤러 구현체를 제공하지 않는다는 것입니다. (물론, 일부 관리형 쿠버네티스 서비스나 특정 쿠버네티스 배포판들은 편의를 위해 기본 인그레스 컨트롤러를 사전 설치하여 제공할 수도 있습니다.) 따라서 대부분의 경우, 사용자는 자신의 클러스터 환경, 애플리케이션 요구사항, 성능 목표, 그리고 운영 선호도 등을 고려하여 적합한 인그레스 컨트롤러(예: Nginx Ingress, Traefik, HAProxy Ingress, Contour 등)를 직접 선택하여 클러스터에 설치하고 구성해야 합니다. 만약 클러스터에 어떠한 인그레스 컨트롤러도 설치되어 있지 않다면, 사용자가 인그레스 리소스를 생성하더라도 이는 단지 API 서버에 저장된 선언적인 객체일 뿐, 실제로 외부 트래픽을 처리하거나 라우팅 규칙을 적용하는 어떠한 효과도 발생하지 않습니다. 따라서 인그레스 기능을 활용하기 위한 첫 번째 단계는 바로 적절한 인그레스 컨트롤러를 클러스터에 배포하는 것입니다.

쿠버네티스 생태계에는 다양한 종류의 인그레스 컨트롤러 구현체들이 존재하며, 각각 서로 다른 기반 기술, 특징, 그리고 장단점을 가지고 있습니다. 어떤 인그레스 컨트롤러를 선택하느냐에 따라 인그레스 기능의 범위, 성능, 설정 방법 등이 크게 달라질 수 있으므로, 신중한 선택이 필요합니다. 대표적으로 널리 사용되거나 주목받는 인그레스 컨트롤러들은 다음과 같습니다.

• Nginx Ingress Controller (NGINX 인그레스 컨트롤러):
  • 아마도 가장 널리 사용되고 커뮤니티 지원이 활발한 인그레스 컨트롤러 중 하나일 것입니다. 쿠버네티스 커뮤니티에서 유지보수하는 버전(kubernetes/ingress-nginx)과 NGINX, Inc.에서 직접 지원하는 버전(nginxinc/kubernetes-ingress) 두 가지 주요 구현체가 있습니다. (기능과 설정 방식에 약간의 차이가 있을 수 있습니다.)
  • 매우 안정적이고 성능이 뛰어난 웹 서버 및 리버스 프록시 소프트웨어인 NGINX를 기반으로 동작합니다. 인그레스 리소스의 규칙을 NGINX 설정으로 변환하고, NGINX를 통해 실제 트래픽 라우팅 및 로드 밸런싱을 수행합니다.
  • 호스트 기반 라우팅, 경로 기반 라우팅, SSL/TLS 종료, 리다이렉션, 헤더 조작, 인증, 요청 속도 제한 등 NGINX가 제공하는 풍부하고 강력한 기능들을 대부분 활용할 수 있습니다. 커스텀 설정을 위한 어노테이션(annotation)도 다양하게 지원합니다.
  • 오랜 기간 검증된 안정성과 풍부한 기능, 방대한 사용자 커뮤니티 덕분에 많은 프로덕션 환경에서 선호되는 선택지입니다.
• Traefik Proxy (트래픽 프록시, 이전 Traefik Ingress Controller):
  • Traefik Labs에서 개발한 현대적인 HTTP 리버스 프록시 및 로드 밸런서로, 특히 클라우드 네이티브 환경과 마이크로서비스 아키텍처를 위해 설계되었습니다. 쿠버네티스 인그레스 컨트롤러 기능도 강력하게 지원합니다.
  • 자동 서비스 디스커버리 기능이 매우 뛰어납니다. 쿠버네티스 API 서버와 직접 통합되어 인그레스 리소스뿐만 아니라 서비스, 엔드포인트 등의 변경 사항을 실시간으로 감지하고 자신의 라우팅 설정을 동적으로 업데이트합니다. 이 과정에서 별도의 설정 파일 리로드가 거의 필요 없어 매우 빠르고 유연하게 동작합니다.
  • Let’s Encrypt를 통한 자동 SSL/TLS 인증서 발급 및 갱신 기능을 내장하고 있어 HTTPS 설정이 매우 간편합니다. 또한, 다양한 미들웨어(예: 인증, 헤더 조작, 압축 등)를 지원하며, 웹 기반 대시보드를 통해 현재 라우팅 상태와 통계 정보를 쉽게 확인할 수 있습니다.
  • 설정이 비교적 간편하고, 동적인 환경 변화에 빠르게 대응할 수 있으며, 다양한 편의 기능을 제공하여 개발자 친화적인 인그레스 컨트롤러로 평가받습니다.
• HAProxy Ingress Controller (HAProxy 인그레스 컨트롤러):
  • 고성능 TCP/HTTP 로드 밸런서로 잘 알려진 HAProxy를 기반으로 하는 인그레스 컨트롤러입니다.
  • HAProxy 자체의 뛰어난 성능과 안정성, 그리고 다양한 로드 밸런싱 알고리즘 및 세션 지속성(session persistence) 기능 등을 활용할 수 있습니다. TCP 레벨의 로드 밸런싱이 필요한 경우에도 유용하게 사용될 수 있습니다.
  • NGINX Ingress Controller와 유사하게 인그레스 규칙을 HAProxy 설정으로 변환하여 적용하며, 대규모 트래픽 처리나 특정 고급 로드 밸런싱 요구사항이 있는 환경에서 고려될 수 있습니다.
• Envoy 기반 인그레스 컨트롤러 (예: Contour, Ambassador/Emissary-ingress, Istio Ingress Gateway):
  • Lyft에서 개발하고 CNCF의 Graduated 프로젝트가 된 Envoy Proxy는 고성능, 고확장성의 L7 프록시 및 통신 버스입니다. Istio, App Mesh와 같은 서비스 메쉬의 데이터 플레인으로 널리 사용되며, 이를 기반으로 하는 여러 인그레스 컨트롤러 구현체들이 있습니다.
    • Contour: VMware에서 주도하는 Envoy 기반 인그레스 컨트롤러로, 동적 구성 업데이트와 안전한 멀티테넌시 지원에 중점을 둡니다.
    • Ambassador (현 Emissary-ingress): Datawire에서 개발한 API 게이트웨이 기능을 겸하는 Envoy 기반 인그레스 컨트롤러로, 개발자 친화적인 설정 방식과 다양한 인증/인가, 요청 변환 기능 등을 제공합니다.
    • Istio Ingress Gateway: 서비스 메쉬인 Istio의 일부로 제공되는 Envoy 기반 게이트웨이로, Istio의 강력한 트래픽 관리, 보안, 관찰성 기능을 클러스터 외부 트래픽에 대해서도 동일하게 적용할 수 있게 해줍니다.
  • Envoy 기반 컨트롤러들은 일반적으로 매우 유연하고 확장 가능하며, 복잡한 트래픽 관리 시나리오나 서비스 메쉬와의 긴밀한 통합이 필요한 경우에 강력한 선택이 될 수 있습니다.

이 외에도 Kong Ingress Controller (API 게이트웨이 기능 통합), Skipper (HTTP 라우터 및 리버스 프록시) 등 다양한 인그레스 컨트롤러들이 있으며, 각 클라우드 제공업체들도 자사 로드 밸런서 서비스와 통합된 관리형 인그레스 컨트롤러(예: AWS ALB Ingress Controller, Azure Application Gateway Ingress Controller, Google Cloud GKE Ingress)를 제공하기도 합니다.

표 읽는 방법 및 추가 설명:

• 성능은 매우 다양한 요소(하드웨어, 네트워크, 설정, 워크로드 특성 등)에 따라 달라지므로, 위 표는 일반적인 경향을 나타냅니다. 실제 환경에서는 반드시 벤치마킹을 통해 검증해야 합니다.
• Envoy 기반 컨트롤러는 단일 제품이라기보다는 Envoy Proxy를 기반으로 하는 여러 구현체들의 특징을 포괄적으로 설명한 것입니다. 각 개별 컨트롤러(Contour, Emissary-ingress, Istio Ingress Gateway 등)는 세부적인 기능과 설정 방식, 그리고 지향하는 목표에서 차이가 있을 수 있습니다.
• cert-manager는 쿠버네티스에서 Let’s Encrypt와 같은 인증 기관으로부터 SSL/TLS 인증서를 자동으로 발급받고 갱신해주는 매우 유용한 도구입니다. 대부분의 인그레스 컨트롤러는 cert-manager와 잘 통합되어 동작합니다.
• 어노테이션(Annotations): 대부분의 인그레스 컨트롤러는 쿠버네티스 인그레스 리소스의 metadata.annotations 필드를 통해 컨트롤러별 특화된 설정을 적용할 수 있도록 지원합니다. 이를 통해 기본 인그레스 명세만으로는 표현하기 어려운 다양한 고급 기능(예: 리다이렉션, 인증, CORS, 요청/응답 헤더 조작, 타임아웃 설정 등)을 활용할 수 있습니다.

어떤 컨트롤러를 선택할지는 클러스터의 규모, 성능 요구사항, 필요한 기능(예: 특정 인증 방식, 고급 라우팅 규칙, 서비스 메쉬 통합), 운영 편의성, 그리고 팀의 기술적 선호도 등을 종합적으로 고려하여 결정해야 합니다.

쿠버네티스를 처음 접하는 사용자나 로컬에서 빠르게 개발 및 테스트 환경을 구축하고자 하는 개발자에게 있어, CNI 플러그인 선택 및 설치, 스토리지 클래스 설정, 그리고 인그레스 컨트롤러 배포와 같은 초기 클러스터 구성 작업은 상당한 시간과 노력을 요구하는 진입 장벽으로 작용할 수 있습니다. 이러한 사용자의 불편함을 해소하고 쿠버네티스 경험을 훨씬 더 간편하고 직관적으로 만들기 위해 등장한 것이 바로 K3s나 Rancher Desktop과 같은 경량 쿠버네티스 배포판입니다. 이들 도구는 “배터리 포함(batteries-included)” 철학을 바탕으로, 쿠버네티스 클러스터 운영에 필요한 핵심 구성 요소들을 기본적으로 내장하거나 손쉽게 활성화할 수 있도록 지원합니다. 인그레스 컨트롤러 역시 이러한 핵심 구성 요소 중 하나로, 대부분의 경량 배포판에서는 사용자가 별도의 설치나 복잡한 구성 과정 없이도 즉시 인그레스 리소스를 생성하고 강력한 L7 라우팅 기능을 활용할 수 있도록 기본 제공되는 경우가 많습니다.

이러한 내장 인그레스 컨트롤러의 존재는 개발자들이 쿠버네티스 인프라의 세부적인 설정에 얽매이지 않고, 애플리케이션 로직 개발과 쿠버네티스의 핵심 개념 학습에 더 집중할 수 있도록 돕는다는 점에서 매우 큰 의미를 가집니다. 이제 대표적인 경량 쿠버네티스 배포판인 K3s와 Rancher Desktop이 어떤 방식으로 인그레스 컨트롤러를 제공하고 활용하는지 자세히 살펴보겠습니다.

• K3s (케이쓰리에스):
  • SUSE(이전 Rancher Labs)에서 개발한 K3s는 CNCF 인증을 받은 경량 쿠버네티스 배포판으로, 단일 바이너리 형태로 제공되어 설치가 매우 간편하고 리소스 사용량이 현저히 적다는 장점을 가지고 있습니다. 이러한 특성 덕분에 엣지 컴퓨팅 환경, IoT 디바이스, CI/CD 파이프라인 내 임시 클러스터, 그리고 개발자의 로컬 머신 등 다양한 시나리오에서 널리 활용되고 있습니다.
  • K3s는 기본적으로 Traefik Proxy (트래픽 프록시)를 내장 인그레스 컨트롤러로 채택하여 제공합니다. 사용자가 K3s 서버(마스터 노드 역할을 하는 컴포넌트)를 시작하면, 별도의 추가 작업 없이도 Traefik 파드가 클러스터 내의 kube-system 네임스페이스(또는 K3s 버전에 따라 다른 지정된 네임스페이스)에 자동으로 배포되고 실행됩니다. 이렇게 실행된 Traefik 인그레스 컨트롤러는 즉시 클러스터 내에 생성되는 인그레스 리소스들을 감시하고, 해당 리소스에 정의된 라우팅 규칙들을 처리할 준비를 갖추게 됩니다.
  • Traefik Proxy는 현대적인 클라우드 네이티브 환경을 위해 설계된 HTTP 리버스 프록시 및 로드 밸런서로, 다음과 같은 개발자 친화적인 특징들을 가지고 있어 K3s의 간편함과 매우 잘 어울립니다:
    • 동적 구성 업데이트: 쿠버네티스 API 서버와 긴밀하게 통합되어 인그레스, 서비스, 엔드포인트 등의 변경 사항을 실시간으로 감지하고 자신의 라우팅 설정을 매우 빠르게 동적으로 업데이트합니다. 이 과정에서 전통적인 웹 서버처럼 설정 파일을 다시 로드(reload)하는 과정이 거의 필요 없어, 변경 사항이 즉각적으로 반영되고 서비스 중단 가능성이 최소화됩니다.
    • 자동 SSL/TLS 인증서 관리: Let’s Encrypt와 같은 ACME(Automatic Certificate Management Environment) 프로토콜을 지원하는 인증 기관과의 통합을 통해, HTTPS 통신에 필요한 SSL/TLS 인증서를 자동으로 발급받고 주기적으로 갱신하는 기능을 내장하고 있습니다. 이는 HTTPS 설정을 매우 간편하게 만들어줍니다.
    • 사용하기 쉬운 웹 대시보드: 현재 적용된 라우팅 규칙, 서비스 상태, 미들웨어 구성 등을 시각적으로 확인할 수 있는 웹 기반 대시보드를 제공하여 운영 편의성을 높입니다.
  • K3s 사용자는 단순히 인그레스 리소스 YAML 파일을 작성하여 클러스터에 적용하는 것만으로도 즉시 호스트 기반 라우팅이나 경로 기반 라우팅과 같은 L7 로드 밸런싱 기능을 테스트하고 활용할 수 있습니다. 물론, K3s는 유연성을 제공하여 사용자가 원한다면 –no-deploy traefik (또는 유사한) 옵션을 사용하여 기본 Traefik 인그레스 컨트롤러의 배포를 비활성화하고, 이후에 자신이 선호하는 다른 인그레스 컨트롤러(예: Nginx Ingress Controller, Contour 등)를 직접 설치하여 사용할 수도 있습니다. 하지만 대부분의 로컬 개발, 학습, 테스트, 또는 리소스가 제한적인 소규모 엣지 환경에서는 K3s에 내장된 Traefik만으로도 충분히 만족스러운 인그레스 기능을 경험할 수 있습니다.
• Rancher Desktop (랜처 데스크탑):
  • 마찬가지로 SUSE에서 제공하는 오픈소스 데스크탑 애플리케이션인 Rancher Desktop은 Windows, macOS, Linux 운영체제에서 사용자가 클릭 몇 번만으로 손쉽게 로컬 쿠버네티스 개발 환경과 컨테이너 관리 도구를 구축하고 사용할 수 있도록 지원하는 매우 유용한 도구입니다. Docker Desktop의 훌륭한 대안으로 주목받고 있으며, 특히 사용자가 원하는 쿠버네티스 버전을 유연하게 선택할 수 있고, 다양한 컨테이너 런타임(containerd 또는 dockerd/moby)을 지원한다는 점이 큰 장점입니다.
  • Rancher Desktop은 내부적으로 쿠버네티스를 실행하기 위한 백엔드 엔진으로 k3s 엔진 또는 moby/dockerd 엔진 중 하나를 사용자가 선택할 수 있도록 합니다. 이 선택에 따라 내부적으로 사용되는 인그레스 컨트롤러의 종류나 기본 포함 여부가 달라질 수 있습니다.
    • 만약 사용자가 Rancher Desktop에서 k3s 엔진을 사용하도록 설정했다면, 그 동작 방식은 앞서 설명한 K3s와 매우 유사합니다. 즉, Rancher Desktop은 내부적으로 경량 리눅스 가상 머신(VM)을 실행하고, 이 VM 내에서 K3s를 구동하여 쿠버네티스 클러스터를 제공합니다. 따라서 이 경우, K3s의 기본 동작과 마찬가지로 Traefik Proxy가 기본 인그레스 컨트롤러로 포함되어 실행될 가능성이 매우 높습니다. 이를 통해 사용자는 Rancher Desktop에서 쿠버네티스 클러스터를 시작하자마자 별도의 인그레스 컨트롤러 설치나 복잡한 설정 과정 없이 인그레스 리소스를 생성하고 L7 라우팅 기능을 바로 테스트해 볼 수 있습니다.
    • 만약 Rancher Desktop이 moby/dockerd 엔진을 사용하도록 설정되어 있다면 (이는 과거 Docker Desktop이 쿠버네티스를 지원하던 방식과 유사할 수 있습니다), 인그레스 컨트롤러의 종류나 기본 포함 여부는 Rancher Desktop의 구체적인 버전 및 사용자의 추가 설정에 따라 달라질 수 있습니다. 일부 경우에는 Docker Desktop이 과거에 제공했던 자체적인 CNI 및 인그레스 솔루션과 유사한 방식이 사용될 수도 있고, 또는 사용자가 직접 선호하는 인그레스 컨트롤러(예: Nginx Ingress Controller, Traefik 등)를 로컬 클러스터에 추가로 설치해야 할 수도 있습니다. Rancher Desktop은 지속적으로 발전하고 있는 프로젝트이므로, 특정 버전에 대한 정확한 기본 인그레스 컨트롤러 정보는 공식 문서나 릴리스 노트를 통해 확인하는 것이 가장 확실한 방법입니다.
  • Rancher Desktop이 추구하는 핵심 가치는 개발자 편의성 극대화입니다. 어떤 내부 엔진이나 CNI, 인그레스 컨트롤러를 사용하든 간에, 최종 사용자에게는 가능한 한 인프라 구성의 복잡함을 감추고 “바로 사용 가능한(out-of-the-box)” 로컬 쿠버네티스 개발 환경을 제공하는 데 초점을 맞추고 있습니다. 이를 통해 개발자들은 자신의 애플리케이션을 컨테이너화하고, 쿠버네티스 환경에서 배포 및 테스트하는 데 필요한 시간과 노력을 크게 줄일 수 있으며, 쿠버네티스의 다양한 기능들을 보다 쉽고 빠르게 학습하고 경험할 수 있습니다.

결론적으로, K3s나 Rancher Desktop과 같은 사용자 친화적인 경량 쿠버네티스 배포판들은 인그레스 컨트롤러를 기본적으로 내장하거나 매우 손쉽게 활성화할 수 있도록 지원함으로써, 사용자들이 쿠버네티스의 강력한 L7 라우팅 기능을 보다 낮은 진입 장벽으로 접하고 활용할 수 있도록 돕습니다. 이는 특히 쿠버네티스를 처음 배우는 입문자나, 로컬 환경에서 빠르게 프로토타입을 개발하고 테스트해야 하는 개발자들에게 매우 유용한 환경을 제공합니다. 물론, 실제 프로덕션 환경으로 나아가거나 매우 특수한 네트워크 요구사항(예: 초고성능, 특정 보안 규정 준수, 복잡한 트래픽 쉐이핑 등)이 있는 경우에는, 해당 환경의 특성과 요구사항에 맞춰 보다 신중하게 인그레스 컨트롤러를 선택하고, 성능 튜닝 및 보안 강화를 위한 전문적인 구성 작업을 수행하는 과정이 반드시 필요할 것입니다.