7장. OpenShift Container Platform의 Ingress 분할

Ingress 컨트롤러 finops-router 는 label selector spec.namespaceSelector.matchLabels.name 을 Thanos 및 ops 로 설정하여 구성됩니다.

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: finops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - finance
          - ops

두 번째 Ingress 컨트롤러 dev-router 는 라벨 선택기 spec.namespaceSelector.matchLabels.name 을 dev 로 설정하여 구성됩니다.

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: dev-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name: dev

모든 애플리케이션 경로가 별도의 네임스페이스에 있는 경우 각각 name:finance,name:ops, name:dev 로 레이블이 지정된 경우 이 구성은 두 Ingress 컨트롤러 간에 경로를 효과적으로 배포합니다. 콘솔, 인증 및 기타 목적을 위한 OpenShift Container Platform 경로는 처리해서는 안 됩니다.

위의 시나리오에서는 분할이 중복된 하위 집합이 없는 특별한 파티션 케이스가 됩니다. 경로는 라우터 shard 간에 나뉩니다.

위의 예에서 finops-router 및 dev-router 외에도, dev 및 ops 로 설정된 라벨 선택기 spec.namespaceSelector.matchLabels.name 으로 구성됩니다.

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: devops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - dev
          - ops

name:dev 및 name:ops 레이블이 지정된 네임스페이스의 경로는 이제 서로 다른 두 개의 Ingress 컨트롤러에서 서비스를 제공합니다. 이 구성을 사용하면 경로가 중복되는 하위 집합이 있습니다.

경로의 중복된 하위 집합을 사용하면 더 복잡한 라우팅 규칙을 생성할 수 있습니다. 예를 들어 전용 finops-router 로 더 높은 우선 순위 트래픽을 전환하면서 더 낮은 우선 순위 트래픽을ECDHE -router 로 전송할 수 있습니다.

새 Ingress shard를 생성한 후 기본 Ingress 컨트롤러에도 적용되는 새 Ingress shard에 적용되는 경로가 있을 수 있습니다. 이는 기본 Ingress 컨트롤러에 선택기가 없고 기본적으로 모든 경로를 허용하기 때문입니다.

네임스페이스 선택기 또는 경로 선택기를 사용하여 특정 라벨을 사용하여 Ingress 컨트롤러를 서비스 경로에서 제한할 수 있습니다. 다음 절차에서는 기본 Ingress 컨트롤러가 네임스페이스 선택기를 사용하여 새로 분할된 Thanos ,ops, dev 경로를 서비스하지 못하도록 제한합니다. 이렇게 하면 Ingress shard에 더 많은 격리가 추가되었습니다.

기본 Ingress 컨트롤러는 더 이상 name:finance,name:ops, name:dev 로 레이블이 지정된 네임스페이스를 제공하지 않습니다.

클러스터 관리자는 프로젝트의 각 라우터에 대해 별도의 DNS 항목을 수행해야 합니다. 라우터는 알 수 없는 경로를 다른 라우터로 전달하지 않습니다.

다음 예제를 고려하십시오.

별도의 DNS 항목은 라우터 A 및 *.example.com 을 라우터 B를 호스팅하는 노드에 *.foo.com 으로 확인해야 합니다.

경로 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 경로 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.

그림 7.1. 경로 라벨을 사용한 Ingress 분할

Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.

네임스페이스 라벨을 사용한 Ingress 컨트롤러 분할이란 Ingress 컨트롤러가 네임스페이스 선택기에서 선택한 모든 네임스페이스의 모든 경로를 제공한다는 뜻입니다.

그림 7.2. 네임스페이스 라벨을 사용한 Ingress 분할

Ingress 컨트롤러 분할은 들어오는 트래픽 부하를 일련의 Ingress 컨트롤러에 균형 있게 분배하고 트래픽을 특정 Ingress 컨트롤러에 격리할 때 유용합니다. 예를 들어, 회사 A는 하나의 Ingress 컨트롤러로, 회사 B는 다른 Ingress 컨트롤러로 이동합니다.