7.2.4. 사용자 프로비저닝 인프라 생성
사용자 프로비저닝 인프라를 사용하는 OpenShift Container Platform 클러스터를 배포하기 전에 기본 인프라를 생성해야 합니다.
사전 요구 사항
- 클러스터 지원 인프라를 생성하기 전에 OpenShift Container Platform 4.x Tested Integrations 페이지를 확인하십시오.
프로세스
- 각 노드에서 DHCP를 구성하거나 고정 IP 주소를 설정합니다.
- 필요한 로드 밸런서를 프로비저닝합니다.
- 시스템에 사용할 포트를 구성합니다.
- DNS를 구성합니다.
- 네트워크 연결을 확인합니다.
7.2.4.1. 사용자 프로비저닝 인프라에 대한 네트워킹 요구사항
모든 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템이 부팅 중에 시스템 구성 서버에서 Ignition 구성을 가져오려면 initramfs의 네트워크가 필요합니다.
초기 부팅 과정에서 시스템에 Ignition 구성 파일을 다운로드하는 데 필요한 네트워크 연결을 구축하기 위해 클러스터의 각 호스트에 고정 IP 주소를 설정하거나 DHCP 서버가 있어야 합니다.
클러스터의 시스템을 장기간 관리하려면 DHCP 서버를 사용하는 것이 좋습니다. 클러스터 시스템에 영구적 IP 주소와 호스트 이름을 제공하도록 DHCP 서버가 구성되었는지 확인합니다.
Kubernetes API 서버가 클러스터 시스템의 노드 이름을 확인할 수 있어야 합니다. API 서버와 작업자 노드가 서로 다른 영역에 있는 경우, API 서버가 노드 이름을 확인할 수 있도록 기본 DNS 검색 영역을 설정할 수 있습니다. 노드 개체와 모든 DNS 요청에서 항상 정규화된 도메인 이름으로 호스트를 가리키는 것도 지원되는 방법입니다
클러스터 구성 요소가 통신할 수 있도록 시스템 간 네트워크 연결을 구성해야 합니다. 각 시스템에서 클러스터에 있는 다른 모든 시스템의 호스트 이름을 확인할 수 있어야 합니다.
| 프로토콜 | 포트 | 설명 |
|---|---|---|
| ICMP | 해당 없음 | 네트워크 연결성 테스트 |
| TCP |
| 메트릭 |
|
|
| |
|
| Kubernetes에서 예약하는 기본 포트 | |
|
| openshift-sdn | |
| UDP |
| VXLAN 및 Geneve |
|
| VXLAN 및 Geneve | |
|
|
| |
| TCP/UDP |
| Kubernetes 노드 포트 |
| 프로토콜 | 포트 | 설명 |
|---|---|---|
| TCP |
| Kubernetes API |
| 프로토콜 | 포트 | 설명 |
|---|---|---|
| TCP |
| etcd 서버 및 피어 포트 |
네트워크 토폴로지 요구사항
클러스터를 위해 프로비저닝하는 인프라는 다음과 같은 네트워크 토폴로지 요구사항을 충족해야 합니다.
OpenShift Container Platform을 사용하려면 플랫폼 컨테이너의 이미지를 가져오고 Red Hat에 Telemetry 데이터를 제공하기 위해 모든 노드가 인터넷에 액세스할 수 있어야 합니다.
로드 밸런서
OpenShift Container Platform을 설치하기 전에 다음과 같은 요구사항을 충족하는 두 개의 로드 밸런서를 프로비저닝해야 합니다.
API 로드 밸런서: 플랫폼과 상호 작용하고 구성하기 위한 사용자(인간 및 시스템) 모두에 공통 엔드포인트를 제공합니다. 다음 조건을 설정합니다.
- Layer 4 로드 밸런싱 전용입니다. 이를 Raw TCP, SSL Passthrough 또는 SSL Bridge 모드라고 합니다. SSL Bridge 모드를 사용하는 경우, API 경로에 대해 SNI(Server Name Indication, 서버 이름 표시)를 활성화해야 합니다.
- 스테이트리스 로드 밸런싱 알고리즘입니다. 옵션은 로드 밸런서 구현에 따라 달라집니다.
중요API 로드 밸런서에 대한 세션 지속성을 구성하지 마십시오.
로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.
표 7.17. API 로드 밸런서 포트 백엔드 시스템(풀 멤버) 내부 외부 설명 6443부트스트랩 및 컨트롤 플레인. 부트스트랩 시스템이 클러스터 컨트롤 플레인을 초기화한 후 로드 밸런서에서 부트스트랩 시스템을 제거합니다. API 서버 상태 검사 프로브에 대한
/readyz끝점을 구성해야 합니다.X
X
Kubernetes API 서버
22623부트스트랩 및 컨트롤 플레인. 부트스트랩 시스템이 클러스터 컨트롤 플레인을 초기화한 후 로드 밸런서에서 부트스트랩 시스템을 제거합니다.
X
시스템 구성 서버
참고API 서버가
/readyz엔드포인트를 해제하는 시점부터 풀에서 API 서버 인스턴스가 제거되는 시점까지 시간이 30초를 넘지 않도록 로드 밸런서를 구성해야 합니다./readyz가 오류를 반환하거나 정상 상태가 된 후 정해진 시간 안에 끝점이 제거 또는 추가되어야 합니다. 5초 또는 10초의 프로빙 주기(두 번의 성공적인 요청은 정상 상태, 세 번의 요청은 비정상 상태)는 충분한 테스트를 거친 값입니다.애플리케이션 인그레스 로드 밸런서: 클러스터 외부에서 들어오는 애플리케이션 트래픽의 수신 지점을 제공합니다. 다음 조건을 설정합니다.
- Layer 4 로드 밸런싱 전용입니다. 이를 Raw TCP, SSL Passthrough 또는 SSL Bridge 모드라고 합니다. SSL Bridge 모드를 사용하는 경우 인그레스 경로에 대해 SNI(Server Name Indication, 서버 이름 표시)를 활성화해야 합니다.
- 사용 가능한 옵션과 플랫폼에서 호스팅되는 애플리케이션 유형에 따라 연결 기반 또는 세션 기반 지속성이 권장됩니다.
로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.
표 7.18. 애플리케이션 인그레스 로드 밸런서 포트 백엔드 시스템(풀 멤버) 내부 외부 설명 443기본적으로 인그레스 라우터 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.
X
X
HTTPS 트래픽
80기본적으로 인그레스 라우터 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.
X
X
HTTP 트래픽
로드 밸런서에서 클라이언트의 실제 IP 주소를 확인할 수 있는 경우 소스 IP 기반 세션 지속성을 활성화하면 엔드 투 엔드 TLS 암호화를 사용하는 애플리케이션의 성능을 향상시킬 수 있습니다.
인그레스 라우터에 대한 작업 구성이 OpenShift Container Platform 클러스터에 필요합니다. 컨트롤 플레인 초기화 후 인그레스 라우터를 설정해야 합니다.
NTP 구성
OpenShift Container Platform 클러스터는 기본적으로 공용 NTP(Network Time Protocol) 서버를 사용하도록 구성되어 있습니다. 로컬 엔터프라이즈 NTP 서버를 사용하거나 클러스터가 연결이 끊긴 네트워크에 배포되는 경우 특정 시간 서버를 사용하도록 클러스터를 구성할 수 있습니다. 자세한 내용은 chrony 타임 서비스 설정 문서를 참조하십시오.
DHCP 서버가 NTP 서버 정보를 제공하는 경우 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템의 chrony 타임 서비스에서 정보를 읽고 NTP 서버와 클럭을 동기화할 수 있습니다.
추가 리소스
