다음 섹션에서는 GKE On-Prem을 사용할 때 발생 가능한 문제와 이를 해결하는 방법을 설명합니다.
시작하기 전에
문제 해결을 시작하기 전에 다음 섹션을 확인하세요.
gkectl
을 사용하여 클러스터 문제 진단
gkectl diagnose
명령어를 사용하여 클러스터 문제를 식별하고 클러스터 정보를 Google과 공유하세요. 클러스터 문제 진단을 참조하세요.
gkectl
명령어를 상세하게 실행
-v5
gkectl
오류를 stderr
에 로깅
--alsologtostderr
관리자 워크스테이션에서 gkectl
로그 찾기
디버깅 플래그를 전달하지 않더라도 다음 관리자 워크스테이션 디렉터리에서 gkectl
로그를 볼 수 있습니다.
/home/ubuntu/.config/gke-on-prem/logs
관리자 클러스터에서 Cluster API 로그 찾기
관리자 제어 영역이 시작된 후에 VM을 시작하지 못하는 경우 다음 안내에 따라 관리자 클러스터에서 Cluster API 컨트롤러의 로그를 검사하여 디버깅할 수 있습니다.
kube-system
네임스페이스에서 Cluster API 컨트롤러 포드의 이름을 찾습니다. 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로입니다.kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
포드의 로그를 엽니다. 여기서 [POD_NAME]은 포드 이름입니다. 원하는 경우
grep
또는 유사한 도구를 사용하여 오류를 검색할 수 있습니다.kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
설치
관리자 클러스터 제어 영역 노드의 kubeconfig를 사용하여 F5 BIG-IP 문제 디버깅
설치 후 GKE On-Prem은 이름이 internal-cluster-kubeconfig-debug
인 관리자 워크스테이션의 홈 디렉터리에 kubeconfig 파일을 생성합니다. 이 kubeconfig 파일은 관리자 클러스터의 kubeconfig와 동일하지만 관리 제어 영역이 실행되는 관리자 클러스터의 제어 영역 노드를 직접 가리킨다는 것만 다릅니다. internal-cluster-kubeconfig-debug
파일을 사용하여 F5 BIG-IP 문제를 디버깅할 수 있습니다.
gkectl check-config
검사 실패: F5 BIG-IP 파티션을 찾을 수 없음
- 증상
F5 BIG-IP 파티션이 존재하더라도 이를 찾을 수 없어서 검사가 실패합니다.
- 가능한 원인
F5 BIG-IP API 관련 문제로 인해 검사가 실패할 수 있습니다.
- 해결 방법
gkectl check-config
를 다시 실행해 보세요.
gkectl prepare --validate-attestations
실패: 빌드 증명을 검사할 수 없음
- 증상
선택사항인
--validate-attestations
플래그로gkectl prepare
를 실행하면 다음 오류가 반환됩니다.could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
- 가능한 원인
해당 이미지에 대한 증명이 존재하지 않을 수 있습니다.
- 해결 방법
관리자 워크스테이션 만들기 안내를 따라 관리자 워크스테이션 OVA를 다시 다운로드하고 배포하세요. 문제가 계속되면 Google에 도움을 요청하세요.
부트스트랩 클러스터 로그를 사용하여 디버깅
설치 중 GKE On-Prem은 임시 부트스트랩 클러스터를 만듭니다. 설치가 성공한 후에는 GKE On-Prem이 부트스트랩 클러스터를 삭제하고 관리자 및 사용자 클러스터를 남겨둡니다. 일반적으로 이 클러스터와 상호작용할 이유가 없습니다.
설치 중 문제가 발생하고 --cleanup-external-cluster=false
를 gkectl create cluster
에 전달한 경우 부트스트랩 클러스터의 로그를 사용하여 디버깅하는 것이 유용할 수 있습니다. 포드를 찾은 후 해당 로그를 가져올 수 있습니다.
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]
Anthos용 인증 플러그인
gkectl create-login-config
실행 실패
문제 1:
- 증상
gkectl create-login-config
를 실행할 때 다음 오류가 발생합니다.Error getting clientconfig using [user_cluster_kubeconfig]
- 가능한 원인
이 오류는
gkectl create-login-config
에 전달된 kubeconfig 파일이 사용자 클러스터 파일이 아니거나 클러스터를 만드는 동안 ClientConfig CRD가 발생하지 않았음을 의미합니다.- 해결 방법
다음 명령어를 실행하여 ClientConfig CRD가 클러스터에 있는지 확인합니다.
$ kubectl --kubeconfig [user_cluster_kubeconfig] get clientconfig default -n kube-public
문제 2:
- 증상
gkectl create-login-config
를 실행할 때 다음 오류가 발생합니다.error merging with file [merge_file] because [merge_file] contains a cluster with the same name as the one read from [kubeconfig]. Please write to a new output file
- 가능한 원인
각 로그인 구성 파일에는 고유한 클러스터 이름이 포함되어야 합니다. 이 오류가 표시되면 로그인 구성 데이터를 쓰는 파일에 대상 파일에 이미 존재하는 클러스터 이름이 포함된 것입니다.
- 해결 방법
새
--output
파일에 씁니다. 다음에 유의하세요.--output
이 제공되지 않으면 기본적으로 로그인 구성 데이터가 현재 디렉터리의kubectl-anthos-config.yaml
파일에 기록됩니다.--output
이 이미 있으면 이 명령어는 새 로그인 구성을--output
에 병합하려고 시도합니다.
gcloud anthos auth
login
실행 실패
문제 1:
- 증상
인증 플러그인 및 생성된 로그인 구성 YAML 파일을 사용하여
login
을 실행할 수 없습니다.- 가능한 원인
OIDC 구성 세부정보에 오류가 있을 수 있습니다.
- 해결 방법
관리자에게 OIDC 클라이언트 등록을 확인합니다.
문제 2:
- 증상
프록시가 HTTPS 트래픽에 대해 구성된 경우 오류 메시지에
proxyconnect tcp
가 표시되면서gcloud anthos auth login
명령어 실행이 실패합니다.proxyconnect tcp: tls: first record does not look like a TLS handshake
와 같은 유형의 메시지가 표시될 수 있습니다.- 가능한 원인
https_proxy
또는HTTPS_PROXY
환경 변수 구성에 오류가 있을 수 있습니다. 환경 변수에https://
가 지정된 경우 프록시가 SOCK5와 같은 기타 프로토콜을 사용하여 HTTPS 연결을 처리하도록 구성되어 있으면 GoLang HTTP 클라이언트 라이브러리가 실패할 수 있습니다.- 해결 방법
https_proxy
및HTTPS_PROXY
환경 변수를 수정하여https://
프리픽스를 생략합니다. Windows에서는 시스템 환경 변수를 수정합니다. 예를 들어https_proxy
환경 변수의 값을https://webproxy.example.com:8000
에서webproxy.example.com:8000
로 변경합니다.
gcloud anthos auth login
으로 생성된 kubeconfig를 사용하여 클러스터에 액세스할 수 없음
- 증상
'승인되지 않음' 오류
gcloud anthos auth login
으로 생성된 kubeconfig를 사용하여 클러스터에 액세스할 때 `승인되지 않음` 오류가 발생하면 apiserver에서 사용자를 승인할 수 없다는 의미입니다.- 가능한 원인
- 적절한 RBAC가 없거나 잘못되었거나 클러스터의 OIDC 구성에 오류가 있습니다.
- 해결 방법
- 문제를 해결하려면 다음 단계를 따르세요.
kubeconfig에서
id-token
을 파싱합니다.login 명령어로 생성된 kubeconfig 파일에서
id-token
을 복사합니다.kind: Config … users: - name: … user: auth-provider: config: id-token: [id-token] …
다음 단계에 따라 jwt-cli를 설치하고 다음을 실행합니다.
$ jwt [id-token]
OIDC 구성을 확인합니다.
클러스터를 만드는 데 사용된
config.yaml
에서 작성된oidc
섹션에는group
및username
필드가 포함되어 있으며, 이러한 필드는 apiserver에서--oidc-group-claim
및--oidc-username-claim
플래그를 설정하는 데 사용됩니다. apiserver가 토큰과 함께 제시되면 해당 그룹 클레임 및 사용자 이름 클레임을 찾아 해당 그룹 또는 사용자에게 올바른 권한이 있는지 확인합니다.config.yaml
의oidc
섹션에서group
및user
에 설정된 클레임이id-token
에 있는지 확인합니다.적용된 RBAC를 확인합니다.
사용자 이름 클레임으로 지정된 사용자 또는 이전 단계의 그룹 클레임에 있는 그룹 중 하나에 대해 올바른 권한을 가진 RBAC가 있는지 확인합니다. RBAC 내 사용자 또는 그룹 이름 앞에는
config.yaml
의oidc
섹션에 제공된usernameprefix
또는groupprefix
를 붙여야 합니다.usernameprefix
가 비어 있고username
이email
이외의 값인 경우 프리픽스의 기본값은issuerurl#
입니다. 사용자 이름 프리픽스를 사용 중지하려면usernameprefix
를-
로 설정해야 합니다.사용자 및 그룹 프리픽스에 대한 자세한 내용은 oidc 사양 채우기를 참조하세요.
Kubernetes API 서버는 현재 백슬래시를 이스케이프 문자로 취급합니다. 따라서 사용자 또는 그룹 이름에
\\
가 포함되어 있으면id_token
을 파싱할 때 API 서버가 이를 단일\
로 읽습니다. 따라서 이 사용자 또는 그룹에 적용된 RBAC는 백슬래시를 하나만 포함해야 하며 그렇지 않으면Unauthorized
오류가 표시될 수 있습니다.예:
config.yaml:
oidc: issuerurl: … username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:" ...
id_token:
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\\cluster-developer", "group": [ "Domain Users", "EXAMPLE\\developers" ], ... }
다음 RBAC는 이 사용자에게 클러스터 관리자 권한을 부여합니다. 이때 이름 필드에 이중 슬래시 대신 단일 슬래시를 사용한다는 것에 유의하세요.
Group RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
User RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
API 서버 로그를 확인합니다.
kube apiserver에 구성된 OIDC 플러그인이 올바르게 시작되지 않으면
id-token
이 표시될 때 API 서버에서 '승인되지 않음' 오류를 반환합니다. API 서버의 OIDC 플러그인에 문제가 있는지 확인하려면 다음을 실행하세요.$ kubectl --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n [user_cluster_name]
- 증상
서버에 연결할 수 없음: {DISCOVERY_ENDPOINT} x509 가져오기: 알 수 없는 기관에서 서명한 인증서
- 가능한 원인
kubeconfig의 갱신 토큰이 만료되었습니다.
- 해결 방법
login
명령어를 다시 실행합니다
Google Cloud 콘솔 로그인
다음은 Google Cloud console을 사용하여 로그인을 시도하는 동안 발생할 수 있는 일반적인 오류입니다.
'URL을 찾을 수 없음' 오류가 발생한 페이지로 로그인 리디렉션
- 증상
Google Cloud console에서 GKE On-Prem ID 공급업체에 연결할 수 없습니다.
- 가능한 원인
Google Cloud Console에서 GKE On-Prem ID 공급업체에 연결할 수 없습니다.
- 해결 방법
문제를 해결하려면 다음 단계를 따르세요.
-
useHTTPProxy
을true
로 설정공개 인터넷을 통해 IDP에 연결할 수 없는 경우 OIDC HTTP 프록시가 Google Cloud console을 통해 로그인할 수 있도록 설정해야 합니다.
config.yaml
의oidc
섹션에서usehttpproxy
를true
로 설정해야 합니다. 이미 클러스터를 만들었고 프록시를 사용 설정하려는 경우 ClientConfig CRD를 직접 수정할 수 있습니다.$ kubectl edit clientconfig default -n kube-public
을 실행하고useHTTPProxy
를true
로 변경합니다. useHTTPProxy
가 이미true
로 설정되어 있음HTTP 프록시가 사용 설정된 상태에서도 이 오류가 계속 발생하면 프록시 시작에 문제가 있을 수 있습니다. 프록시 로그를 가져오려면
$ kubectl logs deployment/clientconfig-operator -n kube-system
을 실행합니다. IDP에 잘 알려진 CA가 있더라도 http 프록시가 시작하려면config.yaml
의oidc
섹션에capath
필드를 제공해야 합니다.IDP에서 동의 요청
승인 서버에서 동의를 요청하고 추가 매개변수
prompt=consent
를 포함하고 있지 않은 경우 이 오류가 표시될 수 있습니다.$ kubectl edit clientconfig default -n kube-public
을 실행하고extraparams
에prompt=consent
를 추가하고 다시 로그인을 시도합니다.RBAC가 잘못 구성됨
아직 인증하지 않았다면 Anthos용 인증 플러그인을 사용하여 인증을 시도합니다. 플러그인으로 로그인하는 중에도 승인 오류가 표시되면 문제 해결 단계에 따라 플러그인 문제를 해결한 다음 Google Cloud Console을 통해 다시 로그인을 시도합니다.
로그아웃했다가 다시 로그인
경우에 따라 스토리지 서비스에서 일부 설정이 변경되는 경우 명시적으로 로그아웃해야 할 수 있습니다. 클러스터 세부정보 페이지로 이동하고 로그아웃을 클릭한 다음 다시 로그인을 시도합니다.
관리자 워크스테이션
OVA 다운로드 중
AccessDeniedException
- 증상
관리자 워크스테이션 OVA와 서명을 다운로드하려고 하면 다음 오류가 반환됩니다.
AccessDeniedException: 403 whitelisted-service-account@project.iam.gserviceaccount.com does not have storage.objects.list access to gke-on-prem-release
- 가능한 원인
허용 목록에 포함된 서비스 계정이 활성화되지 않았습니다.
- 해결 방법
허용 목록에 포함된 서비스 계정이 활성화되었는지 확인합니다. 문제가 계속되면 Google에 도움을 요청하세요.
openssl
이 관리자 워크스테이션 OVA를 검사할 수 없음- 증상
관리자 워크스테이션 OVA 파일에
openssl dgst
를 실행하면Verified OK
가 반환되지 않습니다.- 가능한 원인
OVA 파일에 검사 성공을 방해하는 문제가 있습니다.
- 해결 방법
관리자 워크스테이션 OVA 다운로드의 설명대로 관리자 워크스테이션 OVA를 다시 다운로드하고 배포하세요. 문제가 계속되면 Google에 도움을 요청하세요.
연결
사용자 클러스터를 등록할 수 없음
사용자 클러스터를 등록하는 데 문제가 발생하면 Google에 도움을 요청하세요.
알파 버전에서 생성된 클러스터가 등록 취소됨
연결 문서의 사용자 클러스터 등록을 참조하세요.
또한 클러스터를 삭제하고 다시 만들기를 선택할 수 있습니다.
스토리지
볼륨이 연결되지 않음
증상
gkectl diagnose cluster
의 결과는 다음과 같습니다.Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status 1 storage errors
하나 이상의 포드가
ContainerCreating
상태로 멈춰 있고 다음과 같은 경고가 표시됩니다.Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 6s (x6 over 31s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.
가능한 원인
가상 디스크가 잘못된 가상 머신에 연결되어 있으면 Kubernetes 1.12의 문제 #32727이 원인일 수 있습니다.
해결 방법
가상 디스크가 잘못된 가상 머신에 연결되어 있으면 이를 수동으로 분리해야 할 수 있습니다.
- 노드를 드레이닝합니다.
안전한 노드 드레이닝을 참조하세요.
kubectl drain
명령어에--ignore-daemonsets
및--delete-local-data
플래그를 포함할 수 있습니다. - VM을 끕니다.
- vCenter에서 VM 하드웨어 구성을 수정하여 볼륨을 삭제합니다.
- VM을 켭니다.
- 노드를 차단 해제합니다.
볼륨이 사라짐
증상
gkectl diagnose cluster
의 결과는 다음과 같습니다.Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found 1 storage errors
하나 이상의 포드가
ContainerCreating
상태로 멈춰 있고 다음과 같은 경고가 표시됩니다.Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 71s (x28 over 42m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/ kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found
가능한 원인
VMDK 파일과 관련해서 '찾을 수 없음' 오류가 표시되면 가상 디스크가 영구적으로 삭제되었기 때문일 수 있습니다. 이 문제는 작업자가 가상 디스크 또는 가상 디스크가 연결된 가상 머신을 수동으로 삭제한 경우에 발생할 수 있습니다. 이를 방지하려면 사용자 클러스터 크기 조절과 클러스터 업그레이드의 설명대로 가상 머신을 관리하세요.
해결 방법
가상 디스크가 영구적으로 삭제된 경우 관련 Kubernetes 리소스를 수동으로 삭제해야 할 수 있습니다.
kubectl delete pvc [PVC_NAME].
을 실행하여 PV를 참조한 PVC를 삭제합니다.kubectl delete pod [POD_NAME].
을 실행하여 PVC를 참조한 포드를 삭제합니다.- 2단계를 반복합니다. (자세한 내용은 Kubernetes 문제 74374를 참조하세요.)
업그레이드
업그레이드 중 다운타임 정보
리소스 설명 관리자 클러스터 관리자 클러스터가 다운되면 다운타임을 유발한 오류의 영향을 받지 않는 한 사용자 클러스터 제어 영역과 워크로드는 사용자 클러스터에서 계속 실행됩니다.
사용자 클러스터 제어 영역 일반적으로 사용자 클러스터 제어 영역에는 뚜렷한 다운타임이 없어야 합니다. 하지만 Kubernetes API 서버로의 장기 실행 연결이 끊어져 다시 설정해야 할 수 있습니다. 이 경우 API 호출자는 연결을 설정할 때까지 다시 시도해야 합니다. 최악의 경우에는 업그레이드 중에 다운타임이 최대 1분간 발생할 수 있습니다.
사용자 클러스터 노드 업그레이드 시 사용자 클러스터 노드를 변경해야 하는 경우 GKE On-Prem은 노드를 롤링 방식으로 다시 만들고 이 노드에서 실행 중인 포드를 다시 예약합니다. 적절한 PodDisruptionBudget과 안티어피니티 규칙을 설정하여 워크로드에 대한 영향을 방지할 수 있습니다.
사용자 클러스터 크기 조절
사용자 클러스터 크기 조절 실패
- 증상
사용자 클러스터의 크기 조절 작업이 실패합니다.
- 가능한 원인
여러 요인으로 인해 크기 조절 작업이 실패할 수 있습니다.
- 해결 방법
크기 조절에 실패하는 경우 다음 단계를 따르세요.
클러스터의 MachineDeployment 상태를 살펴보고 이벤트 또는 오류 메시지가 있는지 확인합니다.
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
새로 생성된 머신에 오류가 있는지 확인합니다.
kubectl describe machine [MACHINE_NAME]
오류: '할당할 수 있는 주소가 없음'
- 증상
사용자 클러스터의 크기를 조절하면
kubectl describe machine [MACHINE_NAME]
에 다음 오류가 표시됩니다.Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
- 가능한 원인
사용자 클러스터에 사용할 수 있는 IP 주소가 충분하지 않습니다.
- 해결 방법
클러스터에 더 많은 IP 주소를 할당합니다. 그런 다음 영향을 받은 머신을 삭제합니다.
kubectl delete machine [MACHINE_NAME]
클러스터가 올바르게 구성되면 IP 주소로 대체 머신이 생성됩니다.
할당된 IP 주소의 수가 충분하지만 클러스터에 머신이 등록되지 않음
- 증상
네트워크에 할당된 주소가 충분하지만 사용자 클러스터에 머신이 등록되지 않습니다.
- 가능한 원인
IP 충돌이 있을 수 있습니다. 해당 IP를 다른 머신 또는 부하 분산기에서 사용하고 있을 수 있습니다.
- 해결 방법
영향을 받는 머신의 IP 주소가 사용되지 않았는지 확인합니다. 충돌이 있는 경우 사용자 환경에서 충돌을 해결해야 합니다.
vSphere
govc
로 디버깅vSphere 관련 문제가 발생하면
govc
를 사용하여 문제 해결을 수행할 수 있습니다. 예를 들어 vCenter 사용자 계정에 대한 권한 및 액세스를 쉽게 확인하고 vSphere 로그를 수집할 수 있습니다.vCenter 인증서 변경
평가 또는 기본 설정 모드에서 vCenter Server를 실행 중이고 여기에 생성된 TLS 인증서가 있으면 시간 경과에 따라 이 인증서가 변경될 수 있습니다. 인증서가 변경되었으면 실행 중인 클러스터에서 새 인증서를 확인할 수 있도록 해야 합니다.
새 vCenter 인증서를 검색하고 이를 파일로 저장합니다.
true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
이제 각 클러스터에 대해 vSphere 및 vCenter 인증서가 포함된 ConfigMap을 삭제하고 새 인증서로 새 ConfigMap을 만듭니다. 예를 들면 다음과 같습니다.
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
각 클러스터에서 clusterapi-controllers 포드를 삭제합니다. 포드가 다시 시작되면 새 인증서가 사용됩니다. 예를 들면 다음과 같습니다.
kubectl --kubeconfig kubeconfig -n kube-system get pods
kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...
기타
Terraform vSphere 제공업체 세션 한도
GKE On-Prem은 Terraform의 vSphere 제공업체를 이용하여 vSphere 환경에 VM을 가져옵니다. 제공업체의 세션 한도는 1,000개입니다. 현재 구현은 사용 후 활성 세션을 닫지 않습니다. 실행 중인 세션이 너무 많으면 503 오류가 발생할 수 있습니다.
세션은 300초 후 자동으로 닫힙니다.
- 증상
실행 중인 세션이 너무 많으면 다음과 같은 오류가 발생할 수 있습니다.
Error connecting to CIS REST endpoint: Login failed: body: {"type":"com.vmware.vapi.std.errors.service_unavailable","value": {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is limited to 1000. Existing sessions are 1000.", "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}}, status: 503 Service Unavailable
- 가능한 원인
환경에서 실행 중인 Terraform 제공업체 세션이 너무 많습니다.
- 해결 방법
이는 현재 정상적인 작동입니다. 세션은 300초 후 자동으로 닫힙니다. 자세한 내용은 GitHub 문제 #618을 참조하세요.
Docker용 프록시 사용:
oauth2: cannot fetch token
- 증상
프록시를 사용하는 동안 다음 오류가 발생할 수 있습니다.
oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
- 가능한 원인
HTTP 대신 HTTPS 프록시를 제공했을 수 있습니다.
- 해결 방법
Docker 구성에서 프록시 주소를
https://
대신http://
로 변경합니다.
라이선스가 올바른지 확인
특히 평가판 라이선스를 사용할 때는 해당 라이선스가 올바른지 확인해야 합니다. F5, ESXi 호스트, vCenter 라이선스가 만료되면 예기치 않은 오류가 발생할 수 있습니다.
-