kubectl 명령줄 도구 문제 해결

Autopilot Standard

Google Kubernetes Engine (GKE)을 사용할 때 kubectl 명령줄 도구에 문제가 있으면 애플리케이션을 배포하거나 클러스터 리소스를 관리하지 못할 수 있습니다. 이러한 문제는 일반적으로 클러스터에서 내 ID를 인식하지 못하는 인증 실패와 도구가 클러스터의 제어 영역에 연결할 수 없는 연결 실패의 두 가지 카테고리로 나뉩니다.

이 페이지를 사용하여 이러한 문제를 진단하고 해결하세요. 다양한 인증 문제를 해결하고 kubectl 도구와 클러스터의 컨트롤 플레인 간 연결 문제를 디버깅하는 단계를 확인하세요. 필요한 플러그인이 설치되고 구성되었는지 확인하고 SSH 및 Konnectivity와 같은 서비스의 네트워크 정책 및 방화벽 고려사항을 검토하는 방법을 알아봅니다.

이 정보는 kubectl 명령어를 사용하여 GKE에서 애플리케이션 또는 클러스터 리소스를 관리하는 모든 사용자에게 중요합니다. 특히 핵심 일일 작업에 kubectl 명령어를 사용하는 애플리케이션 개발자, 플랫폼 관리자, 운영자에게 중요합니다. Google Cloud콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE 사용자 역할 및 태스크를 참고하세요.

관련 정보는 다음 리소스를 참고하세요.

• GKE에 국한되지 않는 문제에 대한 자세한 내용은 Kubernetes 문서의 kubectl 문제 해결을 참고하세요.
• kubectl 명령어를 사용하여 클러스터 및 워크로드 문제를 진단하는 방법을 자세히 알아보려면 kubectl로 클러스터 상태 조사를 참고하세요.

인증 및 승인 오류

kubectl 명령줄 도구 명령어를 사용할 때 인증 및 승인 관련 오류가 발생하면 다음 섹션을 참조하세요.

오류: 401(승인되지 않음)

GKE 클러스터에 연결할 때 HTTP 상태 코드 401 (Unauthorized)과 함께 인증 및 승인 오류가 발생할 수 있습니다. 이 문제는 로컬 환경의 GKE 클러스터에서 kubectl 명령어를 실행할 때 발생할 수 있습니다. 자세한 내용은 문제: 인증 및 승인 오류를 참조하세요.

오류: 인증 범위 부족

gcloud container clusters get-credentials를 실행할 때 다음 오류가 표시될 수 있습니다.

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Request had insufficient authentication scopes.

이 오류는 cloud-platform 범위가 없는 Compute Engine VM에서 GKE API에 액세스하려고 할 때 발생합니다.

이 오류를 해결하려면 누락된 cloud-platform 범위를 부여합니다. Compute Engine VM 인스턴스의 범위를 변경하는 방법에 대한 자세한 내용은 Compute Engine 문서의 인스턴스의 서비스 계정 만들기 및 사용 설정을 참조하세요.

오류: 실행 가능한 gke-gcloud-auth-plugin을 찾을 수 없음

kubectl 명령어 또는 GKE와 상호작용하는 커스텀 클라이언트를 실행하려고 할 때 다음과 유사한 오류 메시지가 표시될 수 있습니다.

Unable to connect to the server: getting credentials: exec: executable gke-gcloud-auth-plugin not found

It looks like you are trying to use a client-go credential plugin that is not installed.

To learn more about this feature, consult the documentation available at:
      https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins

Visit cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin to install gke-gcloud-auth-plugin.

Unable to connect to the server: getting credentials: exec: fork/exec /usr/lib/google-cloud-sdk/bin/gke-gcloud-auth-plugin: no such file or directory

이 문제를 해결하려면 필요한 플러그인 설치에 설명된 대로 gke-gcloud-auth-plugin을 설치합니다.

오류: 인증 제공업체를 찾을 수 없음

kubectl 또는 커스텀 Kubernetes 클라이언트가 Kubernetes client-go 버전 1.26 이상으로 빌드된 경우 다음 오류가 발생합니다.

no Auth Provider found for name "gcp"

이 문제를 해결하려면 다음 단계를 완료하시기 바랍니다.

1. 필수 플러그인 설치에 설명된 대로 gke-gcloud-auth-plugin을 설치합니다.

2. gcloud CLI를 최신 버전으로 업데이트합니다.

   gcloud components update
   

3. kubeconfig 파일을 업데이트합니다.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

   다음을 바꿉니다.

   • CLUSTER_NAME: 클러스터 이름
   • CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.

오류: gcp 인증 플러그인은 지원 중단되었습니다. 대신 gcloud를 사용하세요.

gke-gcloud-auth-plugin을 설치하고 GKE 클러스터에 kubectl 명령어를 실행한 후 다음 경고 메시지가 표시될 수 있습니다.

WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.

이 메시지는 클라이언트 버전이 1.26 이전이면 나타납니다.

이 문제를 해결하려면 대신 gke-gcloud-auth-plugin 인증 플러그인을 사용하도록 클라이언트에 지시합니다.

1. 텍스트 편집기에서 셸 로그인 스크립트를 엽니다.

   Bash

   vi ~/.bashrc

   Zsh

   vi ~/.zshrc

   PowerShell을 사용하는 경우 이 단계를 건너뜁니다.

2. 다음 환경 변수를 설정합니다.

   Bash

   export USE_GKE_GCLOUD_AUTH_PLUGIN=True
   

   Zsh

   export USE_GKE_GCLOUD_AUTH_PLUGIN=True
   

   PowerShell

   [Environment]::SetEnvironmentVariable('USE_GKE_GCLOUD_AUTH_PLUGIN', True, 'Machine')
   

3. 사용자 환경에서 변수를 적용합니다.

   Bash

   source ~/.bashrc

   Zsh

   source ~/.zshrc
   

   PowerShell

   터미널을 종료하고 새 터미널 세션을 엽니다.

4. gcloud CLI 업데이트

   gcloud components update
   

5. 클러스터를 인증합니다.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

   다음을 바꿉니다.

   • CLUSTER_NAME: 클러스터 이름
   • CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.

문제: kubectl 명령어를 찾을 수 없음

kubectl 명령어를 찾을 수 없다는 메시지가 표시되면 kubectl 바이너리를 다시 설치하고 $PATH 환경 변수를 설정합니다.

1. kubectl 바이너리를 설치합니다.

   gcloud components update kubectl
   

2. 설치 프로그램에서 $PATH 환경 변수를 수정하라는 메시지가 표시되면 y를 입력하여 계속합니다. 이 변수를 수정하면 전체 경로를 입력하지 않고도 kubectl 명령어를 사용할 수 있습니다.

   또는 셸이 환경 변수를 저장하는 위치(예: ~/.bashrc(macOS에서는 ~/.bash_profile))에 다음 줄을 추가합니다.

   export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/
   

3. 다음 명령어를 실행하여 업데이트된 파일을 로드합니다. 다음 예시는 .bashrc를 사용합니다.

   source ~/.bashrc
   

   macOS를 사용하는 경우 .bashrc 대신 ~/.bash_profile을 사용하세요.

문제: kubectl 명령어가 'connection refused' 오류 반환

kubectl 명령어가 "연결 거부됨" 오류를 반환하면 다음 명령어를 사용하여 클러스터 컨텍스트를 설정해야 합니다.

gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION

다음을 바꿉니다.

• CLUSTER_NAME: 클러스터 이름입니다.
• CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.

클러스터 이름이나 위치를 모르겠으면 다음 명령어를 사용하여 클러스터를 나열합니다.

gcloud container clusters list

오류: kubectl 명령어의 시간 초과됨

클러스터를 만들고 클러스터에 kubectl 명령어를 실행하려 했지만 kubectl 명령어 시간 초과가 발생하는 경우 다음과 유사한 오류가 표시됩니다.

• Unable to connect to the server: dial tcp IP_ADDRESS: connect: connection timed out
• Unable to connect to the server: dial tcp IP_ADDRESS: i/o timeout.

이러한 오류는 kubectl이 클러스터 컨트롤 플레인과 통신할 수 없음을 나타냅니다.

이 문제를 해결하려면 클러스터가 설정된 컨텍스트를 확인 및 설정하고 클러스터에 대한 연결을 확인하세요.

1. $HOME/.kube/config로 이동하거나 kubectl config view 명령어를 실행하여 구성 파일에 클러스터 컨텍스트 및 컨트롤 플레인의 외부 IP 주소가 포함되는지 확인합니다.

2. 클러스터 사용자 인증 정보를 설정합니다.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=PROJECT_ID
   

   다음을 바꿉니다.

   • CLUSTER_NAME: 클러스터 이름
   • CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.
   • PROJECT_ID: 클러스터가 생성된 프로젝트의 ID입니다.

3. 클러스터에서 승인된 네트워크를 사용 설정한 경우 기존 승인된 네트워크 목록에 연결하려는 원본 머신의 발신 IP가 포함되어 있는지 확인합니다. 콘솔에서 또는 다음 명령어를 실행하여 기존 승인된 네트워크를 찾을 수 있습니다.

   gcloud container clusters describe CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --project=PROJECT_ID \
       --format "flattened(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetwork
   sConfig.cidrBlocks[])"
   

   머신의 발신 IP가 이전 명령어 출력에 표시된 승인된 네트워크 목록에 포함되지 않았으면 다음 단계 중 하나를 수행합니다.

   • 콘솔을 사용하는 경우 외부 엔드포인트가 없는 클러스터의 컨트롤 플레인에 연결할 수 없음의 안내를 따릅니다.
   • Cloud Shell에서 연결하는 경우 Cloud Shell을 사용하여 외부 엔드포인트가 사용 중지된 클러스터에 액세스의 안내를 따릅니다.

오류: kubectl 명령어가 api 버전 협상 실패를 반환함

kubectl 명령어가 failed to negotiate an API version 오류를 반환하면 kubectl에 인증 사용자 인증 정보가 있는지 확인해야 합니다.

gcloud auth application-default login

문제: kubectl logs, attach, exec, port-forward 명령어가 응답하지 않음

kubectl logs, attach, exec 또는 port-forward 명령어에서 응답을 중지하면 일반적으로 API 서버가 노드와 통신할 수 없습니다.

먼저 클러스터에 노드가 있는지 확인합니다. 클러스터의 노드 수를 0으로 줄이면 명령어가 작동하지 않습니다. 이 문제를 해결하려면 적어도 노드가 하나가 되도록 클러스터의 크기를 조절합니다.

클러스터에 노드가 하나 이상 있으면 보안 통신을 사용 설정하기 위해 SSH 또는 Konnectivity 프록시 터널을 사용 중인지 확인합니다. 다음 섹션에서는 각 서비스와 관련된 문제 해결 단계에 대해 설명합니다.

• SSH
• Konnectivity 프록시

SSH 문제 해결

SSH를 사용하는 경우 GKE는 Compute Engine 프로젝트 메타데이터에 SSH 공개 키 파일을 저장합니다. Google 제공 이미지를 사용하는 모든 Compute Engine VM은 VM의 승인된 사용자 목록에 추가할 SSH 키를 위해 프로젝트의 공통 메타데이터와 인스턴스의 메타데이터를 정기적으로 확인합니다. 또한 GKE는 컨트롤 플레인의 IP 주소에서 클러스터의 각 노드로 SSH 액세스를 허용하는 방화벽 규칙을 Compute Engine 네트워크에 추가합니다.

다음 설정으로 인해 SSH 통신에 문제가 발생할 수 있습니다.

• 네트워크의 방화벽 규칙은 컨트롤 플레인에서 SSH 액세스를 허용하지 않습니다.

  모든 Compute Engine 네트워크는 모든 IP 주소에서 SSH 액세스를 허용하는(유효한 비공개 키 필요) default-allow-ssh라는 방화벽 규칙으로 생성됩니다. 또한 GKE는 특별히 클러스터의 컨트롤 플레인에서 클러스터의 노드로 SSH 액세스를 허용하는 gke-CLUSTER_NAME-RANDOM_CHARACTERS-ssh 형식의 SSH 규칙을 각 공개 클러스터에 삽입합니다.

  이러한 규칙 중 어느 규칙이라도 존재하지 않으면 컨트롤 플레인에서 SSH 터널을 열 수 없습니다.

  이것이 문제의 원인인지 확인하려면 구성에 해당 규칙이 포함되는지 확인합니다.

  이 문제를 해결하려면 모든 클러스터 노드에 있는 태그를 식별한 후 컨트롤 플레인의 IP 주소에서 해당 태그가 있는 VM에 대한 액세스를 허용하는 방화벽 규칙을 다시 추가하세요.

• 프로젝트의 ssh-keys 공통 메타데이터 항목이 가득 찼습니다.

  ssh-keys라는 프로젝트의 메타데이터 항목이 최대 크기 제한에 가까워지면 GKE가 SSH 터널을 열기 위해 자체 SSH 키를 추가할 수 없습니다.

  이 문제가 맞는지 확인하려면 ssh-keys 목록의 길이를 확인합니다. 선택적으로 --project 플래그를 포함해서 다음 명령어를 실행하여 프로젝트의 메타데이터를 볼 수 있습니다.

  gcloud compute project-info describe [--project=PROJECT_ID]
  

  이 문제를 해결하려면 더 이상 필요 없는 일부 SSH 키를 삭제합니다.

• 클러스터의 VM에서 ssh-keys 키로 메타데이터 필드를 설정했습니다.

  VM의 노드 에이전트는 프로젝트 전체 SSH 키보다 인스턴스별 ssh-keys를 선호합니다. 따라서 특별히 클러스터 노드에 SSH 키를 설정한 경우, 프로젝트 메타데이터에 있는 컨트롤 플레인의 SSH 키가 노드에 사용되지 않습니다.

  이 문제가 맞는지 확인하려면 gcloud compute instances describe VM_NAME을 실행하고 메타데이터에서 ssh-keys 필드를 확인합니다.

  이 문제를 해결하려면 인스턴스 메타데이터에서 인스턴스당 SSH 키를 삭제합니다.

Konnectivity 프록시 문제 해결

다음 시스템 배포를 확인하여 클러스터에 Konnectivity 프록시가 사용되는지 확인할 수 있습니다.

kubectl get deployments konnectivity-agent --namespace kube-system

클러스터에서 Konnectivity 프록시를 사용하는 경우 출력은 다음과 비슷합니다.

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
konnectivity-agent   3/3     3            3           18d

Konnectivity 프록시를 사용하고 있는지 확인한 후 Konnectivity 에이전트에 필요한 방화벽 액세스 권한이 있고 네트워크 정책이 올바르게 설정되어 있는지 확인합니다.

필수 방화벽 액세스 허용

네트워크의 방화벽 규칙이 다음 포트에 대한 액세스를 허용하는지 확인합니다.

• 컨트롤 플레인 포트: 클러스터를 만들면 Konnectivity 에이전트가 포트 8132에서 컨트롤 플레인에 연결을 설정합니다. kubectl 명령어를 실행하면 API 서버가 이 연결을 사용해서 클러스터와 통신합니다. 포트 8132에서 클러스터 컨트롤 플레인에 대한 이그레스 트래픽을 허용해야 합니다 (비교를 위해 API 서버에는 443이 사용됨). 이그레스 액세스를 거부하는 규칙이 있는 경우 규칙을 수정하거나 예외를 만들어야 할 수 있습니다.

• kubelet 포트: Konnectivity 에이전트는 클러스터 노드에 배포된 시스템 포드이므로 방화벽 규칙에서 다음 유형의 트래픽을 허용하는지 확인합니다.

  • 포드 범위에서 포트 10250의 워크로드로 들어오는 트래픽
  • 포드 범위에서 나가는 트래픽입니다.

  방화벽 규칙이 이러한 유형의 트래픽을 허용하지 않는 경우 규칙을 수정합니다.

네트워크 정책 조정

클러스터의 네트워크 정책이 다음 중 하나를 수행하는 경우 Konnectivity 프록시에 문제가 있을 수 있습니다.

• kube-system 네임스페이스에서 workload 네임스페이스로 인그레스를 차단합니다.
• 포트 8132에서 클러스터 컨트롤 플레인으로의 이그레스를 차단합니다.

워크로드 포드의 네트워크 정책에 의해 인그레스가 차단되면 konnectivity-agent 로그에 다음과 유사한 오류 메시지가 포함됩니다.

"error dialing backend" error="dial tcp POD_IP_ADDRESS:PORT: i/o timeout"

오류 메시지에서 POD_IP_ADDRESS은 워크로드 포드의 IP 주소입니다.

네트워크 정책에 의해 이그레스가 차단되면 konnectivity-agent 로그에 다음과 유사한 오류 메시지가 포함됩니다.

"cannot connect once" err="rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp CP_IP_ADDRESS:8132: i/o timeout

오류에서 CP_IP_ADDRESS는 클러스터 컨트롤 플레인의 IP 주소입니다.

이러한 기능은 클러스터의 정상 작동에 필요하지 않습니다. 클러스터의 네트워크를 모든 외부 액세스로부터 잠그려고 하면 이러한 기능이 작동하지 않습니다.

네트워크 정책 인그레스 또는 이그레스 규칙이 문제의 원인인지 확인하려면 다음 명령어를 실행하여 영향을 받는 네임스페이스에서 네트워크 정책을 찾습니다.

kubectl get networkpolicy --namespace AFFECTED_NAMESPACE

인그레스 정책 문제를 해결하려면 네트워크 정책의 spec.ingress 필드에 다음을 추가합니다.

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
    podSelector:
      matchLabels:
        k8s-app: konnectivity-agent

이그레스 정책 문제를 해결하려면 네트워크 정책의 spec.egress 필드에 다음을 추가합니다.

egress:
- to:
  - ipBlock:
      cidr: CP_IP_ADDRESS/32
  ports:
  - protocol: TCP
    port: 8132

네트워크 정책에서 인그레스 및 이그레스 규칙을 함께 사용하는 경우 두 규칙을 모두 조정하는 것이 좋습니다.

IP 매스커레이드 에이전트 조정

소스 IP 주소가 Pod IP 주소 범위에 있으면 클러스터 제어 영역은 Konnectivity 에이전트의 트래픽을 허용합니다. 클러스터 컨트롤 플레인으로 향하는 트래픽의 소스 IP 주소를 매스커레이드하도록 ip-masq-agent의 구성을 수정하면 Konnectivity 에이전트에서 연결 오류가 발생할 수 있습니다.

이 문제를 해결하고 Konnectivity 에이전트에서 클러스터 컨트롤 플레인으로 전송되는 트래픽이 노드 IP 주소로 매스커레이드되지 않도록 하려면 ip-masq-agent ConfigMap의 nonMasqueradeCIDRs 목록에 컨트롤 플레인 IP 주소를 추가하세요.

nonMasqueradeCIDRs:
- CONTROL_PLANE_IP_ADDRESS/32

이 구성에 대한 자세한 내용은 IP 매스커레이드 에이전트를 참고하세요.

오류: kubectl 명령어에 에이전트 사용 불가 오류가 발생함

GKE 컨트롤 플레인에서 포드로 연결해야 하는 kubectl 명령어(예: kubectl exec, kubectl logs, kubectl port-forward)를 실행하면 다음과 유사한 오류 메시지와 함께 명령어가 실패할 수 있습니다.

Error from server: error dialing backend: No agent available

failed to call webhook: Post "https://WEBHOOK_SERVICE.WEBHOOK_NAMESPACE.svc:PORT/PATH?timeout=10s": No agent available

v1beta1.metrics.k8s.io failed with: failing or missing response from https://NODE_IP:10250/apis/metrics.k8s.io/v1beta1: Get "https://NODE_IP:10250/apis/metrics.k8s.io/v1beta1": No agent available

이러한 오류는 GKE 컨트롤 플레인과 클러스터 노드 간의 보안 통신 터널인 Konnectivity에 문제가 있음을 나타냅니다. 특히 컨트롤 플레인의 konnectivity-server가 kube-system 네임스페이스의 정상 konnectivity-agent 포드에 연결할 수 없음을 의미합니다.

이 문제를 해결하려면 다음 솔루션을 시도해 보세요.

1. konnectivity-agent 포드의 상태를 확인합니다.

   1. konnectivity-agent 포드가 실행 중인지 확인합니다.

      kubectl get pods -n kube-system -l k8s-app=konnectivity-agent
      

      출력은 다음과 비슷합니다.

      NAME                                   READY   STATUS    RESTARTS  AGE
      konnectivity-agent-abc123def4-xsy1a    2/2     Running   0         31d
      konnectivity-agent-abc123def4-yza2b    2/2     Running   0         31d
      konnectivity-agent-abc123def4-zxb3c    2/2     Running   0         31d
      

      Status 열의 값을 검토합니다. 포드 상태가 Running인 경우 연결 문제에 관한 로그를 검토합니다. 그렇지 않으면 포드가 실행되지 않는 이유를 조사합니다.

   2. 연결 문제 로그 검토 포드 상태가 Running인 경우 연결 문제에 관한 로그를 확인합니다. kubectl logs 명령어가 Konnectivity에 종속되므로Google Cloud 콘솔에서 로그 탐색기를 사용하세요.

      1. Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

         로그 탐색기로 이동

      2. 쿼리 창에 다음 쿼리를 입력합니다.

         resource.type="k8s_container"
         resource.labels.cluster_name="CLUSTER_NAME"
         resource.labels.namespace_name="kube-system"
         labels."k8s-pod/k8s-app"="konnectivity-agent"
         resource.labels.container_name="konnectivity-agent"
         

         CLUSTER_NAME을 클러스터 이름으로 바꿉니다.

      3. 쿼리 실행을 클릭합니다.

      4. 출력을 검토합니다. konnectivity-agent 로그를 검토할 때 에이전트가 연결할 수 없는 이유를 나타내는 오류를 찾습니다. 인증 또는 권한 오류는 토큰 검토를 차단하는 잘못 구성된 웹훅을 나타내는 경우가 많습니다. '연결 거부됨' 또는 '시간 초과' 오류는 일반적으로 방화벽 규칙 또는 네트워크 정책이 TCP 포트 8132의 컨트롤 플레인으로 전송되는 트래픽을 차단하거나 Konnectivity 에이전트와 다른 노드 간의 트래픽을 차단함을 의미합니다. 인증서 오류는 방화벽 또는 프록시가 암호화된 TLS 트래픽을 검사하고 방해하고 있음을 나타냅니다.

   3. 포드가 실행되지 않는 이유를 조사합니다. 포드의 상태가 Pending이거나 실행되지 않는 다른 상태인 경우 원인을 조사합니다. konnectivity-agent가 DaemonSet이 아닌 Deployment로 실행됩니다. 배포로 실행되므로 에이전트 포드는 노드의 하위 집합에서만 실행하면 됩니다. 하지만 특정 노드 하위 집합을 사용할 수 없으면 전체 서비스가 실패할 수 있습니다.

      포드가 실행되지 않는 일반적인 원인은 다음과 같습니다.

      • 포드가 예약되지 않도록 하는 맞춤 노드 taint입니다.
      • 노드 리소스 (CPU 또는 메모리)가 부족합니다.
      • GKE 시스템 이미지를 차단하는 제한적인 Binary Authorization 정책

      특정 포드가 실행되지 않는 이유에 대한 자세한 내용을 알아보려면 kubectl describe 명령어를 사용하세요.

      kubectl describe pod POD_NAME -n kube-system
      

      POD_NAME을 실행되지 않는 포드의 이름으로 바꿉니다.

2. 어드미션 웹훅을 조사하여 TokenReview API 요청을 차단하는 웹훅이 없는지 확인하세요. konnectivity-agent는 서비스 계정 토큰을 사용하므로 토큰 검토를 방해하면 에이전트가 연결되지 않을 수 있습니다. 웹훅이 원인인 경우 결함이 있는 웹훅이 삭제되거나 복구될 때까지 Konnectivity가 복구될 수 없습니다.

3. 방화벽 규칙이 포트 8132에서 GKE 노드에서 컨트롤 플레인의 IP 주소로 TCP 이그레스 트래픽을 허용하는지 확인합니다. 이 연결은 konnectivity-agent가 Konnectivity 서비스에 도달하는 데 필요합니다. 자세한 내용은 필수 방화벽 액세스 허용을 참고하세요.

4. 필수 Konnectivity 트래픽을 제한하는 네트워크 정책 규칙이 없는지 확인합니다. 네트워크 정책 규칙은 kube-system 네임스페이스 내의 클러스터 내 트래픽 (포드 간)과 konnectivity-agent 포드에서 GKE 컨트롤 플레인으로의 이그레스 트래픽을 모두 허용해야 합니다.

다음 단계

• 문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.

  • Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
  • StackOverflow에서 질문하고 google-kubernetes-engine 태그를 사용하여 유사한 문제를 검색해 커뮤니티의 지원을 받습니다. #kubernetes-engine Slack 채널에 가입하여 더 많은 커뮤니티 지원을 받을 수도 있습니다.
  • 공개 Issue Tracker를 사용하여 버그나 기능 요청을 엽니다.