Ingress

Ingress

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

출처: 문서

본문

용어 (Terminology)

이 가이드에서는 명확성을 위해 다음 용어를 정의해요:

• 노드 (Node): Kubernetes의 워커 머신으로, 클러스터의 일부.
• 클러스터 (Cluster): Kubernetes가 관리하는 컨테이너화된 애플리케이션을 실행하는 노드의 집합. 이 예시에서는 그리고 대부분의 일반적인 Kubernetes 배포에서 클러스터의 노드는 공개 인터넷의 일부가 아니에요.
• 엣지 라우터 (Edge router): 클러스터에 대한 방화벽 정책을 강제하는 라우터. 이것은 클라우드 프로바이더가 관리하는 게이트웨이 또는 물리 하드웨어일 수 있어요.
• 클러스터 네트워크 (Cluster network): Kubernetes 네트워킹 모델에 따라 클러스터 내 통신을 돕는 논리적 또는 물리적 링크 집합.
• 서비스 (Service): 레이블 셀렉터를 사용해 파드 집합을 식별하는 Kubernetes Service. 달리 언급되지 않는 한, Service는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가진다고 가정해요.

Ingress란 무엇인가? (What is Ingress?)

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

다음은 Ingress가 모든 트래픽을 하나의 Service로 보내는 간단한 예시예요.

Ingress는 Service에 외부에서 도달 가능한 URL을 제공하고, 트래픽을 로드 밸런싱하고, SSL/TLS를 종료하고, 이름 기반 가상 호스팅을 제공하도록 구성될 수 있어요. Ingress 컨트롤러는 보통 로드 밸런서로 Ingress를 충족시킬 책임이 있으며, 엣지 라우터나 추가 프론트엔드를 구성해 트래픽을 처리하도록 도울 수도 있어요.

Ingress는 임의의 포트나 프로토콜을 노출하지 않아요. HTTP와 HTTPS가 아닌 서비스를 인터넷에 노출하는 것은 일반적으로 Service.Type=NodePort](/docs/concepts/services-networking/service/#type-nodeport) 또는 Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용해요.

전제 조건 (Prerequisites)

Ingress를 충족시키려면 Ingress 컨트롤러가 있어야 해요. Ingress 리소스만 만드는 것은 효과가 없어요.

여러 Ingress 컨트롤러 중에서 선택할 수 있어요.

이상적으로 모든 Ingress 컨트롤러는 참조 사양에 맞아야 해요. 현실에서는 다양한 Ingress 컨트롤러가 약간 다르게 동작해요.

Ingress 리소스 (The Ingress resource)

최소한의 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 필드가 필요해요. Ingress 객체의 이름은 유효한 DNS 하위 도메인 이름이어야 해요. 구성 파일 작업에 대한 일반 정보는 애플리케이션 배포, 컨테이너 구성, 리소스 관리를 참고해요.

Ingress 컨트롤러는 종종 어노테이션을 사용해 동작을 구성해요. 어떤 어노테이션이 예상되고/또는 지원되는지 배우려면 선택한 ingress 컨트롤러의 문서를 검토해요.

Ingress spec은 로드 밸런서나 프록시 서버를 구성하는 데 필요한 모든 정보를 가져요. 가장 중요하게는 모든 수신 요청과 일치시키는 규칙 목록을 포함해요. Ingress 리소스는 HTTP(S) 트래픽을 안내하기 위한 규칙만 지원해요.

ingressClassName이 생략되면 기본 Ingress 클래스가 정의되어야 해요.

일부 ingress 컨트롤러는 기본 IngressClass 정의 없이도 동작해요. 어떤 IngressClass도 없이 동작할 수 있는 ingress 컨트롤러를 사용하더라도, Kubernetes 프로젝트는 여전히 기본 IngressClass를 정의하는 것을 권장해요.

Ingress 규칙 (Ingress rules)

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

• 선택적 호스트(host). 이 예시에서는 호스트가 지정되지 않았으므로 규칙이 지정된 IP 주소를 통한 모든 인바운드 HTTP 트래픽에 적용돼요. 호스트가 제공되면(예: foo.bar.com) 규칙이 그 호스트에 적용돼요.
• 각각이 service.name과 service.port.name 또는 service.port.number로 정의된 백엔드와 연결된 경로 목록(예: /testpath). 로드 밸런서가 트래픽을 참조된 Service로 보내기 전에 호스트와 경로 모두 수신 요청의 내용과 일치해야 해요.
• 백엔드는 Service 문서에서 설명한 대로 Service와 포트 이름의 조합이거나, CRD를 통한 커스텀 리소스 백엔드예요. 규칙의 호스트와 경로와 일치하는 Ingress에 대한 HTTP(및 HTTPS) 요청은 나열된 백엔드로 전송돼요.

defaultBackend는 spec의 경로와 일치하지 않는 모든 요청을 서비스하기 위해 Ingress 컨트롤러에서 자주 구성돼요.

DefaultBackend

규칙이 없는 Ingress는 모든 트래픽을 단일 기본 백엔드로 보내며, 이 경우 .spec.defaultBackend가 요청을 처리해야 하는 백엔드예요. defaultBackend는 관례적으로 Ingress 컨트롤러의 구성 옵션이며 Ingress 리소스에 지정되지 않아요.

.spec.rules가 지정되지 않으면 .spec.defaultBackend가 지정되어야 해요. defaultBackend가 설정되지 않으면 어떤 규칙과도 일치하지 않는 요청의 처리는 ingress 컨트롤러에 달려 있어요(이 경우를 어떻게 처리하는지 알아보려면 ingress 컨트롤러의 문서를 참조해요).

Ingress 객체의 어떤 호스트나 경로도 HTTP 요청과 일치하지 않으면 트래픽이 기본 백엔드로 라우팅돼요.

리소스 백엔드 (Resource backends)

리소스 백엔드는 Ingress 객체와 같은 네임스페이스에 있는 다른 Kubernetes 리소스에 대한 ObjectRef예요. 리소스는 Service와 상호 배타적인 설정이며, 둘 다 지정되면 검증에 실패해요. 리소스 백엔드의 일반적인 용도는 정적 자산이 있는 객체 스토리지 백엔드로 데이터를 수신하는 것이에요.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-resource-backend
spec:
  defaultBackend:
    resource:
      apiGroup: k8s.example.com
      kind: StorageBucket
      name: static-assets
  rules:
    - http:
        paths:
          - path: /icons
            pathType: ImplementationSpecific
            backend:
              resource:
                apiGroup: k8s.example.com
                kind: StorageBucket
                name: icon-assets

위 Ingress를 만든 후 다음 명령으로 확인할 수 있어요:

kubectl describe ingress ingress-resource-backend

Name:             ingress-resource-backend
Namespace:        default
Address:
Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations:  <none>
Events:       <none>

경로 유형 (Path types)

Ingress의 각 경로에는 해당하는 경로 유형이 있어야 해요. 명시적 pathType을 포함하지 않는 경로는 검증에 실패해요. 지원되는 경로 유형은 세 가지가 있어요:

• ImplementationSpecific: 이 경로 유형에서는 일치가 IngressClass에 달려 있어요. 구현은 이것을 별도의 pathType으로 취급하거나 Prefix 또는 Exact 경로 유형과 동일하게 취급할 수 있어요.
• Exact: URL 경로를 정확히 그리고 대소문자를 구분해 일치시켜요.
• Prefix: /로 분리된 URL 경로 접두사에 기반해 일치시켜요. 일치는 대소문자를 구분하며 경로 요소별로 수행돼요. 경로 요소는 / 구분자로 분리된 경로의 레이블 목록을 말해요. 요청이 p와 일치한다는 것은 p의 각 요소가 요청 경로의 요소별 접두사일 때예요. 참고: 경로의 마지막 요소가 요청 경로의 마지막 요소의 하위 문자열이면 일치하지 않아요(예: /foo/bar은 /foo/bar/baz와 일치하지만 /foo/barbaz와는 일치하지 않음).

예시 (Examples)

종류 (Kind)	경로(들)	요청 경로(들)	일치함?
Prefix	/	(모든 경로)	예
Exact	/foo	/foo	예
Exact	/foo	/bar	아니오
Exact	/foo	/foo/	아니오
Exact	/foo/	/foo	아니오
Prefix	/foo	/foo, /foo/	예
Prefix	/aaa/bb	/aaa/bbb	아니오
Prefix	/aaa/bbb	/aaa/bbb	예
Prefix	/aaa/bbb/	/aaa/bbb	예, 후행 슬래시 무시
Prefix	/aaa/bbb	/aaa/bbb/	예, 후행 슬래시 일치
Prefix	/aaa/bbb	/aaa/bbb/ccc	예, 하위 경로 일치
Prefix	/aaa/bbb	/aaa/bbbxyz	아니오, 문자열 접두사 아님
Prefix	/, /aaa	/aaa/ccc	예, /aaa 접두사 일치
Prefix	/, /aaa, /aaa/bbb	/aaa/bbb	예, /aaa/bbb 접두사 일치
Prefix	/, /aaa, /aaa/bbb	/ccc	예, / 접두사 일치
Prefix	/aaa	/ccc	아니오, 기본 백엔드 사용
혼합 (Mixed)	/foo (Prefix), /foo (Exact)	/foo	예, Exact 선호

여러 일치 (Multiple matches)

어떤 경우에는 Ingress 내의 여러 경로가 요청과 일치해요. 그런 경우 가장 긴 일치 경로에 우선순위가 먼저 주어져요. 두 경로가 여전히 동일하게 일치하면 접두사 경로 유형보다 정확한 경로 유형의 경로에 우선순위가 주어져요.

호스트네임 와일드카드 (Hostname wildcards)

호스트는 정확한 일치(예: "foo.bar.com") 또는 와일드카드(예: "*.foo.com")일 수 있어요. 정확한 일치는 HTTP 호스트 헤더가 호스트 필드와 일치해야 해요. 와일드카드 일치는 HTTP 호스트 헤더가 와일드카드 규칙의 접미사와 같아야 해요.

호스트	호스트 헤더	일치함?
*.foo.com	bar.foo.com	공유 접미사에 기반해 일치
*.foo.com	baz.bar.foo.com	일치하지 않음, 와일드카드는 단일 DNS 레이블만 커버
*.foo.com	foo.com	일치하지 않음, 와일드카드는 단일 DNS 레이블만 커버

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

Ingress 클래스 (Ingress class)

Ingress는 종종 다른 구성을 가진 다른 컨트롤러로 구현될 수 있어요. 각 Ingress는 클래스, 즉 그 클래스를 구현해야 하는 컨트롤러의 이름을 포함한 추가 구성을 포함하는 IngressClass 리소스에 대한 참조를 지정해야 해요.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb
spec:
  controller: example.com/ingress-controller
  parameters:
    apiGroup: k8s.example.com
    kind: IngressParameters
    name: external-lb

IngressClass의 .spec.parameters 필드는 그 IngressClass와 관련된 구성을 제공하는 다른 리소스를 참조하게 해줘요.

사용할 parameters의 특정 유형은 IngressClass의 .spec.controller 필드에 지정한 ingress 컨트롤러에 따라 달라져요.

IngressClass 범위 (IngressClass scope)

ingress 컨트롤러에 따라 클러스터 전체 또는 하나의 네임스페이스에 대해서만 설정한 매개변수를 사용할 수 있을 수도 있어요.

• Cluster
• Namespaced

IngressClass 매개변수의 기본 범위는 클러스터 전체예요.

.spec.parameters 필드를 설정하고 .spec.parameters.scope를 설정하지 않거나 .spec.parameters.scope를 Cluster로 설정하면 IngressClass가 클러스터 범위 리소스를 참조해요. 매개변수의 kind(apiGroup과 함께)는 클러스터 범위 API(아마도 커스텀 리소스)를 참조하며, 매개변수의 name은 그 API에 대한 특정 클러스터 범위 리소스를 식별해요.

예를 들어:

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-1
spec:
  controller: example.com/ingress-controller
  parameters:
    # The parameters for this IngressClass are specified in a
    # ClusterIngressParameter (API group k8s.example.net) named
    # "external-config-1". This definition tells Kubernetes to
    # look for a cluster-scoped parameter resource.
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1

<div class="feature-state-notice feature-stable">
  <span class="feature-state-name">Feature state:</span>
  <span class="feature-state-details">
  <span class="feature-state-stage">Stable</span> since Kubernetes v1.23
  </span>
</div>

.spec.parameters 필드를 설정하고 .spec.parameters.scope를 Namespace로 설정하면 IngressClass가 네임스페이스 범위 리소스를 참조해요. 또한 .spec.parameters 내부에 namespace 필드를 사용하려는 매개변수가 포함된 네임스페이스로 설정해야 해요.

매개변수의 kind(apiGroup과 함께)는 네임스페이스 범위 API(예: ConfigMap)를 참조하며, 매개변수의 name은 namespace에서 지정한 네임스페이스의 특정 리소스를 식별해요.

네임스페이스 범위 매개변수는 클러스터 운영자가 워크로드에 사용되는 구성(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임하는 데 도움을 줘요. 클러스터 범위 매개변수를 사용했다면 다음 중 하나가 필요해요:

• 클러스터 운영자 팀이 새 구성 변경이 적용될 때마다 다른 팀의 변경을 승인해야 함.
• 클러스터 운영자가 애플리케이션 팀이 클러스터 범위 매개변수 리소스를 변경할 수 있게 하는 RBAC 역할·바인딩 같은 특정 접근 제어를 정의해야 함.

IngressClass API 자체는 항상 클러스터 범위예요.

다음은 네임스페이스 범위 매개변수를 참조하는 IngressClass의 예시예요:

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-2
spec:
  controller: example.com/ingress-controller
  parameters:
    # The parameters for this IngressClass are specified in an
    # IngressParameter (API group k8s.example.com) named "external-config",
    # that's in the "external-configuration" namespace.
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config

폐기된 어노테이션 (Deprecated annotation)

IngressClass 리소스와 ingressClassName 필드가 Kubernetes 1.18에서 추가되기 전에는 Ingress 클래스가 Ingress의 kubernetes.io/ingress.class 어노테이션으로 지정됐어요. 이 어노테이션은 공식적으로 정의된 적은 없지만 Ingress 컨트롤러에서 널리 지원됐어요.

Ingress의 더 새로운 ingressClassName 필드는 그 어노테이션을 대체하지만 직접적인 동등물은 아니에요. 어노테이션은 일반적으로 Ingress를 구현해야 하는 Ingress 컨트롤러의 이름을 참조하는 데 사용된 반면, 필드는 Ingress 컨트롤러의 이름을 포함한 추가 Ingress 구성을 포함하는 IngressClass 리소스에 대한 참조예요.

기본 IngressClass (Default IngressClass)

특정 IngressClass를 클러스터의 기본값으로 표시할 수 있어요. IngressClass 리소스에서 ingressclass.kubernetes.io/is-default-class 어노테이션을 true로 설정하면 ingressClassName 필드가 지정되지 않은 새 Ingress가 이 기본 IngressClass에 할당되도록 보장해요.

기본 IngressClass를 정의하는 것으로 시작해요. 기본 IngressClass를 지정하는 것이 권장되긴 하지만:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
  name: example-class
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/example-class

Ingress 유형 (Types of Ingress)

단일 Service가 지원하는 Ingress (Ingress backed by a single Service)

단일 Service를 노출할 수 있는 기존 Kubernetes 개념이 있어요(대안(#대안) 참고). 규칙이 없는 기본 백엔드를 지정함으로써 Ingress로도 할 수 있어요.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  defaultBackend:
    service:
      name: test
      port:
        number: 80

kubectl apply -f로 만들면 추가한 Ingress의 상태를 볼 수 있어요:

kubectl get ingress test-ingress

NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
test-ingress   external-lb   *       203.0.113.123   80      59s

여기서 203.0.113.123은 Ingress 컨트롤러가 이 Ingress를 충족시키기 위해 할당한 IP예요.

단순 팬아웃 (Simple fanout)

팬아웃 구성은 요청되는 HTTP URI에 기반해 단일 IP 주소에서 둘 이상의 Service로 트래픽을 라우팅해요. Ingress를 사용하면 로드 밸런서 수를 최소로 유지할 수 있어요. 예를 들어 다음과 같은 설정:

다음과 같은 Ingress가 필요해요:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-fanout-example
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 4200
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 8080

kubectl apply -f로 Ingress를 만들 때:

kubectl describe ingress simple-fanout-example

Name:             simple-fanout-example
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:4200 (10.8.0.90:4200)
               /bar   service2:8080 (10.8.0.91:8080)
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     22s                loadbalancer-controller  default/test

Services(service1, service2)가 존재하는 한 Ingress 컨트롤러는 Ingress를 충족시키는 구현별 로드 밸런서를 프로비저닝해요. 이것이 끝나면 Address 필드에서 로드 밸런서의 주소를 볼 수 있어요.

이름 기반 가상 호스팅 (Name based virtual hosting)

이름 기반 가상 호스트는 같은 IP 주소에서 여러 호스트 이름으로 HTTP 트래픽 라우팅을 지원해요.

다음 Ingress는 백업 로드 밸런서에 Host 헤더에 기반해 요청을 라우팅하라고 지시해요.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: bar.foo.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80

rules에 호스트가 정의되지 않은 Ingress 리소스를 만들면 Ingress 컨트롤러의 IP 주소로의 모든 웹 트래픽이 이름 기반 가상 호스트 없이도 일치될 수 있어요.

예를 들어 다음 Ingress는 first.bar.com을 위해 요청된 트래픽을 service1로, second.bar.com을 service2로, 그리고 요청 호스트 헤더가 first.bar.com과 second.bar.com과 일치하지 않는 모든 트래픽을 service3으로 라우팅해요.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress-no-third-host
spec:
  rules:
  - host: first.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: second.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80
  - http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service3
            port:
              number: 80

TLS

TLS 개인 키와 인증서를 포함하는 Secret을 지정해 Ingress를 보호할 수 있어요. Ingress 리소스는 단일 TLS 포트 443만 지원하며, ingress 지점에서 TLS 종료를 가정해요(Service와 그 파드로의 트래픽은 평문). Ingress의 TLS 구성 섹션이 다른 호스트를 지정하면 SNI TLS 확장을 통해 지정된 호스트네임에 따라 같은 포트에서 다중화돼요(Ingress 컨트롤러가 SNI를 지원하는 경우). TLS secret은 TLS에 사용할 인증서와 개인 키를 포함하는 tls.crt와 tls.key라는 이름의 키를 포함해야 해요. 예:

apiVersion: v1
kind: Secret
metadata:
  name: testsecret-tls
  namespace: default
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
type: kubernetes.io/tls

Ingress에서 이 secret을 참조하면 Ingress 컨트롤러가 TLS로 클라이언트에서 로드 밸런서까지의 채널을 보호하도록 지시해요. 만든 TLS secret이 https-example.foo.com을 위한 CN(Common Name), 즉 FQDN(Fully Qualified Domain Name)을 포함하는 인증서에서 왔는지 확인해야 해요.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
      - https-example.foo.com
    secretName: testsecret-tls
  rules:
  - host: https-example.foo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80

로드 밸런싱 (Load balancing)

Ingress 컨트롤러는 로드 밸런싱 알고리즘, 백엔드 가중치 체계 같은 모든 Ingress에 적용하는 일부 로드 밸런싱 정책 설정으로 부트스트랩돼요. 더 고급 로드 밸런싱 개념(예: 영속 세션, 동적 가중치)은 아직 Ingress를 통해 노출되지 않아요. 대신 Service에 사용되는 로드 밸런서를 통해 이 기능들을 얻을 수 있어요.

또한 헬스 체크가 Ingress를 통해 직접 노출되지는 않지만, 같은 최종 결과를 달성하게 해주는 준비성 프로브 같은 Kubernetes의 병행 개념이 존재한다는 점도 주목할 가치가 있어요. 헬스 체크를 어떻게 처리하는지 알아보려면 컨트롤러별 문서를 검토해주세요.

Ingress 업데이트 (Updating an Ingress)

기존 Ingress를 업데이트해 새 Host를 추가하려면 리소스를 편집해 업데이트할 수 있어요:

kubectl describe ingress test

Name:             test
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:80 (10.8.0.90:80)
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     35s                loadbalancer-controller  default/test

kubectl edit ingress test

이것은 기존 구성을 YAML 형식으로 가진 편집기를 띄워요. 새 Host를 포함하도록 수정해요:

spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          service:
            name: service1
            port:
              number: 80
        path: /foo
        pathType: Prefix
  - host: bar.baz.com
    http:
      paths:
      - backend:
          service:
            name: service2
            port:
              number: 80
        path: /foo
        pathType: Prefix
..

변경 사항을 저장하면 kubectl이 API 서버의 리소스를 업데이트하고, 이것이 Ingress 컨트롤러에 로드 밸런서를 재구성하라고 알려줘요.

이것을 확인해요:

kubectl describe ingress test

Name:             test
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:80 (10.8.0.90:80)
  bar.baz.com
               /foo   service2:80 (10.8.0.91:80)
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     45s                loadbalancer-controller  default/test

수정된 Ingress YAML 파일에서 kubectl replace -f를 호출해 같은 결과를 얻을 수 있어요.

가용성 영역 간 장애 (Failing across availability zones)

장애 도메인 간 트래픽 확산 기술은 클라우드 프로바이더에 따라 달라요. 자세한 내용은 관련 Ingress 컨트롤러의 문서를 확인해주세요.

대안 (Alternatives)

Ingress 리소스를 직접 포함하지 않고 Service를 여러 가지 방법으로 노출할 수 있어요:

• Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer 사용
• Service.Type=NodePort](/docs/concepts/services-networking/service/#type-nodeport 사용

다음 단계 (What's next)

• Ingress API에 대해 배우기
• Ingress 컨트롤러에 대해 배우기

더 알아보기 (Learn more)

• Ingress 컨트롤러 (Ingress Controllers)
• Service (개념)