Tenth Korean l10n work for release 1.18

- Translate concepts/extend-kubenetes/service-catalog.md in Korean (#23233)
- Translate concepts/configuration/secret.md into Korean (#23110)
- Translate tasks/extend-kubernetes/setup-extension-api-server.md into … (#22574)
- Update outdated files in dev-1.18-ko.10 branch (#23013)

Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: santachopa <santachopa@naver.com>
This commit is contained in:
Jerry Park
2020-08-07 06:25:21 +00:00
committed by June Yi
parent 7874c4d536
commit 6166f99892
79 changed files with 2570 additions and 1093 deletions
@@ -45,13 +45,14 @@ weight: 60
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
앞의 명령은
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}
오브젝트와 연관된
[레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
{{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}
오브젝트를 생성한다. 레플리카셋은 두 개의
[파드](/ko/docs/concepts/workloads/pods/pod/)를 갖고,
{{< glossary_tooltip text="파드" term_id="pod" >}}를 갖고,
각각은 Hello World 애플리케이션을 실행한다.
1. 디플로이먼트에 대한 정보를 보여준다.
```shell
kubectl get deployments hello-world
@@ -155,4 +156,3 @@ weight: 60
[서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에
대해 더 알아본다.
@@ -4,7 +4,7 @@ content_type: task
---
<!-- overview -->
이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
변경하는 방법을 보여준다.
@@ -19,14 +19,14 @@ content_type: task
## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가?
`PersistentVolumes` 은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한
다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 `PersistentVolumes` 의 경우
기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면,
퍼시스턴트볼륨은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한
다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 퍼시스턴트볼륨의 경우
기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면,
동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다.
볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다.
이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다.
"Retain" 정책에서, 사용자가 `PersistentVolumeClaim` 을 삭제할 경우 해당하는
`PersistentVolume` 은 삭제되지 않는다.
"Retain" 정책에서, 사용자가 퍼시스턴트볼륨클레임을 삭제할 경우 해당하는
퍼시스턴트볼륨은 삭제되지 않는다.
대신, `Released` 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다.
## 퍼시스턴트볼륨 반환 정책 변경하기
@@ -44,7 +44,7 @@ content_type: task
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다.
1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다.
@@ -77,8 +77,8 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
볼륨은 자동으로 삭제 되지 않는다.
@@ -93,5 +93,3 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기.
@@ -137,7 +137,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
### 윈도우 워커 노드 조인(joining)
{{< note >}}
`Containers` 기능을 설치하고 도커를 설치해야 한다.
[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)에서 설치에 대한 내용을 참고할 수 있다.
{{< /note >}}
{{< note >}}
@@ -181,5 +181,3 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드
- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
@@ -14,7 +14,7 @@ content_template: task
직접 관리된다.
컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리,
kubelet 이 각각의 스태틱 파드를 감시한다.
(만약 충돌이 날 경우 다시 구동한다.)
(만약 실패할 경우 다시 구동한다.)
스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다.
@@ -0,0 +1,5 @@
---
title: "쿠버네티스 확장"
description: 쿠버네티스 클러스터를 작업 환경의 요구에 맞게 조정하는 고급 과정을 이해한다.
weight: 90
---
@@ -0,0 +1,53 @@
---
title: 확장 API 서버 설정
content_type: task
weight: 15
---
<!-- overview -->
애그리게이션 레이어(aggregation layer)와 작동하도록 확장 API 서버를 설정하면 쿠버네티스 API 서버를 쿠버네티스의 핵심 API의 일부가 아닌 추가 API로 확장할 수 있다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* [애그리게이션 레이어를 구성](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)하고 apiserver 플래그를 활성화해야 한다.
<!-- steps -->
## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정
다음 단계는 확장 API 서버를 *높은 수준* 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)를 참고할 수 있다.
또는, [apiserver-builder](https://github.com/kubernetes-sigs/apiserver-builder-alpha/blob/master/README.md)와 같은 기존의 타사 솔루션을 사용하여 스켈레톤(skeleton)을 생성하고 다음 단계를 모두 자동화해야 한다.
1. API서비스(APIService) API가 활성화되어 있는지 확인한다(`--runtime-config` 확인). 클러스터에서 일부러 해제하지 않았다면, 기본적으로 활성화되어 있어야 한다.
1. API서비스 오브젝트를 추가하거나 클러스터 관리자가 작성하도록 RBAC 규칙을 작성해야 할 수도 있다. (API 확장은 전체 클러스터에 영향을 주기 때문에, 운영 중인 클러스터에서 API 확장에 대한 테스트/개발/디버깅을 수행하지 않는 것이 좋다.)
1. 확장 API 서비스를 실행하려는 쿠버네티스 네임스페이스를 생성한다.
1. HTTPS를 위해 확장 API 서버가 사용하는 서버 인증서에 서명하는 데 사용할 CA 인증서를 생성하거나 가져온다.
1. HTTPS를 위해 API 서버가 사용할 서버 인증서/키를 생성한다. 이 인증서는 위의 CA 인증서에 의해 서명해야 한다. 또한 Kube DNS 이름의 CN이 있어야 한다. 이것은 쿠버네티스 서비스에서 파생되었으며 `<service name>.<service name namespace>.svc` 형식이다.
1. 네임스페이스에 서버 인증서/키를 사용하여 쿠버네티스 시크릿을 생성한다.
1. 확장 API 서버에 대한 쿠버네티스 디플로이먼트를 생성하고 시크릿을 볼륨으로 로드하는지 확인한다. 확장 API 서버의 작동하는(working) 이미지에 대한 참조를 포함해야 한다. 디플로이먼트는 네임스페이스에도 있어야 한다.
1. 확장 API 서버가 해당 볼륨에서 해당 인증서를 로드하고 HTTPS 핸드셰이크에 사용되는지 확인한다.
1. 네임스페이스에서 쿠버네티스 서비스 어카운트를 생성한다.
1. 리소스에 허용하려는 작업에 대한 쿠버네티스 클러스터 롤(role)을 생성한다.
1. 네임스페이스의 서비스 어카운트에서 방금 만든 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 생성한다.
1. 네임스페이스의 서비스 어카운트에서 `system:auth-delegator` 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 만들어 인증 결정을 쿠버네티스 핵심 API 서버에 위임한다.
1. 네임스페이스의 서비스 어카운트에서 `extension-apiserver-authentication-reader` 롤로 쿠버네티스 롤 바인딩을 생성한다. 이를 통해 확장 API 서버가 `extension-apiserver-authentication` 컨피그맵(configmap)에 접근할 수 있다.
1. 쿠버네티스 API 서비스를 생성한다. 위의 CA 인증서는 base64로 인코딩되어, 새로운 라인이 제거되고 API 서비스에서 spec.caBundle로 사용되어야 한다. 이것은 namespaced가 아니어야 한다. [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)를 사용하는 경우, base64 인코딩이 수행되므로 PEM 인코딩된 CA 번들만 통과한다.
1. kubectl을 사용하여 리소스를 얻는다. kubectl을 실행하면, "No resources found."가 반환된다. 이 메시지는
모든 것이 작동됐지만 현재 해당 리소스 유형의 오브젝트가 생성되지 않았음을 나타낸다.
## {{% heading "whatsnext" %}}
* [API 애그리게이션 레이어를 구성](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)하고 apiserver 플래그를 활성화하는 단계를 수행한다.
* 높은 수준의 개요에 대해서는, [애그리게이션 레이어로 쿠버네티스 API 확장하기](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 참고한다.
* [커스텀 리소스 데피니션을 사용하여 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 알아본다.
@@ -52,7 +52,7 @@ kubectl delete pods -l app=myapp
### 퍼시스턴트볼륨(PersistentVolume)
스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨 삭제될 수 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.
스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드가 종료된 후 PVC를 삭제하 스토리지 클래스와 반환 정책에 따라 백업 퍼시스턴트볼륨 삭제가 트리거될 수 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.
{{< note >}}
PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
@@ -42,7 +42,7 @@ Dockerfile은 다음과 같다.
```
FROM php:5-apache
ADD index.php /var/www/html/index.php
COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
@@ -481,5 +481,3 @@ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
```
horizontalpodautoscaler.autoscaling/php-apache created
```
+35
View File
@@ -2,5 +2,40 @@
title: "도구 설치"
description: 컴퓨터에서 쿠버네티스 도구를 설정한다.
weight: 10
no_list: true
---
## kubectl
쿠버네티스 커맨드 라인 도구인 `kubectl` 사용하면 쿠버네티스 클러스터에 대해 명령을
실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및
관리하고, 로그를 볼 수 있다.
클러스터에 접근하기 위해 `kubectl` 을 다운로드 및 설치하고 설정하는 방법에 대한 정보는
[kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다.
`kubectl` 레퍼런스 문서를 읽어볼 수도 있다.
## Minikube
[Minikube](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는
도구이다. Minikube는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을
수행할 수 있다.
공식 사이트에서의 [시작하기!](https://minikube.sigs.k8s.io/docs/start/)
가이드를 따라 해볼 수 있고, 또는 도구 설치에 중점을 두고 있다면
[Minikube 설치](/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.
Minikube가 작동하면, 이를 사용하여
[샘플 애플리케이션을 실행](/docs/tutorials/hello-minikube/)해볼 수 있다.
## kind
Minikube와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서
쿠버네티스를 실행할 수 있다. Minikuke와 달리, kind는 단일 컨테이너 런타임에서만 작동한다.
kind는 [도커](https://docs.docker.com/get-docker/)를 설치하고
구성해야 한다.
[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 kind를 시작하고 실행하기 위해
수행해야 하는 작업을 보여준다.
@@ -26,7 +26,7 @@ card:
1. 다음 명령으로 최신 릴리스를 다운로드한다.
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.