28.3. Ingress 컨트롤러를 사용한 수신 클러스터 트래픽 구성


OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있습니다. 이 방법에서는 Ingress 컨트롤러를 사용합니다.

28.3.1. Ingress 컨트롤러 및 경로 사용

Ingress Operator에서는 Ingress 컨트롤러 및 와일드카드 DNS를 관리합니다.

OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하는 가장 일반적인 방법은 Ingress 컨트롤러를 사용하는 것입니다.

Ingress 컨트롤러는 외부 요청을 수락하고 구성된 경로를 기반으로 이러한 요청을 프록시하도록 구성되어 있습니다. 이는 HTTP, SNI를 사용하는 HTTPS, SNI를 사용하는 TLS로 제한되며, SNI를 사용하는 TLS를 통해 작동하는 웹 애플리케이션 및 서비스에 충분합니다.

관리자와 협력하여 구성된 경로를 기반으로 외부 요청을 수락하고 프록시하도록 Ingress 컨트롤러를 구성하십시오.

관리자는 와일드카드 DNS 항목을 생성한 다음 Ingress 컨트롤러를 설정할 수 있습니다. 그러면 관리자에게 문의하지 않고도 엣지 Ingress 컨트롤러로 작업할 수 있습니다.

기본적으로 클러스터의 모든 Ingress 컨트롤러는 클러스터의 모든 프로젝트에서 생성된 경로를 허용할 수 있습니다.

Ingress 컨트롤러의 경우

  • 기본적으로 두 개의 복제본이 있으므로 두 개의 작업자 노드에서 실행되어야 합니다.
  • 더 많은 노드에 더 많은 복제본을 갖도록 확장할 수 있습니다.
참고

이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.

28.3.2. 사전 요구 사항

다음 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

  • 요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다.
  • 클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.

    $ oc adm policy add-cluster-role-to-user cluster-admin username
  • 클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 하나 이상 있고 클러스터 외부의 시스템이 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

28.3.3. 프로젝트 및 서비스 생성

노출하려는 프로젝트 및 서비스가 존재하지 않는 경우 프로젝트를 생성한 다음 서비스를 생성합니다.

프로젝트 및 서비스가 이미 존재하는 경우 서비스 노출 절차로 건너뛰어 경로를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치하고 클러스터 관리자로 로그인합니다.

프로세스

  1. oc new-project 명령을 실행하여 서비스에 대한 새 프로젝트를 생성합니다.

    $ oc new-project <project_name>
  2. oc new-app 명령을 사용하여 서비스를 생성합니다.

    $ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
  3. 서비스가 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get svc -n <project_name>

    출력 예

    NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    nodejs-ex   ClusterIP   172.30.197.157   <none>        8080/TCP   70s

    참고

    기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

28.3.4. 경로를 생성하여 서비스 노출

oc expose 명령을 사용하여 서비스를 경로로 노출할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform에 로그인되어 있습니다.

프로세스

  1. 노출하려는 서비스가 있는 프로젝트에 로그인합니다.

    $ oc project <project_name>
  2. oc expose service 명령을 실행하여 경로를 노출합니다.

    $ oc expose service nodejs-ex

    출력 예

    route.route.openshift.io/nodejs-ex exposed

  3. 서비스가 노출되었는지 확인하려면 curl 과 같은 툴을 사용하여 클러스터 외부에서 서비스에 액세스할 수 있는지 확인할 수 있습니다.

    1. 경로의 호스트 이름을 찾으려면 다음 명령을 입력합니다.

      $ oc get route

      출력 예

      NAME        HOST/PORT                        PATH   SERVICES    PORT       TERMINATION   WILDCARD
      nodejs-ex   nodejs-ex-myproject.example.com         nodejs-ex   8080-tcp                 None

    2. 호스트가 GET 요청에 응답하는지 확인하려면 다음 명령을 입력합니다.

      curl 명령 예

      $ curl --head nodejs-ex-myproject.example.com

      출력 예

      HTTP/1.1 200 OK
      ...

28.3.5. OpenShift Container Platform의 Ingress 분할

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

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

기본적으로 각 경로는 클러스터의 기본 도메인을 사용합니다. 그러나 라우터의 도메인을 대신 사용하도록 경로를 구성할 수 있습니다.

28.3.6. Ingress 컨트롤러 분할

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

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

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

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

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

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

분할을 사용하면 여러 Ingress 컨트롤러에 경로 서브 세트를 배포할 수 있습니다. 이러한 하위 세트는 기존 샤딩이라고도 하는 겹치지 않거나 겹치는 분할이라고 할 수 있습니다.

28.3.6.1. 기존 분할 예

레이블 선택기 spec.namespaceSelector.matchExpressions 가 있는 구성된 Ingress 컨트롤러 finops-router 의 예로, key 값이 financial 및 ops 로 설정되어 있습니다.

finops-router의 YAML 정의 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: finops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - finance
      - ops

선택기 spec.namespaceSelector.matchLabels.name 레이블이 dev 로 설정된 구성된 Ingress 컨트롤러 dev-router 의 예입니다.

dev-router의 YAML 정의 예

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 컨트롤러" 섹션 "기본 Ingress 컨트롤러"를 참조하십시오.

28.3.6.2. 겹치는 분할 예

선택기 spec.namespaceSelector.matchExpressions에 devops 로 설정된 라벨 선택기 spec.namespaceSelector.matchExpressions 가 있는 구성된 Ingress 컨트롤러 Cryostat -router 의 예

CloudEvent -router에 대한 YAML정의의 예

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: devops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: In
      values:
      - dev
      - ops

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

겹치는 경로 하위 집합을 사용하면 더 복잡한 라우팅 규칙을 생성할 수 있습니다. 예를 들어 더 높은 우선순위 트래픽을 CloudEvent-router로 보내는 동안 더 높은 우선 순위 트래픽을 전용 finops -router 로 변환할 수 있습니다.

28.3.6.3. 기본 Ingress 컨트롤러 분할

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

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

중요

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

사전 요구 사항

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

프로세스

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

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

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

기본 Ingress 컨트롤러는 더 이상 name:finance,name:ops, name:dev 라는 이름을 제공하지 않습니다.

28.3.6.4. Ingress 분할 및 DNS

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

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

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

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

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

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

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

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

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

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

프로세스

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

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: sharded
      namespace: openshift-ingress-operator
    spec:
      domain: <apps-sharded.basedomain.example.net> 1
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""
      routeSelector:
        matchLabels:
          type: sharded
    1
    Ingress 컨트롤러에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress 컨트롤러 도메인과 달라야 합니다.
  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    # oc apply -f router-internal.yaml

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

  3. router-internal.yaml 에 구성된 도메인을 사용하여 새 경로를 생성합니다.

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

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

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

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

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

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

프로세스

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

    $ cat router-internal.yaml

    출력 예

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

    1
    Ingress 컨트롤러에서 사용할 도메인을 지정합니다. 이 도메인은 기본 Ingress 컨트롤러 도메인과 달라야 합니다.
  2. Ingress 컨트롤러 router-internal.yaml 파일을 적용합니다.

    $ oc apply -f router-internal.yaml

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

  3. router-internal.yaml 에 구성된 도메인을 사용하여 새 경로를 생성합니다.

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

28.3.6.7. Ingress 컨트롤러 샤딩 경로 생성

경로를 사용하면 URL에서 애플리케이션을 호스팅할 수 있습니다. 이 경우 호스트 이름이 설정되지 않고 경로에서 하위 도메인을 대신 사용합니다. 하위 도메인을 지정하면 경로를 노출하는 Ingress 컨트롤러의 도메인을 자동으로 사용합니다. 여러 Ingress 컨트롤러에서 경로를 노출하는 경우 경로가 여러 URL에서 호스팅됩니다.

다음 절차에서는 hello-openshift 애플리케이션을 예제로 사용하여 Ingress 컨트롤러 샤딩의 경로를 생성하는 방법을 설명합니다.

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

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트 관리자로 로그인되어 있습니다.
  • 포트의 트래픽을 청취하는 HTTP 또는 TLS 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.
  • 샤딩을 위해 Ingress 컨트롤러가 구성되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 hello-openshift 라는 프로젝트를 생성합니다.

    $ oc new-project hello-openshift
  2. 다음 명령을 실행하여 프로젝트에서 Pod를 생성합니다.

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
  3. 다음 명령을 실행하여 hello-openshift 라는 서비스를 생성합니다.

    $ oc expose pod/hello-openshift
  4. hello-openshift-route.yaml 이라는 경로 정의를 생성합니다.

    분할을 위해 생성된 경로에 대한 YAML 정의:

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      labels:
        type: sharded 1
      name: hello-openshift-edge
      namespace: hello-openshift
    spec:
      subdomain: hello-openshift 2
      tls:
        termination: edge
      to:
        kind: Service
        name: hello-openshift

    1
    label 키와 해당 레이블 값은 Ingress 컨트롤러에 지정된 레이블 값과 일치해야 합니다. 이 예에서 Ingress 컨트롤러에는 라벨 키와 값 type: sharded 가 있습니다.
    2
    하위 도메인 필드 값을 사용하여 경로가 노출됩니다. subdomain 필드를 지정하는 경우 호스트 이름을 설정되지 않은 상태로 두어야 합니다. hostsubdomain 필드를 모두 지정하면 경로에서 호스트 필드의 값을 사용하고 subdomain 필드를 무시합니다.
  5. 다음 명령을 실행하여 hello-openshift-route.yaml 을 사용하여 hello-openshift 애플리케이션에 대한 경로를 생성합니다.

    $ oc -n hello-openshift create -f hello-openshift-route.yaml

검증

  • 다음 명령을 사용하여 경로 상태를 가져옵니다.

    $ oc -n hello-openshift get routes/hello-openshift-edge -o yaml

    결과 경로 리소스는 다음과 유사합니다.

    출력 예

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      labels:
        type: sharded
      name: hello-openshift-edge
      namespace: hello-openshift
    spec:
      subdomain: hello-openshift
      tls:
        termination: edge
      to:
        kind: Service
        name: hello-openshift
    status:
      ingress:
      - host: hello-openshift.<apps-sharded.basedomain.example.net> 1
        routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 2
        routerName: sharded 3

    1
    Ingress 컨트롤러 또는 라우터에서 사용하는 호스트 이름에서 경로를 노출합니다. 호스트 필드의 값은 Ingress 컨트롤러에 의해 자동으로 결정되며 해당 도메인을 사용합니다. 이 예에서 Ingress 컨트롤러의 도메인은 < apps-sharded.basedomain.example.net>입니다.
    2
    Ingress 컨트롤러의 호스트 이름입니다.
    3
    Ingress 컨트롤러의 이름입니다. 이 예에서 Ingress 컨트롤러의 이름은 sharded 입니다.
추가 리소스
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.