검색

8장. OpenShift Container Platform의 Ingress 분할

download PDF

OpenShift Container Platform에서 Ingress 컨트롤러는 모든 경로를 제공하거나 경로 서브 세트를 제공할 수 있습니다. 기본적으로 Ingress 컨트롤러는 클러스터의 모든 네임스페이스에서 생성된 모든 경로를 제공합니다. 선택한 특성을 기반으로 경로의 하위 집합인 shard 를 생성하여 라우팅을 최적화하도록 클러스터에 Ingress 컨트롤러를 추가할 수 있습니다. 경로를 shard의 멤버로 표시하려면 경로 또는 네임스페이스 메타데이터 필드에 라벨을 사용합니다. Ingress 컨트롤러는 선택 표현식 이라고도 하는 선택기 를 사용하여 제공할 전체 경로 풀에서 경로 서브 세트를 선택합니다.

Ingress 분할은 트래픽을 특정 Ingress 컨트롤러로 라우팅하거나 다음 섹션에 설명된 다양한 이유로 트래픽을 분리하려는 경우 여러 Ingress 컨트롤러에서 들어오는 트래픽을 로드 밸런싱하려는 경우에 유용합니다.

기본적으로 각 경로는 클러스터의 기본 도메인을 사용합니다. 그러나 라우터 도메인을 대신 사용하도록 경로를 구성할 수 있습니다. 자세한 내용은 Ingress 컨트롤러 Sharding의 경로 생성 을 참조하십시오.

8.1. Ingress 컨트롤러 분할

라우터 샤딩이라고도 하는 Ingress 샤딩을 사용하여 경로, 네임스페이스 또는 둘 다에 라벨을 추가하여 여러 라우터에 경로 집합을 배포할 수 있습니다. Ingress 컨트롤러는 해당 선택기 세트를 사용하여 지정된 라벨이 있는 경로만 허용합니다. 각 Ingress shard는 지정된 선택 표현식을 사용하여 필터링되는 경로로 구성됩니다.

트래픽이 클러스터로 유입되는 기본 메커니즘으로 Ingress 컨트롤러의 요구 사항이 중요할 수 있습니다. 클러스터 관리자는 다음을 위해 경로를 분할할 수 있습니다.

  • 여러 경로를 통해 Ingress 컨트롤러 또는 라우터를 로드 밸런싱하여 변경에 대한 응답 속도 향상
  • 특정 경로가 나머지 경로와 다른 수준의 신뢰성을 가지도록 할당
  • 특정 Ingress 컨트롤러에 다른 정책을 정의할 수 있도록 허용
  • 특정 경로만 추가 기능을 사용하도록 허용
  • 예를 들어, 내부 및 외부 사용자가 다른 경로를 볼 수 있도록 다른 주소에 다른 경로를 노출
  • 녹색 배포 중에 애플리케이션의 한 버전에서 다른 버전으로 트래픽을 전송합니다.

Ingress 컨트롤러가 분할되면 지정된 경로가 그룹의 0개 이상의 Ingress 컨트롤러에 허용됩니다. 경로 상태는 Ingress 컨트롤러가 승인했는지 여부를 나타냅니다. Ingress 컨트롤러는 해당 shard에 고유한 경우에만 경로를 허용합니다.

Ingress 컨트롤러는 세 가지 분할 방법을 사용할 수 있습니다.

  • 네임스페이스 선택기와 일치하는 라벨이 있는 네임스페이스의 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 네임스페이스 선택기만 추가합니다.
  • 경로 선택기와 일치하는 레이블이 있는 모든 경로가 Ingress shard에 있도록 Ingress 컨트롤러에 경로 선택기만 추가합니다.
  • 네임스페이스 선택기와 경로 선택기를 모두 Ingress 컨트롤러에 추가하여 네임스페이스 선택기와 일치하는 라벨과 일치하는 라벨이 있는 레이블이 있는 경로가 Ingress shard에 있도록 합니다.

샤딩을 사용하면 여러 Ingress 컨트롤러에 경로 서브 세트를 배포할 수 있습니다. 이러한 서브셋은 오버라이프(over-overla)이거나, 기존 샤딩(Sampling)이라고도 하며, 중복되는 분할이라고 할 수 있습니다.

8.1.1. 기존 분할 예

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

finops-router에 대한 YAML 정의의 예

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.namedev 로 설정하여 구성됩니다.

dev-routerYAML 정의의 예

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 간에 나뉩니다.

주의

namespaceSelector 또는 routeSelector 필드에 제외를 위한 경로가 포함되지 않는 한 기본 Ingress 컨트롤러는 모든 경로를 계속 제공합니다. 기본 Ingress 컨트롤러에서 경로를 제외하는 방법에 대한 자세한 내용은 이 Red Hat Knowledgebase 솔루션 및 "기본 Ingress 컨트롤러 삭제" 섹션을 참조하십시오.

8.1.2. 중복된 분할 예

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

ECDHE -router에 대한 YAML정의의 예

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

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

8.1.3. 기본 Ingress 컨트롤러 분할

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

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

중요

모든 OpenShift Container Platform 관리 경로를 동일한 Ingress 컨트롤러에 보관해야 합니다. 따라서 이러한 필수 경로를 제외하는 기본 Ingress 컨트롤러에 추가 선택기를 추가하지 마십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트 관리자로 로그인되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 기본 Ingress 컨트롤러를 수정합니다.

    $ oc edit ingresscontroller -n openshift-ingress-operator default
  2. jaeger ,ops, dev 라벨이 있는 경로를 제외하는 namespaceSelector포함 하도록 Ingress 컨트롤러를 편집합니다.

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
      namespaceSelector:
        matchExpressions:
        - key: type
          operator: NotIn
          values:
          - finance
          - ops
          - dev

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

8.1.4. Ingress 분할 및 DNS

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

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

  • 라우터 A는 호스트 192.168.0.5에 존재하며 *.foo.com 이 있는 경로가 있습니다.
  • 라우터 B는 호스트 192.168.1.9에 있으며 *.example.com 이 있는 경로가 있습니다.

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

  • *.foo.com A IN 192.168.0.5
  • *.example.com A IN 192.168.1.9

8.1.5. 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성

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

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

경로가 속하는 네임스페이스와 관계없이 지정된 경로 선택기와 일치하는 라벨을 제공하는 다른 경로 선택기가 있는 여러 Ingress 컨트롤러를 보여주는 다이어그램

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

프로세스

  1. router-internal.yaml 파일을 다음과 같이 편집합니다.

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        routeSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    # oc apply -f router-internal.yaml

    Ingress 컨트롤러는 type: sharded 라벨이 있는 네임스페이스에서 경로를 선택합니다.

8.1.6. 네임스페이스 라벨을 사용하여 Ingress 컨트롤러 분할 구성

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

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

지정된 네임스페이스 선택기와 일치하는 라벨이 포함된 네임스페이스에 속하는 경로를 제공하는 다른 네임스페이스 선택기가 있는 여러 Ingress 컨트롤러를 보여주는 다이어그램

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

프로세스

  1. router-internal.yaml 파일을 다음과 같이 편집합니다.

    # cat router-internal.yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        namespaceSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""

  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    # oc apply -f router-internal.yaml

    Ingress 컨트롤러는 네임스페이스 선택기에서 선택한 type: sharded 라벨이 있는 네임스페이스에서 경로를 선택합니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.