고객사에서 OpenStack 13 to 16 버전으로 마이그레이션 하면서 발생한 이슈 사항에 대해 정리했다.
1. OpenShift 이슈 상황
1.1. 호스트명 변경 사항
OpenStack 13 to 16 버전 마이그레이션시 master01 노드의 호스트명이 아래와 같이 변경 되었다.
master01.example.com -> master01-example-com
해당 이슈는 OpenStack에서 VM에 설정된 FQDN 형식의 호스트명은 “-“로 변경[1],[2] 되도록 설정 되었기 때문에 발생했다.
이 부분은 OpenStack 지원팀에서 가이드한 내용으로 cloud-init 단에서 아래와 같은 명령어를 통해 파일을 생성하는 방식으로 처리하였다.
node ~# touch /etc/cloud/cloud-init.disabled
[1]: Rebooting an openstack instance causes the hostname to change
[2]: OpenStack – Configurable Instance Hostnames
1.2. Master 노드 중복
master01 노드의 호스트명이 변경된 이후 절체 테스트를 통해 재부팅 했다.
노드가 기동이 된 이후 Pending 된 노드의 CSR(Certificate Signing Requests) 인증서를 승인 하였고,
변경된 호스트명으로 master 노드가 추가 된 상황이다.
master01-example-com NotReady master 10m v1.11.0+d4cacc0
master01.example.com NotReady master 2y v1.11.0+d4cacc0
master02.example.com Ready master 2y v1.11.0+d4cacc0
master03.example.com Ready master 2y v1.11.0+d4cacc0
CSR 인증서가 Pending이 되는 이유는 클러스터의 노드로 추가된 시점부터 1년 만료 인증서가 생성되며,
최소 만료 2달전에 CSR 인증서를 Master에게 요청하여 승인(Approved)이 되기를 기다린다.
이런 과정은 애초에 보안상의 이유로 재갱신을 반드시 하도록 설계되었기 때문이다.
1.3. Master 노드 절체시 서비스 장애
Kubernetes는 노드가 죽어도 서비스가 될수 있도록 장애 허용(fault tolerance)으로 설계 되었다.
장애를 허용하기 때문에, Controle Plane(Master Nodes)에 대한 장애는 기본적으로 무시할 수 있다.
즉, 아래와 같은 시나리오에서 가능하다.
– Master 3대 모두 장애 발생시
Ingress Pod 및 Worker 노드에 Application Pod가 구동되고 있는 상황에서 Master 3대 모두 장애가 발생한 상황.
Application을 새로 빌드하거나 배포 하지 않는 경우 외부 진입점은 Ingress를 통해 Pod 단으로 통신 되므로 서비스 영향도 없음. 단, Ingress 노드 또는 Worker 노드의 다중화가 무너지는 경우 서비스 영향도는 있음.
– Master 1대만 장애날 경우
Master 노드에는 ETCD라는 Key/Value 기반의 데이터 베이스가 제공된다.
ETCD에는 API 및 kubernetes에서 사용하는 object 들에 대한 정보가 모두 저장된다.
이런 데이터를 안전하게 저장하기 위해서 ETCD 서버에 대해 클러스터를 구성하여 정족수(Quorum)을 구성한다.
이런 구성에서 최소한의 데이터를 일관성 있게 저장하기 위한 사항으로 ETCD 서버는 2대 이상에서만 동작하도록 되어있다.
Master 노드 1대만 장애가 발생한 상황이면 데이터를 안전하게 저장할 수 있게 되어, 서비스 영향도가 없다고 보면 된다.
정족수 미만으로 떨어지게 되는 경우 Master 3대 장애 상황과 같다고 보면 된다.
따라서, 2022.03.28에 진행시 master01 노드만 종료 했을 뿐인데 서비스에 영향도가 있었던 상황은
Master용 L4가 없기 때문에 VIP를 사용할 수 없어서 발생한 상황이다.
즉, “1.1. 호스트명 변경 사항”, “1.2. Master 노드 중복” 상황에서 OpenShift 노드에 VIP를 사용하지 않고,
Master01 노드로만 API 서버를 사용했기 때문에 장애가 발생한 상황이다.
1.4. Web Console 접속 불가
OpenShift v3.x 버전에서는 Web Console이 Master API 서버와 같이 사용된다.
접속 불가 현상이 발생한 상황은 “1.2. Master 노드 중복” 상황에서 중복된 Master01 노드의 정보가
ETCD에 Merge 되었기 때문에 해당 노드에서는 master01-example-com 이라는 질의가 되지 않는
도메인으로 연결을 시도하고 있기 때문에, API 및 ETCD 서비스를 구동 할 수 없어 발생한 상황이다.
2. 해결 방안
2.1. 스냅샷 복구
작업 전 OpenStack 단에서 스냅샷 백업 본을 통해 복구가 가능한 상황이었으면 쉽게 해결된다.
다만, 백업 본이 없었기 때문에 불가능 했다.
2.2. Master 노드 재구성
중복 추가 된 Master01 노드를 삭제하고 재구성하는 방법이다.
히스토리 관리가 되어있지 않는 클러스터였기 때문에, 여러가지 이슈가 많이 발생하여 3번과 같은 과정으로 해결했다.
3. 작업 사항
모든 작업은 Bastion에서 진행했으며, 문제 되는 노드(master01)에서 파일 복사/수정/삭제를 진행했다.
3.1. 노드 제거
기존 노드와 중복 추가 된 Master01 노드를 제거했다.
bation ~# oc delete node master01-example-com
bation ~# oc delete node master01.example.com
3.2. 서비스 데몬 중지
master01 ~# systemctl stop atomic-openshift-node docker
3.3. 불필요 컨테이너 정리
master01 ~# systemctl start docker
master01 ~# docker system prune -a -f
3.4. 패키지 및 파일 제거
master01 ~# yum -y remove openshift openshift-* etcd
master01 ~# rm -rf /etc/origin /etc/openshift /var/lib/openshift \
/etc/etcd /var/lib/etcd /etc/sysconfig/openshift* /root/.kube/config \
/etc/ansible/facts.d /usr/share/openshift
3.5. master01 설정
3.5.1. /etc/resolv.conf 파일 복사
OpenShift v3.4 버전부터 존재하였던 버그이며, 초기 Ansible을 통해 배포 이후
노드 추가시 /etc/resolv.conf 파일을 /etc/origin/node/resolv.conf 경로에 파일을 복사 하지 못하는 버그다.
그래서, 강제로 디렉토리를 생성 후 파일을 복사한다.
master01 ~# mkdir -p /etc/origin/node
master01 ~# cp /etc/resolv.conf /etc/origin/node/resolv.conf
3.5.2. ETCD 암호화 설정
ETCD 정보에 대한 암호화[3]를 설정하였던 사항이다.
이 파일이 존재하지 않으면, 정상적으로 노드를 구성할 수가 없었다.
master01 ~# cat << EOF > /etc/origin/master/encryption-config.yaml
kind: EncryptionConfig
apiVersion: v1
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: encryption-aescbc01
secret: yUKN0BbXbDuL/AVSAGASGUOcFzPioI+QjRBspr0=
- name: encryption-aescbc02
secret: bDidC9fhs1ASDASDASDaH+AeLuC8VGNOs6EuEfaIKSQ+Dmk=
- name: encryption-aescbc03
secret: NKfcnGDGDGDGDGDGAV7eb++xa6Og4JNDuS0OuA=
- name: encryption-aescbc04
secret: r9s/io/7qUYWc3dp3SFSPJGJFDGJDFDSHDSGMD9eQvjw=
- name: encryption-aescbc05
secret: ghSAFSAFGASGASGSAG4M2r1gSRHSDFJHDFAF8=
EOF
[3]: Encrypting Data at Datastore Layer
3.5.3. Master02, 03 노드 설정
ansible inventory에 추가된 [master] 섹션에 master 노드가 등록되면, 배열 기준으로 첫번째 master 노드가 Primary 노드가 된다.
기존에 등록된 master01 노드를 삭제 후 재구성시, master02번 노드가 배열의 첫번째 노드가 된다.
Primary 노드가 아닌 master 노드들은 /etc/yum.conf 파일에 exclude 변수에 atomic-openshift와 관련된 RPM 패키지가 설치가 되지 않도록 설정 된다.
아래 3.5.5 번의 과정을 통해 master01 노드가 추가 되면 아래와 같은 메세지와 함께 배포가 실패 된다.
TASK [openshift_ca : Install the base package for admin tooling] ****************************************************************************************************************************************************************************
FAILED - RETRYING: Install the base package for admin tooling (3 retries left).
FAILED - RETRYING: Install the base package for admin tooling (2 retries left).
FAILED - RETRYING: Install the base package for admin tooling (1 retries left).
fatal: [master01.example.com -> master02.example.com]: FAILED! => {"attempts": 3, "changed": false, "msg": "No package matching 'atomic-openshift-3.11*' found available, installed or updated", "rc": 126, "results": ["No package matching 'atomic-openshift-3.11*' found available, installed or updated"]}
따라서, 위의 내용은 Primary로 선택된 master02 노드에 해당 패키지가 제외 되었으므로, 패키지를 설치할 수 없어서 발생하는 이슈다.
아래와 같은 방법으로 해결한다.
master02 ~# vi /etc/yum.conf
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
#exclude= atomic-openshift-tests atomic-openshift-hyperkube atomic-openshift-recycle atomic-openshift-pod atomic-openshift-node atomic-openshift-master atomic-openshift-clients-redistributable atomic-openshift-clients atomic-openshift docker*1.20* docker*1.19* docker*1.18* docker*1.17* docker*1.16* docker*1.15* docker*1.14*
exclude= docker*1.20* docker*1.19* docker*1.18* docker*1.17* docker*1.16* docker*1.15* docker*1.14*
이후 master02 노드에서 수작업으로 atomic-openshift 패키지를 설치하거나 3.5.5 번의 과정을 재진행 한다.
3.5.4. Master 인증서 재갱신
기존 Master01 노드가 사용하고 있던 사설 인증서가 master02, master03 노드에 모두 배포가 되어 있는 상황이다. 노드를 삭제하고 재배포가 진행되면, 시작 날짜를 기준으로 새로운 인증서가 생성되는데, 이때 기존에 가지고 있던, 인증서들을 교체하는 작업이 필요하다.
이 작업은 RootCA 인증서를 재갱신하는 것이 아닌 master용 ca, crt, key 인증서를 위한 작업이다.
기존 Ansible Inventory 파일을 백업 후 진행 했다.
master01 ~# cp /etc/ansible/hosts /etc/ansible/hosts_back-rp-2022-03-28
Inventory에 master01 노드 정보를 주석처리 했다.
bastion ~# vi /etc/ansible/hosts
[OSEv3:children]
masters
nodes
etcd
#nfs
new_nodes
new_masters
new_etcd
[masters]
#master01.example.com
master02.example.com
master03.example.com
[etcd]
#master01.example.com
master02.example.com
master03.example.com
[nodes]
#master01.example.com openshift_node_group_name="master" openshift_schedulable=true
master02.example.com openshift_node_group_name="master" openshift_schedulable=true
master03.example.com openshift_node_group_name="master" openshift_schedulable=true
#[nfs]
#bastion01.example.com
이후 Master용 사설 인증서를 재배포 한다.
인증서가 재갱신 되면 master02, 03 노드에서 API, ETCD, Controller Static Pod가 재기동 된다.
bastion ~# ansible-playbook -i /etc/ansible/hosts \
/usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-certificates.yml
3.5.5. Master01 노드 추가
Inventory에 master01 노드를 [new_nodes], [new_master], [new_etcd] 섹션에 추가한다.
단, 기존 노드 정보에서는 주석처리 필요.
master01 ~# vi /etc/ansible/hosts
[OSEv3:children]
masters
nodes
etcd
#nfs
new_nodes
new_masters
new_etcd
[masters]
#master01.example.com
master02.example.com
master03.example.com
[etcd]
#master01.example.com
master02.example.com
master03.example.com
[nodes]
#master01.example.com openshift_node_group_name="master" openshift_schedulable=true
master02.example.com openshift_node_group_name="master" openshift_schedulable=true
master03.example.com openshift_node_group_name="master" openshift_schedulable=true
#[nfs]
#bastion01.example.com
[new_nodes]
master01.example.com openshift_node_group_name="master" openshift_schedulable=true
[new_masters]
master01.example.com
[new_etcd]
master01.example.com
이후 Master 노드를 배포한다.
bastion ~# ansible-playbook -i /etc/ansible/hosts \
/usr/share/ansible/openshift-ansible/playbooks/openshift-master/scaleup.yml
3.5.6. ETCD CA & Client 인증서 재배포
“3.5.4. Master 인증서 재갱신” 내용과 마찬가지로 기존의 master01에서 사용하던
etcd의 ca 인증서를 재배포 해야 etcd pod에서 “tls: bad certificate” 에러가 발생하지 않는다.
아래와 같은 방법으로 CA 인증서를 재배포 한다.
bastion ~# ansible-playbook -i /etc/ansible/hosts \
/usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-ca.yml
이후 새로 배포한 etcd ca 인증서 기반으로 server, peer, client용 인증서를 재갱신 한다.
bastion ~# ansible-playbook -i /etc/ansible/hosts \
/usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/certificates.yml
[4]: Etcd scaleup fails when first master/etcd node in ansible inventory fails
3.5.7. ETCD Static Pod 설정
Master01 노드에서만 진행하며, 기존 master02번의 파일을 기준으로 master01 기준에 맞게 수정한다.
– /etc/etcd/etcd.conf 파일 생성
master01 ~# vi /etc/etcd/etcd.conf
ETCD_NAME=master01.example.com
ETCD_LISTEN_PEER_URLS=https://xxx.xxx.xxx.162:2380
ETCD_DATA_DIR=/var/lib/etcd/
#ETCD_WAL_DIR=
#ETCD_SNAPSHOT_COUNT=10000
ETCD_HEARTBEAT_INTERVAL=500
ETCD_ELECTION_TIMEOUT=2500
ETCD_LISTEN_CLIENT_URLS=https://xxx.xxx.xxx.162:2379
#ETCD_MAX_SNAPSHOTS=5
#ETCD_MAX_WALS=5
#ETCD_CORS=
#[cluster]
ETCD_INITIAL_ADVERTISE_PEER_URLS=https://xxx.xxx.xxx.162:2380
ETCD_INITIAL_CLUSTER=master01.example.com=https://xxx.xxx.xxx.162:2380,master02.example.com=https://xxx.xxx.xxx.178:2380,master03.example.com=https://xxx.xxx.xxx.179:2380
ETCD_INITIAL_CLUSTER_STATE=new
ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster-1
#ETCD_DISCOVERY=
#ETCD_DISCOVERY_SRV=
#ETCD_DISCOVERY_FALLBACK=proxy
#ETCD_DISCOVERY_PROXY=
ETCD_ADVERTISE_CLIENT_URLS=https://xxx.xxx.xxx.162:2379
#ETCD_STRICT_RECONFIG_CHECK=false
#ETCD_AUTO_COMPACTION_RETENTION=0
#ETCD_ENABLE_V2=true
ETCD_QUOTA_BACKEND_BYTES=4294967296
#[proxy]
#ETCD_PROXY=off
#ETCD_PROXY_FAILURE_WAIT=5000
#ETCD_PROXY_REFRESH_INTERVAL=30000
#ETCD_PROXY_DIAL_TIMEOUT=1000
#ETCD_PROXY_WRITE_TIMEOUT=5000
#ETCD_PROXY_READ_TIMEOUT=0
#[security]
ETCD_TRUSTED_CA_FILE=/etc/etcd/ca.crt
ETCD_CLIENT_CERT_AUTH=true
ETCD_CERT_FILE=/etc/etcd/server.crt
ETCD_KEY_FILE=/etc/etcd/server.key
#ETCD_AUTO_TLS=false
ETCD_PEER_TRUSTED_CA_FILE=/etc/etcd/ca.crt
ETCD_PEER_CLIENT_CERT_AUTH=true
ETCD_PEER_CERT_FILE=/etc/etcd/peer.crt
ETCD_PEER_KEY_FILE=/etc/etcd/peer.key
#ETCD_PEER_AUTO_TLS=false
#[logging]
ETCD_DEBUG=False
#[profiling]
#ETCD_ENABLE_PPROF=false
#ETCD_METRICS=basic
#
#[auth]
#ETCD_AUTH_TOKEN=simple
– Static Pod 생성
master01 ~# vi /etc/origin/node/pods/etcd.yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ''
labels:
openshift.io/component: etcd
openshift.io/control-plane: 'true'
name: master-etcd
namespace: kube-system
spec:
containers:
- args:
- '#!/bin/sh
set -o allexport
source /etc/etcd/etcd.conf
exec etcd
'
command:
- /bin/sh
- -c
image: docker-registry.example.com/rhel7/etcd:3.2.22
livenessProbe:
exec:
command:
- etcdctl
- --cert-file
- /etc/etcd/peer.crt
- --key-file
- /etc/etcd/peer.key
- --ca-file
- /etc/etcd/ca.crt
- --endpoints
- https://xxx.xxx.xxx.162:2379
- cluster-health
initialDelaySeconds: 45
name: etcd
securityContext:
privileged: true
volumeMounts:
- mountPath: /etc/etcd/
name: master-config
readOnly: true
- mountPath: /var/lib/etcd/
name: master-data
workingDir: /var/lib/etcd
hostNetwork: true
priorityClassName: system-node-critical
restartPolicy: Always
volumes:
- hostPath:
path: /etc/etcd/
name: master-config
- hostPath:
path: /var/lib/etcd
name: master-data
– ETCD 클러스터 상태 확인
master01 ~# ETCDCTL_API=3 etcdctl \
--cert="/etc/etcd/peer.crt" --key=/etc/etcd/peer.key --cacert="/etc/etcd/ca.crt" \
--endpoints="https://master01.example.com:2379,https://master02.example.com:2379,https://master03.example.com:2379" endpoint health
– ETCD 클러스터 상태 출력 결과 (정상)
https://master01.example.com:2379 is healthy: successfully committed proposal: took = 1.616867ms
https://master03.example.com:2379 is healthy: successfully committed proposal: took = 884.217µs
https://master02.example.com:2379 is healthy: successfully committed proposal: took = 1.472011ms
3.5.8. CSR 자동 갱신 설정
“1.2. Master 노드 중복”에 설명한 Pending 상태인 CSR을 자동 갱신 해주도록 설정이 가능하다.
아래와 같이 Ansible Inventory 파일에 해당 변수를 설정 후 배포한다.
bastion ~# vi /etc/ansible/hosts
[OSEv3:vars]
openshift_master_bootstrap_auto_approve=true
bootstrap autoapprover pod 배포
bastion ~# ansible-playbook -i /etc/ansible/hosts \
/usr/share/ansible/openshift-ansible/ansible/playbooks/openshift-master/enable_bootstrap.yml
– Pod 확인
bation ~# oc get pod -n openshift-infra
NAME READY STATUS RESTARTS AGE
bootstrap-autoapprover-0 1/1 Running 0 2h
4. 그외 이슈
4.1. OpenShift Metrics Server 인증서 만료
Hawkular Metrics의 대체 Pod로 사용중인 Metrics Server Pod의 인증서가 만료되어 있었다.
bastion ~# oc logs --tail=3 metrics-server-5dc754944c-xx8ds -n openshift-metrics-server
I0328 13:22:59.297860 1 logs.go:41] http: TLS handshake error from xxx.xxx.xxx.1:36276: remote error: tls: bad certificate
I0328 13:22:59.303583 1 logs.go:41] http: TLS handshake error from xxx.xxx.xxx.1:36278: remote error: tls: bad certificate
I0328 13:22:59.312762 1 logs.go:41] http: TLS handshake error from xxx.xxx.xxx.1:36282: remote error: tls: bad certificate
bastion ~# oc get secret metrics-server-certs -n openshift-metrics-server -o jsonpath={.data."tls\.crt"} | base64 -d | openssl x509 -text | grep -A2 Validity
Validity
Not Before: Apr 10 05:41:13 2019 GMT
Not After : Apr 9 05:41:14 2021 GMT
Metrics 인증서가 만료되면 노드 배포 과정 중에 아래와 같은 TASK에서 호출을 할 수가 없어 배포에 실패한다.
TASK [openshift_control_plane : Wait for /apis/metrics.k8s.io/v1beta1 when registered] ******************************************************************************************************************************************************
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (30 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (29 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (28 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (27 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (26 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (25 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (24 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (23 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (22 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (21 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (20 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (19 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (18 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (17 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (16 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (15 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (14 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (13 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (12 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (11 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (10 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (9 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (8 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (7 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (6 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (5 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (4 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (3 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (2 retries left).
FAILED - RETRYING: Wait for /apis/metrics.k8s.io/v1beta1 when registered (1 retries left).
fatal: [master01.example.com]: FAILED! => {"attempts": 30, "changed": true, "cmd": ["oc", "--config=/etc/origin/master/admin.kubeconfig", "get", "--raw", "/apis/metrics.k8s.io/v1beta1"], "delta": "0:00:00.132312", "end": "2022-03-28 22:08:15.429156", "msg": "non-zero return code", "rc": 1, "start": "2022-03-28 22:08:15.296844", "stderr": "Error from server (ServiceUnavailable): the server is currently unable to handle the request", "stderr_lines": ["Error from server (ServiceUnavailable): the server is currently unable to handle the request"], "stdout": "", "stdout_lines": []}
이를 해결하는 방법은 Metrics Server를 제거 후 재구성하여 인증서를 새롭게 재갱신하는 방법으로 가능하다.
bastion ~# oc delete secret metrics-server-certs -n openshift-metrics-server
bastion ~# ansible-playbook -i /etc/ansible/hosts \
/usr/share/ansible/openshift-ansible/playbooks/metrics-server/config.yml -e openshift_metrics_server_install=true
– Metrics Server Pod 인증서 확인
bastion ~# oc get secret metrics-server-certs -n openshift-metrics-server -o jsonpath={.data."tls\.crt"} | base64 -d | openssl x509 -text | grep -A2 Validity
Validity
Not Before: Mar 28 13:29:26 2022 GMT
Not After : Mar 27 13:29:27 2024 GMT
위 과정을 진행 후 “3.5.5. Master01 노드 추가” 과정을 재진행하면 된다.
끝.