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


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

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

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

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

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

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

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

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

Ingress 컨트롤러의 경우

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

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

18.3.2. 사전 요구 사항

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

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

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

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

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

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

사전 요구 사항

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

프로세스

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

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

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

    $ oc get svc -n myproject

    출력 예

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

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

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

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

프로세스

서비스를 노출하려면 다음을 수행하십시오.

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

    $ oc project myproject
  3. oc expose service 명령을 실행하여 경로를 노출합니다.

    $ oc expose service nodejs-ex

    출력 예

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

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

    1. oc get route 명령을 사용하여 경로의 호스트 이름을 찾습니다.

      $ oc get route

      출력 예

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

    2. cURL을 사용하여 호스트가 GET 요청에 응답하는지 확인합니다.

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

      출력 예

      HTTP/1.1 200 OK
      ...

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

경로 라벨을 사용한 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 라벨이 있는 네임스페이스에서 경로를 선택합니다.

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

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

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

주의

Keepalived Ingress VIP를 배포하는 경우 endpointPublishingStrategy 매개변수에 값이 HostNetwork 인 기본이 아닌 Ingress 컨트롤러를 배포하지 마십시오. 이렇게 하면 문제가 발생할 수 있습니다. endpointPublishingStrategy 에 대해 HostNetwork 대신 NodePort 값을 사용합니다.

프로세스

  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 라벨이 있는 네임스페이스에서 경로를 선택합니다.

18.3.7. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.