Merge pull request #32479 from jihoon-seo/220325_Update_links_1.22-ko.4

[ko] Update links in `dev-1.22-ko.4`
[ko] Update links in dev-1.22-ko.4
2022-03-25 00:19:50 -07:00 · 2022-03-25 11:52:36 +09:00 · 2022-02-18 01:38:23 -08:00 · 2022-02-18 14:23:19 +09:00 · 2022-01-20 16:53:59 -08:00 · 2022-01-20 16:51:59 -08:00
91 changed files with 587 additions and 785 deletions
@@ -139,13 +139,13 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.22"
+latest = "v1.23"

-fullversion = "v1.22.0"
+fullversion = "v1.22.4"
 version = "v1.22"
-githubbranch = "main"
-docsbranch = "main"
-deprecated = false
+githubbranch = "v1.22.4"
+docsbranch = "release-1.22"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"

@@ -179,40 +179,40 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.22.0"
-version = "v1.22"
-githubbranch = "v1.22.0"
+fullversion = "v1.23.0"
+version = "v1.23"
+githubbranch = "v1.23.0"
 docsbranch = "main"
 url = "https://kubernetes.io"

 [[params.versions]]
-fullversion = "v1.21.4"
+fullversion = "v1.22.4"
+version = "v1.22"
+githubbranch = "v1.22.4"
+docsbranch = "release-1.22"
+url = "https://v1-22.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.21.7"
 version = "v1.21"
-githubbranch = "v1.21.4"
+githubbranch = "v1.21.7"
 docsbranch = "release-1.21"
 url = "https://v1-21.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.20.10"
+fullversion = "v1.20.13"
 version = "v1.20"
-githubbranch = "v1.20.10"
+githubbranch = "v1.20.13"
 docsbranch = "release-1.20"
 url = "https://v1-20.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.19.14"
+fullversion = "v1.19.16"
 version = "v1.19"
-githubbranch = "v1.19.14"
+githubbranch = "v1.19.16"
 docsbranch = "release-1.19"
 url = "https://v1-19.docs.kubernetes.io"

-[[params.versions]]
-fullversion = "v1.18.20"
-version = "v1.18"
-githubbranch = "v1.18.20"
-docsbranch = "release-1.18"
-url = "https://v1-18.docs.kubernetes.io"
-
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.
@@ -30,7 +30,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
 {{% blocks/feature image="suitcase" %}}
 #### K8s를 어디서나 실행

-쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.
+쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는 데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.

 {{% /blocks/feature %}}

@@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
        <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 11-15, 2021</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">KubeCon Europe (2022년 5월 17~20일) 참가하기</a>
        <br>
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Attend KubeCon Europe on May 17-20, 2022</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">KubeCon North America (2022년 10월 24~28일) 참가하기</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -19,6 +19,7 @@ cid: community

 <div class="community__navbar">

+<a href="https://www.kubernetes.dev/">기여자 커뮤니티</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#values">커뮤니티 가치</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#conduct">행동 강령 </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#videos">비디오</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
@@ -44,10 +44,10 @@ weight: 40
 ### 노드 컨트롤러

 노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}}
-오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자
+오브젝트를 업데이트하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자
 테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다.

-1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다.
+1. 클라우드 공급자 API를 통해 획득한 해당 서버의 고유 ID를 노드 오브젝트에 업데이트한다.
 2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를
   사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다.
 3. 노드의 호스트 이름과 네트워크 주소를 가져온다.
@@ -402,7 +402,7 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
 제어된다.

 기본적으로, 아래 설명된 두 구성 옵션,
-`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
+`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
 그레이스풀 노드 셧다운 기능이 활성화되지 않는다.
 기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다.

@@ -412,13 +412,13 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
 2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.

 그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
-* `ShutdownGracePeriod`:
+* `shutdownGracePeriod`:
  * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
-* `ShutdownGracePeriodCriticalPods`:
-  * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
+* `shutdownGracePeriodCriticalPods`:
+  * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다.

-예를 들어, `ShutdownGracePeriod=30s`,
-`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
+예를 들어, `shutdownGracePeriod=30s`,
+`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
 지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의
 유예 종료에 할당되고, 마지막 10초는
 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다.
@@ -451,6 +451,11 @@ kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에
 [구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가
 false로 지정되어야 한다.

+{{< warning >}}
+메모리 스왑 기능이 활성화되면, 시크릿 오브젝트의 내용과 같은 
+tmpfs에 기록되었던 쿠버네티스 데이터가 디스크에 스왑될 수 있다.
+{{< /warning >}}
+
 사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 
 이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,

@@ -25,7 +25,7 @@ content_type: concept
 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
 * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
-* [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
+* Multus는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
@@ -45,6 +45,11 @@ content_type: concept
 ## 인프라스트럭처

 * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다.
+* [node problem detector](https://github.com/kubernetes/node-problem-detector)는 
+  리눅스 노드에서 실행되며, 
+  시스템 이슈를 
+  [이벤트](/docs/reference/kubernetes-api/cluster-resources/event-v1/) 또는 
+  [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition) 형태로 보고한다.

 ## 레거시 애드온

@@ -118,7 +118,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht

 ### 화웨이의 CNI-Genie

-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](https://docs.projectcalico.org/), [로마나(Romana)](https://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
+[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](https://docs.projectcalico.org/), [로마나(Romana)](https://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.

 CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.

@@ -169,49 +169,6 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
 충족하는 매우 간단한 오버레이 네트워크이다. 많은
 경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다.

-### Google 컴퓨트 엔진(GCE)
-
-Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, [고급
-라우팅](https://cloud.google.com/vpc/docs/routes)을 사용하여
-각 VM에 서브넷을 할당한다(기본값은 `/24` - 254개 IP). 해당 서브넷에 바인딩된
-모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는
-아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본"
-IP 주소에 추가된다. 리눅스 브릿지(`cbr0`)는 해당 서브넷에 존재하도록
-구성되며, 도커의 `--bridge` 플래그로 전달된다.
-
-도커는 다음의 설정으로 시작한다.
-
-```shell
-DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
-```
-
-이 브릿지는 노드의 `.spec.podCIDR`에 따라 Kubelet(`--network-plugin=kubenet`
-플래그로 제어되는)에 의해 생성된다.
-
-도커는 이제 `cbr-cidr` 블록에서 IP를 할당한다. 컨테이너는 `cbr0` 브릿지를
-통해 서로 `Node` 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크
-내에서 라우팅할 수 있다.
-
-그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해
-IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여
-GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을
-마스커레이드(일명 SNAT - 마치 패킷이 `Node` 자체에서 온 것처럼
-보이게 함)한다.
-
-```shell
-iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
-```
-
-마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에
-대한 패킷을 처리한다.
-
-```shell
-sysctl net.ipv4.ip_forward=1
-```
-
-이 모든 것의 결과는 모든 `Pod` 가 서로에게 도달할 수 있고 인터넷으로 트래픽을
-송신할 수 있다는 것이다.
-
 ### 재규어(Jaguar)

 [재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다.
@@ -246,7 +203,7 @@ Lars Kellogg-Stedman이 제공하는

 ### Multus(멀티 네트워크 플러그인)

-[Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다.
+Multus는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다.

 Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다.

@@ -260,12 +217,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 플랫폼 간의 통합을 제공한다.

-### OpenVSwitch
-
-[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만
-오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇
-"대형 벤더"에 의해 승인되었다.
-
 ### OVN(오픈 버추얼 네트워킹)

 OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
@@ -74,8 +74,7 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
 수량이다. 이것은
 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및
 [서비스](/ko/docs/concepts/services-networking/service/)와 같은 API 리소스는
-쿠버네티스 API 서버를 통해 읽고 수정할 수
-있는 오브젝트이다.
+쿠버네티스 API 서버를 통해 읽고 수정할 수 있는 오브젝트이다.

 ## 파드와 컨테이너의 리소스 요청 및 제한

@@ -100,9 +99,10 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
 CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다.
 쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다.

-분수의 요청이 허용된다.
-`0.5` 의 `spec.containers[].resources.requests.cpu` 요청을 가진
-컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은
+요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의 
+`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은, 
+`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다. 
+CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은
 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은
 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다.
 `0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, 
@@ -115,12 +115,12 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
 ### 메모리의 의미

 `memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
-E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를
+E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를
 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.

 ```shell
-128974848, 129e6, 129M, 123Mi
+128974848, 129e6, 129M,  128974848000m, 123Mi
 ```

 다음은 예제이다.
@@ -55,7 +55,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며

  만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.

-  만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.
+  만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스를 사용하는 것을 고려할 수 있다.

 - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.

@@ -244,7 +244,7 @@ kubectl create secret docker-registry secret-tiger-docker \

 `kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기
 위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가
-다음의 두 키를 포함해야 한다.
+다음의 두 키 중 하나를 포함해야 한다.

 - `username`: 인증을 위한 사용자 이름
 - `password`: 인증을 위한 암호나 토큰
@@ -54,13 +54,15 @@ weight: 10
 컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는
 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다.

-다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다.
+다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 
+효과이다.

 `IfNotPresent`
 : 이미지가 로컬에 없는 경우에만 내려받는다.

 `Always`
-: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의
+: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 
+  이미지 레지스트리에 이름과 이미지의
  [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다.
  일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다.
  이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서
@@ -78,7 +80,8 @@ weight: 10

 {{< note >}}
 프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데,
-이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다.
+이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 
+제대로 롤백하기 어렵게 되기 때문이다.

 대신, `v1.42.0`과 같이 의미있는 태그를 명기한다.
 {{< /note >}}
@@ -90,7 +93,8 @@ weight: 10

 이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다.

-파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
+파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 
+태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
 서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다.
 이는 레지스트리에서 태그가 변경되는 일이 발생해도
 구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다.
@@ -104,7 +108,9 @@ weight: 10
  `:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다.
 - `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우,
  `imagePullPolicy`는 자동으로 `Always`로 설정된다.
- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다.
+- `imagePullPolicy` 필드를 생략하고, 
+  명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, 
+  `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다.

 {{< note >}}
 컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상
@@ -127,6 +133,7 @@ weight: 10
  그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다.
 - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다.

+
 ### 이미지풀백오프(ImagePullBackOff)

 kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, 
@@ -258,6 +265,73 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는
 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.

+### config.json 파일 해석 {#config-json}
+
+`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. 
+도커에서는 `auths` 키에 특정 루트 URL만 기재할 수 있으나, 
+쿠버네티스에서는 glob URL과 접두사-매칭 경로도 기재할 수 있다. 
+이는 곧 다음과 같은 `config.json`도 유효하다는 뜻이다.
+
+```json
+{
+    "auths": {
+        "*my-registry.io/images": {
+            "auth": "…"
+        }
+    }
+}
+```
+
+루트 URL(`*my-registry.io`)은 다음 문법을 사용하여 매치된다.
+
+```
+pattern:
+    { term }
+
+term:
+    '*'         구분자가 아닌 모든 문자와 매치됨
+    '?'         구분자가 아닌 문자 1개와 매치됨
+    '[' [ '^' ] { character-range } ']'
+                문자 클래스 (비어 있으면 안 됨))
+    c           문자 c에 매치됨 (c != '*', '?', '\\', '[')
+    '\\' c      문자 c에 매치됨
+
+character-range:
+    c           문자 c에 매치됨 (c != '\\', '-', ']')
+    '\\' c      문자 c에 매치됨
+    lo '-' hi   lo <= c <= hi 인 문자 c에 매치됨
+```
+
+이미지 풀 작업 시, 모든 유효한 패턴에 대해 크리덴셜을 CRI 컨테이너 런타임에 제공할 것이다. 
+예를 들어 다음과 같은 컨테이너 이미지 이름은 
+성공적으로 매치될 것이다.
+
+- `my-registry.io/images`
+- `my-registry.io/images/my-image`
+- `my-registry.io/images/another-image`
+- `sub.my-registry.io/images/my-image`
+- `a.sub.my-registry.io/images/my-image`
+
+kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미지 풀을 수행한다. 즉,
+`config.json`에 다음과 같이 여러 항목을 기재할 수도 있다.
+
+```json
+{
+    "auths": {
+        "my-registry.io/images": {
+            "auth": "…"
+        },
+        "my-registry.io/images/subpath": {
+            "auth": "…"
+        }
+    }
+}
+```
+
+이제 컨테이너가 `my-registry.io/images/subpath/my-image` 
+이미지를 풀 해야 한다고 명시하면,
+kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
+
 ### 미리 내려받은 이미지 {#pre-pulled-images}

 {{< note >}}
@@ -383,3 +457,4 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.

 * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
 * [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
+* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry)
@@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치

 ### 인가

-[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
+[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.


 ### 동적 어드미션 컨트롤
@@ -146,9 +146,9 @@ CRD 오브젝트의 이름은 유효한

 일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.

-[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 독립형 API 서버를
+[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
 작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
-기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여
+기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 자체 API 서버에게 위임하여
 모든 클라이언트가 사용할 수 있게 한다.

 ## 커스텀 리소스를 추가할 방법 선택
@@ -31,9 +31,7 @@ weight: 30
 및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을
 자동화할 수 있다.

-쿠버네티스의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}
-개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을
-확장할 수 있다.
+쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해, {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 커스텀 리소스와 연계시켜 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을 확장할 수 있다.
 오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의
 컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다.

@@ -227,7 +227,7 @@ spec:

 ## {{% heading "whatsnext" %}}

-* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
+* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
 * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
 * [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
 * [svc-cat.io](https://svc-cat.io/docs/) 살펴보기
@@ -50,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP

 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.

-만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다.
+만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다.

 ## 서비스 생성하기

@@ -39,7 +39,7 @@ DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다

 DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은
 각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는
-`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은
+`data.test.svc.cluster.local` 로 확장된다. `search` 옵션의 값은
 쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우,
 [`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다.

@@ -28,6 +28,7 @@ weight: 40
  컨트롤러다.
 * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
 * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
+* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다.
 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
@@ -56,12 +57,11 @@ weight: 40

 ## 여러 인그레스 컨트롤러 사용

-하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다.
-인그레스를 생성할 때,  클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우
-어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
-어노테이션을 각각의 인그레스에 달아야 한다.
+[인그레스 클래스](/ko/docs/concepts/services-networking/ingress/#인그레스-클래스)를 사용하여 하나의 클러스터 내에 여러 개의 인그레스 컨트롤러를 배포할 수 있다. 
+인그레스 클래스 리소스의 `.metadata.name`을 기록해 놓는다. 인그레스를 생성할 때, 인그레스 오브젝트의 `ingressClassName` 필드에 해당 값을 적어야 한다([IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec) 참조). `ingressClassName`은 예전 [어노테이션 메소드](/ko/docs/concepts/services-networking/ingress/#사용중단-deprecated-어노테이션)를 대체한다.

-만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다.
+인그레스에 대해 인그레스클래스를 명시하지 않고, 기본값으로 지정된 인그레스클래스가 클러스터에 단 하나만 있다면, 쿠버네티스는 해당 기본 인그레스클래스를 인그레스에 [적용한다](/ko/docs/concepts/services-networking/ingress/#default-ingress-class).
+인그레스클래스의 [`ingressclass.kubernetes.io/is-default-class` 어노테이션](/ko/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)을 `"true"`로 지정하여 해당 인그레스클래스를 기본 인그레스클래스로 표시할 수 있다.

 이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만,
 다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
@@ -26,7 +26,7 @@ weight: 40
 ## 인그레스란?

 [인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
-{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
+{{< link text="서비스" url="/ko/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.

 다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
@@ -51,7 +51,7 @@ graph LR;
 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.

 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
-[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
+[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는
 [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.

 ## 전제 조건들
@@ -232,6 +232,11 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
 리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를
 설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다.

+네임스페이스 범위의 파라미터를 사용하면 파라미터 리소스에 대해 
+클러스터 범위의 CustomResourceDefinition이 필요하지 않다. 
+또한, 클러스터 범위의 리소스에 권한을 부여하는 데 필요한 
+RBAC 관련 리소스도 필요하지 않게 만든다.
+
 {{< codenew file="service/networking/namespaced-params.yaml" >}}

 ### 사용중단(Deprecated) 어노테이션
@@ -559,7 +564,7 @@ Events:
 사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다.

 * [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용.
-* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용.
+* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 사용.



@@ -550,7 +550,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 * `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
  클러스터 내에서만 서비스에 도달할 수 있다. 이것은
  `ServiceTypes`의 기본 값이다.
-* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
+* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
  노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
  자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
  클러스터 외부에서
@@ -568,7 +568,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.

-### NodePort 유형 {#nodeport}
+### NodePort 유형 {#type-nodeport}

 `type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은
 `--service-node-port-range` 플래그로 지정된 범위에서 포트를 할당한다 (기본값 : 30000-32767).
@@ -10,14 +10,13 @@ feature:
  title: 스토리지 오케스트레이션
  description: >
    로컬 스토리지, <a href="https://cloud.google.com/storage/">GCP</a>나 <a href="https://aws.amazon.com/products/storage/">AWS</a>와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다.
-
 content_type: concept
 weight: 20
 ---

 <!-- overview -->

-이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.
+이 페이지에서는 쿠버네티스의 _퍼시스턴트 볼륨_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.

 <!-- body -->

@@ -415,10 +414,13 @@ spec:
 접근 모드는 다음과 같다.

 `ReadWriteOnce`
-: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다.
+: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파드가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다.
+
+`ReadOnlyMany`
+: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다.

 `ReadWriteMany`
-: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다.
+: 볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다.

 `ReadWriteOncePod`
 : 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다.
@@ -7,7 +7,7 @@

 title: 스토리지 용량
 content_type: concept
-weight: 45
+weight: 70
 ---

 <!-- overview -->
@@ -16,7 +16,6 @@ weight: 45
 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.

-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
 {{< feature-state for_k8s_version="v1.21" state="beta" >}}

 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
@@ -470,14 +470,14 @@ parameters:

 vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다.

- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com`
+- [CSI 프로비저닝 도구](#vsphere-provisioner-csi): `csi.vsphere.vmware.com`
 - [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume`

 인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다.

 #### CSI 프로비저닝 도구 {#vsphere-provisioner-csi}

-vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다.
+vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml)를 참조한다.

 #### vCP 프로비저닝 도구

@@ -1,7 +1,12 @@
 ---
+
+
+
+
+
 title: CSI 볼륨 복제하기
 content_type: concept
-weight: 30
+weight: 60
 ---

 <!-- overview -->
@@ -8,7 +8,7 @@

 title: 볼륨 스냅샷 클래스
 content_type: concept
-weight: 30
+weight: 41 # just after volume snapshots
 ---

 <!-- overview -->
@@ -1,7 +1,14 @@
 ---
+
+
+
+
+
+
+
 title: 볼륨 스냅샷
 content_type: concept
-weight: 20
+weight: 40
 ---

 <!-- overview -->
@@ -44,12 +44,21 @@ weight: 10

 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고
 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다.
-컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템
-뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는
-파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에
-마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를
-가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로
-지정해야 한다.
+컨테이너의 프로세스는 
+{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}의 최초 내용물과 
+컨테이너 안에 마운트된 볼륨(정의된 경우에 한함)으로 구성된 파일시스템을 보게 된다.
+프로세스는 컨테이너 이미지의 최초 내용물에 해당되는 루트 파일시스템을 
+보게 된다.
+쓰기가 허용된 경우, 해당 파일시스템에 쓰기 작업을 하면 
+추후 파일시스템에 접근할 때 변경된 내용을 보게 될 것이다.
+볼륨은 이미지의 [특정 경로](#using-subpath)에 
+마운트된다.
+파드에 정의된 각 컨테이너에 대해, 
+컨테이너가 사용할 각 볼륨을 어디에 마운트할지 명시해야 한다.
+
+볼륨은 다른 볼륨 안에 마운트될 수 없다 
+(하지만, [서브패스 사용](#using-subpath)에서 관련 메커니즘을 확인한다). 
+또한, 볼륨은 다른 볼륨에 있는 내용물을 가리키는 하드 링크를 포함할 수 없다.

 ## 볼륨 유형들 {#volume-types}

@@ -802,142 +811,7 @@ spec:
 ### projected

 `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다.
-
-현재, 다음 유형의 볼륨 소스를 프로젝티드한다.
-
-* [`secret`](#secret)
-* [`downwardAPI`](#downwardapi)
-* [`configMap`](#configmap)
-* `serviceAccountToken`
-
-모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은
-[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
-
-#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap}
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: volume-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: all-in-one
-      mountPath: "/projected-volume"
-      readOnly: true
-  volumes:
-  - name: all-in-one
-    projected:
-      sources:
-      - secret:
-          name: mysecret
-          items:
-            - key: username
-              path: my-group/my-username
-      - downwardAPI:
-          items:
-            - path: "labels"
-              fieldRef:
-                fieldPath: metadata.labels
-            - path: "cpu_limit"
-              resourceFieldRef:
-                containerName: container-test
-                resource: limits.cpu
-      - configMap:
-          name: myconfigmap
-          items:
-            - key: config
-              path: my-group/my-config
-```
-
-#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode}
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: volume-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: all-in-one
-      mountPath: "/projected-volume"
-      readOnly: true
-  volumes:
-  - name: all-in-one
-    projected:
-      sources:
-      - secret:
-          name: mysecret
-          items:
-            - key: username
-              path: my-group/my-username
-      - secret:
-          name: mysecret2
-          items:
-            - key: password
-              path: my-group/my-password
-              mode: 511
-```
-
-각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다.
-파라미터는 두 가지 예외를 제외하고 거의 동일하다.
-
-* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록
-  `name` 으로 변경되었다.
-* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만
-  지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode`
-  를 명시적으로 설정할 수 있다.
-
-`TokenRequestProjection` 기능이 활성화 되면, 현재
-[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에
-대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: sa-token-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: token-vol
-      mountPath: "/service-account"
-      readOnly: true
-  volumes:
-  - name: token-vol
-    projected:
-      sources:
-      - serviceAccountToken:
-          audience: api
-          expirationSeconds: 3600
-          path: token
-```
-
-예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이
-있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데
-사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을
-포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며,
-그렇지 않으면 토큰을 거부해야 한다. 이 필드는
-선택 사항이며 기본값은 API 서버의 식별자이다.
-
-`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효
-기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는
-API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서
-최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한
-상대 경로를 지정한다.
-
-{{< note >}}
-projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 
-해당 볼륨 소스의 업데이트를 수신하지 않는다.
-{{< /note >}}
+더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다.

 ### quobyte (사용 중단됨) {#quobyte}

@@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="
 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다.
 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.

-추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=<time zone>"을 추가해서 타임존을 명기할 수 있으며, 항상 `CRON_TZ`를 설정하는 것을 권장한다.
-
 {{< caution >}}
 모든 **크론잡** `일정:` 시간은
 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다.
@@ -28,6 +26,16 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 크론잡 컨트롤러가 사용하는 시간대로 결정한다.
 {{< /caution >}}

+{{< caution >}}
+[v1 CronJob API](/docs/reference/kubernetes-api/workload-resources/cron-job-v1/)은 
+위에서 설명한 타임존 설정을 공식적으로 지원하지는 않는다.
+
+`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은 쿠버네티스 프로젝트에서 공식적으로 지원하지는 않는다.
+`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은 
+크론탭을 파싱하고 다음 잡 생성 시간을 계산하는 내부 라이브러리의 구현 상세사항이다.
+프로덕션 클러스터에서는 사용을 권장하지 않는다.
+{{< /caution >}}
+
 크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이
 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
@@ -55,16 +63,15 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 ### 크론 스케줄 문법

 ```
-#      ┌────────────────── 타임존 (옵션)
-#      |      ┌───────────── 분 (0 - 59)
-#      |      │ ┌───────────── 시 (0 - 23)
-#      |      │ │ ┌───────────── 일 (1 - 31)
-#      |      │ │ │ ┌───────────── 월 (1 - 12)
-#      |      │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
-#      |      │ │ │ │ │                           특정 시스템에서는 7도 일요일)
-#      |      │ │ │ │ │
-#      |      │ │ │ │ │
-# CRON_TZ=UTC * * * * *
+# ┌───────────── 분 (0 - 59)
+# │ ┌───────────── 시 (0 - 23)
+# │ │ ┌───────────── 일 (1 - 31)
+# │ │ │ ┌───────────── 월 (1 - 12)
+# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
+# │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
+# │ │ │ │ │
+# │ │ │ │ │
+# * * * * *
 ```


@@ -78,9 +85,9 @@ kube-controller-manager 컨테이너에 설정된 시간대는



-예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
+예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.

-`CRON_TZ=UTC 0 0 13 * 5`
+`0 0 13 * 5`

 크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.

@@ -32,7 +32,7 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
 * 디플로이먼트의 PodTemplateSpec을 업데이트해서 [파드의 새로운 상태를 선언한다](#디플로이먼트-업데이트). 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
 * 만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 [디플로이먼트의 이전 버전으로 롤백](#디플로이먼트-롤백)한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
 * [더 많은 로드를 위해 디플로이먼트의 스케일 업](#디플로이먼트-스케일링).
-* [디플로이먼트 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 새로운 롤아웃의 시작을 재개한다.
+* [디플로이먼트 롤아웃 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 재개하여 새로운 롤아웃을 시작한다.
 * 롤아웃이 막혀있는지를 나타내는 [디플로이먼트 상태를 이용](#디플로이먼트-상태).
 * 더 이상 필요 없는 [이전 레플리카셋 정리](#정책-초기화).

@@ -697,12 +697,16 @@ nginx-deployment-1989198191   7         7         0         7m
 nginx-deployment-618515232    11        11        11        7m
 ```

-## 디플로이먼트의 일시 중지와 재개
+## 디플로이먼트 롤아웃 일시 중지와 재개 {#pausing-and-resuming-a-deployment}

-하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
-이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
+디플로이먼트를 업데이트할 때 (또는 계획할 때), 
+하나 이상의 업데이트를 트리거하기 전에 해당 디플로이먼트에 대한 롤아웃을 일시 중지할 수 있다. 
+변경 사항을 적용할 준비가 되면, 디플로이먼트 롤아웃을 재개한다. 
+이러한 방법으로, 불필요한 롤아웃을 트리거하지 않고 
+롤아웃 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.

 * 예를 들어, 생성된 디플로이먼트의 경우
+
  디플로이먼트 상세 정보를 가져온다.
  ```shell
  kubectl get deploy
@@ -753,7 +757,7 @@ nginx-deployment-618515232    11        11        11        7m
    REVISION  CHANGE-CAUSE
    1   <none>
    ```
-* 롤아웃 상태를 가져와서 디플로이먼트 업데이트가 성공적인지 확인한다.
+* 기존 레플리카셋이 변경되지 않았는지 확인하기 위해 롤아웃 상태를 출력한다.
    ```shell
    kubectl get rs
    ```
@@ -774,10 +778,10 @@ nginx-deployment-618515232    11        11        11        7m
    deployment.apps/nginx-deployment resource requirements updated
    ```

-    디플로이먼트를 일시 중지하기 전의 초기 상태는 해당 기능을 지속한다.
-    그러나 디플로이먼트가 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.
+    디플로이먼트 롤아웃을 일시 중지하기 전 디플로이먼트의 초기 상태는 해당 기능을 지속한다.
+    그러나 디플로이먼트 롤아웃이 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.

-* 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
+* 결국, 디플로이먼트 롤아웃을 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
    ```shell
    kubectl rollout resume deployment/nginx-deployment
    ```
@@ -911,8 +915,8 @@ deployment.apps/nginx-deployment patched
 {{< /note >}}

 {{< note >}}
-만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
-롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
+만약 디플로이먼트 롤아웃을 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
+롤아웃 중에 디플로이먼트 롤아웃을 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
 재개할 수 있다.
 {{< /note >}}

@@ -1052,8 +1056,7 @@ echo $?

 `.spec.template` 과 `.spec.selector` 은 `.spec` 에서 유일한 필수 필드이다.

-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
-이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.

 파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다.
 레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야 한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
@@ -1065,6 +1068,18 @@ echo $?

 `.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 이것의 기본값은 1이다.

+예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로 
+디플로이먼트의 크기를 수동으로 조정한 뒤, 
+매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행), 
+수동으로 설정했던 디플로이먼트의 크기가 오버라이드된다.
+
+[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가 
+디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
+
+대신, 쿠버네티스 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 
+`.spec.replicas` 필드를 자동으로 관리한다.
+
 ### 셀렉터

 `.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를
@@ -25,7 +25,8 @@ weight: 50

 잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.

-잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
+잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), 
+[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.

 <!-- body -->

@@ -206,6 +207,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
    있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 
    호스트네임을 사용할 수 있다.
  - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
+  
  각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
  간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
  [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@@ -249,7 +251,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고

 {{< note >}}
 만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
-도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
+도달하면 잡을 실행 중인 파드가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
 더 어려워질 수 있다. 디버깅하거나 로깅 시스템을 사용해서 실패한 작업의 결과를 실수로 손실되지 않도록
 하려면 `restartPolicy = "Never"` 로 설정하는 것을 권장한다.
 {{< /note >}}
@@ -344,6 +346,25 @@ spec:
 삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
 후에 TTL 컨트롤러에 의해 정리되지 않는다.

+{{< note >}}
+`ttlSecondsAfterFinished` 필드를 설정하는 것을 권장하는데, 
+이는 관리되지 않는 잡(직접 생성한, 
+크론잡 등 다른 워크로드 API를 통해 간접적으로 생성하지 않은 잡)의 
+기본 삭제 정책이 `orphanDependents`(관리되지 않는 잡이 완전히 삭제되어도 
+해당 잡에 의해 생성된 파드를 남겨둠)이기 때문이다.
+삭제된 잡의 파드가 실패하거나 완료된 뒤 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 언젠가 
+[가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)을 한다고 해도, 
+이렇게 남아 있는 파드는 클러스터의 성능을 저하시키거나 
+최악의 경우에는 이 성능 저하로 인해 클러스터가 중단될 수도 있다.
+
+[리밋 레인지(Limit Range)](/ko/docs/concepts/policy/limit-range/)와 
+[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여 
+특정 네임스페이스가 사용할 수 있는 자원량을 제한할 수 
+있다.
+{{< /note >}}
+
+
 ## 잡 패턴

 잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다.  잡 오브젝트는 과학
@@ -395,10 +416,10 @@ spec:
 | [정적 작업 할당을 사용한 인덱싱된 잡]             |          W          |        any           |
 | [잡 템플릿 확장]                             |          1          |     1이어야 함         |

-[작업 항목 당 파드가 있는 큐]: /docs/tasks/job/coarse-parallel-processing-work-queue/
-[가변 파드 수를 가진 큐]: /docs/tasks/job/fine-parallel-processing-work-queue/
+[작업 항목 당 파드가 있는 큐]: /ko/docs/tasks/job/coarse-parallel-processing-work-queue/
+[가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/
 [정적 작업 할당을 사용한 인덱싱된 잡]: /docs/tasks/job/indexed-parallel-processing-static/
-[잡 템플릿 확장]: /docs/tasks/job/parallel-processing-expansion/
+[잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/

 ## 고급 사용법

@@ -1,4 +1,11 @@
 ---
+
+
+
+
+
+
+
 title: 스테이트풀셋
 content_type: concept
 weight: 30
@@ -166,9 +173,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있

 ### 안정된 스토리지

-쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을
-생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
-1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
+쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
 명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
 참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
@@ -285,19 +290,29 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가

 `.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 
 컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
-기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
-파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
-[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
+기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다). 파드가 준비가 되는 시기에 대해 
+더 자세히 알아보고 싶다면, [컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.

 이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.

+### 레플리카
+
+`.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 기본값은 1이다.
+
+예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로 
+디플로이먼트의 크기를 수동으로 조정한 뒤, 
+매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행), 
+수동으로 설정했던 디플로이먼트의 크기가 
+오버라이드된다.
+
+[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가 
+디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
+대신, 쿠버네티스 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 
+`.spec.replicas` 필드를 자동으로 관리한다.
+
 ## {{% heading "whatsnext" %}}

-
-* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
-* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
-* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
-
 * [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
 * 스테이트풀셋을 사용하는 방법을 알아본다.
  * [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다.
@@ -306,10 +321,9 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
  * [스테이트풀셋 확장하기](/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
  * [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
  * [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.
-  * [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
+  * [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
 * `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
  스테이트풀셋 API에 대해 이해하기 위해 
-  {{< api-reference page="workload-resources/stateful-set-v1" >}}
-  오브젝트 정의를 읽는다.
+  {{< api-reference page="workload-resources/stateful-set-v1" >}} 오브젝트 정의를 읽는다.
 * [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
  이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.
@@ -128,8 +128,8 @@ Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적
 기반으로 계산한다. 컨트롤 플레인은 파드의 `.metadata.ownerReferences` 를 검사하여
 소유하는 워크로드 리소스를 발견한다.

-PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만,
-버짓이 차감된다.
+[비자발적 중단](#자발적-중단과-비자발적-중단)은 PDB로는 막을 수 없지만, 
+버짓은 차감된다.

 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
 그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는
@@ -159,7 +159,7 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한
 * `PodScheduled`: 파드가 노드에 스케줄되었다.
 * `ContainersReady`: 파드의 모든 컨테이너가 준비되었다.
 * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가
-  성공적으로 시작되었다.
+  성공적으로 완료(completed)되었다.
 * `Ready`: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드
  밸런싱 풀에 추가되어야 한다.

@@ -58,7 +58,7 @@ graph TB
    class zoneA,zoneB cluster;
 {{< /mermaid >}}

-레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
+레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘 알려진 레이블](/ko/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.

 ## 파드의 분배 제약 조건

@@ -234,6 +234,8 @@ graph BT

 스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.

+### 예시: TopologySpreadConstraints와 노드 어피니티
+
 zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.

 {{<mermaid>}}
@@ -349,12 +351,14 @@ defaultConstraints:
 비활성화된다.

 {{< note >}}
+`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
+없는 노드에 점수를 매기지 않는다. 
+이로 인해 기본 토폴로지 제약을 사용하는 경우의 
+레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다.
+
 노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
 레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는
 대신 자체 제약 조건을 정의한다.
-
-`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
-없는 노드에 점수를 매기지 않는다.
 {{< /note >}}

 클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,
@@ -13,8 +13,6 @@ weight: 98
 이해한다고 가정한다. 또한 기여하기 위한 더 많은 방법에 대해 배울 준비가 되었다고 가정한다. 이러한
 작업 중 일부에는 Git 커맨드 라인 클라이언트와 다른 도구를 사용해야 한다.

-
-
 <!-- body -->

 ## 개선 제안
@@ -29,8 +27,8 @@ website 스타일, 풀 리퀘스트 리뷰와 병합
 프로세스 또는 문서 작성의 다른 측면을 개선하기 위한 아이디어가 있을 수 있다. 투명성을 극대화하려면,
 이러한 유형의 제안을 SIG Docs 회의나
 [kubernetes-sig-docs 메일링리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 논의해야 한다.
-또한, 현재의 작업 방식과 과거의 결정이 왜 획기적인 변경을
-제안하기 전에 결정되었는지에 대한 맥락을 이해하는 데 실제로
+또한, 획기적인 변경을 제안하기 전에, 현재의 작업 방식과 과거의 결정이 
+어떻게 정해졌는지에 대한 맥락을 이해하는 데 실제로
 도움이 될 수 있다. 현재의 문서 작업이 어떻게 진행되는지에 대한 질문의
 답변을 얻는 가장 빠른 방법은 [kubernetes.slack.com](https://kubernetes.slack.com)의
 `#sig-docs` 슬랙 채널에 문의하는 것이다.
@@ -84,7 +82,7 @@ SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/
 새로운 기여자 홍보대사의 책임은 다음과 같다.

 - [#sig-docs 슬랙 채널](https://kubernetes.slack.com)에서 새로운 기여자의 질문을 모니터링한다.
- PR 랭글러와 협력하여 새로운 기여자에게 좋은 첫 이슈를 파악한다.
+- PR 랭글러와 협력하여 새로운 기여자에게 [좋은 첫 이슈](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue)를 파악한다.
 - 문서 리포지터리에 대한 처음 몇 번의 PR을 통해 새로운 기여자를 멘토링한다.
 - 새로운 기여자가 쿠버네티스 멤버가 되기 위해 필요한 보다 복잡한 PR을 작성하도록 지원한다.
 - 쿠버네티스 멤버 가입을 위해 [기여자를 후원](/ko/docs/contribute/advanced/#새로운-기여자-후원)한다.
@@ -56,12 +56,14 @@ prior to submitting new content. The information details follow.

 - 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 
  [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
+- 쿠버네티스 문서는 마크다운 스펙으로 [CommonMark](https://commonmark.org/)를 사용한다.
 - 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 
  쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 
  일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트를 이용하여 
  자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 
-  Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
+- [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)은 
+  Hugo에서 문서 콘텐츠가 표시되는 방식을 기술한다.
+- 쿠버네티스 문서 기여 시 [Docsy shortcodes](https://www.docsy.dev/docs/adding-content/shortcodes/) 또는 [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/)를 사용할 수 있다.
 - 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러
  [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 
  콘텐츠 표시를 제어한다.
@@ -26,9 +26,16 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
  - 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다.
  - 관련 `sig/` 레이블을 할당한다.
  - 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다.
+  - PR에 `@kubernetes/<sig>-pr-reviews` 코멘트를 남겨 [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md)에 리뷰를 요청할 수도 있다.
 - PR을 병합하려면 승인을 위한 `approve` 코멘트를 사용한다. 준비가 되면 PR을 병합한다.
  - 병합하기 전에 PR은 다른 멤버의 `/lgtm` 코멘트를 받아야 한다.
  - [스타일 지침]을 충족하지 않지만 기술적으로는 정확한 PR은 수락하는 것을 고려한다. 스타일 문제를 해결하는 `good first issue` 레이블의 새로운 이슈를 올리면 된다.
+  - [스타일 지침](/docs/contribute/style/style-guide/)을 충족하지 않지만 
+      기술적으로는 정확한 PR은 수락하는 쪽으로 고려한다. 
+      변경 사항을 승인하면, 스타일 이슈에 대한 새 이슈를 연다. 
+      보통 이러한 스타일 수정 이슈는 [좋은 첫 이슈](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue)로 지정할 수 있다.
+    - 스타일 수정 이슈를 좋은 첫 이슈로 표시하면 비교적 쉬운 작업을 공급하여 
+      새로운 기여자가 참여하는 것을 장려할 수 있다.

 ### 랭글러를 위해 도움이 되는 GitHub 쿼리

@@ -121,7 +121,7 @@ PR에서 사용할 수 있는 명령의 전체 목록을 보려면
  `priority/important-longterm` | 6개월 이내에 이 작업을 수행한다.
  `priority/backlog` | 무기한 연기할 수 있다. 자원이 있을 때 수행한다.
  `priority/awaiting-more-evidence` | 잠재적으로 좋은 이슈에 대해 잊지 않도록 표시한다.
-  `help` 또는 `good first issue` | 쿠버네티스나 SIG Docs 경험이 거의 없는 사람에게 적합하다. 자세한 내용은 [도움이 필요함 및 좋은 첫 번째 이슈 레이블](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)을 참고한다.
+  `help` 또는 `good first issue` | 쿠버네티스나 SIG Docs 경험이 거의 없는 사람에게 적합하다. 자세한 내용은 [도움이 필요함 및 좋은 첫 번째 이슈 레이블](https://kubernetes.dev/docs/guide/help-wanted/)을 참고한다.

  {{< /table >}}

@@ -24,7 +24,7 @@ weight: 20
 타입 | 설명
 :--- | :----------
 개념 | 개념 페이지는 쿠버네티스의 일부 측면을 설명한다. 예를 들어 개념 페이지는 쿠버네티스 디플로이먼트 오브젝트를 설명하고 배치, 확장 및 업데이트되는 동안 애플리케이션으로서 수행하는 역할을 설명할 수 있다. 일반적으로 개념 페이지는 일련의 단계가 포함되지 않지만 대신 태스크나 튜토리얼에 대한 링크를 제공한다. 개념 문서의 예로서 <a href="/ko/docs/concepts/architecture/nodes/">노드</a>를 참조하자.
-태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">저장소에 볼륨을 사용하도록 파드 구성</a>을 참조하자. 더 긴 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">활동성 및 준비성 프로브 구성</a>을 참조하자.
+태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 <a href="/ko/docs/tasks/configure-pod-container/configure-volume-storage/">저장소에 볼륨을 사용하도록 파드 구성</a>을 참조하자. 더 긴 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">활동성 및 준비성 프로브 구성</a>을 참조하자.
 튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
 {{< /table >}}

@@ -26,7 +26,7 @@ no_list: true
 * [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
 * [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
-* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/labels-annotations-taints/)
+* [잘 알려진 레이블, 어노테이션과 테인트](/ko/docs/reference/labels-annotations-taints/)

 ## 공식적으로 지원되는 클라이언트 라이브러리

@@ -65,7 +65,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
  * [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)

 * 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는
-  [포트와 프로토콜](/docs/reference/ports-and-protocols/) 리스트
+  [포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트
 ## API 설정

 이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
@@ -134,7 +134,7 @@ kubectl auth can-i list secrets --namespace dev --as dave
 no
 ```

-유사하게, `dev` 네임스페이스의 `dev-sa` 서비스 어카운트가 
+유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가 
 `target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다.

 ```bash
@@ -2,7 +2,7 @@
 title: 애그리게이션 레이어(Aggregation Layer)
 id: aggregation-layer
 date: 2018-10-08
-full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
+full_link: /ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
 short_description: >
  애그리게이션 레이어를 이용하면 사용자가 추가로 쿠버네티스 형식의 API를 클러스터에 설치할 수 있다.

@@ -2,7 +2,7 @@
 title: 컨피그맵(ConfigMap)
 id: configmap
 date: 2018-04-12
-full_link: /docs/concepts/configuration/configmap/
+full_link: /ko/docs/concepts/configuration/configmap/
 short_description: >
  키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 사용될 수 있다.

@@ -2,7 +2,7 @@
 title: 컨테이너 런타임
 id: container-runtime
 date: 2019-06-05
-full_link: /docs/setup/production-environment/container-runtimes
+full_link: /ko/docs/setup/production-environment/container-runtimes/
 short_description: >
 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.

@@ -2,7 +2,7 @@
 title: 장치 플러그인(Device Plugin)
 id: device-plugin
 date: 2019-02-02
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
+full_link: /ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
 short_description: >
  파드가 공급자별 초기화 또는 설정이 필요한 장치에 접근할 수 있도록 하는 소프트웨어 확장
 aka:
@@ -2,7 +2,7 @@
 title: 잡(Job)
 id: job
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/job
+full_link: /ko/docs/concepts/workloads/controllers/job/
 short_description: >
  완료를 목표로 실행되는 유한 또는 배치 작업.

@@ -2,7 +2,7 @@
 title: kube-proxy
 id: kube-proxy
 date: 2018-04-12
-full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+full_link: /ko/docs/reference/command-line-tools-reference/kube-proxy/
 short_description: >
  `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다.

@@ -2,7 +2,7 @@
 title: 범위 제한(LimitRange)
 id: limitrange
 date: 2019-04-15
-full_link:  /docs/concepts/policy/limit-range/
+full_link: /ko/docs/concepts/policy/limit-range/
 short_description: >
  네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공한다.

@@ -2,7 +2,7 @@
 title: 로깅(Logging)
 id: logging
 date: 2019-04-04
-full_link: /docs/concepts/cluster-administration/logging/
+full_link: /ko/docs/concepts/cluster-administration/logging/
 short_description: >
  로그는 클러스터나 애플리케이션에 의해 로깅된 이벤트의 목록이다.

@@ -2,7 +2,7 @@
 title: 네트워크 폴리시(Network Policy)
 id: network-policy
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/network-policies/
+full_link: /ko/docs/concepts/services-networking/network-policies/
 short_description: >
  파드 그룹들이 서로에 대한 그리고 다른 네트워크 엔드포인트에 대한 통신이 어떻게 허용되는지에 대한 명세이다.

@@ -14,6 +14,11 @@ tags:
 - operation
 ---

-[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다.
+[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 
+노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다.

-자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다.
+<!--more--> 
+
+자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 
+비자발적 중단은 의도하지 않은 것이며, 
+노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다.
@@ -2,7 +2,7 @@
 title: 파드 시큐리티 폴리시(Pod Security Policy)
 id: pod-security-policy
 date: 2018-04-12
-full_link: /docs/concepts/policy/pod-security-policy/
+full_link: /ko/docs/concepts/policy/pod-security-policy/
 short_description: >
  파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다.

@@ -10,7 +10,7 @@ aka:
 tags:
 - core-object
 ---
- SI 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현.
+ [SI](https://en.wikipedia.org/wiki/International_System_of_Units) 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현.

 <!--more-->

@@ -19,9 +19,8 @@ tags:
 큰 숫자는 킬로(kilo), 메가(mega), 또는 기가(giga) 
 단위로 표시할 수 있다.

-
 예를 들어, 숫자 `1.5`는 `1500m`으로, 숫자 `1000`은 `1k`로, `1000000`은
-`1M`으로 표시할 수 있다. 또한, 이진 표기법 접미사도 명시 가능하므로,
+`1M`으로 표시할 수 있다. 또한, [이진 표기법](https://en.wikipedia.org/wiki/Binary_prefix) 접미사도 명시 가능하므로,
 숫자 2048은 `2Ki`로 표기될 수 있다. 

 허용되는 10진수(10의 거듭 제곱) 단위는 `m` (밀리), `k` (킬로, 의도적인 소문자),
@@ -2,7 +2,7 @@
 title: 리소스 쿼터(Resource Quotas)
 id: resource-quota
 date: 2018-04-12
-full_link: /docs/concepts/policy/resource-quotas/
+full_link: /ko/docs/concepts/policy/resource-quotas/
 short_description: >
  네임스페이스당 전체 리소스 소비를 제한하는 제약을 제공한다.

@@ -15,4 +15,4 @@ tags:

 <!--more--> 

-민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 유휴 상태의 [암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)를 포함하여 우발적인 노출 위험을 줄인다. {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}}는 시크릿을 마운트된 볼륨의 파일로 참조하거나, 파드의 이미지를 풀링하는 kubelet이 시크릿을 참조한다. 시크릿은 기밀 데이터에 적합하고 [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터에 적합하다.
+민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 우발적인 노출 위험을 줄인다. 시크릿 값은 기본적으로 base64 문자열로 인코딩되어 암호화되지 않은 채로 저장되지만, [안전하게 암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)되도록 설정할 수 있다. {{< glossary_tooltip text="파드" term_id="pod" >}}는 볼륨 마운트 내의 파일 형태로 시크릿에 접근하며, 시크릿은 또한 kubelet이 파드를 위해 이미지를 풀링할 때에도 사용될 수 있다. 시크릿은 기밀 데이터를 다루는 용도로 적합으며, [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터를 다루는 용도로 적합하다.
@@ -2,7 +2,7 @@
 title: 서비스(Service)
 id: service
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/service/
+full_link: /ko/docs/concepts/services-networking/service/
 short_description: >
  네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법

@@ -2,7 +2,7 @@
 title: 스태틱 파드(Static Pod)
 id: static-pod
 date: 2019-02-12
-full_link: /docs/tasks/configure-pod-container/static-pod/
+full_link: /ko/docs/tasks/configure-pod-container/static-pod/
 short_description: >
  특정 노드의 Kubelet 데몬이 직접 관리하는 파드

@@ -2,7 +2,7 @@
 title: 테인트(Taint)
 id: taint
 date: 2019-01-11
-full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
+full_link: /ko/docs/concepts/scheduling-eviction/taint-and-toleration/
 short_description: >
  세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.

@@ -2,7 +2,7 @@
 title: 톨러레이션(Toleration)
 id: toleration
 date: 2019-01-11
-full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
+full_link: /ko/docs/concepts/scheduling-eviction/taint-and-toleration/
 short_description: >
  세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.

@@ -1,5 +1,9 @@
 ---
 title: kubectl 치트 시트
+
+
+
+
 content_type: concept
 card:
  name: reference
@@ -215,7 +219,7 @@ kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'

 # 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정).
 # `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다.
-for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done
+for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done
 ```

 ## 리소스 업데이트
@@ -286,10 +290,10 @@ kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # 여러 개

 ```bash
 kubectl delete -f ./pod.json                                      # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제
+kubectl delete pod unwanted --now                                 # 유예 시간 없이 즉시 파드 삭제
 kubectl delete pod,service baz foo                                # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제
 kubectl delete pods,services -l name=myLabel                      # name=myLabel 라벨을 가진 파드와 서비스 삭제
-kubectl delete pods,services -l name=myLabel --include-uninitialized      # 초기화되지 않은 것을 포함하여, name=myLabel 라벨을 가진 파드와 서비스 삭제
-kubectl -n my-ns delete pod,svc --all                                      # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제
+kubectl -n my-ns delete pod,svc --all                             # my-ns 네임스페이스 내 모든 파드와 서비스 삭제
 # awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제
 kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod
 ```
@@ -307,8 +311,7 @@ kubectl logs -f my-pod                              # 실시간 스트림 파드
 kubectl logs -f my-pod -c my-container              # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
 kubectl logs -f -l name=myLabel --all-containers    # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
 kubectl run -i --tty busybox --image=busybox -- sh  # 대화형 셸로 파드를 실행
-kubectl run nginx --image=nginx -n
-mynamespace                                         # 특정 네임스페이스에서 nginx 파드 실행
+kubectl run nginx --image=nginx -n mynamespace      # mynamespace 네임스페이스에서 nginx 파드 1개 실행
 kubectl run nginx --image=nginx                     # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
 --dry-run=client -o yaml > pod.yaml

@@ -320,6 +323,24 @@ kubectl exec my-pod -c my-container -- ls /         # 기존 파드에서 명령
 kubectl top pod POD_NAME --containers               # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
 kubectl top pod POD_NAME --sort-by=cpu              # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬
 ```
+## 컨테이너로/컨테이너에서 파일과 디렉터리 복사
+
+```bash
+kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir            # 로컬 디렉토리 /tmp/foo_dir 를 현재 네임스페이스의 my-pod 파드 안의 /tmp/bar_dir 로 복사
+kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container    # 로컬 파일 /tmp/foo 를 my-pod 파드의 my-container 컨테이너 안의 /tmp/bar 로 복사
+kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar       # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사
+kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar       # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사
+```
+{{< note >}}
+`kubectl cp` 명령을 사용하려면 컨테이너 이미지에 'tar' 바이너리가 포함되어 있어야 한다. 'tar'가 없으면, `kubectl cp`는 실패할 것이다.
+심볼릭 링크, 와일드카드 확장, 파일 모드 보존과 같은 고급 사용 사례에 대해서는 `kubectl exec` 를 고려해볼 수 있다.
+{{< /note >}}
+
+```bash
+tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar           # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사
+kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar    # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사
+```
+

 ## 디플로이먼트, 서비스와 상호 작용
 ```bash
@@ -91,6 +91,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 * `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
 * `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
 * kubectl 명령에 네임스페이스를 명시하지 않으면
+
 kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다. 
 kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
 이는 클러스터 외부에서 실행되었을 때와는 다른데, 
@@ -36,10 +36,9 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블

 적용 대상: 네임스페이스

-`NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 
-활성화되어 있으면, 
-쿠버네티스 API 서버가 모든 네임스페이스에 이 레이블을 적용한다. 
-레이블의 값은 네임스페이스의 이름으로 적용된다.
+({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인) 
+쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다. 
+레이블의 값은 네임스페이스의 이름으로 적용된다. 이 레이블의 값을 변경할 수는 없다.

 레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 
 이 레이블이 유용할 수 있다.
@@ -63,6 +62,16 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k
 이 레이블은 토폴로지 계층의 일부로도 사용된다. [`topology.kubernetes.io/zone`](#topologykubernetesiozone)에서 세부 사항을 확인한다.


+## kubernetes.io/change-cause {#change-cause}
+
+예시: `kubernetes.io/change-cause=kubectl edit --record deployment foo`
+
+적용 대상: 모든 오브젝트
+
+이 어노테이션은 어떤 오브젝트가 왜 변경되었는지 그 이유를 담는다.
+
+어떤 오브젝트를 변경할 수도 있는 `kubectl` 명령에 `--record` 플래그를 사용하면 이 레이블이 추가된다.
+
 ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}

 예시: `controller.kubernetes.io/pod-deletion-cost=10`
@@ -49,3 +49,19 @@ Kompose의 용도
 * 도커 컴포즈 파일을 쿠버네티스 오브젝트로 변환
 * 로컬 도커 개발 환경에서 나의 애플리케이션을 쿠버네티스를 통해 관리하도록 이전
 * V1 또는 V2 도커 컴포즈 `yaml` 파일 또는 [분산 애플리케이션 번들](https://docs.docker.com/compose/bundles/)을 변환
+
+## Kui
+
+[`Kui`](https://github.com/kubernetes-sigs/kui)는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고
+출력으로 그래픽적인 응답을 제공하는 GUI 도구이다.
+
+Kui는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고 출력으로 그래픽적인 응답을 제공한다.
+Kui는 ASCII 표 대신 정렬 가능한 표를 GUI로 제공한다.
+
+Kui를 사용하면 다음의 작업이 가능하다.
+
+* 자동으로 생성되어 길이가 긴 리소스 이름을 클릭하여 복사할 수 있다.
+* `kubectl` 명령을 입력하면 실행되는 모습을 볼 수 있으며, `kubectl` 보다 더 빠른 경우도 있다.
+* {{< glossary_tooltip text="잡" term_id="job">}}을 조회하여
+  실행 형상을 워터폴 그림으로 확인한다.
+* 탭이 있는 UI를 이용하여 클러스터의 자원을 클릭 동작으로 확인할 수 있다.
@@ -1,5 +1,7 @@
 ---
 title: 클라이언트 라이브러리
+
+
 content_type: concept
 weight: 30
 ---
@@ -35,7 +37,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 | JavaScript   | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples)
 | Python   | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples)

-
 ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리

 {{% thirdparty-content %}}
@@ -70,7 +71,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 | Python               | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
 | Python               | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
 | Ruby                 | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
-| Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
 | Ruby                 | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) |
 | Ruby                 | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
 | Rust                 | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |
@@ -1,5 +1,7 @@
 ---
 title: 쿠버네티스 API 헬스(health) 엔드포인트
+
+
 content_type: concept
 weight: 50
 ---
@@ -18,11 +20,11 @@ weight: 50
 `/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다.
 API 서버의 `healthz`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
 상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다.
-아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.
+아래 표시된 더 자세한 옵션은 운영자가 클러스터를 디버깅하거나 특정 API 서버의 상태를 이해하는 데 사용할 수 있다.

 다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.

-모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
+모든 엔드포인트에 대해, `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
 이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.

 ```shell
@@ -79,7 +79,7 @@ systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명
 # dnf install -y grubby && \
  sudo grubby \
  --update-kernel=ALL \
-  --args=”systemd.unified_cgroup_hierarchy=1"
+  --args="systemd.unified_cgroup_hierarchy=1"
 ```

 구성을 적용하려면 노드를 재부팅해야 한다.
@@ -67,7 +67,7 @@ sudo sysctl --system
 자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다.

 ## 필수 포트 확인 {#check-required-ports}
-[필수 포트들](/docs/reference/ports-and-protocols/)은
+[필수 포트들](/ko/docs/reference/ports-and-protocols/)은
 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
 한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다.

@@ -243,7 +243,7 @@ sudo mkdir -p $DOWNLOAD_DIR
 crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요)

 ```bash
-CRICTL_VERSION="v1.17.0"
+CRICTL_VERSION="v1.22.0"
 ARCH="amd64"
 curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
 ```
@@ -38,8 +38,8 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
 * 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
 * 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
 * **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
-* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
-* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
+* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
+* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다

 Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:

@@ -290,4 +290,4 @@ spec:



-[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
+[RuntimeClass]: https://kubernetes.io/ko/docs/concepts/containers/runtime-class/
@@ -214,117 +214,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.

 ## 클러스터에서 실행되는 서비스로 접근

-이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
-쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 
+이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다.

-쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
-[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
-고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
-클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을
-할 수 없을 것이다.
-
-### 통신을 위한 방식들
-
-클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.
-
-  - 공인 IP를 통해 서비스에 접근.
-    - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
-      서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
-      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
-    - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며,
-      인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
-      해당 서비스는 자체적으로 인증을 수행하는가?
-    - 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
-      해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다.
-    - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
-      접근할 필요는 없다.
-  - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근.
-    - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
-      서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에
-      접근을 하려고 하거나 debugging을 하려면 이를 사용한다.
-    - 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다.
-    - HTTP/HTTPS에서만 동작한다.
-    - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
-  - 클러스터 내 노드 또는 파드에서 접근.
-    - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
-      해당 셸에서 다른 노드, 파드, 서비스에 연결한다.
-    - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
-      클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
-      다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
-
-### 빌트인 서비스 검색
-
-일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. 
-`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다.
-
-```shell
-kubectl cluster-info
-```
-
-결괏값은 다음과 같을 것이다.
-
-```
-Kubernetes master is running at https://104.197.5.247
-elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
-kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
-kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
-grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
-heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
-```
-
-이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다.
-예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
-`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로
-`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다.
-(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
-
-#### 수작업으로 apiserver proxy URL을 구축
-
-위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에
-`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다.
-
-당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다.
-
-기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다.
-`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
-
-URL의 네임 부분에 지원되는 양식은 다음과 같다.
-
-* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다.
-* `<service_name>:<port_name>` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
-* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의)
-* `https:<service_name>:<port_name>` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
-
-##### 예제들
-
- * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
- * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
-
-```json
-{
-  "cluster_name" : "kubernetes_logging",
-  "status" : "yellow",
-  "timed_out" : false,
-  "number_of_nodes" : 1,
-  "number_of_data_nodes" : 1,
-  "active_primary_shards" : 5,
-  "active_shards" : 5,
-  "relocating_shards" : 0,
-  "initializing_shards" : 0,
-  "unassigned_shards" : 5
-}
-```
-
-### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근
-
-브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만
-
-  - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만,
-    당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다.
-  - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을
-    구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다.
-
-## 요청 redirect
+## redirect 요청하기

 redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다.

@@ -26,7 +26,7 @@ weight: 70

 이 작업은
 지원되는 환경이 필요한
-[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#nodeport) 서비스 타입을
+[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스 타입을
 대신 사용할 수 있다.

 <!-- lessoncontent -->
@@ -70,7 +70,7 @@ jsonpath에서 `.items[*]` 부분은 생략해야 하는데, 이는 명령어가
 반복하여 출력할 수 있다.

 ```shell
-kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
 sort
 ```

@@ -80,7 +80,7 @@ sort
 명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다.

 ```shell
-kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
 ```

 ## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기
@@ -86,7 +86,18 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi
 위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다.
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`

-포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다.
+포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. 또한, 이름이 지정된 포트와 지정되지 않은 포트 모두에 대해, *port_name* 자리에 포트 번호를 기재할 수도 있다.
+
+기본적으로, API 서버는 서비스로의 프록시를 HTTP로 제공한다. HTTPS를 사용하려면, 서비스 이름 앞에 `https:` 를 추가한다.
+`http://<쿠버네티스_컨트롤_플레인_주소>/api/v1/namespaces/<네임스페이스_이름>/services/<서비스_이름>/proxy`
+
+URL에서 `<서비스_이름>` 이 지원하는 형식은 다음과 같다.
+
+* `<서비스_이름>` - 기본 포트 또는 이름이 지정되지 않은 포트로 http를 사용하여 프록시
+* `<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 http를 사용하여 프록시
+* `https:<서비스_이름>:` - 기본 포트 또는 이름이 지정되지 않은 포트로 https를 사용하여 프록시(맨 끝의 콜론에 유의)
+* `https:<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 https를 사용하여 프록시
+

 ##### 예제

@@ -1,224 +0,0 @@
---
-
-
-title: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기
-content_type: task
-
---
-
-<!-- overview -->
-
-{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
-
-구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 컨트롤 플레인 노드를 복제할 수 있다. 하지만 이러한 스크립트들은 프로덕션 용도로 사용하기에 적합하지 않으며, 프로젝트의 CI에서만 주로 사용된다.
-이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 컨트롤 플레인을 관리하는 방법과 GCE와 함께 사용하기 위해 HA 컨트롤 플레인을 구현하는 방법에 관해 설명한다.
-
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
-<!-- steps -->
-
-## HA 호환 클러스터 시작
-
-새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다.
-
-* `MULTIZONE=true` - 서버의 기본 영역(zone)과 다른 영역에서 컨트롤 플레인 kubelet이 제거되지 않도록 한다.
-여러 영역에서 컨트롤 플레인 노드를 실행(권장됨)하려는 경우에 필요하다.
-
-* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다.
-true인 경우, Etcd의 리더 복제본에서 읽는다.
-이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다.
-
-선택적으로, 첫 번째 컨트롤 플레인 노드가 생성될 GCE 영역을 지정할 수 있다.
-다음 플래그를 설정한다.
-
-* `KUBE_GCE_ZONE=zone` - 첫 번째 컨트롤 플레인 노드가 실행될 영역.
-
-다음 샘플 커맨드는 europe-west1-b GCE 영역에 HA 호환 클러스터를 구성한다.
-
-```shell
-MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
-```
-
-위의 커맨드는 하나의 컨트롤 플레인 노드를 포함하는 클러스터를 생성한다.
-그러나 후속 커맨드로 새 컨트롤 플레인 노드를 추가할 수 있다.
-
-## 새 컨트롤 플레인 노드 추가
-
-HA 호환 클러스터를 생성했다면, 여기에 컨트롤 플레인 노드를 추가할 수 있다.
-`kube-up` 스크립트에 다음 플래그를 사용하여 컨트롤 플레인 노드를 추가한다.
-
-* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 컨트롤 플레인 노드의 복제본을
-만든다.
-
-* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 실행될 영역.
-반드시 다른 컨트롤 플레인 노드가 존재하는 영역과 동일한 지역(region)에 있어야 한다.
-
-HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로
-설정할 필요는 없다.
-
-다음 샘플 커맨드는 기존 HA 호환 클러스터에서
-컨트롤 플레인 노드를 복제한다.
-
-```shell
-KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
-```
-
-## 컨트롤 플레인 노드 제거
-
-다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 컨트롤 플레인 노드를 제거할 수 있다.
-
-* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다.
-
-* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 제거될 영역.
-
-* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 컨트롤 플레인 노드의 이름.
-명시하지 않으면, 해당 영역의 모든 복제본이 제거된다.
-
-다음 샘플 커맨드는 기존 HA 클러스터에서 컨트롤 플레인 노드를 제거한다.
-
-```shell
-KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
-```
-
-## 동작에 실패한 컨트롤 플레인 노드 처리
-
-HA 클러스터의 컨트롤 플레인 노드 중 하나가 동작에 실패하면,
-클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인
-노드를 추가하는 것이 가장 좋다.
-다음 샘플 커맨드로 이 과정을 시연한다.
-
-1. 손상된 복제본을 제거한다.
-
-```shell
-KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
-```
-
-<ol start="2"><li>기존 복제본을 대신할 새 노드를 추가한다.</li></ol>
-
-```shell
-KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
-```
-
-## HA 클러스터에서 컨트롤 플레인 노드 복제에 관한 모범 사례
-
-* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안,
-해당 영역에 있는 컨트롤 플레인 노드도 모두 동작에 실패할 것이다.
-영역 장애를 극복하기 위해 노드를 여러 영역에 배치한다
-(더 자세한 내용은 [멀티 영역](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다).
-
-* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된
-컨트롤 플레인에서의 합의를 위해서는 지속적 상태(persistent state) 변경 시 두 컨트롤 플레인 노드가 모두 정상적으로 동작 중이어야 한다.
-결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도
-클러스터의 심각한 장애 상태를 초래한다.
-따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은
-단일 노드로 구성된 컨트롤 플레인보다도 못하다.
-
-* 컨트롤 플레인 노드를 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
-클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
-이 작업은 [etcd 관리 가이드](https://etcd.io/docs/v2.3/admin_guide/#member-migration)에 기술한 대로
-Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다.
-(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다)
-
-
-
-<!-- discussion -->
-
-## 구현 지침
-
-![ha-control-plane](/docs/images/ha-control-plane.svg)
-
-### 개요
-위의 그림은 3개의 컨트롤 플레인 노드와 컴포넌트를 고가용 클러스터로 구성한 형상을 보여준다. 해당 컨트롤 플레인 노드의 컴포넌트들은 다음의 방법을 차용하고 있다.
-
- etcd: 인스턴스는 합의(consensus)를 통해서 클러스터링되어 있다.
-
- 컨트롤러들, 스케줄러, 클러스터 오토-스케일러: 리스(lease) 메커니즘을 통해 클러스터에서 각각 단 하나의 인스턴스만 활성화될 것이다.
-
- 애드-온(add-on) 메니저: 애드-온들이 동기화를 유지하도록 각각 독립적으로 동작한다.
-
-추가적으로, API 서버들 앞에서 동작하는 로드 밸런서는 내부와 외부 트래픽을 컨트롤 플레인 노드들로 연결(route)한다.
-각 컨트롤 플레인 노드는 다음 모드에서 다음 구성 요소를 실행한다.
-
-* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다.
-
-* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다.
-
-* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다.
-
-* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다.
-
-또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다.
-
-### 로드 밸런싱
-
-두 번째 컨트롤 플레인 노드를 배치할 때, 두 개의 복제본에 대한 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다.
-비슷하게 끝에서 두 번째의 컨트롤 플레인 노드를 제거한 후에는 로드 밸런서가 제거되고
-해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
-로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
-
-### 컨트롤 플레인 서비스와 Kubelet
-
-쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
-시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
-
-* 단일 노드 컨트롤 플레인의 경우, IP 주소는 단일 컨트롤 플레인 노드를 가리킨다.
-
-* 고가용성 컨트롤 플레인의 경우, IP 주소는 컨트롤 플레인 노드 앞의 로드밸런서를 가리킨다.
-
-마찬가지로 Kubelet은 외부 IP 주소를 사용하여 컨트롤 플레인과 통신한다.
-
-### 컨트롤 플레인 노드 인증서
-
-쿠버네티스는 각 컨트롤 플레인 노드의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 TLS 인증서를 발급한다.
-컨트롤 플레인 노드의 임시 퍼블릭 IP 주소에 대한 인증서는 없다.
-임시 퍼블릭 IP 주소를 통해 컨트롤 플레인 노드에 접근하려면, TLS 검증을 건너뛰어야 한다.
-
-### etcd 클러스터화
-
-etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용).
-이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다.
-
-### API 서버 신원
-
-{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
-
-API 서버 식별 기능은
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
-의해 제어되며 기본적으로 활성화되지 않는다.
-{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
-시작 시 `APIServerIdentity` 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다.
-
-```shell
-kube-apiserver \
--feature-gates=APIServerIdentity=true \
- # …다른 플래그는 평소와 같다.
-```
-
-부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는
-`kube-apiserver-{UUID}` 형식이다. 각 kube-apiserver는
-_kube-system_ {{< glossary_tooltip text="네임스페이스" term_id="namespace">}}에
-[임대](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)를 생성한다.
-임대 이름은 kube-apiserver의 고유 ID이다. 임대에는
-`k8s.io/component=kube-apiserver` 라는 레이블이 있다. 각 kube-apiserver는
-`IdentityLeaseRenewIntervalSeconds` (기본값은 10초)마다 임대를 새로 갱신한다. 각
-kube-apiserver는 `IdentityLeaseDurationSeconds` (기본값은 3600초)마다
-모든 kube-apiserver 식별 ID 임대를 확인하고,
-`IdentityLeaseDurationSeconds` 이상 갱신되지 않은 임대를 삭제한다.
-`IdentityLeaseRenewIntervalSeconds` 및 `IdentityLeaseDurationSeconds`는
-kube-apiserver 플래그 `identity-lease-renew-interval-seconds`
-및 `identity-lease-duration-seconds`로 구성된다.
-
-이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을
-사용하기 위한 전제조건이다(예: `StorageVersionAPI` 기능 게이트).
-
-## 추가 자료
-
-[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 윈도우 노드 추가
 min-kubernetes-server-version: 1.17
 content_type: tutorial
@@ -16,10 +16,10 @@ weight: 20
 이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
 이 페이지 대신 다음의 페이지들을 참고한다.

- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)

 추상적인 업그레이드 작업 절차는 다음과 같다.

@@ -78,10 +78,6 @@ OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리
    apt-mark unhold kubeadm && \
    apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubeadm
-    -
-    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
-    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
@@ -175,10 +171,6 @@ sudo kubeadm upgrade apply
    apt-mark unhold kubelet kubectl && \
    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubelet kubectl
-    -
-    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
-    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
@@ -218,10 +210,6 @@ sudo systemctl restart kubelet
    apt-mark unhold kubeadm && \
    apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubeadm
-    -
-    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
-    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
@@ -256,10 +244,6 @@ sudo systemctl restart kubelet
    apt-mark unhold kubelet kubectl && \
    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubelet kubectl
-    -
-    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
-    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
@@ -10,7 +10,8 @@ content_type: task
 {{< feature-state for_k8s_version="v1.21" state="stable" >}}

 이 문서는 쿠버네티스 클러스터에서 {{< glossary_tooltip term_id="sysctl" >}} 인터페이스를 사용하여 
-커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다.
+커널 파라미터를 어떻게 구성하고, 사용하는지를 
+설명한다.

 ## {{% heading "prerequisites" %}}

@@ -20,6 +21,7 @@ content_type: task
 일부 단계에서는 실행 중인 클러스터의 kubelet에서 
 커맨드 라인 옵션을 재구성할 필요가 있다.

+
 <!-- steps -->

 ## 모든 sysctl 파라미터 나열
@@ -57,7 +59,8 @@ sysctl은 _safe_ sysctl과 _unsafe_ sysctl로 구성되어 있다. _safe_ sysctl
 - `kernel.shm_rmid_forced`,
 - `net.ipv4.ip_local_port_range`,
 - `net.ipv4.tcp_syncookies`,
- `net.ipv4.ping_group_range` (Kubernetes 1.18 이후).
+- `net.ipv4.ping_group_range` (쿠버네티스 1.18 이후),
+- `net.ipv4.ip_unprivileged_port_start` (쿠버네티스 1.22 이후).

 {{< note >}}
 `net.ipv4.tcp_syncookies` 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다.
@@ -112,10 +115,13 @@ _네임스페이스_ sysctl만 이 방법을 사용할 수 있다.
 이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나 
 특권있는 컨테이너의 데몬셋을 사용하여야 한다.

-네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다.
+네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. 
+securityContext는 동일한 파드의 모든 컨테이너에 적용된다.

 이 예시는 safe sysctl `kernel.shm_rmid_forced`와 두 개의 unsafe sysctl인 
 `net.core.somaxconn` 과 `kernel.msgmax` 를 설정하기 위해 파드 securityContext를 사용한다.
+스펙에 따르면 _safe_ sysctl과 _unsafe_ sysctl 간 
+차이는 없다.

 {{< warning >}}
 파라미터의 영향을 파악한 후에만 운영체제가 
@@ -96,11 +96,10 @@ hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다.

 설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고
 지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가
-읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를
-지정한다. 여기서는 
+읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 지정한다. 여기서는 
 퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을 
 `manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을 
-이 퍼시스턴트볼륨에 바인딩하는데 사용한다.
+이 퍼시스턴트볼륨에 바인딩하는 데 사용한다.

 퍼시스턴트볼륨을 생성한다.

@@ -237,8 +236,14 @@ sudo rmdir /mnt/data

 이제 사용자 노드에서 셸을 종료해도 된다.

+## 하나의 퍼시스턴트볼륨을 두 경로에 마운트하기

+{{< codenew file="pods/storage/pv-duplicate.yaml" >}}

+하나의 퍼시스턴트볼륨을 nginx 컨테이너의 두 경로에 마운트할 수 있다.
+
+`/usr/share/nginx/html` - 정적 웹사이트 용
+`/etc/nginx/nginx.conf` - 기본 환경 설정 용

 <!-- discussion -->

@@ -6,29 +6,36 @@ weight: 100

 <!-- overview -->

-이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 
+이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 
+{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을 
 사용하는 파드를 생성하는 방법을 보여준다.

+{{% thirdparty-content single="true" %}}
+
 ## {{% heading "prerequisites" %}}

-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+* {{< include "task-tutorial-prereqs.md" >}}

-* 이 실습을 수행하기 위해, 
-[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다.
+* 이 실습을 수행하기 위해, `docker` 명령줄 도구와
+[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다.

 <!-- steps -->

-## 도커 로그인
+## 도커 허브 로그인

 노트북에 프라이빗 이미지를 받아오기 위하여 레지스트리 인증을 필수로 수행해야 한다.

+`docker` 도구를 사용하여 도커 허브에 로그인한다. 자세한 정보는 
+[도커 ID 계정](https://docs.docker.com/docker-id/#log-in)의 _로그 인_ 섹션을 참조한다.
+
 ```shell
 docker login
 ```

-프롬프트가 나타나면, 도커 사용자 이름(username)과 비밀번호(password)를 입력하자.
+프롬프트가 나타나면, 도커 ID를 입력한 다음, 사용하려는 자격증명(액세스 토큰, 
+또는 도커 ID의 비밀번호)을 입력한다.

-로그인 프로세스는 권한 토큰 정보를 가지고 있는 `config.json` 파일을 생성하거나 업데이트 한다.
+로그인 프로세스를 수행하면 권한 토큰 정보를 가지고 있는 `config.json` 파일이 생성되거나 업데이트된다. [쿠버네티스가 이 파일을 어떻게 해석하는지](/ko/docs/concepts/containers/images#config-json) 참고한다.

 `config.json` 파일을 확인하자.

@@ -171,14 +178,14 @@ janedoe:xxxxxxxxxxx

 ## 시크릿을 사용하는 파드 생성하기

-다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 파드의 구성 파일이다.
+다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 예제 파드의 매니페스트이다.

 {{< codenew file="pods/private-reg-pod.yaml" >}}

-아래의 파일을 다운로드받는다.
+위 파일을 컴퓨터에 다운로드한다.

 ```shell
-wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
+curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
 ```

 `my-private-reg-pod.yaml` 파일 안에서, `<your-private-image>` 값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다.
@@ -200,9 +207,10 @@ kubectl get pod private-reg

 ## {{% heading "whatsnext" %}}

-* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
+* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기
+  * 또는 {{< api-reference page="config-and-storage-resources/secret-v1" >}} API 레퍼런스 읽어보기
 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
 * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
 * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
-* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기.
-* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기.
+* 파드의 [컨테이너 정의](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)의 `imagePullSecrets` 필드에 대해 읽어보기
+
@@ -11,7 +11,11 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T

 ## {{% heading "prerequisites" %}}

-{{< include "task-tutorial-prereqs.md" >}}
+쿠버네티스 클러스터가 있어야 하며, kubectl 명령줄 도구가 
+클러스터와 통신하도록 설정되어 있어야 한다. 컨트롤 플레인 호스트가 아닌 
+두 개 이상의 노드로 구성된 클러스터에서 이 튜토리얼을 수행하는 것을 권장한다. 
+클러스터가 없다면, [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)를 
+이용하여 생성할 수 있다.

 <!-- steps -->

@@ -24,16 +28,9 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T
 Konnectivity 서비스를 사용하고 네트워크 트래픽을 클러스터 노드로 보내도록 
 API 서버를 구성해야 한다.

-1. `ServiceAccountTokenVolumeProjection` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
-활성화되어 있는지
-확인한다. kube-apiserver에 다음과 같은 플래그를 제공하여
-[서비스 어카운트 토큰 볼륨 보호](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)를
-활성화할 수 있다.
-   ```
-   --service-account-issuer=api
-   --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
-   --api-audiences=system:konnectivity-server
-   ```
+1. [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) 
+기능이 활성화되어 있는지 확인한다. 
+쿠버네티스 v1.20부터는 기본적으로 활성화되어 있다.
 1. `admin/konnectivity/egress-selector-configuration.yaml`과 같은 송신 구성 파일을 생성한다.
 1. API 서버의 `--egress-selector-config-file` 플래그를 
 API 서버 송신 구성 파일의 경로로 설정한다.
@@ -178,13 +178,13 @@ kubectl delete job -l jobgroup=jobexample


 ```liquid
-{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
+{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
                  { "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
                  { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
 %}
-{%- for p in params %}
-{%- set name = p["name"] %}
-{%- set url = p["url"] %}
+{% for p in params %}
+{% set name = p["name"] %}
+{% set url = p["url"] %}
 ---
 apiVersion: batch/v1
 kind: Job
@@ -204,7 +204,7 @@ spec:
        image: busybox
        command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
      restartPolicy: Never
-{%- endfor %}
+{% endfor %}
 ```

 위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해
@@ -467,9 +467,7 @@ behavior:
      periodSeconds: 60
 ```

-마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
-전략을 추가할 수 있다.
-분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소
+분당 제거되는 파드 수가 5를 넘지 않도록 하기 위해, 크기가 5로 고정된 두 번째 축소
 정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면
 자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다.

@@ -506,6 +504,45 @@ HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한
 다시 활성화할 때까지 HPA는 대상 조정을
 중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정).

+### 디플로이먼트와 스테이트풀셋을 horizontal autoscaling으로 전환하기
+
+HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 또는 둘 중 하나의
+{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서 
+`spec.replicas`의 값을 삭제하는 것이 바람직하다. 
+이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로) 
+오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를 
+`spec.replicas`에 기재된 값으로 조정할 것이다. 
+이는 바람직하지 않으며 HPA가 활성화된 경우에 문제가 될 수 있다.
+
+`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데, 
+이는 이 키의 기본값이 1이기 때문이다(레퍼런스: 
+[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)). 
+값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다. 
+이후의 디플로이먼트 애플리케이션은 정상적으로 작동하며 롤링 업데이트 구성도 의도한 대로 동작한다.
+이러한 1회성 저하를 방지하는 방법이 존재하며, 
+디플로이먼트 수정 방법에 따라 다음 중 한 가지 방법을 선택한다.
+
+{{< tabs name="fix_replicas_instructions" >}}
+{{% tab name="클라이언트 쪽에 적용하기 (기본값))" %}}
+
+1. `kubectl apply edit-last-applied deployment/<디플로이먼트_이름>`
+2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이 
+    업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다.
+3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다. 
+    소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록 
+    변경 사항을 커밋하고 추가 필요 단계를 수행한다.
+4. 이제 `kubectl apply -f deployment.yaml`를 실행할 수 있다.
+
+{{% /tab %}}
+{{% tab name="서버 쪽에 적용하기" %}}
+
+[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면, 
+정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership) 
+가이드라인을 참조한다.
+
+{{% /tab %}}
+{{< /tabs >}}
+
 ## {{% heading "whatsnext" %}}


@@ -1,6 +1,10 @@
 ---
 title: 클러스터에서 TLS 인증서 관리
 content_type: task
+
+
+
+
 ---

 <!-- overview -->
@@ -158,9 +162,19 @@ Events: <none>

 ## 인증서 서명 요청 승인 받기

-인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나
-클러스터 관리자에 의해 일회성으로 수행한다. 여기에 
-관련된 내용에 대한 자세한 내용은 아래에서 설명한다.
+[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 승인은 
+자동화된 승인 프로세스 또는 클러스터 관리자의 일회성 승인으로 수행된다. 
+인증서 요청을 승인할 수 있는 권한이 있다면, 
+다음과 같이 `kubectl`을 사용하여 수동으로 수행할 수 있다.
+
+```shell
+kubectl certificate approve my-svc.my-namespace
+```
+
+```none
+certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
+```
+

 ## 인증서 다운로드 및 사용

@@ -233,7 +233,7 @@ kubectl get events | grep hello-apparmor
 proc attr을 확인하여 컨테이너가 실제로 해당 프로파일로 실행 중인지 확인할 수 있다.

 ```shell
-kubectl exec hello-apparmor cat /proc/1/attr/current
+kubectl exec hello-apparmor -- cat /proc/1/attr/current
 ```
 ```
 k8s-apparmor-example-deny-write (enforce)
@@ -242,7 +242,7 @@ k8s-apparmor-example-deny-write (enforce)
 마지막으로 파일 쓰기를 통해 프로파일을 위반하면 어떻게 되는지 확인할 수 있다.

 ```shell
-kubectl exec hello-apparmor touch /tmp/test
+kubectl exec hello-apparmor -- touch /tmp/test
 ```
 ```
 touch: /tmp/test: Permission denied
@@ -72,7 +72,7 @@ weight: 10
        <div class="row">
            <div class="col-md-8">
                <p><b>컨트롤 플레인은 클러스터 관리를 담당한다.</b> 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
-                <p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>
+                <p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 하는데, 이는 한 노드가 다운되면 etcd 멤버와 컨트롤 플레인 인스턴스가 사라져 중복성(redundancy)을 잃기 때문이다. 컨트롤 플레인 노드를 추가하여 이러한 위험을 줄일 수 있다.</p>

            </div>
            <div class="col-md-4">
@@ -103,7 +103,7 @@ weight: 10
        <div class="row">
            <div class="col-md-8">
                <p>
-                  첫 번째 디플로이먼트로, NGINX를 사용해 모든 요청을 에코(echo)하는 도커 컨테이너로 패키지한 hello-node 애플리케이션을 사용해보자. (아직 hello-node 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, <a href="/docs/tutorials/hello-minikube/">Hello Minikube 튜토리얼</a>의 지시를 따른다.)
+                  첫 번째 디플로이먼트로, NGINX를 사용해 모든 요청을 에코(echo)하는 도커 컨테이너로 패키지한 hello-node 애플리케이션을 사용해보자. (아직 hello-node 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, <a href="/ko/docs/tutorials/hello-minikube/">Hello Minikube 튜토리얼</a>의 지시를 따른다.)
                <p>

                 <p>이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!</p>
@@ -39,7 +39,7 @@ weight: 10
 				<li><i>LoadBalancer</i> - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다. </li>
 				<li><i>ExternalName</i> - <code>CNAME</code> 레코드 및 값을 반환함으로써 서비스를 <code>externalName</code> 필드의 내용(예를 들면, <code>foo.bar.example.com</code>)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 <code>kube-dns</code> v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.</li>
 			</ul>
-			<p>다른 서비스 타입들에 대한 추가 정보는 <a href="/ko/docs/tutorials/services/source-ip/">소스 IP 이용하기</a>  튜토리얼에서 확인 가능하다. 또한 <a href="/docs/concepts/services-networking/connect-applications-service">서비스들로 애플리케이션에 접속하기</a>도 참고해 보자.</p>
+			<p>다른 서비스 타입들에 대한 추가 정보는 <a href="/ko/docs/tutorials/services/source-ip/">소스 IP 이용하기</a>  튜토리얼에서 확인 가능하다. 또한 <a href="/ko/docs/concepts/services-networking/connect-applications-service/">서비스들로 애플리케이션에 접속하기</a>도 참고해 보자.</p>
 			<p>부가적으로, spec에 <code>selector</code>를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. <code>selector</code> 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 <code>type: ExternalName</code>을 이용하겠다고 확고하게 의도하는 경우이다.</p>
 			</div>
 			<div class="col-md-4">
@@ -28,7 +28,7 @@ weight: 10
                <h3>애플리케이션을 스케일하기</h3>
                
                <p>지난 모듈에서 <a href="/ko/docs/concepts/workloads/controllers/deployment/"> 디플로이먼트</a>를 만들고,
-                    <a href="/docs/concepts/services-networking/service/">서비스</a>를
+                    <a href="/ko/docs/concepts/services-networking/service/">서비스</a>를
                    통해서 디플로이먼트를 외부에 노출시켜 봤다. 해당 디플로이먼트는 애플리케이션을 구동하기 위해 단
                    하나의 파드만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를
                    조정할 필요가 있다.</p>
@@ -163,7 +163,7 @@ command=GET

 ## `Type=NodePort` 인 서비스에서 소스 IP

-[`Type=NodePort`](/ko/docs/concepts/services-networking/service/#nodeport)인
+[`Type=NodePort`](/ko/docs/concepts/services-networking/service/#type-nodeport)인
 서비스로 보내진 패킷은
 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다.

@@ -894,8 +894,7 @@ kubernetes-node-2g2d
 kubectl get nodes
 ```

-[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여
-클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자.
+이 튜토리얼에서는 클러스터가 최소 4개의 노드로 구성되었다고 가정한다. 클러스터의 노드가 4개보다 많다면, [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) 명령을 이용하여 4개 노드를 제외하고 다른 모든 노드를 통제(cordon)한다. 이렇게 4개 노드만 사용하도록 제한하여, 다음의 유지보수 시뮬레이션 예시에서 주키퍼 파드를 스케줄링할 때 어피니티와 PodDisruptionBudget 제약이 발생하도록 할 수 있다.

 ```shell
 kubectl cordon <노드-이름>
@@ -0,0 +1,20 @@
+
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test
+spec:
+  containers:
+    - name: test
+      image: nginx
+      volumeMounts:
+        - name: site-data
+          mountPath: /usr/share/nginx/html
+          subPath: html
+        - name: config
+          mountPath: /etc/nginx/nginx.conf
+          subPath: nginx.conf
+  volumes:
+    - name: config
+      persistentVolumeClaim:
+        claimName: test-nfs-claim
Author	SHA1	Message	Date
Kubernetes Prow Robot	767215ff3c	Merge pull request #32479 from jihoon-seo/220325_Update_links_1.22-ko.4 [ko] Update links in `dev-1.22-ko.4`	2022-03-25 00:19:50 -07:00
Jihoon Seo	d42829f16e	[ko] Update links in dev-1.22-ko.4	2022-03-25 11:52:36 +09:00
Kubernetes Prow Robot	9d70f6a818	Merge pull request #31774 from inerplat/fix/pv_access_modes [ko] fix description of the access mode of pv	2022-02-18 01:38:23 -08:00
DH Kim	7032cbd36c	[ko] fix description of the access mode of pv	2022-02-18 14:23:19 +09:00
Kubernetes Prow Robot	8d983ba5f0	Merge pull request #31417 from jihoon-seo/220120_ko_Update_links_in_dev-1.22-ko.4 [ko] Update links in `dev-1.22-ko.4`	2022-01-20 16:53:59 -08:00
Kubernetes Prow Robot	1f256b0498	Merge pull request #31416 from jihoon-seo/220120_ko_Update_type-nodeport_anchor [ko] Update anchor (type-nodeport)	2022-01-20 16:51:59 -08:00
Jihoon Seo	1e2ba97595	[ko] Update links in dev-1.22-ko.4	2022-01-20 18:51:30 +09:00
Jihoon Seo	ca96b1a14d	[ko] Update anchor (type-nodeport)	2022-01-20 18:41:34 +09:00
Kubernetes Prow Robot	5cc8f3da14	Merge pull request #30851 from jihoon-seo/211210_Outdated_M27-M33 [ko] Update outdated files in dev-1.22-ko.4 (M27-M33)	2022-01-20 01:33:51 -08:00
Jihoon Seo	bd70b604e2	[ko] Update outdated files in dev-1.22-ko.4 M27-33	2022-01-14 17:21:08 +09:00
Kubernetes Prow Robot	eb89208739	Merge pull request #30852 from jihoon-seo/211210_Outdated_M34-M42 [ko] Update outdated files in dev-1.22-ko.4 (M34-M42)	2022-01-13 23:52:28 -08:00
Kubernetes Prow Robot	fde5db81d7	Merge pull request #30892 from jihoon-seo/211213_Outdated_M43 [ko] Update outdated files in dev-1.22-ko.4 (M43-M55)	2022-01-13 22:12:28 -08:00
Jihoon Seo	7d020244e7	[ko] Update outdated files in dev-1.22-ko.4 M43-55	2022-01-14 11:08:01 +09:00
Kubernetes Prow Robot	dda55048cd	Merge pull request #31146 from jihoon-seo/211230_ko_Update_ingress.md [ko] Update `ingress.md` in `dev-1.22-ko.4`	2022-01-11 22:26:36 -08:00
Kubernetes Prow Robot	2663de6b83	Merge pull request #30848 from jihoon-seo/211210_Outdated_M1-M9 [ko] Update outdated files in dev-1.22-ko.4 (M1-M11)	2022-01-09 19:11:11 -08:00
Jihoon Seo	563575b33b	[ko] Update ingress.md in dev-1.22-ko.4	2021-12-30 18:00:29 +09:00
Kubernetes Prow Robot	7e07310275	Merge pull request #30893 from jihoon-seo/211213_Outdated_M56 [ko] Update outdated files in dev-1.22-ko.4 (M56-M70)	2021-12-29 23:50:50 -08:00
Jihoon Seo	6fc5dff87b	[ko] Update outdated files in dev-1.22-ko.4 M56-70	2021-12-30 11:04:35 +09:00
Jihoon Seo	f7e1a9f9f6	[ko] Update outdated files in dev-1.22-ko.4 M1-M11	2021-12-13 13:48:27 +09:00
Jihoon Seo	8171fd069c	[ko] Update outdated files in dev-1.22-ko.4 M34-42	2021-12-10 19:19:08 +09:00
Kubernetes Prow Robot	854318acaa	Merge pull request #30850 from jihoon-seo/211210_Outdated_M12-M26 [ko] Update outdated files in dev-1.22-ko.4 (M12-M26)	2021-12-10 00:57:10 -08:00
Jihoon Seo	2ee31ae39c	[ko] Update outdated files in dev-1.22-ko.4 M12-26	2021-12-10 17:23:34 +09:00
Kubernetes Prow Robot	37e625e28c	Merge pull request #30780 from jlbutler/update-122-config-for-123 update release-1.22 config for release 1.23	2021-12-07 15:57:22 -08:00
Jesse Butler	d3298e927b	update release-1.22 config for release 1.23	2021-12-06 18:10:14 -05:00