문제 해결

다음 섹션에서는 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 컨트롤러의 로그를 검사하여 디버깅할 수 있습니다.

  1. kube-system 네임스페이스에서 Cluster API 컨트롤러 포드의 이름을 찾습니다. 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로입니다.

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. 포드의 로그를 엽니다. 여기서 [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=falsegkectl 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_proxyHTTPS_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 구성에 오류가 있습니다.
해결 방법
문제를 해결하려면 다음 단계를 따르세요.
  1. kubeconfig에서 id-token을 파싱합니다.

    login 명령어로 생성된 kubeconfig 파일에서 id-token을 복사합니다.

    kind: Config
    …
    users:
    - name: …
      user:
        auth-provider:
          config:
            id-token: [id-token]
            …
    

    다음 단계에 따라 jwt-cli를 설치하고 다음을 실행합니다.

    $ jwt [id-token]
  2. OIDC 구성을 확인합니다.

    클러스터를 만드는 데 사용된 config.yaml에서 작성된 oidc 섹션에는 groupusername 필드가 포함되어 있으며, 이러한 필드는 apiserver에서 --oidc-group-claim--oidc-username-claim 플래그를 설정하는 데 사용됩니다. apiserver가 토큰과 함께 제시되면 해당 그룹 클레임 및 사용자 이름 클레임을 찾아 해당 그룹 또는 사용자에게 올바른 권한이 있는지 확인합니다.

    config.yamloidc 섹션에서 groupuser에 설정된 클레임이 id-token에 있는지 확인합니다.

  3. 적용된 RBAC를 확인합니다.

    사용자 이름 클레임으로 지정된 사용자 또는 이전 단계의 그룹 클레임에 있는 그룹 중 하나에 대해 올바른 권한을 가진 RBAC가 있는지 확인합니다. RBAC 내 사용자 또는 그룹 이름 앞에는 config.yamloidc 섹션에 제공된 usernameprefix 또는 groupprefix를 붙여야 합니다.

    usernameprefix가 비어 있고 usernameemail 이외의 값인 경우 프리픽스의 기본값은 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
  4. 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 공급업체에 연결할 수 없습니다.

해결 방법

문제를 해결하려면 다음 단계를 따르세요.

  1. useHTTPProxytrue로 설정

    공개 인터넷을 통해 IDP에 연결할 수 없는 경우 OIDC HTTP 프록시가 Google Cloud console을 통해 로그인할 수 있도록 설정해야 합니다. config.yamloidc 섹션에서 usehttpproxytrue로 설정해야 합니다. 이미 클러스터를 만들었고 프록시를 사용 설정하려는 경우 ClientConfig CRD를 직접 수정할 수 있습니다. $ kubectl edit clientconfig default -n kube-public을 실행하고 useHTTPProxytrue로 변경합니다.

  2. useHTTPProxy가 이미 true로 설정되어 있음

    HTTP 프록시가 사용 설정된 상태에서도 이 오류가 계속 발생하면 프록시 시작에 문제가 있을 수 있습니다. 프록시 로그를 가져오려면 $ kubectl logs deployment/clientconfig-operator -n kube-system을 실행합니다. IDP에 잘 알려진 CA가 있더라도 http 프록시가 시작하려면 config.yamloidc 섹션에 capath 필드를 제공해야 합니다.

  3. IDP에서 동의 요청

    승인 서버에서 동의를 요청하고 추가 매개변수 prompt=consent를 포함하고 있지 않은 경우 이 오류가 표시될 수 있습니다. $ kubectl edit clientconfig default -n kube-public을 실행하고 extraparamsprompt=consent를 추가하고 다시 로그인을 시도합니다.

  4. RBAC가 잘못 구성됨

    아직 인증하지 않았다면 Anthos용 인증 플러그인을 사용하여 인증을 시도합니다. 플러그인으로 로그인하는 중에도 승인 오류가 표시되면 문제 해결 단계에 따라 플러그인 문제를 해결한 다음 Google Cloud Console을 통해 다시 로그인을 시도합니다.

  5. 로그아웃했다가 다시 로그인

    경우에 따라 스토리지 서비스에서 일부 설정이 변경되는 경우 명시적으로 로그아웃해야 할 수 있습니다. 클러스터 세부정보 페이지로 이동하고 로그아웃을 클릭한 다음 다시 로그인을 시도합니다.

관리자 워크스테이션

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이 원인일 수 있습니다.

해결 방법

가상 디스크가 잘못된 가상 머신에 연결되어 있으면 이를 수동으로 분리해야 할 수 있습니다.

  1. 노드를 드레이닝합니다. 안전한 노드 드레이닝을 참조하세요. kubectl drain 명령어에 --ignore-daemonsets--delete-local-data 플래그를 포함할 수 있습니다.
  2. VM을 끕니다.
  3. vCenter에서 VM 하드웨어 구성을 수정하여 볼륨을 삭제합니다.
  4. VM을 켭니다.
  5. 노드를 차단 해제합니다.

볼륨이 사라짐

증상

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 리소스를 수동으로 삭제해야 할 수 있습니다.

  1. kubectl delete pvc [PVC_NAME].을 실행하여 PV를 참조한 PVC를 삭제합니다.
  2. kubectl delete pod [POD_NAME].을 실행하여 PVC를 참조한 포드를 삭제합니다.
  3. 2단계를 반복합니다. (자세한 내용은 Kubernetes 문제 74374를 참조하세요.)

업그레이드

업그레이드 중 다운타임 정보

리소스 설명
관리자 클러스터

관리자 클러스터가 다운되면 다운타임을 유발한 오류의 영향을 받지 않는 한 사용자 클러스터 제어 영역과 워크로드는 사용자 클러스터에서 계속 실행됩니다.

사용자 클러스터 제어 영역

일반적으로 사용자 클러스터 제어 영역에는 뚜렷한 다운타임이 없어야 합니다. 하지만 Kubernetes API 서버로의 장기 실행 연결이 끊어져 다시 설정해야 할 수 있습니다. 이 경우 API 호출자는 연결을 설정할 때까지 다시 시도해야 합니다. 최악의 경우에는 업그레이드 중에 다운타임이 최대 1분간 발생할 수 있습니다.

사용자 클러스터 노드

업그레이드 시 사용자 클러스터 노드를 변경해야 하는 경우 GKE On-Prem은 노드를 롤링 방식으로 다시 만들고 이 노드에서 실행 중인 포드를 다시 예약합니다. 적절한 PodDisruptionBudget안티어피니티 규칙을 설정하여 워크로드에 대한 영향을 방지할 수 있습니다.

사용자 클러스터 크기 조절

사용자 클러스터 크기 조절 실패

증상

사용자 클러스터의 크기 조절 작업이 실패합니다.

가능한 원인

여러 요인으로 인해 크기 조절 작업이 실패할 수 있습니다.

해결 방법

크기 조절에 실패하는 경우 다음 단계를 따르세요.

  1. 클러스터의 MachineDeployment 상태를 살펴보고 이벤트 또는 오류 메시지가 있는지 확인합니다.

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
  2. 새로 생성된 머신에 오류가 있는지 확인합니다.

    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 인증서가 있으면 시간 경과에 따라 이 인증서가 변경될 수 있습니다. 인증서가 변경되었으면 실행 중인 클러스터에서 새 인증서를 확인할 수 있도록 해야 합니다.

  1. 새 vCenter 인증서를 검색하고 이를 파일로 저장합니다.

    true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
  2. 이제 각 클러스터에 대해 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 -
  3. 각 클러스터에서 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 라이선스가 만료되면 예기치 않은 오류가 발생할 수 있습니다.