런타임 클래스
런타임 클래스 (Runtime Class)
이 페이지는 RuntimeClass 리소스와 런타임 선택 메커니즘을 설명해요. RuntimeClass는 컨테이너 런타임 구성을 선택하는 기능이에요. 컨테이너 런타임 구성은 파드의 컨테이너를 실행하는 데 사용돼요.
출처: 문서
본문
동기 (Motivation)
파드마다 서로 다른 RuntimeClass를 설정하면 성능과 보안 사이의 균형을 조절할 수 있어요. 예를 들어, 워크로드의 일부가 높은 수준의 정보 보안 보증을 필요로 한다면, 하드웨어 가상화를 사용하는 컨테이너 런타임에서 그 파드가 실행되도록 스케줄링할 수 있어요. 그러면 대체 런타임의 추가 격리 혜택을 얻는 대신, 약간의 추가 오버헤드를 감수하게 돼요.
RuntimeClass를 사용해 같은 컨테이너 런타임을 서로 다른 설정으로 실행하는 서로 다른 파드들도 만들 수 있어요.
설정 (Setup)
- 노드에서 CRI 구현을 구성 (런타임에 따라 다름)
- 해당 RuntimeClass 리소스 생성
1. 노드에서 CRI 구현 구성하기
RuntimeClass를 통해 사용할 수 있는 구성은 CRI(Container Runtime Interface) 구현에 따라 달라져요. CRI 구현별 구성 방법은 아래 해당 문서를 참고해요. 이 구성에는 RuntimeClass가 참조하는 해당 핸들러 이름(handler name)이 있어요. 핸들러는 유효한 DNS 라벨 이름이어야 해요.
2. 해당 RuntimeClass 리소스 생성하기
1단계에서 설정한 각 구성에는 그것을 식별하는 핸들러 이름이 있어야 해요. 각 핸들러에 대해 해당 RuntimeClass 객체를 만들어요.
RuntimeClass 리소스는 현재 중요한 필드가 두 개뿐이에요. RuntimeClass 이름(metadata.name)과 핸들러(handler)예요. 객체 정의는 다음과 같아요.
# RuntimeClass is defined in the node.k8s.io API group
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
# The name the RuntimeClass will be referenced by.
# RuntimeClass is a non-namespaced resource.
name: myclass
# The name of the corresponding CRI configuration
handler: myconfiguration
RuntimeClass 객체의 이름은 유효한 DNS 서브도메인 이름이어야 해요.
사용법 (Usage)
클러스터에 RuntimeClass가 구성되면, 파드 스펙에서 runtimeClassName을 지정해 사용할 수 있어요. 예를 들어:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: myclass
# ...
이렇게 하면 kubelet이 지정된 이름의 RuntimeClass로 이 파드를 실행하도록 지시해요. 지정된 RuntimeClass가 존재하지 않거나 CRI가 해당 핸들러를 실행할 수 없으면, 파드는 Failed 종료 단계로 들어가요. 해당 이벤트에서 오류 메시지를 찾아보세요.
runtimeClassName을 지정하지 않으면 기본 RuntimeHandler가 사용되는데, 이는 RuntimeClass 기능이 비활성화된 경우의 동작과 동일해요.
CRI 구성
CRI 런타임 설정에 대한 자세한 내용은 CRI 설치 문서를 참고해요.
containerd
런타임 핸들러는 /etc/containerd/config.toml의 containerd 구성으로 설정돼요. 유효한 핸들러는 runtimes 섹션 아래에 구성돼요:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
자세한 내용은 containerd config 문서를 참고해요.
CRI-O
런타임 핸들러는 /etc/crio/crio.conf의 CRI-O 구성으로 설정돼요. 유효한 핸들러는 crio.runtime 테이블 아래에 구성돼요:
[crio.runtime.runtimes.${HANDLER_NAME}]
runtime_path = "${PATH_TO_BINARY}"
자세한 내용은 CRI-O config 문서를 참고해요.
스케줄링 (Scheduling)
RuntimeClass의 scheduling 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가 이를 지원하는 노드에 스케줄링되도록 제약을 설정할 수 있어요. scheduling이 설정되지 않으면 이 RuntimeClass가 모든 노드에서 지원된다고 간주돼요.
특정 RuntimeClass를 지원하는 노드에 파드가 떨어지게 하려면, 그 노드 집합에 공통 라벨을 부여하고 runtimeclass.scheduling.nodeSelector 필드로 선택해야 해요. RuntimeClass의 nodeSelector는 admission에서 파드의 nodeSelector와 병합되는데, 사실상 각각이 선택한 노드 집합의 교집합을 취하는 것과 같아요. 충돌이 있으면 파드는 거부돼요.
지원 노드에 테인트(taint)가 걸려 다른 RuntimeClass 파드가 그 노드에서 실행되지 못하게 한다면, RuntimeClass에 톨러레이션(toleration)을 추가할 수 있어요. nodeSelector와 마찬가지로 톨러레이션도 admission에서 파드의 톨러레이션과 병합되며, 사실상 각각이 허용하는 노드 집합의 합집합을 취해요.
노드 셀렉터와 톨러레이션 구성에 대해 더 배우려면 파드를 노드에 할당하기를 참고해요.
파드 오버헤드 (Pod Overhead)
파드 실행과 관련된 오버헤드 리소스를 지정할 수 있어요. 오버헤드를 선언하면 클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 이를 고려할 수 있게 돼요.
파드 오버헤드는 RuntimeClass의 overhead 필드로 정의돼요. 이 필드를 사용해 이 RuntimeClass로 파드를 실행할 때의 오버헤드를 지정하고, Kubernetes가 이 오버헤드를 고려하도록 할 수 있어요.