두 개의 노드 OpenShift 클러스터 설치

1. SMT(동시 멀티스레딩) 또는 Hyper-Threading이 활성화되지 않은 경우 하나의 CPU가 하나의 물리적 코어와 동일합니다. 활성화하면 다음 공식을 사용하여 해당 비율을 계산합니다. (코어당 스레드 수 × 코어 수) × 소켓 = CPU입니다.
2. OpenShift Container Platform 및 Kubernetes는 디스크 성능에 민감하며 특히 컨트롤 플레인 노드의 etcd에 더 빠른 스토리지를 사용하는 것이 좋습니다. 많은 클라우드 플랫폼에서 스토리지 크기와 IOPS를 함께 확장되므로 충분한 성능을 얻으려면 스토리지 볼륨을 과도하게 할당해야 할 수 있습니다.

프로세스

1. 다음 포트에 대한 트래픽을 전달하도록 로드 밸런서를 구성합니다.

   • 6443: Kubernetes API 서버

   • 80 및 443: 애플리케이션 인그레스

     두 컨트롤 플레인 노드로 트래픽을 전달해야 합니다.

2. 로드 밸런서에서 상태 점검을 구성합니다. 로드 밸런서가 응답하는 노드로만 트래픽을 전송하도록 백엔드 끝점을 모니터링해야 합니다.

3. 두 컨트롤 플레인 노드로 트래픽을 전달하도록 로드 밸런서를 구성합니다. 다음 예제에서는 두 개의 컨트롤 플레인 노드를 구성하는 방법을 보여줍니다.

   frontend api_frontend
       bind *:6443
       mode tcp
       default_backend api_backend
   
   backend api_backend
       mode tcp
       balance roundrobin
       server cp0 <cp0_ip>:6443 check
       server cp1 <cp1_ip>:6443 check
   
   frontend ingress_frontend
       bind *:80
       bind *:443
       mode tcp
       default_backend ingress_backend
   
   backend ingress_backend
       mode tcp
       balance roundrobin
       server cp0 <cp0_ip>:80 check
       server cp1 <cp1_ip>:80 check
       server cp0 <cp0_ip>:443 check
       server cp1 <cp1_ip>:443 check

   Copy to Clipboard Toggle word wrap

4. 로드 밸런서 구성을 확인합니다.

   1. 외부 클라이언트에서 다음 명령을 실행합니다.

      $ curl -k https://api.<cluster_name>.<base_domain>:6443/version

      Copy to Clipboard Toggle word wrap

   2. 외부 클라이언트에서 다음 명령을 실행하여 애플리케이션 경로에 액세스합니다.

      $ curl https://<app>.<cluster_name>.<base_domain>

      Copy to Clipboard Toggle word wrap

1. 펜싱 보안 업데이트: 올바르지 않거나 오래된 경우 BMC(Baseboard Management Console) 인증 정보를 새로 고칩니다.
2. 단일 노드 장애 복구: 하나의 컨트롤 플레인 노드만 다운되었을 때 기능을 복원합니다.
3. 전체 노드 장애 복구: 두 컨트롤 플레인 노드가 다운되었을 때 기능을 복원합니다.
4. 복구할 수 없는 컨트롤 플레인 노드를 교체: 클러스터 기능을 복원하려면 노드를 교체하십시오.

프로세스

1. 펜싱 보안을 업데이트합니다.

   1. Cluster API를 사용할 수 없는 경우 클러스터 노드 중 하나에서 다음 명령을 실행하여 펜싱 시크릿을 업데이트합니다.

      $ sudo pcs stonith update <node_name>_redfish username=<user_name> password=<password>

      Copy to Clipboard Toggle word wrap

      Cluster API를 복구하거나 Cluster API를 이미 사용할 수 있는 경우 다음 단계에 설명된 대로 클러스터의 펜싱 시크릿을 업데이트하여 동기화 상태를 유지합니다.

   2. 다음 쉼표를 실행하여 컨트롤 플레인 노드의 기존 펜싱 시크릿의 사용자 이름과 암호를 편집합니다.

      $ oc project openshift-etcd

      Copy to Clipboard Toggle word wrap

      $ oc edit secret <node_name>-fencing

      Copy to Clipboard Toggle word wrap

      펜싱 보안을 업데이트한 후 클러스터가 복구되면 추가 작업이 필요하지 않습니다. 문제가 지속되면 다음 단계를 진행합니다.

2. 단일 노드 실패에서 복구:

   1. 다음 명령을 실행하여 초기 진단을 수집합니다.

      $ sudo pcs status --full

      Copy to Clipboard Toggle word wrap

      이 명령은 현재 클러스터 및 리소스 상태에 대한 자세한 보기를 제공합니다. 출력을 사용하여 펜싱 또는 etcd 시작 문제를 식별할 수 있습니다.

   2. 필요한 경우 다음 추가 진단 명령을 실행합니다.

      클러스터에서 리소스를 재설정하고 다음 명령을 실행하여 Pacemaker에서 새로 시작하도록 지시합니다.

      $ sudo pcs resource cleanup

      Copy to Clipboard Toggle word wrap

      다음 명령을 실행하여 노드의 모든 Pacemaker 활동을 검토합니다.

      $ sudo journalctl -u pacemaker

      Copy to Clipboard Toggle word wrap

      다음 명령을 실행하여 etcd 리소스 시작 문제를 진단합니다.

      $ sudo journalctl -u pacemaker | grep podman-etcd

      Copy to Clipboard Toggle word wrap

   3. 다음 명령을 실행하여 노드의 펜싱 구성을 확인합니다.

      $ sudo pcs stonith config <node_name>_redfish

      Copy to Clipboard Toggle word wrap

      펜싱이 필요하지만 작동하지 않는 경우 Redfish 펜싱 끝점에 액세스할 수 있는지 확인하고 인증 정보가 올바른지 확인합니다.

   4. 펜싱이 작동하는 경우에도 etcd를 시작하지 않는 경우 다음 명령을 실행하여 백업에서 etcd를 복원합니다.

      $ sudo cp -r /var/lib/etcd-backup/* /var/lib/etcd/

      Copy to Clipboard Toggle word wrap

      $ sudo chown -R etcd:etcd /var/lib/etcd

      Copy to Clipboard Toggle word wrap

      복구에 성공하면 추가 작업이 필요하지 않습니다. 문제가 지속되면 다음 단계를 진행합니다.

3. 전체 노드 오류에서 복구합니다.

   1. 두 컨트롤 플레인 노드의 전원을 켭니다.

      Pacemaker가 자동으로 시작되고 두 노드가 온라인 상태임을 감지하면 복구 작업이 시작됩니다. 복구가 예상대로 시작되지 않으면 이전 단계에서 설명하는 진단 명령을 사용하여 문제를 조사합니다.

   2. 클러스터에서 리소스를 재설정하고 다음 명령을 실행하여 Pacemaker에서 새로 시작하도록 지시합니다.

      $ sudo pcs resource cleanup

      Copy to Clipboard Toggle word wrap

   3. 다음 명령을 실행하여 리소스 시작 순서를 확인합니다.

      $ sudo pcs status --full

      Copy to Clipboard Toggle word wrap

   4. 다음 명령을 실행하여 kubelet이 실패하는 경우 pacemaker 서비스 저널을 검사합니다.

      $ sudo journalctl -u pacemaker

      Copy to Clipboard Toggle word wrap

      $ sudo journalctl -u kubelet

      Copy to Clipboard Toggle word wrap

   5. out-of-sync etcd를 처리합니다.

      하나의 노드에 최신 etcd가 있는 경우 Pacemaker에서 노드를 차단하여 학습자로 시작합니다. 이 프로세스가 중지되면 다음 명령을 실행하여 Redfish 펜싱 끝점 및 인증 정보를 확인합니다.

      $ sudo pcs stonith config

      Copy to Clipboard Toggle word wrap

      복구에 성공하면 추가 작업이 필요하지 않습니다. 문제가 지속되면 다음 단계에서 설명하는 대로 수동 복구를 수행합니다.

4. 노드 중 하나를 복구할 수 없는 경우 이벤트에서 수동으로 복구해야 하는 경우 "두 노드 OpenShift 클러스터의 컨트롤 플레인 노드 교체" 절차를 따르십시오.

   클러스터에서 단일 노드가 손실되면 성능이 저하된 모드가 됩니다. 이 상태에서 Pacemaker는 쿼럼을 자동으로 차단 해제하고 나머지 노드에서 클러스터를 일시적으로 작동할 수 있습니다.

   두 노드 모두 실패하는 경우 Pacemaker에서 일반 클러스터 작업을 재개할 수 있도록 쿼럼을 다시 설정하려면 두 노드를 모두 다시 시작해야 합니다.

   두 노드 중 하나만 다시 시작할 수 있는 경우 노드 교체 절차에 따라 남아 있는 노드에서 쿼럼을 수동으로 다시 설정합니다.

   수동 복구가 여전히 필요하며 실패하는 경우 must-gather 및 SOS 보고서를 수집하고 버그를 제출합니다.

프로세스

1. 다음 명령을 실행하여 쿼럼 상태를 확인합니다.

   $ sudo pcs quorum status

   Copy to Clipboard Toggle word wrap

   출력 예

   Quorum information
   ------------------
   Date:             Fri Oct  3 14:15:31 2025
   Quorum provider:  corosync_votequorum
   Nodes:            2
   Node ID:          1
   Ring ID:          1.16
   Quorate:          Yes
   
   Votequorum information
   ----------------------
   Expected votes:   2
   Highest expected: 2
   Total votes:      2
   Quorum:           1
   Flags:            2Node Quorate WaitForAll
   
   Membership information
   ----------------------
       Nodeid      Votes    Qdevice Name
            1          1         NR master-0 (local)
            2          1         NR master-1

   Copy to Clipboard Toggle word wrap

   1. 쿼럼이 유실되고 하나의 컨트롤 플레인 노드가 계속 실행 중인 경우 다음 명령을 실행하여 보류 중인 노드에서 쿼럼을 수동으로 복원합니다.

      $ sudo pcs quorum unblock

      Copy to Clipboard Toggle word wrap

   2. 하나의 노드만 실패한 경우 다음 명령을 실행하여 etcd가 감사자 노드에서 실행되고 있는지 확인합니다.

      $ sudo pcs resource status etcd

      Copy to Clipboard Toggle word wrap

   3. etcd가 실행되고 있지 않은 경우 다음 명령을 실행하여 etcd를 다시 시작하십시오.

      $ sudo pcs resource cleanup etcd

      Copy to Clipboard Toggle word wrap

      etcd가 계속 시작되지 않는 경우 다음 펜싱을 건너뛰십시오.

      중요

      이 명령을 실행하기 전에 교체 중인 노드에 액세스할 수 없는지 확인합니다. 그렇지 않으면 etcd 손상 위험이 있습니다.

      $ sudo pcs resource debug-stop etcd

      Copy to Clipboard Toggle word wrap

      $ sudo OCF_RESKEY_CRM_meta_notify_start_resource='etcd' pcs resource debug-start etcd

      Copy to Clipboard Toggle word wrap

      복구 후 취약점 노드에서 etcd가 성공적으로 실행되고 있어야 합니다.

2. 다음 명령을 실행하여 실패한 노드의 etcd 시크릿을 삭제합니다.

   $ oc project openshift-etcd

   Copy to Clipboard Toggle word wrap

   $ oc delete secret etcd-peer-<node_name>

   Copy to Clipboard Toggle word wrap

   $ oc delete secret etcd-serving-<node_name>

   Copy to Clipboard Toggle word wrap

   $ oc delete secret etcd-serving-metrics-<node_name>

   Copy to Clipboard Toggle word wrap
   참고

   실패한 노드를 교체하려면 먼저 etcd 보안을 삭제해야 합니다. etcd가 실행 중인 경우 API 서버가 이러한 명령에 응답하는 데 약간의 시간이 걸릴 수 있습니다.

3. 실패한 노드의 리소스를 삭제합니다.

   1. BareMetalHost (BMH) 오브젝트가 있는 경우 해당 오브젝트를 나열하여 다음 명령을 실행하여 교체 중인 호스트를 식별합니다.

      $ oc get bmh -n openshift-machine-api

      Copy to Clipboard Toggle word wrap

   2. 다음 명령을 실행하여 실패한 노드의 BMH 오브젝트를 삭제합니다.

      $ oc delete bmh/<bmh_name> -n openshift-machine-api

      Copy to Clipboard Toggle word wrap

   3. Machine 오브젝트를 나열하여 다음 명령을 실행하여 교체하려는 노드에 매핑되는 오브젝트를 식별합니다.

      $ oc get machines.machine.openshift.io -n openshift-machine-api

      Copy to Clipboard Toggle word wrap

   4. 다음 명령을 실행하여 Machine 오브젝트에서 머신 해시 값을 사용하여 라벨을 가져옵니다.

      $ oc get machines.machine.openshift.io/<machine_name> -n openshift-machine-api \
        -o jsonpath='Machine hash label: {.metadata.labels.machine\.openshift\.io/cluster-api-cluster}{"\n"}'

      Copy to Clipboard Toggle word wrap

      & lt;machine_name >을 클러스터의 Machine 오브젝트 이름으로 바꿉니다. 예를 들면 ostest-bfs7w-ctrlplane-0 입니다.

      새 Machine 오브젝트를 프로비저닝하려면 이 레이블이 필요합니다.

   5. 다음 명령을 실행하여 실패한 노드의 Machine 오브젝트를 삭제합니다.

      $ oc delete machines.machine.openshift.io/<machine_name>-<failed nodename> -n openshift-machine-api

      Copy to Clipboard Toggle word wrap
      참고

      Machine 오브젝트를 삭제한 후 노드 오브젝트가 자동으로 삭제됩니다.

4. 동일한 이름과 IP 주소를 사용하여 실패한 호스트를 다시 생성합니다.

   중요

   설치 관리자 프로비저닝 인프라 또는 머신 API를 사용하여 원래 노드를 생성하는 경우에만 이 단계를 수행해야 합니다. 실패한 베어 메탈 컨트롤 플레인 노드를 교체하는 방법에 대한 자세한 내용은 " 베어 메탈에서 비정상적인 etcd 멤버 교체"를 참조하십시오.

   1. BMH 및 머신 오브젝트를 제거합니다. 머신 컨트롤러는 node 오브젝트를 자동으로 삭제합니다.

   2. 다음 샘플 구성을 사용하여 새 머신을 프로비저닝합니다.

      머신 오브젝트 구성 예

      apiVersion: machine.openshift.io/v1beta1
      kind: Machine
      metadata:
        annotations:
          metal3.io/BareMetalHost: openshift-machine-api/{bmh_name}
        finalizers:
        - machine.machine.openshift.io
        labels:
          machine.openshift.io/cluster-api-cluster: {machine_hash_label}
          machine.openshift.io/cluster-api-machine-role: master
          machine.openshift.io/cluster-api-machine-type: master
        name: {machine_name}
        namespace: openshift-machine-api
      spec:
        authoritativeAPI: MachineAPI
        metadata: {}
        providerSpec:
          value:
            apiVersion: baremetal.cluster.k8s.io/v1alpha1
            customDeploy:
              method: install_coreos
            hostSelector: {}
            image:
              checksum: ""
              url: ""
            kind: BareMetalMachineProviderSpec
            metadata:
              creationTimestamp: null
            userData:
              name: master-user-data-managed

      Copy to Clipboard Toggle word wrap

      • metadata.annotations.metal3.io/BareMetalHost: {bmh_name} 을 교체하려는 호스트와 연결된 BMH 오브젝트의 이름으로 바꿉니다.
      • labels.machine.openshift.io/cluster-api-cluster: {machine_hash_label} 을 사용자가 삭제한 시스템에서 가져온 라벨로 바꿉니다.
      • metadata.name: {machine_name} 을 사용자가 삭제한 머신 이름으로 바꿉니다.

   3. 다음 명령을 실행하여 BMC 자격 증명을 저장할 새 BMH 오브젝트와 시크릿을 생성합니다.

      cat <<EOF | oc apply -f -
      apiVersion: v1
      kind: Secret
      metadata:
        name: <secret_name>
        namespace: openshift-machine-api
      data:
        password: <password>
        username: <username>
      type: Opaque
      ---
      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: {bmh_name}
        namespace: openshift-machine-api
      spec:
        automatedCleaningMode: disabled
        bmc:
          address: <redfish_url>/{uuid}
          credentialsName: <name>
          disableCertificateVerification: true
        bootMACAddress: {boot_mac_address}
        bootMode: UEFI
        externallyProvisioned: false
        online: true
        rootDeviceHints:
          deviceName: /dev/disk/by-id/scsi-<serial_number>
        userData:
          name: master-user-data-managed
          namespace: openshift-machine-api
      EOF

      Copy to Clipboard Toggle word wrap
      • metadata.name: 보안 이름을 지정합니다.
      • metadata.name: {bmh_name} 을 사용자가 삭제한 BMH 오브젝트의 이름으로 바꿉니다.
      • BMC.address: {uuid} 를 생성한 노드의 UUID로 바꿉니다.
      • BMC.credentialsName: 이름을 생성한 보안 이름으로 바꿉니다.
      • bootMACAddress: provisioning 네트워크 인터페이스의 MAC 주소를 지정합니다. 프로비저닝 중에 Ironic과 통신할 때 노드가 사용하는 MAC 주소입니다.

5. 다음 명령을 실행하여 새 노드가 Provisioned 상태에 도달했는지 확인합니다.

   $ oc get bmh -o wide

   Copy to Clipboard Toggle word wrap

   이 명령 출력의 STATUS 열 값은 프로비저닝 해야 합니다.

   참고

   프로비저닝 프로세스를 완료하는 데 10~20분이 걸릴 수 있습니다.

6. 다음 명령을 실행하여 두 컨트롤 플레인 노드가 Ready 상태에 있는지 확인합니다.

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

   이 명령 출력의 STATUS 열의 값은 두 노드 모두에 대해 Ready 여야 합니다.

7. 다음 명령을 실행하여 Machine API가 이를 관리하지 못하도록 분리된 주석을 BMH 오브젝트에 적용합니다.

   $ oc annotate bmh <bmh_name> -n openshift-machine-api baremetalhost.metal3.io/detached='' --overwrite

   Copy to Clipboard Toggle word wrap

8. 다음 명령을 실행하여 교체 노드에 Pacemaker 클러스터에 다시 가입합니다.

   참고

   교체 중인 노드가 아닌 세무용 컨트롤 플레인 노드에서 다음 명령을 실행합니다.

   $ sudo pcs cluster node remove <node_name>

   Copy to Clipboard Toggle word wrap

   $ sudo pcs cluster node add <node_name> addr=<node_ip> --start --enable

   Copy to Clipboard Toggle word wrap

9. 다음 명령을 실행하여 실패한 노드의 오래된 작업을 삭제합니다.

   $ oc project openshift-etcd

   Copy to Clipboard Toggle word wrap

   $ oc delete job tnf-auth-job-<node_name>

   Copy to Clipboard Toggle word wrap

   $ oc delete job tnf-after-setup-job-<node_name>

   Copy to Clipboard Toggle word wrap

프로세스

1. 다음 명령을 실행하여 전체 노드 상태를 확인합니다.

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

   이 명령은 두 컨트롤 플레인 노드가 모두 Ready 상태에 있는지 확인하여 스케줄링을 위한 워크로드를 수신할 수 있음을 나타냅니다.

2. 다음 명령을 실행하여 cluster-etcd-operator 의 상태를 확인합니다.

   $ oc describe co/etcd

   Copy to Clipboard Toggle word wrap

   cluster-etcd-operator 는 etcd 설정의 상태를 관리하고 보고합니다. 상태를 검토하면 지속적인 문제 또는 성능이 저하된 조건을 식별하는 데 도움이 됩니다.

3. 다음 명령을 실행하여 etcd 멤버 목록을 검토합니다.

   $ oc rsh -n openshift-etcd <etcd_pod> etcdctl member list -w table

   Copy to Clipboard Toggle word wrap

   이 명령은 현재 etcd 멤버 및 해당 역할을 표시합니다. learner 로 표시된 노드를 찾습니다. 이 노드는 투표 멤버가 되고 있음을 나타냅니다.

4. 컨트롤 플레인 노드에서 다음 명령을 실행하여 Pacemaker 리소스 상태를 확인합니다.

   $ sudo pcs status --full

   Copy to Clipboard Toggle word wrap

   이 명령은 Pacemaker에서 관리하는 모든 리소스에 대한 자세한 개요를 제공합니다. 다음 조건이 충족되었는지 확인해야 합니다.

   • 두 노드가 모두 온라인 상태입니다.
   • kubelet 및 etcd 리소스가 실행 중입니다.
   • 두 노드에 펜싱이 올바르게 구성되어 있습니다.