Third Korean l10n work for release-1.16 (#17168)
Update file outdated korean docs in dev-1.16-ko.3. (#16876) Translate concepts/architecture/controller.md in Korean (#16889) Change the full link in the document to an inline link. (#17059) Add English-Korean translation glossary (#16664) Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: Seokho Son <shsongist@gmail.com>pull/17188/head
June Yi
Kubernetes Prow Robot
parent
f351718930
commit
ff5d03a93b
|
|
@ -26,21 +26,21 @@ weight: 40
|
|||
|
||||
## 쿠버네티스 오브젝트
|
||||
|
||||
쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 개요](/docs/concepts/abstractions/overview/) 문서를 참조한다.
|
||||
쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 문서를 참조한다.
|
||||
|
||||
기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다.
|
||||
|
||||
* [파드](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [서비스](/docs/concepts/services-networking/service/)
|
||||
* [볼륨](/docs/concepts/storage/volumes/)
|
||||
* [네임스페이스](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
추가로, 쿠버네티스에는 컨트롤러라는 보다 높은 수준의 추상 개념도 다수 있다. 컨트롤러는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공해준다. 다음이 포함된다.
|
||||
또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
|
||||
|
||||
* [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [스테이트풀 셋](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
|
||||
* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
|
||||
## 쿠버네티스 컨트롤 플레인
|
||||
|
|
@ -62,7 +62,7 @@ weight: 40
|
|||
#### 오브젝트 메타데이터
|
||||
|
||||
|
||||
* [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
* [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: "쿠버네티스 아키텍처"
|
||||
title: "클러스터 아키텍처"
|
||||
weight: 30
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 클라우트 컨트롤러 매니저 기반에 관한 개념
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,162 @@
|
|||
---
|
||||
title: 컨트롤러
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
로보틱스와 자동화에서 _컨트롤 루프_ 는
|
||||
시스템 상태를 조절하는 종료되지 않는 루프이다.
|
||||
|
||||
컨트롤 루프의 예시: 실내 온도 조절기
|
||||
|
||||
사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를
|
||||
온도 조절기에 알려준다.
|
||||
*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
|
||||
현재 상태를 의도한 상태에 가깝게 만든다.
|
||||
|
||||
{{< glossary_definition term_id="controller" length="short">}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 컨트롤러 패턴
|
||||
|
||||
컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다.
|
||||
이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
는 의도한 상태를 표현하는 사양 필드를 가지고 있다.
|
||||
해당 리소스의 컨트롤러(들)은 현재 상태를 의도한
|
||||
상태에 가깝게 만드는 역할을 한다.
|
||||
|
||||
컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로,
|
||||
쿠버네티스에서는 컨트롤러가
|
||||
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 로
|
||||
유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다.
|
||||
|
||||
{{< comment >}}
|
||||
네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는
|
||||
오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는
|
||||
자세한 설명을 생략한다.
|
||||
{{< /comment >}}
|
||||
|
||||
### API 서버를 통한 제어
|
||||
|
||||
{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스
|
||||
내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와
|
||||
상호 작용하며 상태를 관리한다.
|
||||
|
||||
잡은 단일 {{< glossary_tooltip term_id="pod" >}} 또는 여러 파드를 실행하고,
|
||||
작업을 수행한 다음 중지하는
|
||||
쿠버네티스 리소스 이다.
|
||||
|
||||
(일단 [스케줄되면](/ko/docs/concepts/scheduling/), 파드 오브젝트는 kubelet
|
||||
의 의도한 상태 중 일부가 된다.)
|
||||
|
||||
잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
|
||||
노드 집합의 kubelet이 작업을 수행하기에 적합한
|
||||
수의 파드를 실행하게 한다.
|
||||
잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다.
|
||||
대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록
|
||||
지시한다.
|
||||
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의
|
||||
다른 컴포넌트는 신규 정보
|
||||
(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여,
|
||||
결국 해당 작업을 완료시킨다.
|
||||
|
||||
새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다.
|
||||
잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게
|
||||
만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서
|
||||
잡이 완료에 가까워 지도록 한다.
|
||||
|
||||
또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다.
|
||||
예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는
|
||||
잡 오브젝트가 `Finished` 로 표시되도록 업데이트한다.
|
||||
|
||||
(이것은 지금 방 온도가 설정한 온도인 것을 표시하기
|
||||
위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다).
|
||||
|
||||
### 직접 제어
|
||||
|
||||
잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을
|
||||
변경해야 할 필요가 있다.
|
||||
|
||||
예를 들어, 만약 컨트롤 루프를 사용해서
|
||||
클러스터에 충분한 {{< glossary_tooltip text="노드들" term_id="node" >}}이
|
||||
있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록
|
||||
현재 클러스터 외부의 무언가를 필요로 한다.
|
||||
|
||||
외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한
|
||||
상태를 찾은 다음, 외부 시스템과 직접 통신해서
|
||||
현재 상태를 보다 가깝게 만든다.
|
||||
|
||||
(실제로 클러스터의 노드를 수평으로 확장하는
|
||||
컨트롤러가 있다.
|
||||
[클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 본다.)
|
||||
|
||||
## 원하는 상태와 현재 상태 {#desired-vs-current}
|
||||
|
||||
쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인
|
||||
변화에 대응할 수 있다.
|
||||
|
||||
작업이 발생함에 따라 어떤 시점에서든 클러스터가
|
||||
변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로,
|
||||
클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다.
|
||||
|
||||
클러스터의 컨트롤러가 실행 중이고 유용한 변경을 수행할 수 있는 한,
|
||||
전체 상태가 안정적인지 아닌지는 중요하지 않다.
|
||||
|
||||
## 디자인
|
||||
|
||||
디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을
|
||||
관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프
|
||||
(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로
|
||||
만들기 위해 다른 종류의 리소스를 관리한다.
|
||||
|
||||
컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다,
|
||||
간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를
|
||||
허용하도록 디자인되었다.
|
||||
|
||||
예를 들어, 잡용 컨트롤러는 잡 오브젝트(새 작업을
|
||||
발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를
|
||||
확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
|
||||
잡은 다른 컨트롤러가 생성한다.
|
||||
|
||||
{{< note >}}
|
||||
동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다.
|
||||
이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에
|
||||
연결된 리소스에만 주의를 기울인다.
|
||||
|
||||
예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다.
|
||||
잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다.
|
||||
이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는
|
||||
정보({{< glossary_tooltip term_id="label" text="레이블" >}})가 있기 때문이다.
|
||||
{{< /note >}}
|
||||
|
||||
## 컨트롤러를 실행하는 방법 {#running-controllers}
|
||||
|
||||
쿠버네티스에는 {{< glossary_tooltip term_id="kube-controller-manager" >}}
|
||||
내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이
|
||||
내장 컨트롤러는 중요한 핵심 동작을 제공한다.
|
||||
|
||||
디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의
|
||||
자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다.
|
||||
쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로,
|
||||
어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다.
|
||||
|
||||
컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다.
|
||||
또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다.
|
||||
소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나,
|
||||
또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
|
||||
따라 달라진다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기
|
||||
* [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자.
|
||||
* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
|
||||
* 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)을 본다.
|
||||
{{% /capture %}}
|
||||
|
|
@ -6,7 +6,12 @@ weight: 10
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
하나의 노드는 쿠버네티스에서 하나의 워커 머신으로, 이전에는 `미니언`으로 알려졌다. 노드는 클러스터에 따라, VM 또는 물리 머신이 될 수 있다. 각 노드는 [파드](/docs/concepts/workloads/pods/pod/)를 동작시키기 위해 필요한 서비스를 포함하며 마스터 컴포넌트에 의해 관리된다. 노드 상의 서비스는 [컨테이너 런타임](/docs/concepts/overview/components/#node-components), kubelet 그리고 kube-proxy를 포함한다. 보다 상세한 내용은 아키텍처 문서 내 [쿠버네티스 노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 섹션을 확인한다.
|
||||
하나의 노드는 쿠버네티스에서 하나의 워커 머신으로, 이전에는 `미니언`으로 알려졌다. 노드는
|
||||
클러스터에 따라, VM 또는 물리 머신이 될 수 있다. 각 노드는
|
||||
[파드](/ko/docs/concepts/workloads/pods/pod/)를 동작시키기 위해 필요한 서비스를 포함하며 마스터 컴포넌트에 의해 관리된다. 노드 상의 서비스는 [컨테이너 런타임](/ko/docs/concepts/overview/components/#노드-컴포넌트), kubelet 그리고 kube-proxy를 포함한다. 보다
|
||||
상세한 내용은 아키텍처 문서 내
|
||||
[쿠버네티스 노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
섹션을 확인한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -64,23 +69,34 @@ kubectl describe node <insert-node-name-here>
|
|||
}
|
||||
]
|
||||
```
|
||||
|
||||
ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controller-manager/)에 인수로 넘겨지는 `pod-eviction-timeout` 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
|
||||
|
||||
1.5 이전의 쿠버네티스 버전에서는, 노드 컨트롤러가 apiserver로부터 접근 불가한 이러한 파드를 [강제 삭제](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
|
||||
시킬 것이다. 그러나 1.5 이상에서는, 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
|
||||
1.5 이전의 쿠버네티스 버전에서는, 노드 컨트롤러가 apiserver로부터 접근 불가한 이러한 파드를 [강제 삭제](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제)
|
||||
시킬 것이다. 그러나 1.5 이상에서는, 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를
|
||||
강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서
|
||||
동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우,
|
||||
노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면
|
||||
노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
|
||||
|
||||
1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
|
||||
[taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다. 마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다. 대신 노드의 taint와 toleration을 살펴본다.
|
||||
[taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
|
||||
마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다.
|
||||
대신 노드의 taint와 toleration을 살펴본다.
|
||||
|
||||
현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다. 아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의 taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다.
|
||||
현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다.
|
||||
아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의
|
||||
taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
|
||||
이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는
|
||||
시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
|
||||
{{< /caution >}}
|
||||
|
||||
### 용량과 할당가능 {#capacity}
|
||||
|
||||
노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.
|
||||
노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고
|
||||
노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.
|
||||
|
||||
용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다.
|
||||
할당가능 블록은 일반 파드에서 사용할 수 있는
|
||||
|
|
@ -97,7 +113,13 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
|
|||
|
||||
## 관리
|
||||
|
||||
[파드](/docs/concepts/workloads/pods/pod/)와 [서비스](/docs/concepts/services-networking/service/)와 달리, 노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해 외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다. 그래서 쿠버네티스가 노드를 생성할 때, 노드를 나타내는 오브젝트를 생성한다. 생성 이후, 쿠버네티스는 노드의 유효성 여부를 검사한다. 예를 들어, 다음 내용으로 노드를 생성하려 한다면,
|
||||
[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/docs/concepts/services-networking/service/)와 달리,
|
||||
노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해
|
||||
외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다.
|
||||
그래서 쿠버네티스가 노드를 생성할 때,
|
||||
노드를 나타내는 오브젝트를 생성한다.
|
||||
생성 이후, 쿠버네티스는 노드의 유효성 여부를 검사한다. 예를 들어,
|
||||
다음 내용으로 노드를 생성하려 한다면,
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -112,42 +134,101 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
|
|||
}
|
||||
```
|
||||
|
||||
쿠버네티스는 내부적으로 (표현을) 노드 오브젝트를 생성하고, `metadata.name` 필드를 근거로 상태 체크를 수행하여 노드의 유효성을 확인한다. 노드가 유효하면, 즉 모든 필요한 서비스가 동작 중이면, 파드를 동작시킬 자격이 된다. 그렇지 않으면, 유효하게 될때까지 어떠한 클러스터 활동에 대해서도 무시된다.
|
||||
쿠버네티스는 내부적으로 (표현을) 노드 오브젝트를 생성하고,
|
||||
`metadata.name` 필드를 근거로 상태 체크를 수행하여 노드의 유효성을 확인한다. 노드가 유효하면, 즉
|
||||
모든 필요한 서비스가 동작 중이면, 파드를 동작시킬 자격이 된다. 그렇지 않으면,
|
||||
유효하게 될때까지 어떠한 클러스터 활동에 대해서도 무시된다.
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스는 유효하지 않은 노드로부터 오브젝트를 보호하고 유효한 상태로 이르는지 확인하기 위해 지속적으로 체크한다. 이러한 프로세스를 중지시키기 위해는 명시적으로 노드 오브젝트를 삭제해야 한다.
|
||||
쿠버네티스는 유효하지 않은 노드로부터 오브젝트를 보호하고 유효한 상태로 이르는지 확인하기 위해 지속적으로 체크한다.
|
||||
이러한 프로세스를 중지시키기 위해는 명시적으로 노드 오브젝트를 삭제해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
현재, 쿠버네티스 노드 인터페이스와 상호작용 하는 3개의 컴포넌트가 존재하는데, 노드 컨트롤러, kubelet, 그리고 kubectl 이다.
|
||||
현재, 쿠버네티스 노드 인터페이스와 상호작용 하는 3개의 컴포넌트가 존재하는데,
|
||||
노드 컨트롤러, kubelet, 그리고 kubectl 이다.
|
||||
|
||||
### 노드 컨트롤러
|
||||
|
||||
노드 컨트롤러는 노드의 다양한 측면을 관리하는 쿠버네티스 마스터 컴포넌트다.
|
||||
노드 컨트롤러는 노드의 다양한 측면을 관리하는 쿠버네티스
|
||||
마스터 컴포넌트다.
|
||||
|
||||
노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에 (CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다.
|
||||
노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에
|
||||
(CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다.
|
||||
|
||||
두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
|
||||
두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의
|
||||
사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서
|
||||
동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는
|
||||
해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우,
|
||||
노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
|
||||
|
||||
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, 노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. (ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
|
||||
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
|
||||
노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트
|
||||
수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.)
|
||||
NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고,
|
||||
노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다.
|
||||
(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
|
||||
파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
|
||||
매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
|
||||
|
||||
쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가 된다. 쿠버네티스 1.13을 시작으로 node lease 기능이 알파 기능으로 (기능 게이트 `NodeLease`,
|
||||
[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)) 소개되었다. node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해 갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고 NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다. NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만 (기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.) 노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다. 노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과 성능 두 가지 측면에서 노드 하트비트를 상당히 경제적이도록 해준다.
|
||||
쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가
|
||||
된다. node lease 기능은 1.14 부터 기본값으로 활성화 되었으며, 베타 기능이다
|
||||
(기능 게이트 `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해
|
||||
갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고
|
||||
NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다.
|
||||
NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만
|
||||
(기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.)
|
||||
노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다.
|
||||
노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과
|
||||
성능 두 가지 측면에서 노드 하트비트를 상당히
|
||||
경제적이도록 해준다.
|
||||
|
||||
쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에 문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) 더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로, 노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터 내 모든 노드를 살핀다.
|
||||
쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에
|
||||
문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에)
|
||||
더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로,
|
||||
노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터
|
||||
내 모든 노드를 살핀다.
|
||||
|
||||
대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다.
|
||||
대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
|
||||
축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여
|
||||
파드 축출을 하지 않는다는 의미가 된다.
|
||||
|
||||
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` 기본값 0.55) 가 되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 `--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당 `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, 오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다.
|
||||
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
|
||||
경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
|
||||
체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.).
|
||||
상태가 불량한 노드의 일부가 최소
|
||||
`--unhealthy-zone-threshold` 기본값 0.55) 가
|
||||
되면 축출 비율은 감소한다. 클러스터가 작으면 (즉
|
||||
`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고,
|
||||
그렇지 않으면 축출 비율은 초당
|
||||
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
|
||||
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
|
||||
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
|
||||
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
|
||||
오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다.
|
||||
|
||||
노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 정상 비율 `--node-eviction-rate`로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
|
||||
노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이
|
||||
장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다.
|
||||
그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
|
||||
정상 비율 `--node-eviction-rate`로 축출한다. 코너 케이스란 모든 영역이
|
||||
완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다.
|
||||
이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
|
||||
복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
|
||||
|
||||
쿠버네티스 1.6을 시작으로 NodeController는 파드가 taint를 허용하지 않을 때, NoExecute taint 상태의 노드 상에 동작하는 파드 축출에 대한 책임 또한 지고 있다. 추가로, 기본적으로 비활성화 된 알파 기능으로, NodeController는 노드 접근 불가 또는 준비 부족과 같은 노드 문제에 상응하는 taint 추가에 대한 책임을 진다. `NoExecute` taints와 알파 기능에 대한 보다 상세한 내용은 [이 문서](/docs/concepts/configuration/taint-and-toleration/)를 참고한다.
|
||||
쿠버네티스 1.6을 시작으로 NodeController는 파드가 taint를 허용하지 않을 때,
|
||||
`NoExecute` taint 상태의 노드 상에 동작하는 파드 축출에 대한 책임 또한
|
||||
지고 있다. 추가로, 기본적으로 비활성화 된 알파 기능으로, NodeController는 노드 접근 불가
|
||||
또는 준비 부족과 같은 노드 문제에 상응하는 taint 추가에 대한 책임을 진다.
|
||||
`NoExecute` taints와 알파 기능에 대한 보다 상세한
|
||||
내용은 [이 문서](/docs/concepts/configuration/taint-and-toleration/)를 참고한다.
|
||||
|
||||
1.8 버전을 시작으로, 노드 컨트롤러는 노드 상태를 나타내는 taint 생성에 대한 책임을 지도록 만들 수 있다. 이는 버전 1.8 의 알파 기능이다.
|
||||
1.8 버전을 시작으로, 노드 컨트롤러는 노드 상태를 나타내는 taint 생성에 대한 책임을 지도록
|
||||
만들 수 있다. 이는 버전 1.8 의 알파 기능이다.
|
||||
|
||||
### 노드에 대한 자체-등록
|
||||
|
||||
kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
|
||||
kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
|
||||
스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
|
||||
|
||||
자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
|
||||
|
||||
|
|
@ -160,35 +241,50 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API
|
|||
- `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의.
|
||||
|
||||
[Node authorization mode](/docs/reference/access-authn-authz/node/)와
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면, kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
|
||||
kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
|
||||
|
||||
#### 수동 노드 관리
|
||||
|
||||
클러스터 관리자는 노드 오브젝트를 생성하고 수정할 수 있다.
|
||||
|
||||
관리자가 수동으로 오브젝트를 생성하고자 한다면, kubelet 플래그를 `--register-node=false`로 설정한다.
|
||||
관리자가 수동으로 오브젝트를 생성하고자 한다면, kubelet 플래그를
|
||||
`--register-node=false`로 설정한다.
|
||||
|
||||
관리자는 노드 리소스를 수정할 수 있다(`--register-node`설정과 무관하게). 수정은 노드 상에 레이블 설정과 스케줄 불가 마킹을 포함한다.
|
||||
관리자는 노드 리소스를 수정할 수 있다(`--register-node`설정과 무관하게).
|
||||
수정은 노드 상에 레이블 설정과 스케줄 불가 마킹을 포함한다.
|
||||
|
||||
노드 상의 레이블은 스케줄링을 제어하기 위해, 즉 하나의 파드가 오직 노드의 서브셋 상에 동작할 수 있도록 제한하기 위해 노드 셀렉터와 함께 이용될 수 있다.
|
||||
노드 상의 레이블은 스케줄링을 제어하기 위해,
|
||||
즉 하나의 파드가 오직 노드의 서브셋 상에 동작할 수 있도록 제한하기 위해 노드 셀렉터와 함께 이용될 수 있다.
|
||||
|
||||
노드를 스케줄 불가로 마킹하게 되면, 해당 노드에 새로운 파드가 스케줄되는 것을 막아주지만, 노드 상의 임의의 기존 파드에 대해서는 영향을 미치치 않는다. 이는 노드 리부트 전이나 기타 등의 준비 조치로 유용하다. 예를 들어, 노드를 스케줄 불가로 마크하기 위해 다음 명령을 수행한다.
|
||||
노드를 스케줄 불가로 마킹하게 되면, 해당 노드에 새로운 파드가 스케줄되는 것을 막아주지만,
|
||||
노드 상의 임의의 기존 파드에 대해서는 영향을 미치치 않는다. 이는 노드 리부트
|
||||
전이나 기타 등의 준비 조치로 유용하다. 예를 들어, 노드를 스케줄 불가로
|
||||
마크하기 위해 다음 명령을 수행한다.
|
||||
|
||||
```shell
|
||||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄러를 우회하고 노드 상에 스케줄 불가 속성을 고려하지 않는다. 심지어 리부트를 준비하는 동안 애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다.
|
||||
DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄러를
|
||||
우회하고 노드 상에 스케줄 불가 속성을 고려하지 않는다. 심지어 리부트를 준비하는 동안
|
||||
애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다.
|
||||
{{< /note >}}
|
||||
|
||||
### 노드 용량
|
||||
|
||||
노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다. 일반적으로, 노드는 스스로 등록하고 노드 오브젝트를 생성할 때 자신의 용량을 알린다. 만약 [수동 노드 관리](#manual-node-administration)를 수행 한다면, 노드를 추가할 때 노등 용량을 설정해야 한다.
|
||||
노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다.
|
||||
일반적으로, 노드는 스스로 등록하고 노드 오브젝트를 생성할 때 자신의 용량을 알린다. 만약
|
||||
[수동 노드 관리](#수동-노드-관리)를 수행 한다면, 노드를 추가할 때
|
||||
노드 용량을 설정해야 한다.
|
||||
|
||||
쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다. kubelet에 의해 구동된 모든 컨테이너를 포함하지만, [컨테이너 런타임](/docs/concepts/overview/components/#node-components)에 의해 직접 구동된 컨테이너 또는 컨테이너 외부에서 동작하는 임의의 프로세스는 해당되지 않는다.
|
||||
쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다.
|
||||
노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다.
|
||||
kubelet에 의해 구동된 모든 컨테이너를 포함하지만, [컨테이너 런타임](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 의해 직접 구동된 컨테이너 또는 컨테이너 외부에서 동작하는 임의의 프로세스는 해당되지 않는다.
|
||||
|
||||
파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다.
|
||||
파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면,
|
||||
[reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다.
|
||||
|
||||
## 노드 토폴로지
|
||||
|
||||
|
|
@ -200,10 +296,12 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
|
|||
|
||||
## API 오브젝트
|
||||
|
||||
노드는 쿠버네티스 REST API 내 탑-레벨 리소스 이다. API 오브젝트에 대한 보다 자세한 내용은 [노드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)에서 확인할 수 있다.
|
||||
노드는 쿠버네티스 REST API 내 탑-레벨 리소스 이다. API 오브젝트에 대한
|
||||
보다 자세한 내용은
|
||||
[노드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)에서 확인할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* [노드 컴포넌트](https://kubernetes.io/docs/concepts/overview/components/#node-components)에 대해 읽기
|
||||
* [노드 컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 읽기
|
||||
* 노드 수준 토폴로지에 대해 읽기: [노드의 토폴로지 정책 제어하기](/docs/tasks/administer-cluster/topology-manager/)
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -8,8 +8,11 @@ card:
|
|||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 문서는 기능 수행하는 쿠버네티스 클러스터를 제공하기 위해 필요한
|
||||
다양한 바이너리 컴포넌트들에 대해 요약하여 정리한다
|
||||
쿠버네티스를 배포하면 클러스터를 얻는다.
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="클러스터는">}}
|
||||
|
||||
이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한
|
||||
다양한 컴포넌트들에 대해 요약하고 정리한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
|
@ -90,7 +93,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
|
|||
|
||||
### DNS
|
||||
|
||||
여타 애드온들이 절대적으로 요구되지 않는 반면에, 많은 예시들에서 그것을 필요로 하기때문에 모든 쿠버네티스 클러스터는 [cluster DNS](/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다.
|
||||
여타 애드온들이 절대적으로 요구되지 않는 반면에, 많은 예시들에서 그것을 필요로 하기때문에 모든 쿠버네티스 클러스터는 [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다.
|
||||
|
||||
클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다.
|
||||
|
||||
|
|
@ -98,11 +101,11 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
|
|||
|
||||
### 웹 UI (대시보드)
|
||||
|
||||
[대시보드](/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자로 하여금 클러스터 자체 뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 고장처리를 할 수 있도록 허용해준다.
|
||||
[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자로 하여금 클러스터 자체 뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 고장처리를 할 수 있도록 허용해준다.
|
||||
|
||||
### 컨테이너 리소스 모니터링
|
||||
|
||||
[컨테이너 리소스 모니터링](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
|
||||
[컨테이너 리소스 모니터링](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
|
||||
중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
|
||||
|
||||
### 클러스터-레벨 로깅
|
||||
|
|
@ -110,9 +113,10 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
|
|||
[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
|
||||
검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
|
||||
* [컨트롤러](/docs/concepts/architecture/controller/)에 대해 더 배우기
|
||||
* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기
|
||||
* etcd의 공식 [문서](https://etcd.io/docs/) 읽기
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ card:
|
|||
{{% capture body %}}
|
||||
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
|
||||
|
||||
쿠버네티스란 명칭은 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험](https://research.google.com/pubs/pub43438.html)을 기반으로 만들어졌으며 커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다.
|
||||
쿠버네티스란 명칭은 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험](https://ai.google/research/pubs/pub43438)을 기반으로 만들어졌으며 커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다.
|
||||
|
||||
## 여정 돌아보기
|
||||
시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자.
|
||||
|
|
@ -24,17 +24,15 @@ card:
|
|||
**전통적인 배포 시대:**
|
||||
초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다.
|
||||
|
||||
**가상화된 배포 시대:**
|
||||
그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
|
||||
**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
|
||||
|
||||
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다.
|
||||
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.
|
||||
|
||||
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 전체 시스템이다.
|
||||
|
||||
**컨테이너 개발 시대:**
|
||||
컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
|
||||
**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
|
||||
|
||||
쿠버네티스에는 많은 기능이 있어 점점 인기를 끌고 있다. 컨테이너의 장점의 일부는 다음과 같다.
|
||||
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.
|
||||
|
||||
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
|
||||
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다.
|
||||
|
|
@ -51,7 +49,7 @@ card:
|
|||
|
||||
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
|
||||
|
||||
그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 확장 요구 사항, 장애 조치, 배포 패턴 등을 처리한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
|
||||
그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
|
||||
|
||||
쿠버네티스는 다음을 제공한다.
|
||||
|
||||
|
|
@ -62,7 +60,7 @@ card:
|
|||
* **자동화된 롤아웃과 롤백**
|
||||
쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
|
||||
* **자동화된 빈 패킹(bin packing)**
|
||||
쿠버네티스를 사용하면 각 컨테이너에 필요한 CPU 및 메모리 (RAM)의 양을 지정할 수 있다. 컨테이너에 자원 요청이 지정되면 쿠버네티스는 컨테이너에 대한 자원을 관리하기 위해 더 나은 결정을 내릴 수 있다.
|
||||
컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
|
||||
* **자동화된 복구(self-healing)**
|
||||
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
|
||||
* **시크릿과 구성 관리**
|
||||
|
|
@ -85,6 +83,6 @@ card:
|
|||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [쿠버네티스 구성요소](/docs/concepts/overview/components/) 살펴보기
|
||||
* [시작하기](/docs/setup/) 준비가 되었는가?
|
||||
* [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기
|
||||
* [시작하기](/ko/docs/setup/) 준비가 되었는가?
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ card:
|
|||
|
||||
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
|
||||
|
||||
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [Kubernetes API](/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [Client Libraries](/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
|
||||
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
|
||||
|
||||
### 오브젝트 스펙(spec)과 상태(status)
|
||||
|
||||
|
|
@ -62,12 +62,19 @@ deployment.apps/nginx-deployment created
|
|||
* `apiVersion` - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
|
||||
* `kind` - 어떤 종류의 오브젝트를 생성하고자 하는지
|
||||
* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
|
||||
* `spec` - 오브젝트에 대해 어떤 상태를 의도하는지
|
||||
|
||||
여러분은 또한 오브젝트 `spec` 필드를 제공해야만 할 것이다. 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
|
||||
예를 들어, `파드`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
|
||||
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
|
||||
예를 들어, `파드`에 대한 `spec` 포맷은
|
||||
[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은
|
||||
[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [Pod](/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
|
||||
* [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
|
||||
* 쿠버네티스의 [컨트롤러](/docs/concepts/architecture/controller/)에 대해 배운다.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -15,8 +15,7 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads
|
|||
모든 **크론잡** `일정:` 시간은 잡이 처음 시작된 마스터의 시간대를 기반으로 한다.
|
||||
{{< /note >}}
|
||||
|
||||
크론 잡을 생성하고 작동하는 방법은 크론 잡의 스펙 파일을 확안한다. 내용은 [크론 잡으로 자동 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs)를 참조한다.
|
||||
|
||||
크론 잡을 생성하고 작동하는 방법은 크론 잡의 스펙 파일을 확안한다. 내용은 [크론 잡으로 자동 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs)를 참조한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -25,11 +24,15 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads
|
|||
|
||||
## 크론 잡의 한계
|
||||
|
||||
크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지 않도록 해야겠지만, 완벽히 그럴 수 는 없다. 따라서 잡은 멱등원이 된다.
|
||||
크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는
|
||||
특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지
|
||||
않도록 해야겠지만, 완벽히 그럴 수 는 없다. 따라서 잡은 _멱등원_ 이 된다.
|
||||
|
||||
만약 `startingDeadlineSeconds` 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값), `concurrencyPolicy` 가 `Allow`로 설정될 경우, 잡은 항상 적어도 한 번은 실행될 것이다.
|
||||
만약 `startingDeadlineSeconds` 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값),
|
||||
`concurrencyPolicy` 가 `Allow`로 설정될 경우, 잡은 항상 적어도 한 번은
|
||||
실행될 것이다.
|
||||
|
||||
모든 크론 잡에 대해 크론잡 컨트롤러는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
|
||||
모든 크론 잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
|
||||
|
||||
````
|
||||
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
|
||||
|
|
@ -37,13 +40,17 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
|
|||
|
||||
중요한 것은 만약 `startingDeadlineSeconds` 필드가 설정이 되면(`nil` 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 `startingDeadlineSeconds` 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, `startingDeadlineSeconds` 가 `200` 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다.
|
||||
|
||||
|
||||
크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론 잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다.
|
||||
|
||||
즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고, `startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론 잡 컨트롤러가 `08:29:00` 부터 `10:21:00` 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다.
|
||||
즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고,
|
||||
`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론 잡 컨트롤러가
|
||||
`08:29:00` 부터 `10:21:00` 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다.
|
||||
|
||||
이 개념을 더 자세히 설명하자면, 크론 잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, `startingDeadlineSeconds` 이 200이라고 가정한다. 크론 잡 컨트롤러가 전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함)
|
||||
이 개념을 더 자세히 설명하자면, 크론 잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고,
|
||||
`startingDeadlineSeconds` 이 200이라고 가정한다. 크론 잡 컨트롤러가
|
||||
전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함)
|
||||
|
||||
크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
|
||||
크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
|
||||
잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
|||
|
||||
또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로
|
||||
레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋
|
||||
컨트롤러는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
|
||||
{{< glossary_tooltip term_id="controller" >}} 는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
|
||||
막지 못한다. 사용자가 이와 같은 일을 하게되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을
|
||||
수동으로 생성하는 것이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,10 +11,10 @@ weight: 30
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
_디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다.
|
||||
|
||||
디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 컨트롤러는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.
|
||||
디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}} 는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
디플로이먼트가 소유하는 레플리카셋은 관리하지 말아야 한다. 사용자의 유스케이스가 다음에 포함되지 않는 경우 쿠버네티스 리포지터리에 이슈를 올릴 수 있다.
|
||||
|
|
@ -151,23 +151,29 @@ _디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/p
|
|||
|
||||
다음 단계에 따라 디플로이먼트를 업데이트한다.
|
||||
|
||||
1. nginx 파드를 이용 중인 `nginx:1.9.1` 이미지에서 `nginx:1.7.9` 로 업데이트 한다.
|
||||
1. `nginx:1.7.9` 이미지 대신 `nginx:1.9.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다.
|
||||
|
||||
```shell
|
||||
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
|
||||
```
|
||||
이와 유사하게 출력된다.
|
||||
또는 간단하게 다음의 명령어를 사용한다.
|
||||
|
||||
```shell
|
||||
kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record
|
||||
```
|
||||
|
||||
이와 유사하게 출력된다.
|
||||
```
|
||||
deployment.apps/nginx-deployment image updated
|
||||
```
|
||||
|
||||
대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.7.9` 에서 `nginx:1.9.1` 로 변경한다.
|
||||
대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.7.9` 에서 `nginx:1.9.1` 로 변경한다.
|
||||
|
||||
```shell
|
||||
kubectl edit deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
이와 유사하게 출력된다.
|
||||
이와 유사하게 출력된다.
|
||||
```
|
||||
deployment.apps/nginx-deployment edited
|
||||
```
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ weight: 10
|
|||
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
|
||||
|
||||
레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에 OwnerReference이 없거나
|
||||
OwnerReference가 컨트롤러가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를
|
||||
OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를
|
||||
가지게 될 것이다.
|
||||
|
||||
## 레플리카셋을 사용하는 시기
|
||||
|
|
@ -319,7 +319,7 @@ kubectl autoscale rs frontend --max=10
|
|||
|
||||
### 디플로이먼트(권장)
|
||||
|
||||
[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/)는 레플리카셋을 소유하거나 업데이트를 하고,
|
||||
[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/)는 레플리카셋을 소유하거나 업데이트를 하고,
|
||||
파드의 선언적인 업데이트와 서버측 롤링 업데이트를 할 수 있는 오브젝트이다.
|
||||
레플리카셋은 단독으로 사용할 수 있지만, 오늘날에는 주로 디플로이먼트로 파드의 생성과 삭제 그리고 업데이트를 오케스트레이션하는 메커니즘으로 사용한다.
|
||||
디플로이먼트를 이용해서 배포할 때 생성되는 레플리카셋을 관리하는 것에 대해 걱정하지 않아도 된다.
|
||||
|
|
@ -338,13 +338,13 @@ kubectl autoscale rs frontend --max=10
|
|||
### 데몬셋
|
||||
|
||||
머신 모니터링 또는 머신 로깅과 같은 머신-레벨의 기능을 제공하는 파드를 위해서는 레플리카셋 대신
|
||||
[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용한다.
|
||||
[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용한다.
|
||||
이러한 파드의 수명은 머신의 수명과 연관되어 있고, 머신에서 다른 파드가 시작하기 전에 실행되어야 하며,
|
||||
머신의 재부팅/종료가 준비되었을 때, 해당 파드를 종료하는 것이 안전하다.
|
||||
|
||||
### 레플리케이션 컨트롤러
|
||||
레플리카셋은 [_레플리케이션 컨트롤러_](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 계승하였다.
|
||||
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/docs/concepts/overview/working-with-objects/labels/#label-selectors)에
|
||||
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에
|
||||
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
|
||||
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ weight: 40
|
|||
위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다.
|
||||
만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포,
|
||||
삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을
|
||||
제공하는 컨트롤러로 애플리케이션을 배포해야 한다. 아마도
|
||||
제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다.
|
||||
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는
|
||||
[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다.
|
||||
|
||||
|
|
@ -157,7 +157,8 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
|
|||
|
||||
### 파드 이름 레이블
|
||||
|
||||
스테이트풀셋 컨트롤러가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name`
|
||||
스테이트풀셋 {{< glossary_tooltip term_id="controller" >}}
|
||||
가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name`
|
||||
레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를
|
||||
연결할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ card:
|
|||
|
||||
파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.
|
||||
|
||||
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다.
|
||||
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다.
|
||||
|
||||
|
||||
쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다.
|
||||
|
|
|
|||
|
|
@ -79,8 +79,7 @@ weight: 10
|
|||
* 한영 병기 (예: 훅(hook))
|
||||
* 영어 단어 (예: Kubelet)
|
||||
|
||||
단, 자연스러움을 판단하는 기준은 주관적이므로 문서 한글화팀이 공동으로 관리하는
|
||||
[한글화팀 용어집](https://goo.gl/BDNeJ1)과 기존에 번역된 문서를 참고한다.
|
||||
단, 자연스러움을 판단하는 기준은 주관적이므로 다음의 [용어집](#용어집)과 기존에 번역된 문서를 참고한다.
|
||||
|
||||
{{% note %}}
|
||||
API 오브젝트는 원 단어를
|
||||
|
|
@ -103,5 +102,205 @@ API 오브젝트의 필드 이름, 파일 이름, 경로 이름과 같은 내용
|
|||
한영 병기는 페이지 내에서 해당 용어가 처음 사용되는 경우에만 적용하고 이후 부터는 한글만 표기한다.
|
||||
{{% /note %}}
|
||||
|
||||
### 용어집
|
||||
|
||||
English | 한글 | 비고
|
||||
--- | --- | ---
|
||||
Access | 접근 |
|
||||
Active | Active | 잡의 상태
|
||||
Active Job | 액티브 잡 |
|
||||
Addons | 애드온 |
|
||||
admission controller | 어드미션 컨트롤러 |
|
||||
Age | 기간 |
|
||||
Allocation | 할당량
|
||||
Annotation | 어노테이션 |
|
||||
App | 앱 |
|
||||
Appendix | 부록 |
|
||||
Application | 애플리케이션 |
|
||||
Args | Args | 약어의 형태이므로 한글화하지 않고 영문 표기
|
||||
array | 배열 |
|
||||
autoscaler | 오토스케일러
|
||||
availability zone | 가용성 영역(availability zone) |
|
||||
bare pod | 베어(bare) 파드 |
|
||||
beta | 베타 |
|
||||
boilerplate | 상용구 |
|
||||
Boot | 부트 |
|
||||
Build | 빌드 |
|
||||
Cache | 캐시 |
|
||||
canary | 카나리(canary) | 릴리스 방식에 관련한 용어인 경우에 한함
|
||||
cascading | 캐스케이딩(cascading) |
|
||||
character set | 캐릭터 셋 |
|
||||
Charts | 차트 |
|
||||
checkpoint | 체크포인트 |
|
||||
CLI | CLI |
|
||||
Cluster | 클러스터 |
|
||||
Command Line Tool | 커맨드라인 툴 |
|
||||
Config Map | 컨피그 맵 |
|
||||
configuration | 구성, 설정 |
|
||||
Connection | 연결 |
|
||||
containerized | 컨테이너화 된 |
|
||||
Context | 컨텍스트 |
|
||||
Control Plane | 컨트롤 플레인 |
|
||||
controller | 컨트롤러 |
|
||||
Cron Job | 크론 잡 |
|
||||
custom metrics | 사용자 정의 메트릭 |
|
||||
Custom resource | 사용자 정의 리소스 |
|
||||
CustomResourceDefinition | 커스텀 리소스 데피니션 |
|
||||
Daemon | 데몬 |
|
||||
Daemon Set | 데몬 셋 |
|
||||
Dashboard | 대시보드 |
|
||||
Data Plane | 데이터 플레인 |
|
||||
Default Limit | 기본 상한 |
|
||||
Default Request | 기본 요청량 |
|
||||
Deployment | 디플로이먼트 |
|
||||
deprecated | 사용 중단(deprecated) |
|
||||
descriptor | 디스크립터, 식별자 |
|
||||
Desired number of pods | 의도한 파드의 수 |
|
||||
Desired State | 의도한 상태 |
|
||||
disruption | 중단(disruption) |
|
||||
distros | 배포판 |
|
||||
Docker | 도커 |
|
||||
Dockerfile | Dockerfile |
|
||||
Downward API | 다운워드(Downward) API |
|
||||
Endpoint | 엔드포인트 |
|
||||
entry point | 진입점 |
|
||||
Event | 이벤트 |
|
||||
Exec | Exec |
|
||||
expose | 노출시키다 |
|
||||
extension | 익스텐션(extension) |
|
||||
Failed | Failed | 파드의 상태에 한함
|
||||
Federation | 페더레이션 |
|
||||
field | 필드 |
|
||||
Flannel | Flannel |
|
||||
form | 형식 |
|
||||
Google Compute Engine | Google Compute Engine |
|
||||
hash | 해시 |
|
||||
headless | 헤드리스 |
|
||||
health check | 헬스 체크 |
|
||||
Heapster | 힙스터(Heapster) |
|
||||
Heartbeat | 하트비트 |
|
||||
Homebrew | Homebrew |
|
||||
hook | 훅(hook) |
|
||||
Horizontal Pod Autoscaler | Horizontal Pod Autoscaler | 예외적으로 API 오브젝트에 대해 외래어 표기법 적용하지 않고 원문 그대로 표기
|
||||
hosted zone | 호스팅 영역 |
|
||||
hostname | 호스트네임 |
|
||||
Huge page | Huge page |
|
||||
Hypervisor | 하이퍼바이저 |
|
||||
idempotent | 멱등성 |
|
||||
Image | 이미지 |
|
||||
Image Pull Secrets | 이미지 풀(Pull) 시크릿 |
|
||||
Ingress | 인그레스 |
|
||||
Init Container | 초기화 컨테이너 |
|
||||
Instance group | 인스턴스 그룹 |
|
||||
introspection | 인트로스펙션(introspection) |
|
||||
Istio | 이스티오(Istio) |
|
||||
Job | 잡 |
|
||||
Kubelet | Kubelet |
|
||||
Kubernetes | 쿠버네티스 |
|
||||
label | 레이블 |
|
||||
lifecycle | 라이프사이클 |
|
||||
Linux | 리눅스 |
|
||||
load | 부하 |
|
||||
Log | 로그 |
|
||||
Lost | Lost | 클레임의 상태에 한함
|
||||
Machine | 머신 |
|
||||
manifest | 매니페스트 |
|
||||
Master | 마스터 |
|
||||
max limit/request ratio | 최대 상한/요청량 비율 |
|
||||
metadata | 메타데이터 |
|
||||
metric | 메트릭 |
|
||||
Minikube | Minikube |
|
||||
Mirror pod | 미러 파드(mirror pod) |
|
||||
monitoring | 모니터링 |
|
||||
naked pod | 네이키드(naked) 파드 |
|
||||
Namespace | 네임스페이스 |
|
||||
Network Policy | 네트워크 폴리시 |
|
||||
Node | 노드 |
|
||||
node lease | 노드 리스(lease)
|
||||
Object | 오브젝트 |
|
||||
Orchestrate | 오케스트레이션하다 |
|
||||
Output | 출력 |
|
||||
parameter | 파라미터 |
|
||||
patch | 패치 |
|
||||
Pending | Pending | 파드, 클레임의 상태에 한함
|
||||
Persistent Volume | 퍼시스턴트 볼륨 |
|
||||
Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 |
|
||||
pipeline | 파이프라인 |
|
||||
placeholder pod | 플레이스홀더(placeholder) 파드 |
|
||||
Pod(파드) | 파드 |
|
||||
Pod Preset | 파드 프리셋 |
|
||||
PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) |
|
||||
PodDisruptionBudget | PodDisruptionBudget |
|
||||
postfix | 접미사 |
|
||||
prefix | 접두사 |
|
||||
Previleged | 특권을 가진(previleged) |
|
||||
Prometheus | 프로메테우스 |
|
||||
proof of concept | 개념 증명 |
|
||||
Pull Request | 풀 리퀘스트 |
|
||||
Pull Secret Credentials | 풀(Pull) 시크릿 자격증명 |
|
||||
QoS Class | QoS 클래스 |
|
||||
Quota | 쿼터 |
|
||||
Ready | Ready |
|
||||
Reclaim Policy | 반환 정책 |
|
||||
Registry | 레지스트리 |
|
||||
Release | 릴리스 |
|
||||
Replica Set | 레플리카 셋 |
|
||||
replicas | 레플리카 |
|
||||
Replication Controller | 레플리케이션 컨트롤러 |
|
||||
repository | 리포지터리 |
|
||||
resource | 리소스 |
|
||||
Resource Limit | 리소스 상한 |
|
||||
Resource Quota | 리소스 쿼터 |
|
||||
return | 반환하다 |
|
||||
revision | 리비전 |
|
||||
Role | 롤 |
|
||||
rollback | 롤백 |
|
||||
rolling update | 롤링 업데이트 |
|
||||
rollout | 롤아웃 |
|
||||
Running | Running | 파드의 상태에 한함
|
||||
runtime | 런타임 |
|
||||
Scale | 스케일 |
|
||||
Secret | 시크릿 |
|
||||
segment | 세그먼트 |
|
||||
Selector | 셀렉터 |
|
||||
Self-healing | 자가 치유 |
|
||||
Service | 서비스 |
|
||||
Service Account | 서비스 어카운트 |
|
||||
service discovery | 서비스 디스커버리 |
|
||||
service mesh | 서비스 메쉬 |
|
||||
Session | 세션 |
|
||||
Session Affinity | 세션 어피니티(Affinity) |
|
||||
Setting | 세팅 |
|
||||
Shell | 셸 |
|
||||
Sign In | 로그인 |
|
||||
Sign Out | 로그아웃 |
|
||||
Stateful Set | 스테이트풀 셋 |
|
||||
stateless | 스테이트리스 |
|
||||
Static pod | 스태틱 파드(static pod) |
|
||||
Storage Class | 스토리지 클래스 |
|
||||
Sub-Object | 서브-오브젝트 |
|
||||
support | 지원 |
|
||||
Surge | 증가율 | 롤링업데이트 전략에 한함
|
||||
System | 시스템 |
|
||||
taint | 테인트(taint) |
|
||||
Task | 태스크 |
|
||||
Terminated | Terminated | 파드의 상태에 한함
|
||||
tolerations | 톨러레이션(toleration) |
|
||||
Tools | 도구
|
||||
traffic | 트래픽 |
|
||||
Type | 타입 |
|
||||
ubuntu | 우분투 |
|
||||
use case | 유스케이스 |
|
||||
Utilization | 사용량, 사용률 |
|
||||
verbosity | 로그 상세 레벨(verbosity) |
|
||||
virtualization | 가상화 |
|
||||
Volume | 볼륨 |
|
||||
Waiting | Waiting | 파드의 상태에 한함
|
||||
Walkthrough | 연습 |
|
||||
Windows | 윈도우 |
|
||||
Worker | 워커 | 노드의 형태에 한함
|
||||
Workload | 워크로드 |
|
||||
YAML | YAML |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 컨트롤러(Controller)
|
||||
id: controller
|
||||
date: 2018-04-12
|
||||
full_link: /docs/admin/kube-controller-manager/
|
||||
full_link: /docs/concepts/architecture/controller/
|
||||
short_description: >
|
||||
API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.
|
||||
|
||||
|
|
@ -11,9 +11,20 @@ tags:
|
|||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.
|
||||
쿠버네티스에서 컨트롤러는 {{< glossary_tooltip term_id="cluster" text="클러스터">}}
|
||||
의 상태를 관찰 한 다음, 필요한 경우에 생성 또는 변경을
|
||||
요청하는 컨트롤 루프이다.
|
||||
각 컨트롤러는 현재 클러스터 상태를 의도한 상태에 가깝게
|
||||
이동한다.
|
||||
|
||||
|
||||
<!--more-->
|
||||
|
||||
현재 쿠버네티스에 포함된 컨트롤러의 예시로는 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스 어카운트 컨트롤러가 있다.
|
||||
컨트롤러는 {{< glossary_tooltip text="api 서버" term_id="kube-apiserver" >}}
|
||||
({{< glossary_tooltip term_id="control-plane" >}}의 일부)를
|
||||
통해 클러스터의 공유 상태를 감시한다.
|
||||
|
||||
일부 컨트롤러는 컨트롤 플레인 내부에서 실행되며, 쿠버네티스 작업의 핵심인
|
||||
컨트롤 루프를 제공한다. 예를 들어 디플로이먼트 컨트롤러,
|
||||
데몬셋 컨트롤러, 네임스페이스 컨트롤러 그리고 퍼시스턴트 볼륨
|
||||
컨트롤러(및 그 외)는 모두 "kube-controller-manager" 내에서 실행 된다.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 컨테이너 런타임 인터페이스(Container runtime interface, CRI)
|
||||
id: cri
|
||||
date: 2019-03-07
|
||||
full_link: https://kubernetes.io/docs/concepts/overview/components/#container-runtime
|
||||
full_link: /docs/concepts/overview/components/#container-runtime
|
||||
short_description: >
|
||||
Kubelet과 컨테이너 런타임을 통합시키기 위한 API
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,23 @@
|
|||
---
|
||||
title: kube-apiserver
|
||||
title: API 서버
|
||||
id: kube-apiserver
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-apiserver/
|
||||
short_description: >
|
||||
쿠버네티스 API를 노출하는 마스터 상의 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드이다.
|
||||
쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트.
|
||||
|
||||
aka:
|
||||
- kube-apiserver
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
쿠버네티스 API를 노출하는 마스터 상의 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드이다.
|
||||
API 서버는 쿠버네티스 API를
|
||||
노출하는 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다.
|
||||
API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
수평적 스케일(즉, 더 많은 인스턴스를 디플로이하는 스케일)을 위해 설계되었다. [고가용성 클러스터 구축하기](/docs/admin/high-availability/)를 참고한다.
|
||||
쿠버네티스 API 서버의 주요 구현은 [kube-apiserver](/docs/reference/generated/kube-apiserver/) 이다.
|
||||
kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다.
|
||||
여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: kube-controller-manager
|
||||
id: kube-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-controller-manager/
|
||||
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
|
||||
short_description: >
|
||||
컨트롤러를 구동하는 마스터 상의 컴포넌트.
|
||||
|
||||
|
|
@ -16,4 +16,3 @@ tags:
|
|||
<!--more-->
|
||||
|
||||
논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 스테이트풀 셋(StatefulSet)
|
||||
id: statefulset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/statefulset/
|
||||
full_link: /ko/docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* .
|
||||
|
||||
|
|
@ -18,6 +18,3 @@ tags:
|
|||
<!--more-->
|
||||
|
||||
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀 셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀 셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다.
|
||||
|
||||
스테이트풀 셋도 다른 컨트롤러와 같은 패턴으로 운용된다. 사용자는 의도한 상태를 스테이트풀 셋 *오브젝트* 로 정의하고, 스테이트풀 셋 *컨트롤러* 는 현재 상태에서 의도한 상태에 이르기 위해 필요한 업데이트를 수행한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,8 @@ card:
|
|||
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
|
||||
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
|
||||
| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | |
|
||||
| [Kubermatic](https://www.loodse.com/) | ✔ | ✔ | ✔ | | |
|
||||
| [KubeOne](https://github.com/kubermatic/kubeone) | | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | |
|
||||
| [KubeSail](https://kubesail.com/) | ✔ | | | | |
|
||||
| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ |
|
||||
| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ |
|
||||
|
|
@ -96,7 +97,7 @@ card:
|
|||
| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | |
|
||||
| [oVirt](https://www.ovirt.org/) | | | | | ✔ |
|
||||
| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | |
|
||||
| [Platform9](https://platform9.com/) | ✔ | ✔ | ✔ | | ✔ |✔
|
||||
| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | ✔ | ✔ | ✔
|
||||
| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/)
|
||||
| [StackPoint](https://stackpoint.io/) | ✔ | ✔ | | | |
|
||||
| [Supergiant](https://supergiant.io/) | |✔ | | | |
|
||||
|
|
|
|||
|
|
@ -227,7 +227,7 @@ minikube start \
|
|||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CRI-O" %}}
|
||||
[CRI-O](https://github.com/kubernetes-incubator/cri-o)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다.
|
||||
[CRI-O](https://cri-o.io/)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다.
|
||||
```bash
|
||||
minikube start \
|
||||
--network-plugin=cni \
|
||||
|
|
@ -339,7 +339,7 @@ Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만
|
|||
|
||||
### 대시보드
|
||||
|
||||
[쿠버네티스 대시보드](/docs/tasks/access-application-cluster/web-ui-dashboard/)를 이용하려면, Minikube를 실행한 후 쉘에서 아래 명령어를 실행하여 주소를 확인한다.
|
||||
[쿠버네티스 대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)를 이용하려면, Minikube를 실행한 후 쉘에서 아래 명령어를 실행하여 주소를 확인한다.
|
||||
|
||||
```shell
|
||||
minikube dashboard
|
||||
|
|
@ -406,7 +406,7 @@ spec:
|
|||
|
||||
## 프라이빗 컨테이너 레지스트리
|
||||
|
||||
프라이빗 컨테이너 레지스트리를 이용하려면, [이 페이지](/docs/concepts/containers/images/)의 단계를 따르자.
|
||||
프라이빗 컨테이너 레지스트리를 이용하려면, [이 페이지](/ko/docs/concepts/containers/images/)의 단계를 따르자.
|
||||
|
||||
`ImagePullSecrets`를 이용하기를 권하지만, Minikube VM 상에서 설정하려 한다면 `/home/docker` 디렉터리에 `.dockercfg`를 두거나 `/home/docker/.docker` 디렉터리에 `config.json`을 둘 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -181,7 +181,7 @@ add-apt-repository ppa:projectatomic/ppa
|
|||
apt-get update
|
||||
|
||||
# CRI-O 설치
|
||||
apt-get install cri-o-1.13
|
||||
apt-get install cri-o-1.15
|
||||
|
||||
{{< /tab >}}
|
||||
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
reviewers:
|
||||
title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
|
||||
content_template: templates/concept
|
||||
weight: 75
|
||||
|
|
@ -28,44 +27,47 @@ weight: 75
|
|||
쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. 아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. 아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: win-webserver
|
||||
labels:
|
||||
app: win-webserver
|
||||
spec:
|
||||
ports:
|
||||
# 이 서비스에서 제공하는 포트
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: win-webserver
|
||||
type: NodePort
|
||||
---
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Deployment
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: win-webserver
|
||||
labels:
|
||||
app: win-webserver
|
||||
spec:
|
||||
ports:
|
||||
# 이 서비스에서 제공하는 포트
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: win-webserver
|
||||
type: NodePort
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: win-webserver
|
||||
name: win-webserver
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: win-webserver
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: win-webserver
|
||||
name: win-webserver
|
||||
spec:
|
||||
replicas: 2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: win-webserver
|
||||
name: win-webserver
|
||||
spec:
|
||||
containers:
|
||||
- name: windowswebserver
|
||||
image: mcr.microsoft.com/windows/servercore:ltsc2019
|
||||
command:
|
||||
- powershell.exe
|
||||
- -command
|
||||
- "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
|
||||
nodeSelector:
|
||||
beta.kubernetes.io/os: windows
|
||||
containers:
|
||||
- name: windowswebserver
|
||||
image: mcr.microsoft.com/windows/servercore:ltsc2019
|
||||
command:
|
||||
- powershell.exe
|
||||
- -command
|
||||
- "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
|
||||
nodeSelector:
|
||||
beta.kubernetes.io/os: windows
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -334,7 +334,7 @@ kubectl get nodes
|
|||
1. 등록된 모든 쿠버네티스 서비스(flanneld, kubelet, kube-proxy)를 해지한다.
|
||||
1. 쿠버네티스 바이너리(kube-proxy.exe, kubelet.exe, flanneld.exe, kubeadm.exe)를 모두 삭제한다.
|
||||
1. CNI 네트워크 플러그인 바이너리를 모두 삭제한다.
|
||||
1. 쿠버네티스 클러스터에 접근하기 위한 [Kubeconfig 파일](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 삭제한다.
|
||||
1. 쿠버네티스 클러스터에 접근하기 위한 [Kubeconfig 파일](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 삭제한다.
|
||||
|
||||
|
||||
### 퍼블릭 클라우드 제공자
|
||||
|
|
|
|||
|
|
@ -108,17 +108,18 @@ kubectl create -f <url> --edit
|
|||
몇 가지 수동 단계를 포함한다.
|
||||
|
||||
1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성파일로 내보낸다.
|
||||
```shell
|
||||
kubectl get <종류>/<이름> -o yaml > <종류>_<이름>.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get <종류>/<이름> -o yaml > <종류>_<이름>.yaml
|
||||
```
|
||||
|
||||
1. 수동으로 오브젝트 구성파일에서 상태 필드를 제거한다.
|
||||
|
||||
1. 이후 오브젝트 관리를 위해, `replace`만 사용한다.
|
||||
```shell
|
||||
kubectl replace -f <종류>_<이름>.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl replace -f <종류>_<이름>.yaml
|
||||
```
|
||||
|
||||
## 컨트롤러 셀렉터와 PodTemplate 레이블 삭제하기
|
||||
|
||||
|
|
|
|||
|
|
@ -67,12 +67,15 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
|||
|
||||
## 디플로이먼트 만들기
|
||||
|
||||
쿠버네티스 [*파드*](/docs/concepts/workloads/pods/pod/)는 관리와 네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다.
|
||||
이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스 [*디플로이먼트*](/docs/concepts/workloads/controllers/deployment/)는 파드의
|
||||
쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/pod/)는 관리와
|
||||
네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다.
|
||||
이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스
|
||||
[*디플로이먼트*](/ko/docs/concepts/workloads/controllers/deployment/)는 파드의
|
||||
헬스를 검사해서 파드의 컨테이너가 종료되었다면 재시작해준다.
|
||||
파드의 생성 및 스케일링을 관리하는 방법으로 디플로이먼트를 권장한다.
|
||||
|
||||
1. `kubectl create` 명령어를 실행하여 파드를 관리할 디플로이먼트를 만든다. 이 파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다.
|
||||
1. `kubectl create` 명령어를 실행하여 파드를 관리할 디플로이먼트를 만든다. 이
|
||||
파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
|
||||
|
|
@ -119,9 +122,10 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
|||
|
||||
## 서비스 만들기
|
||||
|
||||
기본적으로 파드는 쿠버네티스 클러스터 내부의 IP 주소로만 접근할 수 있다.
|
||||
`hello-node` 컨테이너를 쿠버네티스 가상 네트워크 외부에서 접근하려면
|
||||
파드를 쿠버네티스 [*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다.
|
||||
기본적으로 파드는 쿠버네티스 클러스터 내부의 IP 주소로만
|
||||
접근할 수 있다. `hello-node` 컨테이너를 쿠버네티스 가상 네트워크
|
||||
외부에서 접근하려면 파드를 쿠버네티스
|
||||
[*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다.
|
||||
|
||||
1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출시키기
|
||||
|
||||
|
|
@ -129,7 +133,8 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
|||
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
|
||||
```
|
||||
|
||||
`--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출시키기 원한다는 뜻이다.
|
||||
`--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출시키기
|
||||
원한다는 뜻이다.
|
||||
|
||||
2. 방금 생성한 서비스 살펴보기
|
||||
|
||||
|
|
@ -145,8 +150,10 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
|||
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
|
||||
```
|
||||
|
||||
로드 밸런서를 지원하는 클라우드 공급자의 경우에는 서비스에 접근할 수 있도록 외부 IP 주소가 프로비저닝 한다.
|
||||
Minikube에서 `LoadBalancer`타입은 `minikube service` 명령어를 통해서 해당 서비스를 접근할 수 있게 한다.
|
||||
로드 밸런서를 지원하는 클라우드 공급자의 경우에는
|
||||
서비스에 접근할 수 있도록 외부 IP 주소가 프로비저닝 한다.
|
||||
Minikube에서 `LoadBalancer`타입은 `minikube service` 명령어를 통해서 해당 서비스를 접근할 수
|
||||
있게 한다.
|
||||
|
||||
3. 다음 명령어를 실행한다
|
||||
|
||||
|
|
@ -156,7 +163,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
|||
|
||||
4. Katacoda 환경에서만: 플러스를 클릭한 후에 **Select port to view on Host 1** 를 클릭.
|
||||
|
||||
5. Katacoda 환경에서만: 포트 번호를 `30369`로 입력하고(서비스 출력 `8080`과 반대편의 포트를 참조), 클릭.
|
||||
5. Katacoda 환경에서만: 서비스 출력에서 `8080`의 반대편에 표시되는 5자리 포트 번호를 기록 한다. 이 포트 번호는 무작위로 생성되며, 사용자마다 다를 수 있다. 포트 번호 텍스트 상자에 `30369` 를 입력한 다음, 포트 표시를 클릭한다.
|
||||
|
||||
이렇게 하면 당신의 앱을 서비스하는 브라우저 윈도우를 띄우고 "Hello World" 메시지를 보여준다.
|
||||
|
||||
|
|
@ -264,8 +271,8 @@ minikube delete
|
|||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Deployment objects](/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
|
||||
* [Deploying applications](/docs/user-guide/deploying-applications/)에 대해서 더 배워 본다.
|
||||
* [Service objects](/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.
|
||||
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
|
||||
* [애플리케이션 배포](/docs/user-guide/deploying-applications/)에 대해서 더 배워 본다.
|
||||
* [서비스 오브젝트](/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -17,10 +17,14 @@ content_template: templates/concept
|
|||
|
||||
* [Cloud Native Certified Kubernetes Administrator (CKA) with Hands-On Labs & Practice Exams (Linux Academy)](https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
|
||||
|
||||
* [Certified Kubernetes Administrator (CKA) Preparation Course (CloudYuga)](https://cloudyuga.guru/courses/cka-online-self-paced)
|
||||
|
||||
* [Certified Kubernetes Administrator Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
|
||||
|
||||
* [Certified Kubernetes Application Developer (CKAD) with Hands-On Labs & Practice Exams (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
|
||||
|
||||
* [Certified Kubernetes Application Developer (CKAD) Preparation Course (CloudYuga)](https://cloudyuga.guru/courses/ckad-online-self-paced)
|
||||
|
||||
* [Certified Kubernetes Application Developer Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
|
||||
|
||||
* [Getting Started with Google Kubernetes Engine (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ card:
|
|||
이 튜토리얼은 [Redis를 이용한 PHP 방명록](../guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자.
|
||||
|
||||
## 클러스터 롤 바인딩 추가
|
||||
[클러스터 단위 롤 바인딩](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다.
|
||||
[클러스터 단위 롤 바인딩](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다.
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding cluster-admin-binding \
|
||||
|
|
|
|||
Loading…
Reference in New Issue