June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
d58e8f1563
commit
cd20abd2eb
@@ -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에서 활성화되어야
|
||||
한다.
|
||||
참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.
|
||||
|
||||
#### 2. 런타임 클래스 CRD 설치
|
||||
1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
|
||||
2. 상응하는 런타임 클래스 리소스 생성
|
||||
|
||||
런타임 클래스 [CustomResourceDefinition][] (CRD)는 쿠버네티스 git 저장소의 애드온 디렉터리에서 찾을 수
|
||||
있다. [kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml][runtimeclass_crd]
|
||||
#### 1. CRI 구현을 노드에 설정
|
||||
|
||||
`kubectl apply -f runtimeclass_crd.yaml`을 통해서 해당 CRD를 설치한다.
|
||||
|
||||
[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" >}}
|
||||
|
||||
## 애드온
|
||||
|
||||
|
||||
@@ -15,8 +15,7 @@ API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/referen
|
||||
|
||||
API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다.
|
||||
|
||||
쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다.
|
||||
[kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
|
||||
쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
|
||||
|
||||
쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다.
|
||||
|
||||
@@ -24,7 +23,6 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -36,9 +34,9 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
|
||||
|
||||
## OpenAPI 및 Swagger 정의
|
||||
|
||||
완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
|
||||
완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
|
||||
|
||||
쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
|
||||
쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
|
||||
요청 형식은 HTTP 헤더에 명시해서 설정할 수 있다.
|
||||
|
||||
헤더 | 가능한 값
|
||||
@@ -46,7 +44,8 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
|
||||
Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (기본 content-type은 `*/*`에 대해 `application/json`이거나 이 헤더를 전달하지 않음)
|
||||
Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨)
|
||||
|
||||
1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다. 이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거될 예정이다.
|
||||
1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다.
|
||||
이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거됬다.
|
||||
|
||||
**OpenAPI 규격을 조회하는 예제**
|
||||
|
||||
@@ -58,21 +57,25 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
|
||||
|
||||
쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다.
|
||||
|
||||
1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/)
|
||||
쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다.
|
||||
1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/)
|
||||
쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다.
|
||||
이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거될 예정이다.
|
||||
|
||||
## API 버전 규칙
|
||||
|
||||
필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나
|
||||
`/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다.
|
||||
필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
|
||||
쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이
|
||||
각각 다른 API 경로에서 복수의 API 버전을 지원한다.
|
||||
|
||||
리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다.
|
||||
|
||||
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자.
|
||||
[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는
|
||||
API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
|
||||
|
||||
API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
|
||||
API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다.
|
||||
각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
|
||||
|
||||
- 알파(Alpha) 수준:
|
||||
- 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
|
||||
@@ -87,7 +90,8 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르
|
||||
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우,
|
||||
다음 버전으로 이관할 수 있는 가이드를 제공할 것이다.
|
||||
이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
|
||||
- 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
|
||||
- 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다.
|
||||
복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
|
||||
- **베타 기능을 사용하고 피드백을 주기를 바란다! 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.**
|
||||
- 안정화(stable) 수준:
|
||||
- 버전 이름이 `vX`이고 `X` 는 정수다.
|
||||
@@ -95,8 +99,7 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르
|
||||
|
||||
## API 그룹
|
||||
|
||||
쿠버네티스 API를 보다 쉽게 확장하기 위해서,
|
||||
[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
|
||||
쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
|
||||
API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
|
||||
|
||||
현재 다양한 API 그룹이 사용되고 있다.
|
||||
@@ -111,8 +114,9 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명
|
||||
|
||||
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)은 아주 기본적인
|
||||
CRUD 요구를 갖는 사용자에게 적합하다.
|
||||
1. 쿠버네티스 API 의미론의 전체 셋을 가지고 사용자만의 apiserver를 만들고자하는 사용자는 [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록
|
||||
만들 수 있다.
|
||||
1. 쿠버네티스 API 의미론의 전체 셋을 가지고, 사용자만의 apiserver를 만들고자하는 사용자는
|
||||
[aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록
|
||||
만들 수 있다.
|
||||
|
||||
|
||||
## API 그룹 활성화 시키기
|
||||
@@ -122,7 +126,7 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명
|
||||
`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을
|
||||
설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
|
||||
|
||||
중요: 그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서
|
||||
중요: 그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서
|
||||
`--runtime-config` 변경을 반영시켜야 한다.
|
||||
|
||||
## 그룹 내 리소스 활성화 시키기
|
||||
|
||||
@@ -69,8 +69,29 @@ _어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두
|
||||
|
||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.
|
||||
|
||||
다음은 `imageregistry: https://hub.docker.com/` 어노테이션이 있는 파드의 구성 파일 예시이다.
|
||||
|
||||
```yaml
|
||||
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: annotations-demo
|
||||
annotations:
|
||||
imageregistry: "https://hub.docker.com/"
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -15,10 +15,9 @@ card:
|
||||
{{% capture body %}}
|
||||
## 파드에 대해 이해하기
|
||||
|
||||
*파드* 는 쿠버네티스의 기본 구성 요소이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다.
|
||||
*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다.
|
||||
|
||||
파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다.
|
||||
파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.
|
||||
파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.
|
||||
|
||||
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다.
|
||||
|
||||
@@ -27,25 +26,19 @@ card:
|
||||
|
||||
* **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다.
|
||||
* **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.
|
||||
|
||||
|
||||
[쿠버네티스 블로그](http://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다.
|
||||
|
||||
* [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
|
||||
|
||||
각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
|
||||
|
||||
|
||||
|
||||
## 어떻게 파드가 다중 컨테이너를 관리하는가
|
||||
|
||||
파드는 결합도가 있는 단위의 서비스를 형성하는 다중 협력 프로세스(컨테이너)를 지원하도록 디자인 되었다. 파드 내부의 컨테이너는 자동으로 동일한 물리적 또는 가상의 머신의 클러스터에 함께 배치되고 스케쥴된다. 컨테이너는 리소스와 의존성 공유, 다른 컨테이너와의 통신 그리고 언제,어떻게 조절하는지를 공유할 수 있다.
|
||||
|
||||
단일 파드 내부에서 함께 배치되고 관리되는 컨테이너 그룹은 상대적으로 심화된 사용 예시임에 유의하자. 컨테이너가 강하게 결합된 특별한 인스턴스의 경우에만 이 패턴을 사용하는게 좋다. 예를 들어, 공유 볼륨 내부 파일의 웹 서버 역할을 하는 컨테이너와 원격 소스로부터 그 파일들을 업데이트하는 분리된 "사이드카" 컨테이너가 있는 경우 아래 다이어그램의 모습일 것이다.
|
||||
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
|
||||
|
||||
몇몇의 파드는 {{< glossary_tooltip text="init containers" term_id="init-container" >}} 뿐만 아니라 {{< glossary_tooltip text="app containers" term_id="app-container" >}} 도 가진다. 초기 컨테이너는 앱 컨테이너 시작이 완료되기 전에 동작한다.
|
||||
@@ -62,18 +55,17 @@ card:
|
||||
|
||||
## 파드 작업
|
||||
|
||||
직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다.
|
||||
직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다.
|
||||
|
||||
{{< note >}}
|
||||
파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다.
|
||||
{{< /note >}}
|
||||
|
||||
파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다.
|
||||
쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
|
||||
파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
|
||||
|
||||
### 파드와 컨트롤러
|
||||
|
||||
컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다.
|
||||
컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다.
|
||||
|
||||
한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시.
|
||||
|
||||
@@ -84,7 +76,11 @@ card:
|
||||
일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다.
|
||||
|
||||
## 파드 템플릿
|
||||
파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/), [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. 컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다.
|
||||
|
||||
파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
|
||||
[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/),
|
||||
[데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
|
||||
컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다.
|
||||
아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다.
|
||||
|
||||
```yaml
|
||||
@@ -98,7 +94,7 @@ spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
|
||||
command: ['sh', '-c', 'echo 안녕하세요 쿠버네티스! && sleep 3600']
|
||||
```
|
||||
|
||||
모든 레플리카의 현재 원하는 상태를 지정하는 대신, 파드 템플릿은 쿠키 틀과 같다. 쿠키가 한 번 잘리면, 그 쿠키는 쿠키 틀과 더이상 관련이 없다. 양자 얽힘이 없는 것이다. 그 이후 템플릿을 변경하거나 새로운 템플릿으로 바꿔도 이미 만들어진 파드에는 직접적인 영향이 없다. 마찬가지로, 레플리케이션 컨트롤러에 의해 만들어진 파드는 아마 그 이후 직접 업데이트될 수 있다. 이것은 모든 컨테이너가 속해있는 파드에서 현재 원하는 상태를 명시하는 것과 의도적으로 대비가 된다. 이러한 접근은 시스템의 의미를 철저히 단순화하고 유연성을 증가시킨다.
|
||||
@@ -106,7 +102,8 @@ spec:
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [파드](/docs/concepts/workloads/pods/pod/)의 다른 동작들을 더 배워보자.
|
||||
* [파드](/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
|
||||
* 파드의 동작에 대해 더 알아보자.
|
||||
* [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -5,8 +5,8 @@ weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에
|
||||
특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
|
||||
이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에
|
||||
특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
|
||||
시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -14,12 +14,12 @@ weight: 50
|
||||
{{% capture body %}}
|
||||
## 파드 프리셋 이해하기
|
||||
|
||||
`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
|
||||
주입하기 위한 API 리소스이다.
|
||||
주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
|
||||
`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
|
||||
주입하기 위한 API 리소스이다.
|
||||
주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
|
||||
[레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다.
|
||||
|
||||
파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
|
||||
파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
|
||||
제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
|
||||
템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
|
||||
|
||||
@@ -28,52 +28,54 @@ weight: 50
|
||||
## 어떻게 동작하는가
|
||||
|
||||
쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면,
|
||||
파드 프리셋을 파드 생성 요청에 적용한다.
|
||||
파드 프리셋을 파드 생성 요청에 적용한다.
|
||||
파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다.
|
||||
|
||||
1. 사용 가능한 모든 `PodPresets`을 검색한다.
|
||||
1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는
|
||||
것이 있는지 확인한다.
|
||||
1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에
|
||||
1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는
|
||||
것이 있는지 확인한다.
|
||||
1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에
|
||||
병합되도록 시도한다.
|
||||
1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로
|
||||
부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다.
|
||||
1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서
|
||||
1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로
|
||||
부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다.
|
||||
1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서
|
||||
수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다.
|
||||
`podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`.
|
||||
|
||||
각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의
|
||||
파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을
|
||||
때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의
|
||||
변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
|
||||
각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의
|
||||
파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을
|
||||
때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의
|
||||
변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
|
||||
수정한다. `Volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.
|
||||
|
||||
{{< note >}}
|
||||
파드 프리셋은 적절한 경우 파드 스펙의 `.spec.containers` 필드를
|
||||
수정할 수도 있다. 파드 프리셋으로부터의 리소스 정의 *없음* 은 `initContainers`
|
||||
필드에 적용될 것이다.
|
||||
파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다.
|
||||
- `.spec.containers` 필드
|
||||
- `initContainers` 필드(쿠버네티스 버전 1.14.0 이후에서 필요)
|
||||
{{< /note >}}
|
||||
|
||||
### 특정 파드의 파드 프리셋 비활성화하기
|
||||
|
||||
어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
|
||||
있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에
|
||||
어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
|
||||
있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에
|
||||
추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.
|
||||
|
||||
## 파드 프리셋 활성화하기
|
||||
|
||||
클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.
|
||||
|
||||
1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
|
||||
예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
|
||||
minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
|
||||
1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
|
||||
예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
|
||||
minikube에서는 클러스터가 시작할 때
|
||||
`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
|
||||
플래그를 추가한다.
|
||||
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
|
||||
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다.
|
||||
이것을 이루는 방법 중 하나는
|
||||
API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
|
||||
minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`
|
||||
minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`
|
||||
플래그를 추가한다.
|
||||
1. 사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여
|
||||
파드 프리셋을 정의하였다.
|
||||
1. 사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여
|
||||
파드 프리셋을 정의하였다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user