Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

5.2. 베어 메탈에서 호스트된 컨트롤 플레인 관리

베어 메탈에 호스팅되는 컨트롤 플레인을 배포한 후 다음 작업을 완료하여 호스팅 클러스터를 관리할 수 있습니다.

5.2.1. 호스트된 클러스터에 액세스
링크 복사

리소스에서 직접 kubeconfig 파일 및 kubeadmin 자격 증명을 가져오거나 hcp 명령줄 인터페이스를 사용하여 kubeconfig 파일을 생성하여 호스팅된 클러스터에 액세스할 수 있습니다.

사전 요구 사항

리소스에서 직접 kubeconfig 파일 및 인증 정보를 가져와 호스팅된 클러스터에 액세스하려면 호스팅 클러스터의 액세스 시크릿을 숙지해야 합니다. 호스팅된 클러스터(호스트링) 네임스페이스에는 호스팅 된 클러스터 리소스 및 액세스 보안이 포함되어 있습니다. 호스팅된 컨트롤 플레인 네임스페이스는 호스팅된 컨트롤 플레인이 실행되는 위치입니다.

보안 이름 형식은 다음과 같습니다.

  • kubeconfig 시크릿: < hosted_cluster_namespace>-<name>-admin-kubeconfig. 예를 들어 cluster -hypershift-demo-admin-kubeconfig.
  • kubeadmin 암호 시크릿: < hosted_cluster_namespace>-<name>-kubeadmin-password. 예를 들어 cluster -hypershift-demo-kubeadmin-password.

kubeconfig 시크릿에는 Base64로 인코딩된 kubeconfig 필드가 포함되어 있으며 다음 명령과 함께 사용할 파일에 디코딩하고 저장할 수 있습니다. 

$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

kubeadmin 암호 시크릿도 Base64로 인코딩됩니다. 이를 디코딩하고 암호를 사용하여 호스팅된 클러스터의 API 서버 또는 콘솔에 로그인할 수 있습니다.

프로세스

  • hcp CLI를 사용하여 kubeconfig 파일을 생성하여 호스팅된 클러스터에 액세스하려면 다음 단계를 수행합니다.

    1. 다음 명령을 입력하여 kubeconfig 파일을 생성합니다. 

      $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
  --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig

    2. kubeconfig 파일을 저장한 후 다음 예제 명령을 입력하여 호스팅된 클러스터에 액세스할 수 있습니다. 

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

5.2.2. 호스트 클러스터의 NodePool 오브젝트 스케일링
링크 복사

호스팅된 클러스터에 노드를 추가하여 NodePool 오브젝트를 확장할 수 있습니다. 노드 풀을 확장할 때 다음 정보를 고려하십시오.

  • 노드 풀로 복제본을 확장하면 머신이 생성됩니다. 모든 머신에 대해 클러스터 API 공급자는 노드 풀 사양에 지정된 요구 사항을 충족하는 에이전트를 찾아 설치합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
  • 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 에이전트를 재사용하려면 먼저 Discovery 이미지를 사용하여 다시 시작해야 합니다.

프로세스

  1. NodePool 오브젝트를 두 개의 노드로 확장합니다. 

    $ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2

    Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 상태를 통과합니다.

    • 바인딩
    • 검색
    • 충분하지 않음
    • 설치
    • installing-in-progress
    • added-to-existing-cluster

  2. 다음 명령을 실행합니다. 

    $ oc -n <hosted_control_plane_namespace> get agent

    출력 예

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign

  3. 다음 명령을 실행합니다. 

    $ oc -n <hosted_control_plane_namespace> get agent \
  -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

    출력 예

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

  4. extract 명령을 입력하여 새 호스팅 클러스터에 대한 kubeconfig를 가져옵니다. 

    $ oc extract -n <hosted_cluster_namespace> \
  secret/<hosted_cluster_name>-admin-kubeconfig --to=- \
  > kubeconfig-<hosted_cluster_name>

  5. 에이전트가 add-to-existing-cluster 상태에 도달한 후 다음 명령을 입력하여 호스팅된 클러스터에 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다. 

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes

    출력 예

    NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f

    클러스터 Operator는 노드에 워크로드를 추가하여 조정하기 시작합니다.

  6. 다음 명령을 입력하여 NodePool 오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다. 

    $ oc -n <hosted_control_plane_namespace> get machines

    출력 예

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.x.z
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.x.z

    clusterversion 조정 프로세스는 결국 Ingress 및 Console 클러스터 Operator만 누락된 지점에 도달합니다.

  7. 다음 명령을 실행합니다. 

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co

    출력 예

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.x.z: the cluster operator console has not yet successfully rolled out

NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                      4.12z     False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
clusteroperator.config.openshift.io/csi-snapshot-controller                      4.12z     True        False         False      10m
clusteroperator.config.openshift.io/dns                                          4.12z     True        False         False      9m16s

5.2.2.1. 노드 풀 추가
링크 복사

이름, 복제본 수 및 에이전트 라벨 선택기와 같은 추가 정보를 지정하여 호스팅된 클러스터에 대한 노드 풀을 생성할 수 있습니다.

참고

호스트된 각 클러스터에 대해 단일 에이전트 네임스페이스만 지원됩니다. 결과적으로 호스트된 클러스터에 노드 풀을 추가할 때 노드 풀은 단일 InfraEnv 리소스 또는 동일한 에이전트 네임스페이스에 있는 InfraEnv 리소스에서 있어야 합니다.

프로세스

  1. 노드 풀을 생성하려면 다음 정보를 입력합니다. 

    $ hcp create nodepool agent \
  --cluster-name <hosted_cluster_name> \
    1 
    
  --name <nodepool_name> \
    2 
    
  --node-count <worker_node_count> \
    3 
    
  --agentLabelSelector size=medium
    4
    1
    &lt ;hosted_cluster_name> 을 호스트된 클러스터 이름으로 교체합니다.
    2
    < nodepool_name >을 노드 풀의 이름으로 바꿉니다(예: < hosted_cluster_name>-extra-cpu ).
    3
    & lt;worker_node_count >를 작업자 노드 수로 바꿉니다(예: 2 ).
    4
    --agentLabelSelector 플래그는 선택 사항입니다. 노드 풀은 size=medium 라벨이 있는 에이전트를 사용합니다.

  2. cluster 네임스페이스에 nodepool 리소스를 나열하여 노드 풀의 상태를 확인합니다. 

    $ oc get nodepools --namespace clusters

  3. 다음 명령을 입력하여 admin-kubeconfig 시크릿을 추출합니다. 

    $ oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm

    출력 예

    hostedcluster-secrets/kubeconfig

  4. 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인할 수 있습니다. 

    $ oc --kubeconfig ./hostedcluster-secrets get nodes

검증

  • 다음 명령을 입력하여 사용 가능한 노드 풀 수가 예상 노드 풀 수와 일치하는지 확인합니다. 

    $ oc get nodepools --namespace clusters

5.2.2.2. 호스트 클러스터의 노드 자동 확장 활성화
링크 복사

호스팅된 클러스터에 용량이 더 필요하고 예비 에이전트를 사용할 수 있는 경우 자동 확장을 활성화하여 새 작업자 노드를 설치할 수 있습니다.

프로세스

  1. 자동 확장을 활성화하려면 다음 명령을 입력합니다. 

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
  --type=json \
  -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
    참고

    이 예에서 최소 노드 수는 2이고 최대값은 5입니다. 추가할 수 있는 최대 노드 수는 플랫폼에 바인딩될 수 있습니다. 예를 들어 에이전트 플랫폼을 사용하는 경우 사용 가능한 에이전트 수에 따라 최대 노드 수가 바인딩됩니다.

  2. 새 노드가 필요한 워크로드를 생성합니다.

    1. 다음 예제를 사용하여 워크로드 구성이 포함된 YAML 파일을 생성합니다. 

      apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: reversewords
  name: reversewords
  namespace: default
spec:
  replicas: 40
  selector:
    matchLabels:
      app: reversewords
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: reversewords
    spec:
      containers:
      - image: quay.io/mavazque/reversewords:latest
        name: reversewords
        resources:
          requests:
            memory: 2Gi
status: {}
    2. 파일을 workload-config.yaml 로 저장합니다.

    3. 다음 명령을 입력하여 YAML을 적용합니다. 

      $ oc apply -f workload-config.yaml

  3. 다음 명령을 입력하여 admin-kubeconfig 시크릿을 추출합니다. 

    $ oc extract -n <hosted_cluster_namespace> \
  secret/<hosted_cluster_name>-admin-kubeconfig \
  --to=./hostedcluster-secrets --confirm

    출력 예

    hostedcluster-secrets/kubeconfig

  4. 다음 명령을 입력하여 새 노드가 Ready 상태에 있는지 확인할 수 있습니다. 

    $ oc --kubeconfig ./hostedcluster-secrets get nodes

  5. 노드를 제거하려면 다음 명령을 입력하여 워크로드를 삭제합니다. 

    $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \
  delete deployment <deployment_name>

  6. 추가 용량을 요구하지 않고 몇 분 정도 경과할 때까지 기다립니다. 에이전트 플랫폼에서 에이전트는 해제되어 재사용될 수 있습니다. 다음 명령을 입력하여 노드가 제거되었는지 확인할 수 있습니다. 

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    참고

    IBM Z® 에이전트의 경우 Processor Resource/Systems Manager (PR/SM) 모드에서 OSA 네트워크 장치를 사용하는 경우 자동 확장이 지원되지 않습니다. 축소 프로세스 중 새 에이전트가 결합되므로 기존 에이전트를 수동으로 삭제하고 노드 풀을 확장해야 합니다.

5.2.2.3. 호스트 클러스터의 노드 자동 확장 비활성화
링크 복사

노드 자동 확장을 비활성화하려면 다음 절차를 완료합니다.

프로세스

  • 다음 명령을 입력하여 호스팅된 클러스터의 노드 자동 스케일링을 비활성화합니다. 

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
  --type=json \
  -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'

    이 명령은 YAML 파일에서 "spec.autoScaling" 을 제거하고 "spec.replicas" 를 추가하고 지정한 정수 값에 "spec.replicas" 를 설정합니다.

5.2.3. 베어 메탈의 호스트 클러스터에서 수신 처리
링크 복사

모든 OpenShift Container Platform 클러스터에는 일반적으로 연결된 외부 DNS 레코드가 있는 기본 애플리케이션 Ingress 컨트롤러가 있습니다. 예를 들어 기본 도메인 krnl.es 를 사용하여 example 이라는 호스팅 클러스터를 생성하는 경우 와일드카드 도메인 *.apps.example.krnl.es 를 라우팅할 수 있을 것으로 예상할 수 있습니다.

프로세스

*.apps 도메인의 로드 밸런서 및 와일드카드 DNS 레코드를 설정하려면 게스트 클러스터에서 다음 작업을 수행합니다.

  1. MetalLB Operator의 구성이 포함된 YAML 파일을 생성하여 MetalLB를 배포합니다. 

    apiVersion: v1
kind: Namespace
metadata:
  name: metallb
  labels:
    openshift.io/cluster-monitoring: "true"
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator-operatorgroup
  namespace: metallb
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb
spec:
  channel: "stable"
  name: metallb-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  2. 파일을 metallb-operator-config.yaml 로 저장합니다.

  3. 다음 명령을 입력하여 구성을 적용합니다. 

    $ oc apply -f metallb-operator-config.yaml

  4. Operator가 실행되면 MetalLB 인스턴스를 생성합니다.

    1. MetalLB 인스턴스의 구성이 포함된 YAML 파일을 생성합니다. 

      apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb
    2. 파일을 metallb-instance-config.yaml 로 저장합니다.

    3. 다음 명령을 입력하여 MetalLB 인스턴스를 생성합니다. 

      $ oc apply -f metallb-instance-config.yaml

  5. 단일 IP 주소를 사용하여 IPAddressPool 리소스를 만듭니다. 이 IP 주소는 클러스터 노드에서 사용하는 네트워크와 동일한 서브넷에 있어야 합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 ipaddresspool.yaml 과 같은 파일을 만듭니다. 

      apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb
  name: <ip_address_pool_name>
      1 
      
spec:
  addresses:
    - <ingress_ip>-<ingress_ip>
      2 
      
  autoAssign: false
      1
      IPAddressPool 리소스 이름을 지정합니다.
      2
      환경의 IP 주소를 지정합니다. 예: 192.168.122.23.

    2. 다음 명령을 입력하여 IP 주소 풀에 대한 구성을 적용합니다. 

      $ oc apply -f ipaddresspool.yaml

  6. L2 광고를 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 l2advertisement.yaml 과 같은 파일을 생성합니다. 

      apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: <l2_advertisement_name>
      1 
      
  namespace: metallb
spec:
  ipAddressPools:
   - <ip_address_pool_name>
      2
      1
      L2Advertisement 리소스 이름을 지정합니다.
      2
      IPAddressPool 리소스 이름을 지정합니다.

    2. 다음 명령을 입력하여 구성을 적용합니다. 

      $ oc apply -f l2advertisement.yaml

  7. LoadBalancer 유형의 서비스를 생성한 후 MetalLB는 서비스에 대한 외부 IP 주소를 추가합니다.

    1. metallb-loadbalancer-service.yaml 이라는 YAML 파일을 생성하여 Ingress 트래픽을 Ingress 배포로 라우팅하는 새 로드 밸런서 서비스를 구성합니다. 

      kind: Service
apiVersion: v1
metadata:
  annotations:
   metallb.io/address-pool: ingress-public-ip
  name: metallb-ingress
  namespace: openshift-ingress
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  type: LoadBalancer
    2. metallb-loadbalancer-service.yaml 파일을 저장합니다.

    3. 다음 명령을 입력하여 YAML 구성을 적용합니다. 

      $ oc apply -f metallb-loadbalancer-service.yaml

    4. 다음 명령을 입력하여 OpenShift Container Platform 콘솔에 연결합니다. 

      $ curl -kI https://console-openshift-console.apps.example.krnl.es

      출력 예

      HTTP/1.1 200 OK

    5. clusterversion 및 clusteroperator 값을 확인하여 모든 항목이 실행 중인지 확인합니다. 다음 명령을 실행합니다. 

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

      출력 예

      NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y      True        False        3m32s   Cluster version is 4.x.y

NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                      4.x.y     True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                      4.x.y     True        False         False      53m

      & lt;4.x.y >를 사용하려는 지원되는 OpenShift Container Platform 버전 (예: 4.20.0-multi )으로 바꿉니다.

5.2.4. 베어 메탈에서 머신 상태 점검 활성화
링크 복사

베어 메탈에서 머신 상태 점검을 활성화하여 비정상 관리형 클러스터 노드를 자동으로 복구 및 교체할 수 있습니다. 관리 클러스터에 설치할 준비가 된 추가 에이전트 시스템이 있어야 합니다.

머신 상태 점검을 활성화하기 전에 다음 제한 사항을 고려하십시오.

  • MachineHealthCheck 오브젝트는 수정할 수 없습니다.
  • 머신 상태 점검에서는 두 개 이상의 노드가 False 또는 Unknown 상태가 8분 이상 유지되는 경우에만 노드를 교체합니다.

관리형 클러스터 노드에 대한 머신 상태 점검을 활성화하면 호스팅된 클러스터에 MachineHealthCheck 오브젝트가 생성됩니다.

프로세스

호스트 클러스터에서 머신 상태 점검을 활성화하려면 NodePool 리소스를 수정합니다. 다음 단계를 완료합니다.

  1. NodePool 리소스의 spec.nodeDrainTimeout 값이 0s 보다 큰지 확인합니다. < hosted_cluster_namespace >를 호스팅된 클러스터 네임스페이스의 이름으로 바꾸고 < nodepool_name >을 노드 풀 이름으로 바꿉니다. 다음 명령을 실행합니다. 

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeout

    출력 예

    nodeDrainTimeout: 30s

  2. spec.nodeDrainTimeout 값이 0s 보다 크면 다음 명령을 실행하여 값을 수정합니다. 

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=merge

  3. NodePool 리소스에서 spec.management.autoRepair 필드를 true 로 설정하여 머신 상태 점검을 활성화합니다. 다음 명령을 실행합니다. 

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=merge

  4. 다음 명령을 실행하여 NodePool 리소스가 autoRepair: true 값으로 업데이트되었는지 확인합니다. 

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair

5.2.5. 베어 메탈에서 머신 상태 점검 비활성화
링크 복사

관리형 클러스터 노드의 머신 상태 점검을 비활성화하려면 NodePool 리소스를 수정합니다.

프로세스

  1. NodePool 리소스에서 spec.management.autoRepair 필드를 false 로 설정하여 머신 상태 점검을 비활성화합니다. 다음 명령을 실행합니다. 

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=merge

  2. 다음 명령을 실행하여 NodePool 리소스가 autoRepair: false 값으로 업데이트되었는지 확인합니다. 

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat맨 위로 이동