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

4.12. etcd 작업

etcd를 백업하거나 etcd 암호화를 활성화 또는 비활성화하거나 etcd 데이터 조각 모음을 실행합니다.

참고

베어 메탈 클러스터를 배포한 경우 설치 후 작업의 일부로 클러스터를 최대 5개 노드까지 확장할 수 있습니다. 자세한 내용은 etcd에 대한 노드 확장을 참조하세요.

4.12.1. etcd 암호화 정보
링크 복사

기본적으로 etcd 데이터는 OpenShift Container Platform에서 암호화되지 않습니다. 클러스터에 etcd 암호화를 사용하여 추가 데이터 보안 계층을 제공할 수 있습니다. 예를 들어 etcd 백업이 잘못된 당사자에게 노출되는 경우 중요한 데이터의 손실을 방지할 수 있습니다.

etcd 암호화를 활성화하면 다음 OpenShift API 서버 및 쿠버네티스 API 서버 리소스가 암호화됩니다.

  • 보안
  • 구성 맵
  • 라우트
  • OAuth 액세스 토큰
  • OAuth 승인 토큰

etcd 암호화를 활성화하면 암호화 키가 생성됩니다. etcd 백업에서 복원하려면 이 키가 있어야 합니다.

참고

etcd 암호화는 키가 아닌 값만 암호화합니다. 리소스 유형, 네임스페이스, 개체 이름은 암호화되지 않습니다.

백업 중에 etcd 암호화가 활성화된 경우 static_kuberesources_<datetimestamp>.tar.gz 파일에 etcd 스냅샷에 대한 암호화 키가 포함됩니다. 보안상의 이유로 이 파일은 etcd 스냅샷과 별도로 저장하세요. 하지만 이 파일은 해당 etcd 스냅샷에서 etcd의 이전 상태를 복원하는 데 필요합니다.

4.12.2. 지원되는 암호화 유형
링크 복사

OpenShift Container Platform에서 etcd 데이터를 암호화하는 데 지원되는 암호화 유형은 다음과 같습니다.

AES-CBC
PKCS#7 패딩과 32바이트 키를 사용하는 AES-CBC를 사용하여 암호화를 수행합니다. 암호화 키는 매주 교체됩니다.
AES-GCM
임의의 비ce 및 32바이트 키와 함께 AES-GCM을 사용하여 암호화를 수행합니다. 암호화 키는 매주 교체됩니다.

4.12.3. etcd 암호화 활성화
링크 복사

etcd 암호화를 활성화하여 클러스터에서 중요한 리소스를 암호화할 수 있습니다.

주의

초기 암호화 프로세스가 완료될 때까지 etcd 리소스를 백업하지 마세요. 암호화 프로세스가 완료되지 않으면 백업이 부분적으로만 암호화될 수 있습니다.

etcd 암호화를 활성화하면 다음과 같은 여러 가지 변경 사항이 발생할 수 있습니다.

  • etcd 암호화는 몇몇 리소스의 메모리 소비에 영향을 미칠 수 있습니다.
  • 리더가 백업을 담당해야 하므로 백업 성능에 일시적인 영향이 있을 수 있습니다.
  • 디스크 I/O는 백업 상태를 수신하는 노드에 영향을 미칠 수 있습니다.

AES-GCM 또는 AES-CBC 암호화로 etcd 데이터베이스를 암호화할 수 있습니다.

참고

etcd 데이터베이스를 한 암호화 유형에서 다른 암호화 유형으로 마이그레이션하려면 API 서버의 spec.encryption.type 필드를 수정하면 됩니다. etcd 데이터는 자동으로 새로운 암호화 유형으로 마이그레이션됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. APIServer 오브젝트를 수정합니다. 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. spec.encryption.type 필드를 aesgcm 또는 aescbc 로 설정합니다. 

    spec:
  encryption:
    type: aesgcm
    1
    Copy to Clipboard Toggle word wrap
    1
    AES-GCM 암호화의 경우 aesgcm 으로 설정하고, AES-CBC 암호화의 경우 aescbc로 설정 합니다.

  3. 파일을 저장하여 변경 사항을 적용합니다.

    암호화 프로세스가 시작됩니다. etcd 데이터베이스 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.

  4. etcd 암호화에 성공했는지 확인합니다.

    1. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다. 

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다. 

      EncryptionCompleted
All resources encrypted: routes.route.openshift.io
      Copy to Clipboard Toggle word wrap

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

    2. 쿠버네티스 API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다. 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다. 

      EncryptionCompleted
All resources encrypted: secrets, configmaps
      Copy to Clipboard Toggle word wrap

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

    3. OpenShift OAuth API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다. 

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다. 

      EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
      Copy to Clipboard Toggle word wrap

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

4.12.4. etcd 암호화 비활성화
링크 복사

클러스터에서 etcd 데이터의 암호화를 비활성화할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. APIServer 오브젝트를 수정합니다. 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. 암호화 필드 유형을 identity로 설정합니다. 

    spec:
  encryption:
    type: identity
    1
    Copy to Clipboard Toggle word wrap
    1
    identity 유형이 기본값이며, 이는 암호화가 수행되지 않음을 의미합니다.

  3. 파일을 저장하여 변경 사항을 적용합니다.

    암호 해독 프로세스가 시작됩니다. 클러스터 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.

  4. etcd 암호 해독에 성공했는지 확인합니다.

    1. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다. 

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다. 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

    2. 쿠버네티스 API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다. 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다. 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

    3. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다. 

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다. 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

4.12.5. etcd 데이터 백업
링크 복사

다음 단계에 따라 etcd 스냅샷을 작성하고 정적 pod의 리소스를 백업하여 etcd 데이터를 백업합니다. 이 백업을 저장하여 etcd를 복원해야하는 경우 나중에 사용할 수 있습니다.

중요

단일 컨트롤 플레인 호스트의 백업만 저장합니다. 클러스터의 각 컨트롤 플레인 호스트에서 백업을 수행하지 마십시오.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

  • 클러스터 전체의 프록시가 활성화되어 있는지 확인해야 합니다.

    작은 정보

    oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxy 및 noProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

프로세스

  1. 제어 평면 노드의 루트로 디버그 세션을 시작합니다. 

    $ oc debug --as-root node/<node_name>
    Copy to Clipboard Toggle word wrap

  2. 디버그 셸에서 루트 디렉토리를 /host 로 변경하세요. 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

  3. 클러스터 전체 프록시가 활성화된 경우 다음 명령을 실행하여 NO_PROXY , HTTP_PROXY 및 HTTPS_PROXY 환경 변수를 내보냅니다. 

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export NO_PROXY=<example.com>
    Copy to Clipboard Toggle word wrap

  4. 디버그 셸에서 cluster-backup.sh 스크립트를 실행하고 백업을 저장할 위치를 전달합니다.

    작은 정보

    cluster-backup.sh 스크립트는 etcd Cluster Operator의 구성 요소로 유지 관리되며 etcdctl snapshot save 명령 관련 래퍼입니다. 

    sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup
    Copy to Clipboard Toggle word wrap

    스크립트 출력 예

    found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
etcdctl version: 3.4.14
API version: 3.4
{"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
{"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
{"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
{"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
{"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
snapshot db and kube resources are successfully saved to /home/core/assets/backup
    Copy to Clipboard Toggle word wrap

    이 예제에서는 컨트롤 플레인 호스트의 /home/core/assets/backup/ 디렉토리에 두 개의 파일이 생성됩니다.

    • snapshot_<datetimestamp>.db:이 파일은 etcd 스냅샷입니다. cluster-backup.sh 스크립트는 유효성을 확인합니다.

    • static_kuberesources_<datetimestamp>.tar.gz: 이 파일에는 정적 pod 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.

      참고

      etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.

      etcd 암호화는 키가 아닌 값만 암호화합니다. 즉, 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.

4.12.6. etcd 데이터 조각 모음
링크 복사

대규모 고밀도 클러스터의 경우 키스페이스가 너무 커져서 공간 할당량을 초과하면 etcd의 성능이 저하될 수 있습니다. 주기적으로 etcd를 유지 관리하고 조각 모음을 수행하여 데이터 저장소의 공간을 확보합니다. Prometheus에서 etcd 메트릭을 모니터링하고 필요한 경우 조각 모음을 수행합니다. 그렇지 않으면 etcd가 클러스터 전체에 알람을 발생시켜 클러스터를 키 읽기와 삭제만 허용하는 유지 관리 모드로 전환할 수 있습니다.

다음과 같은 주요 지표를 모니터링하세요.

  • 현재 할당량 한도인 etcd_server_quota_backend_bytes
  • etcd_mvcc_db_total_size_in_use_in_bytes 는 기록 압축 후 실제 데이터베이스 사용량을 나타냅니다.
  • etcd_mvcc_db_total_size_in_bytes 는 조각 모음을 기다리는 여유 공간을 포함한 데이터베이스 크기를 보여줍니다.

etcd 기록 압축과 같은 디스크 조각화를 초래하는 이벤트 후 디스크 공간을 회수하기 위해 etcd 데이터를 조각 모음합니다.

기록 압축은 5분마다 자동으로 수행되며 백엔드 데이터베이스에서 공백이 남습니다. 이 분할된 공간은 etcd에서 사용할 수 있지만 호스트 파일 시스템에서 사용할 수 없습니다. 호스트 파일 시스템에서 이 공간을 사용할 수 있도록 etcd 조각을 정리해야 합니다.

조각 모음이 자동으로 수행되지만 수동으로 트리거할 수도 있습니다.

참고

etcd Operator는 클러스터 정보를 사용하여 사용자에게 가장 효율적인 작업을 결정하기 때문에 자동 조각 모음은 대부분의 경우에 적합합니다.

4.12.6.1. 자동 조각 모음
링크 복사

etcd Operator는 디스크 조각 모음을 자동으로 수행합니다. 수동 조작이 필요하지 않습니다.

다음 로그 중 하나를 확인하여 조각 모음 프로세스가 성공했는지 확인합니다.

  • etcd 로그
  • cluster-etcd-operator Pod
  • Operator 상태 오류 로그
주의

자동 조각 모음은 Kubernetes 컨트롤러 관리자 등 다양한 OpenShift 핵심 구성 요소에서 리더 선출 실패를 일으킬 수 있으며, 이로 인해 실패한 구성 요소가 다시 시작됩니다. 재시작은 무해하며, 다음 실행 인스턴스로 장애 조치를 시작하거나 재시작 후 구성 요소가 다시 작업을 재개합니다.

성공적인 조각 모음에 대한 로그 출력 예

etcd member has been defragmented: <member_name>, memberID: <member_id>
Copy to Clipboard Toggle word wrap

실패한 조각 모음에 대한 로그 출력 예

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
Copy to Clipboard Toggle word wrap

4.12.6.2. 수동 조각 모음
링크 복사

Prometheus 경고는 수동 조각 모음을 사용해야 하는 경우를 나타냅니다. 경고는 두 가지 경우에 표시됩니다.

  • etcd가 사용 가능한 공간의 50% 이상을 10분 이상 사용하는 경우
  • etcd가 10분 이상 전체 데이터베이스 크기의 50% 미만을 적극적으로 사용하는 경우

또한 PromQL 표현식 ((etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024를 사용하여 조각 모음으로 해제될 etcd 데이터베이스 크기(MB)를 확인하여 조각 모음이 필요한지 여부를 판단할 수 있습니다.

주의

etcd를 분리하는 것은 차단 작업입니다. etcd 멤버는 조각 모음이 완료될 때까지 응답하지 않습니다. 따라서 각 pod의 조각 모음 작업 간에 클러스터가 정상 작동을 재개할 수 있도록 1분 이상 대기해야 합니다.

각 etcd 멤버의 etcd 데이터 조각 모음을 수행하려면 다음 절차를 따릅니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 리더가 최종 조각화 처리를 수행하므로 어떤 etcd 멤버가 리더인지 확인합니다.

    1. etcd pod 목록을 가져옵니다. 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>
      Copy to Clipboard Toggle word wrap

    2. Pod를 선택하고 다음 명령을 실행하여 어떤 etcd 멤버가 리더인지 확인합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      이 출력의 IS LEADER 열에 따르면 https://10.0.199.170:2379 엔드 포인트가 리더입니다. 이전 단계의 출력과 이 앤드 포인트가 일치하면 리더의 Pod 이름은 etcd-ip-10-0199-170.example.redhat.com입니다.

  2. etcd 멤버를 분리합니다.

    1. 실행중인 etcd 컨테이너에 연결하고 리더가 아닌 pod 이름을 전달합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
      Copy to Clipboard Toggle word wrap

    2. ETCDCTL_ENDPOINTS 환경 변수를 설정 해제합니다. 

      sh-4.4# unset ETCDCTL_ENDPOINTS
      Copy to Clipboard Toggle word wrap

    3. etcd 멤버를 분리합니다. 

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
      Copy to Clipboard Toggle word wrap

      출력 예

      Finished defragmenting etcd member[https://localhost:2379]
      Copy to Clipboard Toggle word wrap

      시간 초과 오류가 발생하면 명령이 성공할 때까지 --command-timeout 의 값을 늘립니다.

    4. 데이터베이스 크기가 감소되었는지 확인합니다. 

      sh-4.4# etcdctl endpoint status -w table --cluster
      Copy to Clipboard Toggle word wrap

      출력 예

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        |
      1 
      
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      이 예에서는 etcd 멤버의 데이터베이스 크기가 시작 크기인 104MB와 달리 현재 41MB임을 보여줍니다.

    5. 다음 단계를 반복하여 다른 etcd 멤버에 연결하고 조각 모음을 수행합니다. 항상 리더의 조각 모음을 마지막으로 수행합니다.

      etcd pod가 복구될 수 있도록 조각 모음 작업에서 1분 이상 기다립니다. etcd pod가 복구될 때까지 etcd 멤버는 응답하지 않습니다.

  3. 공간 할당량을 초과하여 NOSPACE 경고가 발생하는 경우 이를 지우십시오.

    1. NOSPACE 경고가 있는지 확인합니다. 

      sh-4.4# etcdctl alarm list
      Copy to Clipboard Toggle word wrap

      출력 예

      memberID:12345678912345678912 alarm:NOSPACE
      Copy to Clipboard Toggle word wrap

    2. 경고를 지웁니다. 

      sh-4.4# etcdctl alarm disarm
      Copy to Clipboard Toggle word wrap

4.12.7. 두 개 이상의 노드에 대해 이전 클러스터 상태로 복원
링크 복사

저장된 etcd 백업을 사용하여 이전 클러스터 상태를 복원하거나 대부분의 제어 평면 호스트를 손실한 클러스터를 복원할 수 있습니다.

HA(고가용성) 클러스터의 경우 3 노드 HA 클러스터를 종료하여 클러스터 분할을 방지하기 위해 두 호스트에서 etcd를 종료해야 합니다. 4-node 및 5-노드 HA 클러스터에서 호스트 3개를 종료해야 합니다. 쿼럼에는 노드의 단순 과반수가 필요합니다. 3-노드 HA 클러스터에서 쿼럼에 필요한 최소 노드 수는 2개입니다. 4-node 및 5-노드 HA 클러스터에서 쿼럼에 필요한 최소 노드 수는 3개입니다. 복구 호스트에서 백업을 통해 새 클러스터를 시작하면 다른 etcd 멤버가 여전히 쿼럼을 형성하고 서비스를 계속할 수 있습니다.

참고

클러스터가 컨트롤 플레인 머신 세트를 사용하는 경우 etcd 복구 절차에 대한 "컨트롤 플레인 머신 세트 문제 해결"의 "성능이 저하된 etcd Operator 복구"를 참조하세요. 단일 노드의 OpenShift Container Platform의 경우 "단일 노드의 이전 클러스터 상태로 복원"을 참조하세요.

중요

클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어, OpenShift Container Platform 4.19.2 클러스터는 4.19.2에서 가져온 etcd 백업을 사용해야 합니다.

사전 요구 사항

  • 설치 중에 사용된 것과 같은 인증서 기반 kubeconfig 파일을 통해 cluster-admin 역할이 있는 사용자로 클러스터에 액세스합니다.
  • 복구 호스트로 사용할 정상적인 컨트롤 플레인 호스트가 있어야 합니다.
  • 제어 평면 호스트에 SSH 액세스 권한이 있습니다.
  • 동일한 백업에서 가져온 etcd 스냅샷과 정적 pod의 리소스가 모두 포함된 백업 디렉토리입니다. 디렉토리의 파일 이름은 snapshot_<datetimestamp>.db 및 static_kuberesources_<datetimestamp>.tar.gz 형식이어야합니다.
  • 노드는 접근 가능하거나 부팅 가능해야 합니다.
중요

복구가 불가능한 제어 평면 노드의 경우 SSH 연결을 설정하거나 정적 포드를 중지할 필요가 없습니다. 다른 비복구 제어 평면 머신을 하나씩 삭제하고 다시 생성할 수 있습니다.

프로세스

  1. 복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복원 작업을 실행하는 호스트입니다.

  2. 복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.

    복구 프로세스가 시작된 후에는 kube-apiserver 에 액세스할 수 없게 되어 제어 평면 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.

    중요

    이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.

  3. SSH를 사용하여 각 제어 평면 노드에 연결하고 다음 명령을 실행하여 etcd를 비활성화합니다. 

    $ sudo -E /usr/local/bin/disable-etcd.sh
    Copy to Clipboard Toggle word wrap

  4. etcd 백업 디렉토리를 복구 컨트롤 플레인 호스트에 복사합니다.

    이 단계에서는 etcd 스냅샷 및 정적 pod의 리소스가 포함된 backup 디렉터리를 복구 컨트롤 플레인 호스트의 /home/core/ 디렉터리에 복사하는 것을 전제로하고 있습니다.

  5. SSH를 사용하여 복구 호스트에 연결하고 다음 명령을 실행하여 이전 백업에서 클러스터를 복원합니다. 

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
    Copy to Clipboard Toggle word wrap
  6. SSH 세션을 종료합니다.

  7. API가 응답하면 다음 명령을 실행하여 etcd Operator 쿼럼 가드를 끕니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 제어 평면의 복구 진행 상황을 모니터링합니다. 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap
    참고

    제어 평면이 복구되는 데 최대 15분이 걸릴 수 있습니다.

  9. 복구가 완료되면 다음 명령을 실행하여 쿼럼 가드를 활성화합니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

문제 해결

etcd 정적 포드 롤아웃에 진행 상황이 보이지 않으면 다음 명령을 실행하여 cluster-etcd-operator 에서 강제로 재배포할 수 있습니다. 

$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Toggle word wrap

4.12.8. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법
링크 복사

OpenShift Container Platform 클러스터에서 모든 형식의 영구저장장치를 사용하는 경우 일반적으로 클러스터의 상태가 etcd 외부에 저장됩니다. StatefulSet 오브젝트에서 실행 중인 Pod 또는 데이터베이스에서 실행 중인 Elasticsearch 클러스터일 수 있습니다. etcd 백업에서 복원하면 OpenShift Container Platform의 워크로드 상태도 복원됩니다. 그러나 etcd 스냅샷이 오래된 경우 상태가 유효하지 않거나 오래되었을 수 있습니다.

중요

PV(영구 볼륨)의 내용은 etcd 스냅샷의 일부가 아닙니다. etcd 스냅샷에서 OpenShift Container Platform 클러스터를 복원할 때 중요하지 않은 워크로드가 중요한 데이터에 액세스할 수 있으며 그 반대의 경우로도 할 수 있습니다.

다음은 사용되지 않는 상태를 생성하는 몇 가지 예제 시나리오입니다.

  • MySQL 데이터베이스는 PV 오브젝트에서 지원하는 pod에서 실행됩니다. etcd 스냅샷에서 OpenShift Container Platform을 복원해도 스토리지 공급자의 볼륨을 다시 가져오지 않으며 pod를 반복적으로 시작하려고 하지만 실행 중인 MySQL pod는 생성되지 않습니다. 스토리지 공급자에서 볼륨을 복원한 다음 새 볼륨을 가리키도록 PV를 편집하여 이 Pod를 수동으로 복원해야 합니다.
  • Pod P1에서는 노드 X에 연결된 볼륨 A를 사용합니다. 다른 pod가 노드 Y에서 동일한 볼륨을 사용하는 동안 etcd 스냅샷을 가져오는 경우 etcd 복원이 수행되면 해당 볼륨이 여전히 Y 노드에 연결되어 있으므로 Pod P1이 제대로 시작되지 않을 수 있습니다. OpenShift Container Platform은 연결을 인식하지 못하고 자동으로 연결을 분리하지 않습니다. 이 경우 볼륨이 노드 X에 연결된 다음 Pod P1이 시작될 수 있도록 노드 Y에서 볼륨을 수동으로 분리해야 합니다.
  • etcd 스냅샷을 만든 후 클라우드 공급자 또는 스토리지 공급자 인증 정보가 업데이트되었습니다. 이로 인해 해당 인증 정보를 사용하는 CSI 드라이버 또는 Operator가 작동하지 않습니다. 해당 드라이버 또는 Operator에 필요한 인증 정보를 수동으로 업데이트해야 할 수 있습니다.

  • etcd 스냅샷을 만든 후 OpenShift Container Platform 노드에서 장치가 제거되거나 이름이 변경됩니다. Local Storage Operator는 /dev/disk/by-id 또는 /dev 디렉터리에서 관리하는 각 PV에 대한 심볼릭 링크를 생성합니다. 이 경우 로컬 PV가 더 이상 존재하지 않는 장치를 참조할 수 있습니다.

    이 문제를 해결하려면 관리자가 다음을 수행해야 합니다.

    1. 잘못된 장치가 있는 PV를 수동으로 제거합니다.
    2. 각 노드에서 심볼릭 링크를 제거합니다.
    3. LocalVolume 또는 LocalVolumeSet 오브젝트를 삭제합니다 (스토리지 영구 스토리지 구성 로컬 볼륨을 사용하는 영구 스토리지 Local Storage Operator 리소스 삭제참조).
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat