NGINX Ingress Controller Documentation

호스트 및 Listener 충돌 처리

이 문서에서는 Ingress Controller 리소스 간의 호스트 및 Listener 충돌 을 처리하는 방법을 설명합니다.

목차

1. Winner Selection Algorithm
2. 호스트 충돌
2-1. Winner 선택
2-2. 동일한 호스트에 대한 구성 병합
3. Listener 충돌
3-1. Winner 선택

1. Winner Selection Algorithm

여러 리소스가 동일한 호스트/Listener를 놓고 경합하는 경우 Ingress Controller가 생성을 기준으로 승자를 선택합니다. creationTimestamp 가장 오래된 리소스가 승리합니다. 가장 오래된 리소스가 둘 이상인 경우(해당 리소스 creationTimestamp는 동일합니다). Ingress Controller는 사전적으로 uid가 가장 작은 리소스를 선택합니다.

참고: creationTimestamp 및 uid 필드는 리소스 ObjectMeta의 일부입니다.

2. 호스트 충돌

호스트 충돌은 여러 Ingress, VirtualServer 및 TransportServer(TLS Passthrough 용으로 구성됨) 리소스가 동일한 host를 구성할 때 발생합니다. Ingress Controller는 호스트 충돌을 처리하기 위한 두 가지 옵션을 지원합니다.

  • 하나의 리소스만 호스트를 처리하도록 승자를 선택합니다.
  • 충돌하는 리소스의 구성을 병합합니다.

2-1. Winner 선택

다음 두 가지 리소스를 고려해 보십시오:

cafe-ingress Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    . . .

cafe-virtual-server VirtualServer:

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe-virtual-server
spec:
  host: cafe.example.com
  . . .

사용자가 클러스터에서 두 리소스를 모두 생성하면 호스트 충돌이 발생합니다. 결과적으로 Ingress Controller는 Winner Selection Algorithm을 사용하여 Winner를 선택합니다.

이 예에서 cafe-virtual-server가 먼저 생성된 경우 호스트 cafe.example.com을 획득하고 Ingress Controller는 cafe-ingress를 거부합니다. 이는 이벤트 및 리소스의 Status 필드에 반영됩니다.

$ kubectl describe vs cafe-virtual-server
. . .
Status:
  . . .
  Message:  Configuration for default/cafe-virtual-server was added or updated
  Reason:   AddedOrUpdated
  State:    Valid
Events:
  Type    Reason          Age   From                      Message
  ----    ------          ----  ----                      -------
  Normal  AddedOrUpdated  9s    nginx-ingress-controller  Configuration for default/cafe-virtual-server was added or updated

$ kubectl describe ingress cafe-ingress
. . .
Events:
  Type     Reason    Age   From                      Message
  ----     ------    ----  ----                      -------
  Warning  Rejected  66s   nginx-ingress-controller  All hosts are taken by other resources

Note: Ingress 리소스에 대해 여러 호스트를 구성할 수 있습니다. 결과적으로 Ingress 리소스가 일부 호스트의 승자가 되고 다른 호스트의 패자가 될 수 있습니다. 예를 들어 cafe-ingress에 추가 규칙 호스트 규칙(pub.example.com)이 있는 경우 Ingress Controller는 Ingress을 거부하지 않습니다. 오히려 cafe-ingress가 pub.example.com을 처리하도록 허용합니다.

2-2. 동일한 호스트에 대한 구성 병합

동일한 호스트에 대한 여러 Ingress 리소스의 구성을 병합할 수 있습니다. 이 접근 방식의 일반적인 사용 사례 중 하나는 리소스를 여러 Namespaces에 분산하는 것입니다. 자세한 내용은 Cross-Namespaces 구성 문서를 참조하세요.

동일한 호스트에 대한 여러 VirtualServer 리소스의 구성을 병합할 수 없습니다. 그러나 VirtualServer를 단일 VirtualServer가 참조할 수 있는 여러 VirtualServerRoute 리소스로 분할할 수 있습니다. GitHub에서 해당 예제를 참조하십시오.

여러 TransportServer 리소스에 대한 구성을 병합할 수 없습니다.

3. Listener 충돌

Listener 충돌은 여러 TransportServer 리소스(TCP/UDP Load Balancing으로 구성됨)가 동일한 Listener를 구성할 때 발생합니다. Ingress Controller는 Listener를 소유할 승자를 선택합니다.

3-1. Winner 선택

다음 두 가지 리소스를 고려해 보십시오:

tcp-1 TransportServer:

apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
  name: tcp-1
spec:
  listener:
    name: dns-tcp
    protocol: TCP
    . . .

tcp-2 TransportServer:

apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
  name: tcp-2
spec:
  listener:
    name: dns-tcp
    protocol: TCP
    . . .

사용자가 클러스터에서 두 리소스를 모두 생성하면 Listener 충돌이 발생합니다. 결과적으로 Ingress Controller는 Winner Selection Algorithm을 사용하여 Winner를 선택합니다.

이 예에서 tcp-1이 먼저 생성된 경우 Listener dns-tcp를 획득하고 Ingress Controller는 tcp-2를 거부합니다. 이는 이벤트 및 리소스의 상태 필드에 반영됩니다.

$ kubectl describe ts tcp-2
. . .
Events:
  Type     Reason    Age   From                      Message
  ----     ------    ----  ----                      -------
  Warning  Rejected  10s   nginx-ingress-controller  Listener dns-tcp is taken by another resource

마찬가지로 tcp-2가 먼저 생성된 경우 dns-tcp를 획득하고 Ingress Controller는 tcp-1을 거부합니다.