관리 클러스터 문제 해결

이 항목에는 독립형 관리 클러스터 배포 문제를 해결하는 데 도움이 되는 팁이 포함되어 있습니다. 아래 절차 중 일부는 kind CLI를 사용합니다. kind를 설치하려면 kind 설명서의 설치를 참조하십시오. 워크로드 클러스터 문제 해결에 대한 자세한 내용은 워크로드 클러스터 문제 해결을 참조하십시오.

일반 작업

SSH를 사용하여 클러스터 노드에 연결

SSH를 사용하여 독립형 관리 클러스터 또는 워크로드 클러스터의 개별 노드에 연결할 수 있습니다. 이렇게 하려면 관리 클러스터를 배포할 때 생성한 SSH 키 쌍을 SSH 명령을 실행하는 시스템에서 사용할 수 있어야 합니다. 따라서 tanzu 명령을 실행하는 시스템에서 ssh 명령을 실행해야 합니다.

관리 클러스터에 등록하고 관리 클러스터에서 배포하는 워크로드 클러스터에서 사용하는 SSH 키는 다음 사용자 계정과 연결됩니다.

  • Photon OS 및 Ubuntu에서 실행되는 vSphere 관리 클러스터 및 Tanzu Kubernetes 노드: capv
  • AWS 배스천 노드: ubuntu
  • Ubuntu에서 실행되는 AWS 관리 클러스터 및 Tanzu Kubernetes 노드: ubuntu
  • Amazon Linux에서 실행되는 AWS 관리 클러스터 및 Tanzu Kubernetes 노드: ec2-user
  • Azure 관리 클러스터 및 Tanzu Kubernetes 노드(항상 Ubuntu): capi

SSH를 사용하여 노드에 연결하려면 부트스트랩 시스템으로 사용하는 시스템에서 다음 명령 중 하나를 실행합니다.

  • vSphere 노드: ssh capv@node-address
  • Ubuntu의 AWS 배스천 노드, 관리 클러스터, 워크로드 노드: ssh ubuntu@node-address
  • Amazon Linux에서 실행되는 AWS 관리 클러스터 및 Tanzu Kubernetes 노드: ssh ec2-user@node-address
  • Azure 노드: ssh capi@node-address

SSH 키가 ssh 명령을 실행하는 시스템에 있으므로 암호가 필요하지 않습니다.

kubectl로 사용자, 컨텍스트, 클러스터 삭제

사용자, 컨텍스트, 클러스터의 일부 또는 전체를 삭제하여 kubectl 상태를 정리하려면 다음을 수행합니다.

  1. ~/.kube-tkg/config 파일을 엽니다.

  2. 삭제할 user 개체에 대해 다음을 실행합니다.

    kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
    

    여기서 USERNAMEconfig 파일에 있는 대로 각 최상위 user 개체의 name 속성입니다.

  3. 삭제할 context 개체에 대해 다음을 실행합니다.

    kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
    

    여기서 CONTEXT-NAMEname 파일에 있는 대로 각 최상위 context 개체의 config 속성입니다(일반적으로 contexts.mycontext-admin@mycontext 형식).

  4. 삭제할 cluster 개체에 대해 다음을 실행합니다.

    kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
    

    여기서 CLUSTER-NAMEconfig 파일에 있는 대로 각 최상위 cluster 개체의 name 속성입니다.

  5. config 파일에 현재 컨텍스트가 삭제한 클러스터로 나열되면 컨텍스트를 설정 해제합니다.

    kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
    
  6. tanzu CLI에서 추적되는 관리 클러스터를 삭제한 경우 Tanzu CLI 구성에서 관리 클러스터 삭제에 설명된 대로 tanzu config server delete를 실행하여 tanzu CLI 상태에서 삭제합니다.

Photon OS 노드에서 nfs-utils 비활성화

문제

Tanzu Kubernetes Grid v1.1.2 이상에서는 기본적으로 nfs-utils를 사용하도록 설정됩니다. nfs-utils가 필요하지 않은 경우 클러스터 노드 VM에서 제거할 수 있습니다.

솔루션

Tanzu Kubernetes Grid v1.1.2 이상과 함께 배포하는 클러스터에서 nfs-utils를 비활성화하려면 SSH를 사용하여 클러스터 노드 VM에 로그인하고 다음 명령을 실행합니다.

tdnf erase nfs-utils

대상 플랫폼

검증 실패, AWS에 자격 증명 오류

문제

tanzu management-cluster create 또는 tanzu mc create 실행이 실패하고 다음과 유사한 오류가 표시됩니다.

Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain

Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request

솔루션

Tanzu Kubernetes Grid는 기본 AWS 자격 증명 제공자 체인을 사용합니다. AWS에서 관리 또는 워크로드 클러스터를 생성하기 전에 AWS 자격 증명 구성에 설명된 대로 AWS 계정 자격 증명을 구성해야 합니다.

유효성 검사 실패, Azure에 법적 조건 오류

문제

Azure에서 독립형 관리 또는 워크로드 클러스터를 생성하기 전에 클러스터 노드에서 사용하는 VM 이미지를 포함하는 법적 조건을 수락해야 합니다. 라이센스를 수락하지 않고 tanzu mc create 또는 tanzu cluster create를 실행하면 다음과 같은 오류와 함께 실패합니다.

User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.

솔루션

이 경우 법적 조건에 동의하고 다음을 다시 시도하십시오.

관리 클러스터

관리 클러스터 배포 실패 후 정리

문제

독립형 관리 클러스터를 배포하려는 시도가 실패하면 클라우드 인프라 및 부트스트랩 시스템에 분리된 개체가 남습니다.

솔루션

  1. 터미널 또는 Tanzu Kubernetes Grid 설치 관리자 인터페이스에서 tanzu mc create 명령 출력을 모니터링합니다. 명령이 실패하면 다음이 포함된 도움말 메시지가 출력됩니다. "관리 클러스터를 배포하는 동안 실패… 관리 클러스터에서 생성된 리소스를 정리하려면: tkg delete mc…."
  2. tanzu mc delete YOUR-CLUSTER-NAME을 실행합니다. 이 명령은 인프라 및 로컬에서 생성한 개체를 제거합니다.

아래에 설명된 대체 방법을 사용할 수도 있습니다.

  • 부트스트랩 시스템을 정리하려면 다음을 수행합니다.

    • kind 클러스터를 제거하려면 kind CLI를 사용합니다. 예:

      kind get clusters
      kind delete cluster --name tkg-kind-example1234567abcdef
      
    • Docker 개체를 제거하려면 docker CLI를 사용합니다. 예를 들어 docker rm, docker rmi , docker system prune -a --volumes.

      주의

      시스템의 Tanzu Kubernetes Grid와 관련되지 않은 Docker 프로세스를 실행 중인 경우 필요에 따라 추가되지 않은 Docker 개체를 개별적으로 제거합니다.

  • 대상 플랫폼 정리:

    • vSphere: Tanzu Kubernetes Grid에서 생성한 VM 및 기타 리소스를 찾아 전원을 끄고 삭제합니다.
    • AWS: Amazon EC2 대시보드에 로그인하고 리소스를 수동으로 삭제하거나 자동화된 솔루션을 사용합니다.
    • Azure: 리소스 그룹(Resource Groups)에서 AZURE_RESOURCE_GROUP을 엽니다. 확인란을 사용하여 Tanzu Kubernetes Grid에서 생성한 리소스를 선택하고 삭제합니다. 이름에 타임 스탬프가 포함되어 있습니다.

AWS에서 관리 클러스터를 삭제할 수 없음

문제

AWS에서 tanzu mc delete를 실행한 후 tanzu mc get 및 기타 Tanzu CLI 명령이 더 이상 삭제된 관리 클러스터를 나열하지 않지만 다음을 수행합니다.

  • 클러스터가 AWS 인프라에서 삭제되지 않고 해당 노드가 Amazon EC2 대시보드에 계속 표시됨
  • 관리 클러스터 로그에 cluster infrastructure is still being provisioned: VpcReconciliationFailed 오류가 표시됩니다.

솔루션

이 동작은 TKG가 만료되었거나 잘못된 AWS 계정 자격 증명을 사용하는 경우에 발생합니다. 이 상황을 방지하거나 복구하려면 다음을 수행합니다.

  • 방지: AWS 자격 증명 프로파일 또는 로컬 정적 환경 변수를 사용하여 AWS 계정 자격 증명 구성에 설명된 대로 AWS 계정 자격 증명을 업데이트합니다.

    • AWS 인스턴스 프로파일 자격 증명을 사용하여 관리 클러스터를 삭제할 수 없습니다.
  • EC2 대시보드를 사용하여 복구: EC2 대시보드에서 관리 클러스터 노드를 수동으로 삭제합니다.

  • CLI를 사용하여 복구

    1. 관리 클러스터 삭제 실패로 인해 부트스트랩 시스템에 남아 있는 kind 클러스터에서 AWS 자격 증명 암호를 수정합니다.

      kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
      
    2. AWS 자격 증명을 포함하도록 암호를 편집합니다.

      [default]
      aws_access_key_id = <key id>
      aws_secret_access_key = <access_key>
      region = <region>
      
    3. tanzu mc delete를 다시 실행합니다.

관리 클러스터를 삭제한 후 클러스터 종류가 유지됩니다.

문제

tanzu mc delete를 실행하면 관리 클러스터가 제거되지만 부트스트랩 시스템에서 로컬 kind 클러스터를 삭제하지 못합니다.

솔루션

  1. 실행 중인 모든 kind 클러스터를 나열하고 tkg-kind-unique_ID처럼 보이는 클러스터를 제거합니다.

    kind delete cluster --name tkg-kind-unique_ID
    
  2. 실행 중인 모든 클러스터를 나열하고 kind 클러스터를 식별합니다.

    docker ps -a
    
  3. kind 클러스터의 컨테이너 ID를 복사하여 제거합니다.

    docker kill container-ID
    

관리 클러스터 배포 실패 후 시스템이 중단되었습니다.

문제

시스템이 중단되어 업데이트 적용을 기다리는 동안 독립형 관리 클러스터가 배포되지 않습니다.

솔루션

제어부 노드가 하나만 있는 dev 계획으로 배포한 관리 클러스터의 경우 관리 클러스터를 다시 배포해야 합니다. 둘 이상의 제어부 노드가 있는 관리 클러스터의 경우 중단된 시스템을 식별하고 삭제할 수 있습니다.

  1. 관리 클러스터의 상태를 검색합니다. 예:

    kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
    
  2. 이전 단계의 출력에서 중단된 시스템의 이름을 찾습니다. 중단된 시스템은 WaitingForRemediation으로 표시됩니다. 예를 들어 다음 출력에서 중단된 시스템의 이름은 my-mgmt-cluster-zpc7t입니다.

    status:
      conditions:
      - lastTransitionTime: "2021-08-25T15:44:23Z"
        message: KCP can't remediate if current replicas are less or equal then 1
        reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
        severity: Warning
        status: "False"
        type: Ready
    
  3. 제어부 노드의 시스템 상태 점검 시간 초과 값을 기본값인 5m보다 증가합니다. 예:

    tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
    

    MachineHealthCheck 개체 업데이트에 대한 자세한 내용은 로드 클러스터의 시스템 상태 점검 구성의 MachineHealthCheck 개체 생성 또는 업데이트를 참조하십시오.

  4. kubectl을 관리 클러스터의 컨텍스트로 설정합니다. 예:

    kubectl config use-context mgmt-cluster-admin@mgmt-cluster
    
  5. 중단된 시스템을 삭제합니다.

    kubectl delete machine MACHINE-NAME
    

    여기서 MACHINE-NAME은 이전 단계에서 배치한 시스템의 이름입니다.

  6. KubeadmControlPlane 컨트롤러가 시스템을 다시 배포할 때까지 기다립니다.

~/.config/tanzu 디렉토리를 복원합니다.

문제

부트스트랩 시스템의 ~/.config/tanzu 디렉토리가 실수로 삭제되거나 손상되었습니다. Tanzu CLI는 이 디렉토리를 생성하고 사용하며 이 디렉토리 없이는 작동할 수 없습니다.

솔루션

~/.config/tanzu 디렉토리의 내용을 복원하려면 다음을 수행합니다.

  1. 기존 Tanzu Kubernetes Grid 관리 클러스터를 식별하려면 다음을 실행합니다.

    kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
    

    명령 출력에는 Tanzu CLI에서 생성하거나 추가한 모든 관리 클러스터의 이름과 컨텍스트가 나열됩니다.

  2. 출력에 나열된 각 관리 클러스터에 대해 다음을 실행하여 ~/.config/tanzu 디렉토리 및 CLI로 복원합니다.

    tanzu login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
    

tanzu management-cluster를 실행하면 macOS 생성하면 kubectl 버전 오류가 발생함

문제

안정적인 최신 버전의 Docker Desktop을 사용하여 macOS에서 tanzu management-cluster create 또는 tanzu mc create 명령을 실행하면 실패하고 다음과 같은 오류 메시지가 표시됩니다.

Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.24.10

이 문제는 Docker Desktop이 경로에 이전 버전의 kubectl을 연결(symlink)하기 때문에 발생합니다.

솔루션

Docker 버전 앞의 경로에 지원되는 최신 버전의 kubectl을 배치합니다.

관리 클러스터 자격 증명 복구

독립형 관리 클러스터의 자격 증명을 분실한 경우(예: tanzu 명령을 실행하는 시스템에서 .kube-tkg/config 파일을 실수로 삭제) 관리 클러스터 제어부 노드에서 자격 증명을 복구할 수 있습니다.

  1. tanzu mc create를 실행하여 .kube-tkg/config 파일을 다시 생성합니다.
  2. vSphere, AWS 또는 Azure에서 관리 클러스터 제어부 노드의 공용 IP 주소를 가져옵니다.
  3. SSH를 사용하여 관리 클러스터 제어부 노드에 로그인합니다.

    각 대상 플랫폼에 사용할 자격 증명은 위의 SSH를 사용하여 클러스터 노드에 연결을 참조하십시오.

  4. 관리 클러스터용 admin.conf 파일에 액세스합니다.

    sudo vi /etc/kubernetes/admin.conf
    

    admin.conf 파일에는 클러스터 이름, 클러스터 사용자 이름, 클러스터 컨텍스트, 클라이언트 인증서 데이터가 포함됩니다.

  5. 클러스터 이름, 클러스터 사용자 이름, 클러스터 컨텍스트, 클라이언트 인증서 데이터를 tanzu 명령을 실행하는 시스템의 .kube-tkg/config 파일에 복사합니다.

Pinniped

Pinniped 배포 후 작업이 실패함

문제

Tanzu Kubernetes Grid v2.1.1로 업그레이드하면 다음과 유사한 오류가 반환됩니다.

 Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again

솔루션

이 오류는 Pinniped 배포 후 작업이 구성 요소의 업그레이드 프로세스와 충돌하는 경우에 발생할 수 있습니다. 다음 단계에 따라 작업을 삭제하고 다시 배포합니다.

  1. Pinniped 배포 후 작업을 삭제합니다.

    kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
    
  2. kapp-controller가 배포 후 작업을 다시 배포할 때까지 5분 정도 기다립니다.

  3. Pinniped 애플리케이션의 상태를 확인합니다.

    kubectl get app -n tkg-system pinniped
    NAME       DESCRIPTION           SINCE-DEPLOY   AGE
    pinniped   Reconcile succeeded   5s             49m
    

    DESCRIPTIONReconciling이 표시되면 몇 분 정도 기다렸다가 다시 확인합니다. Reconcile succeeded가 표시되면 다음 단계를 계속합니다.

  4. Pinniped 배포 후 작업의 상태를 확인합니다.

    kubectl get jobs -n pinniped-supervisor
    NAME                             COMPLETIONS   DURATION   AGE
    pinniped-post-deploy-job-ver-1   1/1           9s         62s
    

관리 클러스터 업그레이드 후 워크로드 클러스터에서 Pinniped 인증 오류 발생

문제

관리 클러스터를 최근에 업그레이드했습니다. 이 관리 클러스터와 연결된 워크로드 클러스터에 인증하려고 하면 다음과 유사한 오류 메시지가 표시됩니다.

Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority

솔루션

이 문제는 워크로드 클러스터에서 사용 중인 Pinniped Supervisor CA 번들의 복사본이 최신 버전이 아닙니다. Supervisor CA 번들을 업데이트하려면 아래 단계를 따릅니다.

  1. kubectl 컨텍스트를 관리 클러스터로 설정합니다.

  2. pinniped-info ConfigMap에서 base64로 인코딩된 CA 번들 및 issuer 끝점을 가져옵니다.

    kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
    
  3. 워크로드 클러스터의 Pinniped 추가 기능 암호에서 values.yaml 섹션을 가져옵니다.

    kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
    

    이 암호는 관리 클러스터에 있습니다.

  4. 위에서 생성된 values.yaml 파일에서 supervisor_ca_bundle_data 키를 pinniped-info ConfigMap의 CA 번들에 맞게 업데이트합니다. 또한 supervisor_svc_endpointissuer 끝점과 일치하는지 확인합니다.

  5. 편집된 values.yaml 파일을 인코딩하고 워크로드 클러스터 암호로 교체하여 base64로 업데이트를 적용합니다. 이 명령은 환경 OS에 따라 다릅니다. 예:

    Linux:

    kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
    

    macOS:

    kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
    
  6. 워크로드 클러스터에서 Pinniped 애플리케이션이 변경 내용을 조정했는지 확인합니다.

    kubectl get app pinniped -n tkg-system
    
  7. 클러스터에 인증합니다. 예:

    kubectl get pods -A --kubeconfig my-cluster-credentials
    

포드

vCenter 연결로 인해 포드가 클러스터에서 보류 중 상태로 중단됨

문제

생성된 클러스터에서 kubectl get pods -A를 실행하면 일부 포드가 보류 중 상태로 유지됩니다.

영향을 받는 포드에서 kubectl describe pod -n pod-namespace pod-name을 실행하고 다음 이벤트를 확인합니다.

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

솔루션

클러스터와 vCenter 간의 통신을 보장하기 위해 연결 및 방화벽 규칙이 있는지 확인합니다. 방화벽 포트 및 프로토콜 요구 사항은 VMware 포트 및 프로토콜의 vSphere 목록을 참조하십시오.

Tanzu CLI

Tanzu CLI가 관리 클러스터에 연결할 수 없음

문제

tanzu CLI 명령을 실행하면 다음과 유사한 오류가 표시됩니다.

Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying

솔루션

이것은 TKG v1.2 이상에 영향을 미치는 알려진 문제입니다. 해결 방법은 Tanzu CLI 구성에서 관리 클러스터 인증서 업데이트Tanzu Kubernetes Grid에서 tkg/tanzu cli 명령을 사용하여 클러스터에 액세스할 수 없음을 참조하십시오.

Tanzu Kubernetes Grid 설치 관리자 인터페이스

Tanzu Kubernetes Grid UI가 Windows에서 올바르게 표시되지 않음

문제

Windows 시스템에서 tanzu management-cluster create --ui 또는 tanzu mc create --ui 명령을 실행하면 UI가 기본 브라우저에서 열리지만 그래픽 및 스타일은 적용되지 않습니다. 이 문제는 Windows 레지스트리가 application/x-css로 설정되어 있기 때문에 발생합니다.

솔루션

  1. Windows 검색에서 regedit를 입력하여 레지스트리 편집기 유틸리티를 엽니다.
  2. HKEY_CLASSES_ROOT를 확장하고 .js를 선택합니다.
  3. 콘텐츠 유형(Content Type)을 마우스 오른쪽 버튼으로 클릭하고 수정(Modify)을 선택합니다.
  4. 값을 application/javascript로 설정하고 확인(OK)을 클릭합니다.
  5. tanzu mc create --ui 명령을 다시 실행하여 UI를 다시 시작합니다.

NSX Advanced Load Balancer

VIP에 NSX Advanced Load Balancer 요청이 실패하고 호스트에 대한 경로 없음 메시지가 표시됨

문제

LoadBalancer 유형 서비스의 수가 많고 모든 서비스 엔진이 동일한 L2 네트워크에 배포된 경우 NSX Advanced Load Balancer VIP에 대한 요청이 실패하고 no route to host 메시지가 표시될 수 있습니다.

이 문제는 서비스 엔진의 기본 ARP 속도 제한이 100이기 때문에 발생합니다.

솔루션

ARP 속도 제한을 더 큰 수로 설정합니다. 이 매개 변수는 NSX Advanced Load Balancer Essentials에서는 조정할 수 없지만 NSX Advanced Load Balancer Enterprise Edition에서는 조정이 가능합니다.

check-circle-line exclamation-circle-line close-line
Scroll to top icon