
호스트 및 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
을 거부합니다.