[ko] Update outdated files dev-1.25-ko.1 (M71)
Signed-off-by: Hyeongju Johannes Lee <hyeongju.lee@intel.com>pull/37154/head
Hyeongju Johannes Lee
parent
fb32f12411
commit
3f75bd1d31
|
|
@ -87,22 +87,67 @@ sudo sysctl --system
|
|||
리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은
|
||||
프로세스에 할당된 리소스를 제한하는데 사용된다.
|
||||
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}과
|
||||
그에 연계된 컨테이너 런타임 모두 컨트롤 그룹(control group)들과 상호작용 해야 하는데, 이는
|
||||
[파드 및 컨테이너 자원 관리](/docs/concepts/configuration/manage-resources-containers/)가 수정될 수 있도록 하고
|
||||
cpu 혹은 메모리와 같은 자원의 요청(request)과 상한(limit)을 설정하기 위함이다. 컨트롤
|
||||
그룹과 상호작용하기 위해서는, kubelet과 컨테이너 런타임이 *cgroup 드라이버*를 사용해야 한다.
|
||||
매우 중요한 점은, kubelet과 컨테이너 런타임이 같은 cgroup
|
||||
group 드라이버를 사용해야 하며 구성도 동일해야 한다는 것이다.
|
||||
|
||||
두 가지의 cgroup 드라이버가 이용 가능하다.
|
||||
|
||||
* [`cgroupfs`](#cgroupfs-cgroup-driver)
|
||||
* [`systemd`](#systemd-cgroup-driver)
|
||||
|
||||
### cgroupfs 드라이버 {#cgroupfs-cgroup-driver}
|
||||
|
||||
`cgroupfs` 드라이버는 kubelet의 기본 cgroup 드라이버이다. `cgroupfs`
|
||||
드라이버가 사용될 때, kubelet과 컨테이너 런타임은 직접적으로
|
||||
cgroup 파일시스템과 상호작용하여 cgroup들을 설정한다.
|
||||
|
||||
`cgroupfs` 드라이버가 권장되지 **않는** 때가 있는데,
|
||||
[systemd](https://www.freedesktop.org/wiki/Software/systemd/)가
|
||||
init 시스템인 경우이다. 이것은 systemd가 시스템에 단 하나의 cgroup 관리자만 있을 것으로 기대하기 때문이다.
|
||||
또한, [cgroup v2](/docs/concepts/architecture/cgroups)를 사용할 경우에도
|
||||
`cgroupfs` 대신 `systemd` cgroup 드라이버를
|
||||
사용한다.
|
||||
|
||||
### systemd cgroup 드라이버 {#systemd-cgroup-driver}
|
||||
|
||||
리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인
|
||||
경우, init 프로세스는 root control group(`cgroup`)을
|
||||
생성 및 사용하는 cgroup 관리자로 작동한다.
|
||||
Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다.
|
||||
컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. systemd와 함께
|
||||
`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다.
|
||||
|
||||
단일 cgroup 관리자는 할당되는 리소스가 무엇인지를 단순화하고,
|
||||
기본적으로 사용할 수 있는 리소스와 사용 중인 리소스를 일관성있게 볼 수 있다.
|
||||
시스템에 두 개의 cgroup 관리자가 있으면, 이런 리소스도 두 개의 관점에서 보게 된다.
|
||||
현장에서 사람들은 kubelet과 도커에 `cgroupfs`를 사용하고,
|
||||
나머지 프로세스는 `systemd`를 사용하도록 노드가 설정된 경우, 리소스가 부족할 때
|
||||
불안정해지는 사례를 보고했다.
|
||||
systemd는 cgroup과 긴밀하게 통합되어 있으며 매 systemd 단위로 cgroup을
|
||||
할당한다. 결과적으로, `systemd`를 init 시스템으로 사용하고 `cgroupfs`
|
||||
드라이버를 사용하면, 그 시스템은 두 개의 다른 cgroup 관리자를 갖게 된다.
|
||||
|
||||
컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면
|
||||
시스템이 안정화된다. 도커에 대해 구성하려면, `native.cgroupdriver=systemd`를 설정한다.
|
||||
두 개의 cgroup 관리자는 시스템 상 사용 가능한 자원과 사용 중인 자원들에 대하여 두 가지 관점을 가져 혼동을
|
||||
초래한다. 예를 들어, kubelet과 컨테이너 런타임은 `cgroupfs`를 사용하고
|
||||
나머지 프로세스는 `systemd`를 사용하도록 노드를 구성한 경우, 노드가
|
||||
자원 압박으로 인해 불안정해질 수 있다.
|
||||
|
||||
이러한 불안정성을 줄이는 방법은, `systemd`가 init 시스템으로 선택되었을 때에는 `systemd`를
|
||||
kubelet과 컨테이너 런타임의 cgroup 드라이버로 사용하는 것이다.
|
||||
|
||||
`systemd`를 cgroup 드라이버로 사용하기 위해서는,
|
||||
[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/)를 수정하여
|
||||
`cgroupDriver` 옵션을 `systemd`로 지정하는 것이다. 예를 들면 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
kind: KubeletConfiguration
|
||||
...
|
||||
cgroupDriver: systemd
|
||||
```
|
||||
|
||||
`systemd`를 kubelet의 cgroup 드라이버로 구성했다면, 반드시
|
||||
컨테이너 런타임의 cgroup 드라이버 또한 `systemd`로 설정해야 한다. 자세한 설명은
|
||||
컨테이너 런타임 대한 문서를 참조한다. 예를 들면 다음과 같다.
|
||||
|
||||
* [containerd](#containerd-systemd)
|
||||
* [CRI-O](#cri-o)
|
||||
|
||||
{{< caution >}}
|
||||
클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 신중하게 수행해야 한다.
|
||||
|
|
@ -114,41 +159,6 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
|
|||
교체하거나, 자동화를 사용하여 다시 설치한다.
|
||||
{{< /caution >}}
|
||||
|
||||
### Cgroup 버전 2 {#cgroup-v2}
|
||||
|
||||
cgroup v2는 cgroup Linux API의 다음 버전이다.
|
||||
cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.
|
||||
|
||||
새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다.
|
||||
|
||||
- API를 더 쉽고 깔끔하게 사용할 수 있음
|
||||
- 컨테이너로의 안전한 하위 트리 위임
|
||||
- 압력 중지 정보와 같은 새로운 기능
|
||||
|
||||
일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도,
|
||||
쿠버네티스는 모든 컨트롤러를 관리하기 위해
|
||||
동일한 cgroup 버전만 지원한다.
|
||||
|
||||
systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을
|
||||
추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.
|
||||
|
||||
```shell
|
||||
# 이 예제는 리눅스 OS에서 DNF 패키지 관리자를 사용하는 경우에 대한 것이다.
|
||||
# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해
|
||||
# 사용자의 시스템이 다른 방법을 사용하고 있을 수도 있다.
|
||||
sudo dnf install -y grubby && \
|
||||
sudo grubby \
|
||||
--update-kernel=ALL \
|
||||
--args="systemd.unified_cgroup_hierarchy=1"
|
||||
```
|
||||
|
||||
커널이 사용하는 커맨드 라인을 업데이트하려면,
|
||||
변경 사항을 적용하기 위해 노드를 재시작해야 한다.
|
||||
|
||||
cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서
|
||||
cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.
|
||||
|
||||
cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다.
|
||||
|
||||
### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
|
||||
|
||||
|
|
@ -197,6 +207,9 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
|
|||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
|
||||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
[cgroup v2](/docs/concepts/architecture/cgroups)을 사용할 경우 `systemd` cgroup 드라이버가 권장된다.
|
||||
|
||||
{{< note >}}
|
||||
만약 containerd를 패키지(RPM, `.deb` 등)를 통해 설치하였다면,
|
||||
CRI integration 플러그인은 기본적으로 비활성화되어 있다.
|
||||
|
|
@ -222,7 +235,7 @@ kubeadm을 사용하는 경우,
|
|||
|
||||
```toml
|
||||
[plugins."io.containerd.grpc.v1.cri"]
|
||||
sandbox_image = "k8s.gcr.io/pause:3.2"
|
||||
sandbox_image = "registry.k8s.io/pause:3.2"
|
||||
```
|
||||
|
||||
설정 파일을 변경하는 경우 역시 `systemctl restart containerd`를 통해 `containerd`를 재시작해야 한다.
|
||||
|
|
@ -282,12 +295,6 @@ live configuration reload 기능을 지원한다.
|
|||
|
||||
`cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다.
|
||||
|
||||
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd}
|
||||
|
||||
`cri-dockerd` 어댑터는,
|
||||
파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
|
||||
해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
|
||||
|
||||
### 미란티스 컨테이너 런타임 {#mcr}
|
||||
|
||||
[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며
|
||||
|
|
|
|||
Loading…
Reference in New Issue