10장. 단일 노드 OpenShift 클러스터의 작업자 노드
10.1. 단일 노드 OpenShift 클러스터에 작업자 노드 추가
단일 노드 OpenShift 클러스터는 단일 호스트로 배포하기 위한 호스트 사전 요구 사항을 줄입니다. 이는 제한된 환경 또는 네트워크 에지의 배포에 유용합니다. 그러나 통신 및 네트워크 에지 시나리오에서 클러스터에 용량을 추가해야 하는 경우가 있습니다. 이러한 시나리오에서는 단일 노드 클러스터에 작업자 노드를 추가할 수 있습니다.
멀티 노드 클러스터와 달리 기본적으로 모든 수신 트래픽은 추가 작업자 노드를 추가한 후에도 단일 컨트롤 플레인 노드로 라우팅됩니다.
단일 노드 클러스터에 작업자 노드를 추가할 수 있는 방법은 여러 가지가 있습니다. Red Hat OpenShift Cluster Manager 를 사용하거나 지원 설치 관리자 REST API를 직접 사용하여 클러스터에 작업자 노드를 수동으로 추가할 수 있습니다.
작업자 노드를 추가해도 클러스터 컨트롤 플레인이 확장되지 않으며 클러스터에 고가용성을 제공하지 않습니다. 단일 노드 OpenShift 클러스터의 경우 다른 사이트로 장애 조치하여 고가용성을 처리합니다. 단일 노드 OpenShift 클러스터에 작업자 노드를 추가할 때 테스트된 최대 두 개의 작업자 노드를 사용하는 것이 좋습니다. 권장 작업자 노드 수를 초과하면 클러스터 실패를 포함하여 전체 성능이 저하될 수 있습니다.
작업자 노드를 추가하려면 OpenShift Cluster Manager에 액세스할 수 있어야 합니다. 이 방법은 에이전트 기반 설치 프로그램을 사용하여 연결이 끊긴 환경에 클러스터를 설치할 때 지원되지 않습니다.
10.1.1. 단일 노드 OpenShift 작업자 노드 설치를 위한 요구사항
단일 노드 OpenShift 작업자 노드를 설치하려면 다음 요구 사항을 충족해야 합니다.
- 관리 호스트: ISO를 준비하고 설치를 모니터링할 컴퓨터가 있어야 합니다.
프로덕션 수준 서버: 단일 노드 OpenShift 작업자 노드를 설치하려면 OpenShift Container Platform 서비스 및 프로덕션 워크로드를 실행하기에 충분한 리소스가 있는 서버가 필요합니다.
표 10.1. 최소 리소스 요구사항 프로필 vCPU 메모리 스토리지 최소
vCPU 코어 2개
8GB RAM
100GB
참고SMT(동시 멀티스레딩) 또는 하이퍼 스레딩이 활성화되지 않은 경우 하나의 vCPU는 하나의 물리적 코어와 동일합니다. 사용 가능한 경우 다음 공식을 사용하여 해당 비율을 계산합니다.
(threads per core × cores) × sockets = vCPUs
가상 미디어를 사용하여 부팅할 때 서버에 BMC(Baseboard Management Controller)가 있어야 합니다.
네트워킹: 작업자 노드 서버는 인터넷에 액세스하거나 라우팅 가능한 네트워크에 연결되지 않은 경우 로컬 레지스트리에 액세스해야 합니다. 작업자 노드 서버에는 DHCP 예약 또는 고정 IP 주소가 있어야 하며 단일 노드 OpenShift 클러스터 Kubernetes API, 인그레스 경로 및 클러스터 노드 도메인 이름에 액세스할 수 있어야 합니다. 단일 노드 OpenShift 클러스터에 대해 다음 FQDN(정규화된 도메인 이름)으로 IP 주소를 확인하도록 DNS를 구성해야 합니다.
표 10.2. 필수 DNS 레코드 사용법 FQDN 설명 Kubernetes API
api.<cluster_name>.<base_domain>
DNS A/AAAA 또는 CNAME 레코드를 추가합니다. 이 레코드는 클러스터 외부의 클라이언트가 확인할 수 있어야 합니다.
내부 API
api-int.<cluster_name>.<base_domain>
ISO를 수동으로 생성할 때 DNS A/AAAA 또는 CNAME 레코드를 추가합니다. 이 레코드는 클러스터 내의 노드에서 확인할 수 있어야 합니다.
Ingress 경로
*.apps.<cluster_name>.<base_domain>
노드를 대상으로 하는 와일드카드 DNS A/AAAA 또는 CNAME 레코드를 추가합니다. 이 레코드는 클러스터 외부의 클라이언트가 확인할 수 있어야 합니다.
영구 IP 주소가 없으면
apiserver
와etcd
간의 통신이 실패할 수 있습니다.
10.1.2. 지원 설치 관리자 및 OpenShift Cluster Manager를 사용하여 작업자 노드 추가
지원 설치 관리자를 사용하여 Red Hat OpenShift Cluster Manager 에서 생성된 단일 노드 OpenShift 클러스터에 작업자 노드를 추가할 수 있습니다.
단일 노드 OpenShift 클러스터에 작업자 노드를 추가하는 것은 OpenShift Container Platform 버전 4.11 이상을 실행하는 클러스터에서만 지원됩니다.
사전 요구 사항
- 지원 설치 관리자를 사용하여 설치된 단일 노드 OpenShift 클러스터에 액세스합니다.
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - 작업자 노드를 추가하는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.
프로세스
- OpenShift Cluster Manager 에 로그인하고 작업자 노드를 추가할 단일 노드 클러스터를 클릭합니다.
- 호스트 추가를 클릭하고 필요에 따라 SSH 공개 키를 추가하고 클러스터 전체 프록시 설정을 구성하여 새 작업자 노드의 검색 ISO를 다운로드합니다.
- 검색 ISO를 사용하여 대상 호스트를 부팅하고 콘솔에서 호스트가 검색될 때까지 기다립니다. 호스트가 검색되면 설치를 시작합니다.
설치가 진행됨에 따라 설치는 작업자 노드에 대해 보류 중인 인증서 서명 요청(CSR)을 생성합니다. 메시지가 표시되면 보류 중인 CSR을 승인하여 설치를 완료합니다.
작업자 노드가 제대로 설치되면 클러스터 웹 콘솔에 작업자 노드로 나열됩니다.
새 작업자 노드는 원래 클러스터와 동일한 방법을 사용하여 암호화됩니다.
10.1.3. 지원 설치 프로그램 API를 사용하여 작업자 노드 추가
지원 설치 관리자 REST API를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드를 추가할 수 있습니다. 작업자 노드를 추가하기 전에 OpenShift Cluster Manager 에 로그인하고 API에 대해 인증해야 합니다.
10.1.3.1. 지원 설치 관리자 REST API에 대해 인증
지원 설치 관리자 REST API를 사용하려면 먼저 생성한 JSON 웹 토큰(JWT)을 사용하여 API에 대해 인증해야 합니다.
사전 요구 사항
- 클러스터 생성 권한이 있는 사용자로 OpenShift Cluster Manager 에 로그인합니다.
-
jq
를 설치합니다.
프로세스
- OpenShift Cluster Manager 에 로그인하고 API 토큰을 복사합니다.
다음 명령을 실행하여 복사된 API 토큰을 사용하여
$OFFLINE_TOKEN
변수를 설정합니다.$ export OFFLINE_TOKEN=<copied_api_token>
이전에 설정된
$OFFLINE_TOKEN
변수를 사용하여$JWT_TOKEN
변수를 설정합니다.$ export JWT_TOKEN=$( curl \ --silent \ --header "Accept: application/json" \ --header "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "grant_type=refresh_token" \ --data-urlencode "client_id=cloud-services" \ --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \ "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \ | jq --raw-output ".access_token" )
참고JWT 토큰은 15분 동안만 유효합니다.
검증
선택 사항: 다음 명령을 실행하여 API에 액세스할 수 있는지 확인합니다.
$ curl -s https://api.openshift.com/api/assisted-install/v2/component-versions -H "Authorization: Bearer ${JWT_TOKEN}" | jq
출력 예
{ "release_tag": "v2.5.1", "versions": { "assisted-installer": "registry.redhat.io/rhai-tech-preview/assisted-installer-rhel8:v1.0.0-175", "assisted-installer-controller": "registry.redhat.io/rhai-tech-preview/assisted-installer-reporter-rhel8:v1.0.0-223", "assisted-installer-service": "quay.io/app-sre/assisted-service:ac87f93", "discovery-agent": "registry.redhat.io/rhai-tech-preview/assisted-installer-agent-rhel8:v1.0.0-156" } }
10.1.3.2. 지원 설치 관리자 REST API를 사용하여 작업자 노드 추가
지원 설치 관리자 REST API를 사용하여 클러스터에 작업자 노드를 추가할 수 있습니다.
사전 요구 사항
-
ocm
(OpenShift Cluster Manager CLI)을 설치합니다. - 클러스터 생성 권한이 있는 사용자로 OpenShift Cluster Manager 에 로그인합니다.
-
jq
를 설치합니다. - 작업자 노드를 추가하는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.
프로세스
- 지원 설치 관리자 REST API에 대해 인증하고 세션에 대한 JSON 웹 토큰(JWT)을 생성합니다. 생성된 JWT 토큰은 15분 동안만 유효합니다.
다음 명령을 실행하여
$API_URL
변수를 설정합니다.$ export API_URL=<api_url> 1
- 1
- &
lt;api_url&
gt;을 지원 설치 관리자 API URL로 바꿉니다(예:https://api.openshift.com)
다음 명령을 실행하여 단일 노드 OpenShift 클러스터를 가져옵니다.
$OPENSHIFT_CLUSTER_ID
변수를 설정합니다. 클러스터에 로그인하고 다음 명령을 실행합니다.$ export OPENSHIFT_CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')
클러스터를 가져오는 데 사용되는
$CLUSTER_REQUEST
변수를 설정합니다.$ export CLUSTER_REQUEST=$(jq --null-input --arg openshift_cluster_id "$OPENSHIFT_CLUSTER_ID" '{ "api_vip_dnsname": "<api_vip>", 1 "openshift_cluster_id": $openshift_cluster_id, "name": "<openshift_cluster_name>" 2 }')
클러스터를 가져오고
$CLUSTER_ID
변수를 설정합니다. 다음 명령을 실행합니다.$ CLUSTER_ID=$(curl "$API_URL/api/assisted-install/v2/clusters/import" -H "Authorization: Bearer ${JWT_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' \ -d "$CLUSTER_REQUEST" | tee /dev/stderr | jq -r '.id')
클러스터에 대한
InfraEnv
리소스를 생성하고 다음 명령을 실행하여$INFRA_ENV_ID
변수를 설정합니다.- console.redhat.com 의 Red Hat OpenShift Cluster Manager에서 풀 시크릿 파일을 다운로드합니다.
$INFRA_ENV_REQUEST
변수를 설정합니다.export INFRA_ENV_REQUEST=$(jq --null-input \ --slurpfile pull_secret <path_to_pull_secret_file> \1 --arg ssh_pub_key "$(cat <path_to_ssh_pub_key>)" \2 --arg cluster_id "$CLUSTER_ID" '{ "name": "<infraenv_name>", 3 "pull_secret": $pull_secret[0] | tojson, "cluster_id": $cluster_id, "ssh_authorized_key": $ssh_pub_key, "image_type": "<iso_image_type>" 4 }')
- 1
- <
path_to_pull_secret_file
>을 console.redhat.com 에서 Red Hat OpenShift Cluster Manager에서 다운로드한 풀 시크릿이 포함된 로컬 파일의 경로로 바꿉니다. - 2
- &
lt;path_to_ssh_pub_key
>를 호스트에 액세스하는 데 필요한 공개 SSH 키 경로로 바꿉니다. 이 값을 설정하지 않으면 검색 모드에서 호스트에 액세스할 수 없습니다. - 3
- &
lt;infraenv_name&
gt;을InfraEnv
리소스의 일반 텍스트 이름으로 바꿉니다. - 4
- &
lt;iso_image_type
>을full-iso
또는minimal-iso
의 ISO 이미지 유형으로 바꿉니다.
$INFRA_ENV_REQUEST
를 /v2/infra-envs API에 게시하고$INFRA_ENV_ID
변수를 설정합니다.$ INFRA_ENV_ID=$(curl "$API_URL/api/assisted-install/v2/infra-envs" -H "Authorization: Bearer ${JWT_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' -d "$INFRA_ENV_REQUEST" | tee /dev/stderr | jq -r '.id')
다음 명령을 실행하여 클러스터 작업자 노드에 대한 검색 ISO의 URL을 가져옵니다.
$ curl -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -r '.download_url'
출력 예
https://api.openshift.com/api/assisted-images/images/41b91e72-c33e-42ee-b80f-b5c5bbf6431a?arch=x86_64&image_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTYwMjYzNzEsInN1YiI6IjQxYjkxZTcyLWMzM2UtNDJlZS1iODBmLWI1YzViYmY2NDMxYSJ9.1EX_VGaMNejMhrAvVRBS7PDPIQtbOOc8LtG8OukE1a4&type=minimal-iso&version=$VERSION
ISO를 다운로드합니다.
$ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1
- 1
- &
lt;iso_url
>을 이전 단계의 ISO URL로 바꿉니다.
-
다운로드한
rhcos-live-minimal.iso
에서 새 작업자 호스트를 부팅합니다. 설치되지 않은 클러스터의 호스트 목록을 가져옵니다. 새 호스트가 표시될 때까지 다음 명령을 계속 실행합니다.
$ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -r '.hosts[] | select(.status != "installed").id'
출력 예
2294ba03-c264-4f11-ac08-2f1bb2f8c296
새 작업자 노드의
$HOST_ID
변수를 설정합니다. 예를 들면 다음과 같습니다.$ HOST_ID=<host_id> 1
- 1
- &
lt;host_id&
gt;를 이전 단계의 호스트 ID로 바꿉니다.
다음 명령을 실행하여 호스트를 설치할 준비가 되었는지 확인합니다.
참고전체
jq
표현식을 포함하여 전체 명령을 복사해야 합니다.$ curl -s $API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID -H "Authorization: Bearer ${JWT_TOKEN}" | jq ' def host_name($host): if (.suggested_hostname // "") == "" then if (.inventory // "") == "" then "Unknown hostname, please wait" else .inventory | fromjson | .hostname end else .suggested_hostname end; def is_notable($validation): ["failure", "pending", "error"] | any(. == $validation.status); def notable_validations($validations_info): [ $validations_info // "{}" | fromjson | to_entries[].value[] | select(is_notable(.)) ]; { "Hosts validations": { "Hosts": [ .hosts[] | select(.status != "installed") | { "id": .id, "name": host_name(.), "status": .status, "notable_validations": notable_validations(.validations_info) } ] }, "Cluster validations info": { "notable_validations": notable_validations(.validations_info) } } ' -r
출력 예
{ "Hosts validations": { "Hosts": [ { "id": "97ec378c-3568-460c-bc22-df54534ff08f", "name": "localhost.localdomain", "status": "insufficient", "notable_validations": [ { "id": "ntp-synced", "status": "failure", "message": "Host couldn't synchronize with any NTP server" }, { "id": "api-domain-name-resolved-correctly", "status": "error", "message": "Parse error for domain name resolutions result" }, { "id": "api-int-domain-name-resolved-correctly", "status": "error", "message": "Parse error for domain name resolutions result" }, { "id": "apps-domain-name-resolved-correctly", "status": "error", "message": "Parse error for domain name resolutions result" } ] } ] }, "Cluster validations info": { "notable_validations": [] } }
이전 명령에서 호스트가 준비되었다고 표시되면 다음 명령을 실행하여 /v2/infra-envs/{infra_env_id}/hosts/{host_id}/actions/install API를 사용하여 설치를 시작합니다.
$ curl -X POST -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install" -H "Authorization: Bearer ${JWT_TOKEN}"
설치가 진행됨에 따라 설치는 작업자 노드에 대해 보류 중인 인증서 서명 요청(CSR)을 생성합니다.
중요설치를 완료하려면 CSR을 승인해야 합니다.
다음 API 호출을 계속 실행하여 클러스터 설치를 모니터링합니다.
$ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq '{ "Cluster day-2 hosts": [ .hosts[] | select(.status != "installed") | {id, requested_hostname, status, status_info, progress, status_updated_at, updated_at, infra_env_id, cluster_id, created_at} ] }'
출력 예
{ "Cluster day-2 hosts": [ { "id": "a1c52dde-3432-4f59-b2ae-0a530c851480", "requested_hostname": "control-plane-1", "status": "added-to-existing-cluster", "status_info": "Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs", "progress": { "current_stage": "Done", "installation_percentage": 100, "stage_started_at": "2022-07-08T10:56:20.476Z", "stage_updated_at": "2022-07-08T10:56:20.476Z" }, "status_updated_at": "2022-07-08T10:56:20.476Z", "updated_at": "2022-07-08T10:57:15.306369Z", "infra_env_id": "b74ec0c3-d5b5-4717-a866-5b6854791bd3", "cluster_id": "8f721322-419d-4eed-aa5b-61b50ea586ae", "created_at": "2022-07-06T22:54:57.161614Z" } ] }
선택 사항: 다음 명령을 실행하여 클러스터의 모든 이벤트를 확인합니다.
$ curl -s "$API_URL/api/assisted-install/v2/events?cluster_id=$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -c '.[] | {severity, message, event_time, host_id}'
출력 예
{"severity":"info","message":"Host compute-0: updated status from insufficient to known (Host is ready to be installed)","event_time":"2022-07-08T11:21:46.346Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"} {"severity":"info","message":"Host compute-0: updated status from known to installing (Installation is in progress)","event_time":"2022-07-08T11:28:28.647Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"} {"severity":"info","message":"Host compute-0: updated status from installing to installing-in-progress (Starting installation)","event_time":"2022-07-08T11:28:52.068Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"} {"severity":"info","message":"Uploaded logs for host compute-0 cluster 8f721322-419d-4eed-aa5b-61b50ea586ae","event_time":"2022-07-08T11:29:47.802Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"} {"severity":"info","message":"Host compute-0: updated status from installing-in-progress to added-to-existing-cluster (Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs)","event_time":"2022-07-08T11:29:48.259Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"} {"severity":"info","message":"Host: compute-0, reached installation stage Rebooting","event_time":"2022-07-08T11:29:48.261Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
- 클러스터에 로그인하고 보류 중인 CSR을 승인하여 설치를 완료합니다.
검증
새 작업자 노드가
Ready
인 클러스터에 성공적으로 추가되었는지 확인합니다.$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION control-plane-1.example.com Ready master,worker 56m v1.27.3 compute-1.example.com Ready worker 11m v1.27.3
10.1.4. 단일 노드 OpenShift 클러스터에 수동으로 작업자 노드 추가
RHCOS(Red Hat Enterprise Linux CoreOS) ISO에서 작업자 노드를 수동 부팅하고 클러스터 worker.ign
파일을 사용하여 새 작업자 노드를 클러스터에 조인하여 작업자 노드를 단일 노드 OpenShift 클러스터에 추가할 수 있습니다.
사전 요구 사항
- 베어 메탈에 단일 노드 OpenShift 클러스터를 설치합니다.
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - 작업자 노드를 추가하는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.
프로세스
OpenShift Container Platform 버전을 설정합니다.
$ OCP_VERSION=<ocp_version> 1
- 1
- &
lt;ocp_version&
gt;을 현재 버전으로 바꿉니다(예:latest-4.14
).
호스트 아키텍처를 설정합니다.
$ ARCH=<architecture> 1
- 1
- &
lt;architecture&
gt;를 대상 호스트 아키텍처(예:aarch64
또는x86_64
)로 바꿉니다.
다음 명령을 실행하여 실행 중인 단일 노드 클러스터에서
worker.ign
데이터를 가져옵니다.$ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
-
네트워크에서 액세스할 수 있는 웹 서버의
worker.ign
파일을 호스팅합니다. OpenShift Container Platform 설치 프로그램을 다운로드하여 다음 명령을 실행하여 사용할 수 있도록 합니다.
$ curl -k https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$OCP_VERSION/openshift-install-linux.tar.gz > openshift-install-linux.tar.gz
$ tar zxvf openshift-install-linux.tar.gz
$ chmod +x openshift-install
RHCOS ISO URL을 검색합니다.
$ ISO_URL=$(./openshift-install coreos print-stream-json | grep location | grep $ARCH | grep iso | cut -d\" -f4)
RHCOS ISO를 다운로드합니다.
$ curl -L $ISO_URL -o rhcos-live.iso
RHCOS ISO 및 호스팅
worker.ign
파일을 사용하여 작업자 노드를 설치합니다.- RHCOS ISO 및 기본 설치 방법을 사용하여 대상 호스트를 부팅합니다.
- 대상 호스트가 RHCOS ISO에서 부팅되면 대상 호스트에서 콘솔을 엽니다.
로컬 네트워크에 DHCP가 활성화되어 있지 않은 경우 새 호스트 이름으로 ignition 파일을 생성하고 RHCOS 설치를 실행하기 전에 작업자 노드 고정 IP 주소를 구성해야 합니다. 다음 단계를 수행합니다.
고정 IP를 사용하여 작업자 호스트 네트워크 연결을 구성합니다. 대상 호스트 콘솔에서 다음 명령을 실행합니다.
$ nmcli con mod <network_interface> ipv4.method manual / ipv4.addresses <static_ip> ipv4.gateway <network_gateway> ipv4.dns <dns_server> / 802-3-ethernet.mtu 9000
다음과 같습니다.
- <static_ip>
-
호스트 고정 IP 주소 및 CIDR입니다(예:
10.1.101.50/24
). - <network_gateway>
-
네트워크 게이트웨이입니다(예:
10.1.101.1).
수정된 네트워크 인터페이스를 활성화합니다.
$ nmcli con up <network_interface>
원래
worker.ign
에 대한 참조와coreos-installer
프로그램이 새 작업자 호스트에/etc/hostname
파일을 채우는 데 사용하는 추가 명령을 포함하는 새 ignition 파일new-worker.ign
을 생성합니다. 예를 들면 다음과 같습니다.{ "ignition":{ "version":"3.2.0", "config":{ "merge":[ { "source":"<hosted_worker_ign_file>" 1 } ] } }, "storage":{ "files":[ { "path":"/etc/hostname", "contents":{ "source":"data:,<new_fqdn>" 2 }, "mode":420, "overwrite":true, "path":"/etc/hostname" } ] } }
- 1
<hosted_worker_ign_file
>은 원래worker.ign
파일에 대해 로컬에 액세스 가능한 URL입니다. 예:http://webserver.example.com/worker.ign
- 2
<new_fqdn
>은 작업자 노드에 설정한 새 FQDN입니다. 예를 들면new-worker.example.com
입니다.
-
네트워크에서 액세스할 수 있는 웹 서버의
new-worker.ign
파일을 호스팅합니다. 다음
coreos-installer
명령을 실행하여ignition-url
및 하드 디스크 세부 정보를 전달합니다.$ sudo coreos-installer install --copy-network / --ignition-url=<new_worker_ign_file> <hard_disk> --insecure-ignition
다음과 같습니다.
- <new_worker_ign_file>
-
호스팅된
new-worker.ign
파일에 대해 로컬에서 액세스할 수 있는 URL입니다(예:http://webserver.example.com/new-worker.ign)
- <hard_disk>
-
RHCOS를 설치하는 하드 디스크입니다(예:
/dev/sda
).
DHCP가 활성화된 네트워크의 경우 고정 IP를 설정할 필요가 없습니다. 대상 호스트 콘솔에서 다음
coreos-installer
명령을 실행하여 시스템을 설치합니다.$ coreos-installer install --ignition-url=<hosted_worker_ign_file> <hard_disk>
DHCP를 수동으로 활성화하려면 다음
NMStateConfig
CR을 단일 노드 OpenShift 클러스터에 적용합니다.apiVersion: agent-install.openshift.io/v1 kind: NMStateConfig metadata: name: nmstateconfig-dhcp namespace: example-sno labels: nmstate_config_cluster_name: <nmstate_config_cluster_label> spec: config: interfaces: - name: eth0 type: ethernet state: up ipv4: enabled: true dhcp: true ipv6: enabled: false interfaces: - name: "eth0" macAddress: "AA:BB:CC:DD:EE:11"
중요NMStateConfig
CR은 고정 IP 주소가 있는 작업자 노드를 성공적으로 배포하고 단일 노드 OpenShift가 고정 IP 주소로 배포된 경우 동적 IP 주소로 작업자 노드를 추가하는 데 필요합니다. 클러스터 네트워크 DHCP는 새 작업자 노드에 대한 이러한 네트워크 설정을 자동으로 설정하지 않습니다.
- 설치가 진행됨에 따라 설치는 작업자 노드에 대해 보류 중인 인증서 서명 요청(CSR)을 생성합니다. 메시지가 표시되면 보류 중인 CSR을 승인하여 설치를 완료합니다.
- 설치가 완료되면 호스트를 재부팅합니다. 호스트는 클러스터에 새 작업자 노드로 참여합니다.
검증
새 작업자 노드가
Ready
인 클러스터에 성공적으로 추가되었는지 확인합니다.$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION control-plane-1.example.com Ready master,worker 56m v1.27.3 compute-1.example.com Ready worker 11m v1.27.3
10.1.5. 머신의 인증서 서명 요청 승인
클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.
사전 요구 사항
- 클러스터에 시스템을 추가했습니다.
프로세스
클러스터가 시스템을 인식하는지 확인합니다.
$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.27.3 master-1 Ready master 63m v1.27.3 master-2 Ready master 64m v1.27.3
출력에 생성된 모든 시스템이 나열됩니다.
참고이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.
보류 중인 CSR을 검토하고 클러스터에 추가한 각 시스템에 대해
Pending
또는Approved
상태의 클라이언트 및 서버 요청이 표시되는지 확인합니다.$ oc get csr
출력 예
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 CSR이 더 많이 나타날 수도 있습니다.
CSR이 승인되지 않은 경우, 추가된 시스템에 대한 모든 보류 중인 CSR이
Pending
상태로 전환된 후 클러스터 시스템의 CSR을 승인합니다.참고CSR은 교체 주기가 자동으로 만료되므로 클러스터에 시스템을 추가한 후 1시간 이내에 CSR을 승인하십시오. 한 시간 내에 승인하지 않으면 인증서가 교체되고 각 노드에 대해 두 개 이상의 인증서가 표시됩니다. 이러한 인증서를 모두 승인해야 합니다. 클라이언트 CSR이 승인되면 Kubelet은 인증서에 대한 보조 CSR을 생성하므로 수동 승인이 필요합니다. 그러면 Kubelet에서 동일한 매개변수를 사용하여 새 인증서를 요청하는 경우 인증서 갱신 요청은
machine-approver
에 의해 자동으로 승인됩니다.참고베어 메탈 및 기타 사용자 프로비저닝 인프라와 같이 머신 API를 사용하도록 활성화되지 않는 플랫폼에서 실행되는 클러스터의 경우 CSR(Kubelet service Certificate Request)을 자동으로 승인하는 방법을 구현해야 합니다. 요청이 승인되지 않으면 API 서버가 kubelet에 연결될 때 서비스 인증서가 필요하므로
oc exec
,oc rsh
,oc logs
명령을 성공적으로 수행할 수 없습니다. Kubelet 엔드 포인트에 연결하는 모든 작업을 수행하려면 이 인증서 승인이 필요합니다. 이 방법은 새 CSR을 감시하고 CSR이system:node
또는system:admin
그룹의node-bootstrapper
서비스 계정에 의해 제출되었는지 확인하고 노드의 ID를 확인합니다.개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
은 현재 CSR 목록에 있는 CSR의 이름입니다.
보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
참고일부 Operator는 일부 CSR이 승인될 때까지 사용할 수 없습니다.
이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.
$ oc get csr
출력 예
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
나머지 CSR이 승인되지 않고
Pending
상태인 경우 클러스터 머신의 CSR을 승인합니다.개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
은 현재 CSR 목록에 있는 CSR의 이름입니다.
보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
모든 클라이언트 및 서버 CSR이 승인된 후 머신은
Ready
상태가 됩니다. 다음 명령을 실행하여 확인합니다.$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION master-0 Ready master 73m v1.27.3 master-1 Ready master 73m v1.27.3 master-2 Ready master 74m v1.27.3 worker-0 Ready worker 11m v1.27.3 worker-1 Ready worker 11m v1.27.3
참고머신이
Ready
상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.
추가 정보
- CSR에 대한 자세한 내용은 인증서 서명 요청을 참조하십시오.