4.10. etcd 작업
etcd를 백업하거나 etcd 암호화를 활성화 또는 비활성화하거나 etcd 데이터 조각 모음을 실행합니다.
4.10.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.10.2. etcd 암호화 활성화
etcd 암호화를 활성화하여 클러스터에서 중요한 리소스를 암호화할 수 있습니다.
초기 암호화 프로세스가 완료될 때까지 etcd 리소스를 백업하지 마십시오. 암호화 프로세스가 완료되지 않으면 백업이 부분적으로만 암호화될 수 있습니다.
etcd 암호화를 활성화하면 다음과 같은 몇 가지 변경이 발생할 수 있습니다.
- etcd 암호화는 몇 가지 리소스의 메모리 사용에 영향을 줄 수 있습니다.
- 리더가 백업을 제공해야 하기 때문에 백업 성능에 일시적인 영향을 미칠 수 있습니다.
- 디스크 I/O는 백업 상태를 수신하는 노드에 영향을 줄 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
APIServer
오브젝트를 수정합니다.$ oc edit apiserver
암호화
필드 유형을aescbc
로 설정합니다.spec: encryption: type: aescbc 1
- 1
aescbc
유형은 PKCS# 7 패딩 및 32바이트 키가 있는 AES-CBC가 암호화를 수행하는 데 사용됨을 나타냅니다.
파일을 저장하여 변경 사항을 적용합니다.
암호화 프로세스가 시작됩니다. 클러스터 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.
etcd 암호화에 성공했는지 확인합니다.
OpenShift API 서버의
Encrypted
상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
암호화에 성공하면 출력에
EncryptionCompleted
가 표시됩니다.EncryptionCompleted All resources encrypted: routes.route.openshift.io
출력에
EncryptionInProgress
가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.쿠버네티스 API 서버의
Encrypted
상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
암호화에 성공하면 출력에
EncryptionCompleted
가 표시됩니다.EncryptionCompleted All resources encrypted: secrets, configmaps
출력에
EncryptionInProgress
가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.OpenShift OAuth API 서버의
Encrypted
상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.$ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
암호화에 성공하면 출력에
EncryptionCompleted
가 표시됩니다.EncryptionCompleted All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
출력에
EncryptionInProgress
가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.
4.10.3. etcd 암호화 비활성화
클러스터에서 etcd 데이터의 암호화를 비활성화할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
APIServer
오브젝트를 수정합니다.$ oc edit apiserver
암호화
필드 유형을identity
로 설정합니다.spec: encryption: type: identity 1
- 1
identity
유형이 기본값이며, 이는 암호화가 수행되지 않음을 의미합니다.
파일을 저장하여 변경 사항을 적용합니다.
암호 해독 프로세스가 시작됩니다. 클러스터 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.
etcd 암호 해독에 성공했는지 확인합니다.
OpenShift API 서버의
Encrypted
상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
암호 해독에 성공하면 출력에
DecryptionCompleted
가 표시됩니다.DecryptionCompleted Encryption mode set to identity and everything is decrypted
출력에
DecryptionInProgress
가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.쿠버네티스 API 서버의
Encrypted
상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
암호 해독에 성공하면 출력에
DecryptionCompleted
가 표시됩니다.DecryptionCompleted Encryption mode set to identity and everything is decrypted
출력에
DecryptionInProgress
가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.OpenShift API 서버의
Encrypted
상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.$ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
암호 해독에 성공하면 출력에
DecryptionCompleted
가 표시됩니다.DecryptionCompleted Encryption mode set to identity and everything is decrypted
출력에
DecryptionInProgress
가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.
4.10.4. etcd 데이터 백업
다음 단계에 따라 etcd 스냅샷을 작성하고 정적 pod의 리소스를 백업하여 etcd 데이터를 백업합니다. 이 백업을 저장하여 etcd를 복원해야하는 경우 나중에 사용할 수 있습니다.
단일 컨트롤 플레인 호스트(마스터 호스트라고도 함)의 백업만 저장합니다. 클러스터의 각 컨트롤 플레인 호스트에서 백업을 수행하지 마십시오.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. 클러스터 전체의 프록시가 활성화되어 있는지 확인해야 합니다.
작은 정보oc get proxy cluster -o yaml
의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다.httpProxy
,httpsProxy
및noProxy
필드에 값이 설정되어 있으면 프록시가 사용됩니다.
절차
컨트롤 플레인 노드의 디버그 세션을 시작합니다.
$ oc debug node/<node_name>
루트 디렉토리를
/host
로 변경합니다.sh-4.2# chroot /host
-
클러스터 전체의 프록시가 활성화되어 있는 경우
NO_PROXY,
HTTP_PROXY
및https_proxy
환경 변수를 내보내고 있는지 확인합니다. 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
스크립트 출력 예
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
이 예제에서는 컨트롤 플레인 호스트의
/home/core/assets/backup/
디렉토리에 두 개의 파일이 생성됩니다.-
snapshot_<datetimestamp>.db
: 이 파일은 etcd 스냅샷입니다.cluster-backup.sh
스크립트는 유효성을 확인합니다. static_kuberesources_<datetimestamp>.tar.gz
: 이 파일에는 정적 포드 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.참고etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.
etcd 암호화는 키가 아닌 값만 암호화합니다. 즉, 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.
-
4.10.5. etcd 데이터 분리
대규모 및 밀도가 높은 클러스터의 경우 키 공간이 너무 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. 정기적으로 etcd를 유지 관리하고 조각 모음하여 데이터 저장소의 공간을 확보합니다. etcd 지표에 대한 Prometheus를 모니터링하고 필요한 경우 조각 모음을 모니터링하십시오. 그러지 않으면 etcd에서 키 읽기 및 삭제만 수락하는 유지 관리 모드로 클러스터를 배치하는 클러스터 전체 알람을 생성할 수 있습니다.
다음 주요 메트릭을 모니터링합니다.
-
etcd_server_quota_backend_bytes
, 현재 할당량 제한 -
etcd_mvcc_db_total_size_in_use_in_bytes
. 이는 기록 압축 후 실제 데이터베이스 사용량을 나타냅니다. -
etcd_debugging_mvcc_db_total_size_in_bytes
. 여기에는 조각 모음 대기 중인 여유 공간을 포함하여 데이터베이스 크기가 표시됩니다.
etcd 기록 압축과 같은 디스크 조각화를 초래하는 이벤트 후 디스크 공간을 회수하기 위해 etcd 데이터를 조각 모음합니다.
기록 압축은 5분마다 자동으로 수행되며 백엔드 데이터베이스에서 공백이 남습니다. 이 분할된 공간은 etcd에서 사용할 수 있지만 호스트 파일 시스템에서 사용할 수 없습니다. 호스트 파일 시스템에서 이 공간을 사용할 수 있도록 etcd 조각을 정리해야 합니다.
etcd는 디스크에 데이터를 쓰기 때문에 etcd 성능은 디스크 성능에 따라 크게 달라집니다. 매달 또는 한달에 한 두 번 또는 클러스터에 필요한 경우 etcd를 조각을 정리하는 것이 좋습니다. etcd_db_total_size_in_bytes
메트릭을 모니터링하여 조각 모음이 필요한지 여부를 결정할 수도 있습니다.
PromQL 표현식을 사용하여 조각 모음을 사용하여 해제할 etcd 데이터베이스 크기를 MB 단위로 확인하여 조각 모음이 필요한지 여부를 확인할 수도 있습니다. (etcd_mvcc_db_total_size_in_in_bytes - etcd_mvcc_in_in_use_in_bytes)/1024/1024
etcd를 분리하는 것은 차단 작업입니다. 조각화 처리가 완료될 때까지 etcd 멤버는 응답하지 않습니다. 따라서 각 pod의 조각 모음 작업 간에 클러스터가 정상 작동을 재개할 수 있도록 1분 이상 대기해야 합니다.
각 etcd 멤버의 etcd 데이터 조각 모음을 수행하려면 다음 절차를 따릅니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
절차
리더가 최종 조각화 처리를 수행하므로 어떤 etcd 멤버가 리더인지 확인합니다.
etcd pod 목록을 가져옵니다.
$ oc get pods -n openshift-etcd -o wide | grep -v quorum-guard | grep etcd
출력 예
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>
Pod를 선택하고 다음 명령을 실행하여 어떤 etcd 멤버가 리더인지 확인합니다.
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
출력 예
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.4.9 | 104 MB | false | false | 7 | 91624 | 91624 | | | https://10.0.159.225:2379 | 264c7c58ecbdabee | 3.4.9 | 104 MB | false | false | 7 | 91624 | 91624 | | | https://10.0.199.170:2379 | 9ac311f93915cc79 | 3.4.9 | 104 MB | true | false | 7 | 91624 | 91624 | | +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
이 출력의
IS
LEADER 열에 따르면https://10.0.199.170:2379
엔드 포인트가 리더입니다. 이전 단계의 출력과 이 앤드 포인트가 일치하면 리더의 Pod 이름은etcd-ip-10-0199-170.example.redhat.com
입니다.
etcd 멤버를 분리합니다.
실행중인 etcd 컨테이너에 연결하고 리더가 아닌 pod 이름을 전달합니다.
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
ETCDCTL_ENDPOINTS
환경 변수를 설정 해제합니다.sh-4.4# unset ETCDCTL_ENDPOINTS
etcd 멤버를 분리합니다.
sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
출력 예
Finished defragmenting etcd member[https://localhost:2379]
시간 초과 오류가 발생하면 명령이 성공할 때까지
--command-timeout
의 값을 늘립니다.데이터베이스 크기가 감소되었는지 확인합니다.
sh-4.4# etcdctl endpoint status -w table --cluster
출력 예
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | 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.4.9 | 104 MB | false | false | 7 | 91624 | 91624 | | | https://10.0.159.225:2379 | 264c7c58ecbdabee | 3.4.9 | 41 MB | false | false | 7 | 91624 | 91624 | | 1 | https://10.0.199.170:2379 | 9ac311f93915cc79 | 3.4.9 | 104 MB | true | false | 7 | 91624 | 91624 | | +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
이 예에서는 etcd 멤버의 데이터베이스 크기가 시작 크기인 104MB와 달리 현재 41MB임을 보여줍니다.
다음 단계를 반복하여 다른 etcd 멤버에 연결하고 조각 모음을 수행합니다. 항상 리더의 조각 모음을 마지막으로 수행합니다.
etcd pod가 복구될 수 있도록 조각 모음 작업에서 1분 이상 기다립니다. etcd pod가 복구될 때까지 etcd 멤버는 응답하지 않습니다.
공간 할당량을 초과하여
NOSPACE
경고가 발생하는 경우 이를 지우십시오.NOSPACE
경고가 있는지 확인합니다.sh-4.4# etcdctl alarm list
출력 예
memberID:12345678912345678912 alarm:NOSPACE
경고를 지웁니다.
sh-4.4# etcdctl alarm disarm
4.10.6. 이전 클러스터 상태로 복원
저장된 etcd 백업을 사용하여 이전 클러스터 상태를 복원하거나 컨트롤 플레인 호스트 (마스터 호스트라고도 함)가 손실된 클러스터를 복원할 수 있습니다.
클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어 OpenShift Container Platform 4.7.2 클러스터는 4.7.2에서 가져온 etcd 백업을 사용해야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 복구 호스트로 사용할 정상적인 컨트롤 플레인 호스트가 있어야 합니다.
- 컨트롤 플레인 호스트에 대한 SSH 액세스.
-
동일한 백업에서 가져온 etcd 스냅샷과 정적 pod 리소스가 모두 포함된 백업 디렉토리입니다. 디렉토리의 파일 이름은
snapshot_<datetimestamp>.db
및static_kuberesources_<datetimestamp>.tar.gz
형식이어야합니다.
복구되지 않은 컨트롤 플레인 노드의 경우 SSH 연결을 설정하거나 정적 Pod를 중지할 필요가 없습니다. 복구되지 않은 다른 컨트롤 플레인 시스템을 하나씩 삭제하고 다시 생성할 수 있습니다.
프로세스
- 복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복구 작업을 실행할 호스트입니다.
복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.
복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.
중요이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.
etcd 백업 디렉토리를 복구 컨트롤 플레인 호스트에 복사합니다.
이 단계에서는 etcd 스냅샷 및 정적 pod의 리소스가 포함된
backup
디렉터리를 복구 컨트롤 플레인 호스트의/home/core/
디렉터리에 복사하는 것을 전제로하고 있습니다.다른 컨트롤 플레인 노드에서 고정 Pod를 중지합니다.
참고복구 호스트에서 pod를 수동으로 중지할 필요는 없습니다. 복구 스크립트는 복구 호스트에서 pod를 중지합니다.
- 복구 호스트가 아닌 컨트롤 플레인 호스트에 액세스합니다.
kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.
$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
etcd pod가 중지되었는지 확인합니다.
$ sudo crictl ps | grep etcd | grep -v operator
이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.
kubelet 매니페스트 디렉토리에서 기존 Kubernetes API 서버 pod 파일을 이동합니다.
$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
Kubernetes API 서버 pod가 중지되었는지 확인합니다.
$ sudo crictl ps | grep kube-apiserver | grep -v operator
이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.
etcd 데이터 디렉토리를 다른 위치로 이동합니다.
$ sudo mv /var/lib/etcd/ /tmp
- 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
- 복구 컨트롤 플레인 호스트에 액세스합니다.
클러스터 전체의 프록시가 활성화되어 있는 경우
NO_PROXY,
HTTP_PROXY
및https_proxy
환경 변수를 내보내고 있는지 확인합니다.작은 정보oc get proxy cluster -o yaml
의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다.httpProxy
,httpsProxy
및noProxy
필드에 값이 설정되어 있으면 프록시가 사용됩니다.복구 컨트롤 플레인 호스트에서 복원 스크립트를 실행하고 etcd 백업 디렉터리에 경로를 전달합니다.
$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup
스크립트 출력 예
...stopping kube-scheduler-pod.yaml ...stopping kube-controller-manager-pod.yaml ...stopping etcd-pod.yaml ...stopping kube-apiserver-pod.yaml Waiting for container etcd to stop .complete Waiting for container etcdctl to stop .............................complete Waiting for container etcd-metrics to stop complete Waiting for container kube-controller-manager to stop complete Waiting for container kube-apiserver to stop ..........................................................................................complete Waiting for container kube-scheduler to stop complete Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup starting restore-etcd static pod starting kube-apiserver-pod.yaml static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml starting kube-controller-manager-pod.yaml static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml starting kube-scheduler-pod.yaml static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml
참고복원 프로세스에서는 마지막 etcd 백업 후 노드 인증서가 업데이트된 경우 노드가
NotReady
상태가 될 수 있습니다.노드를 확인하여
Ready
상태인지 확인합니다.다음 명령을 실행합니다.
$ oc get nodes -w
샘플 출력
NAME STATUS ROLES AGE VERSION host-172-25-75-28 Ready master 3d20h v1.23.3+e419edf host-172-25-75-38 Ready infra,worker 3d20h v1.23.3+e419edf host-172-25-75-40 Ready master 3d20h v1.23.3+e419edf host-172-25-75-65 Ready master 3d20h v1.23.3+e419edf host-172-25-75-74 Ready infra,worker 3d20h v1.23.3+e419edf host-172-25-75-79 Ready worker 3d20h v1.23.3+e419edf host-172-25-75-86 Ready worker 3d20h v1.23.3+e419edf host-172-25-75-98 Ready infra,worker 3d20h v1.23.3+e419edf
모든 노드가 상태를 보고하는 데 몇 분이 걸릴 수 있습니다.
NotReady
상태에 있는 노드가 있는 경우 노드에 로그인하고 각 노드의/var/lib/kubelet/pki
디렉터리에서 모든 PEM 파일을 제거합니다. 노드에 SSH로 액세스하거나 웹 콘솔의 터미널 창을 사용할 수 있습니다.$ ssh -i <ssh-key-path> core@<master-hostname>
샘플
pki
디렉터리sh-4.4# pwd /var/lib/kubelet/pki sh-4.4# ls kubelet-client-2022-04-28-11-24-09.pem kubelet-server-2022-04-28-11-24-15.pem kubelet-client-current.pem kubelet-server-current.pem
모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.
복구 호스트에서 다음 명령을 실행합니다.
$ sudo systemctl restart kubelet.service
- 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
보류 중인 CSR을 승인합니다.
현재 CSR의 목록을 가져옵니다.
$ oc get csr
출력 예
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-2s94x 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 1 csr-4bd6t 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 2 csr-4hl85 13m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 3 csr-zhhhp 3m8s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 4 ...
CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.
$ oc describe csr <csr_name> 1
- 1
<csr_name>
은 현재 CSR 목록에 있는 CSR의 이름입니다.
각각의 유효한
node-bootstrapper
CSR을 승인합니다.$ oc adm certificate approve <csr_name>
사용자 프로비저닝 설치의 경우 각 유효한 kubelet 서비스 CSR을 승인합니다.
$ oc adm certificate approve <csr_name>
단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.
복구 호스트에서 etcd 컨테이너가 실행 중인지 확인합니다.
$ sudo crictl ps | grep etcd | grep -v operator
출력 예
3ad41b7908e32 36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009 About a minute ago Running etcd 0 7c05f8af362f0
복구 호스트에서 etcd pod가 실행 중인지 확인합니다.
$ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
참고이 명령을 실행하기 전에
oc login
을 실행하여 다음 오류가 발생하면 인증 컨트롤러가 시작될 때까지 잠시 기다렸다가 다시 시도하십시오.Unable to connect to the server: EOF
출력 예
NAME READY STATUS RESTARTS AGE etcd-ip-10-0-143-125.ec2.internal 1/1 Running 1 2m47s
Pending
상태에 있거나 출력에 여러 실행중인 etcd pod가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.- 복구 호스트가 아닌 각 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.
복구되지 않은 다른 컨트롤 플레인 시스템을 하나씩 삭제하고 다시 생성합니다. 이러한 머신이 다시 생성되면 새 버전이 강제 적용되고 etcd가 자동으로 확장됩니다.
설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 생성하는 데 사용된 방법과 동일한 방법으로 새 컨트롤 플레인 노드를 생성해야 합니다.
주의복구 호스트에 대한 시스템을 삭제하고 다시 생성하지 마십시오.
손실된 컨트롤 플레인 호스트 중 하나에 대한 시스템을 가져옵니다.
cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-0 Running m4.xlarge us-east-1 us-east-1a 3h37m ip-10-0-131-183.ec2.internal aws:///us-east-1a/i-0ec2782f8287dfb7e stopped 1 clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
- 1
- 이는 손실된 컨트롤 플레인 호스트
ip-10-0-131-183.ec2.internal의 컨트롤 플레인 시스템입니다.
시스템 설정을 파일 시스템의 파일에 저장합니다.
$ oc get machine clustername-8qw5l-master-0 \ 1 -n openshift-machine-api \ -o yaml \ > new-master-machine.yaml
- 1
- 손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.
이전 단계에서 만든
new-master-machine.yaml
파일을 편집하여 새 이름을 할당하고 불필요한 필드를 제거합니다.전체
status
섹션을 삭제합니다.status: addresses: - address: 10.0.131.183 type: InternalIP - address: ip-10-0-131-183.ec2.internal type: InternalDNS - address: ip-10-0-131-183.ec2.internal type: Hostname lastUpdated: "2020-04-20T17:44:29Z" nodeRef: kind: Node name: ip-10-0-131-183.ec2.internal uid: acca4411-af0d-4387-b73e-52b2484295ad phase: Running providerStatus: apiVersion: awsproviderconfig.openshift.io/v1beta1 conditions: - lastProbeTime: "2020-04-20T16:53:50Z" lastTransitionTime: "2020-04-20T16:53:50Z" message: machine successfully created reason: MachineCreationSucceeded status: "True" type: MachineCreation instanceId: i-0fdb85790d76d0c3f instanceState: stopped kind: AWSMachineProviderStatus
metadata.name
필드를 새 이름으로 변경합니다.이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서는
clustername-8qw5l-master-0
이clustername-8qw5l-master-3
으로 변경되었습니다.apiVersion: machine.openshift.io/v1beta1 kind: Machine metadata: ... name: clustername-8qw5l-master-3 ...
spec.providerID
필드를 삭제합니다.providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
metadata.annotations
및metadata.generation
필드를 제거합니다.annotations: machine.openshift.io/instance-state: running ... generation: 2
metadata.resourceVersion
및metadata.uid
필드를 제거합니다.resourceVersion: "13291" uid: a282eb70-40a2-4e89-8009-d05dd420d31a
손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다.
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
- 1
- 손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.
시스템이 삭제되었는지 확인합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
new-master-machine.yaml
파일을 사용하여 새 시스템을 만듭니다.$ oc apply -f new-master-machine.yaml
새 시스템이 생성되었는지 확인합니다.
$ oc get machines -n openshift-machine-api -o wide
출력 예:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-master-3 Provisioning m4.xlarge us-east-1 us-east-1a 85s ip-10-0-173-171.ec2.internal aws:///us-east-1a/i-015b0888fe17bc2c8 running 1 clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
- 1
- 새 시스템
clustername-8qw5l-master-3
이 생성되며 단계가Provisioning(
프로비저닝)에서Running
(실행 중)으로 변경된 후 준비됩니다.
새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.
- 복구 호스트가 아닌 각 손실된 컨트롤 플레인 호스트에 대해 다음 단계를 반복합니다.
별도의 터미널 창에서 다음 명령을 사용하여
cluster-admin
역할의 사용자로 클러스터에 로그인합니다.$ oc login -u <cluster_admin> 1
- 1
<cluster_admin>
은cluster-admin
역할을 사용하여 사용자 이름을 지정합니다.
etcd를 강제로 재배포합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
- 1
forceRedeploymentReason
값은 고유해야하므로 타임 스탬프가 추가됩니다.
etcd 클러스터 Operator가 재배포를 실행하면 기존 노드가 초기 부트 스트랩 확장과 유사한 새 pod를 사용하기 시작합니다.
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
etcd의
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.etcd를 재배포한 후 컨트롤 플레인에 새 롤아웃을 강제 실행합니다. kubelet이 내부 로드 밸런서를 사용하여 API 서버에 연결되어 있으므로 Kubernetes API 서버는 다른 노드에 다시 설치됩니다.
cluster-admin
사용자로 클러스터에 액세스할 수있는 터미널에서 다음 명령을 실행합니다.Kubernetes API 서버에 대해 새 롤아웃을 강제 적용합니다.
$ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.Kubernetes 컨트롤러 관리자에 대해 새 롤아웃을 강제 적용합니다.
$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
$ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.Kubernetes 스케줄러에 대해 새 롤아웃을 강제 적용합니다.
$ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
$ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
NodeInstallerProgressing
상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에AllNodesAtLatestRevision
이 표시됩니다.AllNodesAtLatestRevision 3 nodes are at revision 7 1
- 1
- 이 예에서 최신 버전 번호는
7
입니다.
출력에
2 nodes are at revision 6; 1 nodes are at revision 7
와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.
모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.
클러스터에 액세스할 수 있는 터미널에서
cluster-admin
사용자로 다음 명령을 실행합니다.$ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
출력 예
etcd-ip-10-0-143-125.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-154-194.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-173-171.ec2.internal 2/2 Running 0 9h
복구 절차 후 모든 워크로드가 정상 작업으로 돌아가도록 하려면 Kubernetes API 정보를 저장하는 각 Pod를 다시 시작합니다. 여기에는 라우터, Operator 및 타사 구성 요소와 같은 OpenShift Container Platform 구성 요소가 포함됩니다.
이 프로세스를 완료한 후 모든 서비스를 복구하는데 몇 분 정도 걸릴 수 있습니다. 예를 들어, OAuth 서버 pod가 다시 시작될 때까지 oc login
을 사용한 인증이 즉시 작동하지 않을 수 있습니다.
4.10.7. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법
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가 더 이상 존재하지 않는 장치를 참조할 수 있습니다.이 문제를 해결하려면 관리자가 다음을 수행해야 합니다.
- 잘못된 장치가 있는 PV를 수동으로 제거합니다.
- 각 노드에서 심볼릭 링크를 제거합니다.
-
LocalVolume
또는LocalVolumeSet
오브젝트를 삭제합니다 (스토리지영구 스토리지 구성 로컬 볼륨을 사용하는 영구 스토리지 Local Storage Operator 리소스 삭제참조).