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

앞서 우리는 인그레스 컨트롤러가 어떻게 인그레스 리소스에 정의된 규칙들을 실제 네트워크 트래픽 라우팅으로 변환하는지 알아보았습니다. 그렇다면 이 ‘인그레스 리소스’는 과연 어떻게 생겼고, 어떤 정보들을 담고 있을까요? 인그레스 리소스는 쿠버네티스의 다른 오브젝트들과 마찬가지로 YAML(또는 JSON) 형식의 매니페스트 파일을 통해 선언적으로 정의됩니다. 이 파일에는 인그레스의 이름, 레이블과 같은 메타데이터와 함께, 인그레스의 핵심 동작을 규정하는 spec 필드가 포함됩니다.

마치 우리가 여행 계획을 세울 때, 어떤 교통수단을 이용하고(프로토콜), 어떤 도시를 방문하며(호스트), 각 도시에서 어떤 명소를 둘러볼지(경로), 그리고 각 명소에서 무엇을 할지(백엔드 서비스)를 상세히 기록하는 것과 같습니다. 인그레스 리소스는 쿠버네티스에게 “외부에서 이렇게 생긴 HTTP(S) 요청이 들어오면, 저렇게 처리해서 내부의 이 서비스로 보내줘” 라고 구체적인 지시를 내리는 명세서인 셈입니다.

이번 절에서는 인그레스 리소스의 spec 필드에 포함되는 핵심적인 구성 요소들, 특히 트래픽 라우팅 규칙을 정의하는 rules 필드와 HTTPS 통신을 위한 tls 필드에 대해 자세히 살펴보겠습니다. 이를 통해 독자 여러분은 실제로 인그레스 규칙을 어떻게 작성하고 원하는 L7 라우팅 동작을 구현할 수 있는지 이해하게 될 것입니다.

인그레스 리소스의 가장 핵심적인 부분은 바로 spec.rules 필드입니다. 이 필드는 하나 이상의 라우팅 규칙들의 목록을 정의하며, 각 규칙은 특정 조건(예: 호스트 이름, URL 경로)을 만족하는 HTTP(S) 요청을 어떤 내부 쿠버네티스 서비스로 전달할지를 명시합니다. 마치 복잡한 교차로에서 교통 경찰이 각 차량의 목적지를 확인하고 적절한 차선으로 안내하는 것과 같습니다.

각 규칙(rule)은 주로 다음과 같은 하위 필드들로 구성됩니다.

• host 필드 (선택 사항):이 필드는 해당 규칙이 적용될 호스트 이름(도메인 이름)을 지정합니다. 만약 이 필드가 설정되어 있다면, 인그레스 컨트롤러는 들어오는 HTTP 요청의 Host 헤더 값을 확인하여 이 값과 일치하는 경우에만 해당 규칙을 적용합니다.
  • 예를 들어, host: foo.bar.com으로 설정하면, foo.bar.com이라는 도메인으로 들어오는 요청에 대해서만 이 규칙이 적용됩니다.
  • 와일드카드 호스트 이름(예: *.foo.com)도 일부 인그레스 컨트롤러에서 지원될 수 있지만, 이는 컨트롤러의 구현에 따라 다릅니다. (표준 인그레스 명세 자체는 와일드카드를 명시적으로 지원하지 않지만, Nginx Ingress Controller 등은 이를 해석하여 지원합니다.)
  • 만약 host 필드가 생략되거나 * (모든 호스트를 의미하는 특수 값, 일부 컨트롤러에서 지원)로 설정되면, 해당 규칙은 IP 주소로 직접 들어오거나 어떤 호스트 이름으로 들어오든 모든 요청에 대해 적용될 수 있습니다 (단, 다른 host가 명시된 규칙이 우선적으로 매칭될 수 있습니다).
• http 필드:host 필드와 함께 사용되며 (또는 host 없이 단독으로 사용될 수도 있음), 해당 호스트(또는 모든 호스트)에 대한 HTTP 기반의 라우팅 규칙들을 정의합니다. 이 필드 아래에는 paths라는 배열이 위치하며, 각 path 항목은 특정 URL 경로에 대한 라우팅 동작을 기술합니다.
  • paths 배열: 하나 이상의 경로 기반 라우팅 규칙을 포함합니다. 각 규칙은 다음 필드들로 구성됩니다.
    • path 필드 (필수): 요청 URL의 경로 부분을 지정합니다. 이 경로와 일치하는 요청이 해당 규칙의 대상이 됩니다. 경로 매칭 방식은 아래 pathType 필드에 의해 결정됩니다.
      • 예를 들어, /testpath, /app1/api, / (루트 경로) 등을 지정할 수 있습니다.
    • pathType 필드 (필수, 쿠버네티스 v1.18+): path 필드가 어떻게 해석되고 매칭될지를 정의합니다. 주요 값은 다음과 같습니다.
      • Exact: path 필드에 지정된 문자열과 요청 URL 경로가 정확히 일치해야 합니다. 대소문자를 구분합니다. 예를 들어, path: /foo, pathType: Exact는 /foo 요청에만 매칭되고, /foo/나 /foo/bar에는 매칭되지 않습니다.
      • Prefix: path 필드에 지정된 문자열이 요청 URL 경로의 접두사(prefix)와 일치해야 합니다. 경로 구분자 /를 기준으로 매칭되며, 대소문자를 구분합니다. 예를 들어, path: /foo, pathType: Prefix는 /foo, /foo/, /foo/bar 요청에 모두 매칭됩니다. 가장 일반적으로 사용되는 타입입니다.
      • ImplementationSpecific (기본값, 이전 버전 호환성): 이 타입을 사용하면 경로 매칭 방식은 전적으로 인그레스 컨트롤러의 구현에 따라 달라집니다. 따라서 예측 가능한 동작을 위해서는 Exact나 Prefix를 명시적으로 사용하는 것이 권장됩니다. 이전 버전의 인그레스 리소스에서는 이 타입이 기본이었으며, Nginx Ingress Controller 등은 이를 정규 표현식 또는 접두사 매칭으로 해석하기도 했습니다.
    • backend 필드 (필수): 해당 경로로 들어온 요청을 어떤 내부 쿠버네티스 서비스로 전달할지를 정의합니다. 이 필드 아래에는 다음과 같은 하위 필드들이 위치합니다.
      • service 필드 (필수, 쿠버네티스 v1.20+ 에서는 service.name과 service.port 대신 resource 필드를 사용할 수도 있음):
        • name 필드 (필수): 트래픽을 전달할 대상 쿠버네티스 서비스의 이름을 지정합니다.
        • port 필드 (필수): 대상 서비스가 노출하는 포트 중 어떤 포트로 트래픽을 전달할지를 지정합니다. 이 포트는 서비스 명세에 정의된 포트 이름(name) 또는 포트 번호(number)일 수 있습니다.
          • name: 서비스 포트의 이름을 지정합니다 (예: http, web).
          • number: 서비스 포트의 번호를 직접 지정합니다 (예: 80, 8080).

인그레스 규칙 예시:

다음은 호스트 기반 라우팅과 경로 기반 라우팅을 함께 사용하는 인그레스 리소스의 rules 필드 예시입니다.

이처럼 rules 필드를 통해 매우 유연하고 정교하게 HTTP(S) 트래픽을 원하는 내부 서비스로 라우팅할 수 있습니다. 인그레스 컨트롤러는 이러한 규칙들을 순서대로 평가하여 가장 먼저 매칭되는 규칙에 따라 트래픽을 처리합니다. (매칭 우선순위는 인그레스 컨트롤러 구현에 따라 다를 수 있지만, 일반적으로 더 구체적인 경로가 우선합니다.)

오늘날 대부분의 웹 서비스는 HTTPS를 통해 암호화된 통신을 제공하여 사용자의 데이터를 보호하고 서비스의 신뢰도를 높입니다. 인그레스 리소스는 spec.tls 필드를 통해 이러한 HTTPS 통신을 설정하고 관리하는 기능을 제공합니다. 이 필드를 사용하면 특정 호스트 이름에 대해 SSL/TLS 인증서를 적용하고, 인그레스 컨트롤러에서 SSL/TLS 종료(Termination)를 수행하도록 지시할 수 있습니다.

spec.tls 필드는 TLS 설정 객체들의 배열로 구성되며, 각 객체는 다음과 같은 하위 필드들을 가집니다.

• hosts 배열 (선택 사항):이 TLS 설정을 적용할 호스트 이름(도메인 이름)들의 목록을 지정합니다. 여기에 명시된 호스트 이름으로 HTTPS 요청이 들어올 때, 아래 secretName에 지정된 인증서가 사용됩니다.
  • 예를 들어, hosts: [“secure.example.com“, “another.example.org“] 와 같이 여러 호스트를 지정할 수 있습니다.
  • 만약 hosts 필드가 생략되면, 이 TLS 설정은 인그레스 규칙에 정의된 모든 호스트에 적용될 수 있거나 (인그레스 컨트롤러 구현에 따라), 또는 기본 TLS 인증서(default TLS certificate)로 사용될 수 있습니다. (SNI – Server Name Indication를 통해 클라이언트가 요청한 호스트 이름에 맞는 인증서를 선택하여 제공합니다.)
• secretName 필드 (필수):해당 호스트(들)에 사용할 SSL/TLS 인증서와 개인키가 저장된 쿠버네티스 시크릿(Secret) 오브젝트의 이름을 지정합니다.
  • 이 시크릿은 반드시 kubernetes.io/tls 타입이어야 하며, tls.crt (인증서 파일 내용)와 tls.key (개인키 파일 내용)라는 두 개의 키를 가져야 합니다.
  • 인증서는 공인된 인증 기관(CA)으로부터 발급받거나, Let’s Encrypt와 같은 무료 자동화 CA를 통해 발급받을 수 있습니다 (cert-manager와 같은 도구를 사용하면 이 과정을 자동화할 수 있습니다). 또는 자체 서명된 인증서를 테스트 목적으로 사용할 수도 있습니다.
  • 이 시크릿은 인그레스 리소스와 동일한 네임스페이스에 존재해야 합니다.

TLS 설정 예시:

다음은 secure.example.com 호스트에 대해 my-tls-secret이라는 이름의 시크릿에 저장된 TLS 인증서를 사용하도록 설정하는 인그레스 리소스의 tls 필드 예시입니다.

이렇게 tls 필드를 설정하면, 외부 클라이언트가 https://secure.example.com으로 접속할 때 인그레스 컨트롤러는 my-tls-secret에 저장된 인증서를 사용하여 TLS 핸드셰이크를 수행하고 암호화된 통신을 제공합니다. 그리고 인그레스 컨트롤러는 이 암호화된 요청을 복호화하여, 내부의 my-secure-service (보통 HTTP로 리스닝하는)로 전달하게 됩니다. 이것이 바로 “SSL/TLS 종료”입니다.

만약 특정 호스트에 대해 tls 필드가 설정되어 있고, 해당 호스트로 HTTP 요청이 들어오면, 많은 인그레스 컨트롤러는 이를 자동으로 HTTPS로 리다이렉션하는 기능을 제공하기도 합니다 (어노테이션을 통해 제어 가능).

이처럼 인그레스 리소스의 rules 필드와 tls 필드를 적절히 활용하면, 복잡한 웹 애플리케이션의 라우팅 요구사항과 보안 요구사항을 쿠버네티스 환경에서 선언적이고 효율적인 방식으로 관리할 수 있게 됩니다. 이는 클라우드 네이티브 애플리케이션을 위한 강력한 트래픽 관리 솔루션을 제공하는 인그레스의 핵심적인 능력이라고 할 수 있습니다.