Edit This Page

런타임 클래스

이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다.

경고: 런타임클래스는 v1.14 베타 업그레이드에서 중대한 변화를 포함한다. 런타임클래스를 v1.14 이전부터 사용하고 있었다면, 런타임 클래스를 알파에서 베타로 업그레이드하기를 확인한다.

• 런타임 클래스
• 동기

런타임 클래스

런타임 클래스는 컨테이너 런타임 설정을 선택하는 기능이다. 이 컨테이너 런타임 설정은 파드의 컨테이너를 실행할 때에 이용한다.

동기

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

또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 여러 파드를 실행할 수 있다.

셋업

RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. 특징 게이트 활성화에 대한 설명은 특징 게이트를 참고한다. RuntimeClass 특징 게이트는 apiservers 및 kubelets에서 활성화되어야 한다.

1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
2. 상응하는 런타임 클래스 리소스 생성

1. CRI 구현을 노드에 설정

런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. 사용자의 CRI 구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다(아래).

참고: 런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 스케줄을 참고한다.

해당 설정은 상응하는 handler 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + -와 .문자)을 가져야 한다.

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

1단계에서 셋업 한 설정은 연관된 handler 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 "" 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다.

현재 런타임 클래스 리소스는 런타임 클래스 이름(metadata.name)과 런타임 핸들러 (handler)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.

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

런타임 클래스 오브젝트의 이름은 유효한 DNS 서브도메인 이름어이야 한다.

참고: 런타임 클래스 쓰기 작업(create/update/patch/delete)은 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 권한 개요를 참고한다.

사용

클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 runtimeClassName를 명시한다. 예를 들면 다음과 같다.

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

이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 Failed 터미널 단계로 들어간다. 에러 메시지에 상응하는 이벤트를 확인한다.

만약 명시된 runtimeClassName가 없다면, 기본 런타임 핸들러가 사용되며, 런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.

CRI 구성

CRI 런타임 설치에 대한 자세한 내용은 CRI 설치를 확인한다.

dockershim

쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.

containerdA container runtime with an emphasis on simplicity, robustness and portability

런타임 핸들러는 containerd의 구성 파일인 /etc/containerd/config.toml 통해 설정한다. 유효한 핸들러는 runtimes 단락 아래에서 설정한다.

[plugins.cri.containerd.runtimes.${HANDLER_NAME}]

더 자세한 containerd의 구성 문서를 살펴본다. https://github.com/containerd/cri/blob/master/docs/config.md

CRI-OA lightweight container runtime specifically for Kubernetes

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

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

더 자세한 것은 CRI-O의 설정 문서를 본다.

스케줄

쿠버네티스 v1.16 부터, 런타임 클래스는 scheduling 필드를 통해 이종의 클러스터 지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면, 런타임 클래스 [어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다.

파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 runtimeClass.scheduling.nodeSelector 필드에서 선택되는 공통 레이블을 가져야한다. 런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로 각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다.

지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면, tolerations를 런타임 클래스에 추가할 수 있다. nodeSelector를 사용하면, 어드미션 시 해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 노드의 합집합을 취한다.

노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 노드에 파드 할당을 참고한다.

파드 오버헤드

쿠버네티스 v1.16 부터는, 런타임 클래스에는 구동 중인 파드와 관련된 오버헤드를 지정할 수 있는 기능이 PodOverhead 기능을 통해 지원된다. PodOverhead를 사용하려면, PodOverhead 기능 게이트를 활성화 시켜야 한다. (기본 값으로는 비활성화 되어 있다.)

파드 오버헤드는 런타임 클래스에서 Overhead 필드를 통해 정의된다. 이 필드를 사용하면, 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.

런타임 클래스를 알파에서 베타로 업그레이드

런타임 클래스 베타 기능은 다음의 변화를 포함한다.

• node.k8s.io API 그룹과 runtimeclasses.node.k8s.io 리소스는 CustomResourceDefinition에서 내장 API로 이전되었다.
• 런타임 클래스 정의에서 spec을 직접 사용할 수 있다. (즉, 더 이상 RuntimeClassSpec는 없다).
• runtimeHandler 필드는 handler로 이름이 바뀌었다.
• handler 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 runtimeHandler 필드가 필요하다는 의미이다.
• handler 필드는 반드시 올바른 DNS 레이블(RFC 1123)으로, 이는 더 이상 . 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는 다음의 정규 표현식을 따른다. ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$.

작업 필요 다음 작업은 알파 버전의 런타임 기능을 베타 버전으로 업그레이드하기 위해 진행되어야 한다.

• 런타임 클래스 리소스는 v1.14로 업그레이드 후에 반드시 재생성되어야 하고, runtimeclasses.node.k8s.io CRD는 다음과 같이 수동으로 지워야 한다.

  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
  

• 지정되지 않았거나 비어 있는 runtimeHandler 이거나 핸들러 내에 . 캐릭터를 사용한 알파 런타임 클래스는 더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다 (위를 참조).

더 읽기

• 런타임 클래스 설계
• 런타임 클래스 스케줄링 설계
• 파드 오버헤드 개념에 대해 읽기
• 파드 오버헤드 기능 설계

피드백

이 페이지가 도움이 되었나요?

피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. Stack Overflow. 원한다면 GitHub 리포지터리에 이슈를 열어서 문제 리포트 또는 개선 제안이 가능합니다..