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

Merge pull request #24119 from kubernetes/dev-1.19-ko.2

Browse Source 
Second Korean l10n work for release-1.19
This commit is contained in:
Kubernetes Prow Robot
2020-09-24 23:13:11 -07:00
committed by GitHub
parent ab8fb532fa 9cb997ab15
commit 28980202c1
64 changed files with 2203 additions and 527 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+1 -1
View File
@@ -150,7 +150,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
- **이미지 풀(Pull) 시크릿**:
특정 도커 컨테이너 이미지가 프라이빗한 경우,
[풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 자격 증명을 요구한다.
[풀(Pull) 시크릿](/ko/docs/concepts/configuration/secret/) 자격 증명을 요구한다.
대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성할 수 있도록 한다.
시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다.
content/ko/docs/tasks/administer-cluster/declare-network-policy.md
+4 -8
View File
@@ -6,6 +6,7 @@ content_type: task
<!-- overview -->
이 문서는 사용자가 쿠버네티스 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다.
{{% thirdparty-content %}}
## {{% heading "prerequisites" %}}
@@ -20,11 +21,6 @@ content_type: task
* [로마나(Romana)](/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [위브넷(Weave Net)](/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
{{< note >}}
위 목록은 추천순이나 선호도순이 아닌, 제품 이름의 알파벳 순으로 정렬되어 있다. 이 예제는 이러한 제공자 중 하나를 사용하는 쿠버네티스 클러스터에 유효하다.
{{< /note >}}
<!-- steps -->
## `nginx` 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기
@@ -63,7 +59,7 @@ NAME READY STATUS RESTARTS AGE
pod/nginx-701339712-e0qfq 1/1 Running 0 35s
```
## 다른 파드에서 접근하여 서비스 테스트하기
## 다른 파드에서 접근하여 서비스 테스트하기
사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.
@@ -84,11 +80,11 @@ remote file exists
## `nginx` 서비스에 대해 접근 제한하기
`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다.
`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다.
{{< codenew file="service/networking/nginx-policy.yaml" >}}
네트워크폴리시 오브젝트의 이름은 유효한
네트워크폴리시 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
{{< note >}}
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+1 -1
View File
@@ -155,7 +155,7 @@ min-kubernetes-server-version: 1.19
{{< note >}}
또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다.
인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다.
자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
자세한 내용은 [인증서 관리 가이드](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
{{</ note >}}
{{< note >}}
content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+287
View File
@@ -0,0 +1,287 @@
---
title: 스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정하기
content_type: task
weight: 60
---
<!-- overview -->
이 페이지는 스토리지에 대해
{{< glossary_tooltip text="퍼시스턴트볼륨클레임(PersistentVolumeClaim)" term_id="persistent-volume-claim" >}}을
사용하도록 파드를 설정하는 방법을 보여준다.
과정의 요약은 다음과 같다.
1. 클러스터 관리자로서, 물리적 스토리지와 연결되는 퍼시스턴트볼륨을
생성한다. 볼륨을 특정 파드와 연결하지 않는다.
1. 그 다음 개발자 / 클러스터 사용자의 역할로서, 적합한
퍼시스턴트볼륨에 자동으로 바인딩되는 퍼시스턴트볼륨클레임을
생성한다.
1. 스토리지에 대해 위의 퍼시스턴트볼륨클레임을 사용하는 파드를 생성한다.
## {{% heading "prerequisites" %}}
* 사용자는 노드가 단 하나만 있는 쿠버네티스 클러스터가 필요하고,
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
커맨드라인 툴이 사용자의 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약 사용자가
아직 단일 노드 클러스터를 가지고 있지 않다면, [Minikube](/ko/docs/setup/learning-environment/minikube/)를
사용하여 클러스터 하나를 생성할 수 있다.
* [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)의
관련 자료에 익숙해지도록 한다.
<!-- steps -->
## 사용자 노드에 index.html 파일 생성하기
사용자 클러스터의 단일 노드에 연결되는 셸을 연다. 셸을 여는 방법은
클러스터 설정에 따라 달라진다. 예를 들어 Minikube를 사용하는 경우,
`minikube ssh` 명령어를 입력하여 노드로 연결되는 셸을 열 수 있다.
해당 노드의 셸에서 `/mnt/data` 디렉터리를 생성한다.
```shell
# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
# "sudo"를 사용한다고 가정한다
sudo mkdir /mnt/data
```
`/mnt/data` 디렉터리에서 `index.html` 파일을 생성한다.
```shell
# 이번에도 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
# "sudo"를 사용한다고 가정한다
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
```
{{< note >}}
사용자 노드에서 `sudo` 이외의 슈퍼유저 접근 툴을 사용하는 경우,
`sudo` 를 해당 툴의 이름으로 바꾸면, 동일하게 작업을 수행할 수 있다.
{{< /note >}}
`index.html` 파일이 존재하는지 테스트한다.
```shell
cat /mnt/data/index.html
```
결과는 다음과 같다.
```
Hello from Kubernetes storage
```
이제 사용자 노드에서 셸을 종료해도 된다.
## 퍼시스턴트볼륨 생성하기
이 예제에서, 사용자는 *hostPath* 퍼시스턴트볼륨을 생성한다. 쿠버네티스는 단일 노드에서의
개발과 테스트를 위해 hostPath를 지원한다. hostPath 퍼시스턴트볼륨은
네트워크로 연결된 스토리지를 모방하기 위해, 노드의 파일이나 디렉터리를 사용한다.
운영 클러스터에서, 사용자가 hostPath를 사용하지는 않는다. 대신, 클러스터 관리자는
Google Compute Engine 영구 디스크, NFS 공유 또는 Amazone Elastic
Block Store 볼륨과 같은 네트워크 자원을 프로비저닝한다. 클러스터 관리자는
[스토리지클래스(StorageClasses)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage)를
사용하여
[동적 프로비저닝](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)을 설정할 수도 있다.
hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다.
{{< codenew file="pods/storage/pv-volume.yaml" >}}
설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고
지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가
읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를
지정한다. 여기서는
퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을
`manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을
이 퍼시스턴트볼륨에 바인딩하는데 사용한다.
퍼시스턴트볼륨을 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
```
퍼시스턴트볼륨에 대한 정보를 조회한다.
```shell
kubectl get pv task-pv-volume
```
결과는 퍼시스턴트볼륨의 `STATUS` 가 `Available` 임을 보여준다. 이는
아직 퍼시스턴트볼륨클레임이 바인딩되지 않았다는 것을 의미한다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Available manual 4s
## 퍼시스턴트볼륨클레임 생성하기
다음 단계는 퍼시스턴트볼륨클레임을 생성하는 단계이다. 파드는 퍼시스턴트볼륨클레임을
사용하여 물리적인 스토리지를 요청한다. 이 예제에서, 사용자는 적어도
하나 이상의 노드에 대해 읽기-쓰기 접근을 지원하며 최소 3 기가바이트의 볼륨을 요청하는
퍼시스턴트볼륨클레임을 생성한다.
퍼시스턴트볼륨클레임에 대한 설정 파일은 다음과 같다.
{{< codenew file="pods/storage/pv-claim.yaml" >}}
퍼시스턴트볼륨클레임을 생성한다.
kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml
사용자가 퍼시스턴트볼륨클레임을 생성한 후에, 쿠버네티스 컨트롤 플레인은
클레임의 요구사항을 만족하는 퍼시스턴트볼륨을 찾는다. 컨트롤 플레인이
동일한 스토리지클래스를 갖는 적절한 퍼시스턴트볼륨을 찾으면,
볼륨에 클레임을 바인딩한다.
퍼시스턴트볼륨을 다시 확인한다.
```shell
kubectl get pv task-pv-volume
```
이제 결과는 `STATUS` 가 `Bound` 임을 보여준다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Bound default/task-pv-claim manual 2m
퍼시스턴트볼륨클레임을 확인한다.
```shell
kubectl get pvc task-pv-claim
```
결과는 퍼시스턴트볼륨클레임이 사용자의 퍼시스턴트볼륨인 `task-pv-volume` 에
바인딩되어 있음을 보여준다.
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE
task-pv-claim Bound task-pv-volume 10Gi RWO manual 30s
## 파드 생성하기
다음 단계는 볼륨으로 퍼시스턴트볼륨클레임을 사용하는 파드를 만드는 단계이다.
파드에 대한 설정 파일은 다음과 같다.
{{< codenew file="pods/storage/pv-pod.yaml" >}}
파드의 설정 파일은 퍼시스턴트볼륨클레임을 지정하지만,
퍼시스턴트볼륨을 지정하지는 않는다는 것을 유념하자. 파드의 관점에서 볼때,
클레임은 볼륨이다.
파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
```
파드의 컨테이너가 실행 중임을 확인한다.
```shell
kubectl get pod task-pv-pod
```
사용자 파드에서 구동되고 있는 컨테이너에 셸로 접근한다.
```shell
kubectl exec -it task-pv-pod -- /bin/bash
```
사용자의 셸에서, nginx가 hostPath 볼륨으로부터 `index.html` 파일을
제공하는지 확인한다.
```shell
# 이전 단계에서 "kubectl exec" 명령을 실행한 root 셸 안에서
# 다음의 3개 명령을 실행해야 한다.
apt update
apt install curl
curl http://localhost/
```
결과는 hostPath 볼륨에 있는 `index.html` 파일에 사용자가 작성한 텍스트를
보여준다.
Hello from Kubernetes storage
만약 사용자가 위와 같은 메시지를 확인하면, 파드가 퍼시스턴트볼륨클레임의 스토리지를
사용하도록 성공적으로 설정한 것이다.
## 정리하기
파드, 퍼시스턴트볼륨클레임, 퍼시스턴트볼륨을 삭제한다.
```shell
kubectl delete pod task-pv-pod
kubectl delete pvc task-pv-claim
kubectl delete pv task-pv-volume
```
만약 클러스터의 노드에 대한 셸이 열려져 있지 않은 경우,
이전과 동일한 방식으로 새로운 셸을 연다.
사용자 노드의 셸에서, 생성한 파일과 디렉터리를 제거한다.
```shell
# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
# "sudo"를 사용한다고 가정한다
sudo rm /mnt/data/index.html
sudo rmdir /mnt/data
```
이제 사용자 노드에서 셸을 종료해도 된다.
<!-- discussion -->
## 접근 제어
그룹 ID(GID)로 설정된 스토리지는 동일한 GID를 사용하는 파드에서만 쓰기
작업을 허용한다. GID가 일치하지 않거나 누락되었을 경우 권한
거부 오류가 발생한다. 사용자와의 조정 필요성을 줄이기 위하여 관리자는
퍼시스턴트 볼륨에 GID로 어노테이션을 달 수 있다. 그 뒤에, 퍼시스턴트볼륨을
사용하는 모든 파드에 대하여 GID가 자동으로 추가된다.
다음과 같이 `pv.beta.kubernetes.io/gid` 어노테이션을 사용한다.
```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
annotations:
pv.beta.kubernetes.io/gid: "1234"
```
파드가 GID 어노테이션이 있는 퍼시스턴트볼륨을 사용하면, 어노테이션으로
달린 GID가 파드의 보안 컨텍스트에 지정된 GID와 동일한 방식으로
파드의 모든 컨테이너에 적용된다. 파드의 명세 혹은 퍼시스턴트볼륨의
어노테이션으로부터 생성된 모든 GID는, 각 컨테이너에서 실행되는 첫 번째
프로세스에 적용된다.
{{< note >}}
파드가 퍼시스턴트볼륨을 사용할 때, 퍼시스턴트볼륨과 연관된
GID는 파드 리소스 자체에는 존재하지 않는다.
{{< /note >}}
## {{% heading "whatsnext" %}}
* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기.
* [퍼시스턴트 스토리지 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)에 대해 읽어보기.
### Reference
* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
+1 -1
View File
@@ -206,7 +206,7 @@ kubectl get pod private-reg
## {{% heading "whatsnext" %}}
* [시크릿](/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
* [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
* [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
* [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+103
View File
@@ -0,0 +1,103 @@
---
title: 파드와 레플리케이션컨트롤러(ReplicationController) 디버그하기
content_type: task
---
<!-- overview -->
이 페이지에서는 파드와 레플리케이션컨트롤러를 디버깅하는 방법을 소개한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* 사용자는
{{< glossary_tooltip text="파드" term_id="pod" >}} 기본 사항과 파드의
[라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 잘 알고 있어야 한다.
<!-- steps -->
## 파드 디버깅
파드 디버깅의 첫 번째 단계는 파드를 살펴 보는 것이다. 다음의 명령어를
사용하여 파드의 현재 상태와 최근 이벤트를 점검한다.
```shell
kubectl describe pods ${POD_NAME}
```
파드 내부 컨테이너의 상태를 확인한다. 모두 `Running` 상태인가?
최근에 재시작 되었는가?
파드의 상태에 따라 디버깅을 계속한다.
### 파드가 pending 상태로 유지
파드가 `Pending` 상태로 멈춰 있는 경우는, 노드에 스케줄 될 수 없음을 의미한다.
일반적으로 이것은 어떤 유형의 리소스가 부족하거나 스케줄링을 방해하는 다른 요인 때문이다.
상단의 `kubectl describe ...` 명령의 결과를 확인하자.
파드를 스케줄 할 수 없는 이유에 대한 스케줄러의 메세지가 있어야 한다.
이유는 다음과 같다.
#### 부족한 리소스
사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우
몇 가지 방법을 시도할 수 있다.
* 클러스터에 [노드를 더 추가하기](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-크기-재조정).
* pending 상태인 파드를 위한 공간을 확보하기 위해
[불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination)
* 파드가 노드보다 크지 않은지 확인한다. 예를 들어 모든
노드가 `cpu:1` 의 용량을 가지고 있을 경우, `cpu: 1.1` 을 요청하는 파드는
절대 스케줄 될 수 없다.
사용자는 `kubectl get nodes -o <format>` 명령으로 노드의
용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지
명령의 예이다.
```shell
kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
```
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)
기능은 사용할 수 있는 전체 리소스의 양을 제한하도록 설정할 수 있다.
네임스페이스와 함께 사용하면,
한 팀이 모든 리소스를 점유하는 것을 방지할 수 있다.
#### hostPort 사용하기
파드를 `hostPort` 에 바인딩 할 때 파드를 스케줄링 할 수 있는
위치는 제한되어 있다. 대부분의 경우 `hostPort` 는 불필요하다. 서비스 오브젝트를
사용하여 파드를 노출하도록 한다. `hostPort` 가 필요한 경우
컨테이너 클러스터에 있는 노드의 수만큼 파드를 스케줄 할 수 있다.
### 파드가 waiting 상태로 유지
파드가 `Waiting` 상태에서 멈춘 경우, 워커 노드에 스케줄 되었지만, 해당 장비에서 사용할 수 없다.
거듭 강조하지만, `kubectl describe ...` 의 정보는 유익하게 사용되어야 한다.
`Waiting` 파드의 가장 일반적인 원인은 이미지를 가져오지 못하는 경우이다.
확인해야 할 3가지 사항이 있다.
* 이미지 이름이 올바른지 확인한다.
* 이미지를 저장소에 푸시하였는가?
* 이미지가 풀 될 수 있는지 보기 위해, 사용자의 장비에서 `docker pull <image>` 를 수동으로
실행한다.
### 파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우
일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/docs/tasks/debug-application-cluster/debug-running-pod/)에
기술된 메서드를 디버깅에 사용할 수 있다.
## 레플리케이션컨트롤러 디버깅
레플리케이션컨트롤러는 매우 간단하다. 이 오브젝트는 파드를 만들거나
만들 수 없는 경우뿐이다. 만약 파드를 만들 수 없는 경우,
[위의 지침](#파드-디버깅)을 참조하여 파드를 디버그한다.
사용자는 `kubectl describe rc ${CONTROLLER_NAME}` 을 사용하여 레플리케이션 컨트롤러와
관련된 이벤트를 검사할 수도 있다.
content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
+2 -2
View File
@@ -89,8 +89,8 @@ command: ["/bin/echo"]
args: ["$(MESSAGE)"]
```
이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure
-pod-configmap/)과 [시크릿](/docs/concepts/configuration/secret/)을
이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)과
[시크릿](/ko/docs/concepts/configuration/secret/)을
포함해, 환경 변수를 정의하는데 활용할 수 있는 모든 방법들을 활용해서 파드를 위한 인자를
정의할
수 있다는 것을 의미한다.
content/ko/docs/tasks/job/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "잡(Job) 실행"
description: 병렬 처리를 사용하여 잡을 실행한다.
weight: 50
---
content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
+208
View File
@@ -0,0 +1,208 @@
---
title: 크론잡(CronJob)으로 자동화된 작업 실행
min-kubernetes-server-version: v1.8
content_type: task
weight: 10
---
<!-- overview -->
시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다.
이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다.
크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다.
크론 잡에는 제한 사항과 특이점이 있다.
예를 들어, 특정 상황에서는 하나의 크론 잡이 여러 잡을 생성할 수 있다.
따라서, 잡은 멱등성을 가져야 한다.
제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 크론 잡 생성
크론 잡은 구성 파일이 필요하다.
아래의 크론 잡 구성 `.spec` 파일의 예제는 매 분마다 현재 시간과 hello 메시지를 출력한다.
{{< codenew file="application/job/cronjob.yaml" >}}
다음 명령을 사용하여 크론잡 예제를 실행한다.
```shell
kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml
```
출력 결과는 다음과 비슷하다.
```
cronjob.batch/hello created
```
크론 잡을 생성한 후, 다음 명령을 사용하여 상태를 가져온다.
```shell
kubectl get cronjob hello
```
출력 결과는 다음과 비슷하다.
```
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 <none> 10s
```
명령의 결과에서 알 수 있듯이, 크론 잡은 아직 잡을 스케줄하거나 실행하지 않았다.
약 1분 내로 잡이 생성되는지 확인한다.
```shell
kubectl get jobs --watch
```
출력 결과는 다음과 비슷하다.
```
NAME COMPLETIONS DURATION AGE
hello-4111706356 0/1 0s
hello-4111706356 0/1 0s 0s
hello-4111706356 1/1 5s 5s
```
이제 "hello" 크론 잡에 의해 스케줄된 실행 중인 작업을 확인했다.
잡 감시를 중지한 뒤에 크론 잡이 다시 스케줄되었는지를 확인할 수 있다.
```shell
kubectl get cronjob hello
```
출력 결과는 다음과 비슷하다.
```
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 50s 75s
```
크론 잡 `hello` 가 `LAST SCHEDULE` 에 지정된 시간에 성공적으로 잡을 스케줄했는지 확인해야 한다. 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
{{< note >}}
잡 이름과 파드 이름은 다르다.
{{< /note >}}
```shell
# "hello-4111706356"을 사용자의 시스템에 있는 잡 이름으로 바꾼다
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})
```
파드의 로그를 출력한다.
```shell
kubectl logs $pods
```
출력 결과는 다음과 비슷하다.
```
Fri Feb 22 11:02:09 UTC 2019
Hello from the Kubernetes cluster
```
## 크론 잡 삭제
더 이상 크론 잡이 필요하지 않으면, `kubectl delete cronjob <cronjob name>` 명령을 사용해서 삭제한다.
```shell
kubectl delete cronjob hello
```
크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
[가비지(garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
## 크론 잡 명세 작성
다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와
[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
{{< note >}}
크론 잡, 특히 해당 잡의 `.spec` 에 대한 모든 수정 사항은 다음 번 실행에만 적용된다.
{{< /note >}}
### 스케줄
`.spec.schedule` 은 `.spec` 의 필수 필드이다.
이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
이 형식은 확장된 `vixie cron` 스텝(step) 값도 포함한다. 이 내용은
[FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
> 스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 `/<number>` 를
> 지정하여 범위 내에서 숫자만큼의 값을 건너뛴다. 예를 들어,
> 시간 필드에 `0-23/2` 를 사용하여 매 2시간마다 명령 실행을
> 지정할 수 있다(V7 표준의 대안은 `0,2,4,6,8,10,12,14,16,18,20,22`
> 이다). 별표(asterisk) 뒤에 붙이는 스텝도 허용되며,
> "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다.
{{< note >}}
스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
{{< /note >}}
### 잡 템플릿
`.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다.
### 시작 기한
`.spec.startingDeadlineSeconds` 필드는 선택 사항이다.
어떤 이유로든 스케줄된 시간을 놓친 경우 잡의 시작 기한을 초 단위로 나타낸다.
기한이 지나면, 크론 잡이 잡을 시작하지 않는다.
이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
이 필드를 지정하지 않으면, 잡에 기한이 없다.
크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. `.spec.startingDeadlineSeconds` 이 설정되지 않았다면, 크론잡 컨트롤러는 `status.lastScheduleTime` 부터 지금까지 누락된 스케줄을 계산한다.
예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 `status.lastScheduleTime` 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다.
`.spec.startingDeadlineSeconds` 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 `.spec.startingDeadlineSeconds` 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다.
예를 들어, `200` 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다.
### 동시성 정책
`.spec.concurrencyPolicy` 필드도 선택 사항이다.
이것은 이 크론 잡에 의해 생성된 잡의 동시 실행을 처리하는 방법을 지정한다.
명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
* `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
### 일시 정지
`.spec.suspend` 필드도 선택 사항이다.
`true` 로 설정되면, 모든 후속 실행이 일시 정지된다.
이 설정은 이미 시작된 실행에는 적용되지 않는다.
기본값은 false이다.
{{< caution >}}
스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
{{< /caution >}}
### 잡 히스토리 한도
`.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다.
이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md
+233
View File
@@ -0,0 +1,233 @@
---
title: 작업 대기열을 사용한 정밀 병렬 처리
content_type: task
min-kubernetes-server-version: v1.8
weight: 40
---
<!-- overview -->
이 예에서는, 지정된 파드에서 여러 병렬 워커 프로세스가 있는
쿠버네티스 잡(Job)을 실행한다.
이 예에서는, 각 파드가 생성될 때, 작업 대기열에서 하나의 작업 단위를
선택하여, 처리하고, 대기열이 비워질 때까지 반복한다.
이 예에서의 단계에 대한 개요는 다음과 같다.
1. **작업 대기열을 보관할 스토리지 서비스를 시작한다.** 이 예에서는, Redis를 사용하여
작업 항목을 저장한다. 이전 예에서는, RabbitMQ를 사용했다. 이 예에서는, AMQP가 길이가
정해져 있는 작업 대기열이 비어있을 때 클라이언트가 이를 감지할 수 있는 좋은 방법을 제공하지
않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 이
예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
[잡](/ko/docs/concepts/workloads/controllers/job/)의 기본적이고,
병렬 작업이 아닌, 사용법에 대해 잘 알고 있어야 한다.
<!-- steps -->
## Redis 시작
이 문서의 예시에서는, 단순함을 위해, Redis의 단일 인스턴스를 시작한다.
Redis를 확장 가능하고 중복적으로 배포하는 예에 대해서는
[Redis 예시](https://github.com/kubernetes/examples/tree/master/guestbook)를 참고한다.
다음 파일을 직접 다운로드할 수도 있다.
- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
- [`Dockerfile`](/examples/application/job/redis/Dockerfile)
- [`job.yaml`](/examples/application/job/redis/job.yaml)
- [`rediswq.py`](/examples/application/job/redis/rediswq.py)
- [`worker.py`](/examples/application/job/redis/worker.py)
## 작업으로 대기열 채우기
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제의 작업은 문자열을 출력하는
것이다.
Redis CLI를 실행하기 위한 임시 대화형 파드를 시작한다.
```shell
kubectl run -i --tty temp --image redis --command "/bin/sh"
Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
Hit enter for command prompt
```
이제 엔터 키를 누르고, redis CLI를 시작하고, 몇몇 작업 항목이 포함된 목록을 생성한다.
```
# redis-cli -h redis
redis:6379> rpush job2 "apple"
(integer) 1
redis:6379> rpush job2 "banana"
(integer) 2
redis:6379> rpush job2 "cherry"
(integer) 3
redis:6379> rpush job2 "date"
(integer) 4
redis:6379> rpush job2 "fig"
(integer) 5
redis:6379> rpush job2 "grape"
(integer) 6
redis:6379> rpush job2 "lemon"
(integer) 7
redis:6379> rpush job2 "melon"
(integer) 8
redis:6379> rpush job2 "orange"
(integer) 9
redis:6379> lrange job2 0 -1
1) "apple"
2) "banana"
3) "cherry"
4) "date"
5) "fig"
6) "grape"
7) "lemon"
8) "melon"
9) "orange"
```
자, 키 `job2` 가 있는 목록이 작업 대기열이 된다.
참고: Kube DNS를 올바르게 설정하지 않은 경우, 위 블록의
첫 번째 단계를 `redis-cli -h $REDIS_SERVICE_HOST` 로 변경해야 할 수 있다.
## 이미지 생성
이제 실행할 이미지를 만들 준비가 되었다.
redis 클라이언트와 함께 python 워커 프로그램을 사용하여
메시지 큐에서 메시지를 읽는다.
rediswq.py([다운로드](/examples/application/job/redis/rediswq.py))라는
간단한 Redis 작업 대기열 클라이언트 라이브러리가 제공된다.
잡의 각 파드에 있는 "워커" 프로그램은 작업 대기열
클라이언트 라이브러리를 사용하여 작업을 가져온다. 다음은 워커 프로그램이다.
{{< codenew language="python" file="application/job/redis/worker.py" >}}
[`worker.py`](/examples/application/job/redis/worker.py),
[`rediswq.py`](/examples/application/job/redis/rediswq.py) 및
[`Dockerfile`](/examples/application/job/redis/Dockerfile) 파일을 다운로드할 수 있고, 그런 다음
이미지를 만들 수도 있다.
```shell
docker build -t job-wq-2 .
```
### 이미지 푸시
[도커 허브(Docker Hub)](https://hub.docker.com/)를 위해, 아래 명령으로
사용자의 username과 앱 이미지에 태그하고 허브에 푸시한다. `<username>` 을
사용자의 허브 username으로 바꾼다.
```shell
docker tag job-wq-2 <username>/job-wq-2
docker push <username>/job-wq-2
```
공용 저장소로 푸시하거나 [개인 저장소에 접근할 수 있도록
클러스터를 구성](/ko/docs/concepts/containers/images/)해야 한다.
[Google Container
Registry](https://cloud.google.com/tools/container-registry/)를 사용하는 경우,
사용자의 프로젝트 ID로 앱 이미지에 태그를 지정하고 GCR로 푸시한다. `<project>` 를
사용자의 프로젝트 ID로 바꾼다.
```shell
docker tag job-wq-2 gcr.io/<project>/job-wq-2
gcloud docker -- push gcr.io/<project>/job-wq-2
```
## 잡 정의
다음은 잡 정의이다.
{{< codenew file="application/job/redis/job.yaml" >}}
사용자 자신의 경로로 `gcr.io/myproject` 를
변경하려면 잡 템플릿을 편집해야 한다.
이 예에서, 각 파드는 대기열의 여러 항목에 대해 작업한 다음 더 이상 항목이 없을 때 종료된다.
워커는 작업 대기열이 비어있을 때를 감지하고 잡 컨트롤러는 작업 대기열에 대해
알지 못하기 때문에, 작업이 완료되면 워커에게 신호를 보낸다.
워커는 성공적으로 종료하여 대기열이 비어 있음을 알린다. 따라서, 워커가 성공적으로
종료하자마자, 컨트롤러는 작업이 완료되었음을 인식하고, 파드가 곧 종료된다.
따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지
기다린다.
## 잡 실행
이제 잡을 실행한다.
```shell
kubectl apply -f ./job.yaml
```
이제 조금 기다린 다음, 잡을 확인한다.
```shell
kubectl describe jobs/job-wq-2
Name: job-wq-2
Namespace: default
Selector: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
job-name=job-wq-2
Annotations: <none>
Parallelism: 2
Completions: <unset>
Start Time: Mon, 11 Jan 2016 17:07:59 -0800
Pods Statuses: 1 Running / 0 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
job-name=job-wq-2
Containers:
c:
Image: gcr.io/exampleproject/job-wq-2
Port:
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1 {job-controller } Normal SuccessfulCreate Created pod: job-wq-2-lglf8
kubectl logs pods/job-wq-2-7r7b2
Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
Initial queue state: empty=False
Working on banana
Working on date
Working on lemon
```
보시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다.
<!-- discussion -->
## 대안
대기열 서비스를 실행하거나 작업 대기열을 사용하도록 컨테이너를 수정하는 것이 불편한 경우, 다른
[잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)
중 하나를 고려할 수 있다.
만약 실행할 백그라운드 처리 작업의 연속 스트림이 있는 경우,
`ReplicaSet` 이 있는 백그라운드 워커를 실행하는 것과,
[https://github.com/resque/resque](https://github.com/resque/resque)와 같은
백그라운드 처리 라이브러리를 실행하는 것이 좋다.
content/ko/docs/tasks/network/validate-dual-stack.md
-1
View File
@@ -13,7 +13,6 @@ content_type: task
* 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico)
* IPVS 모드로 구동되는 Kube-proxy
* [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
{{< version-check >}}
content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
+1 -1
View File
@@ -47,7 +47,7 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
동적 프로비저너에 의해서 충족된다.
참고: config yaml 파일에 정의된 비밀번호는 안전하지 않다. 더 안전한 해결방법을 위해
[쿠버네티스 시크릿](/docs/concepts/configuration/secret/)
[쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
을 보자
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
content/ko/docs/tasks/tools/_index.md
+2 -2
View File
@@ -25,10 +25,10 @@ no_list: true
공식 사이트에서의 [시작하기!](https://minikube.sigs.k8s.io/docs/start/)
가이드를 따라 해볼 수 있고, 또는 도구 설치에 중점을 두고 있다면
[Minikube 설치](/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.
[Minikube 설치](/ko/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.
Minikube가 작동하면, 이를 사용하여
[샘플 애플리케이션을 실행](/docs/tutorials/hello-minikube/)해볼 수 있다.
[샘플 애플리케이션을 실행](/ko/docs/tutorials/hello-minikube/)해볼 수 있다.
## kind
content/ko/docs/tasks/tools/install-kubectl.md
+1 -1
View File
@@ -523,7 +523,7 @@ compinit
* [Minikube 설치](/ko/docs/tasks/tools/install-minikube/)
* 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다.
* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 직접 생성하지 않은 클러스터에 접근해야하는 경우,
[클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
* [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기