Fifth Korean l10n work for release-1.13. (#12420)
* ko-trans: glossary/kube-scheduler.md (#12269) * ko-trans: Update outdated files partly in dev-1.13-ko.5 (#12246) * ko-trans: Update outdated files partly in dev-1.13-ko.5 (#12267) * Update outdated in tutorials/kubernetes-basics/ for dev-1.13-ko.5 (#12272) * ko/examples/application/deployment.yaml (#12293) * ko-trans: add tutorials/hello-minikube.md #11532 (#12273) * Translate concepts/containers/container-environment-variables in Korean (#12382) * ko: Tutorial compoent rearrange (#12400) * Translate content/ko/docs/concepts/architecture/master-node-communication in Korean #11963 (#12315) * Translate concepts/workloads/pods/podpreset in Korean (#12308) * Translate concepts/workloads/pods/init-containers in Korean (#12298) * ko-trans: add setup/minikube.md #11531 (#12274) * ko/docs/setup/cluster-large.md (#12370) Co-authored-by: Seokho <shsongist@gmail.com> Co-authored-by: Kim Young Dae <38598117+zer0big@users.noreply.github.com> Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-authored-by: Yoon <learder@gmail.com> Co-authored-by: Jmnote <opcore@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com>
This commit is contained in:
Claudia J.Kang
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
a7792a6ae8
commit
3a0154db4c
@@ -0,0 +1,88 @@
|
||||
---
|
||||
title: 마스터-노드 커뮤니케이션
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의 커뮤니케이션 경로를 나열해 본다.
|
||||
그 목적은 사용자로 하여금 untrusted network(신뢰할 수 없는 네트워크) 상에서
|
||||
(또는 클라우드 제공사업자 환경에서 완전히 공인 IP로) 동작될 수 있는
|
||||
그러한 클러스터의 네트워크 구성을 강화하기 위해 사용자의 설치를 커스터마이즈 할 수 있도록 해주기 위함이다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 클러스터에서 마스터로
|
||||
|
||||
클러스터에서 마스터로의 모든 커뮤니케이션 경로는 apiserver에서 끝난다
|
||||
(어떤 다른 마스터 컴포넌트도 원격 서비스를 노출하기 위해 설계되지 않는다).
|
||||
전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형태가
|
||||
사용가능토록 하여 안전한 HTTPS 포트(443)를 통해 원격 연결에 대해 서비스 리슨하도록 구성된다.
|
||||
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
|
||||
또는 [서비스 계정 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이
|
||||
허용된 경우에는 하나 또는 그 이상의 [인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.
|
||||
|
||||
노드는 유효한 클라이언트 자격증명과 함께 apiserver에 안전하게 접속할 수 있는
|
||||
그런 클러스터용 공인 루트 인증서를 가지고 제공되어야 한다.
|
||||
예를 들어, 기본 GKE 배포의 경우, kubelet에 제공되는 클라이언트 자격증명은
|
||||
클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에 대한 자동화 프로비저닝에 대해서는
|
||||
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
|
||||
|
||||
apiserver에 접속하려는 파드는 서비스 계정에 영향력을 발휘함으로써 안전하게
|
||||
그리 행할 수 있으며 따라서 쿠버네티스는 인스턴스화 될 때 공인 루트 인증서와
|
||||
유효한 베어러 토큰을 파드 속으로 자동 주입할 수 있게 된다.
|
||||
(모든 네임스페이스 내) `kubernetes` 서비스는 apiserver 상의 HTTPS 엔드포인트로
|
||||
(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를 가지고 구성된다.
|
||||
|
||||
마스터 컴포넌트는 또한 신뢰할 수 있는 포트를 통해 클러스터 apiserver와 소통한다.
|
||||
|
||||
결과적으로, 클러스터 (노드 그리고 노드에서 동작하는 파드)에서
|
||||
마스터로의 기본 동작 모드는 기본적으로 안전하며
|
||||
신뢰할 수 없는그리고/또는 공인 네트워크 상에서 동작할 수 있다.
|
||||
|
||||
## 마스터에서 클러스터로
|
||||
|
||||
마스터(apiserver)에서 클러스터로의 두 가지 주된 커뮤니케이션 경로가 존재한다.
|
||||
첫 번째는 클러스터 내 각 노드를 동작시키는 apiserver에서 kubelet 프로세스로의
|
||||
경로이다. 두 번째는 apiserver에서 apiserver의 프록시 기능을 통한 임의의 노드,
|
||||
파드 또는 서비스로의 경로이다.
|
||||
|
||||
### apiserver에서 kubelet으로
|
||||
|
||||
apiserver에서 kubelet으로의 연결은 다음을 위해 이용된다.
|
||||
|
||||
* 파드에 대한 로그 가져오기
|
||||
* 동작중인 파드에 (kubectl을 통해) 연관짓기
|
||||
* kubelet의 포트 포워딩 기능 제공하기
|
||||
|
||||
이 연결은 kubelet의 HTTPS 엔드포인트에서 끝난다. 기본적으로,
|
||||
apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
|
||||
이는 연결에 대한 중간자 공격을 당하게 하고, 신뢰할 수 없는
|
||||
그리고/또는 공인 네트워크에서 운영하기에는 **불안** 하게 만든다.
|
||||
|
||||
이 연결을 확인하려면, apiserver에 kubelet의 제공 인증서 확인을 위해 사용하는
|
||||
루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다
|
||||
|
||||
그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
|
||||
apiserver와 kubelet 사이에 [SSH 터널링](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)을
|
||||
사용한다.
|
||||
|
||||
마지막으로, kubelet API를 안전하게 하기 위해
|
||||
[Kubelet 인증 그리고/또는 인가](/docs/admin/kubelet-authentication-authorization/)가 활성화 되어야만 한다.
|
||||
|
||||
### apiserver에서 노드, 파드, 그리고 서비스로
|
||||
|
||||
apiserver에서 노드, 파드, 또는 서비스로의 연결은 보통 HTTP 연결을
|
||||
기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드, 파드, 또는 서비스 이름에
|
||||
`https:` 프리픽스를 붙임으로써 안전한 HTTPS 연결로 동작될 수 있지만,
|
||||
HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며
|
||||
클라이언트 자격증명 또한 제공하지 않는다.
|
||||
그래서 연결이 암호화될 동안, 어떠한 무결성도 제공되지 않을 것이다.
|
||||
이러한 연결들은 신뢰할 수 없는 그리고/또는 공인 네트워크에서 동작하기에
|
||||
**현재로서는 안전하지 않다**.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -171,24 +171,7 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
|
||||
|
||||
쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다. kubelet에 의해 구동된 모든 컨테이너를 포함하지만, [컨테이너 런타임](/docs/concepts/overview/components/#node-components)에 의해 직접 구동된 컨테이너 또는 컨테이너 외부에서 동작하는 임의의 프로세스는 해당되지 않는다.
|
||||
|
||||
파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, 플레이스홀더 파드를 생성할 수 있다. 다음 템플릿을 이용한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: resource-reserver
|
||||
spec:
|
||||
containers:
|
||||
- name: sleep-forever
|
||||
image: k8s.gcr.io/pause:0.8.0
|
||||
resources:
|
||||
requests:
|
||||
cpu: 100m
|
||||
memory: 100Mi
|
||||
```
|
||||
|
||||
`cpu`와 `memory`값을 확보하고자 하는 리소스의 양만큼 설정한다. 메니페스트 디렉토리 내 파일을 둔다(kubelet 의 `--config=DIR` 플래그). 리소스를 확보하고자 하는 위치에 각 kubelet 에 대해 이를 수행한다.
|
||||
파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다.
|
||||
|
||||
|
||||
## API 오브젝트
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "컨테이너"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: 컨테이너 환경 변수
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 컨테이너 환경에서 컨테이너에 가용한 리소스에 대해 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 컨테이너 환경
|
||||
|
||||
쿠버네티스 컨테이너 환경은 컨테이너에 몇 가지 중요한 리소스를 제공한다.
|
||||
|
||||
* 하나의 [이미지](/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템.
|
||||
* 컨테이너 자신에 대한 정보.
|
||||
* 클러스터 내의 다른 오브젝트에 대한 정보.
|
||||
|
||||
### 컨테이너 정보
|
||||
|
||||
컨테이너의 *호스트네임* 은 컨테이너가 동작 중인 파드의 이름과 같다.
|
||||
그것은 `hostname` 커맨드 또는 libc의
|
||||
[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html)
|
||||
함수 호출을 통해서 구할 수 있다.
|
||||
|
||||
파드 이름과 네임스페이스는
|
||||
[다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
|
||||
|
||||
Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
|
||||
파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.
|
||||
|
||||
### 클러스터 정보
|
||||
|
||||
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
|
||||
있다.
|
||||
이러한 환경 변수는 Docker 링크 구문과 일치한다.
|
||||
|
||||
*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
|
||||
다음의 형태로 변수가 정의된다.
|
||||
|
||||
```shell
|
||||
FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
|
||||
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
|
||||
```
|
||||
|
||||
서비스에 지정된 IP 주소가 있고 [DNS 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [컨테이너 라이프사이클 훅(hooks)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
|
||||
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -123,6 +123,6 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명
|
||||
데몬셋, 디플로이먼트, HorizontalPodAutoscaler, 인그레스, 잡 및 레플리카셋이 기본적으로 활성화되어 있다.
|
||||
다른 확장 리소스는 apiserver의 `--runtime-config`를 설정해서 활성화 시킬 수 있다.
|
||||
`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어 디플로이먼트와 인그레스를 비활성화 시키려면,
|
||||
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`와 같이 설정한다.
|
||||
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`와 같이 설정한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,323 @@
|
||||
---
|
||||
title: 초기화 컨테이너
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는
|
||||
앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는
|
||||
유틸리티 또는 설정 스크립트 등을 포함할 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
이 특징은 1.6에서 베타를 빠져나왔다. 초기화 컨테이너는 앱 `containers` 배열과 나란히
|
||||
파드 스펙에 명시될 수 있다. 베타 어노테이션의 값은 여전히 존중되며 파드 스펙 필드 값을 덮어쓴다.
|
||||
하지만, 베타 어노테이션은 1.6과 1.7에서 사용 중단(deprecated)되었다.
|
||||
1.8에서 어노테이션은 더는 지원되지 않으므로 파드 스펙 필드로 변환되어야 한다.
|
||||
|
||||
{{% capture body %}}
|
||||
## 초기화 컨테이너 이해하기
|
||||
|
||||
[파드](/ko/docs/concepts/workloads/pods/pod-overview/)는 앱들을 실행하는 다수의 컨테이너를
|
||||
포함할 수 있다. 또한, 파드는 앱 컨테이너 실행 전에 동작되는 하나 이상의
|
||||
초기화 컨테이너도 포함할 수 있다.
|
||||
|
||||
다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다.
|
||||
|
||||
* 초기화 컨테이너는 항상 완료를 목표로 실행된다.
|
||||
* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
|
||||
|
||||
만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
|
||||
반복적으로 재시작한다. 그러나, 만약 파드가 `restartPolicy`을 절대 하지 않음(Never)으로 설정한다면, 파드는 재시작되지 않는다.
|
||||
|
||||
컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 앱 `containers` 배열과 나란히
|
||||
`initContainers` 필드를
|
||||
[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
타입 오브젝트들의 JSON 배열로서 추가한다.
|
||||
초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를
|
||||
통해서 컨테이너 상태 배열로 반환된다 (`.status.containerStatuses`와
|
||||
유사하게).
|
||||
|
||||
### 일반적인 컨테이너와의 차이점
|
||||
|
||||
초기화 컨테이너는 앱 컨테이너의 리소스 상한, 볼륨, 보안 세팅을 포함한
|
||||
모든 필드와 특징을 지원한다. 그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은
|
||||
약간 다르게 처리된다. 이것에 대해서는 아래 [리소스](#리소스)에 문서화되어 있다. 또한, 초기화 컨테이너는
|
||||
준비성 프로브(readiness probe)를 지원하지 않는다. 왜냐하면 초기화 컨테이너는
|
||||
파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기
|
||||
때문이다.
|
||||
|
||||
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, 해당 초기화 컨테이너들은 순차적으로
|
||||
한 번에 하나씩 실행된다. 각 초기화 컨테이너들은 다음 초기화 컨테이너가 실행되기 전에 성공되어야 한다.
|
||||
모든 초기화 컨테이너들이 실행 완료되었을 때, 쿠버네티스는 파드를 초기화하고
|
||||
애플리케이션 컨테이너를 평소와 같이 실행한다.
|
||||
|
||||
## 초기화 컨테이너는 무엇을 위해서 사용될 수 있는가?
|
||||
|
||||
초기화 컨테이너는 앱 컨테이너와는 별도의 이미지를 가지고 있기 때문에, 시동(start-up)에
|
||||
관련된 코드에 몇 가지 이점을 가진다.
|
||||
|
||||
* 보안 상 앱 컨테이너 이미지에서는 바람직하지 않은 유틸리티를 포함하고
|
||||
실행시킬 수 있다.
|
||||
* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함한다.
|
||||
예를 들어, 셋업 중에 단지 `sed`, `awk`, `python`, 또는 `dig`와 같은 도구를 사용하기 위해서
|
||||
다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다.
|
||||
* 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서
|
||||
공동의 단일 앱 이미지 형태로 빌드될 필요가 없다.
|
||||
* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다.
|
||||
결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 시크릿에 접근 권한이 주어질 수 있다.
|
||||
* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱
|
||||
컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이
|
||||
충족될 때까지 앱 컨테이너가 시동되는 것을 막거나 지연시키는 간편한 방법을 제공한다.
|
||||
|
||||
### 예제
|
||||
초기화 컨테이너를 사용하는 방법에 대한 몇 가지 아이디어는 다음과 같다.
|
||||
|
||||
* 다음과 같은 셀 커맨드로, 서비스가 생성될 때까지 기다리기.
|
||||
|
||||
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
|
||||
|
||||
* 다음과 같은 커맨드로, 다운워드 API(Downward API)를 통한 원격 서버에 해당 파드를 등록하기.
|
||||
|
||||
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
|
||||
|
||||
* `sleep 60`와 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기.
|
||||
* git 저장소를 볼륨 안에 클론하기.
|
||||
* 설정 파일에 값을 지정하고 메인 앱 컨테이너를 위한 설정 파일을 동적으로 생성하기 위한 템플릿 도구를 실행하기.
|
||||
예를 들어, 설정에 POD_IP 값을 지정하고 메인 앱 설정 파일을 Jinja를 통해서 생성.
|
||||
|
||||
더 자세한 사용 예제는 [스테이트풀 셋 문서](/docs/concepts/workloads/controllers/statefulset/)
|
||||
과 [프로덕션 파드 가이드](/docs/tasks/configure-pod-container/configure-pod-initialization/)에서 확인한다.
|
||||
|
||||
### 사용되고 있는 초기화 컨테이너
|
||||
|
||||
쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다.
|
||||
첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이
|
||||
완료되면, 파드가 시작될 것이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
annotations:
|
||||
pod.beta.kubernetes.io/init-containers: '[
|
||||
{
|
||||
"name": "init-myservice",
|
||||
"image": "busybox",
|
||||
"command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
|
||||
},
|
||||
{
|
||||
"name": "init-mydb",
|
||||
"image": "busybox",
|
||||
"command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
|
||||
}
|
||||
]'
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
|
||||
```
|
||||
|
||||
쿠버네티스 1.6에는 새로운 구문이 있다. 다만, 예전 어노테이션 구문도 1.6과 1.7에서는 여전히 동작한다. 새로운 구문은
|
||||
1.8 또는 더 높은 버전에서 사용되어야 한다. 초기화에 대한 선언은 `spec`으로 옮겨졌다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
|
||||
initContainers:
|
||||
- name: init-myservice
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
|
||||
- name: init-mydb
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
|
||||
```
|
||||
|
||||
1.5 구문도 1.6에서 여전히 동작하지만, 1.6 구문 사용을 추천한다. 쿠버네티스 1.6에서는, 초기화 컨테이너가 API에서 필드로
|
||||
만들어졌었다. 베타 어노테이션은 1.6과 1.7에서 여전히 지원되지만, 1.8이나 더 높은 버전에서는 지원되지 않는다.
|
||||
|
||||
아래의 yaml file은 `mydb`와 `myservice` 서비스의 개요를 보여준다.
|
||||
|
||||
```yaml
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: myservice
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
---
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mydb
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9377
|
||||
```
|
||||
|
||||
다음 커맨드들을 이용하여 파드를 시작하거나 디버깅할 수 있다.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f myapp.yaml
|
||||
pod/myapp-pod created
|
||||
$ kubectl get -f myapp.yaml
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 0/1 Init:0/2 0 6m
|
||||
$ kubectl describe -f myapp.yaml
|
||||
Name: myapp-pod
|
||||
Namespace: default
|
||||
[...]
|
||||
Labels: app=myapp
|
||||
Status: Pending
|
||||
[...]
|
||||
Init Containers:
|
||||
init-myservice:
|
||||
[...]
|
||||
State: Running
|
||||
[...]
|
||||
init-mydb:
|
||||
[...]
|
||||
State: Waiting
|
||||
Reason: PodInitializing
|
||||
Ready: False
|
||||
[...]
|
||||
Containers:
|
||||
myapp-container:
|
||||
[...]
|
||||
State: Waiting
|
||||
Reason: PodInitializing
|
||||
Ready: False
|
||||
[...]
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201
|
||||
16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox"
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox"
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
|
||||
$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
|
||||
$ kubectl logs myapp-pod -c init-mydb # Inspect the second init container
|
||||
```
|
||||
|
||||
`mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고
|
||||
`myapp-pod`가 생성된 것을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f services.yaml
|
||||
service/myservice created
|
||||
service/mydb created
|
||||
$ kubectl get -f myapp.yaml
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 1/1 Running 0 9m
|
||||
```
|
||||
|
||||
이 예제는 매우 단순하지만 사용자만의 초기화 컨테이너를 생성하는데
|
||||
영감을 줄 것이다.
|
||||
|
||||
## 자세한 동작
|
||||
|
||||
파드 시동 시, 네트워크와 볼륨이 초기화되고 나면, 초기화 컨테이너가
|
||||
순서대로 시작된다. 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로
|
||||
종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이
|
||||
실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만,
|
||||
파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
|
||||
`restartPolicy`을 실패 시(OnFailure)로 사용한다.
|
||||
|
||||
파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는
|
||||
서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만
|
||||
`Initializing`이 참이 되는 조건을 가져야 한다.
|
||||
|
||||
만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는
|
||||
반드시 다시 실행된다.
|
||||
|
||||
초기화 컨테이너 스펙 변경은 컨테이너 이미지 필드에서만 한정적으로 가능하다.
|
||||
초기화 컨테이너 이미지 필드를 변경하는 것은 파드를 재시작하는 것과 같다.
|
||||
|
||||
초기화 컨테이너는 재시작되거나, 재시도, 또는 재실행 될 수 있기 때문에, 초기화 컨테이너
|
||||
코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는
|
||||
출력 파일이 이미 존재할 가능성에 대비해야 한다.
|
||||
|
||||
초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는
|
||||
`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
|
||||
구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다.
|
||||
|
||||
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
|
||||
파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를
|
||||
사용한다.
|
||||
|
||||
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
|
||||
컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다.
|
||||
|
||||
### 리소스
|
||||
|
||||
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
|
||||
다음의 규칙이 적용된다.
|
||||
|
||||
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
|
||||
높은 것은 *유효한 초기화 요청량/상한* 이다.
|
||||
* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
|
||||
* 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
|
||||
* 리소스에 대한 유효한 초기화 요청량/상한
|
||||
* 스케줄링은 유효한 요청/상한에 따라 이루어진다. 즉,
|
||||
초기화 컨테이너는 파드의 삶에서는 사용되지 않는 초기화를 위한 리소스를
|
||||
예약할 수 있다.
|
||||
* 파드의 *유효한 QoS 계층* 에서 QoS 계층은 초기화 컨테이너들과
|
||||
앱 컨테이너들의 QoS 계층과 같다.
|
||||
|
||||
쿼터 및 상한은 유효한 파드의 요청량 및 상한에 따라
|
||||
적용된다.
|
||||
|
||||
파드 레벨 cgroup은 유효한 파드 요청량 및 상한을 기반으로 한다. 이는 스케줄러와 같다.
|
||||
|
||||
### 파드 재시작 이유
|
||||
|
||||
파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수
|
||||
있다.
|
||||
|
||||
* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
|
||||
앱 컨테이너 이미지의 변경은 앱 컨테이너만 재시작시킨다.
|
||||
* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
|
||||
대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
|
||||
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는,
|
||||
동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
|
||||
때문에 유실되었다.
|
||||
|
||||
## 지원 및 호환성
|
||||
|
||||
Api서버 버전 1.6.0 또는 더 높은 버전으로 구성된 클러스터는 `.spec.initContainers`
|
||||
필드를 사용하여 초기화 컨테이너를 지원한다. 이전 버전들은 초기화 컨테이너를 알파 또는
|
||||
베타 어노테이션을 사용하여 지원한다. `.spec.initContainers` 필드는 알파 또는 베타
|
||||
어노테이션에도 반영되어 있어서 버전 1.3.0 이상의 Kubelet이 초기화 컨테이너를 실행할 수
|
||||
있도록 한다. 따라서, 버전 1.6 api서버가 기존에 생성된 파드들의 초기화 컨테이너 기능 손실 없이
|
||||
안전하게 버전 1.5.x로 롤백할 수 있게 한다.
|
||||
|
||||
Api서버 및 Kubelet 버전 1.8.0 이상에서는, 사용 중단된 어노테이션을
|
||||
`.spec.initContainers` 필드로 변환하는 것이 필요한, 알파 및 베타 어노테이션의 지원이 중단되었다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: 파드 프리셋
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에
|
||||
특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
|
||||
시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
## 파드 프리셋 이해하기
|
||||
|
||||
`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
|
||||
주입하기 위한 API 리소스이다.
|
||||
주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
|
||||
[레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다.
|
||||
|
||||
파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
|
||||
제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
|
||||
템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
|
||||
|
||||
그 배경에 대한 자세한 정보를 위해서는, [파드 프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 참고한다.
|
||||
|
||||
## 어떻게 동작하는가
|
||||
|
||||
쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면,
|
||||
파드 프리셋을 파드 생성 요청에 적용한다.
|
||||
파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다.
|
||||
|
||||
1. 사용 가능한 모든 `PodPresets`을 검색한다.
|
||||
1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는
|
||||
것이 있는지 확인한다.
|
||||
1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에
|
||||
병합되도록 시도한다.
|
||||
1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로
|
||||
부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다.
|
||||
1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서
|
||||
수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다.
|
||||
`podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`.
|
||||
|
||||
각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의
|
||||
파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을
|
||||
때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의
|
||||
변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
|
||||
수정한다. `Volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.
|
||||
|
||||
{{< note >}}
|
||||
파드 프리셋은 적절한 경우 파드 스펙의 `.spec.containers` 필드를
|
||||
수정할 수도 있다. 파드 프리셋으로부터의 리소스 정의 *없음* 은 `initContainers`
|
||||
필드에 적용될 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
### 특정 파드의 파드 프리셋 비활성화하기
|
||||
|
||||
어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
|
||||
있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에
|
||||
추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.
|
||||
|
||||
## 파드 프리셋 활성화하기
|
||||
|
||||
클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.
|
||||
|
||||
1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다. 예를
|
||||
들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을
|
||||
포함하여 완료할 수 있다.
|
||||
1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
|
||||
API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
|
||||
1. 사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여
|
||||
파드 프리셋을 정의하였다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [파드 프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user