Seventh Korean l10n work for release-1.13 (#12981)
* ko-trans: Update outdated contents in ko7 branch (#12762) * ko: Update outdated files in dev-1.13-ko.7 (#12805) * ko: Translate docs/home/_index.md in Korean (#12829) * Translate scheduler-perf-tuning.md in Korean (#12782) * Translate concepts/overview/object-management-kubectl/overview in Korean (#12834) * Fix new line in Korean translation scheduler-perf-tuning.md (#12835) * ko: Translate tutorials/online-training/overview.md in Korean (#12854) * ko: Translate contribute/_index.md in Korean (#12850) * ko: Update localization guide about instruction-type content (#12877) Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-authored-by: Seokho <shsongist@gmail.com> Co-authored-by: Kim Young Dae <38598117+zer0big@users.noreply.github.com>
This commit is contained in:
Claudia J.Kang
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
08839f640f
commit
92faff9209
@@ -254,6 +254,7 @@ rules:
|
||||
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
|
||||
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
|
||||
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
|
||||
## 클러스터 관리
|
||||
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "구성"
|
||||
weight: 80
|
||||
---
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: 스케줄러 성능 튜닝
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.12" >}}
|
||||
|
||||
Kube-scheduler는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
|
||||
노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는
|
||||
클러스터의 노드를 파드에 "적합한(feasible)" 노드라고 한다. 스케줄러는
|
||||
파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를
|
||||
측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장
|
||||
높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 "바인딩"이라는 프로세스로
|
||||
API 서버에 해당 결정을 통지한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 점수를 측정할 노드의 비율
|
||||
|
||||
쿠버네티스 1.12 이전 버전에서, Kube-scheduler는 클러스터의 모든 노드에
|
||||
대한 적합성(feasibility)을 확인한 후에 적합한 노드들에 대해서 점수를 측정했다.
|
||||
쿠버네티스 1.12는 새로운 특징을 가지고 있으며, 이 특징은 스케줄러가 특정
|
||||
숫자의 적합한 노드를 찾은 이후에 추가적인 적합 노드를 찾는 것을 중단하게 한다.
|
||||
이것은 대규모 클러스터에서 스케줄러 성능을 향상시킨다. 해당 숫자는 클러스터
|
||||
크기에 대한 비율로 지정되며 `percentageOfNodesToScore` 구성 옵션으로
|
||||
제어된다. 값의 범위는 1과 100 사이여야 한다. 그 이외의 값은 100%로 간주한다.
|
||||
이 옵션의 기본 값은 50%이다. 클러스터 관리자는 이 값은 스케줄러 구성에 다른
|
||||
값을 지정함으로써 기본 값을 변경할 수 있다. 그러나, 이 값을 변경할 필요는 없을 것이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: componentconfig/v1alpha1
|
||||
kind: KubeSchedulerConfiguration
|
||||
algorithmSource:
|
||||
provider: DefaultProvider
|
||||
|
||||
...
|
||||
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
클러스터에서 적합한 노드가 0 또는 50 미만인 경우,
|
||||
스케줄러는 여전히 모든 노드를 확인한다. 이는 스케줄러가 탐색을 조기
|
||||
중단하기에는 적합한 노드의 수가 충분하지 않기 때문이다.
|
||||
{{< /note >}}
|
||||
|
||||
**이 특징을 비활성화하려면**, `percentageOfNodesToScore`를 100으로 지정한다.
|
||||
|
||||
### percentageOfNodesToScore 튜닝
|
||||
|
||||
`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며
|
||||
기본 값은 50이다. 또한 50%의 노드로 하드 코딩된 최소 값이 내부적으로
|
||||
적용된다. 스케줄러는 `percentageOfNodesToScore` 값과 상관없이
|
||||
적어도 50%의 노드 탐색을 수행한다. 이는 수백 개 정도의 노드가 있는
|
||||
클러스터에서는 해당 옵션을 더 낮은 값으로 변경하더라도 스케줄러가
|
||||
찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는
|
||||
뜻이다. 이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을
|
||||
눈에 띄게 향상시키지 않는 것을 감안하여 의도적으로 설계되었다. 1000 노드
|
||||
이상의 큰 규모의 클러스터에서는 이 값을 낮은 수로 설정하면 눈에 띄는 성능
|
||||
향상을 보일 수도 있다.
|
||||
|
||||
이 값을 세팅할 때 중요하게 고려해야 할 사항은, 클러스터에서
|
||||
적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
|
||||
일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데
|
||||
가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지
|
||||
않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.
|
||||
그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 30 이하의
|
||||
값으로는 설정하지 않는 것이다. 더 낮은 값은 사용자의 애플리케이션에서 스케줄러의
|
||||
처리량이 치명적이고 노드의 점수가 중요하지 않을 경우에만 사용해야 한다. 다시 말해서, 파드의
|
||||
실행에 적합하기만 하다면 어느 노드가 선택되어도 사용자에게 상관없는 경우를 말한다.
|
||||
|
||||
만약 사용자의 클러스터가 단지 백여 개의 노드를 가지고 있는 경우 기본 값보다 낮은 값으로의
|
||||
변경을 추천하지 않는다. 그것은 스케줄러의 성능을
|
||||
크게 향상시키지 않을 것이다.
|
||||
|
||||
### 스케줄러가 노드 탐색을 반복(iterate)하는 방법
|
||||
|
||||
이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을
|
||||
위해 작성되었다.
|
||||
|
||||
클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를
|
||||
가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을
|
||||
반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의
|
||||
시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를
|
||||
찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가
|
||||
이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막
|
||||
포인트부터 확인을 재개한다.
|
||||
|
||||
만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성
|
||||
확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서
|
||||
탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자.
|
||||
|
||||
```
|
||||
영역 1: 노드 1, 노드 2, 노드 3, 노드 4
|
||||
영역 2: 노드 5, 노드 6
|
||||
```
|
||||
|
||||
스케줄러는 노드의 적합성 평가를 다음의 순서로 실행한다.
|
||||
|
||||
```
|
||||
노드 1, 노드 5, 노드 2, 노드 6, 노드 3, 노드 4
|
||||
```
|
||||
|
||||
모든 노드를 검토한 후, 노드 1로 돌아간다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -33,7 +33,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
|
||||
|
||||
`PreStop`
|
||||
|
||||
이 훅은 컨테이너가 종료되기 직전에 호출된다.
|
||||
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다.
|
||||
그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로,
|
||||
컨테이너를 삭제하기 위한 호출이 전송되기 전에 완료되어야한다.
|
||||
파라미터는 핸들러에 전달되지 않는다.
|
||||
@@ -96,17 +96,17 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
|
||||
|
||||
```
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
|
||||
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
|
||||
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
|
||||
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
|
||||
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
|
||||
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
|
||||
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
|
||||
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
|
||||
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
|
||||
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -167,6 +167,11 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
|
||||
않을 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
현재 쿠버네티스는 docker 설정의 `auths`와 `HttpHeaders` 섹션만 지원한다. 이는 자격증명 도우미(`credHelpers` 또는 `credStore`)가 지원되지 않는다는 뜻이다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을
|
||||
아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다.
|
||||
|
||||
@@ -310,7 +315,7 @@ type: kubernetes.io/dockerconfigjson
|
||||
|
||||
`error: no objects passed to create`라는 에러 메시지가 나오면, 그것은 base64 인코딩된 문자열이 유효하지 않다는 것을 뜻한다.
|
||||
`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`와 유사한 에러 메시지가 나오면, 그것은
|
||||
데이터가 성공적으로 un-base64 인코딩되었지만, `.docker/config.json` 파일로는 파싱될 수 없었음을 의미한다.
|
||||
base64 인코딩 된 데이터가 성공적으로 디코딩되었지만, `.docker/config.json` 파일로는 파싱될 수 없었음을 의미한다.
|
||||
|
||||
#### 파드의 imagePullSecrets 참조
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ weight: 20
|
||||
|
||||
cloud-controller-manager는 클라우드-제공사업자-특유 컨트롤러 루프만을 동작시킨다. 이 컨트롤러 루프는 kube-controller-manager에서 비활성 시켜야만 한다. kube-controller-manager를 구동시킬 때 `--cloud-provider` 플래그를 `external`로 설정함으로써 이 컨트롤러 루프를 비활성 시킬 수 있다.
|
||||
|
||||
cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코어가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는, 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서, 클라우드 밴더에 따른 코드는 클라우드 밴더 자체에 의해 유지되도록 하여야만 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 하여야만 한다.
|
||||
cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는, 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서, 클라우드 밴더에 따른 코드는 클라우드 밴더 자체에 의해 유지되도록 하여야만 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 하여야만 한다.
|
||||
|
||||
다음 컨트롤러들은 클라우드 제공사업자의 의존성을 갖는다.
|
||||
|
||||
@@ -73,7 +73,8 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코어
|
||||
|
||||
### 컨테이너 런타임
|
||||
|
||||
컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. 쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [rkt](https://coreos.com/rkt/), [runc](https://github.com/opencontainers/runc) 그리고 OCI [runtime-spec](https://github.com/opencontainers/runtime-spec)을 충족하는 모든 런타임 등이 있다.
|
||||
컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
|
||||
쿠버네티스는 몇몇의 런타임을 지원하는데 [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/container-runtime-interface.md)를 구현한 모든 런타임이다.
|
||||
|
||||
## 애드온
|
||||
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "kubectl을 이용한 오브젝트 관리"
|
||||
weight: 50
|
||||
---
|
||||
@@ -0,0 +1,186 @@
|
||||
---
|
||||
title: 쿠버네티스 오브젝트 관리
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
|
||||
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
|
||||
제공한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 관리 기법
|
||||
|
||||
{{< warning >}}
|
||||
쿠버네티스 오브젝트는 오직 하나의 기법을 사용하여 관리되어야 한다. 동일한 오브젝트에
|
||||
대해 혼합하고 일치시키는 기법은 확실하지 않은 동작을 초래하게 된다.
|
||||
{{< /warning >}}
|
||||
|
||||
| Management technique | Operates on |Recommended environment | Supported writers | Learning curve |
|
||||
|----------------------------------|----------------------|------------------------|--------------------|----------------|
|
||||
| Imperative commands | Live objects | Development projects | 1+ | Lowest |
|
||||
| Imperative object configuration | Individual files | Production projects | 1 | Moderate |
|
||||
| Declarative object configuration | Directories of files | Production projects | 1+ | Highest |
|
||||
|
||||
## 명령형 명령어
|
||||
|
||||
명령형 명령어를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
|
||||
직접 동작시킨다. 사용자는 `kubectl` 명령어에 인수 또는 플래그로 작업을
|
||||
제공한다.
|
||||
|
||||
이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한
|
||||
가장 단순한 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인
|
||||
영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다.
|
||||
|
||||
### 예시
|
||||
|
||||
디프롤이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동 시킨다.
|
||||
|
||||
```sh
|
||||
kubectl run nginx --image nginx
|
||||
```
|
||||
|
||||
다른 문법을 이용하여 동일한 작업을 수행한다.
|
||||
|
||||
```sh
|
||||
kubectl create deployment nginx --image nginx
|
||||
```
|
||||
|
||||
### 트레이드 오프
|
||||
|
||||
오브젝트 구성과 비교한 장점은
|
||||
|
||||
- 명령어가 익히기에 단순, 용이하고 기억하기 쉽다.
|
||||
- 명령어가 클러스터에 변경을 주기 위해 오직 단일 과정만이 필요하다.
|
||||
|
||||
오브젝트 구성과 비교한 단점은
|
||||
|
||||
- 명령어가 변경 검토 프로세스와 통합되지 않는다.
|
||||
- 명령어가 변경에 관한 감사 추적을 제공하지 않는다.
|
||||
- 명렁어가 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
|
||||
- 명령어가 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.
|
||||
|
||||
## 명령형 오브젝트 구성
|
||||
|
||||
명령형 오브젝트 구성에서, kubectl 명령은 작업 (생성, 대체 등),
|
||||
선택적 플래그, 그리고 최소 하나의 파일 이름을 정의한다.
|
||||
그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를
|
||||
포함해야만 한다.
|
||||
|
||||
오브젝트 정의에 대한 더 자세한 내용은 [API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)를
|
||||
참고한다.
|
||||
|
||||
{{< warning >}}
|
||||
명령형 `replace` 명령은 기존 spec을 새롭게 제공된 것으로 대체하며,
|
||||
구성 파일에서 누락된 오브젝트에 대한 모든 변경사항은 없어진다.
|
||||
이러한 접근은 구성 파일에 대해 독립적으로 spec이 업데이트되는
|
||||
형태의 리소스와 함께 사용하면 안된다.
|
||||
예를 들어, `LoadBalancer` 형태의 서비스는 `externalIPs` 필드를
|
||||
클러스터 구성과는 독립적으로 업데이트한다.
|
||||
{{< /warning >}}
|
||||
|
||||
### 예시
|
||||
|
||||
구성 파일에 정의된 오브젝트를 생성한다.
|
||||
|
||||
```sh
|
||||
kubectl create -f nginx.yaml
|
||||
```
|
||||
|
||||
두 개의 구성 파일에 정의된 오브젝트를 삭제한다.
|
||||
|
||||
```sh
|
||||
kubectl delete -f nginx.yaml -f redis.yaml
|
||||
```
|
||||
|
||||
활성 동작하는 구성을 덮어씀으로서 구성 파일에 정의된 오브젝트를
|
||||
업데이트한다.
|
||||
|
||||
```sh
|
||||
kubectl replace -f nginx.yaml
|
||||
```
|
||||
|
||||
### 트레이드 오프
|
||||
|
||||
명령형 명령과 비교한 장점은
|
||||
|
||||
- 오브젝트 구성이 Git과 같은 소스 컨트롤 시스템에 보관되어 질 수 있다.
|
||||
- 오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
|
||||
- 오브젝트 구성이 새로운 오브젝트 생성을 위한 템플릿을 제공한다.
|
||||
|
||||
명령형 명령과 비교한 단점은
|
||||
|
||||
- 오브젝트 구성이 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
|
||||
- 오브젝트 구성이 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.
|
||||
|
||||
선언형 오브젝트 구성과 비교한 장점은
|
||||
|
||||
- 명령형 오브젝트 구성의 작용은 보다 간결하고 이해하기에 용이하다.
|
||||
- 쿠버네티스 버전 1.5 부터, 명령형 오브젝트 구성이 더욱 발달한다.
|
||||
|
||||
선언형 오브젝트 구성과 비교한 단점은
|
||||
|
||||
- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
|
||||
- 활성 오브젝트에 대한 업데이트는 구성 파일 내 반영되어야만 한다. 그렇지 않으면 다음 대체가 이루어지는 동안 유실 될 것이다.
|
||||
|
||||
## 선언형 오브젝트 구성
|
||||
|
||||
선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
|
||||
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
|
||||
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
|
||||
`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이것은 다른 오브젝트를 위해 필요할 수도 있는
|
||||
다른 작업에서, 디렉토리들을 대상으로 동작할 수 있도록 해준다.
|
||||
|
||||
{{< note >}}
|
||||
선언형 오브젝트 구성은 비록 그 변경사항이 오브젝트 구성 파일로
|
||||
되돌려 병합될 수 없기는 하지만, 다른 작성자에 의해 이루어진 변경사항을 유지한다.
|
||||
이는 전체 오브젝트 구성을 대체하기 위해 `replace` API 작업을 이용하는 대신,
|
||||
오직 인지된 차이점을 기록하기 위한 `patch`
|
||||
API 작업을 이용함으로서 가능하다.
|
||||
{{< /note >}}
|
||||
|
||||
### 예시
|
||||
|
||||
`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
|
||||
생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff`
|
||||
하고 나서 적용할 수 있다.
|
||||
|
||||
```sh
|
||||
kubectl diff -f configs/
|
||||
kubectl apply -f configs/
|
||||
```
|
||||
|
||||
재귀적으로 디렉토리를 처리한다.
|
||||
|
||||
```sh
|
||||
kubectl diff -R -f configs/
|
||||
kubectl apply -R -f configs/
|
||||
```
|
||||
|
||||
### 트레이드 오프
|
||||
|
||||
명령형 오브젝트 구성과 비교한 장점은
|
||||
|
||||
- 구성 파일로 되돌려 병합될 수 없기는 하지만, 활성 오브젝트에 직접 이루어진 변경사항이 유지된다.
|
||||
- 선언형 오브젝트 구성은 디렉토리에 관한 동작에 대해 더 나은 지원을 하고 자동으로 오브젝트 마다의 작업(생성, 패치, 삭제)을 감지한다.
|
||||
|
||||
명령형 오브젝트 구성과 비교한 단점은
|
||||
|
||||
- 선언형 오브젝트 구성은 예측이 불가할 경우 디버그 하기가 더 어렵고 결과를 이해하기가 더 어렵다.
|
||||
- 차이점를 이용한 부분적 업데이트는 복잡한 병합과 패치 작업을 만들어 낸다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
- [명령형 명령어를 이용한 쿠버네티스 오브젝트 관리하기](/docs/concepts/overview/object-management-kubectl/imperative-command/)
|
||||
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
|
||||
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
|
||||
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
{{< comment >}}
|
||||
{{< /comment >}}
|
||||
{{% /capture %}}
|
||||
@@ -28,7 +28,7 @@ weight: 10
|
||||
|
||||
예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해 줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 (상태 변경에) 실패가 난다면, 쿠버네티스 시스템은 보정을 통해, 이 경우에는 인스턴스 대체를 착수하여, spec과 status 간의 차이에 대응한다.
|
||||
|
||||
오브젝트 spec, staus, 그리고 metadata에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md) 를 참조한다.
|
||||
오브젝트 spec, staus, 그리고 metadata에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
|
||||
|
||||
### 쿠버네티스 오브젝트 기술하기
|
||||
|
||||
|
||||
@@ -79,7 +79,7 @@ weight: 40
|
||||
|
||||
* 다음과 같은 커맨드로, 다운워드 API(Downward API)를 통한 원격 서버에 해당 파드를 등록하기.
|
||||
|
||||
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
|
||||
`curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'`
|
||||
|
||||
* `sleep 60`와 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기.
|
||||
* git 저장소를 볼륨 안에 클론하기.
|
||||
|
||||
@@ -37,6 +37,8 @@ weight: 30
|
||||
`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다.
|
||||
`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
|
||||
`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다.
|
||||
`Completed` | 완료된 잡(Job)과 같이 다 실행되어서 더 작동하고 있을 필요 없이 완료된 상태가 되었다.
|
||||
`CrashLoopBackOff` | 파드 내 컨테이너 중 하나가 예상과는 달리 종료(exit)되었고, [restart policy](#restart-policy)에 따라 재시작된 뒤에도 0이 아닌 에러 코드가 발생했을 것이다.
|
||||
|
||||
## 파드의 조건(condition)
|
||||
|
||||
@@ -144,6 +146,41 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
|
||||
파드의 상태로서 보고되는 정보는 현재의
|
||||
[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)에 의존적이라는 점에 유의하길 바란다.
|
||||
|
||||
## 컨테이너 상태
|
||||
|
||||
일단 스케줄러가 파드를 노드에 할당하면, kubelet이 컨테이너 런타임으로 컨테이너를 만들기 시작한다. 컨테이너에 세 가지 상태가 있는데, Waiting, Running, 그리고 Terminated이다. 컨테이너의 상태를 체크하려면 `kubectl describe pod [POD_NAME]` 명령을 사용할 수 있다. 상태는 파드 안에 있는 컨테이너 각각에 대해 출력된다.
|
||||
|
||||
* `Waiting`: 컨테이너의 기본 상태이다. 컨테이너가 Running 이나 Terminated 상태가 아닌 경우, Waiting 상태이다. Waiting 상태의 컨테이너는 이미지를 내려받거나(pull), 시크릿을 적용하는 등의 필요한 오퍼레이션이 수행 중인 상태이다. 이 상태와 더불어서, 더 자세한 정보를 제공하기 위해 상태에 대한 메시지와 이유가 출력된다.
|
||||
|
||||
```yaml
|
||||
...
|
||||
State: Waiting
|
||||
Reason: ErrImagePull
|
||||
...
|
||||
```
|
||||
|
||||
* `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. 컨테이너가 Running 상태가 되면, `postStart` 훅이 (존재한다면) 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다.
|
||||
|
||||
```yaml
|
||||
...
|
||||
State: Running
|
||||
Started: Wed, 30 Jan 2019 16:46:38 +0530
|
||||
...
|
||||
```
|
||||
|
||||
* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다.
|
||||
컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다.
|
||||
|
||||
```yaml
|
||||
...
|
||||
State: Terminated
|
||||
Reason: Completed
|
||||
Exit Code: 0
|
||||
Started: Wed, 30 Jan 2019 11:45:26 +0530
|
||||
Finished: Wed, 30 Jan 2019 11:45:26 +0530
|
||||
...
|
||||
```
|
||||
|
||||
## 파드의 준비성 게이트(readiness gate)
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
@@ -103,5 +103,5 @@ spec:
|
||||
{{% capture whatsnext %}}
|
||||
* 파드의 다른 동작들을 더 배워보자.
|
||||
* [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* 다른 파드 주제
|
||||
* [파드 라이프사이클](../pod-lifecycle)
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user