From 986be3462d83703ffa4d71ffdbb02585af7b7804 Mon Sep 17 00:00:00 2001 From: June Yi Date: Fri, 11 Sep 2020 23:21:22 +0900 Subject: [PATCH] First Korean l10n work for release-1.19 - Translate tasks/job/parallel-processing-expansion.md into Korean (#23544) - Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720) - Translate reference/scheduling/policies.md in Korean (#23690) - Update outdated files in the dev-1.19-ko.1 branch (#23702) - Modify translation access by Korean glossary (#23627) Co-authored-by: Jerry Park Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com> Co-authored-by: coolguyhong --- content/ko/_index.html | 5 - content/ko/docs/_index.md | 1 + .../concepts/architecture/cloud-controller.md | 3 +- .../docs/concepts/architecture/controller.md | 73 +- .../concepts/cluster-administration/addons.md | 2 +- .../cluster-administration/cloud-providers.md | 81 +- .../cluster-administration/logging.md | 5 +- .../{monitoring.md => system-metrics.md} | 0 .../docs/concepts/configuration/configmap.md | 4 +- .../manage-resources-containers.md | 4 +- .../configuration/pod-priority-preemption.md | 40 +- .../configuration/resource-bin-packing.md | 2 +- .../ko/docs/concepts/configuration/secret.md | 8 +- content/ko/docs/concepts/containers/images.md | 4 +- .../compute-storage-net/device-plugins.md | 32 +- .../extend-kubernetes/extend-cluster.md | 2 +- .../concepts/extend-kubernetes/operator.md | 5 +- .../ko/docs/concepts/overview/components.md | 4 +- .../concepts/policy/pod-security-policy.md | 16 +- .../docs/concepts/policy/resource-quotas.md | 3 +- .../scheduling-eviction/kube-scheduler.md | 6 +- .../services-networking/dns-pod-service.md | 20 +- .../services-networking/endpoint-slices.md | 113 +- .../concepts/services-networking/ingress.md | 293 ++-- .../services-networking/network-policies.md | 29 +- .../concepts/services-networking/service.md | 28 +- .../concepts/storage/dynamic-provisioning.md | 3 +- .../concepts/storage/persistent-volumes.md | 10 + .../docs/concepts/storage/volume-snapshots.md | 4 +- content/ko/docs/concepts/storage/volumes.md | 86 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/deployment.md | 12 +- .../controllers/garbage-collection.md | 2 +- .../concepts/workloads/controllers/job.md | 10 +- .../workloads/controllers/replicaset.md | 7 +- .../controllers/replicationcontroller.md | 34 +- .../workloads/controllers/statefulset.md | 2 +- .../ko/docs/concepts/workloads/pods/_index.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 6 +- .../pods/pod-topology-spread-constraints.md | 78 +- content/ko/docs/reference/_index.md | 10 +- .../command-line-tools-reference/_index.md | 1 - .../feature-gates.md | 81 +- .../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/scheduling/_index.md | 5 + .../ko/docs/reference/scheduling/policies.md | 118 ++ .../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 | 201 ++- content/ko/docs/setup/release/notes.md | 1370 ----------------- content/ko/docs/tasks/_index.md | 2 +- .../access-application-cluster/_index.md | 2 +- .../access-cluster.md | 67 +- ...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 | 40 +- .../dns-custom-nameservers.md | 30 +- .../kubeadm/kubeadm-upgrade.md | 188 ++- .../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 +- .../job/parallel-processing-expansion.md | 310 ++++ .../tasks/manage-daemon/update-daemon-set.md | 11 +- .../manage-hugepages/scheduling-hugepages.md | 2 +- .../declarative-config.md | 2 +- .../imperative-command.md | 2 +- .../imperative-config.md | 2 +- .../kustomization.md | 6 +- .../horizontal-pod-autoscale-walkthrough.md | 12 +- .../ko/docs/tasks/tls/certificate-rotation.md | 14 +- .../ko/docs/tasks/tools/install-kubectl.md | 21 +- .../ko/docs/tutorials/clusters/apparmor.md | 7 +- content/ko/docs/tutorials/hello-minikube.md | 2 +- .../explore/explore-intro.html | 6 +- .../ko/docs/tutorials/services/source-ip.md | 8 +- .../stateful-application/cassandra.md | 46 +- .../stateful-application/zookeeper.md | 65 +- .../ko/examples/application/job/job-tmpl.yaml | 18 + .../service/networking/external-lb.yaml | 10 + .../networking/ingress-resource-backend.yaml | 20 + .../networking/ingress-wildcard-host.yaml | 26 + .../examples/service/networking/ingress.yaml | 9 - .../service/networking/minimal-ingress.yaml | 17 + ...me-virtual-host-ingress-no-third-host.yaml | 35 + .../networking/name-virtual-host-ingress.yaml | 26 + .../networking/simple-fanout-example.yaml | 23 + .../service/networking/test-ingress.yaml | 10 + .../networking/tls-example-ingress.yaml | 20 + 102 files changed, 1943 insertions(+), 2452 deletions(-) rename content/ko/docs/concepts/cluster-administration/{monitoring.md => system-metrics.md} (100%) create mode 100644 content/ko/docs/reference/scheduling/_index.md create mode 100644 content/ko/docs/reference/scheduling/policies.md delete mode 100644 content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md delete mode 100644 content/ko/docs/setup/release/notes.md create mode 100644 content/ko/docs/tasks/job/parallel-processing-expansion.md create mode 100644 content/ko/examples/application/job/job-tmpl.yaml create mode 100644 content/ko/examples/service/networking/external-lb.yaml create mode 100644 content/ko/examples/service/networking/ingress-resource-backend.yaml create mode 100644 content/ko/examples/service/networking/ingress-wildcard-host.yaml delete mode 100644 content/ko/examples/service/networking/ingress.yaml create mode 100644 content/ko/examples/service/networking/minimal-ingress.yaml create mode 100644 content/ko/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml create mode 100644 content/ko/examples/service/networking/name-virtual-host-ingress.yaml create mode 100644 content/ko/examples/service/networking/simple-fanout-example.yaml create mode 100644 content/ko/examples/service/networking/test-ingress.yaml create mode 100644 content/ko/examples/service/networking/tls-example-ingress.yaml diff --git a/content/ko/_index.html b/content/ko/_index.html index 0916d04245..fd7053211b 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -41,11 +41,6 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준

- Attend KubeCon EU virtually on August 17-20, 2020 -
-
-
-
Attend KubeCon NA virtually on November 17-20, 2020
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/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index b3806591c2..f7666ef0c3 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -23,7 +23,7 @@ weight: 40 ## 디자인 -![쿠버네티스 컴포넌트](/images/docs/components-of-kubernetes.png) +![쿠버네티스 컴포넌트](/images/docs/components-of-kubernetes.svg) 클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로, 파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일 @@ -213,4 +213,3 @@ rules: 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다. 플러그인 개발에 대한 자세한 내용은 [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참조한다. - 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..6bb421a3d5 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/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 4896a8e7b8..4a0b700e02 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -6,7 +6,7 @@ weight: 60 -애플리케이션과 시스템 로그는 클러스터 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. +애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. 그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다. @@ -91,6 +91,7 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 그 후 `kubectl logs` 는 빈 응답을 반환한다. {{< /note >}} +[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh ### 시스템 컴포넌트 로그 시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. @@ -257,5 +258,3 @@ fluentd를 구성하는 것에 대한 자세한 내용은, 모든 애플리케이션에서 직접 로그를 노출하거나 푸시하여 클러스터-레벨 로깅을 구현할 수 있다. 그러나, 이러한 로깅 메커니즘의 구현은 쿠버네티스의 범위를 벗어난다. - - diff --git a/content/ko/docs/concepts/cluster-administration/monitoring.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md similarity index 100% rename from content/ko/docs/concepts/cluster-administration/monitoring.md rename to content/ko/docs/concepts/cluster-administration/system-metrics.md diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 8e025addd3..458e56358b 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -214,9 +214,9 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최 전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파 지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함). -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과 +쿠버네티스 베타 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게 사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우 데이터 변경을 방지하면 다음과 같은 이점이 있다. 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/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md index da165814da..ec97dec798 100644 --- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md @@ -48,40 +48,6 @@ weight: 70 이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다. {{< /note >}} -## 선점을 비활성화하는 방법 - -{{< caution >}} -중요 파드는 클러스터에 리소스 압박(resource pressure)이 가해지면 -스케줄러 선점에 따라 스케줄링된다. 이런 이유로, 선점을 비활성화하지 -않는 것을 권장한다. -{{< /caution >}} - -{{< note >}} -쿠버네티스 1.15 이상에서, `NonPreemptingPriority` 기능이 활성화된 경우, -프라이어리티클래스는 옵션을 `preemptionPolicy: Never` 로 설정할 수 있다. -이렇게 하면 해당 프라이어리티클래스의 파드가 다른 파드를 축출할 수 없다. -{{< /note >}} - -선점은 기본값이 `false`로 설정된 `disablePreemption` kube-scheduler -플래그에 의해 제어된다. -위의 주의에도 불구하고 선점을 비활성화하려는 경우, -`disablePreemption` 을 `true` 로 설정할 수 있다. - -이 옵션은 컴포넌트 구성에서만 사용할 수 있으며 -이전 스타일의 커맨드 라인 옵션에서는 사용할 수 없다. 다음은 선점을 비활성화하는 샘플 컴포넌트 -구성이다. - -```yaml -apiVersion: kubescheduler.config.k8s.io/v1alpha1 -kind: KubeSchedulerConfiguration -algorithmSource: - provider: DefaultProvider - -... - -disablePreemption: true -``` - ## 프라이어리티클래스 프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을 @@ -135,7 +101,7 @@ description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class} -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} `PreemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의 앞쪽에 배치되지만, @@ -159,10 +125,6 @@ description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사 `PreemptionPolicy` 가 `Never` 로 설정된 경우, 해당 프라이어리티클래스의 파드는 비-선점될 것이다. -`PreemptionPolicy` 필드를 사용하려면 `NonPreemptingPriority` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어야 한다. - 예제 유스케이스는 데이터 과학 관련 워크로드이다. 사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만, 실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다. 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..e75dd37da8 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 ``` @@ -713,9 +715,9 @@ kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 받지 않는다. {{< /note >}} -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 +쿠버네티스 베타 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는 클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면 다음과 같은 이점이 있다. @@ -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/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 2c57af0b5d..1966d2db5d 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -45,7 +45,7 @@ service Registration { 해당 자원을 API 서버에 알리는 역할을 한다. 예를 들어, 장치 플러그인이 kubelet에 `hardware-vendor.example/foo` 를 등록하고 노드에 두 개의 정상 장치를 보고하고 나면, 노드 상태가 업데이트되어 -노드에 2개의 “Foo” 장치가 설치되어 사용 가능함을 알릴 수 있다. +노드에 2개의 "Foo" 장치가 설치되어 사용 가능함을 알릴 수 있다. 그러고 나면, 사용자가 [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 명세에 있는 장치를 요청할 수 있다. @@ -91,6 +91,9 @@ spec: ```gRPC service DevicePlugin { + // GetDevicePluginOptions는 장치 관리자와 통신할 옵션을 반환한다. + rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {} + // ListAndWatch는 장치 목록 스트림을 반환한다. // 장치 상태가 변경되거나 장치가 사라질 때마다, ListAndWatch는 // 새 목록을 반환한다. @@ -100,10 +103,31 @@ spec: // 플러그인이 장치별 작업을 실행하고 Kubelet에 장치를 // 컨테이너에서 사용할 수 있도록 하는 단계를 지시할 수 있다. rpc Allocate(AllocateRequest) returns (AllocateResponse) {} + + // GetPreferredAllocation은 사용 가능한 장치 목록에서 할당할 + // 기본 장치 집합을 반환한다. 그 결과로 반환된 선호하는 할당은 + // devicemanager가 궁극적으로 수행하는 할당이 되는 것을 보장하지 + // 않는다. 가능한 경우 devicemanager가 정보에 입각한 할당 결정을 + // 내릴 수 있도록 설계되었다. + rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {} + + // PreStartContainer는 등록 단계에서 장치 플러그인에 의해 표시되면 각 컨테이너가 + // 시작되기 전에 호출된다. 장치 플러그인은 장치를 컨테이너에서 사용할 수 있도록 하기 전에 + // 장치 재설정과 같은 장치별 작업을 실행할 수 있다. + rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {} } ``` -* 플러그인은 호스트 경로 `/var/lib/kubelet/device-plugins/kubelet.sock` 에서 + {{< note >}} + `GetPreferredAllocation()` 또는 `PreStartContainer()` 에 대한 유용한 구현을 + 제공하기 위해 플러그인이 필요하지 않다. 이러한 호출(있는 경우) 중 + 사용할 수 있는 경우를 나타내는 플래그는 `GetDevicePluginOptions()` + 호출에 의해 다시 전송된 `DevicePluginOptions` 메시지에 설정되어야 한다. `kubelet` 은 + 항상 `GetDevicePluginOptions()` 를 호출하여 사용할 수 있는 + 선택적 함수를 확인한 후 직접 호출한다. + {{< /note >}} + +* 플러그인은 호스트 경로 `/var/lib/kubelet/device-plugins/kubelet.sock` 에서 유닉스 소켓을 통해 kubelet에 직접 등록한다. * 성공적으로 등록하고 나면, 장치 플러그인은 서빙(serving) 모드에서 실행되며, 그 동안 플러그인은 장치 상태를 @@ -183,7 +207,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 ## 토폴로지 관리자와 장치 플러그인 통합 -{{< feature-state for_k8s_version="v1.17" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} 토폴로지 관리자는 Kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다. 이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 확장되었다. @@ -230,3 +254,5 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. * 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기 * [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기 + + 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/overview/components.md b/content/ko/docs/concepts/overview/components.md index ace13900c6..d4b77e9319 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -5,7 +5,7 @@ description: > 쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다. weight: 20 -card: +card: name: concepts weight: 20 --- @@ -19,7 +19,7 @@ card: 여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다. -![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.png) +![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.svg) diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index a81038e444..a3d9b641e9 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -593,8 +593,11 @@ spec: ### Seccomp -파드에서 seccomp 프로파일의 사용은 파드시큐리티폴리시의 어노테이션을 통해 -제어할 수 있다. Seccomp는 쿠버네티스의 알파 기능이다. +쿠버네티스 v1.19부터 파드나 컨테이너의 `securityContext` 에서 +`seccompProfile` 필드를 사용하여 [seccomp 프로파일 사용을 +제어](/docs/tutorials/clusters/seccomp)할 수 있다. 이전 버전에서는, 파드에 +어노테이션을 추가하여 seccomp를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여 +이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다. **seccomp.security.alpha.kubernetes.io/defaultProfileName** - 컨테이너에 적용할 기본 seccomp 프로파일을 지정하는 어노테이션이다. 가능한 값은 @@ -607,7 +610,14 @@ spec: 되었다. 대신 `runtime/default` 사용을 권장한다. - `localhost/` - `/`에 있는 노드에서 파일을 프로파일로 지정한다. 여기서 ``는 Kubelet의 `--seccomp-profile-root` 플래그를 - 통해 정의된다. + 통해 정의된다. `--seccomp-profile-root` 플래그가 + 정의되어 있지 않으면, `` 이 `--root-dir` 플래그로 + 지정된 `/seccomp` 기본 경로가 사용된다. + +{{< note >}} + `--seccomp-profile-root` 플래그는 쿠버네티스 v1.19부터 더 이상 사용되지 + 않는다. 사용자는 기본 경로를 사용하는 것이 좋다. +{{< /note >}} **seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 파드 seccomp 어노테이션에 허용되는 값을 지정하는 어노테이션. 쉼표로 구분된 diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 13107a0613..526cf03e53 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -495,8 +495,7 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset ``` ```shell -kubectl create deployment nginx --image=nginx --namespace=myspace -kubectl scale deployment nginx --replicas=2 --namespace=myspace +kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2 ``` ```shell diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index a306a26a23..b812305cbd 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -77,7 +77,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지 방법이 있다. -1. [스케줄링 정책](/docs/reference/scheduling/policies)을 사용하면 +1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다. 1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 @@ -93,3 +93,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 +* 볼륨을 사용하느 파드의 스케줄링에 대해 배우기 + * [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드) + * [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/) + * [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/) diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 927201d90c..a7e3336fa2 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -163,6 +163,24 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac 또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다. {{< /note >}} +### 파드의 setHostnameAsFQDN 필드 {# pod-sethostnameasfqdn-field} + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +**전제 조건**: `SetHostnameAsFQDN` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 +대해 활성화해야 한다. + +파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다. + +파드 명세에서 `setHostnameAsFQDN: true` 를 설정하면, kubelet은 파드의 FQDN을 해당 파드 네임스페이스의 호스트네임에 기록한다. 이 경우, `hostname` 과 `hostname --fqdn` 은 모두 파드의 FQDN을 반환한다. + +{{< note >}} +리눅스에서, 커널의 호스트네임 필드(`struct utsname` 의 `nodename` 필드)는 64자로 제한된다. + +파드에서 이 기능을 사용하도록 설정하고 FQDN이 64자보다 길면, 시작되지 않는다. 파드는 파드 호스트네임과 클러스터 도메인에서 FQDN을 구성하지 못한다거나, FQDN `long-FDQN` 이 너무 길다(최대 64자, 70자 요청인 경우)와 같은 오류 이벤트를 생성하는 `Pending` 상태(`kubectl` 에서 표시하는 `ContainerCreating`)로 유지된다. 이 시나리오에서 사용자 경험을 개선하는 한 가지 방법은 사용자가 최상위 레벨을 오브젝트(예를 들어, 디플로이먼트)를 생성할 때 FQDN 크기를 제어하기 위해 [어드미션 웹훅 컨트롤러](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)를 생성하는 것이다. +{{< /note >}} + ### 파드의 DNS 정책 DNS 정책은 파드별로 설정할 수 있다. @@ -188,7 +206,7 @@ DNS 정책은 파드별로 설정할 수 있다. {{< note >}} "Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 -“ClusterFirst”가 기본값으로 사용된다. +"ClusterFirst"가 기본값으로 사용된다. {{< /note >}} diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index d5f7a2abf3..900f771cee 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -1,7 +1,7 @@ --- title: 엔드포인트슬라이스 content_type: concept -weight: 15 +weight: 35 --- @@ -21,7 +21,9 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는 간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와 -서비스가 점점 더 커짐에 따라, 이 API의 한계가 더욱 눈에 띄게 되었다. +{{< glossary_tooltip text="서비스" term_id="service" >}}가 점점 더 +커짐에 따라, 이 API의 한계가 더욱 눈에 띄게 +되었다. 특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에 어려움이 있었다. @@ -34,16 +36,17 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워 ## 엔드포인트슬라이스 리소스 {#endpointslice-resource} -쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한 +쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한 참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터" -term_id="selector" >}} 가 지정되면 EndpointSlice -컨트롤러는 자동으로 엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는 +term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로 +엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는 서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는 -고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다. -EndpointSlice 오브젝트의 이름은 유효한 +프로토콜, 포트 번호 및 서비스 이름의 고유한 조합을 통해 네트워크 엔드포인트를 +그룹화한다. +엔드포인트슬라이스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice +예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 엔드포인트슬라이스 리소스 샘플이 있다. ```yaml @@ -69,28 +72,30 @@ endpoints: topology.kubernetes.io/zone: us-west2-a ``` -기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트슬라이스에는 -각각 100개 이하의 엔드포인트를 가지고 있다. 이 스케일 아래에서 엔드포인트슬라이스는 -엔드포인트 및 서비스와 1:1로 매핑해야하며, 유사한 성능을 가져야 한다. +기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를 +갖도록 엔드포인트슬라이스를 생성하고 관리한다. `--max-endpoints-per-slice` +{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} +플래그를 사용하여, 최대 1000개까지 구성할 수 있다. -엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에 +엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해 +{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}에 신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는 서비스에 대해 성능 향상을 제공해야 한다. ### 주소 유형 -EndpointSlice는 다음 주소 유형을 지원한다. +엔드포인트슬라이스는 다음 주소 유형을 지원한다. * IPv4 * IPv6 -* FQDN (Fully Qualified Domain Name) +* FQDN (전체 주소 도메인 이름) -### 토폴로지 +### 토폴로지 정보 {#토폴로지} 엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다. 이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된 -엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면 -다음의 토폴로지 레이블이 엔드포인트슬라이스 컨트롤러에 의해 설정된다. +엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면, +컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다. * `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름. * `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름. @@ -103,37 +108,48 @@ NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당 ### 관리 -기본적으로 엔드포인트슬라이스는 엔드포인트슬라이스 컨트롤러에의해 -생성되고 관리된다. 서비스 메시 구현과 같은 다른 엔드포인트슬라이스 -유스 케이스는 다른 엔터티나 컨트롤러가 추가 엔드포인트슬라이스 -집합을 관리할 수 있게 할 수 있다. 여러 엔티티가 서로 간섭하지 않고 -엔드포인트슬라이스를 관리할 수 있도록 엔드포인트슬라이스를 관리하는 -엔티티를 나타내는데 `endpointslice.kubernetes.io/managed-by` 레이블이 사용된다. -엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트 -슬라이스에 레이블의 값으로 `endpointslice-controller.k8s.io` 를 설정한다. -엔드포인트슬라이스를 관리하는 다른 엔티티도 이 레이블에 -고유한 값을 설정해야 한다. +대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}})는 +엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가 +엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이 +엔드포인트슬라이스에 대한 다양한 다른 유스케이스가 있다. + +여러 엔티티가 서로 간섭하지 않고 엔드포인트슬라이스를 +관리할 수 있도록 쿠버네티스는 엔드포인트슬라이스를 관리하는 +엔티티를 나타내는 `endpointslice.kubernetes.io/managed-by` +{{< glossary_tooltip term_id="label" text="레이블" >}}을 +정의한다. +엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로 +`endpointslice-controller.k8s.io` 를 설정한다. 엔드포인트슬라이스를 +관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다. ### 소유권 -대부분의 유스 케이스에서 엔드포인트를 추적하는 서비스가 엔드포인트슬라이스를 -소유한다. 이는 각 엔드포인트슬라이스의 참조와 서비스에 속하는 모든 -엔드포인트슬라이스를 간단하게 조회할 수 있는 `kubernetes.io/service-name` -레이블로 표시된다. +대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를 +추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자 +참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는 +`kubernetes.io/service-name` 레이블로 표시된다. -## 엔드포인트슬라이스 컨트롤러 +### 엔드포인트슬라이스 미러링 -엔드포인트슬라이스 컨트롤러는 해당 엔드포인트슬라이스가 최신 상태인지 -확인하기 위해 서비스와 파드를 감시한다. 컨트롤러가 셀렉터로 지정한 모든 -서비스에 대해 엔드포인트슬라이스를 관리한다. 이는 서비스 셀렉터와 -일치하는 파드의 IP를 나타내게 된다. +경우에 따라, 애플리케이션이 사용자 지정 엔드포인트 리소스를 생성한다. 이러한 +애플리케이션이 엔드포인트와 엔드포인트슬라이스 리소스에 동시에 쓸 필요가 없도록 +클러스터의 컨트롤 플레인은 대부분의 엔드포인트 리소스를 +해당 엔드포인트슬라이스에 미러링한다. -### 엔드포인트슬라이스의 크기 +컨트롤 플레인은 다음을 제외하고 엔드포인트 리소스를 미러링한다. -기본적으로 엔드포인트슬라이스는 각각 100개의 엔드포인트 크기로 제한된다. -최대 1000개까지 `--max-endpoints-per-slice` {{< glossary_tooltip -text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그를 -사용해서 구성할 수 있다. +* 엔드포인트 리소스에는 `endpointslice.kubernetes.io/skip-mirror` 레이블이 + `true` 로 설정되어 있다. +* 엔드포인트 리소스에는 `control-plane.alpha.kubernetes.io/leader` + 어노테이션이 있다. +* 해당 서비스 리소스가 존재하지 않는다. +* 해당 서비스 리소스에 nil이 아닌 셀렉터가 있다. + +개별 엔드포인트 리소스는 여러 엔드포인트슬라이스로 변환될 수 있다. +엔드포인트 리소스에 여러 하위 집합이 있거나 여러 IP 제품군(IPv4 및 IPv6)이 있는 +엔드포인트가 포함된 경우 변환이 일어난다. 하위 집합 당 최대 1000개의 주소가 +엔드포인트슬라이스에 미러링된다. ### 엔드포인트슬라이스의 배포 @@ -143,8 +159,8 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 엔드포인트슬라이스가 필요하다. 이는 하위 집합이 엔드포인트와 그룹화하는 방식의 논리와 유사하다. -컨트롤러는 엔드포인트슬라이스를 최대한 채우려고 노력하지만, -적극적으로 재조정하지는 않는다. 컨트롤러의 동작은 매우 직관적이다. +컨트롤 플레인은 엔드포인트슬라이스를 최대한 채우려고 노력하지만, +적극적으로 재조정하지는 않는다. 로직은 매우 직관적이다. 1. 기존 엔드포인트슬라이스에 대해 반복적으로, 더 이상 필요하지 않는 엔드포인트를 제거하고 변경에 의해 일치하는 엔드포인트를 업데이트 한다. @@ -173,10 +189,17 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 교체되는 엔드포인트에 대해서 엔드포인트슬라이스를 자연스럽게 재포장한다. +### 중복 엔드포인트 +엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의 +엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에 +대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에 +도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은 +엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트 +중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 `kube-proxy` 의 +`EndpointSliceCache` 구현에서 찾을 수 있다. ## {{% heading "whatsnext" %}} - -* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices) +* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)에 대해 배우기 * [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 9ec0d2f5bf..3f75069300 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -5,7 +5,7 @@ weight: 40 --- -{{< feature-state for_k8s_version="v1.1" state="beta" >}} +{{< feature-state for_k8s_version="v1.19" state="stable" >}} {{< glossary_definition term_id="ingress" length="all" >}} @@ -23,7 +23,7 @@ weight: 40 ## 인그레스란? -[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부 +[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부 {{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. @@ -59,23 +59,7 @@ weight: 40 최소한의 인그레스 리소스 예제: -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: test-ingress - annotations: - nginx.ingress.kubernetes.io/rewrite-target: / -spec: - rules: - - http: - paths: - - path: /testpath - pathType: Prefix - backend: - serviceName: test - servicePort: 80 -``` +{{< codenew file="service/networking/minimal-ingress.yaml" >}} 다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 인그레스 오브젝트의 이름은 유효한 @@ -98,44 +82,100 @@ spec: * 선택적 호스트. 이 예시에서는, 호스트가 지정되지 않기에 지정된 IP 주소를 통해 모든 인바운드 HTTP 트래픽에 규칙이 적용 된다. 만약 호스트가 제공되면(예, foo.bar.com), 규칙이 해당 호스트에 적용된다. -* 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련 - 백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가 - 모두 수신 요청의 내용과 일치해야 한다. -* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이 +* 경로 목록 (예, `/testpath`)에는 각각 `service.name` 과 + `service.port.name` 또는 `service.port.number` 가 정의되어 있는 관련 + 백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 + 보내기 전에 호스트와 경로가 모두 수신 요청의 내용과 + 일치해야 한다. +* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/) 또는 [사용자 정의 리소스 백엔드](#resource-backend)에 설명된 바와 같이 서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한 HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다. -기본 백엔드는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스 +`defaultBackend` 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스 컨트롤러에 구성되는 경우가 많다. -### 기본 벡엔드 +### DefaultBackend {#default-backend} -규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본 -백엔드는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다. +규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로 +[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다. 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은 기본 백엔드로 라우팅 된다. -### 경로(Path) 유형 +### 리소스 백엔드 {#resource-backend} -인그레스의 각 경로에는 해당하는 경로 유형이 있다. 지원되는 세 가지의 경로 -유형이 있다. +`Resource` 백엔드는 인그레스 오브젝트의 동일한 네임스페이스 내에 있는 +다른 쿠버네티스 리소스에 대한 ObjectRef이다. `Resource` 는 서비스와 +상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. `Resource` +백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를 +수신하는 것이다. -* _`ImplementationSpecific`_ (기본): 이 경로 유형의 일치 여부는 IngressClass에 따라 +{{< codenew file="service/networking/ingress-resource-backend.yaml" >}} + +위의 인그레스를 생성한 후, 다음의 명령으로 확인할 수 있다. + +```bash +kubectl describe ingress ingress-resource-backend +``` + +``` +Name: ingress-resource-backend +Namespace: default +Address: +Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets +Rules: + Host Path Backends + ---- ---- -------- + * + /icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets +Annotations: +Events: +``` + +### 경로 유형 + +인그레스의 각 경로에는 해당 경로 유형이 있어야 한다. 명시적 +`pathType` 을 포함하지 않는 경로는 유효성 검사에 실패한다. 지원되는 +경로 유형은 세 가지이다. + +* `ImplementationSpecific`: 이 경로 유형의 일치 여부는 IngressClass에 따라 달라진다. 이를 구현할 때 별도 `pathType` 으로 처리하거나, `Prefix` 또는 `Exact` 경로 유형과 같이 동일하게 처리할 수 있다. -* _`Exact`_: URL 경로의 대소문자를 엄격하게 일치시킨다. +* `Exact`: URL 경로의 대소문자를 엄격하게 일치시킨다. -* _`Prefix`_: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다. +* `Prefix`: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다. 일치는 대소문자를 구분하고, 요소별로 경로 요소에 대해 수행한다. 모든 _p_ 가 요청 경로의 요소별 접두사가 _p_ 인 경우 요청은 _p_ 경로에 일치한다. - {{< note >}} - 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). - {{< /note >}} + {{< note >}} 경로의 마지막 요소가 요청 경로에 있는 마지막 + 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 + `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}} + +### 예제 + +| 종류 | 경로 | 요청 경로 | 일치 여부 | +|--------|---------------------------------|-------------------------------|------------------------------------| +| Prefix | `/` | (모든 경로) | 예 | +| Exact | `/foo` | `/foo` | 예 | +| Exact | `/foo` | `/bar` | 아니오 | +| Exact | `/foo` | `/foo/` | 아니오 | +| Exact | `/foo/` | `/foo` | 아니오 | +| Prefix | `/foo` | `/foo`, `/foo/` | 예 | +| Prefix | `/foo/` | `/foo`, `/foo/` | 예 | +| Prefix | `/aaa/bb` | `/aaa/bbb` | 아니오 | +| Prefix | `/aaa/bbb` | `/aaa/bbb` | 예 | +| Prefix | `/aaa/bbb/` | `/aaa/bbb` | 예, 마지막 슬래시 무시함 | +| Prefix | `/aaa/bbb` | `/aaa/bbb/` | 예, 마지막 슬래시 일치함 | +| Prefix | `/aaa/bbb` | `/aaa/bbb/ccc` | 예, 하위 경로 일치함 | +| Prefix | `/aaa/bbb` | `/aaa/bbbxyz` | 아니오, 문자열 접두사 일치하지 않음 | +| Prefix | `/`, `/aaa` | `/aaa/ccc` | 예, `/aaa` 접두사 일치함 | +| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/aaa/bbb` | 예, `/aaa/bbb` 접두사 일치함 | +| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/ccc` | 예, `/` 접두사 일치함 | +| Prefix | `/aaa` | `/ccc` | 아니오, 기본 백엔드 사용함 | +| Mixed | `/foo` (Prefix), `/foo` (Exact) | `/foo` | 예, Exact 선호함 | #### 다중 일치 경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다. @@ -143,6 +183,20 @@ spec: 여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다 정확한(exact) 경로 유형을 가진 경로가 사용 된다. +## 호스트네임 와일드카드 +호스트는 정확한 일치(예: "`foo.bar.com`") 또는 와일드카드(예: +"`* .foo.com`")일 수 있다. 정확한 일치를 위해서는 HTTP `host` 헤더가 +`host` 필드와 일치해야 한다. 와일드카드 일치를 위해서는 HTTP `host` 헤더가 +와일드카드 규칙의 접미사와 동일해야 한다. + +| 호스트 | 호스트 헤더 | 일치 여부 | +| ----------- |-------------------| --------------------------------------------------| +| `*.foo.com` | `bar.foo.com` | 공유 접미사를 기반으로 일치함 | +| `*.foo.com` | `baz.bar.foo.com` | 일치하지 않음, 와일드카드는 단일 DNS 레이블만 포함함 | +| `*.foo.com` | `foo.com` | 일치하지 않음, 와일드카드는 단일 DNS 레이블만 포함함 | + +{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}} + ## 인그레스 클래스 인그레스는 서로 다른 컨트롤러에 의해 구현될 수 있으며, 종종 다른 구성으로 @@ -150,18 +204,7 @@ spec: 이름을 포함하여 추가 구성이 포함된 IngressClass 리소스에 대한 참조 클래스를 지정해야 한다. -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: IngressClass -metadata: - name: external-lb -spec: - controller: example.com/ingress-controller - parameters: - apiGroup: k8s.example.com/v1alpha - kind: IngressParameters - name: external-lb -``` +{{< codenew file="service/networking/external-lb.yaml" >}} IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한 추가 구성을 참조하는데 사용할 수 있다. @@ -179,7 +222,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클 이 필드는 인그레스 컨트롤러의 이름을 포함하는 추가 인그레스 구성이 포함된 인그레스 클래스 리소스에 대한 참조이다. -### 기본 인그레스 클래스 +### 기본 IngressClass {#default-ingress-class} 특정 IngressClass를 클러스터의 기본 값으로 표시할 수 있다. IngressClass 리소스에서 `ingressclass.kubernetes.io/is-default-class` 를 `true` 로 @@ -195,24 +238,24 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클 ## 인그레스 유형들 -### 단일 서비스 인그레스 +### 단일 서비스로 지원되는 인그레스 {#single-service-ingress} 단일 서비스를 노출할 수 있는 기존 쿠버네티스 개념이 있다 ([대안](#대안)을 본다). 인그레스에 규칙 없이 *기본 백엔드* 를 지정해서 이를 수행할 수 있다. -{{< codenew file="service/networking/ingress.yaml" >}} +{{< codenew file="service/networking/test-ingress.yaml" >}} 만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의 상태를 볼 수 있어야 한다. -```shell +```bash kubectl get ingress test-ingress ``` ``` -NAME HOSTS ADDRESS PORTS AGE -test-ingress * 203.0.113.123 80 59s +NAME CLASS HOSTS ADDRESS PORTS AGE +test-ingress external-lb * 203.0.113.123 80 59s ``` 여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 @@ -229,34 +272,14 @@ test-ingress * 203.0.113.123 80 59s 트래픽을 라우팅 한다. 인그레스를 사용하면 로드 밸런서의 수를 최소로 유지할 수 있다. 예를 들어 다음과 같은 설정을 한다. -```none +``` foo.bar.com -> 178.91.123.132 -> / foo service1:4200 / bar service2:8080 ``` 다음과 같은 인그레스가 필요하다. -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: simple-fanout-example - annotations: - nginx.ingress.kubernetes.io/rewrite-target: / -spec: - rules: - - host: foo.bar.com - http: - paths: - - path: /foo - backend: - serviceName: service1 - servicePort: 4200 - - path: /bar - backend: - serviceName: service2 - servicePort: 8080 -``` +{{< codenew file="service/networking/simple-fanout-example.yaml" >}} `kubectl apply -f` 를 사용해서 인그레스를 생성 할 때 다음과 같다. @@ -275,8 +298,6 @@ Rules: foo.bar.com /foo service1:4200 (10.8.0.90:4200) /bar service2:8080 (10.8.0.91:8080) -Annotations: - nginx.ingress.kubernetes.io/rewrite-target: / Events: Type Reason Age From Message ---- ------ ---- ---- ------- @@ -289,8 +310,8 @@ Events: 볼 수 있다. {{< note >}} -사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) -에 따라 default-http-backend +사용 중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 +따라 default-http-backend [서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다. {{< /note >}} @@ -307,68 +328,26 @@ bar.foo.com --| |-> bar.foo.com service2:80 다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을 라우팅 하기 위해 뒷단의 로드 밸런서를 알려준다. -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: name-virtual-host-ingress -spec: - rules: - - host: foo.bar.com - http: - paths: - - backend: - serviceName: service1 - servicePort: 80 - - host: bar.foo.com - http: - paths: - - backend: - serviceName: service2 - servicePort: 80 -``` +{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}} 만약 규칙에 정의된 호스트 없이 인그레스 리소스를 생성하는 경우, 이름 기반 가상 호스트가 없어도 인그레스 컨트롤러의 IP 주소에 대한 웹 트래픽을 일치 시킬 수 있다. -예를 들어, 다음 인그레스 리소스는 `first.bar.com`에 요청된 트래픽을 +예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을 `service1`로, `second.foo.com`는 `service2`로, 호스트 이름이 정의되지 않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든 트래픽은 `service3`로 라우팅 한다. -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: name-virtual-host-ingress -spec: - rules: - - host: first.bar.com - http: - paths: - - backend: - serviceName: service1 - servicePort: 80 - - host: second.foo.com - http: - paths: - - backend: - serviceName: service2 - servicePort: 80 - - http: - paths: - - backend: - serviceName: service3 - servicePort: 80 -``` +{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}} ### TLS -TLS 개인 키 및 인증서가 포함된 {{< glossary_tooltip term_id="secret" >}} -을 지정해서 인그레스를 보호할 수 있다. 현재 인그레스는 -단일 TLS 포트인 443만 지원하며 TLS 종료를 가정한다. 만약 인그레스의 TLS -구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해 +TLS 개인 키 및 인증서가 포함된 {{< glossary_tooltip term_id="secret" >}}을 +지정해서 인그레스를 보호할 수 있다. 인그레스 리소스는 +단일 TLS 포트인 443만 지원하고 인그레스 지점에서 TLS 종료를 +가정한다(서비스 및 해당 파드에 대한 트래픽은 일반 텍스트임). +인그레스의 TLS 구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해 지정된 호스트이름에 따라 동일한 포트에서 멀티플렉싱 된다(인그레스 컨트롤러가 SNI를 지원하는 경우). TLS secret에는 `tls.crt` 와 `tls.key` 라는 이름의 키가 있어야 하고, 여기에는 TLS에 사용할 인증서와 @@ -391,25 +370,7 @@ type: kubernetes.io/tls TLS 시크릿이 `sslexample.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고 하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다. -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: tls-example-ingress -spec: - tls: - - hosts: - - sslexample.foo.com - secretName: testsecret-tls - rules: - - host: sslexample.foo.com - http: - paths: - - path: / - backend: - serviceName: service1 - servicePort: 80 -``` +{{< codenew file="service/networking/tls-example-ingress.yaml" >}} {{< note >}} TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능 @@ -419,7 +380,7 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능 플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다. {{< /note >}} -### 로드밸런싱 +### 로드 밸런싱 {#load-balancing} 인그레스 컨트롤러는 로드 밸런싱 알고리즘, 백엔드 가중치 구성표 등 모든 인그레스에 적용되는 일부 로드 밸런싱 @@ -432,8 +393,8 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능 [준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)와 같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이 있다는 점도 주목할 가치가 있다. 컨트롤러 별 -설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다( -[nginx](https://git.k8s.io/ingress-nginx/README.md), +설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(예: +[nginx](https://git.k8s.io/ingress-nginx/README.md), 또는 [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)). ## 인그레스 업데이트 @@ -476,16 +437,22 @@ spec: http: paths: - backend: - serviceName: service1 - servicePort: 80 + service: + name: service1 + port: + number: 80 path: /foo + pathType: Prefix - host: bar.baz.com http: paths: - backend: - serviceName: service2 - servicePort: 80 + service: + name: service2 + port: + number: 80 path: /foo + pathType: Prefix .. ``` @@ -523,15 +490,9 @@ Events: ## 가용성 영역에 전체에서의 실패 장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다. -자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2) -를 참조할 수 있다. - -## 앞으로의 할일 - -[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) -를 추적하여 인그레스와 진행중인 리소스의 발전에 대한 자세한 내용을 알아 본다. 다양한 -인그레스 컨트롤러의 발전에 대한 자세한 내용은 -[인그레스 리포지터리](https://github.com/kubernetes/ingress/tree/master)에서 추적할 수 있다. +자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. +페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)를 +참조할 수 있다. ## 대안 @@ -546,4 +507,4 @@ Events: * [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 -* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube) +* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 4d8bb47bda..76076f5965 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -5,11 +5,18 @@ weight: 50 --- -네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. -`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. +IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다. +파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다. +1. 허용되는 다른 파드(예외: 파드는 자신에 대한 접근을 차단할 수 없음) +2. 허용되는 네임스페이스 +3. IP 블록(예외: 파드 또는 노드의 IP 주소와 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨) + +pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 사용하여 셀렉터와 일치하는 파드와 주고받는 트래픽을 지정한다. + +한편, IP 기반의 네트워크폴리시가 생성되면, IP 블록(CIDR 범위)을 기반으로 정책을 정의한다. ## 전제 조건 @@ -199,17 +206,29 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ## SCTP 지원 -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. -기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. +베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다. {{< note >}} SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. {{< /note >}} +# 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는) +쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다. +- 내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음). +- TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용). +- 노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음). +- 이름으로 네임스페이스나 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임). +- 타사 공급사가 이행한 "정책 요청"의 생성 또는 관리. +- 모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음). +- 고급 정책 쿼리 및 도달 가능성 도구. +- 단일 정책 선언에서 포트 범위를 대상으로 하는 기능. +- 네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결). +- 명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음). +- 루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음). ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 90ec166c03..df51f54ec5 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -31,8 +31,8 @@ weight: 10 한 시점에 실행되는 파드 집합이 잠시 후 실행되는 해당 파드 집합과 다를 수 있다. -이는 다음과 같은 문제를 야기한다. (“백엔드”라 불리는) 일부 파드 집합이 -클러스터의 (“프론트엔드”라 불리는) 다른 파드에 기능을 제공하는 경우, +이는 다음과 같은 문제를 야기한다. ("백엔드"라 불리는) 일부 파드 집합이 +클러스터의 ("프론트엔드"라 불리는) 다른 파드에 기능을 제공하는 경우, 프론트엔드가 워크로드의 백엔드를 사용하기 위해, 프론트엔드가 어떻게 연결할 IP 주소를 찾아서 추적할 수 있는가? @@ -89,7 +89,7 @@ spec: targetPort: 9376 ``` -이 명세는 “my-service”라는 새로운 서비스 오브젝트를 생성하고, +이 명세는 "my-service"라는 새로운 서비스 오브젝트를 생성하고, `app=MyApp` 레이블을 가진 파드의 TCP 9376 포트를 대상으로 한다. 쿠버네티스는 이 서비스에 서비스 프록시가 사용하는 IP 주소 ("cluster IP"라고도 함) @@ -97,7 +97,7 @@ spec: (이하 [가상 IP와 서비스 프록시](#가상-ip와-서비스-프록시) 참고) 서비스 셀렉터의 컨트롤러는 셀렉터와 일치하는 파드를 지속적으로 검색하고, -“my-service”라는 엔드포인트 오브젝트에 대한 +"my-service"라는 엔드포인트 오브젝트에 대한 모든 업데이트를 POST한다. {{< note >}} @@ -200,14 +200,11 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, ### 애플리케이션 프로토콜 -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프로토콜을 -지정하는 방법을 제공한다. - -알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면, -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서 -`ServiceAppProtocol` 을 활성화해야 한다. +지정하는 방법을 제공한다. 이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스에 +의해 미러링된다. ## 가상 IP와 서비스 프록시 @@ -862,6 +859,7 @@ Classic ELB의 연결 드레이닝은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20" # 개별 인스턴스의 상태 점검 사이의 # 대략적인 간격 (초 단위). 기본값은 10이며, 5와 300 사이여야 한다. + service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5" # 헬스 체크 실패를 의미하는 무 응답의 총 시간 (초 단위) # 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval @@ -869,6 +867,10 @@ Classic ELB의 연결 드레이닝은 service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" # ELB에 추가될 추가 보안 그룹(security group) 목록 + + service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" + # 로드 밸런서의 대상 노드를 선택하는 데 + # 사용되는 키-값 쌍의 쉼표로 구분된 목록 ``` #### AWS의 네트워크 로드 밸런서 지원 {#aws-nlb-support} @@ -1189,11 +1191,11 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n ### SCTP -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -쿠버네티스는 서비스, 엔드포인트, 네트워크 정책 및 파드 정의에서 알파 기능으로 SCTP를 `프로토콜` 값으로 지원한다. 이 기능을 활성화하기 위해서는, 클러스터 관리자가 API 서버에서 `--feature-gates=SCTPSupport=true,…`처럼 `SCTPSupport` 기능 게이트를 활성화해야 한다. +쿠버네티스는 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 및 파드 정의에서 SCTP를 `protocol` 값으로 지원한다. 이 기능은 베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에서 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다. -기능 게이트가 활성화되면, 서비스, 엔드포인트, 네트워크 정책 또는 파드의 `프로토콜` 필드를 `SCTP`로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다. +기능 게이트가 활성화되면, 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 또는 파드의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다. #### 경고 {#caveat-sctp-overview} diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index 87ce9c9d27..412645e734 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -80,7 +80,7 @@ v1.6부터 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVol 관리자가 구성한 `StorageClass` 의 이름과 일치해야 한다. ([아래](#동적-프로비저닝-활성화하기)를 참고) -예를 들어 “fast” 스토리지 클래스를 선택하려면 다음과 +예를 들어 "fast" 스토리지 클래스를 선택하려면 다음과 같은 `PersistentVolumeClaim` 을 생성한다. ```yaml @@ -127,4 +127,3 @@ spec: 여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를 프로비전해야 한다. [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 설정해서 수행할 수 있다. - 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/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index f57a003d13..13917ecfef 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -150,7 +150,7 @@ awsElasticBlockStore 의 CSI 마이그레이션 기능이 활성화된 경우, 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI 드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationAWS` -베타 기능을 활성화 해야 한다. +베타 기능을 활성화해야 한다. #### CSI 마이그레이션 완료 {{< feature-state for_k8s_version="v1.17" state="alpha" >}} @@ -165,14 +165,14 @@ awsElasticBlockStore 의 CSI 마이그레이션 기능이 활성화된 경우, #### CSI 마이그레이션 -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk` -알파 기능을 활성화 해야 한다. +기능을 활성화해야 한다. ### azureFile {#azurefile} @@ -190,7 +190,7 @@ azureFile의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile` -알파 기능을 활성화 해야 한다. +알파 기능을 활성화해야 한다. ### cephfs {#cephfs} @@ -493,7 +493,7 @@ GCE PD의 CSI 마이그레이션 기능이 활성화된 경우 기존 트리 내 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI 드라이버](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` -베타 기능을 활성화 해야 한다. +베타 기능을 활성화해야 한다. ### gitRepo (사용 중단(deprecated)) {#gitrepo} @@ -1151,6 +1151,38 @@ spec: 더 많은 예시는 [여기](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)에서 확인할 수 있다. +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +vsphereVolume용 CSI 마이그레이션 기능이 활성화되면, 기존 인-트리 플러그인에서 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 shim한다. +이 기능을 사용하려면, [vSphere CSI +드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 +클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. + +또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다. + +{{< note >}} +빌트인 vsphereVolume 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다. + +* `diskformat` +* `hostfailurestotolerate` +* `forceprovisioning` +* `cachereservation` +* `diskstripes` +* `objectspacereservation` +* `iopslimit` + +이러한 파라미터를 사용하여 생성된 기존 볼륨은 vSphere CSI 드라이버로 마이그레이션되지만, vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 따르지 않는다. +{{< /note >}} + +#### CSI 마이그레이션 완료 +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +vsphereVolume 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 true로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치되어 있어야 한다. + ## subPath 사용하기 @@ -1194,7 +1226,6 @@ spec: `subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다. -이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다. `subPath` 와 `subPathExpr` 속성은 상호 배타적이다. 이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다. 호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다. @@ -1284,8 +1315,11 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 `csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결, 마운트, 등을 할 수 있다. -`csi` 볼륨 유형은 파드에서의 직접 참조를 지원하지 않으며 -`PersistentVolumeClaim` 오브젝트를 통해 파드에서 참조할 수 있다. +`csi` 볼륨은 세 가지 방법으로 파드에서 사용할 수 있다. +- [`persistentVolumeClaim`](#persistentvolumeclaim)에 대한 참조를 통해서 +- [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께 (알파 기능) +- 드라이버가 지원하는 경우 + [CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) (베타 기능) 스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을 구성할 수 있다. @@ -1348,38 +1382,14 @@ CSI 설정 변경 없이 평소와 같이 {{< feature-state for_k8s_version="v1.16" state="beta" >}} -이 기능을 사용하면 CSI 볼륨을 퍼시스턴트볼륨 대신에 파드 사양에 직접적으로 포함할 수 있다. -이러한 방식으로 지정된 볼륨은 임시적이고 파드 재시작시에는 유지되지 않는다. +파드 명세 내에서 CSI 볼륨을 직접 구성할 수 +있다. 이 방식으로 지정된 볼륨은 임시 볼륨이며 +파드가 다시 시작할 때 지속되지 않는다. 자세한 내용은 [임시 +볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)을 +참고한다. -예시 +#### {{% heading "whatsnext" %}} -```yaml -kind: Pod -apiVersion: v1 -metadata: - name: my-csi-app -spec: - containers: - - name: my-frontend - image: busybox - volumeMounts: - - mountPath: "/data" - name: my-csi-inline-vol - command: [ "sleep", "1000000" ] - volumes: - - name: my-csi-inline-vol - csi: - driver: inline.storage.kubernetes.io - volumeAttributes: - foo: bar -``` - -이 기능을 사용하려면 CSIInlineVolume 기능 게이트를 활성화 해야 한다. -쿠버네티스 1.16 시작시 기본적으로 활성화 되어있다. - -CSI 임시 볼륨은 CSI 드라이버의 하위집합에서만 지원된다. CSI 드라이버의 목록은 [여기](https://kubernetes-csi.github.io/docs/drivers.html)를 본다. - -# 개발자 리소스 CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. 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..e69761b9e6 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -1,11 +1,11 @@ --- -title: 잡 - 실행부터 완료까지 +title: 잡 content_type: concept feature: title: 배치 실행 description: > 쿠버네티스는 서비스 외에도 배치와 CI 워크로드를 관리할 수 있으며, 원하는 경우 실패한 컨테이너를 교체할 수 있다. -weight: 70 +weight: 50 --- @@ -116,6 +116,7 @@ kubectl logs $pods `.spec.template` 은 `.spec` 의 유일한 필수 필드이다. + `.spec.template` 은 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 `apiVersion` 또는 `kind` 가 없다는 것을 제외한다면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 같은 스키마를 가지고 있다. 추가로 파드의 필수 필드 외에도 잡의 파드 템플릿은 적절한 @@ -129,7 +130,7 @@ kubectl logs $pods [자신의 파드 셀렉터를 지정하기](#자신의-파드-셀렉터를-지정하기) 섹션을 참고한다. -### 병렬 잡 +### 잡에 대한 병렬 실행 {#parallel-jobs} 잡으로 실행하기에 적합한 작업 유형은 크게 세 가지가 있다. @@ -212,9 +213,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프 카운트가 재설정된다. -{{< note >}} -1.12 이전 버전의 쿠버네티스 버전에 대해 여전히 [#54870](https://github.com/kubernetes/kubernetes/issues/54870) 이슈가 있다. -{{< /note >}} {{< note >}} 만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에 도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이 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..5c5b5c750f 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,20 +112,20 @@ 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) 도 필요하다. +레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. ### 파드 템플릿 `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다. -`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿) 이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라. -오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 만 허용되며, 특별히 지정되지 않으면 기본값이다. +오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)만 허용되며, 특별히 지정되지 않으면 기본값이다. 로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다. 예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) 혹은 도커이다. @@ -139,7 +139,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m ### 파드 셀렉터 -`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다. +`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다. 직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나 삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고 레플리케이션 컨트롤러를 교체할 수 있다. @@ -181,14 +181,14 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적 해당 파드에 영향을 주지 않고 레플리케이션 컨트롤러를 삭제할 수 있다. -kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 에 옵션으로 `--cascade=false`를 지정하라. +kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라. REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러 오브젝트를 삭제하라. 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면, 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를 새로운 파드 템플릿과 일치시키려는 노력은 하지 않을 것이다. -새로운 spec에 대한 파드를 제어된 방법으로 업데이트하려면 [롤링 업데이트](#롤링-업데이트) 를 사용하라. +새로운 spec에 대한 파드를 제어된 방법으로 업데이트하려면 [롤링 업데이트](#롤링-업데이트)를 사용하라. ### 레플리케이션 컨트롤러에서 파드 격리 @@ -208,7 +208,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러는 파드를 하나씩 교체함으로써 서비스에 대한 롤링 업데이트를 쉽게 하도록 설계되었다. -[#1353](https://issue.k8s.io/1353) 에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다. +[#1353](https://issue.k8s.io/1353)에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다. 이상적으로 롤링 업데이트 컨트롤러는 애플리케이션 준비 상태를 고려하며 주어진 시간에 충분한 수의 파드가 생산적으로 제공되도록 보장할 것이다. @@ -229,15 +229,15 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 ## 레플리케이션을 위한 프로그램 작성 -레플리케이션 컨트롤러에 의해 생성된 파드는 해당 구성이 시간이 지남에 따라 이질적이 될 수 있지만 균일하고 의미상 동일하도록 설계되었다. 이는 레플리카된 상태 스테이트리스 서버에 적합하지만 레플리케이션 컨트롤러를 사용하여 마스터 선출, 샤드 및 워크-풀 애플리케이션의 가용성을 유지할 수도 있다. [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html) 와 같은 애플리케이션은 안티패턴으로 간주되는 각 파드의 구성에 대한 정적/일회성 사용자 정의와 반대로 동적 작업 할당 메커니즘을 사용해야 한다. 리소스의 수직 자동 크기 조정 (예 : CPU 또는 메모리)과 같은 수행된 모든 파드 사용자 정의는 레플리케이션 컨트롤러 자체와 달리 다른 온라인 컨트롤러 프로세스에 의해 수행되어야 한다. +레플리케이션 컨트롤러에 의해 생성된 파드는 해당 구성이 시간이 지남에 따라 이질적이 될 수 있지만 균일하고 의미상 동일하도록 설계되었다. 이는 레플리카된 상태 스테이트리스 서버에 적합하지만 레플리케이션 컨트롤러를 사용하여 마스터 선출, 샤드 및 워크-풀 애플리케이션의 가용성을 유지할 수도 있다. [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)와 같은 애플리케이션은 안티패턴으로 간주되는 각 파드의 구성에 대한 정적/일회성 사용자 정의와 반대로 동적 작업 할당 메커니즘을 사용해야 한다. 리소스의 수직 자동 크기 조정 (예 : CPU 또는 메모리)과 같은 수행된 모든 파드 사용자 정의는 레플리케이션 컨트롤러 자체와 달리 다른 온라인 컨트롤러 프로세스에 의해 수행되어야 한다. ## 레플리케이션 컨트롤러의 책임 레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다. -레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된) 가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019)) 을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170)) 까지도 고려해야 한다. +레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된)가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019))을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170))까지도 고려해야 한다. -레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) 와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다. +레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다. ## API 오브젝트 @@ -250,14 +250,14 @@ API 오브젝트에 대한 더 자세한 것은 ### 레플리카셋 -[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다. -이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다. +[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건)이다. +이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다. 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다. ### 디플로이먼트 (권장되는) -[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다. +[`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다. ### 베어 파드 @@ -266,12 +266,12 @@ API 오브젝트에 대한 더 자세한 것은 ### 잡 자체적으로 제거될 것으로 예상되는 파드 (즉, 배치 잡)의 경우 -레플리케이션 컨트롤러 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라. +레플리케이션 컨트롤러 대신 [`Job`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라. ### 데몬셋 머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신 -[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다. +[`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다. 다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며, 머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다. 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/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 43d54aff46..a84fb28b4c 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -45,7 +45,7 @@ ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가 상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다. UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되지 않는다. 대신, -해당 파드는 사용자가 원하는 이름은 같지만, UID가 다른, 거의 동일한 새 파드로 +해당 파드는 사용자가 원한다면 이름은 같지만, UID가 다른, 거의 동일한 새 파드로 대체될 수 있다. {{< glossary_tooltip term_id="volume" text="볼륨" >}}과 @@ -118,7 +118,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되 ### `Running` {#container-state-running} `Running` 상태는 컨테이너가 문제없이 실행되고 있음을 나타낸다. `postStart` 훅이 -구성되어 있었다면, 이미 실행이 완료되었다. `kubectl` 을 +구성되어 있었다면, 이미 실행되고 완료되었다. `kubectl` 을 사용하여 컨테이너가 `Running` 인 파드를 쿼리하면, 컨테이너가 `Running` 상태에 진입한 시기에 대한 정보도 볼 수 있다. @@ -341,7 +341,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 적용되면, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 정상 종료를 시도한다. -일반적으로, 컨테이너 런타임은 TERM 시그널을 각 컨테이너의 기본 프로세스로 +일반적으로, 컨테이너 런타임은 각 컨테이너의 기본 프로세스에 TERM 신호를 전송한다. 일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로 전송되고, 그런 다음 파드는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}로부터 삭제된다. 프로세스가 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 8fe6e45134..c81db66021 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 @@ -6,8 +6,6 @@ weight: 40 -{{< feature-state for_k8s_version="v1.18" state="beta" >}} - 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. @@ -16,13 +14,6 @@ weight: 40 ## 필수 구성 요소 -### 기능 게이트 활성화 - -를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** -{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해 -`EvenPodsSpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어야 한다. - ### 노드 레이블 토폴로지 분배 제약 조건은 노드 레이블을 의지해서 각 노드가 속한 토폴로지 도메인(들)을 인식한다. 예를 들어, 노드에 다음과 같은 레이블을 가지고 있을 수 있다. `node=node1,zone=us-east-1a,region=us-east-1` @@ -53,7 +44,7 @@ node4 Ready 2m43s v1.16.0 node=node4,zone=zoneB ### API -`pod.spec.topologySpreadConstraints` 필드는 1.16에서 다음과 같이 도입되었다. +API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다. ``` apiVersion: v1 @@ -70,7 +61,15 @@ spec: 사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다. -- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 한다. +- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. + 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 + 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 + 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다. + - `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는 + 대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 사이에 + 허용되는 최대 차이이다. + - `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는 + 왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다. - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다. - **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다. - `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다. @@ -186,7 +185,7 @@ spec: ### 클러스터 수준의 기본 제약 조건 -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} 클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다. @@ -194,7 +193,7 @@ spec: - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. - 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우. -기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서 +기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, @@ -203,7 +202,7 @@ spec: 예시 구성은 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1alpha2 +apiVersion: kubescheduler.config.k8s.io/v1beta1 kind: KubeSchedulerConfiguration profiles: @@ -212,18 +211,49 @@ profiles: args: defaultConstraints: - maxSkew: 1 - topologyKey: failure-domain.beta.kubernetes.io/zone + topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway ``` {{< note >}} 기본 스케줄링 제약 조건에 의해 생성된 점수는 -[`DefaultPodTopologySpread` 플러그인](/docs/reference/scheduling/profiles/#scheduling-plugins)에 +[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에 의해 생성된 점수와 충돌 할 수 있다. `PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서 이 플러그인을 비활성화 하는 것을 권장한다. {{< /note >}} +#### 내부 기본 제약 + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +`DefaultPodTopologySpread` 기능 게이트를 활성화하면, 기존 +`SelectorSpread` 플러그인이 비활성화된다. +kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은 +기본 토폴로지 제약 조건을 사용한다. + +```yaml +defaultConstraints: + - maxSkew: 3 + topologyKey: "kubernetes.io/hostname" + whenUnsatisfiable: ScheduleAnyway + - maxSkew: 5 + topologyKey: "topology.kubernetes.io/zone" + whenUnsatisfiable: ScheduleAnyway +``` + +또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인이 +비활성화된다. + +{{< note >}} +노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone` +레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는 +대신 자체 제약 조건을 정의한다. + +`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가 +없는 노드에 점수를 매기지 않는다. +{{< /note >}} + ## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교 쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가 @@ -234,13 +264,19 @@ profiles: - `PodAntiAffinity` 로는, 단일 토폴로지 도메인에 단 하나의 파드만 스케줄 될 수 있다. -"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 -고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. -더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다. +더 세밀한 제어를 위해, 토폴로지 분배 제약 조건을 지정하여 다양한 토폴로지 도메인에 파드를 +분배해서 고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 +제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. +더 자세한 내용은 +[모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 +참고한다. ## 알려진 제한사항 -1.18을 기준으로 이 기능은 베타(Beta)이며, 몇 가지 알려진 제한사항이 있다. - - 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다. - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다. + +## {{% heading "whatsnext" %}} + +- [블로그: PodTopologySpread 소개](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)에서는 + `maxSkew` 에 대해 자세히 설명하고, 몇 가지 고급 사용 예제를 제공한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 148abd29a3..b566402cf0 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 도구. ## 컴포넌트 레퍼런스 @@ -44,10 +44,10 @@ content_type: concept * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. * [kube-scheduler 정책](/docs/reference/scheduling/policies) - * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles) + * [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles) ## 설계 문서 -쿠버네티스 기능에 대한 설계 문서의 아카이브. [쿠버네티스 아키텍처](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..8992cb4999 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 @@ -67,7 +67,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CSIMigrationAWS` | `false` | 알파 | 1.14 | | | `CSIMigrationAWS` | `false` | 베타 | 1.17 | | | `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | | -| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | | +| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | +| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | | | `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | | | `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | | @@ -76,15 +77,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | | | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | | +| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | | +| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | | +| `CSIStorageCapacity` | `false` | 알파 | 1.19 | | +| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | | | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | | | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | | `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 | | `CustomResourceDefaulting` | `true` | 베타 | 1.16 | | +| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | | | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | | `DevicePlugins` | `true` | 베타 | 1.10 | | +| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.20 | | `DryRun` | `false` | 알파 | 1.12 | 1.12 | | `DryRun` | `true` | 베타 | 1.13 | | -| `DynamicAuditing` | `false` | 알파 | 1.13 | | | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | | | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | @@ -99,12 +105,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | | `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | | -| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | -| `EvenPodsSpread` | `true` | 베타 | 1.18 | | +| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | | | `HPAScaleToZero` | `false` | 알파 | 1.16 | | -| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | | +| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 | +| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | | | `HyperVContainer` | `false` | 알파 | 1.10 | | -| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | | +| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 | +| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | | | `IPv6DualStack` | `false` | 알파 | 1.16 | | | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | | `KubeletPodResources` | `true` | 베타 | 1.15 | | @@ -113,34 +120,37 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | | `MountContainers` | `false` | 알파 | 1.9 | | -| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | | -| `NonPreemptingPriority` | `false` | 알파 | 1.15 | | +| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | +| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | | +| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | +| `NonPreemptingPriority` | `true` | 베타 | 1.19 | | | `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | | `PodDisruptionBudget` | `true` | 베타 | 1.5 | | | `PodOverhead` | `false` | 알파 | 1.16 | - | | `ProcMountType` | `false` | 알파 | 1.12 | | | `QOSReserved` | `false` | 알파 | 1.11 | | | `RemainingItemCount` | `false` | 알파 | 1.15 | | -| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | | -| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | | | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | | `RunAsGroup` | `true` | 베타 | 1.14 | | | `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 | | `RuntimeClass` | `true` | 베타 | 1.14 | | -| `SCTPSupport` | `false` | 알파 | 1.12 | | +| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 | +| `SCTPSupport` | `true` | 베타 | 1.19 | | +| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 | +| `ServiceAppProtocol` | `true` | 베타 | 1.19 | | | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | | `ServerSideApply` | `true` | 베타 | 1.16 | | | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | | `ServiceAppProtocol` | `false` | 알파 | 1.18 | | -| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | | +| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | +| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | | | `ServiceTopology` | `false` | 알파 | 1.17 | | +| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | | | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | | `StartupProbe` | `true` | 베타 | 1.18 | | | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | -| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | -| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | | | `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 | | `SupportNodePidsLimit` | `true` | 베타 | 1.15 | | | `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 | @@ -156,6 +166,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | | | `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 | | `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | - | +| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | | | `WindowsGMSA` | `false` | 알파 | 1.14 | | | `WindowsGMSA` | `true` | 베타 | 1.16 | | | `WinDSR` | `false` | 알파 | 1.14 | | @@ -210,6 +221,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 | | `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 | | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - | +| `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 | +| `DynamicAuditing` | - | 사용 중단 | 1.19 | - | | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | | `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - | | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | @@ -218,6 +231,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - | | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | | `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - | +| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | +| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | +| `EvenPodsSpread` | `true` | GA | 1.19 | - | | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | | `HugePages` | `false` | 알파 | 1.8 | 1.9 | @@ -251,9 +267,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | | `PVCProtection` | - | 사용 중단 | 1.10 | - | | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | +| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 | +| `ResourceLimitsPriorityFunction` | - | 사용 중단 | 1.19 | - | | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | | `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | +| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 | +| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - | | `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 | | `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 | | `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - | @@ -262,6 +282,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | | `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 | | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | +| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | +| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 | +| `StreamingProxyRedirects` | - | 사용 중단| 1.19 | - | | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | @@ -377,11 +400,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 필요하다. - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. - `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. +- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. - `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 마운트할 수 있다. 자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다. +- `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다. + 자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다. +- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다. - `CustomCPUCFSQuotaPeriod`: 노드가 CPUCFSQuotaPeriod를 변경하도록 한다. - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 @@ -395,11 +423,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. 실행 중인 파드 문제를 해결한다. +- `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/docs/concepts/cluster-administration/monitoring.md). - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 기반 리소스 프로비저닝을 활성화한다. +- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여 + [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다. - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다. - `DynamicAuditing`: [동적 감사](/docs/tasks/debug-application-cluster/audit/#dynamic-backend) 기능을 활성화한다. +- `DynamicAuditing`(*사용 중단됨*): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다. - `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다. - `DynamicProvisioningScheduling`: 볼륨 스케줄을 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다. 이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다. @@ -420,10 +452,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 재 매핑이 활성화된 경우에만 활성화해야 한다. - `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한 엔드포인트 슬라이스를 활성화한다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. -- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, kube-proxy는 - 엔드포인트슬라이스를 엔드포인트 대신 기본 데이터 소스로 사용하여 - 확장성과 성능을 향상시킨다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. +- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, 리눅스에서 실행되는 + kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 + 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. + [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. +- `WindowsEndpointSliceProxying`: 이 기능 게이트가 활성화되면, 윈도우에서 실행되는 + kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 + 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. + [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. +- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다. - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다. - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다. - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. @@ -435,9 +473,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. - `KubeletPodResources`: kubelet의 파드 리소스 grpc 엔드포인트를 활성화한다. 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 참고한다. -- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. +- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `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)을 참고한다. @@ -460,7 +498,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 삭제되지 않도록 한다. - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다(현재 메모리만 해당). -- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 +- `ResourceLimitsPriorityFunction` (*사용 중단됨*): 입력 파드의 CPU 및 메모리 한도 중 하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는 스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진 노드 사이의 관계를 끊는 것이다. @@ -472,7 +510,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다. - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다. - `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다. -- `SCTPSupport`: SCTP를 `Service`, `Endpoint`, `NetworkPolicy` 및 `Pod` 정의에서 `protocol` 값으로 사용하는 것을 활성화한다. +- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다. - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다. - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다. - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다. @@ -480,6 +518,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다. "`alpha.service-controller.kubernetes.io/exclude-balancer`" 키 또는 `node.kubernetes.io/exclude-from-external-load-balancers` 로 레이블이 지정된 경우 노드를 제외할 수 있다. - `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다. +- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다. - `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다. - `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 사용 중인 경우 삭제를 연기한다. 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/scheduling/_index.md b/content/ko/docs/reference/scheduling/_index.md new file mode 100644 index 0000000000..7a37a35981 --- /dev/null +++ b/content/ko/docs/reference/scheduling/_index.md @@ -0,0 +1,5 @@ +--- +title: 스케줄링 +weight: 70 +toc-hide: true +--- diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md new file mode 100644 index 0000000000..71ccef5e87 --- /dev/null +++ b/content/ko/docs/reference/scheduling/policies.md @@ -0,0 +1,118 @@ +--- +title: 스케줄링 정책 +content_type: concept +weight: 10 +--- + + + +스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다. + +`kube-scheduler --policy-config-file ` 또는 `kube-scheduler --policy-configmap `을 실행하고 [정책 유형](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)을 사용하여 스케줄링 정책을 설정할 수 있다. + + + + + +## 단정 {#predicates} + +다음의 *단정* 은 필터링을 구현한다. + +- `PodFitsHostPorts`: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는 + 포트(네트워크 프로토콜 종류)가 있는지 확인한다. + +- `PodFitsHost`: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다. + +- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는 + 리소스(예: CPU 및 메모리)가 있는지 확인한다. + +- `PodMatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 + 노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다. + +- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면 + 파드가 요청하는 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 노드에서 사용할 수 있는지 + 평가한다. + +- `NoDiskConflict`: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해 + 파드가 노드에 적합한지 평가한다. + +- `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와 + 구성된 제한을 초과하는지 여부를 결정한다. + +- `CheckNodeMemoryPressure`: 노드가 메모리 압박을 보고하고 있고, 구성된 + 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. + +- `CheckNodePIDPressure`: 노드가 프로세스 ID 부족을 보고하고 있고, 구성된 + 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. + +- `CheckNodeDiskPressure`: 노드가 스토리지 압박(파일시스템이 가득차거나 + 거의 꽉 참)을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. + +- `CheckNodeCondition`: 노드는 파일시스템이 완전히 가득찼거나, + 네트워킹을 사용할 수 없거나, kubelet이 파드를 실행할 준비가 되지 않았다고 보고할 수 있다. + 노드에 대해 이러한 조건이 설정되고, 구성된 예외가 없는 경우, 파드가 + 해당 노드에 스케줄되지 않는다. + +- `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이 + 노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다. + +- `CheckVolumeBinding`: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다. + 이는 바인딩된 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}와 + 바인딩되지 않은 PVC 모두에 적용된다. + +## 우선순위 {#priorities} + +다음의 *우선순위* 는 스코어링을 구현한다. + +- `SelectorSpreadPriority`: 동일한 {{< glossary_tooltip text="서비스" term_id="service" >}}, + {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는 + {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}에 속하는 + 파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다. + +- `InterPodAffinityPriority`: 선호된 + [파드간 어피니티와 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다. + +- `LeastRequestedPriority`: 요청된 리소스가 적은 노드를 선호한다. 즉, + 노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가 + 많을수록 이 정책이 부여하는 순위가 낮아진다. + +- `MostRequestedPriority`: 요청된 리소스가 가장 많은 노드를 선호한다. + 이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된 + 파드를 맞춘다. + +- `RequestedToCapacityRatioPriority`: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다. + +- `BalancedResourceAllocation`: 균형 잡힌 리소스 사용의 노드를 선호한다. + +- `NodePreferAvoidPodsPriority`: 노드 어노테이션 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라 + 노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가 + 동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다. + +- `NodeAffinityPriority`: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링 + 설정에 따라 노드의 우선순위를 지정한다. + 이에 대한 자세한 내용은 [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)에서 확인할 수 있다. + +- `TaintTolerationPriority`: 노드에서 용인할 수 없는 테인트 수를 기반으로, + 모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을 + 고려하여 노드의 순위를 조정한다. + +- `ImageLocalityPriority`: 해당 파드의 + {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}가 이미 로컬로 캐시된 + 노드를 선호한다. + +- `ServiceSpreadingPriority`: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한 + 파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한 + 파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는 + 서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다. + +- `EqualPriority`: 모든 노드에 동일한 가중치를 부여한다. + +- `EvenPodsSpreadPriority`: 선호된 + [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다. + + + +## {{% heading "whatsnext" %}} + +* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기 +* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기 \ No newline at end of file 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..aa21c110d4 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -219,71 +219,155 @@ sysctl --system {{< tabs name="tab-cri-cri-o-installation" >}} {{< tab name="Debian" >}} -```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 - -``` +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다. -```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 - -``` +| 운영 체제 | $OS | +| ---------------- | ----------------- | +| Debian Unstable | `Debian_Unstable` | +| Debian Testing | `Debian_Testing` | -```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 - -``` +
+그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. +예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다. +사용자의 설치를 특정 릴리스에 고정할 수 있다. +버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다. +
+그런 다음, 아래를 실행한다. ```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 - -``` +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 -그리고 다음과 같이 CRI-O 설치한다. -```shell -sudo apt-get install cri-o-1.17 +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 ``` +<<<<<<< HEAD {{< /tab >}} {{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}} +======= +<<<<<<< HEAD +{{% /tab %}} -```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 -``` +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} +======= +{{% /tab %}} +>>>>>>> upstream/dev-1.19-ko.1 + +{{% 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` 을 설정한다. +
+>>>>>>> 357c22dfe... First Korean l10n work for release-1.19 + +그런 다음, 아래를 실행한다. ```shell -# CRI-O 설치 -sudo apt-get install cri-o-1.17 +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 +``` +<<<<<<< HEAD {{< /tab >}} {{< tab name="CentOS/RHEL 7.4+" >}} +======= +<<<<<<< HEAD +{{% /tab %}} -```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 -``` +{{% tab name="CentOS/RHEL 7.4+" %}} +======= -```shell -# CRI-O 설치 -yum install -y cri-o -``` +{{% /tab %}} -{{< tab name="openSUSE Tumbleweed" >}} +{{% tab name="openSUSE Tumbleweed" %}} +>>>>>>> upstream/dev-1.19-ko.1 +>>>>>>> 357c22dfe... First Korean l10n work for release-1.19 ```shell sudo zypper install cri-o ``` +{{% /tab %}} +{{% tab name="Fedora" %}} + +`$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. +예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다. + +사용할 수 있는 버전을 찾으려면 다음을 실행한다. +```shell +dnf module list cri-o +``` +CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다. + +<<<<<<< HEAD +{{< tab name="openSUSE Tumbleweed" >}} +======= +<<<<<<< HEAD +{{% tab name="openSUSE Tumbleweed" %}} +>>>>>>> 357c22dfe... First Korean l10n work for release-1.19 + +======= +그런 다음, 아래를 실행한다. +>>>>>>> upstream/dev-1.19-ko.1 +```shell +dnf module enable cri-o:$VERSION +dnf install cri-o +``` +<<<<<<< HEAD {{< /tab >}} +======= +<<<<<<< HEAD +======= + +>>>>>>> upstream/dev-1.19-ko.1 +{{% /tab %}} +>>>>>>> 357c22dfe... First Korean l10n work for release-1.19 {{< /tabs >}} ### CRI-O 시작 @@ -395,7 +479,40 @@ containerd config default > /etc/containerd/config.toml # containerd 재시작 systemctl restart containerd ``` +<<<<<<< HEAD {{< /tab >}} +======= +<<<<<<< HEAD +======= +{{< /tab >}} +{{% tab name="윈도우 (PowerShell)" %}} +```powershell +# (containerd 설치) +# containerd 다운로드 +cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.0-beta.2/containerd-1.4.0-beta.2-windows-amd64.tar.gz +cmd /c tar xvf .\containerd-1.4.0-beta.2-windows-amd64.tar.gz +``` + +```powershell +# 압축을 풀고 구성 +Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force +cd $Env:ProgramFiles\containerd\ +.\containerd.exe config default | Out-File config.toml -Encoding ascii + +# 구성을 검토한다. 설정에 따라 아래를 조정할 수 있다. +# - sandbox_image (쿠버네티스 pause 이미지) +# - cni bin_dir 및 conf_dir 위치 +Get-Content config.toml +``` + +```powershell +# containerd 시작 +.\containerd.exe --register-service +Start-Service containerd +``` +>>>>>>> upstream/dev-1.19-ko.1 +{{% /tab %}} +>>>>>>> 357c22dfe... First Korean l10n work for release-1.19 {{< /tabs >}} ### systemd @@ -407,5 +524,3 @@ kubeadm을 사용하는 경우에도 마찬가지로, 수동으로 ## 다른 CRI 런타임: frakti 자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다. - - diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md deleted file mode 100644 index 740d468acc..0000000000 --- a/content/ko/docs/setup/release/notes.md +++ /dev/null @@ -1,1370 +0,0 @@ ---- -title: v1.18 릴리스 노트 -weight: 10 -card: - name: release-notes - weight: 20 - anchors: - - anchor: "#" - title: 최신 릴리스 노트 - - anchor: "#긴급-업그레이드-노트" - title: 긴급 업그레이드 노트 ---- - - - -# v1.18.0 - -[문서](https://docs.k8s.io) - -## v1.18.0 다운로드 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes.tar.gz) | `cd5b86a3947a4f2cea6d857743ab2009be127d782b6f2eb4d37d88918a5e433ad2c7ba34221c34089ba5ba13701f58b657f0711401e51c86f4007cb78744dee7` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-src.tar.gz) | `fb42cf133355ef18f67c8c4bb555aa1f284906c06e21fa41646e086d34ece774e9d547773f201799c0c703ce48d4d0e62c6ba5b2a4d081e12a339a423e111e52` - -### 클라이언트 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-386.tar.gz) | `26df342ef65745df12fa52931358e7f744111b6fe1e0bddb8c3c6598faf73af997c00c8f9c509efcd7cd7e82a0341a718c08fbd96044bfb58e80d997a6ebd3c2` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-amd64.tar.gz) | `803a0fed122ef6b85f7a120b5485723eaade765b7bc8306d0c0da03bd3df15d800699d15ea2270bb7797fa9ce6a81da90e730dc793ea4ed8c0149b63d26eca30` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-386.tar.gz) | `110844511b70f9f3ebb92c15105e6680a05a562cd83f79ce2d2e25c2dd70f0dbd91cae34433f61364ae1ce4bd573b635f2f632d52de8f72b54acdbc95a15e3f0` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-amd64.tar.gz) | `594ca3eadc7974ec4d9e4168453e36ca434812167ef8359086cd64d048df525b7bd46424e7cc9c41e65c72bda3117326ba1662d1c9d739567f10f5684fd85bee` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm.tar.gz) | `d3627b763606557a6c9a5766c34198ec00b3a3cd72a55bc2cb47731060d31c4af93543fb53f53791062bb5ace2f15cbaa8592ac29009641e41bd656b0983a079` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm64.tar.gz) | `ba9056eff1452cbdaef699efbf88f74f5309b3f7808d372ebf6918442d0c9fea1653c00b9db3b7626399a460eef9b1fa9e29b827b7784f34561cbc380554e2ea` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-ppc64le.tar.gz) | `f80fb3769358cb20820ff1a1ce9994de5ed194aabe6c73fb8b8048bffc394d1b926de82c204f0e565d53ffe7562faa87778e97a3ccaaaf770034a992015e3a86` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-s390x.tar.gz) | `a9b658108b6803d60fa3cd4e76d9e58bf75201017164fe54054b7ccadbb68c4ad7ba7800746940bc518d90475e6c0a96965a26fa50882f4f0e56df404f4ae586` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-386.tar.gz) | `18adffab5d1be146906fd8531f4eae7153576aac235150ce2da05aee5ae161f6bd527e8dec34ae6131396cd4b3771e0d54ce770c065244ad3175a1afa63c89e1` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-amd64.tar.gz) | `162396256429cef07154f817de2a6b67635c770311f414e38b1e2db25961443f05d7b8eb1f8da46dec8e31c5d1d2cd45f0c95dad1bc0e12a0a7278a62a0b9a6b` - -### 서버 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-amd64.tar.gz) | `a92f8d201973d5dfa44a398e95fcf6a7b4feeb1ef879ab3fee1c54370e21f59f725f27a9c09ace8c42c96ac202e297fd458e486c489e05f127a5cade53b8d7c4` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm.tar.gz) | `62fbff3256bc0a83f70244b09149a8d7870d19c2c4b6dee8ca2714fc7388da340876a0f540d2ae9bbd8b81fdedaf4b692c72d2840674db632ba2431d1df1a37d` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm64.tar.gz) | `842910a7013f61a60d670079716b207705750d55a9e4f1f93696d19d39e191644488170ac94d8740f8e3aa3f7f28f61a4347f69d7e93d149c69ac0efcf3688fe` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-ppc64le.tar.gz) | `95c5b952ac1c4127a5c3b519b664972ee1fb5e8e902551ce71c04e26ad44b39da727909e025614ac1158c258dc60f504b9a354c5ab7583c2ad769717b30b3836` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-s390x.tar.gz) | `a46522d2119a0fd58074564c1fa95dd8a929a79006b82ba3c4245611da8d2db9fd785c482e1b61a9aa361c5c9a6d73387b0e15e6a7a3d84fffb3f65db3b9deeb` - -### 노드 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-amd64.tar.gz) | `f714f80feecb0756410f27efb4cf4a1b5232be0444fbecec9f25cb85a7ccccdcb5be588cddee935294f460046c0726b90f7acc52b20eeb0c46a7200cf10e351a` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm.tar.gz) | `806000b5f6d723e24e2f12d19d1b9b3d16c74b855f51c7063284adf1fcc57a96554a3384f8c05a952c6f6b929a05ed12b69151b1e620c958f74c9600f3db0fcb` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm64.tar.gz) | `c207e9ab60587d135897b5366af79efe9d2833f33401e469b2a4e0d74ecd2cf6bb7d1e5bc18d80737acbe37555707f63dd581ccc6304091c1d98dafdd30130b7` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-ppc64le.tar.gz) | `a542ed5ed02722af44ef12d1602f363fcd4e93cf704da2ea5d99446382485679626835a40ae2ba47a4a26dce87089516faa54479a1cfdee2229e8e35aa1c17d7` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-s390x.tar.gz) | `651e0db73ee67869b2ae93cb0574168e4bd7918290fc5662a6b12b708fa628282e3f64be2b816690f5a2d0f4ff8078570f8187e65dee499a876580a7a63d1d19` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-windows-amd64.tar.gz) | `d726ed904f9f7fe7e8831df621dc9094b87e767410a129aa675ee08417b662ddec314e165f29ecb777110fbfec0dc2893962b6c71950897ba72baaa7eb6371ed` - -## v1.17.0 이후 체인지로그 - -릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0)에서 사용자 정의 가능한 -형식으로 호스팅된다. 확인하고 의견을 보내주기 -바란다! - -## 새로운 소식 (주요 테마) - -### 쿠버네티스 토폴로지 매니저가 베타로 전환 - 정렬! - -릴리스 1.18의 쿠버네티스 베타 기능인 [토폴로지 매니저 기능](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md)은 저-지연(low-latency)에 최적화된 환경에서 워크로드를 실행할 수 있도록 CPU 및 장치(예: SR-IOV VF)를 NUMA 정렬 할 수 있다. 토폴로지 매니저가 도입되기 전에, CPU와 장치 관리자는 서로 독립적으로 리소스 할당 결정을 내렸다. 이로 인해 다중-소켓 시스템에 의도하지 않은 할당이 발생하여, 지연에 민감한 애플리케이션의 성능을 저하시킬 수 있었다. - -### 서버 사이드(server-side) 적용 - 베타 2 - -서버-사이드 적용은 1.16에서 베타로 승격되었지만, 1.18에서 두 번째 베타가 도입된다. 이 새 버전은 모든 새로운 쿠버네티스 오브젝트의 필드 변경 사항을 추적하고 관리하여, 리소스의 변경된 부분과 시기를 알 수 있다. - -### 인그레스 확장 및 IngressClass로 사용 중단(deprecated) 어노테이션을 교체 - -쿠버네티스 1.18에서 인그레스에 두 가지 중요한 추가 사항이 있는데, 그것은 새로운 `pathType` 필드와 새로운 `IngressClass` 리소스이다. `pathType` 필드는 경로(path)를 일치시키는 방법을 지정한다. 기본 `ImplementationSpecific` 유형 외에도 새로운 `Exact` 와 `Prefix` 경로 유형이 있다. - -`IngressClass` 리소스는 쿠버네티스 클러스터 내에서 인그레스 유형을 설명하는 데 사용된다. 인그레스는 인그레스에서 새로운 `ingressClassName` 필드를 사용하여 연관된 클래스를 지정할 수 있다. 이 새 리소스와 필드는 사용 중단된 `kubernetes.io/ingress.class` 어노테이션을 대체한다. - -### SIG CLI의 kubectl 디버그 소개 - -SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다. - -### 쿠버네티스를 위한 윈도우 CSI 지원 알파 소개 - -쿠버네티스 1.18 릴리스에서는 윈도우 용 CSI 프록시(CSI Proxy)의 알파 버전이 릴리스 된다. CSI 프록시를 사용하면 권한이 없는(사전 승인된) 컨테이너가 윈도우에서 권한이 있는 스토리지 작업을 수행할 수 있다. CSI 프록시를 활용하여 윈도우에서 CSI 드라이버를 지원할 수 있다. -SIG 스토리지는 1.18 릴리스에서 많은 진전을 이루었다. -특히, 다음 스토리지 기능이 쿠버네티스 1.18에서 GA 되었다. -- 원시(Raw) 블록 지원: 볼륨을 마운트된 파일시스템 대신, 컨테이너 내에 블록 장치로 표시할 수 있다. -- 볼륨 복제: CSI를 통해 쿠버네티스 API를 사용하여 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 및 기본 스토리지 볼륨을 복제한다. -- CSIDriver 쿠버네티스 API 오브젝트: CSI 드라이버 검색을 단순화하고 CSI 드라이버가 쿠버네티스 동작을 사용자 정의할 수 있게 한다. - -SIG 스토리지는 쿠버네티스 1.18에서 다음과 같은 새로운 스토리지 기능을 알파로 도입했다. -- 윈도우 CSI 지원: 새로운 [CSIProxy](https://github.com/kubernetes-csi/csi-proxy)를 통해 윈도우에서 컨테이너화 된 CSI 노드 플러그인 활성화한다. -- 재귀 볼륨 소유권 OnRootMismatch 옵션: 소유권 변경이 필요하고 많은 디렉터리와 파일이 있는 볼륨의 마운트 시간을 단축할 수 있는 새로운 “OnRootMismatch” 정책을 추가한다. - -### 다른 중요한 발표 - -새로운 CI 작업으로 테스트 커버리지를 크게 늘린 이후, SIG 네트워크는 쿠버네티스 1.18에서 IPv6를 베타로 전환한다. - -NodeLocal DNSCache는 dnsCache 파드를 데몬셋으로 실행하여 clusterDNS 성능과 안정성을 향상시키는 애드온이다. 이 기능은 1.13 릴리스 이후 알파 버전으로 존재해왔다. SIG 네트워크는 Node Local DNSCache [#1351](https://github.com/kubernetes/enhancements/pull/1351)의 GA를 발표한다. - -## 알려진 이슈 - -알려진 이슈가 보고되지 않음 - -## 긴급 업그레이드 노트 - -### (업그레이드하기 전에 반드시 읽어야 한다) - -#### kube-apiserver: -- `--encryption-provider-config` 설정 파일에서, 명시적인 `cacheSize: 0` 파라미터는 이전에는 묵시적으로 1000개의 키를 캐싱하도록 기본으로 설정되었다. 쿠버네티스 1.18에서 이것은 이제 설정 유효성 검사 오류를 반환한다. 캐싱을 비활성화하려면 쿠버네티스 1.18 이상에서 음의 cacheSize 값을 지정할 수 있다. -- 'certificatesigningrequests/approval' API 사용자는 이제 CSR이 요청한 특정 서명자(signer)에 대해 CSR을 '승인'할 권한이 있어야 한다. 새 signerName 필드 및 필수 권한 부여에 대한 자세한 정보는 https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests#authorization ([#88246](https://github.com/kubernetes/kubernetes/pull/88246), [@munnerz](https://github.com/munnerz)) [SIG API Machinery, 앱, 인증, CLI, 노드 및 테스트] 에서 확인할 수 있다. -- 다음 기능은 무조건 활성화되며, 다음의 `--feature-gates`의 플래그가 제거되었다. `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` 및 `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness)) [SIG 앱과 스케줄] - -#### kubelet: -- `--enable-cadvisor-endpoints` 는 이제 기본적으로 비활성화되어 있다. cAdvisor v1 Json API에 접근해야 하는 경우, kubelet 커맨드 라인에서 명시적으로 활성화한다. 이 플래그는 1.15에서 사용 중단되었으며 1.19에서 제거될 것이다. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, 노드 및 테스트] -- CSIMigrationOpenStack을 베타로 승격한다(OpenStack Cinder CSI 드라이버를 설치해야 하므로 기본적으로 해제되어 있다). 인-트리(in-tree) AWS OpenStack Cinder 드라이버 "kubernetes.io/cinder"는 1.16에서 사용 중단되었으며, 1.20에서 제거될 것이다. 사용자는 CSIMigration + CSIMigrationOpenStack 기능을 활성화하고 OpenStack Cinder CSI 드라이버 (https://github.com/kubernetes-sigs/cloud-provider-openstack)를 설치하여 기존 파드와 PVC 오브젝트가 중단되지 않도록 해야한다. 사용자는 새 볼륨에 대해 OpenStack Cinder CSI 드라이버를 직접 사용해야 한다. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG 클라우드 공급자] - -#### kubectl: -- `kubectl` 및 k8s.io/client-go의 기본값은 더 이상 `http://localhost:8080`의 서버 주소가 아니다. 이러한 레거시 클러스터 중 하나를 소유한 경우, 서버를 안전하게 보호하는 것을 *강력히* 권장한다. 서버를 보호할 수 없다면, `$KUBERNETES_MASTER` 환경 변수를 `http://localhost:8080`으로 설정하여 서버 주소의 기본값을 계속 유지할 수 있다. `kubectl` 사용자는 `--server` 플래그를 사용하거나 `--kubeconfig` 또는 `$KUBECONFIG`를 통해 지정된 kubeconfig 파일에서 서버 주소를 설정할 수도 있다. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI 및 테스트] -- `kubectl run`은 파드 생성과 관련이 없는 플래그와 함께, 이전에 사용 중단된 생성기(generator)를 삭제했다. `kubectl run`은 이제 파드만 생성한다. 파드 이외의 오브젝트를 만드려면, 특정 `kubectl create` 하위 커맨드를 참조한다. -([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, CLI 및 테스트] -- 사용 중단된 커맨드 `kubectl rolling-update`는 삭제되었다. ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG 아키텍처, CLI 및 테스트] - -#### client-go: -- 생성된 클라이언트 세트, 동적, 메타데이터 및 스케일 클라이언트의 메소드에 대한 서명이 `context.Context`를 첫 번째 인수로 채택하도록 수정되었다. Create, Update 및 Patch 메소드의 서명이 각각 CreateOptions, UpdateOptions 및 PatchOptions를 허용하도록 업데이트되었다. Delete 및 DeleteCollection 메소드의 서명은 이제 참조 대신 값으로 DeleteOptions를 허용한다. 이전 인터페이스를 사용하여 생성된 클라이언트 세트가 새로운 "사용 중단된" 패키지에 추가되어 새로운 API로 증분(incremental) 마이그레이션 할 수 있다. 사용 중단된 패키지는 1.21 릴리스에서 제거된다. http://sigs.k8s.io/clientgofix 에서 도구를 사용하여 새로운 서명에 대한 메소드 호출을 다시 쓸 수 있다. - -- 다음의 사용 중단된 메트릭이 제거되었다. 해당 메트릭으로 변환한다. - - 다음 교체 메트릭은 v1.14.0부터 제공된다. - - `rest_client_request_latency_seconds` -> `rest_client_request_duration_seconds` - - `scheduler_scheduling_latency_seconds` -> `scheduler_scheduling_duration_seconds ` - - `docker_operations` -> `docker_operations_total` - - `docker_operations_latency_microseconds` -> `docker_operations_duration_seconds` - - `docker_operations_errors` -> `docker_operations_errors_total` - - `docker_operations_timeout` -> `docker_operations_timeout_total` - - `network_plugin_operations_latency_microseconds` -> `network_plugin_operations_duration_seconds` - - `kubelet_pod_worker_latency_microseconds` -> `kubelet_pod_worker_duration_seconds` - - `kubelet_pod_start_latency_microseconds` -> `kubelet_pod_start_duration_seconds` - - `kubelet_cgroup_manager_latency_microseconds` -> `kubelet_cgroup_manager_duration_seconds` - - `kubelet_pod_worker_start_latency_microseconds` -> `kubelet_pod_worker_start_duration_seconds` - - `kubelet_pleg_relist_latency_microseconds` -> `kubelet_pleg_relist_duration_seconds` - - `kubelet_pleg_relist_interval_microseconds` -> `kubelet_pleg_relist_interval_seconds` - - `kubelet_eviction_stats_age_microseconds` -> `kubelet_eviction_stats_age_seconds` - - `kubelet_runtime_operations` -> `kubelet_runtime_operations_total` - - `kubelet_runtime_operations_latency_microseconds` -> `kubelet_runtime_operations_duration_seconds` - - `kubelet_runtime_operations_errors` -> `kubelet_runtime_operations_errors_total` - - `kubelet_device_plugin_registration_count` -> `kubelet_device_plugin_registration_total` - - `kubelet_device_plugin_alloc_latency_microseconds` -> `kubelet_device_plugin_alloc_duration_seconds` - - `scheduler_e2e_scheduling_latency_microseconds` -> `scheduler_e2e_scheduling_duration_seconds` - - `scheduler_scheduling_algorithm_latency_microseconds` -> `scheduler_scheduling_algorithm_duration_seconds` - - `scheduler_scheduling_algorithm_predicate_evaluation` -> `scheduler_scheduling_algorithm_predicate_evaluation_seconds` - - `scheduler_scheduling_algorithm_priority_evaluation` -> `scheduler_scheduling_algorithm_priority_evaluation_seconds` - - `scheduler_scheduling_algorithm_preemption_evaluation` -> `scheduler_scheduling_algorithm_preemption_evaluation_seconds` - - `scheduler_binding_latency_microseconds` -> `scheduler_binding_duration_seconds` - - `kubeproxy_sync_proxy_rules_latency_microseconds` -> `kubeproxy_sync_proxy_rules_duration_seconds` - - `apiserver_request_latencies` -> `apiserver_request_duration_seconds` - - `apiserver_dropped_requests` -> `apiserver_dropped_requests_total` - - `etcd_request_latencies_summary` -> `etcd_request_duration_seconds` - - `apiserver_storage_transformation_latencies_microseconds ` -> `apiserver_storage_transformation_duration_seconds` - - `apiserver_storage_data_key_generation_latencies_microseconds` -> `apiserver_storage_data_key_generation_duration_seconds` - - `apiserver_request_count` -> `apiserver_request_total` - - `apiserver_request_latencies_summary` - - 다음 교체 메트릭은 v1.15.0부터 제공된다. - - `apiserver_storage_transformation_failures_total` -> `apiserver_storage_transformation_operations_total` ([#76496](https://github.com/kubernetes/kubernetes/pull/76496), [@danielqsj](https://github.com/danielqsj)) [SIG API Machinery, 클러스터 라이프사이클, Instrumentation, 네트워크, 노드 및 스케줄링] - -## 종류(Kind)별 변경 - -### 사용 중단 - -#### kube-apiserver: -- 다음의 사용 중단된 API는 더 이상 제공되지 않는다. - - `apps/v1beta1`와 `apps/v1beta2`의 모든 리소스 대신 `apps/v1`을 사용한다. - - `extensions/v1beta1`의 `daemonsets`, `deployments`, `replicasets` 리소스 대신 `apps/v1`을 사용한다. - - `extensions/v1beta1`의 `networkpolicies` 리소스 대신 `networking.k8s.io/v1`을 사용한다. - - `extensions/v1beta1`의 `podsecuritypolicies`의 리소스 대신 `policy/v1beta1`을 사용한다. ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 앱, 클러스터 라이프사이클, Instrumentation 및 테스트] - -#### kube-controller-manager: -- Azure 서비스 어노테이션 service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset은 사용 중단되었다. 향후 릴리스에서는 지원이 제거될 것이다. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] - -#### kubelet: -- StreamingProxyRedirects 기능과 `--redirect-container-streaming` 플래그는 사용 중단되었으며, 향후 릴리스에서 제거될 예정이다. 디폴트 동작 (kubelet을 통한 프록시 스트리밍 요청)이 유일하게 지원되는 옵션이다. `--redirect-container-streaming=true`로 설정하는 경우, 이 설정으로부터 마이그레이션 해야 한다. v1.20부터는 이 플래그를 더 이상 사용할 수 없다. 플래그를 설정하지 않으면, 아무것도 할 필요가 없다. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery와 노드] -- `/metrics/resource/v1alpha1` 리소스 메트릭 엔드포인트와 이 엔드포인트 이하 모든 메트릭은 사용 중단되었다. `/metrics/resource` 엔드포인트에서 생성된 다음의 메트릭으로 변환해야 한다. - - scrape_error --> scrape_error - - node_cpu_usage_seconds_total --> node_cpu_usage_seconds - - node_memory_working_set_bytes --> node_memory_working_set_bytes - - container_cpu_usage_seconds_total --> container_cpu_usage_seconds - - container_memory_working_set_bytes --> container_memory_working_set_bytes - - scrape_error --> scrape_error - ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) [SIG 노드] -- 향후 릴리스에서, kubelet은 CSI 명세에 따라 더 이상 CSI NodePublishVolume 대상 디렉터리를 만들지 않는다. 대상 경로를 적절하게 생성하고 처리하려면 CSI 드라이버를 상황에 맞게 업데이트해야 한다. ([#75535](https://github.com/kubernetes/kubernetes/issues/75535)) [SIG 스토리지] - -#### kube-proxy: -- `--healthz-port`와 `--metrics-port` 플래그는 사용 중단되었으므로, 대신 `--healthz-bind-address`와 `--metrics-bind-address`를 사용한다. ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG 네트워크] -- kube-proxy에서 엔드포인트슬라이스(EndpointSlice)의 사용을 제어하기 위해 새로운 `EndpointSliceProxying` 기능 게이트가 추가되었다. 이 동작을 제어하는데 사용된 엔드포인트슬라이스 기능 게이트는 더 이상 kube-proxy에 영향을 미치지 않는다. 이 기능은 기본적으로 비활성화되어 있다. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) - -#### kubeadm: -- `kubeadm upgrade node`에 대한 커맨드 라인 옵션 "kubelet-version"은 사용 중단되었으며 향후 릴리스에서 제거될 예정이다. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- `kubeadm alpha certs renew` 커맨드에서 실험용 플래그 `--use-api`의 사용을 중단한다. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- kube-dns는 사용 중단되었으며 향후 버전에서 지원되지 않는다. ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- kubeadm-config 컨피그맵(ConfigMap)에 있는 `ClusterStatus` 구조체는 사용 중단되었으며, 향후 버전에서 제거될 예정이다. 제거될 때까지 kubeadm에 의해 유지 관리된다. 동일 정보는 `etcd`, `kube-apiserver` 파드 어노테이션, `kubeadm.kubernetes.io/etcd.advertise-client-urls`, `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint`에서 각각 찾을 수 있다. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG 클러스터 라이프사이클] - -#### kubectl: -- --dry-run 플래그의 boolean 값과 설정되지 않은 값은 사용 중단되었으며 이후 버전에서는 --dry-run=server|client|none 값이 필요하다. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI] -- `kubectl apply --server-dry-run` 은 사용 중단되었으며 --dry-run=server로 대체되었다. ([# 87580] (https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto) [SIG CLI] - -#### add-ons: -- 클러스터-모니터링 애드온을 제거한다. ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius)) [SIG 클러스터 라이프사이클, Instrumentation, 확장성, 테스트] - -#### kube-scheduler: -- `scheduling_duration_seconds` 요약 메트릭은 사용 중단되었다. ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG 스케줄링] -- `scheduling_algorithm_predicate_evaluation_seconds`, - `scheduling_algorithm_priority_evaluation_seconds` 메트릭은 사용 중단되었으며, `framework_extension_point_duration_seconds[extension_point="Filter"]`, `framework_extension_point_duration_seconds[extension_point="Score"]`으로 대체되었다. ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG 스케줄링] -- 스케줄러 정책 API에서 `AlwaysCheckAllPredicates`는 사용 중단되었다. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG 스케줄링] - -#### 기타 사용 중단: -- k8s.io/node-api 컴포넌트는 더 이상 업데이트되지 않는다. 대신, k8s.io/api의 RuntimeClass 타입과 k8s.io/client-go의 생성된 클라이언트를 사용한다. ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG 노드와 릴리스] -- apiserver_request_total에서 'client' 레이블을 제거했다. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery 와 Instrumentation] - -### API 변경 - -#### 새로운 API 타입/버전: -- 새로운 IngressClass 리소스가 추가되어 보다 나은 인그레스 구성이 가능하다. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, 앱, CLI, 네트워크, 노드, 테스트] -- CSIDriver API는 storage.k8s.io/v1을 졸업했으며, 이제 사용이 가능하다. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG 스토리지] - -#### 새로운 API 필드: -- autoscaling/v2beta2 HorizontalPodAutoscaler는 스케일 동작을 구성할 수 있는 `spec.behavior` 필드를 추가했다. 스케일 업과 다운에 대한 동작은 별도로 지정된다. 정책 목록과 정책 선택 방법 뿐만 아니라, 양 방향에서 안정화 윈도우를 지정할 수 있다. 정책은 추가되거나 제거되는 절대 파드 개수 또는 파드 비율을 제한할 수 있다.] ([#74525](https://github.com/kubernetes/kubernetes/pull/74525), [@gliush](https://github.com/gliush)) [SIG API Machinery, 앱, 오토스케일링, CLI] -- 인그레스: - - `spec.ingressClassName`은 사용 중단된 `kubernetes.io/ingress.class` 어노테이션을 대체하고, 인그레스 오브젝트를 특정 컨트롤러와 연결할 수 있게 한다. - - 경로 정의는 `pathType` 필드를 추가했는데, 지정 경로가 유입되는 요청과 어떻게 일치해야 하는지 표시하는 것을 허용한다. 유효한 값은 `Exact`, `Prefix`, `ImplementationSpecific` 이다. ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG 앱, 클러스터 라이프사이클과 네트워크] -- 알파 기능인 `AnyVolumeDataSource`는 퍼시스턴트볼륨클레임 오브젝트가 spec.dataSource 필드를 사용하여 사용자 정의 유형을 데이터 소스로 참조할 수 있도록 한다. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG 앱, 스토리지] -- 알파 기능인 `ConfigurableFSGroupPolicy`는 v1 파드가 spec.securityContext.fsGroupChangePolicy 정책을 지정하여 파드에 마운트된 볼륨에 파일 권한이 적용되는 방식을 제어할 수 있다. ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG 스토리지] -- 알파 기능인 `ServiceAppProtocol`을 사용하면 ServicePort 및 EndpointPort 정의에서 `appProtocol` 필드를 설정할 수 있다. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG 앱, 네트워크] -- 알파 기능인 `ImmutableEphemeralVolumes`는 시크릿(Secret) 및 컨피그맵 오브젝트의 `immutable` 필드를 통해 내용을 변경할 수 없는(immutable) 것으로 표시할 수 있다. ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t)) [SIG 앱, CLI, 테스팅] - -#### 다른 API 변경: -- 베타 기능인 `ServerSideApply`는 모든 새로운 오브젝트에 대해 변경된 필드를 추적하고 관리할 수 있게 해준다. 이는 관리자와 그것의 자체 필드에 대한 목록과 함께 `metadata`에 `managedFields`가 있음을 의미한다. -- 알파 기능인 `ServiceAccountIssuerDiscovery`는 서비스 어카운트 토큰을 발행하도록 구성된 API 서버에 의해 `/.well-known/openid-configuration` 및 `/openid/v1/jwks` 엔드포인트에 위치한 OIDC 디스커버리 정보 및 서비스 어카운트 토큰 검증 키를 공개할 수 있게 한다. ([#80724](https://github.com/kubernetes/kubernetes/pull/80724), [@cceckman](https://github.com/cceckman)) [SIG API Machinery, 인증, 클러스터 라이프사이클, 테스트] -- `x-kubernetes-list-map-keys`를 사용하여 목록 아이템을 고유하게 식별하는 속성을 지정하는 커스텀리소스데피니션(CustomResourceDefinition) 스키마는 해당 속성이 모든 목록 아이템에 존재하도록 하기 위해, 해당 속성을 필수로 설정하거나 기본값을 가져야 한다. 자세한 내용은 https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy 를 확인한다. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery, 테스트] -- `x-kubernetes-list-type: map` 또는 `x-kubernetes-list-type: set`을 사용하는 커스텀리소스데피니션 스키마는 이제 해당 커스텀 리소스의 목록 아이템이 고유한지 확인할 수 있다. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] - -#### 설정 파일 변경: - -#### kube-apiserver: -- `--egress-selector-config-file` 설정 파일은 이제 apiserver.k8s.io/v1beta1 EgressSelectorConfiguration 설정 오브젝트를 수용하며, 네트워크 프록시에 대한 HTTP 또는 GRPC 연결을 지정할 수 있도록 업데이트되었다. ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, 클라우드 공급자, 클러스터 라이프사이클] - -#### kube-scheduler: -- 다중 스케줄링 프로파일을 지원하는 kubescheduler.config.k8s.io/v1alpha2 설정 파일 버전이 승인되었다. ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링] - - `kubescheduler.config.k8s.io/v1alpha2`에서 HardPodAffinityWeight가 최상위 ComponentConfig 파라미터에서 InterPodAffinity 플러그인의 PluginConfig 파라미터로 이동했다. ([#88002](https://github.com/kubernetes/kubernetes/pull/88002), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링, 테스트] - - Kube-scheduler는 둘 이상의 스케줄링 프로파일을 실행할 수 있다. 파드가 주어지면, 프로파일은 `.spec.schedulerName`을 사용하여 선택된다. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG 앱, 스케줄링, 테스트] - - v1alpha2 컴포넌트 설정에서 스케줄러 확장자(Scheduler Extender)를 설정할 수 있다. ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG 릴리스, 스케줄링, 테스트] - - 스케줄러 프레임워크의 PostFilter는 kubescheduler.config.k8s.io/v1alpha2에서 PreScore로 이름이 변경되었다. ([#87751](https://github.com/kubernetes/kubernetes/pull/87751), [@skilxn-go](https://github.com/skilxn-go)) [SIG 스케줄링, 테스트] - -#### kube-proxy: -- IPVS 연결 타임아웃을 설정하기 위해 kube-proxy 플래그 `--ipvs-tcp-timeout`, `--ipvs-tcpfin-timeout`, `--ipvs-udp-timeout`을 추가했다. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) [SIG 클러스터 라이프사이클, 네트워크] -- kube-proxy에 옵션 `--detect-local-mode` 플래그를 추가했다. 유효한 값은 "ClusterCIDR"(기본값은 이전 동작과 일치)과 "NodeCIDR"이다. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG 클러스터 라이프사이클, 네트워크, 스케줄링] -- Kube-controller-manager와 kube-scheduler는 기본적으로 kube-apiserver와 일치하도록 프로파일링을 노출한다. 비활성화하려면 `--enable-profiling=false`를 사용한다. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, 클라우드 공급자, 스케줄링] -- Kubelet 파드 리소스 API는 이제 활성화(active)된 파드에 대한 정보만 제공한다. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG 노드] -- kube-controller-manager의 새로운 플래그 `--endpointslice-updates-batch-period`를 사용하여 파드 변경으로 생성된 엔드포인트슬라이스 업데이트 수를 줄일 수 있다. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, 앱, 네트워크] -- kube-proxy, kubelet, kube-controller-manager 및 kube-scheduler의 새로운 플래그 `--show-hidden-metrics-for-version`은 이전 마이너 릴리스에서 사용 중단된 모든 숨겨진 메트릭을 표시하는 데 사용할 수 있다. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango)) [SIG 클러스터 라이프사이클, 네트워크] - -#### 베타가 된 기능: - - StartupProbe ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx)) [SIG 노드, Scalability, 테스트] - -#### GA 된 기능: - - VolumePVCDataSource ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG 스토리지] - - TaintBasedEvictions ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, 앱, 노드, 스케줄링, 테스트] - - BlockVolume 및 CSIBlockVolume ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG 스토리지] - - 윈도우 RunAsUserName ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG 앱 및 윈도우] -- 이전 릴리스에서는 관련 기능이 무조건 활성화되었으므로, 다음 기능 게이트가 제거되었다. CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] - -### 기능 - -- (많은 요청으로 인한) API 요청량 제한이 이제 로그 레벨 2의 client-go 로그에 리포트 된다. 메시지는 `Throttling request took 1.50705208s, request: GET:` 형태이다. 이러한 메시지가 있으면 관리자에게 클러스터를 적절히 조정해야 함을 알릴 수 있다. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] -- FC 볼륨 플러그인에 마운트 옵션 지원이 추가된다. ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG 스토리지] -- 이용자 그룹(audience) 클레임의 spn: 접두사 없이 AAD 토큰을 가져올 수 있도록 azure 인증 모듈에 config-mode 플래그를 추가한다. 지정하지 않으면, 디폴트 동작이 변경되지 않는다. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, 인증, CLI, 클라우드 공급자] -- CoreDNS 레플리카 개수 설정을 허용한다. ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick)) [SIG 클러스터 라이프사이클] -- kubectl exec 호출 시 --filename 플래그를 사용하여 리소스를 지정할 수 있도록 허용 ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI, 테스트] -- Apiserver는 HTTP/2 클라이언트가 단일 apiserver에 갇히는 것을 방지하기 위해 그레이스풀(GOAWAY)하게 닫히게 하는 요청의 일부인 새로운 플래그 --goaway-chance를 추가했다. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] -- Azure 클라우드 공급자는 이제 쿠버네티스 클러스터와 다른 AAD 테넌트 및 구독에서 Azure 네트워크 리소스(가상 네트워크, 로드 밸런서, 퍼블릭 IP, 라우팅 테이블, 네트워크 보안 그룹 등) 사용을 지원한다. 이 기능을 사용하려면, 다음을 참고한다. https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md#host-network-resources-in-different-aad-tenant-and-subscription. ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG 클라우드 공급자] -- Azure VMSS/VMSSVM 클라이언트는 이제 스로틀링(throttling) 요청을 금지한다. ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- Azure 클라우드 공급자 캐시 TTL은 설정 가능하며, Azure 클라우드 공급자 목록은 다음과 같다. - - "availabilitySetNodesCacheTTLInSeconds" - - "vmssCacheTTLInSeconds" - - "vmssVirtualMachinesCacheTTLInSeconds" - - "vmCacheTTLInSeconds" - - "loadBalancerCacheTTLInSeconds" - - "nsgCacheTTLInSeconds" - - "routeTableCacheTTLInSeconds" - ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1)) [SIG 클라우드 공급자] -- Azure 글로벌 속도 제한(rate limit)은 클라이언트별로 전환된다. 새로운 속도 제한 설정 옵션이 도입되었고, 다음과 같다. routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit, VirtualMachineSizeRateLimit. 원래 속도 제한 옵션은 새 클라이언트의 속도 리미터(limiter)의 디폴트 값이다. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- Azure 네트워크 및 VM 클라이언트가 이제 스로틀링 요청을 금지한다. ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- Azure 스토리지 클라이언트가 이제 스로틀링 요청을 금지한다. ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- Azure: 단일 스택 IPv6에 대한 지원을 추가한다. ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG 클라우드 공급자] -- 스케줄러의 ComponentConfig에서 PodTopologySpread 플러그인에 대한 DefaultConstraints를 지정할 수 있다. ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링] -- VMSS 클러스터의 VM list 작업을 피하기 위해 DisableAvailabilitySetNodes가 추가되었다. vmType이 "vmss"이고 모든 노드(컨트롤 플레인 노드 포함)가 VMSS 가상 머신인 경우에만 사용해야 한다. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- Elasticsearch는 advertise 주소 자동 설정을 지원한다. ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클, Instrumentation] -- 엔드포인트슬라이스가 이제 디폴트로 활성화된다. 새로운 `EndpointSliceProxying` 기능 게이트는 kube-proxy가 엔드포인트슬라이스를 사용할지 여부를 결정하며, 디폴트로 비활성화되어 있다. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) [SIG 네트워크] -- Kube-proxy: iptables 프록시에 이중 스택 IPv4/IPv6 지원이 추가되었다. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) [SIG 네트워크] -- Kubeadm은 이제 kube-controller-manager에 대한 이중 스택 노드 cidr 마스크의 자동 계산을 지원한다. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) [SIG 클러스터 라이프사이클] -- Kubeadm: 잡(Job)을 배포하는 업그레이드된 헬스 체크를 추가한다. ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는 -클러스터를 생성할 수 있게 한다. "kubeadm alpha certs renew"을 사용하여 기존 ECDSA 인증서의 갱신도 지원되지만, 즉시 또는 업그레이드 중에 RSA와 ECDSA 알고리즘간에 전환하지는 않는다. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth 및 클러스터 라이프사이클] -- Kubeadm: JSON, YAML, Go 템플릿 및 JsonPath 형식으로 'kubeadm config images list' 커맨드의 구조화된 출력을 구현했다. ([#86810](https://github.com/kubernetes/kubernetes/pull/86810), [@bart0sh](https://github.com/bart0sh)) [SIG 클러스터 라이프사이클] -- Kubeadm: kubeconfig 인증서 갱신 시, 내장된 CA를 디스크의 CA와 동기화된 상태로 유지한다. ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: 같은 이름의 노드가 이미 존재하는 경우 클러스터에 조인하려는 노드를 거부한다. ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: kubeadm-flags.env에서 윈도우 특화된 kubelet 플래그를 지원한다. ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG 클러스터 라이프사이클, 윈도우] -- Kubeadm: 이미지를 가져오는 데 실패한 후 자동 재시도를 지원한다. ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- Kubeadm: 알 수 없는 k8s 버전이 전달되면 가장 근접한 알려진 etcd 버전으로 폴백(fallback) 업그레이드를 지원한다. ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- Kubectl/drain: 축출 비활성화(disable-eviction) 옵션을 추가한다. 축출이 지원되는 경우에도, 삭제하기 위해 강제로 드레인(drain)한다. 이것은 PodDisruptionBudgets 확인을 우회하므로 주의해서 사용해야 한다. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI] -- Kubectl/drain: skip-wait-for-delete-timeout 옵션을 추가한다. 파드의 `DeletionTimestamp`가 N초 보다 오래된 경우, 파드를 기다리는 것을 건너뛴다. 건너뛰려면 0초보다 커야 한다. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI] -- 사전 구성된 로드 밸런서의 Azure 클라우드 공급자에 `preConfiguredBackendPoolLoadBalancerTypes` 옵션이 추가됐다. 가능한 값: `""`, `"internal"`, `"external"`,`"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion)) [SIG 클라우드 공급자] -- PodTopologySpread 플러그인은 이제 스케줄링 결정을 할 때 terteringPod를 제외한다. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG 스케줄링] -- 클라우드 공급자/azure : 네트워크 보안 그룹은 이제 별도의 리소스 그룹에 있을 수 있다. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon)) [SIG 클라우드 공급자] -- SafeSysctlWhitelist: net.ipv4.ping_group_range를 추가한다. ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda)) [SIG 인증] -- 스케줄러 프레임워크 허용 플러그인은 이제 예약 플러그인 후 스케줄링 주기가 끝나는 시점에 플러그인이 실행된다. 바인딩 주기 시작 시 허가 대기 상태가 유지된다. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG 스케줄링] -- 스케줄러: DefaultBinder 플러그인을 추가한다. ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링, 테스트] -- TopologySpreadConstraints를 정의하는 파드에 대한 디폴트 스프레드 스코어링(spreading scoring) 플러그인을 건너뛴다. ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG 스케줄링] -- kubectl --dry-run 플래그는 이제 클라이언트-사이드와 서버-사이드의 dry-run 전략을 지원하기 위해 'client', 'server', 'none' 값을 허용한다. --dry-run 플래그의 boolean 값과 설정되지 않은 값은 사용 중단(deprecated)되었으며 향후 버전에서는 값이 필요하다. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI] -- apply, patch, create, run, annotate, label, set, autoscale, drain, rollout undo, 그리고 expose를 포함한 명령에 대해 --dry-run=server를 사용하여 kubectl에서 서버-사이드 dry-run을 지원한다. ([#87714](https://github.com/kubernetes/kubernetes/pull/87714), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, CLI, 테스트] -- --dry-run=server|client를 kubectl delete, taint, replace에 추가한다. ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI, 테스트] -- PodTopologySpread(기능 게이트 `EvenPodsSpread`) 기능은 1.18에서 디폴트로 활성화되었다. ([#88105](https://github.com/kubernetes/kubernetes/pull/88105), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG 스케줄링, 테스트] -- kubelet 및 디폴트 도커 런타임은 이제 대상 컨테이너의 리눅스 프로세스 네임스페이스에서 임시 컨테이너 실행을 지원한다. 다른 컨테이너 런타임은 이 기능에 대한 지원을 구현해야 해당 런타임에서 사용할 수 있다. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG 노드] -- `CPUManager` 상태 파일의 기본 형식이 변경되었다. 업그레이드는 원활해야 하지만, 이전 형식을 참조하는 써드파티 도구는 업데이트해야 한다. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska)) [SIG 노드, 테스트] -- CNI 버전을 v0.8.5로 업데이트한다. ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, 클러스터 라이프사이클, 네트워크, 릴리스, 테스트] -- Webhook은 네트워크 프록시를 알파 버전으로 지원한다. ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, 인증, 테스트] -- 클라이언트 인증서 파일이 제공되면, 새 연결을 위해 파일을 다시 로드하고 인증서가 변경되면 연결을 닫는다. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, 인증, 노드, 테스트] -- --force 플래그로 kubectl을 사용하여 오브젝트를 삭제할 때, 더 이상 --grace-period=0을 지정할 필요가 없다. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- GCE의 윈도우 노드는 컨트롤 플레인에 가상 TPM-기반 인증을 사용할 수 있다. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh)) [SIG 클러스터 라이프사이클] -- 이제 "--node-ip ::"를 kubelet에 전달하여 노드의 기본 주소로 사용할 IPv6 주소를 자동으로 감지해야 함을 나타낼 수 있다. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship)) [SIG 클라우드 공급자, 네트워크, 노드] -- `kubectl`은 이제 `kubectl alpha debug` 명령을 포함한다. 이 명령을 사용하면 디버깅 목적으로 임시 컨테이너를 실행 중인 파드에 연결할 수 있다. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI] -- kubeconfig 파일 및 kubectl의 --tls-server-name을 통해 TLS 서버 이름 재정의를 지정할 수 있다. ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, 인증, CLI] - -#### 메트릭: -- `rest_client_rate_limiter_duration_seconds` 메트릭을 컴포넌트 기반에 추가하여 클라이언트 사이드 속도 제한기(rate limiter) 지연(latency)을 초 단위로 추적한다. 동사(verb)와 URL로 분류된다. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, 클러스터 라이프사이클, Instrumentation] -- exec 인증에 대한 두 개의 클라이언트 인증서 메트릭을 추가했다. - - `rest_client_certificate_expiration_seconds`는 현재 클라이언트 인증서의 수명을 보고하는 측정기이다. UTC 1970년 1월 1일 이후 만료 시간을 초 단위로 보고한다. - - `rest_client_certificate_rotation_age`는 방금 교체한 클라이언트 인증서의 수명을 초 단위로 보고하는 히스토그램이다. ([#84382](https://github.com/kubernetes/kubernetes/pull/84382), [@sambdavidson](https://github.com/sambdavidson)) [SIG API Machinery, 인증, 클러스터 라이프사이클, Instrumentation] -- 컨트롤러 관리자는 작업큐 메트릭을 제공한다. ([#87967](https://github.com/kubernetes/kubernetes/pull/87967), [@zhan849](https://github.com/zhan849)) [SIG API Machinery] -- 다음의 메트릭 기능이 꺼져 있다. - - kubelet_pod_worker_latency_microseconds - - kubelet_pod_start_latency_microseconds - - kubelet_cgroup_manager_latency_microseconds - - kubelet_pod_worker_start_latency_microseconds - - kubelet_pleg_relist_latency_microseconds - - kubelet_pleg_relist_interval_microseconds - - kubelet_eviction_stats_age_microseconds - - kubelet_runtime_operations - - kubelet_runtime_operations_latency_microseconds - - kubelet_runtime_operations_errors - - kubelet_device_plugin_registration_count - - kubelet_device_plugin_alloc_latency_microseconds - - kubelet_docker_operations - - kubelet_docker_operations_latency_microseconds - - kubelet_docker_operations_errors - - kubelet_docker_operations_timeout - - network_plugin_operations_latency_microseconds ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango)) [SIG 네트워크, 노드] -- Kube-apiserver 메트릭은 이제 /healthz, /livez, /readyz 요청에 대한 요청 수, 대기 시간 및 응답 크기를 포함한다. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery] -- Kubelet은 이제 인증서 로테이션(rotation)을 수행할 수 없는 경우, `server_expiration_renew_failure` 및 `client_expiration_renew_failure` 메트릭 카운터를 제공한다. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips)) [SIG API Machinery, 인증, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation, 노드, 릴리스] -- Kubelet: 메트릭 process_start_time_seconds는 ALPHA 안정성 레벨로 표시된다. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, 클러스터 라이프사이클, Instrumentation, 노드] -- 헬스 상태가 좋지 않은 PLEG의 진단을 돕기 위한 새로운 메트릭 `kubelet_pleg_last_seen_seconds`를 추가한다. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham)) [SIG 노드] - -### 기타 (버그, 정리(Cleanup) or Flake(플레이크)) - -- 1.16 이상의 API 서버에 대해, 1.15 이전으로 클라이언트 회귀가 파드 상태의 podIP 또는 노드 명세의 podCIDR을 업데이트할 수 없었던 문제를 수정했다. ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG 앱, 네트워크] -- 롤링 업데이트 파티션에 대한 "kubectl describe statefulsets.apps" 출력 가비지를 수정했다. ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI] -- PV의 파일시스템이 디스크의 실제 파일시스템과 일치하지 않을 때 PV에 이벤트를 추가한다. ([#86982](https://github.com/kubernetes/kubernetes/pull/86982), [@gnufied](https://github.com/gnufied)) [SIG 스토리지] -- azure 디스크 WriteAccelerator 지원을 추가한다. ([#87945](https://github.com/kubernetes/kubernetes/pull/87945), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지] -- VM 인스턴스 업데이트를 위해 고 루틴(goroutines) 간 지연(delay)을 추가한다. ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG 클라우드 공급자] -- 클러스터 덤프 정보에 init 컨테이너 로그를 추가한다. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- 애드온 : elasticsearch 디스커버리는 IPv6를 지원한다. ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클, Instrumentation] -- PV 및 PVC에 "volume.beta.kubernetes.io/migrated-to" 어노테이션을 추가하면, PV 및 PVC가 마이그레이션되어 프로비저닝과 삭제를 위해 해당 오브젝트를 선택할 수 있도록 외부 프로비저너에 신호를 보낸다. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG 스토리지] -- 모든 api-server 로그 요청 라인은 grep으로 찾기 쉬운 형식으로 되어 있다. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp)) [SIG API Machinery] -- Azure VMSS LoadBalancerBackendAddressPools 업데이트는 순차적-동기(sequential-sync) + 동시-비동기(concurrent-async) 요청으로 개선되었다. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- Azure 클라우드 공급자는 이제 이용자 그룹 클레임에 spn: 접두사가 없는 AAD 토큰을 얻는다. ([#87590](https://github.com/kubernetes/kubernetes/pull/87590), [@weinong](https://github.com/weinong)) [SIG 클라우드 공급자] -- AzureFile 및 CephFS는 민감한 마운트 옵션의 로깅을 방지하는 새로운 마운트 라이브러리를 사용한다. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG 스토리지] -- 리눅스 노드와 윈도우 노드를 포함하는 쿠버네티스 클러스터에서 윈도우 스케줄링을 피하기 위해, dns-horizontal 컨테이너를 리눅스 노드에 바인딩한다. ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, 윈도우] -- 윈도우 스케줄링을 피하기 위해 kube-dns 컨테이너를 리눅스 노드에 바인딩한다. ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, 윈도우] -- 리눅스 노드와 윈도우 노드를 포함하는 쿠버네티스 클러스터에서 윈도우 스케줄링을 피하기 위해, metadata-agent 컨테이너를 리눅스 노드에 바인딩한다. ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, Instrumentation, 윈도우] -- 리눅스 노드와 윈도우 노드를 포함하는 쿠버네티스 클러스터에서 윈도우 스케줄링을 피하기 위해, metrics-server 컨테이너를 리눅스 노드에 바인딩한다. ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, Instrumentation, 윈도우] -- 버그 수정: 최신 패키지 노드를 포함해야 한다. #351 (@caseydavenport) ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera)) [SIG 클러스터 라이프사이클] -- CPU 상한(limit)은 이제 윈도우 컨테이너에 적용된다. 노드가 오버-프로비저닝된 경우, 가중치가 사용되지 않으며 상한만 고려된다. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG 노드, 테스트, 윈도우] -- COS 노드의 core_pattern을 절대 경로로 변경했다. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml)) [SIG 클러스터 라이프사이클, 노드] -- Client-go 인증서 관리자 교체는 발급된 인증서와 함께 선택적인 중급(intermediate)의 체인을 유지하는 기능을 얻었다. ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, 인증] -- 클라우드 공급자 설정인 CloudProviderBackoffMode가 더 이상 사용되지 않으므로 제거되었다. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- debian-hyperkube-base 이미지가 사용 중단되고 제거되므로 적합(Conformance) 이미지는 이제 stretch-slim에 의존한다. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG 클러스터 라이프사이클, 릴리스, 테스트] -- kubectl create 커맨드에서 --generator 플래그는 사용 중단(deprecated)됨 ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- 초기화 단계(preflight) 동안, kubeadm은 이제 conntrack 실행 파일이 있는지 확인한다. ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni)) [SIG 클러스터 라이프사이클] -- 엔드포인트슬라이스에는 파드 종료를 위한 엔드포인트가 없어야 한다. ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG 앱, 네트워크] -- 임시 저장 한도를 초과하는 파드로 인한 축출은 이제 `kubelet_evictions` 메트릭에 의해 기록되며 경고할 수 있다. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG 노드] -- kubectl이 널(null) 값을 잘못 거부하지 않도록 하기 위해 널 입력 가능(nullable), 필수/비필수 필드를 만들어 공개된 OpenAPI 스키마를 필터링한다. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- --shutdown-delay-duration이 경과하기 전에, 종료가 시작된 직후 오류를 반환하도록 /readyz를 수정한다. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] -- 감시(watch) 요청 처리 시 API Server 잠재적 메모리 누수 이슈를 수정한다. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] -- 엔드포인트슬라이스 컨트롤러 경합 조건(race condition)을 수정하고 엔드포인트슬라이스의 외부 변경을 처리하는지 확인한다. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott)) [SIG 앱, 네트워크] -- 순수한 ipv6 vsphere 환경에서 손실된 IPv6 주소 이슈를 수정한다. ([#86001](https://github.com/kubernetes/kubernetes/pull/86001), [@hubv](https://github.com/hubv)) [SIG 클라우드 공급자] -- 예기치 않은 LoadBalancer 업데이트가 발생하지 않도록 LoadBalancer 규칙 검사를 수정한다. ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- Kube-proxy에서 다른 IP 군으로 로드 밸런서를 사용할 때 다운되는 버그를 수정한다. ([#87117](https://github.com/kubernetes/kubernetes/pull/87117), [@aojea](https://github.com/aojea)) [SIG 네트워크] -- port-forward 버그 수정: 이름이 지정된 포트가 서비스와 작동하지 않는 문제를 수정한다. ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py)) [SIG CLI] -- 오래된 IPv6 엔드포인트가 정리되지 않은 이중 스택 IPVS 프록시의 버그를 수정한다. ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG 네트워크] -- orphan 리비전(revision)을 채택할 수 없고 스테이트풀셋(statefulset)을 동기화 할 수 없는 버그를 수정한다. ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli)) [SIG 앱] -- ExternalTrafficPolicy가 ExternalIP 서비스에 적용되지 않는 버그를 수정한다. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG 네트워크] -- kubenet이 tc 출력을 파싱(parse)하지 못하는 버그를 수정한다. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG 네트워크] -- 파드가 IP 주소를 얻지 못하게 하는 kubenet의 회귀 문제를 수정한다. ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs)) [SIG 네트워크, 노드] -- azure 파일 AuthorizationFailure를 수정한다. ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지] -- 엔드포인트슬라이스 컨트롤러가 공유 오브젝트를 수정하려고 하는 버그를 수정한다. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott)) [SIG API Machinery, 앱, 네트워크] -- aws-load-balancer-security-groups 어노테이션 처리 문제를 수정한다. 이 어노테이션이 할당된 보안 그룹은 더 이상 쿠버네티스에 의해 수정되지 않으며, 대부분의 사용자가 예상하는 동작이다. 이 어노테이션을 사용하면, 더 이상 불필요한 보안 그룹이 만들어지지 않는다. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG 클라우드 공급자] -- 부정확한 캐시로 인한 잘못된 VMSS 업데이트를 수정한다. ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG 클라우드 공급자] -- hostname의 종속성을 제거하여 윈도우 용 isCurrentInstance를 수정한다. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- LoadBalancer가 또다른 리소스 그룹에 지정된 경우 azure 클라우드 공급자에서 찾을 수 없는 리소스에 대한 이슈 #85805를 수정한다. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm)) [SIG 클라우드 공급자] -- local=true로 설정한 경우 kubectl annotate 오류를 수정한다. ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- kubectl create deployment 커맨드가 사용하는 이미지 이름을 수정한다. ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- `kubectl drain ignore` 데몬셋(daemonset) 및 기타 오류를 수정한다. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- 노드 이벤트에서 "involvedObject"에 대한 "apiVersion"이 누락되는 문제를 수정한다. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG 앱, 노드] -- azure 클라우드 공급자에서 nil 포인터 역참조를 수정한다. ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx)) [SIG 클라우드 공급자] -- 스테이트풀셋을 여러 번 적용하지 못하게 하는 스테이트풀셋 변환에서 회귀 문제를 수정 ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG 앱, 테스트] -- 여러 경로를 함께 업데이트 할 때 경로 충돌된 경로 업데이트 작업을 수정한다. ([#88209](https://github.com/kubernetes/kubernetes/pull/88209), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- 파드 볼륨 처리가 실패할 때 kubelet이 PVC/PV 오브젝트를 반복적으로 가져오는 것을 방지하도록 수정한다. 이렇게 하면 이 같은 오류 시나리오에서 API 서버로의 계속적인 연결시도(hammering)를 막을 수 있지만, 파드 볼륨 처리의 일부 오류가 재시도되기까지 최대 2-3분이 소요될 수 있다. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG 노드, 스토리지] -- DNS 레이블 서비스 어노테이션이 설정되지 않은 경우, PIP의 DNS가 삭제되는 버그를 수정한다. ([#87246] ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19)) [SIG 클라우드 공급자] -- 컨트롤 플레인을 사용할 수 없게 하는 etcd LIST에서 썬더링 허드(thundering herd)를 야기하는 컨트롤 플레인 호스트 롤링 업그레이드를 수정한다. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, 노드, 테스트] -- 수정: CSINode에 대한 azure 디스크 마이그레이션 지원을 추가한다. ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지] -- 수정: azure 클라이언트에서 다시 시도할 수 없는(non-retriable) 오류를 추가한다. ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자] -- 수정: azure 디스크 연결/해제 시 복구를 추가한다. ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자] -- 수정: azure 데이터 디스크는 기본적으로 os 디스크와 동일한 키를 사용해야 한다. ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자] -- 수정: azure 디스크를 Standard_DC4s/DC2s 인스턴스에 마운트할 수 없다. ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지] -- 수정: azure 파일 마운트 타임아웃 이슈를 해결한다. ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지] -- 수정: azure 디스크 전에 디스크 상태를 확인한다. ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자] -- 수정: csi 드라이버에서 손상된 마운트 포인트를 해결한다. ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG 스토리지] -- 수정: azure 디스크 lun 이슈를 해결한다. ([#88158](https://github.com/kubernetes/kubernetes/pull/88158), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지] -- 수정: azure 디스크 최대 개수를 업데이트한다. ([#88201](https://github.com/kubernetes/kubernetes/pull/88201), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지] -- AWS에서 "디바이스 X를 ​​요청했지만 Y를 찾음" 연결 오류를 수정했다. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane)) [SIG 클라우드 공급자, 스토리지] -- CIDR 범위를 벗어나면 `Except` 값이 허용되는 네트워크폴리시(NetworkPolicy) 유효성 검사를 수정했다. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG 네트워크] -- TopologyManager의 버그를 수정했다. 이전에는 컨테이너 생성이 직렬화된(serialized) 상황에서만 TopologyManager가 정렬을 보장했다. 이제는 컨테이너 생성의 모든 시나리오에서 정렬이 보장된다. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG 노드] -- 노드가 추가될 때 공급자 ID를 판별하는 중에 오류가 발생하면 공급자 ID가 노드에 대해 설정되지 않는 버그가 수정되었다. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs)) [SIG 앱, 클라우드 공급자] -- kubelet 이미지 관리자에서 스태틱(static) 파드 워커가 아무 경고 없이 작업을 중지시킬 수 있는 데이터 경합을 수정했다. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG 노드] -- kubelet이 파드 볼륨을 정리하는 문제를 수정했다. ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu)) [SIG 스토리지] -- kubelet이 파드의 준비(ready) 상태를 업데이트하지 못하는 회귀 문제를 수정했다. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu)) [SIG 노드] -- kubelet이 동시 파드 조정(reconciliation) 루프를 잘못 실행하여 충돌하는 문제를 수정했다. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG 노드] -- 타임아웃 후 블록 CSI 볼륨 정리 문제를 수정했다. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG 스토리지] -- 타임아웃 후 CSI 원시 블록 볼륨 정리 문제를 수정했다. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG 스토리지] -- AWS 클라우드 공급자가 프로비저닝하지 않은 LoadBalancer 보안 그룹을 삭제 시도하도록 수정했으며, `service.beta.kubernetes.io/aws-load-balancer-security-groups` 어노테이션이 있더라도 AWS 클라우드 공급자가 기본 LoadBalancer 보안 그룹을 생성하도록 수정했다. aws-load-balancer-security-groups의 의도된 동작은 로드 밸런서에 할당된 모든 보안 그룹을 바꾸는 것이다. ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919)) [SIG 클라우드 공급자] -- 두 개의 스케줄러 메트릭(pending_pods와 schedule_attempts_total)이 기록되지 않는 문제를 수정했다. ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG 스케줄링] -- 삭제/재생성된 파드에 대해 kubelet이 보고한(kubelet-reported) 파드 상태와 관련된 이슈를 수정했다. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt)) [SIG 노드] -- 커스텀 리소스의 no-op 패치 또는 업데이트 시 metadata.generation의 증가를 야기하는 멀티-버전 커스텀 리소스의 변환(conversion) 오류를 수정했다. ([#88995](https://github.com/kubernetes/kubernetes/pull/88995), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] -- kubectl이 획득한 AAD 토큰이 on-behalf-of flow 및 oidc와 호환되지 않는 문제를 수정했다. 이 수정 이전의 이용자 그룹은 "spn:" 접두사를 가진다. 이 수정 후에는 "spn:" 접두사가 생략된다. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong)) [SIG API Machinery, 인증, 클라우드 공급자] -- c2, n2, m1, m2 머신 유형에 15개 이상의 GCE 퍼시스턴트(Persistent) 디스크를 연결할 수 없는 문제를 수정했다. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG 스토리지] -- 윈도우에서 엔드포인트슬라이스 기능 게이트를 활성화할 때 kube-proxy가 지원하도록 수정한다. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott)) [SIG 인증, 네트워크] -- 클라이언트 인증서 교체 사례에서 kubelet이 크래시되는 이슈를 수정한다. ([#88079](https://github.com/kubernetes/kubernetes/pull/88079), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 인증, 노드] -- 서비스 어카운트(service account) 토큰 컨트롤러를 실행하지 않는 클러스터에서 서비스 어카운트 토큰 승인 오류를 수정한다. ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt)) [SIG 인증] -- 65536개의 IP 주소보다 큰 IPv4 범위를 사용하여 --service-cluster-ip-range 처리 중 v1.17.0 회귀 문제를 수정한다. ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt)) [SIG 네트워크] -- 네트워크 폴리시(NetworkPolicy) PolicyTypes의 잘못된 유효성 검사 결과를 수정한다. ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn)) [SIG 네트워크] -- 하위 프로토콜 교섭(negotiation)의 경우 클라이언트 및 서버 프로토콜이 모두 필요하다. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu)) [SIG API Machinery, 노드] -- 여러 노드에서 연결을 허용하는 볼륨의 경우 이제 다른 노드에서 연결 및 분리 작업이 병렬로 실행된다. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG 스토리지] -- 분리(orphan) 전파 정책으로 스테이트풀셋이 삭제되면 가비지 수집기가 ControllerRevisions를 올바르게 분리할 수 있다. ([#84984](https://github.com/kubernetes/kubernetes/pull/84984), [@cofyc](https://github.com/cofyc)) [SIG 앱] -- `Get-kube.sh`는 공급자가 메타데이터 서버 기본값 대신 GCE 또는 GKE 인 경우, 인증을 위해 gcloud의 현재 로컬 GCP 서비스 계정을 사용한다. ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG 클러스터 라이프사이클] -- CVE-2020-9283에 대한 수정 사항을 제공하도록 Golang/x/net이 업데이트되었다. ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation] -- 서빙 인증서(serving certificate)의 파라미터가 SNI 인증서의 IP인 이름을 지정하면 서버 연결에 응답하는 데 우선 순위가 부여된다. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k)) [SIG API Machinery] -- yaml 파싱 성능을 개선했다. ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen)) [SIG API Machinery, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation, 노드] -- 노드 인증자(authorizer)의 성능을 개선한다. ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG 인증] -- GKE 알파 클러스터에서는 서비스 어노테이션 `cloud.google.com/network-tier: Standard`를 사용할 수 있다. ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG 클라우드 공급자] -- CSI 퍼시스턴트 볼륨을 설명할 때 FSType을 포함한다. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca)) [SIG CLI, 스토리지] -- Iptables/유저스페이스(userspace) 프록시: 모든 외부 IP 대신, 동기화 루프 당 하나씩 로컬 주소를 가져옴으로써 성능을 개선한다 ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation , 네트워크] -- Kube-aggregator: 항상 서비스의 현재 상태를 반영하기 위해 unavailableGauge 메트릭을 설정한다. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery] -- Kube-apiserver: gracePeriodSeconds=0 및 resourceVersion 전제 조건(precondition)이 있는 파드를 삭제하는 중에 발생하는 충돌 오류를 수정했다. ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery] -- Kube-proxy가 더 이상 공유 엔드포인트슬라이스를 수정하지 않는다. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott)) [SIG 네트워크] -- Kube-proxy: 이중 스택 모드에서 엔드포인트의 IP Family를 얻을 수 없는 경우, 주소가 없는 엔드포인트에 대한 로그가 넘치지 않도록 경고 대신 InfoV(4) 레벨로 로그를 남긴다. ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG 네트워크] -- Kubeadm을 사용하면 이중 스택이 활성화된 경우 단일 스택 클러스터를 구성할 수 있다. ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, 클러스터 라이프사이클, 네트워크] -- Kubeadm에 이제 CoreDNS 버전 1.6.7이 포함된다. ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG 클러스터 라이프사이클] -- Kubeadm 업그레이드는 항상 스택에 대한 etcd 백업을 유지한다. ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- Kubeadm: 'kubeadm alpha kubelet config download'가 제거되었다. 대신 'kubeadm upgrade node phase kubelet-config'를 사용한다. ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- Kubeadm: 클러스터 이름을 controller-manager 인수(argument)로 포워딩한다. ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre)) [SIG 클러스터 라이프사이클] -- Kubeadm: 더 이상 존재하지 않는 "ci-cross/*" 대신 "ci/k8s-master" 버전 레이블 지원을 추가한다. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu)) [SIG 클러스터 라이프사이클] -- Kubeadm: 동시 etcd 멤버 조인에 대한 잠정 지원을 추가로 개선한다. 여러 구성원이 동일한 호스트 이름을 받을 수 있는 버그를 수정한다. etcd 클라이언트 다이얼 타임아웃을 늘리고 추가/제거/... 작업에 대한 타임아웃을 다시 시도한다. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: "upgrade apply"에 kubelet 환경 파일을 쓰지 않도록 한다. ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa)) [SIG 클러스터 라이프사이클] -- Kubeadm: 손상된 kubelet.conf 파일로 "kubeadm reset"을 실행할 때 발생할 수 있는 문제를 수정한다. ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: 단일 노드 클러스터에서 'kubeadm upgrade'가 멈추는 버그를 수정한다. ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- Kubeadm: 태그가 변경되지 않았지만 내용이 변경된 경우에도 이미지를 미리 가져오도록 한다. ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) [SIG 클러스터 라이프사이클] -- Kubeadm: v1.15에서 사용 중단(deprecated) 되었으므로 'kubeadm upgrade node config' 명령을 제거한다. 대신 'kubeadm upgrade node phase kubelet-config'를 사용한다. ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클] -- Kubeadm: 사용 중단된 CoreDNS 기능-게이트(feature-gate)를 제거한다. 기능이 GA로 전환된 v1.11 이후부터 'true'로 설정되었다. v1.13에서는 CLI에서 사용 중단(deprecated) 및 히든(hidden)으로 표시되었다. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: apiserver가 응답하지 않으면 `kubeadm-config` 컨피그맵 생성 또는 변경(mutation)을 다시 시도한다. 이것은 새로운 컨트롤 플레인 노드에 조인할 때 복원력을 향상시킨다. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre)) [SIG 클러스터 라이프사이클] -- Kubeadm: kubeconfig 파일에서 인증 기관(certificate authority) PEM 데이터의 유효성을 검사할 때 공백을 허용한다. ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: bind-address 옵션을 사용하여 kube-controller-manager 및 kube-scheduler http 프로브(probe)를 구성한다. ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea)) [SIG 클러스터 라이프사이클] -- Kubeadm: api-server AdvertiseAddress IP family를 사용하여 비 외부(non external) etcd 클러스터에 대한 etcd 엔드포인트 IP family를 선택한다. ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea)) [SIG 클러스터 라이프사이클] -- kubectl cluster-info dump --output-directory=xxx 는 이제 출력 형식에 따라 확장자가 있는 파일을 생성한다. ([#82070](https://github.com/kubernetes/kubernetes/pull/82070), [@olivierlemasle](https://github.com/olivierlemasle)) [SIG CLI] -- `kubectl describe ` 및 `kubectl top pod`는 표시할 결과가 없는 경우 `"No resources found"` 또는 `"No resources found in namespace"` 라는 메시지를 반환한다. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- `kubectl drain node --dry-run`은 축출되거나 삭제될 파드를 나열한다. ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom)) [SIG CLI] -- `kubectl set resources`는 리소스에 대한 빈(empty) 변경 사항을 전달하면 더 이상 오류를 반환하지 않는다. `kubectl set subject`는 리소스에 대한 빈 변경 사항을 전달하면 더 이상 오류를 반환하지 않는다. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) [SIG CLI] -- metrics-server 또는 prometheus를 통해 수집한 Kubelet 메트릭은 더 이상 3개 이상의 파드를 실행하는 윈도우 노드에 대해 타임아웃되지 않아야 한다. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG 노드, 테스트, 윈도우] -- kubelet 메트릭이 버킷(bucket)으로 변경되었다. 예를 들어 `exec/{podNamespace}/{podID}/{containerName}`은 이제 exec 일뿐이다. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG 노드] -- kubelet은 API 서버에서 불필요한 파드 상태 업데이트 작업을 줄인다. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG 노드, 확장성] -- 쿠버네티스는 매초가 아닌 5초 동안 100 msec마다 iptables 잠금을 획득하려고 시도한다. 이는 이탈률이 높은 iptables 모드에서 kube-proxy를 사용하는 환경에 특히 유용하다. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea)) [SIG 네트워크] -- GCE 대상 풀에 대한 단일 업데이트의 인스턴스 수를 1000으로 제한한다. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG 클라우드 공급자, Network, 확장성] -- Azure 클라이언트가 지정된 HTTP 상태 코드에서만 다시 시도한다. ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- 오류 메시지 및 서비스 이벤트 메시지를 보다 명확하게 만든다. ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- externalTrafficPolicy가 로컬로 설정된 경우 AWS NLB 헬스 체크 타임아웃을 최소화한다. ([#73363](https://github.com/kubernetes/kubernetes/pull/73363), [@kellycampbell](https://github.com/kellycampbell)) [SIG 클라우드 공급자] -- Pause 이미지에 non-amd64 이미지의 "Architecture"가 포함된다. ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG 릴리스] -- kubelet 및 kubeadm에서 pause 이미지가 3.2로 업그레이드되었다. ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder)) [SIG CLI, 클러스터 라이프사이클, 노드, 테스트] -- 스케줄러를 실행할 때 플러그인/PluginConfig 및 정책 API는 상호 배타적이다. ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링] -- `PreScore` 인터페이스에서 `FilteredNodesStatuses` 인수를 제거한다. ([#88189](https://github.com/kubernetes/kubernetes/pull/88189), [@skilxn-go](https://github.com/skilxn-go)) [SIG 스케줄링, 테스트] -- 노드 인증자(node authorizer) 인덱스 유지보수에서 성능 문제를 해결했다. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG 인증] -- v1.17.0-rc.1에서 승인(admission), 인증(authentication) 및 권한(authorization) 웹훅(webhook) 성능의 회귀를 해결했다. ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 테스트] -- `kubectl get all` 과 `NewDiscoveryClientForConfig` 또는 `NewDiscoveryClientForConfigOrDie`를 사용하여 구성된 client-go 디스커버리 클라이언트에서 성능 회귀를 해결했다. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] -- oidc claim spn: 접두사가 생략되어 기존 Azure AD OIDC 활성화된 api-server와의 동작이 중단되는 kubectl azure 인증 모듈 변경을 되돌렸다. ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, 인증, 클라우드 공급자] -- 공유 정보 제공자(Shared informers)는 이제 네트워크 중단 시에 더 안정적이다. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery] -- 동일한 플러그인에 대해 PluginConfig를 두 번 이상 지정하면 스케줄러 시작을 실패한다. -  Extender 지정 및 NodeResourcesFit 플러그인에 대한 .ignoredResources 구성이 실패된다. ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링] -- restartPolicy=Never 파드의 종료(terminate)가 실제로 실패했을 때 더 이상 파드가 성공했다고 보고할 수 없다. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG 노드, 테스트] -- CSR 서명 인증서/키 페어는 kube-apiserver 인증서/키 페어와 같이 디스크에서 다시 로드된다. ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, 앱, 인증] -- k8s.io/client-go/tools/events의 EventRecorder는 관련 오브젝트에 설정되어 있지 않은 경우 (kube-system 대신) 디폴트 네임스페이스에 이벤트를 생성한다. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery] -- 이제 감사(audit) 이벤트 소스 IP 목록은 요청을 API 서버로 보낸 IP로 항상 끝난다. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery, 인증] -- 쿠버네티스 v1.17.0 샘플 apiserver를 사용하도록 sample-apiserver 집계 적합성 테스트가 업데이트되었다. ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 아키텍처, CLI, 테스트] -- 스로틀링 가능성을 줄이기 위해, Azure 노드 프로비저닝 상태가 삭제될 때 VM 캐시가 nil로 설정된다. ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자] -- VMSS 캐시가 추가되어 VMSS GET 스로틀링 가능성이 감소한다. ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19)) [SIG 클라우드 공급자] -- 윈도우 노드에서 10초 이내로 kubelet 및 kube-proxy가 준비될 때까지 대기한다. ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031)) [SIG 클러스터 라이프사이클] -- `kubectl apply -f --prune -n ​​`는 cli 지정 네임스페이스에서 파일에 정의되지 않은 모든 리소스를 제거(prune)해야 한다. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu)) [SIG CLI] -- `kubectl create clusterrolebinding`는 rbac.authorization.k8s.io/v1 오브젝트를 생성한다. ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI] -- `kubectl diff`는 이제 diff가 변경 내역을 찾은 경우에만 1을, kubectl 오류에서는 >1을 반환한다. "exit status code 1" 메시지도 뮤트(mute)되었다. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI, 테스트] - -## 의존성(Dependencies) - -- v3.8.4로 칼리코(Calico) 업데이트 ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera))[SIG 클러스터 라이프사이클] -- v1.28.2로 aws-sdk-go 의존성 업데이트 ([#87253](https://github.com/kubernetes/kubernetes/pull/87253), [@SaranBalaji90](https://github.com/SaranBalaji90))[SIG API Machinery, 클라우드 공급자] -- v0.8.5로 CNI 버전 업데이트 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus))[SIG 릴리스, 테스트, 네트워크, 클러스터 라이프사이클, API Machinery] -- v1.17.0으로 cri-tools 업데이트 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert))[SIG 릴리스, 클러스터 라이프사이클] -- kubelet 및 kubeadm에서 Pause 이미지가 3.2로 업그레이드 ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, 노드, 테스트, 클러스터 라이프사이클] -- kubeadm에서 1.6.7로 CoreDNS 버전 업데이트 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep))[SIG 클러스터 라이프사이클] -- CVE-2020-9283을 수정하기 위해 golang.org/x/crypto를 업데이트 ([#8838](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, Instrumentation, API Machinery, 클러스터 라이프사이클, 클라우드 공급자] -- 1.13.8로 Go 업데이트 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov))[SIG 릴리스, 테스트] -- 1.18.0으로 Cluster-Autoscaler 업데이트 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk))[SIG 오토스케일링, 클러스터 라이프사이클] - - - -# v1.18.0-rc.1 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.18.0-rc.1 - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes.tar.gz) | `c17231d5de2e0677e8af8259baa11a388625821c79b86362049f2edb366404d6f4b4587b8f13ccbceeb2f32c6a9fe98607f779c0f3e1caec438f002e3a2c8c21` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-src.tar.gz) | `e84ffad57c301f5d6e90f916b996d5abb0c987928c3ca6b1565f7b042588f839b994ca12c43fc36f0ffb63f9fabc15110eb08be253b8939f49cd951e956da618` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-386.tar.gz) | `1aea99923d492436b3eb91aaecffac94e5d0aa2b38a0930d266fda85c665bbc4569745c409aa302247df3b578ce60324e7a489eb26240e97d4e65a67428ea3d1` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-amd64.tar.gz) | `07fa7340a959740bd52b83ff44438bbd988e235277dad1e43f125f08ac85230a24a3b755f4e4c8645743444fa2b66a3602fc445d7da6d2fc3770e8c21ba24b33` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-386.tar.gz) | `48cebd26448fdd47aa36257baa4c716a98fda055bbf6a05230f2a3fe3c1b99b4e483668661415392190f3eebb9cb6e15c784626b48bb2541d93a37902f0e3974` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-amd64.tar.gz) | `c3a5fedf263f07a07f59c01fea6c63c1e0b76ee8dc67c45b6c134255c28ed69171ccc2f91b6a45d6a8ec5570a0a7562e24c33b9d7b0d1a864f4dc04b178b3c04` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm.tar.gz) | `a6b11a55bd38583bbaac14931a6862f8ce6493afe30947ba29e5556654a571593358278df59412bbeb6888fa127e9ae4c0047a9d46cb59394995010796df6b14` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm64.tar.gz) | `9e15331ac8010154a9b64f5488969fc8ee2f21059639896cb84c5cf4f05f4c9d1d8970cb6f9831de6b34013848227c1972c12a698d07aac1ecc056e972fe6f79` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-ppc64le.tar.gz) | `f828fe6252678de9d4822e482f5873309ae9139b2db87298ab3273ce45d38aa07b6b9b42b76c140705f27ba71e101d58b43e59ac7259d7c08dc647ea809e207c` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-s390x.tar.gz) | `19da4b45f0666c063934af616f3e7ed3caa99d4ee1e46d53efadc7a8a4d38e43a36ced7249acd7ad3dcc4b4f60d8451b4f7ec7727e478ee2fadd14d353228bce` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-386.tar.gz) | `775c9afb6cb3e7c4ba53e9f48a5df2cf207234a33059bd74448bc9f177dd120fb3f9c58ab45048a566326acc43bc8a67e886e10ef99f20780c8f63bb17426ebd` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-amd64.tar.gz) | `208d2595a5b57ac97aac75b4a2a6130f0c937f781a030bde1a432daf4bc51f2fa523fca2eb84c38798489c4b536ee90aad22f7be8477985d9691d51ad8e1c4dc` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-amd64.tar.gz) | `dcf832eae04f9f52ff473754ef5cfe697b35f4dc1a282622c94fa10943c8c35f4a8777a0c58c7de871c3c428c8973bf72d6bcd8751416d4c682125268b8fcefe` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm.tar.gz) | `a04e34bea28eb1c8b492e8b1dd3c0dd87ebee71a7dbbef72be10a335e553361af7e48296e504f9844496b04e66350871114d20cfac3f3b49550d8be60f324ba3` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm64.tar.gz) | `a6af086b07a8c2e498f32b43e6511bf6a5e6baf358c572c6910c8df17cd6cae94f562f459714fcead1595767cb14c7f639c5735f1411173bbd38d5604c082a77` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-ppc64le.tar.gz) | `5a960ef5ba0c255f587f2ac0b028cd03136dc91e4efc5d1becab46417852e5524d18572b6f66259531ec6fea997da3c4d162ac153a9439672154375053fec6c7` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-s390x.tar.gz) | `0f32c7d9b14bc238b9a5764d8f00edc4d3bf36bcf06b340b81061424e6070768962425194a8c2025c3a7ffb97b1de551d3ad23d1591ae34dd4e3ba25ab364c33` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-amd64.tar.gz) | `27d8955d535d14f3f4dca501fd27e4f06fad84c6da878ea5332a5c83b6955667f6f731bfacaf5a3a23c09f14caa400f9bee927a0f269f5374de7f79cd1919b3b` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm.tar.gz) | `0d56eccad63ba608335988e90b377fe8ae978b177dc836cdb803a5c99d99e8f3399a666d9477ca9cfe5964944993e85c416aec10a99323e3246141efc0b1cc9e` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm64.tar.gz) | `79bb9be66f9e892d866b28e5cc838245818edb9706981fab6ccbff493181b341c1fcf6fe5d2342120a112eb93af413f5ba191cfba1ab4c4a8b0546a5ad8ec220` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-ppc64le.tar.gz) | `3e9e2c6f9a2747d828069511dce8b4034c773c2d122f005f4508e22518055c1e055268d9d86773bbd26fbd2d887d783f408142c6c2f56ab2f2365236fd4d2635` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-s390x.tar.gz) | `4f96e018c336fa13bb6df6f7217fe46a2b5c47f806f786499c429604ccba2ebe558503ab2c72f63250aa25b61dae2d166e4b80ae10f6ab37d714f87c1dcf6691` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-windows-amd64.tar.gz) | `ab110d76d506746af345e5897ef4f6993d5f53ac818ba69a334f3641047351aa63bfb3582841a9afca51dd0baff8b9010077d9c8ec85d2d69e4172b8d4b338b0` - -## Changelog since v1.18.0-beta.2 - -## Changes by Kind - -### API Change - -- Removes ConfigMap as suggestion for IngressClass parameters ([#89093](https://github.com/kubernetes/kubernetes/pull/89093), [@robscott](https://github.com/robscott)) [SIG Network] - -### Other (Bug, Cleanup or Flake) - -- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network] -- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network] -- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider] -- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fixed a data race in kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node] -- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node] -- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network] -- Update Cluster Autoscaler to 1.18.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk)) [SIG Autoscaling and Cluster Lifecycle] - - -# v1.18.0-beta.2 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.18.0-beta.2 - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes.tar.gz) | `3017430ca17f8a3523669b4a02c39cedfc6c48b07281bc0a67a9fbe9d76547b76f09529172cc01984765353a6134a43733b7315e0dff370bba2635dd2a6289af` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-src.tar.gz) | `c5fd60601380a99efff4458b1c9cf4dc02195f6f756b36e590e54dff68f7064daf32cf63980dddee13ef9dec7a60ad4eeb47a288083fdbbeeef4bc038384e9ea` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-386.tar.gz) | `7e49ede167b9271d4171e477fa21d267b2fb35f80869337d5b323198dc12f71b61441975bf925ad6e6cd7b61cbf6372d386417dc1e5c9b3c87ae651021c37237` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | `3f5cdf0e85eee7d0773e0ae2df1c61329dea90e0da92b02dae1ffd101008dc4bade1c4951fc09f0cad306f0bcb7d16da8654334ddee43d5015913cc4ac8f3eda` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-386.tar.gz) | `b67b41c11bfecb88017c33feee21735c56f24cf6f7851b63c752495fc0fb563cd417a67a81f46bca091f74dc00fca1f296e483d2e3dfe2004ea4b42e252d30b9` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | `1fef2197cb80003e3a5c26f05e889af9d85fbbc23e27747944d2997ace4bfa28f3670b13c08f5e26b7e274176b4e2df89c1162aebd8b9506e63b39b311b2d405` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm.tar.gz) | `84e5f4d9776490219ee94a84adccd5dfc7c0362eb330709771afcde95ec83f03d96fe7399eec218e47af0a1e6445e24d95e6f9c66c0882ef8233a09ff2022420` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | `ba613b114e0cca32fa21a3d10f845aa2f215d3af54e775f917ff93919f7dd7075efe254e4047a85a1f4b817fc2bd78006c2e8873885f1208cbc02db99e2e2e25` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | `502a6938d8c4bbe04abbd19b59919d86765058ff72334848be4012cec493e0e7027c6cd950cf501367ac2026eea9f518110cb72d1c792322b396fc2f73d23217` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | `c24700e0ed2ef5c1d2dd282d638c88d90392ae90ea420837b39fd8e1cfc19525017325ccda71d8472fdaea174762208c09e1bba9bbc77c89deef6fac5e847ba2` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-386.tar.gz) | `0d4c5a741b052f790c8b0923c9586ee9906225e51cf4dc8a56fc303d4d61bb5bf77fba9e65151dec7be854ff31da8fc2dcd3214563e1b4b9951e6af4aa643da4` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | `841ef2e306c0c9593f04d9528ee019bf3b667761227d9afc1d6ca8bf1aa5631dc25f5fe13ff329c4bf0c816b971fd0dec808f879721e0f3bf51ce49772b38010` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | `b373df2e6ef55215e712315a5508e85a39126bd81b7b93c6b6305238919a88c740077828a6f19bcd97141951048ef7a19806ef6b1c3e1772dbc45715c5fcb3af` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm.tar.gz) | `b8103cb743c23076ce8dd7c2da01c8dd5a542fbac8480e82dc673139c8ee5ec4495ca33695e7a18dd36412cf1e18ed84c8de05042525ddd8e869fbdfa2766569` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | `8f8f05cf64fb9c8d80cdcb4935b2d3e3edc48bdd303231ae12f93e3f4d979237490744a11e24ba7f52dbb017ca321a8e31624dcffa391b8afda3d02078767fa0` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | `b313b911c46f2ec129537407af3f165f238e48caeb4b9e530783ffa3659304a544ed02bef8ece715c279373b9fb2c781bd4475560e02c4b98a6d79837bc81938` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | `a1b6b06571141f507b12e5ef98efb88f4b6b9aba924722b2a74f11278d29a2972ab8290608360151d124608e6e24da0eb3516d484cb5fa12ff2987562f15964a` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | `20e02ca327543cddb2568ead3d5de164cbfb2914ab6416106d906bf12fcfbc4e55b13bea4d6a515e8feab038e2c929d72c4d6909dfd7881ba69fd1e8c772ab99` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm.tar.gz) | `ecd817ef05d6284f9c6592b84b0a48ea31cf4487030c9fb36518474b2a33dad11b9c852774682e60e4e8b074e6bea7016584ca281dddbe2994da5eaf909025c0` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | `0020d32b7908ffd5055c8b26a8b3033e4702f89efcfffe3f6fcdb8a9921fa8eaaed4193c85597c24afd8c523662454f233521bb7055841a54c182521217ccc9d` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | `e065411d66d486e7793449c1b2f5a412510b913bf7f4e728c0a20e275642b7668957050dc266952cdff09acc391369ae6ac5230184db89af6823ba400745f2fc` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | `082ee90413beaaea41d6cbe9a18f7d783a95852607f3b94190e0ca12aacdd97d87e233b87117871bfb7d0a4b6302fbc7688549492a9bc50a2f43a5452504d3ce` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | `fb5aca0cc36be703f9d4033eababd581bac5de8399c50594db087a99ed4cb56e4920e960eb81d0132d696d094729254eeda2a5c0cb6e65e3abca6c8d61da579e` - -## Changelog since v1.18.0-beta.1 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - -- `kubectl` no longer defaults to `http://localhost:8080`. If you own one of these legacy clusters, you are *strongly- encouraged to secure your server. If you cannot secure your server, you can set `KUBERNETES_MASTER` if you were relying on that behavior and you're a client-go user. Set `--server`, `--kubeconfig` or `KUBECONFIG` to make it work in `kubectl`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing] - -## Changes by Kind - -### Deprecation - -- AlgorithmSource is removed from v1alpha2 Scheduler ComponentConfig ([#87999](https://github.com/kubernetes/kubernetes/pull/87999), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- Kube-proxy: deprecate `--healthz-port` and `--metrics-port` flag, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network] -- Kubeadm: deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - -### API Change - -- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing] -- Added GenericPVCDataSource feature gate to enable using arbitrary custom resources as the data source for a PVC. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage] -- Allow user to specify fsgroup permission change policy for pods ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage] -- BlockVolume and CSIBlockVolume features are now GA. ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Apps, Node and Storage] -- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing] -- Fixes a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network] -- Ingress: Add Exact and Prefix maching to Ingress PathTypes ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network] -- Ingress: Add alternate backends via TypedLocalObjectReference ([#88775](https://github.com/kubernetes/kubernetes/pull/88775), [@cmluciano](https://github.com/cmluciano)) [SIG Apps and Network] -- Ingress: allow wildcard hosts in IngressRule ([#88858](https://github.com/kubernetes/kubernetes/pull/88858), [@cmluciano](https://github.com/cmluciano)) [SIG Network] -- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver. Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling] -- Move TaintBasedEvictions feature gates to GA ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing] -- New flag --endpointslice-updates-batch-period in kube-controller-manager can be used to reduce number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network] -- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing] -- The apiserver/v1alph1#EgressSelectorConfiguration API is now beta. ([#88502](https://github.com/kubernetes/kubernetes/pull/88502), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery] -- The storage.k8s.io/CSIDriver has moved to GA, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, Apps, Auth, Node, Scheduling, Storage and Testing] -- VolumePVCDataSource moves to GA in 1.18 release ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Apps, CLI and Cluster Lifecycle] - -### Feature - -- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. - After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. - The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. - Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] -- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] -- DefaultConstraints can be specified for the PodTopologySpread plugin in the component config ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows] -- Kubectl cluster-info dump changed to only display a message telling you the location where the output was written when the output is not standard output. ([#88765](https://github.com/kubernetes/kubernetes/pull/88765), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Print NotReady when pod is not ready based on its conditions. ([#88240](https://github.com/kubernetes/kubernetes/pull/88240), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Scheduler Extender API is now located under k8s.io/kube-scheduler/extender ([#88540](https://github.com/kubernetes/kubernetes/pull/88540), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing] -- Signatures on scale client methods have been modified to accept `context.Context` as a first argument. Signatures of Get, Update, and Patch methods have been updated to accept GetOptions, UpdateOptions and PatchOptions respectively. ([#88599](https://github.com/kubernetes/kubernetes/pull/88599), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, Apps, Autoscaling and CLI] -- Signatures on the dynamic client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88906](https://github.com/kubernetes/kubernetes/pull/88906), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, CLI, Cluster Lifecycle, Storage and Testing] -- Signatures on the metadata client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88910](https://github.com/kubernetes/kubernetes/pull/88910), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] -- Webhooks will have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing] -- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing] -- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI] - -### Documentation - -- Update Japanese translation for kubectl help ([#86837](https://github.com/kubernetes/kubernetes/pull/86837), [@inductor](https://github.com/inductor)) [SIG CLI and Docs] -- `kubectl plugin` now prints a note how to install krew ([#88577](https://github.com/kubernetes/kubernetes/pull/88577), [@corneliusweig](https://github.com/corneliusweig)) [SIG CLI] - -### Other (Bug, Cleanup or Flake) - -- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with squential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- AzureFile and CephFS use new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage] -- Build: Enable kube-cross image-building on K8s Infra ([#88562](https://github.com/kubernetes/kubernetes/pull/88562), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] -- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth] -- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing] -- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- FIX: prevent apiserver from panicking when failing to load audit webhook config file ([#88879](https://github.com/kubernetes/kubernetes/pull/88879), [@JoshVanL](https://github.com/JoshVanL)) [SIG API Machinery and Auth] -- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] -- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network] -- Fix describe ingress annotations not sorted. ([#88394](https://github.com/kubernetes/kubernetes/pull/88394), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider] -- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node] -- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage] -- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] -- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node] -- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Node and Storage] -- Fixes issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage] -- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Apps, Node and Storage] -- Hide kubectl.kubernetes.io/last-applied-configuration in describe command ([#88758](https://github.com/kubernetes/kubernetes/pull/88758), [@soltysh](https://github.com/soltysh)) [SIG Auth and CLI] -- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider] -- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability] -- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Specifying PluginConfig for the same plugin more than once fails scheduler startup. - - Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI] -- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing] -- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery] -- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth] -- Update to use golang 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Release and Testing] -- Validate kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout ([#88657](https://github.com/kubernetes/kubernetes/pull/88657), [@chendotjs](https://github.com/chendotjs)) [SIG Network] - - -# v1.18.0-beta.1 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.18.0-beta.1 - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes.tar.gz) | `7c182ca905b3a31871c01ab5fdaf46f074547536c7975e069ff230af0d402dfc0346958b1d084bd2c108582ffc407484e6a15a1cd93e9affbe34b6e99409ef1f` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-src.tar.gz) | `d104b8c792b1517bd730787678c71c8ee3b259de81449192a49a1c6e37a6576d28f69b05c2019cc4a4c40ddeb4d60b80138323df3f85db8682caabf28e67c2de` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-386.tar.gz) | `bc337bb8f200a789be4b97ce99b9d7be78d35ebd64746307c28339dc4628f56d9903e0818c0888aaa9364357a528d1ac6fd34f74377000f292ec502fbea3837e` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | `38dfa5e0b0cfff39942c913a6bcb2ad8868ec43457d35cffba08217bb6e7531720e0731f8588505f4c81193ce5ec0e5fe6870031cf1403fbbde193acf7e53540` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-386.tar.gz) | `8e63ec7ce29c69241120c037372c6c779e3f16253eabd612c7cbe6aa89326f5160eb5798004d723c5cd72d458811e98dac3574842eb6a57b2798ecd2bbe5bcf9` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | `c1be9f184a7c3f896a785c41cd6ece9d90d8cb9b1f6088bdfb5557d8856c55e455f6688f5f54c2114396d5ae7adc0361e34ebf8e9c498d0187bd785646ccc1d0` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm.tar.gz) | `8eab02453cfd9e847632a774a0e0cf3a33c7619fb4ced7f1840e1f71444e8719b1c8e8cbfdd1f20bb909f3abe39cdcac74f14cb9c878c656d35871b7c37c7cbe` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | `f7df0ec02d2e7e63278d5386e8153cfe2b691b864f17b6452cc824a5f328d688976c975b076e60f1c6b3c859e93e477134fbccc53bb49d9e846fb038b34eee48` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | `36dd5b10addca678a518e6d052c9d6edf473e3f87388a2f03f714c93c5fbfe99ace16cf3b382a531be20a8fe6f4160f8d891800dd2cff5f23c9ca12c2f4a151b` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | `5bdbb44b996ab4ccf3a383780270f5cfdbf174982c300723c8bddf0a48ae5e459476031c1d51b9d30ffd621d0a126c18a5de132ef1d92fca2f3e477665ea10cc` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-386.tar.gz) | `5dea3d4c4e91ef889850143b361974250e99a3c526f5efee23ff9ccdcd2ceca4a2247e7c4f236bdfa77d2150157da5d676ac9c3ba26cf3a2f1e06d8827556f77` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | `db298e698391368703e6aea7f4345aec5a4b8c69f9d8ff6c99fb5804a6cea16d295fb01e70fe943ade3d4ce9200a081ad40da21bd331317ec9213f69b4d6c48f` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | `c6284929dd5940e750b48db72ffbc09f73c5ec31ab3db283babb8e4e07cd8cbb27642f592009caae4717981c0db82c16312849ef4cbafe76acc4264c7d5864ac` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm.tar.gz) | `6fc9552cf082c54cc0833b19876117c87ba7feb5a12c7e57f71b52208daf03eaef3ca56bd22b7bce2d6e81b5a23537cf6f5497a6eaa356c0aab1d3de26c309f9` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | `b794b9c399e548949b5bfb2fe71123e86c2034847b2c99aca34b6de718a35355bbecdae9dc2a81c49e3c82fb4b5862526a3f63c2862b438895e12c5ea884f22e` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | `fddaed7a54f97046a91c29534645811c6346e973e22950b2607b8c119c2377e9ec2d32144f81626078cdaeca673129cc4016c1a3dbd3d43674aa777089fb56ac` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | `65951a534bb55069c7419f41cbcdfe2fae31541d8a3f9eca11fc2489addf281c5ad2d13719212657da0be5b898f22b57ac39446d99072872fbacb0a7d59a4f74` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | `992059efb5cae7ed0ef55820368d854bad1c6d13a70366162cd3b5111ce24c371c7c87ded2012f055e08b2ff1b4ef506e1f4e065daa3ac474fef50b5efa4fb07` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm.tar.gz) | `c63ae0f8add5821ad267774314b8c8c1ffe3b785872bf278e721fd5dfdad1a5db1d4db3720bea0a36bf10d9c6dd93e247560162c0eac6e1b743246f587d3b27a` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | `47adb9ddf6eaf8f475b89f59ee16fbd5df183149a11ad1574eaa645b47a6d58aec2ca70ba857ce9f1a5793d44cf7a61ebc6874793bb685edaf19410f4f76fd13` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | `a3bc4a165567c7b76a3e45ab7b102d6eb3ecf373eb048173f921a4964cf9be8891d0d5b8dafbd88c3af7b0e21ef3d41c1e540c3347ddd84b929b3a3d02ceb7b2` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | `109ddf37c748f69584c829db57107c3518defe005c11fcd2a1471845c15aae0a3c89aafdd734229f4069ed18856cc650c80436684e1bdc43cfee3149b0324746` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | `a3a75d2696ad3136476ad7d811e8eabaff5111b90e592695e651d6111f819ebf0165b8b7f5adc05afb5f7f01d1e5fb64876cb696e492feb20a477a5800382b7a` - -## Changelog since v1.18.0-beta.0 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - -- The StreamingProxyRedirects feature and `--redirect-container-streaming` flag are deprecated, and will be removed in a future release. The default behavior (proxy streaming requests through the kubelet) will be the only supported option. - If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node] - -- Yes. - - Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster. - - Changes in Pull Request: - - 1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources. - 2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature. - 3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature. - 4. Related unit tests. - - None. - - User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider] - -## Changes by Kind - -### Deprecation - -- Azure service annotation service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset has been deprecated. Its support would be removed in a future release. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] - -### API Change - -- API additions to apiserver types ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Cloud Provider and Cluster Lifecycle] -- Add Scheduling Profiles to kubescheduler.config.k8s.io/v1alpha2 ([#88087](https://github.com/kubernetes/kubernetes/pull/88087), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] -- Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage] -- AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Introduces optional --detect-local flag to kube-proxy. - Currently the only supported value is "cluster-cidr", - which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] -- Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] -- Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows] - -### Feature - -- Add --dry-run to kubectl delete, taint, replace ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing] -- Add huge page stats to Allocated resources in "kubectl describe node" ([#80605](https://github.com/kubernetes/kubernetes/pull/80605), [@odinuge](https://github.com/odinuge)) [SIG CLI] -- Kubeadm: The ClusterStatus struct present in the kubeadm-config ConfigMap is deprecated and will be removed on a future version. It is going to be maintained by kubeadm until it gets removed. The same information can be found on `etcd` and `kube-apiserver` pod annotations, `kubeadm.kubernetes.io/etcd.advertise-client-urls` and `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint` respectively. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle] -- Kubeadm: add the experimental feature gate PublicKeysECDSA that can be used to create a - cluster with ECDSA certificates from "kubeadm init". Renewal of existing ECDSA certificates is - also supported using "kubeadm alpha certs renew", but not switching between the RSA and - ECDSA algorithms on the fly or during upgrades. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth and Cluster Lifecycle] -- Kubeadm: on kubeconfig certificate renewal, keep the embedded CA in sync with the one on disk ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: upgrade supports fallback to the nearest known etcd version if an unknown k8s version is passed ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- New flag `--show-hidden-metrics-for-version` in kube-scheduler can be used to show all hidden metrics that deprecated in the previous minor release. ([#84913](https://github.com/kubernetes/kubernetes/pull/84913), [@serathius](https://github.com/serathius)) [SIG Instrumentation and Scheduling] -- Scheduler framework permit plugins now run at the end of the scheduling cycle, after reserve plugins. Waiting on permit will remain in the beginning of the binding cycle. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG Scheduling] -- The kubelet and the default docker runtime now support running ephemeral containers in the Linux process namespace of a target container. Other container runtimes must implement this feature before it will be available in that runtime. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG Node] - -### Other (Bug, Cleanup or Flake) - -- Add delays between goroutines for vm instance update ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] -- Add init containers log to cluster dump info. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- CPU limits are now respected for Windows containers. If a node is over-provisioned, no weighting is used - only limits are respected. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG Node, Testing and Windows] -- Cloud provider config CloudProviderBackoffMode has been removed since it won't be used anymore. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Evictions due to pods breaching their ephemeral storage limits are now recorded by the `kubelet_evictions` metric and can be alerted on. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node] -- Fix: add remediation in azure disk attach/detach ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: check disk status before disk azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fixed cleaning of CSI raw block volumes. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] -- Get-kube.sh uses the gcloud's current local GCP service account for auth when the provider is GCE or GKE instead of the metadata server default ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG Cluster Lifecycle] -- Golang/x/net has been updated to bring in fixes for CVE-2020-9283 ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation] -- Kubeadm now includes CoreDNS version 1.6.7 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] -- Kubeadm: fix the bug that 'kubeadm upgrade' hangs in single node cluster ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Optimize kubectl version help info ([#88313](https://github.com/kubernetes/kubernetes/pull/88313), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Removes the deprecated command `kubectl rolling-update` ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing] - - -# v1.18.0-alpha.5 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.18.0-alpha.5 - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes.tar.gz) | `6452cac2b80721e9f577cb117c29b9ac6858812b4275c2becbf74312566f7d016e8b34019bd1bf7615131b191613bf9b973e40ad9ac8f6de9007d41ef2d7fd70` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-src.tar.gz) | `e41d9d4dd6910a42990051fcdca4bf5d3999df46375abd27ffc56aae9b455ae984872302d590da6aa85bba6079334fb5fe511596b415ee79843dee1c61c137da` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-386.tar.gz) | `5c95935863492b31d4aaa6be93260088dafea27663eb91edca980ca3a8485310e60441bc9050d4d577e9c3f7ffd96db516db8d64321124cec1b712e957c9fe1c` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-amd64.tar.gz) | `868faa578b3738604d8be62fae599ccc556799f1ce54807f1fe72599f20f8a1f98ad8152fac14a08a463322530b696d375253ba3653325e74b587df6e0510da3` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-386.tar.gz) | `76a89d1d30b476b47f8fb808e342f89608e5c1c1787c4c06f2d7e763f9482e2ae8b31e6ad26541972e2b9a3a7c28327e3150cdd355e8b8d8b050a801bbf08d49` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-amd64.tar.gz) | `07ad96a09b44d1c707d7c68312c5d69b101a3424bf1e6e9400b2e7a3fba78df04302985d473ddd640d8f3f0257be34110dbe1304b9565dd9d7a4639b7b7b85fd` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm.tar.gz) | `c04fed9fa370a75c1b8e18b2be0821943bb9befcc784d14762ea3278e73600332a9b324d5eeaa1801d20ad6be07a553c41dcf4fa7ab3eadd0730ab043d687c8c` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm64.tar.gz) | `4199147dea9954333df26d34248a1cb7b02ebbd6380ffcd42d9f9ed5fdabae45a59215474dab3c11436c82e60bd27cbd03b3dde288bf611cd3e78b87c783c6a9` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-ppc64le.tar.gz) | `4f6d4d61d1c52d3253ca19031ebcd4bad06d19b68bbaaab5c8e8c590774faea4a5ceab1f05f2706b61780927e1467815b3479342c84d45df965aba78414727c4` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-s390x.tar.gz) | `e2a454151ae5dd891230fb516a3f73f73ab97832db66fd3d12e7f1657a569f58a9fe2654d50ddd7d8ec88a5ff5094199323a4c6d7d44dcf7edb06cca11dd4de1` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-386.tar.gz) | `14b262ba3b71c41f545db2a017cf1746075ada5745a858d2a62bc9df7c5dc10607220375db85e2c4cb85307b09709e58bc66a407488e0961191e3249dc7742b0` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-amd64.tar.gz) | `26353c294755a917216664364b524982b7f5fc6aa832ce90134bb178df8a78604963c68873f121ea5f2626ff615bdbf2ffe54e00578739cde6df42ffae034732` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-amd64.tar.gz) | `ba77e0e7c610f59647c1b2601f82752964a0f54b7ad609a89b00fcfd553d0f0249f6662becbabaa755bb769b36a2000779f08022c40fb8cc61440337481317a1` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm.tar.gz) | `45e87b3e844ea26958b0b489e8c9b90900a3253000850f5ff9e87ffdcafba72ab8fd17b5ba092051a58a4bc277912c047a85940ec7f093dff6f9e8bf6fed3b42` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm64.tar.gz) | `155e136e3124ead69c594eead3398d6cfdbb8f823c324880e8a7bbd1b570b05d13a77a69abd0a6758cfcc7923971cc6da4d3e0c1680fd519b632803ece00d5ce` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-ppc64le.tar.gz) | `3fa0fb8221da19ad9d03278961172b7fa29a618b30abfa55e7243bb937dede8df56658acf02e6b61e7274fbc9395e237f49c62f2a83017eca2a69f67af31c01c` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-s390x.tar.gz) | `db3199c3d7ba0b326d71dc8b80f50b195e79e662f71386a3b2976d47d13d7b0136887cc21df6f53e70a3d733da6eac7bbbf3bab2df8a1909a3cee4b44c32dd0b` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-amd64.tar.gz) | `addcdfbad7f12647e6babb8eadf853a374605c8f18bf63f416fa4d3bf1b903aa206679d840433206423a984bb925e7983366edcdf777cf5daef6ef88e53d6dfa` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm.tar.gz) | `b2ac54e0396e153523d116a2aaa32c919d6243931e0104cd47a23f546d710e7abdaa9eae92d978ce63c92041e63a9b56f5dd8fd06c812a7018a10ecac440f768` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm64.tar.gz) | `7aab36f2735cba805e4fd109831a1af0f586a88db3f07581b6dc2a2aab90076b22c96b490b4f6461a8fb690bf78948b6d514274f0d6fb0664081de2d44dc48e1` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-ppc64le.tar.gz) | `a579936f07ebf86f69f297ac50ba4c34caf2c0b903f73190eb581c78382b05ef36d41ade5bfd25d7b1b658cfcbee3d7125702a18e7480f9b09a62733a512a18a` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-s390x.tar.gz) | `58fa0359ddd48835192fab1136a2b9b45d1927b04411502c269cda07cb8a8106536973fb4c7fedf1d41893a524c9fe2e21078fdf27bfbeed778273d024f14449` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-windows-amd64.tar.gz) | `9086c03cd92b440686cea6d8c4e48045cc46a43ab92ae0e70350b3f51804b9e2aaae7178142306768bae00d9ef6dd938167972bfa90b12223540093f735a45db` - -## Changelog since v1.18.0-alpha.3 - -### Deprecation - -- Kubeadm: command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] - -### API Change - -- Kubelet podresources API now provides the information about active pods only. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG Node] -- Remove deprecated fields from .leaderElection in kubescheduler.config.k8s.io/v1alpha2 ([#87904](https://github.com/kubernetes/kubernetes/pull/87904), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Signatures on generated clientset methods have been modified to accept `context.Context` as a first argument. Signatures of generated Create, Update, and Patch methods have been updated to accept CreateOptions, UpdateOptions and PatchOptions respectively. Clientsets that with the previous interface have been added in new "deprecated" packages to allow incremental migration to the new APIs. The deprecated packages will be removed in the 1.21 release. ([#87299](https://github.com/kubernetes/kubernetes/pull/87299), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, Apps, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Scheduling, Storage, Testing and Windows] -- The k8s.io/node-api component is no longer updated. Instead, use the RuntimeClass types located within k8s.io/api, and the generated clients located within k8s.io/client-go ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG Node and Release] - -### Feature - -- Add indexer for storage cacher ([#85445](https://github.com/kubernetes/kubernetes/pull/85445), [@shaloulcy](https://github.com/shaloulcy)) [SIG API Machinery] -- Add support for mount options to the FC volume plugin ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG Storage] -- Added a config-mode flag in azure auth module to enable getting AAD token without spn: prefix in audience claim. When it's not specified, the default behavior doesn't change. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth, CLI and Cloud Provider] -- Introduced BackoffManager interface for backoff management ([#87829](https://github.com/kubernetes/kubernetes/pull/87829), [@zhan849](https://github.com/zhan849)) [SIG API Machinery] -- PodTopologySpread plugin now excludes terminatingPods when making scheduling decisions. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Promote CSIMigrationOpenStack to Beta (off by default since it requires installation of the OpenStack Cinder CSI Driver) - The in-tree AWS OpenStack Cinder "kubernetes.io/cinder" was already deprecated a while ago and will be removed in 1.20. Users should enable CSIMigration + CSIMigrationOpenStack features and install the OpenStack Cinder CSI Driver (https://github.com/kubernetes-sigs/cloud-provider-openstack) to avoid disruption to existing Pod and PVC objects at that time. - Users should start using the OpenStack Cinder CSI Driver directly for any new volumes. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG Cloud Provider] - -### Design - -- The scheduler Permit extension point doesn't return a boolean value in its Allow() and Reject() functions. ([#87936](https://github.com/kubernetes/kubernetes/pull/87936), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] - -### Other (Bug, Cleanup or Flake) - -- Adds "volume.beta.kubernetes.io/migrated-to" annotation to PV's and PVC's when they are migrated to signal external provisioners to pick up those objects for Provisioning and Deleting. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG Apps and Storage] -- Fix a bug in the dual-stack IPVS proxier where stale IPv6 endpoints were not being cleaned up ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network] -- Fix kubectl drain ignore daemonsets and others. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Fix: add azure disk migration support for CSINode ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix: add non-retriable errors in azure clients ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fixed NetworkPolicy validation that Except values are accepted when they are outside the CIDR range. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG Network] -- Improves performance of the node authorizer ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG Auth] -- Iptables/userspace proxy: improve performance by getting local addresses only once per sync loop, instead of for every external IP ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Network] -- Kube-aggregator: always sets unavailableGauge metric to reflect the current state of a service. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery] -- Kubeadm allows to configure single-stack clusters if dual-stack is enabled ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, Cluster Lifecycle and Network] -- Kubeadm: 'kubeadm alpha kubelet config download' has been removed, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubeadm: remove 'kubeadm upgrade node config' command since it was deprecated in v1.15, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubectl describe and kubectl top pod will return a message saying "No resources found" or "No resources found in namespace" if there are no results to display. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Kubelet metrics gathered through metrics-server or prometheus should no longer timeout for Windows nodes running more than 3 pods. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG Node, Testing and Windows] -- Kubelet metrics have been changed to buckets. - For example the exec/{podNamespace}/{podID}/{containerName} is now just exec. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG Node] -- Limit number of instances in a single update to GCE target pool to 1000. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability] -- Make Azure clients only retry on specified HTTP status codes ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Pause image contains "Architecture" in non-amd64 images ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG Release] -- Pods that are considered for preemption and haven't started don't produce an error log. ([#87900](https://github.com/kubernetes/kubernetes/pull/87900), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Prevent error message from being displayed when running kubectl plugin list and your path includes an empty string ([#87633](https://github.com/kubernetes/kubernetes/pull/87633), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- `kubectl create clusterrolebinding` creates rbac.authorization.k8s.io/v1 object ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI] - -# v1.18.0-alpha.4 - -[Documentation](https://docs.k8s.io) - -## Important note about manual tag - -Due to a [tagging bug in our Release Engineering tooling](https://github.com/kubernetes/release/issues/1080) during `v1.18.0-alpha.3`, we needed to push a manual tag (`v1.18.0-alpha.4`). - -**No binaries have been produced or will be provided for `v1.18.0-alpha.4`.** - -The changelog for `v1.18.0-alpha.4` is included as part of the [changelog since v1.18.0-alpha.3][#changelog-since-v1180-alpha3] section. - -# v1.18.0-alpha.3 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.18.0-alpha.3 - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes.tar.gz) | `60bf3bfc23b428f53fd853bac18a4a905b980fcc0bacd35ccd6357a89cfc26e47de60975ea6b712e65980e6b9df82a22331152d9f08ed4dba44558ba23a422d4` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-src.tar.gz) | `8adf1016565a7c93713ab6fa4293c2d13b4f6e4e1ec4dcba60bd71e218b4dbe9ef5eb7dbb469006743f498fc7ddeb21865cd12bec041af60b1c0edce8b7aecd5` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-386.tar.gz) | `abb32e894e8280c772e96227b574da81cd1eac374b8d29158b7f222ed550087c65482eef4a9817dfb5f2baf0d9b85fcdfa8feced0fbc1aacced7296853b57e1f` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | `5e4b1a993264e256ec1656305de7c306094cae9781af8f1382df4ce4eed48ce030827fde1a5e757d4ad57233d52075c9e4e93a69efbdc1102e4ba810705ccddc` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-386.tar.gz) | `68da39c2ae101d2b38f6137ceda07eb0c2124794982a62ef483245dbffb0611c1441ca085fa3127e7a9977f45646788832a783544ff06954114548ea0e526e46` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | `dc236ffa8ad426620e50181419e9bebe3c161e953dbfb8a019f61b11286e1eb950b40d7cc03423bdf3e6974973bcded51300f98b55570c29732fa492dcde761d` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | `ab0a8bd6dc31ea160b731593cdc490b3cc03668b1141cf95310bd7060dcaf55c7ee9842e0acae81063fdacb043c3552ccdd12a94afd71d5310b3ce056fdaa06c` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | `159ea083c601710d0d6aea423eeb346c99ffaf2abd137d35a53e87a07f5caf12fca8790925f3196f67b768fa92a024f83b50325dbca9ccd4dde6c59acdce3509` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | `16b0459adfa26575d13be49ab53ac7f0ffd05e184e4e13d2dfbfe725d46bb8ac891e1fd8aebe36ecd419781d4cc5cf3bd2aaaf5263cf283724618c4012408f40` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | `d5aa1f5d89168995d2797eb839a04ce32560f405b38c1c0baaa0e313e4771ae7bb3b28e22433ad5897d36aadf95f73eb69d8d411d31c4115b6b0adf5fe041f85` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-386.tar.gz) | `374e16a1e52009be88c94786f80174d82dff66399bf294c9bee18a2159c42251c5debef1109a92570799148b08024960c6c50b8299a93fd66ebef94f198f34e9` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | `5a94c1068c19271f810b994adad8e62fae03b3d4473c7c9e6d056995ff7757ea61dd8d140c9267dd41e48808876673ce117826d35a3c1bb5652752f11a044d57` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | `a677bec81f0eba75114b92ff955bac74512b47e53959d56a685dae5edd527283d91485b1e86ad74ef389c5405863badf7eb22e2f0c9a568a4d0cb495c6a5c32f` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | `2fb696f86ff13ebeb5f3cf2b254bf41303644c5ea84a292782eac6123550702655284d957676d382698c091358e5c7fe73f32803699c19be7138d6530fe413b6` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | `738e95da9cfb8f1309479078098de1c38cef5e1dd5ee1129b77651a936a412b7cd0cf15e652afc7421219646a98846ab31694970432e48dea9c9cafa03aa59cf` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | `7a85bfcbb2aa636df60c41879e96e788742ecd72040cb0db2a93418439c125218c58a4cfa96d01b0296c295793e94c544e87c2d98d50b49bc4cb06b41f874376` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | `1f1cdb2efa3e7cac857203d8845df2fdaa5cf1f20df764efffff29371945ec58f6deeba06f8fbf70b96faf81b0c955bf4cb84e30f9516cb2cc1ed27c2d2185a6` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | `4ccfced3f5ba4adfa58f4a9d1b2c5bdb3e89f9203ab0e27d11eb1c325ac323ebe63c015d2c9d070b233f5d1da76cab5349da3528511c1cd243e66edc9af381c4` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | `d695a69d18449062e4c129e54ec8384c573955f8108f4b78adc2ec929719f2196b995469c728dd6656c63c44cda24315543939f85131ebc773cfe0de689df55b` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | `21df1da88c89000abc22f97e482c3aaa5ce53ec9628d83dda2e04a1d86c4d53be46c03ed6f1f211df3ee5071bce39d944ff7716b5b6ada3b9c4821d368b0a898` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | `ff77e3aacb6ed9d89baed92ef542c8b5cec83151b6421948583cf608bca3b779dce41fc6852961e00225d5e1502f6a634bfa61a36efa90e1aee90dedb787c2d2` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | `57d75b7977ec1a0f6e7ed96a304dbb3b8664910f42ca19aab319a9ec33535ff5901dfca4abcb33bf5741cde6d152acd89a5f8178f0efe1dc24430e0c1af5b98f` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | `63fdbb71773cfd73a914c498e69bb9eea3fc314366c99ffb8bd42ec5b4dae807682c83c1eb5cfb1e2feb4d11d9e49cc85ba644e954241320a835798be7653d61` - -## Changelog since v1.18.0-alpha.2 - -### Deprecation - -- Remove all the generators from kubectl run. It will now only create pods. Additionally, deprecates all the flags that are not relevant anymore. ([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, SIG CLI, and SIG Testing] -- kubeadm: kube-dns is deprecated and will not be supported in a future version ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] - -### API Change - -- Add kubescheduler.config.k8s.io/v1alpha2 ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- --enable-cadvisor-endpoints is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, SIG Node, and SIG Testing] -- The following feature gates are removed, because the associated features were unconditionally enabled in previous releases: CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] - -### Feature - -- aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] -- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form - - Throttling request took 1.50705208s, request: GET: - - The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] -- kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- The kubectl --dry-run flag now accepts the values 'client', 'server', and 'none', to support client-side and server-side dry-run strategies. The boolean and unset values for the --dry-run flag are deprecated and a value will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI] -- Add support for pre-allocated hugepages for more than one page size ([#82820](https://github.com/kubernetes/kubernetes/pull/82820), [@odinuge](https://github.com/odinuge)) [SIG Apps] -- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, SIG Cluster Lifecycle, SIG Network, SIG Release, and SIG Testing] -- Skip default spreading scoring plugin for pods that define TopologySpreadConstraints ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling] -- Added more details to taint toleration errors ([#87250](https://github.com/kubernetes/kubernetes/pull/87250), [@starizard](https://github.com/starizard)) [SIG Apps, and SIG Scheduling] -- Scheduler: Add DefaultBinder plugin ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling, and SIG Testing] -- Kube-apiserver metrics will now include request counts, latencies, and response sizes for /healthz, /livez, and /readyz requests. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery] - -### Other (Bug, Cleanup or Flake) - -- Fix the masters rolling upgrade causing thundering herd of LISTs on etcd leading to control plane unavailability. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, SIG Node, and SIG Testing] -- `kubectl diff` now returns 1 only on diff finding changes, and >1 on kubectl errors. The "exit status code 1" message as also been muted. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI, and SIG Testing] -- To reduce chances of throttling, VM cache is set to nil when Azure node provisioning state is deleting ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fix regression in statefulset conversion which prevented applying a statefulset multiple times. ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG Apps, and SIG Testing] -- fixed two scheduler metrics (pending_pods and schedule_attempts_total) not being recorded ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG Scheduling] -- Resolved a performance issue in the node authorizer index maintenance. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG Auth] -- Removed the 'client' label from apiserver_request_total. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, and SIG Instrumentation] -- `(*"k8s.io/client-go/rest".Request).{Do,DoRaw,Stream,Watch}` now require callers to pass a `context.Context` as an argument. The context is used for timeout and cancellation signaling and to pass supplementary information to round trippers in the wrapped transport chain. If you don't need any of this functionality, it is sufficient to pass a context created with `context.Background()` to these functions. The `(*"k8s.io/client-go/rest".Request).Context` method is removed now that all methods that execute a request accept a context directly. ([#87597](https://github.com/kubernetes/kubernetes/pull/87597), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, SIG Apps, SIG Auth, SIG Autoscaling, SIG CLI, SIG Cloud Provider, SIG Cluster Lifecycle, SIG Instrumentation, SIG Network, SIG Node, SIG Scheduling, SIG Storage, and SIG Testing] -- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#87258](https://github.com/kubernetes/kubernetes/pull/87258), [@verult](https://github.com/verult)) [SIG Apps, SIG Node, and SIG Storage] -- kubeadm: apply further improvements to the tentative support for concurrent etcd member join. Fixes a bug where multiple members can receive the same hostname. Increase the etcd client dial timeout and retry timeout for add/remove/... operations. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Reverted a kubectl azure auth module change where oidc claim spn: prefix was omitted resulting a breaking behavior with existing Azure AD OIDC enabled api-server ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, SIG Auth, and SIG Cloud Provider] -- Update cri-tools to v1.17.0 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cluster Lifecycle, and SIG Release] -- kubeadm: remove the deprecated CoreDNS feature-gate. It was set to "true" since v1.11 when the feature went GA. In v1.13 it was marked as deprecated and hidden from the CLI. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Shared informers are now more reliable in the face of network disruption. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery] -- the CSR signing cert/key pairs will be reloaded from disk like the kube-apiserver cert/key pairs ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, SIG Apps, and SIG Auth] -- "kubectl describe statefulsets.apps" prints garbage for rolling update partition ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI] - - - - - -# v1.18.0-alpha.2 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.18.0-alpha.2 - - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes.tar.gz) | `7af83386b4b35353f0aa1bdaf73599eb08b1d1ca11ecc2c606854aff754db69f3cd3dc761b6d7fc86f01052f615ca53185f33dbf9e53b2f926b0f02fc103fbd3` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-src.tar.gz) | `a14b02a0a0bde97795a836a8f5897b0ee6b43e010e13e43dd4cca80a5b962a1ef3704eedc7916fed1c38ec663a71db48c228c91e5daacba7d9370df98c7ddfb6` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-386.tar.gz) | `427f214d47ded44519007de2ae87160c56c2920358130e474b768299751a9affcbc1b1f0f936c39c6138837bca2a97792a6700896976e98c4beee8a1944cfde1` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | `861fd81ac3bd45765575bedf5e002a2294aba48ef9e15980fc7d6783985f7d7fcde990ea0aef34690977a88df758722ec0a2e170d5dcc3eb01372e64e5439192` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-386.tar.gz) | `7d59b05d6247e2606a8321c72cd239713373d876dbb43b0fb7f1cb857fa6c998038b41eeed78d9eb67ce77b0b71776ceed428cce0f8d2203c5181b473e0bd86c` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | `7cdefb4e32bad9d2df5bb8e7e0a6f4dab2ae6b7afef5d801ac5c342d4effdeacd799081fa2dec699ecf549200786c7623c3176252010f12494a95240dd63311d` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | `6212bbf0fa1d01ced77dcca2c4b76b73956cd3c6b70e0701c1fe0df5ff37160835f6b84fa2481e0e6979516551b14d8232d1c72764a559a3652bfe2a1e7488ff` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | `1f0d9990700510165ee471acb2f88222f1b80e8f6deb351ce14cf50a70a9840fb99606781e416a13231c74b2bd7576981b5348171aa33b628d2666e366cd4629` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | `77e00ba12a32db81e96f8de84609de93f32c61bb3f53875a57496d213aa6d1b92c09ad5a6de240a78e1a5bf77fac587ff92874f34a10f8909ae08ca32fda45d2` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | `a39ec2044bed5a4570e9c83068e0fc0ce923ccffa44380f8bbc3247426beaff79c8a84613bcb58b05f0eb3afbc34c79fe3309aa2e0b81abcfd0aa04770e62e05` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-386.tar.gz) | `1a0ab88f9b7e34b60ab31d5538e97202a256ad8b7b7ed5070cae5f2f12d5d4edeae615db7a34ebbe254004b6393c6b2480100b09e30e59c9139492a3019a596a` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | `1966eb5dfb78c1bc33aaa6389f32512e3aa92584250a0164182f3566c81d901b59ec78ee4e25df658bc1dd221b5a9527d6ce3b6c487ca3e3c0b319a077caa735` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | `f814d6a3872e4572aa4da297c29def4c1fad8eba0903946780b6bf9788c72b99d71085c5aef9e12c01133b26fa4563c1766ba724ad2a8af2670a24397951a94d` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | `56aa08225e546c92c2ff88ac57d3db7dd5e63640772ea72a429f080f7069827138cbc206f6f5fe3a0c01bfca043a9eda305ecdc1dcb864649114893e46b6dc84` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | `fb87128d905211ba097aa860244a376575ae2edbaca6e51402a24bc2964854b9b273e09df3d31a2bcffc91509f7eecb2118b183fb0e0eb544f33403fa235c274` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | `6d21fbf39b9d3a0df9642407d6f698fabdc809aca83af197bceb58a81b25846072f407f8fb7caae2e02dc90912e3e0f5894f062f91bcb69f8c2329625d3dfeb7` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | `ddcda4dc360ca97705f71bf2a18ddacd7b7ddf77535b62e699e97a1b2dd24843751313351d0112e238afe69558e8271eba4d27ab77bb67b4b9e3fbde6eec85c9` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | `78915a9bde35c70c67014f0cea8754849db4f6a84491a3ad9678fd3bc0203e43af5a63cfafe104ae1d56b05ce74893a87a6dcd008d7859e1af6b3bce65425b5d` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | `3218e811abcb0cb09d80742def339be3916db5e9bbc62c0dc8e6d87085f7e3d9eeed79dea081906f1de78ddd07b7e3acdbd7765fdb838d262bb35602fd1df106` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | `fa22de9c4440b8fb27f4e77a5a63c5e1c8aa8aa30bb79eda843b0f40498c21b8c0ad79fff1d841bb9fef53fe20da272506de9a86f81a0b36d028dbeab2e482ce` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | `bbda9b5cc66e8f13d235703b2a85e2c4f02fa16af047be4d27a3e198e11eb11706e4a0fbb6c20978c770b069cd4cd9894b661f09937df9d507411548c36576e0` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | `b2ed1eda013069adce2aac00b86d75b84e006cfce9bafac0b5a2bafcb60f8f2cb346b5ea44eafa72d777871abef1ea890eb3a2a05de28968f9316fa88886a8ed` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | `bd8eb23dba711f31b5148257076b1bbe9629f2a75de213b2c779bd5b29279e9bf22f8bde32f4bc814f4c0cc49e19671eb8b24f4105f0fe2c1490c4b78ec3c704` - -## Changelog since v1.18.0-alpha.1 - -### Other notable changes - -* Bump golang/mock version to v1.3.1 ([#87326](https://github.com/kubernetes/kubernetes/pull/87326), [@wawa0210](https://github.com/wawa0210)) -* fix a bug that orphan revision cannot be adopted and statefulset cannot be synced ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli)) -* Azure storage clients now suppress requests on throttling ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer)) -* Introduce Alpha field `Immutable` in both Secret and ConfigMap objects to mark their contents as immutable. The implementation is hidden behind feature gate `ImmutableEphemeralVolumes` (currently in Alpha stage). ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t)) -* EndpointSlices will now be enabled by default. A new `EndpointSliceProxying` feature gate determines if kube-proxy will use EndpointSlices, this is disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) -* kubeadm upgrades always persist the etcd backup for stacked ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu)) -* Fix the bug PIP's DNS is deleted if no DNS label service annotation isn't set. ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19)) -* New flag `--show-hidden-metrics-for-version` in kube-controller-manager can be used to show all hidden metrics that deprecated in the previous minor release. ([#85281](https://github.com/kubernetes/kubernetes/pull/85281), [@RainbowMango](https://github.com/RainbowMango)) -* Azure network and VM clients now suppress requests on throttling ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer)) -* `kubectl apply -f --prune -n ` should prune all resources not defined in the file in the cli specified namespace. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu)) -* Fixes service account token admission error in clusters that do not run the service account token controller ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt)) -* CustomResourceDefinition status fields are no longer required for client validation when submitting manifests. ([#87213](https://github.com/kubernetes/kubernetes/pull/87213), [@hasheddan](https://github.com/hasheddan)) -* All apiservers log request lines in a more greppable format. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp)) -* provider/azure: Network security groups can now be in a separate resource group. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon)) -* Cleaned up the output from `kubectl describe CSINode `. ([#85283](https://github.com/kubernetes/kubernetes/pull/85283), [@huffmanca](https://github.com/huffmanca)) -* Fixed the following ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919)) - * - AWS Cloud Provider attempts to delete LoadBalancer security group it didn’t provision - * - AWS Cloud Provider creates default LoadBalancer security group even if annotation [service.beta.kubernetes.io/aws-load-balancer-security-groups] is present -* kubelet: resource metrics endpoint `/metrics/resource/v1alpha1` as well as all metrics under this endpoint have been deprecated. ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) - * Please convert to the following metrics emitted by endpoint `/metrics/resource`: - * - scrape_error --> scrape_error - * - node_cpu_usage_seconds_total --> node_cpu_usage_seconds - * - node_memory_working_set_bytes --> node_memory_working_set_bytes - * - container_cpu_usage_seconds_total --> container_cpu_usage_seconds - * - container_memory_working_set_bytes --> container_memory_working_set_bytes - * - scrape_error --> scrape_error -* You can now pass "--node-ip ::" to kubelet to indicate that it should autodetect an IPv6 address to use as the node's primary address. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship)) -* kubeadm: support automatic retry after failing to pull image ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu)) -* TODO ([#87044](https://github.com/kubernetes/kubernetes/pull/87044), [@jennybuckley](https://github.com/jennybuckley)) -* Improved yaml parsing performance ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen)) -* Fixed a bug which could prevent a provider ID from ever being set for node if an error occurred determining the provider ID when the node was added. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs)) -* fix a regression in kubenet that prevent pods to obtain ip addresses ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs)) -* Bind kube-dns containers to linux nodes to avoid Windows scheduling ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210)) -* The following features are unconditionally enabled and the corresponding `--feature-gates` flags have been removed: `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` and `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness)) -* Bind dns-horizontal containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210)) -* fix kubectl annotate error when local=true is set ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0)) -* Bug fixes: ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera)) - * Make sure we include latest packages node #351 ([@caseydavenport](https://github.com/caseydavenport)) -* fix kuebctl apply set-last-applied namespaces error ([#86474](https://github.com/kubernetes/kubernetes/pull/86474), [@zhouya0](https://github.com/zhouya0)) -* Add VolumeBinder method to FrameworkHandle interface, which allows user to get the volume binder when implementing scheduler framework plugins. ([#86940](https://github.com/kubernetes/kubernetes/pull/86940), [@skilxn-go](https://github.com/skilxn-go)) -* elasticsearch supports automatically setting the advertise address ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu)) -* If a serving certificates param specifies a name that is an IP for an SNI certificate, it will have priority for replying to server connections. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k)) -* kube-proxy: Added dual-stack IPv4/IPv6 support to the iptables proxier. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) -* Azure VMSS/VMSSVM clients now suppress requests on throttling ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer)) -* New metric kubelet_pleg_last_seen_seconds to aid diagnosis of PLEG not healthy issues. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham)) -* For subprotocol negotiation, both client and server protocol is required now. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu)) -* kubeadm: use bind-address option to configure the kube-controller-manager and kube-scheduler http probes ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea)) -* Marked scheduler's metrics scheduling_algorithm_predicate_evaluation_seconds and ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) - * scheduling_algorithm_priority_evaluation_seconds as deprecated. Those are replaced by framework_extension_point_duration_seconds[extenstion_point="Filter"] and framework_extension_point_duration_seconds[extenstion_point="Score"] respectively. -* Marked scheduler's scheduling_duration_seconds Summary metric as deprecated ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) -* Add instructions about how to bring up e2e test cluster ([#85836](https://github.com/kubernetes/kubernetes/pull/85836), [@YangLu1031](https://github.com/YangLu1031)) -* If a required flag is not provided to a command, the user will only see the required flag error message, instead of the entire usage menu. ([#86693](https://github.com/kubernetes/kubernetes/pull/86693), [@sallyom](https://github.com/sallyom)) -* kubeadm: tolerate whitespace when validating certificate authority PEM data in kubeconfig files ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123)) -* kubeadm: add support for the "ci/k8s-master" version label as a replacement for "ci-cross/*", which no longer exists. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu)) -* Fix EndpointSlice controller race condition and ensure that it handles external changes to EndpointSlices. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott)) -* Fix nil pointer dereference in azure cloud provider ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx)) -* fix: azure disk could not mounted on Standard_DC4s/DC2s instances ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx)) -* Fixes v1.17.0 regression in --service-cluster-ip-range handling with IPv4 ranges larger than 65536 IP addresses ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt)) -* Adds back support for AlwaysCheckAllPredicates flag. ([#86496](https://github.com/kubernetes/kubernetes/pull/86496), [@ahg-g](https://github.com/ahg-g)) -* Azure global rate limit is switched to per-client. A set of new rate limit configure options are introduced, including routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit and VirtualMachineSizeRateLimit. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer)) - * The original rate limit options would be default values for those new client's rate limiter. -* Fix issue [#85805](https://github.com/kubernetes/kubernetes/pull/85805) about resource not found in azure cloud provider when lb specified in other resource group. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm)) -* `AlwaysCheckAllPredicates` is deprecated in scheduler Policy API. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei)) -* Kubernetes KMS provider for data encryption now supports disabling the in-memory data encryption key (DEK) cache by setting cachesize to a negative value. ([#86294](https://github.com/kubernetes/kubernetes/pull/86294), [@enj](https://github.com/enj)) -* option `preConfiguredBackendPoolLoadBalancerTypes` is added to azure cloud provider for the pre-configured load balancers, possible values: `""`, `"internal"`, "external"`, `"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion)) -* Promote StartupProbe to beta for 1.18 release ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx)) -* Fixes issue where AAD token obtained by kubectl is incompatible with on-behalf-of flow and oidc. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong)) - * The audience claim before this fix has "spn:" prefix. After this fix, "spn:" prefix is omitted. -* change CounterVec to Counter about PLEGDiscardEvent ([#86167](https://github.com/kubernetes/kubernetes/pull/86167), [@yiyang5055](https://github.com/yiyang5055)) -* hollow-node do not use remote CRI anymore ([#86425](https://github.com/kubernetes/kubernetes/pull/86425), [@jkaniuk](https://github.com/jkaniuk)) -* hollow-node use fake CRI ([#85879](https://github.com/kubernetes/kubernetes/pull/85879), [@gongguan](https://github.com/gongguan)) - - - -# v1.18.0-alpha.1 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.18.0-alpha.1 - - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes.tar.gz) | `0c4904efc7f4f1436119c91dc1b6c93b3bd9c7490362a394bff10099c18e1e7600c4f6e2fcbaeb2d342a36c4b20692715cf7aa8ada6dfac369f44cc9292529d7` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-src.tar.gz) | `0a50fc6816c730ca5ae4c4f26d5ad7b049607d29f6a782a4e5b4b05ac50e016486e269dafcc6a163bd15e1a192780a9a987f1bb959696993641c603ed1e841c8` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-386.tar.gz) | `c6d75f7f3f20bef17fc7564a619b54e6f4a673d041b7c9ec93663763a1cc8dd16aecd7a2af70e8d54825a0eecb9762cf2edfdade840604c9a32ecd9cc2d5ac3c` -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | `ca1f19db289933beace6daee6fc30af19b0e260634ef6e89f773464a05e24551c791be58b67da7a7e2a863e28b7cbcc7b24b6b9bf467113c26da76ac8f54fdb6` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-386.tar.gz) | `af2e673653eb39c3f24a54efc68e1055f9258bdf6cf8fea42faf42c05abefc2da853f42faac3b166c37e2a7533020b8993b98c0d6d80a5b66f39e91d8ae0a3fb` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | `9009032c3f94ac8a78c1322a28e16644ce3b20989eb762685a1819148aed6e883ca8e1200e5ec37ec0853f115c67e09b5d697d6cf5d4c45f653788a2d3a2f84f` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | `afba9595b37a3f2eead6e3418573f7ce093b55467dce4da0b8de860028576b96b837a2fd942f9c276e965da694e31fbd523eeb39aefb902d7e7a2f169344d271` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | `04fc3b2fe3f271807f0bc6c61be52456f26a1af904964400be819b7914519edc72cbab9afab2bb2e2ba1a108963079367cedfb253c9364c0175d1fcc64d52f5c` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | `04c7edab874b33175ff7bebfff5b3a032bc6eb088fcd7387ffcd5b3fa71395ca8c5f9427b7ddb496e92087dfdb09eaf14a46e9513071d3bd73df76c182922d38` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | `499287dbbc33399a37b9f3b35e0124ff20b17b6619f25a207ee9c606ef261af61fa0c328dde18c7ce2d3dfb2eea2376623bc3425d16bc8515932a68b44f8bede` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-386.tar.gz) | `cf84aeddf00f126fb13c0436b116dd0464a625659e44c84bf863517db0406afb4eefd86807e7543c4f96006d275772fbf66214ae7d582db5865c84ac3545b3e6` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | `69f20558ccd5cd6dbaccf29307210db4e687af21f6d71f68c69d3a39766862686ac1333ab8a5012010ca5c5e3c11676b45e498e3d4c38773da7d24bcefc46d95` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | `3f29df2ce904a0f10db4c1d7a425a36f420867b595da3fa158ae430bfead90def2f2139f51425b349faa8a9303dcf20ea01657cb6ea28eb6ad64f5bb32ce2ed1` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | `4a21073b2273d721fbf062c254840be5c8471a010bcc0c731b101729e36e61f637cb7fcb521a22e8d24808510242f4fff8a6ca40f10e9acd849c2a47bf135f27` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | `7f1cb6d721bedc90e28b16f99bea7e59f5ad6267c31ef39c14d34db6ad6aad87ee51d2acdd01b6903307c1c00b58ff6b785a03d5a491cc3f8a4df9a1d76d406c` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | `8f2b552030b5274b1c2c7c166eacd5a14b0c6ca0f23042f4c52efe87e22a167ba4460dcd66615a5ecd26d9e88336be1fb555548392e70efe59070dd2c314da98` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | `8d9f2c96f66edafb7c8b3aa90960d29b41471743842aede6b47b3b2e61f4306fb6fc60b9ebc18820c547ee200bfedfe254c1cde962d447c791097dd30e79abdb` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | `84194cb081d1502f8ca68143569f9707d96f1a28fcf0c574ebd203321463a8b605f67bb2a365eaffb14fbeb8d55c8d3fa17431780b242fb9cba3a14426a0cd4a` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | `0091e108ab94fd8683b89c597c4fdc2fbf4920b007cfcd5297072c44bc3a230dfe5ceed16473e15c3e6cf5edab866d7004b53edab95be0400cc60e009eee0d9d` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | `b7e85682cc2848a35d52fd6f01c247f039ee1b5dd03345713821ea10a7fa9939b944f91087baae95eaa0665d11857c1b81c454f720add077287b091f9f19e5d3` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | `cd1f0849e9c62b5d2c93ff0cebf58843e178d8a88317f45f76de0db5ae020b8027e9503a5fccc96445184e0d77ecdf6f57787176ac31dbcbd01323cd0a190cbb` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | `e1e697a34424c75d75415b613b81c8af5f64384226c5152d869f12fd7db1a3e25724975b73fa3d89e56e4bf78d5fd07e68a709ba8566f53691ba6a88addc79ea` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | `c725a19a4013c74e22383ad3fb4cb799b3e161c4318fdad066daf806730a89bc3be3ff0f75678d02b3cbe52b2ef0c411c0639968e200b9df470be40bb2c015cc` - -## Changelog since v1.17.0 - -### Action Required - -* action required ([#85363](https://github.com/kubernetes/kubernetes/pull/85363), [@immutableT](https://github.com/immutableT)) - * 1. Currently, if users were to explicitly specify CacheSize of 0 for KMS provider, they would end-up with a provider that caches up to 1000 keys. This PR changes this behavior. - * Post this PR, when users supply 0 for CacheSize this will result in a validation error. - * 2. CacheSize type was changed from int32 to *int32. This allows defaulting logic to differentiate between cases where users explicitly supplied 0 vs. not supplied any value. - * 3. KMS Provider's endpoint (path to Unix socket) is now validated when the EncryptionConfiguration files is loaded. This used to be handled by the GRPCService. - -### Other notable changes - -* fix: azure data disk should use same key as os disk by default ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx)) -* New flag `--show-hidden-metrics-for-version` in kube-proxy can be used to show all hidden metrics that deprecated in the previous minor release. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango)) -* Remove cluster-monitoring addon ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius)) -* Changed core_pattern on COS nodes to be an absolute path. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml)) -* Track mount operations as uncertain if operation fails with non-final error ([#82492](https://github.com/kubernetes/kubernetes/pull/82492), [@gnufied](https://github.com/gnufied)) -* add kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) -* The sample-apiserver aggregated conformance test has updated to use the Kubernetes v1.17.0 sample apiserver ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt)) -* The underlying format of the `CPUManager` state file has changed. Upgrades should be seamless, but any third-party tools that rely on reading the previous format need to be updated. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska)) -* kubernetes will try to acquire the iptables lock every 100 msec during 5 seconds instead of every second. This specially useful for environments using kube-proxy in iptables mode with a high churn rate of services. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea)) -* Fixed a panic in the kubelet cleaning up pod volumes ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu)) -* azure cloud provider cache TTL is configurable, list of the azure cloud provider is as following: ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1)) - * - "availabilitySetNodesCacheTTLInSeconds" - * - "vmssCacheTTLInSeconds" - * - "vmssVirtualMachinesCacheTTLInSeconds" - * - "vmCacheTTLInSeconds" - * - "loadBalancerCacheTTLInSeconds" - * - "nsgCacheTTLInSeconds" - * - "routeTableCacheTTLInSeconds" -* Fixes kube-proxy when EndpointSlice feature gate is enabled on Windows. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott)) -* Fixes wrong validation result of NetworkPolicy PolicyTypes ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn)) -* Fixes an issue with kubelet-reported pod status on deleted/recreated pods. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt)) -* kube-apiserver no longer serves the following deprecated APIs: ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt)) - * All resources under `apps/v1beta1` and `apps/v1beta2` - use `apps/v1` instead - * `daemonsets`, `deployments`, `replicasets` resources under `extensions/v1beta1` - use `apps/v1` instead - * `networkpolicies` resources under `extensions/v1beta1` - use `networking.k8s.io/v1` instead - * `podsecuritypolicies` resources under `extensions/v1beta1` - use `policy/v1beta1` instead -* kubeadm: fix potential panic when executing "kubeadm reset" with a corrupted kubelet.conf file ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123)) -* Fix a bug in port-forward: named port not working with service ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py)) -* kube-proxy no longer modifies shared EndpointSlices. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott)) -* allow for configuration of CoreDNS replica count ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick)) -* Fixed a regression where the kubelet would fail to update the ready status of pods. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu)) -* Resolves performance regression in client-go discovery clients constructed using `NewDiscoveryClientForConfig` or `NewDiscoveryClientForConfigOrDie`. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt)) -* Make error message and service event message more clear ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer)) -* e2e-test-framework: add e2e test namespace dump if all tests succeed but the cleanup fails. ([#85542](https://github.com/kubernetes/kubernetes/pull/85542), [@schrodit](https://github.com/schrodit)) -* SafeSysctlWhitelist: add net.ipv4.ping_group_range ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda)) -* kubelet: the metric process_start_time_seconds be marked as with the ALPHA stability level. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango)) -* API request throttling (due to a high rate of requests) is now reported in the kubelet (and other component) logs by default. The messages are of the form ([#80649](https://github.com/kubernetes/kubernetes/pull/80649), [@RobertKrawitz](https://github.com/RobertKrawitz)) - * Throttling request took 1.50705208s, request: GET: - * The presence of large numbers of these messages, particularly with long delay times, may indicate to the administrator the need to tune the cluster accordingly. -* Fix API Server potential memory leak issue in processing watch request. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991)) -* Verify kubelet & kube-proxy can recover after being killed on Windows nodes ([#84886](https://github.com/kubernetes/kubernetes/pull/84886), [@YangLu1031](https://github.com/YangLu1031)) -* Fixed an issue that the scheduler only returns the first failure reason. ([#86022](https://github.com/kubernetes/kubernetes/pull/86022), [@Huang-Wei](https://github.com/Huang-Wei)) -* kubectl/drain: add skip-wait-for-delete-timeout option. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino)) - * If pod DeletionTimestamp older than N seconds, skip waiting for the pod. Seconds must be greater than 0 to skip. -* Following metrics have been turned off: ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango)) - * - kubelet_pod_worker_latency_microseconds - * - kubelet_pod_start_latency_microseconds - * - kubelet_cgroup_manager_latency_microseconds - * - kubelet_pod_worker_start_latency_microseconds - * - kubelet_pleg_relist_latency_microseconds - * - kubelet_pleg_relist_interval_microseconds - * - kubelet_eviction_stats_age_microseconds - * - kubelet_runtime_operations - * - kubelet_runtime_operations_latency_microseconds - * - kubelet_runtime_operations_errors - * - kubelet_device_plugin_registration_count - * - kubelet_device_plugin_alloc_latency_microseconds - * - kubelet_docker_operations - * - kubelet_docker_operations_latency_microseconds - * - kubelet_docker_operations_errors - * - kubelet_docker_operations_timeout - * - network_plugin_operations_latency_microseconds -* - Renamed Kubelet metric certificate_manager_server_expiration_seconds to certificate_manager_server_ttl_seconds and changed to report the second until expiration at read time rather than absolute time of expiry. ([#85874](https://github.com/kubernetes/kubernetes/pull/85874), [@sambdavidson](https://github.com/sambdavidson)) - * - Improved accuracy of Kubelet metric rest_client_exec_plugin_ttl_seconds. -* Bind metadata-agent containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210)) -* Bind metrics-server containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210)) -* During initialization phase (preflight), kubeadm now verifies the presence of the conntrack executable ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni)) -* VMSS cache is added so that less chances of VMSS GET throttling ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19)) -* Update go-winio module version from 0.4.11 to 0.4.14 ([#85739](https://github.com/kubernetes/kubernetes/pull/85739), [@wawa0210](https://github.com/wawa0210)) -* Fix LoadBalancer rule checking so that no unexpected LoadBalancer updates are made ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer)) -* kubectl drain node --dry-run will list pods that would be evicted or deleted ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom)) -* Windows nodes on GCE can use TPM-based authentication to the master. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh)) -* kubectl/drain: add disable-eviction option. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino)) - * Force drain to use delete, even if eviction is supported. This will bypass checking PodDisruptionBudgets, and should be used with caution. -* kubeadm now errors out whenever a not supported component config version is supplied for the kubelet and kube-proxy ([#85639](https://github.com/kubernetes/kubernetes/pull/85639), [@rosti](https://github.com/rosti)) -* Fixed issue with addon-resizer using deprecated extensions APIs ([#85793](https://github.com/kubernetes/kubernetes/pull/85793), [@bskiba](https://github.com/bskiba)) -* Includes FSType when describing CSI persistent volumes. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca)) -* kubelet now exports a "server_expiration_renew_failure" and "client_expiration_renew_failure" metric counter if the certificate rotations cannot be performed. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips)) -* kubeadm: don't write the kubelet environment file on "upgrade apply" ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa)) -* fix azure file AuthorizationFailure ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx)) -* Resolved regression in admission, authentication, and authorization webhook performance in v1.17.0-rc.1 ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt)) -* kubeadm: uses the apiserver AdvertiseAddress IP family to choose the etcd endpoint IP family for non external etcd clusters ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea)) -* kubeadm: Forward cluster name to the controller-manager arguments ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre)) -* Fixed "requested device X but found Y" attach error on AWS. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane)) -* addons: elasticsearch discovery supports IPv6 ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu)) -* kubeadm: retry `kubeadm-config` ConfigMap creation or mutation if the apiserver is not responding. This will improve resiliency when joining new control plane nodes. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre)) -* Update Cluster Autoscaler to 1.17.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.17.0 ([#85610](https://github.com/kubernetes/kubernetes/pull/85610), [@losipiuk](https://github.com/losipiuk)) -* Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) -* kubectl set resources will no longer return an error if passed an empty change for a resource. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) - * kubectl set subject will no longer return an error if passed an empty change for a resource. -* kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) -* kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) -* kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) -* kube-apiserver: Fixes a bug that hidden metrics can not be enabled by the command-line option `--show-hidden-metrics-for-version`. ([#85444](https://github.com/kubernetes/kubernetes/pull/85444), [@RainbowMango](https://github.com/RainbowMango)) -* kubeadm now supports automatic calculations of dual-stack node cidr masks to kube-controller-manager. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) -* Fix bug where EndpointSlice controller would attempt to modify shared objects. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott)) -* Use context to check client closed instead of http.CloseNotifier in processing watch request which will reduce 1 goroutine for each request if proto is HTTP/2.x . ([#85408](https://github.com/kubernetes/kubernetes/pull/85408), [@answer1991](https://github.com/answer1991)) -* kubeadm: reset raises warnings if it cannot delete folders ([#85265](https://github.com/kubernetes/kubernetes/pull/85265), [@SataQiu](https://github.com/SataQiu)) -* Wait for kubelet & kube-proxy to be ready on Windows node within 10s ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031)) 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/_index.md b/content/ko/docs/tasks/access-application-cluster/_index.md index 603b186517..3576ebd0a6 100755 --- a/content/ko/docs/tasks/access-application-cluster/_index.md +++ b/content/ko/docs/tasks/access-application-cluster/_index.md @@ -1,5 +1,5 @@ --- -title: "클러스터 내 어플리케이션 액세스" +title: "클러스터 내 어플리케이션 접근" description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다. weight: 60 --- 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..c433384f05 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -1,5 +1,5 @@ --- -title: 클러스터 액세스 +title: 클러스터 접근 weight: 20 content_type: concept --- @@ -8,17 +8,14 @@ content_type: concept 여기에서는 클러스터와 통신을 하는 다양한 방식에 대해서 다룰 것이다. - - - -## 처음이라면 kubectl을 사용하여 액세스 +## 처음이라면 kubectl을 사용하여 접근 -최초로 쿠버네티스 API에 액세스할 때 우리는 +최초로 쿠버네티스 API에 접근할 때 우리는 쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다. -클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 +클러스터에 접근하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 인증정보를 가져야 한다. 일반적으로 이는 당신이 [Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다. @@ -29,14 +26,15 @@ 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에 직접 액세스 +## REST API에 직접 접근 kubectl은 apiserver의 위치 파악과 인증을 처리한다. 만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로 -REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다. +REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다. - kubectl을 proxy 모드로 실행. - 권장하는 접근 방식. @@ -155,7 +153,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터 는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. 이 방식들은 미래의 고가용성 지원과 충돌될 수 있다. -## API에 프로그래밍 방식으로 액세스 +## API에 프로그래밍 방식으로 접근 쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트) 클라이언트 라이브러리를 지원한다. @@ -165,16 +163,16 @@ 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-액세스)을 참조하기를 바란다. +만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-접근)을 참조하기를 바란다. ### Python 클라이언트 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)를 참조한다. ### 다른 언어 @@ -182,7 +180,7 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 다른 언어에서 API를 접속하기 위한 [클라이언트 라이브러리들](/ko/docs/reference/using-api/client-libraries/)도 존재한다. 이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다. -## 파드에서 API 액세스 +## 파드에서 API 접근 파드에서 API를 접속한다면 apiserver의 위치지정과 인증은 다소 다르다. @@ -215,11 +213,13 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. 각각의 사례에서 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들로 라우팅되지 않아서 접근을 할 수 없을 것이다. @@ -228,9 +228,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. 클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다. - - 공인 IP를 통해 서비스에 액세스. + - 공인 IP를 통해 서비스에 접근. - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 - 서비스를 사용한다. [서비스](/docs/user-guide/services)와 + 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. @@ -238,19 +238,19 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다. - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 - 액세스할 필요는 없다. - - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스. - - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. + 접근할 필요는 없다. + - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근. + - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다. 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 - 액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다. + 접근을 하려고 하거나 debugging을 하려면 이를 사용한다. - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다. - HTTP/HTTPS에서만 동작한다. - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - - 클러스터 내 노드 또는 파드에서 액세스. + - 클러스터 내 노드 또는 파드에서 접근. - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. 해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다. - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 - 클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 + 클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. ### 빌트인 서비스들의 발견 @@ -273,10 +273,10 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy ``` -이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다. +이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다. 예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로 -`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다. +`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로 +`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다. (인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) #### 수작업으로 apiserver proxy URL을 구축 @@ -298,8 +298,8 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. ##### 예제들 - * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. - * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. + * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. + * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. ```json { @@ -316,7 +316,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. } ``` -### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 액세스 +### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근 브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만 @@ -333,7 +333,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy 쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다. -1. [kubectl proxy](#rest-api에-직접-액세스): +1. [kubectl proxy](#rest-api에-직접-접근): - 사용자의 데스크탑이나 파드 내에서 실행한다 - localhost 주소에서 쿠버네티스 apiserver로 proxy한다 @@ -375,3 +375,4 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy 일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는 나머지 타입을 적절하게 구성해줘야 한다. + 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..40e0a05fcf 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..b57e07db65 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,22 +188,11 @@ 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)를 참조하라. ## 고급 주제들 -### 다른 API 버전으로 업그레이드 - -신규 API 버전이 릴리스 되었을 때, 해당 신규 API 버전을 지원하려면 클러스터를 업그레이드해야 할 수 있다.(예. 'v2'가 출시되었을 때 'v1'에서 'v2'로 변경) - -이는 드문 경우지만 세심한 관리가 요구된다. 신규 API 버전으로 업그레이드하는데는 일련의 과정이 존재한다. - - 1. 신규 API 버전을 ON한다. - 1. 신규 버전을 사용하도록 클러스터의 스토리지를 업그레이드한다. - 1. 모든 구성 파일들을 업그레이드한다. 구식 API 버전 엔드포인트의 사용자들을 식별한다. - 1. `cluster/update-storage-objects.sh`을 실행하여 스토리지 내에 기존 객체들을 신규 버전으로 업데이트한다. - 1. 구식 API 버전을 OFF한다. - ### 클러스터에서 API 버전을 ON/OFF 하기 특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 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..60d010936e 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -2,17 +2,18 @@ title: kubeadm 클러스터 업그레이드 content_type: task weight: 20 -min-kubernetes-server-version: 1.18 +min-kubernetes-server-version: 1.19 --- 이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를 -1.17.x 버전에서 1.18.x 버전으로, 1.18.x 버전에서 1.18.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. +1.18.x 버전에서 1.19.x 버전으로, 1.19.x 버전에서 1.19.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면, 이 페이지 대신 다음의 페이지들을 참고한다. +- [kubeadm 클러스터를 1.17에서 1.18로 업그레이드](https://v1-18.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/) @@ -24,12 +25,9 @@ min-kubernetes-server-version: 1.18 1. 추가 컨트롤 플레인 노드를 업그레이드한다. 1. 워커(worker) 노드를 업그레이드한다. - - ## {{% heading "prerequisites" %}} - -- 1.17.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다. +- 1.18.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다. - [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). - 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다. - [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다. @@ -43,25 +41,23 @@ min-kubernetes-server-version: 1.18 또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다. 예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다. - - ## 업그레이드할 버전 결정 -최신의 안정 버전인 1.18을 찾는다. +최신의 안정 버전인 1.19를 찾는다. {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} apt update apt-cache madison kubeadm - # 목록에서 최신 버전 1.18을 찾는다 - # 1.18.x-00과 같아야 한다. 여기서 x는 최신 패치이다. + # 목록에서 최신 버전 1.19를 찾는다 + # 1.19.x-00과 같아야 한다. 여기서 x는 최신 패치이다. {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes - # 목록에서 최신 버전 1.18을 찾는다 - # 1.18.x-0과 같아야 한다. 여기서 x는 최신 패치이다. + # 목록에서 최신 버전 1.19를 찾는다 + # 1.19.x-0과 같아야 한다. 여기서 x는 최신 패치이다. {{% /tab %}} {{< /tabs >}} @@ -73,18 +69,18 @@ min-kubernetes-server-version: 1.18 {{< tabs name="k8s_install_kubeadm_first_cp" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # 1.18.x-00에서 x를 최신 패치 버전으로 바꾼다. + # 1.19.x-00에서 x를 최신 패치 버전으로 바꾼다. apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ + apt-get update && apt-get install -y kubeadm=1.19.x-00 && \ apt-mark hold kubeadm - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 + apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} - # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다. - yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes + # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다. + yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -116,33 +112,45 @@ min-kubernetes-server-version: 1.18 [preflight] Running pre-flight checks. [upgrade] Running cluster health checks [upgrade] Fetching available versions to upgrade to - [upgrade/versions] Cluster version: v1.17.3 - [upgrade/versions] kubeadm version: v1.18.0 - [upgrade/versions] Latest stable version: v1.18.0 - [upgrade/versions] Latest version in the v1.17 series: v1.18.0 + [upgrade/versions] Cluster version: v1.18.4 + [upgrade/versions] kubeadm version: v1.19.0 + [upgrade/versions] Latest stable version: v1.19.0 + [upgrade/versions] Latest version in the v1.18 series: v1.19.0 Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply': COMPONENT CURRENT AVAILABLE - Kubelet 1 x v1.17.3 v1.18.0 + Kubelet 1 x v1.18.4 v1.19.0 - Upgrade to the latest version in the v1.17 series: + Upgrade to the latest version in the v1.18 series: COMPONENT CURRENT AVAILABLE - API Server v1.17.3 v1.18.0 - Controller Manager v1.17.3 v1.18.0 - Scheduler v1.17.3 v1.18.0 - Kube Proxy v1.17.3 v1.18.0 - CoreDNS 1.6.5 1.6.7 - Etcd 3.4.3 3.4.3-0 + API Server v1.18.4 v1.19.0 + Controller Manager v1.18.4 v1.19.0 + Scheduler v1.18.4 v1.19.0 + Kube Proxy v1.18.4 v1.19.0 + CoreDNS 1.6.7 1.7.0 + Etcd 3.4.3-0 3.4.7-0 You can now apply the upgrade by executing the following command: - kubeadm upgrade apply v1.18.0 + kubeadm upgrade apply v1.19.0 _____________________________________________________________________ + + 아래 표는 이 버전의 kubeadm에서 이해하는 컴포넌트 구성의 현재 상태를 보여준다. + "MANUAL UPGRADE REQUIRED" 열에 "yes" 표시가 있는 구성은 성공적인 업그레이드를 + 수행하기 전에 수동 구성 업그레이드 또는 kubeadm 기본값으로 재설정이 필요하다. 수동으로 + 업그레이드할 버전은 "PREFERRED VERSION" 열에 표시된다. + + API GROUP CURRENT VERSION PREFERRED VERSION MANUAL UPGRADE REQUIRED + kubeproxy.config.k8s.io v1alpha1 v1alpha1 no + kubelet.config.k8s.io v1beta1 v1beta1 no + _____________________________________________________________________ + ``` 이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다. + 또한 컴포넌트 구성 버전 상태가 있는 표를 보여준다. {{< note >}} 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다. @@ -150,11 +158,17 @@ min-kubernetes-server-version: 1.18 자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다. {{}} +{{< note >}} +`kubeadm upgrade plan` 이 수동 업그레이드가 필요한 컴포넌트 구성을 표시하는 경우, 사용자는 +`--config` 커맨드 라인 플래그를 통해 대체 구성이 포함된 구성 파일을 `kubeadm upgrade apply` 에 제공해야 한다. +그렇게 하지 않으면 `kubeadm upgrade apply` 가 오류와 함께 종료되고 업그레이드를 수행하지 않는다. +{{}} + - 업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다. ```shell # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다. - sudo kubeadm upgrade apply v1.18.x + sudo kubeadm upgrade apply v1.19.x ``` @@ -166,75 +180,78 @@ min-kubernetes-server-version: 1.18 [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' [preflight] Running pre-flight checks. [upgrade] Running cluster health checks - [upgrade/version] You have chosen to change the cluster version to "v1.18.0" - [upgrade/versions] Cluster version: v1.17.3 - [upgrade/versions] kubeadm version: v1.18.0 + [upgrade/version] You have chosen to change the cluster version to "v1.19.0" + [upgrade/versions] Cluster version: v1.18.4 + [upgrade/versions] kubeadm version: v1.19.0 [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y - [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd] - [upgrade/prepull] Prepulling image for component etcd. - [upgrade/prepull] Prepulling image for component kube-apiserver. - [upgrade/prepull] Prepulling image for component kube-controller-manager. - [upgrade/prepull] Prepulling image for component kube-scheduler. - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager - [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd - [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd - [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler - [upgrade/prepull] Prepulled image for component etcd. - [upgrade/prepull] Prepulled image for component kube-apiserver. - [upgrade/prepull] Prepulled image for component kube-controller-manager. - [upgrade/prepull] Prepulled image for component kube-scheduler. - [upgrade/prepull] Successfully prepulled the images for all the control plane components - [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"... - Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 - Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 - Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 + [upgrade/prepull] Pulling images required for setting up a Kubernetes cluster + [upgrade/prepull] This might take a minute or two, depending on the speed of your internet connection + [upgrade/prepull] You can also perform this action in beforehand using 'kubeadm config images pull' + [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.19.0"... + Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003 + Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2 + Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a [upgrade/etcd] Upgrading to TLS for etcd - [upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue - [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012" - W0308 18:48:14.535122 3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC" + Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf + [upgrade/staticpods] Preparing for "etcd" upgrade + [upgrade/staticpods] Renewing etcd-server certificate + [upgrade/staticpods] Renewing etcd-peer certificate + [upgrade/staticpods] Renewing etcd-healthcheck-client certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/etcd.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf + Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf + Static pod: etcd-kind-control-plane hash: 59e40b2aab1cd7055e64450b5ee438f0 + [apiclient] Found 1 Pods for label selector component=etcd + [upgrade/staticpods] Component "etcd" upgraded successfully! + [upgrade/etcd] Waiting for etcd to become available + [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests999800980" [upgrade/staticpods] Preparing for "kube-apiserver" upgrade [upgrade/staticpods] Renewing apiserver certificate [upgrade/staticpods] Renewing apiserver-kubelet-client certificate [upgrade/staticpods] Renewing front-proxy-client certificate [upgrade/staticpods] Renewing apiserver-etcd-client certificate - [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml" + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-apiserver.yaml" [upgrade/staticpods] Waiting for the kubelet to restart the component [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) - Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 - Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4 + Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003 + Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003 + Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003 + Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003 + Static pod: kube-apiserver-kind-control-plane hash: f717874150ba572f020dcd89db8480fc [apiclient] Found 1 Pods for label selector component=kube-apiserver [upgrade/staticpods] Component "kube-apiserver" upgraded successfully! [upgrade/staticpods] Preparing for "kube-controller-manager" upgrade [upgrade/staticpods] Renewing controller-manager.conf certificate - [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml" + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-controller-manager.yaml" [upgrade/staticpods] Waiting for the kubelet to restart the component [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) - Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 - Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156 + Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2 + Static pod: kube-controller-manager-kind-control-plane hash: b155b63c70e798b806e64a866e297dd0 [apiclient] Found 1 Pods for label selector component=kube-controller-manager [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully! [upgrade/staticpods] Preparing for "kube-scheduler" upgrade [upgrade/staticpods] Renewing scheduler.conf certificate - [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml" + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-scheduler.yaml" [upgrade/staticpods] Waiting for the kubelet to restart the component [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) - Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 - Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d + Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a + Static pod: kube-scheduler-kind-control-plane hash: 260018ac854dbf1c9fe82493e88aec31 [apiclient] Found 1 Pods for label selector component=kube-scheduler [upgrade/staticpods] Component "kube-scheduler" upgraded successfully! [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace - [kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster - [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace + [kubelet] Creating a ConfigMap "kubelet-config-1.19" in namespace kube-system with the configuration for the kubelets in the cluster [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" + [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster + W0713 16:26:14.074656 2986 dns.go:282] the CoreDNS Configuration will not be migrated due to unsupported version of CoreDNS. The existing CoreDNS Corefile configuration and deployment has been retained. [addons] Applied essential addon: CoreDNS [addons] Applied essential addon: kube-proxy - [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy! + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.19.0". Enjoy! [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ``` @@ -276,18 +293,18 @@ sudo kubeadm upgrade apply {{< tabs name="k8s_install_kubelet" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다 apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ + apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \ apt-mark hold kubelet kubectl - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 + apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} - # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes + # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -309,18 +326,18 @@ sudo systemctl restart kubelet {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다 apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ + apt-get update && apt-get install -y kubeadm=1.19.x-00 && \ apt-mark hold kubeadm - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 + apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} - # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes + # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -355,18 +372,18 @@ sudo systemctl restart kubelet {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다 apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ + apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \ apt-mark hold kubelet kubectl - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 + apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} - # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes + # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -429,6 +446,7 @@ etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면, - 컨트롤 플레인이 정상적으로 동작한다 - 버전 차이(skew) 정책을 적용한다. - 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다. +- 컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다. - 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다. - 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다. - API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다. 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/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md new file mode 100644 index 0000000000..341739ba62 --- /dev/null +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -0,0 +1,310 @@ +--- +title: 확장을 사용한 병렬 처리 +content_type: task +min-kubernetes-server-version: v1.8 +weight: 20 +--- + + + +이 태스크는 공통 템플릿을 기반으로 하는 여러 개의 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 +실행하는 것을 보여준다. 이 접근 방식을 사용하여 일괄 작업을 병렬로 처리할 수 +있다. + +이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다. +샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다. + +이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면 +[실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다. + +## {{% heading "prerequisites" %}} + +사용자는 기본적인 내용과, 병렬 작업이 아닌 +[잡](/ko/docs/concepts/workloads/controllers/job/) 사용에 대해 익숙해야 한다. + +{{< include "task-tutorial-prereqs.md" >}} + +기본 템플릿을 사용하려면 커맨드 라인 유틸리티 `sed` 가 필요하다. + +고급 템플릿 예제를 따라하려면, [파이썬(Python)](https://www.python.org/)과 +파이썬용 Jinja2 템플릿 라이브러리의 설치가 +필요하다. + +파이썬을 설정했으면, 다음을 실행하여 Jinja2를 설치할 수 있다. + +```shell +pip install --user jinja2 +``` + + + +## 템플릿 기반의 잡 생성하기 + +먼저, 다음의 잡 템플릿을 다운로드해서 `job-tmpl.yaml` 파일로 저장한다. +다운로드할 내용은 다음과 같다. + +{{< codenew file="application/job/job-tmpl.yaml" >}} + +```shell +# job-tmpl.yaml를 다운로드하기 위해 curl을 사용한다 +curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml +``` + +다운로드한 파일은 아직 유효한 쿠버네티스 +{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}가 아니다. +대신 해당 템플릿은 사용하기 전에 채워야하는 자리 표시자가 있는 잡 오브젝트의 +YAML 표현이다. `$ITEM` 구문은 쿠버네티스에 의미가 있지 않다. + + +### 템플릿에서 매니페스트 생성하기 + +다음의 셸 스니펫은 `sed` 를 사용하여 루프 변수로 `$ITEM` 문자열을 바꾸고, +`jobs` 라는 임시 디렉터리에 기록한다. 다음과 같이 실행한다. + +```shell +# 처리할 각 항목에 대해 하나씩, 템플릿을 여러 파일로 확장한다. +mkdir ./jobs +for i in apple banana cherry +do + cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml +done +``` + +작동하는지 확인한다. + +```shell +ls jobs/ +``` + +출력 결과는 다음과 비슷하다. + +``` +job-apple.yaml +job-banana.yaml +job-cherry.yaml +``` + +모든 유형의 템플릿 언어(예를 들어, Jinja2, ERB)를 사용하거나, +프로그램을 작성하여 잡 매니페스트를 생성할 수 있다. + +### 매니페스트에서 잡 생성하기 + +다음으로, 하나의 kubectl 명령으로 모든 잡을 생성한다. + +```shell +kubectl create -f ./jobs +``` + +출력 결과는 다음과 비슷하다. + +``` +job.batch/process-item-apple created +job.batch/process-item-banana created +job.batch/process-item-cherry created +``` + +이제, 작업을 확인한다. + +```shell +kubectl get jobs -l jobgroup=jobexample +``` + +출력 결과는 다음과 비슷하다. + +``` +NAME COMPLETIONS DURATION AGE +process-item-apple 1/1 14s 22s +process-item-banana 1/1 12s 21s +process-item-cherry 1/1 12s 20s +``` + +kubectl 명령에 `-l` 옵션을 사용하면 이 잡 그룹의 +일부인 잡만 선택된다(시스템에서 관련이 없는 다른 잡이 있을 수 있음). + +파드도 동일한 {{< glossary_tooltip text="레이블 셀렉터" term_id="selector" >}}를 +사용하여 확인할 수 있다. + + +```shell +kubectl get pods -l jobgroup=jobexample +``` + +출력 결과는 다음과 비슷하다. + +``` +NAME READY STATUS RESTARTS AGE +process-item-apple-kixwv 0/1 Completed 0 4m +process-item-banana-wrsf7 0/1 Completed 0 4m +process-item-cherry-dnfu9 0/1 Completed 0 4m +``` + +이 단일 명령을 사용하여 모든 잡의 출력을 한 번에 확인할 수 있다. + +```shell +kubectl logs -f -l jobgroup=jobexample +``` + +출력 결과는 다음과 같아야 한다. + +``` +Processing item apple +Processing item banana +Processing item cherry +``` + +### 정리 {#cleanup-1} + +```shell +# 생성한 잡 제거 +# 클러스터가 자동으로 잡의 파드들을 정리 +kubectl delete job -l jobgroup=jobexample +``` + +## 고급 템플릿 파라미터 사용하기 + +[첫 번째 예제](#템플릿-기반의-잡-생성하기)에서, 템플릿의 각 인스턴스는 하나의 +파라미터를 가지고, 해당 파라미터는 잡의 이름에도 사용되었다. 그러나, +[이름](/ko/docs/concepts/overview/working-with-objects/names/#names)은 +특정 문자들만 포함하도록 제한된다. + +이런 약간 더 복잡한 예제는 [Jinja 템플릿 언어](https://palletsprojects.com/p/jinja/)를 +사용하여 각 잡에 대한 여러 파라미터로 매니페스트를 생성한 다음 +해당 매니페스트에서 오브젝트를 생성한다. + +태스크의 이 부분에서는, 한줄 파이썬 스크립트를 사용하여 +매니페스트 집합으로 템플릿을 변환한다. + +먼저, 다음의 잡 오브젝트 템플릿을 복사하고 붙여넣기하여, `job.yaml.jinja2` 파일로 저장한다. + + +```liquid +{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, + { "name": "banana", "url": "http://dbpedia.org/resource/Banana", }, + { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }] +%} +{%- for p in params %} +{%- set name = p["name"] %} +{%- set url = p["url"] %} +--- +apiVersion: batch/v1 +kind: Job +metadata: + name: jobexample-{{ name }} + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox + command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] + restartPolicy: Never +{%- endfor %} +``` + +위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해 +두 개의 파라미터를 정의한다. `for` 루프는 각 파라미터의 집합(나머지 행)에 대해 +하나의 잡 매니페스트를 방출한다. + +이 예제는 YAML의 기능에 의존한다. 하나의 YAML 파일은 여러 +문서(이 경우, 쿠버네티스 매니페스트)를 포함할 수 있으며, 행에 있는 `---` 로 +구분된다. +출력 결과를 `kubectl` 에 직접 파이프를 사용해 잡을 생성할 수 있다. + +다음으로, 이 한 줄 파이썬 프로그램을 사용하여 템플릿을 확장한다. + +```shell +alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' +``` + +`render_template` 을 사용해서 파라미터와 템플릿을 쿠버네티스 매니페스트가 +포함된 하나의 YAML 파일로 변환한다. + +```shell +# 앞에서 정의한 앨리어스(alias)가 필요하다 +cat job.yaml.jinja2 | render_template > jobs.yaml +``` + +`render_template` 스크립트가 제대로 동작하는지 확인하기 위해 `jobs.yaml` 을 +볼 수 있다. + +`render_template` 스크립트가 원하는대로 동작하는 것을 확인했다면, +스크립트의 출력 결과를 파이프를 사용하여 `kubectl` 에 보낼 수 있다. + +```shell +cat job.yaml.jinja2 | render_template | kubectl apply -f - +``` + +쿠버네티스는 생성한 잡을 수락하고 실행한다. + +### 정리 {#cleanup-2} + +```shell +# 생성한 잡 제거 +# 클러스터가 자동으로 잡이 있던 파드를 정리 +kubectl delete job -l jobgroup=jobexample +``` + + + + +## 실제 워크로드에서 잡 사용하기 + +실제 유스케이스에서, 각 잡은 동영상의 프레임을 렌더링하거나, 데이터베이스에서 행 범위를 +처리하는 것과 같은 상당한 규모의 계산을 수행한다. 동영상을 렌더링하는 경우 프레임 번호에 +`$ITEM` 을 설정한다. 데이터베이스에서 행을 처리하는 +경우, 처리할 데이터베이스 행의 범위를 나타내도록 `$ITEM` 을 설정한다. + +이번 태스크에서, 로그를 가져와 파드에서 출력 결과를 수집하는 명령어를 +실행했다. 실제 유스케이스에서, 잡의 각 파드는 완료하기 전에 출력 결과를 +내구성있는 스토리지에 기록한다. 각 잡에 대해 퍼시스턴트볼륨(PersistentVolume)을 +사용하거나 외장 스토리지 서비스를 사용할 수 있다. 예를 들어, 동영상의 프레임을 렌더링하는 경우, +HTTP를 사용하여 렌더링된 프레임 데이터를 각 프레임에 대한 다른 URL을 사용해서 URL에 `PUT` +한다. + +## 잡과 파드의 레이블 + +잡을 생성한 후, 쿠버네티스는 한 잡의 파드를 다른 잡의 파드와 구별하기 위해서 +추가 {{< glossary_tooltip text="레이블" term_id="label" >}}을 +자동으로 추가한다. + +이 예시에서, 각 잡과 잡의 파드 템플릿은 `jobgroup=jobexample` +레이블을 갖는다. + +쿠버네티스 자체는 `jobgroup` 이라는 레이블에 신경쓰지 않는다. 템플릿에서 +생성한 모든 잡에 대해 레이블을 설정하면 한번에 모든 잡을 편리하게 +조작할 수 있다. +[첫 번째 예제](#템플릿-기반의-잡-생성하기)에서 템플릿을 사용해서 +여러 잡을 생성했다. 템플릿은 각 파드도 동일한 레이블을 가질 수 있도록 보장하므로, +단일 명령어로 이러한 템플릿 기반 잡들의 모든 파드에서 확인할 수 있다. + +{{< note >}} +레이블 키 `jobgroup` 은 특별하거나 예약되어 있지 않다. +고유한 레이블링 체계를 선택할 수 있다. +원하는 경우 사용할 수 있는 +[권장 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#레이블)이 있다. +{{< /note >}} + +## 대안 + +많은 수의 잡 오브젝트의 생성을 계획 중이라면, 아마도 다음의 사항을 파악하게 될 것이다. + +- 레이블을 사용해도, 너무 많은 잡을 관리하는 것은 번거롭다. +- 일괄적으로 많은 잡을 생성하는 경우, 쿠버네티스 컨트롤 플레인에 + 높음 부하를 가할 수 있다. 대안으로, 쿠버네티스 API 서버가 + 속도를 제한하여 429 상태의 사용자 요청을 일시적으로 거부할 수 있다. +- 사용자는 잡의 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}로 + 제한될 수 있다. 한번에 많은 작업을 생성하면 API 서버가 사용자의 요청 중 + 일부를 영구적으로 거부한다. + +아주 많은 잡 오브젝트를 생성하지 않고 많은 양의 작업을 처리하는데 사용할 수 있는 +다른 [잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)도 +있다. + +잡 오브젝트를 자동으로 관리하기 위해 자체 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 +작성하는 것도 고려할 수 있다. 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-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index 515b9c2cdd..ececc7beee 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -115,4 +115,4 @@ glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize` [기능 -게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다. +게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 비활성화할 수 있다. 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/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md index 7f7422411c..b23bf2a600 100644 --- a/content/ko/docs/tasks/tls/certificate-rotation.md +++ b/content/ko/docs/tasks/tls/certificate-rotation.md @@ -10,7 +10,7 @@ content_type: task 이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다. -{{< feature-state for_k8s_version="v1.8" state="beta" >}} +{{< feature-state for_k8s_version="v1.19" state="stable" >}} ## {{% heading "prerequisites" %}} @@ -39,13 +39,11 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다. `kubelet` 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라 kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는 `--rotate-certificates` 인자를 허용한다. -인증서 갱신은 베타 기능이므로 기능 플래그는 -`--feature-gates = RotateKubeletClientCertificate=true` 를 사용하여 활성화해야 한다. `kube-controller-manager` 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는 -`--experimental-cluster-signing-duration` 인자를 -허용한다. +`--cluster-signing-duration` (1.19 이전은 `--experimental-cluster-signing-duration`) +인자를 허용한다. ## 인증서 갱신 구성에 대한 이해 @@ -62,7 +60,7 @@ kubectl get csr 인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가 자동으로 승인한 후 상태가 `Approved` 가 된다. 다음으로, 컨트롤러 관리자는 -`--experimental-cluster-signing-duration` 파라미터에 의해 지정된 기간 동안 +`--cluster-signing-duration` 파라미터에 의해 지정된 기간 동안 발행된 인증서에 서명하고 서명된 인증서는 인증서 서명 요청에 첨부된다. @@ -77,7 +75,3 @@ kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서 kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다. 그런 다음 새로운 인증서를 사용한 재연결을 위해서 가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다. - - - - 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/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 803b58594c..74008f9961 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -1,6 +1,7 @@ --- -title: AppArmor +title: AppArmor를 사용하여 리소스에 대한 컨테이너의 접근 제한 content_type: tutorial +weight: 10 --- @@ -77,7 +78,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 3. 컨테이너 런타임이 AppArmor을 지원한다. -- 현재 모든 일반적인 쿠버네티스를 지원하는 {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="cri-o" >}} 또는 -{{< glossary_tooltip term_id="containerd" >}} 와 같은 컨테이너 런타임들은 AppArmor를 지원해야 한다. +{{< glossary_tooltip term_id="containerd" >}} 와 같은 컨테이너 런타임들은 AppArmor를 지원해야 한다. 이 런타임 설명서를 참조해서 클러스터가 AppArmor를 사용하기 위한 요구 사항을 충족하는지 확인해야 한다. @@ -469,5 +470,3 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나 * [퀵 가이드 AppArmor 프로파일 언어](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) * [AppArmor 코어 정책 참고](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) - - 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 1e91a85de7..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 ``` ``` @@ -199,7 +199,7 @@ client_address=10.240.0.3 * 클라이언트는 `node2:nodePort`로 패킷을 보낸다. * `node2`는 소스 IP 주소(SNAT)를 패킷 상에서 자신의 IP 주소로 교체한다. -* `node2`는 대상 IP를 패킷 상에서 파드의 IP로 교체한다. +* `noee2`는 대상 IP를 패킷 상에서 파드의 IP로 교체한다. * 패킷은 node 1로 라우팅 된 다음 엔드포인트로 라우팅 된다. * 파드의 응답은 node2로 다시 라우팅된다. * 파드의 응답은 클라이언트로 다시 전송된다. @@ -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/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" %}} diff --git a/content/ko/examples/application/job/job-tmpl.yaml b/content/ko/examples/application/job/job-tmpl.yaml new file mode 100644 index 0000000000..790025b38b --- /dev/null +++ b/content/ko/examples/application/job/job-tmpl.yaml @@ -0,0 +1,18 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: process-item-$ITEM + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox + command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"] + restartPolicy: Never diff --git a/content/ko/examples/service/networking/external-lb.yaml b/content/ko/examples/service/networking/external-lb.yaml new file mode 100644 index 0000000000..adcf7a2fd0 --- /dev/null +++ b/content/ko/examples/service/networking/external-lb.yaml @@ -0,0 +1,10 @@ +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb +spec: + controller: example.com/ingress-controller + parameters: + apiGroup: k8s.example.com + kind: IngressParameters + name: external-lb diff --git a/content/ko/examples/service/networking/ingress-resource-backend.yaml b/content/ko/examples/service/networking/ingress-resource-backend.yaml new file mode 100644 index 0000000000..87b6bbd0f3 --- /dev/null +++ b/content/ko/examples/service/networking/ingress-resource-backend.yaml @@ -0,0 +1,20 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: ingress-resource-backend +spec: + defaultBackend: + resource: + apiGroup: k8s.example.com + kind: StorageBucket + name: static-assets + rules: + - http: + paths: + - path: /icons + pathType: ImplementationSpecific + backend: + resource: + apiGroup: k8s.example.com + kind: StorageBucket + name: icon-assets diff --git a/content/ko/examples/service/networking/ingress-wildcard-host.yaml b/content/ko/examples/service/networking/ingress-wildcard-host.yaml new file mode 100644 index 0000000000..2be7016706 --- /dev/null +++ b/content/ko/examples/service/networking/ingress-wildcard-host.yaml @@ -0,0 +1,26 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: ingress-wildcard-host +spec: + rules: + - host: "foo.bar.com" + http: + paths: + - pathType: Prefix + path: "/bar" + backend: + service: + name: service1 + port: + number: 80 + - host: "*.foo.com" + http: + paths: + - pathType: Prefix + path: "/foo" + backend: + service: + name: service2 + port: + number: 80 diff --git a/content/ko/examples/service/networking/ingress.yaml b/content/ko/examples/service/networking/ingress.yaml deleted file mode 100644 index 56a0d5138f..0000000000 --- a/content/ko/examples/service/networking/ingress.yaml +++ /dev/null @@ -1,9 +0,0 @@ -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: test-ingress -spec: - backend: - serviceName: testsvc - servicePort: 80 - diff --git a/content/ko/examples/service/networking/minimal-ingress.yaml b/content/ko/examples/service/networking/minimal-ingress.yaml new file mode 100644 index 0000000000..76640b9447 --- /dev/null +++ b/content/ko/examples/service/networking/minimal-ingress.yaml @@ -0,0 +1,17 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: minimal-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - http: + paths: + - path: /testpath + pathType: Prefix + backend: + service: + name: test + port: + number: 80 diff --git a/content/ko/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml b/content/ko/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml new file mode 100644 index 0000000000..16a560b1ff --- /dev/null +++ b/content/ko/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml @@ -0,0 +1,35 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: name-virtual-host-ingress-no-third-host +spec: + rules: + - host: first.bar.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service1 + port: + number: 80 + - host: second.bar.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service2 + port: + number: 80 + - http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service3 + port: + number: 80 diff --git a/content/ko/examples/service/networking/name-virtual-host-ingress.yaml b/content/ko/examples/service/networking/name-virtual-host-ingress.yaml new file mode 100644 index 0000000000..213a73d261 --- /dev/null +++ b/content/ko/examples/service/networking/name-virtual-host-ingress.yaml @@ -0,0 +1,26 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: name-virtual-host-ingress +spec: + rules: + - host: foo.bar.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service1 + port: + number: 80 + - host: bar.foo.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service2 + port: + number: 80 diff --git a/content/ko/examples/service/networking/simple-fanout-example.yaml b/content/ko/examples/service/networking/simple-fanout-example.yaml new file mode 100644 index 0000000000..19fef9455b --- /dev/null +++ b/content/ko/examples/service/networking/simple-fanout-example.yaml @@ -0,0 +1,23 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: simple-fanout-example +spec: + rules: + - host: foo.bar.com + http: + paths: + - path: /foo + pathType: Prefix + backend: + service: + name: service1 + port: + number: 4200 + - path: /bar + pathType: Prefix + backend: + service: + name: service2 + port: + number: 8080 diff --git a/content/ko/examples/service/networking/test-ingress.yaml b/content/ko/examples/service/networking/test-ingress.yaml new file mode 100644 index 0000000000..acd384ab56 --- /dev/null +++ b/content/ko/examples/service/networking/test-ingress.yaml @@ -0,0 +1,10 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: test-ingress +spec: + defaultBackend: + service: + name: test + port: + number: 80 diff --git a/content/ko/examples/service/networking/tls-example-ingress.yaml b/content/ko/examples/service/networking/tls-example-ingress.yaml new file mode 100644 index 0000000000..fe5d52a0cb --- /dev/null +++ b/content/ko/examples/service/networking/tls-example-ingress.yaml @@ -0,0 +1,20 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: tls-example-ingress +spec: + tls: + - hosts: + - https-example.foo.com + secretName: testsecret-tls + rules: + - host: https-example.foo.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: service1 + port: + number: 80