Skip to content
Permalink
Browse files

First Korean l10n work for release-1.15 (#15356)

* Translate concepts/workloads/controllers/replicationcontroller in Korean (#15044)
* ko: Update outdated 1.14-ko.4 branch (#15099)
* Translate tasks/access-application-cluster/configure-access-multiple-clusters in Korean (#15121)
* Translate standardized glossary items in Tag Network into Korean (#15278)
* ko: Keep up with upstream - renamed files (#15030)

Co-Authored-By: Seokho <shsongist@gmail.com>
Co-Authored-By: lapee79 <lapee79@gmail.com>
Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
  • Loading branch information...
4 people authored and k8s-ci-robot committed Jul 10, 2019
1 parent bdf4e5f commit 113008ff6e3ce186d43bb16510e4fea2bc09936f
Showing with 1,776 additions and 824 deletions.
  1. +22 −10 content/ko/docs/concepts/architecture/nodes.md
  2. +1 −1 content/ko/docs/concepts/cluster-administration/federation.md
  3. +3 −13 content/ko/docs/concepts/containers/images.md
  4. +108 −49 content/ko/docs/concepts/containers/runtime-class.md
  5. +3 −5 content/ko/docs/concepts/overview/components.md
  6. +22 −18 content/ko/docs/concepts/overview/kubernetes-api.md
  7. +66 −185 content/ko/docs/concepts/overview/what-is-kubernetes.md
  8. +21 −0 content/ko/docs/concepts/overview/working-with-objects/annotations.md
  9. +17 −2 content/ko/docs/concepts/overview/working-with-objects/names.md
  10. +291 −0 content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
  11. +13 −16 content/ko/docs/concepts/workloads/pods/pod-overview.md
  12. +18 −0 content/ko/docs/reference/glossary/cni.md
  13. +3 −3 content/ko/docs/reference/glossary/container-env-variables.md
  14. +21 −0 content/ko/docs/reference/glossary/container-runtime.md
  15. +5 −2 content/ko/docs/reference/glossary/etcd.md
  16. +20 −0 content/ko/docs/reference/glossary/ingress.md
  17. +20 −0 content/ko/docs/reference/glossary/istio.md
  18. +5 −2 content/ko/docs/reference/glossary/kube-proxy.md
  19. +7 −5 content/ko/docs/reference/glossary/minikube.md
  20. +20 −0 content/ko/docs/reference/glossary/network-policy.md
  21. +5 −6 content/ko/docs/reference/glossary/node.md
  22. +4 −5 content/ko/docs/reference/glossary/service.md
  23. +4 −6 content/ko/docs/reference/kubectl/cheatsheet.md
  24. +4 −0 content/ko/docs/setup/best-practices/_index.md
  25. +10 −9 content/ko/docs/setup/{ → best-practices}/certificates.md
  26. +1 −1 content/ko/docs/setup/{ → best-practices}/cluster-large.md
  27. +1 −1 content/ko/docs/setup/{ → best-practices}/multiple-zones.md
  28. +1 −0 content/ko/docs/setup/{ → best-practices}/node-conformance.md
  29. +0 −4 content/ko/docs/setup/custom-cloud/_index.md
  30. +0 −5 content/ko/docs/setup/independent/_index.md
  31. +4 −0 content/ko/docs/setup/learning-environment/_index.md
  32. +197 −168 content/ko/docs/setup/{ → learning-environment}/minikube.md
  33. +4 −0 content/ko/docs/setup/production-environment/_index.md
  34. +4 −4 content/ko/docs/setup/{cri.md → production-environment/container-runtimes.md}
  35. +1 −1 content/ko/docs/setup/{ → production-environment}/on-premises-vm/_index.md
  36. +4 −0 content/ko/docs/setup/production-environment/tools/_index.md
  37. +2 −1 content/ko/docs/setup/{custom-cloud → production-environment/tools}/kops.md
  38. +1 −1 content/ko/docs/setup/{ → production-environment}/turnkey/_index.md
  39. +2 −2 content/ko/docs/setup/release/_index.md
  40. +0 −30 content/ko/docs/setup/release/building-from-source.md
  41. +8 −6 content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
  42. +379 −0 content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
  43. +113 −33 content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
  44. +120 −112 content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
  45. +82 −40 content/ko/docs/tasks/tools/install-minikube.md
  46. +2 −2 content/ko/docs/tutorials/clusters/apparmor.md
  47. +4 −10 content/ko/docs/tutorials/kubernetes-basics/_index.html
  48. +14 −18 content/ko/docs/tutorials/online-training/overview.md
  49. +21 −10 content/ko/docs/tutorials/services/source-ip.md
  50. +22 −22 content/ko/docs/tutorials/stateful-application/zookeeper.md
  51. +36 −16 content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
  52. +19 −0 content/ko/examples/controllers/replication.yaml
  53. +21 −0 content/ko/examples/service/load-balancer-example.yaml
@@ -17,14 +17,14 @@ weight: 10

노드의 상태는 다음의 정보를 포함한다.

* [주소](#주소)
* [컨디션](#컨디션)
* [용량](#용량)
* [정보](#정보)
* [주소](#addresses)
* [컨디션](#condition)
* [용량과 할당가능](#capacity)
* [정보](#info)

각 섹션은 아래 상세하게 기술되었다.

### 주소
### 주소 {#addresses}

이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다.

@@ -33,9 +33,9 @@ weight: 10
* InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.


### 컨디션
### 컨디션 {#condition}

`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다.
`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다.

| Node Condition | Description |
|----------------|-------------|
@@ -52,7 +52,11 @@ weight: 10
"conditions": [
{
"type": "Ready",
"status": "True"
"status": "True",
"reason": "KubeletReady",
"message": "kubelet is posting ready status",
"lastHeartbeatTime": "2019-06-05T18:38:35Z",
"lastTransitionTime": "2019-06-05T11:41:27Z"
}
]
```
@@ -70,11 +74,19 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
{{< /caution >}}

### 용량
### 용량과 할당가능 {#capacity}

노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.

### 정보
용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다.
할당가능 블록은 일반 파드에서 사용할 수 있는
노드의 리소스 양을 나타낸다.

노드에서
[컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을
배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자.

### 정보 {#info}

커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은 노드에 대한 일반적인 정보이다. 정보는 Kubelet에 의해 노드로부터 수집된다.

@@ -170,7 +170,7 @@ zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availabi

마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면,
더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은
클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/cluster-large/)에서 확인 가능하다.
클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/best-practices/cluster-large/)에서 확인 가능하다.

{{% /capture %}}

@@ -60,6 +60,8 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
- AWS EC2 컨테이너 레지스트리(ECR) 사용
- IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함
- ECR 로그인 자격 증명은 자동으로 갱신됨
- Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용
- IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함
- Azure 컨테이너 레지스트리(ACR) 사용
- IBM 클라우드 컨테이너 레지스트리 사용
- 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
@@ -275,19 +277,7 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.

```shell
cat <<EOF > ./kustomization.yaml
secretGenerator:
- name: myregistrykey
type: docker-registry
literals:
- docker-server=DOCKER_REGISTRY_SERVER
- docker-username=DOCKER_USER
- docker-password=DOCKER_PASSWORD
- docker-email=DOCKER_EMAIL
EOF
kubectl apply -k .
secret/myregistrykey-66h7d4d986 created
kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
```

만약 Docer 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고,
@@ -8,7 +8,13 @@ weight: 20

{{< feature-state for_k8s_version="v1.12" state="alpha" >}}

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

{{< warning >}}
런타임클래스는 v1.14 베타 업그레이드에서 *중대한* 변화를 포함한다.
런타임클래스를 v1.14 이전부터 사용하고 있었다면,
[런타임 클래스를 알파에서 베타로 업그레이드하기](#upgrading-runtimeclass-from-alpha-to-beta)를 확인한다.
{{< /warning >}}

{{% /capture %}}

@@ -17,82 +23,72 @@ weight: 20

## 런타임 클래스

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

### 셋업
## 동기

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

1. 런타임 클래스 특징 게이트 활성화(apiservers 및 kubelets에 대해서, 버전 1.12+ 필요)
2. 런타임 클래스 CRD 설치
3. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
4. 상응하는 런타임 클래스 리소스 생성
또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
여러 파드를 실행할 수 있다.

#### 1. 런타임 클래스 특징 게이트 활성화
### 셋업

RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야
한다.

#### 2. 런타임 클래스 CRD 설치
참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.

런타임 클래스 [CustomResourceDefinition][] (CRD)는 쿠버네티스 git 저장소의 애드온 디렉터리에서 찾을 수
있다. [kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml][runtimeclass_crd]
1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
2. 상응하는 런타임 클래스 리소스 생성

`kubectl apply -f runtimeclass_crd.yaml`을 통해서 해당 CRD를 설치한다.
#### 1. CRI 구현을 노드에 설정

[CustomResourceDefinition]: /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
[runtimeclass_crd]: https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/runtimeclass/runtimeclass_crd.yaml


#### 3. CRI 구현을 노드에 설정

런타임 클래스와 함께 선택할 설정은 CRI 구현에 의존적이다. 사용자의 CRI
구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다. 이것은 알파
특징이므로, 아직 모든 CRI가 다중 런타임 클래스를 지원하지는 않는다.
런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
사용자의 CRI 구현에 따른 설정 방법은
연관된 문서를 통해서 확인한다([아래](#cri-configuration)).

{{< note >}}
런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
설정)이라도
스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다([파드를 노드에
할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다
([파드를 노드에 할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
{{< /note >}}

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

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

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

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

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


{{< note >}}
런타임 클래스 쓰기 작업(create/update/patch/delete)은
클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한
개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
{{< /note >}}

### 사용

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

```yaml
@@ -105,12 +101,75 @@ spec:
# ...
```

이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된
런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다. 에러
메시지를 위해서는 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다.
에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
확인한다.

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

### CRI 구성 {#cri-configuration}

CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다.

#### dockershim

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

#### [containerd](https://containerd.io/)

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

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

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

#### [cri-o](https://cri-o.io/)

런타임 핸들러는 cri-o의 구성파일인 `/etc/crio/crio.conf`을 통해 설정한다.
[crio.runtime 테이블](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) 아래에
유효한 핸들러를 설정한다.

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

더 자세한 cri-o의 구성 문서를 살펴본다.
https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go


### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta}

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

- `node.k8s.io` API 그룹과 `runtimeclasses.node.k8s.io` 리소스는 CustomResourceDefinition에서
내장 API로 이전되었다.
- 런타임 클래스 정의에서 `spec`을 직접 사용할 수 있다.
(즉, 더 이상 RuntimeClassSpec는 없다).
- `runtimeHandler` 필드는 `handler`로 이름이 바뀌었다.
- `handler` 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 `runtimeHandler` 필드가
필요하다는 의미이다.
- `handler` 필드는 반드시 올바른 DNS 레이블([RFC 1123](https://tools.ietf.org/html/rfc1123))으로,
이는 더 이상 `.` 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는
다음의 정규 표현식을 따른다. `^[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` 이거나 핸들러 내에 `.` 캐릭터를 사용한 알파 런타임 클래스는
더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
(위를 참조).

{{% /capture %}}
@@ -16,7 +16,7 @@ card:
## 마스터 컴포넌트

마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.

마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
@@ -72,13 +72,11 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드

### kube-proxy

[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서
쿠버네티스 서비스 추상화가 가능하도록 해준다.
{{< glossary_definition term_id="kube-proxy" length="all" >}}

### 컨테이너 런타임

컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 런타임이다.
{{< glossary_definition term_id="container-runtime" length="all" >}}

## 애드온

0 comments on commit 113008f

Please sign in to comment.
You can’t perform that action at this time.