3.11. 사용자 관리 로드 밸런서의 서비스


기본 로드 밸런서 대신 사용자 관리 로드 밸런서를 사용하도록 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

중요

사용자 관리 로드 밸런서 구성은 벤더의 로드 밸런서에 따라 다릅니다.

이 섹션의 정보와 예제는 지침용으로만 사용됩니다. 벤더의 로드 밸런서에 대한 자세한 내용은 벤더 설명서를 참조하십시오.

Red Hat은 사용자 관리 로드 밸런서에 대해 다음 서비스를 지원합니다.

  • Ingress 컨트롤러
  • OpenShift API
  • OpenShift MachineConfig API

사용자 관리 로드 밸런서에 대해 이러한 서비스 중 하나 또는 모두를 구성할지 여부를 선택할 수 있습니다. Ingress 컨트롤러 서비스만 구성하는 것은 일반적인 구성 옵션입니다. 각 서비스를 더 잘 이해하려면 다음 다이어그램을 참조하십시오.

그림 3.1. OpenShift Container Platform 환경에서 작동하는 Ingress 컨트롤러를 보여주는 네트워크 워크플로의 예

OpenShift Container Platform 환경에서 작동하는 Ingress 컨트롤러의 네트워크 워크플로 예제를 보여주는 이미지입니다.

그림 3.2. OpenShift Container Platform 환경에서 작동하는 OpenShift API를 보여주는 네트워크 워크플로우의 예

OpenShift Container Platform 환경에서 작동하는 OpenShift API의 네트워크 워크플로 예제를 보여주는 이미지입니다.

그림 3.3. OpenShift Container Platform 환경에서 작동하는 OpenShift MachineConfig API를 보여주는 네트워크 워크플로우의 예

OpenShift Container Platform 환경에서 작동하는 OpenShift MachineConfig API의 네트워크 워크플로 예제를 보여주는 이미지입니다.

사용자 관리 로드 밸런서에 대해 지원되는 구성 옵션은 다음과 같습니다.

  • 노드 선택기를 사용하여 Ingress 컨트롤러를 특정 노드 세트에 매핑합니다. 이 세트의 각 노드에 고정 IP 주소를 할당하거나 DHCP(Dynamic Host Configuration Protocol)에서 동일한 IP 주소를 수신하도록 각 노드를 구성해야 합니다. 인프라 노드는 일반적으로 이러한 유형의 구성을 수신합니다.
  • 서브넷의 모든 IP 주소를 대상으로 지정합니다. 이 구성은 로드 밸런서 대상을 재구성하지 않고 해당 네트워크 내에서 노드를 생성하고 삭제할 수 있으므로 유지 관리 오버헤드를 줄일 수 있습니다. /27 또는 /28 과 같은 작은 네트워크에 머신 세트를 사용하여 Ingress Pod를 배포하는 경우 로드 밸런서 대상을 단순화할 수 있습니다.

    작은 정보

    머신 구성 풀의 리소스를 확인하여 네트워크에 존재하는 모든 IP 주소를 나열할 수 있습니다.

OpenShift Container Platform 클러스터에 대한 사용자 관리 로드 밸런서를 구성하기 전에 다음 정보를 고려하십시오.

  • 프런트 엔드 IP 주소의 경우 프런트 엔드 IP 주소, Ingress 컨트롤러의 로드 밸런서 및 API 로드 밸런서에 동일한 IP 주소를 사용할 수 있습니다. 이 기능에 대해서는 벤더의 설명서를 확인하십시오.
  • 백엔드 IP 주소의 경우 사용자 관리 로드 밸런서의 수명 동안 OpenShift Container Platform 컨트롤 플레인 노드의 IP 주소가 변경되지 않아야 합니다. 다음 작업 중 하나를 완료하여 이 작업을 수행할 수 있습니다.

    • 각 컨트롤 플레인 노드에 고정 IP 주소를 할당합니다.
    • 노드가 DHCP 리스를 요청할 때마다 DHCP에서 동일한 IP 주소를 수신하도록 각 노드를 구성합니다. 공급 업체에 따라 DHCP 리스를 IP 예약 또는 정적 DHCP 할당의 형태로 될 수 있습니다.
  • Ingress 컨트롤러 백엔드 서비스의 사용자 관리 로드 밸런서에서 Ingress 컨트롤러를 실행하는 각 노드를 수동으로 정의합니다. 예를 들어 Ingress 컨트롤러가 정의되지 않은 노드로 이동하는 경우 연결 중단이 발생할 수 있습니다.

3.11.1. 사용자 관리 로드 밸런서 구성

기본 로드 밸런서 대신 사용자 관리 로드 밸런서를 사용하도록 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

중요

사용자 관리 로드 밸런서를 구성하기 전에 "사용자 관리 로드 밸런서의 서비스" 섹션을 읽으십시오.

사용자 관리 로드 밸런서에 대해 구성할 서비스에 적용되는 다음 사전 요구 사항을 읽으십시오.

참고

클러스터에서 실행되는 MetalLB는 사용자 관리 로드 밸런서로 작동합니다.

OpenShift API 사전 요구 사항

  • 프런트 엔드 IP 주소를 정의했습니다.
  • TCP 포트 6443 및 22623은 로드 밸런서의 프런트 엔드 IP 주소에 노출됩니다. 다음 항목을 확인합니다.

    • 포트 6443은 OpenShift API 서비스에 대한 액세스를 제공합니다.
    • 포트 22623은 노드에 Ignition 시작 구성을 제공할 수 있습니다.
  • 프런트 엔드 IP 주소와 포트 6443은 OpenShift Container Platform 클러스터 외부의 위치로 시스템의 모든 사용자가 연결할 수 있습니다.
  • 프런트 엔드 IP 주소와 포트 22623은 OpenShift Container Platform 노드에서만 연결할 수 있습니다.
  • 로드 밸런서 백엔드는 포트 6443 및 22623의 OpenShift Container Platform 컨트롤 플레인 노드와 통신할 수 있습니다.

Ingress 컨트롤러 사전 요구 사항

  • 프런트 엔드 IP 주소를 정의했습니다.
  • TCP 포트 443 및 80은 로드 밸런서의 프런트 엔드 IP 주소에 노출됩니다.
  • 프런트 엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터 외부에 있는 위치로 시스템의 모든 사용자가 연결할 수 있습니다.
  • 프런트 엔드 IP 주소, 포트 80 및 포트 443은 OpenShift Container Platform 클러스터에서 작동하는 모든 노드에 연결할 수 있습니다.
  • 로드 밸런서 백엔드는 포트 80, 443, 1936에서 Ingress 컨트롤러를 실행하는 OpenShift Container Platform 노드와 통신할 수 있습니다.

상태 점검 URL 사양의 사전 요구 사항

서비스를 사용할 수 없거나 사용할 수 없는지 결정하는 상태 점검 URL을 설정하여 대부분의 로드 밸런서를 구성할 수 있습니다. OpenShift Container Platform은 OpenShift API, 머신 구성 API 및 Ingress 컨트롤러 백엔드 서비스에 대한 이러한 상태 점검을 제공합니다.

다음 예제에서는 이전에 나열된 백엔드 서비스의 상태 점검 사양을 보여줍니다.

Kubernetes API 상태 점검 사양의 예

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Machine Config API 상태 점검 사양의 예

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Ingress 컨트롤러 상태 점검 사양의 예

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10

프로세스

  1. 포트 6443, 22623, 443 및 80의 로드 밸런서에서 클러스터에 액세스할 수 있도록 HAProxy Ingress 컨트롤러를 구성합니다. 필요에 따라 HAProxy 구성에 있는 여러 서브넷의 IP 주소 또는 단일 서브넷의 IP 주소를 지정할 수 있습니다.

    나열된 서브넷이 있는 HAProxy 구성 예

    # ...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
        bind 192.168.1.100:443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
       bind 192.168.1.100:80
       mode tcp
       balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...

    나열된 여러 서브넷이 있는 HAProxy 구성의 예

    # ...
    listen api-server-6443
        bind *:6443
        mode tcp
          server master-00 192.168.83.89:6443 check inter 1s
          server master-01 192.168.84.90:6443 check inter 1s
          server master-02 192.168.85.99:6443 check inter 1s
          server bootstrap 192.168.80.89:6443 check inter 1s
    
    listen machine-config-server-22623
        bind *:22623
        mode tcp
          server master-00 192.168.83.89:22623 check inter 1s
          server master-01 192.168.84.90:22623 check inter 1s
          server master-02 192.168.85.99:22623 check inter 1s
          server bootstrap 192.168.80.89:22623 check inter 1s
    
    listen ingress-router-80
        bind *:80
        mode tcp
        balance source
          server worker-00 192.168.83.100:80 check inter 1s
          server worker-01 192.168.83.101:80 check inter 1s
    
    listen ingress-router-443
        bind *:443
        mode tcp
        balance source
          server worker-00 192.168.83.100:443 check inter 1s
          server worker-01 192.168.83.101:443 check inter 1s
    
    listen ironic-api-6385
        bind *:6385
        mode tcp
        balance source
          server master-00 192.168.83.89:6385 check inter 1s
          server master-01 192.168.84.90:6385 check inter 1s
          server master-02 192.168.85.99:6385 check inter 1s
          server bootstrap 192.168.80.89:6385 check inter 1s
    
    listen inspector-api-5050
        bind *:5050
        mode tcp
        balance source
          server master-00 192.168.83.89:5050 check inter 1s
          server master-01 192.168.84.90:5050 check inter 1s
          server master-02 192.168.85.99:5050 check inter 1s
          server bootstrap 192.168.80.89:5050 check inter 1s
    # ...

  2. curl CLI 명령을 사용하여 사용자 관리 로드 밸런서 및 해당 리소스가 작동하는지 확인합니다.

    1. 다음 명령을 실행하고 응답을 관찰하여 Kubernetes API 서버 리소스에서 클러스터 머신 구성 API에 액세스할 수 있는지 확인합니다.

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다.

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
    2. 다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성 API에 머신 구성 서버 리소스에 액세스할 수 있는지 확인합니다.

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 다음 명령을 실행하고 출력을 관찰하여 포트 80의 Ingress 컨트롤러 리소스에서 컨트롤러에 액세스할 수 있는지 확인합니다.

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
    4. 다음 명령을 실행하고 출력을 관찰하여 포트 443의 Ingress 컨트롤러 리소스에서 컨트롤러에 액세스할 수 있는지 확인합니다.

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
  3. 사용자 관리 로드 밸런서의 프런트 엔드 IP 주소를 대상으로 하도록 클러스터의 DNS 레코드를 구성합니다. 로드 밸런서를 통해 클러스터 API 및 애플리케이션의 DNS 서버로 레코드를 업데이트해야 합니다.

    수정된 DNS 레코드 예

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    중요

    DNS 전파는 각 DNS 레코드를 사용할 수 있을 때까지 약간의 시간이 걸릴 수 있습니다. 각 레코드를 검증하기 전에 각 DNS 레코드가 전파되는지 확인합니다.

  4. OpenShift Container Platform 클러스터가 사용자 관리 로드 밸런서를 사용하려면 클러스터의 install-config.yaml 파일에 다음 구성을 지정해야 합니다.

    # ...
    platform:
      nutanix:
        loadBalancer:
          type: UserManaged 1
          apiVIPs:
          - <api_ip> 2
          ingressVIPs:
          - <ingress_ip> 3
    # ...
    1
    type 매개변수에 대해 UserManaged 를 설정하여 클러스터의 사용자 관리 로드 밸런서를 지정합니다. 매개변수의 기본값은 기본 내부 로드 밸런서를 나타내는 OpenShiftManagedDefault 입니다. openshift-kni-infra 네임스페이스에 정의된 서비스의 경우 사용자 관리 로드 밸런서는 coredns 서비스를 클러스터의 Pod에 배포할 수 있지만 keepalivedhaproxy 서비스를 무시합니다.
    2
    사용자 관리 로드 밸런서를 지정할 때 필수 매개변수입니다. Kubernetes API가 사용자 관리 로드 밸런서와 통신할 수 있도록 사용자 관리 로드 밸런서의 공용 IP 주소를 지정합니다.
    3
    사용자 관리 로드 밸런서를 지정할 때 필수 매개변수입니다. 사용자 관리 로드 밸런서에서 클러스터의 인그레스 트래픽을 관리할 수 있도록 사용자 관리 로드 밸런서의 공용 IP 주소를 지정합니다.

검증

  1. curl CLI 명령을 사용하여 사용자 관리 로드 밸런서 및 DNS 레코드 구성이 작동하는지 확인합니다.

    1. 다음 명령을 실행하고 출력을 관찰하여 클러스터 API에 액세스할 수 있는지 확인합니다.

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

      구성이 올바르면 응답으로 JSON 오브젝트가 표시됩니다.

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
    2. 다음 명령을 실행하고 출력을 관찰하여 클러스터 머신 구성에 액세스할 수 있는지 확인합니다.

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 다음 명령을 실행하고 출력을 관찰하여 포트의 각 클러스터 애플리케이션에 액세스할 수 있는지 확인합니다.

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
    4. 다음 명령을 실행하고 출력을 관찰하여 포트 443에서 각 클러스터 애플리케이션에 액세스할 수 있는지 확인합니다.

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      구성이 올바르면 명령의 출력에 다음 응답이 표시됩니다.

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.