From 92544b7583ff2d2b0143f35d0765900191cec417 Mon Sep 17 00:00:00 2001 From: "Yuk, Yongsu" Date: Fri, 20 Dec 2019 14:11:32 +0900 Subject: [PATCH] Update to outdated files in the dev-1.17-ko.1 (#18070) * Update to outdated files in the dev-1.17-ko.1 * Fix typo daemonset.md * Update cloud-provider.md * Update URLs. * Apply suggestions from code review Co-Authored-By: Seokho Son * Update user-guide-windows-containers.md * Update nodes.md Co-authored-by: Seokho Son --- content/ko/_index.html | 4 +- .../concepts/architecture/cloud-controller.md | 2 +- .../ko/docs/concepts/architecture/nodes.md | 51 ++++---- .../concepts/overview/what-is-kubernetes.md | 6 +- .../services-networking/endpoint-slices.md | 17 ++- .../workloads/controllers/daemonset.md | 18 +-- .../workloads/controllers/statefulset.md | 14 ++- .../workloads/controllers/ttlafterfinished.md | 5 +- .../pods/pod-topology-spread-constraints.md | 2 +- content/ko/docs/reference/_index.md | 2 +- .../docs/reference/glossary/cloud-provider.md | 24 +++- content/ko/docs/reference/glossary/etcd.md | 2 +- .../ko/docs/reference/kubectl/cheatsheet.md | 4 +- .../reference/using-api/client-libraries.md | 1 + content/ko/docs/setup/_index.md | 6 +- .../docs/setup/best-practices/certificates.md | 4 +- .../setup/learning-environment/minikube.md | 3 + .../container-runtimes.md | 21 ++-- .../production-environment/tools/kops.md | 68 ++++++++++- .../windows/user-guide-windows-containers.md | 110 +++++++++++++++++- .../configure-access-multiple-clusters.md | 2 +- .../configure-dns-cluster.md | 4 +- .../administer-cluster/cluster-management.md | 3 + .../kustomization.md | 12 +- .../horizontal-pod-autoscale-walkthrough.md | 6 +- .../horizontal-pod-autoscale.md | 2 +- .../ko/docs/tasks/tools/install-minikube.md | 43 +++++++ .../configure-redis-using-configmap.md | 3 +- 28 files changed, 333 insertions(+), 106 deletions(-) diff --git a/content/ko/_index.html b/content/ko/_index.html index f179c6576214a..59188feb67f4c 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -45,12 +45,12 @@

150+ 마이크로서비스를 쿠버네티스로 마이그레이션하는


- Attend KubeCon in San Diego on Nov. 18-21, 2019 + Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020



- Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020 + Attend KubeCon in Shanghai on July 28-30, 2020
diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index ac298f9dc3d9a..e21ff73c49283 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -52,7 +52,7 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시 볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다. {{< /note >}} -CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 Flex 볼륨을 사용하기 위한 것이었다. 그러나, CSI라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다. +CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다. 이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index e2a3813ec6d05..dffd6bd2db064 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -78,19 +78,10 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. -1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는 -[taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다. -마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다. -대신 노드의 taint와 toleration을 살펴본다. - -현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다. -아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의 -taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다. - -{{< caution >}} -이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 -시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다. -{{< /caution >}} +노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는 +[테인트(taints)](/docs/concepts/configuration/taint-and-toleration/)를 생성한다. +스케줄러가 파드를 노드에 할당할 때, 스케줄러는 파드가 극복(tolerate)하는 테인트가 +아닌 한, 노드 계정의 테인트를 고려 한다. ### 용량과 할당가능 {#capacity} @@ -169,18 +160,28 @@ NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. -쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가 -된다. node lease 기능은 1.14 부터 기본값으로 활성화 되었으며, 베타 기능이다 -(기능 게이트 `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). -node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해 -갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고 -NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다. -NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만 -(기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.) -노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다. -노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과 -성능 두 가지 측면에서 노드 하트비트를 상당히 -경제적이도록 해준다. +#### 하트비트 + +쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다. +하트비트의 두 가지 형태는 `NodeStatus` 와 +[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io) 이다. +각 노드에는 `kube-node-lease` 라는 +{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다. +리스는 경량 리소스로, 클러스터가 확장될 때 +노드의 하트비트 성능을 향상 시킨다. + +kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 +의무가 있다. + +- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우, + `NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트 + 주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초 + 보다 훨씬 길다). +- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기). + 리스 업데이트는 `NodeStatus` 업데이트와는 + 독립적으로 발생한다. + +#### 안정성 쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에 문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 569a3cef273e7..3402d68c6c7a1 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -64,7 +64,7 @@ card: * **자동화된 복구(self-healing)** 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. * **시크릿과 구성 관리** -쿠버네티스를 사용하면 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다. +쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다. ## 쿠버네티스가 아닌 것 @@ -74,9 +74,9 @@ card: * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다. * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다. -* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. +* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. -* 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. +* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. * 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 4f0354e9e1b4d..481233d4e0049 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -12,7 +12,7 @@ weight: 10 {{% capture overview %}} -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를 추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한 @@ -24,7 +24,7 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워 ## 엔드포인트 슬라이스 리소스 {#endpointslice-resource} -쿠버네티스에서 엔드포인트 슬라이스는 일련의 네트워크 엔드 포인트에 대한 +쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한 참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 EndpointSlice 컨트롤러는 자동으로 엔드포인트 슬라이스를 생성한다. 이 엔드포인트 슬라이스는 서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트 @@ -34,13 +34,13 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워 리소스 샘플이 있다. ```yaml -apiVersion: discovery.k8s.io/v1alpha1 +apiVersion: discovery.k8s.io/v1beta1 kind: EndpointSlice metadata: name: example-abc labels: kubernetes.io/service-name: example -addressType: IP +addressType: IPv4 ports: - name: http protocol: TCP @@ -48,7 +48,6 @@ ports: endpoints: - addresses: - "10.1.2.3" - - "2001:db8::1234:5678" conditions: ready: true hostname: pod-1 @@ -65,6 +64,14 @@ endpoints: 신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는 서비스에 대해 성능 향상을 제공해야 한다. +## 주소 유형 + +EndpointSlice는 다음 주소 유형을 지원한다. + +* IPv4 +* IPv6 +* FQDN (Fully Qualified Domain Name) + ## 사용동기 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 023bc74bc8b77..dccde89562178 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도 - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. - 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행. -- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행. +- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행. 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, @@ -95,21 +95,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ## 데몬 파드가 스케줄 되는 방법 -### 데몬셋 컨트롤러에 의해서 스케줄(1.12 이후로 기본값으로 사용 안함) +### 기본 스케줄러로 스케줄 -일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 머신이 선택된다. 그러나 데몬셋 -컨트롤러에 의해 생성된 파드는 이미 머신이 선택되어 있다(`.spec.nodeName` 이 -파드가 생성될 때 명시되므로, 스케줄러에서는 무시된다). 그러므로 다음과 같다. - - - 데몬셋 컨트롤러는 노드의 [`unschedulable`](/ko/docs/concepts/architecture/nodes/#수동-노드-관리) - 필드를 존중하지 않는다. - - 데몬셋 컨트롤러는 스케줄러가 시작되지 않은 경우에도 파드를 만들 수 있어 클러스터 부트스트랩을 - 도울 수도 있다. - - -### 기본 스케줄러로 스케줄(1.12 이후로 기본값으로 사용) - -{{< feature-state state="beta" for-kubernetes-version="1.12" >}} +{{< feature-state state="stable" for-kubernetes-version="1.17" >}} 데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index f5b802107e70e..3b95e2b47ccf1 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -44,10 +44,6 @@ weight: 40 ## 구성 요소 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다. -* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다. -* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다. -* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다. - ```yaml apiVersion: v1 kind: Service @@ -99,6 +95,12 @@ spec: storage: 1Gi ``` +위의 예시에서: + +* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다. +* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다. +* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다. + ## 파드 셀렉터 스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다. @@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 +클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 아니라면 `cluster.local`로 설정된다. {{< /note >}} @@ -260,7 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다. * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다. -* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다. +* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다. {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index 94b34ff0ce789..2f8cbc2a61c73 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. -알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) -`TTLAfterFinished` 를 통해 활성화 될 수 있다. +알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께 +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다. {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index a07326c905020..8ebdab23455bf 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -144,7 +144,7 @@ spec: +---------------+-------+ | zoneA | zoneB | +-------+-------+-------+ -| node1 | node2 | nod3 | +| node1 | node2 | node3 | +-------+-------+-------+ | P P | P | P P | +-------+-------+-------+ diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 631dc10d13247..d12c0a9d28276 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -18,11 +18,11 @@ content_template: templates/concept * [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 * 쿠버네티스 API 버전 + * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) - * [1.12](/docs/reference/generated/kubernetes-api/v1.12/) ## API 클라이언트 라이브러리 diff --git a/content/ko/docs/reference/glossary/cloud-provider.md b/content/ko/docs/reference/glossary/cloud-provider.md index a0fcc998e9297..e649147b3231c 100644 --- a/content/ko/docs/reference/glossary/cloud-provider.md +++ b/content/ko/docs/reference/glossary/cloud-provider.md @@ -4,14 +4,28 @@ id: cloud-provider date: 2018-04-12 full_link: /docs/concepts/cluster-administration/cloud-providers short_description: > - 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사. + 클라우드 컴퓨팅 플랫폼을 제공하는 조직. -aka: +aka: +- Cloud Service Provide tags: - community --- - 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사. + 클라우드 컴퓨팅 플랫폼을 제공하는 사업자 또는 다른 조직 - + -클라우드 컴퓨팅 플랫폼을 제공하는 클라우드 공급자 또는 클라우드 서비스 공급자(CSP)라고 한다. 이들은 인프라 서비스(IaaS) 또는 플랫폼 서비스(PaaS)를 제공할 수 있다. 클라우드 공급자는 쿠버네티스 클러스터를 호스트 하며 클러스터와 상호작용하는 로드밸런서, 스토리지 클래스 등의 서비스도 제공한다. +클라우드 공급자, 때로는 클라우드 서비스 공급자(CSP) 부르며, +클라우드 컴퓨팅 플랫폼 또는 서비스를 제공한다. + +많은 클라우드 공급자들은 관리되는 인프라를 제공한다(이를 +Infrastructure as a Service 또는 IaaS 라 부른다). +관리되는 인프라를 통해 클라우드 공급자는 +서버, 스토리지 그리고 네트워킹을 담당하고 쿠버네티스 +클러스터 실행과 같은 계층을 관리한다. + +사용자는 쿠버네티스를 관리되는 서비스로 찾을 수 있다. 때로는 이것을 +Platform as a Service 또는 PaaS라 부른다. 관리되는 쿠버네티스를 사용하면 +클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라, +노드와 연관되는 인프라(네트워킹, 스토리지 그리고 로드밸런서와 같은 기타 요소) +를 책임진다. diff --git a/content/ko/docs/reference/glossary/etcd.md b/content/ko/docs/reference/glossary/etcd.md index ea5a38d015bf1..b9a06255854c6 100644 --- a/content/ko/docs/reference/glossary/etcd.md +++ b/content/ko/docs/reference/glossary/etcd.md @@ -19,4 +19,4 @@ tags: 이 데이터를 [백업](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)하는 계획은 필수이다. -etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다. +etcd에 대한 자세한 정보는, 공식 [문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 231373cbec5b1..a964a4a6d6e0b 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -156,9 +156,9 @@ kubectl get services --sort-by=.metadata.name # 재시작 횟수로 정렬된 파드의 목록 조회 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# test 네임스페이스 내 파드 목록을 용량으로 정렬해서 조회 +# test 네임스페이스를 가지는 PersistentVolumes을 용량별로 정렬해서 조회 -kubectl get pods -n test --sort-by=.spec.capacity.storage +kubectl get pv -n test --sort-by=.spec.capacity.storage # app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회 kubectl get pods --selector=app=cassandra -o \ diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index ddd47ef1e812c..e333e4012140d 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -59,6 +59,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) | | Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | +| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 50928ca6e1f8d..d10d66cd204db 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -72,7 +72,7 @@ card: | [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | | [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| | [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ -| [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | | +| [Containership](https://containership.io) | ✔ |✔ | | | | | [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | | [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ | [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | @@ -80,12 +80,12 @@ card: | [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ | [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ | [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [사용자 정의 확장](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | -| [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | | +| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | | [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | | [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | | [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | -| [KubeOne](https://github.com/kubermatic/kubeone) | | ✔ | ✔ | ✔ | ✔ | ✔ | +| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | | [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | | [KubeSail](https://kubesail.com/) | ✔ | | | | | | [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 810c02f4ea7de..4d8d8ed976455 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -102,11 +102,11 @@ kubeadm 사용자만 해당: | 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| | etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | -| etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | +| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | | kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | | kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file | | kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file | -| apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | +| kube-apiserver-kubelet-client| apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file | | front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index d9fce5275fc6c..4c8df0c805d06 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -324,6 +324,9 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설 `minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. +### minikube 업그레이드 +[minikube 업그레이드](https://minikube.sigs.k8s.io/docs/start/macos/)를 본다. + ## 클러스터와 상호 작용하기 ### Kubectl diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 1c83aaf7bc87c..b5758996af3bc 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -62,17 +62,18 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## Docker 각 머신들에 대해서, Docker를 설치한다. -버전 18.06.2가 추천된다. 그러나 1.11, 1.12, 1.13, 17.03 그리고 18.09도 동작하는 것으로 알려져 있다. +버전 19.03.4가 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. 쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다. 시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다. {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Ubuntu 16.04+" codelang="bash" >}} # Docker CE 설치 ## 리포지터리 설정 ### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치 -apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common +apt-get update && apt-get install \ + apt-transport-https ca-certificates curl software-properties-common ### Docker의 공식 GPG 키 추가 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - @@ -84,7 +85,10 @@ add-apt-repository \ stable" ## Docker CE 설치. -apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu +apt-get update && apt-get install \ + containerd.io=1.2.10-3 \ + docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) # 데몬 설정. cat > /etc/docker/daemon.json <}} + +`minikube start` 시 `--vm-driver` 를 설정하려면, 아래에 `` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--vm-driver` 값의 전체 목록은 [VM driver 문서에서 지정하기](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)에서 확인할 수 있다. + +{{< /note >}} + +```shell +minikube start --vm-driver= +``` + +`minikube start` 가 완료되면, 아래 명령을 실행해서 클러스터의 상태를 확인한다. + +```shell +minikube status +``` + +만약 클러스터가 실행 중이면, `minikube status` 의 출력은 다음과 유사해야 한다. + +``` +host: Running +kubelet: Running +apiserver: Running +kubeconfig: Configured +``` + +Minikube가 선택한 하이퍼바이저와 작동하는지 확인한 후에는, Minikube를 계속 사용하거나 클러스터를 중지할 수 있다. 클러스터를 중지하려면 다음을 실행한다. + +```shell +minikube stop +``` + ## 새롭게 시작하기 위해 모두 정리하기 {#cleanup-local-state} 이전에 Minikube를 설치했었다면, 다음을 실행한다. diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index 27db50cdf19c2..bcc25433400a4 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -21,7 +21,8 @@ content_template: templates/tutorial {{% capture prerequisites %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + * 예시는 `kubectl` 1.14 이상 버전에서 동작한다. * [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다.