K8s 컨테이너 런타임 편집하기

==개요==
{{작성중}}
[[분류: k8s]]
;컨테이너 런타임
;Container Runtimes
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
----
{{NOTE}}
Dockershim은 Kubernetes 프로젝트에서 릴리스 1.24부터 제거되었습니다. 자세한 내용은 [https://kubernetes.io/blog/2022/02/17/dockershim-faq/ Dockershim 제거 FAQ]를 참조하세요.
{{/NOTE}}

각 클러스터 노드에 컨테이너 런타임을 설치해야만 파드를 실행할 수 있습니다. 이 페이지에서는 노드 설정에 필요한 작업과 관련된 내용을 설명합니다.

Kubernetes 1.30에서는 [[Container Runtime Interface]] (CRI)를 준수하는 런타임을 사용해야 합니다.

자세한 내용은 [[#CRI 버전 지원|CRI 버전 지원]] 정보를 참조하세요.

이 페이지에서는 Kubernetes에서 몇 가지 일반적인 컨테이너 런타임을 사용하는 방법에 대해 설명합니다.

* [[#containerd|containerd]]
* [[#CRI-O|CRI-O]]
* [[#Docker Engine|Docker Engine]]
* [[#Mirantis 컨테이너 런타임|Mirantis 컨테이너 런타임]]

{{NOTE}}
Kubernetes v1.24 이전 릴리스에서는 dockershim이라는 컴포넌트를 사용하여 Docker Engine과 직접 연계를 제공했습니다. 이 특별한 직접 연계는 더 이상 Kubernetes의 일부가 아닙니다(v1.20 릴리스에서 이 제거가 [https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation 발표]되었습니다). 이 제거가 사용자에게 미치는 영향을 이해하려면 [[Dockershim 제거 영향도 확인하기]]를 읽어보세요. dockershim을 사용하는 것에서의 마이그레이션에 대해 알아보려면 [[dockershim으로부터 마이그레이션]]을 참조하세요.

Kubernetes v1.30 이외의 버전을 사용 중인 경우 해당 버전의 문서를 확인하세요.
{{/NOTE}}

==전제조건 설치 및 설정==
===네트워크 설정===
기본적으로, 리눅스 커널은 인터페이스 간에 IPv4 패킷이 라우팅되는 것을 허용하지 않습니다. 대부분의 Kubernetes 클러스터 네트워킹 구현은 이 설정을 변경합니다(필요한 경우). 그러나 일부는 관리자가 직접 설정해주기를 기대할 수도 있습니다. (또한 일부는 다른 sysctl 매개변수를 설정하거나, 커널 모듈을 로드하는 등의 작업을 기대할 수도 있습니다. 특정 네트워크 구현에 대한 문서를 참조하세요.)

===IPv4 패킷 포워딩 활성화===
IPv4 패킷 포워딩을 수동으로 활성화하려면 다음 단계를 따르세요:

<syntaxhighlight lang='bash'>
# 재부팅 후에도 유지되는 sysctl 파라미터 셋업
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# 재부팅 없이 sysctl 파라미터 적용
sudo sysctl --system
</syntaxhighlight>

<code>net.ipv4.ip_forward</code> 값이 1로 설정되었는지 확인하려면 다음 명령어를 실행하세요:

<syntaxhighlight lang='bash'>
sysctl net.ipv4.ip_forward
</syntaxhighlight>

==cgroup 드라이버==
리눅스에서, [[cgroups|컨트롤 그룹(cgroups)]]은 프로세스에 할당된 자원을 제약하기 위해 사용됩니다.

[[kubelet]]과 기본 컨테이너 런타임은 [[파드 및 컨테이너 리소스 관리|파드와 컨테이너에 대한 리소스 관리]](예: CPU/메모리 요청 및 제한)를 강제하기 위해 컨트롤 그룹과 인터페이스해야 합니다. 컨트롤 그룹과 인터페이스하기 위해, kubelet과 컨테이너 런타임은 cgroup 드라이버를 사용해야 합니다. kubelet과 컨테이너 런타임이 동일한 cgroup 드라이버를 사용하고 동일하게 설정하는 것이 중요합니다.

사용가능한 두 가지 cgroup 드라이버는 다음과 같습니다:

* [[#cgroupfs 드라이버|cgroupfs]]
* [[#systemd cgroup 드라이버|systemd]]

===cgroupfs 드라이버===
===systemd cgroup 드라이버===
[[systemd]]가 Linux 배포판의 init 시스템으로 선택되면, init 프로세스는 root 컨트롤 그룹(<code>cgroup</code>)을 생성하고 이를 소비하며, cgroup 매니저로 동작합니다.

systemd는 cgroup과 긴밀하게 통합되어 있으며, systemd 유닛마다 하나의 cgroup을 할당합니다. 따라서, <code>cgroupfs</code> 드라이버를 사용하는 상태에서 <code>systemd</code>를 init 시스템으로 사용할 경우, 시스템에는 두 개의 다른 cgroup 매니저가 존재하게 됩니다.

두 개의 cgroup 매니저가 존재하면 시스템에서 사용가능한 자원과 사용중인 자원에 대한 두 가지 서로 다른 뷰가 생성됩니다. 일부 경우에는, kubelet 및 컨테이너 런타임을 위해 <code>cgroupfs</code>를 사용하지만 나머지 프로세스에 대해서는 <code>systemd</code>를 사용하는 노드가 자원 압박 상황에서 불안정해질 수 있습니다.

이 불안정을 완화하기 위한 접근방식은, systemd가 선택된 init 시스템일 때 kubelet과 컨테이너 런타임에 대해 <code>systemd</code>를 cgroup 드라이버로 사용하는 것입니다.

<code>systemd</code>를 cgroup 드라이버로 설정하려면, <code>[[설정 파일을 통한 Kubelete 매개변수 세팅|KubeletConfiguration]]</code> 옵션의 <code>cgroupDriver</code>를 편집하고 이를 <code>systemd</code>로 설정합니다. 예시:

<syntaxhighlight lang='yaml'>
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
</syntaxhighlight>

{{NOTE}}
v1.22 이후 버전에서는, 사용자가 <code>KubeletConfiguration</code> 아래의 <code>cgroupDriver</code> 필드를 세팅하지 않으면, kubeadm이 기본적으로 <code>systemd</code>로 세팅합니다.
{{/NOTE}}

Kubernetes v1.28에서는 <code>KubeletCgroupDriverFromCRI</code> [[k8s 기능 게이트|기능 게이트]]가 활성화되고 <code>RuntimeConfig</code> CRI RPC를 지원하는 컨테이너 런타임을 사용하는 경우, kubelet이 런타임에서 적절한 cgroup 드라이버를 자동으로 감지하고, kubelet 설정 내의 <code>cgroupDriver</code> 세팅을 무시합니다.

kubelet의 cgroup 드라이버를 <code>systemd</code>로 설정하는 경우, 컨테이너 런타임의 cgroup 드라이버도 <code>systemd</code>로 설정해야 합니다. 컨테이너 런타임에 대한 문서를 참조하십시오. 예시:
* [[k8s 컨테이너 런타임#systemd cgroup 드라이버 설정|containerd]]
* [[k8s 컨테이너 런타임#CRI-O|CRI-O]]

{{CAUTION}}
클러스터에 조인된 노드의 cgroup 드라이버를 변경하는 것은 민감한 작업입니다. kubelet이 하나의 cgroup 드라이버의 의미론을 사용하여 파드를 생성한 경우, 컨테이너 런타임을 다른 cgroup 드라이버로 변경하면 이러한 기존 파드의 파드 샌드박스를 다시 생성할 때 오류가 발생할 수 있습니다. kubelet을 재시작해도 이러한 오류를 해결하지 못할 수 있습니다.

자동화를 통해 이를 실행가능하게 만들었다면, 업데이트된 설정으로 노드를 다른 것으로 교체하거나 자동화를 사용하여 재설치하십시오.
{{/CAUTION}}

===kubeadm으로 생성한 클러스터의 드라이버를 <code>systemd</code>로 마이그레이션===
기존 kubeadm으로 관리되는 클러스터에서 <code>systemd</code> cgroup 드라이버로 마이그레이션하려면, [[cgroup 드라이버 설정|cgroup 드라이버를 설정]]하는 절차를 따르세요.

==CRI 버전 지원==
컨테이너 런타임은 최소 v1alpha2 버전의 컨테이너 런타임 인터페이스를 지원해야 합니다.

[https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal Kubernetes v1.26부터는] v1 버전의 CRI API와만 작동합니다. 이전 버전에서는 기본적으로 v1 버전을 사용하지만, 컨테이너 런타임이 v1 API를 지원하지 않는 경우 kubelet은 (지원중단된) v1alpha2 API를 대신 사용합니다.

==컨테이너 런타임==
{{NOTE}}
이 섹션은 Kubernetes에 필요한 기능을 제공하는 서드파티 프로젝트로 연결됩니다. Kubernetes 프로젝트 작성자는 이 프로젝트들에 대한 책임이 없으며, 프로젝트는 알파벳순으로 나열되어 있습니다. 이 목록에 프로젝트를 추가하려면, 변경사항을 제출하기 전에 [[k8s 문서 컨텐츠 가이드#서드파티 컨텐츠|컨텐츠 가이드]]를 읽으십시오.
{{/NOTE}}

===containerd===
이 섹션은 containerd를 CRI 런타임으로 사용하는 데 필요한 단계들을 설명합니다.

시스템에 containerd를 설치하려면, [https://github.com/containerd/containerd/blob/main/docs/getting-started.md containerd 시작하기] 안내를 따르십시오. 유효한 <code>config.toml</code> 설정 파일을 생성한 후 이 단계로 돌아오십시오.

이 파일은 <code>/etc/containerd/config.toml</code> 경로에서 찾을 수 있습니다.

Linux에서 containerd의 기본 CRI 소켓은 <code>/run/containerd/containerd.sock</code>입니다. Windows에서 기본 CRI 엔드포인트는 <code>npipe://./pipe/containerd-containerd</code>입니다.

===CRI-O===
이 섹션은 컨테이너 런타임으로 CRI-O를 설치하는 데 필요한 절차를 포함하고 있습니다.

CRI-O를 설치하려면 [https://github.com/cri-o/packaging/blob/main/README.md#usage CRI-O 설치 지침]을 따르십시오.

===Docker Engine===

===Mirantis 컨테이너 런타임===

==다음 내용==