Ingress

Ingress

HTTP(또는 HTTPS) 네트워크 서비스를 프로토콜을 인식하는 구성 메커니즘으로 외부에 공개해요. 이 메커니즘은 URI, 호스트명, 경로 같은 웹 개념을 이해하죠. Ingress 개념은 Kubernetes API로 정의한 규칙에 따라 트래픽을 다른 백엔드에 매핑하게 해줘요.

FEATURE STATE: Kubernetes v1.19 [stable]

클러스터 내 서비스에 대한 외부 접근(보통 HTTP)을 관리하는 API 객체예요. Ingress는 로드 밸런싱, SSL 종료, 이름 기반 가상 호스팅을 제공할 수 있어요.

참고: Kubernetes 프로젝트는 Ingress 대신 Gateway를 권장해요. Ingress API는 동결(frozen)됐어요. 즉 Ingress API는 GA이며 안정성 보장을 받지만, 더 이상 개발되지 않고 추가 변경·업데이트가 없을 예정이에요.

용어

• Node: Kubernetes의 워커 머신, 클러스터의 일부.
• Cluster: Kubernetes가 관리하는 컨테이너화된 애플리케이션을 실행하는 노드 집합.
• Edge router: 클러스터의 방화벽 정책을 강제하는 라우터. 클라우드 제공자가 관리하는 게이트웨이 또는 물리 하드웨어일 수 있어요.
• Cluster network: Kubernetes 네트워킹 모델에 따라 클러스터 내 통신을 촉진하는 논리적·물리적 링크 집합.
• Service: 라벨 셀렉터로 Pod 집합을 식별하는 Kubernetes Service.

Ingress란 무엇인가?

Ingress는 클러스터 외부에서 내부 서비스로 HTTP와 HTTPS 경로를 노출해요. 트래픽 라우팅은 Ingress 리소스에 정의된 규칙이 제어해요.

Ingress는 Service에 외부에서 도달 가능한 URL을 제공하고, 트래픽을 로드 밸런싱하고, SSL/TLS를 종료하고, 이름 기반 가상 호스팅을 제공하도록 구성될 수 있어요. Ingress controller가 보통 로드 밸런서로 Ingress를 구현해요.

Ingress는 임의의 포트나 프로토콜을 노출하지 않아요. HTTP/HTTPS가 아닌 서비스를 인터넷에 노출하려면 보통 Service.Type=NodePort나 Service.Type=LoadBalancer를 사용해요.

전제 조건

Ingress를 충족하려면 Ingress controller가 있어야 해요. Ingress 리소스만 만드는 건 효과가 없어요.

Ingress 리소스

최소 Ingress 리소스 예시:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Ingress에는 apiVersion, kind, metadata, spec 필드가 필요해요. ingressClassName을 생략하면 기본 Ingress class가 정의되어 있어야 해요. Ingress controller는 annotations으로 동작을 구성하는 경우가 많아요.

Ingress 규칙

각 HTTP 규칙은 다음 정보를 포함해요.

• 선택적 host. 지정하면 그 host에만 규칙이 적용돼요.
• 각각 연결된 백엔드(service.name과 service.port.name 또는 service.port.number)가 있는 경로 목록(예: /testpath).
• 백엔드는 Service와 포트 이름의 결합 또는 CRD를 통한 custom resource 백엔드예요.

DefaultBackend

규칙이 없는 Ingress는 모든 트래픽을 단일 default backend로 보내고, .spec.defaultBackend가 그 경우 요청을 처리해야 하는 백엔드예요. .spec.rules가 지정되지 않으면 .spec.defaultBackend를 지정해야 해요. host나 path가 어떤 HTTP 요청과도 매칭되지 않으면 트래픽은 default backend로 라우팅돼요.

Resource 백엔드

Resource 백엔드는 Ingress 객체와 같은 네임스페이스에 있는 다른 Kubernetes 리소스에 대한 ObjectRef예요. Service와 상호 배타적이며 둘 다 지정하면 검증 실패해요. 정적 에셋이 있는 객체 스토리지 백엔드에 데이터를 인그레스하는 데 흔히 쓰여요.

경로 유형 (Path types)

Ingress의 각 경로는 해당 경로 유형이 필요해요. 세 가지 유형이 지원돼요.

• ImplementationSpecific: 매칭은 IngressClass에 달려 있음. Prefix나 Exact와 동일하게 취급할 수 있음.
• Exact: URL 경로를 대소문자 구분하여 정확히 매칭.
• Prefix: /로 나눈 URL 경로 접두사에 기반해 매칭. 대소문자 구분, 요소별로 매칭. /foo/bar는 /foo/bar/baz와 매칭되지만 /foo/barbaz와는 매칭되지 않아요.

경로 유형 매칭 예시:

로드 밸런싱

Ingress controller는 모든 Ingress에 적용되는 일부 로드 밸런싱 정책 설정으로 부트스트랩돼요 (알고리즘, 백엔드 가중치 등). 지속 세션, 동적 가중치 같은 고급 개념은 아직 Ingress로 노출되지 않아요. Service에 사용된 로드 밸런서로 얻을 수 있어요. 헬스 체크도 Ingress로 직접 노출되진 않지만, readiness probes 같은 병행 개념으로 같은 결과를 얻을 수 있어요.

Ingress 업데이트

kubectl edit ingress test로 host를 추가하는 방식으로 업데이트할 수 있어요. 저장하면 kubectl이 API server의 리소스를 업데이트하고, Ingress controller가 로드 밸런서를 재구성하도록 지시해요. kubectl replace -f로도 같은 결과를 얻을 수 있어요.

가용 영역에 걸친 장애 처리

장애 도메인에 걸쳐 트래픽을 분산하는 기법은 클라우드 제공자마다 달라요. 관련 Ingress controller 문서를 확인하세요.

대안

Ingress 리소스 없이 Service를 노출하는 방법:

• Service.Type=LoadBalancer 사용
• Service.Type=NodePort 사용

더 알아보기 (Learn more)

• Ingress API
• Ingress controller
• Services