diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 8b33e3322e..7852d7acff 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -1,6 +1,6 @@ --- - - +# reviewers: +# - mikedanese title: 구성 모범 사례 content_type: concept weight: 10 @@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 ## 레이블 사용하기 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다. +- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다. 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다. diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index eeab1e0680..517ca7e170 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -1,7 +1,7 @@ --- - - - +# reviewers: +# - tallclair +# - dchen1107 title: 런타임클래스(RuntimeClass) content_type: concept weight: 20 @@ -81,7 +81,7 @@ handler: myconfiguration ## 사용 -클러스터에 런타임클래스를 설정하고 나면, +클러스터에 런타임클래스를 설정하고 나면, 다음과 같이 파드 스펙에 `runtimeClassName`를 명시하여 해당 런타임클래스를 사용할 수 있다. ```yaml @@ -116,7 +116,7 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` -더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를 +더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를 살펴본다. #### {{< glossary_tooltip term_id="cri-o" >}} @@ -136,7 +136,7 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p {{< feature-state for_k8s_version="v1.16" state="beta" >}} -RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가 +RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가 이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다. `scheduling`이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 1b472a3451..0ced9fc52f 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -1,7 +1,7 @@ --- title: 레퍼런스 - - +# approvers: +# - chenopis linkTitle: "레퍼런스" main_menu: true weight: 70 @@ -86,7 +86,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) * [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/) -* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및 +* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및 [클라이언트 인증 API (v1)](/docs/reference/config-api/client-authentication.v1/) * [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) * [이미지 정책 API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/) diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index a2e36f8a18..46aa5a0b4c 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -1,9 +1,9 @@ --- - - - - - +# reviewers: +# - erictune +# - lavalamp +# - deads2k +# - liggitt title: 인가 개요 content_type: concept weight: 60 @@ -74,6 +74,10 @@ PUT | update PATCH | patch DELETE | delete(개별 리소스), deletecollection(리소스 모음) +{{< caution >}} +`get`, `list`, `watch` 요청은 모두 리소스의 전체 세부 내용을 반환할 수 있다. 반환된 데이터의 관점으론 모두 동일하다. 예를 들어 `secrets`에 대해 `list` 요청은 반환된 리소스의 `data` 속성을 여전히 드러낼 것이다. +{{< /caution >}} + 쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면, * [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/) @@ -134,7 +138,7 @@ kubectl auth can-i list secrets --namespace dev --as dave no ``` -유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가 +유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가 `target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다. ```bash @@ -209,7 +213,7 @@ status: ## 워크로드 생성 및 수정을 통한 권한 확대 {#privilege-escalation-via-pod-creation} -네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는 +네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는 해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다. {{< caution >}} @@ -230,8 +234,8 @@ status: - 다른 워크로드를 위한 정보의 획득 및 수정에 사용될 수 있음 {{< caution >}} -시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다. -이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다. +시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다. +이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다. RBAC 제어에 대해 결정할 때 이와 같은 사항을 고려해야 한다. {{< /caution >}} 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 8d06536a7d..aca56d3dfb 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 @@ -25,7 +25,7 @@ card: 각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을 활성화 또는 비활성화할 수 있다. 모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 `-h` 플래그를 사용한다. -kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, +kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다. ```shell @@ -603,9 +603,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다. - `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다. - `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다. -- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는 - 플러그인의 초기 형태를 제공하였으며, 사용 중단되었다. - 대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 +- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는 + 플러그인의 초기 형태를 제공하였으며, 사용 중단되었다. + 대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 확인한다. - `AdvancedAuditing`: [고급 감사](/docs/tasks/debug/debug-cluster/audit/#advanced-audit) 기능을 활성화한다. - `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) @@ -619,7 +619,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다. - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 대한 제한을 보고하도록 한다. - 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 + 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다. - `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 @@ -627,35 +627,35 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 참고한다. -- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 - 서비스어카운트 볼륨을 마이그레이션한다. - 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 - 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. - 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 - `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. +- `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)와 + [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 환경설정으로 변경할 수 있다. - 더 자세한 내용은 +- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. + 로그 파일 사이즈 기본값은 10MB이며, + 컨테이너 당 최대 로그 파일 수 기본값은 5이다. + 이 값은 kubelet 환경설정으로 변경할 수 있다. + 더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. - `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을 @@ -665,11 +665,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다. - `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다. -- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 - AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. - 이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 - 인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다. - 프로비전 동작에 대해서는 폴백을 지원하지 않는데, +- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 + AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. + 이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. - `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS @@ -677,27 +677,27 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 EBS 플러그인의 등록을 막는 `InTreePluginAWSUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. + 더 이상 사용되지 않는다. - `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. - 이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 - 인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다. - 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. -- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 - Azure-Disk 인-트리 플러그인 등록을 중지하고 - shim 및 변환 로직을 사용하여 - 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. - 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 - AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. - 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 +- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 + Azure-Disk 인-트리 플러그인 등록을 중지하고 + shim 및 변환 로직을 사용하여 + 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. + 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 + AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. - 이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 - 인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다. - 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 @@ -705,59 +705,59 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 - 있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는 + 있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는 `InTreePluginAzureFileUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 - GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. - 이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 - 인-트리 GCE 플러그인으로의 폴백(falling back)을 지원한다. - 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 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` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 - Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. - 이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 - 인-트리 Cinder 플러그인으로의 폴백(falling back)을 지원한다. - 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 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` 기능 플래그에 의해 +- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 + Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. + 클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, + Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다. + 이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 `InTreePluginRBDUnregister` 기능 플래그에 의해 사용 중단되었다. - `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. - 이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 - 인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다. - 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 - 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. -- `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 - Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. +- `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 + Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다. - `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) @@ -780,9 +780,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. -- `ContextualLogging`: 이 기능을 활성화하면, +- `ContextualLogging`: 이 기능을 활성화하면, 컨텍스츄얼 로깅을 지원하는 쿠버네티스 구성 요소가 로그 출력에 추가 상세를 추가한다. -- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에 +- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에 대한 리더 마이그레이션을 지원한다. - `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면, @@ -790,8 +790,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `CronJobTimeZone`: [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)의 선택적 `timeZone` 필드 사용을 허용한다. - `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서 `cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다. -- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 - 검증 규칙을 기반으로 커스텀 리소스를 검증하는 +- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 + 검증 규칙을 기반으로 커스텀 리소스를 검증하는 표현 언어 검증(expression language validation)을 CRD에 활성화한다. - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 @@ -804,30 +804,30 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다. - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. -- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록 +- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록 데몬셋 워크로드를 사용하도록 설정한다. [데몬셋에서 롤링 업데이트 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)을 참고한다. - `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여 - [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다. -- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해 - `fsGroup`를 전달하여 파드의 `securityContext`에서 + [기본 분배](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/#내부-기본-제약)를 수행한다. +- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해 + `fsGroup`를 전달하여 파드의 `securityContext`에서 `fsGroup`를 드라이브에 적용하는 역할을 위임한다. - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 기반 리소스 프로비저닝을 활성화한다. - `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/#액셀러레이터-메트릭-비활성화). -- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`, - `--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의 +- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`, + `--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의 모든 기능을 비활성화한다. -- `DisableKubeletCloudCredentialProviders`: 이미지 풀 크리덴셜을 위해 +- `DisableKubeletCloudCredentialProviders`: 이미지 풀 크리덴셜을 위해 클라우드 프로바이더 컨테이너 레지스트리에 인증을 수행하는 kubelet 내부(in-tree) 기능을 비활성화한다. - `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서 hugepages 사용을 활성화한다. - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다. - `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다. -- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. - 이 기능은 지원하는 버전 차이(supported skew policy) 바깥에서는 더 이상 지원되지 않는다. +- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. + 이 기능은 지원하는 버전 차이(supported skew policy) 바깥에서는 더 이상 지원되지 않는다. 이 기능 게이트는 1.24에 kubelet에서 제거되었다. [kubelet 재구성하기](/docs/tasks/administer-cluster/reconfigure-kubelet/)를 참고한다. - `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다. @@ -854,13 +854,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를 추가할 수 있다. - `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. - [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다. + [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)을 참고한다. - `ExecProbeTimeout` : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다. 이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한 현재 수정된 결함에 의존하는 경우 존재한다. [준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다. - `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다. -- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면 +- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면 kubelet과 kube-apiserver를 사용하도록 설정한다. 이 기능을 사용하려면 컨테이너 런타임이 지원해야 한다(Containerd: v1.5.6 이상, CRI-O: v1.22 이상). [확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다. @@ -876,7 +876,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. -- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 +- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 @@ -888,13 +888,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을 참조한다. -- `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때 +- `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때 kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다. -- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. +- `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 삭제 순서와 상관없이 정책을 준수한다. - 더 자세한 정보는 - [퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer)](/ko/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer) 문서를 + 더 자세한 정보는 + [퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer)](/ko/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer) 문서를 참고한다. - `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의 개별 컨테이너 메트릭을 기반으로 확장한다. @@ -907,55 +907,55 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. -- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. - 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. - 쿠버네티스 {{< skew currentVersion >}}에서, +- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. + 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. + 쿠버네티스 {{< skew currentVersion >}}에서, `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다. - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다. -- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를 +- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를 완료 인덱스에 따라 관리할 수 있도록 허용한다. -- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가 - `IngressClass` 리소스를 참조할 수 있도록 허용한다. +- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가 + `IngressClass` 리소스를 참조할 수 있도록 허용한다. 이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다. -- `Initializers`: Initializers 어드미션 플러그인을 사용하여, +- `Initializers`: Initializers 어드미션 플러그인을 사용하여, 오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다. -- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리 +- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리 플러그인의 등록을 중지한다. -- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리 +- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리 플러그인의 등록을 중지한다. -- `InTreePluginAzureFileUnregister`: kubelet 및 볼륨 컨트롤러에 azurefile 인-트리 +- `InTreePluginAzureFileUnregister`: kubelet 및 볼륨 컨트롤러에 azurefile 인-트리 플러그인의 등록을 중지한다. -- `InTreePluginGCEUnregister`: kubelet 및 볼륨 컨트롤러에 gce-pd 인-트리 +- `InTreePluginGCEUnregister`: kubelet 및 볼륨 컨트롤러에 gce-pd 인-트리 플러그인의 등록을 중지한다. -- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리 +- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리 플러그인의 등록을 중지한다. -- `InTreePluginPortworxUnregister`: kubelet 및 볼륨 컨트롤러에 Portworx 인-트리 +- `InTreePluginPortworxUnregister`: kubelet 및 볼륨 컨트롤러에 Portworx 인-트리 플러그인의 등록을 중지한다. -- `InTreePluginRBDUnregister`: kubelet 및 볼륨 컨트롤러에 RBD 인-트리 +- `InTreePluginRBDUnregister`: kubelet 및 볼륨 컨트롤러에 RBD 인-트리 플러그인의 등록을 중지한다. -- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리 +- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리 플러그인의 등록을 중지한다. - `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/) 기능을 활성화한다. -- `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의 +- `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의 파드 템플릿에 있는 노드 스케줄링 지시를 업데이트할 수 있게 한다. -- `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)이 - `Ready`인 파드의 수를 추적하는 기능을 활성화한다. - `Ready`인 파드의 수는 [잡](/ko/docs/concepts/workloads/controllers/job/) 상태의 - [status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus) +- `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)이 + `Ready`인 파드의 수를 추적하는 기능을 활성화한다. + `Ready`인 파드의 수는 [잡](/ko/docs/concepts/workloads/controllers/job/) 상태의 + [status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus) 필드에 기록된다. -- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고 +- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고 [잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다. - 잡 컨트롤러는 완료된 파드를 추적하기 위해 + 잡 컨트롤러는 완료된 파드를 추적하기 위해 완료된 파드의 잡 상태 필드를 사용한다. - `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다. 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다. -- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 +- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다. -- `KubeletInUserNamespace`: {{}}에서 +- `KubeletInUserNamespace`: {{}}에서 kubelet 실행을 활성화한다. [루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다. - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 @@ -963,15 +963,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을 참고한다. -- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 +- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다. - 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, + 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를 [자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다. - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. -- `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반 +- `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)의 자동 생성을 중단한다. - `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 @@ -986,15 +986,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 향상시킨다. - `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여 축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다. -- `MaxUnavailableStatefulSet`: 스테이트풀셋의 - [롤링 업데이트 전략](/ko/docs/concepts/workloads/controllers/statefulset/#롤링-업데이트)에 대해 - `maxUnavailable` 필드를 설정할 수 있도록 한다. +- `MaxUnavailableStatefulSet`: 스테이트풀셋의 + [롤링 업데이트 전략](/ko/docs/concepts/workloads/controllers/statefulset/#롤링-업데이트)에 대해 + `maxUnavailable` 필드를 설정할 수 있도록 한다. 이 필드는 업데이트 동안 사용 불가능(unavailable) 상태의 파드를 몇 개까지 허용할지를 정한다. -- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한 +- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한 메모리 어피니티를 설정할 수 있다. -- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 +- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다. -- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/) 내의 +- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/) 내의 `minDomains` 사용을 활성화한다. - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다. @@ -1002,35 +1002,35 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. - `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable) - {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. + {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가) -- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 +- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. - `NetworkPolicyStatus`: 네트워크폴리시 오브젝트에 대해 `status` 서브리소스를 활성화한다. - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. -- `NodeOutOfServiceVolumeDetach`: 노드가 `node.kubernetes.io/out-of-service` 테인트를 사용하여 서비스 불가(out-of-service)로 표시되면, - 노드에 있던 이 테인트를 허용하지 않는 파드는 강제로 삭제되며, - 종료되는 파드에 대한 볼륨 해제(detach) 동작도 즉시 수행된다. +- `NodeOutOfServiceVolumeDetach`: 노드가 `node.kubernetes.io/out-of-service` 테인트를 사용하여 서비스 불가(out-of-service)로 표시되면, + 노드에 있던 이 테인트를 허용하지 않는 파드는 강제로 삭제되며, + 종료되는 파드에 대한 볼륨 해제(detach) 동작도 즉시 수행된다. 이로 인해 삭제된 파드가 다른 노드에서 빠르게 복구될 수 있다. - `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다. 반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다. 더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다. - `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다. -- `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의 +- `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의 "enum" 필드 채우기를 활성화한다. - `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다. - `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록, [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다. - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. -- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라 +- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라 CRI 컨테이너 런타임으로부터 수집하도록 설정한다. - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. -- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) +- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과 - [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) + [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다. - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다. @@ -1043,16 +1043,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은 [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다. -- `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에 - 지정된 노드를 먼저 검사할지 여부를 +- `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에 + 지정된 노드를 먼저 검사할지 여부를 스케줄러에 알려준다. - `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`일 때 종료 엔드포인트를 처리하도록 +- `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록 kube-proxy를 활성화한다. - `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 삭제되지 않도록 한다. @@ -1061,16 +1061,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, (현재 메모리만 해당). - `ReadWriteOncePod`: `ReadWriteOncePod` 퍼시스턴트 볼륨 엑세스 모드를 사용한다. -- `RecoverVolumeExpansionFailure`: 이전에 실패했던 볼륨 확장으로부터 복구할 수 있도록, - 사용자가 PVC를 더 작은 크기로 변경할 수 있도록 한다. - [볼륨 확장 시 오류 복구](/ko/docs/concepts/storage/persistent-volumes/#볼륨-확장-시-오류-복구)에서 +- `RecoverVolumeExpansionFailure`: 이전에 실패했던 볼륨 확장으로부터 복구할 수 있도록, + 사용자가 PVC를 더 작은 크기로 변경할 수 있도록 한다. + [볼륨 확장 시 오류 복구](/ko/docs/concepts/storage/persistent-volumes/#볼륨-확장-시-오류-복구)에서 자세한 사항을 확인한다. - `RemainingItemCount`: API 서버가 [청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한 응답에서 남은 항목 수를 표시하도록 허용한다. -- `RemoveSelfLink`: 모든 오브젝트와 콜렉션에 대해 `.metadata.selfLink` 필드를 빈 칸(빈 문자열)으로 설정한다. - 이 필드는 쿠버네티스 v1.16에서 사용 중단되었다. - 이 기능을 활성화하면, `.metadata.selfLink` 필드는 쿠버네티스 API에 존재하지만, +- `RemoveSelfLink`: 모든 오브젝트와 콜렉션에 대해 `.metadata.selfLink` 필드를 빈 칸(빈 문자열)으로 설정한다. + 이 필드는 쿠버네티스 v1.16에서 사용 중단되었다. + 이 기능을 활성화하면, `.metadata.selfLink` 필드는 쿠버네티스 API에 존재하지만, 항상 빈 칸으로 유지된다. - `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을 관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다. @@ -1086,7 +1086,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 참조한다. - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. - 자세한 내용은 + 자세한 내용은 [kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. 자세한 사항은 @@ -1099,15 +1099,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 스케줄링할 수 있다. - `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다. -- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 +- `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` 명령줄)가 아니라 +- `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다. + 이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라 API 서버 사이드에서 수행됨을 의미한다. - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 @@ -1116,7 +1116,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다. - `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다. - `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다. -- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. +- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은 [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다. - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. @@ -1127,11 +1127,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다. -- `ServiceIPStaticSubrange`: ClusterIP 범위를 분할하는 - 서비스 ClusterIP 할당 전략을 활성화한다. - ClusterIP 동적 할당을 주로 상위 범위에서 수행하여, - 사용자가 고정 ClusterIP를 하위 범위에서 할당하는 상황에서도 충돌 확률을 낮출 수 있다. - 더 자세한 사항은 +- `ServiceIPStaticSubrange`: ClusterIP 범위를 분할하는 + 서비스 ClusterIP 할당 전략을 활성화한다. + ClusterIP 동적 할당을 주로 상위 범위에서 수행하여, + 사용자가 고정 ClusterIP를 하위 범위에서 할당하는 상황에서도 충돌 확률을 낮출 수 있다. + 더 자세한 사항은 [충돌 방지](/ko/docs/concepts/services-networking/service/#avoiding-collisions)를 참고한다. - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. @@ -1141,7 +1141,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다. -- `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를 +- `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를 반영할 수 있다. - `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 사용 중인 경우 삭제를 연기한다. @@ -1219,8 +1219,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, * [사용 중단 정책](/docs/reference/using-api/deprecation-policy/)은 쿠버네티스에 대한 기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다. -* 쿠버네티스 1.24부터, 새로운 베타 API는 기본적으로 활성화되어 있지 않다. - 베타 기능을 활성화하려면, 연관된 API 리소스도 활성화해야 한다. - 예를 들어, `storage.k8s.io/v1beta1/csistoragecapacities`와 같은 특정 리소스를 활성화하려면, - `--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`를 설정한다. +* 쿠버네티스 1.24부터, 새로운 베타 API는 기본적으로 활성화되어 있지 않다. + 베타 기능을 활성화하려면, 연관된 API 리소스도 활성화해야 한다. + 예를 들어, `storage.k8s.io/v1beta1/csistoragecapacities`와 같은 특정 리소스를 활성화하려면, + `--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`를 설정한다. 명령줄 플래그에 대한 상세 사항은 [API 버전 규칙](/ko/docs/reference/using-api/#api-버전-규칙)을 참고한다. diff --git a/content/ko/docs/reference/glossary/api-eviction.md b/content/ko/docs/reference/glossary/api-eviction.md index d155f0152a..610cb4421f 100644 --- a/content/ko/docs/reference/glossary/api-eviction.md +++ b/content/ko/docs/reference/glossary/api-eviction.md @@ -19,9 +19,9 @@ API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api 축출 API를 직접 호출해 축출 요청을 할 수 있다. `Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다. -API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 +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/node-pressure-eviction/)과 동일하지 않다. * 더 많은 정보는 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 참고한다. diff --git a/content/ko/docs/reference/glossary/extensions.md b/content/ko/docs/reference/glossary/extensions.md index daa5e37841..cb70a7e3e9 100644 --- a/content/ko/docs/reference/glossary/extensions.md +++ b/content/ko/docs/reference/glossary/extensions.md @@ -4,15 +4,18 @@ id: Extensions date: 2019-02-01 full_link: /ko/docs/concepts/extend-kubernetes/#익스텐션 short_description: > - 익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다. + 익스텐션은 새로운 종류의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 + 깊게 통합시키는 소프트웨어 컴포넌트이다. aka: tags: - fundamental - extension --- - 익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다. + 익스텐션은 새로운 종류의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다. -많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 또한 익스텐션을 새로 만들어야 하는 사용자는 거의 없을 것이다. +많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. +이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. +그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 익스텐션을 새로 만들어야 하는 사용자 역시 거의 없을 것이다. diff --git a/content/ko/docs/reference/glossary/garbage-collection.md b/content/ko/docs/reference/glossary/garbage-collection.md index 529ae67400..b311760a40 100644 --- a/content/ko/docs/reference/glossary/garbage-collection.md +++ b/content/ko/docs/reference/glossary/garbage-collection.md @@ -4,19 +4,24 @@ id: garbage-collection date: 2022-01-14 full_link: /ko/docs/concepts/architecture/garbage-collection/ short_description: > - 쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다. + 쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 + 다양한 방법을 종합한 용어이다. -aka: +aka: tags: - fundamental - operation --- - 쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다. + +쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 +다양한 방법을 종합한 용어이다. -쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images), +쿠버네티스는 가비지 수집을 이용하여 +[사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images), [실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection), [타겟 리소스가 소유한 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/), [종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/), 그리고 -만료되거나 실패한 리소스를 정리하기 위해 가비지 수집을 사용한다. +만료되거나 실패한 리소스 같은 리소스를 정리한다. + diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 3aed766d8a..f5393b5963 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -1,9 +1,9 @@ --- title: kubectl 치트 시트 - - - - +# reviewers: +# - erictune +# - krousey +# - clove content_type: concept weight: 10 # highlight it card: @@ -68,6 +68,11 @@ kubectl config get-contexts # 컨텍스트 리스트 kubectl config current-context # 현재 컨텍스트 출력 kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정 +kubectl config set-cluster my-cluster-name # kubeconfig에 클러스터 엔트리를 설정 + +# kubeconfig에 이 클라이언트가 발생시킨 요청에 사용할 프록시 서버의 URL을 구성한다. +kubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url + # 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword @@ -182,6 +187,9 @@ kubectl get pods --selector=app=cassandra -o \ kubectl get configmap myconfig \ -o jsonpath='{.data.ca\.crt}' +# 밑줄(`_`) 대신 대시(`-`)를 사용하여 base64 인코딩된 값을 조회 +kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}' + # 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/control-plane' # 으로 명명된 라벨의 결과를 제외) kubectl get node --selector='!node-role.kubernetes.io/control-plane' diff --git a/content/ko/docs/reference/labels-annotations-taints/_index.md b/content/ko/docs/reference/labels-annotations-taints/_index.md index 9aa175ef2a..e3ea1b9376 100644 --- a/content/ko/docs/reference/labels-annotations-taints/_index.md +++ b/content/ko/docs/reference/labels-annotations-taints/_index.md @@ -107,11 +107,11 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블 적용 대상: 네임스페이스 -({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인) -쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다. +({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인) +쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다. 레이블의 값은 네임스페이스의 이름으로 적용된다. 이 레이블의 값을 변경할 수는 없다. -레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 +레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 이 레이블이 유용할 수 있다. ## beta.kubernetes.io/arch (사용 중단됨) @@ -165,7 +165,7 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k 적용 대상: 파드 -이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을 +이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을 설정하기 위해 사용한다. 명시된 값은 `int32` 타입으로 파싱된다. ### kubernetes.io/ingress-bandwidth @@ -180,7 +180,7 @@ Example: `kubernetes.io/ingress-bandwidth: 10M` 적용 대상: 파드 -파드에 QoS(quality-of-service)를 적용함으로써 가용한 대역폭을 효과적으로 제한할 수 있다. +파드에 QoS(quality-of-service)를 적용함으로써 가용한 대역폭을 효과적으로 제한할 수 있다. 인그레스 트래픽(파드로 향하는)은 효과적으로 데이터를 처리하기 위해 대기 중인 패킷을 큐로 관리한다. 파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고 `kubernetes.io/ingress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 인그레스 속도를 명시할 때 사용되는 단위는 @@ -199,7 +199,7 @@ Example: `kubernetes.io/ingress-bandwidth: 10M` 적용 대상: 파드 -이그레스 트래픽(파드로부터의)은 설정된 속도를 초과하는 패킷을 삭제하는 정책에 의해 처리되며, +이그레스 트래픽(파드로부터의)은 설정된 속도를 초과하는 패킷을 삭제하는 정책에 의해 처리되며, 파드에 거는 제한은 다른 파드의 대역폭에 영향을 주지 않는다. 파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고 `kubernetes.io/egress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 이그레스 속도를 명시할 때 사용되는 단위는 @@ -216,9 +216,9 @@ Example: `kubernetes.io/ingress-bandwidth: 10M` 적용 대상: 노드 -`클라우드 제공자`에 의해 정의된 인스턴스 타입의 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. -`클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다. -특정 워크로드를 특정 인스턴스 타입에 할당하고 싶다면 이 레이블이 유용할 수 있다. +`클라우드 제공자`에 의해 정의된 인스턴스 타입의 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. +`클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다. +특정 워크로드를 특정 인스턴스 타입에 할당하고 싶다면 이 레이블이 유용할 수 있다. 하지만 일반적으로는 자원 기반 스케줄링을 수행하는 쿠버네티스 스케줄러를 이용하게 된다. 인스턴스 타입 보다는 특성을 기준으로 스케줄링을 고려해야 한다(예: `g2.2xlarge` 를 요구하기보다는, GPU가 필요하다고 요구한다). ## failure-domain.beta.kubernetes.io/region (사용 중단됨) {#failure-domainbetakubernetesioregion} @@ -239,10 +239,10 @@ Example: `kubernetes.io/ingress-bandwidth: 10M` `statefulset.kubernetes.io/pod-name=mystatefulset-7` -스테이트풀셋(StatefulSet) 컨트롤러가 파드를 위한 스테이트풀셋을 생성하면, 컨트롤 플레인이 파드에 이 레이블을 설정한다. +스테이트풀셋(StatefulSet) 컨트롤러가 파드를 위한 스테이트풀셋을 생성하면, 컨트롤 플레인이 파드에 이 레이블을 설정한다. 생성되는 파드의 이름을 이 레이블의 값으로 설정한다. -스테이트풀셋 문서의 [파드 이름 레이블](/ko/docs/concepts/workloads/controllers/statefulset/#파드-이름-레이블)에서 +스테이트풀셋 문서의 [파드 이름 레이블](/ko/docs/concepts/workloads/controllers/statefulset/#파드-이름-레이블)에서 상세 사항을 확인한다. ## topology.kubernetes.io/region {#topologykubernetesioregion} @@ -281,7 +281,7 @@ _SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클 스케줄러도 (_VolumeZonePredicate_ 표시자를 이용하여) '파드가 요청하는 볼륨'이 위치하는 영역과 같은 영역에 파드를 배치한다. 여러 영역에서 볼륨에 접근할 수는 없다. -`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다. +`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다. `PersistentVolumeLabel`이 설정되어 있으면, 스케줄러는 파드가 다른 영역에 있는 볼륨에 마운트하는 것을 막는다. 만약 사용 중인 인프라에 이러한 제약이 없다면, 볼륨에 영역 레이블을 추가할 필요가 전혀 없다. ## volume.beta.kubernetes.io/storage-provisioner (사용 중단됨) @@ -340,7 +340,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo Used on: 시크릿(Secret) -이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 +이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 서비스어카운트의 {{< glossary_tooltip term_id="name" text="이름">}}을 기록한다. ### kubernetes.io/service-account.uid @@ -349,7 +349,7 @@ Used on: 시크릿(Secret) 적용 대상: 시크릿 -이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 +이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 서비스어카운트의 {{< glossary_tooltip term_id="uid" text="고유 ID">}}를 기록한다. ## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} @@ -409,7 +409,7 @@ v1.18부터, `spec.ingressClassName`으로 대체되었다. 적용 대상: 스토리지클래스(StorageClass) -하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우, +하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우, 클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임 리소스는 해당 기본 클래스로 할당될 것이다. ## alpha.kubernetes.io/provided-node-ip @@ -428,7 +428,7 @@ kubelet이 "외부" 클라우드 제공자에 의해 실행되었다면, 명령 적용 대상: 파드 -kube-controller-manager의 잡(Job) 컨트롤러는 +kube-controller-manager의 잡(Job) 컨트롤러는 `Indexed` [완료 모드](/ko/docs/concepts/workloads/controllers/job/#완료-모드)로 생성된 파드에 이 어노테이션을 추가한다. ## kubectl.kubernetes.io/default-container @@ -451,7 +451,7 @@ v1.22 이상의 쿠버네티스 클러스터에서, 한 엔드포인트(Endpoint 적용 대상: 잡 -잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers) +잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers) 중임을 나타낸다. 어노테이션을 수동으로 추가하거나 제거하지 **않는다**. @@ -511,7 +511,7 @@ kubelet은 '`/proc/sys/kernel/pid_max`의 크기의 D-값'과 노드에서 쿠 예시: `node.kubernetes.io/out-of-service:NoExecute` -사용자는 노드에 테인트를 수동으로 추가함으로써 서비스 중이 아니라고 표시할 수 있다. 만약 `NodeOutOfServiceVolumeDetach` +사용자는 노드에 테인트를 수동으로 추가함으로써 서비스 중이 아니라고 표시할 수 있다. 만약 `NodeOutOfServiceVolumeDetach` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 `kube-controller-manager`에 활성화되어 있으며 노드가 이 테인트로 인해 서비스 중이 아니라고 표시되어있을 경우, 노드에서 실행되던 매칭되는 톨러레이션이 없는 파드들은 강제로 삭제됨과 동시에 볼륨이 분리된다. 이는 서비스 중이 아닌 노드의 파드들이 다른 노드에서 빠르게 복구될 수 있도록 해준다. @@ -540,9 +540,9 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 적용 대상: 네임스페이스 -값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 +값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 `privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다. -특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 +특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 모든 파드의 생성을 금지한다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 @@ -555,7 +555,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 적용 대상: 네임스페이스 값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다. -설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) +설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) 정책의 버전이 결정된다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 @@ -567,9 +567,9 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 적용 대상: 네임스페이스 -값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 +값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 `privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다. -특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을 +특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을 방지하지 않지만, 해당 파드에 audit 어노테이션을 추가한다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 @@ -582,7 +582,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 적용 대상: 네임스페이스 값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다. -설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) +설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) 정책의 버전이 결정된다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 @@ -594,11 +594,11 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 적용 대상: 네임스페이스 -값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 +값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 `privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다. -특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을 +특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을 방지하지는 않지만, 그러한 파드가 생성되면 사용자에게 경고를 반환한다. -디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 +디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 객체를 만들거나 업데이트할 때에도 경고가 표시된다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 @@ -611,27 +611,37 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 적용 대상: 네임스페이스 값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다. -설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) -정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 +설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) +정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 객체를 만들거나 업데이트할 때에도 경고가 표시된다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 참고한다. +### kubernetes.io/psp (사용 중단됨) {#kubernetes-io-psp} + +예시: `kubernetes.io/psp: restricted` + +이 어노테이션은 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/)를 사용하는 경우에만 관련있다. + +파드시큐리티폴리시 어드미션 컨트롤러가 파드를 승인하면, +어드미션 컨트롤러는 파드가 이 어노테이션을 갖도록 수정한다. +이 어노테이션 값은 유효성 검사에서 사용된 파드시큐리티폴리시의 이름이다. + ## seccomp.security.alpha.kubernetes.io/pod (사용 중단됨) {#seccomp-security-alpha-kubernetes-io-pod} -이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. -파드의 보안 설정을 지정하려면, 파드 스펙에 `securityContext` 필드를 추가한다. -파드의 `.spec` 내의 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) 필드는 파드 수준 보안 속성을 정의한다. -[파드의 보안 컨텍스트를 설정](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)하면, +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +파드의 보안 설정을 지정하려면, 파드 스펙에 `securityContext` 필드를 추가한다. +파드의 `.spec` 내의 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) 필드는 파드 수준 보안 속성을 정의한다. +[파드의 보안 컨텍스트를 설정](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)하면, 해당 설정이 파드 내의 모든 컨테이너에 적용된다. ## container.seccomp.security.alpha.kubernetes.io/[이름] {#container-seccomp-security-alpha-kubernetes-io} -이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. -[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/security/seccomp/) 튜토리얼에서 -seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다. -튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며, +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/security/seccomp/) 튜토리얼에서 +seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다. +튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며, 이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다. ### snapshot.storage.kubernetes.io/allowVolumeModeChange @@ -642,10 +652,10 @@ seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 값은 `true` 혹은 `false`만을 받는다. {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}이 -볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우, +볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우, 사용자가 소스 볼륨의 모드를 수정할 수 있는지 여부를 결정한다. -자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) +자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) 와 [쿠버네티스 CSI 개발자용 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. ## Audit을 위한 어노테이션들 @@ -669,8 +679,8 @@ seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 적용 대상: 노드 -kubeadm `init`/`join`시 주어지는 CRI 소켓 정보를 유지하기 위해 사용하는 어노테이션. -kubeadm은 노드 오브젝트를 이 정보를 주석 처리한다. 이상적으로는 KubeletConfiguration의 항목이어야 하기 때문에, +kubeadm `init`/`join`시 주어지는 CRI 소켓 정보를 유지하기 위해 사용하는 어노테이션. +kubeadm은 노드 오브젝트를 이 정보를 주석 처리한다. 이상적으로는 KubeletConfiguration의 항목이어야 하기 때문에, 어노테이션은 "alpha" 상태로 남아있다. ### kubeadm.kubernetes.io/etcd.advertise-client-urls @@ -688,7 +698,7 @@ etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위 적용 대상: 파드 -외부로 노출시킬 API 서버의 엔드포인트를 추적하기 위해, +외부로 노출시킬 API 서버의 엔드포인트를 추적하기 위해, 로컬에서 관리되는 kube-apiserver 파드에 배치되는 어노테이션. ### kubeadm.kubernetes.io/component-config.hash @@ -697,7 +707,7 @@ etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위 적용 대상: 컨피그맵(ConfigMap) -컴포넌트 설정을 관리하는 컨피그맵에 배치되는 어노테이션. +컴포넌트 설정을 관리하는 컨피그맵에 배치되는 어노테이션. 사용자가 특정 컴포넌트에 대해서 kubeadm 기본값과 다른 설정값을 적용했는지 판단하기 위한 해시(SHA-256)를 가지고 있다. ### node-role.kubernetes.io/control-plane diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index 1c1db61d1b..4ee0fba5cc 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -19,7 +19,7 @@ weight: 20 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/) -또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)) +또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)) 구조에 맞게 파일을 작성하고, `kube-scheduler --config `을 실행하여 스케줄링 프로파일을 지정할 수 있다. @@ -60,7 +60,7 @@ clientConnection: 구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로 표시된다. 1. `postFilter`: 이 플러그인은 파드의 실행 가능한 노드를 찾을 수 없을 때, - 구성된 순서대로 호출된다. `postFilter` 플러그인이 파드 _schedulable_ 을 표시하는 경우, + 구성된 순서대로 호출된다. `postFilter` 플러그인이 파드 _schedulable_ 을 표시하는 경우, 나머지 플러그인은 호출 되지 않는다. 1. `preScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는 정보성 익스텐션 포인트이다. @@ -78,7 +78,7 @@ clientConnection: 플러그인은 적어도 하나 이상 필요하다. 1. `postBind`: 파드가 바인드된 후 호출되는 정보성 익스텐션 포인트이다. -1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해 +1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해 플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드이다. 각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나 @@ -122,7 +122,7 @@ profiles: [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를 구현한다. 익스텐션 포인트: `filter`, `score`. -- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를 +- `PodTopologySpread`: [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)을 구현한다. 익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`. - `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를 @@ -174,7 +174,7 @@ profiles: - `SelectorSpread`: {{< glossary_tooltip text="Services" term_id="service" >}}, {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}와 - {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우, + {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우, 노드간에 퍼지는 것을 선호한다. 익스텐션 포인트: `preScore`, `score`. - `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/) @@ -231,13 +231,13 @@ profiles: ### 다수의 익스텐션 포인트에 플러그인 적용하기 {#multipoint} -`kubescheduler.config.k8s.io/v1beta3` 부터, -다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나 -비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다. +`kubescheduler.config.k8s.io/v1beta3` 부터, +다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나 +비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다. 이를 사용하여 사용자와 관리자가 커스텀 프로파일을 사용할 때 환경 설정을 간소화할 수 있다. -`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자. -모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면, +`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자. +모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면, 다음과 같은 프로파일 환경 설정을 사용한다. ```yaml @@ -251,7 +251,7 @@ profiles: - name: MyPlugin ``` -위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과 +위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과 동일한 효과를 갖는다. ```yaml @@ -274,13 +274,13 @@ profiles: - name: MyPlugin ``` -여기서 `multiPoint` 를 사용했을 때의 이점은, -추후 `MyPlugin` 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때, +여기서 `multiPoint` 를 사용했을 때의 이점은, +추후 `MyPlugin` 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때, 새로운 익스텐션에 대해서도 `multiPoint` 환경 설정이 자동으로 활성화될 것이라는 점이다. -`disabled` 필드를 사용하여, `MultiPoint` 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다. -기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나, -와일드카드(`'*'`)를 사용하여 모든 플러그인을 비활성화할 수 있다. +`disabled` 필드를 사용하여, `MultiPoint` 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다. +기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나, +와일드카드(`'*'`)를 사용하여 모든 플러그인을 비활성화할 수 있다. 다음은 `Score` 와 `PreScore` 에 대해 비활성화하는 예시이다. ```yaml @@ -300,10 +300,10 @@ profiles: - name: '*' ``` -`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다. -그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다. -예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고 -각각의 가중치가 `1` 이라고 하자. +`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다. +그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다. +예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고 +각각의 가중치가 `1` 이라고 하자. 이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다. ```yaml @@ -318,10 +318,10 @@ profiles: weight: 5 ``` -이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데, -이는 이 플러그인들이 기본 플러그인이기 때문이다. -그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다. -이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다. +이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데, +이는 이 플러그인들이 기본 플러그인이기 때문이다. +그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다. +이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다. 결론적으로, 위의 예시에서는 두 플러그인을 모두 명시하지 않고도 두 플러그인의 순서를 조정하였다. `MultiPoint` 플러그인을 설정할 때, 일반적인 우선 순위는 다음과 같다. @@ -363,8 +363,8 @@ profiles: - name: 'DefaultPlugin2' ``` -명시한 익스텐션 포인트 내에 `MultiPoint` 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다. -명시한 익스텐션 포인트의 우선 순위가 더 높으므로, +명시한 익스텐션 포인트 내에 `MultiPoint` 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다. +명시한 익스텐션 포인트의 우선 순위가 더 높으므로, 이 재정의는 무시되고 로그에만 기록된다. 대부분의 환경 설정을 한 곳에서 관리하는 것 말고도, 이 예시는 다음과 같은 내용을 포함한다. @@ -380,14 +380,14 @@ kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: - + # 기본 QueueSort 플러그인을 비활성화한다 queueSort: enabled: - name: 'CustomQueueSort' disabled: - name: 'DefaultQueueSort' - + # 커스텀 Filter 플러그인을 활성화한다 filter: enabled: @@ -396,7 +396,7 @@ profiles: - name: 'DefaultPlugin2' disabled: - name: 'DefaultPlugin1' - + # 커스텀 score 플러그인을 활성화하고 순서를 조정한다 score: enabled: @@ -406,19 +406,19 @@ profiles: weight: 3 ``` -다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 `MultiPoint` 환경 설정의 유연성과 +다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 `MultiPoint` 환경 설정의 유연성과 기존 방법과의 끊김없는 통합을 확인할 수 있다. ## 스케줄러 설정 전환 {{< tabs name="tab_with_md" >}} {{% tab name="v1beta1 → v1beta2" %}} -* 설정 버전 v1beta2 에서는, `NodeResourcesFit` 플러그인을 위한 새로운 스코어링 확장을 +* 설정 버전 v1beta2 에서는, `NodeResourcesFit` 플러그인을 위한 새로운 스코어링 확장을 이용할 수 있다. - 새 확장은 `NodeResourcesLeastAllocated`, `NodeResourcesMostAllocated`, + 새 확장은 `NodeResourcesLeastAllocated`, `NodeResourcesMostAllocated`, `RequestedToCapacityRatio` 플러그인의 기능을 통합하여 제공한다. - 예를 들어, 이전에 `NodeResourcesMostAllocated` 플러그인을 사용했다면, - 대신 `NodeResourcesFit`(기본적으로 활성화되어 있음)을 사용하면서 + 예를 들어, 이전에 `NodeResourcesMostAllocated` 플러그인을 사용했다면, + 대신 `NodeResourcesFit`(기본적으로 활성화되어 있음)을 사용하면서 다음과 같이 `scoreStrategy`를 포함하는 `pluginConfig`를 추가할 수 있다. ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index 39e0acc172..4716e1081f 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -1,9 +1,9 @@ --- title: API 개요 - - - - +# reviewers: +# - erictune +# - lavalamp +# - jbeda content_type: concept weight: 10 no_list: true @@ -39,7 +39,7 @@ JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다. API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. -[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/design-proposals-archive/release/versioning.md)에는 +[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/sig-release/release-engineering/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md index 93ab353d37..bf7284dca0 100644 --- a/content/ko/docs/setup/best-practices/multiple-zones.md +++ b/content/ko/docs/setup/best-practices/multiple-zones.md @@ -1,4 +1,8 @@ --- +# reviewers: +# - jlowdermilk +# - justinsb +# - quinton-hoole title: 여러 영역에서 실행 weight: 20 content_type: concept @@ -58,7 +62,7 @@ content_type: concept [영역 정보](/ko/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다. 클러스터가 여러 영역 또는 지역에 걸쳐있는 경우, -[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과 +[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)과 함께 노드 레이블을 사용하여 파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에 분산되는 방식을 제어할 수 있다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 02398df6a7..eda9c1f8f6 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -1,7 +1,7 @@ --- - - - +# reviewers: +# - vincepri +# - bart0sh title: 컨테이너 런타임 content_type: concept weight: 20 @@ -15,13 +15,13 @@ weight: 20 설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고 노드 설정 관련 작업을 설명한다. -쿠버네티스 {{< skew currentVersion >}}에서는 -{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는 +쿠버네티스 {{< skew currentVersion >}}에서는 +{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는 런타임을 사용해야 한다. 더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다. -이 페이지는 쿠버네티스에서 +이 페이지는 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한 개요를 제공한다. - [containerd](#containerd) @@ -30,17 +30,17 @@ weight: 20 - [미란티스 컨테이너 런타임](#mcr) {{< note >}} -쿠버네티스 v1.24 이전 릴리스는 -_dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다. -이 특별한 직접 통합은 -더 이상 쿠버네티스에 포함되지 않는다(이 제거는 -v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다). -이 제거가 어떻게 영향을 미치는지 알아보려면 -[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. -dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, +쿠버네티스 v1.24 이전 릴리스는 +_dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다. +이 특별한 직접 통합은 +더 이상 쿠버네티스에 포함되지 않는다(이 제거는 +v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다). +이 제거가 어떻게 영향을 미치는지 알아보려면 +[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. +dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, [dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다. -v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면, +v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면, 해당 버전의 문서를 참고한다. {{< /note >}} @@ -84,7 +84,7 @@ sudo sysctl --system ## cgroup 드라이버 -리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은 +리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은 프로세스에 할당된 리소스를 제한하는데 사용된다. 리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인 @@ -116,7 +116,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. ### Cgroup 버전 2 {#cgroup-v2} -cgroup v2는 cgroup Linux API의 다음 버전이다. +cgroup v2는 cgroup Linux API의 다음 버전이다. cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다. 새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다. @@ -125,16 +125,16 @@ cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계 - 컨테이너로의 안전한 하위 트리 위임 - 압력 중지 정보와 같은 새로운 기능 -일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도, -쿠버네티스는 모든 컨트롤러를 관리하기 위해 +일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도, +쿠버네티스는 모든 컨트롤러를 관리하기 위해 동일한 cgroup 버전만 지원한다. -systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을 +systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을 추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다. ```shell # 이 예제는 리눅스 OS에서 DNF 패키지 관리자를 사용하는 경우에 대한 것이다. -# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해 +# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해 # 사용자의 시스템이 다른 방법을 사용하고 있을 수도 있다. sudo dnf install -y grubby && \ sudo grubby \ @@ -142,17 +142,17 @@ sudo dnf install -y grubby && \ --args="systemd.unified_cgroup_hierarchy=1" ``` -커널이 사용하는 커맨드 라인을 업데이트하려면, +커널이 사용하는 커맨드 라인을 업데이트하려면, 변경 사항을 적용하기 위해 노드를 재시작해야 한다. -cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서 +cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서 cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다. cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다. ### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기 -기존에 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면, +기존에 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면, [cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다. ## CRI 버전 지원 {#cri-versions} @@ -160,7 +160,7 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 사용할 컨테이너 런타임이 적어도 CRI의 v1alpha2 이상을 지원해야 한다. 쿠버네티스 {{< skew currentVersion >}} 버전에서는 기본적으로 CRI API 중 v1을 사용한다. -컨테이너 런타임이 v1 API를 지원하지 않으면, +컨테이너 런타임이 v1 API를 지원하지 않으면, kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된다. ## 컨테이너 런타임 @@ -217,7 +217,7 @@ kubeadm을 사용하는 경우, #### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-containerd} -[containerd 설정](https://github.com/containerd/cri/blob/master/docs/config.md)에서 +[containerd 설정](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)에서 아래와 같이 샌드박스 이미지를 덮어쓸 수 있다. ```toml @@ -235,9 +235,9 @@ CRI-O를 설치하려면, [CRI-O 설치 방법](https://github.com/cri-o/cri-o/b #### cgroup 드라이버 -CRI-O는 기본적으로 systemd cgroup 드라이버를 사용하며, 이는 대부분의 경우에 잘 동작할 것이다. -`cgroupfs` cgroup 드라이버로 전환하려면, `/etc/crio/crio.conf` 를 수정하거나 -`/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 드롭-인(drop-in) 구성을 배치한다. +CRI-O는 기본적으로 systemd cgroup 드라이버를 사용하며, 이는 대부분의 경우에 잘 동작할 것이다. +`cgroupfs` cgroup 드라이버로 전환하려면, `/etc/crio/crio.conf` 를 수정하거나 +`/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 드롭-인(drop-in) 구성을 배치한다. 예를 들면 다음과 같다. ```toml @@ -269,46 +269,46 @@ live configuration reload 기능을 지원한다. ### 도커 엔진 {#docker} {{< note >}} -아래의 지침은 -당신이 도커 엔진과 쿠버네티스를 통합하는 데 +아래의 지침은 +당신이 도커 엔진과 쿠버네티스를 통합하는 데 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 어댑터를 사용하고 있다고 가정한다. {{< /note >}} -1. 각 노드에서, [도커 엔진 설치하기](https://docs.docker.com/engine/install/#server)에 따라 +1. 각 노드에서, [도커 엔진 설치하기](https://docs.docker.com/engine/install/#server)에 따라 리눅스 배포판에 맞게 도커를 설치한다. -2. [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 소스 코드 저장소의 지침대로 +2. [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 소스 코드 저장소의 지침대로 `cri-dockerd`를 설치한다. `cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다. #### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd} -`cri-dockerd` 어댑터는, +`cri-dockerd` 어댑터는, 파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다. 해당 커맨드라인 인자는 `--pod-infra-container-image`이다. ### 미란티스 컨테이너 런타임 {#mcr} -[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며 +[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며 이전에는 도커 엔터프라이즈 에디션으로 알려져 있었다. -오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며, +오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며, 이 컴포넌트는 MCR에 포함되어 있다. -미란티스 컨테이너 런타임을 설치하는 방법에 대해 더 알아보려면, +미란티스 컨테이너 런타임을 설치하는 방법에 대해 더 알아보려면, [MCR 배포 가이드](https://docs.mirantis.com/mcr/20.10/install.html)를 참고한다. -CRI 소켓의 경로를 찾으려면 +CRI 소켓의 경로를 찾으려면 `cri-docker.socket`라는 이름의 systemd 유닛을 확인한다. #### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd-mcr} -`cri-dockerd` 어댑터는, +`cri-dockerd` 어댑터는, 파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다. 해당 커맨드라인 인자는 `--pod-infra-container-image`이다. ## {{% heading "whatsnext" %}} -컨테이너 런타임과 더불어, 클러스터에는 +컨테이너 런타임과 더불어, 클러스터에는 동작하는 [네트워크 플러그인](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)도 필요하다. diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md index 2651406491..5f6003c504 100644 --- a/content/ko/docs/setup/production-environment/tools/kubespray.md +++ b/content/ko/docs/setup/production-environment/tools/kubespray.md @@ -8,18 +8,23 @@ weight: 30 이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다. -Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다. +Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md#inventory), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다. +Kubespray 지원 사항 * 고가용성을 지닌 클러스터 -* 구성할 수 있는 속성들 +* 구성 가능 (인스턴스를 위한 네트워크 플러그인 선택) * 대부분의 인기있는 리눅스 배포판들에 대한 지원 - * Ubuntu 16.04, 18.04, 20.04, 22.04 - * CentOS/RHEL/Oracle Linux 7, 8 - * Debian Buster, Jessie, Stretch, Wheezy - * Fedora 34, 35 - * Fedora CoreOS - * openSUSE Leap 15 - * Flatcar Container Linux by Kinvolk + - Flatcar Container Linux by Kinvolk + - Debian Bullseye, Buster, Jessie, Stretch + - Ubuntu 16.04, 18.04, 20.04, 22.04 + - CentOS/RHEL 7, 8 + - Fedora 34, 35 + - Fedora CoreOS + - openSUSE Leap 15.x/Tumbleweed + - Oracle Linux 7, 8 + - Alma Linux 8 + - Rocky Linux 8 + - Amazon Linux 2 * 지속적인 통합 (CI) 테스트 클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자. @@ -33,13 +38,13 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h 언더레이(underlay) [요건](https://github.com/kubernetes-sigs/kubespray#requirements)을 만족하는 프로비전 한다. -* **Ansible의 명령어를 실행하기 위해 Ansible v 2.11와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다** -* **Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다** -* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) -* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다 -* **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다 -* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다 -* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 +* **쿠버네티스는 최소한 v1.22 이상의 버전이 필요하다.** +* **Ansible의 명령어를 실행하기 위해 Ansible v2.11+, Jinja 2.11+와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**. +* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 **인터넷에 접속**할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) +* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다. +* 파드와 서비스에서 IPv6를 이용한다면, 대상 서버도 **IPv6 포워딩**이 활성화되어야 한다. +* **방화벽은 kubespray가 관리하지 않는다**. 사용자는 기존 방식으로 자신의 규칙을 구현해야 한다. 배포 중에 만날 문제를 예방하려면 방화벽을 비활성화해야 한다. +* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 상승 방법이 설정되어야 한다. 그 후에 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다: @@ -115,5 +120,5 @@ reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타 ## {{% heading "whatsnext" %}} - -Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자. +* Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자. +* [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 더 알아보자.