diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index dbb30150e3..d39559e24c 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 ## 업데이트 전략 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 +스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 -구성하거나 비활성화 할 수 있다. +구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다. -### 삭제 시(On Delete) - -`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 -`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 -스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 +`OnDelete`(삭제시) +: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, +스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. +사용자는 컨트롤러가 스테이트풀셋의 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다. -### 롤링 업데이트 +`RollingUpdate`(롤링 업데이트) +: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 +구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. -`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 -구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 -스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 -순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), -각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 -때까지 기다린다. +## 롤링 업데이트 -#### 파티션(Partition) +스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 +스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이 +순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로), +각 파드의 업데이트는 한 번에 하나씩 한다. + +쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다. +`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다. + +### 파티션 롤링 업데이트 {#partitions} `롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` 를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 @@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다. -#### 강제 롤백 +### 강제 롤백 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 @@ -273,8 +277,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 실행하려고 시도한 모든 파드를 삭제해야 한다. -그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다. +그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다. +### 최소 준비 시간 초 {#minimum-ready-seconds} + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 +컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다. +기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다). +파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면, +[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다. + +이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 22b98b705c..54fdf4a9a2 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -257,8 +257,12 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 ## 컨테이너에 대한 특권 모드 -파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다. -특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다. +리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다. +클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다. + +파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다. + +HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다. {{< note >}} 이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다. @@ -282,6 +286,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만, 여기에서 제어할 수는 없다는 의미이다. +## 컨테이너 프로브 + +_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다. + +- `ExecAction` (컨테이너 런타임의 도움을 받아 수행) +- `TCPSocketAction` (kubelet에 의해 직접 검사) +- `HTTPGetAction` (kubelet에 의해 직접 검사) + +[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은 +파드 라이프사이클 문서를 참고한다. + ## {{% heading "whatsnext" %}} * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다. diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 9aa9e9bf51..136413b88f 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -6,15 +6,15 @@ weight: 80 -{{< feature-state state="alpha" for_k8s_version="v1.16" >}} +{{< feature-state state="alpha" for_k8s_version="v1.22" >}} -이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 -트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 -임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 -컨테이너를 사용한다. +이 페이지는 임시 컨테이너에 대한 개요를 제공한다. +이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 +기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다. +임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다. {{< warning >}} -임시 컨테이너는 초기 알파 상태이며, +임시 컨테이너 기능은 알파 상태이며, 프로덕션 클러스터에는 적합하지 않다. [쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. @@ -72,119 +72,8 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 임시 컨테이너 사용 시 [프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 -활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다. +활성화하면 다른 컨테이너 안의 프로세스를 보는 데 도움이 된다. -임시 컨테이너를 사용해서 문제를 해결하는 예시는 -[임시 디버깅 컨테이너로 디버깅하기] -(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다. +## {{% heading "whatsnext" %}} -## 임시 컨테이너 API - -{{< note >}} -이 섹션의 예시는 `EphemeralContainers` [기능 -게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 -활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다. -{{< /note >}} - -이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지 -보여준다. 일반적으로 `kubectl debug` 또는 -다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을 -사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다. - -임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 -사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 -`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다. - -```json -{ - "apiVersion": "v1", - "kind": "EphemeralContainers", - "metadata": { - "name": "example-pod" - }, - "ephemeralContainers": [{ - "command": [ - "sh" - ], - "image": "busybox", - "imagePullPolicy": "IfNotPresent", - "name": "debugger", - "stdin": true, - "tty": true, - "terminationMessagePolicy": "File" - }] -} -``` - -이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다. - -```shell -kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json -``` - -그러면 새로운 임시 컨테이너 목록이 반환된다. - -```json -{ - "kind":"EphemeralContainers", - "apiVersion":"v1", - "metadata":{ - "name":"example-pod", - "namespace":"default", - "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers", - "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c", - "resourceVersion":"15886", - "creationTimestamp":"2019-08-29T06:41:42Z" - }, - "ephemeralContainers":[ - { - "name":"debugger", - "image":"busybox", - "command":[ - "sh" - ], - "resources":{ - - }, - "terminationMessagePolicy":"File", - "imagePullPolicy":"IfNotPresent", - "stdin":true, - "tty":true - } - ] -} -``` - -사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다. - -```shell -kubectl describe pod example-pod -``` - -``` -... -Ephemeral Containers: - debugger: - Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f - Image: busybox - Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70 - Port: - Host Port: - Command: - sh - State: Running - Started: Thu, 29 Aug 2019 06:42:21 +0000 - Ready: False - Restart Count: 0 - Environment: - Mounts: -... -``` - -예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서 -다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와 -상호작용할 수 있다. - -```shell -kubectl attach -it example-pod -c debugger -``` +* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기. diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index c8c7055408..a1c01b17ab 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -290,8 +290,9 @@ myapp-pod 1/1 Running 0 9m 초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한 다음의 규칙이 적용된다. -* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장 - 높은 것은 *유효한 초기화 요청량/상한* 이다. +* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 + 가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는 + 이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다. * 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다. * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계 * 리소스에 대한 유효한 초기화 요청량/상한 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 11aeaa31b0..1e2754ebaf 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다. 확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료 프로세스를 시작한다. 1. 파드의 컨테이너 중 하나가 `preStop` - [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은 + [훅](/ko/docs/concepts/containers/container-lifecycle-hooks)을 정의한 경우, kubelet은 컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이 계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을 요청한다. diff --git a/content/ko/docs/contribute/generate-ref-docs/quickstart.md b/content/ko/docs/contribute/generate-ref-docs/quickstart.md index 6855696b9d..531b1ad50b 100644 --- a/content/ko/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/ko/docs/contribute/generate-ref-docs/quickstart.md @@ -6,7 +6,7 @@ weight: 40 -이 문서에서는 `update-imported-docs` 스크립트를 사용하여 +이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여 쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다. 이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다. @@ -39,7 +39,7 @@ git clone git@github.com:/website.git ## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs} -`update-imported-docs` 스크립트는 `/update-imported-docs/` +`update-imported-docs.py` 스크립트는 `/update-imported-docs/` 디렉터리에 존재한다. 이 스크립트는 다음 레퍼런스를 생성한다. @@ -48,7 +48,7 @@ git clone git@github.com:/website.git * `kubectl` 명령어 레퍼런스 * 쿠버네티스 API 레퍼런스 -`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 +`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를 생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와 `kubernetes-sigs/reference-docs` 저장소를 클론하며, @@ -69,7 +69,7 @@ git clone git@github.com:/website.git `kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다. `K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다. -`update-imported-docs` 스크립트는 다음의 과정을 수행한다. +`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다. 1. 환경설정 파일에 있는 관련 저장소를 클론한다. 레퍼런스 문서 생성을 위해 @@ -152,11 +152,11 @@ repos: ## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool} -다음과 같이 `update-imported-docs` 도구를 실행할 수 있다. +다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다. ```shell cd /update-imported-docs -./update-imported-docs +./update-imported-docs.py ``` 예를 들면 다음과 같다. @@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon * [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/) * [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/) - diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 55401988b4..8bfa706ea4 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -71,8 +71,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 제공하지 않는다. +* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) * [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) * [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) * [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) * [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/) @@ -82,6 +84,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 ## kubeadm을 위한 API 설정 * [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/) +* [v1beta3](/docs/reference/config-api/kubeadm-config.v1beta3/) ## 설계 문서 diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md index ca06783465..55615e55de 100644 --- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md @@ -57,10 +57,9 @@ weight: 50 #### 바인딩된 서비스 어카운트 토큰 볼륨 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} -`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, -토큰 컨트롤러에 의해 생성된 무기한 서비스 어카운트 토큰을 위해, 서비스 어카운트 어드미션 컨트롤러가 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. +서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. ```yaml - name: kube-api-access- @@ -91,10 +90,6 @@ weight: 50 상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다. -`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우, -위의 프로젝티드 볼륨을 파드 스펙에 추가하여 -시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다. - ### 토큰 컨트롤러 토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,