@@ -8,7 +8,13 @@ weight: 20
88
99{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
1010
11- 이 페이지는 런타임 클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
11+ 이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
12+
13+ {{< warning >}}
14+ 런타임클래스는 v1.14 베타 업그레이드에서 * 중대한* 변화를 포함한다.
15+ 런타임클래스를 v1.14 이전부터 사용하고 있었다면,
16+ [ 런타임 클래스를 알파에서 베타로 업그레이드하기] ( #upgrading-runtimeclass-from-alpha-to-beta ) 를 확인한다.
17+ {{< /warning >}}
1218
1319{{% /capture %}}
1420
@@ -17,82 +23,72 @@ weight: 20
1723
1824## 런타임 클래스
1925
20- 런타임 클래스는 파드의 컨테이너를 실행하는데 사용할 컨테이너 런타임 설정을 선택하기 위한
21- 알파 특징이다 .
26+ 런타임 클래스는 컨테이너 런타임 설정을 선택하는 기능이다.
27+ 이 컨테이너 런타임 설정은 파드의 컨테이너를 실행할 때에 이용한다 .
2228
23- ### 셋업
29+ ## 동기
2430
25- 초기 알파 특징이므로, 런타임 클래스 특징을 사용하기 위해서는 몇 가지 추가 셋업
26- 단계가 필요하다.
31+ 서로 다른 파드간에 런타임 클래스를 설정하여
32+ 성능대 보안의 균형을 유지할 수 있다.
33+ 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
34+ 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
35+ 그러면 몇가지 추가적인 오버헤드는 있지만
36+ 대체 런타임을 추가 분리하는 유익이 있다.
2737
28- 1 . 런타임 클래스 특징 게이트 활성화(apiservers 및 kubelets에 대해서, 버전 1.12+ 필요)
29- 2 . 런타임 클래스 CRD 설치
30- 3 . CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
31- 4 . 상응하는 런타임 클래스 리소스 생성
38+ 또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
39+ 여러 파드를 실행할 수 있다.
3240
33- #### 1. 런타임 클래스 특징 게이트 활성화
41+ ### 셋업
3442
43+ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
3544특징 게이트 활성화에 대한 설명은 [ 특징 게이트] ( /docs/reference/command-line-tools-reference/feature-gates/ ) 를
36- 참고한다. ` RuntimeClass ` 특징 게이트는 apiservers _ 및_ kubelets에서 활성화되어야
37- 한다.
38-
39- #### 2. 런타임 클래스 CRD 설치
45+ 참고한다. ` RuntimeClass ` 특징 게이트는 apiservers _ 및_ kubelets에서 활성화되어야 한다.
4046
41- 런타임 클래스 [ CustomResourceDefinition ] [ ] (CRD)는 쿠버네티스 git 저장소의 애드온 디렉터리에서 찾을 수
42- 있다. [ kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml ] [ runtimeclass_crd ]
47+ 1 . CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
48+ 2 . 상응하는 런타임 클래스 리소스 생성
4349
44- ` kubectl apply -f runtimeclass_crd.yaml ` 을 통해서 해당 CRD를 설치한다.
50+ #### 1. CRI 구현을 노드에 설정
4551
46- [ CustomResourceDefinition ] : /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
47- [ runtimeclass_crd ] : https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/runtimeclass/runtimeclass_crd.yaml
48-
49-
50- #### 3. CRI 구현을 노드에 설정
51-
52- 런타임 클래스와 함께 선택할 설정은 CRI 구현에 의존적이다. 사용자의 CRI
53- 구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다. 이것은 알파
54- 특징이므로, 아직 모든 CRI가 다중 런타임 클래스를 지원하지는 않는다.
52+ 런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
53+ 사용자의 CRI 구현에 따른 설정 방법은
54+ 연관된 문서를 통해서 확인한다([ 아래] ( #cri-configuration ) ).
5555
5656{{< note >}}
5757런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정
58- (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
59- 설정)이라도
60- 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다([ 파드를 노드에
61- 할당하기] ( /docs/concepts/configuration/assign-pod-node/ ) 참고).
58+ (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
59+ 설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다
60+ ([ 파드를 노드에 할당하기] ( /docs/concepts/configuration/assign-pod-node/ ) 참고).
6261{{< /note >}}
6362
64- 해당 설정은 상응하는 ` RuntimeHandler ` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
63+ 해당 설정은 상응하는 ` handler ` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
6564런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + ` - ` 와 ` . ` 문자)을 가져야 한다.
6665
67- #### 4 . 상응하는 런타임 클래스 리소스 생성
66+ #### 2 . 상응하는 런타임 클래스 리소스 생성
6867
69- 3단계에서 셋업 한 설정은 연관된 ` RuntimeHandler ` 이름을 가져야 하며, 이를 통해서
70- 설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 ` "" ` 핸들러)에 대해서,
71- 상응하는 런타임 클래스 오브젝트를 생성한다.
68+ 1단계에서 셋업 한 설정은 연관된 ` handler ` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다.
69+ 각 런타임 핸들러(그리고 선택적으로 비어있는 ` "" ` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다.
7270
7371현재 런타임 클래스 리소스는 런타임 클래스 이름(` metadata.name ` )과 런타임 핸들러
74- (` spec.runtimeHandler ` )로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
72+ (` handler ` )로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
7573
7674``` yaml
77- apiVersion : node.k8s.io/v1alpha1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
75+ apiVersion : node.k8s.io/v1beta1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
7876kind : RuntimeClass
7977metadata :
8078 name : myclass # 런타임 클래스는 해당 이름을 통해서 참조됨
8179 # 런타임 클래스는 네임스페이스가 없는 리소스임
82- spec :
83- runtimeHandler : myconfiguration # 상응하는 CRI 설정의 이름임
80+ handler : myconfiguration # 상응하는 CRI 설정의 이름임
8481` ` `
8582
86-
8783{{< note >}}
8884런타임 클래스 쓰기 작업(create/update/patch/delete)은
89- 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한
90- 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
85+ 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
86+ 더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
9187{{< /note >}}
9288
9389### 사용
9490
95- 클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
91+ 클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
9692` runtimeClassName`를 명시한다. 예를 들면 다음과 같다.
9793
9894` ` ` yaml
@@ -105,12 +101,75 @@ spec:
105101 # ...
106102` ` `
107103
108- 이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된
109- 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
110- ` Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계- phase)로 들어간다. 에러
111- 메시지를 위해서는 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
104+ 이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
105+ 만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
106+ ` Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod- phase)로 들어간다.
107+ 에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
112108확인한다.
113109
114- 만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용될 것이다. 기본 런타임 핸들러는 런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
110+ 만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며,
111+ 런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
112+
113+ # ## CRI 구성 {#cri-configuration}
114+
115+ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다.
116+
117+ # ### dockershim
118+
119+ 쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.
120+
121+ # ### [containerd](https://containerd.io/)
122+
123+ 런타임 핸들러는 containerd의 구성 파일인 `/etc/containerd/config.toml` 통해 설정한다.
124+ 유효한 핸들러는 runtimes 단락 아래에서 설정한다.
125+
126+ ```
127+ [ plugins.cri.containerd.runtimes.${HANDLER_NAME}]
128+ ```
129+
130+ 더 자세한 containerd의 구성 문서를 살펴본다.
131+ https://github.com/containerd/cri/blob/master/docs/config.md
132+
133+ #### [cri-o](https://cri-o.io/)
134+
135+ 런타임 핸들러는 cri-o의 구성파일인 `/etc/crio/crio.conf`을 통해 설정한다.
136+ [crio.runtime 테이블](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) 아래에
137+ 유효한 핸들러를 설정한다.
138+
139+ ```
140+ [ crio.runtime.runtimes.${HANDLER_NAME}]
141+ runtime_path = "${PATH_TO_BINARY}"
142+ ```
143+
144+ 더 자세한 cri-o의 구성 문서를 살펴본다.
145+ https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
146+
147+
148+ ### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta}
149+
150+ 런타임 클래스 베타 기능은 다음의 변화를 포함한다.
151+
152+ - `node.k8s.io` API 그룹과 `runtimeclasses.node.k8s.io` 리소스는 CustomResourceDefinition에서
153+ 내장 API로 이전되었다.
154+ - 런타임 클래스 정의에서 `spec`을 직접 사용할 수 있다.
155+ (즉, 더 이상 RuntimeClassSpec는 없다).
156+ - `runtimeHandler` 필드는 `handler`로 이름이 바뀌었다.
157+ - `handler` 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 `runtimeHandler` 필드가
158+ 필요하다는 의미이다.
159+ - `handler` 필드는 반드시 올바른 DNS 레이블([RFC 1123](https://tools.ietf.org/html/rfc1123))으로,
160+ 이는 더 이상 `.` 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는
161+ 다음의 정규 표현식을 따른다. `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`.
162+
163+ **작업 필요** 다음 작업은 알파 버전의 런타임 기능을
164+ 베타 버전으로 업그레이드하기 위해 진행되어야 한다.
165+
166+ - 런타임 클래스 리소스는 v1.14로 업그레이드 *후에* 반드시 재생성되어야 하고,
167+ `runtimeclasses.node.k8s.io` CRD는 다음과 같이 수동으로 지워야 한다.
168+ ```
169+ kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
170+ ```
171+ - 지정되지 않았거나 비어 있는 `runtimeHandler` 이거나 핸들러 내에 `.` 캐릭터를 사용한 알파 런타임 클래스는
172+ 더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
173+ (위를 참조).
115174
116175{{% /capture %}}
0 commit comments