이 페이지는 클라우드 인프라를 설정, 모니터링, 관리하려는 IT 관리자와 운영자를 위해 작성되었습니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.
Kubernetes 구성 파일
Kubernetes는 kubeconfig라는 YAML 파일을 사용하여 kubectl의 클러스터 인증 정보를 저장합니다. kubeconfig에는 명령어를 실행할 때 kubectl이 참조하는 컨텍스트 목록이 포함됩니다. 기본적으로 파일은 $HOME/.kube/config에 저장됩니다.
컨텍스트는 액세스 매개변수 그룹입니다. 각 컨텍스트에는 Kubernetes 클러스터, 사용자, 네임스페이스가 포함되어 있습니다. 현재 컨텍스트는 현재 kubectl의 기본값인 클러스터입니다. 모든 kubectl 명령어가 이 클러스터를 대상으로 실행됩니다.
클러스터를 만든 후 kubeconfig 항목 생성에 따라 클러스터 컨텍스트를 로컬 kubeconfig에 추가합니다.
비공개 엔드포인트
모든 클러스터에는 Standard 엔드포인트가 있습니다. 이 엔드포인트는 kubectl 및 기타 서비스가 TCP 포트 443을 통해 클러스터 컨트롤 플레인과 통신하기 위해 사용하는 Kubernetes API 서버를 노출합니다. Azure에서 이 엔드포인트는 내부 대면 부하 분산기에서 지원되는 단일 비공개 IP입니다(예: 10.0.1.5). 이 엔드포인트는 공개 인터넷에서 액세스할 수 없습니다. gcloud container azure clusters describe 명령어 결과의 endpoint 필드에서 비공개 클러스터 엔드포인트 주소를 가져올 수 있습니다.
Connect 게이트웨이 엔드포인트
기본적으로 gcloud container azure clusters get-credentials 명령어는 Connect 게이트웨이를 사용하는 kubeconfig를 생성합니다. 이 kubeconfig와 함께 kubectl은 Connect를 사용해서 트래픽을 사용자 대신 비공개 엔드포인트로 안전하게 전달합니다. Connect 게이트웨이를 사용할 때 엔드포인트는 https://connectgateway.googleapis.com/v1/projects/PROJECT_NUMBER/memberships/CLUSTER_NAME과 비슷하게 표시됩니다. 여기서 PROJECT_NUMBER는 프로젝트 번호이고 CLUSTER_NAME은 클러스터 이름입니다.
모든 Azure용 GKE는 kubectl이 제공한 사용자 인증 정보를 검증하고 사용자 또는 서비스 계정 ID에 연결된 이메일 주소를 검색하여 Google Cloud사용자 및 서비스 계정 ID를 수락하도록 구성됩니다. 따라서 이러한 계정의 사용자 인증 정보에 userinfo.email OAuth 범위가 포함되어야 인증이 성공합니다.
gcloud를 사용하여 신규 또는 기존 클러스터에 대해 환경의 kubeconfig를 설정하는 경우 gcloud가 gcloud 자체에 사용된 것과 동일한 사용자 인증 정보를 kubectl에 제공합니다. 예를 들어 gcloud auth login을 사용하는 경우 개인의 사용자 인증 정보가 kubectl에 제공되며 userinfo.email 범위가 포함됩니다. 따라서 Azure용 GKE는 kubectl 클라이언트를 인증할 수 있습니다.
사용자 또는 Google Cloud 서비스 계정은 인증 후에도 승인 과정도 거쳐야 Azure용 GKE에서 작업을 수행할 수 있습니다. 클러스터 관리자는 승인을 구성하기 위해 적절한 역할 기반 액세스 제어를 설정해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-07(UTC)"],[],[],null,["# About Kubeconfig\n================\n\nThis page is for IT administrators and Operators who want to set up,\nmonitor, and manage cloud infrastructure. To learn more about common roles and\nexample tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nKubernetes configuration file\n-----------------------------\n\nKubernetes uses a YAML file called\n[`kubeconfig`](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)\nto store cluster authentication information for `kubectl`. `kubeconfig` contains\na list of contexts to which `kubectl` refers when running commands. By default,\nthe file is saved at `$HOME/.kube/config`.\n\nA *context* is a group of access parameters. Each context contains a Kubernetes\ncluster, a user, and a namespace. The *current context* is the cluster that is\ncurrently the default for `kubectl`: all `kubectl` commands run against that\ncluster.\n\nAfter you create a cluster, follow\n[Generate a `kubeconfig` entry](/kubernetes-engine/multi-cloud/docs/azure/how-to/configure-cluster-access-for-kubectl#generate_kubeconfig_entry)\nto add the context of the cluster to your local `kubeconfig`.\n\nPrivate endpoints\n-----------------\n\nAll clusters have a canonical endpoint. The endpoint exposes the\nKubernetes API server that `kubectl` and other services use to communicate with\nyour cluster control plane over TCP port 443. On Azure, this endpoint\nis a\nsingle private IP backed by an internal-facing\nload balancer--- for example `10.0.1.5`. This endpoint is not\naccessible on the public internet. You can get the private cluster endpoint\naddress from the `endpoint` field in the output of the\n[`gcloud container azure clusters describe`](/sdk/gcloud/reference/container/azure/clusters/describe)\ncommand.\n\n### Connect gateway endpoint\n\nBy default, the `gcloud container azure clusters get-credentials` command\ngenerates a `kubeconfig` that uses\n[Connect gateway](/anthos/multicluster-management/gateway). With this\n`kubeconfig`, `kubectl` uses Connect, which then securely forwards the\ntraffic to the private endpoint on your behalf. When you use Connect gateway,\nthe endpoint looks like\n`https://connectgateway.googleapis.com/v1/projects/`\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`/memberships/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e,\nwhere \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e is your project number and\n\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e is your cluster name.\n\nIf you have access to your cluster's private endpoint through your\nVNet, you can connect directly to the private endpoint. To\ngenerate a `kubeconfig` using the private endpoint, use the\n[`gcloud container azure clusters get-credentials --private-endpoint`](/kubernetes-engine/multi-cloud/docs/azure/how-to/configure-cluster-access-for-kubectl#private-endpoint)\ncommand.\n\nAbout authentication for `kubectl`\n----------------------------------\n\nAll GKE on Azure are configured to accept Google Cloud\nuser and service account identities, by validating the credentials presented by\n`kubectl` and retrieving the email address associated with the user or service\naccount identity. As a result, the credentials for those accounts must include\nthe `userinfo.email` OAuth scope in order to successfully authenticate.\n\nWhen you use `gcloud` to set up your environment's `kubeconfig` for a\nnew or existing cluster, `gcloud`\ngives `kubectl` the same credentials used by `gcloud` itself. For example, if\nyou use `gcloud auth login`, your personal credentials are provided to\n`kubectl`, including the `userinfo.email` scope. This allows the\nGKE on Azure to authenticate the `kubectl` client.\n\nOnce users or Google Cloud service accounts are authenticated, they must\nalso be *authorized* to perform any action on a GKE on Azure. The\ncluster admin is responsible for setting up the appropriate\n[Role-Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\nto configure authorization."]]
