From 2a94b058ce6e8d1e7809aac577de6babec5301d1 Mon Sep 17 00:00:00 2001 From: Daehyun Paik Date: Fri, 4 Sep 2020 14:16:02 +0900 Subject: [PATCH] Eleventh Korean l10n work for release 1.18 - Update outdated files in the dev-1.18-ko.11 branch (#23643) - Fix inconsistent translation in Ko (#23683) Co-authored-by: Jerry Park Co-authored-by: Daehyun Paik --- content/ko/docs/_index.md | 1 + .../docs/concepts/architecture/controller.md | 73 ++++---- .../concepts/cluster-administration/addons.md | 2 +- .../cluster-administration/cloud-providers.md | 81 +-------- .../manage-resources-containers.md | 4 +- .../configuration/resource-bin-packing.md | 2 +- .../ko/docs/concepts/configuration/secret.md | 4 + content/ko/docs/concepts/containers/images.md | 4 +- .../extend-kubernetes/extend-cluster.md | 2 +- .../concepts/extend-kubernetes/operator.md | 5 +- .../concepts/storage/persistent-volumes.md | 10 ++ .../docs/concepts/storage/volume-snapshots.md | 4 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/deployment.md | 12 +- .../controllers/garbage-collection.md | 2 +- .../concepts/workloads/controllers/job.md | 2 +- .../workloads/controllers/replicaset.md | 7 +- .../controllers/replicationcontroller.md | 4 +- .../workloads/controllers/statefulset.md | 2 +- .../ko/docs/concepts/workloads/pods/_index.md | 2 +- content/ko/docs/reference/_index.md | 8 +- .../command-line-tools-reference/_index.md | 1 - .../feature-gates.md | 5 +- .../docs/reference/glossary/kube-apiserver.md | 8 +- .../reference/glossary/managed-service.md | 14 +- .../docs/reference/issues-security/_index.md | 1 - .../ko/docs/reference/kubectl/cheatsheet.md | 26 +-- content/ko/docs/reference/kubectl/overview.md | 27 ++- .../ko/docs/reference/setup-tools/_index.md | 2 - .../reference/setup-tools/kubeadm/_index.md | 26 ++- .../reference/setup-tools/kubeadm/kubeadm.md | 28 --- content/ko/docs/reference/using-api/_index.md | 1 - .../reference/using-api/client-libraries.md | 7 +- .../container-runtimes.md | 164 +++++++++++------- content/ko/docs/tasks/_index.md | 2 +- .../access-cluster.md | 18 +- ...icate-containers-same-pod-shared-volume.md | 36 ++-- .../web-ui-dashboard.md | 151 ++++++++++++---- .../administer-cluster/access-cluster-api.md | 15 +- .../access-cluster-services.md | 3 +- .../administer-cluster/cluster-management.md | 28 +-- .../dns-custom-nameservers.md | 30 ++-- .../kubeadm/kubeadm-upgrade.md | 5 - .../romana-network-policy.md | 14 +- .../weave-network-policy.md | 21 ++- .../quality-service-pod.md | 3 +- .../debug-init-containers.md | 26 ++- .../logging-elasticsearch-kibana.md | 7 +- .../resource-metrics-pipeline.md | 21 ++- .../resource-usage-monitoring.md | 37 ++-- .../define-environment-variable-container.md | 35 ++-- .../tasks/manage-daemon/update-daemon-set.md | 11 +- .../declarative-config.md | 2 +- .../imperative-command.md | 2 +- .../imperative-config.md | 2 +- .../kustomization.md | 6 +- .../horizontal-pod-autoscale-walkthrough.md | 12 +- .../ko/docs/tasks/tools/install-kubectl.md | 21 ++- content/ko/docs/tutorials/hello-minikube.md | 2 +- .../explore/explore-intro.html | 6 +- .../ko/docs/tutorials/services/source-ip.md | 6 +- .../stateful-application/cassandra.md | 46 +++-- .../mysql-wordpress-persistent-volume.md | 14 +- .../stateful-application/zookeeper.md | 65 +++---- 64 files changed, 624 insertions(+), 566 deletions(-) delete mode 100644 content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md diff --git a/content/ko/docs/_index.md b/content/ko/docs/_index.md index e3c4620130..8a2dbc31a5 100644 --- a/content/ko/docs/_index.md +++ b/content/ko/docs/_index.md @@ -1,3 +1,4 @@ --- +linktitle: 쿠버네티스 문서 title: 문서 --- diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 7782d27855..836b4a5b6b 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -6,14 +6,14 @@ weight: 30 -로보틱스와 자동화에서 _컨트롤 루프_ 는 +로보틱스와 자동화에서 _컨트롤 루프_ 는 시스템 상태를 조절하는 종료되지 않는 루프이다. 컨트롤 루프의 예시: 실내 온도 조절기 사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를 온도 조절기에 알려준다. -*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서 +*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서 현재 상태를 의도한 상태에 가깝게 만든다. {{< glossary_definition term_id="controller" length="short">}} @@ -28,64 +28,64 @@ weight: 30 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다. 이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 는 의도한 상태를 표현하는 사양 필드를 가지고 있다. -해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 +해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 상태에 가깝게 만드는 역할을 한다. -컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로, -쿠버네티스에서는 컨트롤러가 +컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로, +쿠버네티스에서는 컨트롤러가 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 로 유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다. {{< comment >}} -네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는 -오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는 +네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는 +오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는 자세한 설명을 생략한다. {{< /comment >}} ### API 서버를 통한 제어 -{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스 -내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 +{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스 +내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 상호 작용하며 상태를 관리한다. -잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, -작업을 수행한 다음 중지하는 +잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, +작업을 수행한 다음 중지하는 쿠버네티스 리소스 이다. -(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet +(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet 의 의도한 상태 중 일부가 된다.) -잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 +잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 노드 집합의 kubelet이 작업을 수행하기에 적합한 수의 파드를 실행하게 한다. 잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다. -대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록 +대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록 지시한다. -{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 다른 컴포넌트는 신규 정보 -(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여, +(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여, 결국 해당 작업을 완료시킨다. 새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다. -잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게 -만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서 +잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게 +만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서 잡이 완료에 가까워 지도록 한다. 또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다. 예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는 잡 오브젝트가 `Finished` 로 표시되도록 업데이트한다. -(이것은 지금 방 온도가 설정한 온도인 것을 표시하기 +(이것은 지금 방 온도가 설정한 온도인 것을 표시하기 위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다). ### 직접 제어 -잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을 +잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을 변경해야 할 필요가 있다. -예를 들어, 만약 컨트롤 루프를 사용해서 +예를 들어, 만약 컨트롤 루프를 사용해서 클러스터에 충분한 {{< glossary_tooltip text="노드들" term_id="node" >}}이 -있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록 +있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록 현재 클러스터 외부의 무언가를 필요로 한다. 외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한 @@ -101,7 +101,7 @@ weight: 30 쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인 변화에 대응할 수 있다. -작업이 발생함에 따라 어떤 시점에서든 클러스터가 +작업이 발생함에 따라 어떤 시점에서든 클러스터가 변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로, 클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다. @@ -110,26 +110,26 @@ weight: 30 ## 디자인 -디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 +디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프 -(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 +(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는 -잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 +잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면, 잡은 다른 컨트롤러가 생성한다. -컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, -간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 +컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, +간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 허용하도록 디자인되었다. {{< note >}} 동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다. -이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에 +이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에 연결된 리소스에만 주의를 기울인다. 예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다. -잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다. -이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는 +잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다. +이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는 정보({{< glossary_tooltip term_id="label" text="레이블" >}})가 있기 때문이다. {{< /note >}} @@ -139,14 +139,14 @@ weight: 30 내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이 내장 컨트롤러는 중요한 핵심 동작을 제공한다. -디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의 +디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의 자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다. -쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로, +쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로, 어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다. 컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다. 또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다. -소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나, +소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나, 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에 따라 달라진다. @@ -154,8 +154,7 @@ weight: 30 ## {{% heading "whatsnext" %}} -* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기 -* [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자. +* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기 +* [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자. * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자. * 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다. - diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 067ebab037..c0caa56526 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -29,7 +29,7 @@ content_type: concept * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. * [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. -* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. +* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. ## 서비스 검색 diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 9c1c556808..fb1ede14be 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -6,7 +6,7 @@ weight: 30 이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에 -대해 설명한다. +대해 설명한다. 다른 클라우드 제공자의 프로젝트가 많이 있지만, 여기의 목록은 쿠버네티스 자체에 의존하거나, 포함되어있는 프로젝트로 한정한다. ### kubeadm @@ -116,15 +116,6 @@ AWS 어노테이션에 대한 정보 출처는 [aws.go](https://github.com/kuber Azure 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름(hostname)을 사용한다. 참고로 쿠버네티스 노드 이름은 Azure VM 이름과 일치해야 한다. -## CloudStack - -이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)이다. - -### 노드 이름 - -CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. -참고로 쿠버네티스 노드 이름은 CloudStack VM 이름과 일치해야 한다. - ## GCE 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)이다. @@ -138,11 +129,6 @@ GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다. -### 노드 이름 - -HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다. -노드에서 kubelet을 시작할 때 반드시 `--hostname-override=` 를 사용한다. - ## OpenStack 이 섹션에서는 쿠버네티스와 함께 OpenStack을 사용할 때 사용할 수 있는 모든 구성에 대해 설명한다. @@ -251,11 +237,9 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 로드 밸런서와 관 값은 `v1` 또는 `v2` 이다. 값이 제공되지 않는 경우 자동 감지는 기본 OpenStack 클라우드에 의해 제공되는 가장 최신의 지원되는 버전을 선택한다. -* `use-octavia` (선택): Octavia LBaaS V2 서비스 카탈로그 엔드포인트를 찾고 사용할지의 - 여부를 결정하는 데 사용된다. 유효한 값은 `true` 또는 `false` 이다. - `true` 가 지정되고 Octaiva LBaaS V2 항목을 찾을 수 없는 경우, - 제공자는 폴백(fall back)하고 대신 Neutron LBaaS V2 엔드포인트를 찾으려고 - 시도한다. 기본값은 `false` 이다. +* `use-octavia` (선택): Neutron-LBaaS를 사용하는 대신 LoadBalancer 유형의 + 서비스 구현에 Octavia를 사용할지 여부를 결정한다. 기본값: true + 주의: Openstack CCM은 v1.17.0 이후로 기본 로드 밸런서 구현으로 Octavia를 사용한다. * `subnet-id` (선택): 로드 밸런서를 생성하려는 서브넷의 id를 지정하는 데 사용된다. Network > Networks 에서 찾을 수 있다. 해당 네트워크를 클릭하여 서브넷을 가져온다. @@ -362,19 +346,7 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet] [kubenet](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)을 사용하는 데 필요하다. -## OVirt - -### 노드 이름 - -OVirt 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. -참고로 쿠버네티스 노드 이름은 VM FQDN(Ovirt의 `...` 아래에서 보고된)과 일치해야 한다. - -## Photon - -### 노드 이름 - -Photon 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. -참고로 쿠버네티스 노드 이름은 Photon VM 이름(또는 `--cloud-config` 에서 `overrideIP` 가 true로 설정된 경우, 쿠버네티스 노드 이름은 Photon VM IP 주소와 일치해야 함)과 일치해야 한다. +[kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet ## vSphere @@ -388,46 +360,3 @@ vSphere 6.7U3 미만을 사용할 경우, 인-트리 vSphere 클라우드 제공 {{< /tabs >}} vSphere 클라우드 제공자에 대한 자세한 문서를 보려면, [vSphere 클라우드 제공자 문서 사이트](https://cloud-provider-vsphere.sigs.k8s.io)를 방문한다. - -## IBM 클라우드 쿠버네티스 서비스 - -### 컴퓨트 노드 -IBM 클라우드 쿠버네티스 서비스 제공자를 사용하면, 단일 영역 또는 하나의 리전에서 여러 영역에 걸쳐 가상 노드와 물리(베어 메탈) 노드가 혼합된 클러스터를 생성할 수 있다. 자세한 정보는, [클러스터와 워커(worker) 노드 설정 계획](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)을 참고한다. - -쿠버네티스 노드 오브젝트의 이름은 IBM 클라우드 쿠버네티스 서비스 워커 노드 인스턴스의 프라이빗 IP 주소이다. - -### 네트워킹 -IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [클러스터 네트워킹 구성](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)을 참고한다. - -퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [앱을 노출할 서비스 선택하기](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다. - -### 스토리지 -IBM 클라우드 쿠버네티스 서비스 제공자는 쿠버네티스-네이티브 퍼시스턴트 볼륨을 활용하여 사용자가 파일, 블록 및 클라우드 오브젝트 스토리지를 앱에 마운트할 수 있도록 한다. 데이터를 지속적으로 저장하기 위해 서비스로서의-데이터베이스(database-as-a-service)와 써드파티 애드온을 사용할 수도 있다. 자세한 정보는 [고가용성 퍼시스턴트 스토리지 계획](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)을 참고한다. - -## Baidu 클라우드 컨테이너 엔진 - -### 노드 이름 - -Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 프라이빗 IP 주소를 사용한다. -참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다. - -## Tencent 쿠버네티스 엔진 - -이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다. - -### 노드 이름 - -Tencent 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. -참고로 쿠버네티스 노드 이름은 Tencent VM 프라이빗 IP와 일치해야 한다. - -## Alibaba 클라우드 쿠버네티스 - - 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)이다. - -### 노드 이름 - -Alibaba 클라우드는 노드 이름의 형식을 요구하지는 않지만, kubelet은 `--provider-id=${REGION_ID}.${INSTANCE_ID}` 를 추가해야만 한다. 파라미터 `${REGION_ID}` 는 쿠버네티스의 지역 ID에 해당하고, `${INSTANCE_ID}` 는 Alibaba ECS (Elastic Compute Service) ID를 의미한다. - -### 로드 밸런서 - -[어노테이션](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)을 구성해서 Alibaba 클라우드의 특정 기능을 사용하도록 외부 로드 밸런서를 설정할 수 있다. diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 99e5c27298..41e6422e75 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -112,7 +112,7 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. `memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를 -일반 정수 또는 고정 소수점 정수로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 +일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. ```shell @@ -311,7 +311,7 @@ _임시-스토리지_ 를 사용하여 로컬 임시 저장소를 관리할 수 * `spec.containers[].resources.requests.ephemeral-storage` `ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와 -같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 정수로 표현할 수 있다. +같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/configuration/resource-bin-packing.md index 998456ca49..b6efd38404 100644 --- a/content/ko/docs/concepts/configuration/resource-bin-packing.md +++ b/content/ko/docs/concepts/configuration/resource-bin-packing.md @@ -168,7 +168,7 @@ Node Score: intel.com/foo = resourceScoringFunction((2+2),8) = (100 - ((8-4)*100/8) - = (100 - 25) + = (100 - 50) = 50 = rawScoringFunction(50) = 5 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 5b95d9a484..e5d41e4def 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -350,6 +350,8 @@ NAME TYPE DATA db-user-pass-96mffmfh4k Opaque 2 51s ``` +시크릿에 대한 설명을 볼 수 있다. + ```shell kubectl describe secrets/db-user-pass-96mffmfh4k ``` @@ -1000,6 +1002,8 @@ kubectl create secret generic prod-db-secret --from-literal=username=produser -- secret "prod-db-secret" created ``` +테스트 환경의 자격 증명에 대한 시크릿을 만들 수도 있다. + ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ``` diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index f17841027b..497f4cbfda 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -94,7 +94,7 @@ weight: 10 이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다. {{< note >}} -쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다. +기본 쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다. 도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다. {{< /note >}} @@ -262,7 +262,7 @@ EOF 이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다. -그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-accounts/)) 리소스에 +그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 리소스에 imagePullSecrets을 셋팅하여 자동화할 수 있다. 자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index 8a98d9bd28..e4e2b9b96d 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -93,7 +93,7 @@ kubectl에서 1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. 2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. 3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. -4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. +4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/#스케줄러-익스텐션) 섹션에 설명되어 있다. 5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. 6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. 7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index bcd9bb9945..9e55dfae04 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -9,7 +9,7 @@ weight: 30 오퍼레이터(Operator)는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는 -쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)를 따른다. +쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/architecture/controller/)를 따른다. @@ -126,6 +126,3 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기 * 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기 * 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기 - - - diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 71e78eae96..d67ee4d993 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -248,6 +248,16 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하 EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다. {{< /note >}} +#### 볼륨 확장 시 오류 복구 + +기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다. + +1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다. +2. PVC를 삭제한다. PV에는 `Retain` 반환 정책이 있으므로 PVC를 재생성할 때 데이터가 손실되지 않는다. +3. 새 PVC를 바인딩할 수 있도록 PV 명세에서 `claimRef` 항목을 삭제한다. 그러면 PV가 `Available` 상태가 된다. +4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다. +5. PV의 반환 정책을 복원하는 것을 잊지 않는다. + ## 퍼시스턴트 볼륨의 유형 diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 9aadbe3726..5ad5a938eb 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -87,14 +87,14 @@ spec: 사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다. -``` +```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: test-snapshot spec: source: - volumeSnapshotContentName: test-content + volumeSnapshotContentName: test-content ``` ## 볼륨 스냅샷 컨텐츠 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index dca5a651f4..3fd5f2830a 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -1,7 +1,7 @@ --- title: 데몬셋 content_type: concept -weight: 50 +weight: 40 --- diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index e782c7c60d..0e5c5e94fb 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -6,7 +6,7 @@ feature: 쿠버네티스는 애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 성장하는 디플로이먼트 솔루션 생태계를 이용한다. content_type: concept -weight: 30 +weight: 10 --- @@ -82,7 +82,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. 만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다. - ```shell + ``` NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 0/3 0 0 1s ``` @@ -98,21 +98,21 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다. 다음과 유사하게 출력된다. - ```shell + ``` Waiting for rollout to finish: 2 out of 3 new replicas have been updated... deployment.apps/nginx-deployment successfully rolled out ``` 4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다. 다음과 유사하게 출력된다. - ```shell + ``` NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 18s ``` 디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다. 5. 디플로이먼트로 생성된 레플리카셋(`rs`)을 보려면, `kubectl get rs` 를 실행한다. 다음과 유사하게 출력된다. - ```shell + ``` NAME DESIRED CURRENT READY AGE nginx-deployment-75675f5897 3 3 3 18s ``` @@ -129,7 +129,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 6. 각 파드에 자동으로 생성된 레이블을 보려면, `kubectl get pods --show-labels` 를 실행한다. 다음과 유사하게 출력된다. - ```shell + ``` NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index 902326a9a4..21bfce8fc2 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,7 +1,7 @@ --- title: 가비지(Garbage) 수집 content_type: concept -weight: 70 +weight: 60 --- diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index a77678a975..b0ae483ad4 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -5,7 +5,7 @@ feature: title: 배치 실행 description: > 쿠버네티스는 서비스 외에도 배치와 CI 워크로드를 관리할 수 있으며, 원하는 경우 실패한 컨테이너를 교체할 수 있다. -weight: 70 +weight: 50 --- diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index a23c3605cf..5c0852dc12 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -1,7 +1,7 @@ --- title: 레플리카셋 content_type: concept -weight: 10 +weight: 20 --- @@ -241,9 +241,10 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한 `.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)이다. [앞서](#레플리카-셋의-작동-방식) 논의한 것처럼 이 레이블은 소유될 가능성이 있는 파드를 식별하는데 사용된다. 우리 `frontend.yaml` 예제에서의 셀렉터는 다음과 같다. -```shell + +```yaml matchLabels: - tier: frontend + tier: frontend ``` 레플리카셋에서 `.spec.template.metadata.labels`는 `spec.selector`과 일치해야 하며 diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index e800a253d7..22cdfa42a2 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -7,7 +7,7 @@ feature: 오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다. content_type: concept -weight: 20 +weight: 90 --- @@ -112,7 +112,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다. 레플리케이션 컨트롤러 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/). +컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다. 레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index d588276b25..6b8299a0c3 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -1,7 +1,7 @@ --- title: 스테이트풀셋 content_type: concept -weight: 40 +weight: 30 --- diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 42e0b14607..1daf452200 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -255,7 +255,7 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버 * [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여 다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다. * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다. -* [PodDisruptionBudget](https://kubernetes.io/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다. +* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다. * 파드는 쿠버네티스 REST API의 최상위 리소스이다. [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) 오브젝트 정의는 오브젝트를 상세히 설명한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 148abd29a3..0741dc7546 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -33,7 +33,7 @@ content_type: concept ## CLI 레퍼런스 * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. - * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. + * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 컴포넌트 레퍼런스 @@ -48,6 +48,6 @@ content_type: concept ## 설계 문서 -쿠버네티스 기능에 대한 설계 문서의 아카이브. [쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다. - - +쿠버네티스 기능에 대한 설계 문서의 아카이브. +[쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 +[쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다. diff --git a/content/ko/docs/reference/command-line-tools-reference/_index.md b/content/ko/docs/reference/command-line-tools-reference/_index.md index 0639d05b15..14025d0f71 100644 --- a/content/ko/docs/reference/command-line-tools-reference/_index.md +++ b/content/ko/docs/reference/command-line-tools-reference/_index.md @@ -1,5 +1,4 @@ --- title: 커맨드 라인 도구 레퍼런스 weight: 60 -toc-hide: true --- diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 1e2796b484..2b730af9c4 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -437,7 +437,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 참고한다. - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. - `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다. -- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 대해 `LocalStorageCapacityIsolation`이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)에 대한 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 프로젝트 쿼터를 사용하여 파일시스템 사용보다는 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다. +- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 대해 + `LocalStorageCapacityIsolation`이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)에 대한 + 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 프로젝트 쿼터를 사용하여 파일시스템 사용보다는 + [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다. - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. diff --git a/content/ko/docs/reference/glossary/kube-apiserver.md b/content/ko/docs/reference/glossary/kube-apiserver.md index b219acb340..201bc3780e 100644 --- a/content/ko/docs/reference/glossary/kube-apiserver.md +++ b/content/ko/docs/reference/glossary/kube-apiserver.md @@ -2,21 +2,21 @@ title: API 서버 id: kube-apiserver date: 2018-04-12 -full_link: /docs/reference/generated/kube-apiserver/ +full_link: /ko/docs/concepts/overview/components/#kube-apiserver short_description: > 쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트. -aka: +aka: - kube-apiserver tags: - architecture - fundamental --- - API 서버는 쿠버네티스 API를 + API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다. - + 쿠버네티스 API 서버의 주요 구현은 [kube-apiserver](/docs/reference/generated/kube-apiserver/) 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. diff --git a/content/ko/docs/reference/glossary/managed-service.md b/content/ko/docs/reference/glossary/managed-service.md index 282bc7e9d6..d34e2832e3 100644 --- a/content/ko/docs/reference/glossary/managed-service.md +++ b/content/ko/docs/reference/glossary/managed-service.md @@ -2,17 +2,21 @@ title: 매니지드 서비스 id: managed-service date: 2018-04-12 -full_link: +full_link: short_description: > 타사 공급자가 유지보수하는 소프트웨어. -aka: +aka: tags: - extension --- - 타사 공급자가 유지보수하는 소프트웨어. + 타사 공급자가 유지보수하는 소프트웨어. - + -매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고 GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다. [서비스 카탈로그](/docs/concepts/service-catalog/)는 {{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다. +매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고 +GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다. +[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는 +{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는 +매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다. diff --git a/content/ko/docs/reference/issues-security/_index.md b/content/ko/docs/reference/issues-security/_index.md index a1f56bc08e..596a6e01a4 100644 --- a/content/ko/docs/reference/issues-security/_index.md +++ b/content/ko/docs/reference/issues-security/_index.md @@ -1,5 +1,4 @@ --- title: 쿠버네티스 이슈와 보안 weight: 10 -toc-hide: true --- diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 3446c11a06..bf3e0cc81d 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -8,16 +8,10 @@ card: -참고 항목: [Kubectl 개요](/ko/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath). - -이 페이지는 `kubectl` 커맨드의 개요이다. - - +이 페이지는 일반적으로 사용하는 `kubectl` 커맨드와 플래그에 대한 목록을 포함한다. -# kubectl - 치트 시트 - ## Kubectl 자동 완성 ### BASH @@ -77,7 +71,8 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \ kubectl config unset users.foo # foo 사용자 삭제 ``` -## Apply +## Kubectl apply + `apply`는 쿠버네티스 리소스를 정의하는 파일을 통해 애플리케이션을 관리한다. `kubectl apply`를 실행하여 클러스터에 리소스를 생성하고 업데이트한다. 이것은 프로덕션 환경에서 쿠버네티스 애플리케이션을 관리할 때 권장된다. [Kubectl Book](https://kubectl.docs.kubernetes.io)을 참고한다. ## 오브젝트 생성 @@ -200,6 +195,13 @@ kubectl get events --sort-by=.metadata.creationTimestamp # 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다. kubectl diff -f ./my-manifest.yaml + +# 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다. +# 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다. +kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다. +kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' ``` ## 리소스 업데이트 @@ -249,6 +251,7 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", ``` ## 리소스 편집 + 편집기로 모든 API 리소스를 편집. ```bash @@ -382,15 +385,12 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 `--v=8` | HTTP 요청 내용을 표시. `--v=9` | 내용을 잘라 내지 않고 HTTP 요청 내용을 표시. - - ## {{% heading "whatsnext" %}} - -* [kubectl 개요](/ko/docs/reference/kubectl/overview/)에 대해 더 배워보자. +* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자. * [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다. * 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다. -* 더 많은 [kubectl 치트 시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4) 커뮤니티 확인 +* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다. diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index 6eab3cbafe..04b3e6c1d3 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -8,10 +8,16 @@ card: --- -Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. 구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. - -이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. +Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. +구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. +KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +파일을 지정할 수 있다. +이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. +지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 +[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. +설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. @@ -25,9 +31,12 @@ kubectl [command] [TYPE] [NAME] [flags] 다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다. -* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. 예: `create`, `get`, `describe`, `delete` +* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. +예: `create`, `get`, `describe`, `delete` -* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. +* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 + 단수형, 복수형 또는 약어 형식을 지정할 수 있다. + 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. ```shell kubectl get pod pod1 @@ -205,11 +214,13 @@ kubectl [command] [TYPE] [NAME] -o kubectl get pod web-pod-13je7 -o yaml ``` -기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. +기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은 +[kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. #### 사용자 정의 열 {#custom-columns} -사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다. 사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=` 또는 `-o custom-columns-file=` +사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다. +사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=` 또는 `-o custom-columns-file=` ##### 예제 @@ -493,8 +504,6 @@ kubectl whoami Current user: plugins-user ``` - - ## {{% heading "whatsnext" %}} * [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. diff --git a/content/ko/docs/reference/setup-tools/_index.md b/content/ko/docs/reference/setup-tools/_index.md index 268a280c50..051fba4c5d 100644 --- a/content/ko/docs/reference/setup-tools/_index.md +++ b/content/ko/docs/reference/setup-tools/_index.md @@ -1,6 +1,4 @@ --- title: 설치 도구 레퍼런스 weight: 50 -toc-hide: true --- - diff --git a/content/ko/docs/reference/setup-tools/kubeadm/_index.md b/content/ko/docs/reference/setup-tools/kubeadm/_index.md index 085b1e1ef9..683f78000b 100644 --- a/content/ko/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/ko/docs/reference/setup-tools/kubeadm/_index.md @@ -1,6 +1,30 @@ --- title: "Kubeadm" weight: 10 -toc-hide: true +no_list: true +content_type: concept +card: + name: reference + weight: 40 --- +Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 `kubeadm init` 과 `kubeadm join` 을 제공하도록 만들어진 도구이다. + +kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계 상, 시스템 프로비저닝이 아닌 부트스트랩(bootstrapping)만 다룬다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드별 애드온과 같은 다양한 있으면 좋은(nice-to-have) 애드온을 설치하는 것은 범위에 포함되지 않는다. + +대신, 우리는 더 높은 수준의 맞춤형 도구가 kubeadm 위에 구축될 것으로 기대하며, 이상적으로는, 모든 배포의 기반으로 kubeadm을 사용하면 규격을 따르는 클러스터를 더 쉽게 생성할 수 있다. + +## 설치 방법 + +kubeadm을 설치하려면, [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참고한다. + +## {{% heading "whatsnext" %}} + +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다. +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다. +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다. +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다. +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join` 을 위한 토큰을 관리한다. +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다. +* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력한다. +* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다. diff --git a/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md deleted file mode 100644 index f011459dd6..0000000000 --- a/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: kubeadm 개요 -weight: 10 -card: - name: reference - weight: 40 ---- -Kubeadm은 쿠버네티스 클러스터를 "빠른 경로"로 생성하기 위한 모범 사례인 `kubeadm init`과 `kubeadm join`을 제공하기 위해 구성된 도구이다. - -kubeadm은 최소 기능 클러스터(minimum viable cluster)를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계상, 부트스트랩만 다루며, 머신을 프로비저닝하지는 않는다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드 별 애드온과 같은 다양한 기능을 갖춘 애드온을 설치하는 것은 범위에 포함되지 않는다. - -대신, kubeadm 위에 있는 더 높은 수준의 맞춤형 도구가 구축될 것으로 예상되며, 모든 배포의 기초로서 kubeadm을 사용하면 적합한 클러스터를 보다 쉽게 만들 수 있다. - -## 설치하는 방법 - -kubeadm을 설치하려면 [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참조한다. - -## 다음 내용 - -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩 함 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커 노드를 부트스트랩 후 클러스터에 결합시킴 -* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 최신 버전으로 업그레이드 -* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x이하의 버전을 사용하여 클러스터를 초기화한 경우, 클러스터를 설정하여 `kubeadm upgrade`하기 위해 사용 -* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join`을 위한 토큰 관리 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init`나 `kubeadm join`를 의한 호스트에 대해서 변경된 사항을 되돌림 -* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력 -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티의 피드백 수집을 위해서 기능 미리 보기를 제공 - diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index a224824aa1..7751aef2f4 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -1,5 +1,4 @@ --- title: 쿠버네티스 API 사용하기 weight: 10 -toc-hide: true --- diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index a0a87e0837..5b9f179cbc 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -22,8 +22,8 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. ## 공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리 -다음의 클라이언트 라이브러리들은 [쿠버네티스 SIG API -Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다. +다음의 클라이언트 라이브러리들은 +[쿠버네티스 SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다. | 언어 | 클라이언트 라이브러리 | 예제 프로그램 | @@ -73,6 +73,3 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | | Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | - - - diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 39c2d07464..aef121b731 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -68,7 +68,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. 시스템에 도커를 설치하기 위해서 아래의 커맨드들을 사용한다. {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04+" >}} +{{% tab name="Ubuntu 16.04+" %}} ```shell # (도커 CE 설치) @@ -122,8 +122,8 @@ mkdir -p /etc/systemd/system/docker.service.d systemctl daemon-reload systemctl restart docker ``` -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" >}} +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} ```shell # (도커 CE 설치) @@ -177,7 +177,7 @@ mkdir -p /etc/systemd/system/docker.service.d systemctl daemon-reload systemctl restart docker ``` -{{< /tab >}} +{{% /tab %}} {{< /tabs >}} 부팅 시 도커 서비스를 시작하려면, 다음 명령을 실행한다. @@ -217,73 +217,117 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Debian" >}} +{{% tab name="Debian" %}} +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다. + +| 운영 체제 | $OS | +| ---------------- | ----------------- | +| Debian Unstable | `Debian_Unstable` | +| Debian Testing | `Debian_Testing` | + +
+그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. +예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다. +사용자의 설치를 특정 릴리스에 고정할 수 있다. +버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다. +
+ +그런 다음, 아래를 실행한다. ```shell -# Debian 개발 배포본(Unstable/Sid) -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list + +curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add - +curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add - + +apt-get update +apt-get install cri-o cri-o-runc ``` +{{% /tab %}} + +{{% tab name="Ubuntu" %}} + +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다. + +| 운영 체제 | $OS | +| ---------------- | ----------------- | +| Ubuntu 20.04 | `xUbuntu_20.04` | +| Ubuntu 19.10 | `xUbuntu_19.10` | +| Ubuntu 19.04 | `xUbuntu_19.04` | +| Ubuntu 18.04 | `xUbuntu_18.04` | + +
+그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. +예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다. +사용자의 설치를 특정 릴리스에 고정할 수 있다. +버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다. +
+ +그런 다음, 아래를 실행한다. ```shell -# Debian Testing -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - +echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list + +curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add - +curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add - + +apt-get update +apt-get install cri-o cri-o-runc +``` +{{% /tab %}} + +{{% tab name="CentOS" %}} + +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다. + +| 운영 체제 | $OS | +| ---------------- | ----------------- | +| Centos 8 | `CentOS_8` | +| Centos 8 Stream | `CentOS_8_Stream` | +| Centos 7 | `CentOS_7` | + +
+그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. +예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다. +사용자의 설치를 특정 릴리스에 고정할 수 있다. +버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다. +
+ +그런 다음, 아래를 실행한다. +```shell +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo +yum install cri-o ``` -```shell -# Debian 10 -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - -``` +{{% /tab %}} -```shell -# Raspbian 10 -echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - -``` - -그리고 다음과 같이 CRI-O 설치한다. -```shell -sudo apt-get install cri-o-1.17 -``` -{{< /tab >}} - -{{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}} - -```shell -# 패키지 리포지터리 설정 -. /etc/os-release -sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" -wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - -sudo apt-get update -``` - -```shell -# CRI-O 설치 -sudo apt-get install cri-o-1.17 -``` -{{< /tab >}} - -{{< tab name="CentOS/RHEL 7.4+" >}} - -```shell -# 선행 조건 설치 -curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo -curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo -``` - -```shell -# CRI-O 설치 -yum install -y cri-o -``` - -{{< tab name="openSUSE Tumbleweed" >}} +{{% tab name="openSUSE Tumbleweed" %}} ```shell sudo zypper install cri-o ``` -{{< /tab >}} +{{% /tab %}} +{{% tab name="Fedora" %}} + +`$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. +예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다. + +사용할 수 있는 버전을 찾으려면 다음을 실행한다. +```shell +dnf module list cri-o +``` +CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다. + +그런 다음, 아래를 실행한다. +```shell +dnf module enable cri-o:$VERSION +dnf install cri-o +``` + +{{% /tab %}} {{< /tabs >}} ### CRI-O 시작 @@ -407,5 +451,3 @@ kubeadm을 사용하는 경우에도 마찬가지로, 수동으로 ## 다른 CRI 런타임: frakti 자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다. - - diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index e6c80f32ed..89b653cb6f 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -12,4 +12,4 @@ content_type: concept 시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다. 만약 태스크 페이지를 작성하고 싶다면, -[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다. +[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/open-a-pr/)를 참조한다. 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 c28c51ea16..faeeb1045e 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -8,9 +8,6 @@ content_type: concept 여기에서는 클러스터와 통신을 하는 다양한 방식에 대해서 다룰 것이다. - - - ## 처음이라면 kubectl을 사용하여 액세스 @@ -29,8 +26,9 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확 kubectl config view ``` -많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 -완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다. +많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 +kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는 +[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다. ## REST API에 직접 액세스 @@ -165,7 +163,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터 * 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다. * client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다. -Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다. [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. 만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다. @@ -174,7 +172,7 @@ Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동 Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다. -Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다. [예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다. ### 다른 언어 @@ -219,7 +217,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. 이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 -[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 +[노드들](/ko/docs/concepts/architecture/nodes/), +[파드들](/ko/docs/concepts/workloads/pods/pod/), +[서비스들](/ko/docs/concepts/services-networking/service/)은 모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 할 수 없을 것이다. @@ -230,7 +230,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. - 공인 IP를 통해 서비스에 액세스. - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 - 서비스를 사용한다. [서비스](/docs/user-guide/services)와 + 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 5a585eddd4..b0cc036c91 100644 --- a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,20 +6,15 @@ weight: 110 -이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지 -살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자. - - - +이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, +어떻게 볼륨을 이용하는지 살펴본다. 컨테이너 간에 +[프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 +통해 통신할 수 있는 방법을 참고하자. ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - ## 두 개의 컨테이너를 실행하는 파드 생성 @@ -103,14 +98,15 @@ nginx 컨테이너의 쉘(shell)을 실행한다. Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 디렉터리에 `index.html` 파일을 생성했었음을 상기하자. `curl`을 이용하여 nginx 웹 서버에 HTTP GET 요청을 보낸다. - root@two-containers:/# curl localhost +``` +root@two-containers:/# curl localhost +``` 출력을 보면, nginx 웹 서버에서 debian 컨테이너에서 쓰여진 웹 페이지를 제공하는 것을 알 수 있다. - debian 컨테이너에서 안녕하세요 - - - +``` +debian 컨테이너에서 안녕하세요 +``` @@ -127,20 +123,14 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 이 예제에서 볼륨은 파드의 생명 주기 동안 컨테이너를 위한 통신 방법으로 이용했다. 파드가 삭제되고 재생성되면, 공유 볼륨에 저장된 데이터는 잃어버린다. - - - ## {{% heading "whatsnext" %}} -* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 -더 공부한다. +* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 더 공부한다. -* [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여 -더 공부한다. +* [모듈 구조를 위한 합성 컨테이너 구조](https://www.slideshare.net/Docker/slideshare-burns)에 관하여 더 공부한다. -* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 -확인한다. +* [파드에서 저장소로 볼륨을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 확인한다. * [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다. 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 3aa05a92b0..fb67628dec 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 @@ -10,15 +10,19 @@ card: -대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다. +대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. +대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, +컨테이너화 된 애플리케이션을 트러블슈팅할 수 있으며, 클러스터 리소스들을 관리할 수 있다. +대시보드를 통해 클러스터에서 동작 중인 애플리케이션의 정보를 볼 수 있고, +개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) +생성하거나 수정할 수 있다. +예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 +또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다. 또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다. ![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png) - - - ## 대시보드 UI 배포 @@ -32,7 +36,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a ## 대시보드 UI 접근 -클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다. +클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. +현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. +본 시연을 위한 토큰을 생성하기 위해서는, +[샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다. {{< warning >}} 시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다. @@ -55,13 +62,17 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 ## 웰컴 뷰 -초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. 이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. 게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` [네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다. +초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. +이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. +게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` +[네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다. ![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png) ## 컨테이너화 된 애플리케이션 배포 -대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. +대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. +애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드할 수 있다. 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다. @@ -69,17 +80,29 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 배포 마법사는 다음 정보를 제공한다. -- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다. +- **앱 이름** (필수): 애플리케이션 이름. + [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 + 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다. - 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다. + 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. + 소문자로 시작해야 하며, 소문자 또는 숫자로 끝나고, + 소문자, 숫자 및 대쉬(-)만을 포함해야 한다. 24 문자만을 제한한다. + 처음과 끝의 스페이스는 무시된다. -- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다. +- **컨테이너 이미지** (필수): + 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/) + 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. + 컨테이너 이미지 사양은 콜론으로 끝난다. -- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다. +- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. + 값은 양의 정수만 허용됩니다. - 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. + 클러스터에 의도한 파드의 수를 유지하기 위해서 + [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. -- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. +- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 + 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 + 노출시키고 싶을 수 있다. {{< note >}} 외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다. @@ -87,13 +110,22 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다. - 서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. + 서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, + 두 개의 포트를 정의해야 한다. + 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. + 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. + 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다. -- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. +- **설명**: 입력하는 텍스트값은 디플로이먼트에 + [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 + 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. -- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. +- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 + 애플리케이션 이름과 버전이다. + 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 + 생성할 때 추가적으로 정의할 수 있다. 예를 들면: @@ -104,66 +136,111 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 track=stable ``` -- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다. +- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. + 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. + 논리적으로 명명된 그룹으로 리소스들을 분할할 수 있다. - 대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다. - 네임스페이스 이름은 숫자로만 구성할 수 없다. 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다. + 대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. + 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다. + 네임스페이스 이름은 숫자로만 구성할 수 없다. + 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다. - 네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다. + 네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. + 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다. -- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다. +- **이미지 풀(Pull) 시크릿**: + 특정 도커 컨테이너 이미지가 프라이빗한 경우, + [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 자격 증명을 요구한다. - 대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다. + 대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성할 수 있도록 한다. + 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. + 시크릿 내용은 base64 인코딩 방식이며, + [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다. + 시크릿 이름은 최대 253 문자를 포함할 수 있다. 이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다. -- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다. +- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: + 컨테이너를 위한 최소 [리소스 상한](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)을 + 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다. -- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다. +- **커맨드 실행** 와 **커맨드 인수 실행**: + 기본적으로, 컨테이너는 선택된 도커 이미지의 + [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. + 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다. -- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. +- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 + [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 + 프로세스들과 동등한지 아닌지 정의한다. + 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. -- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. +- **환경 변수**: 쿠버네티스 서비스를 + [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. + 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. + 애플리케이션들이 서비스를 찾는데 사용된다. + 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. ### YAML 또는 JSON 파일 업로드 -쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. +쿠버네티스는 선언적인 설정을 제공한다. +이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 +이용하여 YAML 또는 JSON 설정 파일에 저장한다. -배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. +배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, +애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. ## 대시보드 사용 다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다. ### 탐색 -클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다. +클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. +기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, +이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다. 대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다. #### 어드민 개요 -클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다. +클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. +노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. +세부사항은 각 노드들에 대한 사용량, 사양, 상태, +할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다. #### 워크로드 -선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. -워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. +선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. +애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 +각각의 워크로드 종류는 따로 보여진다. +리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 +워크로드에 대한 실용적인 정보를 요약한다. + +워크로드에 대한 세부적인 것들은 상태와 사양 정보, +오프젝트들 간의 관계를 보여준다. +예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. #### 서비스 -외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. + +외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 +쿠버네티스 리소스들을 보여준다. +이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 +외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. #### 스토리지 + 스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다. #### 컨피그 맵과 시크릿 -클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다. + +클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. +컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다. #### 로그 뷰어 -파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. 뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다. + +파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. +뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다. ![Logs viewer](/images/docs/ui-dashboard-logs-view.png) - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md index 1b92c1283a..21be3970d2 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -6,13 +6,10 @@ content_type: task 이 페이지는 쿠버네티스 API를 사용하여 클러스터에 접근하는 방법을 보여준다. - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - ## 쿠버네티스 API에 접근 @@ -170,7 +167,7 @@ client-go는 자체 API 오브젝트를 정의하므로, 필요한 경우, 기 {{< /note >}} -Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다. 이 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. ```golang @@ -199,7 +196,7 @@ func main() { [Python 클라이언트](https://github.com/kubernetes-client/python)를 사용하려면, 다음 명령을 실행한다. `pip install kubernetes` 추가 설치 옵션은 [Python Client Library 페이지](https://github.com/kubernetes-client/python)를 참고한다. -Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)를 참고한다. ```python @@ -229,7 +226,7 @@ mvn install 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)를 참고한다. -Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)를 참고한다. ```java @@ -283,7 +280,7 @@ public class KubeConfigFileClientExample { [dotnet 클라이언트](https://github.com/kubernetes-client/csharp)를 사용하려면, 다음 명령을 실행한다. `dotnet add package KubernetesClient --version 1.6.1` 추가 설치 옵션은 [dotnet Client Library 페이지](https://github.com/kubernetes-client/csharp)를 참고한다. 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)를 참고한다. -dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs)를 참고한다. ```csharp @@ -318,7 +315,7 @@ namespace simple [JavaScript 클라이언트](https://github.com/kubernetes-client/javascript)를 설치하려면, 다음 명령을 실행한다. `npm install @kubernetes/client-node` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)를 참고한다. -JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을 +JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)를 참고한다. ```javascript @@ -387,7 +384,7 @@ exampleWithKubeConfig = do 호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는 이를 자동으로 수행한다. -API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/user-guide/service-accounts) +API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 자격 증명을 사용하는 것이다. 기본적으로, 파드는 서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은 해당 파드에 있는 각 컨테이너의 파일시스템 트리의 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md index 0b1cf9540f..e65ec1cc1f 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -17,7 +17,8 @@ content_type: task ## 클러스터에서 실행되는 서비스에 접근 -쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 +쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), +[파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수 없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서 도달할 수 없다. diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md index 440ece1531..abe33c5be5 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md @@ -10,9 +10,6 @@ content_type: concept 노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 쿠버네티스 API 버전 업그레이드. - - - ## 클러스터 생성과 설정 @@ -77,24 +74,33 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레 * [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) * ... -위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) 페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다. +위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) +페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다. ## 클러스터 크기 재조정 -[노드 자가 등록 모드](/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를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다. +[노드 자가 등록 모드](/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 gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE ``` -인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에 Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다. 사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다. +인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에 +Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다. +사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다. 다른 환경에서는 사용자가 직접 머신을 구성하고 어떤 머신에서 API 서버가 동작하는지를 Kubelet에 알려줘야 할 수도 있다. ### Azure Kubernetes Service (AKS) 클러스터 크기 재조정 -Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서 이를 설명하고 있다. +Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며 +[Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서 +이를 설명하고 있다. ### 클러스터 오토스케일링 @@ -102,7 +108,8 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터 GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 재조정하도록 클러스터를 구성할 수 있다. -[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. +[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 +사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. 이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. 여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다. @@ -181,7 +188,8 @@ kubectl uncordon $NODENAME 해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; -이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/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/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md index 0e5a87bc82..ad76009844 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -5,16 +5,16 @@ min-kubernetes-server-version: v1.12 --- -이 페이지는 클러스터 안에서 사용자의 -DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고 +이 페이지는 클러스터 안에서 사용자의 +DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고 DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한다. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} -클러스터는 CoreDNS 애드온을 구동하고 있어야 한다. -[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기) +클러스터는 CoreDNS 애드온을 구동하고 있어야 한다. +[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기) 는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다. {{% version-check %}} @@ -23,11 +23,11 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한 ## 소개 -DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 -사용하여 자동으로 시작되는 쿠버네티스 +DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 +사용하여 자동으로 시작되는 쿠버네티스 내장 서비스이다. -쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우, +쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우, CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다. {{< note >}} @@ -35,19 +35,19 @@ CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다. {{< /note >}} -CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. +CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. Kubelet 은 `--cluster-dns=` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다. -DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=` 플래그를 +DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=` 플래그를 통하여 로컬 도메인을 설정할 수 있다. DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다. 더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다. -만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우, +만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우, 파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다. 파드의 DNS 변환도 노드와 동일하게 작동해야 한다. -그 외에는 [알려진 이슈](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참고한다. +그 외에는 [알려진 이슈](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues)를 참고한다. 만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우, 사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다. @@ -63,7 +63,7 @@ CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/speci CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다. 이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다. 클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여 -해당 클러스터에 대한 DNS 서비스 검색 동작을 +해당 클러스터에 대한 DNS 서비스 검색 동작을 변경할 수 있다. 쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다. @@ -164,7 +164,7 @@ data: } ``` -`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의 +`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의 자동 변환을 지원한다. {{< note >}} @@ -248,11 +248,11 @@ my.cluster.local:53 { ## CoreDNS로의 이관 -kube-dns에서 CoreDNS로 이관하기 위하여, +kube-dns에서 CoreDNS로 이관하기 위하여, kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는 [블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다. -또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를 +또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를 사용하여 이관할 수도 있다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 9e48ea900a..ff8d67a7ef 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -24,11 +24,8 @@ min-kubernetes-server-version: 1.18 1. 추가 컨트롤 플레인 노드를 업그레이드한다. 1. 워커(worker) 노드를 업그레이드한다. - - ## {{% heading "prerequisites" %}} - - 1.17.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다. - [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). - 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다. @@ -43,8 +40,6 @@ min-kubernetes-server-version: 1.18 또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다. 예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다. - - ## 업그레이드할 버전 결정 diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index d59cdd3e15..1b0873f74a 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -10,14 +10,9 @@ weight: 40 이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다. - - ## {{% heading "prerequisites" %}} - -[kubeadm 시작하기](/docs/getting-started-guides/kubeadm/)의 1, 2, 3 단계를 완료하자. - - +[kubeadm 시작하기](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)의 1, 2, 3 단계를 완료하자. @@ -33,9 +28,8 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman * [Romana 네트워크 폴리시의 예](https://github.com/romana/core/blob/master/doc/policy.md). * 네트워크 폴리시 API. - - ## {{% heading "whatsnext" %}} - -로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. +로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 +[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 +따라 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 3aea719c56..b20c2e9890 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -8,14 +8,10 @@ weight: 50 이 페이지는 네트워크 폴리시(NetworkPolicy)로 위브넷(Weave Net)를 사용하는 방법을 살펴본다. - - ## {{% heading "prerequisites" %}} - -쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 [kubeadm 시작하기 안내서](/docs/getting-started-guides/kubeadm/)를 따른다. - - +쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 +[kubeadm 시작하기 안내서](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)를 따른다. @@ -23,7 +19,10 @@ weight: 50 [애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다. -쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의 네크워크 정책 어노테이션을 자동으로 모니터링하며, 정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는 [네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다. +쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의 +네크워크 정책 어노테이션을 자동으로 모니터링하며, +정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는 +[네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다. ## 설치 시험 @@ -47,9 +46,9 @@ weave-net-pmw8w 2/2 Running 0 9d 위브넷 파드를 가진 각 노드와 모든 파드는 `Running`이고 `2/2 READY`이다(`2/2`는 각 파드가 `weave`와 `weave-npc`를 가지고 있음을 뜻한다). - - ## {{% heading "whatsnext" %}} - -위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다. +위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 +[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 +따라 할 수 있다. 질문이 있으면 +[슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다. diff --git a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md index 77ac7ce6d5..2d1d482585 100644 --- a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md @@ -80,7 +80,7 @@ spec: requests: cpu: 700m memory: 200Mi - ... + ... status: qosClass: Guaranteed ``` @@ -269,4 +269,3 @@ kubectl delete namespace qos-example * [API 오브젝트 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/) * [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/) - diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md index dc774b9ce3..a831f5d267 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -5,24 +5,20 @@ content_type: task -이 페이지는 초기화 컨테이너의 실행과 관련된 문제를 -조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `` 으로, -초기화 컨테이너를 `` 과 +이 페이지는 초기화 컨테이너의 실행과 관련된 문제를 +조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `` 으로, +초기화 컨테이너를 `` 과 `` 로 표시한다. - - ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의 +* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의 기본 사항에 익숙해야 한다. * 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다. - - ## 초기화 컨테이너의 상태 체크하기 @@ -33,7 +29,7 @@ content_type: task kubectl get pod ``` -예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중 +예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중 하나가 성공적으로 완료되었음을 나타낸다. ``` @@ -41,7 +37,7 @@ NAME READY STATUS RESTARTS AGE 0/1 Init:1/2 0 7s ``` -상태값과 그 의미에 대한 추가 예제는 +상태값과 그 의미에 대한 추가 예제는 [파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다. ## 초기화 컨테이너에 대한 상세 정보 조회하기 @@ -82,7 +78,7 @@ Init Containers: ... ``` -파드 스펙의 `status.initContainerStatuses` 필드를 읽어서 +파드 스펙의 `status.initContainerStatuses` 필드를 읽어서 프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다. @@ -102,8 +98,8 @@ kubectl get pod nginx --template '{{.status.initContainerStatuses}}' kubectl logs -c ``` -셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가 -실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에 +셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가 +실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에 `set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다. @@ -112,8 +108,8 @@ kubectl logs -c ## 파드의 상태 이해하기 -`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의 -실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는 +`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의 +실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는 동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다. 상태 | 의미 diff --git a/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md index cf0b639cbd..54a2ae61b0 100644 --- a/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md +++ b/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md @@ -7,7 +7,7 @@ title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로 Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은 [스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는 -[스택드라이버 로깅으로 로깅하기](/docs/user-guide/logging/stackdriver)에 자세히 설명되어 있다. +[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다. 이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로, [엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고 @@ -87,7 +87,8 @@ monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h 엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에 있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해, -[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에 대한 지침을 참고한다. +[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에 +대한 지침을 참고한다. 브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면, 다음과 같은 상태 페이지가 표시된다. @@ -118,5 +119,3 @@ monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h 키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한 아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다. - - diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index ee6991ef30..758c782a44 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -10,9 +10,6 @@ content_type: concept `kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. - - - ## 메트릭 API @@ -38,11 +35,19 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 ### CPU -CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다. +CPU는 일정 기간 동안 +[CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 +평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 +누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. +kubelet은 비율 계산에 사용할 윈도우를 선택한다. ### 메모리 -메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다. 이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다. 그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다. 쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다. 호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다. +메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다. +이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다. +그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다. +쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다. +호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다. ## 메트릭 서버 @@ -51,9 +56,11 @@ CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage- 디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 [디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다. -메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다. +메트릭 서버는 각 노드에서 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해 +노출된 Summary API에서 메트릭을 수집한다. 메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 통해 메인 API 서버에 등록된다. -[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. +[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 +메트릭 서버에 대해 자세하게 배울 수 있다. 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 34c51ad860..584afa5b19 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 @@ -5,38 +5,41 @@ title: 리소스 모니터링 도구 -애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, -애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. -컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), -[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 -검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 +애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, +애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. +컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), +[서비스](/ko/docs/concepts/services-networking/service), +그리고 전체 클러스터의 특성을 검사하여 +쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다. -이 정보는 애플리케이션의 성능을 평가하고 +이 정보는 애플리케이션의 성능을 평가하고 병목 현상을 제거하여 전체 성능을 향상할 수 있게 해준다. - - -쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다. +쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. +신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 +[완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다. ## 리소스 메트릭 파이프라인 -리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) -컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 +리소스 메트릭 파이프라인은 +[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) +컨트롤러와 같은 클러스터 구성요소나 +`kubectl top` 유틸리티에 관련되어 있는 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 [metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 -의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. +의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. -metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의 -[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리 +metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의 +[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 CPU와 메모리 사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서 머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는 컨테이너로 변환하고 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서 -개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의 +개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의 통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. 그 다음으로 취합된 파드 리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는 -kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서 +kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서 제공된다. ## 완전한 메트릭 파이프라인 @@ -50,5 +53,3 @@ kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1 CNCF 프로젝트인, [프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다. CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 쿠버네티스 문서의 범위가 아니다. - - diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md index c7057c1887..191e82021c 100644 --- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -9,28 +9,21 @@ weight: 20 본 페이지는 쿠버네티스 파드의 컨테이너를 위한 환경 변수를 정의하는 방법에 대해 설명한다. - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - ## 컨테이너를 위한 환경 변수 정의하기 -파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할 +파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할 수 있다. 환경 변수를 설정하려면, 구성 파일에 `env`나 `envFrom` 필드를 포함시켜야 한다. 이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는 -값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 +값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다. {{< codenew file="pods/inject/envars.yaml" >}} @@ -81,24 +74,24 @@ weight: 20 1. 셸에서 빠져나오기 위해, `exit`을 입력한다. {{< note >}} -`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 +`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 안에서 명시된 모든 환경 변수들을 오버라이딩한다. {{< /note >}} {{< note >}} -환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다. +환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다. 사용하기 전에 순서에 주의한다. {{< /note >}} ## 설정 안에서 환경 변수 사용하기 -파드의 구성 파일 안에서 정의한 환경 변수는 -파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, -구성 파일 안의 다른 곳에서 사용할 수 있다. -아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 -`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, -그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은 -이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 +파드의 구성 파일 안에서 정의한 환경 변수는 +파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, +구성 파일 안의 다른 곳에서 사용할 수 있다. +아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 +`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, +그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은 +이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 사용된다. ```yaml @@ -123,12 +116,8 @@ spec: 컨테이너가 생성되면, `echo Warm greetings to The Most Honorable Kubernetes` 커맨드가 컨테이너에서 실행된다. - - ## {{% heading "whatsnext" %}} - * [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다. -* [시크릿을 환경 변수로 사용하기](/docs/user-guide/secrets/#using-secrets-as-environment-variables)에 대해 알아본다. +* [시크릿을 환경 변수로 사용하기](/ko/docs/concepts/configuration/secret/#시크릿을-환경-변수로-사용하기)에 대해 알아본다. * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다. - diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 925f174206..659836833a 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -10,17 +10,10 @@ weight: 10 이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다. - - - ## {{% heading "prerequisites" %}} * 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다. - - - - ## 데몬셋 업데이트 전략 @@ -164,7 +157,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system {{< note >}} 삭제된 파드가 컨트롤러에 의해 제어되지 않거나 파드가 복제되지 않은 경우 서비스 중단이 -발생한다. 이 때 [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)정책도 적용되지 +발생한다. 이 때 [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)정책도 적용되지 않는다. {{< /note >}} @@ -200,5 +193,3 @@ kubectl delete ds fluentd-elasticsearch -n kube-system * [태스크: 데몬셋에서 롤백 수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다. * [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다. - - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index f3b15d3206..26fa2830ff 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -1005,5 +1005,5 @@ template: * [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) -* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/) +* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md index ac7690a325..a10cd29362 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -167,5 +167,5 @@ kubectl create --edit -f /tmp/srv.yaml * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) -* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/) +* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md index 49691c341b..b9c90475d8 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -150,5 +150,5 @@ template: * [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) -* [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/) +* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index 6a45b5a73b..2da789fb0d 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -832,6 +832,6 @@ deployment.apps "dev-my-nginx" deleted * [Kustomize](https://github.com/kubernetes-sigs/kustomize) -* [Kubectl Book](https://kubectl.docs.kubernetes.io) -* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) -* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +* [Kubectl 북](https://kubectl.docs.kubernetes.io) +* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) +* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 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 b42f8952b8..73c0310493 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,11 +10,9 @@ Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. -이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/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/)를 참고하기 바란다. ## {{% heading "prerequisites" %}} @@ -457,12 +455,12 @@ Events: ## 부록: 수량 HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 -쿠버네티스에서 사용하는 *수량* 숫자 표기법을 사용한다. +쿠버네티스에서 사용하는 +{{< glossary_tooltip term_id="quantity" text="수량">}} 숫자 표기법을 사용한다. 예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다. 메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며, 일반적으로 수량을 밀리단위로 반환한다. 10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다. -더 많은 정보를 위해서는 [수량에 관한 용어집](/docs/reference/glossary?core-object=true#term-quantity) 을 참고하기 바란다. ## 부록: 다른 가능한 시나리오 diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md index baf003f595..4d65b37503 100644 --- a/content/ko/docs/tasks/tools/install-kubectl.md +++ b/content/ko/docs/tasks/tools/install-kubectl.md @@ -9,13 +9,18 @@ card: --- -쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/user-guide/kubectl/)을 사용하면, 쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며 로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는, [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다. +쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/reference/kubectl/kubectl/)을 사용하면, +쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. +kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며 +로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는, +[kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다. ## {{% heading "prerequisites" %}} -클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. - +클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. +예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. +최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. @@ -306,7 +311,12 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다. ## kubectl 구성 확인 -kubectl이 쿠버네티스 클러스터를 찾아 접근하려면, [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를 사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)이 필요하다. 기본적으로, kubectl 구성은 `~/.kube/config` 에 있다. +kubectl이 쿠버네티스 클러스터를 찾아 접근하려면, +[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를 +사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는 +[kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)이 +필요하다. +기본적으로, kubectl 구성은 `~/.kube/config` 에 있다. 클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다. @@ -514,5 +524,6 @@ compinit * [Minikube 설치](/ko/docs/tasks/tools/install-minikube/) * 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다. * [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/) -* 직접 생성하지 않은 클러스터에 접근해야하는 경우, [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다. +* 직접 생성하지 않은 클러스터에 접근해야하는 경우, + [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다. * [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기 diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 35b4365eb2..4a566e3776 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -118,7 +118,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ``` {{< note >}} - `kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자. +`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자. {{< /note >}} ## 서비스 만들기 diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 8fa348393e..6e6eabda96 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -29,7 +29,7 @@ weight: 10

쿠버네티스 파드

-

모듈 2에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 파드를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커 또는 rkt와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:

+

모듈 2에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 파드를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:

  • 볼륨과 같은, 공유 스토리지
  • 클러스터 IP 주소와 같은, 네트워킹
    • @@ -51,7 +51,7 @@ weight: 10

- 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커 또는 rkt와 같은)들의 그룹이고 공유 스토리지 (볼륨), IP 주소 그리고 그것을 동작시키는 방식에 대한 정보를 포함하고 있다. + 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹이고 공유 스토리지 (볼륨), IP 주소 그리고 그것을 동작시키는 방식에 대한 정보를 포함하고 있다.

@@ -79,7 +79,7 @@ weight: 10

모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.

  • Kubelet은, 쿠버네티스 마스터와 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.
    • -
  • (도커, rkt)와 같은 컨테이너 런타임은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.
    • +
  • 컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.
diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 382f096375..9d47599589 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -150,7 +150,7 @@ ip addr 그런 다음 `wget` 을 사용해서 로컬 웹 서버에 쿼리한다. ```shell -# 10.0.170.92를 파드의 IPv4 주소로 변경한다. +# "10.0.170.92"를 "clusterip"라는 이름의 서비스의 IPv4 주소로 변경한다. wget -qO - 10.0.170.92 ``` ``` @@ -409,10 +409,10 @@ client_address=198.51.100.79 끝나는 패킷 전달자를 이용한다. 첫 번째 범주의 로드밸런서는 진짜 클라이언트 IP를 통신하기 위해 -HTTP [Forwarded]](https://tools.ietf.org/html/rfc7239#section-5.2) +HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2) 또는 [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 헤더 또는 -[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)과 +[프록시 프로토콜](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)과 같은 로드밸런서와 백엔드 간에 합의된 프로토콜을 사용해야 한다. 두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는 HTTP 헬스 체크를 생성하여 diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index ea6b3063cc..33fdcb4dbe 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -7,9 +7,13 @@ weight: 30 -이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. 데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). 이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다. +이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. +데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). +이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다. -*스테이트풀셋* 은 상태있는 애플리케이션을 쿠버네티스 클러스터에 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 참조한다. +*스테이트풀셋* 은 상태있는 애플리케이션을 쿠버네티스 클러스터에 쉽게 배포할 수 있게 한다. +이 튜토리얼에서 이용할 기능의 자세한 정보는 +[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 참조한다. {{< note >}} 카산드라와 쿠버네티스는 클러스터 맴버라는 의미로 _노드_ 라는 용어를 사용한다. 이 @@ -38,12 +42,17 @@ weight: 30 {{< include "task-tutorial-prereqs.md" >}} -이 튜토리얼을 완료하려면 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip text="서비스" term_id="service" >}}, {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다. +이 튜토리얼을 완료하려면, +{{< glossary_tooltip text="파드" term_id="pod" >}}, +{{< glossary_tooltip text="서비스" term_id="service" >}}, +{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다. ### 추가적인 Minikube 설정 요령 {{< caution >}} -[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. 이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자. +[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. +이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 +발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자. ```shell minikube start --memory 5120 --cpus=4 @@ -51,11 +60,11 @@ minikube start --memory 5120 --cpus=4 {{< /caution >}} - ## 카산드라를 위한 헤드리스 서비스 생성하기 {#creating-a-cassandra-headless-service} -쿠버네티스 에서 {{< glossary_tooltip text="서비스" term_id="service" >}}는 동일 작업을 수행하는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 집합을 기술한다. +쿠버네티스 에서 {{< glossary_tooltip text="서비스" term_id="service" >}}는 동일 작업을 수행하는 +{{< glossary_tooltip text="파드" term_id="pod" >}}의 집합을 기술한다. 다음의 서비스는 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다. @@ -83,14 +92,17 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cassandra ClusterIP None 9042/TCP 45s ``` -이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한 [서비스 디버깅하기](/docs/tasks/debug-application-cluster/debug-service/)를 읽어보자. +`cassandra` 서비스가 보이지 않는다면, 이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한 +[서비스 디버깅하기](/docs/tasks/debug-application-cluster/debug-service/)를 +읽어보자. ## 카산드라 링을 생성하는 스테이트풀셋 이용하기 스테이트풀셋 매니페스트에는 다음을 포함하는데 3개 파드로 구성된 카산드라 링을 생성한다. {{< note >}} -이 예는 Minikube를 위한 기본 프로비저너이다. 다음 스테이트풀셋을 작업하는 클라우드 환경에서 갱신한다. +이 예는 Minikube를 위한 기본 프로비저너이다. +다음 스테이트풀셋을 작업하는 클라우드 환경에서 갱신한다. {{< /note >}} {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}} @@ -182,12 +194,13 @@ kubectl apply -f cassandra-statefulset.yaml kubectl edit statefulset cassandra ``` - 이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 `replicas` 필드이다. 다음 예제는 스테이트풀셋 파일에서 발췌했다. + 이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 `replicas` 필드이다. + 다음 예제는 스테이트풀셋 파일에서 발췌했다. ```yaml - # Please edit the object below. Lines beginning with a '#' will be ignored, - # and an empty file will abort the edit. If an error occurs while saving this file will be - # reopened with the relevant failures. + # 다음의 오브젝트를 수정한다. '#'로 시작하는 행은 무시되고, + # 빈 파일은 편집을 중단한다. 저장할 때 오류가 발생하면 이 파일이 + # 관련 실패와 함께 다시 열린다. # apiVersion: apps/v1 kind: StatefulSet @@ -225,10 +238,12 @@ kubectl apply -f cassandra-statefulset.yaml ## {{% heading "cleanup" %}} -스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다. 당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다. +스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다. +당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다. {{< warning >}} -스토리지 클래스와 리클레임 정책에 따라 *퍼시스턴스볼륨클레임* 을 삭제하면 그와 연관된 볼륨도 삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자. +스토리지 클래스와 리클레임 정책에 따라 *퍼시스턴스볼륨클레임* 을 삭제하면 그와 연관된 볼륨도 +삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자. {{< /warning >}} 1. 다음 명령어(한 줄로 연결된)를 실행하여 카산드라 스테이트풀셋을 모두 제거하자. @@ -271,6 +286,3 @@ kubectl apply -f cassandra-statefulset.yaml * 어떻게 [스테이트풀셋 스케일](/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다. * [*쿠버네티스시드제공자*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)에 대해 더 살펴본다. * 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다. - - - diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 1e0aefd4a3..cdd803d57f 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -2,7 +2,7 @@ title: "예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기" content_type: tutorial weight: 20 -card: +card: name: tutorials weight: 40 title: "스테이트풀셋 예시: Wordpress와 퍼시스턴트 볼륨" @@ -76,9 +76,9 @@ MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필 ## kustomization.yaml 생성하기 ### 시크릿 생성자 추가 -[시크릿](/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다. +[시크릿](/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 생성자로 시크릿을 생성할 수 있다. -다음 명령어로 `kustomization.yaml` 내에 시크릿 제네레이터를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다. +다음 명령어로 `kustomization.yaml` 내에 시크릿 생성자를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다. ```shell cat <./kustomization.yaml @@ -98,7 +98,7 @@ EOF 다음의 매니페스트는 단일-인스턴스 WordPress 디플로이먼트를 기술한다. WordPress 컨테이너는 웹사이트 데이터 파일을 위해 `/var/www/html`에 퍼시스턴트볼륨을 마운트한다. `WORDPRESS_DB_HOST` 환경 변수에는 위에서 정의한 MySQL 서비스의 이름이 설정되며, WordPress는 서비스를 통해 데이터베이스에 접근한다. -`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다. +`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다. {{< codenew file="application/wordpress/wordpress-deployment.yaml" >}} @@ -107,13 +107,13 @@ EOF ```shell curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml ``` - + 2. WordPress 구성 파일을 다운로드한다. ```shell curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml ``` - + 3. 두 파일을 `kustomization.yaml`에 추가하자. ```shell @@ -151,7 +151,7 @@ kubectl apply -k ./ ```shell kubectl get pvc ``` - + {{< note >}} PV를 프로비저닝하고 정착(bound)시키는데 수 분이 걸릴 수 있다. {{< /note >}} diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index a253f04a0b..8e17a85527 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -7,25 +7,23 @@ weight: 40 이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org) 쿠버네티스에서 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 -[파드디스룹선버짓(PodDisruptionBudget)](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과 -[파드안티어피니티(PodAntiAffinity)](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. - +[PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)과 +[파드안티어피니티(PodAntiAffinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. ## {{% heading "prerequisites" %}} - 이 튜토리얼을 시작하기 전에 다음 쿠버네티스 개념에 친숙해야 한다. -- [파드](/docs/user-guide/pods/single-container/) +- [파드](/ko/docs/concepts/workloads/pods/) - [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) - [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) - [퍼시스턴트볼륨](/ko/docs/concepts/storage/volumes/) - [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) - [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) -- [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget) -- [파드안티어피니티](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티) -- [kubectl CLI](/docs/user-guide/kubectl/) +- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets) +- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) +- [kubectl CLI](/docs/reference/kubectl/kubectl/) 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. @@ -42,7 +40,7 @@ weight: 40 - 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가. - 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가. - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. -- 어떻게 파드디스룹션버짓을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. +- 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. @@ -63,17 +61,17 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변 ## ZooKeeper 앙상블 생성하기 -아래 메니페스트에는 +아래 매니페스트에는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스), [서비스](/ko/docs/concepts/services-networking/service/), -[파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget), +[PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다. {{< codenew file="application/zookeeper/zookeeper.yaml" >}} 터미널을 열고 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 명령어로 -메니페스트를 생성하자. +매니페스트를 생성하자. ```shell kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml @@ -118,7 +116,7 @@ zk-2 1/1 Running 0 40s ``` 스테이트풀셋 컨트롤러는 3개의 파드를 생성하고, 각 파드는 -[ZooKeeper](http://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다. +[ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다. ### 리더 선출 촉진 @@ -339,7 +337,7 @@ zk-0 0/1 Terminating 0 11m zk-0 0/1 Terminating 0 11m ``` -`zookeeper.yaml` 메니페스트를 다시 적용한다. +`zookeeper.yaml` 매니페스트를 다시 적용한다. ```shell kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml @@ -446,7 +444,7 @@ volumeMounts: `zk` 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 `퍼시스턴트볼륨`을 ZooKeeper의 서버 디렉터리에 마운트한다. -파드를 재스케쥴할 때에도 ZooKeeper의 WAL을 통해 이뤄진 모든 쓰기와 +파드를 재스케줄할 때에도 ZooKeeper의 WAL을 통해 이뤄진 모든 쓰기와 모든 그 스냅샷도 내구성을 유지한다. ## 일관된 구성 보장하기 @@ -456,7 +454,7 @@ ZooKeeper의 서버 디렉터리에 마운트한다. ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다. 또한 Zab 프로토콜의 일관된 설정도 네트워크에 걸쳐 올바르게 동작하기 위해서 -필요하다. 이 예시에서는 메니페스트에 구성을 직접 포함시켜서 일관된 구성을 +필요하다. 이 예시에서는 매니페스트에 구성을 직접 포함시켜서 일관된 구성을 달성한다. `zk` 스테이트풀셋을 살펴보자. @@ -495,7 +493,7 @@ ZooKeeper 서버를 시작하는데 사용한 명령어는 커맨드라인 파 ### 로깅 설정하기 `zkGenConfig.sh` 스크립트로 생성된 파일 중 하나는 ZooKeeper의 로깅을 제어한다. -ZooKeeper는 [Log4j](http://logging.apache.org/log4j/2.x/)를 이용하며 +ZooKeeper는 [Log4j](https://logging.apache.org/log4j/2.x/)를 이용하며 기본 로깅 구성으로는 시간과 파일 크기 기준의 롤링 파일 어펜더를 사용한다. `zk` `스테이트풀셋`의 한 파드에서 로깅 설정을 살펴보는 아래 명령어를 이용하자. @@ -517,7 +515,10 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n ``` -이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다. 표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다. 또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여 로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다. +이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다. +표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다. +또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여 +로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다. 파드의 마지막 20줄의 로그를 가져오는 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) 명령을 이용하자. @@ -787,7 +788,7 @@ zk-0 1/1 Running 1 1h ### 준비도 테스트 -준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케쥴링되고 건강하다. +준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케줄링되고 건강하다. 프로세스가 준비되면 입력을 처리할 수 있다. 활성도는 필수적이나 준비도의 조건으로는 충분하지 않다. 몇몇 경우 특별히 초기화와 종료 시에 프로세스는 살아있지만 @@ -796,7 +797,7 @@ zk-0 1/1 Running 1 1h 준비도 검사를 지정하면, 쿠버네티스는 준비도가 통과할 때까지 애플리케이션 프로세스가 네트워크 트래픽을 수신하지 않게 한다. -ZooKeeper 서버에서는 준비도가 활성도를 내포한다. 그러므로 `zookeeper.yaml` 메니페스트에서 +ZooKeeper 서버에서는 준비도가 활성도를 내포한다. 그러므로 `zookeeper.yaml` 매니페스트에서 준비도 검사는 활성도 검사와 동일하다. ```yaml @@ -823,7 +824,9 @@ ZooKeeper는 변조된 데이터를 성공적으로 커밋하기 위한 서버 중단을 방지하기 위해 개별 시스템의 손실로 인해 모범 사례에서는 동일한 시스템에 여러 인스턴스의 응용 프로그램을 함께 배치하는 것을 배제한다. -기본적으로 쿠버네티스는 동일 노드상에 `스테이트풀셋`의 파드를 위치시킬 수 있다. 생성한 3개의 서버 앙상블에서 2개의 서버가 같은 노드에 있다면, 그 노드는 실패하고 ZooKeeper 서비스 클라이언트는 그 파드들의 최소 하나가 재스케쥴링될 때까지 작동 중단을 경험할 것이다. +기본적으로 쿠버네티스는 동일 노드상에 `스테이트풀셋`의 파드를 위치시킬 수 있다. +생성한 3개의 서버 앙상블에서 2개의 서버가 같은 노드에 있다면, 그 노드는 실패하고 +ZooKeeper 서비스 클라이언트는 그 파드들의 최소 하나가 재스케줄링될 때까지 작동 중단을 경험할 것이다. 노드 실패하는 사건 중에도 중요 시스템의 프로세스가 재스케줄될 수 있게 항상 추가적인 용량을 프로비전해야 한다. 그렇게 하면 쿠버네티스 스케줄러가 @@ -909,7 +912,7 @@ zk-pdb N/A 1 1 kubectl get pods -w -l app=zk ``` -다른 터미널에서 현재 스케쥴되는 파드의 노드를 살펴보자. +다른 터미널에서 현재 스케줄되는 파드의 노드를 살펴보자. ```shell for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done @@ -921,7 +924,7 @@ kubernetes-node-ixsl kubernetes-node-i4c4 ``` -`zk-0`파드가 스케쥴되는 노드를 통제하기 위해 +`zk-0`파드가 스케줄되는 노드를 통제하기 위해 [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)를 이용하자. ```shell @@ -937,7 +940,7 @@ node "kubernetes-node-group-pb41" drained ``` 클러스터에 4개 노드가 있기 때문에 `kubectl drain`이 성공하여 -`zk-0`을 다른 노드로 재스케쥴링 된다. +`zk-0`을 다른 노드로 재스케줄링 된다. ``` NAME READY STATUS RESTARTS AGE @@ -957,7 +960,7 @@ zk-0 1/1 Running 0 1m ``` 계속해서 `스테이트풀셋`의 파드를 첫 터미널에서 지켜보고 -`zk-1` 이 스케쥴된 노드를 비워보자. +`zk-1` 이 스케줄된 노드를 비워보자. ```shell kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned @@ -969,7 +972,8 @@ pod "zk-1" deleted node "kubernetes-node-ixsl" drained ``` -`zk-1` 파드는 스케쥴되지 않는데 이는 `zk` `스테이트풀셋`이 오직 2개 노드가 스케쥴되도록 파드를 위치시키는 것을 금하는 `파드안티어피니티` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다. +`zk-1` 파드는 스케줄되지 않는데 이는 `zk` `StatefulSet`이 오직 2개 노드가 스케줄되도록 파드를 위치시키는 것을 금하는 +`PodAntiAffinity` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다. ```shell kubectl get pods -w -l app=zk @@ -1051,7 +1055,7 @@ kubectl uncordon kubernetes-node-pb41 node "kubernetes-node-pb41" uncordoned ``` -`zk-1`은 이 노드에서 재스케쥴된다. `zk-1`이 Running과 Ready가 될 때까지 기다리자. +`zk-1`은 이 노드에서 재스케줄된다. `zk-1`이 Running과 Ready가 될 때까지 기다리자. ```shell kubectl get pods -w -l app=zk @@ -1083,7 +1087,7 @@ zk-1 0/1 Running 0 13m zk-1 1/1 Running 0 13m ``` -`zk-2`가 스케쥴된 노드를 비워보자. +`zk-2`가 스케줄된 노드를 비워보자. ```shell kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data @@ -1111,7 +1115,10 @@ kubectl uncordon kubernetes-node-ixsl node "kubernetes-node-ixsl" uncordoned ``` -`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다. drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다. +`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다. +drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 +서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. +파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다. ## {{% heading "cleanup" %}}