diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 4fff50dced..51bdf9d5cb 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -87,7 +87,7 @@ volumeBindingMode: Immediate 여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이 이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와 함께 제공된다). 또한, 쿠버네티스에서 정의한 -[사양](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)을 +[사양](https://git.k8s.io/design-proposals-archive/storage/volume-provisioning.md)을 따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다. 외부 프로비저너의 작성자는 코드의 수명, 프로비저너의 배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인 @@ -241,8 +241,8 @@ allowedTopologies: - matchLabelExpressions: - key: failure-domain.beta.kubernetes.io/zone values: - - us-central1-a - - us-central1-b + - us-central-1a + - us-central-1b ``` ## 파라미터 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index f6b9c9f0d2..5085ae000f 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -145,12 +145,19 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} -`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 -`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) -드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI -드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) -를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk` -기능을 활성화해야 한다. +`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, +기존 인-트리 플러그인의 모든 플러그인 작업을 +`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 +[Azure Disk CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 를 설치하고 +`CSIMigration` 및 `CSIMigrationAzureDisk` 기능을 활성화해야 한다. + +#### azureDisk CSI 마이그레이션 완료 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +컨트롤러 매니저 및 kubelet이 `azureDisk` 스토리지 플러그인을 로드하지 않도록 하려면, +`InTreePluginAzureDiskUnregister` 플래그를 `true`로 설정한다. ### azureFile {#azurefile} @@ -163,15 +170,22 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} -`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 -`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) -드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI -드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) -를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, +기존 인-트리 플러그인의 모든 플러그인 작업을 +`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 +[Azure File CSI 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) 를 설치하고 +`CSIMigration` 및 `CSIMigrationAzureFile` 기능을 활성화해야 한다. Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다. +#### azureFile CSI 마이그레이션 완료 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +컨트롤러 매니저 및 kubelet이 `azureFile` 스토리지 플러그인을 로드하지 않도록 하려면, +`InTreePluginAzureFileUnregister` 플래그를 `true`로 설정한다. + ### cephfs `cephfs` 볼륨은 기존 CephFS 볼륨을 @@ -251,7 +265,7 @@ metadata: spec: containers: - name: test - image: busybox + image: busybox:1.28 volumeMounts: - name: config-vol mountPath: /etc/config @@ -879,9 +893,7 @@ RBD CSI 드라이버로의 마이그레이션을 시도하기 전에 * 또한, 트리 내(in-tree) 스토리지클래스의 `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 `adminSecretName` 값이 `adminId` 파라미터 값의 - base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. - -{{< /note >}} + base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. {{< /note >}} ### secret @@ -1130,7 +1142,7 @@ spec: fieldRef: apiVersion: v1 fieldPath: metadata.name - image: busybox + image: busybox:1.28 command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] volumeMounts: - name: workdir1 diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 34ac547b73..ca376d9bf1 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -69,7 +69,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 # │ │ │ ┌───────────── 월 (1 - 12) # │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지; # │ │ │ │ │ 특정 시스템에서는 7도 일요일) -# │ │ │ │ │ +# │ │ │ │ │ 또는 sun, mon, tue, wed, thu, fri, sat # │ │ │ │ │ # * * * * * ``` diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 33b8812d1a..ffd07afd9a 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -76,11 +76,11 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `.spec.selector` 필드는 파드 셀렉터이다. 이것은 [잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다. -쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다. -파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다. -셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다. -또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다. -파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다. +`.spec.template`의 레이블과 매치되는 +파드 셀렉터를 명시해야 한다. +또한, 한 번 데몬셋이 만들어지면 +`.spec.selector` 는 바꿀 수 없다. +파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다. `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다. @@ -91,8 +91,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다. -만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. -일치하지 않는 구성은 API에 의해 거부된다. +`.spec.selector` 는 `.spec.template.metadata.labels` 와 일치해야 한다. +이 둘이 서로 일치하지 않는 구성은 API에 의해 거부된다. ### 오직 일부 노드에서만 파드 실행 @@ -107,7 +107,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 기본 스케줄러로 스케줄 -{{< feature-state state="stable" for-kubernetes-version="1.17" >}} +{{< feature-state for_k8s_version="1.17" state="stable" >}} 데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 440307f381..395ad1b73a 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -255,10 +255,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다. 기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지). - 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 - 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, - 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. - 이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. + 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음, + 이전 파드를 삭제하고, 또 다른 새로운 파드를 만든 것을 볼 수 있다. + 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. + 이것은 최소 3개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. + 디플로이먼트의 레플리카 크기가 4인 경우, 파드 숫자는 3개에서 5개 사이이다. * 디플로이먼트의 세부 정보 가져오기 ```shell @@ -303,13 +304,20 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 ``` - 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 - 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. - 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 - 이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다. - 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. + 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성하고 + 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. + 디플로이먼트를 업데이트하자, 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 모두 실행될 때까지 대기하였다. + 그 뒤 이전 레플리카셋을 2개로 스케일 다운하고 새 레플리카셋을 2개로 스케일 업하여 모든 시점에 대해 최소 3개 / 최대 3개의 파드가 존재하도록 하였다. + 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. 마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다. +{{< note >}} +쿠버네티스가 `availableReplicas` 수를 계산할 때 종료 중인(terminating) 파드는 포함하지 않으며, +이 수는 `replicas - maxUnavailable` 와 `replicas + maxSurge` 사이에 존재한다. +그 결과, 롤아웃 중에는 파드의 수가 예상보다 많을 수 있으며, +종료 중인 파드의 `terminationGracePeriodSeconds`가 만료될 때까지는 디플로이먼트가 소비하는 총 리소스가 `replicas + maxSurge` 이상일 수 있다. +{{< /note >}} + ### 롤오버(일명 인-플라이트 다중 업데이트) 디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 06ce527869..d2bdf00d7e 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -308,7 +308,7 @@ spec: ### 완료된 잡을 위한 TTL 메커니즘 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} 완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은 잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해 @@ -631,7 +631,8 @@ spec: 이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. 이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다. -사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다. +사용자가 느낄 수 있는 유일한 차이점은 +컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다. {{< /note >}} 이 기능이 활성화되지 않으면, 잡 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index e03f2bedb7..5a799680b2 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -223,8 +223,6 @@ pod2 1/1 Running 0 36s 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다. 레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다. -쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다. -API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다. 레플리카셋 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index bcf8a9771a..3de8fbfc02 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -185,8 +185,8 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용 Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를 삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다. -REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, -레플리케이션 컨트롤러를 삭제). +REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 +명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, 레플리케이션 컨트롤러를 삭제). ### 레플리케이션 컨트롤러만 삭제 @@ -194,7 +194,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적 kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라. -REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라. +REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라. 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면, 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index ff9eca9155..386089fc43 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -115,7 +115,7 @@ spec: ### 파드 셀렉터 -스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다. +스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다. ### 볼륨 클레임 템플릿 @@ -226,8 +226,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 되기 전까지 종료되지 않는다. ### 파드 관리 정책 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 -통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. +스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해 +고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. #### OrderedReady 파드 관리 @@ -242,6 +242,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 받지 않는다. + ## 업데이트 전략 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 @@ -255,8 +256,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다. `RollingUpdate`(롤링 업데이트) -: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 -구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. +`RollingUpdate` 업데이트 전략은 스테이트풀셋의 파드에 대한 자동화된 롤링 업데이트를 구현한다. 이는 기본 업데이트 전략이다. ## 롤링 업데이트 diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 6a13adb91f..ce0c620392 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -180,7 +180,7 @@ spec: spec: containers: - name: hello - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure # 여기까지 파드 템플릿이다 @@ -251,20 +251,19 @@ spec: ### 파드 네트워킹 -각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의 -모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를 -공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한 -컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가 -*파드 외부의* 엔티티와 통신할 때, -공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. -파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, -`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는 -POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로 -통신할 수도 있다. 다른 파드의 컨테이너는 -고유한 IP 주소를 가지며 -[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다. -다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 -사용하여 통신할 수 있다. +각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. +파드의 모든 컨테이너는 네트워크 네임스페이스를 공유하며, +여기에는 IP 주소와 네트워크 포트가 포함된다. +파드 내부(이 경우에 **만** 해당)에서, 파드에 속한 컨테이너는 +`localhost` 를 사용하여 서로 통신할 수 있다. +파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때, +공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. +파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, +`localhost` 를 통해 서로를 찾을 수 있다. +파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은 +표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다. +다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 OS 수준의 IPC로 통신할 수 없다. +다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다. 파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된 `name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index fbaa26548a..ff5053c8db 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -136,8 +136,8 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되 쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과 종료 시간이 표시된다. -컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에 -실행된다. +컨테이너에 구성된 `preStop` 훅이 있는 경우, +이 훅은 컨테이너가 `Terminated` 상태에 들어가기 전에 실행된다. ## 컨테이너 재시작 정책 {#restart-policy} diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index d25f001607..3dcf7abac5 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -12,14 +12,6 @@ obsolete --> 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. -{{< note >}} -v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 -[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와 -[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서 -`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화해야 한다 -{{< /note >}} - ## 필수 구성 요소 @@ -306,11 +298,12 @@ class zoneC cluster; 예시 구성은 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - - pluginConfig: + - schedulerName: default-scheduler + pluginConfig: - name: PodTopologySpread args: defaultConstraints: @@ -366,11 +359,12 @@ defaultConstraints: `defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - - pluginConfig: + - schedulerName: default-scheduler + pluginConfig: - name: PodTopologySpread args: defaultConstraints: [] diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 64b7ba594e..62b98b68d3 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -95,9 +95,9 @@ class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey class S,T,U spacewhite class first,second,third white {{}} -***그림 - 신규 기여자를 위한 시작 가이드*** +그림 1. 신규 기여자를 위한 시작 가이드. -위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다! +그림 1은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다! 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 @@ -105,7 +105,7 @@ class first,second,third white ## 첫 번째 기여 -몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다. +몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 그림 2는 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다. @@ -136,7 +136,7 @@ class A,B,D,E,F,G grey class S,T spacewhite class first,second white {{}} -***그림 - 첫 기여를 위한 준비*** +그림 2. 첫 기여를 위한 준비. - [기여 개요](/ko/docs/contribute/new-content/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 9b4f8835e3..e40ebc71c1 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -86,6 +86,7 @@ SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/ - 문서 리포지터리에 대한 처음 몇 번의 PR을 통해 새로운 기여자를 멘토링한다. - 새로운 기여자가 쿠버네티스 멤버가 되기 위해 필요한 보다 복잡한 PR을 작성하도록 지원한다. - 쿠버네티스 멤버 가입을 위해 [기여자를 후원](/ko/docs/contribute/advanced/#새로운-기여자-후원)한다. +- 월간 미팅을 개최하여 새로운 기여자에게 도움을 주고 조언을 해 준다. 현재 새로운 기여자 홍보대사는 각 SIG-Docs 회의와 [쿠버네티스 #sig-docs 채널](https://kubernetes.slack.com)에서 발표된다. diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md index 424f9b0227..15bcd2198d 100644 --- a/content/ko/docs/contribute/participate/pr-wranglers.md +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -48,8 +48,7 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. CLA에 서명한 후 PR을 열 수 있음을 알린다. **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!** - [LGTM 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm): - 멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 - 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. + 멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. - [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+): 병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다. - [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) @@ -88,3 +87,17 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. [`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. {{< /note >}} + +## PR 랭글러 섀도우 프로그램 + +2021년 말에, SIG Docs는 PR 랭글러 섀도우 프로그램을 도입했다. 이 프로그램은 새로운 기여자가 PR 랭글링 과정을 이해하는 데 도움을 주기 위해 도입되었다. + +### 섀도우 되기 + +- PR 랭글러 섀도우 활동에 관심이 있다면, [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)에서 올해의 PR 랭글링 스케줄을 확인하고 지원한다. + +- 쿠버네티스 org 멤버는 [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수정하여 기존 PR 랭글러를 1주일 간 섀도잉할 수 있다. + +- 쿠버네티스 org 비 멤버는 [#sig-docs 슬랙 채널](https://kubernetes.slack.com/messages/sig-docs)에서 특정 주간에 대해 기존 PR 랭글러에 대한 섀도잉을 요청할 수 있다. Brad Topol (`@bradtopol`) 또는 [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) 중 한 명에게 연락하면 된다. + +- PR 랭글러 섀도워로 지원했다면, [쿠버네티스 슬랙](https://slack.k8s.io)에서 PR 랭글러에게 자신을 소개한다. diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index e6bb3dc84c..91f8627e17 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -36,7 +36,7 @@ weight: 10 ## 리뷰 과정 -일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다. +일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다. @@ -67,7 +67,7 @@ class S,T spacewhite class third,fourth white {{}} -***그림 - 리뷰 과정 절차*** +그림 1. 리뷰 과정 절차. 1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 이동한다. diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 5233856648..5becc565f9 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -60,7 +60,7 @@ cards: title: K8s 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. button: "쿠버네티스 다운로드" - button_path: "/docs/setup/release/notes" + button_path: "/releases/download" - name: about title: 문서에 대하여 description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index ca824db37d..0f1f0d7155 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -43,7 +43,7 @@ no_list: true ## CLI -* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. +* [kubectl](/ko/docs/reference/kubectl/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. @@ -66,6 +66,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 * 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는 [포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트 + ## API 설정 이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는 @@ -73,10 +74,12 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 제공하지 않는다. - +* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) * [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/) +* [kube-apiserver 암호화 (v1)](/docs/reference/config-api/apiserver-encryption.v1/) * [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및 [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) +* [kubelet 크리덴셜 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) * [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및 [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 5f31d10efa..823bb56dbb 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -29,7 +29,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다. ```shell ---feature-gates="...,GracefulNodeShutdown=true" +--feature-gates=...,GracefulNodeShutdown=true ``` 다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를 @@ -63,7 +63,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | | | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | | | `AppArmor` | `true` | 베타 | 1.4 | | -| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | | +| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 | +| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | | | `CPUManager` | `false` | 알파 | 1.8 | 1.9 | | `CPUManager` | `true` | 베타 | 1.10 | | | `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | | @@ -74,7 +75,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CSIInlineVolume` | `true` | 베타 | 1.16 | - | | `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigration` | `true` | 베타 | 1.17 | | -| `CSIMigrationAWS` | `false` | 알파 | 1.14 | | +| `CSIMigrationAWS` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 | | `CSIMigrationAWS` | `true` | 베타 | 1.23 | | | `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | @@ -129,6 +130,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 | | `GracefulNodeShutdown` | `true` | 베타 | 1.21 | | | `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | | +| `GracefulNodeShutdownBasedOnPodPriority` | `true` | 베타 | 1.24 | | | `GRPCContainerProbe` | `false` | 알파 | 1.23 | | | `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | | | `HPAContainerMetrics` | `false` | 알파 | 1.20 | | @@ -428,6 +430,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | | `ServerSideApply` | `true` | 베타 | 1.16 | 1.21 | | `ServerSideApply` | `true` | GA | 1.22 | - | +| `ServerSideFieldValidation` | `false` | 알파 | 1.23 | - | | `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 | | `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 | | `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - | @@ -579,48 +582,58 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다. - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 대한 제한을 보고하도록 한다. - 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다. + 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 + 참고한다. - `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 더 가까운 노드가 선호된다. - `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 참고한다. -- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 - 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 - 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 - `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. - 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 - 확인한다. +- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 + 서비스어카운트 볼륨을 마이그레이션한다. + 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 + 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. + 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 + `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. + 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. - `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가 kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면, cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록 - [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의 + [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 + [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의 리더 마이그레이션(Leader Migration)을 활성화한다. - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다. -- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 미세 조정을 허용한다. +- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 + 미세 조정을 허용한다. 이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다. 이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다. -- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 미세 조정을 허용한다. +- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 + 미세 조정을 허용한다. 이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다. 이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다. - `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다. -- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며, -컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다. -더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. +- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. + 로그 파일 사이즈 기본값은 10MB이며, + 컨테이너 당 최대 로그 파일 수 기본값은 5이다. + 이 값은 kubelet 환경설정으로 변경할 수 있다. + 더 자세한 내용은 + [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. - `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. - 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원) - 문서를 참고한다. + 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을 + 참고한다. - `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다. - `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다. -- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 - AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에 - EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로 - 폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 + AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. + 이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. - `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. @@ -630,21 +643,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 더 이상 사용되지 않는다. - `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. - 노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 - AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 - 필요하다. -- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리 - 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 - Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 - 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 - 플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어 - 있어야 한다. 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. + 이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. +- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 + Azure-Disk 인-트리 플러그인 등록을 중지하고 + shim 및 변환 로직을 사용하여 + 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. + 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 + AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 + `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. - 노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 - AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 - 필요하다. + 이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 @@ -654,46 +672,57 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, `InTreePluginAzureFileUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 - GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에 - PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을 - 지원한다. CSIMigration 기능 플래그가 필요하다. -- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 - Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. - 클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, - Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다. - 이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 - `InTreePluginRBDUnregister` 기능 플래그에 의해 - 사용 중단되었다. + GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. + 이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 GCE 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI - 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해 + 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 - Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 - Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 - Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. + Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. + 이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 Cinder 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 - Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 + Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. +- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 + Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. + 클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, + Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다. + 이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 `InTreePluginRBDUnregister` 기능 플래그에 의해 + 사용 중단되었다. - `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. - 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 - 인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. + 이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 - 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 + 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. - Portworx CSI 드라이버가 설치 및 설정되어 있어야 하며, kube-controller-manager와 kubelet 환경 설정 내에 `CSIMigrationPortworx=true` 기능 게이트가 활성화되어 있어야 한다. -- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. + Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다. +- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 마운트할 수 있다. @@ -721,7 +750,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 동일한 컨트롤러의 버전 1이 선택된다. - `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서 `cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다. -- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 검증 규칙을 기반으로 커스텀 리소스를 검증하는 표현 언어 검증(expression language validation)을 CRD에 활성화한다. +- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 + 검증 규칙을 기반으로 커스텀 리소스를 검증하는 + 표현 언어 검증(expression language validation)을 CRD에 활성화한다. - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 확인한다. @@ -804,7 +835,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. -- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다. +- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 + 버그를 수정한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 @@ -817,8 +849,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 참조한다. - `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때 kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다. -- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다. -- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 PV-PVC 삭제 순서와 상관없이 정책을 준수한다. +- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. + [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다. +- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 + PV-PVC 삭제 순서와 상관없이 정책을 준수한다. - `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의 개별 컨테이너 메트릭을 기반으로 확장한다. - `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해 @@ -830,10 +864,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. -- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. - 쿠버네티스 {{< skew currentVersion >}}에서, `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다. +- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. + 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. + 쿠버네티스 {{< skew currentVersion >}}에서, + `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다. - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다. +- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를 + 완료 인덱스에 따라 관리할 수 있도록 허용한다. +- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가 + `IngressClass` 리소스를 참조할 수 있도록 허용한다. + 이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다. +- `Initializers`: Initializers 어드미션 플러그인을 사용하여, + 오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다. - `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리 플러그인의 등록을 중지한다. - `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리 @@ -850,13 +893,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 플러그인의 등록을 중지한다. - `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리 플러그인의 등록을 중지한다. -- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 - 완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다. -- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로 - 한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에 - `Scope` 와 `Namespace` 2개의 필드를 추가한다. -- `Initializers`: Initializers 어드미션 플러그인을 사용하여 오브젝트 생성의 - 비동기 조정을 허용한다. - `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/) 기능을 활성화한다. - `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의 @@ -874,16 +910,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, kubelet 구성을 로드할 수 있다. 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다. -- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다. -- `KubeletInUserNamespace`: {{}}에서 kubelet 실행을 활성화한다. +- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 + kubelet exec 자격 증명 공급자를 활성화한다. +- `KubeletInUserNamespace`: {{}}에서 + kubelet 실행을 활성화한다. [루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다. - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. - `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을 참고한다. -- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다. - 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를 +- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 + `GetAllocatableResources` 기능을 활성화한다. + 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, + 할당 가능 자원에 대한 정보를 [자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다. - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 @@ -903,18 +943,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다. - `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한 메모리 어피니티를 설정할 수 있다. -- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다. +- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 + 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다. - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다. - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. - `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable) - {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가) -- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. + {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. + (네임스페이스의 이름도 변경 불가) +- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 + 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. -- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. +- `NodeLease`: 새로운 리스(Lease) API가 + 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. - `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다. 반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다. 더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다. @@ -922,8 +966,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의 "enum" 필드 채우기를 활성화한다. - `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다. -- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 - 삭제되지 않도록 한다. - `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록, [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다. - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. @@ -931,8 +973,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라 CRI 컨테이너 런타임으로부터 수집하도록 설정한다. - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. -- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과 - [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다. +- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) + 기능과 + [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) + 쿼터 범위 기능을 활성화한다. - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다. - `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 @@ -948,12 +992,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 지정된 노드를 먼저 검사할지 여부를 스케줄러에 알려준다. - `ProbeTerminationGracePeriod`: 파드의 [프로브-수준 - `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다. + `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) + 기능을 활성화한다. 더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다. - `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여 컨테이너의 proc 타입의 마운트를 제어할 수 있다. - `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록 kube-proxy를 활성화한다. +- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 + 삭제되지 않도록 한다. - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다 (현재 메모리만 해당). @@ -966,8 +1013,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `RemainingItemCount`: API 서버가 [청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한 응답에서 남은 항목 수를 표시하도록 허용한다. -- `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고 - 제거한다. +- `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고 제거한다. - `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을 관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다. - `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 @@ -982,7 +1028,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 참조한다. - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. - 자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. + 자세한 내용은 + [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. 자세한 사항은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다. @@ -994,12 +1041,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 스케줄링할 수 있다. - `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다. -- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다. +- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 + `RuntimeDefault`을 사용한다. seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다. - `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여 목록 작업을 가속화할 수 있다. - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다. +- `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다. + 이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라 + API 서버 사이드에서 수행됨을 의미한다. - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 @@ -1007,7 +1058,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다. - `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다. - `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다. -- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은 +- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. + 자세한 내용은 [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다. - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 diff --git a/content/ko/docs/reference/glossary/api-eviction.md b/content/ko/docs/reference/glossary/api-eviction.md index 7d5ee60667..d155f0152a 100644 --- a/content/ko/docs/reference/glossary/api-eviction.md +++ b/content/ko/docs/reference/glossary/api-eviction.md @@ -10,7 +10,6 @@ aka: tags: - operation --- - API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core)를 사용하여 생성된 `Eviction` 오브젝트로 파드를 정상 종료한다. @@ -20,4 +19,9 @@ API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api 축출 API를 직접 호출해 축출 요청을 할 수 있다. `Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다. +API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 +[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다. + API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다. + +* 더 많은 정보는 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 참고한다. diff --git a/content/ko/docs/reference/glossary/kubectl.md b/content/ko/docs/reference/glossary/kubectl.md index 0de6f95898..2d90d5412a 100644 --- a/content/ko/docs/reference/glossary/kubectl.md +++ b/content/ko/docs/reference/glossary/kubectl.md @@ -2,18 +2,20 @@ title: Kubectl id: kubectl date: 2018-04-12 -full_link: /docs/user-guide/kubectl-overview/ +full_link: /ko/docs/reference/kubectl/ short_description: > - 쿠버네티스 API 서버와 통신하기 위한 커맨드라인 툴. + 쿠버네티스 클러스터와 통신하기 위한 커맨드라인 툴. aka: +- kubectl tags: - tool - fundamental --- - {{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}} 서버와 통신하기 위한 커맨드라인 툴. +쿠버네티스 API를 사용하여 +쿠버네티스 클러스터의 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}과 +통신하기 위한 커맨드라인 툴 -사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 kubectl를 사용할 수 있다. - +사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 `kubectl`을 사용할 수 있다. diff --git a/content/ko/docs/reference/glossary/namespace.md b/content/ko/docs/reference/glossary/namespace.md index 417ad0672f..3c98d7a7a7 100644 --- a/content/ko/docs/reference/glossary/namespace.md +++ b/content/ko/docs/reference/glossary/namespace.md @@ -2,9 +2,9 @@ title: 네임스페이스(Namespace) id: namespace date: 2018-04-12 -full_link: /ko/docs/concepts/overview/working-with-objects/namespaces +full_link: /ko/docs/concepts/overview/working-with-objects/namespaces/ short_description: > - 쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화. + 쿠버네티스에서, 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상화. aka: tags: diff --git a/content/ko/docs/reference/glossary/pod-security-policy.md b/content/ko/docs/reference/glossary/pod-security-policy.md index 4ef734d946..8dd0a09af4 100644 --- a/content/ko/docs/reference/glossary/pod-security-policy.md +++ b/content/ko/docs/reference/glossary/pod-security-policy.md @@ -2,7 +2,7 @@ title: 파드 시큐리티 폴리시(Pod Security Policy) id: pod-security-policy date: 2018-04-12 -full_link: /ko/docs/concepts/policy/pod-security-policy/ +full_link: /ko/docs/concepts/security/pod-security-policy/ short_description: > 파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다. @@ -17,3 +17,4 @@ tags: 파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. `PodSecurityPolicy` 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다. +파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거될 예정이다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인으로 이전(migrate)하는 것을 추천한다. diff --git a/content/ko/docs/reference/issues-security/security.md b/content/ko/docs/reference/issues-security/security.md index 2c5a287df4..84fda49478 100644 --- a/content/ko/docs/reference/issues-security/security.md +++ b/content/ko/docs/reference/issues-security/security.md @@ -19,8 +19,6 @@ weight: 20 보안 및 주요 API 공지에 대한 이메일을 위해서는 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입한다. -[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드도 구독할 수 있다. - ## 취약점 보고 우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다. diff --git a/content/ko/docs/reference/kubectl/_index.md b/content/ko/docs/reference/kubectl/_index.md index 765adb6fe8..a649fb2045 100644 --- a/content/ko/docs/reference/kubectl/_index.md +++ b/content/ko/docs/reference/kubectl/_index.md @@ -1,5 +1,556 @@ --- -title: "kubectl" +title: 명령줄 도구 (kubectl) +content_type: reference weight: 60 +no_list: true +card: + name: reference + weight: 20 --- + +{{< glossary_definition prepend="쿠버네티스는 다음을 제공한다: " term_id="kubectl" length="short" >}} + +이 툴의 이름은 `kubectl`이다. + +구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. +KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +파일을 지정할 수 있다. + +이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. +지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 +[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. + +설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고하고, +빠른 가이드는 [치트 시트](/ko/docs/reference/kubectl/cheatsheet/)를 참고한다. `docker` 명령줄 도구에 익숙하다면, +[도커 사용자를 위한 `kubectl`](/ko/docs/reference/kubectl/docker-cli-to-kubectl/)에서 대응되는 쿠버네티스 명령어를 볼 수 있다. + + + +## 구문 + +터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다. + +```shell +kubectl [command] [TYPE] [NAME] [flags] +``` + +다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다. + +* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. +예: `create`, `get`, `describe`, `delete` + +* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 + 단수형, 복수형 또는 약어 형식을 지정할 수 있다. + 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. + + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` + +* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods` + + 여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다. + + * 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다. + + * 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`
+ 예: `kubectl get pod example-pod1 example-pod2` + + * 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`
+ 예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1` + + * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>` + + * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).
+ 예: `kubectl get -f ./pod.yaml` + +* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.
+ +{{< caution >}} +커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다. +{{< /caution >}} + +도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다. + +## 클러스터 내 인증과 네임스페이스 오버라이드 + +기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다. + +하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다. + +**`POD_NAMESPACE` 환경 변수** + +`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다. + +명시적으로 `--namespace ` 인자를 사용하면 위와 같은 동작을 오버라이드한다. + +**kubectl이 서비스어카운트 토큰을 관리하는 방법** + +만약 +* 쿠버네티스 서비스 어카운트 토큰 파일이 + `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고, +* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고, +* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고, +* kubectl 명령에 네임스페이스를 명시하지 않으면 + +kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다. +kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다. +이는 클러스터 외부에서 실행되었을 때와는 다른데, +kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우 +kubectl은 `default` 네임스페이스에 대해 동작한다. + +## 명령어 + +다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다. + +명령어 | 구문 | 설명 +-------------------- | -------------------- | -------------------- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다. +`annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다. +`api-resources` | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다. +`api-versions` | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다. +`apply` | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다. +`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다. +`auth` | `kubectl auth [flags] [options]` | 승인을 검사한다. +`autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다. +`certificate` | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다. +`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다. +`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다. +`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다. +`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다. +`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다. +`cp` | `kubectl cp [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다. +`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다. +`delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다. +`describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 하나 이상의 리소스의 자세한 상태를 표시한다. +`diff` | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다. +`drain` | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다. +`edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다. +`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다. +`explain` | `kubectl explain [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다. +`expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다. +`get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 하나 이상의 리소스를 나열한다. +`kustomize` | `kubectl kustomize [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다. +`label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다. +`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다. +`options` | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다. +`patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다. +`plugin` | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다. +`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다. +`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다. +`replace` | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다. +`rollout` | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다. +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | 클러스터에서 지정된 이미지를 실행한다. +`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다. +`set` | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다. +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다. +`top` | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다. +`uncordon` | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다. +`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. + +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. + +## 리소스 타입 + +다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다. + +(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.) + +| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND | +|---|---|---|---|---| +| `bindings` | | | true | Binding | +| `componentstatuses` | `cs` | | false | ComponentStatus | +| `configmaps` | `cm` | | true | ConfigMap | +| `endpoints` | `ep` | | true | Endpoints | +| `events` | `ev` | | true | Event | +| `limitranges` | `limits` | | true | LimitRange | +| `namespaces` | `ns` | | false | Namespace | +| `nodes` | `no` | | false | Node | +| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | | false | PersistentVolume | +| `pods` | `po` | | true | Pod | +| `podtemplates` | | | true | PodTemplate | +| `replicationcontrollers` | `rc` | | true | ReplicationController | +| `resourcequotas` | `quota` | | true | ResourceQuota | +| `secrets` | | | true | Secret | +| `serviceaccounts` | `sa` | | true | ServiceAccount | +| `services` | `svc` | | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io | false | APIService | +| `controllerrevisions` | | apps | true | ControllerRevision | +| `daemonsets` | `ds` | apps | true | DaemonSet | +| `deployments` | `deploy` | apps | true | Deployment | +| `replicasets` | `rs` | apps | true | ReplicaSet | +| `statefulsets` | `sts` | apps | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch | true | CronJob | +| `jobs` | | batch | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io | true | Lease | +| `endpointslices` | | discovery.k8s.io | true | EndpointSlice | +| `events` | `ev` | events.k8s.io | true | Event | +| `ingresses` | `ing` | extensions | true | Ingress | +| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema | +| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration | +| `ingressclasses` | | networking.k8s.io | false | IngressClass | +| `ingresses` | `ing` | networking.k8s.io | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy | +| `runtimeclasses` | | node.k8s.io | false | RuntimeClass | +| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass | +| `csidrivers` | | storage.k8s.io | false | CSIDriver | +| `csinodes` | | storage.k8s.io | false | CSINode | +| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | +| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | + +## 출력 옵션 + +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. + +### 출력 서식화 + +모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다. + +#### 구문 + +```shell +kubectl [command] [TYPE] [NAME] -o +``` + +`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다. + +출력 형식 | 설명 +--------------| ----------- +`-o custom-columns=` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다. +`-o custom-columns-file=` | `` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다. +`-o json` | JSON 형식의 API 오브젝트를 출력한다. +`-o jsonpath=