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

First Korean l10n work for release-1.19

Browse Source 
- Translate tasks/job/parallel-processing-expansion.md into Korean (#23544)
- Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720)
- Translate reference/scheduling/policies.md in Korean (#23690)
- Update outdated files in the dev-1.19-ko.1 branch (#23702)
- Modify translation access by Korean glossary (#23627)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
This commit is contained in:
June Yi
2020-09-11 23:21:22 +09:00
parent 94b2f857bb
commit 986be3462d
102 changed files with 1943 additions and 2452 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/_index.md
+1 -1
View File
@@ -12,4 +12,4 @@ content_type: concept
시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다.
만약 태스크 페이지를 작성하고 싶다면,
[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다.
[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/open-a-pr/)를 참조한다.
content/ko/docs/tasks/access-application-cluster/_index.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
title: "클러스터 내 어플리케이션 액세스"
title: "클러스터 내 어플리케이션 접근"
description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다.
weight: 60
---
content/ko/docs/tasks/access-application-cluster/access-cluster.md
+34 -33
View File
@@ -1,5 +1,5 @@
---
title: 클러스터 액세스
title: 클러스터 접근
weight: 20
content_type: concept
---
@@ -8,17 +8,14 @@ content_type: concept
여기에서는 클러스터와 통신을 하는 다양한 방식에 대해서 다룰 것이다.
<!-- body -->
## 처음이라면 kubectl을 사용하여 액세스
## 처음이라면 kubectl을 사용하여 접근
최초로 쿠버네티스 API에 액세스할 때 우리는
최초로 쿠버네티스 API에 접근할 때 우리는
쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다.
클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
클러스터에 접근하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
인증정보를 가져야 한다. 일반적으로 이는 당신이
[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나,
다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다.
@@ -29,14 +26,15 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
kubectl config view
```
많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며
완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다.
많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서
kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는
[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다.
## REST API에 직접 액세스
## REST API에 직접 접근
kubectl은 apiserver의 위치 파악과 인증을 처리한다.
만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로
REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
- kubectl을 proxy 모드로 실행.
- 권장하는 접근 방식.
@@ -155,7 +153,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터
는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
이 방식들은 미래의 고가용성 지원과 충돌될 수 있다.
## API에 프로그래밍 방식으로 액세스
## API에 프로그래밍 방식으로 접근
쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트)
클라이언트 라이브러리를 지원한다.
@@ -165,16 +163,16 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터
* 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다.
* client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다.
Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다.
[예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다.
만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-접근)을 참조하기를 바란다.
### Python 클라이언트
Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다.
Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다.
[예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다.
### 다른 언어
@@ -182,7 +180,7 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와
다른 언어에서 API를 접속하기 위한 [클라이언트 라이브러리들](/ko/docs/reference/using-api/client-libraries/)도 존재한다.
이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다.
## 파드에서 API 액세스
## 파드에서 API 접근
파드에서 API를 접속한다면 apiserver의
위치지정과 인증은 다소 다르다.
@@ -215,11 +213,13 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다.
## 클러스터에서 실행되는 서비스로 액세스
## 클러스터에서 실행되는 서비스로 접근
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은
[노드들](/ko/docs/concepts/architecture/nodes/),
[파드들](/ko/docs/concepts/workloads/pods/pod/),
[서비스들](/ko/docs/concepts/services-networking/service/)은
모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
할 수 없을 것이다.
@@ -228,9 +228,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다.
- 공인 IP를 통해 서비스에 액세스.
- 공인 IP를 통해 서비스에 접근.
- 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
서비스를 사용한다. [서비스](/docs/user-guide/services)와
서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
- 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나
인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
@@ -238,19 +238,19 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
- 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다.
- 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
액세스할 필요는 없다.
- Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스.
- 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
접근할 필요는 없다.
- Proxy Verb를 사용하여 서비스, 노드, 파드에 접근.
- 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에
액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다.
접근을 하려고 하거나 debugging을 하려면 이를 사용한다.
- 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다.
- HTTP/HTTPS에서만 동작한다.
- [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
- 클러스터 내 노드 또는 파드에서 액세스.
- 클러스터 내 노드 또는 파드에서 접근.
- 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다.
- 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
### 빌트인 서비스들의 발견
@@ -273,10 +273,10 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
```
이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다.
이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다.
예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다.
`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다.
(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
#### 수작업으로 apiserver proxy URL을 구축
@@ -298,8 +298,8 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
##### 예제들
* Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
* Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
```json
{
@@ -316,7 +316,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
}
```
### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 액세스
### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근
브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만
@@ -333,7 +333,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다.
1. [kubectl proxy](#rest-api에-직접-액세스):
1. [kubectl proxy](#rest-api에-직접-접근):
- 사용자의 데스크탑이나 파드 내에서 실행한다
- localhost 주소에서 쿠버네티스 apiserver로 proxy한다
@@ -375,3 +375,4 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는
나머지 타입을 적절하게 구성해줘야 한다.
content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+13 -23
View File
@@ -6,20 +6,15 @@ weight: 110
<!-- overview -->
이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지
살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자.
이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에,
어떻게 볼륨을 이용하는지 살펴본다. 컨테이너 간에
[프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를
통해 통신할 수 있는 방법을 참고하자.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 두 개의 컨테이너를 실행하는 파드 생성
@@ -103,14 +98,15 @@ nginx 컨테이너의 쉘(shell)을 실행한다.
Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 디렉터리에 `index.html` 파일을 생성했었음을 상기하자.
`curl`을 이용하여 nginx 웹 서버에 HTTP GET 요청을 보낸다.
root@two-containers:/# curl localhost
```
root@two-containers:/# curl localhost
```
출력을 보면, nginx 웹 서버에서 debian 컨테이너에서 쓰여진 웹 페이지를 제공하는 것을 알 수 있다.
debian 컨테이너에서 안녕하세요
```
debian 컨테이너에서 안녕하세요
```
<!-- discussion -->
@@ -127,20 +123,14 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트
이 예제에서 볼륨은 파드의 생명 주기 동안 컨테이너를 위한 통신 방법으로 이용했다.
파드가 삭제되고 재생성되면, 공유 볼륨에 저장된 데이터는 잃어버린다.
## {{% heading "whatsnext" %}}
* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여
더 공부한다.
* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 더 공부한다.
* [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여
더 공부한다.
* [모듈 구조를 위한 합성 컨테이너 구조](https://www.slideshare.net/Docker/slideshare-burns)에 관하여 더 공부한다.
* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여
확인한다.
* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 확인한다.
* [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다.
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+114 -37
View File
@@ -10,15 +10,19 @@ card:
<!-- overview -->
대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다.
대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고,
컨테이너화 된 애플리케이션을 트러블슈팅할 수 있으며, 클러스터 리소스들을 관리할 수 있다.
대시보드를 통해 클러스터에서 동작 중인 애플리케이션의 정보를 볼 수 있고,
개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등)
생성하거나 수정할 수 있다.
예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나
또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다.
![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png)
<!-- body -->
## 대시보드 UI 배포
@@ -32,7 +36,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a
## 대시보드 UI 접근
클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다.
현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다.
본 시연을 위한 토큰을 생성하기 위해서는,
[샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
{{< warning >}}
시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다.
@@ -55,13 +62,17 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
## 웰컴 뷰
초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. 이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. 게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` [네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다.
이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다.
게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system`
[네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png)
## 컨테이너화 된 애플리케이션 배포
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다.
애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드할 수 있다.
시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
@@ -69,17 +80,29 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
배포 마법사는 다음 정보를 제공한다.
- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
- **앱 이름** (필수): 애플리케이션 이름.
[레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은
배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다.
소문자로 시작해야 하며, 소문자 또는 숫자로 끝나고,
소문자, 숫자 및 대쉬(-)만을 포함해야 한다. 24 문자만을 제한한다.
처음과 끝의 스페이스는 무시된다.
- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다.
- **컨테이너 이미지** (필수):
레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/)
또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL.
컨테이너 이미지 사양은 콜론으로 끝난다.
- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다.
- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수.
값은 양의 정수만 허용됩니다.
클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
클러스터에 의도한 파드의 수를 유지하기 위해서
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다.
- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의
퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를
노출시키고 싶을 수 있다.
{{< note >}}
외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다.
@@ -87,13 +110,22 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다.
서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면,
두 개의 포트를 정의해야 한다.
서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다.
서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다.
서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
- **설명**: 입력하는 텍스트값은 디플로이먼트에
[어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로
추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은
애플리케이션 이름과 버전이다.
릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를
생성할 때 추가적으로 정의할 수 있다.
예를 들면:
@@ -104,66 +136,111 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
track=stable
```
- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다.
- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다.
이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다.
논리적으로 명명된 그룹으로 리소스들을 분할할 수 있다.
대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
네임스페이스 이름은 숫자로만 구성할 수 없다. 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다.
네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
네임스페이스 이름은 숫자로만 구성할 수 없다.
만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다.
만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다.
- **이미지 풀(Pull) 시크릿**:
특정 도커 컨테이너 이미지가 프라이빗한 경우,
[풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 자격 증명을 요구한다.
대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다.
대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성할 수 있도록 한다.
시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다.
시크릿 내용은 base64 인코딩 방식이며,
[`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다.
시크릿 이름은 최대 253 문자를 포함할 수 있다.
이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**:
컨테이너를 위한 최소 [리소스 상한](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)을
정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
- **커맨드 실행** 와 **커맨드 인수 실행**:
기본적으로, 컨테이너는 선택된 도커 이미지의
[기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다.
커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이
[특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의
프로세스들과 동등한지 아닌지 정의한다.
특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
- **환경 변수**: 쿠버네티스 서비스를
[환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다.
애플리케이션들이 서비스를 찾는데 사용된다.
값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
### YAML 또는 JSON 파일 업로드
쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
쿠버네티스는 선언적인 설정을 제공한다.
이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를
이용하여 YAML 또는 JSON 설정 파일에 저장한다.
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신,
애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
## 대시보드 사용
다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
### 탐색
클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다.
기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데,
이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
#### 어드민 개요
클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다.
노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다.
세부사항은 각 노드들에 대한 사용량, 사양, 상태,
할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
#### 워크로드
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고
각각의 워크로드 종류는 따로 보여진다.
리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
워크로드에 대한 실용적인 정보를 요약한다.
워크로드에 대한 세부적인 것들은 상태와 사양 정보,
오프젝트들 간의 관계를 보여준다.
예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
#### 서비스
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는
쿠버네티스 리소스들을 보여준다.
이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과
외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
#### 스토리지
스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
#### 컨피그 맵과 시크릿
클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다.
컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
#### 로그 뷰어
파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. 뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다.
뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
## {{% heading "whatsnext" %}}
content/ko/docs/tasks/administer-cluster/access-cluster-api.md
+6 -9
View File
@@ -6,13 +6,10 @@ content_type: task
<!-- overview -->
이 페이지는 쿠버네티스 API를 사용하여 클러스터에 접근하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 쿠버네티스 API에 접근
@@ -170,7 +167,7 @@ client-go는 자체 API 오브젝트를 정의하므로, 필요한 경우, 기
{{< /note >}}
Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
사용할 수 있다. 이 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
```golang
@@ -199,7 +196,7 @@ func main() {
[Python 클라이언트](https://github.com/kubernetes-client/python)를 사용하려면, 다음 명령을 실행한다. `pip install kubernetes` 추가 설치 옵션은 [Python Client Library 페이지](https://github.com/kubernetes-client/python)를 참고한다.
Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)를 참고한다.
```python
@@ -229,7 +226,7 @@ mvn install
어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)를 참고한다.
Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)를 참고한다.
```java
@@ -283,7 +280,7 @@ public class KubeConfigFileClientExample {
[dotnet 클라이언트](https://github.com/kubernetes-client/csharp)를 사용하려면, 다음 명령을 실행한다. `dotnet add package KubernetesClient --version 1.6.1` 추가 설치 옵션은 [dotnet Client Library 페이지](https://github.com/kubernetes-client/csharp)를 참고한다. 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)를 참고한다.
dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs)를 참고한다.
```csharp
@@ -318,7 +315,7 @@ namespace simple
[JavaScript 클라이언트](https://github.com/kubernetes-client/javascript)를 설치하려면, 다음 명령을 실행한다. `npm install @kubernetes/client-node` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)를 참고한다.
JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)를 참고한다.
```javascript
@@ -387,7 +384,7 @@ exampleWithKubeConfig = do
호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
이를 자동으로 수행한다.
API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/user-guide/service-accounts)
API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
자격 증명을 사용하는 것이다. 기본적으로, 파드는
서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
해당 파드에 있는 각 컨테이너의 파일시스템 트리의
content/ko/docs/tasks/administer-cluster/access-cluster-services.md
+2 -1
View File
@@ -17,7 +17,8 @@ content_type: task
## 클러스터에서 실행되는 서비스에 접근
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
[파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
도달할 수 없다.
content/ko/docs/tasks/administer-cluster/cluster-management.md
+18 -22
View File
@@ -10,9 +10,6 @@ content_type: concept
노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
쿠버네티스 API 버전 업그레이드.
<!-- body -->
## 클러스터 생성과 설정
@@ -77,24 +74,33 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레
* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
* ...
위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) 페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다.
위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order)
페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다.
## 클러스터 크기 재조정
[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인
클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다.
GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면
`Compute > Compute Engine > Instance groups > your group > Edit group`에서
인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
```shell
gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
```
인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에 Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다. 사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다.
인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에
Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다.
사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다.
다른 환경에서는 사용자가 직접 머신을 구성하고 어떤 머신에서 API 서버가 동작하는지를 Kubelet에 알려줘야 할 수도 있다.
### Azure Kubernetes Service (AKS) 클러스터 크기 재조정
Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서 이를 설명하고 있다.
Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며
[Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서
이를 설명하고 있다.
### 클러스터 오토스케일링
@@ -102,7 +108,8 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터
GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
재조정하도록 클러스터를 구성할 수 있다.
[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼
사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.
@@ -181,22 +188,11 @@ kubectl uncordon $NODENAME
해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.)
상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
## 고급 주제들
### 다른 API 버전으로 업그레이드
신규 API 버전이 릴리스 되었을 때, 해당 신규 API 버전을 지원하려면 클러스터를 업그레이드해야 할 수 있다.(예. 'v2'가 출시되었을 때 'v1'에서 'v2'로 변경)
이는 드문 경우지만 세심한 관리가 요구된다. 신규 API 버전으로 업그레이드하는데는 일련의 과정이 존재한다.
1. 신규 API 버전을 ON한다.
1. 신규 버전을 사용하도록 클러스터의 스토리지를 업그레이드한다.
1. 모든 구성 파일들을 업그레이드한다. 구식 API 버전 엔드포인트의 사용자들을 식별한다.
1. `cluster/update-storage-objects.sh`을 실행하여 스토리지 내에 기존 객체들을 신규 버전으로 업데이트한다.
1. 구식 API 버전을 OFF한다.
### 클러스터에서 API 버전을 ON/OFF 하기
특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
+15 -15
View File
@@ -5,16 +5,16 @@ min-kubernetes-server-version: v1.12
---
<!-- overview -->
이 페이지는 클러스터 안에서 사용자의
DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고
이 페이지는 클러스터 안에서 사용자의
DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고
DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기)
클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기)
는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다.
{{% version-check %}}
@@ -23,11 +23,11 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
## 소개
DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
사용하여 자동으로 시작되는 쿠버네티스
DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
사용하여 자동으로 시작되는 쿠버네티스
내장 서비스이다.
쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
{{< note >}}
@@ -35,19 +35,19 @@ CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로
이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
{{< /note >}}
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를
DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를
통하여 로컬 도메인을 설정할 수 있다.
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다.
더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우,
만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우,
파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다.
파드의 DNS 변환도 노드와 동일하게 작동해야 한다.
그 외에는 [알려진 이슈](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참고한다.
그 외에는 [알려진 이슈](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues)를 참고한다.
만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우,
사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다.
@@ -63,7 +63,7 @@ CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/speci
CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다.
클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
해당 클러스터에 대한 DNS 서비스 검색 동작을
해당 클러스터에 대한 DNS 서비스 검색 동작을
변경할 수 있다.
쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다.
@@ -164,7 +164,7 @@ data:
}
```
`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
자동 변환을 지원한다.
{{< note >}}
@@ -248,11 +248,11 @@ my.cluster.local:53 {
## CoreDNS로의 이관
kube-dns에서 CoreDNS로 이관하기 위하여,
kube-dns에서 CoreDNS로 이관하기 위하여,
kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는
[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다.
또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를
또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를
사용하여 이관할 수도 있다.
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+103 -85
View File
@@ -2,17 +2,18 @@
title: kubeadm 클러스터 업그레이드
content_type: task
weight: 20
min-kubernetes-server-version: 1.18
min-kubernetes-server-version: 1.19
---
<!-- overview -->
이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
1.17.x 버전에서 1.18.x 버전으로, 1.18.x 버전에서 1.18.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
1.18.x 버전에서 1.19.x 버전으로, 1.19.x 버전에서 1.19.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
이 페이지 대신 다음의 페이지들을 참고한다.
- [kubeadm 클러스터를 1.17에서 1.18로 업그레이드](https://v1-18.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
@@ -24,12 +25,9 @@ min-kubernetes-server-version: 1.18
1. 추가 컨트롤 플레인 노드를 업그레이드한다.
1. 워커(worker) 노드를 업그레이드한다.
## {{% heading "prerequisites" %}}
- 1.17.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다.
- 1.18.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다.
- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다.
- [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다.
@@ -43,25 +41,23 @@ min-kubernetes-server-version: 1.18
또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다.
예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다.
<!-- steps -->
## 업그레이드할 버전 결정
최신의 안정 버전인 1.18을 찾는다.
최신의 안정 버전인 1.19를 찾는다.
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
apt update
apt-cache madison kubeadm
# 목록에서 최신 버전 1.18을 찾는다
# 1.18.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
# 목록에서 최신 버전 1.19를 찾는다
# 1.19.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# 목록에서 최신 버전 1.18을 찾는다
# 1.18.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
# 목록에서 최신 버전 1.19를 찾는다
# 1.19.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{< /tabs >}}
@@ -73,18 +69,18 @@ min-kubernetes-server-version: 1.18
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00에서 x를 최신 패치 버전으로 바꾼다.
# 1.19.x-00에서 x를 최신 패치 버전으로 바꾼다.
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@@ -116,33 +112,45 @@ min-kubernetes-server-version: 1.18
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/versions] Latest stable version: v1.18.0
[upgrade/versions] Latest version in the v1.17 series: v1.18.0
[upgrade/versions] Cluster version: v1.18.4
[upgrade/versions] kubeadm version: v1.19.0
[upgrade/versions] Latest stable version: v1.19.0
[upgrade/versions] Latest version in the v1.18 series: v1.19.0
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.17.3 v1.18.0
Kubelet 1 x v1.18.4 v1.19.0
Upgrade to the latest version in the v1.17 series:
Upgrade to the latest version in the v1.18 series:
COMPONENT CURRENT AVAILABLE
API Server v1.17.3 v1.18.0
Controller Manager v1.17.3 v1.18.0
Scheduler v1.17.3 v1.18.0
Kube Proxy v1.17.3 v1.18.0
CoreDNS 1.6.5 1.6.7
Etcd 3.4.3 3.4.3-0
API Server v1.18.4 v1.19.0
Controller Manager v1.18.4 v1.19.0
Scheduler v1.18.4 v1.19.0
Kube Proxy v1.18.4 v1.19.0
CoreDNS 1.6.7 1.7.0
Etcd 3.4.3-0 3.4.7-0
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.18.0
kubeadm upgrade apply v1.19.0
_____________________________________________________________________
아래 표는 이 버전의 kubeadm에서 이해하는 컴포넌트 구성의 현재 상태를 보여준다.
"MANUAL UPGRADE REQUIRED" 열에 "yes" 표시가 있는 구성은 성공적인 업그레이드를
수행하기 전에 수동 구성 업그레이드 또는 kubeadm 기본값으로 재설정이 필요하다. 수동으로
업그레이드할 버전은 "PREFERRED VERSION" 열에 표시된다.
API GROUP CURRENT VERSION PREFERRED VERSION MANUAL UPGRADE REQUIRED
kubeproxy.config.k8s.io v1alpha1 v1alpha1 no
kubelet.config.k8s.io v1beta1 v1beta1 no
_____________________________________________________________________
```
이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다.
또한 컴포넌트 구성 버전 상태가 있는 표를 보여준다.
{{< note >}}
또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다.
@@ -150,11 +158,17 @@ min-kubernetes-server-version: 1.18
자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
{{</ note >}}
{{< note >}}
`kubeadm upgrade plan` 이 수동 업그레이드가 필요한 컴포넌트 구성을 표시하는 경우, 사용자는
`--config` 커맨드 라인 플래그를 통해 대체 구성이 포함된 구성 파일을 `kubeadm upgrade apply` 에 제공해야 한다.
그렇게 하지 않으면 `kubeadm upgrade apply` 가 오류와 함께 종료되고 업그레이드를 수행하지 않는다.
{{</ note >}}
- 업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다.
```shell
# 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
sudo kubeadm upgrade apply v1.18.x
sudo kubeadm upgrade apply v1.19.x
```
@@ -166,75 +180,78 @@ min-kubernetes-server-version: 1.18
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade/version] You have chosen to change the cluster version to "v1.18.0"
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/version] You have chosen to change the cluster version to "v1.19.0"
[upgrade/versions] Cluster version: v1.18.4
[upgrade/versions] kubeadm version: v1.19.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/prepull] Prepulling image for component etcd.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[upgrade/prepull] Prepulling image for component kube-controller-manager.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[upgrade/prepull] Successfully prepulled the images for all the control plane components
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"...
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
[upgrade/prepull] Pulling images required for setting up a Kubernetes cluster
[upgrade/prepull] This might take a minute or two, depending on the speed of your internet connection
[upgrade/prepull] You can also perform this action in beforehand using 'kubeadm config images pull'
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.19.0"...
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
[upgrade/etcd] Upgrading to TLS for etcd
[upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012"
W0308 18:48:14.535122 3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
[upgrade/staticpods] Preparing for "etcd" upgrade
[upgrade/staticpods] Renewing etcd-server certificate
[upgrade/staticpods] Renewing etcd-peer certificate
[upgrade/staticpods] Renewing etcd-healthcheck-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
Static pod: etcd-kind-control-plane hash: 59e40b2aab1cd7055e64450b5ee438f0
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests999800980"
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Renewing apiserver certificate
[upgrade/staticpods] Renewing apiserver-kubelet-client certificate
[upgrade/staticpods] Renewing front-proxy-client certificate
[upgrade/staticpods] Renewing apiserver-etcd-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml"
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: f717874150ba572f020dcd89db8480fc
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml"
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156
Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
Static pod: kube-controller-manager-kind-control-plane hash: b155b63c70e798b806e64a866e297dd0
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml"
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d
Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
Static pod: kube-scheduler-kind-control-plane hash: 260018ac854dbf1c9fe82493e88aec31
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.19" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
W0713 16:26:14.074656 2986 dns.go:282] the CoreDNS Configuration will not be migrated due to unsupported version of CoreDNS. The existing CoreDNS Corefile configuration and deployment has been retained.
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy!
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.19.0". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
@@ -276,18 +293,18 @@ sudo kubeadm upgrade apply
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
# 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@@ -309,18 +326,18 @@ sudo systemctl restart kubelet
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
# 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@@ -355,18 +372,18 @@ sudo systemctl restart kubelet
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
# 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@@ -429,6 +446,7 @@ etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면,
- 컨트롤 플레인이 정상적으로 동작한다
- 버전 차이(skew) 정책을 적용한다.
- 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다.
- 컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다.
- 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다.
- 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
- API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다.
content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+4 -10
View File
@@ -10,14 +10,9 @@ weight: 40
이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다.
## {{% heading "prerequisites" %}}
[kubeadm 시작하기](/docs/getting-started-guides/kubeadm/)의 1, 2, 3 단계를 완료하자.
[kubeadm 시작하기](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)의 1, 2, 3 단계를 완료하자.
<!-- steps -->
@@ -33,9 +28,8 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman
* [Romana 네트워크 폴리시의 예](https://github.com/romana/core/blob/master/doc/policy.md).
* 네트워크 폴리시 API.
## {{% heading "whatsnext" %}}
로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해
[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를
따라 할 수 있다.
content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
+10 -11
View File
@@ -8,14 +8,10 @@ weight: 50
이 페이지는 네트워크 폴리시(NetworkPolicy)로 위브넷(Weave Net)를 사용하는 방법을 살펴본다.
## {{% heading "prerequisites" %}}
쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 [kubeadm 시작하기 안내서](/docs/getting-started-guides/kubeadm/)를 따른다.
쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서
[kubeadm 시작하기 안내서](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)를 따른다.
<!-- steps -->
@@ -23,7 +19,10 @@ weight: 50
[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다.
쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의 네크워크 정책 어노테이션을 자동으로 모니터링하며, 정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는 [네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다.
쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의
네크워크 정책 어노테이션을 자동으로 모니터링하며,
정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는
[네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다.
## 설치 시험
@@ -47,9 +46,9 @@ weave-net-pmw8w 2/2 Running 0 9d
위브넷 파드를 가진 각 노드와 모든 파드는 `Running`이고 `2/2 READY`이다(`2/2`는 각 파드가 `weave`와 `weave-npc`를 가지고 있음을 뜻한다).
## {{% heading "whatsnext" %}}
위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해
[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를
따라 할 수 있다. 질문이 있으면
[슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
+1 -2
View File
@@ -80,7 +80,7 @@ spec:
requests:
cpu: 700m
memory: 200Mi
...
...
status:
qosClass: Guaranteed
```
@@ -269,4 +269,3 @@ kubectl delete namespace qos-example
* [API 오브젝트 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/)
* [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)
content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md
+11 -15
View File
@@ -5,24 +5,20 @@ content_type: task
<!-- overview -->
이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로,
초기화 컨테이너를 `<init-container-1>` 과
이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로,
초기화 컨테이너를 `<init-container-1>` 과
`<init-container-2>` 로 표시한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의
* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의
기본 사항에 익숙해야 한다.
* 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다.
<!-- steps -->
## 초기화 컨테이너의 상태 체크하기
@@ -33,7 +29,7 @@ content_type: task
kubectl get pod <pod-name>
```
예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중
예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중
하나가 성공적으로 완료되었음을 나타낸다.
```
@@ -41,7 +37,7 @@ NAME READY STATUS RESTARTS AGE
<pod-name> 0/1 Init:1/2 0 7s
```
상태값과 그 의미에 대한 추가 예제는
상태값과 그 의미에 대한 추가 예제는
[파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다.
## 초기화 컨테이너에 대한 상세 정보 조회하기
@@ -82,7 +78,7 @@ Init Containers:
...
```
파드 스펙의 `status.initContainerStatuses` 필드를 읽어서
파드 스펙의 `status.initContainerStatuses` 필드를 읽어서
프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다.
@@ -102,8 +98,8 @@ kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
kubectl logs <pod-name> -c <init-container-2>
```
셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가
실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에
셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가
실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에
`set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다.
@@ -112,8 +108,8 @@ kubectl logs <pod-name> -c <init-container-2>
## 파드의 상태 이해하기
`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의
실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는
`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의
실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는
동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다.
상태 | 의미
content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+3 -4
View File
@@ -7,7 +7,7 @@ title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로
Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은
[스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는
[스택드라이버 로깅으로 로깅하기](/docs/user-guide/logging/stackdriver)에 자세히 설명되어 있다.
[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다.
이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로,
[엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고
@@ -87,7 +87,8 @@ monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에
있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해,
[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에 대한 지침을 참고한다.
[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에
대한 지침을 참고한다.
브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면,
다음과 같은 상태 페이지가 표시된다.
@@ -118,5 +119,3 @@ monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한
아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다.
content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+14 -7
View File
@@ -10,9 +10,6 @@ content_type: concept
`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
<!-- body -->
## 메트릭 API
@@ -38,11 +35,19 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
### CPU
CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
CPU는 일정 기간 동안
[CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서
평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는
누적 CPU 카운터보다 높은 비율을 적용해서 얻는다.
kubelet은 비율 계산에 사용할 윈도우를 선택한다.
### 메모리
메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다. 이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다. 그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다. 쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다. 호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다.
이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다.
그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다.
쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다.
호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
## 메트릭 서버
@@ -51,9 +56,11 @@ CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
[디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다.
메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
메트릭 서버는 각 노드에서 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해
노출된 Summary API에서 메트릭을 수집한다.
메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
통해 메인 API 서버에 등록된다.
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다.
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서
메트릭 서버에 대해 자세하게 배울 수 있다.
content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+19 -18
View File
@@ -5,38 +5,41 @@ title: 리소스 모니터링 도구
<!-- overview -->
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을
검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
[서비스](/ko/docs/concepts/services-networking/service),
그리고 전체 클러스터의 특성을 검사하여
쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다.
이 정보는 애플리케이션의 성능을 평가하고
이 정보는 애플리케이션의 성능을 평가하고
병목 현상을 제거하여 전체 성능을 향상할 수 있게 해준다.
<!-- body -->
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다.
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다.
신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는
[완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다.
## 리소스 메트릭 파이프라인
리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는
리소스 메트릭 파이프라인은
[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
컨트롤러와 같은 클러스터 구성요소나
`kubectl top` 유틸리티에 관련되어 있는
메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)에
의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다.
의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다.
metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의
[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리
metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 CPU와 메모리
사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서
머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는
컨테이너로 변환하고 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서
개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의
개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의
통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. 그 다음으로 취합된 파드
리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는
kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서
kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서
제공된다.
## 완전한 메트릭 파이프라인
@@ -50,5 +53,3 @@ kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1
CNCF 프로젝트인, [프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다.
CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 쿠버네티스 문서의 범위가 아니다.
content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md
+12 -23
View File
@@ -9,28 +9,21 @@ weight: 20
본 페이지는 쿠버네티스 파드의 컨테이너를 위한 환경 변수를
정의하는 방법에 대해 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 컨테이너를 위한 환경 변수 정의하기
파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할
파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할
수 있다. 환경 변수를 설정하려면, 구성 파일에 `env`나 `envFrom` 필드를
포함시켜야 한다.
이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는
값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트
값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트
예시이다.
{{< codenew file="pods/inject/envars.yaml" >}}
@@ -81,24 +74,24 @@ weight: 20
1. 셸에서 빠져나오기 위해, `exit`을 입력한다.
{{< note >}}
`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지
`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지
안에서 명시된 모든 환경 변수들을 오버라이딩한다.
{{< /note >}}
{{< note >}}
환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다.
환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다.
사용하기 전에 순서에 주의한다.
{{< /note >}}
## 설정 안에서 환경 변수 사용하기
파드의 구성 파일 안에서 정의한 환경 변수는
파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이,
구성 파일 안의 다른 곳에서 사용할 수 있다.
아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고
`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`,
그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은
이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서
파드의 구성 파일 안에서 정의한 환경 변수는
파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이,
구성 파일 안의 다른 곳에서 사용할 수 있다.
아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고
`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`,
그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은
이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서
사용된다.
```yaml
@@ -123,12 +116,8 @@ spec:
컨테이너가 생성되면, `echo Warm greetings to The Most Honorable Kubernetes` 커맨드가 컨테이너에서 실행된다.
## {{% heading "whatsnext" %}}
* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
* [시크릿을 환경 변수로 사용하기](/docs/user-guide/secrets/#using-secrets-as-environment-variables)에 대해 알아본다.
* [시크릿을 환경 변수로 사용하기](/ko/docs/concepts/configuration/secret/#시크릿을-환경-변수로-사용하기)에 대해 알아본다.
* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
content/ko/docs/tasks/job/parallel-processing-expansion.md
+310
View File
@@ -0,0 +1,310 @@
---
title: 확장을 사용한 병렬 처리
content_type: task
min-kubernetes-server-version: v1.8
weight: 20
---
<!-- overview -->
이 태스크는 공통 템플릿을 기반으로 하는 여러 개의 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을
실행하는 것을 보여준다. 이 접근 방식을 사용하여 일괄 작업을 병렬로 처리할 수
있다.
이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다.
샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면
[실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다.
## {{% heading "prerequisites" %}}
사용자는 기본적인 내용과, 병렬 작업이 아닌
[잡](/ko/docs/concepts/workloads/controllers/job/) 사용에 대해 익숙해야 한다.
{{< include "task-tutorial-prereqs.md" >}}
기본 템플릿을 사용하려면 커맨드 라인 유틸리티 `sed` 가 필요하다.
고급 템플릿 예제를 따라하려면, [파이썬(Python)](https://www.python.org/)과
파이썬용 Jinja2 템플릿 라이브러리의 설치가
필요하다.
파이썬을 설정했으면, 다음을 실행하여 Jinja2를 설치할 수 있다.
```shell
pip install --user jinja2
```
<!-- steps -->
## 템플릿 기반의 잡 생성하기
먼저, 다음의 잡 템플릿을 다운로드해서 `job-tmpl.yaml` 파일로 저장한다.
다운로드할 내용은 다음과 같다.
{{< codenew file="application/job/job-tmpl.yaml" >}}
```shell
# job-tmpl.yaml를 다운로드하기 위해 curl을 사용한다
curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
```
다운로드한 파일은 아직 유효한 쿠버네티스
{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}가 아니다.
대신 해당 템플릿은 사용하기 전에 채워야하는 자리 표시자가 있는 잡 오브젝트의
YAML 표현이다. `$ITEM` 구문은 쿠버네티스에 의미가 있지 않다.
### 템플릿에서 매니페스트 생성하기
다음의 셸 스니펫은 `sed` 를 사용하여 루프 변수로 `$ITEM` 문자열을 바꾸고,
`jobs` 라는 임시 디렉터리에 기록한다. 다음과 같이 실행한다.
```shell
# 처리할 각 항목에 대해 하나씩, 템플릿을 여러 파일로 확장한다.
mkdir ./jobs
for i in apple banana cherry
do
cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml
done
```
작동하는지 확인한다.
```shell
ls jobs/
```
출력 결과는 다음과 비슷하다.
```
job-apple.yaml
job-banana.yaml
job-cherry.yaml
```
모든 유형의 템플릿 언어(예를 들어, Jinja2, ERB)를 사용하거나,
프로그램을 작성하여 잡 매니페스트를 생성할 수 있다.
### 매니페스트에서 잡 생성하기
다음으로, 하나의 kubectl 명령으로 모든 잡을 생성한다.
```shell
kubectl create -f ./jobs
```
출력 결과는 다음과 비슷하다.
```
job.batch/process-item-apple created
job.batch/process-item-banana created
job.batch/process-item-cherry created
```
이제, 작업을 확인한다.
```shell
kubectl get jobs -l jobgroup=jobexample
```
출력 결과는 다음과 비슷하다.
```
NAME COMPLETIONS DURATION AGE
process-item-apple 1/1 14s 22s
process-item-banana 1/1 12s 21s
process-item-cherry 1/1 12s 20s
```
kubectl 명령에 `-l` 옵션을 사용하면 이 잡 그룹의
일부인 잡만 선택된다(시스템에서 관련이 없는 다른 잡이 있을 수 있음).
파드도 동일한 {{< glossary_tooltip text="레이블 셀렉터" term_id="selector" >}}를
사용하여 확인할 수 있다.
```shell
kubectl get pods -l jobgroup=jobexample
```
출력 결과는 다음과 비슷하다.
```
NAME READY STATUS RESTARTS AGE
process-item-apple-kixwv 0/1 Completed 0 4m
process-item-banana-wrsf7 0/1 Completed 0 4m
process-item-cherry-dnfu9 0/1 Completed 0 4m
```
이 단일 명령을 사용하여 모든 잡의 출력을 한 번에 확인할 수 있다.
```shell
kubectl logs -f -l jobgroup=jobexample
```
출력 결과는 다음과 같아야 한다.
```
Processing item apple
Processing item banana
Processing item cherry
```
### 정리 {#cleanup-1}
```shell
# 생성한 잡 제거
# 클러스터가 자동으로 잡의 파드들을 정리
kubectl delete job -l jobgroup=jobexample
```
## 고급 템플릿 파라미터 사용하기
[첫 번째 예제](#템플릿-기반의-잡-생성하기)에서, 템플릿의 각 인스턴스는 하나의
파라미터를 가지고, 해당 파라미터는 잡의 이름에도 사용되었다. 그러나,
[이름](/ko/docs/concepts/overview/working-with-objects/names/#names)은
특정 문자들만 포함하도록 제한된다.
이런 약간 더 복잡한 예제는 [Jinja 템플릿 언어](https://palletsprojects.com/p/jinja/)를
사용하여 각 잡에 대한 여러 파라미터로 매니페스트를 생성한 다음
해당 매니페스트에서 오브젝트를 생성한다.
태스크의 이 부분에서는, 한줄 파이썬 스크립트를 사용하여
매니페스트 집합으로 템플릿을 변환한다.
먼저, 다음의 잡 오브젝트 템플릿을 복사하고 붙여넣기하여, `job.yaml.jinja2` 파일로 저장한다.
```liquid
{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
{ "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
{ "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
%}
{%- for p in params %}
{%- set name = p["name"] %}
{%- set url = p["url"] %}
---
apiVersion: batch/v1
kind: Job
metadata:
name: jobexample-{{ name }}
labels:
jobgroup: jobexample
spec:
template:
metadata:
name: jobexample
labels:
jobgroup: jobexample
spec:
containers:
- name: c
image: busybox
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
restartPolicy: Never
{%- endfor %}
```
위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해
두 개의 파라미터를 정의한다. `for` 루프는 각 파라미터의 집합(나머지 행)에 대해
하나의 잡 매니페스트를 방출한다.
이 예제는 YAML의 기능에 의존한다. 하나의 YAML 파일은 여러
문서(이 경우, 쿠버네티스 매니페스트)를 포함할 수 있으며, 행에 있는 `---` 로
구분된다.
출력 결과를 `kubectl` 에 직접 파이프를 사용해 잡을 생성할 수 있다.
다음으로, 이 한 줄 파이썬 프로그램을 사용하여 템플릿을 확장한다.
```shell
alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'
```
`render_template` 을 사용해서 파라미터와 템플릿을 쿠버네티스 매니페스트가
포함된 하나의 YAML 파일로 변환한다.
```shell
# 앞에서 정의한 앨리어스(alias)가 필요하다
cat job.yaml.jinja2 | render_template > jobs.yaml
```
`render_template` 스크립트가 제대로 동작하는지 확인하기 위해 `jobs.yaml` 을
볼 수 있다.
`render_template` 스크립트가 원하는대로 동작하는 것을 확인했다면,
스크립트의 출력 결과를 파이프를 사용하여 `kubectl` 에 보낼 수 있다.
```shell
cat job.yaml.jinja2 | render_template | kubectl apply -f -
```
쿠버네티스는 생성한 잡을 수락하고 실행한다.
### 정리 {#cleanup-2}
```shell
# 생성한 잡 제거
# 클러스터가 자동으로 잡이 있던 파드를 정리
kubectl delete job -l jobgroup=jobexample
```
<!-- discussion -->
## 실제 워크로드에서 잡 사용하기
실제 유스케이스에서, 각 잡은 동영상의 프레임을 렌더링하거나, 데이터베이스에서 행 범위를
처리하는 것과 같은 상당한 규모의 계산을 수행한다. 동영상을 렌더링하는 경우 프레임 번호에
`$ITEM` 을 설정한다. 데이터베이스에서 행을 처리하는
경우, 처리할 데이터베이스 행의 범위를 나타내도록 `$ITEM` 을 설정한다.
이번 태스크에서, 로그를 가져와 파드에서 출력 결과를 수집하는 명령어를
실행했다. 실제 유스케이스에서, 잡의 각 파드는 완료하기 전에 출력 결과를
내구성있는 스토리지에 기록한다. 각 잡에 대해 퍼시스턴트볼륨(PersistentVolume)을
사용하거나 외장 스토리지 서비스를 사용할 수 있다. 예를 들어, 동영상의 프레임을 렌더링하는 경우,
HTTP를 사용하여 렌더링된 프레임 데이터를 각 프레임에 대한 다른 URL을 사용해서 URL에 `PUT`
한다.
## 잡과 파드의 레이블
잡을 생성한 후, 쿠버네티스는 한 잡의 파드를 다른 잡의 파드와 구별하기 위해서
추가 {{< glossary_tooltip text="레이블" term_id="label" >}}을
자동으로 추가한다.
이 예시에서, 각 잡과 잡의 파드 템플릿은 `jobgroup=jobexample`
레이블을 갖는다.
쿠버네티스 자체는 `jobgroup` 이라는 레이블에 신경쓰지 않는다. 템플릿에서
생성한 모든 잡에 대해 레이블을 설정하면 한번에 모든 잡을 편리하게
조작할 수 있다.
[첫 번째 예제](#템플릿-기반의-잡-생성하기)에서 템플릿을 사용해서
여러 잡을 생성했다. 템플릿은 각 파드도 동일한 레이블을 가질 수 있도록 보장하므로,
단일 명령어로 이러한 템플릿 기반 잡들의 모든 파드에서 확인할 수 있다.
{{< note >}}
레이블 키 `jobgroup` 은 특별하거나 예약되어 있지 않다.
고유한 레이블링 체계를 선택할 수 있다.
원하는 경우 사용할 수 있는
[권장 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#레이블)이 있다.
{{< /note >}}
## 대안
많은 수의 잡 오브젝트의 생성을 계획 중이라면, 아마도 다음의 사항을 파악하게 될 것이다.
- 레이블을 사용해도, 너무 많은 잡을 관리하는 것은 번거롭다.
- 일괄적으로 많은 잡을 생성하는 경우, 쿠버네티스 컨트롤 플레인에
높음 부하를 가할 수 있다. 대안으로, 쿠버네티스 API 서버가
속도를 제한하여 429 상태의 사용자 요청을 일시적으로 거부할 수 있다.
- 사용자는 잡의 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}로
제한될 수 있다. 한번에 많은 작업을 생성하면 API 서버가 사용자의 요청 중
일부를 영구적으로 거부한다.
아주 많은 잡 오브젝트를 생성하지 않고 많은 양의 작업을 처리하는데 사용할 수 있는
다른 [잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)도
있다.
잡 오브젝트를 자동으로 관리하기 위해 자체 [컨트롤러](/ko/docs/concepts/architecture/controller/)를
작성하는 것도 고려할 수 있다.
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
+1 -10
View File
@@ -10,17 +10,10 @@ weight: 10
이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
* 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다.
<!-- steps -->
## 데몬셋 업데이트 전략
@@ -164,7 +157,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
{{< note >}}
삭제된 파드가 컨트롤러에 의해 제어되지 않거나 파드가 복제되지 않은 경우 서비스 중단이
발생한다. 이 때 [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)정책도 적용되지
발생한다. 이 때 [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)정책도 적용되지
않는다.
{{< /note >}}
@@ -200,5 +193,3 @@ kubectl delete ds fluentd-elasticsearch -n kube-system
* [태스크: 데몬셋에서 롤백
수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다.
* [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다.
content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
+1 -1
View File
@@ -115,4 +115,4 @@ glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{<
glossary_tooltip text="kube-apiserver"
term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
`HugePageStorageMediumSize` [기능
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 비활성화할 수 있다.
content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
+1 -1
View File
@@ -1005,5 +1005,5 @@ template:
* [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/)
* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
+1 -1
View File
@@ -167,5 +167,5 @@ kubectl create --edit -f /tmp/srv.yaml
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/)
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
+1 -1
View File
@@ -150,5 +150,5 @@ template:
* [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/)
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
+3 -3
View File
@@ -832,6 +832,6 @@ deployment.apps "dev-my-nginx" deleted
* [Kustomize](https://github.com/kubernetes-sigs/kustomize)
* [Kubectl Book](https://kubectl.docs.kubernetes.io)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [Kubectl 북](https://kubectl.docs.kubernetes.io)
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+5 -7
View File
@@ -10,11 +10,9 @@ Horizontal Pod Autoscaler는
CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다.
Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는
[Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
## {{% heading "prerequisites" %}}
@@ -457,12 +455,12 @@ Events:
## 부록: 수량
HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
쿠버네티스에서 사용하는 *수량* 숫자 표기법을 사용한다.
쿠버네티스에서 사용하는
{{< glossary_tooltip term_id="quantity" text="수량">}} 숫자 표기법을 사용한다.
예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다.
메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며,
일반적으로 수량을 밀리단위로 반환한다.
10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다.
더 많은 정보를 위해서는 [수량에 관한 용어집](/docs/reference/glossary?core-object=true#term-quantity) 을 참고하기 바란다.
## 부록: 다른 가능한 시나리오
content/ko/docs/tasks/tls/certificate-rotation.md
+4 -10
View File
@@ -10,7 +10,7 @@ content_type: task
이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다.
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
## {{% heading "prerequisites" %}}
@@ -39,13 +39,11 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다.
`kubelet` 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라
kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는
`--rotate-certificates` 인자를 허용한다.
인증서 갱신은 베타 기능이므로 기능 플래그는
`--feature-gates = RotateKubeletClientCertificate=true` 를 사용하여 활성화해야 한다.
`kube-controller-manager` 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는
`--experimental-cluster-signing-duration` 인자를
허용한다.
`--cluster-signing-duration` (1.19 이전은 `--experimental-cluster-signing-duration`)
인자를 허용한다.
## 인증서 갱신 구성에 대한 이해
@@ -62,7 +60,7 @@ kubectl get csr
인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가
자동으로 승인한 후 상태가 `Approved` 가 된다.
다음으로, 컨트롤러 관리자는
`--experimental-cluster-signing-duration` 파라미터에 의해 지정된 기간 동안
`--cluster-signing-duration` 파라미터에 의해 지정된 기간 동안
발행된 인증서에 서명하고
서명된 인증서는 인증서 서명 요청에 첨부된다.
@@ -77,7 +75,3 @@ kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서
kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다.
그런 다음 새로운 인증서를 사용한 재연결을 위해서
가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다.
content/ko/docs/tasks/tools/install-kubectl.md
+16 -5
View File
@@ -9,13 +9,18 @@ card:
---
<!-- overview -->
쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/user-guide/kubectl/)을 사용하면, 쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며 로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는, [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다.
쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/reference/kubectl/kubectl/)을 사용하면,
쿠버네티스 클러스터에 대해 명령을 실행할 수 있다.
kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며
로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는,
[kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다.
## {{% heading "prerequisites" %}}
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다.
예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다.
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
<!-- steps -->
@@ -306,7 +311,12 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다.
## kubectl 구성 확인
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면, [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를 사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)이 필요하다. 기본적으로, kubectl 구성은 `~/.kube/config` 에 있다.
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를
사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
[kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)이
필요하다.
기본적으로, kubectl 구성은 `~/.kube/config` 에 있다.
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
@@ -514,5 +524,6 @@ 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/configure-access-multiple-clusters/)를 참고한다.
* 직접 생성하지 않은 클러스터에 접근해야하는 경우,
[클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
* [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기