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

etcd

OpenShift Container Platform 4.20

etcd에 중복 제공

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform의 클러스터 구성 및 복원력에 대한 안정적인 접근 방식을 보장하는 etcd 사용 방법을 설명합니다.

1장. etcd 개요
링크 복사

etcd(pronounced et-see-dee)는 메모리에 완전히 들어갈 수 있는 머신 클러스터에 적은 양의 데이터를 저장하는 일관된 분산 키-값 저장소입니다. 많은 프로젝트의 핵심 구성 요소로서 etcd는 컨테이너 오케스트레이션의 표준 시스템인 Kubernetes의 기본 데이터 저장소이기도 합니다.

etcd를 사용하면 다음과 같은 여러 가지 방법으로 이점을 누릴 수 있습니다.

  • 클라우드 네이티브 애플리케이션에 대한 지속적인 가동 시간을 지원하고 개별 서버가 실패하는 경우에도 계속 작동합니다.
  • Kubernetes의 모든 클러스터 상태 저장 및 복제
  • 구성 데이터를 배포하여 노드 구성에 대한 중복성 및 복원력 제공
중요

기본 etcd 구성은 컨테이너 오케스트레이션을 최적화합니다. 최상의 결과를 위해 설계된 대로 사용하십시오.

1.1. etcd 작동 방식
링크 복사

클러스터 구성 및 관리에 대한 안정적인 접근 방식을 보장하기 위해 etcd는 etcd Operator를 사용합니다. Operator는 OpenShift Container Platform과 같은 Kubernetes 컨테이너 플랫폼에서 etcd를 사용하는 것을 단순화합니다.

또한 etcd Operator를 사용하여 OpenShift Container Platform 컨트롤 플레인의 etcd 클러스터를 배포하고 관리할 수 있습니다. etcd Operator는 다음과 같은 방식으로 클러스터 상태를 관리합니다.

  • Kubernetes API를 사용하여 클러스터 상태 관찰
  • 현재 상태와 필요한 상태 간의 차이점 분석
  • etcd 클러스터 관리 API, Kubernetes API 또는 둘 다를 통해 차이점을 수정합니다.
참고

etcd에는 클러스터 상태가 있으며 이는 지속적으로 업데이트됩니다. 이 상태는 지속적으로 유지되므로 높은 빈도로 인해 작은 변화가 많이 발생합니다. 따라서 빠르고 대기 시간이 짧은 I/O로 etcd 클러스터 멤버를 백업하는 것이 중요합니다. etcd의 모범 사례에 대한 자세한 내용은 "etcd에 대한 권장 사례"를 참조하십시오.

1.2. etcd 성능 이해
링크 복사

복제된 노드의 클러스터로 작동하는 일관된 분산 키-값 저장소로서 etcd는 하나의 노드를 리더로 선택하고 다른 노드를 리더로 선택하여 Raft 알고리즘을 따릅니다. 리더는 시스템 현재 상태의 현재 상태를 유지하고 맹인을 최신 상태로 유지합니다.

리더 노드는 로그 복제를 담당합니다. 클라이언트에서 들어오는 쓰기 트랜잭션을 처리하고 팔로우에게 브로드캐스트한 Raft 로그 항목을 작성합니다.

kube-apiserver 와 같은 etcd 클라이언트가 쿼럼이 필요한 작업을 요청하는 etcd 멤버(예: etcd 멤버가 follower인 경우)에 연결하면 트랜잭션이 리더로 이동해야 함을 나타내는 메시지를 반환합니다.

etcd 클라이언트가 값 작성과 같이 쿼럼이 필요한 리더의 작업을 요청하면 리더는 로컬 Raft 로그를 쓰는 동안 클라이언트 연결을 열린 상태로 유지 관리하고, 팔로우에게 로그를 브로드캐스트하고, 대다수가 실패 없이 로그를 커밋하도록 승인할 때까지 기다립니다. 리더는 승인을 etcd 클라이언트에 전송하고 세션을 종료합니다. 실패 알림은 미용사로부터 수신되고 합의가 충족되지 않으면 리더는 클라이언트에게 오류 메시지를 반환하고 세션을 종료합니다.

etcd의 OpenShift Container Platform 타이머 조건

OpenShift Container Platform은 각 플랫폼에 최적화된 etcd 타이머를 유지 관리합니다. OpenShift Container Platform에는 각 플랫폼 공급자에 최적화된 검증 값이 지정되어 있습니다. platform=none 또는 platform=metal 값이 있는 기본 etcd 타이머 매개변수는 다음과 같습니다. 

- name: ETCD_ELECTION_TIMEOUT
1 

  value: "1000"
  ...
- name: ETCD_HEARTBEAT_INTERVAL
2 

  value: "100"
Copy to Clipboard Toggle word wrap
1
이 시간 초과는 후속 노드가 리더가 되기 전에 하트비트를 관찰하지 않고 대기하는 시간입니다.
2
리더가 여전히 리더임을 알리는 빈도입니다.

이러한 매개변수는 컨트롤 플레인 또는 etcd에 대한 모든 정보를 제공하지 않습니다. etcd 클러스터는 디스크 대기 시간에 민감합니다. etcd는 로그에 대한 제안을 유지해야 하므로 다른 프로세스의 디스크 작업으로 인해 fsync 대기 시간이 길어질 수 있습니다. 그 결과 etcd에서 하트비트가 누락되어 요청 시간 초과 및 일시적으로 리더 손실이 발생할 수 있습니다. 리더 손실 및 복원 중에 Kubernetes API는 클러스터에 영향을 미치는 이벤트 및 불안정성을 유발하는 요청을 처리할 수 없습니다.

etcd에서 디스크 대기 시간 영향

etcd 클러스터는 디스크 대기 시간에 민감합니다. 컨트롤 플레인 환경에서 etcd에서 etcd가 경험하는 디스크 대기 시간을 이해하려면 유연한 I/O Tester(fio) 테스트 또는 제품군을 실행하여 OpenShift Container Platform에서 etcd 디스크 성능을 확인합니다.

중요

fio 테스트만 사용하여 특정 시점에서 디스크 대기 시간을 측정합니다. 이 테스트는 프로덕션 환경에서 etcd에서 발생하는 장기 디스크 동작 및 기타 디스크 워크로드를 고려하지 않습니다.

다음 예와 같이 최종 보고서가 etcd에 대해 디스크를 적절하게 분류하는지 확인합니다. 

...
99th percentile of fsync is 5865472 ns
99th percentile of the fsync is within the suggested threshold: - 20 ms, the disk can be used to host etcd
Copy to Clipboard Toggle word wrap

대기 시간이 긴 디스크를 사용하는 경우 다음 예와 같이 etcd에 대한 디스크가 권장되지 않음을 알리는 메시지가 표시됩니다. 

...
99th percentile of fsync is 15865472 ns
99th percentile of the fsync is greater than the suggested value which is 20 ms, faster disks are suggested to host etcd for better performance
Copy to Clipboard Toggle word wrap

클러스터 배포가 제안된 대기 시간을 충족하지 않는 etcd에 디스크를 사용하는 많은 데이터 센터에 걸쳐 있으면 서비스 영향을 미치는 오류가 발생할 수 있습니다. 또한 컨트롤 플레인에서 유지할 수 있는 네트워크 대기 시간이 크게 단축됩니다.

etcd에서 네트워크 대기 시간 및 지터의 영향

MTU(최대 전송 단위) 검색 및 검증 섹션에 설명된 툴을 사용하여 평균 및 최대 네트워크 대기 시간을 확보합니다.

하트비트 간격의 값은 멤버 간의 평균 Round-trip 시간 (RTT)의 최대 값이어야 합니다. 일반적으로 왕복 시간보다 약 1.5 배입니다. OpenShift Container Platform의 기본 하트비트 간격이 100ms인 경우 컨트롤 플레인 노드 간 제안된 RTT는 33ms 미만이며 최대 66ms(66ms x 1.5 = 99ms)입니다. 더 큰 네트워크 대기 시간으로 인해 서비스 영향을 미치는 이벤트 및 클러스터 불안정성이 발생할 수 있습니다.

네트워크 대기 시간은 구리, 광섬유, 무선 또는 Satellite와 같은 전송 네트워크의 기술, 전송 네트워크의 네트워크 장치의 수 및 품질 및 기타 요소를 포함하는 요인에 의해 결정됩니다.

정확한 계산을 위해 네트워크 지터가 있는 네트워크 대기 시간을 고려하십시오. 네트워크 지터 는 네트워크 대기 시간 또는 수신된 패킷 지연의 차이입니다. 효율적인 네트워크 조건에서는 지터가 0이어야 합니다. 네트워크 지터는 시간이 지남에 따라 실제 네트워크 대기 시간이 RTT + 또는 - Jitter이므로 etcd의 네트워크 대기 시간 계산에 영향을 미칩니다.

예를 들어, 최대 대기 시간이 80ms이고 30ms의 지터가 있는 네트워크는 110ms의 대기 시간을 경험하므로 etcd는 하트비트를 놓치게 됩니다. 이 조건으로 인해 요청 시간 초과 및 임시 리더 손실이 발생합니다. 리더 손실 및 재지정 중에 Kubernetes API는 클러스터에 영향을 미치는 이벤트 및 불안정성을 유발하는 요청을 처리할 수 없습니다.

etcd에서 합의된 대기 시간으로 인한 영향

절차는 활성 클러스터에서만 실행할 수 있습니다. 클러스터 배포를 계획하는 동안 디스크 또는 네트워크 테스트를 완료해야 합니다. 이 테스트에서는 배포 후 클러스터 상태를 확인하고 모니터링합니다.

etcdctl CLI를 사용하면 etcd에서 경험한 대로 지연 시간에 도달할 수 있습니다. etcd pod 중 하나를 확인한 다음 엔드포인트 상태를 검색해야합니다.

etcd 피어 라운드 트립 시간은 성능에 영향을 미칩니다.

etcd 피어 트립 시간은 네트워크 라운드 트립 시간과 동일하지 않습니다. 이 계산은 멤버 간에 복제가 얼마나 빨리 발생할 수 있는지에 대한 엔드 투 엔드 테스트 메트릭입니다.

etcd 피어 트립 시간은 모든 etcd 멤버 간에 클라이언트 요청을 복제하기 위해 etcd의 대기 시간을 보여주는 메트릭입니다. OpenShift Container Platform 콘솔은 다양한 etcd 지표를 시각화하는 대시보드를 제공합니다. 콘솔에서 모니터링 → 대시보드 를 클릭합니다. 드롭다운 목록에서 etcd 를 선택합니다.

etcd 피어 라운드 트립 시간을 요약하는 플롯은 etcd 대시보드 페이지 끝에 있습니다.

etcd에 데이터베이스 크기에 미치는 영향

etcd 데이터베이스 크기는 etcd 조각 모음 프로세스를 완료하는 시간에 직접적인 영향을 미칩니다. OpenShift Container Platform은 45% 이상의 조각화가 감지되면 한 번에 하나의 etcd 멤버에서 etcd 조각 모음을 자동으로 실행합니다. 조각 모음 프로세스 중에 etcd 멤버는 요청을 처리할 수 없습니다. 소규모 etcd 데이터베이스에서 조각 모음 프로세스는 1초 미만으로 수행됩니다. 더 큰 etcd 데이터베이스를 사용하면 조각화 시간에 직접 디스크 대기 시간이 영향을 미치므로 조각 모음 중에 작업이 차단되므로 대기 시간이 추가로 발생합니다.

etcd 데이터베이스의 크기는 네트워크 파티션이 일정 기간 동안 컨트롤 플레인 노드를 격리할 때 고려해야 할 요소이며 통신을 다시 설정한 후 컨트롤 플레인을 동기화해야 합니다.

시스템의 Operator 및 애플리케이션에 따라 다르기 때문에 etcd 데이터베이스의 크기를 제어하기 위한 최소 옵션이 있습니다. 시스템이 작동하는 대기 시간 범위를 고려할 때 etcd 데이터베이스의 크기당 동기화 또는 조각 모음의 영향을 설명하십시오.

영향의 크기는 배포에 따라 다릅니다. etcd 멤버는 조각 모음 프로세스 중 업데이트를 수락할 수 없으므로 조각 모음을 완료하는 시간으로 인해 트랜잭션 속도 저하가 발생합니다. 마찬가지로 변경 속도가 높은 대규모 데이터베이스의 etcd 재동기화 시간은 시스템의 트랜잭션 속도 및 트랜잭션 대기 시간에 영향을 미칩니다. 계획할 영향 유형에 대해 다음 두 가지 예를 고려하십시오.

데이터베이스 크기에 따른 etcd 조각 모음의 첫 번째 예는 1GB의 etcd 데이터베이스를 초당 80Mb에서 느린 7200 RPM 디스크에 작성하는 데 약 1분 40초가 걸리는 것입니다. 이러한 시나리오에서는 조각 모음 프로세스를 완료하는 데 최소한 이 시간이 걸립니다.

etcd 동기화에 데이터베이스 크기가 미치는 영향의 두 번째 예는 컨트롤 플레인 노드 중 하나의 연결을 끊는 동안 etcd 데이터베이스의 10%가 변경되면 동기화에서 최소 100MB를 전송해야 한다는 것입니다. 1Gbps 링크를 통해 100MB를 전송하는 데는 800ms가 걸립니다. Kubernetes API를 사용한 일반 트랜잭션이 있는 클러스터에서 etcd 데이터베이스 크기가 클수록 네트워크 불안정으로 인해 컨트롤 플레인 불안정성이 발생합니다.

OpenShift Container Platform에서 etcd 대시보드에는 etcd 데이터베이스의 크기를 보고하는 플롯이 있습니다. 또는 etcdctl 툴을 사용하여 CLI에서 데이터베이스 크기를 가져올 수 있습니다. 

# oc get pods -n openshift-etcd -l app=etcd
Copy to Clipboard Toggle word wrap

출력 예

NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h
Copy to Clipboard Toggle word wrap 

# oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4
Copy to Clipboard Toggle word wrap

출력 예

https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB
Copy to Clipboard Toggle word wrap

etcd에서 Kubernetes API 트랜잭션 비율의 영향

확장된 컨트롤 플레인을 사용하는 경우 Kebernetes API 트랜잭션 속도는 특정 배포의 특성에 따라 다릅니다. etcd 디스크 대기 시간, etcd 왕복 시간 및 API에 기록된 오브젝트의 크기에 따라 다릅니다. 결과적으로 확장된 컨트롤 플레인을 사용할 때 클러스터 관리자는 환경에 가능한 지속적인 트랜잭션 속도를 결정하기 위해 환경을 테스트해야 합니다. kube-burner 툴을 이 용도로 사용할 수 있습니다.

사용자 환경에 대한 Kubernetes API 트랜잭션 속도 확인

Kubernetes API의 트랜잭션 속도를 측정하지 않고 확인할 수 없습니다. 컨트롤 플레인을 로드하는 데 사용되는 툴 중 하나는 kube-burner 입니다. 바이너리는 OpenShift Container Platform 클러스터를 테스트하기 위한 OpenShift Container Platform 래퍼를 제공합니다. 클러스터 또는 노드 밀도를 테스트하는 데 사용됩니다. 컨트롤 플레인 테스트를 위해 kube-burner ocp 에는 cluster-density , cluster-density -v2 및 cluster-density- ms 라는 세 가지 워크로드 프로필이 있습니다. 각 워크로드 프로파일은 컨트롤을 로드하도록 설계된 일련의 리소스를 생성합니다.

2장. etcd 관련 권장 사례
링크 복사

다음 문서에서는 etcd의 권장 성능 및 확장성 사례에 대한 정보를 제공합니다.

2.3. etcd 하드웨어 검증
링크 복사

OpenShift Container Platform 클러스터를 생성하기 전이나 후에 etcd의 하드웨어를 검증하려면 fio를 사용할 수 있습니다.

사전 요구 사항

  • Podman 또는 Docker와 같은 컨테이너 런타임은 테스트 중인 머신에 설치됩니다.
  • 데이터는 /var/lib/etcd 경로에 기록됩니다.

프로세스

  • Fio를 실행하고 결과를 분석합니다.

    • Podman을 사용하는 경우 다음 명령을 실행합니다. 

      $ sudo podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
      Copy to Clipboard Toggle word wrap

    • Docker를 사용하는 경우 다음 명령을 실행합니다. 

      $ sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
      Copy to Clipboard Toggle word wrap

출력에서는 실행에서 캡처된 fsync 지표의 99번째 백분위수를 비교하여 디스크가 etcd를 호스트할 수 있을 만큼 빠른지 여부를 보고하여 10ms 미만인지 확인합니다. I/O 성능의 영향을 받을 수 있는 가장 중요한 etcd 지표 중 일부는 다음과 같습니다.

  • etcd_disk_wal_fsync_duration_seconds_bucket 지표에서 etcd의 WAL fsync 기간을 보고합니다.
  • etcd_disk_backend_commit_duration_seconds_bucket 지표에서 etcd 백엔드 커밋 대기 시간 보고
  • etcd_server_leader_changes_seen_total 메트릭에서 리더 변경 사항을 보고합니다.

etcd는 모든 멤버 간에 요청을 복제하므로 성능은 네트워크 입력/출력(I/O) 대기 시간에 따라 달라집니다. 네트워크 대기 시간이 길어지면 etcd 하트비트가 선택 시간 초과보다 오래 걸리므로 리더 선택이 발생하여 클러스터가 손상될 수 있습니다. 배포된 OpenShift Container Platform 클러스터에서 모니터링되는 주요 메트릭은 각 etcd 클러스터 멤버에서 etcd 네트워크 피어 대기 시간의 99번째 백분위 수입니다. 이러한 메트릭을 추적하려면 Prometheus를 사용하십시오.

히스토그램_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[2m])) 메트릭은 etcd가 멤버 간 클라이언트 요청을 복제하는 것을 완료하기 위한 왕복 시간을 보고합니다. 50ms 미만이어야 합니다.

3장. 안정적인 etcd 성능 및 확장성 보장
링크 복사

etcd를 사용하여 최적의 성능을 얻으려면 노드 스케일링, 리더 선택, 로그 복제, 튜닝, 대기 시간, 네트워크 지터, 피어 라운드 트립 시간, 데이터베이스 크기, Kubernetes API 트랜잭션 속도 등 성능에 영향을 미치는 조건을 이해하는 것이 중요합니다.

3.1. etcd의 리더 선택 및 로그 복제
링크 복사

etcd는 복제된 노드 클러스터로 작동하는 일관된 분산 키-값 저장소입니다. Raft 알고리즘에 따라 etcd는 하나의 노드를 리더로 선택하고 다른 노드를 팔로우로 선택하여 작동합니다. 리더는 시스템의 현재 상태를 유지하고 유망이 최신 상태인지 확인합니다.

리더 노드는 로그 복제를 담당합니다. 클라이언트에서 들어오는 쓰기 트랜잭션을 처리하고 팔로우에게 브로드캐스트한 Raft 로그 항목을 작성합니다.

kube-apiserver 와 같은 etcd 클라이언트가 쿼럼이 필요한 작업을 요청하는 etcd 멤버(예: etcd 멤버가 후속자인 경우)에 연결하면 트랜잭션을 리더로 보내야 함을 나타내는 메시지를 반환합니다.

etcd 클라이언트가 리더의 쿼럼이 필요한 작업을 요청하면 리더는 로컬 Raft 로그를 쓰는 동안 클라이언트 연결을 열린 상태로 유지하고, 팔로우에게 로그를 브로드캐스트하고, 대다수가 실패 없이 로그를 커밋하도록 승인할 때까지 기다립니다. 그러면 리더만 etcd 클라이언트에 승인을 보내고 세션을 종료합니다. 실패 알림은 미용사로부터 수신되고 대다수가 합의에 도달하지 못하면 리더는 클라이언트에게 오류 메시지를 반환하고 세션을 종료합니다.

3.2. etcd의 노드 확장
링크 복사

일반적으로 클러스터에는 3개의 컨트롤 플레인 노드가 있어야 합니다. 그러나 클러스터가 베어 메탈 플랫폼에 설치된 경우 최대 5개의 컨트롤 플레인 노드가 있을 수 있습니다. 기존 베어 메탈 클러스터에 컨트롤 플레인 노드가 5개 미만인 경우 설치 후 작업으로 클러스터를 확장할 수 있습니다.

예를 들어 설치 후 3~4개의 컨트롤 플레인 노드를 확장하려면 호스트를 추가하고 컨트롤 플레인 노드로 설치할 수 있습니다. 그런 다음 etcd Operator는 추가 컨트롤 플레인 노드를 고려하여 적절하게 스케일링합니다.

클러스터를 4개 또는 5개로 스케일링하는 컨트롤 플레인 노드는 베어 메탈 플랫폼에서만 사용할 수 있습니다.

지원 설치 관리자를 사용하여 컨트롤 플레인 노드를 확장하는 방법에 대한 자세한 내용은 "API를 사용하여 호스트 추가" 및 "정의된 클러스터에서 컨트롤 플레인 노드 교체"를 참조하십시오.

참고

컨트롤 플레인 노드를 추가하면 안정성과 가용성을 향상시킬 수 있지만 처리량을 줄이고 성능에 영향을 주므로 대기 시간을 늘릴 수 있습니다.

다음 표에서는 다양한 크기의 클러스터에 대한 실패 허용 오차를 보여줍니다.

Expand
표 3.1. 클러스터 크기별 장애 허용
클러스터 크기대부분의실패 허용

노드 1개

1

0

노드 3개

2

1

4개의 노드

3

1

5개의 노드

3

2

쿼럼 손실에서 복구하는 방법에 대한 자세한 내용은 "이전 클러스터 상태로 복구"를 참조하십시오.

3.3. etcd에서 디스크 대기 시간 영향
링크 복사

etcd 클러스터는 디스크 대기 시간에 민감합니다. 컨트롤 플레인 환경에서 etcd에서 경험하는 디스크 대기 시간을 이해하려면 fio 테스트 또는 제품군을 실행합니다.

다음 예와 같이 최종 보고서가 etcd에 대해 디스크를 적절하게 분류하는지 확인합니다. 

...
99th percentile of fsync is 5865472 ns
99th percentile of the fsync is within the recommended threshold: - 20 ms, the disk can be used to host etcd
Copy to Clipboard Toggle word wrap

대기 시간이 긴 디스크를 사용하는 경우 다음 예와 같이 디스크가 etcd에 권장되지 않음을 알리는 메시지가 표시됩니다. 

...
99th percentile of fsync is 15865472 ns
99th percentile of the fsync is greater than the recommended value which is 20 ms, faster disks are recommended to host etcd for better performance
Copy to Clipboard Toggle word wrap

권장 대기 시간을 충족하지 않는 etcd에 디스크를 사용하는 여러 데이터 센터에 걸쳐 있는 클러스터 배포를 사용하면 서비스 영향을 미치는 오류가 발생할 가능성이 증가하고 컨트롤 플레인에서 유지할 수 있는 네트워크 대기 시간을 크게 줄일 수 있습니다.

3.4. etcd의 예상 대기 시간 모니터링
링크 복사

etcdctl CLI를 사용하면 etcd에서 경험한 것처럼 예상치 못한 결과에 도달하기 위해 대기 시간을 모니터링할 수 있습니다. etcd pod 중 하나를 확인한 다음 엔드포인트 상태를 검색해야합니다.

클러스터 상태를 검증하고 모니터링하는 이 절차는 활성 클러스터에서만 실행할 수 있습니다.

사전 요구 사항

  • 클러스터 배포를 계획하는 동안 디스크 및 네트워크 테스트를 완료했습니다.

프로세스

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

    # oc get pods -n openshift-etcd -l app=etcd
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          8h
etcd-m1   4/4     Running   4          8h
etcd-m2   4/4     Running   4          8h
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력합니다. 합의에 대한 etcd 대기 시간을 더 잘 이해하기 위해 몇 분 동안 정확한 감시 주기에서 이 명령을 실행하여 숫자가 ~66ms 임계값 아래로 유지되는지 확인할 수 있습니다. 합의된 시간은 100ms에 가까울수록 클러스터가 서비스 영향을 미치는 이벤트 및 불안정성을 경험할 가능성이 높아집니다. 

    # oc exec -ti etcd-m0 -- etcdctl endpoint health -w table
    Copy to Clipboard Toggle word wrap

    출력 예

    +----------------------------+--------+-------------+-------+
|          ENDPOINT          | HEALTH |    TOOK     | ERROR |
+----------------------------+--------+-------------+-------+
| https://198.18.111.12:2379 |   true |  3.798349ms |       |
| https://198.18.111.14:2379 |   true |  7.389608ms |       |
| https://198.18.111.13:2379 |   true |  6.263117ms |       |
+----------------------------+--------+-------------+-------+
    Copy to Clipboard Toggle word wrap

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

    # oc exec -ti etcd-m0 -- watch -dp -c etcdctl endpoint health -w table
    Copy to Clipboard Toggle word wrap

    출력 예

    +----------------------------+--------+-------------+-------+
|          ENDPOINT          | HEALTH |    TOOK     | ERROR |
+----------------------------+--------+-------------+-------+
| https://198.18.111.12:2379 |   true |  9.533405ms |       |
| https://198.18.111.13:2379 |   true |  4.628054ms |       |
| https://198.18.111.14:2379 |   true |  5.803378ms |       |
+----------------------------+--------+-------------+-------+
    Copy to Clipboard Toggle word wrap

3.5. etcd를 다른 디스크로 이동
링크 복사

etcd를 공유 디스크에서 별도의 디스크로 이동하여 성능 문제를 방지하거나 해결할 수 있습니다.

MCO(Machine Config Operator)는 OpenShift Container Platform 4.20 컨테이너 스토리지를 위한 보조 디스크를 마운트합니다.

참고

이 인코딩된 스크립트는 다음 장치 유형에 대한 장치 이름만 지원합니다.

SCSI 또는 SATA
/dev/sd*
가상 장치
/dev/vd*
NVMe
/dev/nvme*[0-9]*n*

제한

  • 새 디스크가 클러스터에 연결되면 etcd 데이터베이스가 root 마운트의 일부입니다. 기본 노드가 다시 생성되는 경우 보조 디스크 또는 의도한 디스크의 일부가 아닙니다. 결과적으로 기본 노드는 별도의 /var/lib/etcd 마운트를 생성하지 않습니다.

사전 요구 사항

  • 클러스터의 etcd 데이터 백업이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • 머신 구성을 업로드하기 전에 디스크를 추가합니다.
  • MachineConfigPool 은 metadata.labels[machineconfiguration.openshift.io/role] 과 일치해야 합니다. 이는 컨트롤러, 작업자 또는 사용자 지정 풀에 적용됩니다.
참고

이 절차에서는 루트 파일 시스템의 부분(예: /var/ )을 설치된 노드의 다른 디스크 또는 파티션으로 이동하지 않습니다.

중요

컨트롤 플레인 머신 세트를 사용할 때 이 절차는 지원되지 않습니다.

프로세스

  1. 새 디스크를 클러스터에 연결하고 디버그 쉘에서 lsblk 명령을 실행하여 노드에서 디스크가 감지되었는지 확인합니다. 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap 
    # lsblk
    Copy to Clipboard Toggle word wrap

    lsblk 명령에서 보고한 새 디스크의 장치 이름을 확인합니다.

  2. 다음 스크립트를 생성하고 이름을 etcd-find-secondary-device.sh 로 지정합니다. 

    #!/bin/bash
set -uo pipefail

for device in <device_type_glob>; do
    1 
    
/usr/sbin/blkid "${device}" &> /dev/null
 if [ $? == 2  ]; then
    echo "secondary device found ${device}"
    echo "creating filesystem for etcd mount"
    mkfs.xfs -L var-lib-etcd -f "${device}" &> /dev/null
    udevadm settle
    touch /etc/var-lib-etcd-mount
    exit
 fi
done
echo "Couldn't find secondary block device!" >&2
exit 77
    Copy to Clipboard Toggle word wrap
    1
    & lt;device_type_glob >를 블록 장치 유형의 쉘 글로 바꿉니다. SCSI 또는 SATA 드라이브의 경우 /dev/sd* 를 사용합니다. 가상 드라이브의 경우 /dev/vd* 를 사용합니다. NVMe 드라이브의 경우 /dev/nvme*[0-9]* 를 사용합니다.

  3. etcd-find-secondary-device.sh 스크립트에서 base64로 인코딩된 문자열을 생성하고 해당 내용을 확인합니다. 

    $ base64 -w0 etcd-find-secondary-device.sh
    Copy to Clipboard Toggle word wrap

  4. 다음과 같은 콘텐츠를 사용하여 etcd-mc.yml 이라는 MachineConfig YAML 파일을 만듭니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 98-var-lib-etcd
spec:
  config:
    ignition:
      version: 3.5.0
    storage:
      files:
        - path: /etc/find-secondary-device
          mode: 0755
          contents:
            source: data:text/plain;charset=utf-8;base64,<encoded_etcd_find_secondary_device_script>
    1 
    
    systemd:
      units:
        - name: find-secondary-device.service
          enabled: true
          contents: |
            [Unit]
            Description=Find secondary device
            DefaultDependencies=false
            After=systemd-udev-settle.service
            Before=local-fs-pre.target
            ConditionPathExists=!/etc/var-lib-etcd-mount

            [Service]
            RemainAfterExit=yes
            ExecStart=/etc/find-secondary-device

            RestartForceExitStatus=77

            [Install]
            WantedBy=multi-user.target
        - name: var-lib-etcd.mount
          enabled: true
          contents: |
            [Unit]
            Before=local-fs.target

            [Mount]
            What=/dev/disk/by-label/var-lib-etcd
            Where=/var/lib/etcd
            Type=xfs
            TimeoutSec=120s

            [Install]
            RequiredBy=local-fs.target
        - name: sync-var-lib-etcd-to-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Sync etcd data if new mount is empty
            DefaultDependencies=no
            After=var-lib-etcd.mount var.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecCondition=/usr/bin/test ! -d /var/lib/etcd/member
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 1
            ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
            ExecStart=/usr/sbin/semanage fcontext -a -t container_var_lib_t '/var/lib/etcd(/.*)?'
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 0
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target
        - name: restorecon-var-lib-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Restore recursive SELinux security contexts
            DefaultDependencies=no
            After=var-lib-etcd.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecStart=/sbin/restorecon -R /var/lib/etcd/
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target
    Copy to Clipboard Toggle word wrap
    1
    & lt;encoded_etcd_find_secondary_device_script >를 사용자가 언급한 인코딩된 스크립트 콘텐츠로 바꿉니다.

  5. 생성된 MachineConfig YAML 파일을 적용합니다. 

    $ oc create -f etcd-mc.yml
    Copy to Clipboard Toggle word wrap

검증 단계

  • 노드의 디버그 쉘에서 grep /var/lib/etcd /proc/mounts 명령을 실행하여 디스크가 마운트되었는지 확인합니다. 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap 
    # grep -w "/var/lib/etcd" /proc/mounts
    Copy to Clipboard Toggle word wrap

    출력 예

    /dev/sdb /var/lib/etcd xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

주의

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

3.7. etcd의 튜닝 매개변수 설정
링크 복사

컨트롤 플레인 하드웨어 속도를 "Standard", "Slower" 또는 기본값인 "" 로 설정할 수 있습니다.

기본 설정을 사용하면 시스템에서 사용할 속도를 결정할 수 있습니다. 이 값을 사용하면 시스템에서 이전 버전에서 값을 선택할 수 있으므로 이 기능이 존재하지 않는 버전에서 업그레이드할 수 있습니다.

다른 값 중 하나를 선택하면 기본값을 덮어씁니다. 시간 초과 또는 누락된 하트비트로 인해 리더 선택이 많이 표시되고 시스템이 "" 또는 "표준" 으로 설정된 경우 하드웨어 속도를 "Slower" 로 설정하여 시스템의 대기 시간을 늘리도록 합니다.

3.7.1. 하드웨어 속도 내결함성 변경
링크 복사

etcd의 하드웨어 속도 내결함성을 변경하려면 다음 단계를 완료합니다.

프로세스

  1. 다음 명령을 입력하여 현재 값이 무엇인지 확인합니다. 

    $ oc describe etcd/cluster | grep "Control Plane Hardware Speed"
    Copy to Clipboard Toggle word wrap

    출력 예

    Control Plane Hardware Speed:  <VALUE>
    Copy to Clipboard Toggle word wrap

    참고

    출력이 비어 있으면 필드가 설정되지 않았으며 기본값으로 간주해야 합니다.

  2. 다음 명령을 입력하여 값을 변경합니다. & lt;value >를 "", "Standard" 또는 "Slower": 유효한 값 중 하나로 바꿉니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"controlPlaneHardwareSpeed": "<value>"}}'
    Copy to Clipboard Toggle word wrap

    다음 표는 각 프로필에 대한 하트비트 간격 및 리더 선택 시간 초과를 나타냅니다. 이러한 값은 변경될 수 있습니다.

    Expand

    프로필

    ETCD_HEARTBEAT_INTERVAL

    ETCD_LEADER_ELECTION_TIMEOUT

    ""

    플랫폼에 따라 다릅니다.

    플랫폼에 따라 다릅니다.

    Standard

    100

    1000

    느림

    500

    2500

  3. 출력을 확인합니다.

    출력 예

    etcd.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

    유효한 값 이외의 값을 입력하면 오류 출력이 표시됩니다. 예를 들어 값으로 "Faster" 를 입력하면 출력은 다음과 같습니다.

    출력 예

    The Etcd "cluster" is invalid: spec.controlPlaneHardwareSpeed: Unsupported value: "Faster": supported values: "", "Standard", "Slower"
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 값이 변경되었는지 확인합니다. 

    $ oc describe etcd/cluster | grep "Control Plane Hardware Speed"
    Copy to Clipboard Toggle word wrap

    출력 예

    Control Plane Hardware Speed:  ""
    Copy to Clipboard Toggle word wrap

  5. etcd pod가 롤아웃될 때까지 기다립니다. 

    $ oc get pods -n openshift-etcd -w
    Copy to Clipboard Toggle word wrap

    다음 출력은 master-0에 대한 예상 항목을 보여줍니다. 계속하기 전에 모든 마스터에 실행 중인 4/4 상태가 표시될 때까지 기다립니다.

    출력 예

    installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Pending             0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Pending             0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     ContainerCreating   0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     ContainerCreating   0          1s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           1/1     Running             0          2s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          34s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          36s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          36s
etcd-guard-ci-ln-qkgs94t-72292-9clnd-master-0            0/1     Running             0          26m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Terminating         0          11m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Terminating         0          11m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Pending             0          0s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Init:1/3            0          1s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Init:2/3            0          2s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     PodInitializing     0          3s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  3/4     Running             0          4s
etcd-guard-ci-ln-qkgs94t-72292-9clnd-master-0            1/1     Running             0          26m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  3/4     Running             0          20s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Running             0          20s
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 입력하여 값을 검토합니다. 

    $ oc describe -n openshift-etcd pod/<ETCD_PODNAME> | grep -e HEARTBEAT_INTERVAL -e ELECTION_TIMEOUT
    Copy to Clipboard Toggle word wrap
    참고

    이러한 값은 기본값에서 변경되지 않을 수 있습니다.

3.8. etcd의 OpenShift Container Platform 타이머 튜닝 가능 항목
링크 복사

OpenShift Container Platform은 각 플랫폼에 최적화된 etcd 타이머를 유지 관리합니다. OpenShift Container Platform에는 각 플랫폼 공급자에 최적화된 검증 값이 지정되어 있습니다. platform=none 또는 platform=metal 인 기본 etcd 타이머는 다음과 같습니다. 

- name: ETCD_ELECTION_TIMEOUT
  value: "1000"
  ...
- name: ETCD_HEARTBEAT_INTERVAL
  value: "100"
Copy to Clipboard Toggle word wrap

etcd 관점에서 두 가지 주요 값은 선택 시간 초과와 하트비트 간격입니다.

하트비트 간격
리더가 여전히 리더임을 알리는 빈도입니다.
선택 시간 초과
이 시간 초과는 리더 자체가 되기 전에 하트비트에 대해 고의하지 않고 후속 노드가 이동하는 시간입니다.

이러한 값은 컨트롤 플레인 또는 etcd에 대한 전체 스토리를 제공하지 않습니다. etcd 클러스터는 디스크 대기 시간에 민감합니다. etcd는 로그에 대한 제안을 유지해야 하므로 다른 프로세스의 디스크 작업으로 인해 fsync 대기 시간이 길어질 수 있습니다. 그 결과 etcd에서 하트비트가 누락되어 요청 시간 초과 및 일시적으로 리더 손실이 발생할 수 있습니다. 리더 손실 및 복원 중에 Kubernetes API는 클러스터에 영향을 미치는 이벤트 및 불안정성을 유발하는 요청을 처리할 수 없습니다.

3.9. etcd 데이터베이스의 크기 확인 및 해당 영향 이해
링크 복사

etcd 데이터베이스의 크기는 etcd 조각 모음 프로세스를 완료하는 시간에 직접적인 영향을 미칩니다. OpenShift Container Platform은 45% 이상의 조각화가 감지되면 한 번에 하나의 etcd 멤버에서 etcd 조각 모음을 자동으로 실행합니다. 조각 모음 프로세스 중에 etcd 멤버는 요청을 처리할 수 없습니다. 소규모 etcd 데이터베이스에서 조각 모음 프로세스는 1초 미만으로 수행됩니다. 더 큰 etcd 데이터베이스를 사용하면 조각화 시간에 직접 디스크 대기 시간이 영향을 미치므로 조각 모음 중에 작업이 차단되므로 대기 시간이 추가로 발생합니다.

etcd 데이터베이스의 크기는 네트워크 파티션이 기간 동안 컨트롤 플레인 노드를 격리하고 통신을 다시 설정한 후 컨트롤 플레인을 다시 동기화해야 할 때 고려해야 할 요소입니다.

시스템의 운영자 및 애플리케이션에 따라 달라지므로 etcd 데이터베이스의 크기를 제어하기 위한 최소 옵션이 있습니다. 시스템이 작동할 대기 시간 범위를 고려할 때 etcd 데이터베이스의 크기당 동기화 또는 조각 모음의 영향을 설명합니다.

영향의 크기는 배포에 따라 다릅니다. etcd 멤버는 조각 모음 프로세스 중 업데이트를 수락할 수 없으므로 조각 모음을 완료하는 시간으로 인해 트랜잭션 속도 저하가 발생합니다. 마찬가지로 변경 속도가 높은 대규모 데이터베이스의 etcd 재동기화 시간은 시스템의 트랜잭션 속도 및 트랜잭션 대기 시간에 영향을 미칩니다.

계획할 영향 유형에 대해 다음 두 가지 예를 고려하십시오.

데이터베이스 크기에 따른 etcd 조각의 영향 예
80Mbit/s에서 1GB의 etcd 데이터베이스를 느린 7200 RPM 디스크에 작성하는 데 약 1분 40초가 걸립니다. 이러한 시나리오에서 조각 모음 프로세스는 조각 모음을 완료하는 데 적어도 이 시간이 오래 걸리지 않습니다.
etcd 동기화에 데이터베이스 크기가 미치는 영향 예
컨트롤 플레인 노드 중 하나의 연결이 끊어진 동안 etcd 데이터베이스의 10%가 변경되면 재동기화가 최소 100MB를 전송해야 합니다. 1Gbps 링크를 통해 100MB를 전송하는 데는 800ms가 걸립니다. Kubernetes API를 사용한 일반 트랜잭션이 있는 클러스터에서 etcd 데이터베이스 크기가 클수록 네트워크 불안정으로 인해 컨트롤 플레인 불안정성이 발생합니다.

OpenShift Container Platform 콘솔을 사용하거나 etcdctl 툴에서 명령을 실행하여 etcd 데이터베이스의 크기를 확인할 수 있습니다.

프로세스

  • OpenShift Container Platform 콘솔에서 데이터베이스 크기를 찾으려면 etcd 대시보드로 이동하여 etcd 데이터베이스의 크기를 보고하는 플롯을 확인합니다.

  • etcdctl 툴을 사용하여 데이터베이스 크기를 찾으려면 다음 두 가지 명령을 입력합니다.

    1. 다음 명령을 입력하여 Pod를 나열합니다. 

      # oc get pods -n openshift-etcd -l app=etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 입력하고 출력에 데이터베이스 크기를 확인합니다. 

      # oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4
      Copy to Clipboard Toggle word wrap

      출력 예

      https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB
      Copy to Clipboard Toggle word wrap

3.10. etcd의 데이터베이스 크기 증가
링크 복사

각 etcd 인스턴스에 대해 디스크 할당량을 기가바이트(GiB)로 설정할 수 있습니다. etcd 인스턴스의 디스크 할당량을 설정하는 경우 8에서 32로 정수 값을 지정할 수 있습니다. 기본값은 8입니다. 증가하는 값만 지정할 수 있습니다.

공간 부족 경고가 발생하면 디스크 할당량을 늘릴 수 있습니다. 이 경고는 자동 압축 및 조각 모음에도 불구하고 클러스터가 etcd에 너무 커서 있음을 나타냅니다. 이 경고가 표시되면 etcd가 공간이 부족하면 쓰기가 실패하기 때문에 즉시 디스크 할당량을 늘려야 합니다.

디스크 할당량을 늘릴 수 있는 또 다른 시나리오는 과도한 데이터베이스 증가 경고가 발생하는 경우입니다. 이 경고는 다음 4시간 동안 데이터베이스가 너무 커질 수 있다는 경고입니다. 이 시나리오에서는 결국 낮은 공간 경고가 발생하지 않고 쓰기가 실패할 수 있도록 디스크 할당량을 늘리는 것이 좋습니다.

디스크 할당량을 늘리면 지정한 디스크 공간이 즉시 예약되지 않습니다. 대신 필요한 경우 etcd를 해당 크기로 확장할 수 있습니다. etcd가 디스크 할당량에 지정된 값보다 큰 전용 디스크에서 실행되고 있는지 확인합니다.

대규모 etcd 데이터베이스의 경우 컨트롤 플레인 노드에 추가 메모리 및 스토리지가 있어야 합니다. API 서버 캐시를 고려해야 하므로 필요한 최소 메모리는 etcd 데이터베이스의 구성된 크기의 세 배 이상입니다.

중요

etcd의 데이터베이스 크기를 늘리는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.

3.10.1. etcd 데이터베이스 크기 변경
링크 복사

etcd의 데이터베이스 크기를 변경하려면 다음 단계를 완료합니다.

프로세스

  1. 다음 명령을 입력하여 각 etcd 인스턴스의 디스크 할당량의 현재 값을 확인합니다. 

    $ oc describe etcd/cluster | grep "Backend Quota"
    Copy to Clipboard Toggle word wrap

    출력 예

    Backend Quota Gi B: <value>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 디스크 할당량 값을 변경합니다. 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": <value>}}'
    Copy to Clipboard Toggle word wrap

    출력 예

    etcd.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 입력하여 디스크 할당량의 새 값이 설정되었는지 확인합니다. 

    $ oc describe etcd/cluster | grep "Backend Quota"
    Copy to Clipboard Toggle word wrap

    etcd Operator는 새 값으로 etcd 인스턴스를 자동으로 롤아웃합니다.

  2. 다음 명령을 입력하여 etcd pod가 실행 중인지 확인합니다. 

    $ oc get pods -n openshift-etcd
    Copy to Clipboard Toggle word wrap

    다음 출력에서는 예상된 항목을 보여줍니다.

    출력 예

    NAME                                                   READY   STATUS      RESTARTS   AGE
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-0                4/4     Running     0          39m
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-1                4/4     Running     0          37m
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-2                4/4     Running     0          41m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-0          1/1     Running     0          51m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-1          1/1     Running     0          49m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-2          1/1     Running     0          54m
installer-5-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          51m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-0         0/1     Completed   0          46m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          44m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-2         0/1     Completed   0          49m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-0         0/1     Completed   0          40m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          38m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-2         0/1     Completed   0          42m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-0   0/1     Completed   0          43m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-1   0/1     Completed   0          43m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-2   0/1     Completed   0          43m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-0   0/1     Completed   0          42m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-1   0/1     Completed   0          42m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-2   0/1     Completed   0          42m
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 etcd 포드에 대한 디스크 할당량 값이 업데이트되었는지 확인합니다. 

    $ oc describe -n openshift-etcd pod/<etcd_podname> | grep "ETCD_QUOTA_BACKEND_BYTES"
    Copy to Clipboard Toggle word wrap

    이 값은 기본값인 8 에서 변경되지 않을 수 있습니다.

    출력 예

    ETCD_QUOTA_BACKEND_BYTES:                               8589934592
    Copy to Clipboard Toggle word wrap

    참고

    설정한 값은 GiB 단위의 정수이지만 출력에 표시된 값은 바이트로 변환됩니다.

3.10.2. 문제 해결
링크 복사

etcd의 데이터베이스 크기를 늘리려고 할 때 문제가 발생하면 다음 문제 해결 단계가 도움이 될 수 있습니다.

3.10.2.1. 값이 너무 작음
링크 복사

지정한 값이 8 보다 작으면 다음과 같은 오류 메시지가 표시됩니다. 

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

오류 메시지의 예

The Etcd "cluster" is invalid:
* spec.backendQuotaGiB: Invalid value: 5: spec.backendQuotaGiB in body should be greater than or equal to 8
* spec.backendQuotaGiB: Invalid value: "integer": etcd backendQuotaGiB may not be decreased
Copy to Clipboard Toggle word wrap

이 문제를 해결하려면 8 에서 32 사이의 정수를 지정합니다.

3.10.2.2. 값이 너무 큽니다
링크 복사

지정한 값이 32 보다 크면 다음과 같은 오류 메시지가 표시됩니다. 

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

오류 메시지의 예

The Etcd "cluster" is invalid: spec.backendQuotaGiB: Invalid value: 64: spec.backendQuotaGiB in body should be less than or equal to 32
Copy to Clipboard Toggle word wrap

이 문제를 해결하려면 8 에서 32 사이의 정수를 지정합니다.

3.10.2.3. 값이 감소
링크 복사

값이 8 에서 32 사이의 유효한 값으로 설정된 경우 값을 줄일 수 없습니다. 그렇지 않으면 오류 메시지가 표시됩니다.

  1. 다음 명령을 입력하여 현재 값을 확인합니다. 

    $ oc describe etcd/cluster | grep "Backend Quota"
    Copy to Clipboard Toggle word wrap

    출력 예

    Backend Quota Gi B: 10
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 디스크 할당량 값을 줄입니다. 

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

    오류 메시지의 예

    The Etcd "cluster" is invalid: spec.backendQuotaGiB: Invalid value: "integer": etcd backendQuotaGiB may not be decreased
    Copy to Clipboard Toggle word wrap

  3. 이 문제를 해결하려면 10 보다 큰 정수를 지정합니다.

3.11. 컨트롤 플레인 노드 간 네트워크 지터 측정
링크 복사

하트비트 간격의 값은 멤버 간 평균 RTT(Round-trip time)의 최대값이어야 합니다. 일반적으로 왕복 시간(약 1.5배)입니다. OpenShift Container Platform의 기본 하트비트 간격이 100ms인 경우 컨트롤 플레인 노드 간 권장 RTT는 약 33ms보다 적고 최대 66ms(66ms가 99ms를 곱한 값)입니다. 자세한 내용은 " etcd에 대한 튜닝 매개변수 설정"을 참조하십시오. 네트워크 대기 시간이 길면 서비스 영향을 미치는 이벤트 및 클러스터 불안정성을 유발할 수 있습니다.

네트워크 대기 시간은 다음 요소를 포함하여 여러 요인의 영향을 받습니다.

  • 구리, 광섬유, 무선 또는 Satellite와 같은 전송 네트워크의 기술
  • 전송 네트워크에서 네트워크 장치의 수 및 품질

좋은 평가 참조는 월간 IP 대기 시간 통계와 같이 통신 공급자가 게시한 상용 대기 시간과 조직의 네트워크 대기 시간을 비교합니다.

보다 정확한 계산을 위해 네트워크 지터로 네트워크 대기 시간을 고려하십시오. 네트워크 지터 는 네트워크 대기 시간 또는 특히 수신된 패킷 지연의 변형입니다. 이상적인 네트워크 조건에서는 지터가 가능한 한 0에 가깝습니다. 네트워크 지터는 시간이 지남에 따라 실제 네트워크 대기 시간이 RTT + 또는 - jitter이므로 etcd의 네트워크 대기 시간 계산에 영향을 미칩니다. 예를 들어, 최대 대기 시간이 80ms이고 30ms의 지터가 있는 네트워크는 110ms의 대기 시간을 경험하므로 etcd가 하트비트가 누락되어 요청 시간 초과 및 임시 리더 손실이 발생합니다. 리더 손실 및 복원 중에 Kubernetes API는 클러스터에 영향을 미치는 이벤트 및 불안정성을 유발하는 요청을 처리할 수 없습니다.

모든 컨트롤 플레인 노드 간에 네트워크 지터를 측정하는 것이 중요합니다. 이렇게 하려면 UDP 모드에서 iPerf3 툴을 사용할 수 있습니다.

사전 요구 사항

프로세스

  1. 컨트롤 플레인 노드 중 하나에 연결하고 호스트 네트워크 모드에서 iPerf 컨테이너를 iPerf 서버로 실행합니다. 서버 모드에서 실행 중이면 툴에서 TCP 및 UDP 테스트를 허용합니다. < iperf_image>를 i Perf 이미지로 교체하려면 다음 명령을 입력합니다. 

    # podman run -ti --rm --net host <iperf_image> iperf3 -s
    Copy to Clipboard Toggle word wrap

  2. 다른 컨트롤 플레인 노드에 연결하고 다음 명령을 입력하여 UDP 클라이언트 모드에서 iPerf를 실행합니다. 

    # podman run -ti --rm --net host <iperf_image> iperf3 -u -c <node_iperf_server> -t 300
    Copy to Clipboard Toggle word wrap

    기본 테스트는 10초 동안 실행되며, 클라이언트 출력은 클라이언트 관점에서 평균 지터를 표시합니다.

  3. 다음 명령을 입력하여 디버그 노드 모드를 실행합니다. 

    # oc debug node/m1
    Copy to Clipboard Toggle word wrap

    출력 예

    Starting pod/m1-debug ...
To use host binaries, run `chroot /host`
Pod IP: 198.18.111.13
If you don't see a command prompt, try pressing enter.
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력합니다. 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap 
    sh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -u -c m0
    Copy to Clipboard Toggle word wrap

    출력 예

    Connecting to host m0, port 5201
[  5] local 198.18.111.13 port 60878 connected to 198.18.111.12 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   1.00-2.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   2.00-3.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   3.00-4.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   4.00-5.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   5.00-6.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   6.00-7.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   7.00-8.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   8.00-9.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   9.00-10.00  sec   129 KBytes  1.05 Mbits/sec  91
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms  0/906 (0%)  sender
[  5]   0.00-10.04  sec  1.25 MBytes  1.05 Mbits/sec  1.074 ms  0/906 (0%)  receiver

iperf Done.
    Copy to Clipboard Toggle word wrap

  5. iPerf 서버에서 출력에 1초 간격마다 지터가 표시됩니다. 평균은 끝에 표시됩니다. 이 테스트의 목적을 위해 잘못된 측정이 포함될 수 있으므로 첫 번째 초의 출력을 무시하고 테스트 중에 경험하는 최대 지터를 식별하려고 합니다. 다음 명령을 실행합니다. 

    # oc debug node/m0
    Copy to Clipboard Toggle word wrap

    출력 예

    Starting pod/m0-debug ...
To use host binaries, run `chroot /host`
Pod IP: 198.18.111.12
If you don't see a command prompt, try pressing enter.
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 입력합니다. 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap 
    sh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -s
    Copy to Clipboard Toggle word wrap

    출력 예

    -----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 198.18.111.13, port 44136
[  5] local 198.18.111.12 port 5201 connected to 198.18.111.13 port 60878
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   124 KBytes  1.02 Mbits/sec  4.763 ms  0/88 (0%)
[  5]   1.00-2.00   sec   127 KBytes  1.04 Mbits/sec  4.735 ms  0/90 (0%)
[  5]   2.00-3.00   sec   129 KBytes  1.05 Mbits/sec  0.568 ms  0/91 (0%)
[  5]   3.00-4.00   sec   127 KBytes  1.04 Mbits/sec  2.443 ms  0/90 (0%)
[  5]   4.00-5.00   sec   129 KBytes  1.05 Mbits/sec  1.372 ms  0/91 (0%)
[  5]   5.00-6.00   sec   127 KBytes  1.04 Mbits/sec  2.769 ms  0/90 (0%)
[  5]   6.00-7.00   sec   129 KBytes  1.05 Mbits/sec  2.393 ms  0/91 (0%)
[  5]   7.00-8.00   sec   127 KBytes  1.04 Mbits/sec  0.883 ms  0/90 (0%)
[  5]   8.00-9.00   sec   129 KBytes  1.05 Mbits/sec  0.594 ms  0/91 (0%)
[  5]   9.00-10.00  sec   127 KBytes  1.04 Mbits/sec  0.953 ms  0/90 (0%)
[  5]  10.00-10.04  sec  5.66 KBytes  1.30 Mbits/sec  1.074 ms  0/4 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.04  sec  1.25 MBytes  1.05 Mbits/sec  1.074 ms  0/906 (0%)  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
    Copy to Clipboard Toggle word wrap

  7. 계산된 jitter를 네트워크 대기 시간에 페널링합니다. 예를 들어, 네트워크 대기 시간이 80ms이고 지터가 30ms인 경우 컨트롤 플레인을 위해 110ms의 효과적인 네트워크 대기 시간을 고려하십시오. 이 예에서 해당 값은 100 ms 임계값을 초과하면 시스템은 하트비트를 놓치게 됩니다.

  8. etcd의 네트워크 대기 시간을 계산할 때 다음 식의 합계인 유효한 네트워크 대기 시간을 사용합니다.

    RTT + 지터

    평균 jitter 값을 사용하여 페널티를 계산할 수 있지만 etcd 하트비트 타이머가 다음 식의 합계보다 작으면 클러스터에서 하트비트를 급증할 수 있습니다.

    RTT + max(jitter)

    대신 보다 유연한 배포를 위해 99번째 백분위 또는 최대 jitter 값을 사용하는 것이 좋습니다.

    효과적인 네트워크 대기 시간 = RTT + max(jitter)

3.12. etcd 피어 트립 시간이 성능에 미치는 영향
링크 복사

etcd 피어 트립 시간은 멤버 간에 어떤 것을 얼마나 빠르게 복제할 수 있는지에 대한 엔드 투 엔드 테스트 메트릭입니다. 모든 etcd 멤버 중 클라이언트 요청 복제를 완료하기 위해 etcd의 대기 시간을 보여줍니다. etcd 피어 트립 시간은 네트워크 라운드 트립 시간과 동일하지 않습니다.

OpenShift Container Platform 콘솔의 대시보드에서 다양한 etcd 지표를 모니터링할 수 있습니다. 콘솔의 모니터링 → 대시보드 를 클릭하고 드롭다운 목록에서 etcd 를 선택합니다.

etcd 대시보드가 끝나면 etcd 피어 라운드 트립 시간을 요약하는 플롯을 찾을 수 있습니다.

참고

이러한 etcd 지표는 Prometheus의 OpenShift 지표 시스템에 의해 수집됩니다. Red Hat Knowledgebase 솔루션에 따라 CLI에서 액세스할 수 있습니다. 명령행 Prometheus 통계에서 쿼리하는 방법. 

# Get token to connect to Prometheus
SECRET=$(oc get secret -n openshift-user-workload-monitoring | grep  prometheus-user-workload-token | head -n 1 | awk '{print $1 }')
export TOKEN=$(oc get secret $SECRET -n openshift-user-workload-monitoring -o json | jq -r '.data.token' | base64 -d)
export THANOS_QUERIER_HOST=$(oc get route thanos-querier -n openshift-monitoring -o json | jq -r '.spec.host')
Copy to Clipboard Toggle word wrap

쿼리는 URL로 인코딩되어야 합니다. 다음 예제에서는 etcd에 대해 라운드 트립 시간(초)을 보고하는 메트릭을 검색하여 멤버 간에 클라이언트 요청을 복제하는 방법을 보여줍니다. 

# prometheus query
query="histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[5m]))"

# urlencoded query
encoded_query=$(printf "%s" $query |jq -sRr @uri)

# querying the OpenShift metrics service
curl -s -X GET -k -H "Authorization: Bearer $TOKEN" "https://$THANOS_QUERIER_HOST/api/v1/query?query=$encoded_query" | jq '.data.result[] | .metric.pod,.value[1]'

"etcd-m2"
"0.09318400000000004"   # example ~93ms
"etcd-m0"
"0.050688"              # example ~51ms
"etcd-m1"
"0.050688"              # example ~51ms
Copy to Clipboard Toggle word wrap

다음 메트릭은 etcd 성능을 이해하는 것과도 관련이 있습니다.

etcd_disk_wal_fsync_duration_seconds_bucket
etcd WAL fsync 기간을 보고합니다.
etcd_disk_backend_commit_duration_seconds_bucket
etcd 백엔드 커밋 대기 시간을 보고합니다.
etcd_server_leader_changes_seen_total
리더의 변경 사항을 보고합니다.

3.13. 사용자 환경에 대한 Kubernetes API 트랜잭션 속도 확인
링크 복사

확장된 컨트롤 플레인을 사용하는 경우 Kubernetes API 트랜잭션 속도는 특정 배포의 특성에 따라 다릅니다. 특히 다음과 같은 결합된 요인에 따라 달라집니다.

  • etcd 디스크 대기 시간
  • etcd 라운드 트립 시간
  • API에 기록되는 오브젝트의 크기

결과적으로 확장된 컨트롤 플레인을 사용할 때 클러스터 관리자는 환경에 가능한 지속적인 트랜잭션 속도를 결정하기 위해 환경을 테스트해야 합니다. kube-burner 툴은 해당 목적에 유용합니다. 바이너리에는 OpenShift 클러스터 테스트에 대한 래퍼가 포함되어 있습니다. kube-burner-ocp. kube-burner-ocp 를 사용하여 클러스터 또는 노드 밀도를 테스트할 수 있습니다. 컨트롤 플레인을 테스트하기 위해 kube-burner-ocp 에는 cluster-density, cluster-density-v2, cluster-density-ms 세 가지 워크로드 프로필이 있습니다. 각 워크로드 프로파일은 컨트롤 플레인을 로드하도록 설계된 일련의 리소스를 생성합니다. 각 프로필에 대한 자세한 내용은 kube-burner-ocp 워크로드 설명서를 참조하십시오.

프로세스

  1. 리소스를 생성하고 삭제하는 명령을 입력합니다. 다음 예제에서는 20분 내에 리소스를 생성하고 삭제하는 명령을 보여줍니다. 

    # kube-burner ocp cluster-density-ms --churn-duration 20m --churn-delay 0s --iterations 10 --timeout 30m
    Copy to Clipboard Toggle word wrap
  2. OpenShift Container Platform 콘솔은 모든 관련 API 성능 정보를 대시보드에 제공합니다. API 성능 정보에 액세스하려면 모니터링 → 대시보드 를 클릭하고 대시보드 메뉴에서 API 성능을 클릭합니다.

  3. 실행 중에 모니터링 → 대시보드를 클릭하고 대시보드 메뉴에서 API 성능을 클릭하여 OpenShift Container Platform 콘솔의 API 성능 대시보드 를 관찰 합니다.

    대시보드에서 컨트롤 플레인이 로드 중에 응답하는 방법과 읽기 및 쓰기를 통해 다양한 동사 및 요청 속도를 실행할 수 있는 99번째 백분위 트랜잭션 속도입니다. 이 정보와 조직의 워크로드에 대한 지식을 사용하여 조직이 특정 확장 컨트롤 플레인 배포를 위해 클러스터에 배치할 수 있는 로드를 결정합니다.

4장. etcd 데이터 백업 및 복원
링크 복사

4.1. etcd 데이터 백업 및 복원
링크 복사

OpenShift Container Platform의 키-값 저장소로서 etcd는 모든 리소스 오브젝트의 상태를 유지합니다.

클러스터의 etcd 데이터를 정기적으로 백업하고 OpenShift Container Platform 환경 외부에서 안전한 위치에 저장하는 것이 좋습니다. 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체가 완료되기 전까지 etcd 백업을 수행하지 마십시오. 인증서 교체가 완료되기 전에 실행하면 백업에 만료된 인증서가 포함됩니다. etcd 스냅샷에 높은 I/O 비용이 있기 때문에 사용량이 많지 않은 시간에 etcd 백업을 수행하는 것이 좋습니다.

클러스터를 업데이트하기 전에 etcd 백업을 수행해야합니다. 클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 하므로 업데이트 전에 백업을 수행하는 것이 중요합니다. 예를 들어, OpenShift Container Platform 4.17.5 클러스터는 4.17.5에서 가져온 etcd 백업을 사용해야 합니다.

중요

컨트롤 플레인 호스트에서 백업 스크립트를 실행하여 클러스터의 etcd 데이터를 백업합니다. 클러스터의 각 컨트롤 플레인 호스트마다 백업을 수행하지 마십시오.

etcd 백업 후 이전 클러스터 상태로 복원할 수 있습니다.

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

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

중요

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

사전 요구 사항

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

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

    작은 정보

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

프로세스

  1. 컨트롤 플레인 노드의 root로 디버그 세션을 시작합니다. 

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

  2. 디버그 쉘에서 root 디렉토리를 /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.1.2. 자동화된 etcd 백업 생성
링크 복사

etcd의 자동화된 백업 기능은 반복 및 단일 백업을 모두 지원합니다. 반복 백업은 작업이 트리거될 때마다 단일 백업을 시작하는 cron 작업을 생성합니다.

중요

etcd 백업 자동화는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.

다음 단계에 따라 etcd에 대한 자동 백업을 활성화합니다.

주의

클러스터에 TechPreviewNoUpgrade 기능 세트를 활성화하면 마이너 버전 업데이트가 수행되지 않습니다. TechPreviewNoUpgrade 기능 세트를 비활성화할 수 없습니다. 프로덕션 클러스터에서 이 기능 세트를 활성화하지 마십시오.

사전 요구 사항

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

프로세스

  1. 다음 콘텐츠를 사용하여 enable-tech-preview-no-upgrade.yaml 이라는 FeatureGate CR(사용자 정의 리소스) 파일을 생성합니다. 

    apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade
    Copy to Clipboard Toggle word wrap

  2. CR을 적용하고 자동화된 백업을 활성화합니다. 

    $ oc apply -f enable-tech-preview-no-upgrade.yaml
    Copy to Clipboard Toggle word wrap

  3. 관련 API를 활성화하는 데 시간이 걸립니다. 다음 명령을 실행하여 CRD(사용자 정의 리소스 정의) 생성을 확인합니다. 

    $ oc get crd | grep backup
    Copy to Clipboard Toggle word wrap

    출력 예

    backups.config.openshift.io 2023-10-25T13:32:43Z
etcdbackups.operator.openshift.io 2023-10-25T13:32:04Z
    Copy to Clipboard Toggle word wrap

4.1.2.1. 자동화된 단일 etcd 백업 생성
링크 복사

다음 단계에 따라 CR(사용자 정의 리소스)을 생성하고 적용하여 단일 etcd 백업을 생성합니다.

사전 요구 사항

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

프로세스

  • 동적으로 프로비저닝된 스토리지를 사용할 수 있는 경우 다음 단계를 완료하여 단일 자동화된 etcd 백업을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 etcd-backup-pvc.yaml 이라는 PVC(영구 볼륨 클레임)를 생성합니다. 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi
      1 
      
  volumeMode: Filesystem
      Copy to Clipboard Toggle word wrap
      1 1
      PVC에서 사용할 수 있는 스토리지 용량입니다. 요구 사항에 맞게 이 값을 조정합니다.

    2. 다음 명령을 실행하여 PVC를 적용합니다. 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 PVC 생성을 확인합니다. 

      $ oc get pvc
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
etcd-backup-pvc   Bound                                                       51s
      Copy to Clipboard Toggle word wrap

      참고

      동적 PVC는 마운트될 때까지 Pending 상태로 유지됩니다.

    4. 다음 예와 같은 콘텐츠를 사용하여 etcd-single-backup.yaml 이라는 CR 파일을 만듭니다. 

      apiVersion: operator.openshift.io/v1alpha1
kind: EtcdBackup
metadata:
  name: etcd-single-backup
  namespace: openshift-etcd
spec:
  pvcName: etcd-backup-pvc
      1
      Copy to Clipboard Toggle word wrap
      1
      백업을 저장할 PVC의 이름입니다. 환경에 따라 이 값을 조정합니다.

    5. CR을 적용하여 단일 백업을 시작합니다. 

      $ oc apply -f etcd-single-backup.yaml
      Copy to Clipboard Toggle word wrap

  • 동적으로 프로비저닝된 스토리지를 사용할 수 없는 경우 다음 단계를 완료하여 단일 자동화된 etcd 백업을 생성합니다.

    1. 다음 콘텐츠를 사용하여 etcd-backup-local-storage.yaml 이라는 StorageClass CR 파일을 만듭니다. 

      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: etcd-backup-local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 StorageClass CR을 적용합니다. 

      $ oc apply -f etcd-backup-local-storage.yaml
      Copy to Clipboard Toggle word wrap

    3. 다음 예와 같은 콘텐츠를 사용하여 etcd-backup-pv-fs.yaml 이라는 PV를 생성합니다. 

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: etcd-backup-pv-fs
spec:
  capacity:
    storage: 100Gi
      1 
      
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: etcd-backup-local-storage
  local:
    path: /mnt
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
      - key: kubernetes.io/hostname
         operator: In
         values:
         - <example_master_node>
      2
      Copy to Clipboard Toggle word wrap
      1
      PV에서 사용할 수 있는 스토리지의 양입니다. 요구 사항에 맞게 이 값을 조정합니다.
      2
      이 PV를 연결할 노드로 이 값을 바꿉니다.

    4. 다음 명령을 실행하여 PV 생성을 확인합니다. 

      $ oc get pv
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS                REASON   AGE
etcd-backup-pv-fs       100Gi      RWO            Retain           Available           etcd-backup-local-storage            10s
      Copy to Clipboard Toggle word wrap

    5. 다음 예와 같은 콘텐츠를 사용하여 etcd-backup-pvc.yaml 이라는 PVC를 만듭니다. 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
      1
      Copy to Clipboard Toggle word wrap
      1
      PVC에서 사용할 수 있는 스토리지 용량입니다. 요구 사항에 맞게 이 값을 조정합니다.

    6. 다음 명령을 실행하여 PVC를 적용합니다. 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

    7. 다음 예와 같은 콘텐츠를 사용하여 etcd-single-backup.yaml 이라는 CR 파일을 만듭니다. 

      apiVersion: operator.openshift.io/v1alpha1
kind: EtcdBackup
metadata:
  name: etcd-single-backup
  namespace: openshift-etcd
spec:
  pvcName: etcd-backup-pvc
      1
      Copy to Clipboard Toggle word wrap
      1
      백업을 저장할 PVC(영구 볼륨 클레임)의 이름입니다. 환경에 따라 이 값을 조정합니다.

    8. CR을 적용하여 단일 백업을 시작합니다. 

      $ oc apply -f etcd-single-backup.yaml
      Copy to Clipboard Toggle word wrap
4.1.2.2. 반복적인 자동화된 etcd 백업 생성
링크 복사

다음 단계에 따라 etcd의 자동 반복 백업을 생성합니다.

동적으로 프로비저닝된 스토리지를 사용하여 가능한 경우 생성된 etcd 백업 데이터를 안전한 외부 위치에 보관합니다. 동적으로 프로비저닝된 스토리지를 사용할 수 없는 경우 NFS 공유에 백업 데이터를 저장하여 백업 복구에 더 쉽게 액세스할 수 있도록 하는 것이 좋습니다.

사전 요구 사항

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

프로세스

  1. 동적으로 프로비저닝된 스토리지를 사용할 수 있는 경우 다음 단계를 완료하여 자동화된 반복 백업을 생성합니다.

    1. 다음 예와 같은 콘텐츠를 사용하여 etcd-backup-pvc.yaml 이라는 PVC(영구 볼륨 클레임)를 생성합니다. 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi
      1 
      
  volumeMode: Filesystem
  storageClassName: etcd-backup-local-storage
      Copy to Clipboard Toggle word wrap
      1
      PVC에서 사용할 수 있는 스토리지 용량입니다. 요구 사항에 맞게 이 값을 조정합니다.
      참고

      다음 공급자마다 accessModes 및 storageClassName 키를 변경해야 합니다.

      Expand
      공급자accessModes 값storageClassName value

      버전ed-installer-efc_operator-ci 프로필이 있는 AWS

      - ReadWriteMany

      efs-sc

      Google Cloud

      - ReadWriteMany

      filestore-csi

      Microsoft Azure

      - ReadWriteMany

      azurefile-csi

    2. 다음 명령을 실행하여 PVC를 적용합니다. 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 PVC 생성을 확인합니다. 

      $ oc get pvc
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
etcd-backup-pvc   Bound                                                       51s
      Copy to Clipboard Toggle word wrap

      참고

      동적 PVC는 마운트될 때까지 Pending 상태로 유지됩니다.

  2. 동적으로 프로비저닝된 스토리지를 사용할 수 없는 경우 다음 단계를 완료하여 로컬 스토리지 PVC를 생성합니다.

    주의

    저장된 백업 데이터가 포함된 노드에 대한 액세스 권한을 삭제하거나 손실하면 데이터가 손실될 수 있습니다.

    1. 다음 콘텐츠를 사용하여 etcd-backup-local-storage.yaml 이라는 StorageClass CR 파일을 만듭니다. 

      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: etcd-backup-local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 StorageClass CR을 적용합니다. 

      $ oc apply -f etcd-backup-local-storage.yaml
      Copy to Clipboard Toggle word wrap

    3. 다음 예와 같은 콘텐츠를 사용하여 적용된 StorageClass 에서 etcd-backup-pv-fs.yaml 이라는 PV를 만듭니다. 

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: etcd-backup-pv-fs
spec:
  capacity:
    storage: 100Gi
      1 
      
  volumeMode: Filesystem
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Delete
  storageClassName: etcd-backup-local-storage
  local:
    path: /mnt/
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - <example_master_node>
      2
      Copy to Clipboard Toggle word wrap
      1
      PV에서 사용할 수 있는 스토리지의 양입니다. 요구 사항에 맞게 이 값을 조정합니다.
      2
      이 PV를 연결할 마스터 노드로 이 값을 바꿉니다.
      작은 정보

      다음 명령을 실행하여 사용 가능한 노드를 나열합니다. 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 실행하여 PV 생성을 확인합니다. 

      $ oc get pv
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS                REASON   AGE
etcd-backup-pv-fs       100Gi      RWX            Delete           Available           etcd-backup-local-storage            10s
      Copy to Clipboard Toggle word wrap

    5. 다음 예와 같은 콘텐츠를 사용하여 etcd-backup-pvc.yaml 이라는 PVC를 만듭니다. 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
spec:
  accessModes:
  - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
      1 
      
  storageClassName: etcd-backup-local-storage
      Copy to Clipboard Toggle word wrap
      1
      PVC에서 사용할 수 있는 스토리지 용량입니다. 요구 사항에 맞게 이 값을 조정합니다.

    6. 다음 명령을 실행하여 PVC를 적용합니다. 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

  3. etcd-recurring-backups.yaml 이라는 CRD(사용자 정의 리소스 정의) 파일을 생성합니다. 생성된 CRD의 내용은 자동 백업의 일정 및 보존 유형을 정의합니다.

    • 15개의 보존된 백업이 있는 보존 Number 의 기본 보존 유형은 다음 예와 같은 내용을 사용합니다. 

      apiVersion: config.openshift.io/v1alpha1
kind: Backup
metadata:
  name: etcd-recurring-backup
spec:
  etcd:
    schedule: "20 4 * * *"
      1 
      
    timeZone: "UTC"
    pvcName: etcd-backup-pvc
      Copy to Clipboard Toggle word wrap
      1
      반복 백업에 대한 CronTab 스케줄입니다. 요구 사항에 맞게 이 값을 조정합니다.

    • 최대 백업 수에 따라 보존을 사용하려면 다음 키-값 쌍을 etcd 키에 추가합니다. 

      spec:
  etcd:
    retentionPolicy:
      retentionType: RetentionNumber
      1 
      
      retentionNumber:
        maxNumberOfBackups: 5
      2
      Copy to Clipboard Toggle word wrap
      1
      보존 유형입니다. 지정되지 않은 경우 기본값은 RetentionNumber 입니다.
      2
      유지할 최대 백업 수입니다. 요구 사항에 맞게 이 값을 조정합니다. 지정되지 않은 경우 기본값은 15 백업입니다.
      주의

      알려진 문제로 인해 보존된 백업 수가 구성된 값보다 큰 문제가 됩니다.

    • 백업 파일 크기에 따라 보존하려면 다음을 사용합니다. 

      spec:
  etcd:
    retentionPolicy:
      retentionType: RetentionSize
      retentionSize:
        maxSizeOfBackupsGb: 20
      1
      Copy to Clipboard Toggle word wrap
      1
      보관된 백업의 최대 파일 크기(GB)입니다. 요구 사항에 맞게 이 값을 조정합니다. 지정되지 않은 경우 기본값은 10GB입니다.
      주의

      알려진 문제로 인해 보존 백업의 최대 크기가 구성된 값보다 최대 10GB가 됩니다.

  4. 다음 명령을 실행하여 CRD에서 정의한 cron 작업을 생성합니다. 

    $ oc create -f etcd-recurring-backup.yaml
    Copy to Clipboard Toggle word wrap

  5. 생성된 cron 작업을 찾으려면 다음 명령을 실행합니다. 

    $ oc get cronjob -n openshift-etcd
    Copy to Clipboard Toggle word wrap

4.2. 비정상적인 etcd 멤버 교체
링크 복사

비정상적인 단일 etcd 멤버를 교체하는 프로세스는 시스템이 실행 중이 아니거나 노드가 준비되지 않았거나 etcd pod가 크래시 루프 상태에 있는 경우 etcd 멤버의 비정상적인 상태에 따라 달라집니다.

참고

대부분의 컨트롤 플레인 호스트가 손실된 경우 재해 복구 절차에 따라 이 절차 대신 이전 클러스터 상태로 복원 하십시오.

교체 중인 멤버 에서 컨트롤 플레인 인증서가 유효하지 않은 경우 이 절차 대신 만료된 컨트롤 플레인 인증서 복구 절차를 따라야 합니다.

컨트롤 플레인 노드가 유실되고 새 노드가 생성되는 경우 etcd 클러스터 Operator는 새 TLS 인증서 생성 및 노드를 etcd 멤버로 추가하는 프로세스를 진행합니다.

4.2.1. 비정상 etcd 멤버 식별
링크 복사

클러스터에 비정상적인 etcd 멤버가 있는지 여부를 확인할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • etcd 백업이 수행되었습니다. 자세한 내용은 " etcd 데이터 백업"을 참조하십시오.

프로세스

  1. 다음 명령을 사용하여 EtcdMembersAvailable 상태의 상태 조건을 확인하십시오. 

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

  2. 출력을 확인합니다. 

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy
    Copy to Clipboard Toggle word wrap

    이 출력 예는 ip-10-0-131-183.ec2.internal etcd 멤버가 비정상임을 보여줍니다.

4.2.2. 비정상적인 etcd 멤버의 상태 확인
링크 복사

비정상적인 etcd 멤버를 교체하는 프로세스는 etcd가 다음의 어떤 상태에 있는지에 따라 달라집니다.

  • 컴퓨터가 실행 중이 아니거나 노드가 준비되지 않았습니다.
  • etcd pod가 크래시 루프 상태에 있습니다.

다음 프로세스에서는 etcd 멤버가 어떤 상태에 있는지를 확인합니다. 이를 통해 비정상 etcd 멤버를 대체하기 위해 수행해야하는 단계를 확인할 수 있습니다.

참고

시스템이 실행되고 있지 않거나 노드가 준비되지 않았지만 곧 정상 상태로 돌아올 것으로 예상되는 경우 etcd 멤버를 교체하기 위한 절차를 수행할 필요가 없습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 비정상적인 etcd 멤버를 식별하고 있습니다.

프로세스

  1. 시스템이 실행되고 있지 않은지를 확인합니다. 

    $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running
    Copy to Clipboard Toggle word wrap

    출력 예

    ip-10-0-131-183.ec2.internal  stopped
    1
    Copy to Clipboard Toggle word wrap

    1
    이 출력은 노드와 노드 시스템의 상태를 나열합니다. 상태가 running이 아닌 경우 시스템은 실행되지 않습니다.

    시스템이 실행되고 있지 않은 경우, 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  2. 노드가 준비되지 않았는지 확인합니다.

    다음 조건 중 하나에 해당하면 노드가 준비되지 않은 것입니다.

    • 시스템이 실행중인 경우 노드에 액세스할 수 있는지 확인하십시오. 

      $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable
      Copy to Clipboard Toggle word wrap

      출력 예

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable
      1
      Copy to Clipboard Toggle word wrap

      1
      unreachable 상태의 노드가 나열되면 노드가 준비되지 않은 것 입니다.

    • 노드에 여전히 액세스할 수 있는 경우 노드가 NotReady로 나열되어 있는지 확인하십시오. 

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"
      Copy to Clipboard Toggle word wrap

      출력 예

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.33.4
      1
      Copy to Clipboard Toggle word wrap

      1
      노드가 NotReady로 표시되면 노드가 준비되지 않은 것입니다.

    노드가 준비되지 않은 경우 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  3. etcd pod가 크래시 루프 상태인지 확인합니다.

    시스템이 실행되고 있고 노드가 준비된 경우 etcd pod가 크래시 루프 상태인지 확인하십시오.

    1. 모든 컨트롤 플레인 노드가 Ready 로 나열되어 있는지 확인합니다. 

      $ oc get nodes -l node-role.kubernetes.io/master
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.33.4
ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.33.4
ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.33.4
      Copy to Clipboard Toggle word wrap

    2. etcd pod의 상태가 Error 또는 CrashloopBackoff인지 확인하십시오. 

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

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
      1 
      
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m
      Copy to Clipboard Toggle word wrap

      1
      이 pod의 상태는 Error이므로 etcd pod는 크래시 루프 상태입니다.

    etcd pod가 크래시 루프 상태인 경우etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

4.2.3. 비정상적인 etcd 멤버 교체
링크 복사

비정상적인 etcd 멤버의 상태에 따라 다음 절차 중 하나를 사용합니다.

  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체
  • 비정상 클러스터에 기본 컨트롤 플레인 노드 설치
  • etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체
  • 비정상 중지된 baremetal etcd 멤버 교체

다음에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 경우의 비정상적인 etcd 멤버를 교체하는 프로세스에 대해 자세히 설명합니다.

참고

클러스터가 컨트롤 플레인 머신 세트를 사용하는 경우 etcd 복구 절차에 대한 "컨트롤 플레인 머신 세트 문제 해결"의 "성능이 저하된 etcd Operator 복구"를 참조하세요.

사전 요구 사항

  • 비정상적인 etcd 멤버를 식별했습니다.

  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.

    중요

    다른 컨트롤 플레인 노드의 전원을 끄는 경우 기다려야 합니다. 비정상적인 etcd 멤버 교체가 완료될 때까지 컨트롤 플레인 노드의 전원을 꺼야 합니다.

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

  • etcd 백업이 수행되었습니다.

    중요

    이 절차를 수행하기 전에 문제가 발생할 경우 클러스터를 복원할 수 있도록 etcd 백업을 사용하십시오.

프로세스

  1. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 Pod를 선택하세요.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

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

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 절차의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. $ etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

  2. 다음 명령을 입력하여 쿼럼 가드를 끕니다. 

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

    이 명령을 사용하면 시크릿을 성공적으로 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

    중요

    쿼럼 가드를 끄면 나머지 etcd 인스턴스가 재부팅되는 동안 구성 변경 사항을 반영하는 동안 클러스터에 연결할 수 없을 수 있습니다.

    참고

    두 멤버로 실행하는 경우 etcd는 추가 멤버 실패를 허용할 수 없습니다. 나머지 멤버 중 하나를 다시 시작하면 쿼럼이 중단되고 클러스터의 다운 타임이 발생합니다. 쿼럼 가드에서는 다운타임을 일으킬 수 있는 구성 변경으로 인해 etcd가 다시 시작되지 않도록 보호하므로 이 절차를 완료하려면 비활성화해야 합니다.

  3. 다음 명령을 실행하여 영향을 받는 노드를 삭제합니다. 

    $ oc delete node <node_name>
    Copy to Clipboard Toggle word wrap

    명령 예

    $ oc delete node ip-10-0-131-183.ec2.internal
    Copy to Clipboard Toggle word wrap

  4. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

      출력 예

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

  5. 다음 명령을 입력하여 컨트롤 플레인 머신 세트가 있는지 확인합니다. 

    $ oc -n openshift-machine-api get controlplanemachineset
    Copy to Clipboard Toggle word wrap

    • 컨트롤 플레인 머신 세트가 있는 경우 컨트롤 플레인 시스템을 삭제하고 다시 생성합니다. 이 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd는 자동으로 확장됩니다. 자세한 내용은 "시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체"를 참조하십시오.

      설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 컨트롤 플레인을 생성하는 데 사용된 것과 동일한 방법을 사용하여 새 컨트롤 플레인을 생성해야 합니다.

      1. 비정상 멤버의 컴퓨터를 가져옵니다.

        클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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-154-204.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-164-97.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
        Copy to Clipboard Toggle word wrap

        1
        이는 비정상 노드의 컨트롤 플레인 시스템 ip-10-0-131-183.ec2.internal입니다.

      2. 비정상 멤버의 시스템을 삭제합니다. 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

        비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

      3. 새 머신이 생성되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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-154-204.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-164-97.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-133-53.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
        Copy to Clipboard Toggle word wrap

        1
        새 시스템 clustername-8qw5l-master-3이 생성되고 단계가 Provisioning에서 Running으로 변경되면 시스템이 준비 상태가 됩니다.

        새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

        참고

        시스템 세트에 사용하는 서브넷 ID를 확인하여 해당 ID가 올바른 가용성 영역에 속하는지 확인합니다.

    • 컨트롤 플레인 머신 세트가 없는 경우 컨트롤 플레인 시스템을 삭제하고 다시 생성합니다. 이 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd는 자동으로 확장됩니다.

      설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 컨트롤 플레인을 생성하는 데 사용된 것과 동일한 방법을 사용하여 새 컨트롤 플레인을 생성해야 합니다.

      1. 비정상 멤버의 컴퓨터를 가져옵니다.

        클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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-154-204.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-164-97.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
        Copy to Clipboard Toggle word wrap

        1
        이는 비정상 노드의 컨트롤 플레인 시스템 ip-10-0-131-183.ec2.internal입니다.

      2. 시스템 설정을 파일 시스템의 파일에 저장합니다. 

        $ oc get machine clustername-8qw5l-master-0 \
        1 
        
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
        Copy to Clipboard Toggle word wrap
        1
        비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

      3. 이전 단계에서 만든 new-master-machine.yaml 파일을 편집하여 새 이름을 할당하고 불필요한 필드를 제거합니다.

        1. 전체 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
          Copy to Clipboard Toggle word wrap

        2. metadata.name 필드를 새 이름으로 변경합니다.

          이전 시스템과 동일한 기본 이름을 유지하고 종료 번호를 사용 가능한 다음 번호로 변경합니다. 이 예에서 clustername-8qw5l-master-0은 clustername-8qw5l-master-3으로 변경되어 있습니다.

          예를 들면 다음과 같습니다. 

          apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
          Copy to Clipboard Toggle word wrap

        3. spec.providerID 필드를 삭제합니다. 

            providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
          Copy to Clipboard Toggle word wrap

      4. 비정상 멤버의 시스템을 삭제합니다. 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

      5. 시스템이 삭제되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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-154-204.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-164-97.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
        Copy to Clipboard Toggle word wrap

      6. new-master-machine.yaml 파일을 사용하여 새 머신을 생성합니다. 

        $ oc apply -f new-master-machine.yaml
        Copy to Clipboard Toggle word wrap

      7. 새 머신이 생성되었는지 확인합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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-154-204.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-164-97.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-133-53.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
        Copy to Clipboard Toggle word wrap

        1
        새 시스템 clustername-8qw5l-master-3이 생성되고 단계가 Provisioning에서 Running으로 변경되면 시스템이 준비 상태가 됩니다.

        새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

  6. 다음 명령을 입력하여 쿼럼 가드를 다시 켭니다. 

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

  7. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  8. 단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에 다음과 같은 오류가 발생할 수 있습니다.

    출력 예

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
    Copy to Clipboard Toggle word wrap

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

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

    출력 예

    etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m
    Copy to Clipboard Toggle word wrap

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

  2. 정확히 세 개의 etcd 멤버가 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.

4.2.3.2. etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체
링크 복사

이 단계에서는 etcd pod가 크래시 루프 상태에 있는 경우 비정상 etcd 멤버를 교체하는 방법을 설명합니다.

전제 조건

  • 비정상적인 etcd 멤버를 식별했습니다.
  • etcd pod가 크래시 루프 상태에 있는것으로 확인되었습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.

프로세스

  1. 크래시 루프 상태에 있는 etcd pod를 중지합니다.

    1. 크래시 루프 상태의 노드를 디버깅합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc debug node/ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      이를 비정상 노드의 이름으로 변경합니다.

    2. 루트 디렉토리를 /host 로 변경합니다. 

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

    3. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다. 

      sh-4.2# mkdir /var/lib/etcd-backup
      Copy to Clipboard Toggle word wrap 
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
      Copy to Clipboard Toggle word wrap

    4. etcd 데이터 디렉토리를 다른 위치로 이동합니다. 

      sh-4.2# mv /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

  2. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

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

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 62bcf33650a7170a
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

  3. 다음 명령을 입력하여 쿼럼 가드를 끕니다. 

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

    이 명령을 사용하면 시크릿을 성공적으로 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  4. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

      출력 예

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

  5. etcd를 강제로 재배포합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 수행하면 모든 컨트롤 플레인 노드가 etcd pod가 작동하는지 확인합니다.

  6. 다음 명령을 입력하여 쿼럼 가드를 다시 켭니다. 

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

  7. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  8. 단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에 다음 오류가 발생할 수 있습니다.

    출력 예

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
    Copy to Clipboard Toggle word wrap

검증

  • 새 멤버가 사용 가능하고 정상적인 상태에 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 다시 연결합니다.

      cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. 모든 멤버가 정상인지 확인합니다. 

      sh-4.2# etcdctl endpoint health
      Copy to Clipboard Toggle word wrap

      출력 예

      https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms
https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms
https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms
      Copy to Clipboard Toggle word wrap

다음 절차에서는 머신이 실행되고 있지 않거나 노드가 준비되지 않았기 때문에 비정상적인 베어 메탈 etcd 멤버를 교체하는 단계를 자세히 설명합니다.

설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오. 그렇지 않으면 원래 생성에 사용된 것과 동일한 방법을 사용하여 새 컨트롤 플레인 노드를 생성해야 합니다.

사전 요구 사항

  • 비정상 베어 메탈 etcd 멤버를 확인했습니다.
  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 절차를 수행하기 전에 etcd 백업을 수행해야 합니다.

프로세스

  1. 비정상 멤버를 확인하고 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

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

      출력 예

      etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

      클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 절차의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다. 

      sh-4.2# etcdctl member remove 7a8197040a5126c8
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| cc3830a72fc357f9 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

      중요

      멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 클러스터에 짧은 시간 동안 클러스터에 연결할 수 없을 수 있습니다.

  2. 다음 명령을 입력하여 쿼럼 가드를 끕니다. 

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

    이 명령을 사용하면 시크릿을 성공적으로 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

  3. 다음 명령을 실행하여 제거된 비정상 etcd 멤버의 이전 시크릿을 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2
      Copy to Clipboard Toggle word wrap

      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다. 

      etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd

secret "etcd-peer-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-metrics-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

  4. 비정상 멤버의 컴퓨터를 가져옵니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
    1 
    
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
    Copy to Clipboard Toggle word wrap

    1
    이는 비정상 노드의 컨트롤 플레인 시스템입니다( 예:cluster-control-plane-2 ).

  5. 다음 명령을 실행하여 Bare Metal Operator를 사용할 수 있는지 확인합니다. 

    $ oc get clusteroperator baremetal
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
baremetal   4.20.0    True        False         False      3d15h
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 이전 BareMetalHost 오브젝트를 제거합니다. 

    $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    출력 예

    baremetalhost.metal3.io "openshift-control-plane-2" deleted
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 비정상 멤버의 시스템을 삭제합니다. 

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2
    Copy to Clipboard Toggle word wrap

    BareMetalHost 및 Machine 오브젝트를 제거한 후 Machine 컨트롤러에서 Node 오브젝트를 자동으로 삭제합니다.

    어떠한 이유로든 머신 삭제가 지연되거나 명령이 방해되고 지연되는 경우 머신 오브젝트 종료자 필드를 제거하여 강제로 삭제할 수 있습니다.

    중요

    Ctrl+c 를 눌러 시스템 삭제를 중단하지 마십시오. 명령이 완료될 수 있도록 허용해야 합니다. 새 터미널 창을 열어 종료자 필드를 편집하고 삭제합니다.

    비정상 멤버의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

    1. 다음 명령을 실행하여 머신 구성을 편집합니다. 

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
      Copy to Clipboard Toggle word wrap

    2. Machine 사용자 정의 리소스에서 다음 필드를 삭제한 다음 업데이트된 파일을 저장합니다. 

      finalizers:
- machine.machine.openshift.io
      Copy to Clipboard Toggle word wrap

      출력 예

      machine.machine.openshift.io/examplecluster-control-plane-2 edited
      Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 머신이 삭제되었는지 확인합니다. 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
    Copy to Clipboard Toggle word wrap

  9. 다음 명령을 실행하여 노드가 삭제되었는지 확인합니다. 

    $ oc get nodes

NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 3h24m v1.33.4
openshift-control-plane-1 Ready master 3h24m v1.33.4
openshift-compute-0       Ready worker 176m v1.33.4
openshift-compute-1       Ready worker 176m v1.33.4
    Copy to Clipboard Toggle word wrap

  10. 새로운 BareMetalHost 오브젝트와 시크릿을 생성하여 BMC 인증 정보를 저장합니다. 

    $ cat <<EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: openshift-control-plane-2-bmc-secret
  namespace: openshift-machine-api
data:
  password: <password>
  username: <username>
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: openshift-control-plane-2
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: disabled
  bmc:
    address: redfish://10.46.61.18:443/redfish/v1/Systems/1
    credentialsName: openshift-control-plane-2-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:b0:8a:a0
  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
    참고

    사용자 이름과 암호는 다른 베어 메탈 호스트의 시크릿에서 확인할 수 있습니다. bmc:address 에서 사용할 프로토콜은 다른 bmh 오브젝트에서 가져올 수 있습니다.

    중요

    기존 컨트롤 플레인 호스트에서 BareMetalHost 오브젝트 정의를 재사용하는 경우 external Provisioned 필드를 true 로 설정하지 마십시오.

    OpenShift Container Platform 설치 프로그램에서 프로비저닝한 경우 기존 컨트롤 플레인 BareMetalHost 오브젝트의 external Provisioned 플래그가 true 로 설정될 수 있습니다.

    검사가 완료되면 BareMetalHost 오브젝트가 생성되고 프로비저닝할 수 있습니다.

  11. 사용 가능한 BareMetalHost 오브젝트를 사용하여 생성 프로세스를 확인합니다. 

    $ oc get bmh -n openshift-machine-api

NAME                      STATE                  CONSUMER                      ONLINE ERROR   AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 available              examplecluster-control-plane-3 true         47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m
    Copy to Clipboard Toggle word wrap

    1. 새 시스템이 생성되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
      1 
      
examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
      Copy to Clipboard Toggle word wrap

      1
      새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비됩니다.

      새 시스템을 생성하는 데 몇 분이 걸릴 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

    2. 다음 명령을 실행하여 베어 메탈 호스트가 프로비저닝되고 오류가 보고되지 않았는지 확인합니다. 

      $ oc get bmh -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      출력 예

      $ oc get bmh -n openshift-machine-api
NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 새 노드가 추가되었고 준비 상태에 있는지 확인합니다. 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

      출력 예

      $ oc get nodes
NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 4h26m v1.33.4
openshift-control-plane-1 Ready master 4h26m v1.33.4
openshift-control-plane-2 Ready master 12m   v1.33.4
openshift-compute-0       Ready worker 3h58m v1.33.4
openshift-compute-1       Ready worker 3h58m v1.33.4
      Copy to Clipboard Toggle word wrap

  12. 다음 명령을 입력하여 쿼럼 가드를 다시 켭니다. 

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

  13. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다. 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  14. 단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에 다음 오류가 발생할 수 있습니다.

    출력 예

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
    Copy to Clipboard Toggle word wrap

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

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

    출력 예

    etcd-openshift-control-plane-0      5/5     Running     0     105m
etcd-openshift-control-plane-1      5/5     Running     0     107m
etcd-openshift-control-plane-2      5/5     Running     0     103m
    Copy to Clipboard Toggle word wrap

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    정확히 세 개의 etcd 멤버가 있는지 확인하려면 실행 중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
    Copy to Clipboard Toggle word wrap

  2. 멤버 목록을 확인합니다. 

    sh-4.2# etcdctl member list -w table
    Copy to Clipboard Toggle word wrap

    출력 예

    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
|        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    Copy to Clipboard Toggle word wrap

    참고

    이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

  3. 다음 명령을 실행하여 모든 etcd 멤버가 정상인지 확인합니다. 

    # etcdctl endpoint health --cluster
    Copy to Clipboard Toggle word wrap

    출력 예

    https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 모든 노드가 최신 버전인지 확인합니다. 

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

4.3. 재해 복구
링크 복사

재해 복구 문서에서는 관리자에게 OpenShift Container Platform 클러스터에서 발생할 수있는 여러 재해 상황을 복구하는 방법에 대한 정보를 제공합니다. 관리자는 클러스터를 작동 상태로 복원하려면 다음 절차 중 하나 이상을 수행해야합니다.

중요

재해 복구를 위해서는 하나 이상의 정상 컨트롤 플레인 호스트가 있어야 합니다.

4.3.1. 쿼럼 복원
링크 복사

quorum-restore.sh 스크립트를 사용하여 쿼럼 손실로 인해 오프라인 상태의 클러스터에서 etcd 쿼럼을 복원할 수 있습니다. 쿼럼이 손실되면 OpenShift Container Platform API가 읽기 전용이 됩니다. 쿼럼이 복원되면 OpenShift Container Platform API가 읽기/쓰기 모드로 돌아갑니다.

4.3.1.1. 고가용성 클러스터를 위해 etcd 쿼럼 복원
링크 복사

quorum-restore.sh 스크립트를 사용하여 쿼럼 손실로 인해 오프라인 상태의 클러스터에서 etcd 쿼럼을 복원할 수 있습니다. 쿼럼이 손실되면 OpenShift Container Platform API가 읽기 전용이 됩니다. 쿼럼이 복원되면 OpenShift Container Platform API가 읽기/쓰기 모드로 돌아갑니다.

quorum-restore.sh 스크립트는 로컬 데이터 디렉터리를 기반으로 새 단일 멤버 etcd 클러스터를 즉시 다시 가져오고 이전 클러스터 ID를 다시 비활성화하여 다른 모든 멤버를 유효하지 않은 것으로 표시합니다. 컨트롤 플레인을 복원하려면 이전 백업이 필요하지 않습니다.

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

주의

복원을 실행하는 호스트에 모든 데이터가 복제되지 않으면 데이터 손실이 발생할 수 있습니다.

중요

쿼럼 복원은 복원 프로세스 외부에서 노드 수를 줄이는 데 사용해서는 안 됩니다. 노드 수를 줄이면 지원되지 않는 클러스터 구성이 발생합니다.

사전 요구 사항

  • 쿼럼을 복원하는 데 사용되는 노드에 대한 SSH 액세스 권한이 있어야 합니다.

프로세스

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

    1. 다음 명령을 실행하여 실행중인 etcd pod를 나열합니다. 

      $ oc get pods -n openshift-etcd -l app=etcd --field-selector="status.phase==Running"
      Copy to Clipboard Toggle word wrap

    2. Pod를 선택하고 다음 명령을 실행하여 IP 주소를 가져옵니다. 

      $ oc exec -n openshift-etcd <etcd-pod> -c etcdctl -- etcdctl endpoint status -w table
      Copy to Clipboard Toggle word wrap

      학습자가 아니며 가장 높은 Raft 인덱스가 있는 멤버의 IP 주소를 확인합니다.

    3. 다음 명령을 실행하고 선택한 etcd 멤버의 IP 주소에 해당하는 노드 이름을 확인합니다. 

      $ oc get nodes -o jsonpath='{range .items[*]}[{.metadata.name},{.status.addresses[?(@.type=="InternalIP")].address}]{end}'
      Copy to Clipboard Toggle word wrap

  2. SSH를 사용하여 선택한 복구 노드에 연결하고 다음 명령을 실행하여 etcd 쿼럼을 복원합니다. 

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

    몇 분 후에 다운된 노드가 복구 스크립트가 실행된 노드와 자동으로 동기화됩니다. 나머지 온라인 노드는 quorum-restore.sh 스크립트에서 만든 새 etcd 클러스터에 자동으로 다시 참여합니다. 이 프로세스는 몇 분 정도 걸립니다.

  3. SSH 세션을 종료합니다.

  4. 노드가 오프라인인 경우 3-노드 구성으로 돌아갑니다. 오프라인 상태인 각 노드에 대해 다음 단계를 반복하여 삭제하고 다시 생성합니다. 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd가 자동으로 확장됩니다.

    • 사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래에 사용한 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " bare metal에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.

      주의

      복구 호스트에 대한 시스템을 삭제하고 다시 생성하지 마십시오.

    • 설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.

      주의

      복구 호스트에 대한 시스템을 삭제하고 다시 생성하지 마십시오.

      설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 시스템이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.

      1. 오프라인 노드 중 하나에 대한 머신을 가져옵니다.

        클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        출력 예

        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
        Copy to Clipboard Toggle word wrap

        1
        오프라인 노드의 컨트롤 플레인 시스템인 ip-10-0-131-183.ec2.internal 입니다.

      2. 다음을 실행하여 오프라인 노드의 머신을 삭제합니다. 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        오프라인 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

        오프라인 노드의 시스템을 삭제한 후 새 머신이 자동으로 프로비저닝됩니다.

  5. 다음을 실행하여 새 시스템이 생성되었는지 확인합니다. 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

    1
    새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비됩니다.

    새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

    1. 오프라인 상태인 각 노드에 대해 이 단계를 반복합니다.

  6. 다음 명령을 실행하여 컨트롤 플레인을 복구할 때까지 기다립니다. 

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

    컨트롤 플레인을 복구하는 데 최대 15분이 걸릴 수 있습니다.

문제 해결

  • etcd 정적 pod를 롤아웃하는 진행 상황이 표시되지 않으면 다음 명령을 실행하여 etcd 클러스터 Operator에서 강제로 재배포할 수 있습니다. 

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

대부분의 컨트롤 플레인 노드를 계속 사용할 수 있고 etcd 쿼럼이 있는 경우 비정상적인 단일 etcd 멤버를 교체 합니다.

4.3.2. 이전 클러스터 상태로 복원
링크 복사

클러스터를 이전 상태로 복원하려면 스냅샷을 생성하여 etcd 데이터를 백업해야 합니다. 이 스냅샷을 사용하여 클러스터 상태를 복구합니다. 자세한 내용은 " etcd 데이터 백업"을 참조하십시오.

해당하는 경우 만료된 컨트롤 플레인 인증서에서 복구해야 할 수도 있습니다.

주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이 절차는 마지막 수단으로만 사용해야 합니다.

복원을 수행하기 전에 클러스터에 미치는 영향에 대한 자세한 내용은 "이전 클러스터 상태로 복원하는 기능"을 참조하십시오.

4.3.2.1. 이전 클러스터 상태로의 복원 정보
링크 복사

클러스터를 이전 상태로 복원하려면 스냅샷을 생성하여 etcd 데이터를 백업해야 합니다. 이 스냅샷을 사용하여 클러스터 상태를 복구합니다. 자세한 내용은 " etcd 데이터 백업"을 참조하십시오.

etcd 백업을 사용하여 클러스터를 이전 상태로 복원할 수 있습니다. 이를 사용하여 다음과 같은 상황에서 복구할 수 있습니다.

  • 클러스터에서 대부분의 컨트롤 플레인 호스트가 손실되었습니다(쿼럼 손실).
  • 관리자가 중요한 것을 삭제했으며 클러스터를 복구하려면 복원해야 합니다.
주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이는 마지막 수단으로만 사용해야 합니다.

Kubernetes API 서버를 사용하여 데이터를 검색할 수 있는 경우 etcd를 사용할 수 있으며 etcd 백업을 사용하여 복원할 수 없습니다.

etcd를 복원하려면 클러스터를 효율적으로 복원하는 데 시간이 걸리며 모든 클라이언트가 충돌하는 병렬 기록이 발생합니다. 이는 kubelets, Kubernetes 컨트롤러 관리자, 영구 볼륨 컨트롤러 및 네트워크 Operator를 포함하여 OpenShift Container Platform Operator와 같은 구성 요소 모니터링 동작에 영향을 미칠 수 있습니다.

이로 인해 etcd의 콘텐츠가 디스크의 실제 콘텐츠와 일치하지 않을 때 Operator가 문제가 발생하여 디스크의 파일이 etcd의 콘텐츠와 충돌할 때 Kubernetes API 서버, Kubernetes 컨트롤러 관리자, Kubernetes 스케줄러 및 etcd의 Operator가 중단될 수 있습니다. 여기에는 문제를 해결하기 위해 수동 작업이 필요할 수 있습니다.

극단적인 경우 클러스터에서 영구 볼륨 추적을 손실하고, 더 이상 존재하지 않는 중요한 워크로드를 삭제하고, 시스템을 다시 이미지화하고, 만료된 인증서로 CA 번들을 다시 작성할 수 있습니다.

4.3.2.2. 단일 노드의 이전 클러스터 상태로 복원
링크 복사

저장된 etcd 백업을 사용하여 단일 노드에서 이전 클러스터 상태를 복원할 수 있습니다.

중요

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

사전 요구 사항

  • 설치 중에 사용된 인증서 기반 kubeconfig 파일을 통해 cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 컨트롤 플레인 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • 동일한 백업에서 가져온 etcd 스냅샷과 정적 pod 리소스가 모두 포함된 백업 디렉토리입니다. 디렉토리의 파일 이름은 snapshot_<datetimestamp>.db 및 static_kuberesources_<datetimestamp>.tar.gz 형식이어야합니다.

프로세스

  1. SSH를 사용하여 단일 노드에 연결하고 다음 명령을 실행하여 etcd 백업을 /home/core 디렉터리에 복사합니다. 

    $ cp <etcd_backup_directory> /home/core
    Copy to Clipboard Toggle word wrap

  2. 단일 노드에서 다음 명령을 실행하여 이전 백업에서 클러스터를 복원합니다. 

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

  4. 다음 명령을 실행하여 컨트롤 플레인의 복구 진행 상황을 모니터링합니다. 

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

    컨트롤 플레인을 복구하는 데 최대 15분이 걸릴 수 있습니다.

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

저장된 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.20.2 클러스터는 4.20.2에서 가져온 etcd 백업을 사용해야 합니다.

사전 요구 사항

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

복구되지 않은 컨트롤 플레인 노드의 경우 SSH 연결을 설정하거나 정적 Pod를 중지할 필요가 없습니다. 복구되지 않은 다른 컨트롤 플레인 시스템을 삭제하고 다시 생성할 수 있습니다.

프로세스

  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 정적 pod를 롤아웃하는 진행 상황이 표시되지 않으면 다음 명령을 실행하여 cluster-etcd-operator 에서 강제로 재배포할 수 있습니다. 

$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Toggle word wrap
4.3.2.4. etcd 백업에서 수동으로 클러스터 복원
링크 복사

"이전 클러스터 상태로 복원" 섹션에 설명된 복원 절차:

  • UPI 설치 시 컨트롤 플레인 노드에 대한 Machine 또는 ControlPlaneMachineset 을 생성하지 않으므로 UPI 설치 방법을 사용하여 설치된 클러스터에 대한 2개의 컨트롤 플레인 노드를 완전히 다시 생성해야 합니다.
  • 새 단일 멤버 etcd 클러스터를 시작한 /usr/local/bin/cluster-restore.sh 스크립트를 사용하여 세 멤버로 확장합니다.

이와 반대로 이 절차는 다음과 같습니다.

  • 컨트롤 플레인 노드를 다시 생성할 필요가 없습니다.
  • 3개의 멤버 etcd 클러스터를 직접 시작합니다.

클러스터에서 컨트롤 플레인에 MachineSet 을 사용하는 경우 etcd 복구 절차를 위해 "Restoring to a previous cluster state"를 사용하는 것이 좋습니다.

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

사전 요구 사항

  • cluster-admin 역할(예: kubeadmin 사용자)을 사용하여 사용자로 클러스터에 액세스합니다.
  • 호스트 사용자를 사용하여 모든 컨트롤 플레인 호스트에 대한 SSH 액세스 ( 예: 기본 코어 호스트 사용자)
  • 이전 etcd 스냅샷과 동일한 백업의 정적 pod 리소스가 모두 포함된 백업 디렉터리입니다. 디렉토리의 파일 이름은 snapshot_<datetimestamp>.db 및 static_kuberesources_<datetimestamp>.tar.gz 형식이어야합니다.

프로세스

  1. SSH를 사용하여 각 컨트롤 플레인 노드에 연결합니다.

    복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 별도의 터미널에서 액세스하려는 각 컨트롤 플레인 호스트에 SSH 연결을 사용하는 것이 좋습니다.

    중요

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

  2. etcd 백업 디렉터리를 각 컨트롤 플레인 호스트에 복사합니다.

    이 절차에서는 etcd 스냅샷과 정적 pod의 리소스가 포함된 백업 디렉터리를 각 컨트롤 플레인 호스트의 /home/core/assets 디렉터리에 복사하는 것을 전제로 합니다. 아직 존재하지 않는 경우 이러한 assets 폴더를 생성해야 할 수도 있습니다.

  3. 모든 컨트롤 플레인 노드에서 정적 Pod를 중지합니다. 한 번에 하나의 호스트입니다.

    1. kubelet 매니페스트 디렉터리에서 기존 Kubernetes API Server 정적 Pod를 표시합니다. 

      $ mkdir -p /root/manifests-backup
      Copy to Clipboard Toggle word wrap 
      $ mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /root/manifests-backup/
      Copy to Clipboard Toggle word wrap

    2. 명령을 사용하여 Kubernetes API 서버 컨테이너가 중지되었는지 확인합니다. 

      $ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"
      Copy to Clipboard Toggle word wrap

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

    3. Kubernetes API Server 컨테이너가 계속 실행 중인 경우 다음 명령을 사용하여 수동으로 종료합니다. 

      $ crictl stop <container_id>
      Copy to Clipboard Toggle word wrap

    4. kube-controller-manager-pod.yaml,kube-scheduler-pod.yaml 및 마지막으로 etcd-pod.yaml 에 대해 동일한 단계를 반복합니다.

      1. 다음 명령을 사용하여 kube-controller-manager Pod를 중지합니다. 

        $ mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      2. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다. 

        $ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

      3. 다음 명령을 사용하여 kube-scheduler Pod를 중지합니다. 

        $ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      4. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다. 

        $ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

      5. 다음 명령을 사용하여 etcd pod를 중지합니다. 

        $ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      6. 다음 명령을 사용하여 컨테이너가 중지되었는지 확인합니다. 

        $ crictl ps | grep etcd | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

  4. 각 컨트롤 플레인 호스트에서 현재 etcd 데이터를 백업 폴더로 이동하여 저장합니다. 

    $ mkdir /home/core/assets/old-member-data
    Copy to Clipboard Toggle word wrap 
    $ mv /var/lib/etcd/member /home/core/assets/old-member-data
    Copy to Clipboard Toggle word wrap

    이 데이터는 etcd 백업 복원이 작동하지 않고 etcd 클러스터를 현재 상태로 복원해야 하는 경우 유용합니다.

  5. 각 컨트롤 플레인 호스트에 대해 올바른 etcd 매개변수를 찾습니다.

    1. < ETCD_NAME >의 값은 각 컨트롤 플레인 호스트에 대해 고유하며 매니페스트 /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml 파일의 ETCD_NAME 변수와 동일합니다. 다음 명령을 사용하여 찾을 수 있습니다. 

      RESTORE_ETCD_POD_YAML="/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml"
cat $RESTORE_ETCD_POD_YAML | \
  grep -A 1 $(cat $RESTORE_ETCD_POD_YAML | grep 'export ETCD_NAME' | grep -Eo 'NODE_.+_ETCD_NAME') | \
  grep -Po '(?<=value: ").+(?=")'
      Copy to Clipboard Toggle word wrap

    2. < UUID&gt;의 값은 명령을 사용하여 컨트롤 플레인 호스트에서 생성할 수 있습니다. 

      $ uuidgen
      Copy to Clipboard Toggle word wrap
      참고

      < UUID> 의 값은 한 번만 생성되어야 합니다. 하나의 컨트롤 플레인 호스트에서 UUID 를 생성한 후 다른 컨트롤 플레인 호스트에서 다시 생성하지 마십시오. 모든 컨트롤 플레인 호스트의 다음 단계에서 동일한 UUID 를 사용합니다.

    3. ETCD_NODE_PEER_URL 의 값은 다음 예와 같이 설정해야 합니다. 

      https://<IP_CURRENT_HOST>:2380
      Copy to Clipboard Toggle word wrap

      올바른 IP는 특정 컨트롤 플레인 호스트의 < ETCD_NAME >에서 명령을 사용하여 찾을 수 있습니다. 

      $ echo <ETCD_NAME> | \
  sed -E 's/[.-]/_/g' | \
  xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env | \
  grep "IP" | grep -Po '(?<=").+(?=")'
      Copy to Clipboard Toggle word wrap

    4. < ETCD_INITIAL_CLUSTER >의 값은 다음과 같이 설정해야 합니다. 여기서 < ETCD_NAME_n >은 각 컨트롤 플레인 호스트의 < ETCD_NAME >입니다.

      참고

      사용되는 포트는 2380이어야 하며 2379가 아닙니다. 포트 2379는 etcd 데이터베이스 관리에 사용되며 컨테이너의 etcd start 명령에 직접 구성됩니다.

      출력 예

      <ETCD_NAME_0>=<ETCD_NODE_PEER_URL_0>,<ETCD_NAME_1>=<ETCD_NODE_PEER_URL_1>,<ETCD_NAME_2>=<ETCD_NODE_PEER_URL_2>
      1
      Copy to Clipboard Toggle word wrap

      1
      각 컨트롤 플레인 호스트의 ETCD_NODE_PEER_URL 값을 지정합니다.

      & lt;ETCD_INITIAL_CLUSTER& gt; 값은 모든 컨트롤 플레인 호스트에서 동일하게 유지됩니다. 모든 컨트롤 플레인 호스트의 다음 단계에서 동일한 값이 필요합니다.

  6. 백업에서 etcd 데이터베이스를 다시 생성합니다.

    이러한 작업은 각 컨트롤 플레인 호스트에서 실행해야 합니다.

    1. 다음 명령을 사용하여 etcd 백업을 /var/lib/etcd 디렉토리에 복사합니다. 

      $ cp /home/core/assets/backup/<snapshot_yyyy-mm-dd_hhmmss>.db /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    2. 계속하기 전에 올바른 etcdctl 이미지를 식별합니다. 다음 명령을 사용하여 Pod 매니페스트 백업에서 이미지를 검색합니다. 

      $ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml
      Copy to Clipboard Toggle word wrap 
      $ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>
      Copy to Clipboard Toggle word wrap

    3. etcdctl 도구 버전이 백업이 생성된 etcd 서버의 버전인지 확인합니다. 

      $ etcdctl version
      Copy to Clipboard Toggle word wrap

    4. 현재 호스트에 올바른 값을 사용하여 etcd 데이터베이스를 다시 생성하려면 다음 명령을 실행합니다. 

      $ ETCDCTL_API=3 /usr/bin/etcdctl snapshot restore /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db \
  --name "<ETCD_NAME>" \
  --initial-cluster="<ETCD_INITIAL_CLUSTER>" \
  --initial-cluster-token "openshift-etcd-<UUID>" \
  --initial-advertise-peer-urls "<ETCD_NODE_PEER_URL>" \
  --data-dir="/var/lib/etcd/restore-<UUID>" \
  --skip-hash-check=true
      Copy to Clipboard Toggle word wrap
      참고

      etcd 데이터베이스를 다시 생성할 때는 따옴표가 필요합니다.

  7. 추가된 멤버 로그에 출력된 값을 기록합니다. 예를 들면 다음과 같습니다.

    출력 예

    2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "56cd73b614699e7", "added-peer-peer-urls": ["https://10.0.91.5:2380"], "added-peer-is-learner": false}
2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "1f63d01b31bb9a9e", "added-peer-peer-urls": ["https://10.0.90.221:2380"], "added-peer-is-learner": false}
2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "fdc2725b3b70127c", "added-peer-peer-urls": ["https://10.0.94.214:2380"], "added-peer-is-learner": false}
    Copy to Clipboard Toggle word wrap

    1. 컨테이너를 종료합니다.
    2. 다른 컨트롤 플레인 호스트에서 이러한 단계를 반복하여 추가된 멤버 로그에 출력된 값이 모든 컨트롤 플레인 호스트에 대해 동일한지 확인합니다.

  8. 재생성된 etcd 데이터베이스를 기본 위치로 이동합니다.

    이러한 작업은 각 컨트롤 플레인 호스트에서 실행해야 합니다.

    1. 재현된 데이터베이스(이전 etcdctl snapshot restore 명령으로 생성된 멤버 폴더)를 기본 etcd 위치 /var/lib/etcd:로 이동합니다. 

      $ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    2. /var/lib/etcd /member 폴더에서 /var/lib/etcd/member 폴더의 SELinux 컨텍스트를 복원합니다. 

      $ restorecon -vR /var/lib/etcd/
      Copy to Clipboard Toggle word wrap

    3. 남은 파일과 디렉터리를 제거합니다. 

      $ rm -rf /var/lib/etcd/restore-<UUID>
      Copy to Clipboard Toggle word wrap 
      $ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db
      Copy to Clipboard Toggle word wrap
      중요

      완료되면 /var/lib/etcd 디렉토리에 폴더 멤버 만 포함되어야 합니다.

    4. 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

  9. etcd 클러스터를 다시 시작하십시오.

    1. 다음 단계는 모든 컨트롤 플레인 호스트에서 실행해야 하지만 한 번에 하나의 호스트 를 실행해야 합니다.

    2. kubelet이 관련 컨테이너를 시작하도록 하려면 etcd 정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동합니다. 

      $ mv /root/manifests-backup/etcd-pod.yaml /etc/kubernetes/manifests
      Copy to Clipboard Toggle word wrap

    3. 모든 etcd 컨테이너가 시작되었는지 확인합니다. 

      $ crictl ps | grep etcd | grep -v operator
      Copy to Clipboard Toggle word wrap

      출력 예

      38c814767ad983       f79db5a8799fd2c08960ad9ee22f784b9fbe23babe008e8a3bf68323f004c840                                                         28 seconds ago       Running             etcd-health-monitor                   2                   fe4b9c3d6483c
e1646b15207c6       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd-metrics                          0                   fe4b9c3d6483c
08ba29b1f58a7       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd                                  0                   fe4b9c3d6483c
2ddc9eda16f53       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcdctl
      Copy to Clipboard Toggle word wrap

      이 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인하십시오.

  10. etcd 클러스터의 상태를 확인합니다.

    1. 다음 명령을 사용하여 컨트롤 플레인 호스트에서 etcd 클러스터의 상태를 확인합니다. 

      $ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table
      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.89.133:2379 | 682e4a83a0cec6c0 |   3.5.0 |   67 MB |      true |      false |         2 |        218 |                218 |        |
|  https://10.0.92.74:2379 | 450bcf6999538512 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
| https://10.0.93.129:2379 | 358efa9c1d91c3d6 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

  11. 다른 정적 pod를 다시 시작합니다.

    한 번에 하나의 호스트이지만 모든 컨트롤 플레인 호스트에서 다음 단계를 실행해야 합니다.

    1. Kubernetes API Server 정적 Pod 매니페스트를 kubelet 매니페스트 디렉터리로 다시 이동하여 kubelet이 명령을 사용하여 관련 컨테이너를 시작합니다. 

      $ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests
      Copy to Clipboard Toggle word wrap

    2. 모든 Kubernetes API Server 컨테이너가 시작되었는지 확인합니다. 

      $ crictl ps | grep kube-apiserver | grep -v operator
      Copy to Clipboard Toggle word wrap
      참고

      다음 명령의 출력이 비어 있으면 몇 분 기다렸다가 다시 확인합니다.

    3. kube-controller-manager-pod.yaml 및 kube-scheduler-pod.yaml 파일에 대해 동일한 단계를 반복합니다.

      1. 다음 명령을 사용하여 모든 노드에서 kubelet을 다시 시작합니다. 

        $ systemctl restart kubelet
        Copy to Clipboard Toggle word wrap

      2. 다음 명령을 사용하여 나머지 컨트롤 플레인 Pod를 시작합니다. 

        $ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/
        Copy to Clipboard Toggle word wrap

      3. kube-apiserver,kube-scheduler 및 kube-controller-manager Pod가 올바르게 시작되었는지 확인합니다. 

        $ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'
        Copy to Clipboard Toggle word wrap

      4. 다음 명령을 사용하여 OVN 데이터베이스를 지웁니다. 

        for NODE in  $(oc get node -o name | sed 's:node/::g')
do
  oc debug node/${NODE} -- chroot /host /bin/bash -c  'rm -f /var/lib/ovn-ic/etc/ovn*.db && systemctl restart ovs-vswitchd ovsdb-server'
  oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --wait
  oc -n openshift-ovn-kubernetes wait pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --for condition=ContainersReady --timeout=600s
done
        Copy to Clipboard Toggle word wrap
4.3.2.5. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법
링크 복사

OpenShift Container Platform 클러스터에서 모든 형식의 영구저장장치를 사용하는 경우 일반적으로 클러스터의 상태가 etcd 외부에 저장됩니다. 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 리소스 삭제참조).

4.3.3. 만료된 컨트롤 플레인 인증서 복구
링크 복사

클러스터는 만료된 컨트롤 플레인 인증서에서 자동으로 복구될 수 있습니다.

그러나 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 사용자 프로비저닝 설치의 경우 보류 중인 kubelet 서비스 CSR을 승인해야 할 수도 있습니다.

보류중인 CSR을 승인하려면 다음 단계를 수행합니다.

프로세스

  1. 현재 CSR의 목록을 가져옵니다. 

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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
csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    2 
    
csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...
    Copy to Clipboard Toggle word wrap

    1
    보류 중인 kubelet 서비스 CSR(사용자 프로비저닝 설치용)입니다.
    2
    보류 중인 node-bootstrapper CSR입니다.

  2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다. 

    $ oc describe csr <csr_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

  3. 각각의 유효한 node-bootstrapper CSR을 승인합니다. 

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

  4. 사용자 프로비저닝 설치의 경우 CSR을 제공하는 각 유효한 kubelet을 승인합니다. 

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

4.3.4. 복원 절차 테스트
링크 복사

복원 절차를 테스트하는 것은 자동화와 워크로드가 새 클러스터 상태를 정상적으로 처리하도록 하는 데 중요합니다. etcd 쿼럼과 etcd Operator의 복잡한 특성으로 인해 클러스터를 복원할 수 있는 충분한 상태로 클러스터를 올바르게 가져오기가 쉽지 않은 경우가 많습니다.

주의

클러스터에 대한 SSH 액세스 권한이 있어야 합니다. SSH 액세스없이 클러스터가 완전히 손실될 수 있습니다.

사전 요구 사항

  • 컨트롤 플레인 호스트에 대한 SSH 액세스 권한이 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. SSH를 사용하여 복구되지 않은 각 노드에 연결하고 다음 명령을 실행하여 etcd 및 kubelet 서비스를 비활성화합니다.

    1. 다음 명령을 실행하여 etcd를 비활성화합니다. 

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

    2. 다음 명령을 실행하여 etcd의 변수 데이터를 삭제합니다. 

      $ sudo rm -rf /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    3. 다음 명령을 실행하여 kubelet 서비스를 비활성화합니다. 

      $ sudo systemctl disable kubelet.service
      Copy to Clipboard Toggle word wrap
  2. 모든 SSH 세션을 종료합니다.

  3. 다음 명령을 실행하여 복구되지 않은 노드가 NOT READY 상태에 있는지 확인합니다. 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
  4. 클러스터를 복원하려면 "이전 클러스터 상태 복원"의 단계에 따릅니다.

  5. 클러스터와 API가 응답하는 후 SSH를 사용하여 복구되지 않은 각 노드에 연결하고 kubelet 서비스를 활성화합니다. 

    $ sudo systemctl enable kubelet.service
    Copy to Clipboard Toggle word wrap
  6. 모든 SSH 세션을 종료합니다.

  7. 다음 명령을 실행하여 READY 상태로 돌아가 노드를 관찰합니다. 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 etcd를 사용할 수 있는지 확인합니다. 

    $ oc get pods -n openshift-etcd
    Copy to Clipboard Toggle word wrap

5장. etcd 암호화 활성화
링크 복사

5.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 상태를 복원해야 합니다.

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

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

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

5.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가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

5.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가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

6장. 데이터 센터에 걸쳐 있는 클러스터에 대한 지침
링크 복사

Red Hat은 OpenShift Container Platform 클러스터가 데이터 센터 내에 배포되는 배포 모델을 강력히 권장하지만, 공급자가 클러스터가 데이터 센터 전체에 걸쳐 있을 수 있는 배포 모델을 사용할 수 있는 시나리오가 있을 수 있음을 인지하고 있습니다. 이 문서에서는 많은 데이터 센터에 걸쳐 있는 클러스터 배포를 살펴보고 배포 가능성에 영향을 미치는 중요한 메트릭을 설명할 때 고려해야 할 사항을 간략하게 설명합니다. 이러한 배포 설계는 제품이 최적으로 작동할 수 있도록 이러한 지침을 준수하고 적절한 제품 지원 서브스크립션을 통해 최고 수준의 지원을 보장해야 합니다.

주의

많은 데이터 센터에 걸쳐 있는 클러스터 배포는 위치를 통해 클러스터를 단일 장애 도메인으로 확장하며 재해 복구 계획을 대체하지 않아야 합니다.

많은 데이터 센터에 걸쳐 있는 클러스터 배포가 있는 클러스터는 표준 Red Hat OpenShift Container Platform 지원 지침에 따라 바인딩됩니다. 자세한 내용은 Red Hat OpenShift Container Platform 라이프 사이클 및 Red Hat 제품 지원 적용 범위를 참조하십시오.

많은 사이트에 걸쳐 있는 OpenShift Container Platform 클러스터를 배포하지 않는 것이 좋습니다. 많은 데이터 센터 또는 지역에 있어야 하는 경우 리전 또는 사이트당 하나의 클러스터를 배포하고 Red Hat Advanced Cluster Management for Kubernetes (ACM)와 같은 도구를 사용하여 이러한 클러스터 및 배포를 관리합니다.

일부 OpenShift Container Platform 플랫폼은 많은 데이터 센터 배포에 대해 특정 지원을 제공합니다. 자세한 내용은 플랫폼별 제품 문서 및 릴리스 노트를 확인하십시오. 다른 플랫폼은 노드 간 네트워크 연결의 품질에 따라 데이터 센터에 걸쳐 있을 수 있습니다. 자세한 내용은 etcd 및 성능에 영향을 미치는 튜닝 가능 항목/조건 이해를 참조하십시오.

많은 데이터 센터에 걸쳐 있는 클러스터 배포를 구현할 때 Red Hat OpenShift Container Platform High Availability 및 Recommended Practices 에 설명된 사례를 구현해야 합니다. 다중 사이트 배포의 대안은 ACM에서 관리하는 사이트당 하나의 OpenShift Container Platform 클러스터를 배포하는 것입니다.

6.1. 확장된 클러스터의 배포 경고
링크 복사

이 문서에 제공된 지침은 데이터 센터에 걸쳐 있는 클러스터 배포의 일반적인 측면에 중점을 둡니다. 명심해야 할 몇 가지 경고 사항:

  • 데이터 센터에 걸쳐 있는 배포 설계는 특수 지원 요구 사항에 부합하지 않지만 표준 단일 사이트 클러스터에 비해 추가 고려 사항이나 지원(시간, 문제 확인, 수정, 해결)이 필요할 수 있는 추가적인 내재적 복잡성이 있습니다.
  • Kube API 대기 시간이 길거나 트랜잭션 속도가 낮은 클러스터에서 애플리케이션이 제대로 작동하지 않거나 전혀 작동하지 않을 수 있습니다.
  • 스토리지 공급자와 같은 계층화된 제품은 대기 시간이 단축됩니다. 이러한 경우 대기 시간 제한은 계층화된 제품에서 지원하는 아키텍처에서 지정합니다.

  • 실패 시나리오는 확장된 컨트롤 플레인으로 확대되고 영향을 받는 방식은 배포와 관련이 있습니다. 이로 인해 프로덕션 환경의 데이터 센터에 걸쳐 있는 배포를 사용하기 전에 조직은 다음과 같은 중단 중에 클러스터의 동작을 테스트하고 문서화해야 합니다.

    • 하나, 둘 또는 모든 컨트롤 플레인 노드를 분리한 네트워크 파티션이 있는 경우
    • 컨트롤 플레인 노드 간 전송 네트워크에 MTU 불일치가 있는 경우
    • 1개 이상의 컨트롤 플레인 노드를 향하는 Day 2 이벤트로 대기 시간이 지속적으로 급증하는 경우
    • 네트워크 혼잡, 잘못된 구성 또는 QoS 부족, 패킷 오류를 유발하는 중간 네트워크 장치 및 기타 오류로 인해 지터에 상당한 변경이 있는 경우
  • 많은 사이트, 네트워크 인프라, 스토리지 인프라 또는 기타 구성 요소에 배포된 클러스터에는 더 많은 장애 지점이 있습니다. 네트워크 중단 또는 분할이 이러한 클러스터에 큰 위협으로 작용하여 특히 노드가 서로 연결이 끊어질 위험이 있습니다. 이러한 다중 사이트 클러스터는 이러한 오류를 염두에 두고 설계되어야 합니다. 다중 사이트 클러스터를 배포하는 조직은 장애 시나리오를 광범위하게 테스트해야 하며 클러스터가 모든 장애 지점으로부터 보호되는지 여부를 고려해야 합니다. 탄력적 고가용성 클러스터 설계의 중요한 측면을 검토하려면 Red Hat 지원팀에 문의하십시오.
  • 경우에 따라 GEO 인식은 대기 시간을 최소화하기 위해 해결해야 하는 요구 사항 또는 문제이므로GSLB(Global Service Load Balancing) 방법을 올바르게 구현할 수 있어야 합니다.

6.2. IaaS(Infrastructure as a Service) 및 클라우드 공급자 고려 사항
링크 복사

이 지침은 "User Managed Network" 옵션을 사용하는 사용자 프로비저닝 인프라 설치 프로그램(platform=none) 또는 에이전트 기반 설치 프로그램(platform=metal)에서 OpenShift Container Platform 컨트롤 플레인 노드를 지원하는 모든 인프라 공급자에 적용됩니다. 설치 관리자 프로비저닝 인프라 설치 프로그램은 이러한 지침의 적용을 받지 않지만 가능한 경우 설치 관리자 프로비저닝 인프라 배포는 클라우드 또는 IaaS 공급자의 영역 또는 가용성 영역에 걸쳐 이러한 지침 또는 유사한 지침에 따라 다릅니다. 즉, 인프라 공급자별 통합을 사용할 수 없습니다(예: 스토리지 서비스 및 로드 밸런서와 같은 클라우드 공급자 서비스와의 통합). 공급자별 서비스를 외부 서비스로 계속 사용할 수 있습니다.

컨트롤 플레인 노드에 다른 인프라 플랫폼 공급자를 사용하는 것은 권장되지 않습니다(예: IaaS, 클라우드 및 베어 메탈에서 노드를 컨트롤 플레인 노드로 혼합). 이러한 조합이 필요한 경우 다음 지침을 고려하십시오.

  • 인프라의 최소 유효 MTU는 배포에 사용되는 최대 MTU여야 합니다. 더 낮은 MTU를 사용할 수 있습니다. 자세한 내용은 OpenShift Container Platform 4.x로 MTU 설정 이해 및 유효성 검사를 참조하십시오.
  • 결합된 디스크 및 네트워크 대기 시간 및 지터는 etcd 피어 라운드 트립 시간을 100ms 미만으로 유지해야 합니다. 이는 네트워크 라운드 트립 시간과 동일하지 않습니다.
  • 계층화된 제품은 대기 시간이 단축될 수 있습니다. 이러한 경우 대기 시간 제한은 계층화된 제품에서 지원하는 아키텍처의 요구 사항에 따라 결정됩니다. 예를 들어 Red Hat OpenShift Data Foundation을 사용하여 데이터 센터에 걸쳐 있는 OpenShift Container Platform 클러스터 배포에는 대기 시간 요구 사항이 10ms RTT 미만이어야 합니다. 이러한 경우 특정 제품 지침을 따르십시오.
  • OpenShift Data Foundation을 스토리지 공급자로 사용하여 데이터 센터에 걸쳐 있는 클러스터 배포에 대한 지침은 OpenShift 워크로드 용 OpenShift Data Foundation 재해 복구 구성을 참조하십시오.

6.3. 사이트 권장 사항
링크 복사

각 사이트에 하나의 컨트롤 플레인 멤버가 있다고 가정하면 이론적으로는 Red Hat이 권장하는 세 개의 사이트를 정의합니다. 이를 통해 하나의 데이터 센터가 비활성 상태로 전환되고 클러스터는 쿼럼 및 운영 일관성을 유지할 수 있습니다.

이러한 가정이 충족되지 않으면 종종 배포의 운영 기능(업시 및 안정성)을 간략하게 설명하거나 지시하므로 클러스터의 원하는 내결함성 상태에 주의해야 합니다.

6.4. etcd, 네트워킹 및 스토리지에 대한 요구사항
링크 복사

데이터 센터에 걸쳐 있는 클러스터에 대한 다음 요구 사항을 고려하십시오.

6.4.1. etcd 요구 사항
링크 복사

etcd 클러스터 배포를 계획하는 데 필요한 요인 및 고려 사항이 많이 있습니다. 데이터 센터에 걸쳐 있는 OpenShift Container Platform 클러스터를 계획할 때 과부하가 발생할 가능성이 있는 상황을 계획하거나 운영 제한의 에지로 etcd를 푸시해야 합니다.

운영 기능을 유지하고 클러스터 의 서비스 영향을 미치는 이벤트 및 불안정성을 줄이는 방법에 대한 자세한 내용은 etcd 및 성능에 영향을 미치는 조정 가능 항목/조건 이해 를 참조하십시오.

6.4.2. 네트워크 요구 사항
링크 복사

선택한 네트워크 토폴로지는 노드 간에 직접 IP 연결을 산출해야 합니다. 인프라의 최소 유효 MTU는 배포에 사용되는 최대 MTU여야 합니다. 더 낮은 MTU를 사용할 수 있습니다.

자세한 내용은 OpenShift Container Platform 4.x로 MTU 설정 이해 및 유효성 검사를 참조하십시오. 대기 시간 요구는 궁극적으로 네트워크를 사용하는 서비스에 의해 정의됩니다. 요구 사항에 대한 자세한 내용은 etcd 및 스토리지와 관련된 섹션을 참조하십시오.

기본 네트워킹 요구 사항 외에도 애플리케이션에 액세스하는 방법을 고려해야 합니다. 외부 트래픽이 OpenShift Container Platform 컨트롤 플레인 서비스 및 인그레스 컨트롤러에 연결하기 위해 OpenShift Container Platform 외부에서 최상위 수준의 글로벌 서비스 로드 밸런싱(GSLB) 방법이 필요합니다.

6.4.3. 스토리지 요구사항
링크 복사

데이터 센터에 걸쳐 있는 클러스터 배포를 고려할 때 모든 사이트, 내결함성, 고가용성 등의 접근성과 관련하여 다중 사이트 요구 사항을 충족하도록 선택한 스토리지 통합에 특별한 고려가 필요합니다.

오브젝트 스토리지 솔루션은 레지스트리에 사용해야 하며 이 스토리지 솔루션은 애플리케이션 볼륨 또는 워크로드에 사용되는 PV 스토리지 통합 외에도 사용해야 합니다. 이 개체 스토리지 솔루션에는 모든 사이트, 내결함성, 고가용성 등의 접근성에 제공된 동일한 특별한 고려 사항이 있어야 합니다.

디스크 I/O는 etcd 데이터베이스의 상태에서 중요한 요소이므로 높은 속도, 짧은 대기 시간 미디어에 배포해야 합니다. 충족해야 하는 정확한 요구 사항에 대한 자세한 내용은 etcd 피어 라운드 트립 시간과 etcd 데이터베이스 크기에 대한 etcd 지침을 참조하십시오.

6.5. 워크로드 배치 고려 사항
링크 복사

멀티사이트 클러스터를 사용하면 관리자와 개발자는 클러스터 토폴로지 내의 적절한 하드웨어 또는 호스트를 기반으로 중요한 워크로드를 예약하거나 배치하기 위해 특별한 고려 사항을 고려해야 합니다. 이렇게 하면 클러스터 배포 토폴로지에 따라 애플리케이션 및 서비스가 고가용성 및 Fault Tolerant가 됩니다.

이를 고려하지 않고 OpenShift Container Platform은 데이터 센터 중단이 있는 경우 OpenShift Container Platform 인프라 서비스 및 기타 애플리케이션 서비스에 대해 SPoF(Single Point of Failure)가 생성되도록 클러스터 내의 호스트에서 워크로드를 예약할 수 있습니다.

Legal Notice
링크 복사

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat맨 위로 이동