whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #26089 from kubernetes/dev-1.20-ko.2

Browse Source 
Ko: Second Korean l10n work for release-1.20
This commit is contained in:
Kubernetes Prow Robot
2021-01-14 19:45:52 -08:00
committed by GitHub
parent d37ab8abaf bfd90bff5f
commit 29963327b6
42 changed files with 437 additions and 252 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/control-plane-node-communication.md
+1 -1
View File
@@ -46,7 +46,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
사용한다.
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다.
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다.
### API 서버에서 노드, 파드 및 서비스로의 통신
content/ko/docs/concepts/cluster-administration/_index.md
+1 -1
View File
@@ -60,7 +60,7 @@ no_list: true
### kubelet 보안
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
## 선택적 클러스터 서비스
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+3 -2
View File
@@ -1,4 +1,5 @@
---
title: kubelet 가비지(Garbage) 수집 설정하기
content_type: concept
weight: 70
@@ -6,7 +7,7 @@ weight: 70
<!-- overview -->
가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다.
@@ -20,7 +21,7 @@ weight: 70
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
라이프사이클을 관리한다.
이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
`HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는
디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
이미지들을 삭제한다.
content/ko/docs/concepts/cluster-administration/system-metrics.md
+18 -14
View File
@@ -1,18 +1,19 @@
---
title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
content_type: concept
weight: 60
aliases:
- controller-metrics.md
---
<!-- overview -->
시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다.
쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
<!-- body -->
@@ -49,18 +50,20 @@ rules:
## 메트릭 라이프사이클
알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제
알파(Alpha) 메트릭 → 안정적인(Stable) 메트릭 → 사용 중단된(Deprecated) 메트릭 → 히든(Hidden) 메트릭 → 삭제된(Deleted) 메트릭
알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다.
안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다.
안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다.
* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다.
* 안정적인 메트릭의 유형(type)은 수정되지 않는다.
* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다
* 메트릭 유형은 수정되지 않는다
사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다.
이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다.
사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다.
예를 들면,
사용 중단되기 전에는 아래와 같다.
* 사용 중단 이전에는 다음과 같다.
```
# HELP some_counter this counts things
@@ -68,7 +71,7 @@ rules:
some_counter 0
```
사용 중단된 이후에는 아래와 같다.
* 사용 중단 이후에는 다음과 같다.
```
# HELP some_counter (Deprecated since 1.15.0) this counts things
@@ -76,9 +79,9 @@ some_counter 0
some_counter 0
```
메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다.
히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다.
메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다.
삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다.
## 히든 메트릭 표시
@@ -128,6 +131,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
```
### kube-scheduler 메트릭
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
content/ko/docs/concepts/configuration/configmap.md
-3
View File
@@ -225,7 +225,6 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
모든 요청을 리디렉션할 수 있다.
따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의
@@ -262,12 +261,10 @@ data:
immutable: true
```
{{< note >}}
컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
`data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만
삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
{{< /note >}}
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/configuration/secret.md
+1 -1
View File
@@ -349,7 +349,7 @@ data:
부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다.
- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
- `token-id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
문자열. 선택 사항.
content/ko/docs/concepts/overview/kubernetes-api.md
+2 -2
View File
@@ -17,8 +17,8 @@ card:
최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할
수 있도록 HTTP API를 제공한다.
쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.
쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
커맨드 라인 인터페이스 또는 API를 사용하는
content/ko/docs/concepts/overview/working-with-objects/common-labels.md
+6 -7
View File
@@ -58,14 +58,14 @@ metadata:
## 애플리케이션과 애플리케이션 인스턴스
애플리케이션은 동일한 쿠버네티스 클러스터에,
애플리케이션은 동일한 쿠버네티스 클러스터에,
심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
예를 들어 WordPress는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
## 예시
@@ -169,4 +169,3 @@ metadata:
```
MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.
content/ko/docs/concepts/policy/pod-security-policy.md
+24 -6
View File
@@ -1,4 +1,7 @@
---
title: 파드 시큐리티 폴리시
content_type: concept
weight: 30
@@ -213,12 +216,17 @@ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
name: pause
spec:
containers:
- name: pause
- name: pause
image: k8s.gcr.io/pause
EOF
```
이것의 출력은 다음과 같을 것이다.
```
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
```
@@ -261,12 +269,17 @@ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
name: pause
spec:
containers:
- name: pause
- name: pause
image: k8s.gcr.io/pause
EOF
```
이것의 출력은 다음과 같을 것이다.
```
pod "pause" created
```
@@ -278,14 +291,19 @@ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: privileged
name: privileged
spec:
containers:
- name: pause
- name: pause
image: k8s.gcr.io/pause
securityContext:
privileged: true
EOF
```
이것의 출력은 다음과 같을 것이다.
```
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
```
content/ko/docs/concepts/policy/resource-quotas.md
+1 -1
View File
@@ -186,7 +186,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
| `NotBestEffort` | 서비스 품질이 나쁜 파드 |
| `PriorityClass` | 지정된 [프라이올리티 클래스](/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
| `PriorityClass` | 지정된 [프라이올리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
+2 -2
View File
@@ -77,8 +77,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지
방법이 있다.
1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
1. [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
1. [스케줄링 정책](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
1. [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -420,5 +420,5 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/ko/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
* [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
content/ko/docs/concepts/workloads/_index.md
+49 -26
View File
@@ -8,50 +8,73 @@ no_list: true
{{< glossary_definition term_id="workload" length="short" >}}
워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의
[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
[_파드_](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
쿠버네티스에서 `Pod` 는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
집합을 나타낸다.
파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고
해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서
심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다.
쿠버네티스 파드에는 [정의된 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)이 있다.
예를 들어, 일단 파드가 클러스터에서 실행되고 나서
해당 파드가 동작 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에
심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 `Pod` 를 새로 생성해야 한다.
그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다.
그러나, 작업이 훨씬 쉽도록, 각 `Pod` 를 직접 관리할 필요는 없도록 만들었다.
대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다.
이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이
실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를
구성한다.
이러한 워크로드 리소스에는 다음이 포함된다.
쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다.
* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
(레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체);
* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/);
* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는
파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
* 완료될 때까지 실행되는 작업에 대한
[잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및
[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)
* [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 및 [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)
(레거시 리소스
{{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체).
`Deployment` 는 `Deployment` 의 모든 `Pod` 가 필요 시 교체 또는 상호 교체 가능한 경우,
클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.
* [`StatefulSet`](/ko/docs/concepts/workloads/controllers/statefulset/)는
어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가
데이터를 지속적으로 기록하는 경우, 사용자는 `Pod` 와
[`PersistentVolume`](/ko/docs/concepts/storage/persistent-volumes/)을 연계하는 `StatefulSet` 을 실행할 수 있다.
전체적인 회복력 향상을 위해서, `StatefulSet` 의 `Pods` 에서 동작 중인 코드는 동일한 `StatefulSet` 의
다른 `Pods` 로 데이터를 복제할 수 있다.
* [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)은 노드-로컬 기능(node-local facilities)을 제공하는 `Pods` 를 정의한다.
이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다.
예를 들면, 네트워킹 지원 도구 또는
{{< glossary_tooltip text="add-on" term_id="addons" >}} 등이 있다.
`DaemonSet` 의 명세에 맞는 노드를 클러스터에 추가할 때마다,
컨트롤 플레인은 해당 신규 노드에 `DaemonSet` 을 위한 `Pod` 를 스케줄한다.
* [`Job`](/ko/docs/concepts/workloads/controllers/job/) 및
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)은
실행 완료 후 중단되는 작업을 정의한다. `CronJobs` 이 스케줄에 따라 반복되는 반면,
잡은 단 한 번의 작업을 나타낸다.
관련성을 찾을 수 있는 두 가지 지원 개념도 있다.
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
제거된 후 클러스터에서 오브젝트를 정리한다.
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
완료된 이후 정의된 시간이 경과되면 잡을 제거한다.
더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드
리소스도 찾을 수 있다.
[커스텀 리소스 데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)을 사용하면,
쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를
추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 `Pods` 의 그룹을 실행하되
_모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은),
사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다.
## {{% heading "whatsnext" %}}
각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
* 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는,
[구성](/ko/docs/concepts/configuration/)을 참고하길 바란다.
다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는
두 가지 개념이다.
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
제거된 후 클러스터에서 오브젝트를 정리한다.
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는
잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.
일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로
사용하거나, 웹 애플리케이션의 경우에만
[인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다.
[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의
메커니즘에 대해 알아볼 수도 있다.
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+34
View File
@@ -1,4 +1,8 @@
---
title: 크론잡
content_type: concept
weight: 80
@@ -45,6 +49,36 @@ kube-controller-manager 컨테이너에 설정된 시간대는
([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는
이 예시를 더 자세히 설명한다.)
### 크론 스케줄 문법
```
# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
```
| 항목 | 설명 | 상응 표현 |
| ------------- | ------------- |------------- |
| @yearly (or @annually) | 매년 1월 1일 자정에 실행 | 0 0 1 1 * |
| @monthly | 매월 1일 자정에 실행 | 0 0 1 * * |
| @weekly | 매주 일요일 자정에 실행 | 0 0 * * 0 |
| @daily (or @midnight) | 매일 자정에 실행 | 0 0 * * * |
| @hourly | 매시 0분에 시작 | 0 * * * * |
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
`0 0 13 * 5`
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
## 크론잡의 한계 {#cron-job-limitations}
크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는
content/ko/docs/concepts/workloads/controllers/job.md
+11 -4
View File
@@ -1,4 +1,7 @@
---
title: 잡
content_type: concept
feature:
@@ -35,6 +38,7 @@ weight: 50
```shell
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
```
출력 결과는 다음과 같다.
```
job.batch/pi created
```
@@ -44,6 +48,7 @@ job.batch/pi created
```shell
kubectl describe jobs/pi
```
출력 결과는 다음과 같다.
```
Name: pi
Namespace: default
@@ -88,6 +93,7 @@ Events:
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods
```
출력 결과는 다음과 같다.
```
pi-5rwd7
```
@@ -100,7 +106,7 @@ pi-5rwd7
```shell
kubectl logs $pods
```
다음과 유사하게 출력된다.
출력 결과는 다음과 같다.
```shell
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
```
@@ -395,10 +401,11 @@ spec:
잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_.
삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
```
```shell
kubectl get job old -o yaml
```
```
출력 결과는 다음과 같다.
```yaml
kind: Job
metadata:
name: old
@@ -417,7 +424,7 @@ spec:
시스템이 일반적으로 자동 생성하는 셀렉터를 사용하지 않도록 하기 위해
새 잡에서 `manualSelector: true` 를 지정해야 한다.
```
```yaml
kind: Job
metadata:
name: new
content/ko/docs/concepts/workloads/pods/_index.md
+30
View File
@@ -1,4 +1,6 @@
---
title: 파드
content_type: concept
weight: 10
@@ -189,6 +191,34 @@ spec:
시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을
확장할 수 있게 한다.
## 파드 갱신 및 교체
이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드
템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신
갱신된 템플릿을 기반으로 신규 파드를 생성한다.
쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다.
동작 중인 파드의 필드를 갱신하는 것도 가능하다.
그러나,
[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 및
[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)와 같은
파드 갱신 작업에는 다음과 같은 제약이 있다.
- 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는
`namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다.
그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는
갱신만 허용한다.
- `metadata.deletionTimestamp` 가 설정된 경우,
`metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다.
- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`,
`spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는
변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다.
- `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만
허용한다.
1. 지정되지 않은 필드를 양수로 설정;
1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신.
## 리소스 공유와 통신
파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을
content/ko/docs/concepts/workloads/pods/init-containers.md
+4 -2
View File
@@ -1,4 +1,6 @@
---
title: 초기화 컨테이너
content_type: concept
weight: 40
@@ -47,9 +49,9 @@ weight: 40
또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다.
왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을
한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다.
모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을
모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을
초기화하고 평소와 같이 실행한다.
## 초기화 컨테이너 사용하기
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+3 -3
View File
@@ -66,7 +66,7 @@ graph TB
API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다.
```
```yaml
apiVersion: v1
kind: Pod
metadata:
@@ -290,7 +290,7 @@ graph BT
- `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서
기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서
`PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
@@ -315,7 +315,7 @@ profiles:
{{< note >}}
기본 스케줄링 제약 조건에 의해 생성된 점수는
[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에
의해 생성된 점수와 충돌 할 수 있다.
`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
이 플러그인을 비활성화 하는 것을 권장한다.