Eleventh Korean l10n work for release 1.18

- Update outdated files in the dev-1.18-ko.11 branch (#23643)
- Fix inconsistent translation in Ko (#23683)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Daehyun Paik <paik@a30a.dev>

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

@@ -6,14 +6,14 @@ weight: 30
 
 <!-- overview -->
 
-로보틱스와 자동화에서 _컨트롤 루프_ 는 
+로보틱스와 자동화에서 _컨트롤 루프_ 는
 시스템 상태를 조절하는 종료되지 않는 루프이다.
 
 컨트롤 루프의 예시: 실내 온도 조절기
 
 사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를
 온도 조절기에 알려준다.
-*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서 
+*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
 현재 상태를 의도한 상태에 가깝게 만든다.
 
 {{< glossary_definition term_id="controller" length="short">}}
@@ -28,64 +28,64 @@ weight: 30
 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다.
 이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
 는 의도한 상태를 표현하는 사양 필드를 가지고 있다.
-해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 
+해당 리소스의 컨트롤러(들)은 현재 상태를 의도한
 상태에 가깝게 만드는 역할을 한다.
 
-컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로, 
-쿠버네티스에서는 컨트롤러가 
+컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로,
+쿠버네티스에서는 컨트롤러가
 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 로
 유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다.
 
 {{< comment >}}
-네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는 
-오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는 
+네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는
+오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는
 자세한 설명을 생략한다.
 {{< /comment >}}
 
 ### API 서버를 통한 제어
 
-{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스 
-내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 
+{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스
+내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와
 상호 작용하며 상태를 관리한다.
 
-잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 
-작업을 수행한 다음 중지하는 
+잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고,
+작업을 수행한 다음 중지하는
 쿠버네티스 리소스 이다.
 
-(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet 
+(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet
 의 의도한 상태 중 일부가 된다.)
 
-잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 
+잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
 노드 집합의 kubelet이 작업을 수행하기에 적합한
 수의 파드를 실행하게 한다.
 잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다.
-대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록 
+대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록
 지시한다.
-{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의
 다른 컴포넌트는 신규 정보
-(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여, 
+(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여,
 결국 해당 작업을 완료시킨다.
 
 새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다.
-잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게 
-만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서 
+잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게
+만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서
 잡이 완료에 가까워 지도록 한다.
 
 또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다.
 예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는
 잡 오브젝트가 `Finished`  로 표시되도록 업데이트한다.
 
-(이것은 지금 방 온도가 설정한 온도인 것을 표시하기 
+(이것은 지금 방 온도가 설정한 온도인 것을 표시하기
 위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다).
 
 ### 직접 제어
 
-잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을 
+잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을
 변경해야 할 필요가 있다.
 
-예를 들어, 만약 컨트롤 루프를 사용해서 
+예를 들어, 만약 컨트롤 루프를 사용해서
 클러스터에 충분한 {{< glossary_tooltip text="노드들" term_id="node" >}}이
-있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록 
+있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록
 현재 클러스터 외부의 무언가를 필요로 한다.
 
 외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한
@@ -101,7 +101,7 @@ weight: 30
 쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인
 변화에 대응할 수 있다.
 
-작업이 발생함에 따라 어떤 시점에서든 클러스터가 
+작업이 발생함에 따라 어떤 시점에서든 클러스터가
 변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로,
 클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다.
 
@@ -110,26 +110,26 @@ weight: 30
 
 ## 디자인
 
-디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 
+디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을
 관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프
-(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 
+(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로
 만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는
-잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 
+잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를
 확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
 잡은 다른 컨트롤러가 생성한다.
 
-컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, 
-간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 
+컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다,
+간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를
 허용하도록 디자인되었다.
 
 {{< note >}}
 동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다.
-이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에 
+이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에
 연결된 리소스에만 주의를 기울인다.
 
 예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다.
-잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다. 
-이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는 
+잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다.
+이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는
 정보({{< glossary_tooltip term_id="label" text="레이블" >}})가 있기 때문이다.
 {{< /note >}}
 
@@ -139,14 +139,14 @@ weight: 30
 내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이
 내장 컨트롤러는 중요한 핵심 동작을 제공한다.
 
-디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의 
+디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의
 자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다.
-쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로, 
+쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로,
 어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다.
 
 컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다.
 또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다.
-소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나, 
+소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나,
 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
 따라 달라진다.
 
@@ -154,8 +154,7 @@ weight: 30
 
 ## {{% heading "whatsnext" %}}
 
-* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기
-* [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자.
+* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기
+* [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자.
 * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
 * 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다.
-