네트워킹
네트워킹에 대해 자세히 알아보려면 자세히 알아보십시오.
초록
1장. 네트워킹
hub 클러스터와 관리 클러스터 둘 다에 대한 네트워크 요구 사항에 대해 알아보십시오.
1.1. hub 클러스터 네트워크 구성
중요: 신뢰할 수 있는 CA 번들은 Red Hat Advanced Cluster Management 네임스페이스에서 사용할 수 있지만 개선 사항을 적용하려면 네트워크를 변경해야 합니다. 신뢰할 수 있는 CA 번들 ConfigMap은 trusted-ca-bundle 의 기본 이름을 사용합니다. TRUSTED_CA_BUNDLE 이라는 환경 변수에서 이 이름을 operator에 제공하여 이름을 변경할 수 있습니다. 자세한 내용은 Red Hat OpenShift Container Platform의 네트워킹 섹션에서 클러스터 전체 프록시 구성을 참조하십시오.
hub 클러스터 네트워크의 구성을 참조할 수 있습니다.
1.1.1. hub 클러스터 네트워크 구성 테이블
다음 표에서 허브 클러스터 네트워크 요구 사항을 참조하십시오.
| direction | 프로토콜 | 연결 | 포트(지정된 경우) | 소스 주소 | 대상 주소 |
|---|---|---|---|---|---|
| 관리형 클러스터의 아웃 바운드 | HTTPS |
Search Console에서 관리되는 클러스터의 Pod로 로그를 동적으로 검색하고 관리 클러스터에서 실행 중인 | 443 | 없음 | 관리형 클러스터 경로에 액세스하기 위한 IP 주소 |
| 관리형 클러스터의 아웃 바운드 | HTTPS | klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버 | 6443 | 없음 | Kubernetes 관리 클러스터 API 서버의 IP |
| 채널 소스에 대한 아웃 바운드 | HTTPS | GitHub, Object Store, Helm 리포지토리를 포함한 채널 소스는 애플리케이션 라이프사이클, OpenShift GitOps 또는 ArgoCD를 사용하여 연결하는 경우에만 필요합니다. | 443 | 없음 | 채널 소스의 IP |
| 관리형 클러스터의 인바운드 | HTTPS | OpenShift Container Platform 버전 4.8 이상을 실행하는 관리형 클러스터에 대해서만 수집된 메트릭 및 경고를 푸시하는 관리형 클러스터 | 443 | 없음 | hub 클러스터 액세스 경로로 IP 주소 |
| 관리형 클러스터의 인바운드 | HTTPS | 관리 클러스터에서 변경 사항을 조사하는 Kubernetes API 서버 허브 클러스터 | 6443 | 없음 | hub 클러스터 Kubernetes API 서버의 IP 주소 |
| ObjectStore에 대한 아웃 바운드 | HTTPS | Cluster Backup Operator가 실행 중일 때 장기 스토리지에 대한 관찰성 지표 데이터를 보냅니다. | 443 | 없음 | ObjectStore의 IP 주소 |
| 이미지 리포지터리의 아웃 바운드 | HTTPS | OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스 | 443 | 없음 | 이미지 리포지토리의 IP 주소 |
1.2. 관리형 클러스터 네트워크 구성
관리형 클러스터 네트워크의 구성을 참조할 수 있습니다.
1.2.1. 관리형 클러스터 네트워크 구성 테이블
다음 표의 관리형 클러스터 네트워크 요구 사항을 참조하십시오.
| direction | 프로토콜 | 연결 | 포트(지정된 경우) | 소스 주소 | 대상 주소 |
|---|---|---|---|---|---|
| hub 클러스터에서 인바운드 | HTTPS |
관리 클러스터의 Pod에 대해 검색 콘솔에서 동적으로 로그를 전송하는 경우 관리 클러스터에서 실행 중인 | 443 | 없음 | 관리형 클러스터 경로에 액세스하기 위한 IP 주소 |
| hub 클러스터에서 인바운드 | HTTPS | klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버 | 6443 | 없음 | Kubernetes 관리 클러스터 API 서버의 IP |
| 이미지 리포지터리의 아웃 바운드 | HTTPS | OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스 | 443 | 없음 | 이미지 리포지토리의 IP 주소 |
| hub 클러스터의 아웃 바운드 | HTTPS | OpenShift Container Platform 버전 4.8 이상을 실행하는 관리형 클러스터에 대해서만 수집된 메트릭 및 경고를 푸시하는 관리형 클러스터 | 443 | 없음 | hub 클러스터 액세스 경로로 IP 주소 |
| hub 클러스터의 아웃 바운드 | HTTPS | hub 클러스터의 Kubernetes API 서버에서 변경 사항을 감시합니다. | 6443 | 없음 | hub 클러스터 Kubernetes API 서버의 IP 주소 |
| 채널 소스에 대한 아웃 바운드 | HTTPS | GitHub, Object Store, Helm 리포지토리를 포함한 채널 소스는 애플리케이션 라이프사이클, OpenShift GitOps 또는 ArgoCD를 사용하여 연결하는 경우에만 필요합니다. | 443 | 없음 | 채널 소스의 IP |
1.3. 고급 네트워크 구성
1.3.1. 인프라 운영자 테이블에 대한 추가 네트워킹 요구 사항
Infrastructure Operator를 사용하여 베어 메탈 관리 클러스터를 설치할 때 추가 네트워킹 요구 사항은 다음 표를 참조하십시오.
| direction | 프로토콜 | 연결 | 포트(지정된 경우) |
|---|---|---|---|
| 단일 노드 OpenShift Container Platform 관리 클러스터의 BMC 인터페이스에 대한 Hub 클러스터 아웃바운드 | HTTPS(연결이 끊긴 환경의 HTTP) | OpenShift Container Platform 클러스터를 부팅 | 443 |
| OpenShift Container Platform 관리 클러스터에서 허브 클러스터로의 아웃 바운드 | HTTPS |
| 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 클러스터 아웃바운드 및 | IP |
베어 메탈 클러스터를 생성할 때 부트스트랩 역할을 하는 |
참고: 이 요구 사항은 설치 시에만 적용되며 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에 액세스해야 합니다.
-
네임스페이스
