From 5894fa3942d67b057edf21242a04b889b0e35a3c Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 28 Sep 2021 17:27:27 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.22-ko.1 (p7) --- .../docs/concepts/storage/storage-classes.md | 31 +++++++- content/ko/docs/concepts/storage/volumes.md | 61 ++++------------ .../workloads/controllers/cron-jobs.md | 7 +- .../workloads/controllers/daemonset.md | 6 +- .../concepts/workloads/controllers/job.md | 72 ++++++++++++++----- .../workloads/controllers/replicaset.md | 8 +-- 6 files changed, 110 insertions(+), 75 deletions(-) diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index f4385419f1..c915b65fad 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -76,7 +76,7 @@ volumeBindingMode: Immediate | Glusterfs | ✓ | [Glusterfs](#glusterfs) | | iSCSI | - | - | | Quobyte | ✓ | [Quobyte](#quobyte) | -| NFS | - | - | +| NFS | - | [NFS](#nfs) | | RBD | ✓ | [Ceph RBD](#ceph-rbd) | | VsphereVolume | ✓ | [vSphere](#vsphere) | | PortworxVolume | ✓ | [Portworx 볼륨](#portworx-볼륨) | @@ -423,6 +423,29 @@ parameters: 헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을 삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다. +### NFS + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: example-nfs +provisioner: example.com/external-nfs +parameters: + server: nfs-server.example.com + path: /share + readOnly: false +``` + +* `server`: NFS 서버의 호스트네임 또는 IP 주소. +* `path`: NFS 서버가 익스포트(export)한 경로. +* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false). + +쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다. +예시는 다음과 같다. +* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner) +* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner) + ### OpenStack Cinder ```yaml @@ -578,6 +601,12 @@ parameters: ### Quobyte +{{< feature-state for_k8s_version="v1.22" state="deprecated" >}} + +Quobyte 인-트리 스토리지 플러그인은 사용 중단되었으며, +아웃-오브-트리 Quobyte 플러그인에 대한 [예제](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml) +`StorageClass`는 Quobyte CSI 저장소에서 찾을 수 있다. + ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 050566388e..349f47a55c 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -124,7 +124,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지 -플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `true` 로 설정한다. 이 기능은 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다. +플러그인을 끄려면, `InTreePluginAWSUnregister` 플래그를 `true` 로 설정한다. ### azureDisk {#azuredisk} @@ -462,7 +462,8 @@ spec: required: nodeSelectorTerms: - matchExpressions: - - key: failure-domain.beta.kubernetes.io/zone + # 1.21 이전 버전에서는 failure-domain.beta.kubernetes.io/zone 키를 사용해야 한다. + - key: topology.kubernetes.io/zone operator: In values: - us-central1-a @@ -480,6 +481,13 @@ GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` 베타 기능을 활성화해야 한다. +#### GCE CSI 마이그레이션 완료 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +컨트롤러 매니저와 kubelet이 `gcePersistentDisk` 스토리지 플러그인을 로드하는 것을 방지하려면, +`InTreePluginGCEUnregister` 플래그를 `true`로 설정한다. + ### gitRepo (사용 중단됨) {#gitrepo} {{< warning >}} @@ -931,7 +939,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마 해당 볼륨 소스의 업데이트를 수신하지 않는다. {{< /note >}} -### quobyte +### quobyte (사용 중단됨) {#quobyte} `quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을 파드에 마운트할 수 있다. @@ -967,49 +975,6 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를 참고한다. -### scaleIO (사용 중단됨) {#scaleio} - -ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를 -생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨 -플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수 -있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는 -방법에 대한 자세한 내용은 -[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다. - -{{< note >}} -사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고 -생성한 볼륨과 함께 실행해야 한다. -{{< /note >}} - -다음의 예시는 ScaleIO를 사용하는 파드 구성이다. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: pod-0 -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: pod-0 - volumeMounts: - - mountPath: /test-pd - name: vol-0 - volumes: - - name: vol-0 - scaleIO: - gateway: https://localhost:443/api - system: scaleio - protectionDomain: sd0 - storagePool: sp1 - volumeName: vol-0 - secretRef: - name: sio-secret - fsType: xfs -``` - -더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/master/staging/volumes/scaleio) 예제를 참고한다. - ### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 @@ -1029,7 +994,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다. -### storageOS {#storageos} +### storageOS (사용 중단됨) {#storageos} `storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) 볼륨을 파드에 마운트할 수 있다. @@ -1177,7 +1142,7 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 {{< feature-state for_k8s_version="v1.19" state="beta" >}} -`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다. +`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다. ## subPath 사용하기 {#using-subpath} diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 6935cf8fb4..740929b05c 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는 ## 크론잡 -크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인 -작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을 -스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다. +크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다. +각 작업은 무기한 반복되도록 구성해야 한다(예: +1일/1주/1달마다 1회). +작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다. ### 예시 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 1496b25ec3..dc8f543048 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 -디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, -다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다. +디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면, +파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다. + +예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 4972df45cd..21da00ff5a 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -187,14 +187,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 ### 완료 모드 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} - -{{< note >}} -인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/) -및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서 -`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화해야 한다. -{{< /note >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} 완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은 `.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다. @@ -203,8 +196,14 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드 완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는 잡은 암시적으로 `NonIndexed` 이다. -- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index` - 어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다. +- `Indexed`: 잡의 파드는 연결된 완료 인덱스를 0에서 `.spec.completions-1` 까지 + 가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다. + - 파드 어노테이션 `batch.kubernetes.io/job-completion-index`. + - 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). 인덱스된(Indexed) 잡과 + {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 + 있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 + 호스트네임을 사용할 수 있다. + - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수. 각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로 간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은 [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다. @@ -255,7 +254,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 ## 잡의 종료와 정리 -잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다. 이를 유지하면 +잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다. +이를 유지하면 완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다. 잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다. `kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다. @@ -402,14 +402,12 @@ spec: ### 잡 일시 중지 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} {{< note >}} -잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을 -사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/) -및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서 -`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화해야 한다. +이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며, +이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다. +[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다. {{< /note >}} 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해 @@ -568,6 +566,46 @@ spec: `manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런 불일치를 허용한다. +### 종료자(finalizers)를 이용한 잡 추적 + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +{{< note >}} +이 기능을 이용하기 위해서는 +[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와 +[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해 +`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +기본적으로는 비활성화되어 있다. + +이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. +기존에 존재하던 잡은 영향을 받지 않는다. +사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다. +{{< /note >}} + +이 기능이 활성화되지 않으면, 잡 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 +`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다. +그런데, 파드는 다음과 같은 이유로 제거될 수 있다. +- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거 +- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를 + 일정 임계값 이후에 제거 +- 잡에 속한 파드를 사용자가 임의로 제거 +- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나 + 교체 + +클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면, +컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고 +API 서버에서 파드가 제거되면 이를 알아챈다. +이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다. +컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로, +이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다. + +잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다. +이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다. +잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여, +잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다. +이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**. + ## 대안 ### 베어(Bare) 파드 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 7cf399d242..14056eef1d 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -323,7 +323,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron 모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다. ### 파드 삭제 비용 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다. @@ -335,9 +335,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron 파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다. 유효하지 않은 값은 API 서버가 거부한다. -이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다. -kube-apiserver와 kube-controller-manager에서 `PodDeletionCost` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다. +이 기능은 베타 상태이며 기본적으로 활성화되어 있다. +kube-apiserver와 kube-controller-manager에 대해 `PodDeletionCost` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다. {{< note >}} - 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.