Fifth Korean l10n work for release-1.16 (kubernetes#17745)

* Update files outdated Korean docs in dev-1.16-ko.5 (kubernetes#17537) * Update Korean glossary (kubernetes#17619) * Translate services-networking/endpoint-slices.md in Korean (kubernetes#17631) Co-Authored-By: Yuk, Yongsu <[email protected]> Co-Authored-By: June Yi <[email protected]> Co-Authored-By: Wook-Jin, Lee <[email protected]> Co-Authored-By: Seokho Son <[email protected]>
leakingtapan · Nov 26, 2019 · 6fb56c5 · 6fb56c5
1 parent 4d589e2
commit 6fb56c5
Show file tree

Hide file tree

Showing 20 changed files with 136 additions and 69 deletions.
diff --git 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -122,7 +122,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설
 가장 쉽게 맥OS에 Minikube를 설치하는 방법은 [Homebrew](https://brew.sh)를 이용하는 것이다.
 
 ```shell
-brew cask install minikube
+brew install minikube
 ```
 
 실행 바이너리를 다운로드 받아서 맥OS에 설치할 수도 있다.