3.4. 사용자 프로비저닝 인프라를 포함한 클러스터의 시스템 요구사항
사용자 프로비저닝 인프라가 포함된 클러스터의 경우, 필요한 모든 시스템을 배포해야 합니다.
이 섹션에서는 사용자 프로비저닝 인프라에 OpenShift Container Platform을 배포해야 하는 요구 사항에 대해 설명합니다.
3.4.1. 클러스터 설치에 필요한 시스템
최소 OpenShift Container Platform 클러스터에 다음과 같은 호스트가 필요합니다.
호스트 | 설명 |
---|---|
임시 부트스트랩 시스템 한 개 | 컨트롤 플레인 시스템 세 개에 OpenShift Container Platform 클러스터를 배포하기 위한 부트스트랩 시스템이 클러스터에 필요합니다. 클러스터를 설치한 후 부트스트랩 시스템을 제거할 수 있습니다. |
컨트롤 플레인 시스템 세 개 | 컨트롤 플레인 시스템은 컨트롤 플레인을 구성하는 Kubernetes 및 OpenShift Container Platform 서비스를 실행합니다. |
두 개 이상의 컴퓨팅 시스템(작업자 시스템이라고도 함). | OpenShift Container Platform 사용자가 요청한 워크로드는 컴퓨팅 머신에서 실행됩니다. |
클러스터의 고가용성을 개선하려면 컨트롤 플레인 시스템을 두 개 이상의 물리적 시스템의 서로 다른 z/VM 인스턴스에 배포하십시오.
부트스트랩, 컨트롤 플레인 및 컴퓨팅 시스템은 운영 체제로 RHCOS (Red Hat Enterprise Linux CoreOS)를 사용해야 합니다.
RHCOS는 RHEL 8(Red Hat Enterprise Linux)을 기반으로하며 모든 하드웨어 인증 및 요구사항을 모두 이어받습니다. Red Hat Enterprise Linux 기술 기능 및 제한을 참조하십시오.
3.4.2. 클러스터 설치를 위한 최소 리소스 요구 사항
각 클러스터 시스템이 다음과 같은 최소 요구사항을 충족해야 합니다.
머신 | 운영 체제 | vCPU [1] | 가상 RAM | 스토리지 | IOPS |
---|---|---|---|---|---|
부트스트랩 | RHCOS | 4 | 16GB | 100GB | 해당 없음 |
컨트롤 플레인 | RHCOS | 4 | 16GB | 100GB | 해당 없음 |
Compute | RHCOS | 2 | 8GB | 100GB | 해당 없음 |
- SMT-2가 활성화된 경우 하나의 물리적 코어(IFL)는 두 개의 논리 코어(스레드)를 제공합니다. 하이퍼바이저는 두 개 이상의 vCPU를 제공할 수 있습니다.
플랫폼의 인스턴스 유형이 클러스터 머신의 최소 요구 사항을 충족하는 경우 OpenShift Container Platform에서 사용할 수 있습니다.
추가 리소스
3.4.3. 최소 IBM Z 시스템 환경
다음 IBM 하드웨어에 OpenShift Container Platform 버전 4.12를 설치할 수 있습니다.
- IBM z16 (모든 모델), IBM z15 (모든 모델), IBM z14 (모든 모델), IBM z13 및 IBM z13s
- IBM® LinuxONE Emperor 4, IBM® LinuxONE III(모든 모델), IBM® LinuxONE Emperor II, IBM® LinuxONE Rockhopper II, IBM® LinuxONE Emperor, IBM® LinuxONE Rockhopper
IBM z13에 대한 RHCOS 기능, 모든 모델, IBM® LinuxONE Emperor 및 IBM® LinuxONE Rockhopper에 대한 지원은 더 이상 사용되지 않습니다. 이러한 하드웨어 모델은 OpenShift Container Platform 4.12에서 완전히 지원됩니다. 그러나 Red Hat은 이후의 하드웨어 모델을 사용할 것을 권장합니다.
하드웨어 요구 사항
- 각 클러스터에 대해 SMT2가 활성화된 6개의 통합 Linux(IFL)와 동일합니다.
-
둘 다
LoadBalancer
서비스에 연결하고 클러스터 외부의 트래픽에 대한 데이터를 제공하는 하나 이상의 네트워크 연결입니다.
전용 또는 공유 IFL을 사용하여 충분한 컴퓨팅 리소스를 할당할 수 있습니다. 리소스 공유는 IBM Z의 주요 강점 중 하나이지만 각 하이퍼바이저 계층에서 용량을 올바르게 조정하고 모든 OpenShift Container Platform 클러스터에 충분한 리소스를 확보해야 합니다.
클러스터의 전반적인 성능에 영향을 미칠 수 있으므로 OpenShift Container Platform 클러스터를 설정하는 데 사용되는 LPAR은 충분한 컴퓨팅 용량을 제공해야 합니다. 이 컨텍스트에서 하이퍼바이저 수준의 LPAR 가중치 관리, 자격 및 CPU 공유가 중요한 역할을 합니다.
운영 체제 요구 사항
- z/VM 7.2 이상의 인스턴스 1개
z/VM 인스턴스에서 다음을 설정합니다.
- OpenShift Container Platform 컨트롤 플레인 시스템 용 게스트 가상 머신 세 개
- OpenShift Container Platform 컴퓨팅 머신 용 게스트 가상 머신 두 개
- 임시 OpenShift Container Platform 부트스트랩 시스템용 게스트 가상 머신 1개
IBM Z 네트워크 연결 요구 사항
IBM Z의 z/VM에 설치하려면 레이어 2 모드의 단일 z/VM 가상 NIC가 필요합니다. 또한 다음이 필요합니다.
- 직접 연결된 OSA 또는 RoCE 네트워크 어댑터
- z/VM VSwitch 설정. 권장 설정의 경우 OSA 링크 통합을 사용합니다.
z/VM 게스트 가상 머신 용 디스크 스토리지
- FICON 연결 디스크 스토리지 (DASD). 이는 z/VM 미니 디스크, 풀팩 미니 디스크 또는 전용 DASD가 포함될 수 있으며, 모두 기본 CDL로 포맷되어야 합니다. Red Hat Enterprise Linux CoreOS (RHCOS) 설치에 필요한 최소 DASD 크기에 도달하려면 확장 주소 볼륨 (EAV)이 필요합니다. 사용 가능한 경우 HyperPAV를 사용하여 최적의 성능을 보장합니다.
- FCP 연결 디스크 스토리지
스토리지 / 메인 메모리
- OpenShift Container Platform 컨트롤 플레인 시스템용 16GB
- OpenShift Container Platform 컴퓨팅 머신 용 8GB
- 임시 OpenShift Container Platform 부트스트랩 머신 용 16GB
3.4.4. 권장되는 IBM Z 시스템 환경
하드웨어 요구 사항
- 각 클러스터에 대해 SMT2가 활성화된 6개의 IFL에 해당하는 3개의 LPARS입니다.
-
둘 다
LoadBalancer
서비스에 연결하고 클러스터 외부의 트래픽에 대한 데이터를 제공하는 두 개의 네트워크 연결입니다. - Hipersockets는 하나의 장치로 노드에 직접 연결되거나 z/VM 게스트에 하나의 z/VM VSWITCH와 브리징하여 노드에 연결됩니다. HiperSockets를 노드에 직접 연결하려면 RHEL 8 게스트를 통해 외부 네트워크의 게이트웨이를 설정하여 HiperSockets 네트워크에 연결해야 합니다.
운영 체제 요구 사항
- 고가용성을 위해 z/VM 7.2 이상의 두 개 또는 세 개의 인스턴스
z/VM 인스턴스에서 다음을 설정합니다.
- OpenShift Container Platform 컨트롤 플레인 시스템 용 게스트 가상 머신 세 개, z/VM 인스턴스당 1개입니다.
- z/VM 인스턴스에 분산된 OpenShift Container Platform 컴퓨팅 머신용 게스트 가상 머신 6개 이상
- 임시 OpenShift Container Platform 부트스트랩 시스템용 게스트 가상 머신 1개
-
오버 커밋된 환경에서 통합 구성 요소를 사용하려면 CP 명령
SET SHARE
를 사용하여 컨트롤 플레인의 우선 순위를 높입니다. 인프라 노드가 있는 경우 동일한 작업을 수행합니다. IBM 문서의 SET SHARE 를 참조하십시오.
IBM Z 네트워크 연결 요구 사항
IBM Z의 z/VM에 설치하려면 레이어 2 모드의 단일 z/VM 가상 NIC가 필요합니다. 또한 다음이 필요합니다.
- 직접 연결된 OSA 또는 RoCE 네트워크 어댑터
- z/VM VSwitch 설정. 권장 설정의 경우 OSA 링크 통합을 사용합니다.
z/VM 게스트 가상 머신 용 디스크 스토리지
- FICON 연결 디스크 스토리지 (DASD). 이는 z/VM 미니 디스크, 풀팩 미니 디스크 또는 전용 DASD가 포함될 수 있으며, 모두 기본 CDL로 포맷되어야 합니다. Red Hat Enterprise Linux CoreOS (RHCOS) 설치에 필요한 최소 DASD 크기에 도달하려면 확장 주소 볼륨 (EAV)이 필요합니다. 가능한 경우 HyperPAV 및 고성능 FICON (zHPF)을 사용하여 최적의 성능을 보장합니다.
- FCP 연결 디스크 스토리지
스토리지 / 메인 메모리
- OpenShift Container Platform 컨트롤 플레인 시스템용 16GB
- OpenShift Container Platform 컴퓨팅 머신 용 8GB
- 임시 OpenShift Container Platform 부트스트랩 머신 용 16GB
3.4.5. 인증서 서명 요청 관리
사용자가 프로비저닝하는 인프라를 사용하는 경우 자동 시스템 관리 기능으로 인해 클러스터의 액세스가 제한되므로 설치한 후 클러스터 인증서 서명 요청(CSR)을 승인하는 메커니즘을 제공해야 합니다. kube-controller-manager
는 kubelet 클라이언트 CSR만 승인합니다. machine-approver
는 올바른 시스템에서 발행한 요청인지 확인할 수 없기 때문에 kubelet 자격 증명을 사용하여 요청하는 서비스 인증서의 유효성을 보장할 수 없습니다. kubelet 서빙 인증서 요청의 유효성을 확인하고 요청을 승인하는 방법을 결정하여 구현해야 합니다.
추가 리소스
- IBM 문서에서 Bridging a HiperSockets LAN with a z/VM Virtual Switch 를 참조하십시오.
- 성능 최적화를 위해 z/VM의 Linux 게스트에서 HyperPAV 별칭 장치 스케일링을 참조하십시오.
- LPAR 가중치 관리 및 권한 부여는 LPAR 성능의 주제를 참조하십시오.
- IBM Z 및 IBM® LinuxONE 환경에 대한 호스트 관련 권장 사례
3.4.6. 사용자 프로비저닝 인프라에 대한 네트워킹 요구사항
모든 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템이 부팅 중에 Ignition 구성 파일을 가져오려면 initramfs
에 네트워킹을 구성해야 합니다.
초기 부팅 과정에서 시스템에 필요한 부팅 옵션을 제공하여 DHCP 서버를 통해 설정하거나 정적으로 설정하는 IP 주소 구성이 필요합니다. 네트워크 연결이 설정된 후 시스템은 HTTP 또는 HTTPS 서버에서 Ignition 구성 파일을 다운로드합니다. 그런 다음 Ignition 구성 파일을 사용하여 각 머신의 정확한 상태를 설정합니다. Machine Config Operator는 설치 후 새 인증서 또는 키 적용과 같은 머신에 대한 추가 변경을 완료합니다.
클러스터 시스템의 장기적인 관리를 위해 DHCP 서버를 사용하는 것이 좋습니다. DHCP 서버가 클러스터 시스템에 영구 IP 주소, DNS 서버 정보 및 호스트 이름을 제공하도록 구성되었는지 확인합니다.
사용자 프로비저닝 인프라에 DHCP 서비스를 사용할 수 없는 경우 RHCOS 설치 시 노드에 IP 네트워킹 구성과 DNS 서버의 주소를 대신 제공할 수 있습니다. ISO 이미지에서 설치하는 경우 부팅 인수로 전달할 수 있습니다. 고정 IP 프로비저닝 및 고급 네트워킹 옵션에 대한 자세한 내용은 RHCOS 설치 및 OpenShift Container Platform 부트스트랩 프로세스 시작 섹션을 참조하십시오.
Kubernetes API 서버가 클러스터 시스템의 노드 이름을 확인할 수 있어야 합니다. API 서버와 작업자 노드가 서로 다른 영역에 있는 경우, API 서버가 노드 이름을 확인할 수 있도록 기본 DNS 검색 영역을 설정할 수 있습니다. 노드 개체와 모든 DNS 요청에서 항상 정규화된 도메인 이름으로 호스트를 가리키는 것도 지원되는 방법입니다
3.4.6.1. DHCP를 통해 클러스터 노드의 호스트 이름 설정
RHCOS(Red Hat Enterprise Linux CoreOS) 시스템에서 호스트 이름은 NetworkManager를 통해 설정됩니다. 기본적으로 시스템은 DHCP를 통해 호스트 이름을 가져옵니다. DHCP에서 호스트 이름을 제공하지 않으면 커널 인수를 통해 정적으로 설정하거나 다른 방법을 통해 역방향 DNS 조회를 통해 가져옵니다. 역방향 DNS 조회는 노드에서 네트워크를 초기화한 후 수행되며 확인하는 데 시간이 걸릴 수 있습니다. 다른 시스템 서비스는 이 보다 먼저 시작하여 호스트 이름을 localhost
등으로 감지할 수 있습니다. DHCP를 사용하여 각 클러스터 노드의 호스트 이름을 제공하여 이 문제를 방지할 수 있습니다.
또한 DHCP를 통해 호스트 이름을 설정하면 DNS 분할 수평 구현 환경에서 수동으로 DNS 레코드 이름 구성 오류를 무시할 수 있습니다.
3.4.6.2. 네트워크 연결 요구사항
OpenShift Container Platform 클러스터 구성 요소가 통신할 수 있도록 시스템 간 네트워크 연결을 구성해야 합니다. 각 시스템에서 클러스터에 있는 다른 모든 시스템의 호스트 이름을 확인할 수 있어야 합니다.
이 섹션에서는 필요한 포트에 대해 자세히 설명합니다.
프로토콜 | 포트 | 설명 |
---|---|---|
ICMP | 해당 없음 | 네트워크 연결성 테스트 |
TCP |
| 메트릭 |
|
| |
| Kubernetes에서 예약하는 기본 포트 | |
| openshift-sdn | |
UDP |
| VXLAN |
| Geneve | |
|
| |
| IPsec IKE 패킷 | |
| IPsec NAT-T 패킷 | |
|
UDP 포트
외부 NTP 시간 서버가 구성된 경우 UDP 포트 | |
TCP/UDP |
| Kubernetes 노드 포트 |
ESP | 해당 없음 | IPsec Encapsulating Security Payload (ESP) |
프로토콜 | 포트 | 설명 |
---|---|---|
TCP |
| Kubernetes API |
프로토콜 | 포트 | 설명 |
---|---|---|
TCP |
| etcd 서버 및 피어 포트 |
사용자 프로비저닝 인프라에 대한 NTP 구성
OpenShift Container Platform 클러스터는 기본적으로 공용 NTP(Network Time Protocol) 서버를 사용하도록 구성되어 있습니다. 로컬 엔터프라이즈 NTP 서버를 사용하거나 클러스터가 연결이 끊긴 네트워크에 배포되는 경우 특정 시간 서버를 사용하도록 클러스터를 구성할 수 있습니다. 자세한 내용은 chrony 타임 서비스 설정 문서를 참조하십시오.
추가 리소스
3.4.7. 사용자 프로비저닝 DNS 요구사항
OpenShift Container Platform 배포의 경우 다음 구성 요소에 DNS 이름을 확인해야 합니다.
- Kubernetes API
- OpenShift Container Platform 애플리케이션 와일드카드
- 부트스트랩, 컨트롤 플레인 및 컴퓨팅 시스템
Kubernetes API, 부트스트랩 시스템, 컨트롤 플레인 시스템 및 컴퓨팅 시스템에 대한 역방향 DNS 확인이 필요합니다.
DNS A/AAAA 또는 CNAME 레코드는 이름 확인에 사용되며 PTR 레코드는 역방향 이름 확인에 사용됩니다. RHCOS (Red Hat Enterprise Linux CoreOS)는 DHCP에서 호스트 이름을 제공하지 않는 한 모든 노드의 호스트 이름을 설정할 때 역방향 레코드를 사용하기 때문에 역방향 레코드가 중요합니다. 또한 역방향 레코드는 OpenShift Container Platform이 작동하는 데 필요한 인증서 서명 요청 (CSR)을 생성하는 데 사용됩니다.
사용자가 프로비저닝한 OpenShift Container Platform 클러스터에 대해 다음 DNS 레코드가 필요하며 설치 전에 있어야 합니다. 각 레코드에서 <cluster_name>
은 클러스터 이름이고 <base_domain>
은 install-config.yaml
파일에서 지정하는 기반 도메인입니다. 전체 DNS 레코드는 <component>.<cluster_name>.<base_domain>
형식입니다.
구성 요소 | 레코드 | 설명 |
---|---|---|
Kubernetes API |
| API 로드 밸런서를 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다. |
| 내부적으로 API 로드 밸런서를 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다. 중요 API 서버는 Kubernetes에 기록된 호스트 이름으로 작업자 노드를 확인할 수 있어야 합니다. API 서버가 노드 이름을 확인할 수 없는 경우 프록시된 API 호출이 실패할 수 있으며 pod에서 로그를 검색할 수 없습니다. | |
라우트 |
| 애플리케이션 인그레스 로드 밸런서를 참조하는 와일드카드 DNS A/AAA 또는 CNAME 레코드입니다. 애플리케이션 인그레스 로드 밸런서는 Ingress 컨트롤러 Pod를 실행하는 머신을 대상으로 합니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다. 이 레코드는 클러스터 외부의 클라이언트와 클러스터 내의 모든 노드에서 확인할 수 있어야 합니다.
예를 들어 |
부트스트랩 시스템 |
| 부트스트랩 머신을 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다. |
컨트롤 플레인 머신 |
| 컨트롤 플레인 노드의 각 머신을 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다. |
컴퓨팅 머신 |
| 작업자 노드의 각 머신을 식별하는 DNS A/AAAA 또는 CNAME 레코드와 DNS PTR 레코드입니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다. |
OpenShift Container Platform 4.4 이상에서는 DNS 구성에서 etcd 호스트 및 SRV 레코드를 지정할 필요가 없습니다.
dig
명령을 사용하여 이름과 역방향 이름을 확인할 수 있습니다. 자세한 검증 단계는 사용자 프로비저닝 인프라의 DNS 확인 섹션을 참조하십시오.
3.4.7.1. 사용자 프로비저닝 클러스터의 DNS 구성 예
이 섹션에서는 사용자 프로비저닝 인프라에 OpenShift Container Platform을 배포하기 위한 DNS 요구 사항을 충족하는 A 및 PTR 레코드 구성 샘플을 제공합니다. 샘플은 하나의 DNS 솔루션을 선택하기 위한 조언을 제공하기 위한 것이 아닙니다.
이 예제에서 클러스터 이름은 ocp4
이고 기본 도메인은 example.com
입니다.
사용자 프로비저닝 클러스터의 DNS A 레코드 구성 예
다음 BIND 영역 파일의 예제에서는 사용자가 프로비저닝한 클러스터의 이름 확인을 위한 샘플 A 레코드를 보여줍니다.
예 3.1. 샘플 DNS 영역 데이터베이스
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. IN MX 10 smtp.example.com. ; ; ns1.example.com. IN A 192.168.1.5 smtp.example.com. IN A 192.168.1.5 ; helper.example.com. IN A 192.168.1.5 helper.ocp4.example.com. IN A 192.168.1.5 ; api.ocp4.example.com. IN A 192.168.1.5 1 api-int.ocp4.example.com. IN A 192.168.1.5 2 ; *.apps.ocp4.example.com. IN A 192.168.1.5 3 ; bootstrap.ocp4.example.com. IN A 192.168.1.96 4 ; control-plane0.ocp4.example.com. IN A 192.168.1.97 5 control-plane1.ocp4.example.com. IN A 192.168.1.98 6 control-plane2.ocp4.example.com. IN A 192.168.1.99 7 ; compute0.ocp4.example.com. IN A 192.168.1.11 8 compute1.ocp4.example.com. IN A 192.168.1.7 9 ; ;EOF
- 1
- Kubernetes API의 이름 확인을 제공합니다. 레코드는 API 로드 밸런서의 IP 주소를 나타냅니다.
- 2
- Kubernetes API의 이름 확인을 제공합니다. 레코드는 API 로드 밸런서의 IP 주소를 참조하며 내부 클러스터 통신에 사용됩니다.
- 3
- 와일드카드 경로의 이름 확인을 제공합니다. 레코드는 애플리케이션 인그레스 로드 밸런서의 IP 주소를 나타냅니다. 애플리케이션 인그레스 로드 밸런서는 Ingress 컨트롤러 Pod를 실행하는 머신을 대상으로 합니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다.참고
이 예제에서는 Kubernetes API 및 애플리케이션 인그레스 트래픽에 동일한 로드 밸런서를 사용합니다. 프로덕션 시나리오에서는 각각에 대해 개별적으로 로드 밸런서 인프라를 확장할 수 있도록 API 및 애플리케이션 인그레스 로드 밸런서를 별도로 배포할 수 있습니다.
- 4
- 부트스트랩 시스템의 이름 확인을 제공합니다.
- 5 6 7
- 컨트롤 플레인 시스템의 이름 확인을 제공합니다.
- 8 9
- 컴퓨팅 시스템의 이름 확인을 제공합니다.
사용자 프로비저닝 클러스터의 DNS PTR 레코드 구성 예
다음 예제 BIND 영역 파일은 사용자 프로비저닝 클러스터의 역방향 이름 확인을 위한 샘플 PTR 레코드를 보여줍니다.
예 3.2. 역방향 레코드의 샘플 DNS 영역 데이터베이스
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. ; 5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com. 1 5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com. 2 ; 96.1.168.192.in-addr.arpa. IN PTR bootstrap.ocp4.example.com. 3 ; 97.1.168.192.in-addr.arpa. IN PTR control-plane0.ocp4.example.com. 4 98.1.168.192.in-addr.arpa. IN PTR control-plane1.ocp4.example.com. 5 99.1.168.192.in-addr.arpa. IN PTR control-plane2.ocp4.example.com. 6 ; 11.1.168.192.in-addr.arpa. IN PTR compute0.ocp4.example.com. 7 7.1.168.192.in-addr.arpa. IN PTR compute1.ocp4.example.com. 8 ; ;EOF
OpenShift Container Platform 애플리케이션 와일드카드에는 PTR 레코드가 필요하지 않습니다.
3.4.8. 사용자 프로비저닝 인프라에 대한 로드 밸런싱 요구사항
OpenShift Container Platform을 설치하기 전에 API 및 애플리케이션 인그레스 로드 밸런싱 인프라를 프로비저닝해야 합니다. 프로덕션 시나리오에서는 각각에 대해 개별적으로 로드 밸런서 인프라를 확장할 수 있도록 API 및 애플리케이션 인그레스 로드 밸런서를 별도로 배포할 수 있습니다.
RHEL(Red Hat Enterprise Linux) 인스턴스를 사용하여 API 및 애플리케이션 인그레스 로드 밸런서를 배포하려면 RHEL 서브스크립션을 별도로 구입해야 합니다.
로드 밸런서 인프라는 다음 요구 사항을 충족해야 합니다.
API 로드 밸런서: 플랫폼과 상호 작용하고 플랫폼을 구성할 수 있도록 사용자(인간과 시스템 모두)에게 공통 끝점을 제공합니다. 다음 조건을 설정합니다.
- Layer 4 로드 밸런싱 전용입니다. 원시 TCP 또는 SSL Passthrough 모드라고 할 수 있습니다.
- 스테이트리스 로드 밸런싱 알고리즘입니다. 옵션은 로드 밸런서 구현에 따라 달라집니다.
중요API 로드 밸런서에 대한 세션 지속성을 구성하지 마십시오. Kubernetes API 서버에 대한 세션 지속성을 구성하면 성능 문제가 OpenShift Container Platform 클러스터의 초과 애플리케이션 트래픽 및 클러스터 내에서 실행되는 Kubernetes API가 발생하지 않을 수 있습니다.
로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.
표 3.7. API 로드 밸런서 포트 백엔드 시스템(풀 멤버) 내부 외부 설명 6443
부트스트랩 및 컨트롤 플레인. 부트스트랩 시스템이 클러스터 컨트롤 플레인을 초기화한 후 로드 밸런서에서 부트스트랩 시스템을 제거합니다. API 서버 상태 검사 프로브에 대한
/readyz
끝점을 구성해야 합니다.X
X
Kubernetes API 서버
22623
부트스트랩 및 컨트롤 플레인. 부트스트랩 시스템이 클러스터 컨트롤 플레인을 초기화한 후 로드 밸런서에서 부트스트랩 시스템을 제거합니다.
X
시스템 구성 서버
참고API 서버가
/readyz
엔드포인트를 해제하는 시점부터 풀에서 API 서버 인스턴스가 제거되는 시점까지 시간이 30초를 넘지 않도록 로드 밸런서를 구성해야 합니다./readyz
가 오류를 반환하거나 정상 상태가 된 후 정해진 시간 안에 끝점이 제거 또는 추가되어야 합니다. 5초 또는 10초의 프로빙 주기(두 번의 성공적인 요청은 정상 상태, 세 번의 요청은 비정상 상태)는 충분한 테스트를 거친 값입니다.애플리케이션 인그레스 로드 밸런서: 클러스터 외부에서 유입되는 애플리케이션 트래픽에 대한 수신 지점을 제공합니다. 인그레스 라우터에 대한 작업 구성이 OpenShift Container Platform 클러스터에 필요합니다.
다음 조건을 설정합니다.
- Layer 4 로드 밸런싱 전용입니다. 원시 TCP 또는 SSL Passthrough 모드라고 할 수 있습니다.
- 사용 가능한 옵션과 플랫폼에서 호스팅되는 애플리케이션 유형에 따라 연결 기반 또는 세션 기반 지속성이 권장됩니다.
작은 정보애플리케이션 Ingress 로드 밸런서에서 클라이언트의 실제 IP 주소를 확인할 수 있는 경우 소스 IP 기반 세션 지속성을 활성화하면 엔드 투 엔드 TLS 암호화를 사용하는 애플리케이션의 성능을 향상시킬 수 있습니다.
로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.
표 3.8. 애플리케이션 인그레스 로드 밸런서 포트 백엔드 시스템(풀 멤버) 내부 외부 설명 443
기본적으로 인그레스 컨트롤러 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.
X
X
HTTPS 트래픽
80
기본적으로 인그레스 컨트롤러 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.
X
X
HTTP 트래픽
참고컴퓨팅 노드가 0인 3-노드 클러스터를 배포하는 경우 Ingress 컨트롤러 Pod는 컨트롤 플레인 노드에서 실행됩니다. 3-노드 클러스터 배포에서 HTTP 및 HTTPS 트래픽을 컨트롤 플레인 노드로 라우팅하도록 애플리케이션 인그레스 로드 밸런서를 구성해야 합니다.
3.4.8.1. 사용자 프로비저닝 클러스터의 로드 밸런서 구성 예
이 섹션에서는 사용자 프로비저닝 클러스터의 로드 밸런싱 요구 사항을 충족하는 API 및 애플리케이션 수신 로드 밸런서 구성 예를 제공합니다. 샘플은 HAProxy 로드 밸런서에 대한 /etc/haproxy/haproxy.cfg
구성입니다. 이 예제에서는 하나의 로드 밸런싱 솔루션을 선택하기 위한 조언을 제공하는 것을 목적으로 하지 않습니다.
이 예제에서는 Kubernetes API 및 애플리케이션 인그레스 트래픽에 동일한 로드 밸런서를 사용합니다. 프로덕션 시나리오에서는 각각에 대해 개별적으로 로드 밸런서 인프라를 확장할 수 있도록 API 및 애플리케이션 인그레스 로드 밸런서를 별도로 배포할 수 있습니다.
HAProxy를 로드 밸런서로 사용하고 SELinux가 enforcing
으로 설정된 경우 HAProxy 서비스가 setsebool -P haproxy_connect_any=1
을 실행하여 구성된 TCP 포트에 바인딩할 수 있는지 확인해야 합니다.
예 3.3. API 및 애플리케이션 인그레스 로드 밸런서 구성 샘플
global log 127.0.0.1 local2 pidfile /var/run/haproxy.pid maxconn 4000 daemon defaults mode http log global option dontlognull option http-server-close option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 listen api-server-6443 1 bind *:6443 mode tcp option httpchk GET /readyz HTTP/1.0 option log-health-checks balance roundrobin server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup 2 server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 listen machine-config-server-22623 3 bind *:22623 mode tcp server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 4 server master0 master0.ocp4.example.com:22623 check inter 1s server master1 master1.ocp4.example.com:22623 check inter 1s server master2 master2.ocp4.example.com:22623 check inter 1s listen ingress-router-443 5 bind *:443 mode tcp balance source server worker0 worker0.ocp4.example.com:443 check inter 1s server worker1 worker1.ocp4.example.com:443 check inter 1s listen ingress-router-80 6 bind *:80 mode tcp balance source server worker0 worker0.ocp4.example.com:80 check inter 1s server worker1 worker1.ocp4.example.com:80 check inter 1s
- 1
- 포트
6443
은 Kubernetes API 트래픽을 처리하고 컨트롤 플레인 시스템을 가리킵니다. - 2 4
- 부트스트랩 항목은 OpenShift Container Platform 클러스터 설치 전에 있어야 하며 부트스트랩 프로세스가 완료된 후 제거해야 합니다.
- 3
- 포트
22623
은 머신 구성 서버 트래픽을 처리하고 컨트롤 플레인 시스템을 가리킵니다. - 5
- 포트
443
은 HTTPS 트래픽을 처리하고 Ingress 컨트롤러 Pod를 실행하는 시스템을 가리킵니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다. - 6
- 포트
80
은 HTTP 트래픽을 처리하고 Ingress 컨트롤러 Pod를 실행하는 머신을 가리킵니다. Ingress 컨트롤러 Pod는 기본적으로 컴퓨팅 머신에서 실행됩니다.참고컴퓨팅 노드가 0인 3-노드 클러스터를 배포하는 경우 Ingress 컨트롤러 Pod는 컨트롤 플레인 노드에서 실행됩니다. 3-노드 클러스터 배포에서 HTTP 및 HTTPS 트래픽을 컨트롤 플레인 노드로 라우팅하도록 애플리케이션 인그레스 로드 밸런서를 구성해야 합니다.
HAProxy를 로드 밸런서로 사용하는 경우 HAProxy 노드에서 netstat -nltupe
를 실행하여 haproxy
프로세스가 포트 6443
, 22623
, 443
및 80
에서 수신 대기 중인지 확인할 수 있습니다.