kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #29843 from jihoon-seo/210928_Update_outdated_files_in_dev-1.22-ko.1_p7 

[ko] Update outdated files in dev-1.22-ko.1 (p7)
pull/29998/head
Kubernetes Prow Robot 2021-10-06 22:47:46 -07:00 committed by GitHub
parent 6aa0912947 5894fa3942
commit ab52a12ff0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 110 additions and 75 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
content/ko/docs/concepts/storage/storage-classes.md
View File

@ -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

61
content/ko/docs/concepts/storage/volumes.md
View File

@ -124,7 +124,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
컨트롤러 관리자와 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}

7
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는
## 크론잡
크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인
작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다.
각 작업은 무기한 반복되도록 구성해야 한다(예:
1일/1주/1달마다 1회).
작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다.
### 예시

6
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면,
파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.

72
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -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) 파드

8
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -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`](/ko/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 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.