알려진 문제

이 문서에서는 VMware용 Anthos 클러스터(GKE On-Prem) 버전 1.9에서 알려진 문제를 설명합니다.

/var/log/audit/로 디스크 공간이 채워짐

식별된 버전

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를 위반하게 됩니다.

Ubuntu 노드에서 재부팅 후 systemd-timesyncd가 실행되지 않음

식별된 버전

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: 다음 Daemonset을 배포하여 systemd-timesyncd가 종료된 경우 항상 다시 시작되도록 합니다.

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 커스텀 리소스

gkectl update는 ClientConfig 커스텀 리소스에서 수행한 변경을 수동으로 되돌립니다. 수동으로 변경한 후 항상 ClientConfig 리소스를 백업하는 것이 좋습니다.

gkectl check-config 검사 실패: F5 BIG-IP 파티션을 찾을 수 없음

증상: F5 BIG-IP 파티션이 존재하더라도 이를 찾을 수 없어서 검사가 실패합니다.
가능한 원인: F5 BIG-IP API 관련 문제로 인해 검사가 실패할 수 있습니다.
해결 방법: gkectl check-config를 다시 실행해 보세요.

PodDisruptionBudget으로 워크로드 중단

클러스터를 업그레이드하면 PodDisruptionBudget(PDB)을 사용하는 워크로드에 중단이나 다운타임이 발생할 수 있습니다.

노드가 업그레이드 절차를 완료하지 못함

추가 중단을 허용할 수 없도록 구성된 PodDisruptionBudget 객체가 있으면 반복된 시도 후 노드 업그레이드가 제어 영역 버전으로 업그레이드되지 않을 수 있습니다. 이러한 실패를 방지하려면 PodDisruptionBudget 구성을 지키면서 노드 드레이닝을 허용하도록 Deployment 또는 HorizontalPodAutoscaler를 확장하는 것이 좋습니다.

중단을 허용하지 않는 모든 PodDisruptionBudget 객체를 보려면 다음 안내를 따르세요.

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Anthos 1.9.0에서 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.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

갱신된 인증서의 유효성을 검사하고 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

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.

원격 호스트에서 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.9.0 또는 1.9.1로 업그레이드하는 경우 `cert-manager`과의 충돌

VMware용 Anthos 클러스터에 자체 cert-manager 설치가 있는 경우 버전 1.9.0 또는 1.9.1로 업그레이드하려고 할 때 오류가 발생할 수 있습니다. cert-manager 네임스페이스에 설치될 수 있는 cert-manager 버전과 monitoring-operator 버전 간의 충돌로 인해 발생합니다.

VMware용 Anthos 클러스터 버전 1.9.0 또는 1.9.1로 업그레이드한 후 cert-manager의 다른 사본을 설치하려고 하면 monitoring-operator에서 관리하는 기존 항목과 충돌하여 설치가 실패할 수 있습니다.

제어 영역 및 관측 가능성 구성요소가 인증서 보안 비밀을 만들고 순환하는 데 사용하는 metrics-ca 클러스터 발급기관을 사용하려면 클러스터 리소스 네임스페이스에 metrics-ca 인증서 보안 비밀이 저장되어야 합니다. 이 네임스페이스는 모니터링 연산자 설치에 대해 kube-system이며 설치에 대해 cert-manager일 수 있습니다.

설치에 실패하면 다음 단계를 수행하여 버전 1.9.0 및 1.9.1로 성공적으로 업그레이드할 수 있습니다.

업그레이드 중에 충돌 방지

보유한 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를 다시 설치합니다. 있으면 맞춤설정된 리소스를 복원합니다.

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

버전 1.9.2 이상으로 업그레이드할 때 `cert-manager`와의 충돌

1.9.2 이상 버전에서 monitoring-operator는 cert-manager 네임스페이스에 cert-manager를 설치합니다. 특정한 이유로 cert-manager를 직접 설치해야 하는 경우 충돌을 피하려면 다음 안내를 따르세요.

업그레이드 중에 충돌 방지

보유한 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 cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

고객의 cert-manager를 다시 설치합니다. 있으면 맞춤설정된 리소스를 복원합니다.

업스트림 기본 cert-manager 설치를 사용하거나 cert-manager가 cert-manager 네임스페이스에 설치되어 있는 경우 이 단계를 건너뛸 수 있습니다. 그렇지 않으면 cert-manager에서 metrics-ca cert-manager.io/v1 인증서 및 metrics-pki.cluster.local 발급기관 리소스를 설치된 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 cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n cert-manager 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 복원

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 cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

고객의 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 cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n cert-manager 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에서 추적됩니다.

Seesaw 또는 수동 모드 부하 분산기를 사용할 때 konnectivity 서버 포드 비정상화

Seesaw 또는 수동 모드 부하 분산기를 사용하는 경우 konnectivity 서버 포드가 비정상 상태일 수 있습니다. 그 이유는 Seesaw가 서비스 간에 IP 주소 재사용을 지원하지 않기 때문입니다. 수동 모드의 경우 부하 분산기 서비스를 만들어도 부하 분산기에 서비스가 자동으로 프로비저닝되지 않습니다.

버전 1.9 클러스터에서는 SSH 터널링이 사용 설정됩니다. 따라서 konnectivity 서버가 정상이 아니더라도 SSH 터널을 사용할 수 있으므로 클러스터에 대한 연결 및 클러스터 내부 연결에는 영향이 없습니다. 그러므로 비정상 포드에 대해 걱정할 필요가 없습니다.

버전 1.9.0에서 1.9.x로 업그레이드하려는 경우 업그레이드 전에 비정상 konnectivity 서버 배포를 삭제하는 것이 좋습니다. 다음 명령어를 실행합니다.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME delete Deployment konnectivity-server

`/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`.

부하 분산기와 NSX-T 스테이트풀(Stateful) 분산형 방화벽 규칙의 예기치 않은 상호작용

VMware용 Anthos 클러스터 버전 1.9 이상을 배포할 때 NSX-T 스테이트풀(Stateful) 분산 방화벽 규칙을 사용하는 환경에 Seesaw 번들 부하 분산기가 있으면 stackdriver-operator이 gke-metrics-agent-conf ConfigMap을 만들지 못하고 gke-connect-agent 포드가 비정상 종료 루프에 빠집니다.

근본적인 문제는 Seesaw가 비대칭 연결 흐름을 사용하기 때문에 스테이트풀(Stateful) NSX-T 분산형 방화벽 규칙에서 Seesaw 부하 분산기를 통한 클라이언트에서 사용자 클러스터 API 서버로의 연결을 종료하는 것입니다. NSX-T 분산형 방화벽 규칙과의 통합 문제는 Seesaw를 사용하는 모든 VMware용 Anthos 클러스터에 영향을 미칩니다. 크기가 32K 이상인 대형 Kubernetes 객체를 만들면 애플리케이션에서 비슷한 연결 문제가 발생할 수 있습니다. NSX-T 분산형 방화벽 규칙을 중지하거나 Seesaw VM에 스테이트리스(Stateless) 분산형 방화벽 규칙을 사용하려면 이 안내를 따르세요.

클러스터에 수동 부하 분산기가 사용되는 경우 이 안내에 따라 백엔드 노드 장애가 감지되었을 때 클라이언트 연결을 재설정하도록 부하 분산기를 구성합니다. 이 구성을 사용하지 않으면 서버 인스턴스가 작동 중지되었을 때 Kubernetes API 서버의 클라이언트가 몇 분 동안 응답하지 않을 수 있습니다.

생성 중 관리자 클러스터 등록 실패

1.9.x 또는 1.10.0 버전의 관리자 클러스터를 만드는 중에 관리자 클러스터를 제공된 gkeConnect 사양으로 등록하지 못하면 다음 오류가 발생합니다.

  Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

이 관리자 클러스터를 계속 사용할 수 있지만 나중에 관리자 클러스터를 버전 1.10.y로 업그레이드하려고 하면 다음 오류가 발생합니다.

  failed to migrate to first admin trust chain: failed to parse current version "":
  invalid version: "" failed to migrate to first admin trust chain: failed to parse
  current version "": invalid version: ""

이 오류가 발생하면 다음 단계에 따라 클러스터 등록 문제를 해결합니다. 이 문제를 해결한 후 관리자 클러스터를 업그레이드할 수 있습니다.

vSphere에 대한 명령줄 인터페이스인 govc를 제공합니다. 일부 변수는 vCenter Server와 vSphere 환경의 요소를 선언합니다.

참고: 관리자 클러스터 구성 파일에서 또는 vCenter Server에 로그인하여 이러한 여러 값을 찾을 수 있습니다.
```
export GOVC_URL=https://VCENTER_SERVER_ADDRESS
export GOVC_USERNAME=VCENTER_SERVER_USERNAME
export GOVC_PASSWORD=VCENTER_SERVER_PASSWORD
export GOVC_DATASTORE=VSPHERE_DATASTORE
export GOVC_DATACENTER=VSPHERE_DATACENTER
export GOVC_INSECURE=true
# DATA_DISK_NAME should not include the suffix ".vmdk"
export DATA_DISK_NAME=DATA_DISK_NAME
```
다음을 바꿉니다.
- VCENTER_SERVER_ADDRESS는 vCenter Server의 IP 주소 또는 호스트 이름입니다.
- VCENTER_SERVER_USERNAME은 vCenter Server의 관리자 역할 또는 동등한 권한을 보유한 계정의 사용자 이름입니다.
- VCENTER_SERVER_PASSWORD는 vCenter Server 계정의 비밀번호입니다.
- VSPHERE_DATASTORE는 vSphere 환경에서 구성한 Datastore의 이름입니다.
- VSPHERE_DATACENTER는 vSphere 환경에서 구성한 데이터 센터의 이름입니다.
- DATA_DISK_NAME은 데이터 디스크 이름입니다.

DATA_DISK_NAME‑checkpoint.yaml 파일을 다운로드합니다.

govc datastore.download ${DATA_DISK_NAME}-checkpoint.yaml temp-checkpoint.yaml

체크포인트 필드를 수정합니다.

# Find out the gkeOnPremVersion
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster -n kube-system $ADMIN_CLUSTER_NAME -o=jsonpath='{.spec.gkeOnPremVersion}')

# Replace the gkeOnPremVersion in temp-checkpoint.yaml
sed -i "s/gkeonpremversion: \"\"/gkeonpremversion: \"$GKE_ON_PREM_VERSION\"/" temp-checkpoint.yaml

#The steps below are only needed for upgrading from 1.9x to 1.10x clusters.

# Find out the provider ID of the admin control-plane VM
ADMIN_CONTROL_PLANE_MACHINE_NAME=$(kubectl get machines --no-headers | grep master)
ADMIN_CONTROL_PLANE_PROVIDER_ID=$(kubectl get machines $ADMIN_CONTROL_PLANE_MACHINE_NAME -o=jsonpath='{.spec.providerID}' | sed 's/\//\\\//g')

# Fill in the providerID field in temp-checkpoint.yaml
sed -i "s/providerid: null/providerid: \"$ADMIN_CONTROL_PLANE_PROVIDER_ID\"/" temp-checkpoint.yaml

ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터 kubeconfig 파일의 경로로 바꿉니다.

새 체크섬을 생성합니다.
- 체크포인트 파일의 마지막 줄을 다음으로 변경합니다.
```
checksum:$NEW_CHECKSUM
```
  NEW_CHECKSUM을 다음 명령어의 출력으로 바꿉니다.
```
sha256sum temp-checkpoint.yaml
```

새 체크포인트 파일을 업로드합니다.

govc datastore.upload temp-checkpoint.yaml ${DATA_DISK_NAME}-checkpoint.yaml

Anthos Identity Service를 사용하면 Connect Agent가 예기치 않게 다시 시작될 수 있음

Anthos Identity Service 기능을 사용하여 Anthos Identity Service ClientConfig를 관리하는 경우 Connect 에이전트가 예기치 않게 다시 시작될 수 있습니다.

기존 클러스터에서 이 문제가 발생한 경우 다음 중 하나를 수행할 수 있습니다.

Anthos Identity Service(AIS)를 사용 중지합니다. AIS를 사용 중지해도 배포된 AIS 바이너리 또는 AIS ClientConfig는 삭제되지 않습니다. AIS를 사용 중지하려면 다음 명령어를 실행합니다.
```
gcloud beta container hub identity-service disable --project PROJECT_NAME
```
PROJECT_NAME을 클러스터의 Fleet 호스트 프로젝트 이름으로 바꿉니다.
Connect Agent 버전을 업그레이드할 수 있도록 클러스터를 버전 1.9.3 또는 1.10.1 이상으로 업데이트합니다.

monitoring.googleapis.com에 대한 높은 네트워크 트래픽

사용자 워크로드가 없는 새 클러스터에서도 monitoring.googleapis.com에 대해 높은 네트워크 트래픽이 확인될 수 있습니다.

이 문제는 버전 1.10.0-1.10.1 및 버전 1.9.0-1.9.4에 영향을 미칩니다. 이 문제는 버전 1.10.2 및 1.9.5에서 해결되었습니다.

이 문제를 해결하려면 버전 1.10.2/1.9.5 이상으로 업그레이드하세요.

이전 버전에서 이 문제를 해결하려면 다음 안내를 따르세요.

stackdriver-operator 축소:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   scale deployment stackdriver-operator --replicas=0

USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다.

수정할 gke-metrics-agent-conf ConfigMap을 엽니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit configmap gke-metrics-agent-conf

프로브 간격을 0.1초에서 13초로 늘립니다.

processors:
  disk_buffer/metrics:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-metrics
    probe_interval: 13s
    retention_size_mib: 6144
 disk_buffer/self:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-self
    probe_interval: 13s
    retention_size_mib: 200
  disk_buffer/uptime:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-uptime
    probe_interval: 13s
    retention_size_mib: 200

수정 세션을 닫습니다.

gke-metrics-agent DaemonSet 버전을 1.1.0-anthos.8로 변경합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

일부 노드에서 측정항목 누락

모든 노드가 아닌 일부 노드에서 다음 측정항목이 누락될 수 있습니다.

kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total

문제 해결 방법

[버전 1.9.5 이상]: 1~4단계를 수행하여 gke-metrics-agent의 CPU를 늘립니다.
[버전 1.9.0~1.9.4]: 1~9단계를 수행합니다.

수정할 stackdriver 리소스를 엽니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

gke-metrics-agent의 CPU 요청을 10m에서 50m로 늘리려면 다음 resourceAttrOverride 섹션을 stackdriver 매니페스트에 추가합니다.

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

수정된 리소스는 다음과 비슷하게 표시되어야 합니다.

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

변경사항을 저장하고 텍스트 편집기를 닫습니다.
변경사항이 적용되었는지 확인하려면 다음 명령어를 실행합니다.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
수정이 적용된 경우 명령어가 cpu: 50m을 찾습니다.

다음 변경 사항을 되돌리지 않으려면 stackdriver-operator를 축소합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system scale deploy stackdriver-operator --replicas=0

수정할 gke-metrics-agent-conf를 엽니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit configmap gke-metrics-agent-conf

probe_interval: 0.1s의 모든 인스턴스를 probe_interval: 13s로 변경하도록 구성을 수정합니다.

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

변경사항을 저장하고 텍스트 편집기를 닫습니다.

gke-metrics-agent DaemonSet 버전을 1.1.0-anthos.8로 변경합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

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 패브릭의 여러 위치 간에 플랩됩니다.

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

알려진 문제

/var/log/audit/로 디스크 공간이 채워짐

카테고리

식별된 버전

증상

원인

해결 방법

관리 워크스테이션

클러스터 노드

Ubuntu 노드에서 재부팅 후 systemd-timesyncd가 실행되지 않음

카테고리

식별된 버전

증상

원인

해결 방법

ClientConfig 커스텀 리소스

gkectl check-config 검사 실패: F5 BIG-IP 파티션을 찾을 수 없음

PodDisruptionBudget으로 워크로드 중단

노드가 업그레이드 절차를 완료하지 못함

Anthos 1.9.0에서 cert-manager/ca-injector의 리더 선택 문제로 인해 사용자 클러스터 설치에 실패함

관리자 클러스터를 업그레이드하기 전에 인증서 갱신이 필요할 수 있음

관리자 클러스터 인증서 갱신 프로세스

7.0U2 미만 버전으로 vCenter 다시 시작 또는 업그레이드

원격 호스트에서 SSH 연결 종료

버전 1.9.0 또는 1.9.1로 업그레이드하는 경우 cert-manager과의 충돌

업그레이드 중에 충돌 방지

사용자 클러스터에서 고유한 cert-manager 복원

관리자 클러스터에서 고유한 cert-manager 복원

버전 1.9.2 이상으로 업그레이드할 때 cert-manager와의 충돌

업그레이드 중에 충돌 방지

사용자 클러스터에서 고유한 cert-manager 복원

관리자 클러스터에서 고유한 cert-manager 복원

docker, containerd, runc 취약점 스캔의 거짓양성

Seesaw 또는 수동 모드 부하 분산기를 사용할 때 konnectivity 서버 포드 비정상화

/etc/cron.daily/aide CPU 및 메모리 급증 문제

부하 분산기와 NSX-T 스테이트풀(Stateful) 분산형 방화벽 규칙의 예기치 않은 상호작용

생성 중 관리자 클러스터 등록 실패

Anthos Identity Service를 사용하면 Connect Agent가 예기치 않게 다시 시작될 수 있음

monitoring.googleapis.com에 대한 높은 네트워크 트래픽

일부 노드에서 측정항목 누락

Cisco ACI가 직접 서버 반환(DSR)에서 작동하지 않음

gkectl 진단 인증서 확인 실패

버전 1.9.0 또는 1.9.1로 업그레이드하는 경우 `cert-manager`과의 충돌

버전 1.9.2 이상으로 업그레이드할 때 `cert-manager`와의 충돌

`/etc/cron.daily/aide` CPU 및 메모리 급증 문제