[컨테이너] 런타임클래스

런타임클래스(RuntimeClass)

쿠버네티스 공식문서를 확인하며 런타임클래스에 대해서 기억해야 하는 부분을 기록한다.

• 런타임클래스는 컨테이너 런타임 구성을 선택하는 기능으로 파드의 컨테이너를 실행하는 데 사용된다.

---

동기

• 서로 다른 파드간에 런타임클래스를 설정하여 성능과 보안의 균형을 유지할 수 있다.
• 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우, 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 것을 선택할 수 있다.
• 이러한 작업은 몇가지 추가적인 오버헤드가 있지만 대체 런타임을 추가 분리하는 이익이 있다.
• 런타임클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 여러 파드를 실행할 수 있다.

[정리]

런타임클래스는 컨테이너 런타임을 구성하기 위해 사용되고 서로 다른 파드간에 성능과 보안의 균형을 유지할 수 있다. 런타임클래스를 사용하면 컨테이너 런타임은 동일하지만 설정이 다른 여러 파드를 실행할 수 있다.

---

셋업

CRI 구현을 노드에 설정

• 런타임클래스를 통해 가능한 구성은 CRI에 의존적이기 때문에 사용자의 CRI 구현에 따른 설정 방법은 연관된 문서를 통해 확인해야 한다.
• 이러한 설정은 상응하는 handler 이름을 가지며, 이는 런타임클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인을 가져야 한다.
• 런타임클래스는 기본적으로 클러스터 전체에 걸쳐 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되어 있을 것으로 가정하기 때문에 이종(heterogeneous) 노드 설정을 지원하기 위해서는, 스케줄 필드를 지정해야 한다.

상응하는 런타임클래스 리소스 생성

• 1단계에서 셋업 한 설정은 연관된 handler 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다.
• 각 런타임 핸들러에 대해서, 상응하는 런타임클래스 오브젝트를 생성한다.
• 런타임클래스 리소스는 런타임클래스 이름(metadata.name)과 런타임 핸들러(handler)로 단 2개의 중요 필드만 가지고 있다. 오브젝트의 정의는 아래와 같다.

# 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  # 런타임클래스 참조에 사용될 이름
  # 런타임클래스는 네임스페이스가 없는 리소스임
  name: myclass
# 상응하는 CRI 설정의 이름
handler: myconfiguration

• 런타임클래스의 CRUD작업은 클러스터 관리자로 제한하는 것이 권장되며 기본 설정이다.

[정리]

런타임클래스의 구성은 CRI 종류에 의존적이기 때문에 사용하려는 CRI에 따라 구성이 변경될 수 있다.

클러스터에 위치하는 모든 노드가 같은 컨테이너 런타임 설정으로 실행되었을 것으로 가정하기 때문에 다른 노드 설정을 지원하기 위해서는 스케줄 필드를 지정해야 한다.

런타임클래스 리소스는 metadata.name, handler 단 2개의 중요 필요로 한다.

---

사용

• 클러스터에 런타임클래스를 설정하고 나면, 아래와 같이 파드 스펙에 runtimeClassName을 명시하여 해당 런타임 클래스를 사용할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ... 

• kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
• 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 Failed 터미널 단계로 들어가고 에러 메시지에 상응하는 이벤트를 확인한다.
• 명시된 runtimeClassName가 없다면, 기본 런타임 핸들러가 사용되며, 런타임클래스 기능이 비활성화되었을 때와 동일하게 동작한다.

CRI 구성

containerd

• 런타임 핸들러는 containerd의 구성 파일인 /etc/containerd/config.toml을 통해 유효한 핸들러는 runtimes 뒤에 설정한다.

**[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]**

CRI-O

• 런타임 핸들러는 CRI-O의 구성파일인 /etc/crio/crio.conf을 통해 설정한다. crio.runtime 테이블 아래에 유효한 핸들러를 설정한다.

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

[정리]

클러스터에 런타임클래스를 설정하고 파드의 스펙 부분에 runtimeClassName 을 명시하여 런타임클래스 사용이 가능하다. 만약, 명시한 runtimeClassName 가 없다면 기본 런타임 핸들러가 사용되어 런타임클래스 기능이 비활성화되어 있을 때와 동일하게 동작한다.

---

스케줄

• RuntimeClass에 scheduling 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가 이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다.
• scheduling이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.
• 파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 runtimeClass.scheduling.nodeSelector 필드에서 선택되는 공통 레이블을 가져야한다.
• 런타임클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어, 실질적으로 각각에 의해 선택된 노드의 교집합을 취하고, 충돌이 발생하는 경우 파드는 거부된다.
• 지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면, tolerations를 런타임클래스에 추가할 수 있다.
• nodeSelector를 사용하면, 어드미션 시 해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 노드의 합집합을 취한다.

파드 오버헤드

• 파드 실행과 연관되는 “오버헤드” 리소스를 지정할 수 있다. “오버헤드”를 선언하면 클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리 할 수 있다.
• 파드 오버헤드는 런타임클래스에서 overhead 필드를 통해 정의되고, 필드를 통해서 해당 런타임클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.

[정리]

RuntimeClass에 scheduling 필드를 지정하면 해당 RuntimeClass로 실행되는 파드가 이것을 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다. 만약 scheduling이 설정되지 않았다면 모든 노드에서 지원되는 것으로 간주된다.

overhead 필드를 통해서 파드 실행과 연관되는 “오버헤드” 리소스를 결정할 수 있다. 런타임클래스를 사용해서 구동 중인 파드의 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.

---

참고 자료

• https://kubernetes.io/ko/docs/concepts/containers/runtime-class/