Third Korean l10n work for release 1.18
- Translate cluster-administration/networking.md in Korean - Fix issue with concepts/storage/volumes.md - Translate /concepts/configuration/pod-overhead in Korean - Update to Outdated files in the dev-1.18-ko.3 branch. - Translate concepts/configuration/configmap.md in Korean - Translate contribute/review/reviewing-prs/ in Korean - Translate concepts/configuration/pod-priority-preemption.md in Korean - Translate tasks/configure-pod-container/configure-volume-storage in Korean - Translate contribute/new-content/new-content/ in Korean - Translate concepts/architecture/control-plane-node-communication.md in Korean - Restore the deleted master-node-communication.md file - Translate concepts/cluster-administration/addons.md in Korean - Translate contribute/new-content/overview/ in Korean - Translate tasks/tools/install-kubectl.md in Korean - Translate concepts/configuration/manage-resources-containers.md in Korean - Translate tasks/administer-cluster/kubeadm/kubeadm-upgrade/ in Korean - add new words to Korean glossary and fix minor - Translate contribute/style/_index.md in Korean - Translate concepts/cloud-administration/cloud-providers.md in Korean - Translate contribute/review/for-approvers.md in Korean Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com> Co-authored-by: SangshikLee <neolss@gmail.com>
This commit is contained in:
committed by
Claudia J.Kang
parent
c74ce882ec
commit
ca62e21766
@@ -296,12 +296,13 @@ parameters:
|
||||
|
||||
`replication-type` 이 `regional-pd` 로 설정되면,
|
||||
[지역 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds)
|
||||
가 프로비전된다. 이 경우, 사용자는 `zone` 대신 `zones` 를 사용해서 원하는
|
||||
복제 영역을 지정해야 한다. 정확히 두 개의 영역이 지정된 경우, 해당
|
||||
영역에서 지역 PD가 프로비전된다. 둘 이상의 영역이 지정되면
|
||||
쿠버네티스는 지정된 영역 중에서 임의로 선택한다. `zones` 파라미터가 생략되면,
|
||||
쿠버네티스는 클러스터가 관리하는 영역 중에서
|
||||
임의로 선택한다.
|
||||
가 프로비전된다. 이는 퍼시스턴트볼륨클레임과 스토리지클래스를 소모하는 파드를
|
||||
생성할 때 지역 퍼시스턴트 디스크는 두개의 영역으로
|
||||
프로비전되기에 `volumeBindingMode: WaitForFirstConsumer` 를
|
||||
설정하는 것을 강력히 권장한다. 하나의 영역은 파드가 스케줄된
|
||||
영역과 동일하다. 다른 영역은 클러스터에서 사용할 수
|
||||
있는 영역에서 임의로 선택된다. 디스크 영역은 `allowedTopologies` 를
|
||||
사용하면 더 제한할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
`zone` 과 `zones` 파라미터는 사용 중단 되었으며,
|
||||
|
||||
@@ -6,7 +6,7 @@ weight: 20
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.17" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -55,7 +55,9 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
|
||||
|
||||
### 스냅샷 소스 보호로서의 퍼시스턴트 볼륨 클레임
|
||||
|
||||
이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에).
|
||||
이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인
|
||||
{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}
|
||||
API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에).
|
||||
|
||||
퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 객체를 삭제한다면, 퍼시스턴트볼륨클레임 객체는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 객체 삭제는 스냅샷이 준비(readyTouse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 10
|
||||
컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때
|
||||
애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면,
|
||||
kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상태로
|
||||
시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때
|
||||
시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때
|
||||
컨테이너 사이에 파일을 공유해야 하는 경우가 자주 발생한다. 쿠버네티스의
|
||||
`볼륨` 추상화는 이 두 가지 문제를 모두 해결한다.
|
||||
|
||||
@@ -22,7 +22,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상
|
||||
|
||||
## 배경
|
||||
|
||||
도커는 다소 느슨하고, 덜 관리되지만
|
||||
도커는 다소 느슨하고, 덜 관리되지만
|
||||
[볼륨](https://docs.docker.com/engine/admin/volumes/)이라는
|
||||
개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는
|
||||
다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는
|
||||
@@ -70,7 +70,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상
|
||||
* [csi](#csi)
|
||||
* [downwardAPI](#downwardapi)
|
||||
* [emptyDir](#emptydir)
|
||||
* [fc (파이버 채널))](#fc)
|
||||
* [fc (파이버 채널)](#fc)
|
||||
* [flexVolume](#flexVolume)
|
||||
* [flocker](#flocker)
|
||||
* [gcePersistentDisk](#gcepersistentdisk)
|
||||
@@ -496,7 +496,7 @@ gitRepo 볼륨 유형은 사용 중단(deprecated)되었다. git repo가 있는
|
||||
|
||||
`gitRepo` 볼륨은 볼륨 플러그인으로 할 수 있는 예시이다. 빈
|
||||
디렉터리를 마운트하고 파드가 사용할 수 있도록 해당 디렉터리에 git 리포지트리를
|
||||
복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에
|
||||
복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에
|
||||
이런 볼륨은 훨씬 더 분리된 모델로 이동될 수 있다.
|
||||
|
||||
여기 gitRepo 볼륨의 예시가 있다.
|
||||
@@ -1031,7 +1031,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
|
||||
|
||||
### storageOS {#storageos}
|
||||
|
||||
`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com)
|
||||
`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com)
|
||||
볼륨을 파드에 마운트할 수 있다.
|
||||
|
||||
StorageOS 는 쿠버네티스 환경에서 컨테이너로 실행되므로
|
||||
|
||||
Reference in New Issue
Block a user