From 8c4365edcf26a3ecacb6508c380df47dce7dde79 Mon Sep 17 00:00:00 2001 From: ysyukr Date: Tue, 24 Dec 2019 16:37:30 +0900 Subject: [PATCH] Update path of referenced links in translated documents - 1.17 --- content/ko/docs/concepts/_index.md | 2 +- .../cluster-administration-overview.md | 4 ++-- .../docs/concepts/configuration/overview.md | 10 +++++----- .../container-environment-variables.md | 4 ++-- .../containers/container-lifecycle-hooks.md | 4 ++-- content/ko/docs/concepts/containers/images.md | 4 ++-- .../ko/docs/concepts/overview/components.md | 2 +- .../working-with-objects/annotations.md | 2 +- .../kubernetes-objects.md | 2 +- .../overview/working-with-objects/labels.md | 8 ++++---- .../overview/working-with-objects/names.md | 2 +- .../working-with-objects/namespaces.md | 2 +- .../workloads/controllers/replicaset.md | 2 +- .../controllers/replicationcontroller.md | 17 +++++++--------- .../concepts/workloads/pods/disruptions.md | 4 ++-- .../concepts/workloads/pods/pod-lifecycle.md | 16 +++++++-------- .../concepts/workloads/pods/pod-overview.md | 18 ++++++++--------- .../ko/docs/concepts/workloads/pods/pod.md | 10 +++++----- .../docs/concepts/workloads/pods/podpreset.md | 2 +- .../ko/docs/reference/glossary/annotation.md | 2 +- .../ko/docs/reference/glossary/controller.md | 2 +- content/ko/docs/reference/glossary/cri.md | 2 +- content/ko/docs/reference/glossary/cronjob.md | 2 +- .../ko/docs/reference/glossary/daemonset.md | 2 +- .../ko/docs/reference/glossary/deployment.md | 2 +- content/ko/docs/reference/glossary/ingress.md | 2 +- content/ko/docs/reference/glossary/label.md | 2 +- .../ko/docs/reference/glossary/minikube.md | 2 +- content/ko/docs/reference/glossary/name.md | 2 +- .../ko/docs/reference/glossary/namespace.md | 2 +- content/ko/docs/reference/glossary/node.md | 2 +- content/ko/docs/reference/glossary/pod.md | 2 +- .../ko/docs/reference/glossary/replica-set.md | 2 +- .../ko/docs/reference/glossary/selector.md | 2 +- content/ko/docs/reference/glossary/uid.md | 2 +- .../ko/docs/reference/glossary/workload.md | 2 +- .../windows/user-guide-windows-containers.md | 2 +- .../access-cluster.md | 6 +++--- .../web-ui-dashboard.md | 10 +++++----- .../administer-cluster/cluster-management.md | 6 +++--- .../highly-available-master.md | 2 +- .../resource-usage-monitoring.md | 2 +- .../horizontal-pod-autoscale-walkthrough.md | 4 ++-- content/ko/docs/tutorials/hello-minikube.md | 2 +- .../basic-stateful-set.md | 18 ++++++++--------- .../stateful-application/cassandra.md | 16 +++++++-------- .../stateful-application/zookeeper.md | 20 +++++++++---------- .../expose-external-ip-address.md | 6 +++--- .../guestbook-logs-metrics-with-elk.md | 8 ++++---- 49 files changed, 124 insertions(+), 127 deletions(-) diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index d6643ec3a46c3..fb287118660be 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -35,7 +35,7 @@ weight: 40 * [볼륨](/docs/concepts/storage/volumes/) * [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) -또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다. +또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다. * [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) * [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/) diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md index 1d807e434bf51..03c7bc919b177 100644 --- a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -41,7 +41,7 @@ weight: 10 * [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다. -* [쿠버네티스 컨테이너 환경](/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다. +* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다. * [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다. @@ -62,7 +62,7 @@ weight: 10 ## 선택적 클러스터 서비스 -* [DNS 통합](/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다. +* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다. * [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index d1294c119d402..4dd1ffea5474d 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -30,9 +30,9 @@ weight: 10 ## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 -- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. +- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. - 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다. + 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다. ## 서비스 @@ -62,9 +62,9 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. ## 레이블 사용하기 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. -릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. +릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. @@ -100,7 +100,7 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. - `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. -- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다. +- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다. - 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. diff --git a/content/ko/docs/concepts/containers/container-environment-variables.md b/content/ko/docs/concepts/containers/container-environment-variables.md index c476a557bbd07..6100f4c28a367 100644 --- a/content/ko/docs/concepts/containers/container-environment-variables.md +++ b/content/ko/docs/concepts/containers/container-environment-variables.md @@ -17,7 +17,7 @@ weight: 20 쿠버네티스 컨테이너 환경은 컨테이너에 몇 가지 중요한 리소스를 제공한다. -* 하나의 [이미지](/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템. +* 하나의 [이미지](/ko/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템. * 컨테이너 자신에 대한 정보. * 클러스터 내의 다른 오브젝트에 대한 정보. @@ -54,7 +54,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트> {{% capture whatsnext %}} -* [컨테이너 라이프사이클 훅(hooks)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기. +* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기. * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기. {{% /capture %}} diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index 2ce5a61fa27ea..6967e70fc0008 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -39,7 +39,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로 파라미터는 핸들러에 전달되지 않는다. 종료 동작에 더 자세한 대한 설명은 -[파드의 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)에서 찾을 수 있다. +[파드의 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)에서 찾을 수 있다. ### 훅 핸들러 구현 @@ -113,7 +113,7 @@ Events: {{% capture whatsnext %}} -* [컨테이너 환경](/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기. +* [컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기. * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실습 경험하기. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 42a94393ab61f..c0d4fe4b0b7b4 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -26,7 +26,7 @@ weight: 10 - `imagePullPolicy`와 사용할 이미지의 태그를 생략. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화. -`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/docs/concepts/configuration/overview/#container-images)를 참고한다. +`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다. ## 매니페스트로 멀티-아키텍처 이미지 빌드 @@ -141,7 +141,7 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다 * `DOCKER_EMAIL`: `${some-email-address}` 해당 변수에 대한 값을 채우고 나면 -[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)할 수 있다. +[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다. ### IBM 클라우드 컨테이너 레지스트리 사용 IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 Docker 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index c8cea19b9d7ee..541e4f164c6ae 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -121,7 +121,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 {{% /capture %}} {{% capture whatsnext %}} * [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기 -* [컨트롤러](/docs/concepts/architecture/controller/)에 대해 더 배우기 +* [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기 * [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기 {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index b0b3c975f02c1..dfac3521d177a 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -91,7 +91,7 @@ spec: {{% /capture %}} {{% capture whatsnext %}} -[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다. +[레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다. {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 93a1daf82cb3d..30b75b82a4703 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -74,7 +74,7 @@ deployment.apps/nginx-deployment created {{% capture whatsnext %}} * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. -* 쿠버네티스의 [컨트롤러](/docs/concepts/architecture/controller/)에 대해 배운다. +* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 41fc2df1cd8ef..f0f56e600c6d0 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -20,7 +20,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이 } ``` -레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다. +레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다. {{% /capture %}} @@ -75,7 +75,7 @@ spec: ## 레이블 셀렉터 -[이름과 UID](/docs/user-guide/identifiers)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다. +[이름과 UID](/ko/docs/concepts/overview/working-with-objects/names/)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다. 레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다. @@ -184,7 +184,7 @@ kubectl get pods -l 'environment,environment notin (frontend)' ### API 오브젝트에서 참조 설정 -[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다. +[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다. #### 서비스와 레플리케이션 컨트롤러 @@ -209,7 +209,7 @@ selector: #### 세트-기반 요건을 지원하는 리소스 -[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. +[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. ```yaml selector: diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index d7e2735e01dda..0804c0d425cd6 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -11,7 +11,7 @@ weight: 20 예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 가질 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 가질 수 있다. -유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다. +유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다. {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index 43e6195b2ee11..b6108dfc59c06 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -84,7 +84,7 @@ kubectl config view --minify | grep namespace: ## 네임스페이스와 DNS [서비스](/docs/user-guide/services)를 생성하면, 대응되는 -[DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다. +[DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다. 이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데, 이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 1e04ec619bae3..27f2dd359cc0d 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -277,7 +277,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli 원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다. 기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다. 하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다. -컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)를 이용하면 된다. +컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다. 이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다. ### 레플리카셋에서 파드 격리 diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index cf52d7890987e..245bbf464c6f2 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -1,7 +1,4 @@ --- - - - title: 레플리케이션 컨트롤러 feature: title: 자가 치유 @@ -16,7 +13,7 @@ weight: 20 {{% capture overview %}} {{< note >}} -[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다. +[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다. {{< /note >}} _레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가 @@ -143,7 +140,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m ### 파드 셀렉터 -`.spec.selector` 필드는 [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다. +`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다. 직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나 삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고 레플리케이션 컨트롤러를 교체할 수 있다. @@ -257,14 +254,14 @@ API 오브젝트에 대한 더 자세한 것은 ### 레플리카셋 -[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) 이다. -이것은 주로 [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다. +[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다. +이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다. 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다. ### 디플로이먼트 (권장되는) -[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. +[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. `kubectl rolling-update` 와는 다르게 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다. @@ -280,12 +277,12 @@ API 오브젝트에 대한 더 자세한 것은 ### 데몬셋 머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신 -[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다. +[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다. 다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며, 머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다. ## 더 자세한 정보는 -[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라. +[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라. {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 3f0947d5aec27..5dc6f75d328ea 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -68,7 +68,7 @@ weight: 60 - 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다. - 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.) - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 -영역 간(또는 [다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다.)에 +영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에 애플리케이션을 분산해야 한다. 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. @@ -116,7 +116,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다. 그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다. 애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다. -([디플로이먼트 업데이트](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)에 대해 알아보기.) +([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.) 파드를 Eviction API로 축출하면 정상적으로 종료된다. ([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.) diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index de781afe3489e..3c8f9af995064 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -65,7 +65,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 * `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음. * `Ready`: 파드는 요청들을 수행할 수 있으며 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함. - * `Initialized`: 모든 [초기화 컨테이너](/docs/concepts/workloads/pods/init-containers)가 + * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가 성공적으로 시작 완료되었음. * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서 지금 당장은 파드를 스케줄할 수 없음. @@ -243,7 +243,7 @@ status: ``` 파드의 새로운 조건들은 -쿠버네티스의 [레이블 키 포멧](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)을 준수해야 한다. +쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다. `kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에, 새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다. @@ -271,7 +271,7 @@ PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으 kubelet에 의해서 재시작되는 종료된 컨테이너는 5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 기준으로 재시작되며, 10분의 성공적 실행 후에 재설정된다. -[파드 문서](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)에서 의논된 바와 같이, +[파드 문서](/ko/docs/concepts/workloads/pods/pod/#파드의-내구성-또는-결핍)에서 의논된 바와 같이, 파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다. @@ -290,13 +290,13 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는 지정된 경우에 적합하다. - 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는 - [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), - [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/), 또는 - [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다. + [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/), + [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는 + [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다. 레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된 경우에만 적합하다. -- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)을 사용하길 +- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하길 바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다. 세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를 @@ -401,7 +401,7 @@ spec: * Hands-on 경험하기 [활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). -* [컨테이너 라이프사이클 후크(hook)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기. +* [컨테이너 라이프사이클 후크(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기. {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 323ed12dde3c1..ef0b0de7558f4 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -31,7 +31,7 @@ card: * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns) -각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다. +각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다. ## 어떻게 파드가 다중 컨테이너를 관리하는가 @@ -61,7 +61,7 @@ card: 파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다. {{< /note >}} -파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다. +파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다. ### 파드와 컨트롤러 @@ -69,17 +69,17 @@ card: 한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시. -* [디플로이먼트](/docs/concepts/workloads/controllers/deployment/) -* [스테이트풀 셋](/docs/concepts/workloads/controllers/statefulset/) -* [데몬 셋](/docs/concepts/workloads/controllers/daemonset/) +* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) +* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/) +* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/) 일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다. ## 파드 템플릿 -파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), +파드 템플릿은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/), [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/), -[데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. +[데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. 컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다. 아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다. @@ -102,8 +102,8 @@ spec: {{% /capture %}} {{% capture whatsnext %}} -* [파드](/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자. +* [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자. * 파드의 동작에 대해 더 알아보자. - * [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods) + * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index fdadf15710814..990330f7ea7cf 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -45,13 +45,13 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지 도커 컨테이너 그룹으로 모델링 된다. 개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다. -[파드의 생애](/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이, +[파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이, 파드가 만들어지고 고유한 ID(UID)가 할당되고, 재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. 노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다. 해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로, 원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다. -더 자세한 내용은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다. +더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다. 볼륨과 같이 파드와 동일한 수명이 있다고 하면, UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것을 의미한다. @@ -133,10 +133,10 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. 일반적으로 사용자는 파드를 직접 만들 필요가 없다. -싱글톤이라도 대부분 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. +싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. 컨트롤러는 클러스터 범위에서 복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다. -[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도 +[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도 위와 같은 기능 제공을 할 수 있다. 사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. @@ -165,7 +165,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다. 1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다. 1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다. - 1. 파드의 컨테이너 중 하나에 [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다. + 1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다. 1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 204f7d9ec1dfa..b6ebb25a0433b 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -17,7 +17,7 @@ weight: 50 `Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을 주입하기 위한 API 리소스이다. 주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는 -[레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다. +[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다. 파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드 diff --git a/content/ko/docs/reference/glossary/annotation.md b/content/ko/docs/reference/glossary/annotation.md index a853050db3710..36b814c1588ed 100755 --- a/content/ko/docs/reference/glossary/annotation.md +++ b/content/ko/docs/reference/glossary/annotation.md @@ -2,7 +2,7 @@ title: 어노테이션(Annotation) id: annotation date: 2018-04-12 -full_link: /docs/concepts/overview/working-with-objects/annotations +full_link: /ko/docs/concepts/overview/working-with-objects/annotations short_description: > 임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍. diff --git a/content/ko/docs/reference/glossary/controller.md b/content/ko/docs/reference/glossary/controller.md index c2a3e1e339845..6bd7306842060 100644 --- a/content/ko/docs/reference/glossary/controller.md +++ b/content/ko/docs/reference/glossary/controller.md @@ -2,7 +2,7 @@ title: 컨트롤러(Controller) id: controller date: 2018-04-12 -full_link: /docs/concepts/architecture/controller/ +full_link: /ko/docs/concepts/architecture/controller/ short_description: > API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프. diff --git a/content/ko/docs/reference/glossary/cri.md b/content/ko/docs/reference/glossary/cri.md index a5fe42d905bcf..341015a0b7777 100644 --- a/content/ko/docs/reference/glossary/cri.md +++ b/content/ko/docs/reference/glossary/cri.md @@ -2,7 +2,7 @@ title: 컨테이너 런타임 인터페이스(Container runtime interface, CRI) id: cri date: 2019-03-07 -full_link: /docs/concepts/overview/components/#container-runtime +full_link: /ko/docs/concepts/overview/components/#컨테이너-런타임 short_description: > Kubelet과 컨테이너 런타임을 통합시키기 위한 API diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md index ff2153c73b001..6b2aeb41549c3 100755 --- a/content/ko/docs/reference/glossary/cronjob.md +++ b/content/ko/docs/reference/glossary/cronjob.md @@ -2,7 +2,7 @@ title: 크론잡(CronJob) id: cronjob date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/cron-jobs/ +full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/ short_description: > 주기적인 일정에 따라 실행되는 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. diff --git a/content/ko/docs/reference/glossary/daemonset.md b/content/ko/docs/reference/glossary/daemonset.md index 81405e5437aa5..ddb385709e380 100755 --- a/content/ko/docs/reference/glossary/daemonset.md +++ b/content/ko/docs/reference/glossary/daemonset.md @@ -2,7 +2,7 @@ title: 데몬셋(DaemonSet) id: daemonset date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/daemonset +full_link: /ko/docs/concepts/workloads/controllers/daemonset short_description: > 파드의 복제본을 클러스터 노드 집합에서 동작하게 한다. diff --git a/content/ko/docs/reference/glossary/deployment.md b/content/ko/docs/reference/glossary/deployment.md index 39c5e4d7f6380..8c7192f1f7c23 100755 --- a/content/ko/docs/reference/glossary/deployment.md +++ b/content/ko/docs/reference/glossary/deployment.md @@ -2,7 +2,7 @@ title: 디플로이먼트(Deployment) id: deployment date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/deployment/ +full_link: /ko/docs/concepts/workloads/controllers/deployment/ short_description: > 복제된(replicated) 애플리케이션을 관리하는 API 오브젝트. diff --git a/content/ko/docs/reference/glossary/ingress.md b/content/ko/docs/reference/glossary/ingress.md index fc6189e975ddb..590cc300850fc 100755 --- a/content/ko/docs/reference/glossary/ingress.md +++ b/content/ko/docs/reference/glossary/ingress.md @@ -2,7 +2,7 @@ title: 인그레스(Ingress) id: ingress date: 2018-04-12 -full_link: /docs/concepts/services-networking/ingress/ +full_link: /ko/docs/concepts/services-networking/ingress/ short_description: > 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함. diff --git a/content/ko/docs/reference/glossary/label.md b/content/ko/docs/reference/glossary/label.md index 27485451a60ca..9b6156b54d205 100755 --- a/content/ko/docs/reference/glossary/label.md +++ b/content/ko/docs/reference/glossary/label.md @@ -2,7 +2,7 @@ title: 레이블(Label) id: label date: 2018-04-12 -full_link: /docs/concepts/overview/working-with-objects/labels +full_link: /ko/docs/concepts/overview/working-with-objects/labels short_description: > 사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다. diff --git a/content/ko/docs/reference/glossary/minikube.md b/content/ko/docs/reference/glossary/minikube.md index 71ba64ef3985a..57267cddd44fa 100755 --- a/content/ko/docs/reference/glossary/minikube.md +++ b/content/ko/docs/reference/glossary/minikube.md @@ -2,7 +2,7 @@ title: Minikube id: minikube date: 2018-04-12 -full_link: /docs/setup/learning-environment/minikube/ +full_link: /ko/docs/setup/learning-environment/minikube/ short_description: > 로컬에서 쿠버네티스를 실행하기 위한 도구. diff --git a/content/ko/docs/reference/glossary/name.md b/content/ko/docs/reference/glossary/name.md index 5dae19c95f419..261be7667eecb 100755 --- a/content/ko/docs/reference/glossary/name.md +++ b/content/ko/docs/reference/glossary/name.md @@ -2,7 +2,7 @@ title: 이름(Name) id: name date: 2018-04-12 -full_link: /docs/concepts/overview/working-with-objects/names +full_link: /ko/docs/concepts/overview/working-with-objects/names short_description: > `/api/v1/pods/some-name`과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열. diff --git a/content/ko/docs/reference/glossary/namespace.md b/content/ko/docs/reference/glossary/namespace.md index 037961b41b3fb..584f2fc2bdb6d 100755 --- a/content/ko/docs/reference/glossary/namespace.md +++ b/content/ko/docs/reference/glossary/namespace.md @@ -2,7 +2,7 @@ title: 네임스페이스(Namespace) id: namespace date: 2018-04-12 -full_link: /docs/concepts/overview/working-with-objects/namespaces +full_link: /ko/docs/concepts/overview/working-with-objects/namespaces short_description: > 쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화. diff --git a/content/ko/docs/reference/glossary/node.md b/content/ko/docs/reference/glossary/node.md index b92bd5468e448..311e2ea0b5f6c 100755 --- a/content/ko/docs/reference/glossary/node.md +++ b/content/ko/docs/reference/glossary/node.md @@ -2,7 +2,7 @@ title: 노드(Node) id: node date: 2018-04-12 -full_link: /docs/concepts/architecture/nodes/ +full_link: /ko/docs/concepts/architecture/nodes/ short_description: > 노드는 쿠버네티스의 작업 장비(worker machine)이다. diff --git a/content/ko/docs/reference/glossary/pod.md b/content/ko/docs/reference/glossary/pod.md index aca9f9a421660..c7a4d4debc786 100755 --- a/content/ko/docs/reference/glossary/pod.md +++ b/content/ko/docs/reference/glossary/pod.md @@ -2,7 +2,7 @@ title: 파드(Pod) id: pod date: 2018-04-12 -full_link: /docs/concepts/workloads/pods/pod-overview/ +full_link: /ko/docs/concepts/workloads/pods/pod-overview/ short_description: > 가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다. diff --git a/content/ko/docs/reference/glossary/replica-set.md b/content/ko/docs/reference/glossary/replica-set.md index 3b92ae31bd9bc..8e4a060e7f67f 100755 --- a/content/ko/docs/reference/glossary/replica-set.md +++ b/content/ko/docs/reference/glossary/replica-set.md @@ -2,7 +2,7 @@ title: 레플리카셋(ReplicaSet) id: replica-set date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/replicaset/ +full_link: /ko/docs/concepts/workloads/controllers/replicaset/ short_description: > 레플리카셋은 지정된 수의 파드 레플리카가 동시에 실행이 되도록 보장한다 diff --git a/content/ko/docs/reference/glossary/selector.md b/content/ko/docs/reference/glossary/selector.md index 400263e873af3..c5a4011b766fe 100755 --- a/content/ko/docs/reference/glossary/selector.md +++ b/content/ko/docs/reference/glossary/selector.md @@ -2,7 +2,7 @@ title: 셀렉터(Selector) id: selector date: 2018-04-12 -full_link: /docs/concepts/overview/working-with-objects/labels/ +full_link: /ko/docs/concepts/overview/working-with-objects/labels/ short_description: > 사용자가 레이블에 따라서 리소스 리스트를 필터할 수 있게 한다. diff --git a/content/ko/docs/reference/glossary/uid.md b/content/ko/docs/reference/glossary/uid.md index e32c7e85e2bc9..b04a1be5c8c6c 100755 --- a/content/ko/docs/reference/glossary/uid.md +++ b/content/ko/docs/reference/glossary/uid.md @@ -2,7 +2,7 @@ title: UID id: uid date: 2018-04-12 -full_link: /docs/concepts/overview/working-with-objects/names +full_link: /ko/docs/concepts/overview/working-with-objects/names short_description: > 오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열. diff --git a/content/ko/docs/reference/glossary/workload.md b/content/ko/docs/reference/glossary/workload.md index 55dcc3167bcdc..143d7f86f8d3e 100644 --- a/content/ko/docs/reference/glossary/workload.md +++ b/content/ko/docs/reference/glossary/workload.md @@ -2,7 +2,7 @@ title: 워크로드(Workloads) id: workloads date: 2019-02-13 -full_link: /docs/concepts/workloads/ +full_link: /ko/docs/concepts/workloads/ short_description: > 워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다. diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index 5cc45a22533df..f5d624e07ea7f 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -96,7 +96,7 @@ spec: * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며). * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 보여지는)로 실행한다. - * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/docs/concepts/services-networking/dns-pod-service/#services)와 서비스 이름으로 `curl`을 실행한다. + * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다. * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 8566e1d15101c..c4f30d1d1d863 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -20,7 +20,7 @@ content_template: templates/concept 클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 인증정보를 가져야 한다. 일반적으로 이는 당신이 -[Getting started guide](/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, +[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다. kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다. @@ -29,7 +29,7 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확 kubectl config view ``` -많은 [예제들](/docs/user-guide/kubectl-cheatsheet)에서 kubectl을 사용하는 것을 소개하고 있으며 +많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다. ## REST API에 직접 액세스 @@ -212,7 +212,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. 이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 -[노드들](/docs/admin/node), [파드들](/docs/user-guide/pods), [서비스들](/docs/user-guide/services)은 +[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 할 수 없을 것이다. diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index b0e5577d894b8..46ca07d4524b5 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -69,15 +69,15 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 배포 마법사는 다음 정보를 제공한다. -- **앱 이름** (필수): 애플리케이션 이름. [레이블](/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다. +- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다. 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다. -- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다. +- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다. - **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다. - 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. + 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. - **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. @@ -87,9 +87,9 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다. -- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. +- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. -- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. +- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. 예를 들면: diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md index c43b41fa1558b..4d1446526fdc9 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md @@ -17,7 +17,7 @@ content_template: templates/concept ## 클러스터 생성과 설정 -일련의 머신들에 쿠버네티스를 설치하려면, 환경에 맞게 기존의 [시작하기](/docs/setup/) 안내서들 중에 하나를 선택하여 참조한다. +일련의 머신들에 쿠버네티스를 설치하려면, 환경에 맞게 기존의 [시작하기](/ko/docs/setup/) 안내서들 중에 하나를 선택하여 참조한다. ## 클러스터 업그레이드 @@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레 ## 클러스터 크기 재조정 -[노드 자가 등록 모드](/docs/concepts/architecture/nodes/#self-registration-of-nodes)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. +[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. [Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다. ```shell @@ -181,7 +181,7 @@ kubectl uncordon $NODENAME 해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; -이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/docs/concepts/architecture/nodes)를 참조하라. +이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라. ## 고급 주제들 diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-master.md b/content/ko/docs/tasks/administer-cluster/highly-available-master.md index 4f4a2ce184123..cd9be9736c9ed 100644 --- a/content/ko/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/ko/docs/tasks/administer-cluster/highly-available-master.md @@ -106,7 +106,7 @@ HA 클러스터의 마스터 복제본 중 하나가 실패하면, * 다른 존에 마스터 복제본을 배치하도록 한다. 한 존이 실패하는 동안, 해당 존에 있는 마스터도 모두 실패할 것이다. 존 장애를 극복하기 위해 노드를 여러 존에 배치한다 -(더 자세한 내용은 [멀티 존](/docs/setup/best-practices/multiple-zones/)를 참조한다). +(더 자세한 내용은 [멀티 존](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다). * 두 개의 마스터 복제본은 사용하지 않는다. 두 개의 복제 클러스터에 대한 합의는 지속적 상태를 변경해야 할 때 두 복제본 모두 실행해야 한다. 결과적으로 두 복제본 모두 필요하고, 어떤 복제본의 장애에도 클러스터가 대부분 장애 상태로 변한다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index b0a175ee11556..9f1be04977365 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -26,7 +26,7 @@ title: 리소스 모니터링 도구 ## 리소스 메트릭 파이프라인 리소스 메트릭 파이프라인은 -[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) +[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 [metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 62ff9f438524c..27ae2c2f52fb4 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -10,7 +10,7 @@ Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. -이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. +이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. {{% /capture %}} @@ -28,7 +28,7 @@ Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하 또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. 마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우, 버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다. -자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)를 참고하길 바란다. +자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다. {{% /capture %}} diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 2707d3289bbc7..5c7470ef63ed7 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -15,7 +15,7 @@ card: {{% capture overview %}} -이 튜토리얼에서는 [Minikube](/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 +이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 쿠버네티스에서 Node.js 로 작성된 간단한 Hello World 애플리케이션을 어떻게 실행하는지 살펴본다. Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 52e7a65b877dc..45056e86223cc 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -6,7 +6,7 @@ weight: 10 --- {{% capture overview %}} -이 튜토리얼은 스테이트풀셋([StatefulSets](/docs/concepts/workloads/controllers/statefulset/))을 이용하여 +이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여 애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며 스케일링하고 업데이트하는지 시연한다. {{% /capture %}} @@ -15,12 +15,12 @@ weight: 10 튜토리얼을 시작하기 전에 다음의 쿠버네티스 컨셉에 대해 익숙해야 한다. -* [파드](/docs/concepts/workloads/pods/) -* [클러스터 DNS(Cluster DNS)](/docs/concepts/services-networking/dns-pod-service/) +* [파드](/docs/user-guide/pods/single-container/) +* [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/) * [헤드리스 서비스(Headless Services)](/docs/concepts/services-networking/service/#headless-services) * [퍼시스턴트볼륨(PersistentVolumes)](/docs/concepts/storage/persistent-volumes/) * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) -* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) +* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) * [kubectl CLI](/docs/user-guide/kubectl/) 이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록 @@ -49,7 +49,7 @@ weight: 10 ## 스테이트풀셋 생성하기 아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는 -[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 +[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인 `nginx` 를 생성한다. @@ -110,7 +110,7 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/docs/user-guide/pod-states) 상태가 되기 전에 +`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드 @@ -129,7 +129,7 @@ web-1 1/1 Running 0 1m ``` -[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 +[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다. 이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는 고유한 순번에 기인한다. 파드의 이름의 형식은 @@ -377,7 +377,7 @@ web-4 1/1 Running 0 19s ``` 스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다. -[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는 +[스테이트풀셋 생성](#차례대로-파드-생성하기)으로 스테이트풀셋 컨트롤러는 각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에 이전 파드가 Running과 Ready 상태가 될 때까지 기다린다. @@ -656,7 +656,7 @@ k8s.gcr.io/nginx-slim:0.8 종료되어 원래 환경설정으로 복원된다. #### 단계적 롤아웃 -[카나리 롤아웃](#rolling-out-a-canary)에서 했던 방법과 비슷하게 +[카나리 롤아웃](#카나리-canary-롤링-아웃)에서 했던 방법과 비슷하게 분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을 수행할 수 있다. 단계적 롤아웃을 수행하려면 컨트롤러가 업데이트를 일시 중지할 순번으로 diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 17f85f488752f..10c011aa3bff9 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -8,7 +8,7 @@ weight: 30 {{% capture overview %}} 이 튜토리얼은 네이티브 클라우드 [카산드라](http://cassandra.apache.org/)를 쿠버네티스에서 배포하는 방법을 소개한다. 이 예제에서 커스텀 카산드라 *시드 제공자(SeedProvider)* 는 카산드라가 클러스터에 조인한 새 카산드라 노드를 발견할 수 있게 한다. -*스테이트풀셋* 은 상태있는 애플리케이션을 클러스터 환경에서 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [*스테이트풀셋*](/docs/concepts/workloads/controllers/statefulset/) 문서를 참조하자. +*스테이트풀셋* 은 상태있는 애플리케이션을 클러스터 환경에서 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [*스테이트풀셋*](/ko/docs/concepts/workloads/controllers/statefulset/) 문서를 참조하자. **도커에서 카산드라** @@ -30,14 +30,14 @@ weight: 30 {{% capture objectives %}} * 카산드라 헤드리스 [*서비스*](/docs/concepts/services-networking/service/)를 생성하고 검증한다. -* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다. -* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 검증한다. -* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 수정한다. -* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과 포함된 [파드](/docs/concepts/workloads/pods/pod/)를 삭제한다. +* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다. +* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 검증한다. +* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 수정한다. +* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 포함된 [파드](/ko/docs/concepts/workloads/pods/pod/)를 삭제한다. {{% /capture %}} {{% capture prerequisites %}} -이 튜토리얼을 완료하려면, [파드](/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 +이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 * *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. @@ -47,7 +47,7 @@ weight: 30 * 실행 중인 쿠버네티스 클러스터를 소유 {{< note >}} -아직 클러스터가 없다면 [설치](/docs/setup/)를 읽도록 하자. +아직 클러스터가 없다면 [설치](/ko/docs/setup/)를 읽도록 하자. {{< /note >}} ### 추가적인 Minikube 설정 요령 @@ -65,7 +65,7 @@ minikube start --memory 5120 --cpus=4 {{% capture lessoncontent %}} ## 카산드라 헤드리스 서비스 생성하기 -쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. +쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. 다음의 `서비스`는 쿠버네티스 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 27d5fa90cf09a..06dc81fed433a 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -17,12 +17,12 @@ weight: 40 다음 쿠버네티스 개념에 친숙해야 한다. - [파드](/docs/user-guide/pods/single-container/) -- [클러스터 DNS](/docs/concepts/services-networking/dns-pod-service/) +- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) - [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services) - [퍼시스턴트볼륨](/docs/concepts/storage/volumes/) - [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) -- [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) -- [파드디스룹션버짓](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget) +- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) +- [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget) - [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) - [kubectl CLI](/docs/user-guide/kubectl/) @@ -64,8 +64,8 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변 아래 메니페스트에는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services), [서비스](/docs/concepts/services-networking/service/), -[파드디스룹션버짓](/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget), -[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 포함한다. +[파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget), +[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다. {{< codenew file="application/zookeeper/zookeeper.yaml" >}} @@ -173,7 +173,7 @@ zk-1.zk-hs.default.svc.cluster.local zk-2.zk-hs.default.svc.cluster.local ``` -[쿠버네티스 DNS](/docs/concepts/services-networking/dns-pod-service/)의 A 레코드는 FQDN을 파드의 IP 주소로 풀어낸다. 쿠버네티스가 파드를 리스케줄하면, 파드의 새 IP 주소로 A 레코드를 갱신하지만, A 레코드의 이름은 바뀌지 않는다. +[쿠버네티스 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)의 A 레코드는 FQDN을 파드의 IP 주소로 풀어낸다. 쿠버네티스가 파드를 리스케줄하면, 파드의 새 IP 주소로 A 레코드를 갱신하지만, A 레코드의 이름은 바뀌지 않는다. ZooKeeper는 그것의 애플리케이션 환경설정을 `zoo.cfg` 파일에 저장한다. `kubectl exec`를 이용하여 `zk-0` 파드의 `zoo.cfg` 내용을 보자. @@ -366,7 +366,7 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` -아래 명령어로 [무결성 테스트](#sanity-testing-the-ensemble)에서 입력한 값을 +아래 명령어로 [무결성 테스트](#앙상블-무결성-테스트)에서 입력한 값을 `zk-2` 파드에서 얻어온다. ```shell @@ -443,8 +443,8 @@ ZooKeeper의 서버 디렉터리에 마운트한다. ## 일관된 구성 보장하기 -[리더 선출 촉진](#facilitating-leader-election)과 -[합의 달성](#achieving-consensus) 섹션에서 알렸듯이, +[리더 선출 촉진](#리더-선출-촉진)과 +[합의 달성](#합의-달성) 섹션에서 알렸듯이, ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다. 또한 Zab 프로토콜의 일관된 설정도 네트워크에 걸쳐 올바르게 동작하기 위해서 @@ -655,7 +655,7 @@ statefulset.apps/zk rolled back ### 프로세스 장애 관리하기 -[재시작 정책](/docs/user-guide/pod-states/#restartpolicy)은 +[재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)은 쿠버네티스가 파드 내에 컨테이너의 진입점에서 프로세스 실패를 어떻게 다루는지 제어한다. `스테이트풀셋`의 파드에서 오직 적절한 `재시작 정책`는 Always이며 이것이 기본 값이다. 상태가 유지되는 애플리케이션을 위해 diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 8c921c9f77735..0143b9b440a04 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -50,11 +50,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml 위의 명령어는 - [디플로이먼트](/docs/concepts/workloads/controllers/deployment/) + [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 오브젝트와 관련된 - [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/) + [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/) 오브젝트를 생성한다. 레플리카 셋은 다섯 개의 - [파드](/docs/concepts/workloads/pods/pod/)가 있으며, + [파드](/ko/docs/concepts/workloads/pods/pod/)가 있으며, 각 파드는 Hello World 애플리케이션을 실행한다. 1. 디플로이먼트에 대한 정보를 확인한다. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index 816aa4ce50dda..00900d5973822 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -394,8 +394,8 @@ deployment.extensions/frontend scaled {{% /capture %}} {{% capture whatsnext %}} -* [리소스 모니터링 도구](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다. -* [로깅 아키텍처](/docs/concepts/클러스터-administration/logging/)를 더 읽어본다. -* [애플리케이션 검사 및 디버깅](/docs/tasks/debug-application-cluster/)을 더 읽어본다. -* [애플리케이션 문제 해결](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. +* [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다. +* [로깅 아키텍처](/docs/concepts/cluster-administration/logging/)를 더 읽어본다. +* [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다. +* [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. {{% /capture %}}