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>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
f351718930
commit
ff5d03a93b
@@ -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`
|
||||
레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를
|
||||
연결할 수 있다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user