Sixth Korean l10n work for release 1.18
- Update outdated files in dev-1.18-ko.6 partly (#21714) - Translate StorageClass to Korean word (#21805) - Translate StatefulSet to Korean word in pods.md (#21794) - Translate tasks/run-application/delete-stateful-set/ in Korean (#21686) - Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801) - update outdated docs (#21940) - Modify spacing term StatefulSet in Korean (#21871) - Translate /tasks/administer-cluster/coredns in Korean (#21876) - Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975) - Translation error correction in /concepts/containers/runtime-class.md (#21868) - Translate tasks/tls/certificate-rotation/ in Korean (#21838) - Translate /tasks/configure-pod-container/static-pod in Korean (#21798) - Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911) - Fix English bugs in Korean documentation (#21994) - Update outdated dev-1.18-ko.6 partly (#22067) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com> Co-authored-by: Dajin Gwon <d.gweon@samsung.com> Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com> Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
@@ -56,6 +56,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
|
||||
|
||||
|
||||
* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
|
||||
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기.
|
||||
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
실제 경험 얻기.
|
||||
|
||||
|
||||
|
||||
@@ -63,6 +63,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
|
||||
- Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용
|
||||
- IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함
|
||||
- Azure 컨테이너 레지스트리(ACR) 사용
|
||||
- IAM 역할과 정책을 사용하여 ACR 저장소에 접근을 제어함
|
||||
- IBM 클라우드 컨테이너 레지스트리 사용
|
||||
- IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여
|
||||
- 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
|
||||
@@ -127,13 +128,19 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
|
||||
- `aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com`
|
||||
|
||||
### Azure 컨테이너 레지스트리(ACR) 사용
|
||||
[Azure 컨테이너 레지스트리](https://azure.microsoft.com/en-us/services/container-registry/)를 사용하는 경우
|
||||
관리자 역할의 사용자나 서비스 주체(principal) 중 하나를 사용하여 인증할 수 있다.
|
||||
쿠버네티스는 Azure 쿠버네티스 서비스(AKS)를 사용할 때
|
||||
[Azure 컨테이너 레지스트리(ACR)](https://azure.microsoft.com/ko-kr/services/container-registry/)를
|
||||
기본적으로 지원한다.
|
||||
|
||||
AKS 클러스터 서비스 주체(principal)는 ACR 인스턴스에서 `ArcPull` 권한이 있어야 한다. 구성에 대한
|
||||
지침은 [Azure 쿠버네티스 서비스에서 Azure 컨테이너 레지스트리로 인증](https://docs.microsoft.com/ko-kr/azure/aks/cluster-container-registry-integration)을 참조한다. 그런 다음, 전체 ACR 이미지 이름(예: `my_registry.azurecr.io/image:tag`)을 사용한다.
|
||||
|
||||
ACR 관리자 또는 서비스 주체를 사용해서 인증할 수도 있다.
|
||||
어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은
|
||||
[azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다.
|
||||
|
||||
우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는
|
||||
[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다.
|
||||
[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/ko-kr/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다.
|
||||
|
||||
컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다.
|
||||
|
||||
@@ -367,4 +374,3 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
|
||||
다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
|
||||
Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다.
|
||||
|
||||
|
||||
|
||||
@@ -31,7 +31,6 @@ weight: 10
|
||||
애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든
|
||||
새로운 이미지를 통해 컨테이너를 다시 생성해야 한다.
|
||||
|
||||
|
||||
## 컨테이너 런타임
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 런타임 클래스
|
||||
title: 런타임클래스(RuntimeClass)
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
@@ -8,7 +8,7 @@ weight: 20
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
|
||||
이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
|
||||
|
||||
런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
|
||||
구성은 파드의 컨테이너를 실행하는데 사용된다.
|
||||
@@ -20,69 +20,69 @@ weight: 20
|
||||
|
||||
## 동기
|
||||
|
||||
서로 다른 파드간에 런타임 클래스를 설정하여
|
||||
서로 다른 파드간에 런타임클래스를 설정하여
|
||||
성능대 보안의 균형을 유지할 수 있다.
|
||||
예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
|
||||
하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
|
||||
그러면 몇가지 추가적인 오버헤드는 있지만
|
||||
대체 런타임을 추가 분리하는 유익이 있다.
|
||||
|
||||
또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
|
||||
또한 런타임클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
|
||||
여러 파드를 실행할 수 있다.
|
||||
|
||||
## 셋업
|
||||
|
||||
RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
|
||||
특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.
|
||||
런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다.
|
||||
기능 게이트 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.
|
||||
|
||||
1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
|
||||
2. 상응하는 런타임 클래스 리소스 생성
|
||||
2. 상응하는 런타임클래스 리소스 생성
|
||||
|
||||
### 1. CRI 구현을 노드에 설정
|
||||
|
||||
런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
|
||||
런타임클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
|
||||
사용자의 CRI 구현에 따른 설정 방법은
|
||||
연관된 문서를 통해서 확인한다([아래](#cri-configuration)).
|
||||
|
||||
{{< note >}}
|
||||
런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
|
||||
런타임클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
|
||||
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다.
|
||||
이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
|
||||
해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임클래스에 의해서 참조된다.
|
||||
런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다.
|
||||
|
||||
### 2. 상응하는 런타임 클래스 리소스 생성
|
||||
### 2. 상응하는 런타임클래스 리소스 생성
|
||||
|
||||
1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다.
|
||||
각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다.
|
||||
각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임클래스 오브젝트를 생성한다.
|
||||
|
||||
현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러
|
||||
현재 런타임클래스 리소스는 런타임클래스 이름(`metadata.name`)과 런타임 핸들러
|
||||
(`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1beta1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
|
||||
apiVersion: node.k8s.io/v1beta1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: myclass # 런타임 클래스는 해당 이름을 통해서 참조됨
|
||||
# 런타임 클래스는 네임스페이스가 없는 리소스임
|
||||
name: myclass # 런타임클래스는 해당 이름을 통해서 참조됨
|
||||
# 런타임클래스는 네임스페이스가 없는 리소스임
|
||||
handler: myconfiguration # 상응하는 CRI 설정의 이름임
|
||||
```
|
||||
|
||||
런타임 클래스 오브젝트의 이름은 유효한
|
||||
런타임클래스 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)어이야 한다.
|
||||
|
||||
{{< note >}}
|
||||
런타임 클래스 쓰기 작업(create/update/patch/delete)은
|
||||
런타임클래스 쓰기 작업(create/update/patch/delete)은
|
||||
클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
|
||||
더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 사용
|
||||
|
||||
클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
|
||||
클러스터를 위해서 런타임클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
|
||||
`runtimeClassName`를 명시한다. 예를 들면 다음과 같다.
|
||||
|
||||
```yaml
|
||||
@@ -95,14 +95,14 @@ spec:
|
||||
# ...
|
||||
```
|
||||
|
||||
이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
|
||||
만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
|
||||
이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
|
||||
만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
|
||||
`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다.
|
||||
에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
|
||||
확인한다.
|
||||
|
||||
만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며,
|
||||
런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
|
||||
런타임클래스 기능이 비활성화되었을 때와 동일하게 동작한다.
|
||||
|
||||
### CRI 구성 {#cri-configuration}
|
||||
|
||||
@@ -143,24 +143,26 @@ https://github.com/containerd/cri/blob/master/docs/config.md
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다.
|
||||
이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다.
|
||||
이 스케줄링 기능을 사용하려면, [런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다.
|
||||
쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터
|
||||
지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는
|
||||
노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면,
|
||||
[런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본값)해야 한다.
|
||||
|
||||
파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
|
||||
파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
|
||||
해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
|
||||
런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로
|
||||
각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다.
|
||||
각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우,
|
||||
파드는 거부된다.
|
||||
|
||||
지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면,
|
||||
`tolerations`를 런타임 클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시
|
||||
지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면,
|
||||
`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시
|
||||
해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된
|
||||
노드의 합집합을 취한다.
|
||||
|
||||
노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면
|
||||
[노드에 파드 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 참고한다.
|
||||
|
||||
[런타임 클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
|
||||
[런타임클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
|
||||
|
||||
### 파드 오버헤드
|
||||
|
||||
@@ -171,7 +173,6 @@ https://github.com/containerd/cri/blob/master/docs/config.md
|
||||
PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)
|
||||
|
||||
|
||||
파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
|
||||
해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
|
||||
쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.
|
||||
@@ -180,8 +181,8 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/c
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
- [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
|
||||
- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user