Merge pull request #23278 from kubernetes/dev-1.18-ko.10
Tenth Korean l10n work for release 1.18
This commit is contained in:
+4
-4
@@ -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
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -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)` 명령 부분을 특정 버전으로 바꾼다.
|
||||
|
||||
Reference in New Issue
Block a user