-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Third Korean l10n work for release-1.16
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 <[email protected]> Co-Authored-By: June Yi <[email protected]> Co-Authored-By: Seokho Son <[email protected]>
- Loading branch information
1 parent
d50f2cd
commit 6973002
Showing
30 changed files
with
688 additions
and
179 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
--- | ||
title: "쿠버네티스 아키텍처" | ||
title: "클러스터 아키텍처" | ||
weight: 30 | ||
--- |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 %}} |
Oops, something went wrong.