Third Korean l10n work for release-1.19
- Fix issue with broken links in ko documents (#24190) - Fix issue with links to already translated ko documents (#24158) - Translate docs/reference/kubectl/docker-cli-to-kubectl/ into Korean (#24131) - Translate docs/setup/production-environment/tools/kubespray.md in Korean (#24144) - Translated titles into korean (#24394) - DNS subdomain translation corrected (#24393) - Update ko/docs/concepts/overview/working-with-objects/common-labels/ (#24370) - Translate tasks/job/coarse-parallel-processing-work-queue in Korean (#24218) - Update outdated files in the dev-1.19-ko.3 branch (#24151) - Add missing dot on job.md (#24084) Co-authored-by: chhanz <han0495@gmail.com> Co-authored-by: Yuuraa <yoorachoi8937@gmail.com> Co-authored-by: sushil <sushilktiwari.st@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> Co-authored-by: Jonghun Park <jonghun.park.194@gmail.com> Co-authored-by: Leo <leo.lab001@gmail.com>
This commit is contained in:
June Yi
@@ -149,8 +149,8 @@ root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.
|
||||
|
||||
localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을
|
||||
요구하지 않지만 이는 표준이 아니다.
|
||||
[Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
|
||||
는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
|
||||
[API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은
|
||||
클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
|
||||
이 방식들은 미래의 고가용성 지원과 충돌될 수 있다.
|
||||
|
||||
## API에 프로그래밍 방식으로 접근
|
||||
@@ -218,7 +218,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
|
||||
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
|
||||
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
|
||||
[노드들](/ko/docs/concepts/architecture/nodes/),
|
||||
[파드들](/ko/docs/concepts/workloads/pods/pod/),
|
||||
[파드들](/ko/docs/concepts/workloads/pods/),
|
||||
[서비스들](/ko/docs/concepts/services-networking/service/)은
|
||||
모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
|
||||
클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
|
||||
@@ -375,4 +375,3 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
|
||||
|
||||
일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는
|
||||
나머지 타입을 적절하게 구성해줘야 한다.
|
||||
|
||||
|
||||
+1
-1
@@ -30,7 +30,7 @@ card:
|
||||
|
||||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
|
||||
`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
|
||||
[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
|
||||
[마이너 버전 하나 차이 이내](/docs/setup/release/version-skew-policy/#kubectl)여야
|
||||
한다.
|
||||
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 30
|
||||
title: Use the Web UI Dashboard
|
||||
title: 웹 UI 대시보드 사용
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -52,7 +52,7 @@ kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
kubectl은 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
|
||||
kubectl은 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/)에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
|
||||
|
||||
UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다.
|
||||
|
||||
@@ -170,7 +170,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
|
||||
커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
|
||||
|
||||
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이
|
||||
[특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의
|
||||
[특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/#컨테이너에-대한-특권-모드)의
|
||||
프로세스들과 동등한지 아닌지 정의한다.
|
||||
특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
|
||||
|
||||
|
||||
@@ -148,7 +148,7 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한
|
||||
|
||||
일부 클러스터에서, API 서버는 인증이 필요하지 않다.
|
||||
로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
|
||||
없다. [API에 대한 접근 구성](/docs/reference/access-authn-authz/controlling-access/)은
|
||||
없다. [API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은
|
||||
클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
|
||||
고 가용성 지원과 충돌할 수 있다.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ content_type: task
|
||||
## 클러스터에서 실행되는 서비스에 접근
|
||||
|
||||
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
|
||||
[파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
|
||||
[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
|
||||
고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
|
||||
없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
|
||||
도달할 수 없다.
|
||||
|
||||
+1
-1
@@ -69,7 +69,7 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예,
|
||||
## 실리움을 실 서비스 용도로 배포하기
|
||||
|
||||
실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
|
||||
[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/kubernetes/intro/)를 살펴본다.
|
||||
[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)를 살펴본다.
|
||||
이 문서는 자세한 요구사항, 방법과
|
||||
실제 데몬셋 예시를 포함한다.
|
||||
|
||||
|
||||
+2
-2
@@ -17,12 +17,12 @@ weight: 50
|
||||
|
||||
## Weave Net 애드온을 설치한다
|
||||
|
||||
[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다.
|
||||
[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) 가이드를 따른다.
|
||||
|
||||
쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의
|
||||
네크워크 정책 어노테이션을 자동으로 모니터링하며,
|
||||
정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는
|
||||
[네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다.
|
||||
[네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc)와 함께 제공된다.
|
||||
|
||||
## 설치 시험
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ title: 리소스 모니터링 도구
|
||||
|
||||
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
|
||||
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
|
||||
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
|
||||
컨테이너, [파드](/ko/docs/concepts/workloads/pods/),
|
||||
[서비스](/ko/docs/concepts/services-networking/service),
|
||||
그리고 전체 클러스터의 특성을 검사하여
|
||||
쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
|
||||
|
||||
@@ -0,0 +1,328 @@
|
||||
---
|
||||
title: 작업 대기열을 사용한 거친 병렬 처리
|
||||
min-kubernetes-server-version: v1.8
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 예제에서는, 여러 병렬 워커 프로세스를 활용해 쿠버네티스 잡(Job)을
|
||||
실행한다.
|
||||
|
||||
이 예제에서는, 각 파드가 생성될 때 작업 대기열에서 하나의 작업 단위를
|
||||
선택하여, 완료하고, 대기열에서 삭제하고, 종료한다.
|
||||
|
||||
이 예제에서의 단계에 대한 개요는 다음과 같다.
|
||||
|
||||
1. **메시지 대기열 서비스를 시작한다.** 이 예에서는, RabbitMQ를 사용하지만, 다른 메시지 대기열을 이용해도
|
||||
된다. 실제로 사용할 때는, 한 번 메시지 대기열 서비스를 구축하고서 이를 여러 잡을 위해 재사용하기도 한다.
|
||||
1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다.
|
||||
이 예제에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
|
||||
1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는
|
||||
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
기본적이고, 병렬 작업이 아닌,
|
||||
[잡](/ko/docs/concepts/workloads/controllers/job/)의 사용법에 대해 잘 알고 있어야 한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 메시지 대기열 서비스 시작
|
||||
|
||||
이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다.
|
||||
|
||||
실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번
|
||||
구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다.
|
||||
|
||||
다음과 같이 RabbitMQ를 시작한다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-service.yaml
|
||||
```
|
||||
```
|
||||
service "rabbitmq-service" created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-controller.yaml
|
||||
```
|
||||
```
|
||||
replicationcontroller "rabbitmq-controller" created
|
||||
```
|
||||
|
||||
이 문서에서는 [celery-rabbitmq 예제](https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/celery-rabbitmq)에 나오는 정도로만 rabbitmq를 사용한다.
|
||||
|
||||
## 메시지 대기열 서비스 테스트하기
|
||||
|
||||
이제, 메시지 대기열을 이용해 실험할 수 있다. 임시
|
||||
대화형 파드를 만들어 그 위에 도구들을 설치하고,
|
||||
대기열을 실험해본다.
|
||||
|
||||
먼저 임시 대화형 파드를 만든다.
|
||||
|
||||
```shell
|
||||
# 임시 대화형 컨테이너를 만든다.
|
||||
kubectl run -i --tty temp --image ubuntu:18.04
|
||||
```
|
||||
```
|
||||
Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false
|
||||
... [ previous line repeats several times .. hit return when it stops ] ...
|
||||
```
|
||||
|
||||
참고로 파드 이름과 명령 프롬프트는 위와 다를 수 있다.
|
||||
|
||||
다음으로 `amqp-tools`를 설치하여 메시지 대기열을 활용할 수 있게 한다.
|
||||
|
||||
```shell
|
||||
# 도구들을 설치한다.
|
||||
root@temp-loe07:/# apt-get update
|
||||
.... [ lots of output ] ....
|
||||
root@temp-loe07:/# apt-get install -y curl ca-certificates amqp-tools python dnsutils
|
||||
.... [ lots of output ] ....
|
||||
```
|
||||
|
||||
후에, 이 패키지들을 포함하는 도커 이미지를 만든다.
|
||||
|
||||
다음으로, rabbitmq 서비스를 발견할 수 있는지 확인한다.
|
||||
|
||||
```
|
||||
# rabbitmq-service가 쿠버네티스로부터 주어진 DNS 이름을 갖는다.
|
||||
|
||||
root@temp-loe07:/# nslookup rabbitmq-service
|
||||
Server: 10.0.0.10
|
||||
Address: 10.0.0.10#53
|
||||
|
||||
Name: rabbitmq-service.default.svc.cluster.local
|
||||
Address: 10.0.147.152
|
||||
|
||||
# 주소는 다를 수 있다.
|
||||
```
|
||||
|
||||
만약 Kube-DNS가 적절히 구축되지 않았다면, 전 단계 작업이 작동하지 않을 수 있다.
|
||||
환경 변수를 통해서도 서비스 IP를 찾을 수 있다.
|
||||
|
||||
```
|
||||
# env | grep RABBIT | grep HOST
|
||||
RABBITMQ_SERVICE_SERVICE_HOST=10.0.147.152
|
||||
# 주소는 다를 수 있다.
|
||||
```
|
||||
|
||||
다음으로 대기열을 생성하고, 메시지를 발행하고 사용할 수 있는지 확인한다.
|
||||
|
||||
```shell
|
||||
# 다음 줄에서, rabbitmq-service는 rabbitmq-service에 접근할 수 있는
|
||||
# 호스트네임이다. 5672는 rabbitmq의 표준 포트이다.
|
||||
|
||||
root@temp-loe07:/# export BROKER_URL=amqp://guest:guest@rabbitmq-service:5672
|
||||
# 만약 전 단계에서 "rabbitmq-service"가 주소로 변환되지 않는다면,
|
||||
# 이 커맨드를 대신 사용하면 된다.
|
||||
# root@temp-loe07:/# BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672
|
||||
|
||||
# 이제 대기열을 생성한다.
|
||||
|
||||
root@temp-loe07:/# /usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo -d
|
||||
foo
|
||||
|
||||
# 대기열에 메시지를 하나 발행한다.
|
||||
|
||||
root@temp-loe07:/# /usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b Hello
|
||||
|
||||
# 다시 메시지를 돌려받는다.
|
||||
|
||||
root@temp-loe07:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && echo
|
||||
Hello
|
||||
root@temp-loe07:/#
|
||||
```
|
||||
|
||||
마지막 커맨드에서, `amqp-consume` 도구는 대기열로부터 하나의 메시지를
|
||||
받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터
|
||||
받은 값을 바로 출력하고 있고, echo가 캐리지 리턴을 더해주어
|
||||
출력 결과가 보여진다.
|
||||
|
||||
## 작업으로 대기열 채우기
|
||||
|
||||
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을
|
||||
출력하는 것이다.
|
||||
|
||||
실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다.
|
||||
|
||||
- 처리되어야 하는 파일들의 이름
|
||||
- 프로그램의 추가 플래그
|
||||
- 데이터베이스 테이블의 키(key) 범위
|
||||
- 시뮬레이션의 구성 파라미터
|
||||
- 렌더링해야 하는 씬(scene)의 프레임 번호
|
||||
|
||||
실제로는, 잡의 모든 파드에서 읽기-전용 모드로 필요한 큰 데이터가
|
||||
있다면, 일반적으로 그 데이터를 NFS와 같은 공유 파일시스템에 넣고
|
||||
모든 파드에 읽기 전용으로 마운트하거나, 파드 안에 있는 프로그램이 기본적으로 HDFS와 같은
|
||||
클러스터 파일시스템으로부터 데이터를 불러들인다.
|
||||
|
||||
본 예제에서는, 대기열을 만들고 amqp 커맨드라인 도구를 이용해 대기열을 채울 것이다.
|
||||
실제로는, amqp 라이브러리를 이용해 대기열을 채우는 프로그램을 작성하게 된다.
|
||||
|
||||
```shell
|
||||
/usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1 -d
|
||||
job1
|
||||
```
|
||||
```shell
|
||||
for f in apple banana cherry date fig grape lemon melon
|
||||
do
|
||||
/usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $f
|
||||
done
|
||||
```
|
||||
|
||||
8개의 메시지로 대기열을 채웠다.
|
||||
|
||||
## 이미지 생성
|
||||
|
||||
이제 잡으로 실행할 이미지를 만들 준비가 되었다.
|
||||
|
||||
`amqp-consume` 유틸리티를 이용해 대기열로부터 메시지를 읽고,
|
||||
실제 프로그램을 실행해 볼 것이다.
|
||||
여기에 아주 간단한 예제 프로그램이 있다.
|
||||
|
||||
{{< codenew language="python" file="application/job/rabbitmq/worker.py" >}}
|
||||
|
||||
스크립트에 실행 권한을 준다.
|
||||
|
||||
```shell
|
||||
chmod +x worker.py
|
||||
```
|
||||
|
||||
이제 이미지를 빌드한다. 만약 소스 트리 안에서 작업하고
|
||||
있다면, `examples/job/work-queue-1`로 디렉터리를 옮긴다.
|
||||
아니면, 임시 디렉터리를 만들고, 그 디렉터리로 옮긴다.
|
||||
[Dockerfile](/examples/application/job/rabbitmq/Dockerfile)과
|
||||
[worker.py](/examples/application/job/rabbitmq/worker.py)를 다운로드한다.
|
||||
위 두 경우 모두, 다음의 명령을 이용해 이미지를 빌드한다.
|
||||
|
||||
```shell
|
||||
docker build -t job-wq-1 .
|
||||
```
|
||||
|
||||
[도커 허브](https://hub.docker.com/)를 이용하기 위해, 앱 이미지를
|
||||
사용자의 username으로 태깅하고 아래의 명령어를 이용해 허브에 푸시한다.
|
||||
`<username>`을 사용자의 허브 username으로 대체한다.
|
||||
|
||||
```shell
|
||||
docker tag job-wq-1 <username>/job-wq-1
|
||||
docker push <username>/job-wq-1
|
||||
```
|
||||
|
||||
만약 [구글 컨테이너
|
||||
레지스트리](https://cloud.google.com/tools/container-registry/)를 이용하고 있다면,
|
||||
앱 이미지를 사용자의 프로젝트 ID를 이용해 태깅하고, GCR에 푸시한다.
|
||||
`<proejct>` 부분을 사용자의 프로젝트 ID로 대체한다.
|
||||
|
||||
```shell
|
||||
docker tag job-wq-1 gcr.io/<project>/job-wq-1
|
||||
gcloud docker -- push gcr.io/<project>/job-wq-1
|
||||
```
|
||||
|
||||
## 잡 정의
|
||||
|
||||
다음은 잡 정의이다. 잡의 사본을 만들고 위에서 정한 이름에 맞게
|
||||
이미지를 수정하고, 파일 이름을 `./job.yaml`이라 정한다.
|
||||
|
||||
|
||||
{{< codenew file="application/job/rabbitmq/job.yaml" >}}
|
||||
|
||||
이 예시에서는, 각 파드가 대기열로부터 얻은 하나의 아이템을 수행하고 종료한다.
|
||||
그래서, 잡의 완료 횟수가 완료된 작업 아이템의 숫자에 대응한다.
|
||||
예시에서 `.spec.completions: 8`이라 정한 것도, 대기열에 8개의 아이템을 넣었기 때문이다.
|
||||
|
||||
## 잡 실행
|
||||
|
||||
이제 잡을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./job.yaml
|
||||
```
|
||||
|
||||
이제 조금 기다린 다음, 잡을 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl describe jobs/job-wq-1
|
||||
```
|
||||
```
|
||||
Name: job-wq-1
|
||||
Namespace: default
|
||||
Selector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
|
||||
Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
|
||||
job-name=job-wq-1
|
||||
Annotations: <none>
|
||||
Parallelism: 2
|
||||
Completions: 8
|
||||
Start Time: Wed, 06 Sep 2017 16:42:02 +0800
|
||||
Pods Statuses: 0 Running / 8 Succeeded / 0 Failed
|
||||
Pod Template:
|
||||
Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
|
||||
job-name=job-wq-1
|
||||
Containers:
|
||||
c:
|
||||
Image: gcr.io/causal-jigsaw-637/job-wq-1
|
||||
Port:
|
||||
Environment:
|
||||
BROKER_URL: amqp://guest:guest@rabbitmq-service:5672
|
||||
QUEUE: job1
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
───────── ──────── ───── ──── ───────────── ────── ────── ───────
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-hcobb
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-weytj
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-qaam5
|
||||
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-b67sr
|
||||
26s 26s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-xe5hj
|
||||
15s 15s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-w2zqe
|
||||
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-d6ppa
|
||||
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0
|
||||
```
|
||||
|
||||
모든 파드가 성공했다. 야호.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 대안
|
||||
|
||||
이러한 접근은 "워커" 프로그램을 작업 대기열에 맞게 수정하지 않아도
|
||||
된다는 장점이 있다.
|
||||
|
||||
이 접근을 이용하려면, 메시지 대기열 서비스를 실행해야만 한다.
|
||||
만약 메시지 대기열 서비스를 실행하는 게 불편하다면,
|
||||
다른 [잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)을 고려해볼 수 있다.
|
||||
|
||||
이 접근은 모든 작업 아이템에 대해 파드를 생성한다. 만약 작업 아이템이 오직 몇 초밖에 걸리지 않는 작업이라면,
|
||||
매 작업마다 파드를 생성하는 것은 아주 큰 오버헤드를 더할 수 있다. 하나의 파드가
|
||||
여러 작업 아이템을 수행하는 이 [예제](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)를 고려해보자.
|
||||
|
||||
이 예제에서는, `amqp-consume` 유틸리티를 이용해 대기열로부터 메시지를 읽어
|
||||
실제 프로그램을 실행했다. 이러면 메시지 대기열을 이용하기 위해 프로그램을 수정하지
|
||||
않아도 된다는 장점이 있다.
|
||||
[다른 예제](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)는
|
||||
클라이언트 라이브러리를 이용해 작업 대기열과 소통하는 방법을 보여준다.
|
||||
|
||||
## 주의 사항
|
||||
|
||||
만약 작업 완료 수가 대기열에 있는 아이템의 숫자보다 적게 설정되면,
|
||||
모든 아이템 처리되지 않는다.
|
||||
|
||||
만약 작업 완료 수가 큐에 있는 아이템의 숫자보다 많게 설정되면,
|
||||
대기열에 있는 아이템이 모두 처리되어도, 잡이 완료됐다고 표시되지
|
||||
않고, 메시지를 기다리는 과정에서 막히는 파드를
|
||||
추가적으로 실행시킨다.
|
||||
|
||||
이 패턴에서는 경쟁 상태(race)가 잘 나타나지 않는다. 만약 amqp-consume 명령으로부터
|
||||
메시지가 인정되는 시간과 컨테이너가 성공적으로 종료되는
|
||||
시간 사이에 컨테이너가 종료되거나, kubelet이 api-server에게 파드가 성공했음을 알리기 전에
|
||||
노드가 비정상적으로 종료되면, 대기열의 모든 아이템이 처리되었다 해도,
|
||||
잡이 완료되었다고 표시되지 않는다.
|
||||
@@ -37,7 +37,7 @@ weight: 30
|
||||
지원한다. 쿠버네티스 오브젝트 타입에 익숙하지 않은 사용자가 인지할 수 있도록 커맨드
|
||||
이름이 지어졌다.
|
||||
|
||||
- `run`: 하나 이상의 파드 내 컨테이너를 실행하도록 새로운 디플로이먼트 오브젝트를 생성한다.
|
||||
- `run`: 컨테이너를 실행할 새로운 파드를 생성한다.
|
||||
- `expose`: 파드에 걸쳐 트래픽을 로드 밸런스하도록 새로운 서비스 오브젝트를 생성한다.
|
||||
- `autoscale`: 디플로이먼트와 같이, 하나의 컨트롤러에 대해 자동으로 수평적 스케일이 이루어 지도록 새로운 Autoscaler 오브젝트를 생성한다.
|
||||
|
||||
|
||||
@@ -64,6 +64,18 @@ weight: 40
|
||||
|
||||
* `kubectl delete -f <파일명|url>`
|
||||
|
||||
{{< note >}}
|
||||
구성 파일이 `metadata` 섹션에서 `name` 필드 대신 `generateName`
|
||||
필드를 지정한 경우, `kubectl delete -f <filename|url>` 을 사용하여
|
||||
오브젝트를 삭제할 수 없다.
|
||||
오브젝트를 삭제하려면 다른 플래그를 사용해야 한다. 예를 들면, 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl delete <type> <name>
|
||||
kubectl delete <type> -l <label>
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
## 오브젝트 확인 방법
|
||||
|
||||
구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 20
|
||||
<!-- overview -->
|
||||
|
||||
[Kustomize](https://github.com/kubernetes-sigs/kustomize)는
|
||||
[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을
|
||||
[kustomization 파일](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization)을
|
||||
통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다.
|
||||
|
||||
1.14 이후로, kubectl도
|
||||
|
||||
Reference in New Issue
Block a user