Fourth Korean l10n work for release-1.15 (#16063)
* ko: update translation in reference/glossary/* (#15776) * Update outdated files partly in dev-1.15-ko.4 (#15856) * ko: update translation in tasks/debug-application-cluster/resource-metrics-pipeline (#15798) * ko: translate setup/production-environment/tools/control-plane-flags (#15820) * ko: translate user-guide-windows-containers (#15730) * ko: update translation in reference/glossary/* (#15761) * ko: Update outdated files partly in dev-1.15-ko.4 (#15790) * ko: fix corrupt date in glossary/static-pod (#15911) * ko: translate user-guide-windows-nodes (#15759) * Translate /docs/concepts/configuration/overview/ in Korean (#15803) * ko: translate setup/production-environment/tools/ha-topology (#15819) * ko: translate tasks/administer-cluster/network-policy-provider (#15846) * Translate tasks/inject-data-application/define-command-argument-container in Korea (#15933) * ko: translate concepts/configuration/organize-cluster-access-kubeconfig (#15871) * Translate working-with-objects/common-labels.md in Korean (#15832) * Translate concepts/workloads/pods/disruptions.md in Korean (#15926) * Translate tasks/access-application-cluster/web-ui/dashboard in Korean (#15852) * Translate concepts/overview/working-with-objects/labels.md in Korean (#15831) * ko: translate guestbook-logs-metrics-with-elk (#15894) * ko: translate tasks/administer-cluster/highly-available-master (#15928) Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: Eden <longlg88@naver.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com> Co-Authored-By: alice_k106 <alice_k106@naver.com> Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
This commit is contained in:
Seokho Son
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
270aaf1f16
commit
c82a912e29
@@ -22,6 +22,10 @@ weight: 10
|
||||
* [용량과 할당가능](#capacity)
|
||||
* [정보](#info)
|
||||
|
||||
노드의 상태와 상세 정보는 다음 커맨드를 통해 확인할 수 있다.
|
||||
```shell
|
||||
kubectl describe node <insert-node-name-here>
|
||||
```
|
||||
각 섹션은 아래 상세하게 기술되었다.
|
||||
|
||||
### 주소 {#addresses}
|
||||
@@ -88,7 +92,8 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
|
||||
|
||||
### 정보 {#info}
|
||||
|
||||
커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은 노드에 대한 일반적인 정보이다. 정보는 Kubelet에 의해 노드로부터 수집된다.
|
||||
커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다.
|
||||
이 정보는 Kubelet에 의해 노드로부터 수집된다.
|
||||
|
||||
## 관리
|
||||
|
||||
|
||||
@@ -0,0 +1,156 @@
|
||||
---
|
||||
title: kubeconfig 파일을 사용하여 클러스터 접근 구성하기
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 및 인증 메커니즘에 대한 정보를 관리하자.
|
||||
`kubectl` 커맨드라인 툴은 kubeconfig 파일을 사용하여
|
||||
클러스터의 선택과
|
||||
클러스터의 API 서버와의 통신에 필요한 정보를 찾는다.
|
||||
|
||||
{{< note >}}
|
||||
클러스터에 대한 접근을 구성하는 데 사용되는 파일을 *kubeconfig 파일* 이라 한다.
|
||||
이는 구성 파일을 참조하는 일반적인 방법을 의미한다.
|
||||
`kubeconfig`라는 이름의 파일이 있다는 의미는 아니다.
|
||||
{{< /note >}}
|
||||
|
||||
기본적으로 `kubectl`은 `$HOME/.kube` 디렉터리에서 `config`라는 이름의 파일을 찾는다.
|
||||
`KUBECONFIG` 환경 변수를 설정하거나
|
||||
[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) 플래그를 지정해서
|
||||
다른 kubeconfig 파일을 사용할 수 있다.
|
||||
|
||||
kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은
|
||||
[다중 클러스터로 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)를 참조한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 다중 클러스터, 사용자와 인증 메커니즘 지원
|
||||
|
||||
여러 클러스터가 있고, 사용자와 구성 요소가 다양한 방식으로 인증한다고 가정하자.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
- 실행 중인 kubelet은 인증서를 이용하여 인증할 수 있다.
|
||||
- 사용자는 토큰으로 인증할 수 있다.
|
||||
- 관리자는 개별 사용자에게 제공하는 인증서 집합을 가지고 있다.
|
||||
|
||||
kubeconfig 파일을 사용하면 클러스터와 사용자와 네임스페이스를 구성할 수 있다.
|
||||
또한 컨텍스트를 정의하여
|
||||
빠르고 쉽게 클러스터와 네임스페이스 간에 전환할 수 있다.
|
||||
|
||||
## 컨텍스트
|
||||
|
||||
kubeconfig에서 *컨텍스트* 요소는 편리한 이름으로 접속 매개 변수를 묶는데 사용한다.
|
||||
각 컨텍스트는 클러스터, 네임스페이스와 사용자라는 세 가지 매개 변수를 가진다.
|
||||
기본적으로 `kubectl` 커맨드라인 툴은 *현재 컨텍스트* 의 매개 변수를
|
||||
사용하여 클러스터와 통신한다.
|
||||
|
||||
현재 컨택스트를 선택하려면 다음을 실행한다.
|
||||
```
|
||||
kubectl config use-context
|
||||
```
|
||||
|
||||
## KUBECONFIG 환경 변수
|
||||
|
||||
`KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다.
|
||||
Linux 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다.
|
||||
Windows는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다.
|
||||
`KUBECONFIG` 환경 변수가 없으면,
|
||||
`kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다.
|
||||
|
||||
`KUBECONFIG` 환경 변수가 존재하면, `kubectl`은
|
||||
`KUBECONFIG` 환경 변수에 나열된 파일을 병합한 결과 형태의
|
||||
효과적 구성을 이용한다.
|
||||
|
||||
## kubeconfig 파일 병합
|
||||
|
||||
구성을 보려면, 다음 커맨드를 입력한다.
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
앞서 설명한 것처럼, 이 출력 내용은 단일 kubeconfig 파일이나
|
||||
여러 kubeconfig 파일을 병합한 결과 일 수 있다.
|
||||
|
||||
다음은 kubeconfig 파일을 병합할 때에 `kubectl`에서 사용하는 규칙이다.
|
||||
|
||||
1. `--kubeconfig` 플래그를 설정했으면, 지정한 파일만 사용한다. 병합하지 않는다.
|
||||
이 플래그는 오직 한 개 인스턴스만 허용한다.
|
||||
|
||||
그렇지 않고, `KUBECONFIG` 환경 변수를 설정하였다면
|
||||
병합해야 하는 파일의 목록으로 사용한다.
|
||||
`KUBECONFIG` 환경 변수의 나열된 파일은
|
||||
다음 규칙에 따라 병합한다.
|
||||
|
||||
* 빈 파일명은 무시한다.
|
||||
* 역 직렬화 불가한 파일 내용에 대해서 오류를 일으킨다.
|
||||
* 특정 값이나 맵 키를 설정한 첫 번째 파일을 우선한다.
|
||||
* 값이나 맵 키를 변경하지 않는다.
|
||||
예: `현재 컨텍스트`를 설정할 첫 번째 파일의 컨택스트를 유지한다.
|
||||
예: 두 파일이 `red-user`를 지정했다면, 첫 번째 파일의 `red-user` 값만을 사용한다.
|
||||
두 번째 파일의 `red-user` 하위에 충돌하지 않는 항목이 있어도 버린다.
|
||||
|
||||
`KUBECONFIG` 환경 변수 설정의 예로,
|
||||
[KUBECONFIG 환경 변수 설정](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)를 참조한다.
|
||||
|
||||
그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다.
|
||||
|
||||
1. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다.
|
||||
|
||||
1. 커맨드라인 플래그의 `--context`를 사용한다.
|
||||
1. 병합된 kubeconfig 파일에서 `current-context`를 사용한다.
|
||||
|
||||
이 시점에서는 빈 컨텍스트도 허용한다.
|
||||
|
||||
1. 클러스터와 사용자를 결정한다. 이 시점에서는 컨텍스트가 있을 수도 있고 없을 수도 있다.
|
||||
사용자에 대해 한 번, 클러스터에 대해 한 번 총 두 번에 걸친
|
||||
이 체인에서 첫 번째 것을 기반으로 클러스터와 사용자를 결정한다.
|
||||
|
||||
1. 커맨드라인 플래그가 존재하면, `--user` 또는 `--cluster`를 사용한다.
|
||||
1. 컨텍스트가 비어있지 않다면, 컨텍스트에서 사용자 또는 클러스터를 가져온다.
|
||||
|
||||
이 시점에서는 사용자와 클러스터는 비워둘 수 있다.
|
||||
|
||||
1. 사용할 실제 클러스터 정보를 결정한다.
|
||||
이 시점에서 클러스터 정보가 있을 수 있고 없을 수도 있다.
|
||||
이 체인을 기반으로 클러스터 정보를 구축한다. 첫 번째 것을 사용한다.
|
||||
|
||||
1. 커맨드라인 플래그가 존재하면, `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`를 사용한다.
|
||||
1. 병합된 kubeconfig 파일에서 클러스터 정보 속성이 있다면 사용한다.
|
||||
1. 서버 위치가 없다면 실패한다.
|
||||
|
||||
1. 사용할 실제 사용자 정보를 결정한다.
|
||||
사용자 당 하나의 인증 기법만 허용하는 것을 제외하고는
|
||||
클러스터 정보와 동일한 규칙을 사용하여 사용자 정보를 작성한다.
|
||||
|
||||
1. 커맨드라인 플래그가 존재하면, `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`을 사용한다.
|
||||
1. 병합된 kubeconfig 파일에서 `user` 필드를 사용한다.
|
||||
1. 충돌하는 두 가지 기법이 있다면 실패한다.
|
||||
|
||||
1. 여전히 누락된 정보는 기본 값을 사용하고
|
||||
인증 정보를 묻는 메시지가 표시될 수 있다.
|
||||
|
||||
## 파일 참조
|
||||
|
||||
kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치와 관련 있다.
|
||||
커맨드라인 상에 파일 참조는 현재 디렉터리를 기준으로 한다.
|
||||
`$HOME/.kube/config`에서 상대 경로는 상대적으로, 절대 경로는
|
||||
절대적으로 저장한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [다중 클러스터 접근 구성하기](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
title: 구성 모범 사례
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 구성 모범 사례를 강조하고 통합한다.
|
||||
|
||||
이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, 새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## 일반적인 구성 팁
|
||||
|
||||
- 구성을 정의할 때, 안정된 최신 API 버전을 명시한다.
|
||||
|
||||
- 구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면 구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의 재-생성과 복원을 도와준다.
|
||||
|
||||
- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
|
||||
|
||||
- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
|
||||
|
||||
- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
|
||||
|
||||
- 불필요하게 기본 값을 명시하지 않는다. 간단하고 최소한의 설정은 에러를 덜 발생시킨다.
|
||||
|
||||
- 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다.
|
||||
|
||||
|
||||
## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡
|
||||
|
||||
- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
|
||||
|
||||
명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
|
||||
|
||||
|
||||
## 서비스
|
||||
|
||||
- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
|
||||
|
||||
```shell
|
||||
FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
|
||||
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
|
||||
```
|
||||
|
||||
*이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다.
|
||||
|
||||
- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/docs/concepts/cluster-administration/addons/)은 DNS 서버이다.
|
||||
DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다.
|
||||
|
||||
- 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다.
|
||||
|
||||
만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
|
||||
|
||||
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.
|
||||
|
||||
- `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.
|
||||
|
||||
- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-
|
||||
services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
|
||||
|
||||
## 레이블 사용하기
|
||||
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
|
||||
|
||||
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
|
||||
|
||||
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
|
||||
|
||||
- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카 셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
|
||||
|
||||
## 컨테이너 이미지
|
||||
|
||||
[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/admin/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다.
|
||||
|
||||
- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다.
|
||||
|
||||
- `imagePullPolicy: Always`: 파드가 시작될 때마다 이미지가 풀(Pull) 된다.
|
||||
|
||||
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다.
|
||||
|
||||
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `IfNotPresent`가 적용된다.
|
||||
|
||||
- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
|
||||
|
||||
{{< note >}}
|
||||
컨테이너가 항상 같은 버전의 이미지를 사용하도록 만들기 위해, `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`와 같은 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
운영 환경에서 컨테이너를 생성할 때 `:latest` 태그의 사용을 피하는 것이 좋은데, 이는 어떠한 버전의 이미지가 실행 중인지 추적하기가 어렵고, 적절히 롤백하기가 더 어려워지기 때문이다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
기반이 되는 이미지 제공자의 캐시 방법은 `imagePullPolicy: Always`를 효율적으로 만든다. 예를 들어, 도커에서는 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
|
||||
{{< /note >}}
|
||||
|
||||
## kubectl 사용하기
|
||||
|
||||
- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.
|
||||
|
||||
- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.
|
||||
|
||||
- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -57,7 +57,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
|
||||
- 각 클러스터에 대하여
|
||||
- Google 컴퓨트 엔진 또는 Google 쿠버네티스 엔진에서 자동적으로 구성됨
|
||||
- 모든 파드는 해당 프로젝트의 프라이빗 레지스트리를 읽을 수 있음
|
||||
- AWS EC2 컨테이너 레지스트리(ECR) 사용
|
||||
- AWS Elastic Container Registry(ECR) 사용
|
||||
- IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함
|
||||
- ECR 로그인 자격 증명은 자동으로 갱신됨
|
||||
- Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용
|
||||
@@ -67,7 +67,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
|
||||
- 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
|
||||
- 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
|
||||
- 클러스터 관리자에 의한 노드 구성 필요
|
||||
- 미리 풀링(pre-pulling)된 이미지
|
||||
- 미리 내려받은(pre-pulled) 이미지
|
||||
- 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
|
||||
- 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
|
||||
- 파드에 ImagePullSecrets을 명시
|
||||
@@ -89,10 +89,9 @@ Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 GCR을
|
||||
인스턴스의 서비스 계정은 `https://www.googleapis.com/auth/devstorage.read_only`라서,
|
||||
프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다.
|
||||
|
||||
### AWS EC2 컨테이너 레지스트리 사용
|
||||
### Amazon Elastic Container Registry 사용
|
||||
|
||||
쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [AWS EC2 컨테이너
|
||||
레지스트리](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다.
|
||||
쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다.
|
||||
|
||||
간단히 이미지의 전체 이름(예: `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)을
|
||||
파드 정의에 사용하면 된다.
|
||||
@@ -240,7 +239,7 @@ kubectl describe pods/private-image-test-1 | grep "Failed"
|
||||
프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는
|
||||
프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.
|
||||
|
||||
### 미리 풀링(pre-pulling)된 이미지
|
||||
### 미리 내려받은 이미지
|
||||
|
||||
{{< note >}}
|
||||
Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
|
||||
@@ -257,11 +256,11 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
|
||||
로컬 이미지가 사용된다(우선적으로 또는 배타적으로).
|
||||
|
||||
레지스트리 인증의 대안으로 미리 풀 된 이미지에 의존하고 싶다면,
|
||||
클러스터의 모든 노드가 동일한 미리 풀 된 이미지를 가지고 있는지 확인해야 한다.
|
||||
클러스터의 모든 노드가 동일한 미리 내려받은 이미지를 가지고 있는지 확인해야 한다.
|
||||
|
||||
이것은 특정 이미지를 속도를 위해 미리 로드하거나 프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다.
|
||||
|
||||
모든 파드는 미리 풀 된 이미지에 대해 읽기 접근 권한을 가질 것이다.
|
||||
모든 파드는 미리 내려받은 이미지에 대해 읽기 접근 권한을 가질 것이다.
|
||||
|
||||
### 파드에 ImagePullSecrets 명시
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ card:
|
||||
## 마스터 컴포넌트
|
||||
|
||||
마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
|
||||
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
|
||||
(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동 시키는 것)를 감지하고 반응한다.
|
||||
|
||||
마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
|
||||
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
|
||||
@@ -110,6 +110,9 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
|
||||
[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
|
||||
검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
|
||||
|
||||
* [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
|
||||
* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기
|
||||
* etcd의 공식 [문서](https://etcd.io/docs/) 읽기
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: 권장 레이블
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝트를 시각화 하고 관리할 수 있다.
|
||||
공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고
|
||||
도구들이 상호 운용적으로 작동할 수 있도록 한다.
|
||||
|
||||
권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
메타데이터는 _애플리케이션_ 의 개념을 중심으로 정리된다.
|
||||
쿠버네티스는 플랫폼 서비스(PaaS)가 아니며 애플리케이션에 대해 공식적인 개념이 없거나 강요하지 않는다.
|
||||
대신 애플리케이션은 비공식적이며 메타데이터로 설명된다.
|
||||
애플리케이션에 포함된 정의는 유연하다.
|
||||
|
||||
{{< note >}}
|
||||
메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 코어 도구에는 필요하지 않다.
|
||||
{{< /note >}}
|
||||
|
||||
공유 레이블과 주석에는 공통 접두사인 `app.kubernetes.io` 가 있다.
|
||||
접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다.
|
||||
공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다.
|
||||
|
||||
|
||||
## 레이블
|
||||
|
||||
레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다.
|
||||
|
||||
| Key | Description | Example | Type |
|
||||
| ----------------------------------- | --------------------- | -------- | ---- |
|
||||
| `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 |
|
||||
| `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `wordpress-abcxzy` | 문자열 |
|
||||
| `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 |
|
||||
| `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 |
|
||||
| `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 |
|
||||
| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는데 사용되는 도구 | `helm` | 문자열 |
|
||||
|
||||
위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: mysql
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/version: "5.7.21"
|
||||
app.kubernetes.io/component: database
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
app.kubernetes.io/managed-by: helm
|
||||
```
|
||||
|
||||
## 애플리케이션과 애플리케이션 인스턴스
|
||||
|
||||
애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 한번 또는 그 이상 설치할 수 있다.
|
||||
예를 들어 워드프레스는 다른 워드프레스가 설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다.
|
||||
|
||||
애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다.
|
||||
예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는
|
||||
`app.kubernetes.io/instance` 에 `wordpress-abcxzy` 의 값을 가진다.
|
||||
이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다.
|
||||
모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
|
||||
|
||||
## 예시
|
||||
|
||||
위 레이블을 사용하는 다른 방식에 대한 예시는 다양한 복잡성이 있다.
|
||||
|
||||
### 단순한 스테이트리스 서비스
|
||||
|
||||
`Deployment` 와 `Service` 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다.
|
||||
|
||||
`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는데 사용한다.
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: myservice
|
||||
app.kubernetes.io/instance: myservice-abcxzy
|
||||
...
|
||||
```
|
||||
|
||||
`Service`는 애플리케이션을 노출하기 위해 사용한다.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: myservice
|
||||
app.kubernetes.io/instance: myservice-abcxzy
|
||||
...
|
||||
```
|
||||
|
||||
### 데이터베이스가 있는 웹 애플리케이션
|
||||
|
||||
Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다.
|
||||
다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다.
|
||||
|
||||
WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: wordpress
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/version: "4.9.4"
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: server
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
...
|
||||
```
|
||||
|
||||
`Service` 는 애플리케이션을 노출하기 위해 사용한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: wordpress
|
||||
app.kubernetes.io/instance: wordpress-abcxzy
|
||||
app.kubernetes.io/version: "4.9.4"
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: server
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
...
|
||||
```
|
||||
|
||||
MySQL은 `StatefulSet` 에 MySQL의 소속과 상위 애플리케이션에 대한 메타데이터가 포함되어 노출된다.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: mysql
|
||||
app.kubernetes.io/instance: mysql-abcxzy
|
||||
app.kubernetes.io/version: "5.7.21"
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: database
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
...
|
||||
```
|
||||
|
||||
`Service` 는 WordPress의 일부로 MySQL을 노출하는데 이용한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: mysql
|
||||
app.kubernetes.io/instance: mysql-abcxzy
|
||||
app.kubernetes.io/version: "5.7.21"
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/component: database
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
...
|
||||
```
|
||||
|
||||
MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,225 @@
|
||||
---
|
||||
title: 레이블과 셀렉터
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
_레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다.
|
||||
레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다.
|
||||
레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다.
|
||||
오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.
|
||||
|
||||
```json
|
||||
"metadata": {
|
||||
"labels": {
|
||||
"key1" : "value1",
|
||||
"key2" : "value2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 사용동기
|
||||
|
||||
레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.
|
||||
|
||||
서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔터티들이다(예: 다중파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
|
||||
|
||||
레이블 예시:
|
||||
|
||||
* `"release" : "stable"`, `"release" : "canary"`
|
||||
* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"`
|
||||
* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"`
|
||||
* `"partition" : "customerA"`, `"partition" : "customerB"`
|
||||
* `"track" : "daily"`, `"track" : "weekly"`
|
||||
|
||||
레이블 예시는 일반적으로 사용하는 경우에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야한다는 것을 기억해야한다.
|
||||
|
||||
## 구문과 캐릭터 셋
|
||||
|
||||
_레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(`/`)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야하며, 점(`.`)과, 전체 253자 이하, 슬래시(`/`)로 구분되는 DNS 레이블이다.
|
||||
|
||||
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 구성 요소(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
|
||||
|
||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 구성요소로 예약되어있다.
|
||||
|
||||
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
||||
|
||||
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
|
||||
|
||||
```yaml
|
||||
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: label-demo
|
||||
labels:
|
||||
environment: production
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
|
||||
```
|
||||
|
||||
## 레이블 셀렉터
|
||||
|
||||
[이름과 UID](/docs/user-guide/identifiers)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
|
||||
|
||||
레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.
|
||||
|
||||
API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 셀렉터를 지원한다.
|
||||
레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다.
|
||||
|
||||
비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다.
|
||||
셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화 해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충되는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
|
||||
{{< /note >}}
|
||||
|
||||
### _일치성 기준_ 요건
|
||||
|
||||
_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만 레이블의 명시된 제약 조건을 모두 만족해야 한다.
|
||||
`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_를 의미한다. 예를 들면,
|
||||
|
||||
```
|
||||
environment = production
|
||||
tier != frontend
|
||||
```
|
||||
|
||||
전자는 `environment`를 키로 가지는 것과 `production`를 값으로 가지는 모든 리소스를 선택한다.
|
||||
후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다.
|
||||
`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다.
|
||||
|
||||
균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
|
||||
예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다.
|
||||
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: cuda-test
|
||||
spec:
|
||||
containers:
|
||||
- name: cuda-test
|
||||
image: "k8s.gcr.io/cuda-vector-add:v0.1"
|
||||
resources:
|
||||
limits:
|
||||
nvidia.com/gpu: 1
|
||||
nodeSelector:
|
||||
accelerator: nvidia-tesla-p100
|
||||
```
|
||||
|
||||
### _집합성 기준_ 요건
|
||||
|
||||
_집합성 기준_ 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. `in`,`notin` and `exists`(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면,
|
||||
|
||||
```
|
||||
environment in (production, qa)
|
||||
tier notin (frontend, backend)
|
||||
partition
|
||||
!partition
|
||||
```
|
||||
|
||||
첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
|
||||
두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와, 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
|
||||
세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하는 모든 리소스를 선택한다.
|
||||
네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`를 포함하지 않는 모든 리소스를 선택한다.
|
||||
마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
|
||||
_집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production` 과 `environment in (production)`를 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.
|
||||
|
||||
_집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa`
|
||||
|
||||
## API
|
||||
|
||||
### LIST와 WATCH 필터링
|
||||
|
||||
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
|
||||
|
||||
* _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
* _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||
|
||||
두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `API 서버`를 대상으로 _불일치 기준_으로 하는 셀렉터를 다음과 같이 이용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l environment=production,tier=frontend
|
||||
```
|
||||
|
||||
또는 _집합성 기준_ 요건을 사용하면
|
||||
|
||||
```shell
|
||||
kubectl get pods -l 'environment in (production),tier in (frontend)'
|
||||
```
|
||||
|
||||
앞서 안내한 것처럼 _집합성 기준_ 요건은 더 보여준다. 예시에서 다음과 같이 OR 연산자를 구현할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l 'environment in (production, qa)'
|
||||
```
|
||||
|
||||
또는 _exists_ 연산자에 불일치한 것으로 제한할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l 'environment,environment notin (frontend)'
|
||||
```
|
||||
|
||||
### API 오브젝트에서 참조 설정
|
||||
|
||||
[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
|
||||
|
||||
#### 서비스와 리플리케이션 컨트롤러
|
||||
|
||||
`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
|
||||
|
||||
서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
|
||||
|
||||
```json
|
||||
"selector": {
|
||||
"component" : "redis",
|
||||
}
|
||||
```
|
||||
or
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
component: redis
|
||||
```
|
||||
|
||||
`json` 또는 `yaml` 서식에서 셀렉터는 `component=redis` 또는 `component in (redis)` 모두 같은 것이다.
|
||||
|
||||
|
||||
#### 세트-기반 요건을 지원하는 리소스
|
||||
|
||||
[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
matchLabels:
|
||||
component: redis
|
||||
matchExpressions:
|
||||
- {key: tier, operator: In, values: [cache]}
|
||||
- {key: environment, operator: NotIn, values: [dev]}
|
||||
```
|
||||
|
||||
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`과 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
|
||||
|
||||
#### 노드 셋 선택
|
||||
|
||||
레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
|
||||
자세한 내용은 [노드 선택](/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -61,13 +61,13 @@ kube-public Active 1d
|
||||
|
||||
### 요청에 네임스페이스 설정하기
|
||||
|
||||
임시로 네임스페이스를 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다.
|
||||
네임스페이스를 현재 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다.
|
||||
|
||||
예를 들면,
|
||||
|
||||
```shell
|
||||
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
|
||||
kubectl --namespace=<insert-namespace-name-here> get pods
|
||||
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
|
||||
kubectl get pods --namespace=<insert-namespace-name-here>
|
||||
```
|
||||
|
||||
### 선호하는 네임스페이스 설정하기
|
||||
@@ -108,3 +108,10 @@ kubectl api-resources --namespaced=false
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
|
||||
* [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+12
-6
@@ -8,14 +8,20 @@ weight: 70
|
||||
|
||||
{{< feature-state for_k8s_version="1.14" state="beta" >}}
|
||||
|
||||
Kube-scheduler는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
|
||||
노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는
|
||||
클러스터의 노드를 파드에 "적합한(feasible)" 노드라고 한다. 스케줄러는
|
||||
파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를
|
||||
측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장
|
||||
높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 "바인딩"이라는 프로세스로
|
||||
[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
|
||||
는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
|
||||
노드에 파드를 배치하는 역할을 한다.
|
||||
|
||||
파드의 스케줄링 요건을 충족하는
|
||||
클러스터의 노드를 파드에 _적합한(feasible)_ 노드라고 한다. 스케줄러는
|
||||
파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를
|
||||
측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장
|
||||
높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 _바인딩_ 이라는 프로세스로
|
||||
API 서버에 해당 결정을 통지한다.
|
||||
|
||||
본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
|
||||
최적화에 대해 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
@@ -0,0 +1,252 @@
|
||||
---
|
||||
title: 중단(disruption)
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 가이드는 고가용성 애플리케이션을 구성하려는 소유자와
|
||||
파드에서 발생하는 장애 유형을 이해하기
|
||||
원하는 애플리케이션 소유자를 위한 것이다.
|
||||
|
||||
또한 클러스터의 업그레이드와 오토스케일링과 같은
|
||||
클러스터의 자동화 작업을 하려는 관리자를 위한 것이다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 자발적 중단과 비자발적 중단
|
||||
|
||||
파드는 누군가(사람 또는 컨트롤러)가 파괴하거나
|
||||
불가피한 하드웨어 오류 또는 시스템 소프트웨어 오류가 아니면 사라지지 않는다.
|
||||
|
||||
우리는 이런 불가피한 상황을 애플리케이션의 *비자발적 중단* 으로 부른다.
|
||||
예시:
|
||||
|
||||
- 노드를 지원하는 물리 머신의 하드웨어 오류
|
||||
- 클러스터 관리자의 실수로 VM(인스턴스) 삭제
|
||||
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
|
||||
- 커널 패닉
|
||||
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
|
||||
- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨
|
||||
|
||||
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
|
||||
왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다.
|
||||
|
||||
우리는 다른 상황을 *자발적인 중단* 으로 부른다.
|
||||
여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다.
|
||||
다음은 대표적인 애플리케이션 소유자의 작업이다.
|
||||
|
||||
- 디플로이먼트 제거 또는 다른 파드를 관리하는 컨트롤러의 제거
|
||||
- 재시작을 유발하는 디플로이먼트의 파드 템플릿 업데이트
|
||||
- 파드를 직접 삭제(예: 우연히)
|
||||
|
||||
클러스터 관리자의 작업:
|
||||
|
||||
- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
|
||||
- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기).
|
||||
- 노드에 다른 무언가를 추가하기 위해 파드를 제거.
|
||||
|
||||
위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며,
|
||||
클러스터 호스팅 공급자에 의해서도 수행된다.
|
||||
|
||||
클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지
|
||||
클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다.
|
||||
만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다.
|
||||
예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다.
|
||||
{{< /caution >}}
|
||||
|
||||
## 중단 다루기
|
||||
|
||||
비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다.
|
||||
|
||||
- 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다.
|
||||
- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.)
|
||||
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는
|
||||
영역 간(또는 [다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다.)에
|
||||
애플리케이션을 분산해야 한다.
|
||||
|
||||
자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
|
||||
그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다.
|
||||
예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다.
|
||||
또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
|
||||
클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
|
||||
|
||||
쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을
|
||||
실행 할 수 있는 기능을 제공한다.
|
||||
우리는 이 기능을 *Disruption Budgets* 이라 부른다.
|
||||
|
||||
## Disruption Budgets의 작동 방식
|
||||
|
||||
애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다.
|
||||
PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
|
||||
예를 들어 정족수 기반의 애플리케이션이
|
||||
실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다.
|
||||
웹 프런트 엔드는 부하를 처리하는 레플리카의 수가
|
||||
일정 비율 이하로 떨어지지 않도록 보장할 수 있다.
|
||||
|
||||
클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
|
||||
[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
|
||||
불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다.
|
||||
예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다.
|
||||
|
||||
클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다.
|
||||
해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다.
|
||||
축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나
|
||||
설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다.
|
||||
|
||||
PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다.
|
||||
예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다.
|
||||
만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다.
|
||||
|
||||
파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며
|
||||
애플리케이션 컨트롤러(디플로이먼트, 스테이트풀 셋 등)를 사용한 것과 같다.
|
||||
|
||||
파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다.
|
||||
컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다.
|
||||
|
||||
PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만,
|
||||
버짓이 차감된다.
|
||||
|
||||
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
|
||||
그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다.
|
||||
애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
|
||||
([디플로이먼트 업데이트](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)에 대해 알아보기.)
|
||||
|
||||
파드를 Eviction API로 축출하면 정상적으로 종료된다.
|
||||
([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.)
|
||||
|
||||
## PDB 예시
|
||||
|
||||
`node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자.
|
||||
클러스터에는 여러 애플리케이션을 실행하고 있다.
|
||||
여러 애플리케이션 중 하나는 `pod-a`, `pod-b`, `pod-c` 로 부르는 3개의 레플리카가 있다. 여기에 `pod-x` 라고 부르는 PDB와 무관한 파드가 보인다.
|
||||
초기에 파드는 다음과 같이 배치된다.
|
||||
|
||||
| node-1 | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *available* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *available* | | |
|
||||
|
||||
전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다.
|
||||
|
||||
예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자.
|
||||
클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다.
|
||||
`kubectl` 은 `pod-a` 과 `pod-x` 를 축출하려고 한다. 이는 즉시 성공한다.
|
||||
두 파드는 동시에 `terminating` 상태로 진입한다.
|
||||
이렇게 하면 클러스터는 다음의 상태가 된다.
|
||||
|
||||
| node-1 *draining* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *terminating* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *terminating* | | |
|
||||
|
||||
디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, `pod-d` 라는 대체 파드를 생성한다.
|
||||
`node-1` 은 차단되어 있어 다른 노드에 위치한다.
|
||||
무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다.
|
||||
|
||||
(참고: 스테이트풀 셋은 `pod-1`처럼 불릴, `pod-a`를
|
||||
교체하기 전에 완전히 중지해야 하며, `pod-1` 로 불리지만, 다른 UID로 생성된다.
|
||||
그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.)
|
||||
|
||||
이제 클러스터는 다음과 같은 상태이다.
|
||||
|
||||
| node-1 *draining* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *terminating* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *terminating* | pod-d *starting* | pod-y |
|
||||
|
||||
어느 순간 파드가 종료되고, 클러스터는 다음과 같은 상태가 된다.
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* |
|
||||
| | pod-d *starting* | pod-y |
|
||||
|
||||
이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을
|
||||
비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고,
|
||||
PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d`가 available 상태가 된다.
|
||||
|
||||
이제 클러스터는 다음과 같은 상태이다.
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* |
|
||||
| | pod-d *available* | pod-y |
|
||||
|
||||
이제 클러스터 관리자는 `node-2` 를 비우려고 한다.
|
||||
drain 커멘드는 `pod-b`에서 `pod-d`와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다.
|
||||
drain 커멘드는 `pod-b`를 축출하는데 성공했다.
|
||||
그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우
|
||||
디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다.
|
||||
|
||||
디플로이먼트는`pod-b` 를 대체할 `pod-e`라는 파드를 생성한다.
|
||||
클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에
|
||||
드레이닝 명령어는 차단된다.
|
||||
클러스터는 다음 상태로 끝나게 된다.
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 | *no node* |
|
||||
|:--------------------:|:-------------------:|:------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* | pod-e *pending* |
|
||||
| | pod-d *available* | pod-y | |
|
||||
|
||||
이 시점에서 클러스터 관리자는
|
||||
클러스터에 노드를 추가해서 업그레이드를 진행해야 한다.
|
||||
|
||||
쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지
|
||||
다음의 사례를 통해 알 수 있다.
|
||||
|
||||
- 애플리케이션에 필요한 레플리카의 수
|
||||
- 인스턴스를 정상적으로 종료하는데 소요되는 시간
|
||||
- 새 인스턴스를 시작하는데 소요되는 시간
|
||||
- 컨트롤러의 유형
|
||||
- 클러스터의 리소스 용량
|
||||
|
||||
## 클러스터 소유자와 애플리케이션 소유자의 역할 분리
|
||||
|
||||
보통 클러스터 매니저와 애플리케이션 소유자는
|
||||
서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다.
|
||||
이와 같은 책임의 분리는
|
||||
다음의 시나리오에서 타당할 수 있다.
|
||||
|
||||
- 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우
|
||||
- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우
|
||||
|
||||
Pod Disruption Budgets는 역할 분리에 따라
|
||||
역할에 맞는 인터페이스를 제공한다.
|
||||
|
||||
만약 조직에 역할 분리에 따른 책임의 분리가 없다면
|
||||
Pod Disruption Budgets를 사용할 필요가 없다.
|
||||
|
||||
## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법
|
||||
|
||||
만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은
|
||||
중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다.
|
||||
|
||||
- 업그레이드 하는 동안 다운타임을 허용한다.
|
||||
- 다른 레플리카 클러스터로 장애조치를 한다.
|
||||
- 다운타임은 없지만, 노드 사본과
|
||||
전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다.
|
||||
- PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다.
|
||||
- 다운타임 없음
|
||||
- 최소한의 리소스 중복
|
||||
- 클러스터 관리의 자동화 확대 적용
|
||||
- 내결함성이 있는 애플리케이션의 작성은 까다롭지만
|
||||
자발적 중단를 허용하는 작업의 대부분은 오토스케일링과
|
||||
비자발적 중단를 지원하는 작업과 겹친다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다.
|
||||
|
||||
* [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -19,7 +19,7 @@ card:
|
||||
|
||||
파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.
|
||||
|
||||
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다.
|
||||
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다.
|
||||
|
||||
|
||||
쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다.
|
||||
|
||||
@@ -139,7 +139,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
|
||||
[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
|
||||
위와 같은 기능 제공을 할 수 있다.
|
||||
|
||||
사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
|
||||
사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
|
||||
|
||||
|
||||
파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다:
|
||||
@@ -176,7 +176,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
|
||||
|
||||
### 파드 강제 삭제
|
||||
|
||||
파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, apiserver는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다.
|
||||
파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다.
|
||||
API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다.
|
||||
노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user