이 항목에는 독립형 관리 클러스터 배포 문제를 해결하는 데 도움이 되는 팁이 포함되어 있습니다.
워크로드 클러스터 문제 해결에 대한 자세한 내용은 워크로드 클러스터 문제 해결을 참조하십시오. Release Notes 또는 VMware 기술 자료 문서에서 이 릴리스의 알려진 문제에 대한 추가 해결 방법을 찾을 수 있습니다
아래 절차 중 일부는 kind
CLI를 사용합니다. kind
를 설치하려면 kind
설명서의 설치를 참조하십시오.
SSH를 사용하여 독립형 관리 클러스터 또는 워크로드 클러스터의 개별 노드에 연결할 수 있습니다. 이렇게 하려면 관리 클러스터를 배포할 때 생성한 SSH 키 쌍을 SSH 명령을 실행하는 시스템에서 사용할 수 있어야 합니다. 따라서 tanzu
명령을 실행하는 시스템에서 ssh
명령을 실행해야 합니다.
관리 클러스터에 등록하고 관리 클러스터에서 배포하는 워크로드 클러스터에서 사용하는 SSH 키는 다음 사용자 계정과 연결됩니다.
capv
ubuntu
ubuntu
ec2-user
capi
SSH를 사용하여 노드에 연결하려면 부트스트랩 시스템으로 사용하는 시스템에서 다음 명령 중 하나를 실행합니다.
ssh capv@node-address
ssh ubuntu@node-address
ssh ec2-user@node-address
ssh capi@node-address
SSH 키가 ssh
명령을 실행하는 시스템에 있으므로 암호가 필요하지 않습니다.
kubectl
로 사용자, 컨텍스트, 클러스터 삭제사용자, 컨텍스트, 클러스터의 일부 또는 전체를 삭제하여 kubectl
상태를 정리하려면 다음을 수행합니다.
~/.kube-tkg/config
파일을 엽니다.
삭제할 user
개체에 대해 다음을 실행합니다.
kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
여기서 USERNAME
은 config
파일에 있는 대로 각 최상위 user
개체의 name
속성입니다.
삭제할 context
개체에 대해 다음을 실행합니다.
kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
여기서 CONTEXT-NAME
은 name
파일에 있는 대로 각 최상위 context
개체의 config
속성입니다(일반적으로 contexts.mycontext-admin@mycontext
형식).
삭제할 cluster
개체에 대해 다음을 실행합니다.
kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
여기서 CLUSTER-NAME
은 config
파일에 있는 대로 각 최상위 cluster
개체의 name
속성입니다.
config
파일에 현재 컨텍스트가 삭제한 클러스터로 나열되면 컨텍스트를 설정 해제합니다.
kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
tanzu
CLI에서 추적되는 관리 클러스터를 삭제한 경우 Tanzu CLI 구성에서 관리 클러스터 삭제에 설명된 대로 tanzu config server delete
를 실행하여 tanzu
CLI 상태에서 삭제합니다.
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
문제
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에서 독립형 관리 또는 워크로드 클러스터를 생성하기 전에 클러스터 노드에서 사용하는 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.
솔루션
이 경우 법적 조건에 동의하고 다음을 다시 시도하십시오.
문제
독립형 관리 클러스터를 배포하려는 시도가 실패하면 클라우드 인프라 및 부트스트랩 시스템에 분리된 개체가 남습니다.
솔루션
tanzu mc create
명령 출력을 모니터링합니다. 명령이 실패하면 다음이 포함된 도움말 메시지가 출력됩니다. "관리 클러스터를 배포하는 동안 실패… 관리 클러스터에서 생성된 리소스를 정리하려면: tkg delete mc…."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 개체를 개별적으로 제거합니다.
대상 플랫폼 정리:
AZURE_RESOURCE_GROUP
을 엽니다. 확인란을 사용하여 Tanzu Kubernetes Grid에서 생성한 리소스를 선택하고 삭제합니다. 이름에 타임 스탬프가 포함되어 있습니다.문제
AWS에서 tanzu mc delete
를 실행한 후 tanzu mc get
및 기타 Tanzu CLI 명령이 더 이상 삭제된 관리 클러스터를 나열하지 않지만 다음을 수행합니다.
cluster infrastructure is still being provisioned: VpcReconciliationFailed
오류가 표시됩니다.솔루션
이 동작은 TKG가 만료되었거나 잘못된 AWS 계정 자격 증명을 사용하는 경우에 발생합니다. 이 상황을 방지하거나 복구하려면 다음을 수행합니다.
방지: AWS 자격 증명 프로파일 또는 로컬 정적 환경 변수를 사용하여 AWS 계정 자격 증명 구성에 설명된 대로 AWS 계정 자격 증명을 업데이트합니다.
EC2 대시보드를 사용하여 복구: EC2 대시보드에서 관리 클러스터 노드를 수동으로 삭제합니다.
CLI를 사용하여 복구
관리 클러스터 삭제 실패로 인해 부트스트랩 시스템에 남아 있는 kind
클러스터에서 AWS 자격 증명 암호를 수정합니다.
kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
AWS 자격 증명을 포함하도록 암호를 편집합니다.
[default]
aws_access_key_id = <key id>
aws_secret_access_key = <access_key>
region = <region>
tanzu mc delete
를 다시 실행합니다.
문제
tanzu mc delete
를 실행하면 관리 클러스터가 제거되지만 부트스트랩 시스템에서 로컬 kind
클러스터를 삭제하지 못합니다.
솔루션
실행 중인 모든 kind
클러스터를 나열하고 tkg-kind-unique_ID
처럼 보이는 클러스터를 제거합니다.
kind delete cluster --name tkg-kind-unique_ID
실행 중인 모든 클러스터를 나열하고 kind
클러스터를 식별합니다.
docker ps -a
kind
클러스터의 컨테이너 ID를 복사하여 제거합니다.
docker kill container-ID
문제
시스템이 중단되어 업데이트 적용을 기다리는 동안 독립형 관리 클러스터가 배포되지 않습니다.
솔루션
제어부 노드가 하나만 있는 dev
계획으로 배포한 관리 클러스터의 경우 관리 클러스터를 다시 배포해야 합니다. 둘 이상의 제어부 노드가 있는 관리 클러스터의 경우 중단된 시스템을 식별하고 삭제할 수 있습니다.
관리 클러스터의 상태를 검색합니다. 예:
kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
이전 단계의 출력에서 중단된 시스템의 이름을 찾습니다. 중단된 시스템은 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
제어부 노드의 시스템 상태 점검 시간 초과 값을 기본값인 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
개체 생성 또는 업데이트를 참조하십시오.
kubectl
을 관리 클러스터의 컨텍스트로 설정합니다. 예:
kubectl config use-context mgmt-cluster-admin@mgmt-cluster
중단된 시스템을 삭제합니다.
kubectl delete machine MACHINE-NAME
여기서 MACHINE-NAME
은 이전 단계에서 배치한 시스템의 이름입니다.
KubeadmControlPlane
컨트롤러가 시스템을 다시 배포할 때까지 기다립니다.
~/.config/tanzu
디렉토리를 복원합니다.문제
부트스트랩 시스템의 ~/.config/tanzu
디렉토리가 실수로 삭제되거나 손상되었습니다. Tanzu CLI는 이 디렉토리를 생성하고 사용하며 이 디렉토리 없이는 작동할 수 없습니다.
솔루션
~/.config/tanzu
디렉토리의 내용을 복원하려면 다음을 수행합니다.
기존 Tanzu Kubernetes Grid 관리 클러스터를 식별하려면 다음을 실행합니다.
kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
명령 출력에는 Tanzu CLI에서 생성하거나 추가한 모든 관리 클러스터의 이름과 컨텍스트가 나열됩니다.
출력에 나열된 각 관리 클러스터에 대해 다음을 실행하여 ~/.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.25.7
이 문제는 Docker Desktop이 경로에 이전 버전의 kubectl
을 연결(symlink)하기 때문에 발생합니다.
솔루션
Docker 버전 앞의 경로에 지원되는 최신 버전의 kubectl
을 배치합니다.
독립형 관리 클러스터의 자격 증명을 분실한 경우(예: tanzu
명령을 실행하는 시스템에서 .kube-tkg/config
파일을 실수로 삭제) 관리 클러스터 제어부 노드에서 자격 증명을 복구할 수 있습니다.
tanzu mc create
를 실행하여 .kube-tkg/config
파일을 다시 생성합니다.SSH를 사용하여 관리 클러스터 제어부 노드에 로그인합니다.
각 대상 플랫폼에 사용할 자격 증명은 위의 SSH를 사용하여 클러스터 노드에 연결을 참조하십시오.
관리 클러스터용 admin.conf
파일에 액세스합니다.
sudo vi /etc/kubernetes/admin.conf
admin.conf
파일에는 클러스터 이름, 클러스터 사용자 이름, 클러스터 컨텍스트, 클라이언트 인증서 데이터가 포함됩니다.
tanzu
명령을 실행하는 시스템의 .kube-tkg/config
파일에 복사합니다.VSPHERE_CONTROL_PLANE_ENDPOINT
값을 설정해야 할 수 있습니다.문제
외부 ID 공급자를 기존 TKG 배포와 통합하려면 관리 클러스터용 Pinniped 추가 기능 암호 생성에 설명된 대로 추가 기능 암호를 생성하는 데 사용되는 관리 클러스터 구성 파일에서 더미 VSPHERE_CONTROL_PLANE_ENDPOINT
값을 설정해야 할 수 있습니다.
Secret
를 삭제해야 합니다.문제
관리 클러스터에서 외부 ID 관리를 비활성화하면 사용되지 않은 Pinniped Secret
개체가 레거시 워크로드 클러스터에 남아 있습니다.
사용자가 이전 kubeconfig
를 사용하여 클러스터에 액세스하려고 하면 로그인 팝업이 나타나고 실패합니다.
해결 방법
ID 관리 비활성화에 설명된 대로 레거시 클러스터의 Pinniped Secret
를 수동으로 삭제합니다.
문제
Tanzu Kubernetes Grid v2.2로 업그레이드하면 다음과 유사한 오류가 반환됩니다.
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 배포 후 작업이 구성 요소의 업그레이드 프로세스와 충돌하는 경우에 발생할 수 있습니다. 다음 단계에 따라 작업을 삭제하고 다시 배포합니다.
Pinniped 배포 후 작업을 삭제합니다.
kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
kapp-controller
가 배포 후 작업을 다시 배포할 때까지 5분 정도 기다립니다.
Pinniped 애플리케이션의 상태를 확인합니다.
kubectl get app -n tkg-system pinniped
NAME DESCRIPTION SINCE-DEPLOY AGE
pinniped Reconcile succeeded 5s 49m
DESCRIPTION
에 Reconciling
이 표시되면 몇 분 정도 기다렸다가 다시 확인합니다. Reconcile succeeded
가 표시되면 다음 단계를 계속합니다.
Pinniped 배포 후 작업의 상태를 확인합니다.
kubectl get jobs -n pinniped-supervisor
NAME COMPLETIONS DURATION AGE
pinniped-post-deploy-job-ver-1 1/1 9s 62s
문제
관리 클러스터를 최근에 업그레이드했습니다. 이 관리 클러스터와 연결된 워크로드 클러스터에 인증하려고 하면 다음과 유사한 오류 메시지가 표시됩니다.
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 번들을 업데이트하려면 아래 단계를 따릅니다.
kubectl
컨텍스트를 관리 클러스터로 설정합니다.
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
워크로드 클러스터의 Pinniped 추가 기능 암호에서 values.yaml
섹션을 가져옵니다.
kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
이 암호는 관리 클러스터에 있습니다.
위에서 생성된 values.yaml
파일에서 supervisor_ca_bundle_data
키를 pinniped-info
ConfigMap의 CA 번들에 맞게 업데이트합니다. 또한 supervisor_svc_endpoint
가 issuer
끝점과 일치하는지 확인합니다.
편집된 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
워크로드 클러스터에서 Pinniped 애플리케이션이 변경 내용을 조정했는지 확인합니다.
kubectl get app pinniped -n tkg-system
클러스터에 인증합니다. 예:
kubectl get pods -A --kubeconfig my-cluster-credentials
문제
생성된 클러스터에서 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 명령을 실행하면 다음과 유사한 오류가 표시됩니다.
Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying
솔루션
Tanzu CLI 구성에서 관리 클러스터 인증서 업데이트 및 Tanzu Kubernetes Grid에서 tkg/tanzu cli 명령을 사용하여 클러스터에 액세스할 수 없음을 참조하십시오.
문제
cmD(Windows 명령 프롬프트)에서 열 형식의 CLI 명령 출력에 Tanzu 열 머리글에 관련 없는 문자가 포함됩니다. Windows 터미널 또는 PowerShell에서는 이 문제가 발생하지 않습니다.
솔루션
Windows 부트스트랩 시스템에서 Windows 터미널에서 Tanzu CLI를 실행합니다.
문제
MHC(시스템 상태 점검)가 비활성화되면 tanzu cluster status
와 같은 CLI 명령을 Tanzu 인프라가 다시 생성되는 동안 최신 노드 상태를 보고하지 않을 수 있습니다.
솔루션
없음.
문제
Windows 시스템에서 tanzu management-cluster create --ui
또는 tanzu mc create --ui
명령을 실행하면 UI가 기본 브라우저에서 열리지만 그래픽 및 스타일은 적용되지 않습니다. 이 문제는 Windows 레지스트리가 application/x-css
로 설정되어 있기 때문에 발생합니다.
솔루션
regedit
를 입력하여 레지스트리 편집기 유틸리티를 엽니다.HKEY_CLASSES_ROOT
를 확장하고 .js
를 선택합니다.application/javascript
로 설정하고 확인(OK)을 클릭합니다.tanzu mc create --ui
명령을 다시 실행하여 UI를 다시 시작합니다.문제
워크로드(AVI_ENABLE
) 또는 제어부(AVI_CONTROL_PLANE_HA_PROVIDER
)에 NSX Advanced Load Balancer 사용하는 경우 Avi 컨트롤러가 이름이 동일한 클러스터를 구분하지 못할 수 있습니다.
솔루션:
각 클러스터에 고유한 CLUSTER_NAME
값을 설정합니다. 서로 다른 부트스트랩 시스템에서도 CLUSTER_NAME
값이 동일한 여러 관리 클러스터를 생성하지 마십시오.
문제
총 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에서는 조정이 가능합니다.
AKODeploymentConfig
오류 발생문제
tanzu management-cluster create
를 실행하여 NSX ALB로 관리 클러스터를 생성하면 no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???
오류가 발생합니다.
솔루션
이 오류는 무시할 수 있습니다. 자세한 내용은 이 KB 문서를 참조하십시오.
medium
및 NSX Advanced Load Balancer가 있는 소규모 포드에서 Multus CNI가 실패함문제
vSphere NSX ALB를 사용하여 Multus CNI 패키지를 실행하는 medium
또는 더 작은 Worker 노드가 있는 워크로드 클러스터가 Insufficient CPU
또는 기타 오류와 함께 실패할 수 있습니다.
솔루션
NSX ALB에서 Multus CNI를 사용하려면 대규모 large
또는 extra-large
크기의 Worker 노드가 있는 워크로드 클러스터를 배포합니다.
문제
Azure에서 관리 클러스터 및 워크로드 클러스터 업그레이드가 context deadline exceeded
또는 unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane
과 같은 오류와 함께 실패합니다. 이 문제는 Azure에서의 작업이 다른 플랫폼보다 오래 걸리는 경우가 있기 때문에 발생합니다.
솔루션
tanzu management-cluster upgrade
또는 tanzu cluster upgrade
를 다시 실행하여 --timeout
플래그에 더 긴 시간 초과를 지정합니다. 기본 시간 초과 값은 30분 0초입니다.
문제
TKG v2.2에서 일반 클러스터를 TKG 독립형 관리 클러스터로 전환하는 구성 요소는 Carvel 패키지 tkg-pkg
에 패키징됩니다. 원래 TKG v1.3 이하에서 생성된 독립형 관리 클러스터에는 tkg-pkg
를 설치하기 위해 업그레이드 프로세스에 필요한 구성 암호가 부족하여 업그레이드가 실패합니다.
솔루션
TKG v1.3 이하에서 생성된 독립형 관리 클러스터에 대해 독립형 관리 클러스터 업그레이드에 있는 추가 단계를 수행합니다.