Fifth Korean l10n work for release-1.15 (#16231)
* Translate `concepts/scheduling/_index.md` to Korean (#16072) * Translate concepts/workloads/controllers/replicaset.md in Korean (#16070) * Update outdated content in dev-1.15-ko.5 (#16162) * Translate using-api/client-libraries into korean (#16182) * ko: translate concepts/cluster-administration/proxies (#16030) * Translate concepts/workloads/controllers/deployment.md in Korean (#16113) Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-Authored-By: Eden <longlg88@naver.com> Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: Sunghoon Kang <me@devholic.io> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <gochist@gmail.com>pull/16248/head
Seokho Son
Kubernetes Prow Robot
parent
772ecf9fe4
commit
c5261d3d6b
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
title: 쿠버네티스에서 프락시(Proxy)
|
||||
content_template: templates/concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 쿠버네티스에서 함께 사용되는 프락시(Proxy)를 설명한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 프락시
|
||||
|
||||
쿠버네티스를 이용할 때에 사용할 수 있는 여러 프락시가 있다.
|
||||
|
||||
1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
|
||||
|
||||
- 사용자의 데스크탑이나 파드 안에서 실행한다.
|
||||
- 로컬 호스트 주소에서 쿠버네티스의 API 서버로 프락시한다.
|
||||
- 클라이언트로 프락시는 HTTP를 사용한다.
|
||||
- API 서버로 프락시는 HTTPS를 사용한다.
|
||||
- API 서버를 찾는다.
|
||||
- 인증 헤더를 추가한다.
|
||||
|
||||
1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
|
||||
|
||||
- API 서버에 내장된 요새(bastion)이다.
|
||||
- 클러스터 외부의 사용자가 도달할 수 없는 클러스터 IP 주소로 연결한다.
|
||||
- API 서버 프로세스에서 실행한다.
|
||||
- 클라이언트로 프락시는 HTTPS(또는 API서버에서 HTTP로 구성된 경우는 HTTP)를 사용한다.
|
||||
- 사용 가능한 정보를 이용하여 프락시에 의해 선택한 HTTP나 HTTPS를 사용할 수 있는 대상이다.
|
||||
- 노드, 파드, 서비스에 도달하는데 사용할 수 있다.
|
||||
- 서비스에 도달할 때에는 로드 밸런싱을 수행한다.
|
||||
|
||||
1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
|
||||
|
||||
- 각 노드에서 실행한다.
|
||||
- UDP, TCP, SCTP를 이용하여 프락시 한다.
|
||||
- HTTP는 이해하지 못한다.
|
||||
- 로드 밸런싱을 제공한다.
|
||||
- 단지 서비스에 도달하는데 사용한다.
|
||||
|
||||
1. API 서버 앞단의 프락시/로드밸런서
|
||||
|
||||
- 존재 및 구현은 클러스터 마다 다르다. (예: nginx)
|
||||
- 모든 클라이언트와 하나 이상의 API 서버에 위치한다.
|
||||
- 여러 API 서버가 있는 경우 로드 밸런서로서 작동한다.
|
||||
|
||||
1. 외부 서비스의 클라우드 로드 밸런서
|
||||
|
||||
- 일부 클라우드 제공자는 제공한다. (예: AWS ELB, 구글 클라우드 로드 밸런서)
|
||||
- 쿠버네티스 서비스로 `LoadBalancer` 유형이 있으면 자동으로 생성된다.
|
||||
- 일반적으로 UDP/TCP만 지원한다.
|
||||
- SCTP 지원은 클라우드 제공자의 구현에 달려 있다.
|
||||
- 구현은 클라우드 제공자에 따라 다양하다.
|
||||
|
||||
쿠버네티스 사용자는 보통 처음 두 가지 유형 외의 것은 걱정할 필요없다.
|
||||
클러스터 관리자는 일반적으로 후자의 유형이 올바르게 구성되었는지 확인한다.
|
||||
|
||||
## 요청을 리다이렉트하기
|
||||
|
||||
프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "스케줄링"
|
||||
weight: 90
|
||||
---
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,351 @@
|
|||
---
|
||||
title: 레플리카셋
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다.
|
||||
이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 레플리카셋의 작동 방식
|
||||
|
||||
레플리카셋을 정의하는 필드는 획득 가능한 파드를 식별하는 방법이 명시된 셀렉터, 유지해야 하는 파드 개수를 명시하는 레플리카의 개수,
|
||||
그리고 레플리카 수 유지를 위해 생성하는 신규 파드에 대한 데이터를 명시하는 파드 템플릿을 포함한다.
|
||||
그러면 레플리카셋은 필드에 지정된 설정을 충족하기 위해 필요한 만큼 파드를 만들고 삭제한다.
|
||||
레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
|
||||
사용한다.
|
||||
|
||||
레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
|
||||
필드를 통해서 제공되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
|
||||
레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
|
||||
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
|
||||
|
||||
레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에 OwnerReference이 없거나
|
||||
OwnerReference가 컨트롤러가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를
|
||||
가지게 될 것이다.
|
||||
|
||||
## 레플리카셋을 사용하는 시기
|
||||
|
||||
레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다.
|
||||
그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께
|
||||
파드에 대한 선언적 업데이트를 제공하는 상위 개념이다.
|
||||
따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면
|
||||
레플리카셋을 직접적으로 사용하기 보다는 디플로이먼트를 사용하는 것을 권장한다.
|
||||
|
||||
이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다.
|
||||
대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다.
|
||||
|
||||
## 예시
|
||||
|
||||
{{< codenew file="controllers/frontend.yaml" >}}
|
||||
|
||||
이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어있는 레플리카셋이
|
||||
생성되고 레플리카셋이 관리하는 파드가 생성된다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
|
||||
```
|
||||
|
||||
현재 배포된 레플리카셋을 확인할 수 있다.
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
그리고 생성된 프런트엔드를 볼 수 있다.
|
||||
```shell
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
frontend 3 3 3 6s
|
||||
```
|
||||
|
||||
또한 레플리카셋의 상태를 확인할 수 있다.
|
||||
```shell
|
||||
kubectl describe rs/frontend
|
||||
```
|
||||
|
||||
출력은 다음과 유사할 것이다.
|
||||
```shell
|
||||
Name: frontend
|
||||
Namespace: default
|
||||
Selector: tier=frontend,tier in (frontend)
|
||||
Labels: app=guestbook
|
||||
tier=frontend
|
||||
Annotations: <none>
|
||||
Replicas: 3 current / 3 desired
|
||||
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
|
||||
Pod Template:
|
||||
Labels: app=guestbook
|
||||
tier=frontend
|
||||
Containers:
|
||||
php-redis:
|
||||
Image: gcr.io/google_samples/gb-frontend:v3
|
||||
Port: 80/TCP
|
||||
Requests:
|
||||
cpu: 100m
|
||||
memory: 100Mi
|
||||
Environment:
|
||||
GET_HOSTS_FROM: dns
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
|
||||
```
|
||||
|
||||
마지막으로 파드가 올라왔는지 확인할 수 있다.
|
||||
```shell
|
||||
kubectl get Pods
|
||||
```
|
||||
|
||||
다음과 유사한 파드 정보를 볼 수 있다.
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-9si5l 1/1 Running 0 1m
|
||||
frontend-dnjpy 1/1 Running 0 1m
|
||||
frontend-qhloh 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
또한 파드들의 소유자 참조 정보가 해당 프런트엔드 레플리카셋으로 설정되어 있는지 확인할 수 있다.
|
||||
확인을 위해서는 실행 중인 파드 중 하나의 yaml을 확인한다.
|
||||
```shell
|
||||
kubectl get pods frontend-9si5l -o yaml
|
||||
```
|
||||
|
||||
메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
creationTimestamp: 2019-01-31T17:20:41Z
|
||||
generateName: frontend-
|
||||
labels:
|
||||
tier: frontend
|
||||
name: frontend-9si5l
|
||||
namespace: default
|
||||
ownerReferences:
|
||||
- apiVersion: extensions/v1beta1
|
||||
blockOwnerDeletion: true
|
||||
controller: true
|
||||
kind: ReplicaSet
|
||||
name: frontend
|
||||
uid: 892a2330-257c-11e9-aecd-025000000001
|
||||
...
|
||||
```
|
||||
|
||||
## 템플릿을 사용하지 않는 파드의 획득
|
||||
|
||||
단독(bare) 파드를 생성하는 것에는 문제가 없지만, 단독 파드가 레플리카셋의 셀렉터와 일치하는 레이블을 가지지
|
||||
않도록 하는 것을 강력하게 권장한다. 그 이유는 레플리카셋이 소유하는 파드가 템플릿에 명시된 파드에만 국한되지 않고,
|
||||
이전 섹션에서 명시된 방식에 의해서도 다른 파드의 획득이 가능하기 때문이다.
|
||||
|
||||
이전 프런트엔드 레플리카셋 예제와 다음의 매니페스트에 명시된 파드를 가져와 참조한다.
|
||||
|
||||
{{< codenew file="pods/pod-rs.yaml" >}}
|
||||
|
||||
기본 파드는 소유자 관련 정보에 컨트롤러(또는 오브젝트)를 가지지 않기 때문에 프런트엔드
|
||||
레플리카셋의 셀렉터와 일치하면 즉시 레플리카셋에 소유된다.
|
||||
|
||||
프런트엔드 레플리카셋이 배치되고 초기 파드 레플리카가 셋업된 이후에, 레플리카 수 요구 사항을 충족시키기 위해서
|
||||
신규 파드를 생성한다고 가정해보자.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
|
||||
```
|
||||
|
||||
새로운 파드는 레플리카셋에 의해 인식되며 레플리카셋이 필요한 수량을 초과하면
|
||||
즉시 종료된다.
|
||||
|
||||
파드를 가져온다.
|
||||
```shell
|
||||
kubectl get Pods
|
||||
```
|
||||
|
||||
결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다.
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-9si5l 1/1 Running 0 1m
|
||||
frontend-dnjpy 1/1 Running 0 1m
|
||||
frontend-qhloh 1/1 Running 0 1m
|
||||
pod2 0/1 Terminating 0 4s
|
||||
```
|
||||
|
||||
파드를 먼저 생성한다.
|
||||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
|
||||
```
|
||||
|
||||
그 다음 레플리카셋을 생성한다.
|
||||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
|
||||
```
|
||||
|
||||
레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가
|
||||
레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다.
|
||||
```shell
|
||||
kubectl get Pods
|
||||
```
|
||||
|
||||
다음 출력에서 볼 수 있다.
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-pxj4r 1/1 Running 0 5s
|
||||
pod1 1/1 Running 0 13s
|
||||
pod2 1/1 Running 0 13s
|
||||
```
|
||||
|
||||
이러한 방식으로 레플리카셋은 템플릿을 사용하지 않는 파드를 소유하게 된다.
|
||||
|
||||
## 레플리카셋 매니페스트 작성하기
|
||||
|
||||
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
|
||||
레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다.
|
||||
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
|
||||
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
|
||||
|
||||
레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다.
|
||||
|
||||
### 파드 템플릿
|
||||
|
||||
`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다.
|
||||
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
|
||||
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
|
||||
|
||||
템플릿의 [재시작 정책](ko/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) 필드인
|
||||
`.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다.
|
||||
|
||||
### 파드 셀렉터
|
||||
|
||||
`.spec.selector` 필드는 [레이블 셀렉터](ko/docs/concepts/overview/working-with-objects/labels/)이다.
|
||||
[앞서](#레플리카-셋의-작동-방식) 논의한 것처럼 이 레이블은 소유될 가능성이 있는 파드를 식별하는데 사용된다.
|
||||
우리 `frontend.yaml` 예제에서의 셀렉터는 다음과 같다.
|
||||
```shell
|
||||
matchLabels:
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
레플리카셋에서 `.spec.template.metadata.labels`는 `spec.selector`과 일치해야 하며
|
||||
그렇지 않으면 API에 의해 거부된다.
|
||||
|
||||
{{< note >}}
|
||||
2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카 셋은 다른 레플리카 셋이 생성한 파드를 무시한다.
|
||||
{{< /note >}}
|
||||
|
||||
### 레플리카
|
||||
|
||||
`.spec.replicas`를 설정해서 동시에 동작하는 파드의 수를 지정할 수 있다.
|
||||
레플리카셋은 파드의 수가 일치하도록 생성 및 삭제한다.
|
||||
|
||||
만약 `.spec.replicas`를 지정하지 않으면 기본값은 1이다.
|
||||
|
||||
## 레플리카셋 작업
|
||||
|
||||
### 레플리카셋과 해당 파드 삭제
|
||||
|
||||
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
|
||||
|
||||
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
|
||||
설정해야 한다.
|
||||
예시:
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
|
||||
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
> -H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
### 레플리카셋만 삭제하기
|
||||
|
||||
레플리카셋을 `--cascade=false` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
|
||||
REST API 또는 `client-go` 라이브러리를 이용할 때는 `propagationPolicy`에 `Orphan`을 설정해야 한다.
|
||||
예시:
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
|
||||
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
> -H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
|
||||
기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다.
|
||||
하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
|
||||
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)를 이용하면 된다.
|
||||
이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.
|
||||
|
||||
### 레플리카셋에서 파드 격리
|
||||
|
||||
레이블을 변경하면 레플리카셋에서 파드를 제거할 수 있다. 이 방식은 디버깅과 데이터 복구 등을
|
||||
위해 서비스에서 파드를 제거하는 데 사용할 수 있다. 이 방식으로 제거된 파드는 자동으로 교체된다(
|
||||
레플리카의 수가 변경되지 않는다고 가정한다).
|
||||
|
||||
### 레플리카셋의 스케일링
|
||||
|
||||
레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트 하면 된다.
|
||||
레플리카셋 컨트롤러는 일치하는 레이블 셀렉터가 있는 파드가 의도한 수 만큼 가용하고 운영 가능하도록 보장한다.
|
||||
|
||||
### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정
|
||||
|
||||
레플리카 셋은
|
||||
[Horizontal Pod Autoscalers (HPA)](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)의 대상이 될 수 있다.
|
||||
즉, 레플리카셋은 HPA에 의해 오토스케일될 수 있다.
|
||||
다음은 이전에 만든 예시에서 만든 레플리카셋을 대상으로 하는 HPA 예시이다.
|
||||
|
||||
{{< codenew file="controllers/hpa-rs.yaml" >}}
|
||||
|
||||
이 매니페스트를 `hpa-rs.yaml`로 저장한 다음 쿠버네티스
|
||||
클러스터에 적용하면 CPU 사용량에 따라 파드가 복제되는
|
||||
오토스케일 레플리카 셋 HPA가 생성된다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
|
||||
```
|
||||
|
||||
또는 `kubectl autoscale` 커맨드을 사용해서 동일한 작업을 할 수 있다.
|
||||
(그리고 더 쉽다!)
|
||||
|
||||
```shell
|
||||
kubectl autoscale rs frontend --max=10
|
||||
```
|
||||
|
||||
## 레플리카셋의 대안
|
||||
|
||||
### 디플로이먼트(권장)
|
||||
|
||||
[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/)는 레플리카셋을 소유하거나 업데이트를 하고,
|
||||
파드의 선언적인 업데이트와 서버측 롤링 업데이트를 할 수 있는 오브젝트이다.
|
||||
레플리카셋은 단독으로 사용할 수 있지만, 오늘날에는 주로 디플로이먼트로 파드의 생성과 삭제 그리고 업데이트를 오케스트레이션하는 메커니즘으로 사용한다.
|
||||
디플로이먼트를 이용해서 배포할 때 생성되는 레플리카셋을 관리하는 것에 대해 걱정하지 않아도 된다.
|
||||
디플로이먼트는 레플리카셋을 소유하거나 관리한다.
|
||||
따라서 레플리카셋을 원한다면 디플로이먼트를 사용하는 것을 권장한다.
|
||||
|
||||
### 기본 파드
|
||||
|
||||
사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는 노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든 종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도 레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면, 레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다. 레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 어떤 에이전트에게 위임한다(예를들어 Kubelet 또는 도커).
|
||||
|
||||
### 잡
|
||||
|
||||
스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 이용한다
|
||||
(즉, 배치 잡).
|
||||
|
||||
### 데몬셋
|
||||
|
||||
머신 모니터링 또는 머신 로깅과 같은 머신-레벨의 기능을 제공하는 파드를 위해서는 레플리카셋 대신
|
||||
[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용한다.
|
||||
이러한 파드의 수명은 머신의 수명과 연관되어 있고, 머신에서 다른 파드가 시작하기 전에 실행되어야 하며,
|
||||
머신의 재부팅/종료가 준비되었을 때, 해당 파드를 종료하는 것이 안전하다.
|
||||
|
||||
### 레플리케이션 컨트롤러
|
||||
레플리카셋은 [_레플리케이션 컨트롤러_](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 계승하였다.
|
||||
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/docs/concepts/overview/working-with-objects/labels/#label-selectors)에
|
||||
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
|
||||
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -150,8 +150,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
|
|||
`node-1` 은 차단되어 있어 다른 노드에 위치한다.
|
||||
무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다.
|
||||
|
||||
(참고: 스테이트풀 셋은 `pod-1`처럼 불릴, `pod-a`를
|
||||
교체하기 전에 완전히 중지해야 하며, `pod-1` 로 불리지만, 다른 UID로 생성된다.
|
||||
(참고: 스테이트풀 셋은 `pod-0`처럼 불릴, `pod-a`를
|
||||
교체하기 전에 완전히 중지해야 하며, `pod-0` 로 불리지만, 다른 UID로 생성된다.
|
||||
그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.)
|
||||
|
||||
이제 클러스터는 다음과 같은 상태이다.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,7 @@
|
|||
---
|
||||
title: 미러 파드(Mirror Pod)
|
||||
id: mirror-pod
|
||||
date: 2091-02-12
|
||||
full_link:
|
||||
date: 2019-08-06
|
||||
short_description: >
|
||||
Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 객체.
|
||||
|
||||
|
|
|
|||
|
|
@ -201,9 +201,12 @@ kubectl get events --sort-by=.metadata.creationTimestamp
|
|||
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
|
||||
kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크
|
||||
kubectl rollout undo deployment/frontend # 이전 디플로이먼트로 롤백
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # 특정 리비전으로 롤백
|
||||
kubectl rollout status -w deployment/frontend # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시
|
||||
|
||||
|
||||
# 버전 1.11 부터 사용 중단
|
||||
kubectl rolling-update frontend-v1 -f frontend-v2.json # (사용중단) frontend-v1 파드의 롤링 업데이트
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (사용중단) 리소스 이름 변경과 이미지 업데이트
|
||||
|
|
|
|||
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
title: 클라이언트 라이브러리
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 다양한 프로그래밍 언어에서 쿠버네티스 API를 사용하기 위한
|
||||
클라이언트 라이브러리에 대한 개요를 포함하고 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
[쿠버네티스 REST API](/ko/docs/reference/using-api/api-overview/)를 사용해 애플리케이션을 작성하기 위해
|
||||
API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
|
||||
사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다.
|
||||
|
||||
클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다.
|
||||
대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증
|
||||
또는 [kubeconfig 파일](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) 포맷을 통해
|
||||
자격증명과 API 서버 주소를 읽을 수 있게
|
||||
쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다.
|
||||
|
||||
## 공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리
|
||||
|
||||
다음의 클라이언트 라이브러리들은 [쿠버네티스 SIG API
|
||||
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다.
|
||||
|
||||
|
||||
| 언어 | 클라이언트 라이브러리 | 예제 프로그램 |
|
||||
|----------|----------------|-----------------|
|
||||
| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples)
|
||||
| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples)
|
||||
| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation)
|
||||
| dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple)
|
||||
| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples)
|
||||
| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example)
|
||||
|
||||
|
||||
## 커뮤니티에 의해 관리되는 클라이언트 라이브러리
|
||||
|
||||
다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌
|
||||
각각의 저자들이 제공하고 관리한다.
|
||||
|
||||
| 언어 | 클라이언트 라이브러리 |
|
||||
| -------------------- | ---------------------------------------- |
|
||||
| Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) |
|
||||
| Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) |
|
||||
| Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) |
|
||||
| Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) |
|
||||
| Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) |
|
||||
| Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) |
|
||||
| Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) |
|
||||
| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) |
|
||||
| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) |
|
||||
| Node.js | [github.com/ajpauwels/easy-k8s](https://github.com/ajpauwels/easy-k8s)
|
||||
| Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) |
|
||||
| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
|
||||
| PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
|
||||
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
|
||||
| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
|
||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
||||
| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
|
||||
| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
|
||||
| Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |
|
||||
| Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) |
|
||||
| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
|
||||
| dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
|
||||
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
|
||||
| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
|
||||
| Haskell | [github.com/soundcloud/haskell-kubernetes](https://github.com/soundcloud/haskell-kubernetes) |
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다.
|
|||
* 노드 포트
|
||||
* 컨피그 맵과 시크릿
|
||||
* 대시보드
|
||||
* 컨테이너 런타임: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd)
|
||||
* 컨테이너 런타임: Docker, [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd)
|
||||
* CNI(Container Network Interface) 사용
|
||||
* 인그레스
|
||||
|
||||
|
|
@ -228,7 +228,6 @@ minikube start \
|
|||
{{% /tab %}}
|
||||
{{% tab name="CRI-O" %}}
|
||||
[CRI-O](https://github.com/kubernetes-incubator/cri-o)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다.
|
||||
|
||||
```bash
|
||||
minikube start \
|
||||
--network-plugin=cni \
|
||||
|
|
@ -248,17 +247,6 @@ minikube start \
|
|||
--bootstrapper=kubeadm
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="rkt container engine" %}}
|
||||
[rkt](https://github.com/rkt/rkt)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
minikube start \
|
||||
--network-plugin=cni \
|
||||
--enable-default-cni \
|
||||
--container-runtime=rkt
|
||||
```
|
||||
이것은 rkt와 Docker와 CNI 네트워킹을 포함하는 대안적인 Minikube ISO 이미지를 이용한다.
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
#### Docker 데몬 재사용을 통한 로컬 이미지 사용하기
|
||||
|
|
|
|||
|
|
@ -213,6 +213,11 @@ Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사
|
|||
### 선행 조건
|
||||
|
||||
```shell
|
||||
cat > /etc/modules-load.d/containerd.conf <<EOF
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
|
|
@ -92,10 +92,9 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes
|
|||
|
||||
1. `kube-flannel.yml`의 `net-conf.json` 부분을 거듭 확인하자.
|
||||
1. 클러스터 서브넷(예, "10.244.0.0/16")은 IP 주소 설계에 따라 설정되어야 한다.
|
||||
* VNI 4096 은 벡엔드에 설정한다.
|
||||
* Port 4789 는 벡엔드에 설정한다.
|
||||
2. `kube-flannel.yml`의 `cni-conf.json` 부분에서 네트워크 이름을 `vxlan0`로 바꾼다.
|
||||
|
||||
* VNI 4096 은 벡엔드에 설정한다.
|
||||
* Port 4789 는 벡엔드에 설정한다.
|
||||
1. `kube-flannel.yml`의 `cni-conf.json` 부분에서 네트워크 이름을 `vxlan0`로 바꾼다.
|
||||
|
||||
`cni-conf.json`는 다음과 같다.
|
||||
|
||||
|
|
@ -141,7 +140,18 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes
|
|||
kubectl get pods --all-namespaces
|
||||
```
|
||||
|
||||
|
||||
결과는 다음과 같다.
|
||||
|
||||
```
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
kube-system etcd-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-apiserver-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m
|
||||
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
|
||||
kube-system kube-proxy-Zjlxz 1/1 Running 0 1m
|
||||
kube-system kube-scheduler-flannel-master 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
플라넬 데몬셋에 노드 셀렉터가 적용되었음을 확인한다.
|
||||
|
||||
|
|
@ -149,13 +159,20 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes
|
|||
kubectl get ds -n kube-system
|
||||
```
|
||||
|
||||
|
||||
결과는 다음과 같다. 노드 셀렉터 `beta.kubernetes.io/os=linux`가 적용되었다.
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
|
||||
kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d
|
||||
kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d
|
||||
```
|
||||
|
||||
#### 윈도우 워커 조인
|
||||
|
||||
이번 단원은 맨 땅에서부터 온프레미스 클러스터에 가입하기까지 윈도우 노드 구성을 다룬다. 클러스터가 클라우드상에 있다면, 다음 단원에 있는 클라우드에 특정한 가이드를 따르도록 된다.
|
||||
|
||||
#### 윈도우 노드 준비하기
|
||||
|
||||
{{< note >}}
|
||||
윈도우 단원에서 모든 코드 부분은 높은 권한(Admin)으로 파워쉘(PowerShell) 환경에서 구동한다.
|
||||
{{< /note >}}
|
||||
|
|
@ -180,7 +197,26 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes
|
|||
|
||||
리부팅 후에 다음 오류를 보게되면, 도커 서비스를 수동으로 재시작해야 한다.
|
||||
|
||||
|
||||
```PowerShell
|
||||
docker version
|
||||
```
|
||||
|
||||
만약 다음과 같은 에러 메시지를 보게되면, 도커 서비스를 수동으로 시작해야 한다.
|
||||
|
||||
```
|
||||
Client:
|
||||
Version: 17.06.2-ee-11
|
||||
API version: 1.30
|
||||
Go version: go1.8.7
|
||||
Git commit: 06fc007
|
||||
Built: Thu May 17 06:14:39 2018
|
||||
OS/Arch: windows / amd64
|
||||
error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c
|
||||
annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to
|
||||
connect. This error may also indicate that the docker daemon is not running.
|
||||
```
|
||||
|
||||
다음과 같이 도커 서비스를 수동으로 시작할 수 있다.
|
||||
|
||||
```PowerShell
|
||||
Start-Service docker
|
||||
|
|
@ -227,7 +263,13 @@ wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/s
|
|||
{{< /note >}}
|
||||
|
||||
```PowerShell
|
||||
.\start.ps1 -ManagementIP <Windows Node IP> -NetworkMode overlay -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory>
|
||||
cd c:\k
|
||||
.\start.ps1 -ManagementIP <Windows Node IP> `
|
||||
-NetworkMode overlay `
|
||||
-ClusterCIDR <Cluster CIDR> `
|
||||
-ServiceCIDR <Service CIDR> `
|
||||
-KubeDnsServiceIP <Kube-dns Service IP> `
|
||||
-LogDir <Log directory>
|
||||
```
|
||||
|
||||
| 파라미터 | 기본값 | 비고 |
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 80 KiB |
|
|
@ -19,98 +19,40 @@ title: 리소스 모니터링 도구
|
|||
{{% capture body %}}
|
||||
|
||||
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다.
|
||||
신규 클러스터에서는 기본적으로 두 개의 개별 파이프라인을 사용하여 모니터링 통계를
|
||||
신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한
|
||||
메트릭 파이프라인](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를
|
||||
수집할 수 있다.
|
||||
|
||||
- [**리소스 메트릭 파이프라인**](#리소스-메트릭-파이프라인)은 HorizontalPodAutoscaler
|
||||
컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로
|
||||
제한된 집합을 제공한다. 이 메트릭은
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
|
||||
에 의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. `metrics-server`는 클러스터
|
||||
상의 모든 노드를 발견하고 각 노드의
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리
|
||||
사용량을 질의한다. Kubelet은 [cAdvisor](https://github.com/google/cadvisor)에서
|
||||
데이터를 가져온다. `metrics-server`는 경량의 단기 인메모리 저장소이다.
|
||||
|
||||
- 프로메테우스 같이 [**완전한 메트릭 파이프라인**](#완전한-메트릭-파이프라인)은 보다 풍부한
|
||||
메트릭에 액세스할 수 있게 해준다. 추가적으로 쿠버네티스는 Horizontal Pod Autoscaler와
|
||||
같은 메커니즘을 사용하여 현재 상태를 기반으로 클러스터를 자동으로 확장 또는
|
||||
조정함으로써 이런 메트릭에 응답할 수 있다. 모니터링 파이프라인은 Kubelet에서
|
||||
메트릭을 가져온 다음 `custom.metrics.k8s.io` 이나
|
||||
`external.metrics.k8s.io` API로 구현된 어댑터를 통해
|
||||
이들을 쿠버네티스에 노출한다.
|
||||
|
||||
## 리소스 메트릭 파이프라인
|
||||
|
||||
### Kubelet
|
||||
리소스 메트릭 파이프라인은
|
||||
[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale)
|
||||
컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는
|
||||
메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)에
|
||||
의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다.
|
||||
|
||||
Kubelet은 쿠버네티스 마스터와 노드들 사이의 다리 역할을 한다. 이는 머신 상에서 실행되는 파드들과 컨테이너들을 관리한다. Kubelet은 각 파드를 이를 구성하는 컨테이너들로 변환하며 컨테이너 런타임 인터페이스를 통해 컨테이너 런타임에서 개별 컨테이너의 사용량 통계를 가져온다. 레거시 도커 통합에서는 cAdvisor에서 이 정보를 가져온다. 그런 다음 Kubelet 리소스 메트릭 API를 통해 집계된 파드 리소스 사용량 통계를 노출한다. 이 API는 Kubelet의 인증되고 읽기 전용의 포트들 상에서 `/metrics/resource/v1alpha1`으로 제공된다.
|
||||
|
||||
### cAdvisor
|
||||
|
||||
cAdvisor는 오픈 소스 컨테이너 자원 사용률/성능 분석 에이전트이다. 이는 컨테이너 전용으로 설계되었으며 도커 컨테이너를 기본적으로 지원한다. 쿠버네티스에서 cAdvisor는 Kubelet 바이너리와 통합된다. cAdvisor는 머신 내 모든 컨테이너를 자동으로 발견하며 CPU, 메모리, 파일시스템, 네트워크 사용량 통계를 수집한다. cAdvisor는 또한 machine 상의 'root' 컨테이너 분석에 의한 전체 머신 사용량도 제공한다.
|
||||
|
||||
Kubelet은 기본 포트 4194를 통해 머신의 컨테이너에 대한 단순한 cAdvisor UI를 노출한다.
|
||||
아래 그림은 전체 머신의 사용량을 예제로 보여준다. 하지만, 이 기능은 v1.10에서는 사용 중단(deprecated)으로
|
||||
표시되었으며, v1.12에서는 완전히 제거되었다.
|
||||
|
||||
|
||||
|
||||
v1.13부터, [cAdvisor를 데몬셋으로 배포](https://github.com/google/cadvisor/tree/master/deploy/kubernetes)하여 cAdvisor UI에 액세스할 수 있다.
|
||||
metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리
|
||||
사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서
|
||||
머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는
|
||||
컨테이너로 변환하고 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서
|
||||
개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의
|
||||
통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. 그 다음으로 취합된 파드
|
||||
리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는
|
||||
kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서
|
||||
제공된다.
|
||||
|
||||
## 완전한 메트릭 파이프라인
|
||||
|
||||
쿠버네티스를 위한 많은 완전한 메트릭 솔루션들이 존재한다.
|
||||
완전한 메트릭 파이프라인은 보다 풍부한 메트릭에 접근할 수 있도록 해준다.
|
||||
쿠버네티스는 Horizontal Pod Autoscaler와 같은 메커니즘을 활용해서 이런 메트릭에
|
||||
대한 반응으로 클러스터의 현재 상태를 기반으로 자동으로 스케일링하거나 클러스터를
|
||||
조정할 수 있다. 모니터링 파이프라인은 kubelet에서 메트릭을 가져와서 쿠버네티스에
|
||||
`custom.metrics.k8s.io`와 `external.metrics.k8s.io` API를 구현한 어댑터를 통해
|
||||
노출한다.
|
||||
|
||||
### 프로메테우스
|
||||
|
||||
[프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다.
|
||||
[Prometheus Operator](https://coreos.com/operators/prometheus/docs/latest/)는
|
||||
쿠버네티스에서 프로메테우스 설정을 단순화하고,
|
||||
[Prometheus adapter](https://github.com/directxman12/k8s-prometheus-adapter)를
|
||||
사용하여 커스텀 메트릭 API를 제공할 수 있게 해준다.
|
||||
프로메테우스는 강력한 쿼리 언어와 데이터 쿼리와 시각화를 위한 내장 대시보드를 제공한다.
|
||||
또한 [Grafana](https://prometheus.io/docs/visualization/grafana/)에서는
|
||||
데이터 소스로 프로메테우스가 지원된다.
|
||||
|
||||
### Sysdig
|
||||
[Sysdig](http://sysdig.com)는 완전한 스펙트럼 컨테이너와 플랫폼 인텔리전스를 제공하며,
|
||||
진정한 컨테이너 네이티브 솔루션이다. Sysdig는 시스템 호출, 쿠버네티스 이벤트, 프로메테우스 메트릭,
|
||||
statsD, JMX 등의 데이터를 하나의 창으로 통합하여 환경에 대한 포괄적인 그림을 제공한다.
|
||||
또한 Sysdig는 강력하고 사용자 정의가 가능한 솔루션을 제공하기 위해 쿼리를 실행할 수 있는 API를 제공한다.
|
||||
Sysdig는 오픈 소스로 만들어졌다. [Sysdig와 Sysdig Inspect](https://sysdig.com/opensource/inspect/)는
|
||||
자유롭게 트러블슈팅, 분석, 포렌식을 수행할 수 있는 기능을 제공한다.
|
||||
|
||||
### 구글 클라우드 모니터링
|
||||
|
||||
구글 클라우드 모니터링은 호스팅 모니터링 서비스로 애플리케이션의
|
||||
중요한 메트릭을 시각화하고 경고하는데 사용할 수 있으며,
|
||||
쿠버네티스에서 메트릭을 수집하고
|
||||
[Cloud Monitoring Console](https://app.google.stackdriver.com/)을
|
||||
통해 이 메트릭들에 접근할 수 있다. 대시보드를 만들고 사용자 정의하여 쿠버네티스 클러스터에서
|
||||
수집한 데이터를 시각화할 수 있다.
|
||||
|
||||
이 동영상은 힙스터(Heapster)를 기반으로 구글 클라우드 모니터링을 구성하고 실행하는 방법을 보여준다.
|
||||
|
||||
[](https://www.youtube.com/watch?v=xSMNR2fcoLs)
|
||||
|
||||
|
||||
{{< figure src="/images/docs/gcm.png" alt="구글 클라우드 모니터링 대시보드 예제" title="구글 클라우드 모니터링 대시보드 예제" caption="대시보드는 클러스터 전역의 리소스 사용량을 보여준다." >}}
|
||||
|
||||
## 크론잡 모니터링
|
||||
|
||||
### Kubernetes Job Monitor
|
||||
|
||||
[Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) 대시보드를 사용하여 클러스터 관리자는 실행되고 있는 잡들과 완료된 잡의 상태를 볼 수 있다.
|
||||
|
||||
### New Relic 쿠버네티스 모니터링 통합
|
||||
|
||||
[New Relic 쿠버네티스](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration) 통합은 쿠버네티스 환경의 성능에 대한 가시성을 향상시킨다. New Relic의 쿠버네티스 통합은 쿠버네티스 오브젝트의 메트릭을 리포팅하는 것으로 컨테이너 오케스트레이션 계층을 측정한다. 통합을 통해 쿠버네티스 노드, 네임스페이스, 디플로이먼트, 레플리카 셋, 파드, 컨테이너에 대한 인사이트를 얻을 수 있다.
|
||||
|
||||
중요 기능:
|
||||
사전 구축된 대시보드에서 데이터를 확인하여 쿠버네티스 환경에 대한 즉각적인 인사이트를 확인한다.
|
||||
자동으로 보고되는 데이터의 인사이트로 커스텀 쿼리와 차트를 생성한다.
|
||||
쿠버네티스 데이터에 대해 경고 조건을 생성한다.
|
||||
이 [페이지](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration)에서 더 알아볼 수 있다.
|
||||
CNCF 프로젝트인, [프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다.
|
||||
CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 쿠버네티스 문서의 범위가 아니다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -285,7 +285,7 @@ HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수
|
|||
`kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2beta1
|
||||
apiVersion: autoscaling/v2beta2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ weight: 10
|
|||
<div class="col-md-8">
|
||||
<p>
|
||||
첫 번째 디플로이먼트로, 도커 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자.
|
||||
(Node.js 애플리케이션을 작성하고 Node.js 애플리케이션을 배포하고, 컨테이너를 활용해서 배포해보지 않았다면,
|
||||
(Node.js 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면,
|
||||
<a href="/ko/docs/tutorials/hello-minikube/">Hello Minikube 튜토리얼</a>의 지시를 따른다.)</p>
|
||||
<p>
|
||||
|
||||
|
|
|
|||
|
|
@ -146,12 +146,12 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
|||
|
||||
서비스를 삭제하려면, 아래의 명령어를 입력한다.
|
||||
|
||||
kubectl delete services my-service
|
||||
kubectl delete services my-service
|
||||
|
||||
Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 셋, 파드를 삭제하려면,
|
||||
아래의 명령어를 입력한다.
|
||||
|
||||
kubectl delete deployment hello-world
|
||||
kubectl delete deployment hello-world
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
kind: PersistentVolume
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: mysql-pv-volume
|
||||
labels:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
apiVersion: apps/v1
|
||||
kind: ReplicaSet
|
||||
metadata:
|
||||
name: frontend
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
spec:
|
||||
# 케이스에 따라 레플리카를 수정한다.
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
tier: frontend
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
tier: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: php-redis
|
||||
image: gcr.io/google_samples/gb-frontend:v3
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
apiVersion: autoscaling/v1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: frontend-scaler
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
kind: ReplicaSet
|
||||
name: frontend
|
||||
minReplicas: 3
|
||||
maxReplicas: 10
|
||||
targetCPUUtilizationPercentage: 50
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx-deployment
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pod1
|
||||
labels:
|
||||
tier: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: hello1
|
||||
image: gcr.io/google-samples/hello-app:2.0
|
||||
|
||||
---
|
||||
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pod2
|
||||
labels:
|
||||
tier: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: hello2
|
||||
image: gcr.io/google-samples/hello-app:1.0
|
||||
Loading…
Reference in New Issue