1.3. etcd 관련 권장 사례
이 주제에서는 OpenShift Container Platform의 etcd에 대한 권장 성능 및 확장성 사례를 제공합니다.
1.3.1. etcd 관련 권장 사례
etcd는 디스크에 데이터를 작성하고 디스크에 제안을 유지하므로 성능은 디스크 성능에 따라 다릅니다. etcd는 특히 I/O 집약적이지만 최적의 성능과 안정성을 위해 짧은 대기 시간 블록 장치가 필요합니다. etcd의 접합성 프로토콜은 메타데이터를 로그(WAL)에 영구적으로 저장하는 데 따라 다르기 때문에 etcd는 디스크 쓰기 대기 시간에 민감합니다. 다른 프로세스의 디스크 및 디스크 활동이 느리면 fsync 대기 시간이 길어질 수 있습니다.
이러한 대기 시간으로 인해 etcd가 하트비트를 놓치고 새 제안을 제 시간에 디스크에 커밋하지 않고 궁극적으로 요청 시간 초과 및 임시 리더 손실이 발생할 수 있습니다. 쓰기 대기 시간이 길어지면 OpenShift API 속도가 느려서 클러스터 성능에 영향을 미칩니다. 이러한 이유로 I/O 민감하거나 집약적이며 동일한 기본 I/O 인프라를 공유하는 컨트롤 플레인 노드에서 다른 워크로드를 배치하지 마십시오.
대기 시간 측면에서 8000바이트의 최소 50 IOPS를 순차적으로 작성할 수 있는 블록 장치 상단에서 etcd를 실행합니다. 즉, 대기 시간이 10ms인 경우 fdatasync를 사용하여 WAL의 각 쓰기를 동기화합니다. 로드가 많은 클러스터의 경우 8000바이트(2ms)의 순차적 500 IOPS를 권장합니다. 이러한 숫자를 측정하려면 fio와 같은 벤치마킹 툴을 사용할 수 있습니다.
이러한 성능을 달성하려면 대기 시간이 짧고 처리량이 높은 SSD 또는 NVMe 디스크에서 지원하는 머신에서 etcd를 실행합니다. 메모리 셀당 1비트를 제공하는 SSD(Single-level cell) SSD(Solid-State Drive)는 Cryostat 및 reliable이며 쓰기 집약적인 워크로드에 이상적입니다.
etcd의 로드는 노드 및 Pod 수와 같은 정적 요인과 Pod 자동 스케일링, Pod 재시작, 작업 실행 및 기타 워크로드 관련 이벤트로 인한 끝점 변경 등 동적 요인에서 발생합니다. etcd 설정의 크기를 정확하게 조정하려면 워크로드의 특정 요구 사항을 분석해야 합니다. etcd의 로드에 영향을 미치는 노드, 포드 및 기타 관련 요인을 고려하십시오.
다음 하드 드라이브 사례는 최적의 etcd 성능을 제공합니다.
- 전용 etcd 드라이브를 사용합니다. iSCSI와 같이 네트워크를 통해 통신하는 드라이브를 방지합니다. etcd 드라이브에 로그 파일 또는 기타 많은 워크로드를 배치하지 마십시오.
- 빠른 읽기 및 쓰기 작업을 지원하기 위해 대기 시간이 짧은 드라이브를 선호합니다.
- 더 빠른 압축 및 조각 모음을 위해 고 대역폭 쓰기를 선호합니다.
- 실패에서 더 빠른 복구를 위해 고 대역폭 읽기를 선호합니다.
- 솔리드 스테이트 드라이브를 최소 선택으로 사용하십시오. 프로덕션 환경에 대한 NVMe 드라이브를 선호합니다.
- 안정성 향상을 위해 서버 수준 하드웨어를 사용하십시오.
NAS 또는 SAN 설정 및 회전 드라이브를 방지합니다. Ceph Rados Block Device(RBD) 및 기타 유형의 네트워크 연결 스토리지로 인해 네트워크 대기 시간이 예측할 수 없습니다. 대규모 etcd 노드에 빠른 스토리지를 제공하려면 PCI 패스스루를 사용하여 NVM 장치를 노드에 직접 전달합니다.
항상 fio와 같은 유틸리티를 사용하여 벤치마크합니다. 이러한 유틸리티를 사용하여 증가에 따라 클러스터 성능을 지속적으로 모니터링할 수 있습니다.
NFS(Network File System) 프로토콜 또는 기타 네트워크 기반 파일 시스템을 사용하지 마십시오.
배포된 OpenShift Container Platform 클러스터에서 모니터링할 몇 가지 주요 지표는 etcd 디스크 쓰기 전 로그 기간과 etcd 리더 변경 횟수입니다. 이러한 지표를 추적하려면 Prometheus를 사용하십시오.
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
Docker를 사용하는 경우 다음 명령을 실행합니다.
$ sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
출력에서는 실행에서 캡처된 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 미만이어야 합니다.
1.3.2. etcd를 다른 디스크로 이동
etcd를 공유 디스크에서 별도의 디스크로 이동하여 성능 문제를 방지하거나 해결할 수 있습니다.
MCO(Machine Config Operator)는 OpenShift Container Platform 4.15 컨테이너 스토리지를 위한 보조 디스크를 마운트합니다.
이 인코딩된 스크립트는 다음 장치 유형에 대한 장치 이름만 지원합니다.
- 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/
)을 설치된 노드의 다른 디스크 또는 파티션으로 이동하지 않습니다.
컨트롤 플레인 머신 세트를 사용할 때 이 절차는 지원되지 않습니다.
프로세스
새 디스크를 클러스터에 연결하고 디버그 쉘에서
lsblk
명령을 실행하여 노드에서 디스크가 감지되었는지 확인합니다.$ oc debug node/<node_name>
# lsblk
lsblk
명령에서 보고한 새 디스크의 장치 이름을 확인합니다.사용자 환경에 따라 스크립트의 장치 이름을 디코딩하고 교체합니다.
#!/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
- 1
- &
lt;device_type_glob
>를 블록 장치 유형의 쉘 글로 바꿉니다. SCSI 또는 SATA 드라이브의 경우/dev/sd*
를 사용합니다. 가상 드라이브의 경우/dev/vd*
를 사용합니다. NVMe 드라이브의 경우/dev/nvme*[0-9]*
를 사용합니다.
다음과 같은 콘텐츠를 사용하여
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.1.0 storage: files: - path: /etc/find-secondary-device mode: 0755 contents: source: data:text/plain;charset=utf-8;base64,<encoded_etc_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
- 1
- 이전에 생성한 인코딩된 문자열을 사용하여 이 문자열을 사용자가 지정한 인코딩된 스크립트로 바꿉니다.
검증 단계
노드의 디버그 쉘에서
grep /var/lib/etcd /proc/mounts
명령을 실행하여 디스크가 마운트되었는지 확인합니다.$ oc debug node/<node_name>
# grep -w "/var/lib/etcd" /proc/mounts
출력 예
/dev/sdb /var/lib/etcd xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
1.3.3. 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는 클러스터 정보를 사용하여 사용자에게 가장 효율적인 작업을 결정하기 때문에 자동 조각 모음은 대부분의 경우에 적합합니다.
1.3.3.1. 자동 조각 모음
etcd Operator는 디스크 조각 모음을 자동으로 수행합니다. 수동 조작이 필요하지 않습니다.
다음 로그 중 하나를 확인하여 조각 모음 프로세스가 성공했는지 확인합니다.
- etcd 로그
- cluster-etcd-operator Pod
- Operator 상태 오류 로그
자동 조각 모음으로 인해 Kubernetes 컨트롤러 관리자와 같은 다양한 OpenShift 핵심 구성 요소에서 리더 선택 실패가 발생하여 실패한 구성 요소를 다시 시작할 수 있습니다. 재시작은 무해하며 다음 실행 중인 인스턴스로 장애 조치를 트리거하거나 다시 시작한 후 구성 요소가 작업을 다시 시작합니다.
성공적으로 조각 모음을 위한 로그 출력 예
etcd member has been defragmented: <member_name>, memberID: <member_id>
실패한 조각 모음에 대한 로그 출력 예
failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
1.3.3.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
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
리더가 최종 조각화 처리를 수행하므로 어떤 etcd 멤버가 리더인지 확인합니다.
etcd pod 목록을 가져옵니다.
$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
출력 예
etcd-ip-10-0-159-225.example.redhat.com 3/3 Running 0 175m 10.0.159.225 ip-10-0-159-225.example.redhat.com <none> <none> etcd-ip-10-0-191-37.example.redhat.com 3/3 Running 0 173m 10.0.191.37 ip-10-0-191-37.example.redhat.com <none> <none> etcd-ip-10-0-199-170.example.redhat.com 3/3 Running 0 176m 10.0.199.170 ip-10-0-199-170.example.redhat.com <none> <none>
Pod를 선택하고 다음 명령을 실행하여 어떤 etcd 멤버가 리더인지 확인합니다.
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
출력 예
Defaulting container name to etcdctl. Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod. +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS | +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | https://10.0.191.37:2379 | 251cd44483d811c3 | 3.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 | | +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
이 출력의
IS
LEADER 열에 따르면https://10.0.199.170:2379
엔드 포인트가 리더입니다. 이전 단계의 출력과 이 앤드 포인트가 일치하면 리더의 Pod 이름은etcd-ip-10-0199-170.example.redhat.com
입니다.
etcd 멤버를 분리합니다.
실행중인 etcd 컨테이너에 연결하고 리더가 아닌 pod 이름을 전달합니다.
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
ETCDCTL_ENDPOINTS
환경 변수를 설정 해제합니다.sh-4.4# unset ETCDCTL_ENDPOINTS
etcd 멤버를 분리합니다.
sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
출력 예
Finished defragmenting etcd member[https://localhost:2379]
시간 초과 오류가 발생하면 명령이 성공할 때까지
--command-timeout
의 값을 늘립니다.데이터베이스 크기가 감소되었는지 확인합니다.
sh-4.4# etcdctl endpoint status -w table --cluster
출력 예
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS | +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | https://10.0.191.37:2379 | 251cd44483d811c3 | 3.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 | | +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
이 예에서는 etcd 멤버의 데이터베이스 크기가 시작 크기인 104MB와 달리 현재 41MB임을 보여줍니다.
다음 단계를 반복하여 다른 etcd 멤버에 연결하고 조각 모음을 수행합니다. 항상 리더의 조각 모음을 마지막으로 수행합니다.
etcd pod가 복구될 수 있도록 조각 모음 작업에서 1분 이상 기다립니다. etcd pod가 복구될 때까지 etcd 멤버는 응답하지 않습니다.
공간 할당량을 초과하여
NOSPACE
경고가 발생하는 경우 이를 지우십시오.NOSPACE
경고가 있는지 확인합니다.sh-4.4# etcdctl alarm list
출력 예
memberID:12345678912345678912 alarm:NOSPACE
경고를 지웁니다.
sh-4.4# etcdctl alarm disarm
1.3.4. etcd의 튜닝 매개변수 설정
컨트롤 플레인 하드웨어 속도를 "Standard"
, "Slower"
또는 기본값인 ""
로 설정할 수 있습니다.
기본 설정을 사용하면 시스템에서 사용할 속도를 결정할 수 있습니다. 이 값을 사용하면 시스템에서 이전 버전에서 값을 선택할 수 있으므로 이 기능이 존재하지 않는 버전에서 업그레이드할 수 있습니다.
다른 값 중 하나를 선택하면 기본값을 덮어씁니다. 시간 초과 또는 누락된 하트비트로 인해 리더 선택이 많이 표시되고 시스템이 ""
또는 "표준"
으로 설정된 경우 하드웨어 속도를 "Slower"
로 설정하여 시스템의 대기 시간을 늘리도록 합니다.
etcd 대기 오차 튜닝은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
1.3.4.1. 하드웨어 속도 내결함성 변경
etcd의 하드웨어 속도 내결함성을 변경하려면 다음 단계를 완료합니다.
사전 요구 사항
- 기술 프리뷰 기능을 활성화하기 위해 클러스터 인스턴스를 편집했습니다. 자세한 내용은 "기능 게이트 이해"를 참조하십시오.
프로세스
다음 명령을 입력하여 현재 값이 무엇인지 확인합니다.
$ oc describe etcd/cluster | grep "Control Plane Hardware Speed"
출력 예
Control Plane Hardware Speed: <VALUE>
참고출력이 비어 있으면 필드가 설정되지 않았으며 기본값으로 간주해야 합니다.
다음 명령을 입력하여 값을 변경합니다. &
lt;value
>를""
,"Standard"
또는"Slower"
: 유효한 값 중 하나로 바꿉니다.$ oc patch etcd/cluster --type=merge -p '{"spec": {"controlPlaneHardwareSpeed": "<value>"}}'
다음 표는 각 프로필에 대한 하트비트 간격 및 리더 선택 시간 초과를 나타냅니다. 이러한 값은 변경될 수 있습니다.
프로필
ETCD_HEARTBEAT_INTERVAL
ETCD_LEADER_ELECTION_TIMEOUT
""
플랫폼에 따라 다릅니다.
플랫폼에 따라 다릅니다.
Standard
100
1000
느림
500
2500
출력을 확인합니다.
출력 예
etcd.operator.openshift.io/cluster patched
유효한 값 이외의 값을 입력하면 오류 출력이 표시됩니다. 예를 들어 값으로
"Faster"
를 입력하면 출력은 다음과 같습니다.출력 예
The Etcd "cluster" is invalid: spec.controlPlaneHardwareSpeed: Unsupported value: "Faster": supported values: "", "Standard", "Slower"
다음 명령을 입력하여 값이 변경되었는지 확인합니다.
$ oc describe etcd/cluster | grep "Control Plane Hardware Speed"
출력 예
Control Plane Hardware Speed: ""
etcd pod가 롤아웃될 때까지 기다립니다.
$ oc get pods -n openshift-etcd -w
다음 출력은 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
다음 명령을 입력하여 값을 검토합니다.
$ oc describe -n openshift-etcd pod/<ETCD_PODNAME> | grep -e HEARTBEAT_INTERVAL -e ELECTION_TIMEOUT
참고이러한 값은 기본값에서 변경되지 않을 수 있습니다.
추가 리소스