Google Distributed Cloud는 인증서와 비공개 키를 사용하여 관리자 클러스터의 Kubernetes 시스템 구성요소 간의 통신을 인증합니다. 관리자 클러스터를 만들면 새 인증 기관(CA) 인증서가 생성되며 이러한 루트 인증서는 Kubernetes 시스템 구성요소에 대한 추가 리프 인증서를 발급하는 데 사용됩니다.
이 가이드는 관리자 클러스터 CA 인증서 순환에만 적용됩니다. 사용자 클러스터의 경우 사용자 클러스터 CA 인증서 순환을 참조하세요.
관리자 클러스터의 Kubernetes 시스템에서 사용하는 3가지 CA 인증서가 있습니다.
etcd CA 인증서는 Kubernetes API 서버에서 etcd 복제본으로의 통신과 etcd 복제본 간 통신도 보호합니다. 이 인증서는 자체 서명됩니다.
클러스터 CA 인증서는 Kubernetes API 서버와 모든 내부 Kubernetes API 클라이언트(예: kubelet, 컨트롤러 관리자, 스케줄러) 간의 통신을 보호합니다. 이 인증서는 자체 서명됩니다.
프런트 프록시 CA 인증서는 집계된 API와의 통신을 보호합니다.
이 인증서는 자체 서명됩니다.
gkectl을 사용하여 인증서 순환을 트리거할 수 있습니다. 순환 중에 gkectl은 관리자 클러스터의 핵심 시스템 CA 인증서를 새로 생성된 인증서로 바꿉니다. 그런 다음 새 CA 인증서, 리프 인증서, 비공개 키를 관리자 클러스터 시스템 구성요소에 배포합니다. 순환이 증분적으로 발생하므로 순환 중에도 시스템 구성요소가 계속 통신할 수 있습니다. 그러나 워크로드와 노드는 순환 중에 다시 시작됩니다.
순환이 없으면 CA 인증서 및 컨트롤 플레인 인증서가 클러스터가 생성된 날로부터 5년 후에 만료됩니다. 컨트롤 플레인 인증서는 클러스터 업그레이드 중에 자동으로 순환되지만 CA는 자동으로 순환되지 않습니다. 즉, 일반 버전 업그레이드 외에도 최소 5년마다 한 번씩 CA 순환을 수행해야 합니다.
제한사항
CA 인증서 순환은 이전에 언급된 etcd, 클러스터, 프런트 프록시 인증서로 제한됩니다.
CA 인증서 순환은 Google Distributed Cloud에서 자동으로 발급한 인증서로 제한됩니다. 해당 인증서가 시스템 CA에서 서명된 경우에도 관리자가 수동으로 발급한 인증서는 업데이트하지 않습니다.
CA 인증서 순환은 Kubernetes API 서버, 기타 컨트롤 플레인 프로세스 및 관리자 클러스터의 각 노드를 여러 번 다시 시작합니다.
순환의 각 단계는 클러스터 업그레이드와 비슷하게 진행됩니다. 관리자 클러스터에서 관리하는 관리자 클러스터와 사용자 클러스터는 인증서 순환 중에 계속 작동하지만 관리자 클러스터의 워크로드가 다시 시작되고 다시 예약됩니다. 관리자 클러스터 컨트롤 플레인과 사용자 클러스터 컨트롤 플레인에도 짧은 기간 동안 다운타임이 발생할 수 있습니다.
인증서 순환 도중, 그리고 관리자 순환이 완료된 후에 관리자 클러스터 kubeconfig 파일을 업데이트해야 합니다. 이전 클러스터 인증서가 취소되고 kubeconfig 파일의 사용자 인증 정보가 더 이상 작동하지 않기 때문입니다.
CA 인증서 순환을 시작한 후에는 롤백할 수 없습니다.
CA 인증서 순환은 클러스터의 크기에 따라 완료하는 데 상당한 시간이 걸릴 수 있습니다.
중단된 경우 동일한 명령어를 다시 실행하면 인증서 순환 프로세스를 재개할 수 있습니다. 하지만 한 번에 순환 명령어 하나만 실행되는지 확인해야 합니다.
순환 시작
인증서 순환을 시작하려면 다음 명령어를 실행합니다. 순환의 전반부를 수행하고 일시중지 지점에서 중지됩니다.
ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
명령어가 중단되면 동일한 명령어를 실행하여 재개합니다.
kubeconfig 파일 업데이트
앞의 명령어가 일시중지되면 관리자 클러스터의 kubeconfig 파일을 업데이트합니다. 그러면 새 클라이언트 인증서와 새 CA 인증서가 kubeconfig 파일에 배치됩니다. 이전 클라이언트 인증서는 kubeconfig 파일에서 삭제되고 이전 CA 인증서는 kubeconfig 파일에 유지됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-11-22(UTC)"],[],[],null,["Google Distributed Cloud use certificates and private keys to authenticate\ncommunication between Kubernetes system components in an admin cluster. When you\ncreate an admin cluster, new certificate authority (CA) certificates are created,\nand these root certificates are used to issue additional leaf certificates for\nKubernetes system components.\n\nThis guide applies only to rotation of admin cluster CA certificates. For\nuser clusters, see\n[Rotating user cluster CA certificates](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/ca-rotation).\n\nThere are three CA certificates used by the Kubernetes system in an admin\ncluster:\n\n- The etcd CA certificate secures communication from the Kubernetes API server\n to the etcd replicas and also communication between etcd replicas. This\n certificate is self-signed.\n\n- The cluster CA certificate secures communication between the Kubernetes API\n server and all internal Kubernetes API clients, for example, the kubelet, the\n controller manager, and the scheduler. This certificate is self-signed.\n\n- The front-proxy CA certificate secures communication with\n [aggregated APIs](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).\n This certificate is self-signed.\n\nYou can use `gkectl` to trigger a certificate rotation. During a rotation,\n`gkectl` replaces the core system CA certificates for the\nadmin cluster with newly generated certificates. Then it distributes the new\nCA certificates, leaf certificates, and private keys to admin cluster system\ncomponents. The rotation happens incrementally, so that system components can\ncontinue to communicate during the rotation. Note, however, that workloads and\nnodes are restarted during the rotation.\n\nWithout rotation, CA certificates and control-plane certificates will expire\nfive years from the date the cluster was created. The control plane certificates\nare automatically rotated during a cluster upgrade, but the CAs are\nnot automatically rotated. This means a CA rotation must be performed at least\nonce every five years, in addition to regular version upgrades.\n| **Warning:** A CA certificate rotation revokes the old CA certificates at the end of the operation. This invalidates kubeconfig files that were based on an old certificate. Consequently, the credentials in the kubeconfig file stop working after a CA certificate rotation. This guide includes instructions on how to update your kubeconfig file. The same issue applies to authentication configuration files.\n\nLimitations\n\n- Note the following limitation with advanced clusters:\n\n - Version 1.31: CA rotation isn't supported on [advanced clusters](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#enable-advanced-cluster-field).\n - Version 1.32 and higher: CA rotation is supported on advanced clusters but there are some minor differences noted where applicable in this document.\n- CA certificate rotation limited to the etcd, cluster, and front-proxy\n certificates mentioned previously.\n\n- CA certificate rotation is limited to certificates issued automatically by\n Google Distributed Cloud. It does not update certificates issued manually by an\n administrator, even if those certificates are signed by the system CAs.\n\n- CA certificate rotation restarts the Kubernetes API server, other\n control-plane processes, and each node in the admin cluster multiple times.\n Each stage of a rotation progresses similarly to a cluster upgrade. While the\n admin cluster and the user clusters managed by the admin cluster do remain\n operational during a certificate rotation, you should expect that workloads\n in the admin cluster will be restarted and rescheduled. You should also expect\n brief periods of downtime for the admin cluster control plane and user cluster\n control plane.\n\n- You must update the admin cluster kubeconfig file in the middle of a\n certificate rotation and again after the rotation completes. This is because\n the old cluster certificate is revoked, and the credentials in the kubeconfig\n file will no longer work.\n\n- Once initiated, a CA certificate rotation cannot be rolled back.\n\n- A CA certificate rotation might take considerable time to complete, depending\n on the size of the cluster.\n\n- The certificate rotation process can be resumed by re-running the same\n command if it is interrupted. However, you must ensure that there is only one\n rotation command running at a time.\n\nStart the rotation\n\nTo start the certificate rotation, run the following command:\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_CONFIG\u003c/var\u003e: the path of the admin cluster configuration\n file\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e: the path of the admin cluster kubeconfig\n file\n\nThe behavior of the command differs depending on whether advanced cluster\nis enabled: \n\nNot enabled\n\nThe `gkectl update credentials certificate-authorities rotate` command starts\nand performs the first half of the rotation. The command then pauses to let\nyou run the next command to update the kubeconfig file.\n\nUpdate the kubeconfig file\n\nWhen the `gkectl update credentials certificate-authorities rotate` command\npauses, update the kubeconfig file for the admin cluster. This places a new\nclient certificate and a new CA certificate in the kubeconfig file. The old\nclient certificate is removed from the kubeconfig file, and the old CA\ncertificate remains in the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nContinue the rotation\n\nRun the following command to perform the second half of the procedure. The\ncommand doesn't proceed until `gkectl` verifies that the updated kubeconfig\nfile is in the current directory.\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --complete \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nWhen the rotation is complete, it reports the current CA version.\n\nUpdate the kubeconfig file again\n\nAfter the second half of the rotation completes, update the kubeconfig file\nagain. This removes the old CA certificate from the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nEnabled\n\nIf advanced cluster is enabled, the `gkectl update credentials\ncertificate-authorities rotate` command is synchronous. The command outputs\nstatus messages to the admin workstation as the CA rotation progresses.\n\nAfter the CA is rotated successfully, the command exits and a new kubeconfig\nfile is automatically generated. The kubeconfig file that you specified in the\ncommand is replaced with a new one. The command output is similar to the\nfollowing:\n\n```\nBeginning CA rotation with generated CA\n...\nSuccessfully rotated CA for admin cluster. The kubeconfig file\n\"/home/ubuntu/kubeconfig\" has been updated.\nDone rotating certificate-authorities\n```\n\nDistribute the new kubeconfig file\n\nDistribute the new admin cluster kubeconfig file to all cluster users."]]
