Update to Outdated files in the dev-1.20-ko.7 branch part. 1.

Author: ysyukr

content/ko/docs/concepts/architecture/control-plane-node-communication.md

@@ -21,7 +21,7 @@ aliases:
 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
 
 API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다.
-`kubernetes` 서비스(모든 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
+`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
 
 컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.
 

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

@@ -27,7 +27,7 @@ weight: 10
 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 노드를 추가하는 두가지 주요 방법이 있다.
 
 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
-2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가
+2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가
 
 노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
@@ -48,8 +48,8 @@ weight: 10
 
 쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
 kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
-노드가 정상이면(필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
-그렇지 않으면, 해당 노드는 정상이 될때까지 모든 클러스터 활동에
+노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
+그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
 대해 무시된다.
 
 {{< note >}}
@@ -226,13 +226,14 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
 
 세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
-노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트
-수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.)
-NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고,
-노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다.
-(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
-파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
-매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
+다음을 담당한다.
+- 노드 다운과 같은 어떤 이유로 노드 컨트롤러가
+ 하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady
+ 컨디션을 ConditionUnknown으로 업데이트 한다.
+- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
+ ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
+ 파드를 축출하기 시작하는 값은 5분이다.
+노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
 
 #### 하트비트
 
@@ -250,11 +251,12 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 
 - kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
  `NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트
- 주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초
- 보다 훨씬 길다).
+ 주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초
+ 보다 훨씬 길다.
 - kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
  리스 업데이트는 `NodeStatus` 업데이트와는
- 독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
+ 독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며
+ 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
 
 #### 안정성
 
@@ -264,13 +266,13 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 
 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
-체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.).
-상태가 불량한 노드의 일부가 최소
-`--unhealthy-zone-threshold` 기본값 0.55) 가
-되면 축출 비율은 감소한다. 클러스터가 작으면 (즉
-`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고,
-그렇지 않으면 축출 비율은 초당
-`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
+체크한다(NodeReady 컨디션은 ConditionUnknown 또는
+ConditionFalse 다.).
+- 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold`
+ (기본값 0.55)가 되면 축출 비율은 감소한다.
+- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
+ 노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
+ `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
@@ -299,8 +301,8 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 
 ### 노드 용량
 
-노드 오브젝트는 노드 리소스 용량에 대한 정보(예: 사용 가능한 메모리의
-양과 CPU의 수)를 추적한다.
+노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의
+양과 CPU의 수를 추적한다.
 노드의 [자체 등록](#노드에-대한-자체-등록)은 등록하는 중에 용량을 보고한다.
 [수동](#수동-노드-관리)으로 노드를 추가하는 경우 추가할 때
 노드의 용량 정보를 설정해야 한다.

content/ko/docs/concepts/cluster-administration/manage-deployment.md

@@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
 
 동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다.
 
-URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
+URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
 
 ```shell
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml

content/ko/docs/concepts/configuration/configmap.md

@@ -42,8 +42,8 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob
 `spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData`
 필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와
 `binaryData` 는 모두 선택 사항이다. `data` 필드는
-UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 데이터를
-포함하도록 설계되었다.
+UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리
+데이터를 base64로 인코딩된 문자열로 포함하도록 설계되었다.
 
 컨피그맵의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

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

@@ -81,9 +81,9 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
 
 - `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다.
 
-- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다.
+- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `imagePullPolicy`는 자동으로 `Always`가 적용된다. 태그 값을 변경하더라도 이 값은 `IfNotPresent`로 업데이트 되지 _않는다_.
 
-- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `IfNotPresent`가 적용된다.
+- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `imagePullPolicy`는 자동으로 `IfNotPresent`가 적용된다. 태그가 나중에 제거되거나 `:latest`로 변경되더라도 `Always`로 업데이트 되지 _않는다_.
 
 - `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
 
@@ -96,7 +96,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
 {{< /note >}}
 
 {{< note >}}
-기반이 되는 이미지 제공자의 캐시 방법은 `imagePullPolicy: Always`를 효율적으로 만든다. 예를 들어, 도커에서는 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
+레지스트리가 안정적으로 동작하는 상황에서는, `imagePullPolicy: Always`로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
 {{< /note >}}
 
 ## kubectl 사용하기

content/ko/docs/concepts/containers/images.md

@@ -49,16 +49,32 @@ weight: 10
 
 ## 이미지 업데이트
 
-기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은
-{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미
-존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면,
-다음 중 하나를 수행하면 된다.
+{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}},
+{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}, 파드 또는 파드
+템플릿은 포함하는 다른 오브젝트를 처음 만들 때 특별히 명시하지 않은 경우
+기본적으로 해당 파드에 있는 모든 컨테이너의 풀(pull)
+정책은 `IfNotPresent`로 설정된다. 이 정책은
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는
+이미지에 대한 풀을 생략하게 한다.
+
+만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다.
 
 - 컨테이너의 `imagePullPolicy`를 `Always`로 설정.
-- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용.
+- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용,
+ 쿠버네티스는 정책을 `Always`로 설정한다.
 - `imagePullPolicy`와 사용할 이미지의 태그를 생략.
 - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.
 
+{{< note >}}
+컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상
+설정되고 나중에 이미지 태그가 변경되더라도 업데이트되지 않는다.
+
+예를 들어, 태그가 `:latest`가 아닌 이미지로 디플로이먼트를 생성하고,
+나중에 해당 디플로이먼트의 이미지를 `:latest` 태그로 업데이트하면
+`imagePullPolicy` 필드가 `Always` 로 변경되지 않는다. 오브젝트를
+처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다.
+{{< /note >}}
+
 `imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다.
 
 ## 이미지 인덱스가 있는 다중 아키텍처 이미지

content/ko/docs/concepts/extend-kubernetes/operator.md

@@ -102,27 +102,28 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
 
 ## 자신만의 오퍼레이터 작성 {#writing-operator}
 
-에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면 직접 코딩할 수 있다.
-[다음 내용](#다음-내용)에서는 클라우드 네이티브 오퍼레이터를 작성하는 데
-사용할 수 있는 라이브러리 및 도구에 대한 몇 가지 링크를
-찾을 수 있다.
+에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면
+직접 코딩할 수 있다.
 
 또한 [쿠버네티스 API의 클라이언트](/ko/docs/reference/using-api/client-libraries/)
 역할을 할 수 있는 모든 언어 / 런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현한다.
 
+다음은 클라우드 네이티브 오퍼레이터를 작성하는 데 사용할 수 있는
+몇 가지 라이브러리와 도구들이다.
 
+{{% thirdparty-content %}}
+
+* [kubebuilder](https://book.kubebuilder.io/) 사용하기
+* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
+* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
+ 사용하여 직접 구현하기
+* [오퍼레이터 프레임워크](https://operatorframework.io)
 
 ## {{% heading "whatsnext" %}}
 
 
 * [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
 * [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기
-* 기존 도구를 사용하여 자신만의 오퍼레이터를 작성해보자. 다음은 예시이다.
- * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) 사용하기
- * [kubebuilder](https://book.kubebuilder.io/) 사용하기
- * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
- 사용하여 직접 구현하기
- * [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
 * 오퍼레이터 패턴을 소개한 [CoreOS 원본 글](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) 읽기 (이 링크는 원본 글에 대한 보관 버전임)
 * 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기

content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -5,7 +5,7 @@
 
 title: 노드에 파드 할당하기
 content_type: concept
-weight: 50
+weight: 20
 ---
 
 

content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md

@@ -5,7 +5,7 @@
 
 title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
 content_type: concept
-weight: 50
+weight: 30
 ---
 
 <!-- overview -->

content/ko/docs/concepts/storage/dynamic-provisioning.md

@@ -75,8 +75,8 @@ parameters:
 사용자는 `PersistentVolumeClaim` 에 스토리지 클래스를 포함시켜 동적으로 프로비전된
 스토리지를 요청한다. 쿠버네티스 v1.6 이전에는 `volume.beta.kubernetes.io/storage-class`
 어노테이션을 통해 수행되었다. 그러나 이 어노테이션은
-v1.6부터 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의
-`storageClassName` 필드를 사용할 수 있기에 대신하여 사용해야 한다. 이 필드의 값은
+v1.9부터는 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의
+`storageClassName` 필드를 사용해야 한다. 이 필드의 값은
 관리자가 구성한 `StorageClass` 의 이름과
 일치해야 한다. ([아래](#동적-프로비저닝-활성화하기)를 참고)