From 62a3baf06cb94c408298d8a6b39564c4cf4f7579 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Mon, 15 Nov 2021 03:53:10 +0900 Subject: [PATCH 01/12] Fix outdated in ko architecture/nodes --- .../ko/docs/concepts/architecture/nodes.md | 78 +++++++++++++------ 1 file changed, 55 insertions(+), 23 deletions(-) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 5ceb5d98ce..09e2264a80 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -72,15 +72,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록 [이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는 동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가 동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한 -상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가 +상태(예: 네트워크 설정, 루트 디스크 내용)와 노드 레이블과 같은 동일한 속성(attribute)을 +갖는다고 암시적으로 가정한다. 인스턴스가 이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나 업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고 업데이트 후 다시 추가해야 한다. -### 노드에 대한 자체-등록 +### 노드에 대한 자체-등록(self-registration) -kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 -스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다. +kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API 서버에 +스스로 등록을 시도할 것이다. 이는 선호되는 패턴이며, 대부분의 배포판에서 사용된다. 자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다. @@ -96,7 +97,22 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API [Node authorization mode](/docs/reference/access-authn-authz/node/)와 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면, -kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다. +kubelets은 자신의 노드 리소스를 생성/수정할 권한을 가진다. + +{{< note >}} +[노드 이름 고유성](#노드-이름-고유성) 섹션에서 언급했듯이, +노드 구성을 업데이트해야 하는 경우 API 서버에 노드를 +다시 등록하는 것이 좋다. 예를 들어 kubelet이 `--node-labels`의 새로운 구성으로 +다시 시작되더라도, 동일한 노드 이름이 사용된 경우 +레이블이 해당 노드의 등록에 설정되기 때문에 변경 사항이 적용되지 않는다. + +노드에 이미 스케줄된 파드는 해당 노드 구성이 kubelet 재시작에 의해 변경된 경우 +오작동하거나 문제를 일으킬 수 있다. 예를 들어 이미 실행 중인 파드가 노드에 +할당된 새 레이블에 대해 테인트(taint)될 수 있는 반면 해당 파드와 호환되지 않는 다른 파드는 +새 레이블을 기반으로 스케줄링된다. 노드 재-등록(re-registration)은 모든 파드를 +비우고(drain) 다시 적절하게 스케줄링되도록 +한다. +{{< /note >}} #### 수동 노드 관리 @@ -177,7 +193,8 @@ kubectl describe node 대신 코드화된 노드는 사양에 스케줄 불가로 표시된다. {{< /note >}} -쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다. +쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 +표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다. ```json "conditions": [ @@ -209,10 +226,12 @@ API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 -API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. +API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 +낳는다. 노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는 -[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. +[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 +생성한다. 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. 또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 {{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다. @@ -235,9 +254,11 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 ### 정보 -커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다. - -이 정보는 Kubelet이 노드로부터 수집해서 쿠버네티스 API로 이를 보낸다. +커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 +런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 +노드에 대한 일반적인 정보가 기술된다. +이 정보는 Kubelet이 노드로부터 수집해서 +쿠버네티스 API로 이를 보낸다. ## 하트비트 @@ -248,20 +269,25 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 * 노드의 `.status`에 대한 업데이트 * `kube-node-lease` - {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트. - 각 노드는 연관된 리스 오브젝트를 갖는다. + {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} + 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) + 오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다. 노드의 `.status`와 비교해서, 리스는 경량의 리소스이다. -큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 필요한 성능 영향도를 줄일 수 있다. +큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 +필요한 성능 영향도를 줄일 수 있다. kubelet은 노드의 `.status` 생성과 업데이트 및 관련된 리스의 업데이트를 담당한다. -- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 `.status`를 업데이트한다. - 노드의 `.status` 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다. -- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다. - 리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다. - 만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다. +- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 + 노드의 `.status`를 업데이트한다. 노드의 `.status` 업데이트에 대한 기본 + 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 + 40초 보다 훨씬 긴 5분이다. +- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 + 생성하고 업데이트한다. 리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다. + 만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 + 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다. ### 노드 컨트롤러 @@ -280,11 +306,14 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 다음을 담당한다. -- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다. +- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` + 내에 있는 NodeReady 컨디션을 업데이트한다. 이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다. - 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서 - [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다. - 기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다. + [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 + 트리거한다. 기본적으로, 노드 컨트롤러는 노드를 + `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 + 최초의 축출 요청을 시작한다. 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. @@ -315,7 +344,10 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 `--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다. -이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.) +이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 +있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 +다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 +나머지 노드에서 파드를 축출한다.) 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의 노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다. From 4616e63617705c2b1c2b630b0604d8261971750b Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Mon, 15 Nov 2021 04:14:38 +0900 Subject: [PATCH 02/12] Update outdated in dev-1.22-ko.3 (M2-M3) --- .../cluster-administration/networking.md | 8 +------ .../docs/concepts/extend-kubernetes/_index.md | 23 +++++++++++-------- 2 files changed, 14 insertions(+), 17 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 3f6e103ba7..545c26f420 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -145,7 +145,7 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네 ### 콘티브(Contiv) -[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다. +[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. ### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric) @@ -260,12 +260,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https:// [NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. -### Nuage Networks VCS(가상 클라우드 서비스) - -[Nuage](https://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다. - -Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다. - ### OpenVSwitch [OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만 diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index 95c61079dd..79466e8df3 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -2,6 +2,11 @@ title: 쿠버네티스 확장 weight: 110 description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법 + + + + + feature: title: 확장성을 고려하여 설계됨 description: > @@ -47,9 +52,9 @@ no_list: true 익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다. 이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. -대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. -결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고 -새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. +많은 클러스터 관리자가 호스팅 또는 배포판 쿠버네티스 인스턴스를 사용한다. +이러한 클러스터들은 미리 설치된 익스텐션을 포함한다. 결과적으로 대부분의 +쿠버네티스 사용자는 익스텐션을 설치할 필요가 없고, 새로운 익스텐션을 만들 필요가 있는 사용자는 더 적다. ## 익스텐션 패턴 @@ -74,14 +79,12 @@ no_list: true 바이너리 플러그인은 kubelet(예: [Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 -kubectl에서 -사용한다. +kubectl에서 사용한다. 아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을 보여주는 다이어그램이다. - ![익스텐션 포인트와 컨트롤 플레인](/ko/docs/concepts/extend-kubernetes/control-plane.png) ## 익스텐션 포인트 @@ -89,7 +92,6 @@ kubectl에서 이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다. - ![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png) 1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. @@ -103,10 +105,10 @@ kubectl에서 어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. - ![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png) ## API 익스텐션 + ### 사용자 정의 유형 새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자. @@ -155,7 +157,6 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ## 인프라스트럭처 익스텐션 - ### 스토리지 플러그인 [Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면 @@ -172,7 +173,8 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 ### 네트워크 플러그인 -노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. +노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. ### 스케줄러 익스텐션 @@ -200,3 +202,4 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) * [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 * [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 + From 7373ffe1fdcc72f77d3f99e757c2d61848be2c51 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Mon, 15 Nov 2021 05:40:16 +0900 Subject: [PATCH 03/12] Apply 1.21-ko.2 enhancement to 1.22-ko.3 --- content/ko/docs/concepts/architecture/nodes.md | 4 ++-- .../ko/docs/concepts/configuration/secret.md | 2 +- content/ko/docs/concepts/containers/_index.md | 2 +- .../compute-storage-net/network-plugins.md | 2 +- .../overview/working-with-objects/labels.md | 6 +++--- .../scheduling-eviction/assign-pod-node.md | 2 +- .../pod-priority-preemption.md | 4 ++-- .../connect-applications-service.md | 4 ++-- .../services-networking/dns-pod-service.md | 2 +- .../services-networking/network-policies.md | 2 +- .../services-networking/service-topology.md | 2 +- content/ko/docs/concepts/storage/volumes.md | 2 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/deployment.md | 6 +++--- .../docs/concepts/workloads/controllers/job.md | 2 +- .../workloads/controllers/replicaset.md | 10 +++++----- .../change-default-storage-class.md | 2 +- .../horizontal-pod-autoscale-walkthrough.md | 2 +- .../horizontal-pod-autoscale.md | 2 +- content/ko/docs/tutorials/clusters/apparmor.md | 18 +++++++++--------- 20 files changed, 39 insertions(+), 39 deletions(-) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 5ceb5d98ce..b6bf9c1ac7 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -51,7 +51,7 @@ weight: 10 ``` 쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는 -kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다. +kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어 있는지 확인한다. 노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다. 그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에 대해 무시된다. @@ -146,7 +146,7 @@ kubectl cordon $NODENAME kubectl describe node ``` -출력되는 각 섹션은 아래에 설명되어있다. +출력되는 각 섹션은 아래에 설명되어 있다. ### 주소 {#addresses} diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 8c0630c4b2..891e1def90 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -37,7 +37,7 @@ weight: 30 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/). 2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/) 활성화 또는 구성. -3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다. +3. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다. {{< /caution >}} diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md index fa56660f1a..7d37a1c4f3 100644 --- a/content/ko/docs/concepts/containers/_index.md +++ b/content/ko/docs/concepts/containers/_index.md @@ -22,7 +22,7 @@ no_list: true ## 컨테이너 이미지 [컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을 -실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다. +실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어 있는(ready-to-run) 소프트웨어 패키지이다. 여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리, 그리고 모든 필수 설정에 대한 기본값이 포함된다. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 359284b357..ce53f997c8 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -85,7 +85,7 @@ CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도 플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다. 트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을 -추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어있는지 확인한다. +추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어 있는지 확인한다. ```json { diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 571c62b7db..76eda67392 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -50,7 +50,7 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시 접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다. -`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다. +`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어 있다. 유효한 레이블 값은 다음과 같다. * 63 자 이하여야 하고 (공백일 수도 있음), @@ -95,7 +95,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 {{< /note >}} {{< caution >}} -일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다. +일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다. {{< /caution >}} ### _일치성 기준_ 요건 @@ -231,7 +231,7 @@ selector: - {key: environment, operator: NotIn, values: [dev]} ``` -`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다. +`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다. #### 노드 셋 선택 diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index d64358ec64..0d099b13e7 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -265,7 +265,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다. `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다). -생략되어있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다. +생략되어 있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다. 파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와 연관된 `matchExpressions` 가 모두 충족되어야 한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index 6df4ec16b4..96a8f005b1 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -357,11 +357,11 @@ kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure) 사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지 예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다. - 1. 부족한 리소스 사용량이 요청을 초과하는지 여부 + 1. 기아(starved) 리소스 사용량이 요청을 초과하는지 여부 1. 파드 우선순위 1. 요청 대비 리소스 사용량 -더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을 +더 자세한 내용은 [kubelet 축출을 위한 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을 참조한다. kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우 diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 2b70f86d54..bb7a9154c3 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -56,7 +56,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP 평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다. -쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다. +쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어 있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다. `kubectl expose` 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다. @@ -346,7 +346,7 @@ kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert 노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와 LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 `NodePort` 를 사용했기에 노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할 -준비가 되어있다. +준비가 되어 있다. ```shell kubectl get svc my-nginx -o yaml | grep nodePort -C 5 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 5b8dada435..3544d7e745 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -233,7 +233,7 @@ DNS 정책은 파드별로 설정할 수 있다. 자세한 내용을 확인할 수 있다. {{< note >}} -"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 +"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어 있지 않다면 "ClusterFirst"가 기본값으로 사용된다. {{< /note >}} diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index bd1bc328f8..6ce089d72f 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -96,7 +96,7 @@ __podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드 __policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다. -__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. +__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어 있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. __egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index 47799ba9f7..8814c772c7 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -96,7 +96,7 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노 * 유효한 토폴로지 키는 현재 `kubernetes.io/hostname`, `topology.kubernetes.io/zone` 그리고 `topology.kubernetes.io/region` 로 - 제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다. + 제한되어 있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다. * 토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 349f47a55c..6771f6fd01 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -358,7 +358,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다 `flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약 Flocker내에 데이터셋이 없는 경우, 먼저 Flocker CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면 -Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에 +Flocker는 파드가 스케줄 되어 있는 노드에 다시 연결한다. 이는 필요에 따라 파드 간에 데이터를 공유할 수 있다는 의미이다. {{< note >}} diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index c5a1beeb38..2514d56ab3 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -166,7 +166,7 @@ nodeAffinity: 데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다. - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 - 구성되어있다. 그들은 클라이언트들을 가지지 않는다. + 구성되어 있다. 그들은 클라이언트들을 가지지 않는다. - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 6d1a5a9568..8769e2b9fd 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -50,13 +50,13 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id= 보다 정교한 선택 규칙의 적용이 가능하다. {{< note >}} - `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 + `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어 있다. `matchLabels` 에 매핑된 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며 `value` 배열은 "value"만 포함한다. 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. {{< /note >}} -* `template` 필드에는 다음 하위 필드가 포함되어있다. +* `template` 필드에는 다음 하위 필드가 포함되어 있다. * 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다. * 파드 템플릿의 사양 또는 `.template.spec` 필드는 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 @@ -1023,7 +1023,7 @@ echo $? 디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다. -기본적으로 10으로 되어있다. +기본적으로 10으로 되어 있다. {{< note >}} 명시적으로 이 필드를 0으로 설정하면 그 결과로 디플로이먼트의 기록을 전부 초기화를 하고, diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 382495e2f6..3f1666b940 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -369,7 +369,7 @@ spec: 다른 접근 방식들은 기존에 컨테이너화된 애플리케이션에 보다 쉽게 적용할 수 있다. -여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다. +여기에 트레이드오프가 요약되어 있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다. 패턴 이름은 예시와 더 자세한 설명을 위한 링크이다. | 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? | diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 9fd3bbe794..7e02f90ef9 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -50,7 +50,7 @@ OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고 {{< codenew file="controllers/frontend.yaml" >}} -이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어있는 레플리카셋이 +이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어 있는 레플리카셋이 생성되고 레플리카셋이 관리하는 파드가 생성된다. ```shell @@ -128,7 +128,7 @@ frontend-wtsmm 1/1 Running 0 6m36s kubectl get pods frontend-b2zdv -o yaml ``` -메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다. +메타데이터의 ownerReferences 필드에 설정되어 있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다. ```shell apiVersion: v1 @@ -223,7 +223,7 @@ pod2 1/1 Running 0 36s 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다. 레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다. -쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다. +쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다. API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다. 레플리카셋 오브젝트의 이름은 유효한 @@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한 ### 파드 템플릿 -`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. +`.spec.template`은 레이블을 붙이도록 되어 있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다. 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다. @@ -269,7 +269,7 @@ matchLabels: ### 레플리카셋과 해당 파드 삭제 -레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다. +레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다. REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로 설정해야 한다. diff --git a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md index ff6379ee1f..2f64503d49 100644 --- a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md @@ -80,7 +80,7 @@ content_type: task 최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약 2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다. -1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다. +1. 사용자가 선택한 스토리지클래스가 기본값으로 되어 있는지 확인한다. ```bash kubectl get storageclass 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 1ec1db988c..9b5ea5b6cf 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 @@ -447,7 +447,7 @@ Events: 이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다. 첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지, 백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다. -두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지), +두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지), 원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우, 일반적으로 메트릭을 가져오는데 문제가 있다. 마지막으로, 마지막 조건인 `ScalingLimited`는 diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 8ceafa7d6a..96f86ac046 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -398,7 +398,7 @@ behavior: 안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을 다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터 계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다. -다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다. +다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다. ```yaml scaleDown: diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 7b11ea7722..a8facdaa67 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -346,21 +346,21 @@ Events: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다. -### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy} +### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy} {{< note >}} -PodSecurityPolicy는 쿠버네티스 v1.21에서 사용 중지되었으며, v1.25에서 제거될 예정이다. -더 자세한 내용은 [PodSecurityPolicy 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다. +파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다. +더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다. {{< /note >}} -만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다. -PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다. +만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다. +파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다. ``` --enable-admission-plugins=PodSecurityPolicy[,others...] ``` -AppArmor 옵션은 PodSecurityPolicy의 어노테이션으로 지정할 수 있다. +AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다. ```yaml apparmor.security.beta.kubernetes.io/defaultProfileName: @@ -390,7 +390,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다. ### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor} 클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다. -그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다. +그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다. 그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여 파드의 권한을 docker-default 보다 높일 수 있다. 이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된 @@ -439,7 +439,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나 ### 프로파일 참조 {#profile-reference} - `runtime/default`: 기본 런타임 프로파일을 참조한다. - - (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고 + - (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고 AppArmor를 사용하는 것과 동등하다. - 도커에서는 권한 없는 컨테이너의 경우는 [`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로, @@ -451,7 +451,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나 다른 어떤 프로파일 참조 형식도 유효하지 않다. -### PodSecurityPolicy 어노테이션 {#podsecuritypolicy-annotations} +### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations} 아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기 From 0d09bd668fb83d576dcc8c398e66d4d0928c4dc2 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 15 Nov 2021 15:11:00 +0900 Subject: [PATCH 04/12] [ko] Update links in dev-1.22-ko.3 --- .../architecture/control-plane-node-communication.md | 2 +- content/ko/docs/concepts/architecture/nodes.md | 10 +++++----- .../docs/concepts/cluster-administration/_index.md | 2 +- .../kubelet-garbage-collection.md | 2 +- content/ko/docs/concepts/configuration/secret.md | 12 ++++++------ .../concepts/containers/container-environment.md | 2 +- .../ko/docs/concepts/policy/pod-security-policy.md | 2 +- .../ko/docs/concepts/scheduling-eviction/_index.md | 2 +- .../concepts/scheduling-eviction/api-eviction.md | 2 +- .../concepts/scheduling-eviction/kube-scheduler.md | 2 +- .../scheduling-eviction/pod-priority-preemption.md | 2 +- .../services-networking/ingress-controllers.md | 2 +- .../ko/docs/concepts/services-networking/ingress.md | 4 ++-- .../services-networking/service-traffic-policy.md | 2 +- content/ko/docs/concepts/storage/volumes.md | 2 +- content/ko/docs/concepts/workloads/_index.md | 2 +- .../docs/concepts/workloads/controllers/daemonset.md | 2 +- .../concepts/workloads/controllers/deployment.md | 2 +- .../concepts/workloads/controllers/statefulset.md | 2 +- .../ko/docs/concepts/workloads/pods/disruptions.md | 4 ++-- .../concepts/workloads/pods/ephemeral-containers.md | 2 +- .../ko/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- content/ko/docs/contribute/_index.md | 2 +- content/ko/docs/contribute/advanced.md | 2 +- content/ko/docs/contribute/new-content/open-a-pr.md | 2 +- content/ko/docs/contribute/participate/_index.md | 2 +- .../participate/roles-and-responsibilities.md | 2 +- content/ko/docs/contribute/review/reviewing-prs.md | 2 +- content/ko/docs/contribute/style/write-new-topic.md | 2 +- .../command-line-tools-reference/feature-gates.md | 12 ++++++------ content/ko/docs/reference/glossary/sysctl.md | 2 +- .../docs/reference/kubectl/docker-cli-to-kubectl.md | 2 +- .../windows/user-guide-windows-containers.md | 2 +- .../access-application-cluster/web-ui-dashboard.md | 2 +- .../docs/tasks/administer-cluster/sysctl-cluster.md | 2 +- .../configure-runasusername.md | 2 +- .../debug-pod-replication-controller.md | 2 +- .../debug-application-cluster/debug-running-pod.md | 4 ++-- .../debug-application-cluster/debug-stateful-set.md | 2 +- .../define-command-argument-container.md | 2 +- .../define-environment-variable-container.md | 2 +- .../define-interdependent-environment-variables.md | 2 +- .../downward-api-volume-expose-pod-information.md | 8 ++++---- .../environment-variable-expose-pod-information.md | 4 ++-- .../docs/tasks/job/automated-tasks-with-cron-jobs.md | 2 +- .../ko/docs/tasks/manage-daemon/update-daemon-set.md | 2 +- .../tasks/run-application/delete-stateful-set.md | 4 ++-- .../run-application/force-delete-stateful-set-pod.md | 2 +- .../run-single-instance-stateful-application.md | 2 +- content/ko/docs/tutorials/hello-minikube.md | 2 +- .../mysql-wordpress-persistent-volume.md | 2 +- 51 files changed, 73 insertions(+), 73 deletions(-) diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 52fa728043..00f99d07ea 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -67,4 +67,4 @@ SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업 SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다. -[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다. +[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index b6bf9c1ac7..dd37c35a3a 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -283,7 +283,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 - 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다. 이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다. - 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서 - [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다. + [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다. 기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다. 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. @@ -377,19 +377,19 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다. 1. 노드에서 실행 중인 일반 파드를 종료시킨다. -2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다. +2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다. 그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다. * `ShutdownGracePeriod`: - * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다. + * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다. * `ShutdownGracePeriodCriticalPods`: - * 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다. + * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다. 예를 들어, `ShutdownGracePeriod=30s`, `ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의 유예 종료에 할당되고, 마지막 10초는 -[중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다. +[중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다. {{< note >}} 그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다. diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index f5363a45c2..5879f3cf8f 100644 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -57,7 +57,7 @@ no_list: true * [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다. -* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다. +* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다. * [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다. diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 6db0871e48..a21715e4b3 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -105,5 +105,5 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 ## {{% heading "whatsnext" %}} -자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를 +자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를 본다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 891e1def90..73d48cd18b 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -425,9 +425,9 @@ stringData: 시크릿을 생성하기 위한 몇 가지 옵션이 있다. -- [`kubectl` 명령을 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- [`kubectl` 명령을 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [구성 파일로 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [kustomize를 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/) ## 시크릿 편집하기 @@ -1259,7 +1259,7 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다. ## {{% heading "whatsnext" %}} -- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 -- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 -- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 +- [`kubectl` 을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 +- [구성 파일을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 +- [kustomize를 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 - [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기 diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 18ed0aadd3..fe6010d961 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -32,7 +32,7 @@ weight: 20 함수 호출을 통해서 구할 수 있다. 파드 이름과 네임스페이스는 -[다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다. +[다운워드(Downward) API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다. Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로, 파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다. diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index ff98e134eb..91f431b22d 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -695,7 +695,7 @@ spec: - `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다. [Sysctl 문서]( -/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다. +/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index 7128dbe99f..7ee5c488ed 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -33,5 +33,5 @@ no_list: true {{}} * [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) -* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/) * [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md index 53724320b0..45077a6674 100644 --- a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md +++ b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md @@ -14,5 +14,5 @@ API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-ap ## {{% heading "whatsnext" %}} -- [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기 +- [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기 - [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 5b0a1648c3..1c4424a047 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -91,5 +91,5 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 * 볼륨을 사용하는 파드의 스케줄링에 대해 배우기 * [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드) - * [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/) + * [스토리지 용량 추적](/ko/docs/concepts/storage/storage-capacity/) * [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/) diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index 96a8f005b1..1f78510759 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -48,7 +48,7 @@ weight: 70 {{< note >}} 쿠버네티스는 이미 `system-cluster-critical` 과 `system-node-critical`, 두 개의 프라이어리티클래스를 제공한다. -이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다. +이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다. {{< /note >}} ## 프라이어리티클래스 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index b43467d936..c66a9b6e84 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -76,4 +76,4 @@ weight: 40 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기. -* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). +* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/). diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index e9e5f12a05..bafb216014 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -77,7 +77,7 @@ graph LR; 다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 인그레스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. +설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. 인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데, 그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다. 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다. @@ -567,4 +567,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에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index c4f87e2b3e..f658cd6cfa 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되 ## {{% heading "whatsnext" %}} -* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-topology-aware-hints)에 대해서 읽기 +* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 6771f6fd01..5983c37647 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -280,7 +280,7 @@ spec: 업데이트를 수신하지 않는다. {{< /note >}} -더 자세한 내용은 [다운워드 API 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다. +더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다. ### emptyDir {#emptydir} diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index ff1c62221c..e42f482a32 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -60,7 +60,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마 각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다. -* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/) +* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/ko/docs/tasks/run-application/run-stateless-application-deployment/) * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/) 또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행 * [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 2514d56ab3..33b8812d1a 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 일반적인 설정파일 작업에 대한 정보는 -[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와 +[스테이트리스 애플리케이션 실행하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다. 데몬셋 오브젝트의 이름은 유효한 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 8769e2b9fd..fc82199883 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -1040,7 +1040,7 @@ echo $? 다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다. 설정 파일 작업에 대한 일반적인 내용은 -[애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), +[애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 9bb8b4a345..e09a08ab47 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -189,7 +189,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 * 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다. * 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다. -스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. +스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. 위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 배포된다. web-1은 web-0이 diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 497d857d11..4a5452a826 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -31,7 +31,7 @@ weight: 60 - 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애 - 커널 패닉 - 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐 -- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨 +- 노드의 [리소스 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다. 왜냐하면 @@ -71,7 +71,7 @@ weight: 60 - 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다. - 고가용성이 필요한 경우 애플리케이션을 복제한다. - (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 + (복제된 [스테이트리스](/ko/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.) - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체 ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용) diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 136413b88f..cda62ef09b 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -76,4 +76,4 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 ## {{% heading "whatsnext" %}} -* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기. +* [임시 컨테이너 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 48a918715e..3b48baf4eb 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -433,7 +433,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파 작은 유예 기간이 계속 제공된다. 스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우, -[스테이트풀셋에서 파드를 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 +[스테이트풀셋에서 파드를 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 태스크 문서를 참고한다. ### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection} diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index dcb7a68f49..d96ad15195 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -56,7 +56,7 @@ card: ## 첫 번째 기여 -- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고 +- [기여 개요](/ko/docs/contribute/new-content/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. - [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을 확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 21337a785e..2f28ab6acd 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -8,7 +8,7 @@ weight: 98 이 페이지에서는 당신이 -[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/overview)하고 +[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/)하고 [다른 사람의 작업을 리뷰](/ko/docs/contribute/review/reviewing-prs/)하는 방법을 이해한다고 가정한다. 또한 기여하기 위한 더 많은 방법에 대해 배울 준비가 되었다고 가정한다. 이러한 작업 중 일부에는 Git 커맨드 라인 클라이언트와 다른 도구를 사용해야 한다. diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index a1f0178b3c..1a46323612 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -15,7 +15,7 @@ card: [새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다. {{< /note >}} -새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/overview/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다. +새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다. 변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자. diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md index c2d9aed771..9f874351b0 100644 --- a/content/ko/docs/contribute/participate/_index.md +++ b/content/ko/docs/contribute/participate/_index.md @@ -116,6 +116,6 @@ PR 소유자에게 조언하는데 활용된다. 쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. -- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/) +- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/) - [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/) - [문서 스타일 가이드](/ko/docs/contribute/style/) diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index ad27eea6ff..5f4e1605dd 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D - [슬랙](https://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. -[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다. +[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다. - 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. - 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다. diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index e0b07a79a9..cc9e95b31a 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -43,7 +43,7 @@ weight: 10 표시된다. 2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다. - - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다. + - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을 참고한다. - `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다. - `size/`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다. diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 9bb3376933..cd815d0220 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -105,7 +105,7 @@ YAML 블록이다. 여기 예시가 있다. 포함할 수 있다. - 이 코드의 목적은 더 큰 파일의 일부를 강조하는 것이기 때문에 불완전한 예제다. 예를 들어 몇 가지 이유로 - [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy) + [PodSecurityPolicy](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy) 를 사용자 정의 방법을 설명할 때 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다. - 이 코드는 사용자가 다른 이유로 시도하기 위한 것이 아니다. 예를 들어 `kubectl edit` 명령을 사용하여 리소스에 새 속성을 추가하는 방법을 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 9767966cab..9606b74898 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 @@ -654,7 +654,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 [토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다. - `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. - [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다. + [스토리지 용량](/ko/docs/concepts/storage/storage-capacity/)을 참고한다. 자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다. - `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 @@ -698,7 +698,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`, `--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의 모든 기능을 비활성화한다. -- `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서 +- `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서 hugepages 사용을 활성화한다. - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다. @@ -738,13 +738,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다. - `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면 kubelet과 kube-apiserver를 사용하도록 설정한다. - [확장된 DNS 구성](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration)을 참고한다. + [확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다. - `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다. [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다. - `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다. [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다. - `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 - 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. + 어노테이션을 달아서 [스케줄링이 보장되도록](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다. - `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, @@ -847,7 +847,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. - `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다. 반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다. - 더 자세한 정보는 [스왑 메모리](/docs/concepts/architecture/nodes/#swap-memory)를 참고한다. + 더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다. - `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다. - `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 삭제되지 않도록 한다. @@ -970,7 +970,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 참고한다. - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. 자세한 내용은 - [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. + [sysctl](/ko/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. - `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 실행이 끝난 후 리소스를 정리하도록 허용한다. diff --git a/content/ko/docs/reference/glossary/sysctl.md b/content/ko/docs/reference/glossary/sysctl.md index bce4d26ba1..e099aaec6e 100644 --- a/content/ko/docs/reference/glossary/sysctl.md +++ b/content/ko/docs/reference/glossary/sysctl.md @@ -2,7 +2,7 @@ title: sysctl id: sysctl date: 2019-02-12 -full_link: /docs/tasks/administer-cluster/sysctl-cluster/ +full_link: /ko/docs/tasks/administer-cluster/sysctl-cluster/ short_description: > 유닉스 커널 파라미터를 가져오거나 설정하는 데 사용하는 인터페이스 diff --git a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md index a367c175cb..4935b83ec6 100644 --- a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -187,7 +187,7 @@ kubectl exec -ti nginx-app-5jyvm -- /bin/sh # exit ``` -자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다. +자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다. ## docker logs diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index 2e1694834e..aaa96a4fcf 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -147,7 +147,7 @@ LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. -윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. +윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/ko/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. ## 테인트(Taint)와 톨러레이션(Toleration) 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 daa1417ce9..2b308e7e2a 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 @@ -182,7 +182,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. - **환경 변수**: 쿠버네티스 서비스를 - [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. + [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md index d97850afbc..8adf5c4564 100644 --- a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md @@ -156,7 +156,7 @@ sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다. 두 _unsafe_ sysctl을 명시적으로 활성화하지 않은 노드에서 _unsafe_ sysctl을 사용하는 파드가 시작되지 않는다. _node-level_ sysctl과 마찬가지로 [_테인트와 톨러레이션_ 특징](/docs/reference/generated/kubectl/kubectl-commands/#taint) 또는 -[노드 테인트](/docs/concepts/scheduling-eviction/taint-and-toleration/)를 +[노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 사용하여 해당 파드를 오른쪽 노드에 스케줄하는 것을 추천한다. diff --git a/content/ko/docs/tasks/configure-pod-container/configure-runasusername.md b/content/ko/docs/tasks/configure-pod-container/configure-runasusername.md index 8bae2f4286..12546126ce 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-runasusername.md @@ -122,5 +122,5 @@ ContainerAdministrator * [쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/) * [그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/#그룹-매니지드-서비스-어카운트를-이용하여-워크로드-신원-관리하기) -* [윈도우 파드와 컨테이너의 GMSA 구성](/docs/tasks/configure-pod-container/configure-gmsa/) +* [윈도우 파드와 컨테이너의 GMSA 구성](/ko/docs/tasks/configure-pod-container/configure-gmsa/) diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index f8696993ff..11b46ede8e 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -91,7 +91,7 @@ kubectl describe pods ${POD_NAME} ### 파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우 -일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/docs/tasks/debug-application-cluster/debug-running-pod/)에 +일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/)에 기술된 메서드를 디버깅에 사용할 수 있다. diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md index 0145967dd8..1c2073a21b 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -69,7 +69,7 @@ kubectl exec -it cassandra -- sh ``` 더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기]( -/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라. +/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라. ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container} @@ -87,7 +87,7 @@ kubectl exec -it cassandra -- sh {{< note >}} 이 섹션에서 소개하는 예시를 사용하기 위해서는 -여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다. {{< /note >}} diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ko/docs/tasks/debug-application-cluster/debug-stateful-set.md index b9a1d3f677..45f170f5d3 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -32,7 +32,7 @@ kubectl get pods -l app=myapp 만약 오랜 시간동안 `Unknown`이나 `Terminating` 상태에 있는 파드들을 발견하였다면, 이러한 파드들을 어떻게 다루는지 알아보기 위해 -[스테이트풀셋 파드 삭제하기](/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다. +[스테이트풀셋 파드 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다. 스테이트풀셋에 포함된 개별 파드들을 디버깅하기 위해서는 [파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) 가이드를 참고하길 바란다. diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md index aae34dc3b9..6893dd0f74 100644 --- a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md @@ -152,5 +152,5 @@ EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값 * [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다. -* [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다. +* [컨테이너 안에서 커맨드를 실행하는 방법](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다. * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다. 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 5e23ba831e..40272c3060 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 @@ -110,6 +110,6 @@ spec: ## {{% heading "whatsnext" %}} -* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다. +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다. * [시크릿을 환경 변수로 사용하기](/ko/docs/concepts/configuration/secret/#시크릿을-환경-변수로-사용하기)에 대해 알아본다. * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다. diff --git a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md index 34a91a600c..54e809cf00 100644 --- a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md +++ b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md @@ -72,6 +72,6 @@ weight: 20 ## {{% heading "whatsnext" %}} -* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다. +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다. * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다. diff --git a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index 2a8a206d6d..b57c6e5f88 100644 --- a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -25,7 +25,7 @@ weight: 40 실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다. -* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api) +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api) * 볼륨 파일 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다. @@ -134,7 +134,7 @@ total 8 원자적(atomic)으로 갱신한다. {{< note >}} -다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath) +다운워드 API를 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다. {{< /note >}} @@ -200,8 +200,8 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh * 컨테이너의 CPU 요청(request) * 컨테이너의 메모리 한도(limit) * 컨테이너의 메모리 요청(request) - * 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우) - * 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우) + * 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우) + * 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우) * 컨테이너의 임시-스토리지 한도(limit) * 컨테이너의 임시-스토리지 요청(request) diff --git a/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index 033e0afa79..951fb716f3 100644 --- a/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -27,7 +27,7 @@ weight: 30 파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다. * 환경 변수 -* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) +* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#다운워드-downward-api) 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다. @@ -145,7 +145,7 @@ kubectl logs dapi-envars-resourcefieldref ## {{% heading "whatsnext" %}} -* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/) +* [컨테이너를 위한 환경 변수 정의하기](/ko/docs/tasks/inject-data-application/define-environment-variable-container/) * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) * [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core) diff --git a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md index 26353959ef..1a0ffe553b 100644 --- a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -132,7 +132,7 @@ kubectl delete cronjob hello ## 크론 잡 명세 작성 다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일 -작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와 +작업에 대한 일반적인 정보는 [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와 [kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. 크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. 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 a3575704ae..6bf5e7f659 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -147,7 +147,7 @@ daemonset "fluentd-elasticsearch" successfully rolled out #### 일부 노드에 리소스가 부족하다 적어도 하나의 노드에서 새 데몬셋 파드를 스케줄링할 수 없어서 롤아웃이 -중단되었다. 노드에 [리소스가 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때 +중단되었다. 노드에 [리소스가 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때 발생할 수 있다. 이 경우, `kubectl get nodes` 의 출력 결과와 다음의 출력 결과를 비교하여 diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md index 7c2b1ed783..8aeb8aa67b 100644 --- a/content/ko/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -80,11 +80,11 @@ kubectl delete pvc -l app=myapp ### 스테이트풀셋 파드의 강제 삭제 -스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. +스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. ## {{% heading "whatsnext" %}} -[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기. +[스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기. diff --git a/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md index 5c9f1358a4..7c1b311a2a 100644 --- a/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -91,6 +91,6 @@ kubectl patch pod -p '{"metadata":{"finalizers":null}}' ## {{% heading "whatsnext" %}} -[스테이트풀셋 디버깅하기](/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기. +[스테이트풀셋 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기. diff --git a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md index cf6c3188b7..a26c0a459f 100644 --- a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -196,7 +196,7 @@ kubectl delete pv mysql-pv-volume * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기 -* [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기 +* [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기 * [kubectl run 문서](/docs/reference/generated/kubectl/kubectl-commands/#run) diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 6518d0102e..cd7e5c9b08 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -301,5 +301,5 @@ minikube delete * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다. -* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다. +* [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다. * [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 4c5f690d70..b2ac3e92b5 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -239,4 +239,4 @@ kubectl apply -k ./ * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. * [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자. * [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. -* 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. +* 어떻게 [컨테이너에서 셸을 사용하는지](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. From 0f26532d91418d80e615a88931cb856866a9da5b Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 17 Nov 2021 13:52:56 +0900 Subject: [PATCH 05/12] [ko] Update outdated files in dev-1.22-ko.3 28-38 --- .../ingress-minikube.md | 279 +++++++++--------- .../web-ui-dashboard.md | 2 +- .../change-pv-reclaim-policy.md | 8 +- .../horizontal-pod-autoscale-walkthrough.md | 4 +- .../docs/tasks/tools/install-kubectl-linux.md | 4 +- .../docs/tasks/tools/install-kubectl-macos.md | 4 +- .../tasks/tools/install-kubectl-windows.md | 4 +- .../stateful-application/zookeeper.md | 17 +- content/ko/releases/notes.md | 4 +- content/ko/training/_index.html | 12 + 10 files changed, 166 insertions(+), 172 deletions(-) diff --git a/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md b/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md index fcc64072b7..a59c25d390 100644 --- a/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md @@ -2,6 +2,7 @@ title: NGINX 인그레스(Ingress) 컨트롤러로 Minikube에서 인그레스 설정하기 content_type: task weight: 100 +min-kubernetes-server-version: 1.19 --- @@ -17,23 +18,21 @@ API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-network {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +만약 이보다 더 이전 버전의 쿠버네티스를 사용하고 있다면, +해당 쿠버네티스 버전의 문서를 참고한다. +### Minikube 클러스터 생성하기 + +Katacoda 활용하기 +: {{< kat-button >}} + +로컬에서 생성하기 +: 이미 로컬에 [Minikube를 설치](/ko/docs/tasks/tools/#minikube)했다면, + `minikube start`를 실행하여 클러스터를 생성한다. -## Minikube 클러스터 생성하기 - -1. **터미널 실행**을 클릭한다. - - {{< kat-button >}} - -1. (선택 사항) Minikube를 로컬로 설치한 경우 다음 명령을 실행한다. - - ```shell - minikube start - ``` - ## 인그레스 컨트롤러 활성화 1. NGINX 인그레스 컨트롤러를 활성화하기 위해 다음 명령을 실행한다. @@ -45,14 +44,14 @@ API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-network 1. NGINX 인그레스 컨트롤러가 실행 중인지 확인한다. - {{< tabs name="tab_with_md" >}} - {{% tab name="minikube v1.19 or later" %}} + {{< tabs name="tab_with_md" >}} + {{% tab name="minikube v1.19 or later" %}} ```shell kubectl get pods -n ingress-nginx ``` - {{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}} + {{< note >}}파드가 정상적으로 실행되기까지 1분 정도 소요될 수 있다.{{< /note >}} -Output: + 결과는 다음과 같다. ``` NAME READY STATUS RESTARTS AGE @@ -60,15 +59,14 @@ ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m ``` - {{% /tab %}} - - {{% tab name="minikube v1.18.1 or earlier" %}} + {{% /tab %}} + {{% tab name="minikube v1.18.1 or earlier" %}} ```shell kubectl get pods -n kube-system ``` -{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}} + {{< note >}}파드가 정상적으로 실행되기까지 1분 정도 소요될 수 있다.{{< /note >}} -Output: + 결과는 다음과 같다. ``` NAME READY STATUS RESTARTS AGE @@ -79,133 +77,121 @@ kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m storage-provisioner 1/1 Running 0 2m ``` - {{% /tab %}} - {{< /tabs >}} - - - - ```shell - kubectl get pods -n ingress-nginx - ``` - - {{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}} - - Output: - - ```shell - NAME READY STATUS RESTARTS AGE - ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s - ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s - ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s - ``` + `nginx-ingress-controller-`로 시작하는 파드가 있는지 확인한다. + {{% /tab %}} + {{< /tabs >}} ## hello, world 앱 배포하기 1. 다음 명령을 사용하여 디플로이먼트(Deployment)를 생성한다. - ```shell - kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 - ``` + ```shell + kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 + ``` - Output: + 결과는 다음과 같다. - ```shell - deployment.apps/web created - ``` + ``` + deployment.apps/web created + ``` 1. 디플로이먼트를 노출시킨다. - ```shell - kubectl expose deployment web --type=NodePort --port=8080 - ``` + ```shell + kubectl expose deployment web --type=NodePort --port=8080 + ``` - Output: + 결과는 다음과 같다. - ```shell - service/web exposed - ``` + ``` + service/web exposed + ``` 1. 서비스(Service)가 생성되고 노드 포트에서 사용할 수 있는지 확인한다. - ```shell - kubectl get service web - ``` + ```shell + kubectl get service web + ``` - Output: + 결과는 다음과 같다. - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - web NodePort 10.104.133.249 8080:31637/TCP 12m - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + web NodePort 10.104.133.249 8080:31637/TCP 12m + ``` 1. 노드포트(NodePort)를 통해 서비스에 접속한다. - ```shell - minikube service web --url - ``` + ```shell + minikube service web --url + ``` - Output: + 결과는 다음과 같다. - ```shell - http://172.17.0.15:31637 - ``` + ``` + http://172.17.0.15:31637 + ``` - {{< note >}}Katacoda 환경만 해당: 터미널 패널 상단에서 더하기 기호를 클릭한 다음 **Select port to view on Host 1**을 클릭한다. 노드포트(이 경우 '31637')를 입력한 다음 **Display Port**를 클릭한다.{{< /note >}} + {{< note >}}Katacoda 환경만 해당: 터미널 패널 상단에서 더하기 기호를 클릭한 다음 **Select port to view on Host 1**을 클릭한다. 노드포트(이 경우 '31637')를 입력한 다음 **Display Port**를 클릭한다.{{< /note >}} - Output: + 결과는 다음과 같다. - ```shell - Hello, world! - Version: 1.0.0 - Hostname: web-55b8c6998d-8k564 - ``` + ``` + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` - 이제 Minikube IP 주소와 노드포트를 통해 샘플 앱에 액세스할 수 있다. 다음 단계에서는 - 인그레스 리소스를 사용하여 앱에 액세스할 수 있다. + 이제 Minikube IP 주소와 노드포트를 통해 샘플 앱에 액세스할 수 있다. 다음 단계에서는 + 인그레스 리소스를 사용하여 앱에 액세스할 수 있다. -## 인그레스 리소스 생성하기 +## 인그레스 생성하기 -다음 파일은 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스 리소스다. +다음 매니페스트는 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스를 정의한다. 1. 다음 파일을 통해 `example-ingress.yaml`을 만든다. {{< codenew file="service/networking/example-ingress.yaml" >}} -1. 다음 명령어를 실행하여 인그레스 리소스를 생성한다. +1. 다음 명령어를 실행하여 인그레스 오브젝트를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml + ``` - Output: + 결과는 다음과 같다. - ```shell - ingress.networking.k8s.io/example-ingress created - ``` + ``` + ingress.networking.k8s.io/example-ingress created + ``` 1. IP 주소가 설정되었는지 확인한다. - ```shell - kubectl get ingress - ``` + ```shell + kubectl get ingress + ``` - {{< note >}}이 작업은 몇 분 정도 소요될 수 있다.{{< /note >}} + {{< note >}}이 작업은 몇 분 정도 소요될 수 있다.{{< /note >}} - ```shell - NAME CLASS HOSTS ADDRESS PORTS AGE - example-ingress hello-world.info 172.17.0.15 80 38s - ``` +다음 예시와 같이, ADDRESS 열에서 IPv4 주소를 확인할 수 있다. -1. `/etc/hosts` 파일의 맨 아래에 다음 행을 추가한다. + ``` + NAME CLASS HOSTS ADDRESS PORTS AGE + example-ingress hello-world.info 172.17.0.15 80 38s + ``` - {{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}} +1. 호스트 컴퓨터의 `/etc/hosts` 파일 맨 아래에 + 다음 행을 추가한다 (관리자 권한 필요). ``` 172.17.0.15 hello-world.info ``` - 이것은 hello-world.info에서 Minikube로 요청을 보낸다. + {{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}} + + 이렇게 하면, 웹 브라우저가 + hello-world.info URL에 대한 요청을 Minikube로 전송한다. 1. 인그레스 컨트롤러가 트래픽을 전달하는지 확인한다. @@ -213,9 +199,9 @@ storage-provisioner 1/1 Running 0 2m curl hello-world.info ``` - Output: + 결과는 다음과 같다. - ```shell + ``` Hello, world! Version: 1.0.0 Hostname: web-55b8c6998d-8k564 @@ -225,32 +211,33 @@ storage-provisioner 1/1 Running 0 2m ## 두 번째 디플로이먼트 생성하기 -1. 다음 명령을 사용하여 v2 디플로이먼트를 생성한다. +1. 다음 명령을 사용하여 두 번째 디플로이먼트를 생성한다. - ```shell - kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0 - ``` - Output: + ```shell + kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0 + ``` + 결과는 다음과 같다. - ```shell - deployment.apps/web2 created - ``` + ``` + deployment.apps/web2 created + ``` -1. 디플로이먼트를 노출시킨다. +1. 두 번째 디플로이먼트를 노출시킨다. - ```shell - kubectl expose deployment web2 --port=8080 --type=NodePort - ``` + ```shell + kubectl expose deployment web2 --port=8080 --type=NodePort + ``` - Output: + 결과는 다음과 같다. - ```shell - service/web2 exposed - ``` + ``` + service/web2 exposed + ``` -## 인그레스 수정하기 +## 기존 인그레스 수정하기 {#edit-ingress} -1. 기존 `example-ingress.yaml`을 편집하여 다음 줄을 추가한다. +1. 기존 `example-ingress.yaml` 매니페스트를 편집하고, +하단에 다음 줄을 추가한다. ```yaml - path: /v2 @@ -264,47 +251,47 @@ storage-provisioner 1/1 Running 0 2m 1. 변경 사항을 적용한다. - ```shell - kubectl apply -f example-ingress.yaml - ``` + ```shell + kubectl apply -f example-ingress.yaml + ``` - Output: + 결과는 다음과 같다. - ```shell - ingress.networking/example-ingress configured - ``` + ``` + ingress.networking/example-ingress configured + ``` ## 인그레스 테스트하기 1. Hello World 앱의 첫 번째 버전에 액세스한다. - ```shell - curl hello-world.info - ``` + ```shell + curl hello-world.info + ``` - Output: + 결과는 다음과 같다. - ```shell - Hello, world! - Version: 1.0.0 - Hostname: web-55b8c6998d-8k564 - ``` + ``` + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` 1. Hello World 앱의 두 번째 버전에 액세스한다. - ```shell - curl hello-world.info/v2 - ``` + ```shell + curl hello-world.info/v2 + ``` - Output: + 결과는 다음과 같다. - ```shell - Hello, world! - Version: 2.0.0 - Hostname: web2-75cd47646f-t8cjk - ``` + ``` + Hello, world! + Version: 2.0.0 + Hostname: web2-75cd47646f-t8cjk + ``` - {{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info 및 hello-world.info/v2에 접속할 수 있다.{{< /note >}} + {{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info 및 hello-world.info/v2에 접속할 수 있다.{{< /note >}} @@ -315,5 +302,3 @@ storage-provisioner 1/1 Running 0 2m * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 더 보기. * [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 보기. - - 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 daa1417ce9..0f1055ca60 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 @@ -35,7 +35,7 @@ card: 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근 diff --git a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index 2d1b723e27..2f663befec 100644 --- a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -88,8 +88,8 @@ kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\" * [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 배워 보기. * [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)에 대해 더 배워 보기. -### Reference +### 레퍼런스 {#reference} -* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) -* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) -* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기. +* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}} + * Pay attention to the 퍼시스턴트볼륨의 `.spec.persistentVolumeReclaimPolicy` [필드](docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)에 주의한다. +* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}} 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 9b5ea5b6cf..a910dc5c48 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 @@ -82,8 +82,8 @@ service/php-apache created 다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다. 간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. -(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고, -따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다). +kubectl run으로 각 파드는 200 밀리코어를 요청하므로, +여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다. 이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다. ```shell diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index da58e6ca8b..71858e3e92 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -12,8 +12,8 @@ card: ## {{% heading "prerequisites" %}} -클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다. -최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. +클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다. +호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. ## 리눅스에 kubectl 설치 diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md index cd03eb91b7..0fc350f02f 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-macos.md +++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md @@ -12,8 +12,8 @@ card: ## {{% heading "prerequisites" %}} -클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다. -최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. +클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다. +호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. ## macOS에 kubectl 설치 diff --git a/content/ko/docs/tasks/tools/install-kubectl-windows.md b/content/ko/docs/tasks/tools/install-kubectl-windows.md index 21fe1a9afb..e1a62c613c 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-windows.md +++ b/content/ko/docs/tasks/tools/install-kubectl-windows.md @@ -12,8 +12,8 @@ card: ## {{% heading "prerequisites" %}} -클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다. -최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. +클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다. +호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. ## 윈도우에 kubectl 설치 diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index a9c834d7b3..248d6d1d4d 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -40,7 +40,6 @@ weight: 40 튜토리얼을 시작하기 전에 수동으로 3개의 20 GiB 볼륨을 프로비저닝해야 한다. - ## {{% heading "objectives" %}} 이 튜토리얼을 마치면 다음에 대해 알게 된다. @@ -50,7 +49,6 @@ weight: 40 - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. - 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. - ### ZooKeeper @@ -262,13 +260,15 @@ server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 ### 앙상블 무결성 테스트 -가장 기본적인 테스트는 한 ZooKeeper 서버에 데이터를 쓰고 다른 ZooKeeper 서버에서 데이터를 읽는 것이다. +가장 기본적인 테스트는 한 ZooKeeper 서버에 데이터를 쓰고 +다른 ZooKeeper 서버에서 데이터를 읽는 것이다. 아래 명령어는 앙상블 내에 `zk-0` 파드에서 `/hello` 경로로 `world`를 쓰는 스크립트인 `zkCli.sh`를 실행한다. ```shell -kubectl exec zk-0 zkCli.sh create /hello world +kubectl exec zk-0 -- zkCli.sh create /hello world ``` + ``` WATCHER:: @@ -279,7 +279,7 @@ Created /hello `zk-1` 파드에서 데이터를 읽기 위해 다음 명령어를 이용하자. ```shell -kubectl exec zk-1 zkCli.sh get /hello +kubectl exec zk-1 -- zkCli.sh get /hello ``` `zk-0`에서 생성한 그 데이터는 앙상블 내에 모든 서버에서 @@ -409,7 +409,6 @@ numChildren = 0 `zk` 스테이트풀셋의 `spec`에 `volumeClaimTemplates` 필드는 각 파드에 프로비전될 퍼시스턴트볼륨을 지정한다. - ```yaml volumeClaimTemplates: - metadata: @@ -443,7 +442,6 @@ datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi R `스테이트풀셋`의 컨테이너 `template`의 `volumeMounts` 부분이 ZooKeeper 서버의 데이터 디렉터리에 퍼시스턴트볼륨 마운트하는 내용이다. - ```shell volumeMounts: - name: datadir @@ -591,6 +589,7 @@ kubectl exec zk-0 -- ps -elf `securityContext` 오브젝트의 `runAsUser` 필드 값이 1000 이므로 루트 사용자로 실행하는 대신 ZooKeeper 프로세스는 ZooKeeper 사용자로 실행된다. + ``` F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground @@ -695,6 +694,7 @@ kubectl exec zk-0 -- ps -ef 컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되었으며 ZooKeeper 프로세스는 엔트리 포인트의 자식 프로세스로 PID 27 이다. + ``` UID PID PPID C STIME TTY TIME CMD zookeep+ 1 0 0 15:03 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground @@ -1033,7 +1033,6 @@ kubectl 을 종료하기 위해 `CTRL-C`를 이용하자. `zk-0`에서 온전성 테스트 때에 입력한 값을 가져오는 `zkCli.sh`를 이용하자. - ```shell kubectl exec zk-0 zkCli.sh get /hello ``` @@ -1132,10 +1131,8 @@ drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다. - ## {{% heading "cleanup" %}} - - `kubectl uncordon`은 클러스터 내에 모든 노드를 통제 해제한다. - 반드시 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 퍼시스턴트 스토리지 미디어를 삭제하자. 귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서 diff --git a/content/ko/releases/notes.md b/content/ko/releases/notes.md index b509ae0d65..45f3f0a28a 100644 --- a/content/ko/releases/notes.md +++ b/content/ko/releases/notes.md @@ -8,6 +8,6 @@ sitemap: priority: 0.5 --- -릴리스 노트는 사용자의 쿠버네티스 버전에 해당하는 [변경로그(Changelog)](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)를 통해서 확인할 수 있다. {{< skew latestVersion >}} 의 변경로그는 [깃허브](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew latestVersion >}}.md)에 있다. +릴리스 노트는 사용자의 쿠버네티스 버전에 해당하는 [변경로그(Changelog)](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)를 통해서 확인할 수 있다. {{< skew currentVersionAddMinor 0 >}} 의 변경로그는 [깃허브](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md)에 있다. -대안으로, 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io)에서 온라인으로 검색 및 필터링이 가능하다. {{< skew latestVersion >}}로 필터링된 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew latestVersion >}}.0)에서 확인한다. +대안으로, 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io)에서 온라인으로 검색 및 필터링이 가능하다. {{< skew currentVersionAddMinor 0 >}}로 필터링된 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0)에서 확인한다. diff --git a/content/ko/training/_index.html b/content/ko/training/_index.html index ff24428664..ac028b6005 100644 --- a/content/ko/training/_index.html +++ b/content/ko/training/_index.html @@ -14,6 +14,9 @@ class: training

클라우드 네이티브 커리어를 구축하세요

쿠버네티스는 클라우드 네이티브 무브먼트의 핵심입니다. 리눅스 재단이 제공하는 교육과 인증 프로그램을 통해 커리어에 투자하고, 쿠버네티스를 배우며, 클라우드 네이티브 프로젝트를 성공적으로 수행하세요.

+
+ +
@@ -81,6 +84,15 @@ class: training

쿠버네티스 공인 자격 획득하기

+
+
+ 쿠버네티스 및 클라우드 네이티브 전문가(Kubernetes and Cloud Native Associate, KCNA) +
+

쿠버네티스 및 클라우드 네이티브 전문가 시험은 사용자의 쿠버네티스와 더 넓은 클라우드 네이티브 생태계에 대한 핵심 지식과 기술을 보여줍니다.

+

인증된 KCNA는 전체적인 클라우드 네이티브 생태계, 특히 쿠버네티스에 대한 개념적 지식을 확인시켜 줄 것입니다.

+
+ Go to Certification +
공인 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer, CKAD) From d75f6f2a46a31121add5355eeee1137d8398b39d Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Mon, 22 Nov 2021 21:02:47 +0900 Subject: [PATCH 06/12] Rev-1 to be squashed --- .../ko/docs/concepts/architecture/nodes.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 09e2264a80..8c7390eef7 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -97,7 +97,7 @@ kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API [Node authorization mode](/docs/reference/access-authn-authz/node/)와 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면, -kubelets은 자신의 노드 리소스를 생성/수정할 권한을 가진다. +각 kubelet은 자신이 속한 노드의 리소스에 대해서만 생성/수정할 권한을 가진다. {{< note >}} [노드 이름 고유성](#노드-이름-고유성) 섹션에서 언급했듯이, @@ -109,7 +109,7 @@ kubelets은 자신의 노드 리소스를 생성/수정할 권한을 가진다. 노드에 이미 스케줄된 파드는 해당 노드 구성이 kubelet 재시작에 의해 변경된 경우 오작동하거나 문제를 일으킬 수 있다. 예를 들어 이미 실행 중인 파드가 노드에 할당된 새 레이블에 대해 테인트(taint)될 수 있는 반면 해당 파드와 호환되지 않는 다른 파드는 -새 레이블을 기반으로 스케줄링된다. 노드 재-등록(re-registration)은 모든 파드를 +새 레이블을 기반으로 스케줄링된다. 노드 재등록(re-registration)은 모든 파드를 비우고(drain) 다시 적절하게 스케줄링되도록 한다. {{< /note >}} @@ -225,14 +225,14 @@ API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. -쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 -API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 -낳는다. +쿠버네티스에서 노드 오브젝트를 삭제하면 +노드 상에서 동작 중인 모든 파드 오브젝트가 API 서버로부터 삭제되며 +파드가 사용하던 이름을 다시 사용할 수 있게 된다. 노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는 [테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. -스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. +스케줄러는 파드를 노드에 할당할 때 노드의 테인트를 고려한다. 또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 {{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다. @@ -255,10 +255,10 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 ### 정보 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 -런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 +런타임 상세 정보 및 노드가 사용하는 운영 체제가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다. -이 정보는 Kubelet이 노드로부터 수집해서 -쿠버네티스 API로 이를 보낸다. +이 정보는 Kubelet이 노드에서 수집하여 +쿠버네티스 API로 전송한다. ## 하트비트 @@ -273,9 +273,9 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다. -노드의 `.status`와 비교해서, 리스는 경량의 리소스이다. -큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 -필요한 성능 영향도를 줄일 수 있다. +노드의 `.status`에 비하면, 리스는 경량의 리소스이다. +큰 규모의 클러스터에서는 리스를 하트비트에 사용하여 +업데이트로 인한 성능 영향을 줄일 수 있다. kubelet은 노드의 `.status` 생성과 업데이트 및 관련된 리스의 업데이트를 담당한다. @@ -304,12 +304,12 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다. -세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 +세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는 다음을 담당한다. -- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` +- 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다. 이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다. -- 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서 +- 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서 [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다. 기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 From 506fede20cca5701f53f7ce41515858bf6f5d048 Mon Sep 17 00:00:00 2001 From: bang9211 Date: Thu, 25 Nov 2021 15:35:19 +0900 Subject: [PATCH 07/12] Translate tasks/service-catalog/install-service-catalog-using-sc.md in Korean --- .../ko/docs/tasks/service-catalog/_index.md | 5 ++ .../install-service-catalog-using-sc.md | 78 +++++++++++++++++++ 2 files changed, 83 insertions(+) create mode 100644 content/ko/docs/tasks/service-catalog/_index.md create mode 100644 content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md diff --git a/content/ko/docs/tasks/service-catalog/_index.md b/content/ko/docs/tasks/service-catalog/_index.md new file mode 100644 index 0000000000..bc8920240f --- /dev/null +++ b/content/ko/docs/tasks/service-catalog/_index.md @@ -0,0 +1,5 @@ +--- +title: "서비스 카탈로그" +description: 서비스 카탈로그 익스텐션(extension) API를 설치한다. +weight: 150 +--- diff --git a/content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md new file mode 100644 index 0000000000..e7af324ddf --- /dev/null +++ b/content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -0,0 +1,78 @@ +--- +title: SC로 서비스 카탈로그 설치하기 +content_type: task +--- + + +{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}} + +GCP [서비스 카탈로그 설치 프로그램](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) +도구로 쿠버네티스 클러스터에 서비스 카탈로그를 쉽게 설치하거나 제거하여 +Google Cloud 프로젝트에 연결할 수 있다. + +서비스 카탈로그는 Google Cloud뿐 아니라 모든 종류의 관리형 서비스와 함께 작동할 수 있다. + +## {{% heading "prerequisites" %}} + +* [서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)의 핵심 개념을 이해한다. +* [Go 1.6+](https://golang.org/dl/)를 설치하고 `GOPATH`를 설정한다. +* SSL 아티팩트 생성에 필요한 [cfssl](https://github.com/cloudflare/cfssl) 도구를 설치한다. +* 서비스 카탈로그에는 Kubernetes 버전 1.7 이상이 필요하다. +* [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 사용하여 Kubernetes 버전 1.7 이상의 클러스터에 연결하도록 구성한다. +* kubectl 사용자는 서비스 카탈로그를 설치하기 위해 *cluster-admin* 역할에 바인딩되어야 한다. 이것이 사실인지 확인하려면 다음 명령을 실행한다. + + kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= + + + + + +## 로컬 환경에 `sc` 설치하기 + +설치 프로그램은 로컬 컴퓨터에서 `sc`라는 CLI 도구로 실행된다. + +`go get`을 사용하여 설치한다. + +```shell +go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc +``` + +`sc`는 이제 `GOPATH/bin` 디렉토리에 설치되어야 한다. + +## 쿠버네티스 클러스터에 서비스 카탈로그 설치하기 + +먼저 명령을 실행하여 모든 종속성이 설치되었는지 확인한다. + +```shell +sc check +``` + +확인에 성공하면 다음을 반환해야 한다. + +``` +Dependency check passed. You are good to go. +``` + +그런 다음 설치 명령을 실행하고 백업에 사용할 `storageclass`를 지정한다. + +```shell +sc install --etcd-backup-storageclass "standard" +``` + +## 서비스 카탈로그 제거하기 + +`sc` 도구를 사용하여 쿠버네티스 클러스터에서 서비스 카탈로그를 제거하려면 다음을 실행한다. + +```shell +sc uninstall +``` + + + + +## {{% heading "whatsnext" %}} + +* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 +* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 + + From 5961160ac2a7a17f475cde2cb637a48c28561c49 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 25 Nov 2021 19:25:15 +0900 Subject: [PATCH 08/12] [ko] Update outdated files in dev-1.22-ko.3 M4-M8 --- content/ko/docs/concepts/overview/components.md | 8 +++----- .../overview/working-with-objects/namespaces.md | 7 +++++-- content/ko/docs/concepts/security/overview.md | 12 ++++++------ .../ko/docs/concepts/services-networking/service.md | 7 ++++--- 4 files changed, 18 insertions(+), 16 deletions(-) diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index b4c6079213..4a93cf9e5c 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -1,4 +1,6 @@ --- + + title: 쿠버네티스 컴포넌트 content_type: concept description: > @@ -17,11 +19,7 @@ card: 이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한 다양한 컴포넌트들에 대해 요약하고 정리한다. -여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다. - -![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.svg) - - +{{< figure src="/images/docs/components-of-kubernetes.svg" alt="쿠버네티스 구성 요소" caption="쿠버네티스 클러스터 구성 요소" class="diagram-large" >}} ## 컨트롤 플레인 컴포넌트 diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index fb2e52534c..03597eee50 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -1,4 +1,8 @@ --- + + + + title: 네임스페이스 content_type: concept weight: 30 @@ -6,8 +10,7 @@ weight: 30 -쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다. -이런 가상 클러스터를 네임스페이스라고 한다. +쿠버네티스에서, _네임스페이스_ 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트 _(예: 디플로이먼트, 서비스 등)_ 에만 적용 가능하며 클러스터 범위의 오브젝트 _(예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등)_ 에는 적용 불가능하다. diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index dd81fe6b2c..02cf7d72ae 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -29,7 +29,7 @@ weight: 1 널리 알려져 있다. {{< /note >}} -{{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" >}} +{{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" class="diagram-large" >}} 클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다. 코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다. @@ -77,7 +77,7 @@ API 서버에 대한 네트워크 접근(컨트롤 플레인) | 쿠버네티스 노드에 대한 네트워크 접근(노드) | 지정된 포트의 컨트롤 플레인에서 _만_ (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. 클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. [Kops 설명서](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)는 IAM 정책 및 역할에 대한 정보를 제공한다. etcd에 대한 접근 | etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 [etcd 문서](https://github.com/etcd-io/etcd/tree/master/Documentation)에서 확인할 수 있다. -etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다. +etcd 암호화 | 가능한 한 모든 스토리지를 암호화하는 것이 좋은 방법이며, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다. {{< /table >}} @@ -107,9 +107,9 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋 ------------------------------ | ------------ | RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ 인증 | https://kubernetes.io/ko/docs/concepts/security/controlling-access/ -애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ -파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ -서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ +애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/ko/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ +파드가 파드 시큐리티 폴리시를 만족하는지 확인하기 | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation +서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/ko/docs/tasks/configure-pod-container/quality-service-pod/ 네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/ 쿠버네티스 인그레스를 위한 TLS | https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#tls @@ -137,7 +137,7 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r 코드에서 고려할 영역 | 추천 | -------------------------| -------------- | -TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. | +TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 실행하는 [mTLS(상호 TLS 인증)](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. | 통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. | 타사 종속성 보안 | 애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | 정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools | diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index e0b022185f..798c0b4e97 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -263,9 +263,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다. - kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다. - kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다. -- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, - 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. - 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다. +- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다. ### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace} @@ -1074,6 +1072,9 @@ spec: {{< /note >}} +엘라스틱 IP에 대한 설명 문서와 기타 일반적 사용 사례를 +[AWS 로드 밸런서 컨트롤러 문서](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/)에서 볼 수 있다. + #### Tencent Kubernetes Engine (TKE)의 다른 CLB 어노테이션 아래 표시된 것처럼 TKE에서 클라우드 로드 밸런서를 관리하기 위한 다른 어노테이션이 있다. From abc7aa0e8bb03ce03dcf35eb7d0b7b69c86066c6 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 26 Nov 2021 12:07:03 +0900 Subject: [PATCH 09/12] [ko] Update outdated files in dev-1.22-ko.3 M9-18 --- .../workloads/controllers/cron-jobs.md | 1 + .../workloads/controllers/deployment.md | 47 ++++---- .../controllers/replicationcontroller.md | 1 - .../ko/docs/concepts/workloads/pods/_index.md | 17 ++- .../workloads/pods/init-containers.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 2 +- .../pods/pod-topology-spread-constraints.md | 62 +++++------ content/ko/docs/contribute/_index.md | 93 +++++++++++++++- .../ko/docs/contribute/new-content/_index.md | 84 ++++++++++++--- .../docs/contribute/new-content/open-a-pr.md | 101 ++++++++++++++++-- content/ko/examples/pods/simple-pod.yaml | 10 ++ 11 files changed, 336 insertions(+), 84 deletions(-) create mode 100644 content/ko/examples/pods/simple-pod.yaml diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index e2b684166f..3ae5659806 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -77,6 +77,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 | @hourly | 매시 0분에 시작 | 0 * * * * | + 예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다. `CRON_TZ=UTC 0 0 13 * 5` diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index fc82199883..ed9eaa8cbb 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -1,4 +1,6 @@ --- + + title: 디플로이먼트 feature: title: 자동화된 롤아웃과 롤백 @@ -74,7 +76,6 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ``` - 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. 만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다. @@ -163,7 +164,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다. ```shell - kubectl deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 ``` 또는 다음의 명령어를 사용한다. @@ -181,7 +182,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 변경한다. ```shell - kubectl edit deployment.v1.apps/nginx-deployment + kubectl edit deployment/nginx-deployment ``` 다음과 유사하게 출력된다. @@ -364,7 +365,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 * 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다. ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 + kubectl set image deployment/nginx-deployment nginx=nginx:1.161 ``` 이와 유사하게 출력된다. @@ -473,25 +474,25 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 1. 먼저 이 디플로이먼트의 수정 사항을 확인한다. ```shell - kubectl rollout history deployment.v1.apps/nginx-deployment + kubectl rollout history deployment/nginx-deployment ``` 이와 유사하게 출력된다. ``` deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml - 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 - 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 + 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161 ``` `CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다. - * 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다. + * 디플로이먼트에 `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다. * 수동으로 리소스 매니페스트 편집. 2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다. ```shell - kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 + kubectl rollout history deployment/nginx-deployment --revision=2 ``` 이와 유사하게 출력된다. @@ -499,7 +500,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 deployments "nginx-deployment" revision 2 Labels: app=nginx pod-template-hash=1159050644 - Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 Containers: nginx: Image: nginx:1.16.1 @@ -516,7 +517,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 1. 이제 현재 롤아웃의 실행 취소 및 이전 수정 버전으로 롤백 하기로 결정했다. ```shell - kubectl rollout undo deployment.v1.apps/nginx-deployment + kubectl rollout undo deployment/nginx-deployment ``` 이와 유사하게 출력된다. @@ -526,7 +527,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: ```shell - kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 + kubectl rollout undo deployment/nginx-deployment --to-revision=2 ``` 이와 유사하게 출력된다. @@ -560,7 +561,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 Labels: app=nginx Annotations: deployment.kubernetes.io/revision=4 - kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 Selector: app=nginx Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate @@ -603,7 +604,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 다음 명령어를 사용해서 디플로이먼트의 스케일을 할 수 있다. ```shell -kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +kubectl scale deployment/nginx-deployment --replicas=10 ``` 이와 유사하게 출력된다. ``` @@ -615,7 +616,7 @@ deployment.apps/nginx-deployment scaled 실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다. ```shell -kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80 ``` 이와 유사하게 출력된다. ``` @@ -644,7 +645,7 @@ deployment.apps/nginx-deployment scaled * 클러스터 내부에서 확인할 수 없는 새 이미지로 업데이트 된다. ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag + kubectl set image deployment/nginx-deployment nginx=nginx:sometag ``` 이와 유사하게 출력된다. @@ -723,7 +724,7 @@ nginx-deployment-618515232 11 11 11 7m * 다음 명령을 사용해서 일시 중지한다. ```shell - kubectl rollout pause deployment.v1.apps/nginx-deployment + kubectl rollout pause deployment/nginx-deployment ``` 이와 유사하게 출력된다. @@ -733,7 +734,7 @@ nginx-deployment-618515232 11 11 11 7m * 그런 다음 디플로이먼트의 이미지를 업데이트 한다. ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 ``` 이와 유사하게 출력된다. @@ -743,7 +744,7 @@ nginx-deployment-618515232 11 11 11 7m * 새로운 롤아웃이 시작되지 않는다. ```shell - kubectl rollout history deployment.v1.apps/nginx-deployment + kubectl rollout history deployment/nginx-deployment ``` 이와 유사하게 출력된다. @@ -765,7 +766,7 @@ nginx-deployment-618515232 11 11 11 7m * 예를 들어 사용할 리소스를 업데이트하는 것처럼 원하는 만큼 업데이트할 수 있다. ```shell - kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi + kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi ``` 이와 유사하게 출력된다. @@ -778,7 +779,7 @@ nginx-deployment-618515232 11 11 11 7m * 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다. ```shell - kubectl rollout resume deployment.v1.apps/nginx-deployment + kubectl rollout resume deployment/nginx-deployment ``` 이와 유사하게 출력된다. @@ -888,7 +889,7 @@ echo $? 10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다. ```shell -kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' ``` 이와 유사하게 출력된다. ``` @@ -999,7 +1000,7 @@ Conditions: `kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다. ```shell -kubectl rollout status deployment.v1.apps/nginx-deployment +kubectl rollout status deployment/nginx-deployment ``` 이와 유사하게 출력된다. ``` diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index a8cc60708e..bcf8a9771a 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -118,7 +118,6 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m 다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은 반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다. - ## 레플리케이션 컨트롤러의 Spec 작성 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다. diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 33f616fed3..6a1066c2ca 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -48,6 +48,21 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) ## 파드의 사용 +다음은 `nginx:1.14.2` 이미지를 실행하는 컨테이너로 구성되는 파드의 예시이다. + +{{< codenew file="pods/simple-pod.yaml" >}} + +위에서 설명한 파드를 생성하려면, 다음 명령을 실행한다. +```shell +kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml +``` + +일반적으로 파드는 직접 생성하지는 않으며, 대신 워크로드 리소스를 사용하여 생성한다. +[파드 작업](#파드-작업) 섹션에서 파드와 워크로드 리소스의 관계에 대한 +더 많은 정보를 확인한다. + +### Workload resources for managing pods + 일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다. 파드가 상태를 추적해야 한다면, @@ -97,7 +112,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo 공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는 별도의 "사이드카" 컨테이너가 있을 수 있다. -{{< figure src="/images/docs/pod.svg" alt="예제 파드 다이어그램" width="50%" >}} +{{< figure src="/images/docs/pod.svg" alt="파드 생성 다이어그램" class="diagram-medium" >}} 일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다. diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 79b5bb2fff..f3ca845549 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -283,7 +283,7 @@ myapp-pod 1/1 Running 0 9m 초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서 파드의 `activeDeadlineSeconds`를 사용한다. Active deadline은 초기화 컨테이너를 포함한다. -그러나 사용자가 애플리케이션을 잡(job)으로 배포한 경우 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다. +그러나 팀에서 애플리케이션을 잡(job)으로 배포한 경우에만 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다. 이미 정상적으로 동작하고 있는 파드도 `activeDeadlineSeconds`를 설정한 경우 종료(killed)될 수 있다. 파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 3b48baf4eb..54af7521d5 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -55,7 +55,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되 생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고 새로 생성된다. -{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} +{{< figure src="/images/docs/pod.svg" title="Pod diagram" class="diagram-medium" >}} *컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와 파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.* 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 a7f57b4e6a..865a7cd7c2 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 @@ -234,43 +234,43 @@ graph BT 스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다. - zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다. +zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다. - {{}} - graph BT - subgraph "zoneB" - p3(Pod) --> n3(Node3) - n4(Node4) - end - subgraph "zoneA" - p1(Pod) --> n1(Node1) - p2(Pod) --> n2(Node2) - end +{{}} +graph BT + subgraph "zoneB" + p3(Pod) --> n3(Node3) + n4(Node4) + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n2(Node2) + end - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; - class n1,n2,n3,n4,p1,p2,p3 k8s; - class p4 plain; - class zoneA,zoneB cluster; - {{< /mermaid >}} +classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; +classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; +classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; +class n1,n2,n3,n4,p1,p2,p3 k8s; +class p4 plain; +class zoneA,zoneB cluster; +{{< /mermaid >}} - {{}} - graph BT - subgraph "zoneC" - n5(Node5) - end +{{}} +graph BT + subgraph "zoneC" + n5(Node5) + end - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; - class n5 k8s; - class zoneC cluster; - {{< /mermaid >}} +classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; +classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; +classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; +class n5 k8s; +class zoneC cluster; +{{< /mermaid >}} - 그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다. +그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다. - {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} +{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} 스케줄러는 클러스터에 있는 모든 영역(zone) 또는 다른 토폴로지 도메인에 대한 사전 지식이 없다. 스케줄링은 클러스터의 기존 노드에서 결정된다. 노드 풀(또는 노드 그룹)이 0개의 노드로 스케일(scale)되고 사용자는 노드가 확장될 것으로 예상하는 경우, 자동 스케일되는 클러스터에서 문제가 발생할 수 있다. 이러한 토폴로지 도메인은 스케줄링에서 해당 도메인에 노드가 하나 이상 있을 때까지 고려되지 않을 것이기 때문이다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index d96ad15195..64b7ba594e 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -29,6 +29,8 @@ card: - 문서를 번역합니다. - 쿠버네티스 릴리스 주기에 맞추어 문서 부분을 관리하고 발행합니다. + + ## 시작하기 @@ -44,18 +46,98 @@ card: 문서에 참여하려면 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다. -1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의 +2. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. -1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와 +3. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와 [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. + + + +{{< mermaid >}} +flowchart TB +subgraph third[PR 열기] +direction TB +U[ ] -.- +Q[컨텐츠 향상시키기] --- N[컨텐츠 생성하기] +N --- O[문서 번역하기] +O --- P[K8s 릴리스 사이클의 문서 파트
관리/퍼블리싱하기] + +end + +subgraph second[리뷰] +direction TB + T[ ] -.- + D[K8s/website
저장소 살펴보기] --- E[Hugo 정적 사이트
생성기 확인하기] + E --- F[기본 GitHub 명령어
이해하기] + F --- G[열려 있는 PR을 리뷰하기] +end + +subgraph first[가입] + direction TB + S[ ] -.- + B[CNCF
Contributor
License Agreement
서명하기] --- C[sig-docs 슬랙 채널
가입하기] + C --- V[kubernetes-sig-docs
메일링 리스트 가입하기] + V --- M[주간
sig-docs 회의/
슬랙 미팅 참여하기] +end + +A([fa:fa-user 신규
기여자]) --> first +A --> second +A --> third +A --> H[질문하세요!!!] + + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey +class S,T,U spacewhite +class first,second,third white +{{}} +***그림 - 신규 기여자를 위한 시작 가이드*** + +위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다! + 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 [SIG Docs 참여](/ko/docs/contribute/participate/)를 봅니다. ## 첫 번째 기여 +몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다. + + + + +{{< mermaid >}} +flowchart LR + subgraph second[첫 기여] + direction TB + S[ ] -.- + G[다른 K8s 멤버의 PR 리뷰하기] --> + A[K8s/website 이슈 리스트에서
good first issue 확인하기] --> B[PR을 여세요!!] + end + subgraph first[추천 준비 사항] + direction TB + T[ ] -.- + D[기여 개요 읽기] -->E[K8s 컨텐츠 및
스타일 가이드 읽기] + E --> F[Hugo 페이지 컨텐츠 종류와
shortcode 숙지하기] + end + + + first ----> second + + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,D,E,F,G grey +class S,T spacewhite +class first,second white +{{}} +***그림 - 첫 기여를 위한 준비*** + - [기여 개요](/ko/docs/contribute/new-content/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. - [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을 @@ -92,10 +174,13 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다. 자신을 소개하세요! - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는 [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요. -- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다. +- 2주마다 열리는 [SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 공지되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다. +- 줌 화상 회의가 열리지 않은 경우, SIG Docs 비실시간 슬랙 스탠드업 회의에 참여하세요. 회의는 항상 `#sig-docs` 에 공지됩니다. 회의 공지 후 24시간까지 어느 스레드에나 기여할 수 있습니다. ## 다른 기여 방법들 - [쿠버네티스 커뮤니티 사이트](/ko/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다. -- [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다. +- [기여자 치트시트](https://www.kubernetes.dev/docs/contributor-cheatsheet/)를 읽고 쿠버네티스 기능 개발에 참여합니다. +- 쿠버네티스 기여자 사이트에서 [쿠버네티스 기여자](https://www.kubernetes.dev/)와 [추가적인 기여자 리소스](https://www.kubernetes.dev/resources/)에 대해 더 알아봅니다. - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다. + diff --git a/content/ko/docs/contribute/new-content/_index.md b/content/ko/docs/contribute/new-content/_index.md index 59b4b7aae4..5abe67265c 100644 --- a/content/ko/docs/contribute/new-content/_index.md +++ b/content/ko/docs/contribute/new-content/_index.md @@ -5,10 +5,48 @@ main_menu: true weight: 20 --- + + -이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다. +이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 +있다. + + +{{< mermaid >}} +flowchart LR + subgraph second[시작하기 전에] + direction TB + S[ ] -.- + A[CNCF CLA 서명하기] --> B[Git 브랜치 선택하기] + B --> C[한 PR에는 한 언어에 대한 변경사항만] + C --> F[기여자 도구 확인하기] + end + subgraph first[기여 기초] + direction TB + T[ ] -.- + D[문서를 마크다운으로 작성하고
Hugo로 사이트 빌드] --- E[GitHub에 있는 소스] + E --- G['/content/../docs' 폴더에
각 언어 컨텐츠가 있음] + G --- H[Hugo 페이지 컨텐츠 종류와
shortcode 숙지하기] + end + + + first ----> second + + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,C,D,E,F,G,H grey +class S,T spacewhite +class first,second white +{{}} + +***Figure - Contributing new content preparation*** + +The figure above depicts the information you should know +prior to submitting new content. The information details follow. @@ -16,28 +54,43 @@ weight: 20 ## 기여에 대한 기본 사항 -- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. -- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. -- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. +- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 + [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. +- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. + 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. + 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트를 이용하여 + 자동으로 생성된다. +- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 + Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. - 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 - [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. + [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 + 콘텐츠 표시를 제어한다. - 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. -- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. +- 여러 언어로 문서화에 기여하거나 + 새로운 번역을 시작하는 방법에 대한 자세한 내용은 + [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. ## 시작하기 전에 {#before-you-begin} ### CNCF CLA 서명 {#sign-the-cla} -모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다. +모든 쿠버네티스 기여자는 **반드시** +[기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 +[기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다 +. -CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다. +CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. +제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, +git 이름과 이메일은 CNCF CLA에 사용된 것과 +일치해야 한다. ### 사용할 Git 브랜치를 선택한다 -풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다. +풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 +미리 알아야 한다. 시나리오 | 브랜치 :---------|:------------ @@ -45,20 +98,21 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 기능 변경 릴리스의 콘텐츠 | `dev-` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다. 다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다. - 어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다. -{{< note >}} -풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면, +{{< note >}} 풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면, 제출자(제출자인 여러분만)가 이를 변경할 수 있다. {{< /note >}} ### PR 당 언어 -PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다. +PR 당 하나의 언어로 풀 리퀘스트를 제한한다. +여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 +각 언어마다 별도의 PR을 연다. ## 기여자를 위한 도구들 -`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다. - +`kubernetes/website` 리포지터리의 +[문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) +디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다. diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 1a46323612..0871800715 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -28,7 +28,40 @@ card: ## GitHub을 사용하여 변경하기 git 워크플로에 익숙하지 않은 경우, 풀 리퀘스트를 -여는 쉬운 방법이 있다. +여는 쉬운 방법이 있다. 아래의 그림은 각 단계를 보여주며, 상세사항은 그 아래에 나온다. + + + + +{{< mermaid >}} +flowchart LR +A([fa:fa-user 신규
기여자]) --- id1[(K8s/Website
GitHub)] +subgraph tasks[GitHub 상에서 변경하기] +direction TB + 0[ ] -.- + 1[1. '페이지 편집' 누르기] --> 2[2. GitHub 마크다운
편집기로 편집하기] + 2 --> 3[3. 'Propose file change'에
추가 내용 기재하기] + +end +subgraph tasks2[ ] +direction TB +4[4. 'Propose changes' 누르기] --> 5[5. 'Create pull request' 누르기] --> 6[6. 'Open a pull request'에
추가 내용 기재하기] +6 --> 7[7. 'Create pull request' 누르기] +end + +id1 --> tasks --> tasks2 + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,1,2,3,4,5,6,7 grey +class 0 spacewhite +class tasks,tasks2 white +class id1 k8s +{{}} + +***그림 - GitHub 상에서 PR을 여는 단계*** 1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다. 페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다. @@ -89,6 +122,37 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다. +아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다. + + + + +{{< mermaid >}} +flowchart LR +1[K8s/website
저장소 포크하기] --> 2[로컬 클론 생성
및 upstream 설정] +subgraph changes[당신의 변경사항] +direction TB +S[ ] -.- +3[브랜치 생성
예: my_new_branch] --> 3a[텍스트 편집기로
변경사항 만들기] --> 4["Hugo (localhost:1313)
를 이용하거나
컨테이너 이미지를 빌드하여
변경사항을 로컬에서 미리보기"] +end +subgraph changes2[커밋 / 푸시] +direction TB +T[ ] -.- +5[변경사항 커밋하기] --> 6[커밋을
origin/my_new_branch
로 푸시하기] +end + +2 --> changes --> changes2 + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class 1,2,3,3a,4,5,6 grey +class S,T spacewhite +class changes,changes2 white +{{}} +***그림 - 로컬 포크에서 변경 사항 작업하기*** + ### kubernetes/website 리포지터리 포크하기 1. [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. @@ -230,7 +294,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 1. 로컬에서 이미지를 빌드한다. ```bash - make docker-image # docker 사용(기본값) make container-image @@ -243,7 +306,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. ```bash - make docker-serve # docker 사용(기본값) make container-serve @@ -291,6 +353,34 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 ### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr} +아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다. + + + +{{< mermaid >}} +flowchart LR +subgraph first[ ] +direction TB +1[1. K8s/website 저장소로 이동] --> 2[2. 'New Pull Request' 클릭] +2 --> 3[3. 'Compare across forks' 클릭] +3 --> 4[4. 'head repository' 드롭다운 메뉴에서
당신의 포크 선택] +end +subgraph second [ ] +direction TB +5[5. 'compare' 드롭다운 메뉴에서
당신의 브랜치 선택] --> 6[6. 'Create Pull Request' 클릭] +6 --> 7[7. PR 본문에 상세 설명 기재] +7 --> 8[8. 'Create pull request' 클릭] +end + +first --> second + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +class 1,2,3,4,5,6,7,8 grey +class first,second white +{{}} +***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계*** + 1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. 2. **New Pull Request** 를 선택한다. 3. **compare across forks** 를 선택한다. @@ -305,7 +395,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 8. **Create pull request** 버튼을 선택한다. - 축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다. +축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다. PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다. @@ -416,7 +506,6 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 풀 리퀘스트에 더 이상 충돌이 표시되지 않는다. - ### 커밋 스쿼시하기 {{< note >}} @@ -502,8 +591,6 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때 가능한 한 상세하게 템플릿의 내용을 작성한다. - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/examples/pods/simple-pod.yaml b/content/ko/examples/pods/simple-pod.yaml new file mode 100644 index 0000000000..0e79d8a3c6 --- /dev/null +++ b/content/ko/examples/pods/simple-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 From 55bcd4ec4be8c683f30ce7ed9879349847cf63ac Mon Sep 17 00:00:00 2001 From: Sejin Kim Date: Sat, 27 Nov 2021 00:01:46 +0900 Subject: [PATCH 10/12] Fix the wrong indent for bullet list --- .../concepts/workloads/controllers/job.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 3f1666b940..5f52096b3f 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -144,19 +144,19 @@ kubectl logs $pods 잡으로 실행하기에 적합한 작업 유형은 크게 세 가지가 있다. 1. 비-병렬(Non-parallel) 잡: - - 일반적으로, 파드가 실패하지 않은 한, 하나의 파드만 시작된다. - - 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다. + - 일반적으로, 파드가 실패하지 않은 한, 하나의 파드만 시작된다. + - 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다. 1. *고정적(fixed)인 완료 횟수* 를 가진 병렬 잡: - - `.spec.completions` 에 0이 아닌 양수 값을 지정한다. - - 잡은 전체 작업을 나타내며, `.spec.completions` 성공한 파드가 있을 때 완료된다. - - `.spec.completionMode="Indexed"` 를 사용할 때, 각 파드는 0에서 `.spec.completions-1` 범위 내의 서로 다른 인덱스를 가져온다. + - `.spec.completions` 에 0이 아닌 양수 값을 지정한다. + - 잡은 전체 작업을 나타내며, `.spec.completions` 성공한 파드가 있을 때 완료된다. + - `.spec.completionMode="Indexed"` 를 사용할 때, 각 파드는 0에서 `.spec.completions-1` 범위 내의 서로 다른 인덱스를 가져온다. 1. *작업 큐(queue)* 가 있는 병렬 잡: - - `.spec.completions` 를 지정하지 않고, `.spec.parallelism` 를 기본으로 한다. - - 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다. - - 각 파드는 모든 피어들의 작업이 완료되었는지 여부를 독립적으로 판단할 수 있으며, 결과적으로 전체 잡이 완료되게 한다. - - 잡의 _모든_ 파드가 성공적으로 종료되면, 새로운 파드는 생성되지 않는다. - - 하나 이상의 파드가 성공적으로 종료되고, 모든 파드가 종료되면 잡은 성공적으로 완료된다. - - 성공적으로 종료된 파드가 하나라도 생긴 경우, 다른 파드들은 해당 작업을 지속하지 않아야 하며 어떠한 출력도 작성하면 안 된다. 파드들은 모두 종료되는 과정에 있어야 한다. + - `.spec.completions` 를 지정하지 않고, `.spec.parallelism` 를 기본으로 한다. + - 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다. + - 각 파드는 모든 피어들의 작업이 완료되었는지 여부를 독립적으로 판단할 수 있으며, 결과적으로 전체 잡이 완료되게 한다. + - 잡의 _모든_ 파드가 성공적으로 종료되면, 새로운 파드는 생성되지 않는다. + - 하나 이상의 파드가 성공적으로 종료되고, 모든 파드가 종료되면 잡은 성공적으로 완료된다. + - 성공적으로 종료된 파드가 하나라도 생긴 경우, 다른 파드들은 해당 작업을 지속하지 않아야 하며 어떠한 출력도 작성하면 안 된다. 파드들은 모두 종료되는 과정에 있어야 한다. _비-병렬_ 잡은 `.spec.completions` 와 `.spec.parallelism` 모두를 설정하지 않은 채로 둘 수 있다. 이때 둘 다 설정하지 않은 경우 1이 기본으로 설정된다. From 13c18873e1ea0881df9790e231d49caedfc7aa29 Mon Sep 17 00:00:00 2001 From: bang9211 Date: Tue, 30 Nov 2021 10:09:14 +0900 Subject: [PATCH 11/12] Translate reference/ports-and-protocols.md in Korean --- .../ko/docs/reference/ports-and-protocols.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 content/ko/docs/reference/ports-and-protocols.md diff --git a/content/ko/docs/reference/ports-and-protocols.md b/content/ko/docs/reference/ports-and-protocols.md new file mode 100644 index 0000000000..6ba447cda9 --- /dev/null +++ b/content/ko/docs/reference/ports-and-protocols.md @@ -0,0 +1,40 @@ +--- +title: 포트와 프로토콜 +content_type: reference +weight: 50 +--- + +물리적 네트워크 방화벽이 있는 온프레미스 데이터 센터 또는 +퍼블릭 클라우드의 가상 네트워크와 같이 네트워크 경계가 엄격한 환경에서 +쿠버네티스를 실행할 때, 쿠버네티스 구성 요소에서 +사용하는 포트와 프로토콜을 알고 있는 것이 유용하다. + +## 컨트롤 플레인 + +| 프로토콜 | 방향 | 포트 범위 | 용도 | 사용 주체 | +|----------|-----------|------------|-------------------------|---------------------------| +| TCP | 인바운드 | 6443 | 쿠버네티스 API 서버 | 전부 | +| TCP | 인바운드 | 2379-2380 | etcd 서버 클라이언트 API | kube-apiserver, etcd | +| TCP | 인바운드 | 10250 | Kubelet API | Self, 컨트롤 플레인 | +| TCP | 인바운드 | 10259 | kube-scheduler | Self | +| TCP | 인바운드 | 10257 | kube-controller-manager | Self | + +etcd 포트가 컨트롤 플레인 섹션에 포함되어 있지만, 외부 또는 사용자 지정 포트에서 자체 +etcd 클러스터를 호스팅할 수도 있다. + +## 워커 노드 {#node} + +| 프로토콜 | 방향 | 포트 범위 | 용도 | 사용 주체 | +|----------|-----------|-------------|-----------------------|-------------------------| +| TCP | 인바운드 | 10250 | Kubelet API | Self, 컨트롤 플레인 +| TCP | 인바운드 | 30000-32767 | NodePort 서비스† | 전부 | + +† [노드포트(NodePort) 서비스](/ko/docs/concepts/services-networking/service/)의 기본 포트 범위. + +모든 기본 포트 번호를 재정의할 수 있다. 사용자 지정 포트를 사용하는 경우 +여기에 언급된 기본값 대신 해당 포트를 열어야 한다. + +종종 발생하는 한 가지 일반적인 예는 API 서버 포트를 443으로 변경하는 경우이다. +또는, API 서버의 기본 포트를 그대로 유지하고, +443 포트에서 수신 대기하는 로드 밸런서 뒤에 API 서버를 두고, +로드 밸런서에서 API 서버로 가는 요청을 API 서버의 기본 포트로 라우팅할 수도 있다. From 27b24fd4b2d8c31a7bce51dc4805a02cc53931dd Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 17 Nov 2021 19:34:51 +0900 Subject: [PATCH 12/12] [ko] Update outdated files in dev-1.22-ko.3 19-26 --- .../docs/contribute/review/reviewing-prs.md | 36 ++++++++++++- .../access-authn-authz/authorization.md | 15 ++++++ .../feature-gates.md | 8 +-- .../ko/docs/reference/glossary/extensions.md | 2 +- .../ko/docs/reference/glossary/namespace.md | 4 +- .../reference/issues-security/security.md | 2 +- .../ko/docs/reference/scheduling/config.md | 53 +++++++++++++++---- .../tools/kubeadm/install-kubeadm.md | 6 ++- 8 files changed, 103 insertions(+), 23 deletions(-) diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index e0b07a79a9..bb98753252 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -18,7 +18,8 @@ weight: 10 - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. - 쿠버네티스 문서화 커뮤니티의 다양한 - [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 이해한다. + [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 + 이해한다. @@ -35,7 +36,38 @@ weight: 10 ## 리뷰 과정 -일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. +일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다. + + + + +{{< mermaid >}} +flowchart LR + subgraph fourth[리뷰 시작] + direction TB + S[ ] -.- + M[코멘트 작성] --> N[변경사항 리뷰] + N --> O[새 기여자가 어떤 코멘트를
반영할지 선택해야 함] + end + subgraph third[PR 선택] + direction TB + T[ ] -.- + J[본문과 코멘트 확인]--> K[Netlify 미리보기 빌드로
변경사항 미리보기] + end + + A[열려 있는 PR 목록 확인]--> B[레이블을 이용하여
PR을 필터링] + B --> third --> fourth + + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,J,K,M,N,O grey +class S,T spacewhite +class third,fourth white +{{}} + +***그림 - 리뷰 과정 절차*** 1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 이동한다. diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index b4d221c675..115966e077 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -134,6 +134,21 @@ kubectl auth can-i list secrets --namespace dev --as dave no ``` +유사하게, `dev` 네임스페이스의 `dev-sa` 서비스 어카운트가 +`target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다. + +```bash +kubectl auth can-i list pods \ + --namespace target \ + --as system:serviceaccount:dev:dev-sa +``` + +다음과 유사하게 출력된다. + +``` +yes +``` + `SelfSubjectAccessReview`는 `authorization.k8s.io` API 그룹의 일부로서 API 서버 인가를 외부 서비스에 노출시킨다. 이 그룹의 기타 리소스에는 다음이 포함된다. 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 9767966cab..44815299fc 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 @@ -125,7 +125,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `HPAScaleToZero` | `false` | 알파 | 1.16 | | | `IndexedJob` | `false` | 알파 | 1.21 | 1.21 | | `IndexedJob` | `true` | 베타 | 1.22 | | -| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | | | `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 | | `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | | | `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | | @@ -138,13 +137,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `IPv6DualStack` | `true` | 베타 | 1.21 | | | `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | | | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | | +| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | | +| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | | | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | | `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 | | `LogarithmicScaleDown` | `true` | 베타 | 1.22 | | -| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | | -| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | | | `MemoryManager` | `false` | 알파 | 1.21 | 1.21 | | `MemoryManager` | `true` | 베타 | 1.22 | | | `MemoryQoS` | `false` | 알파 | 1.22 | | @@ -289,9 +288,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - | | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | | `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - | -| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | -| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 | -| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - | | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | | `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - | diff --git a/content/ko/docs/reference/glossary/extensions.md b/content/ko/docs/reference/glossary/extensions.md index 547cd934bc..daa5e37841 100644 --- a/content/ko/docs/reference/glossary/extensions.md +++ b/content/ko/docs/reference/glossary/extensions.md @@ -15,4 +15,4 @@ tags: -대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다. +많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 또한 익스텐션을 새로 만들어야 하는 사용자는 거의 없을 것이다. diff --git a/content/ko/docs/reference/glossary/namespace.md b/content/ko/docs/reference/glossary/namespace.md index 584f2fc2bd..417ad0672f 100644 --- a/content/ko/docs/reference/glossary/namespace.md +++ b/content/ko/docs/reference/glossary/namespace.md @@ -10,9 +10,9 @@ aka: tags: - fundamental --- - 쿠버네티스에서 동일한 물리 {{< glossary_tooltip text="클러스터" term_id="cluster" >}}에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화. + 쿠버네티스에서 하나의 {{< glossary_tooltip text="클러스터" term_id="cluster" >}} 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상적 개념. -네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 한다. 그러나, 네임스페이스 간에서 유일할 필요는 없다. +네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 한다. 그러나, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트(예: 디플로이먼트, 서비스 등)에만 적용 가능하며 클러스터 범위의 오브젝트(예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등)에는 적용 불가능하다. diff --git a/content/ko/docs/reference/issues-security/security.md b/content/ko/docs/reference/issues-security/security.md index fea97697e2..75191efdcb 100644 --- a/content/ko/docs/reference/issues-security/security.md +++ b/content/ko/docs/reference/issues-security/security.md @@ -27,7 +27,7 @@ weight: 20 보고서를 작성하려면, [쿠버네티스 버그 현상금 프로그램](https://hackerone.com/kubernetes)에 취약점을 제출한다. 이를 통해 표준화된 응답시간으로 취약점을 분류하고 처리할 수 있다. -또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다. +또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml)로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다. [보안 대응 위원회(Security Response Committee) 구성원](https://git.k8s.io/security/README.md#product-security-committee-psc)의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다. diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index 4680bc868f..d31897054d 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -89,7 +89,7 @@ profiles: - plugins: score: disabled: - - name: NodeResourcesLeastAllocated + - name: PodTopologySpread enabled: - name: MyCustomPluginA weight: 2 @@ -116,10 +116,6 @@ profiles: 익스텐션 포인트: `filter`. - `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다. 익스텐션 포인트: `preFilter`, `filter`. -- `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}} - `scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라 - 노드 점수를 매긴다. - 익스텐션 포인트: `score`. - `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를 구현한다. @@ -195,8 +191,8 @@ profiles: - `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를 선호한다. 익스텐션 포인트: `score`. -- `NodeLabel`: Filters and / or scores a node according to configured - {{< glossary_tooltip text="label(s)" term_id="label" >}}. +- `NodeLabel`: 설정된 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라 + 노드를 필터링하거나 스코어링한다. 익스텐션 포인트: `Filter`, `Score`. - `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에 속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지 @@ -255,10 +251,47 @@ profiles: 단 하나만 가질 수 있기 때문이다. {{< /note >}} +## 스케줄러 설정 전환 + +{{< tabs name="tab_with_md" >}} +{{% tab name="v1beta1 → v1beta2" %}} +* 설정 버전 v1beta2 에서는, `NodeResourcesFit` 플러그인을 위한 새로운 스코어링 확장을 + 이용할 수 있다. + 새 확장은 `NodeResourcesLeastAllocated`, `NodeResourcesMostAllocated`, + `RequestedToCapacityRatio` 플러그인의 기능을 통합하여 제공한다. + 예를 들어, 이전에 `NodeResourcesMostAllocated` 플러그인을 사용했다면, + 대신 `NodeResourcesFit`(기본적으로 활성화되어 있음)을 사용하면서 + 다음과 같이 `scoreStrategy`를 포함하는 `pluginConfig`를 추가할 수 있다. + ```yaml + apiVersion: kubescheduler.config.k8s.io/v1beta2 + kind: KubeSchedulerConfiguration + profiles: + - pluginConfig: + - args: + scoringStrategy: + resources: + - name: cpu + weight: 1 + type: MostAllocated + name: NodeResourcesFit + ``` + +* 스케줄러 플러그인 `NodeLabel`은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 [`NodeAffinity`](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 플러그인(기본적으로 활성화되어 있음)을 사용한다. + +* 스케줄러 플러그인 `ServiceAffinity`은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 [`InterPodAffinity`](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 플러그인(기본적으로 활성화되어 있음)을 사용한다. + +* 스케줄러 플러그인 `NodePreferAvoidPods`은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 [노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 사용한다. + +* v1beta2 설정 파일에서 활성화된 플러그인은 해당 플러그인의 기본 설정값보다 v1beta2 설정 파일의 값이 우선 적용된다. + +* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port`가 잘못 설정되면 검증 실패를 유발한다. + +{{% /tab %}} +{{< /tabs >}} + ## {{% heading "whatsnext" %}} * [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 -* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기 -* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기 - +* [kube-scheduler 설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기 +* [kube-scheduler 설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기 diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 446953327f..999bfd192e 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -69,7 +69,11 @@ sudo sysctl --system ## 필수 포트 확인 {#check-required-ports} [필수 포트들](/docs/reference/ports-and-protocols/)은 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야 -한다. +한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다. + +```shell +telnet 127.0.0.1 6443 +``` 사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도 있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한