1.3. 고급 네트워크 구성

1.3.1. 인프라 운영자 테이블에 대한 추가 네트워킹 요구 사항

Infrastructure Operator를 사용하여 베어 메탈 관리 클러스터를 설치할 때 추가 네트워킹 요구 사항은 다음 표를 참조하십시오.

direction프로토콜연결포트(지정된 경우)

단일 노드 OpenShift Container Platform 관리 클러스터의 BMC 인터페이스에 대한 Hub 클러스터 아웃바운드

HTTPS(연결이 끊긴 환경의 HTTP)

OpenShift Container Platform 클러스터를 부팅

443

OpenShift Container Platform 관리 클러스터에서 허브 클러스터로의 아웃 바운드

HTTPS

assistedService 경로를 사용하여 하드웨어 정보를 보고합니다.

443

1.3.2. Submariner 네트워킹 요구 사항 표

Submariner를 사용하는 클러스터에는 세 개의 열린 포트가 필요합니다. 다음 표에서는 사용할 수 있는 포트를 보여줍니다.

direction프로토콜연결포트(지정된 경우)

아웃바운드 및 인바운드

UDP

각 관리형 클러스터

4800

아웃바운드 및 인바운드

UDP

각 관리형 클러스터

4500, 500 및 게이트웨이 노드에서 IPSec 트래픽에 사용되는 다른 모든 포트

인바운드

TCP

각 관리형 클러스터

8080

1.3.3. Hive 테이블에 대한 추가 네트워킹 요구 사항

중앙 인프라 관리 사용을 포함하는 Hive Operator를 사용하여 베어 메탈 관리 클러스터를 설치하는 경우 허브 클러스터와 libvirt 프로비저닝 호스트 간에 계층 2 또는 계층 3 포트 연결을 구성해야 합니다. 이 프로비저닝 호스트에 대한 연결은 Hive를 사용하여 기본 메탈 클러스터를 생성하는 동안 필요합니다. 자세한 내용은 다음 표를 참조하십시오.

direction프로토콜연결포트(지정된 경우)

Hub 클러스터 아웃바운드 및 libvirt 프로비저닝 호스트에 대한 인바운드

IP

베어 메탈 클러스터를 생성할 때 부트스트랩 역할을 하는 libvirt 프로비저닝 호스트에 Hive Operator가 설치된 hub 클러스터를 연결합니다.

 

참고: 이 요구 사항은 설치 시에만 적용되며 Infrastructure Operator와 함께 설치된 클러스터를 업그레이드할 때 필요하지 않습니다.

1.3.4. 호스트된 컨트롤 플레인 네트워킹 요구 사항 테이블 (기술 프리뷰)

호스팅 컨트롤 플레인을 사용하는 경우 HypershiftDeployment 리소스는 다음 표에 나열된 끝점에 연결되어 있어야 합니다.

direction연결포트(지정된 경우)

outbound

OpenShift Container Platform 컨트롤 플레인 및 작업자 노드

 

outbound

Amazon Web Services의 호스트 클러스터만의 경우: AWS API 및 S3 API에 대한 아웃 바운드 연결

 

outbound

Microsoft Azure 클라우드 서비스의 호스팅 클러스터의 경우: Azure API에 대한 아웃 바운드 연결

 

outbound

coreOS의 ISO 이미지와 OpenShift Container Platform Pod용 이미지 레지스트리를 저장하는 OpenShift Container Platform 이미지 리포지토리

 

outbound

호스팅 클러스터의 klusterlet 로컬 API 클라이언트는 HyperShift 호스팅 클러스터의 API와 통신합니다.

 

1.3.5. 애플리케이션 배포 네트워크 요구 사항 표

일반적으로 애플리케이션 배포 통신은 관리 클러스터에서 허브 클러스터로의 한 가지 방법입니다. 연결에서는 관리 클러스터의 에이전트에 의해 구성된 kubeconfig 를 사용합니다. 관리형 클러스터의 애플리케이션 배포는 hub 클러스터의 다음 네임스페이스에 액세스해야 합니다.

  • 채널 리소스의 네임스페이스
  • 관리형 클러스터의 네임스페이스

1.3.6. 네임스페이스 연결 네트워크 요구 사항 표

  • 애플리케이션 라이프사이클 연결:

    • 네임스페이스 open-cluster-management 는 포트 4000의 콘솔 API에 액세스해야 합니다.
    • 네임스페이스 open-cluster-management 는 포트 3001에 애플리케이션 UI를 노출해야 합니다.
  • 애플리케이션 라이프사이클 백엔드 구성 요소(Pod):

    hub 클러스터에서는 다음 Pod를 포함하여 모든 애플리케이션 라이프사이클 Pod가 open-cluster-management 네임스페이스에 설치됩니다.

    • multicluster-operators-hub-subscription
    • multicluster-operators-standalone-subscription
    • multicluster-operators-channel
    • multicluster-operators-application
    • multicluster-integrations

      이러한 Pod가 open-cluster-management 네임스페이스에 있기 때문입니다.

    • 네임스페이스 open-cluster-management 는 포트 6443의 Kube API에 액세스해야 합니다.

    관리형 클러스터에서 klusterlet-addon-appmgr 애플리케이션 라이프사이클 Pod만 open-cluster-management-agent-addon 네임스페이스에 설치됩니다.

    • 네임스페이스 open-cluster-management-agent-addon 은 포트 6443의 Kube API에 액세스해야 합니다.
  • 거버넌스 및 위험:

    hub 클러스터에서는 다음 액세스가 필요합니다.

    • 네임스페이스 open-cluster-management 는 포트 6443의 Kube API에 액세스해야 합니다.
    • 네임스페이스 open-cluster-management 는 포트 5353의 OpenShift DNS에 액세스해야 합니다.

    관리형 클러스터에서는 다음 액세스가 필요합니다.

    • 네임스페이스 open-cluster-management-addon 은 포트 6443의 Kube API에 액세스해야 합니다.