From d75f6f2a46a31121add5355eeee1137d8398b39d Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Mon, 22 Nov 2021 21:02:47 +0900 Subject: [PATCH] Rev-1 to be squashed --- .../ko/docs/concepts/architecture/nodes.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 09e2264a80..8c7390eef7 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/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분을 기다렸다가