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

Fourth Korean l10n work for release 1.18

Browse Source 
- Translate docs/reference/issues-security/_index.md into Korean (#21145)
- Translate tasks/administer-cluster/kubeadm/adding-windows-nodes.md into Korean (#21003)
- Translate manage-resources/memory-default-namespace.md into Korean (#21089)
- Translate tasks/configure-pod-container/pull-image-private-registry in Korean (#21036)
- Translate contribute/advanced.md into Korean (#21002)
- Update to Outdated files in the dev-1.18-ko.4 branch. (#21102)
- Translate manage-resources/cpu-constraint-namespace.md into Korean (#21048)
- Translate manage-resources/memory-constraint-namespace.md into Korean (#21091)
- Translate setup/release/notes.md in Korean (#21158)
- Translate manage-resources/quota-pod-namespace.md into Korean (#21087)
- Translate tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md into Korean (#20999)
- Translate tasks/administer-cluster/kubeadm/kubeadm-certs.md into Korean (#21000)
- Translate manage-resources/quota-memory-cpu-namespace.md into Korean (#21088)
- Translate manage-resources/cpu-default-namespace.md into Korean (#21090)
- Translate contribute/suggesting-improvements.md into Korean (#21001)
- Translate quality-service-pod in Korean (#21081)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: DongMoon Kim <dmoons.kim@gmail.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
This commit is contained in:
Jerry Park
2020-05-23 21:31:56 +09:00
committed by June Yi
parent 3dee902b75
commit b6760f3ae2
135 changed files with 5336 additions and 1110 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/master-node-communication.md
-120
View File
@@ -1,120 +0,0 @@
---
title: 마스터-노드 커뮤니케이션
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의
커뮤니케이션 경로를 나열해 본다. 그 목적은 신뢰할 수 없는 네트워크
(또는 클라우드 제공자의 공인 IP만으로 구성된 네트워크)에서도 동작될 수 있는
클러스터 구축을 위해, 네트워크의 구성을 강화하는 사용자
맞춤형 설치를 허용하기 위함이다.
{{% /capture %}}
{{% capture body %}}
## 클러스터에서 마스터로
클러스터에서 마스터로의 모든 커뮤니케이션 경로는 apiserver에서 끝난다
(어떤 다른 마스터 컴포넌트도 원격 서비스를 노출하기 위해 설계되지 않는다).
전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트
[인증](/docs/reference/access-authn-authz/authentication/) 형태가
사용가능토록 하여 안전한 HTTPS 포트(443)를 통해 원격 연결에 대해 서비스 리슨하도록 구성된다.
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
또는 [서비스 계정 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이
허용된 경우에는 하나 또는 그 이상의
[인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.
노드는 유효한 클라이언트 자격증명과 함께 apiserver에 안전하게 접속할 수 있는
그런 클러스터용 공인 루트 인증서를 가지고 제공되어야 한다.
예를 들어, 기본 GKE 배포의 경우, kubelet에 제공되는 클라이언트 자격증명은
클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에
대한 자동화 프로비저닝에 대해서는
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
apiserver에 접속하려는 파드는 서비스 계정에 영향력을 발휘함으로써 안전하게
그리 행할 수 있으며 따라서 쿠버네티스는 인스턴스화 될 때 공인 루트 인증서와
유효한 베어러 토큰을 파드 속으로 자동 주입할 수 있게 된다.
(모든 네임스페이스 내) `kubernetes` 서비스는 apiserver 상의 HTTPS 엔드포인트로
(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를
가지고 구성된다.
마스터 컴포넌트는 또한 신뢰할 수 있는 포트를 통해 클러스터 apiserver와 소통한다.
결과적으로, 클러스터 (노드 그리고 노드에서 동작하는 파드)에서
마스터로의 기본 동작 모드는 기본적으로 안전하며
신뢰할 수 없는그리고/또는 공인 네트워크 상에서 동작할 수 있다.
## 마스터에서 클러스터로
마스터(apiserver)에서 클러스터로의 두 가지 주된 커뮤니케이션 경로가 존재한다.
첫 번째는 클러스터 내 각 노드를 동작시키는 apiserver에서 kubelet 프로세스로의
경로이다. 두 번째는 apiserver에서 apiserver의 프록시 기능을 통한 임의의 노드,
파드 또는 서비스로의 경로이다.
### apiserver에서 kubelet으로
apiserver에서 kubelet으로의 연결은 다음을 위해 이용된다.
* 파드에 대한 로그 가져오기
* 동작중인 파드에 (kubectl을 통해) 연관짓기
* kubelet의 포트 포워딩 기능 제공하기
이 연결은 kubelet의 HTTPS 엔드포인트에서 끝난다. 기본적으로,
apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
이는 연결에 대한 중간자 공격을 당하게 하고, 신뢰할 수 없는
그리고/또는 공인 네트워크에서 운영하기에는 **불안** 하게 만든다.
이 연결을 확인하려면, apiserver에 kubelet의 제공 인증서 확인을
위해 사용하는 루트 인증서 번들로 `--kubelet-certificate-authority`
플래그를 이용한다
그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
apiserver와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/master-node-communication/#ssh-터널)을
사용한다.
마지막으로, kubelet API를 안전하게 하기 위해
[Kubelet 인증 그리고/또는 인가](/docs/admin/kubelet-authentication-authorization/)가 활성화 되어야만 한다.
### apiserver에서 노드, 파드, 그리고 서비스로
apiserver에서 노드, 파드, 또는 서비스로의 연결은 보통 HTTP 연결을
기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드, 파드, 또는 서비스 이름에
`https:` 프리픽스를 붙임으로써 안전한 HTTPS 연결로 동작될 수 있지만,
HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며
클라이언트 자격증명 또한 제공하지 않는다.
그래서 연결이 암호화될 동안, 어떠한 무결성도 제공되지 않을 것이다.
이러한 연결들은 신뢰할 수 없는 그리고/또는 공인 네트워크에서 동작하기에
**현재로서는 안전하지 않다**.
### SSH 터널
쿠버네티스는 마스터 → 클러스터 통신 경로를 보호하는 SSH 터널을
지원한다. 이 구성에서 apiserver는 클러스터의 각 노드에서 SSH 터널을
시작하고(포트 22번으로 수신 대기하는 ssh 서버에 연결), 터널을 통해
kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 실행중인 노드의 트래픽이 외부로 노출되지
않도록 보장한다.
SSH 터널은 현재 사용 중단(deprecated)되었으므로, 무엇을 하고 있는지 알지 못하는
한 터널을 이용하지 말아야 한다. Konnectivity 서비스는 이 통신
채널을 대체한다.
### Konnectivity 서비스
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
SSH 터널을 대체하는 Konnectivity 서비스는 마스터 → 클러스터 통신을
위한 TCP 수준의 프록시를 제공한다. Konnectivity는 마스터
네트워크와 클러스터 네트워크에서 실행되는 Konnectivity 서버와
에이전트 두 부분으로 구성된다. Konnectivity 에이전트는
Konnectivity 서버에 대한 연결을 시작하고, 유지한다.
이 연결을 통해 모든 마스터 → 클러스터로의 트래픽이 통과하게 된다.
클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 구성](/docs/tasks/setup-konnectivity/)
하기를 참고한다.
{{% /capture %}}
content/ko/docs/concepts/architecture/nodes.md
+155 -136
View File
@@ -6,18 +6,112 @@ weight: 10
{{% capture overview %}}
하나의 노드는 쿠버네티스에서 하나의 워커 머신으로, 이전에는 `미니언`으로 알려졌다. 노드는
클러스터에 따라, VM 또는 물리 머신이 될 수 있다. 각 노드는
[파드](/ko/docs/concepts/workloads/pods/pod/)를 동작시키기 위해 필요한 서비스를 포함하며 마스터 컴포넌트에 의해 관리된다. 노드 상의 서비스는 [컨테이너 런타임](/ko/docs/concepts/overview/components/#컨테이너-런타임), kubelet 그리고 kube-proxy를 포함한다. 보다
상세한 내용은 아키텍처 문서 내
[쿠버네티스 노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
섹션을 확인한다.
쿠버네티스는 컨테이너를 파드내에 배치하고 _노드_ 에서 실행함으로 워크로드를 구동한다.
노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드에는
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이라는
{{< glossary_tooltip text="파드" term_id="pod" >}}를
실행하는데 필요한 서비스가 포함되어 있다.
일반적으로 클러스터에는 여러개의 노드가 있으며, 학습 또는 리소스가 제한되는
환경에서는 하나만 있을 수도 있다.
노드의 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에는
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}},
{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}
그리고 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가 포함된다.
{{% /capture %}}
{{% capture body %}}
## 관리
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 노드를 추가하는 두가지 주요 방법이 있다.
1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가
노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다.
```json
{
"kind": "Node",
"apiVersion": "v1",
"metadata": {
"name": "10.240.79.157",
"labels": {
"name": "my-first-k8s-node"
}
}
}
```
쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
노드가 정상이면(필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
그렇지 않으면, 해당 노드는 정상이 될때까지 모든 클러스터 활동에
대해 무시된다.
{{< note >}}
쿠버네티스는 유효하지 않은 노드 오브젝트를 유지하고, 노드가
정상적인지 확인한다.
상태 확인을 중지하려면 사용자 또는 {{< glossary_tooltip term_id="controller" text="컨트롤러">}}에서
노드 오브젝트를 명시적으로 삭제해야한다.
{{< /note >}}
노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
### 노드에 대한 자체-등록
kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
- `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
- `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
- `--register-node` - 자동으로 API 서버에 등록.
- `--register-with-taints` - 주어진 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 authorization mode](/docs/reference/access-authn-authz/node/)와
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
#### 수동 노드 관리
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}을
사용해서 노드 오브젝트를 생성하고 수정할 수 있다.
노드 오브젝트를 수동으로 생성하려면 kubelet 플래그를 `--register-node=false` 로 설정한다.
`--register-node` 설정과 관계 없이 노드 오브젝트를 수정할 수 있다.
예를 들어 기존 노드에 레이블을 설정하거나, 스케줄 불가로 표시할 수 있다.
파드의 노드 셀렉터와 함께 노드의 레이블을 사용해서 스케줄링을 제어할 수 있다.
예를 들어, 사용 가능한 노드의 하위 집합에서만 실행되도록
파드를 제한할 수 있다.
노드를 스케줄 불가로 표시하면 스케줄러가 해당 노드에 새 파드를 배치할 수 없지만,
노드에 있는 기존 파드에는 영향을 미치지 않는다.
이는 노드 재부팅 또는 기타 유지보수 준비 단계에서 유용하다.
노드를 스케줄 불가로 표시하려면 다음을 실행한다.
```shell
kubectl cordon $NODENAME
```
{{< note >}}
{{< glossary_tooltip term_id="daemonset" >}}에 포함되는 일부 파드는
스케줄 불가 노드에서 실행될 수 있다. 일반적으로 데몬셋은 워크로드 애플리케이션을
비우는 경우에도 노드에서 실행되어야 하는 노드 로컬 서비스를 제공한다.
{{< /note >}}
## 노드 상태
노드의 상태는 다음의 정보를 포함한다.
@@ -27,11 +121,13 @@ weight: 10
* [용량과 할당가능](#capacity)
* [정보](#info)
노드의 상태와 상세 정보는 다음 커맨드를 통해 확인할 수 있다.
`kubectl` 을 사용해서 노드 상태와 기타 세부 정보를 볼수 있다.
```shell
kubectl describe node <insert-node-name-here>
```
각 섹션은 아래 상세하게 기술되었다.
출력되는 각 섹션은 아래에 설명되어있다.
### 주소 {#addresses}
@@ -46,13 +142,21 @@ kubectl describe node <insert-node-name-here>
`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다.
| Node Condition | Description |
{{< table caption = "노드 컨디션과 각 컨디션이 적용되는 시기에 대한 설명들이다." >}}
| 노드 컨디션 | 설명 |
|----------------|-------------|
| `Ready` | 노드가 상태 양호하며 파드를 수용할 준비가 되어 있는 경우 `True`, 노드의 상태가 불량하여 파드를 수용하지 못할 경우 `False`, 그리고 노드 컨트롤러가 마지막 `node-monitor-grace-period` (기본값 40 기간 동안 노드로부터 응답을 받지 못한 경우) `Unknown` |
| `DiskPressure` | 디스크 사이즈 상에 압박이 있는 경우, 즉 디스크 용량이 넉넉치 않은 경우 `True`, 반대의 경우 `False` |
| `MemoryPressure` | 노드 메모리 상에 압박이 있는 경우, 즉 노드 메모리가 넉넉치 않은 경우 `True`, 반대의 경우 `False` |
| `PIDPressure` | 프로세스 상에 압박이 있는 경우, 즉 노드 상에 많은 프로세스들이 존재하는 경우 `True`, 반대의 경우 `False` |
| `DiskPressure` | 디스크 사이즈 상에 압박이 있는 경우, 즉 디스크 용량이 넉넉치 않은 경우 `True`, 반대의 경우 `False` |
| `NetworkUnavailable` | 노드에 대해 네트워크가 올바르게 구성되지 않은 경우 `True`, 반대의 경우 `False` |
{{< /table >}}
{{< note >}}
커맨드 라인 도구를 사용해서 코드화된 노드의 세부 정보를 출력하는 경우 조건에는
`SchedulingDisabled` 이 포함된다. `SchedulingDisabled` 은 쿠버네티스 API의 조건이 아니며,
대신 코드화된 노드는 사양에 스케줄 불가로 표시된다.
{{< /note >}}
노드 컨디션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다.
@@ -69,17 +173,18 @@ kubectl describe node <insert-node-name-here>
]
```
ready 컨디션의 상태가 `pod-eviction-timeout` ([kube-controller-manager](/docs/admin/kube-controller-manager/)에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
1.5 이전의 쿠버네티스 버전에서는, 노드 컨트롤러가 apiserver로부터 접근 불가한 이러한 파드를 [강제 삭제](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제)
시킬 것이다. 그러나 1.5 이상에서는, 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를
노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를
강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서
동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우,
노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면
노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가
apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
[테인트(taints)](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
[테인트(taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다.
스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다.
@@ -101,47 +206,10 @@ ready 컨디션의 상태가 `pod-eviction-timeout` ([kube-controller-manager](/
커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다.
이 정보는 Kubelet에 의해 노드로부터 수집된다.
## 관리
[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/ko/docs/concepts/services-networking/service/)와 달리,
노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해
외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다.
그래서 쿠버네티스가 노드를 생성할 때,
노드를 나타내는 오브젝트를 생성한다.
생성 이후, 쿠버네티스는 노드의 유효성 여부를 검사한다. 예를 들어,
다음 내용으로 노드를 생성하려 한다면,
```json
{
"kind": "Node",
"apiVersion": "v1",
"metadata": {
"name": "10.240.79.157",
"labels": {
"name": "my-first-k8s-node"
}
}
}
```
쿠버네티스는 내부적으로 (표현을) 노드 오브젝트를 생성하고,
`metadata.name` 필드를 근거로 상태 체크를 수행하여 노드의 유효성을 확인한다. 노드가 유효하면, 즉
모든 필요한 서비스가 동작 중이면, 파드를 동작시킬 자격이 된다. 그렇지 않으면,
유효하게 될때까지 어떠한 클러스터 활동에 대해서도 무시된다.
노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
{{< note >}}
쿠버네티스는 유효하지 않은 노드로부터 오브젝트를 보호하고 유효한 상태로 이르는지 확인하기 위해 지속적으로 체크한다.
이러한 프로세스를 중지시키기 위해는 명시적으로 노드 오브젝트를 삭제해야 한다.
{{< /note >}}
현재, 쿠버네티스 노드 인터페이스와 상호작용 하는 3개의 컴포넌트가 존재하는데,
노드 컨트롤러, kubelet, 그리고 kubectl 이다.
### 노드 컨트롤러
노드 컨트롤러는 노드의 다양한 측면을 관리하는 쿠버네티스
마스터 컴포넌트다.
노드 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
노드의 다양한 측면을 관리하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.
노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에
(CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다.
@@ -164,6 +232,7 @@ NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는
#### 하트비트
쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다.
하트비트의 두 가지 형태는 `NodeStatus` 와
[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io) 이다.
각 노드에는 `kube-node-lease` 라는
@@ -184,13 +253,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
#### 안정성
쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에
문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제들이 발생했기 때문에)
더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로,
노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터
내 모든 노드를 살핀다.
대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여
파드 축출을 하지 않는다는 의미가 된다.
@@ -216,62 +279,11 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
쿠버네티스 1.6을 시작으로 NodeController는 파드가 taint를 허용하지 않을 때,
`NoExecute` taint 상태의 노드 상에 동작하는 파드 축출에 대한 책임 또한
지고 있다. 추가로, 기본적으로 비활성화 된 알파 기능으로, NodeController는 노드 접근 불가
또는 준비 부족과 같은 노드 문제에 상응하는 taint 추가에 대한 책임을 진다.
`NoExecute` taints와 알파 기능에 대한 보다 상세한
내용은 [이 문서](/docs/concepts/configuration/taint-and-toleration/)를 참고한다.
1.8 버전을 시작으로, 노드 컨트롤러는 노드 상태를 나타내는 taint 생성에 대한 책임을 지도록
만들 수 있다. 이는 버전 1.8 의 알파 기능이다.
### 노드에 대한 자체-등록
kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
- `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
- `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 클라우드 제공사업자와 소통할지에 대한 방법.
- `--register-node` - 자동으로 API 서버에 등록.
- `--register-with-taints` - 주어진 taint 리스트 (콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안함.
- `--node-ip` - 노드의 IP 주소.
- `--node-labels` - 클러스터 내 노드를 등록할 경우 추가되는 레이블 (1.13+ 에서 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 강제되는 레이블 제약사항 참고).
- `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의.
[Node authorization mode](/docs/reference/access-authn-authz/node/)와
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
#### 수동 노드 관리
클러스터 관리자는 노드 오브젝트를 생성하고 수정할 수 있다.
관리자가 수동으로 오브젝트를 생성하고자 한다면, kubelet 플래그를
`--register-node=false`로 설정한다.
관리자는 노드 리소스를 수정할 수 있다(`--register-node`설정과 무관하게).
수정은 노드 상에 레이블 설정과 스케줄 불가 마킹을 포함한다.
노드 상의 레이블은 스케줄링을 제어하기 위해,
즉 하나의 파드가 오직 노드의 서브셋 상에 동작할 수 있도록 제한하기 위해 노드 셀렉터와 함께 이용될 수 있다.
노드를 스케줄 불가로 마킹하게 되면, 해당 노드에 새로운 파드가 스케줄되는 것을 막아주지만,
노드 상의 임의의 기존 파드에 대해서는 영향을 미치치 않는다. 이는 노드 리부트
전이나 기타 등의 준비 조치로 유용하다. 예를 들어, 노드를 스케줄 불가로
마크하기 위해 다음 명령을 수행한다.
```shell
kubectl cordon $NODENAME
```
{{< note >}}
DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄러를
우회하고 노드 상에 스케줄 불가 속성을 고려하지 않는다. 심지어 리부트를 준비하는 동안
애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다.
{{< /note >}}
또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의
노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다.
추가로, 노드 컨틀로러는 연결할 수 없거나, 준비되지 않은 노드와 같은 노드 문제에 상응하는
{{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
{{< caution >}}
`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
@@ -281,34 +293,41 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
### 노드 용량
노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다.
일반적으로, 노드는 스스로 등록하고 노드 오브젝트를 생성할 때 자신의 용량을 알린다. 만약
[수동 노드 관리](#수동-노드-관리)를 수행 한다면, 노드를 추가할 때
노드 용량을 설정해야 한다.
노드 오브젝트는 노드 리소스 용량에 대한 정보(예: 사용 가능한 메모리의
양과 CPU의 수)를 추적한다.
노드의 [자체 등록](#노드에-대한-자체-등록)은 등록하는 중에 용량을 보고한다.
[수동](#수동-노드-관리)으로 노드를 추가하는 경우 추가할 때
노드의 용량 정보를 설정해야 한다.
쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다.
노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다.
kubelet에 의해 구동된 모든 컨테이너를 포함하지만, [컨테이너 런타임](/ko/docs/concepts/overview/components/#컨테이너-런타임)에 의해 직접 구동된 컨테이너 또는 컨테이너 외부에서 동작하는 임의의 프로세스는 해당되지 않는다.
쿠버네티스 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}는
노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 스케줄러는 노드 상에
컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다.
요청의 합은 kubelet에서 관리하는 모든 컨테이너를 포함하지만, 컨테이너 런타임에
의해 직접적으로 시작된 컨 테이너는 제외되고 kubelet의 컨트롤 범위
밖에서 실행되는 모든 프로세스도 제외된다.
{{< note >}}
파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면,
[reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다.
[시스템 데몬에 사용할 리소스 예약하기](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)을 본다.
{{< /note >}}
## 노드 토폴로지
{{< feature-state state="alpha" >}}
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
`TopologyManager`
[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
## API 오브젝트
노드는 쿠버네티스 REST API 내 탑-레벨 리소스 이다. API 오브젝트에 대한
보다 자세한 내용은
[노드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)에서 확인할 수 있다.
자세한 내용은
[노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
{{% /capture %}}
{{% capture whatsnext %}}
* [노드 컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 읽기
* 노드 수준 토폴로지에 대해 읽기: [노드의 토폴로지 정책 제어하기](/docs/tasks/administer-cluster/topology-manager/)
* 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.
* [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다.
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
섹션을 읽어본다.
* [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다.
* [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.
{{% /capture %}}