Sixth Korean l10n work for release-1.16

* Update _index.md (#17762)
* Update apparmor.md (#17767)
* Update hello-minikube.md (#17771)
* Update guestbook.md (#17773)
* Update localization_ko.md (#17777)
* Fix grammatical errors (#17776)
* Translate /docs/reference/issues-security/security.md in Korea (#17763)
* Create issues.md (#17765)
* Update basic-stateful-set.md (#17774)
* Fixed typo ko/docs/concepts/overview/components.md (#17778)
* Modify typo. (#17802)
* Update cloud-controller.md (#17760)
* Update file outdated korean docs in dev-1.16-ko.6. (#17772)
* Translate concepts/services-networking/ingress-controller in Korean (#17858)
* Update ingress-controller.md
* Translate services-networking/ingress.md in Korean. (#17807)
* Fix grammatical errors (#17775)
* Translate docs/contribute/style/write-new-topic.md in Korean (#17758)

Co-Authored-By: const-k <[email protected]>
Co-Authored-By: Yuk, Yongsu <[email protected]>
Co-Authored-By: power8993 <[email protected]>
Co-Authored-By: reung37 <[email protected]>
Co-Authored-By: Chihoon-Sung <[email protected]>
Co-Authored-By: Claudia J.Kang <[email protected]>
Co-Authored-By: Seokho Son <[email protected]>

content/ko/docs/concepts/_index.md

@@ -17,7 +17,7 @@ weight: 40
 
 쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다.
 
-바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator (PLEG) 를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다.
+바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다.
 
 * **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다.
 * 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다.
@@ -59,10 +59,6 @@ weight: 40
 
 클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신(VM, 물리 서버 등)이다. 쿠버네티스 마스터는 각 노드를 관리한다. 직접 노드와 직접 상호 작용할 일은 거의 없을 것이다.
 
-#### 오브젝트 메타데이터
-
-
-* [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)
 
 {{% /capture %}}
 

content/ko/docs/concepts/architecture/cloud-controller.md

@@ -83,7 +83,7 @@ CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급
 
 #### 서비스 컨트롤러
 
-서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucutre LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다.
+서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucuture LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다.
 
 ### 2. Kubelet
 
@@ -231,6 +231,7 @@ rules:
 * [Linode](https://github.com/linode/linode-cloud-controller-manager)
 * [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
 * [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
+* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)
 
 ## 클러스터 관리
 

content/ko/docs/concepts/architecture/nodes.md

@@ -48,7 +48,6 @@ kubectl describe node <insert-node-name-here>
 
 | Node Condition | Description |
 |----------------|-------------|
-| `OutOfDisk`    | 노드 상에 새로운 파드를 추가하기 위한 여유 공간이 부족할 경우 `True`, 반대의 경우 `False` |
 | `Ready`        | 노드가 상태 양호하며 파드를 수용할 준비가 되어 있는 경우 `True`, 노드의 상태가 불량하여 파드를 수용하지 못할 경우 `False`, 그리고 노드 컨트롤러가 마지막 `node-monitor-grace-period` (기본값 40 기간 동안 노드로부터 응답을 받지 못한 경우) `Unknown` |
 | `MemoryPressure`    | 노드 메모리 상에 압박이 있는 경우, 즉 노드 메모리가 넉넉치 않은 경우 `True`, 반대의 경우 `False` |
 | `PIDPressure`    | 프로세스 상에 압박이 있는 경우, 즉 노드 상에 많은 프로세스들이 존재하는 경우 `True`, 반대의 경우 `False` |

content/ko/docs/concepts/overview/components.md

@@ -13,15 +13,20 @@ card:
 
 이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한
 다양한 컴포넌트들에 대해 요약하고 정리한다.
+
+여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다.
+
+![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.png)
+
 {{% /capture %}}
 
 {{% capture body %}}
 ## 마스터 컴포넌트
 
 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
-(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동 시키는 것)를 감지하고 반응한다.
+(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다.
 
-마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
+마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나
 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
 사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
 [고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
@@ -63,11 +68,11 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
   * 노드 컨트롤러: 노드가 응답을 멈추고 나서 클라우드 상에서 삭제되어 졌는지 확정하기 위해 클라우드 제공사업자에게 확인하는 것
   * 라우트 컨트롤러: 바탕을 이루는 클라우드 인프라에 경로를 구성하는 것
   * 서비스 컨트롤러: 클라우드 제공사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것
-  * 볼륨 컨트롤러: 볼륨의 생성, 부착 그리고 마운트 하는 것과 볼륨을 조정하기 위해 클라우드 제공사업자와 상호작용 하는 것
+  * 볼륨 컨트롤러: 볼륨의 생성, 부착 그리고 마운트 하는 것과 볼륨을 조정하기 위해 클라우드 제공사업자와 상호작용하는 것
 
 ## 노드 컴포넌트
 
-노드 컴포넌트는 동작중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다.
+노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다.
 
 ### kubelet
 
@@ -88,30 +93,30 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
 이용하여 클러스터 기능을 구현한다. 이들은 클러스터 단위의 기능을 제공하기 때문에
 애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다.
 
-선택된 일부 애드온은 아래에 설명하였고, 사용가능한 전체 확장 애드온 리스트는
+선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는
 [애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
 
 ### DNS
 
-여타 애드온들이 절대적으로 요구되지 않는 반면에, 많은 예시들에서 그것을 필요로 하기때문에 모든 쿠버네티스 클러스터는 [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다.
+여타 애드온들이 절대적으로 요구되지 않지만, 많은 예시에서 그것을 필요로 하기 때문에 모든 쿠버네티스 클러스터는 [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다.
 
 클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다.
 
-쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함시킨다.
+쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다.
 
 ### 웹 UI (대시보드)
 
-[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자로 하여금 클러스터 자체 뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 고장처리를 할 수 있도록 허용해준다.
+[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 고장처리를 할 수 있도록 허용해준다.
 
 ### 컨테이너 리소스 모니터링
 
 [컨테이너 리소스 모니터링](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
-중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
+중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
 
 ### 클러스터-레벨 로깅
 
 [클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
-검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
+검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.
 
 {{% /capture %}}
 {{% capture whatsnext %}}

content/ko/docs/concepts/overview/what-is-kubernetes.md

@@ -74,7 +74,7 @@ card:
 
 * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
 * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
-* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
+* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
 * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
 * 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
 * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.

content/ko/docs/concepts/overview/working-with-objects/labels.md

@@ -89,6 +89,11 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
 레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충되는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
 {{< /note >}}
 
+{{< caution >}}
+일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다.
+필터 구문이 적절히 구성되어있는지 확인해야 한다.
+{{< /caution >}}
+
 ### _일치성 기준_ 요건
 
 _일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만 레이블의 명시된 제약 조건을 모두 만족해야 한다.

content/ko/docs/concepts/services-networking/endpoint-slices.md

@@ -58,12 +58,12 @@ endpoints:
 ```
 
 기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트 슬라이스에는
-각각 100개 이하의 엔드포인트가 가지고 있다. 이 스케일 아래에서 엔드포인트 슬라이스는
-엔드포인트 및 서비스와 1:1 매핑해야하며, 유사한 성능을 가져야 한다. 
+각각 100개 이하의 엔드포인트를 가지고 있다. 이 스케일 아래에서 엔드포인트 슬라이스는
+엔드포인트 및 서비스와 1:1로 매핑해야하며, 유사한 성능을 가져야 한다.
 
 엔드포인트 슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에
-신뢰할 수 있는 소스로 작용할 수 있다. 활성화 하면, 많은 수의 엔드포인트를 가지는
-서비스에 대해 성능 향상을 제공한다. 
+신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
+서비스에 대해 성능 향상을 제공해야 한다.
 
 ## 사용동기