이 문서에서는 VMware용 Anthos 클러스터(GKE On-Prem) 버전 1.8에서 알려진 문제를 설명합니다.
/var/log/audit/로 디스크 공간이 채워짐
카테고리
OS
식별된 버전
1.8.0+, 1.9.0+, 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+
증상
/var/log/audit/
에 감사 로그가 채워집니다. sudo du -h -d 1 /var/log/audit
를 실행하면 디스크 사용량을 확인할 수 있습니다.
원인
Anthos v1.8부터 Ubuntu 이미지는 CIS Level2 벤치마크로 강화됩니다. 그리고 규정 준수 규칙 중 하나인 4.1.2.2 Ensure audit logs are not automatically deleted
는 auditd 설정이 max_log_file_action = keep_logs
가 되도록 보장하므로 모든 감사 규칙이 디스크에 유지됩니다.
해결 방법
관리 워크스테이션
관리자 워크스테이션의 경우 로그를 자동으로 순환하도록 수동으로 auditd 설정을 변경한 후 auditd 서비스를 다시 시작할 수 있습니다.
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd
위 설정을 사용하면 생성된 파일이 250개를 초과하면(각각 8M 크기) auditd 로그가 자동으로 순환됩니다.
클러스터 노드
클러스터 노드의 경우 잠재적인 문제를 방지하기 위해 다음 DaemonSet을 클러스터에 적용합니다.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-auditd-log-action
namespace: kube-system
spec:
selector:
matchLabels:
app: change-auditd-log-action
template:
metadata:
labels:
app: change-auditd-log-action
spec:
hostIPC: true
hostPID: true
containers:
- name: update-audit-rule
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
echo "updating auditd max_log_file_action to rotate with a max of 250 files"
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
echo "restarting auditd"
systemctl restart auditd
else
echo "auditd setting is expected, skip update"
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
이 auditd 구성을 변경하면 CIS Level2 규칙 4.1.2.2 Ensure audit logs are not automatically deleted
를 위반하게 됩니다.
'사용자 클러스터 등록 실패'로 인해 사용자 클러스터 업그레이드/업데이트 실패
카테고리
업그레이드, 업데이트
식별된 버전
1.7.0+, 1.8.0+
증상
다음과 같은 경우 이전 gkectl
명령어가 시간 초과되면 gkectl diagnose cluster
를 실행합니다.
- GKE Connect가 사용 설정된 사용자 클러스터를 1.8 버전으로 업그레이드
- GKE Connect가 사용 설정된 1.8 사용자 클러스터에서
gkectl update cluster
실행 gkectl update cluster
를 실행하여 1.8 사용자 클러스터에서 GKE Connect를 사용 설정
$ gkectl diagnose cluster --kubeconfig kubeconfig --cluster-name foo-cluster
…
Unhealthy Resources:
OnPremUserCluster foo-cluster: not ready: ready condition is not true: ClusterCreateOrUpdate: failed to register user cluster "foo-cluster": failed to register cluster: ...
...
GKE Connect의 기능은 영향을 받지 않습니다. 즉, 이 명령어를 사용하기 전에 GKE Connect가 작동했다면 계속 작동합니다.
원인
1.8 버전에 사용된 Connect 에이전트 버전 20210514-00-00
은 지원되지 않습니다.
해결 방법
문제를 완화하려면 Google 지원팀에 문의하세요.
Ubuntu 노드에서 재부팅 후 systemd-timesyncd가 실행되지 않음
카테고리
OS
식별된 버전
1.7.1-1.7.5, 1.8.0-1.8.4, 1.9.0+
증상
systemctl status systemd-timesyncd
에서 서비스 종료를 보여줍니다.
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)
이로 인해 시간 미동기화 문제가 발생할 수 있습니다.
원인
chrony
가 Ubuntu OS 이미지에 잘못 설치되었으며, chrony
와 systemd-timesyncd
간에 충돌이 발생하여 systemd-timesyncd
는 비활성 상태가 되고 chrony
는 Ubuntu VM이 재부팅할 때마다 매번 활성화됩니다. 그러나 systemd-timesyncd
는 VM의 기본 ntp 클라이언트여야 합니다.
해결 방법
옵션 1: VM이 재부팅될 때마다 restart systemd-timesyncd
를 수동으로 실행합니다.
옵션 2: systemd-timesyncd
가 종료되면 항상 다시 시작되도록 다음 Daemonset을 배포합니다.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ensure-systemd-timesyncd
spec:
selector:
matchLabels:
name: ensure-systemd-timesyncd
template:
metadata:
labels:
name: ensure-systemd-timesyncd
spec:
hostIPC: true
hostPID: true
containers:
- name: ensure-systemd-timesyncd
# Use your preferred image.
image: ubuntu
command:
- /bin/bash
- -c
- |
while true; do
echo $(date -u)
echo "Checking systemd-timesyncd status..."
chroot /host systemctl status systemd-timesyncd
if (( $? != 0 )) ; then
echo "Restarting systemd-timesyncd..."
chroot /host systemctl start systemd-timesyncd
else
echo "systemd-timesyncd is running."
fi;
sleep 60
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "10m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
````
## ClientConfig custom resource
`gkectl update` reverts any manual changes that you have made to the ClientConfig
custom resource. We strongly recommend that you back up the ClientConfig
resource after every manual change.
## gkectl check-config</code> validation fails: can't find F5 BIG-IP partitions
<dl>
<dt>Symptoms</dt>
<dd><p>Validation fails because F5 BIG-IP partitions can't be found, even though they exist.</p></dd>
<dt>Potential causes</dt>
<dd><p>An issue with the F5 BIG-IP API can cause validation to fail.</p></dd>
<dt>Resolution</dt>
<dd><p>Try running <code>gkectl check-config</code> again.</p></dd>
</dl>
## Disruption for workloads with PodDisruptionBudgets {:#workloads_pdbs_disruption}
Upgrading clusters can cause disruption or downtime for workloads that use
[PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/){:.external}
(PDBs).
## Nodes fail to complete their upgrade process
If you have `PodDisruptionBudget` objects configured that are unable to
allow any additional disruptions, node upgrades might fail to upgrade to the
control plane version after repeated attempts. To prevent this failure, we
recommend that you scale up the `Deployment` or `HorizontalPodAutoscaler` to
allow the node to drain while still respecting the `PodDisruptionBudget`
configuration.
To see all `PodDisruptionBudget` objects that do not allow any disruptions:
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}' ```
Anthos 1.8.2 및 1.8.3에서 cert-manager/ca-injector의 리더 선택 문제로 인해 사용자 클러스터 설치 실패
apiserver/etcd가 느릴 때 crashloop의 cert-manager-cainjector
로 인해 설치 장애가 발생할 수 있습니다. 다음 명령어를 실행하면
kubectl logs --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployments/cert-manager-cainjector
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core: Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
문제를 해결하려면 다음 명령어를 실행합니다.
변경사항을 cert-manager-cainjector
배포로 되돌리지 않도록 먼저 monitoring-operator
를 축소합니다.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0
다음으로 cert-manager-cainjector
배포를 패치하여 리더 선택을 중지합니다. 복제본이 한 개만 실행되므로 안전합니다. 단일 복제본에는 필요하지 않습니다.
# Ensure that we run only 1 cainjector replica, even during rolling updates. kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=strategic --patch ' spec: strategy: rollingUpdate: maxSurge: 0 ' # Add a command line flag for cainjector: `--leader-elect=false` kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=json --patch '[ { "op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--leader-elect=false" } ]'
설치가 완료될 때까지 문제 해결을 위해 monitoring-operator
복제본을 0으로 유지합니다. 그렇지 않으면 변경사항이 되돌려집니다.
설치가 완료되고 클러스터가 작동하면 2일차 작업을 위해 monitoring-operator
를 설정합니다.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=1
1.8.4 이상(또는 1.9로 업그레이드하는 경우 1.9.1 이상)으로 업그레이드한 후에는 Anthos에서 cainjector의 리더 선택을 중지하므로 이러한 단계가 더 이상 필요하지 않습니다. 그때까지는 각 업그레이드 중에 이 문제가 발생하면 같은 완화 단계를 다시 수행해야 합니다.
관리자 클러스터를 업그레이드하기 전에 인증서 갱신이 필요할 수 있음
관리자 클러스터 업그레이드 절차를 시작하기 전에 관리자 클러스터 인증서가 현재 유효한지 확인하고 유효하지 않은 경우 갱신해야 합니다.
관리자 클러스터 인증서 갱신 프로세스
시작하기 전에 관리자 워크스테이션에 OpenSSL이 설치되어 있어야 합니다.
KUBECONFIG
변수를 설정합니다.KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터 kubeconfig 파일의 절대 경로로 바꿉니다.
관리자 마스터 노드의 IP 주소와 SSH 키를 가져옵니다.
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')
인증서가 만료되었는지 확인합니다.
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"
인증서가 만료된 경우 관리자 클러스터를 업그레이드하기 전에 갱신해야 합니다.
관리자 클러스터 kubeconfig 파일도 관리자 인증서가 만료되면 만료되므로 만료 전에 이 파일을 백업해야 합니다.
관리자 클러스터 kubeconfig 파일을 백업합니다.
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"kubeconfig의
client-certificate-data
및client-key-data
를 생성된new_admin.conf
파일의client-certificate-data
및client-key-data
로 바꿉니다.
이전 인증서를 백업합니다.
이 단계는 선택사항이지만 권장됩니다.
# ssh into admin master if you didn't in the previous step ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
kubeadm으로 인증서를 갱신합니다.
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all
관리자 마스터 노드에서 실행 중인 정적 포드를 다시 시작합니다.
# on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout
관리자 클러스터 워커 노드의 인증서 갱신
노드 인증서 만료일 확인
kubectl get nodes -o wide # find the oldest node, fill NODE_IP with the internal ip of that node ssh -i ~/.ssh/admin-cluster.key ubuntu@"${NODE_IP}" openssl x509 -enddate -noout -in /var/lib/kubelet/pki/kubelet-client-current.pem logout
인증서가 곧 만료되는 경우 수동 노드 복구로 노드 인증서를 갱신하세요.
갱신된 인증서의 유효성을 검사하고 kube-apiserver의 인증서를 검증해야 합니다.
인증서 만료를 확인합니다.
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"kube-apiserver의 인증서를 확인합니다.
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
/etc/cron.daily/aide 스크립트가 /run의 모든 공간을 소비하여 포드에 비정상 종료 루프가 발생함
VMware용 Anthos 클러스터 1.7.2부터 시작하여 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화됩니다.
.
그 결과 CIS L1 서버 규칙 "1.4.2 파일 시스템 무결성에 대한 정기 검사 확인"을 따르기 위해 aide 검사가 예약되도록 크론 스크립트 /etc/cron.daily/aide
가 설치되었습니다.
이 스크립트는 /run/aide
를 임시 디렉터리로 사용하여 크론 로그를 저장하고 시간 경과에 따라 /run
의 모든 공간을 소비할 수 있습니다. 해결 방법은 /etc/cron.daily/aide 스크립트가 /run의 모든 공간 소비를 참조하세요.
노드에서 하나 이상의 포드 비정상 종료 루프가 발견될 경우 노드에서 df -h /run
을 실행합니다. 명령어 결과에 100% 공간 사용이 표시되면 이 문제가 발생할 가능성이 높습니다.
이 문제는 버전 1.8.1에서 해결되었습니다. 1.7.2 및 1.8.0 버전의 경우 다음 두 가지 해결 방법 중 하나로 이 문제를 수동으로 해결할 수 있습니다.
/run/aide/cron.daily.old*
에서 주기적으로 로그 파일을 삭제합니다(권장).- /etc/cron.daily/aide 스크립트가 /run의 모든 공간 소비에 나온 단계를 따릅니다. 참고: 이 해결방법은 노드 규정 준수 상태에 영향을 줄 수 있습니다.
버전 1.8.0을 사용한 Seesaw 부하 분산기 업그레이드
버전 1.8.0에서 gkectl upgrade loadbalancer
를 사용하여 Seesaw 부하 분산기의 일부 매개변수를 업데이트하려고 하면 DHCP 또는 IPAM 모드에서 작동하지 않습니다. 설정에 이러한 구성이 포함된 경우 버전 1.8.0으로 업그레이드하지 말고 버전 1.8.1 이상으로 업그레이드하세요.
비밀번호 만료 문제로 인해 관리 워크스테이션에 로그인할 수 없음
다음 버전의 VMware용 Anthos 클러스터를 사용하는 경우 이 문제가 발생할 수 있습니다.
- 1.7.2-gke.2
- 1.7.3-gke.2
- 1.8.0-gke.21
- 1.8.0-gke.24
- 1.8.0-gke.25
- 1.8.1-gke.7
- 1.8.2-gke.8
관리 워크스테이션, 클러스터 노드, Seesaw 노드를 포함하여 Anthos VM에 SSH 연결을 시도할 때 다음 오류가 발생할 수 있습니다.
WARNING: Your password has expired.
이 오류는 VM의 ubuntu 사용자 비밀번호가 만료되었기 때문에 발생합니다. VM에 로그인하기 전에 수동으로 사용자 비밀번호의 만료 시간을 큰 값으로 재설정해야 합니다.
비밀번호 만료 오류 방지
위에 나열된 영향을 받는 버전을 실행 중이며 사용자 비밀번호가 아직 만료되지 않은 경우 SSH 오류를 확인하기 전에 만료 시간을 연장해야 합니다.
각 Anthos VM에서 다음 명령어를 실행합니다.
sudo chage -M 99999 ubuntu
비밀번호 만료 오류 완화
사용자 비밀번호가 이미 만료되어 VM에 로그인하여 만료 시간을 연장할 수 없는 경우 각 구성요소에 대해 다음 완화 단계를 수행하세요.
관리 워크스테이션
임시 VM을 사용하여 다음 단계를 수행합니다. 임시 VM으로 사용할 1.7.1-gke.4 버전을 사용하여 관리 워크스테이션을 만들 수 있습니다.
임시 VM과 관리 워크스테이션의 전원이 꺼져 있는지 확인합니다.
관리 워크스테이션의 부팅 디스크를 임시 VM에 연결합니다. 부팅 디스크는 '하드 디스크 1' 라벨이 있는 디스크입니다.
다음 명령어를 실행하여 VM 내에 부팅 디스크를 마운트합니다.
dev/sdc1
을 자체 부팅 디스크 식별자로 바꿉니다.sudo mkdir -p /mnt/boot-disk sudo mount /dev/sdc1 /mnt/boot-disk
ubuntu 사용자 만료일을
99999
일과 같이 큰 값으로 설정합니다.sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
임시 VM을 종료합니다.
관리자 워크스테이션의 전원을 켭니다. 이제 평소와 같이 SSH를 사용할 수 있습니다.
정리를 위해 임시 VM을 삭제합니다.
관리자 클러스터 제어 영역 VM
안내에 따라 관리자 클러스터 제어 영역 VM을 다시 만듭니다.
관리자 클러스터 부가기능 VM
관리자 워크스테이션에서 다음 명령어를 실행하여 VM을 다시 만듭니다.
kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
이 명령어를 실행한 후 관리자 클러스터 부가기능 VM이 재생성을 완료하고 준비될 때까지 기다린 후 다음 단계를 계속 진행합니다.
사용자 클러스터 제어 영역 VM
관리자 워크스테이션에서 다음 명령어를 실행하여 VM을 다시 만듭니다.
usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
이 명령어를 실행한 후 사용자 클러스터 제어 영역 VM이 재생성을 완료하고 준비될 때까지 기다린 후 다음 단계를 계속 진행합니다.
사용자 클러스터 작업자 VM
관리자 워크스테이션에서 다음 명령어를 실행하여 VM을 다시 만듭니다.
for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done
Seesaw VM
관리자 워크스테이션에서 다음 명령어를 실행하여 Seesaw VM을 다시 만듭니다. 이때 다운타임이 발생합니다. 부하 분산기에 HA가 사용 설정된 경우 최대 다운타임은 2초입니다.
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff
7.0U2 미만 버전으로 vCenter 다시 시작 또는 업그레이드
업그레이드 후 7.0U2 미만 버전의 vCenter가 다시 시작되면 vCenter의 VM 정보에 있는 네트워크 이름이 올바르지 않으며 머신이 Unavailable
상태가 됩니다. 그러면 결국 노드가 자동 복구되어 새로운 노드가 생성됩니다.
관련 govmomi 버그: https://github.com/vmware/govmomi/issues/2552
이 해결 방법은 VMware 지원팀에서 제공합니다.
1. The issue is fixed in vCenter versions 7.0U2 and above. 2. For lower versions: Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the VM's portgroup.
gkectl create-config admin
및 gkectl create-config cluster
패닉
버전 1.8.0~1.8.3에서 gkectl create-config admin/cluster
명령어에 패닉이 발생하며 panic: invalid version: "latest"
메시지가 표시됩니다.
이 문제를 해결하려면 gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION
을 사용합니다. DESIRED_CLUSTER_VERSION
을 원하는 버전으로 바꿉니다(예: 1.8.2-gke.8).
관리자 클러스터 생성/업그레이드 시간 초과
이 문제는 버전 1.8.0~1.8.3에 영향을 미칩니다.
관리자 클러스터 생성 또는 관리자 클러스터 업그레이드가 다음 오류와 함께 타임아웃될 수 있습니다.
Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory
또한 외부 클러스터 스냅샷에 있는 nodes/ADMIN_MASTER_NODE/files/var/log/startup.log
의 로그가 다음 메시지로 끝납니다.
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
이 오류는 관리자 제어 영역 VM과 Container Registry 간에 네트워크가 느릴 때 발생합니다. 네트워크 또는 프록시 설정을 검사하여 지연 시간을 줄이고 대역폭을 늘려야 합니다.
원격 호스트에서 SSH 연결 종료
VMware용 Anthos 클러스터 버전 1.7.2 이상의 경우 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화됩니다.
CIS 규칙 '5.2.16 SSH 유휴 제한 시간 간격이 구성되었는지 확인'을 충족하도록 /etc/ssh/sshd_config
가 다음과 같이 설정됩니다.
ClientAliveInterval 300 ClientAliveCountMax 0
이 설정의 목적은 유휴 시간 5분이 지난 후 클라이언트 세션을 종료하는 것입니다. 하지만 ClientAliveCountMax 0
값은 예기치 않은 동작을 가져옵니다. 관리자 워크스테이션 또는 클러스터 노드에서 SSH 세션을 사용하면 SSH 클라이언트가 유휴 상태가 아니더라도 SSH 연결이 끊길 수 있습니다. 예를 들어 시간이 오래 걸리는 명령어를 실행하면 다음 메시지와 함께 명령어가 종료될 수 있습니다.
Connection to [IP] closed by remote host. Connection to [IP] closed.
이 문제를 해결하려면 다음 중 하나를 수행하세요.
SSH 연결이 끊길 때 명령어가 종료되지 않도록
nohup
를 사용합니다.nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig
0이 아닌
ClientAliveCountMax
값을 사용하도록sshd_config
를 업데이트합니다. CIS 규칙은 3보다 작은 값을 사용하는 것이 좋습니다.sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config sudo systemctl restart sshd
SSH 세션을 다시 연결해야 합니다.
버전 1.8.2 이상으로 업그레이드할 때 cert-manager
와 충돌
VMware용 Anthos 클러스터에 자체 cert-manager
설치가 있는 경우 버전 1.8.2 이상으로 업그레이드하려고 할 때 오류가 발생할 수 있습니다. cert-manager
네임스페이스에 설치될 수 있는 cert-manager
버전과 monitoring-operator
버전 간의 충돌로 인해 발생합니다.
VMware용 Anthos 클러스터 버전 1.8.2 이상으로 업그레이드한 후 cert-manager
의 다른 사본을 설치하려고 하면 monitoring-operator
에서 관리하는 기존 항목과 충돌하여 설치가 실패할 수 있습니다.
제어 영역 및 관측 가능성 구성요소가 인증서 보안 비밀을 만들고 순환하는 데 사용하는 metrics-ca
클러스터 발급기관을 사용하려면 클러스터 리소스 네임스페이스에 metrics-ca
인증서 보안 비밀이 저장되어야 합니다. 이 네임스페이스는 모니터링 연산자 설치에 대해 kube-system
이며 설치에 대해 cert-manager
일 수 있습니다.
설치가 실패한 경우 다음 단계를 수행하면 버전 1.8.2 이상으로 성공적으로 업그레이드할 수 있습니다.
업그레이드 중에 충돌 방지
보유한
cert-manager
버전을 제거합니다. 자체 리소스를 정의한 경우 백업할 수 있습니다.업그레이드를 수행합니다.
다음 안내에 따라 자체
cert-manager
를 복원하세요.
사용자 클러스터에서 고유한 cert-manager 복원
monitoring-operator
배포를 0으로 확장합니다.kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0
monitoring-operator
에서 관리하는cert-manager
배포를 0으로 확장합니다.kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
고객의
cert-manager
를 다시 설치합니다. 있으면 맞춤설정된 리소스를 복원합니다.metrics-ca
cert-manager.io/v1 인증서 및metrics-pki.cluster.local
발급기관 리소스를kube-system
에서 설치된 cert-manager의 클러스터 리소스 네임스페이스에 복사합니다. 업스트림 기본 cert-manager 설치를 사용하는 경우 설치된 cert-manager 네임스페이스는cert-manager
이지만 설치에 따라 달라집니다.relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f1=$(mktemp) f2=$(mktemp) kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f2 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
관리자 클러스터에서 고유한 cert-manager 복원
일반적으로 관리자 클러스터는 VMware용 Anthos 클러스터 제어 영역 워크로드만 실행하므로 관리자 클러스터에 cert-manager를 다시 설치할 필요가 없습니다. 드물지만 관리자 클러스터에 자체 cert-manager를 설치해야 하는 경우에도 다음 안내를 따라 충돌을 방지하세요. Apigee 고객이고 Apigee에 대한 cert-manager만 필요한 경우 관리자 클러스터 명령어를 실행할 필요가 없습니다.
monitoring-operator
배포를 0으로 확장합니다.kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0
monitoring-operator
에서 관리하는cert-manager
배포를 0으로 확장합니다.kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
고객의
cert-manager
를 다시 설치합니다. 있으면 맞춤설정된 리소스를 복원합니다.metrics-ca
cert-manager.io/v1 인증서 및metrics-pki.cluster.local
발급기관 리소스를kube-system
에서 설치된 cert-manager의 클러스터 리소스 네임스페이스에 복사합니다. 업스트림 기본 cert-manager 설치를 사용하는 경우 설치된 cert-manager 네임스페이스는cert-manager
이지만 설치에 따라 달라집니다.relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f3=$(mktemp) f4=$(mktemp) kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f4 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
docker, containerd, runc 취약점 스캔의 거짓양성
VMware용 Anthos 클러스터와 함께 제공되는 Ubuntu OS 이미지의 docker, containerd, runc는 Ubuntu PPA를 사용하는 특수 버전으로 고정됩니다. 이렇게 하면 VMware용 Anthos 클러스터가 모든 컨테이너 런타임 변경사항을 출시 전에 검증합니다.
하지만 다양한 CVE 스캔 도구에서 취약점 피드로 사용하는 Ubuntu CVE Tracker에 대한 특수 버전은 알려지지 않았습니다. 따라서 docker, containerd, runc 취약점 스캔 결과에 거짓양성이 표시됩니다.
예를 들어 CVE 스캔 결과에 다음과 같은 거짓양성이 표시될 수 있습니다. VMware용 Anthos 클러스터의 최신 패치 버전에서는 이러한 CVE가 이미 수정되었습니다.
CVE 수정 사항은 출시 노트를 참조하세요.
Canonical에서는 이 문제를 인식하고 있으며 수정 사항은 https://github.com/canonical/sec-cvescan/issues/73에서 추적됩니다.
/etc/cron.daily/aide
CPU 및 메모리 급증 문제
VMware용 Anthos 클러스터 1.7.2부터 Ubuntu OS 이미지가 CIS L1 서버 벤치마크로 강화되었습니다.
따라서 CIS L1 서버 규칙인 '1.4.2 파일 시스템 무결성을 정기적으로 검증'을 준수하기 위해 aide
검사를 예약하는 /etc/cron.daily/aide
크론 스크립트가 설치되었습니다.
크론 작업은 매일 오전 6시 25분(UTC)에 실행됩니다. 파일 시스템의 파일 수에 따라 이 aide
프로세스로 인해 해당 시간에 CPU 및 메모리 사용량이 급증할 수 있습니다.
급증이 워크로드에 영향을 주는 경우 일일 크론 작업을 사용 중지할 수 있습니다.
`sudo chmod -x /etc/cron.daily/aide`.
Cisco ACI가 직접 서버 반환(DSR)에서 작동하지 않음
Seesaw는 DSR 모드에서 실행되며 기본적으로 데이터 영역 IP 학습 때문에 Cisco ACI에서 작동하지 않습니다. 가능한 해결 방법은 Cisco Application Policy Infrastructure Controller(APIC)에서 Seesaw IP 주소를 L4-L7 가상 IP로 추가하여 IP 학습을 사용 중지하는 것입니다.
테넌트 > 애플리케이션 프로필 > 애플리케이션 EPG 또는 uSeg EPG로 이동하여 L4-L7 가상 IP 옵션을 구성할 수 있습니다. IP 학습을 사용 중지하지 못하면 IP 엔드포인트가 Cisco API 패브릭의 여러 위치 간에 플랩됩니다.
서비스 계정 Bearer 토큰이 너무 길면 Seesaw 부하 분산기 로그가 손상될 수 있음
logging-monitoring 서비스 계정 Bearer 토큰이 512KB보다 크면 Seesaw 부하 분산기 로그가 손상될 수 있습니다. 이 문제를 해결하려면 버전 1.9 이상으로 업그레이드하세요.
anetd
데몬의 소프트웨어 교착 상태로 인한 포드 간 연결 문제
enableDataplaneV2
가 true
로 설정된 클러스터에서는 anetd
데몬(데몬 세트로 실행)이 소프트웨어 교착 상태로 진입하여 포드 간 연결 문제가 발생할 수 있습니다. 이 상태에서 anetd
데몬은 비활성 노드(이전에 삭제된 노드)를 피어로 인식하고 새로 추가된 노드는 새 피어로 인식하지 못합니다.
이 문제가 발생하는 경우 다음 단계에 따라 anetd
데몬을 다시 시작하여 피어 노드를 새로고침하면 연결이 복원됩니다.
클러스터의 모든
anetd
데몬을 찾습니다.kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd
anetd
데몬에 현재 비활성 피어가 표시되는지 확인합니다.kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status
ANETD_XYZ를
anetd
포드의 이름으로 바꿉니다.영향을 받는 모든 포드를 다시 시작합니다.
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ
gkectl 진단 인증서 확인 실패
워크스테이션이 사용자 클러스터 워커 노드에 액세스할 수 없으면 gkectl diagnose
를 실행할 때 다음 오류가 발생합니다. 이 오류를 무시해도 안전합니다.
Checking user cluster certificates...FAILURE
Reason: 3 user cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out