whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[ko] Update outdated files in dev-1.24-ko.1 M1-M16

Browse Source
This commit is contained in:
Jihoon Seo
2022-05-19 10:46:36 +09:00
parent e6d993feb3
commit 3928253710
14 changed files with 390 additions and 313 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/garbage-collection.md
+1 -1
View File
@@ -13,7 +13,7 @@ weight: 50
* [소유자 참조가 없는 오브젝트](#owners-dependents)
* [사용되지 않는 컨테이너와 컨테이너 이미지](#containers-images)
* [반환 정책이 삭제인 스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/#delete)
* [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) <!-- en 글에서부터 링크가 깨져있어 /docs를 따로 추가-->
* [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
* {{<glossary_tooltip text="노드" term_id="node">}} 는 다음과 같은 상황에서 삭제된다:
* 클러스터가 [클라우드 컨트롤러 매니저](/ko/docs/concepts/architecture/cloud-controller/)를 사용하는 클라우드
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스
content/ko/docs/concepts/architecture/nodes.md
+110 -30
View File
@@ -86,14 +86,18 @@ kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API
자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
- `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
- `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
- `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게
{{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
- `--register-node` - 자동으로 API 서버에 등록.
- `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록.
- `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}}
리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록.
`register-node`가 거짓이면 동작 안 함.
- `--node-ip` - 노드의 IP 주소.
- `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 {{< glossary_tooltip text="레이블" term_id="label" >}}([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고).
- `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의.
- `--node-labels` - 클러스터에 노드를 등록할 때 추가 할
{{< glossary_tooltip text="레이블" term_id="label" >}}
([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고).
- `--node-status-update-frequency` - 얼마나 자주 kubelet이 API 서버에 해당 노드 상태를 게시할 지 정의.
[Node authorization mode](/docs/reference/access-authn-authz/node/)와
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
@@ -168,8 +172,10 @@ kubectl describe node <insert-node-name-here>
이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다.
* HostName: 노드의 커널에 의해 알려진 호스트명이다. `--hostname-override` 파라미터를 통해 치환될 수 있다.
* ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능 (클러스터 외부에서 이용 가능) 하다 .
* HostName: 노드의 커널에 의해 알려진 호스트명이다.
`--hostname-override` 파라미터를 통해 치환될 수 있다.
* ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능
(클러스터 외부에서 이용 가능) 하다 .
* InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.
@@ -289,7 +295,6 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고
7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.
### 노드 컨트롤러
노드 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
@@ -306,18 +311,21 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는
다음을 담당한다.
- 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 `.status`
내에 있는 NodeReady 컨디션을 업데이트한다.
이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
- 노드가 접근 불가능(unreachable) 상태가 되는 경우,
노드의 `.status` 필드의 `Ready` 컨디션을 업데이트한다.
이 경우에는 노드 컨트롤러가 `Ready` 컨디션을 `Unknown`으로 설정한다.
- 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서
[API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을
트리거한다. 기본적으로, 노드 컨트롤러는 노드를
`ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가
`Unknown`으로 마킹한 뒤 5분을 기다렸다가
최초의 축출 요청을 시작한다.
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
기본적으로, 노드 컨트롤러는 5 초마다 각 노드의 상태를 체크한다.
체크 주기는 `kube-controller-manager` 구성 요소의
`--node-monitor-period` 플래그를 이용하여 설정할 수 있다.
#### 축출 빈도 한계
#### 축출 빈도 제한
대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여
@@ -325,8 +333,9 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
체크한다(NodeReady 컨디션은 `ConditionUnknown` 또는
`ConditionFalse` 다).
체크한다(`Ready` 컨디션은 `Unknown` 또는
`False` 값을 가진다).
- 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold`
(기본값 0.55)가 되면 축출 속도가 감소한다.
- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
@@ -335,7 +344,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
하나의 가용성 영역이 컨트롤 플레인으로부터 분할되어 질 수도 있기 때문이다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않는 이상,
축출 매커니즘은 영역 별 가용성을 고려하지 않는다.
@@ -377,7 +386,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
## 노드 토폴로지
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
{{< feature-state state="beta" for_k8s_version="v1.18" >}}
`TopologyManager`
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
@@ -391,7 +400,9 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
kubelet은 노드 시스템 셧다운을 감지하고 노드에서 실행 중인 파드를 종료하려고 시도한다.
Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다.
Kubelet은 노드가 종료되는 동안 파드가
일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를
따르도록 한다.
그레이스풀 노드 셧다운 기능은
[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를
@@ -404,18 +415,26 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
기본적으로, 아래 설명된 두 구성 옵션,
`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
그레이스풀 노드 셧다운 기능이 활성화되지 않는다.
기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다.
기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고
0이 아닌 값으로 설정해야 한다.
그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
2. 노드에서 실행 중인
[중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
그레이스풀 노드 셧다운 기능은
두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
* `shutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* 노드가 종료를 지연해야 하는 총 기간을 지정한다.
이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의
파드 종료에 필요한 총 유예 기간에 해당한다.
* `shutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다.
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를
종료하는 데 사용되는 기간을 지정한다.
이 값은 `shutdownGracePeriod` 보다 작아야 한다.
예를 들어, `shutdownGracePeriod=30s`,
`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
@@ -433,6 +452,56 @@ Reason: Terminated
Message: Pod was terminated in response to imminent node shutdown.
```
{{< /note >}}
## 논 그레이스풀 노드 셧다운 {#non-graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.24" >}}
전달한 명령이 kubelet에서 사용하는 금지 잠금 메커니즘(inhibitor locks mechanism)을 트리거하지 않거나,
또는 사용자 오류(예: ShutdownGracePeriod 및 ShutdownGracePeriodCriticalPods가 제대로 설정되지 않음)로 인해
kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
노드 셧다운 액션을 감지하지 못할 수 있다.
자세한 내용은 위의 [그레이스풀 노드 셧다운](#graceful-node-shutdown) 섹션을 참조한다.
노드가 셧다운되었지만 kubelet의 노드 셧다운 관리자가 이를 감지하지 못하면,
스테이트풀셋에 속한 파드는 셧다운된 노드에 '종료 중(terminating)' 상태로 고착되어
다른 동작 중인 노드로 이전될 수 없다.
이는 셧다운된 노드의 kubelet이 파드를 지울 수 없어서
결국 스테이트풀셋이 동일한 이름으로 새 파드를 만들 수 없기 때문이다.
만약 파드가 사용하던 볼륨이 있다면,
볼륨어태치먼트(VolumeAttachment)도 기존의 셧다운된 노드에서 삭제되지 않아
결국 파드가 사용하던 볼륨이 다른 동작 중인 노드에 연결(attach)될 수 없다.
결과적으로, 스테이트풀셋에서 실행되는 애플리케이션이 제대로 작동하지 않는다.
기존의 셧다운된 노드가 정상으로 돌아오지 못하면,
이러한 파드는 셧다운된 노드에 '종료 중(terminating)' 상태로 영원히 고착될 것이다.
위와 같은 상황을 완화하기 위해,
사용자가 `node.kubernetes.io/out-of-service` 테인트를
`NoExecute` 또는 `NoSchedule` 값으로 추가하여
노드를 서비스 불가(out-of-service) 상태로 표시할 수 있다.
`kube-controller-manager`에 `NodeOutOfServiceVolumeDetach`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고,
노드가 이 테인트에 의해 서비스 불가 상태로 표시되어 있는 경우,
노드에 매치되는 톨러레이션이 없다면 노드 상의 파드는 강제로 삭제될 것이고,
노드 상에서 종료되는 파드에 대한 볼륨 해제(detach) 작업은 즉시 수행될 것이다.
이를 통해 서비스 불가 상태 노드의 파드가 빠르게 다른 노드에서 복구될 수 있다.
논 그레이스풀 셧다운 과정 동안, 파드는 다음의 두 단계로 종료된다.
1. 매치되는 `out-of-service` 톨러레이션이 없는 파드를 강제로 삭제한다.
2. 이러한 파드에 대한 볼륨 해제 작업을 즉시 수행한다.
{{< note >}}
- `node.kubernetes.io/out-of-service` 테인트를 추가하기 전에,
노드가 완전한 셧다운 또는 전원 꺼짐 상태에 있는지
(재시작 중인 것은 아닌지) 확인한다.
- 사용자가 서비스 불가 상태 테인트를 직접 추가한 것이기 때문에,
파드가 다른 노드로 옮겨졌고 셧다운 상태였던 노드가 복구된 것을 확인했다면
사용자가 서비스 불가 상태 테인트를 수동으로 제거해야 한다.
{{< /note >}}
### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown}
@@ -443,7 +512,7 @@ Message: Pod was terminated in response to imminent node shutdown.
클러스터에 프라이어리티클래스(PriorityClass) 기능이 활성화되어 있으면
그레이스풀 노드 셧다운 과정에서 파드의 프라이어리티클래스가 고려된다.
이 기능으로 그레이스풀 노드 셧다운 시 파드가 종료되는 순서를 클러스터 관리자가
[프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)
[프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)
기반으로 명시적으로 정할 수 있다.
위에서 기술된 것처럼, [그레이스풀 노드 셧다운](#graceful-node-shutdown) 기능은 파드를
@@ -492,7 +561,7 @@ shutdownGracePeriodByPodPriority:
shutdownGracePeriodSeconds: 60
```
위의 표에 의하면 우선순위 값이 100000 이상인 파드는 종료까지 10초만 주어지며,
위의 표에 의하면 `priority` 값이 100000 이상인 파드는 종료까지 10초만 주어지며,
10000 이상 ~ 100000 미만이면 180초,
1000 이상 ~ 10000 미만이면 120초가 주어진다.
마지막으로, 다른 모든 파드는 종료까지 60초가 주어질 것이다.
@@ -507,7 +576,7 @@ shutdownGracePeriodByPodPriority:
| 0 |60 seconds |
위의 경우, custom-class-b에 속하는 파드와 custom-class-c에 속하는 파드는
위의 경우, `custom-class-b`에 속하는 파드와 `custom-class-c`에 속하는 파드는
동일한 종료 대기 시간을 갖게 될 것이다.
특정 범위에 해당되는 파드가 없으면,
@@ -517,10 +586,21 @@ kubelet은 해당 범위에 해당되는 파드를 위해 기다려 주지 않
기능이 활성화되어 있지만 환경 설정이 되어 있지 않으면,
순서 지정 동작이 수행되지 않을 것이다.
이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority` 기능 게이트를 활성화해야 하고,
kubelet 환경 설정의 `ShutdownGracePeriodByPodPriority`를
파드 프라이어리티 클래스 값과
각 값에 대한 종료 대기 시간을 명시하여 지정해야 한다.
이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 하고,
[kubelet config](/docs/reference/config-api/kubelet-config.v1beta1/)의
`ShutdownGracePeriodByPodPriority`를
파드 프라이어리티 클래스 값과 각 값에 대한 종료 대기 시간을 명시하여
지정해야 한다.
{{< note >}}
그레이스풀 노드 셧다운 과정에서 파드 프라이어리티를 고려하는 기능은
쿠버네티스 v1.23에서 알파 기능으로 도입되었다.
쿠버네티스 {{< skew currentVersion >}}에서 이 기능은 베타 상태이며 기본적으로 활성화되어 있다.
{{< /note >}}
`graceful_shutdown_start_time_seconds` 및 `graceful_shutdown_end_time_seconds` 메트릭은
노드 셧다운을 모니터링하기 위해 kubelet 서브시스템에서 방출된다.
## 스왑(swap) 메모리 관리 {#swap-memory}