10.4. 설치 관리자가 프로비저닝한 설치 후 구성
설치 관리자 프로비저닝 클러스터를 성공적으로 배포한 후 다음 설치 후 절차를 고려하십시오.
10.4.1. 연결이 끊긴 클러스터의 NTP 구성 (선택 사항)
OpenShift Container Platform은 클러스터 노드에 chrony Network Time Protocol(NTP) 서비스를 설치합니다. 다음 절차에 따라 컨트롤 플레인 노드에서 NTP 서버를 구성하고 성공적으로 배포 후 작업자 노드를 컨트롤 플레인 노드의 NTP 클라이언트로 구성합니다.
OpenShift Container Platform 노드는 올바로 실행되려면 날짜와 시간에 동의해야 합니다. 작업자 노드는 컨트롤 플레인 노드의 NTP 서버에서 날짜와 시간을 검색하면 라우팅 가능한 네트워크에 연결되지 않은 클러스터를 설치 및 운영할 수 있으므로 상위 계층 NTP 서버에 액세스할 수 없습니다.
프로세스
컨트롤 플레인 노드에 대한
chrony.conf파일의 콘텐츠를 포함하여 Butane 구성,99-master-chrony-conf-override.bu를 만듭니다.참고Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.
Butane 구성의 예
variant: openshift version: 4.9.0 metadata: name: 99-master-chrony-conf-override labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # Use public servers from the pool.ntp.org project. # Please consider joining the pool (https://www.pool.ntp.org/join.html). # The Machine Config Operator manages this file server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony # Configure the control plane nodes to serve as local NTP servers # for all worker nodes, even if they are not in sync with an # upstream NTP server. # Allow NTP client access from the local network. allow all # Serve time even if not synchronized to a time source. local stratum 3 orphan- 1
<cluster-name>을 클러스터 이름으로 바꾸고<domain>을 정규화된 도메인 이름으로 교체해야 합니다.
Butane을 사용하여 컨트롤 플레인 노드에 전달할 구성이 포함된
MachineConfig파일99-master-chrony-conf-override.yaml을 생성합니다.$ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
컨트롤 플레인 노드의 NTP 서버를 참조하는 작업자 노드의
chrony.conf파일의 내용을 포함하여 Butane 구성99-worker-chrony-conf-override.bu를 만듭니다.Butane 구성의 예
variant: openshift version: 4.9.0 metadata: name: 99-worker-chrony-conf-override labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # The Machine Config Operator manages this file. server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony- 1
<cluster-name>을 클러스터 이름으로 바꾸고<domain>을 정규화된 도메인 이름으로 교체해야 합니다.
Butane을 사용하여 작업자 노드로 전달할 구성이 포함된
MachineConfig개체 파일99-worker-chrony-conf-override.yaml을 생성합니다.$ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
99-master-chrony-conf-override.yaml정책을 컨트롤 플레인 노드에 적용합니다.$ oc apply -f 99-master-chrony-conf-override.yaml
출력 예
machineconfig.machineconfiguration.openshift.io/99-master-chrony-conf-override created
99-worker-chrony-conf-override.yaml정책을 작업자 노드에 적용합니다.$ oc apply -f 99-worker-chrony-conf-override.yaml
출력 예
machineconfig.machineconfiguration.openshift.io/99-worker-chrony-conf-override created
적용된 NTP 설정 상태를 확인합니다.
$ oc describe machineconfigpool
10.4.2. 설치 후 프로비저닝 네트워크 활성화
베어 메탈 클러스터에 지원되는 설치 프로그램 및 설치 관리자 프로비저닝 설치는 provisioning 네트워크 없이 클러스터를 배포하는 기능을 제공합니다. 이 기능은 개념 증명 클러스터 또는 각 노드의 베이스보드 관리 컨트롤러를 baremetal 네트워크를 통해 라우팅할 수 있는 Redfish 가상 미디어 전용 배포와 같은 시나리오에 적합합니다.
CBO(Cluster Baremetal Operator)를 사용하여 설치 후 provisioning 네트워크를 활성화할 수 있습니다.
사전 요구 사항
- 모든 작업자 및 컨트롤 플레인 노드에 연결된 전용 물리적 네트워크가 있어야 합니다.
- 태그가 지정되지 않은 기본 물리적 네트워크를 분리해야 합니다.
-
provisioningNetwork구성 설정이Managed로 설정된 경우 네트워크에 DHCP 서버가 있을 수 없습니다. -
bootMACAddress구성 설정을 사용하도록 OpenShift Container Platform 4.9에서provisioningInterface설정을 생략할 수 있습니다.
프로세스
-
provisioningInterface설정을 설정할 때 먼저 클러스터 노드의 프로비저닝 인터페이스 이름을 확인합니다. 예를 들어eth0또는eno1입니다. -
클러스터 노드의
provisioning네트워크 인터페이스에서 PXE(Preboot eXecution Environment)를 활성화합니다. provisioning 네트워크의 현재 상태를 검색하여
provisioningCR(사용자 정의 리소스) 파일에 저장합니다.$ oc get provisioning -o yaml > enable-provisioning-nw.yaml
provisioning CR 파일을 수정합니다.
$ vim ~/enable-provisioning-nw.yaml
아래로 스크롤하여
provisioningNetwork구성 설정으로 이동한 후Disabled에서Managed로 변경합니다. 그런 다음provisioningNetwork설정 후provisioningOSDownloadURL,provisioningIP,provisioningNetworkCIDR,provisioningDHCPRange,provisioningInterface,watchAllNameSpaces구성 설정을 추가합니다. 각 설정에 적절한 값을 제공합니다.apiVersion: v1 items: - apiVersion: metal3.io/v1alpha1 kind: Provisioning metadata: name: provisioning-configuration spec: provisioningNetwork: 1 provisioningOSDownloadURL: 2 provisioningIP: 3 provisioningNetworkCIDR: 4 provisioningDHCPRange: 5 provisioningInterface: 6 watchAllNameSpaces: 7- 1
provisioningNetwork는Managed,Unmanaged또는Disabled중 하나입니다.Managed로 설정하면 Metal3에서 프로비저닝 네트워크를 관리하고 CBO는 구성된 DHCP 서버를 사용하여 Metal3 pod를 배포합니다.Unmanaged로 설정하면 시스템 관리자가 DHCP 서버를 수동으로 구성합니다.- 2
provisioningOSDownloadURL은 유효한 sha 256 체크섬이 있는 HTTPS URL로 Metal3 pod에서.qcow2.gz또는.qcow2.xz로 끝나는 qcow2 운영 체제 이미지를 다운로드할 수 있습니다. 이 필드는 프로비저닝 네트워크가Managed,Unmanaged또는Disabled인지 여부에 관계없이 필요합니다. 예:http://192.168.0.1/images/rhcos-<version>.x86_64.qcow2.gz?sha256=<sha>.- 3
provisioningIP는 DHCP 서버와 ironic에서 네트워크를 프로비저닝하는 데 사용하는 고정 IP 주소입니다. 이 고정 IP 주소는provisioning서브넷 내에 있어야 하며 DHCP 범위 외부에 있어야 합니다. 이 설정을 구성하는 경우provisioning네트워크가Disabled인 경우에도 유효한 IP 주소가 있어야 합니다. 고정 IP 주소는 metal3 pod에 바인딩됩니다. metal3 pod에 장애가 발생하여 다른 서버로 이동하는 경우 고정 IP 주소도 새 서버로 이동합니다.- 4
- CIDR(Classless Inter-Domain Routing) 주소입니다. 이 설정을 구성하는 경우
provisioning네트워크가Disabled인 경우에도 유효한 CIDR 주소가 있어야 합니다. 예:192.168.0.1/24 - 5
- DHCP 범위입니다. 이 설정은
Managed프로비저닝 네트워크에만 적용할 수 있습니다.provisioning네트워크가Disabled인 경우 이 구성 설정을 생략합니다. 예:192.168.0.64, 192.168.0.253. - 6
- 클러스터 노드의
provisioning인터페이스의 NIC 이름입니다.provisioningInterface설정은Managed및Unmanaged프로비저닝 네트워크에만 적용할 수 있습니다. provisioning네트워크가Disabled인 경우 provisioning.Interface구성 설정을 생략합니다bootMACAddress구성 설정을 사용하도록provisioningInterface구성 설정을 생략합니다. - 7
- metal3가 기본
openshift-machine-api네임스페이스 이외의 네임스페이스를 감시하도록 하려면 이 설정을true로 설정합니다. 기본값은false입니다.
- provisioning CR 파일에 변경 사항을 저장합니다.
provisioning CR 파일을 클러스터에 적용합니다.
$ oc apply -f enable-provisioning-nw.yaml
10.4.3. 외부 로드 밸런서 구성
기본 로드 밸런서 대신 외부 로드 밸런서를 사용하도록 OpenShift Container Platform 클러스터를 구성할 수 있습니다.
사전 요구 사항
- 로드 밸런서에서 포트 6443, 443 및 80을 통한 TCP는 시스템의 모든 사용자가 사용할 수 있어야 합니다.
- 각 컨트롤 플레인 노드 간에 API 포트 6443을 로드 밸런싱합니다.
- 모든 컴퓨팅 노드 간에 애플리케이션 포트 443 및 80을 로드 밸런싱합니다.
- 로드 밸런서에서 노드에 Ignition 시작 구성을 제공하는 데 사용되는 포트 22623은 클러스터 외부에 노출되지 않습니다.
로드 밸런서는 클러스터의 모든 머신에 액세스할 수 있어야 합니다. 이러한 액세스를 허용하는 방법은 다음과 같습니다.
- 클러스터의 머신 서브넷에 로드 밸런서를 연결합니다.
- 로드 밸런서를 사용하는 머신에 유동 IP 주소를 연결합니다.
외부 로드 밸런싱 서비스와 컨트롤 플레인 노드는 동일한 L2 네트워크에서 실행해야 하며 VLAN을 사용하여 로드 밸런싱 서비스와 컨트롤 플레인 노드 간에 트래픽을 라우팅할 때 동일한 VLAN에서 실행해야 합니다.
절차
포트 6443, 443, 80의 로드 밸런서에서 클러스터에 대한 액세스를 활성화합니다.
예를 들어 이 HAProxy 구성에 유의하십시오.
샘플 HAProxy 구성 섹션
... listen my-cluster-api-6443 bind 0.0.0.0:6443 mode tcp balance roundrobin server my-cluster-master-2 192.0.2.2:6443 check server my-cluster-master-0 192.0.2.3:6443 check server my-cluster-master-1 192.0.2.1:6443 check listen my-cluster-apps-443 bind 0.0.0.0:443 mode tcp balance roundrobin server my-cluster-worker-0 192.0.2.6:443 check server my-cluster-worker-1 192.0.2.5:443 check server my-cluster-worker-2 192.0.2.4:443 check listen my-cluster-apps-80 bind 0.0.0.0:80 mode tcp balance roundrobin server my-cluster-worker-0 192.0.2.7:80 check server my-cluster-worker-1 192.0.2.9:80 check server my-cluster-worker-2 192.0.2.8:80 check클러스터 API의 DNS 서버에 레코드를 추가하고 로드 밸런서를 통해 앱을 추가합니다. 예를 들면 다음과 같습니다.
<load_balancer_ip_address> api.<cluster_name>.<base_domain> <load_balancer_ip_address> apps.<cluster_name>.<base_domain>
명령줄에서
curl을 사용하여 외부 로드 밸런서 및 DNS 구성이 작동하는지 확인합니다.클러스터 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" }클러스터 애플리케이션에 액세스할 수 있는지 확인합니다.
참고웹 브라우저에서 OpenShift Container Platform 콘솔을 여는 방식으로 애플리케이션 액세스 가능성을 확인할 수도 있습니다.
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
구성이 올바르면 HTTP 응답이 표시됩니다.
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
