add ko pages
This commit is contained in:
Karen Bradshaw
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: 크론잡
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
|
||||
|
||||
@@ -28,8 +28,8 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트
|
||||
63자라는 제약 조건이 있기 때문이다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 크론잡
|
||||
|
||||
@@ -77,12 +77,13 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
|
||||
크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
|
||||
잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[크론 표현 포맷](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)은
|
||||
크론잡 `schedule` 필드의 포맷을 문서화 한다.
|
||||
|
||||
크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
|
||||
예는 [크론 잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: 데몬셋
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면
|
||||
파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로
|
||||
@@ -20,10 +20,10 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
|
||||
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
|
||||
각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 데몬셋 사양 작성
|
||||
|
||||
@@ -226,4 +226,4 @@ Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를
|
||||
디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
|
||||
다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -5,11 +5,11 @@ feature:
|
||||
description: >
|
||||
쿠버네티스는 애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 성장하는 디플로이먼트 솔루션 생태계를 이용한다.
|
||||
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다.
|
||||
@@ -20,10 +20,10 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
디플로이먼트가 소유하는 레플리카셋은 관리하지 말아야 한다. 사용자의 유스케이스가 다음에 포함되지 않는 경우 쿠버네티스 리포지터리에 이슈를 올릴 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 유스케이스
|
||||
|
||||
@@ -1165,4 +1165,4 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
|
||||
일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다.
|
||||
디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: 가비지(Garbage) 수집
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
|
||||
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 소유자(owner)와 종속(dependent)
|
||||
|
||||
@@ -168,15 +168,16 @@ kubectl delete replicaset my-repset --cascade=false
|
||||
|
||||
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)을 추적한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
|
||||
|
||||
[디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 잡 - 실행부터 완료까지
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
feature:
|
||||
title: 배치 실행
|
||||
description: >
|
||||
@@ -8,7 +8,7 @@ feature:
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료되도록 한다.
|
||||
파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의
|
||||
@@ -21,10 +21,10 @@ weight: 70
|
||||
|
||||
잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 예시 잡 실행하기
|
||||
|
||||
@@ -475,4 +475,4 @@ spec:
|
||||
|
||||
[`크론잡`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: 레플리카셋
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다.
|
||||
이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 레플리카셋의 작동 방식
|
||||
|
||||
@@ -362,4 +362,4 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
|
||||
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
|
||||
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -6,11 +6,11 @@ feature:
|
||||
description: >
|
||||
오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다.
|
||||
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
|
||||
@@ -20,10 +20,10 @@ _레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레
|
||||
실행 중임을 보장한다.
|
||||
다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 레플리케이션 컨트롤러의 동작방식
|
||||
|
||||
@@ -282,4 +282,4 @@ API 오브젝트에 대한 더 자세한 것은
|
||||
|
||||
[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: 스테이트풀셋
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
스테이트풀셋은 애플리케이션의 스테이트풀을 관리하는데 사용하는 워크로드 API 오브젝트이다.
|
||||
|
||||
{{< glossary_definition term_id="statefulset" length="all" >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 스테이트풀셋 사용
|
||||
|
||||
@@ -262,12 +262,13 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
|
||||
실행하려고 시도한 모든 파드를 삭제해야 한다.
|
||||
그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
|
||||
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
|
||||
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: 완료된 리소스를 위한 TTL 컨트롤러
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 65
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
@@ -18,12 +18,12 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
|
||||
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## TTL 컨트롤러
|
||||
|
||||
@@ -75,12 +75,13 @@ TTL 컨트롤러는 쿠버네티스 리소스에
|
||||
에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는
|
||||
아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
|
||||
|
||||
[디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user