Rev-1 to be squashed

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

@@ -97,7 +97,7 @@ kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API
 
 [Node authorization mode](/docs/reference/access-authn-authz/node/)와
 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
-kubelets은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
+각 kubelet은 자신이 속한 노드의 리소스에 대해서만 생성/수정할 권한을 가진다.
 
 {{< note >}}
 [노드 이름 고유성](#노드-이름-고유성) 섹션에서 언급했듯이,
@@ -109,7 +109,7 @@ kubelets은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
 노드에 이미 스케줄된 파드는 해당 노드 구성이 kubelet 재시작에 의해 변경된 경우
 오작동하거나 문제를 일으킬 수 있다. 예를 들어 이미 실행 중인 파드가 노드에
 할당된 새 레이블에 대해 테인트(taint)될 수 있는 반면 해당 파드와 호환되지 않는 다른 파드는
-새 레이블을 기반으로 스케줄링된다. 노드 재-등록(re-registration)은 모든 파드를
+새 레이블을 기반으로 스케줄링된다. 노드 재등록(re-registration)은 모든 파드를
 비우고(drain) 다시 적절하게 스케줄링되도록
 한다.
 {{< /note >}}
@@ -225,14 +225,14 @@ API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은
 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
-쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가
-API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를
-낳는다.
+쿠버네티스에서 노드 오브젝트를 삭제하면
+노드 상에서 동작 중인 모든 파드 오브젝트가 API 서버로부터 삭제되며
+파드가 사용하던 이름을 다시 사용할 수 있게 된다.
 
 노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는
 [테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를
 생성한다.
-스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
+스케줄러는 파드를 노드에 할당할 때 노드의 테인트를 고려한다.
 또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 
 {{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다.
 
@@ -255,10 +255,10 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를
 ### 정보
 
 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너
-런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은
+런타임 상세 정보 및 노드가 사용하는 운영 체제가 무엇인지와 같은
 노드에 대한 일반적인 정보가 기술된다.
-이 정보는 Kubelet이 노드로부터 수집해서
-쿠버네티스 API로 이를 보낸다.
+이 정보는 Kubelet이 노드에서 수집하여
+쿠버네티스 API로 전송한다.
 
 ## 하트비트
 
@@ -273,9 +273,9 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를
   내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
   오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다.
 
-노드의 `.status`와 비교해서, 리스는 경량의 리소스이다.
-큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해
-필요한 성능 영향도를 줄일 수 있다.
+노드의 `.status`에 비하면, 리스는 경량의 리소스이다.
+큰 규모의 클러스터에서는 리스를 하트비트에 사용하여 
+업데이트로 인한 성능 영향을 줄일 수 있다.
 
 kubelet은 노드의 `.status` 생성과 업데이트 및
 관련된 리스의 업데이트를 담당한다. 
@@ -304,12 +304,12 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
 해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우,
 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
 
-세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
+세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는
 다음을 담당한다.
-- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status`
+- 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 `.status`
   내에 있는 NodeReady 컨디션을 업데이트한다.
   이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
-- 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서
+- 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서
   [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을
   트리거한다. 기본적으로, 노드 컨트롤러는 노드를
   `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가