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 주소가 없으면 apiserveretcd 간의 통신이 실패할 수 있습니다.

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 레코드가 있는지 확인합니다.

프로세스

  1. OpenShift Cluster Manager 에 로그인하고 작업자 노드를 추가할 단일 노드 클러스터를 클릭합니다.
  2. 호스트 추가를 클릭하고 필요에 따라 SSH 공개 키를 추가하고 클러스터 전체 프록시 설정을 구성하여 새 작업자 노드의 검색 ISO를 다운로드합니다.
  3. 검색 ISO를 사용하여 대상 호스트를 부팅하고 콘솔에서 호스트가 검색될 때까지 기다립니다. 호스트가 검색되면 설치를 시작합니다.
  4. 설치가 진행됨에 따라 설치는 작업자 노드에 대해 보류 중인 인증서 서명 요청(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 를 설치합니다.

프로세스

  1. OpenShift Cluster Manager 에 로그인하고 API 토큰을 복사합니다.
  2. 다음 명령을 실행하여 복사된 API 토큰을 사용하여 $OFFLINE_TOKEN 변수를 설정합니다.

    $ export OFFLINE_TOKEN=<copied_api_token>
  3. 이전에 설정된 $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 레코드가 있는지 확인합니다.

프로세스

  1. 지원 설치 관리자 REST API에 대해 인증하고 세션에 대한 JSON 웹 토큰(JWT)을 생성합니다. 생성된 JWT 토큰은 15분 동안만 유효합니다.
  2. 다음 명령을 실행하여 $API_URL 변수를 설정합니다.

    $ export API_URL=<api_url> 1
    1
    & lt;api_url& gt;을 지원 설치 관리자 API URL로 바꿉니다(예: https://api.openshift.com)
  3. 다음 명령을 실행하여 단일 노드 OpenShift 클러스터를 가져옵니다.

    1. $OPENSHIFT_CLUSTER_ID 변수를 설정합니다. 클러스터에 로그인하고 다음 명령을 실행합니다.

      $ export OPENSHIFT_CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')
    2. 클러스터를 가져오는 데 사용되는 $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
      }')
      1
      & lt;api_vip >를 클러스터 API 서버의 호스트 이름으로 바꿉니다. API 서버의 DNS 도메인 또는 작업자 노드가 도달할 수 있는 단일 노드의 IP 주소일 수 있습니다. 예를 들면 api.compute-1.example.com 입니다.
      2
      & lt;openshift_cluster_name& gt;을 클러스터의 일반 텍스트 이름으로 바꿉니다. 클러스터 이름은 Day 1 클러스터 설치 중에 설정된 클러스터 이름과 일치해야 합니다.
    3. 클러스터를 가져오고 $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')
  4. 클러스터에 대한 InfraEnv 리소스를 생성하고 다음 명령을 실행하여 $INFRA_ENV_ID 변수를 설정합니다.

    1. console.redhat.com 의 Red Hat OpenShift Cluster Manager에서 풀 시크릿 파일을 다운로드합니다.
    2. $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 이미지 유형으로 바꿉니다.
    3. $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')
  5. 다음 명령을 실행하여 클러스터 작업자 노드에 대한 검색 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

  6. ISO를 다운로드합니다.

    $ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1
    1
    & lt;iso_url >을 이전 단계의 ISO URL로 바꿉니다.
  7. 다운로드한 rhcos-live-minimal.iso 에서 새 작업자 호스트를 부팅합니다.
  8. 설치되지 않은 클러스터의 호스트 목록을 가져옵니다. 새 호스트가 표시될 때까지 다음 명령을 계속 실행합니다.

    $ 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

  9. 새 작업자 노드의 $HOST_ID 변수를 설정합니다. 예를 들면 다음과 같습니다.

    $ HOST_ID=<host_id> 1
    1
    & lt;host_id& gt;를 이전 단계의 호스트 ID로 바꿉니다.
  10. 다음 명령을 실행하여 호스트를 설치할 준비가 되었는지 확인합니다.

    참고

    전체 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": []
      }
    }

  11. 이전 명령에서 호스트가 준비되었다고 표시되면 다음 명령을 실행하여 /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}"
  12. 설치가 진행됨에 따라 설치는 작업자 노드에 대해 보류 중인 인증서 서명 요청(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"
        }
      ]
    }

  13. 선택 사항: 다음 명령을 실행하여 클러스터의 모든 이벤트를 확인합니다.

    $ 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"}

  14. 클러스터에 로그인하고 보류 중인 CSR을 승인하여 설치를 완료합니다.

검증

  • 새 작업자 노드가 Ready 인 클러스터에 성공적으로 추가되었는지 확인합니다.

    $ oc get nodes

    출력 예

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.29.4
    compute-1.example.com          Ready    worker          11m   v1.29.4

10.1.4. 단일 노드 OpenShift 클러스터에 수동으로 작업자 노드 추가

RHCOS(Red Hat Enterprise Linux CoreOS) ISO에서 작업자 노드를 수동 부팅하고 클러스터 worker.ign 파일을 사용하여 새 작업자 노드를 클러스터에 조인하여 작업자 노드를 단일 노드 OpenShift 클러스터에 추가할 수 있습니다.

사전 요구 사항

  • 베어 메탈에 단일 노드 OpenShift 클러스터를 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 작업자 노드를 추가하는 클러스터에 필요한 모든 DNS 레코드가 있는지 확인합니다.

프로세스

  1. OpenShift Container Platform 버전을 설정합니다.

    $ OCP_VERSION=<ocp_version> 1
    1
    & lt;ocp_version& gt;을 현재 버전으로 바꿉니다(예: latest-4.16).
  2. 호스트 아키텍처를 설정합니다.

    $ ARCH=<architecture> 1
    1
    & lt;architecture& gt;를 대상 호스트 아키텍처(예: aarch64 또는 x86_64 )로 바꿉니다.
  3. 다음 명령을 실행하여 실행 중인 단일 노드 클러스터에서 worker.ign 데이터를 가져옵니다.

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  4. 네트워크에서 액세스할 수 있는 웹 서버의 worker.ign 파일을 호스팅합니다.
  5. 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
  6. RHCOS ISO URL을 검색합니다.

    $ ISO_URL=$(./openshift-install coreos print-stream-json | grep location | grep $ARCH | grep iso | cut -d\" -f4)
  7. RHCOS ISO를 다운로드합니다.

    $ curl -L $ISO_URL -o rhcos-live.iso
  8. RHCOS ISO 및 호스팅 worker.ign 파일을 사용하여 작업자 노드를 설치합니다.

    1. RHCOS ISO 및 기본 설치 방법을 사용하여 대상 호스트를 부팅합니다.
    2. 대상 호스트가 RHCOS ISO에서 부팅되면 대상 호스트에서 콘솔을 엽니다.
    3. 로컬 네트워크에 DHCP가 활성화되어 있지 않은 경우 새 호스트 이름으로 ignition 파일을 생성하고 RHCOS 설치를 실행하기 전에 작업자 노드 고정 IP 주소를 구성해야 합니다. 다음 단계를 수행합니다.

      1. 고정 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).
      2. 수정된 네트워크 인터페이스를 활성화합니다.

        $ nmcli con up <network_interface>
      3. 원래 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 입니다.
      4. 네트워크에서 액세스할 수 있는 웹 서버의 new-worker.ign 파일을 호스팅합니다.
      5. 다음 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).
    4. DHCP가 활성화된 네트워크의 경우 고정 IP를 설정할 필요가 없습니다. 대상 호스트 콘솔에서 다음 coreos-installer 명령을 실행하여 시스템을 설치합니다.

      $ coreos-installer install --ignition-url=<hosted_worker_ign_file> <hard_disk>
    5. 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는 새 작업자 노드에 대한 이러한 네트워크 설정을 자동으로 설정하지 않습니다.

  9. 설치가 진행됨에 따라 설치는 작업자 노드에 대해 보류 중인 인증서 서명 요청(CSR)을 생성합니다. 메시지가 표시되면 보류 중인 CSR을 승인하여 설치를 완료합니다.
  10. 설치가 완료되면 호스트를 재부팅합니다. 호스트는 클러스터에 새 작업자 노드로 참여합니다.

검증

  • 새 작업자 노드가 Ready 인 클러스터에 성공적으로 추가되었는지 확인합니다.

    $ oc get nodes

    출력 예

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.29.4
    compute-1.example.com          Ready    worker          11m   v1.29.4

10.1.5. 머신의 인증서 서명 요청 승인

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

  • 클러스터에 시스템을 추가했습니다.

프로세스

  1. 클러스터가 시스템을 인식하는지 확인합니다.

    $ oc get nodes

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.29.4
    master-1  Ready     master  63m  v1.29.4
    master-2  Ready     master  64m  v1.29.4

    출력에 생성된 모든 시스템이 나열됩니다.

    참고

    이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.

  2. 보류 중인 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이 더 많이 나타날 수도 있습니다.

  3. 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이 승인될 때까지 사용할 수 없습니다.

  4. 이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.

    $ 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
    ...

  5. 나머지 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
  6. 모든 클라이언트 및 서버 CSR이 승인된 후 머신은 Ready 상태가 됩니다. 다음 명령을 실행하여 확인합니다.

    $ oc get nodes

    출력 예

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.29.4
    master-1  Ready     master  73m  v1.29.4
    master-2  Ready     master  74m  v1.29.4
    worker-0  Ready     worker  11m  v1.29.4
    worker-1  Ready     worker  11m  v1.29.4

    참고

    머신이 Ready 상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.

추가 정보

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.