diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
index af04a2fd9092f..d800263154cb2 100644
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@@ -8,7 +8,7 @@ weight: 10
하나의 노드는 쿠버네티스에서 하나의 워커 머신으로, 이전에는 `미니언`으로 알려졌다. 노드는
클러스터에 따라, VM 또는 물리 머신이 될 수 있다. 각 노드는
-[파드](/ko/docs/concepts/workloads/pods/pod/)를 동작시키기 위해 필요한 서비스를 포함하며 마스터 컴포넌트에 의해 관리된다. 노드 상의 서비스는 [컨테이너 런타임](/ko/docs/concepts/overview/components/#노드-컴포넌트), kubelet 그리고 kube-proxy를 포함한다. 보다
+[파드](/ko/docs/concepts/workloads/pods/pod/)를 동작시키기 위해 필요한 서비스를 포함하며 마스터 컴포넌트에 의해 관리된다. 노드 상의 서비스는 [컨테이너 런타임](/ko/docs/concepts/overview/components/#컨테이너-런타임), kubelet 그리고 kube-proxy를 포함한다. 보다
상세한 내용은 아키텍처 문서 내
[쿠버네티스 노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
섹션을 확인한다.
@@ -281,7 +281,7 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다.
노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다.
-kubelet에 의해 구동된 모든 컨테이너를 포함하지만, [컨테이너 런타임](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 의해 직접 구동된 컨테이너 또는 컨테이너 외부에서 동작하는 임의의 프로세스는 해당되지 않는다.
+kubelet에 의해 구동된 모든 컨테이너를 포함하지만, [컨테이너 런타임](/ko/docs/concepts/overview/components/#컨테이너-런타임)에 의해 직접 구동된 컨테이너 또는 컨테이너 외부에서 동작하는 임의의 프로세스는 해당되지 않는다.
파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면,
[reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다.
diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
index c1d32704bc086..2ce5a61fa27ea 100644
--- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
@@ -96,7 +96,7 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
```
Events:
- FirstSeen LastSeen Count From SubobjectPath Type Reason Message
+ FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md
index 37a1a22642949..d7e2735e01dda 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/names.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/names.md
@@ -9,8 +9,7 @@ weight: 20
클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 [_이름_](#names) 을 가지고 있다.
또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 [_UID_](#uids) 를 가지고 있다.
-예를 들어, 이름이 “myapp-1234”인 파드는 하나만 가질 수 있지만, 이름이 “myapp-1234”인
-파드와 디플로이먼트는 각각 가질 수 있다.
+예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 가질 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 가질 수 있다.
유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md
new file mode 100644
index 0000000000000..9ad714860d42b
--- /dev/null
+++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md
@@ -0,0 +1,90 @@
+---
+title: 엔드포인트 슬라이스
+feature:
+ title: 엔드포인트 슬라이스
+ description: >
+ 쿠버네티스 클러스터에서 확장 가능한 네트워크 엔드포인트 추적.
+
+content_template: templates/concept
+weight: 10
+---
+
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+_엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
+추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
+대안을 제안한다.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 엔드포인트 슬라이스 리소스 {#endpointslice-resource}
+
+쿠버네티스에서 엔드포인트 슬라이스는 일련의 네트워크 엔드 포인트에 대한
+참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 EndpointSlice
+컨트롤러는 자동으로 엔드포인트 슬라이스를 생성한다. 이 엔드포인트 슬라이스는
+서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트
+슬라이스는 고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
+
+예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice
+리소스 샘플이 있다.
+
+```yaml
+apiVersion: discovery.k8s.io/v1alpha1
+kind: EndpointSlice
+metadata:
+ name: example-abc
+ labels:
+ kubernetes.io/service-name: example
+addressType: IP
+ports:
+ - name: http
+ protocol: TCP
+ port: 80
+endpoints:
+ - addresses:
+ - "10.1.2.3"
+ - "2001:db8::1234:5678"
+ conditions:
+ ready: true
+ hostname: pod-1
+ topology:
+ kubernetes.io/hostname: node-1
+ topology.kubernetes.io/zone: us-west2-a
+```
+
+기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트 슬라이스에는
+각각 100개 이하의 엔드포인트가 가지고 있다. 이 스케일 아래에서 엔드포인트 슬라이스는
+엔드포인트 및 서비스와 1:1 매핑해야하며, 유사한 성능을 가져야 한다.
+
+엔드포인트 슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에
+신뢰할 수 있는 소스로 작용할 수 있다. 활성화 하면, 많은 수의 엔드포인트를 가지는
+서비스에 대해 성능 향상을 제공한다.
+
+## 사용동기
+
+엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
+간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
+서비스가 점점 더 커짐에 따라, 이 API의 한계가 더욱 눈에 띄게 되었다.
+특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
+어려움이 있었다.
+
+이후로 서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
+리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스
+구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고
+엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다.
+엔드포인트 슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
+같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [엔드포인트 슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpoint-slices)
+* [애플리케이션을 서비스와 함께 연결하기](/docs/concepts/services-networking/connect-applications-service/) 를 읽는다.
+
+{{% /capture %}}
diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md
index d8baa8767ee5a..dbeb1fb643deb 100644
--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@@ -55,7 +55,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
한다([파드 셀렉터](#파드-셀렉터)를 본다).
-데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/)는 `Always` 를 가져야 하며,
+데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)는 `Always` 를 가져야 하며,
명시되지 않은 경우 기본으로 `Always`가 된다.
### 파드 셀렉터
diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md
index a89fa36bc594c..7c012196d542b 100644
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@@ -82,8 +82,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. 만약 디플로이먼트가 여전히 생성중이면 다음과 유사하게 출력된다.
```shell
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 0 0 0 1s
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 0/3 0 0 1s
```
클러스터에서 디플로이먼트를 점검할 때 다음 필드가 표시된다.
@@ -104,8 +104,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다. 다음과 유사하게 출력된다.
```shell
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 3 3 3 18s
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 3/3 3 3 18s
```
디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
@@ -159,7 +159,7 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
또는 간단하게 다음의 명령어를 사용한다.
```shell
- kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record
```
이와 유사하게 출력된다.
@@ -198,8 +198,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
* 롤아웃이 성공하면 `kubectl get deployments` 를 실행해서 디플로이먼트를 볼 수 있다.
이와 유사하게 출력된다.
```
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 3 3 3 36s
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 3/3 3 3 36s
```
* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고,
@@ -439,7 +439,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
Events:
- FirstSeen LastSeen Count From SubobjectPath Type Reason Message
+ FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
@@ -533,8 +533,8 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
이와 유사하게 출력된다.
```
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 3 3 3 30m
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 3/3 3 3 30m
```
3. 디플로이먼트의 설명 가져오기.
```shell
diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
index 6dcfd6908bd98..cf52d7890987e 100644
--- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -39,7 +39,7 @@ _레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레
단일 노드에서 개별 프로세스를 감시하는 대신 레플리케이션 컨트롤러는
여러 노드에서 여러 파드를 감시한다.
-레플리케이션 컨트롤러는 디스커션에서 종종 "rc" 혹은 "rcs"로 축약되며
+레플리케이션 컨트롤러는 디스커션에서 종종 "rc"로 축약되며
kubectl 명령에서 숏컷으로 사용된다.
간단한 경우는 하나의 레플리케이션 컨트롤러 오브젝트를 생성하여
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
index 6d8869a646dcc..f5b802107e70e 100644
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -260,6 +260,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
+* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
{{% /capture %}}
diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md
index 6520104964315..19dabdd03c91e 100644
--- a/content/ko/docs/concepts/workloads/pods/init-containers.md
+++ b/content/ko/docs/concepts/workloads/pods/init-containers.md
@@ -60,7 +60,6 @@ weight: 40
* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함할 수 있다.
예를 들어, 셋업 중에 단지 `sed`, `awk`, `python`, 또는 `dig`와 같은 도구를 사용하기 위해서
다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다.
-* 앱 컨테이너 이미지의 보안성을 떨어뜨릴 수도 있는 유틸리티를 안전하게 실행할 수 있다.
* 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서
공동의 단일 앱 이미지 형태로 빌드될 필요가 없다.
* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다.
@@ -69,6 +68,9 @@ weight: 40
* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱
컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이
충족될 때까지 앱 컨테이너가 시동되는 것을 막거나 지연시키는 간편한 방법을 제공한다.
+* 초기화 컨테이너는 앱 컨테이너 이미지의 보안성을 떨어뜨릴 수도 있는 유틸리티 혹은 커스텀 코드를 안전하게
+ 실행할 수 있다. 불필요한 툴들을 분리한 채로 유지함으로써 앱 컨테이너 이미지의 공격에 대한
+ 노출을 제한할 수 있다.
### 예제
@@ -124,31 +126,6 @@ spec:
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
```
-
-아래의 yaml file은 `mydb`와 `myservice` 서비스의 개요를 보여준다.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- name: myservice
-spec:
- ports:
- - protocol: TCP
- port: 80
- targetPort: 9376
----
-apiVersion: v1
-kind: Service
-metadata:
- name: mydb
-spec:
- ports:
- - protocol: TCP
- port: 80
- targetPort: 9377
-```
-
다음 커맨드들을 이용하여 파드를 시작하거나 디버깅할 수 있다.
```shell
diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
index 25ce824947fd3..de781afe3489e 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -277,10 +277,11 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는
## 파드의 일생(lifetime)
-일반적으로, 파드는 누군가 파드를 파괴할 때까지 사라지지 않는다.
-그것은 주로 사람이나 컨트롤러에 의해서 일어난다.
-이 법칙에 대한 유일한 예외는 일정 기간(마스터의 `terminated-pod-gc-threshold`에 의해 결정되는)
-이상 파드의 `phase`가 Succeeded 또는 Failed라서 파드가 만료되고 자동적으로 파괴되는 경우이다.
+일반적으로, 파드는 사람 혹은 컨트롤러의 프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다.
+컨트롤 플레인은 파드의 수가 설정된 임계치(kube-controller-manager에서
+`terminated-pod-gc-threshold`에 의해 결정)를 초과할 때,
+종료된 파드들(`Succeeded` 또는 `Failed` 단계)을 정리한다.
+이로써 시간이 지남에 따라 파드들이 생성 및 종료되며 발생하는 리소스 누수를 피할 수 있다.
세 가지 유형의 컨트롤러를 사용할 수 있다.
diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md
index 775fcccd219c7..0b5c5ed837968 100644
--- a/content/ko/docs/contribute/localization_ko.md
+++ b/content/ko/docs/contribute/localization_ko.md
@@ -271,10 +271,11 @@ Session Affinity | 세션 어피니티(Affinity) |
Setting | 세팅 |
Shell | 셸 |
Sign In | 로그인 |
-Sign Out | 로그아웃 |
+Sign Out | 로그아웃 |
+skew | 차이(skew) |
Stateful Set | 스테이트풀 셋 |
stateless | 스테이트리스 |
-Static pod | 스태틱 파드(static pod) |
+Static pod | 스태틱(static) 파드 |
Storage Class | 스토리지 클래스 |
Sub-Object | 서브-오브젝트 |
support | 지원 |
@@ -284,7 +285,8 @@ taint | 테인트(taint) |
Task | 태스크 |
Terminated | Terminated | 파드의 상태에 한함
tolerations | 톨러레이션(toleration) |
-Tools | 도구
+Topology spread constraints | 토폴로지 분배 제약 조건 |
+Tools | 도구 |
traffic | 트래픽 |
Type | 타입 |
ubuntu | 우분투 |
diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md
index 0df4d59fe1a7b..631dc10d13247 100644
--- a/content/ko/docs/reference/_index.md
+++ b/content/ko/docs/reference/_index.md
@@ -49,8 +49,6 @@ content_template: templates/concept
* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
* [kube-proxy](/docs/admin/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
* [kube-scheduler](/docs/admin/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
-* [federation-apiserver](/docs/admin/federation-apiserver/) - 연합된 클러스터를 위한 API 서버.
-* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 쿠버네티스 연합에 탑재된 핵심 제어 루프를 포함하는 데몬.
## 설계 문서
diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md
index fd63ab67b4bc5..1c83aaf7bc87c 100644
--- a/content/ko/docs/setup/production-environment/container-runtimes.md
+++ b/content/ko/docs/setup/production-environment/container-runtimes.md
@@ -286,8 +286,7 @@ systemctl restart containerd
`systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`의 `plugins.cri.systemd_cgroup = true`을 설정한다.
kubeadm을 사용하는 경우에도 마찬가지로, 수동으로
-[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)을
-설정해준다.
+[kubelet을 위한 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 설정한다.
## 다른 CRI 런타임: frakti
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 24a54c1143c22..e23cfd4cb52e9 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -129,8 +129,8 @@ CPU 소비가 305%까지 증가하였다.
kubectl get deployment php-apache
```
```
-NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
-php-apache 7 7 7 7 19m
+NAME READY UP-TO-DATE AVAILABLE AGE
+php-apache 7/7 7 7 19m
```
{{< note >}}
@@ -160,8 +160,8 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1
kubectl get deployment php-apache
```
```
-NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
-php-apache 1 1 1 1 27m
+NAME READY UP-TO-DATE AVAILABLE AGE
+php-apache 1/1 1 1 27m
```
CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮췄다.
@@ -302,7 +302,7 @@ spec:
resource:
name: cpu
target:
- type: AverageUtilization
+ type: Utilization
averageUtilization: 50
- type: Pods
pods:
@@ -320,7 +320,7 @@ spec:
kind: Ingress
name: main-route
target:
- kind: Value
+ type: Value
value: 10k
status:
observedGeneration: 1
diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md
index 267d776738caa..5b87bb9640f97 100644
--- a/content/ko/docs/tasks/tools/install-minikube.md
+++ b/content/ko/docs/tasks/tools/install-minikube.md
@@ -122,7 +122,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설
가장 쉽게 맥OS에 Minikube를 설치하는 방법은 [Homebrew](https://brew.sh)를 이용하는 것이다.
```shell
-brew cask install minikube
+brew install minikube
```
실행 바이너리를 다운로드 받아서 맥OS에 설치할 수도 있다.
diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md
index b15a5b02df412..b359bc309d2a6 100644
--- a/content/ko/docs/tutorials/hello-minikube.md
+++ b/content/ko/docs/tutorials/hello-minikube.md
@@ -15,7 +15,7 @@ card:
{{% capture overview %}}
-이 튜토리얼에서는 [Minikube](/docs/getting-started-guides/minikube)와 Katacoda를 이용하여
+이 튜토리얼에서는 [Minikube](/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여
쿠버네티스에서 Node.js 로 작성된 간단한 Hello World 애플리케이션을 어떻게 실행하는지 살펴본다.
Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
@@ -90,8 +90,8 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
출력:
```shell
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- hello-node 1 1 1 1 1m
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ hello-node 1/1 1 1 1m
```
3. 파드 보기
diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html
index 0d6e51bb8d429..d9baf3a832d63 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html
@@ -14,7 +14,7 @@
-
+