Forth Korean l10n work for release-1.19
- Fix ko glossary managed service title (#24621) - Translate reference/glossary/service-broker.md in Korean (#24632) - Translate reference/command-line-tools-reference/kubelet-authentication-authorization.md into korean (#24623) - Update outdated files in the dev-1.19-ko.4 branch (#24622) - Translate setup/production-environment/tools/kubeadm/self-hosting/ into Korean (#24655) - Translate reference/kubectl/kubectl.md into Korean (#24482) - docs: fix typo (#24713) - Translate connecting-frontend-backend to Korean (#24422) - Translate reference/kubectl/conventions.md into Korean (#24614) - Translate k8s 1.19 relaese note in korean (#24633) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: santachopa <santachopa@naver.com> Co-authored-by: kosehy@gmail.com <kosehy@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: markruler <csu0414@gmail.com> Co-authored-by: noel <neutiyoo@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: chhanz <han0495@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com>pull/24833/head
Jerry Park
Seokho Son
parent
253eff2827
commit
6d27247c1e
|
|
@ -2,11 +2,13 @@
|
|||
title: "운영 수준의 컨테이너 오케스트레이션"
|
||||
abstract: "자동화된 컨테이너 배포, 스케일링과 관리"
|
||||
cid: home
|
||||
sitemap:
|
||||
priority: 1.0
|
||||
---
|
||||
|
||||
{{< blocks/section id="oceanNodes" >}}
|
||||
{{% blocks/feature image="flower" %}}
|
||||
### [쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
|
||||
[쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
|
||||
|
||||
애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
|
||||
{{% /blocks/feature %}}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
linktitle: 쿠버네티스 문서
|
||||
title: 문서
|
||||
sitemap:
|
||||
priority: 1.0
|
||||
---
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ weight: 10
|
|||
{{< glossary_tooltip text="파드" term_id="pod" >}}를
|
||||
실행하는데 필요한 서비스가 포함되어 있다.
|
||||
|
||||
일반적으로 클러스터에는 여러개의 노드가 있으며, 학습 또는 리소스가 제한되는
|
||||
일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는
|
||||
환경에서는 하나만 있을 수도 있다.
|
||||
|
||||
노드의 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에는
|
||||
|
|
|
|||
|
|
@ -16,7 +16,6 @@ weight: 20
|
|||
{{< /caution >}}
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## 사용 동기
|
||||
|
||||
|
|
@ -24,25 +23,38 @@ weight: 20
|
|||
|
||||
예를 들어, 자신의 컴퓨터(개발용)와 클라우드(실제 트래픽 처리)에서
|
||||
실행할 수 있는 애플리케이션을 개발한다고 가정해보자.
|
||||
`DATABASE_HOST` 라는
|
||||
환경 변수를 찾기 위해 코드를 작성한다. 로컬에서는 해당 변수를
|
||||
`localhost` 로 설정한다. 클라우드에서는, 데이터베이스
|
||||
컴포넌트를 클러스터에 노출하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}를 참조하도록
|
||||
설정한다.
|
||||
|
||||
`DATABASE_HOST` 라는 환경 변수를 찾기 위해 코드를 작성한다.
|
||||
로컬에서는 해당 변수를 `localhost` 로 설정한다. 클라우드에서는, 데이터베이스
|
||||
컴포넌트를 클러스터에 노출하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}를
|
||||
참조하도록 설정한다.
|
||||
이를 통해 클라우드에서 실행 중인 컨테이너 이미지를 가져와
|
||||
필요한 경우 정확히 동일한 코드를 로컬에서 디버깅할 수 있다.
|
||||
|
||||
컨피그맵은 많은 양의 데이터를 보유하도록 설계되지 않았다. 컨피그맵에 저장된
|
||||
데이터는 1MiB를 초과할 수 없다. 이 제한보다 큰 설정을
|
||||
저장해야 하는 경우, 볼륨을 마운트하는 것을 고려하거나 별도의
|
||||
데이터베이스 또는 파일 서비스를 사용할 수 있다.
|
||||
|
||||
## 컨피그맵 오브젝트
|
||||
|
||||
컨피그맵은 다른 오브젝트가 사용할 구성을 저장할 수 있는
|
||||
API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)이다.
|
||||
`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리,
|
||||
컨피그맵에는 항목(키)과 해당 값을 저장하는 `data` 섹션이 있다.
|
||||
`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData`
|
||||
필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와
|
||||
`binaryData` 는 모두 선택 사항이다. `data` 필드는
|
||||
UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 데이터를
|
||||
포함하도록 설계되었다.
|
||||
|
||||
컨피그맵의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
|
||||
`data` 또는 `binaryData` 필드 아래의 각 키는
|
||||
영숫자 문자, `-`, `_` 또는 `.` 으로 구성되어야 한다. `data` 에 저장된 키는
|
||||
`binaryData` 필드의 키와 겹치지 않아야 한다.
|
||||
|
||||
v1.19부터 컨피그맵 정의에 `immutable` 필드를 추가하여
|
||||
[변경할 수 없는 컨피그맵](#configmap-immutable)을 만들 수 있다.
|
||||
|
||||
## 컨피그맵과 파드
|
||||
|
||||
컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를
|
||||
|
|
@ -62,7 +74,7 @@ data:
|
|||
# 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨
|
||||
player_initial_lives: "3"
|
||||
ui_properties_file_name: "user-interface.properties"
|
||||
#
|
||||
|
||||
# 파일과 비슷한 키
|
||||
game.properties: |
|
||||
enemy.types=aliens,monsters
|
||||
|
|
@ -94,6 +106,7 @@ data:
|
|||
기술을 사용하여 다른 네임스페이스의 컨피그맵에 접근할 수도 있다.
|
||||
|
||||
다음은 `game-demo` 의 값을 사용하여 파드를 구성하는 파드 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
|
|
@ -102,7 +115,8 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: demo
|
||||
image: game.example/demo-game
|
||||
image: alpine
|
||||
command: ["sleep", "3600"]
|
||||
env:
|
||||
# 환경 변수 정의
|
||||
- name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과
|
||||
|
|
@ -134,7 +148,6 @@ spec:
|
|||
path: "user-interface.properties"
|
||||
```
|
||||
|
||||
|
||||
컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을
|
||||
구분하지 않는다.
|
||||
더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다.
|
||||
|
|
@ -153,7 +166,6 @@ spec:
|
|||
노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
|
||||
컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의
|
||||
파드에서 실행되는 컨테이너에 대한 설정을 구성하는 것이다. 컨피그맵을
|
||||
별도로 사용할 수도 있다.
|
||||
|
|
@ -162,16 +174,23 @@ spec:
|
|||
컨피그맵에 기반한 동작을 조정하는 {{< glossary_tooltip text="애드온" term_id="addons" >}}이나
|
||||
{{< glossary_tooltip text="오퍼레이터" term_id="operator-pattern" >}}를
|
||||
사용할 수도 있다.
|
||||
{{< /note >}}
|
||||
|
||||
### 파드에서 컨피그맵을 파일로 사용하기
|
||||
|
||||
파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.
|
||||
|
||||
1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다.
|
||||
1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name` 필드를 설정한다.
|
||||
1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
|
||||
1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다.
|
||||
1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을
|
||||
참조할 수 있다.
|
||||
1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은
|
||||
원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name`
|
||||
필드를 설정한다.
|
||||
1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를
|
||||
추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고
|
||||
컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로
|
||||
`.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
|
||||
1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을
|
||||
수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의
|
||||
파일 이름이 된다.
|
||||
|
||||
다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다.
|
||||
|
||||
|
|
@ -225,12 +244,14 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
|
|||
데이터 변경을 방지하면 다음과 같은 이점이 있다.
|
||||
|
||||
- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
|
||||
- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
|
||||
- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써
|
||||
클러스터의 성능을 향상시킴
|
||||
|
||||
이 기능은 `ImmutableEphemeralVolumes`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 의해 제어된다.
|
||||
`immutable` 필드를 `true` 로 설정하여 변경할 수 없는 컨피그맵을 생성할 수 있다.
|
||||
다음은 예시이다.
|
||||
|
||||
이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
|
||||
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
|
||||
의해 제어된다. `immutable` 필드를 `true` 로 설정하여
|
||||
변경할 수 없는 컨피그맵을 생성할 수 있다. 다음은 예시이다.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
|
|
@ -242,15 +263,14 @@ immutable: true
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나
|
||||
`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다.
|
||||
기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는
|
||||
것을 권장한다.
|
||||
컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
|
||||
`data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만
|
||||
삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
|
||||
유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 읽어본다.
|
||||
* [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다.
|
||||
* 코드를 구성에서 분리하려는 동기를 이해하려면
|
||||
|
|
|
|||
|
|
@ -47,6 +47,13 @@ feature:
|
|||
또는 강제적(시스템이 컨테이너가 제한을 초과하지 않도록 방지)으로 구현할 수 있다. 런타임마다
|
||||
다른 방식으로 동일한 제약을 구현할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
컨테이너가 자체 메모리 제한을 지정하지만, 메모리 요청을 지정하지 않는 경우, 쿠버네티스는
|
||||
제한과 일치하는 메모리 요청을 자동으로 할당한다. 마찬가지로, 컨테이너가 자체 CPU 제한을
|
||||
지정하지만, CPU 요청을 지정하지 않는 경우, 쿠버네티스는 제한과 일치하는 CPU 요청을 자동으로
|
||||
할당한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 리소스 타입
|
||||
|
||||
*CPU* 와 *메모리* 는 각각 *리소스 타입* 이다. 리소스 타입에는 기본 단위가 있다.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 30
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서
|
||||
이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서
|
||||
컨테이너 라이프사이클 훅 프레임워크를 사용하는 방법에 대해서 설명한다.
|
||||
|
||||
|
||||
|
|
@ -16,9 +16,9 @@ weight: 30
|
|||
|
||||
## 개요
|
||||
|
||||
Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게,
|
||||
Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게,
|
||||
쿠버네티스도 컨테이너에 라이프사이클 훅을 제공한다.
|
||||
훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는
|
||||
훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는
|
||||
라이프사이클 훅이 실행될 때 핸들러에 구현된 코드를 실행할 수 있게 한다.
|
||||
|
||||
## 컨테이너 훅
|
||||
|
|
@ -33,12 +33,12 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
|
|||
|
||||
`PreStop`
|
||||
|
||||
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다.
|
||||
그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로,
|
||||
컨테이너를 삭제하기 위한 호출이 전송되기 전에 완료되어야한다.
|
||||
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다.
|
||||
그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로,
|
||||
컨테이너를 중지하기 위한 신호가 전송되기 전에 완료되어야 한다.
|
||||
파라미터는 핸들러에 전달되지 않는다.
|
||||
|
||||
종료 동작에 더 자세한 대한 설명은
|
||||
종료 동작에 더 자세한 대한 설명은
|
||||
[파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다.
|
||||
|
||||
### 훅 핸들러 구현
|
||||
|
|
@ -52,34 +52,46 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
|
|||
|
||||
### 훅 핸들러 실행
|
||||
|
||||
컨테이너 라이프사이클 관리 훅이 호출되면,
|
||||
쿠버네티스 관리 시스템은 해당 훅이 등록된 컨테이너에서 핸들러를 실행한다.
|
||||
컨테이너 라이프사이클 관리 훅이 호출되면,
|
||||
쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고,
|
||||
`exec` 와 `tcpSocket` 은 컨테이너에서 실행되고, `httpGet` 은 kubelet 프로세스에 의해 실행된다.
|
||||
|
||||
훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 맥락과 동기적으로 동작한다.
|
||||
이것은 `PostStart` 훅에 대해서,
|
||||
훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다.
|
||||
이것은 `PostStart` 훅에 대해서,
|
||||
훅이 컨테이너 엔트리포인트와는 비동기적으로 동작함을 의미한다.
|
||||
그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면,
|
||||
그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면,
|
||||
컨테이너는 `running` 상태에 이르지 못한다.
|
||||
|
||||
이러한 동작은 `PreStop` 훅에 대해서도 비슷하게 일어난다.
|
||||
만약 훅이 실행되던 도중에 매달려 있다면,
|
||||
파드의 단계(phase)는 `Terminating` 상태에 머물고 해당 훅은 파드의 `terminationGracePeriodSeconds`가 끝난 다음에 종료된다.
|
||||
`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로
|
||||
실행되지 않는다. 훅은 신호를 보내기 전에 실행을
|
||||
완료해야 한다.
|
||||
실행 중에 `PreStop` 훅이 중단되면,
|
||||
파드의 단계는 `Terminating` 이며 `terminationGracePeriodSeconds` 가
|
||||
만료된 후 파드가 종료될 때까지 남아 있다.
|
||||
이 유예 기간은 `PreStop` 훅이 실행되고 컨테이너가
|
||||
정상적으로 중지되는 데 걸리는 총 시간에 적용된다.
|
||||
예를 들어, `terminationGracePeriodSeconds` 가 60이고, 훅이
|
||||
완료되는 데 55초가 걸리고, 컨테이너가 신호를 수신한 후
|
||||
정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후
|
||||
컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데
|
||||
걸리는 총 시간(55+10)보다 적다.
|
||||
|
||||
만약 `PostStart` 또는 `PreStop` 훅이 실패하면,
|
||||
그것은 컨테이너를 종료시킨다.
|
||||
|
||||
사용자는 훅 핸들러를 가능한 한 가볍게 만들어야 한다.
|
||||
그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이,
|
||||
그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이,
|
||||
오래 동작하는 커맨드가 의미 있는 경우도 있다.
|
||||
|
||||
### 훅 전달 보장
|
||||
|
||||
훅 전달은 *한 번 이상* 으로 의도되어 있는데,
|
||||
이는 `PostStart` 또는 `PreStop`와 같은 특정 이벤트에 대해서,
|
||||
훅 전달은 *한 번 이상* 으로 의도되어 있는데,
|
||||
이는 `PostStart` 또는 `PreStop`와 같은 특정 이벤트에 대해서,
|
||||
훅이 여러 번 호출될 수 있다는 것을 의미한다.
|
||||
이것을 올바르게 처리하는 것은 훅의 구현에 달려 있다.
|
||||
|
||||
일반적으로, 전달은 단 한 번만 이루어진다.
|
||||
예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도,
|
||||
예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도,
|
||||
재전송을 시도하지 않는다.
|
||||
그러나, 드문 경우로, 이중 전달이 발생할 수 있다.
|
||||
예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면,
|
||||
|
|
@ -88,8 +100,8 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
|
|||
### 디버깅 훅 핸들러
|
||||
|
||||
훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
|
||||
만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
|
||||
`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
|
||||
만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
|
||||
`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
|
||||
`PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
|
||||
이 이벤트는 `kubectl describe pod <파드_이름>`를 실행하면 볼 수 있다.
|
||||
다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.
|
||||
|
|
@ -117,5 +129,3 @@ Events:
|
|||
* [컨테이너 환경](/ko/docs/concepts/containers/container-environment/)에 대해 더 배우기.
|
||||
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
실습 경험하기.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/referenc
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
|
||||
- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
|
||||
- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
|
||||
- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ kubectl에서
|
|||
|
||||
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
|
||||
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
|
||||
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
||||
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
||||
4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
|
||||
5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
|
||||
6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
|
||||
|
|
|
|||
|
|
@ -7,21 +7,17 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
{{< caution >}}알파 기능은 빨리 변경될 수 있다. {{< /caution >}}
|
||||
|
||||
쿠버네티스의 네트워크 플러그인은 몇 가지 종류가 있다.
|
||||
|
||||
* CNI 플러그인: 상호 운용성을 위해 설계된 appc/CNI 명세를 준수한다.
|
||||
* CNI 플러그인: 상호 운용성을 위해 설계된 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 명세를 준수한다.
|
||||
* 쿠버네티스는 CNI 명세의 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 릴리스를 따른다.
|
||||
* Kubenet 플러그인: `bridge` 와 `host-local` CNI 플러그인을 사용하여 기본 `cbr0` 구현한다.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 설치
|
||||
|
||||
kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(rkt는 자체 CNI 플러그인을 관리하므로 Docker에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
|
||||
kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
|
||||
|
||||
* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
|
||||
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 단순히 "cni"이다.
|
||||
|
|
@ -30,7 +26,7 @@ kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에
|
|||
|
||||
파드 네트워킹을 구성하고 정리하기 위해 [`NetworkPlugin` 인터페이스](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)를 제공하는 것 외에도, 플러그인은 kube-proxy에 대한 특정 지원이 필요할 수 있다. iptables 프록시는 분명히 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. 예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 리눅스 브리지를 사용하지 않는 경우(그러나 Open vSwitch나 다른 메커니즘과 같은 기능을 사용함) 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
|
||||
|
||||
kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 Docker 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
|
||||
kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
|
||||
|
||||
### CNI
|
||||
|
||||
|
|
@ -146,7 +142,7 @@ Kubenet은 `cbr0` 라는 리눅스 브리지를 만들고 각 쌍의 호스트
|
|||
|
||||
최상의 네트워킹 성능을 얻으려면 MTU를 항상 올바르게 구성해야 한다. 네트워크 플러그인은 일반적으로 합리적인 MTU를
|
||||
유추하려고 시도하지만, 때로는 로직에 따라 최적의 MTU가 지정되지 않는다. 예를 들어,
|
||||
Docker 브리지나 다른 인터페이스에 작은 MTU가 지정되어 있으면, kubenet은 현재 해당 MTU를 선택한다. 또는
|
||||
도커 브리지나 다른 인터페이스에 작은 MTU가 지정되어 있으면, kubenet은 현재 해당 MTU를 선택한다. 또는
|
||||
IPSEC 캡슐화를 사용하는 경우, MTU를 줄여야 하며, 이 계산은 대부분의
|
||||
네트워크 플러그인에서 범위를 벗어난다.
|
||||
|
||||
|
|
@ -161,10 +157,3 @@ AWS에서 `eth0` MTU는 일반적으로 9001이므로, `--network-plugin-mtu=900
|
|||
* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
|
||||
* `--network-plugin=kubenet` 은 `/opt/cni/bin` 또는 `cni-bin-dir` 에 있는 CNI `bridge` 및 `host-local` 플러그인과 함께 kubenet 네트워크 플러그인을 사용하도록 지정한다.
|
||||
* 현재 kubenet 네트워크 플러그인에서만 사용하는 `--network-plugin-mtu=9001` 은 사용할 MTU를 지정한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ kubectl에서
|
|||
|
||||
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
|
||||
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
|
||||
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
||||
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
||||
4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/#스케줄러-익스텐션) 섹션에 설명되어 있다.
|
||||
5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
|
||||
6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
|
|||
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
|
||||
* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
|
||||
사용하여 직접 구현하기
|
||||
* [오퍼레이터 프레임워크](https://github.com/operator-framework/getting-started) 사용하기
|
||||
* [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
|
||||
* 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
|
||||
* 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기
|
||||
* 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기
|
||||
|
|
|
|||
|
|
@ -2,4 +2,6 @@
|
|||
title: "개요"
|
||||
weight: 20
|
||||
description: 쿠버네티스와 그 컴포넌트에 대한 하이-레벨(high-level) 개요를 제공한다.
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
---
|
||||
|
|
|
|||
|
|
@ -39,6 +39,7 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
|
|||
다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다.
|
||||
|
||||
<table>
|
||||
<caption style="display:none">Valid request header values for OpenAPI v2 queries</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Header</th>
|
||||
|
|
@ -66,7 +67,6 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
|
|||
<td><em>serves </em><code>application/json</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
<caption>Valid request header values for OpenAPI v2 queries</caption>
|
||||
</table>
|
||||
|
||||
쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
|
||||
|
|
@ -100,13 +100,22 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를
|
|||
수명 종료 및/또는 실험적 API에 대한 접근을
|
||||
제어할 수 있도록 한다.
|
||||
|
||||
API 버전 수준 정의에 대한 자세한 내용은
|
||||
[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
|
||||
|
||||
보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는
|
||||
[활성화 또는 비활성화](/ko/docs/reference/using-api/api-overview/#api-그룹-활성화-또는-비활성화-하기)가
|
||||
가능한 [API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 구현한다.
|
||||
|
||||
API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스
|
||||
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한
|
||||
기본 데이터를 제공하고 API 버전 간의 변환을 투명하게
|
||||
처리할 수 있다. 이 모든 다른 버전은 실제로
|
||||
동일한 리소스의 표현이다. 예를 들어, 동일한 리소스에 대해 두 가지
|
||||
버전 `v1` 과 `v1beta1` 이 있다고 가정한다. 그런 다음 `v1beta1` 버전에서
|
||||
생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 읽고 업데이트하고
|
||||
삭제할 수 있다.
|
||||
|
||||
API 버전 수준 정의에 대한 자세한 내용은
|
||||
[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
|
||||
|
||||
## API 확장
|
||||
|
||||
쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.
|
||||
|
|
|
|||
|
|
@ -7,6 +7,8 @@ weight: 10
|
|||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -24,9 +24,6 @@ weight: 30
|
|||
|
||||
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다.
|
||||
|
||||
이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로
|
||||
동일한 접근 제어 정책을 갖게 된다.
|
||||
|
||||
동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
|
||||
여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를
|
||||
구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을
|
||||
|
|
|
|||
|
|
@ -44,9 +44,9 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
|
|||
* [NGINX, Inc.](https://www.nginx.com/)는
|
||||
[쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
|
||||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
|
||||
* [Traefik](https://github.com/containous/traefik)은
|
||||
* [Traefik](https://github.com/traefik/traefik)은
|
||||
모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
|
||||
[Containous](https://containo.us/services)에서 상업적인 지원을 제공한다.
|
||||
[Traefik Labs](https://traefik.io)에서 상업적인 지원을 제공한다.
|
||||
|
||||
## 여러 인그레스 컨트롤러 사용
|
||||
|
||||
|
|
|
|||
|
|
@ -408,7 +408,7 @@ type: kubernetes.io/tls
|
|||
|
||||
인그레스에서 시크릿을 참조하면 인그레스 컨트롤러가 TLS를 사용하여
|
||||
클라이언트에서 로드 밸런서로 채널을 보호하도록 지시한다. 생성한
|
||||
TLS 시크릿이 `sslexample.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고
|
||||
TLS 시크릿이 `https-example.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고
|
||||
하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다.
|
||||
|
||||
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
|
||||
|
|
|
|||
|
|
@ -234,7 +234,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
|
|||
이 모드에서는, kube-proxy는 쿠버네티스 마스터의 서비스, 엔드포인트 오브젝트의
|
||||
추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
|
||||
포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
|
||||
연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
|
||||
연결은 (엔드포인트를 통해 보고된 대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
|
||||
kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
|
||||
`SessionAffinity` 설정을 고려한다.
|
||||
|
||||
|
|
@ -879,6 +879,10 @@ Classic ELB의 연결 드레이닝은
|
|||
# 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
|
||||
# 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.
|
||||
|
||||
service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
|
||||
# 생성된 ELB에 추가할 기존 보안 그룹 목록.
|
||||
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다.
|
||||
|
||||
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
|
||||
# ELB에 추가될 추가 보안 그룹(security group) 목록
|
||||
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ Events: <none>
|
|||
기본 볼륨 플러그인에서 지원하는 경우 `Recycle` 반환 정책은 볼륨에서 기본 스크럽(`rm -rf /thevolume/*`)을 수행하고 새 클레임에 다시 사용할 수 있도록 한다.
|
||||
|
||||
그러나 관리자는 [레퍼런스](/docs/reference/command-line-tools-reference/kube-controller-manager/)에
|
||||
설명된대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를
|
||||
설명된 대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를
|
||||
사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다.
|
||||
사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 `volumes` 명세가
|
||||
포함되어야 한다.
|
||||
|
|
@ -168,6 +168,45 @@ spec:
|
|||
|
||||
그러나 `volumes` 부분의 사용자 정의 재활용 파드 템플릿에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 바뀐다.
|
||||
|
||||
### 퍼시스턴트볼륨 예약
|
||||
|
||||
컨트롤 플레인은 클러스터에서 [퍼시스턴트볼륨클레임을 일치하는 퍼시스턴트볼륨에 바인딩](#바인딩)할
|
||||
수 있다. 그러나, PVC를 특정 PV에 바인딩하려면, 미리 바인딩해야 한다.
|
||||
|
||||
퍼시스턴트볼륨클레임에서 퍼시스턴트볼륨을 지정하여, 특정 PV와 PVC 간의 바인딩을 선언한다.
|
||||
퍼시스턴트볼륨이 존재하고 `claimRef` 필드를 통해 퍼시스턴트볼륨클레임을 예약하지 않은 경우, 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이 바인딩된다.
|
||||
|
||||
바인딩은 노드 선호도(affinity)를 포함하여 일부 볼륨 일치(matching) 기준과 관계없이 발생한다.
|
||||
컨트롤 플레인은 여전히 [스토리지 클래스](https://kubernetes.io/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다.
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: foo-pvc
|
||||
namespace: foo
|
||||
spec:
|
||||
volumeName: foo-pv
|
||||
...
|
||||
```
|
||||
|
||||
이 메서드는 퍼시스턴트볼륨에 대한 바인딩 권한을 보장하지 않는다. 다른 퍼시스턴트볼륨클레임에서 지정한 PV를 사용할 수 있는 경우, 먼저 해당 스토리지 볼륨을 예약해야 한다. PV의 `claimRef` 필드에 관련 퍼시스턴트볼륨클레임을 지정하여 다른 PVC가 바인딩할 수 없도록 한다.
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: foo-pv
|
||||
spec:
|
||||
claimRef:
|
||||
name: foo-pvc
|
||||
namespace: foo
|
||||
...
|
||||
```
|
||||
|
||||
이는 기존 PV를 재사용하는 경우를 포함하여 `claimPolicy` 가
|
||||
`Retain` 으로 설정된 퍼시스턴트볼륨을 사용하려는 경우에 유용하다.
|
||||
|
||||
### 퍼시스턴트 볼륨 클레임 확장
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
|
||||
|
|
|
|||
|
|
@ -3,4 +3,55 @@ title: "워크로드"
|
|||
weight: 50
|
||||
description: >
|
||||
쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화
|
||||
no_list: true
|
||||
---
|
||||
|
||||
{{< glossary_definition term_id="workload" length="short" >}}
|
||||
워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의
|
||||
[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
|
||||
쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
|
||||
집합을 나타낸다.
|
||||
|
||||
파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고
|
||||
해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서
|
||||
심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
|
||||
최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다.
|
||||
|
||||
그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다.
|
||||
대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다.
|
||||
이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이
|
||||
실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를
|
||||
구성한다.
|
||||
|
||||
이러한 워크로드 리소스에는 다음이 포함된다.
|
||||
|
||||
* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
|
||||
(레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체);
|
||||
* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/);
|
||||
* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는
|
||||
파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
|
||||
* 완료될 때까지 실행되는 작업에 대한
|
||||
[잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및
|
||||
[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cronjob/)
|
||||
|
||||
관련성을 찾을 수 있는 두 가지 지원 개념도 있다.
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
제거된 후 클러스터에서 오브젝트를 정리한다.
|
||||
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
|
||||
완료된 이후 정의된 시간이 경과되면 잡을 제거한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
|
||||
|
||||
* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
* 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
|
||||
또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
|
||||
* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
|
||||
|
||||
일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로
|
||||
사용하거나, 웹 애플리케이션의 경우에만
|
||||
[인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다.
|
||||
|
||||
[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의
|
||||
메커니즘에 대해 알아볼 수도 있다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: "컨트롤러"
|
||||
title: "워크로드 리소스"
|
||||
weight: 20
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1015,7 +1015,7 @@ echo $?
|
|||
### 실패한 디플로이먼트에서의 운영
|
||||
|
||||
완료된 디플로이먼트에 적용되는 모든 행동은 실패한 디플로이먼트에도 적용된다.
|
||||
디플로이먼트 파드 템플릿에서 여러개의 수정사항을 적용해야하는 경우 스케일 업/다운 하거나, 이전 수정 버전으로 롤백하거나, 일시 중지할 수 있다.
|
||||
디플로이먼트 파드 템플릿에서 여러 개의 수정사항을 적용해야하는 경우 스케일 업/다운 하거나, 이전 수정 버전으로 롤백하거나, 일시 중지할 수 있다.
|
||||
|
||||
## 정책 초기화
|
||||
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ kubectl delete replicaset my-repset --cascade=false
|
|||
### 디플로이먼트에 대한 추가 참고
|
||||
|
||||
1.7 이전에서는 디플로이먼트와 캐스케이딩 삭제를 사용하면 반드시 `propagationPolicy: Foreground`
|
||||
를 사용해서 생성된 레플리카셋 뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
|
||||
를 사용해서 생성된 레플리카셋뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
|
||||
유형을 사용하지 않는다면, 레플리카셋만 삭제되고 파드는 분리된 상태로 남을 것이다.
|
||||
더 많은 정보는 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)를 본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -200,7 +200,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
|
|||
두 번 시작하는 경우가 있다는 점을 참고한다.
|
||||
|
||||
`.spec.parallelism` 그리고 `.spec.completions` 를 모두 1보다 크게 지정한다면 한번에
|
||||
여러개의 파드가 실행될 수 있다. 따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다.
|
||||
여러 개의 파드가 실행될 수 있다. 따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다.
|
||||
|
||||
### 파드 백오프(backoff) 실패 정책
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ card:
|
|||
_파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
|
||||
|
||||
_파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
|
||||
{{< glossary_tooltip text="컨테이너" term_id="container" >}}의 그룹이다.
|
||||
[컨테이너](/ko/docs/concepts/containers/)의 그룹이다.
|
||||
이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
|
||||
함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
|
||||
애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
|
||||
|
|
|
|||
|
|
@ -26,8 +26,8 @@ weight: 40
|
|||
* 초기화 컨테이너는 항상 완료를 목표로 실행된다.
|
||||
* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
|
||||
|
||||
만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
|
||||
반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
|
||||
만약 파드의 초기화 컨테이너가 실패하면, kubelet은 초기화 컨테이너가 성공할 때까지 반복적으로 재시작한다.
|
||||
그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정하고, 해당 파드를 시작하는 동안 초기화 컨테이너가 실패하면, 쿠버네티스는 전체 파드를 실패한 것으로 처리한다.
|
||||
|
||||
컨테이너를 초기화 컨테이너로 지정하기 위해서는,
|
||||
파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
|
||||
|
|
|
|||
|
|
@ -13,7 +13,8 @@ weight: 30
|
|||
|
||||
파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시
|
||||
시작할 수 있다. 파드 내에서, 쿠버네티스는 다양한 컨테이너
|
||||
[상태](#컨테이너-상태)와 핸들을 추적한다.
|
||||
[상태](#컨테이너-상태)를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를
|
||||
결정한다.
|
||||
|
||||
쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다.
|
||||
파드 오브젝트의 상태는 일련의 [파드 조건](#파드의-조건)으로 구성된다.
|
||||
|
|
@ -314,7 +315,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
|
|||
|
||||
### 언제 스타트업 프로브를 사용해야 하는가?
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
|
||||
파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
|
||||
|
|
@ -342,7 +343,9 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
|
|||
종료를 시도한다.
|
||||
|
||||
일반적으로, 컨테이너 런타임은 각 컨테이너의 기본 프로세스에 TERM 신호를
|
||||
전송한다. 일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
|
||||
전송한다. 많은 컨테이너 런타임은 컨테이너 이미지에 정의된 `STOPSIGNAL` 값을 존중하며
|
||||
TERM 대신 이 값을 보낸다.
|
||||
일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
|
||||
전송되고, 그런 다음 파드는
|
||||
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}로부터 삭제된다. 프로세스가
|
||||
종료될 때까지 기다리는 동안 kubelet 또는 컨테이너 런타임의 관리 서비스가 다시 시작되면, 클러스터는
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ graph BT
|
|||
|
||||
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
|
||||
|
||||
이 경우에는, 첫번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
|
||||
이 경우에는, 첫 번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
|
||||
|
||||
다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,6 +13,13 @@ card:
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
*쿠버네티스는 신규 및 숙련된 모든 기여자의 개선을 환영합니다!*
|
||||
|
||||
{{< note >}}
|
||||
일반적인 쿠버네티스에 기여하는 방법에 대한 자세한 내용은
|
||||
[기여자 문서](https://www.kubernetes.dev/docs/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다.
|
||||
|
||||
쿠버네티스 문서 기여자들은
|
||||
|
|
@ -22,8 +29,6 @@ card:
|
|||
- 문서를 번역합니다.
|
||||
- 쿠버네티스 릴리스 주기에 맞추어 문서 부분을 관리하고 발행합니다.
|
||||
|
||||
쿠버네티스 문서는 새롭고 경험이 풍부한 모든 기여자의 개선을 환영합니다!
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 시작하기
|
||||
|
|
|
|||
|
|
@ -190,7 +190,7 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의
|
|||
|
||||
문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과
|
||||
같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다.
|
||||
문서와 관련이 없는 이슈의 경우, `kind/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
|
||||
문서와 관련이 없는 이슈의 경우, `triage/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
|
||||
알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우,
|
||||
관련 리포지터리를 코멘트로 남긴다(`kubernetes/kubernetes` 는
|
||||
시작하기 좋은 곳이다).
|
||||
|
|
@ -221,6 +221,3 @@ https://github.com/kubernetes/kubernetes 에서
|
|||
|
||||
문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ weight: 60
|
|||
* **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
|
||||
* **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당).
|
||||
* **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
|
||||
* **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/concepts/overview/kubernetes-api/)을 지정한다.
|
||||
* **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 지정한다.
|
||||
|
||||
## 요청 동사 결정
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,83 @@
|
|||
---
|
||||
title: Kubelet 인증/인가
|
||||
---
|
||||
|
||||
|
||||
## 개요
|
||||
|
||||
kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 노출시키며,
|
||||
노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다.
|
||||
|
||||
이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다.
|
||||
|
||||
## Kubelet 인증
|
||||
|
||||
기본적으로, 다른 구성의 인증 방법에 의해 거부되지 않은 kubelet의 HTTPS 엔드포인트에 대한 요청은
|
||||
익명의 요청으로 처리되며, `system:anonymous`의 사용자 이름과 `system:unauthenticated`
|
||||
의 그룹이 부여된다.
|
||||
|
||||
익명의 접근을 비활성화하고 인증되지 않은 요청에 `401 Unauthorized` 응답을 보내려면 아래를 참고한다.
|
||||
|
||||
* `--anonymous-auth=false` 플래그로 kubelet을 시작
|
||||
|
||||
kubelet의 HTTPS 엔드포인트에 대한 X509 클라이언트 인증서 인증을 활성화하려면 아래를 참고한다.
|
||||
|
||||
* `--client-ca-file` 플래그로 kubelet을 시작하면 클라이언트 인증서를 확인할 수 있는 CA 번들을 제공
|
||||
* `--kubelet-client-certificate` 및 `--kubelet-client-key` 플래그로 apiserver를 시작
|
||||
* 자세한 내용은 [apiserver 인증 문서](/docs/reference/access-authn-authz/authentication/#x509-client-certs)를 참고
|
||||
|
||||
API bearer 토큰(서비스 계정 토큰 포함)을 kubelet의 HTTPS 엔드포인트 인증에 사용하려면 아래를 참고한다.
|
||||
|
||||
* API 서버에서 `authentication.k8s.io/v1beta1` API 그룹이 사용 가능한지 확인
|
||||
* `--authentication-token-webhook` 및 `--kubeconfig` 플래그로 kubelet을 시작
|
||||
* kubelet은 구성된 API 서버의 `TokenReview` API를 호출하여 bearer 토큰에서 사용자 정보를 결정
|
||||
|
||||
## Kubelet 승인
|
||||
|
||||
성공적으로 인증된 모든 요청(익명 요청 포함)이 승인된다. 기본 인가 모드는 모든 요청을 허용하는 `AlwaysAllow` 이다.
|
||||
|
||||
kubelet API에 대한 접근을 세분화하는 데는 다양한 이유가 있다.
|
||||
|
||||
* 익명 인증을 사용할 수 있지만, 익명 사용자의 kubelet API 호출 기능은 제한되어야 함
|
||||
* bearer 토큰 인증을 사용할 수 있지만, 임의의 API 사용자(API 계정)의 kubelet API 호출 기능은 제한되어야 함
|
||||
* 클라이언트 인증을 사용할 수 있지만, 구성된 CA에서 서명한 일부 클라이언트 인증서만 kubelet API를 사용하도록 허용해야 함
|
||||
|
||||
kubelet API에 대한 접근을 세분화하려면 API 서버에 권한을 위임한다.
|
||||
|
||||
* `authorization.k8s.io/v1beta1` API 그룹이 API 서버에서 사용 가능한지 확인
|
||||
* `--authorization-mode=Webhook` 및 `--kubeconfig` 플래그로 kubelet을 시작
|
||||
* kubelet은 구성된 API 서버의 `SubjectAccessReview` API를 호출하여 각각의 요청이 승인되었는지 여부를 확인
|
||||
|
||||
kubelet은 API 요청을 apiserver와 동일한 [요청 속성](/ko/docs/reference/access-authn-authz/authorization/#요청-속성-검토) 접근 방식을 사용하여 승인한다.
|
||||
|
||||
동사는 들어오는 요청의 HTTP 동사로부터 결정된다.
|
||||
|
||||
HTTP 동사 | 요청 동사
|
||||
----------|---------------
|
||||
POST | create
|
||||
GET, HEAD | get
|
||||
PUT | update
|
||||
PATCH | patch
|
||||
DELETE | delete
|
||||
|
||||
리소스 및 하위 리소스는 들어오는 요청의 경로로부터 결정된다.
|
||||
|
||||
Kubelet API | 리소스 | 하위 리소스
|
||||
-------------|----------|------------
|
||||
/stats/\* | nodes | stats
|
||||
/metrics/\* | nodes | metrics
|
||||
/logs/\* | nodes | log
|
||||
/spec/\* | nodes | spec
|
||||
*all others* | nodes | proxy
|
||||
|
||||
네임스페이스와 API 그룹 속성은 항상 빈 문자열이며,
|
||||
리소스 이름은 항상 kubelet의 `Node` API 오브젝트 이름이다.
|
||||
|
||||
이 모드로 실행할 때, `--kubelet-client-certificate` 및 `--kubelet-client-key` 플래그로 식별된 사용자에게
|
||||
다음 속성에 대한 권한이 있는지 확인한다.
|
||||
|
||||
* verb=\*, resource=nodes, subresource=proxy
|
||||
* verb=\*, resource=nodes, subresource=stats
|
||||
* verb=\*, resource=nodes, subresource=log
|
||||
* verb=\*, resource=nodes, subresource=spec
|
||||
* verb=\*, resource=nodes, subresource=metrics
|
||||
|
|
@ -6,14 +6,12 @@ full_link: /docs/reference/generated/kubelet
|
|||
short_description: >
|
||||
클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
클러스터의 각 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행되는 에이전트. Kubelet은 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 {{< glossary_tooltip text="컨테이너" term_id="container" >}}가 확실하게 동작하도록 관리한다.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 매니지드 서비스
|
||||
title: 매니지드 서비스(Managed Service)
|
||||
id: managed-service
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: 서비스 브로커(Service Broker)
|
||||
id: service-broker
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
서드파티에서 제공하고 유지 관리하는 일련의 매니지드 서비스에 대한 엔드포인트이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- extension
|
||||
---
|
||||
서드파티에서 제공하고 유지 관리하는 일련의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}에 대한 엔드포인트이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}는
|
||||
[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)를
|
||||
구현하고 애플리케이션이 매니지드 서비스를 사용할 수 있도록 표준 인터페이스를 제공한다.
|
||||
[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는
|
||||
서비스 브로커가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
|
||||
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
title: kubectl 사용 규칙
|
||||
|
||||
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
`kubectl`에 대한 권장 사용 규칙.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 재사용 가능한 스크립트에서 `kubectl` 사용
|
||||
|
||||
스크립트의 안정적인 출력을 위해서
|
||||
|
||||
* `-o name`, `-o json`, `-o yaml`, `-o go-template` 혹은 `-o jsonpath`와 같은 머신 지향(machine-oriented) 출력 양식 중 하나를 요청한다.
|
||||
* 예를 들어 `jobs.v1.batch/myjob`과 같이 전체 버전을 사용한다. 이를 통해 `kubectl`이 시간이 지남에 따라 변경될 수 있는 기본 버전을 사용하지 않도록 한다.
|
||||
* 문맥, 설정 또는 기타 암묵적 상태에 의존하지 않는다.
|
||||
|
||||
## 모범 사례
|
||||
|
||||
### `kubectl run`
|
||||
|
||||
`kubectl run`으로 infrastructure as code를 충족시키기 위해서
|
||||
|
||||
* 버전이 명시된 태그로 이미지를 태그하고 그 태그를 새로운 버전으로 이동하지 않는다. 예를 들어, `:latest`가 아닌 `:v1234`, `v1.2.3`, `r03062016-1-4`를 사용한다(자세한 정보는 [구성 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다).
|
||||
* 많은 파라미터가 적용된 이미지를 위한 스크립트를 작성한다.
|
||||
* 필요하지만 `kubectl run` 플래그를 통해 표현할 수 없는 기능은 구성 파일을 소스 코드 버전 관리 시스템에 넣어서 전환한다.
|
||||
|
||||
`--dry-run` 플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
모든 `kubectl`의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 [목록](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
#### 생성기
|
||||
`kubectl create --dry-run -o yaml`라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성 할 수 있다.
|
||||
```
|
||||
clusterrole 클러스터롤(ClusterRole)를 생성한다.
|
||||
clusterrolebinding 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
|
||||
configmap 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
|
||||
cronjob 지정된 이름으로 크론잡(CronJob)을 생성한다.
|
||||
deployment 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
|
||||
job 지정된 이름으로 잡(Job)을 생성한다.
|
||||
namespace 지정된 이름으로 네임스페이스(Namespace)를 생성한다.
|
||||
poddisruptionbudget 지정된 이름으로 pod disruption budget을 생성한다.
|
||||
priorityclass 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
|
||||
quota 지정된 이름으로 쿼터(Quota)를 생성한다.
|
||||
role 단일 규칙으로 롤(Role)을 생성한다.
|
||||
rolebinding 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
|
||||
secret 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
|
||||
service 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
|
||||
serviceaccount 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
|
||||
```
|
||||
|
||||
### `kubectl apply`
|
||||
|
||||
* `kubectl apply`를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 [Kubectl 책](https://kubectl.docs.kubernetes.io)을 참고한다.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,370 @@
|
|||
---
|
||||
title: kubectl
|
||||
content_type: tool-reference
|
||||
weight: 30
|
||||
---
|
||||
|
||||
## {{% heading "synopsis" %}}
|
||||
|
||||
|
||||
kubectl은 쿠버네티스 클러스터 관리자를 제어한다.
|
||||
|
||||
자세한 정보는 https://kubernetes.io/docs/reference/kubectl/overview/ 에서 확인한다.
|
||||
|
||||
```
|
||||
kubectl [flags]
|
||||
```
|
||||
|
||||
## {{% heading "options" %}}
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--add-dir-header</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">true인 경우, 로그 메시지의 헤더에 파일 디렉터리를 추가한다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--alsologtostderr</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">표준 에러와 파일에 로그를 기록한다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--as string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">작업을 수행할 사용자 이름</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--as-group stringArray</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">작업을 수행할 그룹. 이 플래그를 반복해서 여러 그룹을 지정할 수 있다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--azure-container-registry-config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Azure 컨테이너 레지스트리 구성 정보가 포함된 파일의 경로이다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--cache-dir string 기본값: "$HOME/.kube/cache"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">기본 캐시 디렉터리</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--certificate-authority string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">인증 기관의 인증서에 대한 파일 경로</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--client-certificate string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">TLS용 클라이언트 인증서의 파일 경로</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--client-key string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">TLS용 클라이언트 키의 파일 경로</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--cloud-provider-gce-l7lb-src-cidrs cidrs 기본값: 130.211.0.0/22,35.191.0.0/16</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">L7 LB 트래픽 프록시 및 상태 확인을 위해 GCE 방화벽에서 오픈된 CIDR</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs 기본값: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">L4 LB 트래픽 프록시 및 상태 확인을 위해 GCE 방화벽에서 오픈된 CIDR</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--cluster string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">사용할 kubeconfig 클러스터의 이름</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--context string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">사용할 kubeconfig 콘텍스트의 이름</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--default-not-ready-toleration-seconds int 기본값: 300</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">아직 톨러레이션(toleration)이 없는 모든 파드에 기본적으로 추가되는 notReady:NoExecute에 대한 톨러레이션의 tolerationSeconds를 나타낸다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--default-unreachable-toleration-seconds int 기본값: 300</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">아직 톨러레이션이 없어서 기본인 unreachable:NoExecute가 추가된 모든 파드에 대한 톨러레이션의 tolerationSeconds를 나타낸다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">-h, --help</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">kubectl에 대한 도움말</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--insecure-skip-tls-verify</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">true인 경우, 서버 인증서의 유효성을 확인하지 않는다. 이렇게 하면 사용자의 HTTPS 연결이 안전하지 않게 된다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--kubeconfig string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">CLI 요청에 사용할 kubeconfig 파일의 경로이다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--log-backtrace-at traceLocation 기본값: :0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">로깅이 file:N에 도달했을 때 스택 트레이스를 내보낸다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--log-dir string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">비어 있지 않으면, 이 디렉터리에 로그 파일을 작성한다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--log-file string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">비어 있지 않으면, 이 로그 파일을 사용한다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--log-file-max-size uint 기본값: 1800</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">로그 파일이 커질 수 있는 최대 크기를 정의한다. 단위는 메가 바이트이다. 값이 0이면, 파일의 최대 크기는 무제한이다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--log-flush-frequency duration 기본값: 5s</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">로그를 비우는 간격의 최대 시간(초)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--logtostderr 기본값: true</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">파일 대신 표준 에러에 기록</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--match-server-version</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">클라이언트 버전과 일치하는 서버 버전 필요</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">-n, --namespace string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">지정된 경우, 해당 네임스페이스가 CLI 요청의 범위가 됨</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--password string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">API 서버에 대한 기본 인증을 위한 비밀번호</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--profile string 기본값: "none"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">캡처할 프로파일의 이름. (none|cpu|heap|goroutine|threadcreate|block|mutex) 중 하나</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--profile-output string 기본값: "profile.pprof"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">프로파일을 쓸 파일의 이름</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--request-timeout string 기본값: "0"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">단일 서버 요청을 포기하기 전에 대기하는 시간이다. 0이 아닌 값에는 해당 시간 단위(예: 1s, 2m, 3h)가 포함되어야 한다. 값이 0이면 요청 시간이 초과되지 않는다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">-s, --server string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">쿠버네티스 API 서버의 주소와 포트</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--skip-headers</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">true이면, 로그 메시지에서 헤더 접두사를 사용하지 않는다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--skip-log-headers</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">true이면, 로그 파일을 열 때 헤더를 사용하지 않는다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--stderrthreshold severity 기본값: 2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">이 임계값 이상의 로그는 표준 에러로 이동한다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--tls-server-name string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면, 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--token string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">API 서버 인증을 위한 베어러(Bearer) 토큰</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--user string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">사용할 kubeconfig 사용자의 이름</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--username string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">API 서버에 대한 기본 인증을 위한 사용자 이름</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">-v, --v Level</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">로그 수준의 자세한 정도를 나타내는 숫자</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--version version[=true]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">버전 정보를 출력하고 종료</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--vmodule moduleSpec</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">파일 필터링 로깅을 위한 쉼표로 구분된 pattern=N 설정 목록</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--warnings-as-errors</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">서버에서 받은 경고를 오류로 처리하고 0이 아닌 종료 코드로 종료</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## {{% heading "seealso" %}}
|
||||
|
||||
* [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha) - 알파 기능에 대한 커맨드
|
||||
* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - 리소스에 대한 어노테이션 업데이트
|
||||
* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources) - 서버에서 지원되는 API 리소스 출력
|
||||
* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions) - "그룹/버전" 형식으로 서버에서 지원되는 API 버전을 출력
|
||||
* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) - 파일명 또는 표준 입력으로 리소스에 구성 적용
|
||||
* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach) - 실행 중인 컨테이너에 연결
|
||||
* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth) - 권한 검사
|
||||
* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) - 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 레플리케이션컨트롤러(ReplicationController) 자동 스케일링
|
||||
* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate) - 인증서 리소스 수정
|
||||
* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info) - 클러스터 정보 표시
|
||||
* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion) - 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드 출력
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - kubeconfig 파일 수정
|
||||
* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) - 다른 API 버전 간에 구성 파일 변환
|
||||
* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon) - 노드를 unschedulable로 표시
|
||||
* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp) - 컨테이너 간에 파일과 디렉터리 복사
|
||||
* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) - 파일 또는 표준 입력에서 리소스를 생성
|
||||
* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete) - 파일명, 표준 입력, 리소스 및 이름, 또는 리소스 및 레이블 셀렉터로 리소스 삭제
|
||||
* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe) - 특정 리소스 또는 리소스 그룹의 세부 정보를 표시
|
||||
* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - 적용 예정 버전과 라이브 버전 비교
|
||||
* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain) - 유지 보수 준비 중 노드 드레인
|
||||
* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit) - 서버에서 리소스 편집
|
||||
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - 컨테이너에서 커맨드 실행
|
||||
* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - 리소스의 문서
|
||||
* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - 레플리케이션 컨트롤러, 서비스, 디플로이먼트 또는 파드를 가져와서 새로운 쿠버네티스 서비스로 노출
|
||||
* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get) - 하나 이상의 리소스 표시
|
||||
* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize) - 디렉터리 또는 원격 URL에서 kustomization 대상을 빌드
|
||||
* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label) - 리소스의 레이블 업데이트
|
||||
* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs) - 파드의 컨테이너에 대한 로그 출력
|
||||
* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options) - 모든 커맨드에서 상속된 플래그 목록을 출력
|
||||
* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch) - 전략적 병합 패치를 사용하여 리소스 필드를 업데이트
|
||||
* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin) - 플러그인과 상호 작용하기 위한 유틸리티를 제공
|
||||
* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward) - 하나 이상의 로컬 포트를 파드로 전달
|
||||
* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy) - 쿠버네티스 API 서버에 대한 프록시 실행
|
||||
* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace) - 파일명 또는 표준 입력으로 리소스 교체
|
||||
* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout) - 리소스 롤아웃 관리
|
||||
* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run) - 클러스터에서 특정 이미지 실행
|
||||
* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - 디플로이먼트, 레플리카셋 또는 레플리케이션 컨트롤러의 새 크기 설정
|
||||
* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - 오브젝트에 특정 기능 설정
|
||||
* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) - 하나 이상의 노드에서 테인트(taint) 업데이트
|
||||
* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top) - 리소스(CPU/메모리/스토리지) 사용량을 표시
|
||||
* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - 노드를 schedulable로 표시
|
||||
* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - 클라이언트 및 서버 버전 정보 출력
|
||||
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - 실험적(experimental) 기능: 하나 이상의 리소스에 대해서 특정 조건이 만족될 때까지 대기(wait)
|
||||
|
|
@ -60,6 +60,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
|
|||
| PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
|
||||
| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
|
||||
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
|
||||
| PHP | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
|
||||
| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
|
||||
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
|
||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||
|
|
|
|||
|
|
@ -1,398 +1,140 @@
|
|||
---
|
||||
title: 여러 영역에서 구동
|
||||
weight: 10
|
||||
title: 여러 영역에서 실행
|
||||
weight: 20
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다.
|
||||
|
||||
|
||||
이 페이지에서는 여러 영역에서 쿠버네티스를 실행하는 방법을 설명한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 소개
|
||||
## 배경
|
||||
|
||||
Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
|
||||
(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
|
||||
This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
|
||||
nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
|
||||
Full Cluster Federation allows combining separate
|
||||
Kubernetes clusters running in different regions or cloud providers
|
||||
(or on-premises data centers). However, many
|
||||
users simply want to run a more available Kubernetes cluster in multiple zones
|
||||
of their single cloud provider, and this is what the multizone support in 1.2 allows
|
||||
(this previously went by the nickname "Ubernetes Lite").
|
||||
쿠버네티스는 단일 쿠버네티스 클러스터가 여러 장애 영역에서
|
||||
실행될 수 있도록 설계되었다. 일반적으로 이러한 영역은 _지역(region)_ 이라는
|
||||
논리적 그룹 내에 적합하다. 주요 클라우드 제공자는 지역을 일관된 기능 집합을
|
||||
제공하는 장애 영역 집합(_가용성 영역_ 이라고도 함)으로
|
||||
정의한다. 지역 내에서 각 영역은 동일한 API 및
|
||||
서비스를 제공한다.
|
||||
|
||||
Multizone support is deliberately limited: a single Kubernetes cluster can run
|
||||
in multiple zones, but only within the same region (and cloud provider). Only
|
||||
GCE and AWS are currently supported automatically (though it is easy to
|
||||
add similar support for other clouds or even bare metal, by simply arranging
|
||||
for the appropriate labels to be added to nodes and volumes).
|
||||
일반적인 클라우드 아키텍처는 한 영역의 장애가 다른 영역의 서비스도
|
||||
손상시킬 가능성을 최소화하는 것을 목표로 한다.
|
||||
|
||||
## 컨트롤 플레인 동작
|
||||
|
||||
## 기능
|
||||
모든 [컨트롤 플레인 컴포넌트](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)는
|
||||
컴포넌트별로 복제되는 교환 가능한 리소스 풀로 실행을
|
||||
지원한다.
|
||||
|
||||
When nodes are started, the kubelet automatically adds labels to them with
|
||||
zone information.
|
||||
|
||||
Kubernetes will automatically spread the pods in a replication controller
|
||||
or service across nodes in a single-zone cluster (to reduce the impact of
|
||||
failures.) With multiple-zone clusters, this spreading behavior is
|
||||
extended across zones (to reduce the impact of zone failures.) (This is
|
||||
achieved via `SelectorSpreadPriority`). This is a best-effort
|
||||
placement, and so if the zones in your cluster are heterogeneous
|
||||
(e.g. different numbers of nodes, different types of nodes, or
|
||||
different pod resource requirements), this might prevent perfectly
|
||||
even spreading of your pods across zones. If desired, you can use
|
||||
homogeneous zones (same number and types of nodes) to reduce the
|
||||
probability of unequal spreading.
|
||||
|
||||
When persistent volumes are created, the `PersistentVolumeLabel`
|
||||
admission controller automatically adds zone labels to them. The scheduler (via the
|
||||
`VolumeZonePredicate` predicate) will then ensure that pods that claim a
|
||||
given volume are only placed into the same zone as that volume, as volumes
|
||||
cannot be attached across zones.
|
||||
|
||||
## 제한 사항
|
||||
|
||||
There are some important limitations of the multizone support:
|
||||
|
||||
* We assume that the different zones are located close to each other in the
|
||||
network, so we don't perform any zone-aware routing. In particular, traffic
|
||||
that goes via services might cross zones (even if some pods backing that service
|
||||
exist in the same zone as the client), and this may incur additional latency and cost.
|
||||
|
||||
* Volume zone-affinity will only work with a `PersistentVolume`, and will not
|
||||
work if you directly specify an EBS volume in the pod spec (for example).
|
||||
|
||||
* Clusters cannot span clouds or regions (this functionality will require full
|
||||
federation support).
|
||||
|
||||
* Although your nodes are in multiple zones, kube-up currently builds
|
||||
a single master node by default. While services are highly
|
||||
available and can tolerate the loss of a zone, the control plane is
|
||||
located in a single zone. Users that want a highly available control
|
||||
plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
|
||||
|
||||
### Volume limitations
|
||||
The following limitations are addressed with [topology-aware volume binding](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드).
|
||||
|
||||
* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
|
||||
pod affinity or anti-affinity policies.
|
||||
|
||||
* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
|
||||
may not provide a uniform distribution of storage across zones.
|
||||
|
||||
* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
|
||||
needs to be configured for a specific single zone, or the PVs need to be
|
||||
statically provisioned in a specific zone. Another workaround is to use a
|
||||
StatefulSet, which will ensure that all the volumes for a replica are
|
||||
provisioned in the same zone.
|
||||
|
||||
## 연습
|
||||
|
||||
We're now going to walk through setting up and using a multi-zone
|
||||
cluster on both GCE & AWS. To do so, you bring up a full cluster
|
||||
(specifying `MULTIZONE=true`), and then you add nodes in additional zones
|
||||
by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
|
||||
|
||||
### 클러스터 가져오기
|
||||
|
||||
Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
This step brings up a cluster as normal, still running in a single zone
|
||||
(but `MULTIZONE=true` has enabled multi-zone capabilities).
|
||||
|
||||
### 라벨이 지정된 노드 확인
|
||||
|
||||
View the nodes; you can see that they are labeled with zone information.
|
||||
They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far. The
|
||||
labels are `failure-domain.beta.kubernetes.io/region` for the region,
|
||||
and `failure-domain.beta.kubernetes.io/zone` for the zone:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-87j9 Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
```
|
||||
|
||||
### 두번째 영역에 더 많은 노드 추가하기
|
||||
|
||||
Let's add another set of nodes to the existing cluster, reusing the
|
||||
existing master, running in a different zone (us-central1-b or us-west-2b).
|
||||
We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
|
||||
kube-up will not create a new master, but will reuse one that was previously
|
||||
created instead.
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
On AWS we also need to specify the network CIDR for the additional
|
||||
subnet, along with the master internal IP address:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
|
||||
View the nodes again; 3 more nodes should have launched and be tagged
|
||||
in us-central1-b:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-281d Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-87j9 Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready <none> 17m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
kubernetes-minion-pp2f Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
|
||||
kubernetes-minion-wf8i Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
|
||||
```
|
||||
|
||||
### 볼륨 어피니티
|
||||
|
||||
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
|
||||
|
||||
```bash
|
||||
kubectl apply -f - <<EOF
|
||||
{
|
||||
"apiVersion": "v1",
|
||||
"kind": "PersistentVolumeClaim",
|
||||
"metadata": {
|
||||
"name": "claim1",
|
||||
"annotations": {
|
||||
"volume.alpha.kubernetes.io/storage-class": "foo"
|
||||
}
|
||||
},
|
||||
"spec": {
|
||||
"accessModes": [
|
||||
"ReadWriteOnce"
|
||||
],
|
||||
"resources": {
|
||||
"requests": {
|
||||
"storage": "5Gi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
EOF
|
||||
```
|
||||
클러스터 컨트롤 플레인을 배포할 때, 여러 장애 영역에
|
||||
컨트롤 플레인 컴포넌트의 복제본을 배치한다. 가용성이
|
||||
중요한 문제인 경우, 3개 이상의 장애 영역을 선택하고
|
||||
각 개별 컨트롤 플레인 컴포넌트(API 서버, 스케줄러, etcd,
|
||||
클러스터 컨트롤러 관리자)를 3개 이상의 장애 영역에 복제한다.
|
||||
클라우드 컨트롤러 관리자를 실행 중인 경우 선택한
|
||||
모든 장애 영역에 걸쳐 이를 복제해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
For version 1.3+ Kubernetes will distribute dynamic PV claims across
|
||||
the configured zones. For version 1.2, dynamic persistent volumes were
|
||||
always created in the zone of the cluster master
|
||||
(here us-central1-a / us-west-2a); that issue
|
||||
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
|
||||
was addressed in 1.3+.
|
||||
쿠버네티스는 API 서버 엔드포인트에 대한 교차 영역 복원성을 제공하지
|
||||
않는다. DNS 라운드-로빈, SRV 레코드 또는 상태 확인 기능이 있는
|
||||
써드파티 로드 밸런싱 솔루션을 포함하여 다양한 기술을 사용하여
|
||||
클러스터 API 서버의 가용성을 향상시킬 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
|
||||
## 노드 동작
|
||||
|
||||
```shell
|
||||
kubectl get pv --show-labels
|
||||
```
|
||||
쿠버네티스는 클러스터의 여러 노드에 걸쳐
|
||||
워크로드 리소스(예: {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
|
||||
또는 {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}})에
|
||||
대한 파드를 자동으로 분배한다. 이러한 분배는
|
||||
실패에 대한 영향을 줄이는 데 도움이 된다.
|
||||
|
||||
The output is similar to this:
|
||||
노드가 시작되면, 각 노드의 kubelet이 쿠버네티스 API에서
|
||||
특정 kubelet을 나타내는 노드 오브젝트에
|
||||
{{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다.
|
||||
이러한 레이블에는
|
||||
[영역 정보](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
|
||||
|
||||
```shell
|
||||
NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS
|
||||
pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
|
||||
```
|
||||
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과
|
||||
함께 노드 레이블을 사용하여
|
||||
파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에
|
||||
분산되는 방식을 제어할 수 있다.
|
||||
이러한 힌트를 통해
|
||||
{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}는
|
||||
더 나은 예상 가용성을 위해 파드를 배치할 수 있으므로, 상관 관계가 있는
|
||||
오류가 전체 워크로드에 영향을 미칠 위험을 줄일 수 있다.
|
||||
|
||||
So now we will create a pod that uses the persistent volume claim.
|
||||
Because GCE PDs / AWS EBS volumes cannot be attached across zones,
|
||||
this means that this pod can only be created in the same zone as the volume:
|
||||
예를 들어, 가능할 때마다 스테이트풀셋의
|
||||
3개 복제본이 모두 서로 다른 영역에서 실행되도록 제약 조건을
|
||||
설정할 수 있다. 각 워크로드에 사용 중인
|
||||
가용 영역을 명시적으로 정의하지 않고 이를 선언적으로
|
||||
정의할 수 있다.
|
||||
|
||||
```yaml
|
||||
kubectl apply -f - <<EOF
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: myfrontend
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: "/var/www/html"
|
||||
name: mypd
|
||||
volumes:
|
||||
- name: mypd
|
||||
persistentVolumeClaim:
|
||||
claimName: claim1
|
||||
EOF
|
||||
```
|
||||
### 여러 영역에 노드 분배
|
||||
|
||||
Note that the pod was automatically created in the same zone as the volume, as
|
||||
cross-zone attachments are not generally permitted by cloud providers:
|
||||
쿠버네티스의 코어는 사용자를 위해 노드를 생성하지 않는다. 사용자가 직접 수행하거나,
|
||||
[클러스터 API](https://cluster-api.sigs.k8s.io/)와 같은 도구를 사용하여
|
||||
사용자 대신 노드를 관리해야 한다.
|
||||
|
||||
```shell
|
||||
kubectl describe pod mypod | grep Node
|
||||
```
|
||||
클러스터 API와 같은 도구를 사용하면 여러 장애 도메인에서
|
||||
클러스터의 워커 노드로 실행할 머신 집합과 전체 영역 서비스 중단 시
|
||||
클러스터를 자동으로 복구하는 규칙을 정의할 수 있다.
|
||||
|
||||
```shell
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
```
|
||||
## 파드에 대한 수동 영역 할당
|
||||
|
||||
And check node labels:
|
||||
생성한 파드와 디플로이먼트, 스테이트풀셋, 잡(Job)과
|
||||
같은 워크로드 리소스의 파드 템플릿에 [노드 셀렉터 제약 조건](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)을
|
||||
적용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get node kubernetes-minion-9vlv --show-labels
|
||||
```
|
||||
## 영역에 대한 스토리지 접근
|
||||
|
||||
```shell
|
||||
NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
```
|
||||
퍼시스턴트 볼륨이 생성되면, `PersistentVolumeLabel`
|
||||
[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는
|
||||
특정 영역에 연결된 모든 퍼시스턴트볼륨(PersistentVolume)에 영역 레이블을 자동으로
|
||||
추가한다. 그런 다음 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}는
|
||||
`NoVolumeZoneConflict` 프레디케이트(predicate)를 통해 주어진 퍼시스턴트볼륨을 요구하는 파드가
|
||||
해당 볼륨과 동일한 영역에만 배치되도록 한다.
|
||||
|
||||
### 여러 영역에 파드 분배하기
|
||||
해당 클래스의 스토리지가 사용할 수 있는 장애 도메인(영역)을 지정하는
|
||||
퍼시스턴트볼륨클레임(PersistentVolumeClaims)에 대한
|
||||
{{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 지정할 수 있다.
|
||||
장애 도메인 또는 영역을 인식하는 스토리지클래스 구성에 대한 자세한 내용은
|
||||
[허용된 토폴로지](/ko/docs/concepts/storage/storage-classes/#허용된-토폴로지)를 참고한다.
|
||||
|
||||
Pods in a replication controller or service are automatically spread
|
||||
across zones. First, let's launch more nodes in a third zone:
|
||||
## 네트워킹
|
||||
|
||||
GCE:
|
||||
쿠버네티스가 스스로 영역-인지(zone-aware) 네트워킹을 포함하지는 않는다.
|
||||
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을
|
||||
사용하여 클러스터 네트워킹을 구성할 수 있으며, 해당 네트워크 솔루션에는 영역별 요소가
|
||||
있을 수 있다. 예를 들어, 클라우드 제공자가
|
||||
`type=LoadBalancer` 를 사용하여 서비스를 지원하는 경우, 로드 밸런서는 지정된 연결을 처리하는
|
||||
로드 밸런서 요소와 동일한 영역에서 실행 중인 파드로만 트래픽을 보낼 수 있다.
|
||||
자세한 내용은 클라우드 제공자의 문서를 확인한다.
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
사용자 정의 또는 온-프레미스 배포의 경우, 비슷한 고려 사항이 적용된다.
|
||||
다른 장애 영역 처리를 포함한 {{< glossary_tooltip text="서비스" term_id="service" >}}와
|
||||
{{< glossary_tooltip text="인그레스(Ingress)" term_id="ingress" >}} 동작은
|
||||
클러스터가 설정된 방식에 명확히 의존한다.
|
||||
|
||||
AWS:
|
||||
## 장애 복구
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
클러스터를 설정할 때, 한 지역의 모든 장애 영역이 동시에
|
||||
오프라인 상태가 되는 경우 설정에서 서비스를 복원할 수 있는지
|
||||
여부와 방법을 고려해야 할 수도 있다. 예를 들어, 영역에서 파드를 실행할 수 있는
|
||||
노드가 적어도 하나 이상 있어야 하는가?
|
||||
클러스터에 중요한 복구 작업이 클러스터에
|
||||
적어도 하나 이상의 정상 노드에 의존하지 않는지 확인한다. 예를 들어, 모든 노드가
|
||||
비정상인 경우, 하나 이상의 노드를 서비스할 수 있을 만큼 복구를 완료할 수 있도록 특별한
|
||||
{{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}으로
|
||||
복구 작업을 실행해야 할 수 있다.
|
||||
|
||||
Verify that you now have nodes in 3 zones:
|
||||
쿠버네티스는 이 문제에 대한 답을 제공하지 않는다. 그러나,
|
||||
고려해야 할 사항이다.
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
|
||||
|
||||
```shell
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
|
||||
```
|
||||
|
||||
The pods should be spread across all 3 zones:
|
||||
|
||||
```shell
|
||||
kubectl describe pod -l app=guestbook | grep Node
|
||||
```
|
||||
|
||||
```shell
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
Node: kubernetes-minion-281d/10.240.0.8
|
||||
Node: kubernetes-minion-olsh/10.240.0.11
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
|
||||
```
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready <none> 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-281d Ready <none> 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-olsh Ready <none> 3m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
|
||||
```
|
||||
|
||||
|
||||
Load-balancers span all zones in a cluster; the guestbook-go example
|
||||
includes an example load-balanced service:
|
||||
|
||||
```shell
|
||||
kubectl describe service guestbook | grep LoadBalancer.Ingress
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
LoadBalancer Ingress: 130.211.126.21
|
||||
```
|
||||
|
||||
Set the above IP:
|
||||
|
||||
```shell
|
||||
export IP=130.211.126.21
|
||||
```
|
||||
|
||||
Explore with curl via IP:
|
||||
|
||||
```shell
|
||||
curl -s http://${IP}:3000/env | grep HOSTNAME
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
```
|
||||
|
||||
Again, explore multiple times:
|
||||
|
||||
```shell
|
||||
(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
"HOSTNAME": "guestbook-hum5n",
|
||||
"HOSTNAME": "guestbook-ppm40",
|
||||
```
|
||||
|
||||
The load balancer correctly targets all the pods, even though they are in multiple zones.
|
||||
|
||||
### 클러스터 강제 종료
|
||||
|
||||
When you're done, clean up:
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
스케줄러가 구성된 제약 조건을 준수하면서, 클러스터에 파드를 배치하는 방법을 알아보려면,
|
||||
[스케줄링과 축출(eviction)](/ko/docs/concepts/scheduling-eviction/)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -29,9 +29,6 @@ weight: 10
|
|||
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
|
||||
{{< /note >}}
|
||||
|
||||
이 가이드의 모든 명령은 `root`로 실행해야 한다.
|
||||
예를 들어,`sudo`로 접두사를 붙이거나, `root` 사용자가 되어 명령을 실행한다.
|
||||
|
||||
### Cgroup 드라이버
|
||||
|
||||
리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는
|
||||
|
|
@ -74,18 +71,18 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
|
|||
# (도커 CE 설치)
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
|
||||
apt-get update && apt-get install -y \
|
||||
sudo apt-get update && sudo apt-get install -y \
|
||||
apt-transport-https ca-certificates curl software-properties-common gnupg2
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
|
|
@ -93,7 +90,7 @@ add-apt-repository \
|
|||
|
||||
```shell
|
||||
# 도커 CE 설치.
|
||||
apt-get update && apt-get install -y \
|
||||
sudo apt-get update && sudo apt-get install -y \
|
||||
containerd.io=1.2.13-2 \
|
||||
docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
|
||||
docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
|
||||
|
|
@ -101,7 +98,7 @@ apt-get update && apt-get install -y \
|
|||
|
||||
```shell
|
||||
# 도커 데몬 설정
|
||||
cat > /etc/docker/daemon.json <<EOF
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
|
|
@ -114,13 +111,13 @@ EOF
|
|||
```
|
||||
|
||||
```shell
|
||||
mkdir -p /etc/systemd/system/docker.service.d
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 재시작.
|
||||
systemctl daemon-reload
|
||||
systemctl restart docker
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS/RHEL 7.4+" %}}
|
||||
|
|
@ -129,18 +126,18 @@ systemctl restart docker
|
|||
# (도커 CE 설치)
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 리포지터리 추가
|
||||
yum-config-manager --add-repo \
|
||||
sudo yum-config-manager --add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 CE 설치.
|
||||
yum update -y && yum install -y \
|
||||
sudo yum update -y && sudo yum install -y \
|
||||
containerd.io-1.2.13 \
|
||||
docker-ce-19.03.11 \
|
||||
docker-ce-cli-19.03.11
|
||||
|
|
@ -148,12 +145,12 @@ yum update -y && yum install -y \
|
|||
|
||||
```shell
|
||||
## /etc/docker 생성.
|
||||
mkdir /etc/docker
|
||||
sudo mkdir /etc/docker
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 데몬 설정.
|
||||
cat > /etc/docker/daemon.json <<EOF
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
|
|
@ -169,13 +166,13 @@ EOF
|
|||
```
|
||||
|
||||
```shell
|
||||
mkdir -p /etc/systemd/system/docker.service.d
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d
|
||||
```
|
||||
|
||||
```shell
|
||||
# 도커 재시작.
|
||||
systemctl daemon-reload
|
||||
systemctl restart docker
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
|
@ -203,17 +200,17 @@ CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너
|
|||
### 선행 조건
|
||||
|
||||
```shell
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다.
|
||||
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sysctl --system
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
{{< tabs name="tab-cri-cri-o-installation" >}}
|
||||
|
|
@ -235,16 +232,19 @@ sysctl --system
|
|||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
"deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /"
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
"deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /"
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -
|
||||
|
||||
apt-get update
|
||||
apt-get install cri-o cri-o-runc
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Ubuntu" %}}
|
||||
|
|
@ -297,9 +297,9 @@ apt-get install cri-o cri-o-runc
|
|||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
yum install cri-o
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
sudo yum install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
|
@ -317,14 +317,14 @@ sudo zypper install cri-o
|
|||
|
||||
사용할 수 있는 버전을 찾으려면 다음을 실행한다.
|
||||
```shell
|
||||
dnf module list cri-o
|
||||
sudo dnf module list cri-o
|
||||
```
|
||||
CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다.
|
||||
|
||||
그런 다음, 아래를 실행한다.
|
||||
```shell
|
||||
dnf module enable cri-o:$VERSION
|
||||
dnf install cri-o
|
||||
sudo dnf module enable cri-o:$VERSION
|
||||
sudo dnf install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
|
@ -333,8 +333,8 @@ dnf install cri-o
|
|||
### CRI-O 시작
|
||||
|
||||
```shell
|
||||
systemctl daemon-reload
|
||||
systemctl start crio
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl start crio
|
||||
```
|
||||
|
||||
자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를
|
||||
|
|
@ -349,22 +349,22 @@ Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사
|
|||
### 선행 조건
|
||||
|
||||
```shell
|
||||
cat > /etc/modules-load.d/containerd.conf <<EOF
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅에서도 유지된다.
|
||||
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sysctl --system
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
### containerd 설치
|
||||
|
|
@ -376,17 +376,17 @@ sysctl --system
|
|||
# (containerd 설치)
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치
|
||||
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
|
|
@ -394,18 +394,18 @@ add-apt-repository \
|
|||
|
||||
```shell
|
||||
## containerd 설치
|
||||
apt-get update && apt-get install -y containerd.io
|
||||
sudo apt-get update && sudo apt-get install -y containerd.io
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
sudo mkdir -p /etc/containerd
|
||||
sudo containerd config default > /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS/RHEL 7.4+" %}}
|
||||
|
|
@ -414,30 +414,30 @@ systemctl restart containerd
|
|||
# (containerd 설치)
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
|
||||
```
|
||||
|
||||
```shell
|
||||
## 도커 리포지터리 추가
|
||||
yum-config-manager \
|
||||
sudo yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
```
|
||||
|
||||
```shell
|
||||
## containerd 설치
|
||||
yum update -y && yum install -y containerd.io
|
||||
sudo yum update -y && yum install -y containerd.io
|
||||
```
|
||||
|
||||
```shell
|
||||
## containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
sudo mkdir -p /etc/containerd
|
||||
sudo containerd config default > /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="윈도우 (PowerShell)" %}}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Installing Kubernetes with deployment tools
|
||||
title: 배포 도구로 쿠버네티스 설치하기
|
||||
weight: 30
|
||||
---
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의
|
|||
|
||||
만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은
|
||||
쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를
|
||||
통해 만들어진다. 사용자는 여러개의 인스턴스 그룹을 관리할 수 있는데,
|
||||
통해 만들어진다. 사용자는 여러 개의 인스턴스 그룹을 관리할 수 있는데,
|
||||
예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
reviewers:
|
||||
title: 컨트롤 플레인을 자체 호스팅하기 위해 쿠버네티스 클러스터 구성하기
|
||||
content_type: concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
### 쿠버네티스 컨트롤 플레인 자체 호스팅하기 {#self-hosting}
|
||||
|
||||
kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
|
||||
해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
|
||||
통해 kubelet에 구성된 [스태틱(static) 파드](/docs/tasks/configure-pod-container/static-pod/)
|
||||
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/docs/concepts/workloads/controllers/daemonset/)
|
||||
로 실행된다.
|
||||
|
||||
자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
|
||||
명령어를 확인한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
#### 주의사항
|
||||
|
||||
{{< caution >}}
|
||||
이 기능은 클러스터를 지원되지 않는 상태로 전환하여 더 이상 클러스터를 관리할 수 없게 만든다.
|
||||
이것은 `kubeadm upgrade`를 포함한다.
|
||||
{{< /caution >}}
|
||||
|
||||
1. 1.8 이후 버전에서 자체 호스팅은 몇 가지 중요한 한계가 있다.
|
||||
특히 자체 호스팅된 클러스터는 수동 조정 없이는
|
||||
_컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._
|
||||
|
||||
1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는
|
||||
[`hostPath`](/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
|
||||
자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해
|
||||
관리되지 않는다.
|
||||
|
||||
1. 컨트롤 플레인의 자체 호스팅된 부분에는 스태틱 파드로 실행되는 etcd가
|
||||
포함되지 않는다.
|
||||
|
||||
#### 프로세스
|
||||
|
||||
자체 호스팅 부트스트랩 프로세스는 [kubeadm 설계
|
||||
문서](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)에 기록되어 있다.
|
||||
|
||||
요약하면 `kubeadm alpha selfhosting`은 다음과 같이 작동한다.
|
||||
|
||||
1. 부트스트랩 스태틱 컨트롤 플레인이 실행되고 정상 상태가 될 때까지 기다린다.
|
||||
이것은 자체 호스팅이 없는 `kubeadm init` 프로세스와 동일하다.
|
||||
|
||||
1. 스태틱 컨트롤 플레인 파드 매니페스트를 사용하여 자체 호스팅된 컨트롤
|
||||
플레인을 실행할 데몬셋 매니페스트 집합을 구성한다. 또한 필요한 경우
|
||||
해당 매니페스트를 수정한다. 예를 들어, 시크릿을 위한 새로운 볼륨을
|
||||
추가한다.
|
||||
|
||||
1. `kube-system` 네임스페이스에 데몬셋을 생성하고 결과 파드가 실행될 때까지
|
||||
대기한다.
|
||||
|
||||
1. 일단 자체 호스팅된 파드가 동작하면 관련 스태틱 파드가 삭제되고
|
||||
kubeadm은 계속해서 다음 구성 요소를 설치한다.
|
||||
이것은 kubelet이 스태틱 파드를 멈추게 한다.
|
||||
|
||||
1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
|
||||
리스닝 포트에 바인딩하여 활성화할 수 있다.
|
||||
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
|||
|
||||
오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
|
||||
|
||||
플래그의 동작은 아래에 설명된대로 다르게 동작한다.
|
||||
플래그의 동작은 아래에 설명된 대로 다르게 동작한다.
|
||||
|
||||
* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트
|
||||
* `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다.
|
||||
|
|
@ -570,7 +570,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
|
|||
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
|
||||
```
|
||||
|
||||
호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.
|
||||
호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.
|
||||
|
||||
1. 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.
|
||||
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,114 +0,0 @@
|
|||
---
|
||||
---
|
||||
<script language="JavaScript">
|
||||
var dropDownsPopulated = false;
|
||||
$( document ).ready(function() {
|
||||
// When the document loads, get the metadata JSON, and kick off tbl render
|
||||
$.get("/metadata.txt", function(data, status) {
|
||||
metadata = $.parseJSON(data);
|
||||
metadata.pages.sort(dynamicSort("t"));
|
||||
mainLogic()
|
||||
$(window).bind( 'hashchange', function(e) {
|
||||
mainLogic();
|
||||
});
|
||||
});
|
||||
});
|
||||
function mainLogic()
|
||||
{
|
||||
// If there's a tag filter, change the table/drop down output
|
||||
if (!dropDownsPopulated) populateDropdowns();
|
||||
var tag=window.location.hash.replace("#","");
|
||||
if(tag) {
|
||||
tag = $.trim(tag);
|
||||
for (i=0;i<tagName.length;i++) {
|
||||
querystringTag = tagName[i] + "=";
|
||||
if (tag.indexOf(querystringTag) > -1)
|
||||
{
|
||||
console.log("in mainLog: querystringTag of " + querystringTag + " matches tag of " + tag);
|
||||
tag = tag.replace(querystringTag,"");
|
||||
selectDropDown(tagName[i],tag);
|
||||
topicsFilter(tagName[i],tag,"output");
|
||||
}
|
||||
}
|
||||
} else {
|
||||
currentTopics = metadata.pages;
|
||||
}
|
||||
renderTable(currentTopics,"output");
|
||||
|
||||
}
|
||||
function populateDropdowns()
|
||||
{
|
||||
// Keeping mainLogic() brief by functionalizing the initialization of the
|
||||
// drop-down filter boxes
|
||||
|
||||
for(i=0;i<metadata.pages.length;i++)
|
||||
{
|
||||
var metadataArrays = [metadata.pages[i].cr,metadata.pages[i].or,metadata.pages[i].mr];
|
||||
for(j=0;j<metadataArrays.length;j++)
|
||||
{
|
||||
if (metadataArrays[j]) {
|
||||
for (k=0;k<metadataArrays[j].length;k++) {
|
||||
if (typeof storedTagsArrays[j] == 'undefined') storedTagsArrays[j] = new Array();
|
||||
storedTagsArrays[j][metadataArrays[j][k][tagName[j]]] = true;
|
||||
// ^ conceptList[metadata.pages[i].cr[k].concept] = true; (if rolling through concepts)
|
||||
// ^ conceptList['container'] = true; (ultimate result)
|
||||
// ^ objectList[metadata.pages[i].or[k].object] = true; (if rolling through objects)
|
||||
// ^ objectList['restartPolicy'] = true; (ultimate result)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
var output = new Array();
|
||||
for(i=0;i<tagName.length;i++)
|
||||
{
|
||||
// Phew! All tags in conceptList, objectList, and commandList!
|
||||
// Loop through them and populate those drop-downs through html() injection
|
||||
output = [];
|
||||
output.push("<select id='" + tagName[i] + "' onchange='dropFilter(this)'>");
|
||||
output.push("<option>---</option>");
|
||||
Object.keys(storedTagsArrays[i]).sort().forEach(function (key) {
|
||||
output.push("<option>" + key + "</option>");
|
||||
});
|
||||
output.push("</select>")
|
||||
$(dropDowns[i]).html(output.join(""));
|
||||
}
|
||||
dropDownsPopulated = true;
|
||||
}
|
||||
function dropFilter(srcobj)
|
||||
{
|
||||
// process the change of a drop-down value
|
||||
// the ID of the drop down is either command, object, or concept
|
||||
// these exact values are what topicsFilter() expects, plus a filter val
|
||||
// which we get from .text() of :selected
|
||||
console.log("dropFilter:" + $(srcobj).attr('id') + ":" + $(srcobj).find(":selected").text());
|
||||
topicsFilter($(srcobj).attr('id').replace("#",""),$(srcobj).find(":selected").text(),"output");
|
||||
for(i=0;i<tagName.length;i++)
|
||||
{
|
||||
if($(srcobj).attr('id')!=tagName[i]) selectDropDown(tagName[i],"---");
|
||||
}
|
||||
}
|
||||
function selectDropDown(type,tag)
|
||||
{
|
||||
// change drop-down selection w/o filtering
|
||||
$("#" + type).val(tag);
|
||||
}
|
||||
</script>
|
||||
<style>
|
||||
#filters select{
|
||||
font-size: 14px;
|
||||
border: 1px #000 solid;
|
||||
}
|
||||
#filters {
|
||||
padding-top: 20px;
|
||||
}
|
||||
</style>
|
||||
|
||||
필터하려면 태그를 클릭하거나 드롭 다운을 사용하세요. 정순 또는 역순으로 정렬하려면 테이블 헤더를 클릭하세요.
|
||||
|
||||
<p id="filters">
|
||||
개념으로 필터: <span id="conceptFilter" /><br/>
|
||||
오브젝트로 필터: <span id="objectFilter" /><br/>
|
||||
커맨드로 필터: <span id="commandFilter" />
|
||||
</p>
|
||||
|
||||
<div id="output" />
|
||||
|
|
@ -0,0 +1,212 @@
|
|||
---
|
||||
title: 서비스를 사용하여 프론트엔드를 백엔드에 연결
|
||||
content_type: tutorial
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 작업은 프론트엔드와 마이크로서비스 백엔드를 어떻게 생성하는지를
|
||||
설명한다. 백엔드 마이크로서비스는 인사하기(hello greeter)이다.
|
||||
프론트엔드와 백엔드는 쿠버네티스 {{< glossary_tooltip term_id="service" text="서비스" >}}
|
||||
오브젝트를 이용해 연결되어 있다.
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* {{< glossary_tooltip term_id="deployment" text="디플로이먼트(Deployment)" >}} 오브젝트를 사용해 마이크로서비스를 생성하고 실행한다.
|
||||
* 프론트엔드를 사용하여 백엔드로 트래픽을 전달한다.
|
||||
* 프론트엔드 애플리케이션을 백엔드 애플리케이션에 연결하기 위해
|
||||
서비스 오브젝트를 사용한다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
이 작업은
|
||||
지원되는 환경이 필요한
|
||||
[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#nodeport) 서비스 타입을
|
||||
대신 사용할 수 있다.
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## 디플로이먼트를 사용해 백엔드 생성하기
|
||||
|
||||
백엔드는 인사하기라는 간단한 마이크로서비스이다. 여기에 백엔드 디플로이먼트
|
||||
구성 파일이 있다.
|
||||
|
||||
{{< codenew file="service/access/hello.yaml" >}}
|
||||
|
||||
백엔드 디플로이먼트를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/hello.yaml
|
||||
```
|
||||
|
||||
백엔드 디플로이먼트에 관한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl describe deployment hello
|
||||
```
|
||||
|
||||
결과는 아래와 같다.
|
||||
|
||||
```
|
||||
Name: hello
|
||||
Namespace: default
|
||||
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
|
||||
Labels: app=hello
|
||||
tier=backend
|
||||
track=stable
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=hello,tier=backend,track=stable
|
||||
Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
Pod Template:
|
||||
Labels: app=hello
|
||||
tier=backend
|
||||
track=stable
|
||||
Containers:
|
||||
hello:
|
||||
Image: "gcr.io/google-samples/hello-go-gke:1.0"
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: hello-3621623197 (7/7 replicas created)
|
||||
Events:
|
||||
...
|
||||
```
|
||||
|
||||
## 백엔드 서비스 오브젝트 생성하기
|
||||
|
||||
프론트엔드와 백엔드를 연결하는 방법은 백엔드
|
||||
서비스이다. 서비스는 백엔드 마이크로서비스에 언제든 도달하기 위해
|
||||
변하지 않는 IP 주소와 DNS 이름 항목을 생성한다. 서비스는
|
||||
트래픽을 보내는 파드를 찾기 위해
|
||||
{{< glossary_tooltip text="selectors" term_id="selector" text="셀렉터" >}}를 사용한다.
|
||||
|
||||
먼저, 서비스 구성 파일을 살펴보자.
|
||||
|
||||
{{< codenew file="service/access/hello-service.yaml" >}}
|
||||
|
||||
구성 파일에서 서비스가 `app: hello` 과 `tier: backend` 레이블을 갖는
|
||||
파드에 트래픽을 보내는 것을 볼 수 있다.
|
||||
|
||||
`hello` 서비스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
|
||||
```
|
||||
|
||||
이 시점에서, 백엔드 디플로이먼트는 Running 중이며, 해당 백엔드로
|
||||
트래픽을 보내는 서비스를 갖고 있다.
|
||||
|
||||
## 프론트엔드 생성하기
|
||||
|
||||
이제 백엔드가 있기 때문에 백엔드와 연결하는 프론트엔드를 생성할 수 있다.
|
||||
프론트엔드는 백엔드 서비스에서 제공된 DNS 이름을 사용해 백엔드 워커
|
||||
파드에 연결할 수 있다. DNS 이름은 "hello" 이고, 앞선
|
||||
서비스 구성 파일의 `name` 항목의 값이다.
|
||||
|
||||
프론트엔드 디플로이먼트 안에 파드는 hello 백엔드 서비스를 찾도록
|
||||
구성된 nginx 이미지를 실행한다. 여기에 nginx 구성 파일이 있다.
|
||||
|
||||
{{< codenew file="service/access/frontend.conf" >}}
|
||||
|
||||
백엔드와 같이, 프론트엔드는 디플로이먼트와 서비스를 갖고 있다.
|
||||
서비스의 구성은 `type: LoadBalancer` 이며, 이는 서비스가
|
||||
클라우드 공급자의 기본 로드 밸런서를 사용하는 것을 의미한다.
|
||||
|
||||
{{< codenew file="service/access/frontend.yaml" >}}
|
||||
|
||||
프론트엔드 디플로이먼트와 서비스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml
|
||||
```
|
||||
|
||||
결과는 두 리소스가 생성되었음을 확인한다.
|
||||
|
||||
```
|
||||
deployment.apps/frontend created
|
||||
service/frontend created
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
nginx 구성은 [컨테이너 이미지](/examples/service/access/Dockerfile)에
|
||||
반영 되었다. 이를 실행하는 더 좋은 방법은
|
||||
구성을
|
||||
보다 쉽게 변경할
|
||||
수 있는 [컨피그맵(ConfigMap)](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 사용하는 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
## 프론트엔드 서비스와 통신하기
|
||||
|
||||
일단 로드밸런서 타입의 서비스를 생성하면, 이 명령어를
|
||||
사용해 외부 IP를 찾을 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get service frontend --watch
|
||||
```
|
||||
|
||||
`frontend` 서비스의 구성을 보여주고, 변경 사항을
|
||||
주시한다. 처음에, 외부 IP는 `<pending>` 으로 나열된다.
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend LoadBalancer 10.51.252.116 <pending> 80/TCP 10s
|
||||
```
|
||||
|
||||
하지만, 외부 IP가 생성되자마자 구성은
|
||||
`EXTERNAL-IP` 제목 아래에 새로운 IP를 포함하여 갱신한다.
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend LoadBalancer 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m
|
||||
```
|
||||
|
||||
이제 해당 IP는 클러스터 외부에서 `frontend` 서비스와 통신하는데
|
||||
사용된다.
|
||||
|
||||
## 프론트엔드 통해서 트래픽 보내기
|
||||
|
||||
이제 프론트엔드와 백엔드가 연결되었다. 프론트엔드 서비스의 외부 IP에서
|
||||
curl 명령을 사용해 엔드포인트에 도달할 수 있다.
|
||||
|
||||
```shell
|
||||
curl http://${EXTERNAL_IP} # 앞의 예에서 본 EXTERNAL-IP로 수정한다
|
||||
```
|
||||
|
||||
결과로 백엔드에서 생성된 메시지가 보인다.
|
||||
|
||||
```json
|
||||
{"message":"Hello"}
|
||||
```
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
서비스를 삭제하기 위해, 아래 명령어를 입력하자.
|
||||
|
||||
```shell
|
||||
kubectl delete services frontend hello
|
||||
```
|
||||
|
||||
백엔드와 프론트엔드 애플리케이션에서 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하기 위해, 아래 명령어를 입력하자.
|
||||
|
||||
```shell
|
||||
kubectl delete deployment frontend hello
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 알아본다.
|
||||
* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)에 대해 더 알아본다.
|
||||
|
||||
|
|
@ -7,7 +7,7 @@ min-kubernetes-server-version: v1.10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서
|
||||
이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서
|
||||
실행중인 Redis 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스
|
||||
디버깅에 유용할 수 있다.
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ min-kubernetes-server-version: v1.10
|
|||
## Redis 디플로이먼트와 서비스 생성하기
|
||||
|
||||
1. Redis를 실행하기 위해 디플로이먼트를 생성한다.
|
||||
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
|
||||
```
|
||||
|
|
@ -151,7 +151,7 @@ min-kubernetes-server-version: v1.10
|
|||
또는 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl port-forward svc/redis-master 7000:6379
|
||||
kubectl port-forward service/redis-master 7000:redis
|
||||
```
|
||||
|
||||
위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
|
||||
|
|
@ -203,7 +203,3 @@ UDP 프로토콜에 대한 지원은
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)에 대해 더 알아본다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
|
|||
만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
|
||||
|
||||
네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다.
|
||||
만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
|
||||
만약 생성에 실패하면, 첫 번째 네임스페이스가 선택된다.
|
||||
|
||||
- **이미지 풀(Pull) 시크릿**:
|
||||
특정 도커 컨테이너 이미지가 프라이빗한 경우,
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ deployment.apps/cilium-operator created
|
|||
```
|
||||
|
||||
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
|
||||
L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예, HTTP)의 보안 정책을
|
||||
L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, HTTP)의 보안 정책을
|
||||
적용하는 방법을 설명한다.
|
||||
|
||||
## 실리움을 실 서비스 용도로 배포하기
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ weight: 130
|
|||
`/usr/share/nginx/html` 에 마운트한다. 초기화 컨테이너는 다음 명령을 실행 후
|
||||
종료한다.
|
||||
|
||||
wget -O /work-dir/index.html http://kubernetes.io
|
||||
wget -O /work-dir/index.html http://info.cern.ch
|
||||
|
||||
초기화 컨테이너는 nginx 서버의 루트 디렉터리 내 `index.html` 파일을
|
||||
저장한다.
|
||||
|
|
@ -67,16 +67,13 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
|
|||
|
||||
출력 결과는 nginx가 초기화 컨테이너에 의해 저장된 웹 페이지를 제공하고 있음을 보여준다.
|
||||
|
||||
<!Doctype html>
|
||||
<html id="home">
|
||||
<html><head></head><body><header>
|
||||
<title>http://info.cern.ch</title>
|
||||
</header>
|
||||
|
||||
<head>
|
||||
...
|
||||
"url": "http://kubernetes.io/"}</script>
|
||||
</head>
|
||||
<body>
|
||||
<h1>http://info.cern.ch - home of the first website</h1>
|
||||
...
|
||||
<p>Kubernetes is open source giving you the freedom to take advantage ...</p>
|
||||
<li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
|
||||
...
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ Redis 파드의
|
|||
|
||||
* [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 참고한다.
|
||||
|
||||
* 쿠버네티스는 `emptyDir` 이 제공하는 로컬 디스크 스토리지 뿐만 아니라,
|
||||
* 쿠버네티스는 `emptyDir` 이 제공하는 로컬 디스크 스토리지뿐만 아니라,
|
||||
중요한 데이터에 선호하는 GCE의 PD, EC2의 EBS를 포함해서
|
||||
네트워크 연결 스토리지(NAS) 솔루션을 지원하며,
|
||||
노드의 디바이스 마운트, 언마운트와 같은 세부사항을 처리한다.
|
||||
|
|
|
|||
|
|
@ -7,16 +7,16 @@ content_type: concept
|
|||
|
||||
컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
|
||||
쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
|
||||
`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
|
||||
`kubectl top` 커맨드 사용하여 사용자가 직접적으로 액세스하거나,
|
||||
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 메트릭 API
|
||||
|
||||
메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인
|
||||
메트릭 API를 통해, 주어진 노드나 파드에서 현재 사용중인
|
||||
리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
|
||||
않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
|
||||
않으므로, 예를 들어, 지정된 노드에서 10분 전에 사용된 리소스의 양을
|
||||
가져오는 것과 같은 일을 할 수는 없다.
|
||||
|
||||
이 API와 다른 API는 차이가 없다.
|
||||
|
|
@ -52,14 +52,12 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다.
|
|||
## 메트릭 서버
|
||||
|
||||
[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
|
||||
`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
|
||||
기본적으로, `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 메트릭 서버가
|
||||
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
|
||||
[디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다.
|
||||
|
||||
메트릭 서버는 각 노드에서 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해
|
||||
노출된 Summary API에서 메트릭을 수집한다.
|
||||
|
||||
메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
|
||||
노출된 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)에서
|
||||
|
|
|
|||
|
|
@ -108,11 +108,7 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1
|
|||
|
||||
|
||||
```shell
|
||||
kubectl run -it --rm load-generator --image=busybox /bin/sh
|
||||
|
||||
Hit enter for command prompt
|
||||
|
||||
while true; do wget -q -O- http://php-apache; done
|
||||
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
|
||||
```
|
||||
|
||||
실행 후, 약 1분 정도 후에 CPU 부하가 올라가는 것을 볼 수 있다.
|
||||
|
|
@ -386,7 +382,7 @@ object:
|
|||
외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
|
||||
위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고,
|
||||
`Object` 대신에 `External` 메트릭 타입을 사용한다.
|
||||
만일 여러개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
|
||||
만일 여러 개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
|
||||
외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고,
|
||||
`Object` 타입을 사용할 때와 똑같이 동작한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -406,6 +406,9 @@ behavior:
|
|||
|
||||
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
|
||||
전략을 추가할 수 있다.
|
||||
분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소
|
||||
정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면
|
||||
자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다.
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
|
|
@ -417,7 +420,7 @@ behavior:
|
|||
- type: Pods
|
||||
value: 5
|
||||
periodSeconds: 60
|
||||
selectPolicy: Max
|
||||
selectPolicy: Min
|
||||
```
|
||||
|
||||
### 예시: 스케일 다운 비활성화
|
||||
|
|
|
|||
|
|
@ -8,34 +8,41 @@ no_list: true
|
|||
## kubectl
|
||||
|
||||
쿠버네티스 커맨드 라인 도구인 `kubectl` 사용하면 쿠버네티스 클러스터에 대해 명령을
|
||||
실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및
|
||||
실행할 수 있다. `kubectl` 을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및
|
||||
관리하고, 로그를 볼 수 있다.
|
||||
|
||||
클러스터에 접근하기 위해 `kubectl` 을 다운로드 및 설치하고 설정하는 방법에 대한 정보는
|
||||
[kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다.
|
||||
[`kubectl` 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을
|
||||
참고한다.
|
||||
|
||||
`kubectl` 레퍼런스 문서를 읽어볼 수도 있다.
|
||||
<a class="btn btn-primary" href="/ko/docs/tasks/tools/install-kubectl/" role="button" aria-label="kubectl 설치 및 설정 가이드 보기">kubectl 설치 및 설정 가이드 보기</a>
|
||||
|
||||
## Minikube
|
||||
[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)를 읽어볼 수도 있다.
|
||||
|
||||
[Minikube](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는
|
||||
도구이다. Minikube는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
|
||||
## minikube
|
||||
|
||||
[`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는
|
||||
도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
|
||||
단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을
|
||||
수행할 수 있다.
|
||||
|
||||
공식 사이트에서의 [시작하기!](https://minikube.sigs.k8s.io/docs/start/)
|
||||
가이드를 따라 해볼 수 있고, 또는 도구 설치에 중점을 두고 있다면
|
||||
[Minikube 설치](/ko/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.
|
||||
도구 설치에 중점을 두고 있다면 공식 사이트에서의
|
||||
[시작하기!](https://minikube.sigs.k8s.io/docs/start/)
|
||||
가이드를 따라 해볼 수 있다.
|
||||
|
||||
Minikube가 작동하면, 이를 사용하여
|
||||
<a class="btn btn-primary" href="https://minikube.sigs.k8s.io/docs/start/" role="button" aria-label="minikube 시작하기! 가이드 보기">minikube 시작하기! 가이드 보기</a>
|
||||
|
||||
`minikube` 가 작동하면, 이를 사용하여
|
||||
[샘플 애플리케이션을 실행](/ko/docs/tutorials/hello-minikube/)해볼 수 있다.
|
||||
|
||||
## kind
|
||||
|
||||
Minikube와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서
|
||||
쿠버네티스를 실행할 수 있다. Minikuke와 달리, kind는 단일 컨테이너 런타임에서만 작동한다.
|
||||
kind는 [도커](https://docs.docker.com/get-docker/)를 설치하고
|
||||
`minikube` 와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서
|
||||
쿠버네티스를 실행할 수 있다. `minikube` 와 달리, `kind` 는 단일 컨테이너 런타임에서만 작동한다.
|
||||
`kind` 는 [도커](https://docs.docker.com/get-docker/)를 설치하고
|
||||
구성해야 한다.
|
||||
|
||||
[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 kind를 시작하고 실행하기 위해
|
||||
[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 `kind` 를 시작하고 실행하기 위해
|
||||
수행해야 하는 작업을 보여준다.
|
||||
|
||||
<a class="btn btn-primary" href="https://kind.sigs.k8s.io/docs/user/quick-start/" role="button" aria-label="kind 시작하기 가이드 보기">kind 시작하기 가이드 보기</a>
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소
|
|||
|
||||
{{< tabs name="kubectl_install" >}}
|
||||
{{< tab name="Ubuntu, Debian 또는 HypriotOS" codelang="bash" >}}
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
|
||||
sudo apt-get update
|
||||
|
|
|
|||
|
|
@ -1,262 +0,0 @@
|
|||
---
|
||||
title: Minikube 설치
|
||||
content_type: task
|
||||
weight: 20
|
||||
card:
|
||||
name: tasks
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 단일 노드 쿠버네티스 클러스터를 노트북의 가상 머신에서 구동하는 도구인 [Minikube](/ko/docs/tutorials/hello-minikube)의 설치 방법을 설명한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< tabs name="minikube_before_you_begin" >}}
|
||||
{{% tab name="리눅스" %}}
|
||||
리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다.
|
||||
```
|
||||
grep -E --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="맥OS" %}}
|
||||
맥OS에서 가상화 지원 여부를 확인하려면, 아래 명령어를 터미널에서 실행한다.
|
||||
```
|
||||
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
|
||||
```
|
||||
만약 출력 중에 (색상으로 강조된) `VMX`를 볼 수 있다면, VT-x 기능이 머신에서 활성화된 것이다.
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="윈도우" %}}
|
||||
윈도우 8 이후 버전에서 가상화 지원 여부를 확인하려면, 다음 명령어를 윈도우 터미널이나 명령 프롬프트에서 실행한다.
|
||||
```
|
||||
systeminfo
|
||||
```
|
||||
아래와 같은 내용을 볼 수 있다면, 윈도우에서 가상화를 지원한다.
|
||||
```
|
||||
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
|
||||
Virtualization Enabled In Firmware: Yes
|
||||
Second Level Address Translation: Yes
|
||||
Data Execution Prevention Available: Yes
|
||||
```
|
||||
|
||||
다음의 출력을 확인할 수 있다면, 이미 하이퍼바이저가 설치되어 있는 것으로 다음 단계를 건너 뛸 수 있다.
|
||||
```
|
||||
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## minikube 설치하기
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="리눅스" %}}
|
||||
|
||||
### kubectl 설치
|
||||
|
||||
kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#리눅스에-kubectl-설치)의 요령을 따라서 설치할 수 있다.
|
||||
|
||||
## 하이퍼바이저(hypervisor) 설치
|
||||
|
||||
하이퍼바이저를 설치하지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다.
|
||||
|
||||
• [KVM](https://www.linux-kvm.org/), 또한 QEMU를 사용한다
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--driver=none` 옵션도 지원한다.
|
||||
이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경이 필요하지만, 하이퍼바이저는 필요하지 않다.
|
||||
|
||||
데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우,
|
||||
Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다.
|
||||
[도커](https://www.docker.com/products/docker-desktop)에서 `.deb` 패키지를 다운로드 할 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
`none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다.
|
||||
`--driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다.
|
||||
{{< /caution >}}
|
||||
|
||||
Minikube는 도커 드라이브와 비슷한 `vm-driver=podman` 도 지원한다. 슈퍼사용자 권한(root 사용자)으로 실행되는 Podman은 컨테이너가 시스템에서 사용 가능한 모든 기능에 완전히 접근할 수 있는 가장 좋은 방법이다.
|
||||
|
||||
{{< caution >}}
|
||||
일반 사용자 계정은 컨테이너를 실행하는 데 필요한 모든 운영 체제 기능에 완전히 접근할 수 없기에 `podman` 드라이버는 컨테이너를 root로 실행해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
### 패키지를 이용하여 Minikube 설치
|
||||
|
||||
Minikube를 위한 *실험적인* 패키지가 있다.
|
||||
리눅스 (AMD64) 패키지는 GitHub의 Minikube의 [릴리스](https://github.com/kubernetes/minikube/releases)에서 찾을 수 있다.
|
||||
|
||||
적절한 패키지를 설치하기 위해 리눅스 배포판의 패키지 도구를 사용한다.
|
||||
|
||||
### Minikube를 직접 다운로드하여 설치
|
||||
|
||||
패키지를 통해 설치하지 못하였다면,
|
||||
바이너리 자체를 다운로드 받고 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다.
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /usr/local/bin/
|
||||
sudo install minikube /usr/local/bin/
|
||||
```
|
||||
|
||||
### Homebrew를 이용해서 Minikube 설치하기
|
||||
|
||||
또 다른 대안으로 리눅스 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다.
|
||||
|
||||
```shell
|
||||
brew install minikube
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="맥OS" %}}
|
||||
### kubectl 설치
|
||||
|
||||
kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#macos에-kubectl-설치)의 요령을 따라서 설치할 수 있다.
|
||||
|
||||
### 하이퍼바이저(hypervisor) 설치
|
||||
|
||||
하이퍼바이저를 설치하지 않았다면, 다음 중 하나를 지금 설치한다.
|
||||
|
||||
• [HyperKit](https://github.com/moby/hyperkit)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
• [VMware Fusion](https://www.vmware.com/products/fusion)
|
||||
|
||||
### Minikube 설치
|
||||
가장 쉽게 맥OS에 Minikube를 설치하는 방법은 [Homebrew](https://brew.sh)를 이용하는 것이다.
|
||||
|
||||
```shell
|
||||
brew install minikube
|
||||
```
|
||||
|
||||
실행 바이너리를 다운로드 받아서 맥OS에 설치할 수도 있다.
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다.
|
||||
|
||||
```shell
|
||||
sudo mv minikube /usr/local/bin
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="윈도우" %}}
|
||||
### kubectl 설치하기
|
||||
|
||||
kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#windows에-kubectl-설치)의 요령을 따라서 설치할 수 있다.
|
||||
|
||||
### 하이퍼바이저(hypervisor) 설치하기
|
||||
|
||||
하이퍼바이저가 설치 안 되어 있다면 아래중 하나를 지금 설치한다.
|
||||
|
||||
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
Hyper-V는 다음 세 버전의 윈도우 10에서 실행할 수 있다. Windows 10 Enterprise, Windows 10 Professional, Windows 10 Education.
|
||||
{{< /note >}}
|
||||
|
||||
### Chocolatey를 이용한 Minikube 설치
|
||||
|
||||
윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다(관리자 권한으로 실행).
|
||||
|
||||
```shell
|
||||
choco install minikube
|
||||
```
|
||||
|
||||
Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube 실행 파일의 경로는 실행 경로(path)에 자동으로 추가된다.
|
||||
|
||||
### 인스톨러 실행파일을 통한 Minikube 설치
|
||||
|
||||
[윈도우 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)를 사용하여 윈도우에 Minikube를 수동으로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다.
|
||||
|
||||
### 직접 다운로드하여 Minikube 설치
|
||||
|
||||
윈도우에서 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 다운로드 받아서, 파일 이름을 `minikube.exe`로 변경하고, 실행 경로에 추가한다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## 설치 확인
|
||||
|
||||
하이퍼바이저와 Minikube의 성공적인 설치를 확인하려면, 다음 명령어를 실행해서 로컬 쿠버네티스 클러스터를 시작할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
`minikube start` 시 `--driver` 를 설정하려면, 아래에 `<driver_name>` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 지정하기 문서](/ko/docs/setup/learning-environment/minikube/#vm-드라이버-지정하기)에서 확인할 수 있다.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
KVM을 사용할 때 Debian과 다른 시스템에서 libvirt의 기본 QEMU URI는 `qemu:///session`이고, Minikube의 기본 QEMU URI는 `qemu:///system`이다. 시스템이 이런 환경이라면, `--kvm-qemu-uri qemu:///session`을 `minikube start`에 전달해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
```shell
|
||||
minikube start --driver=<driver_name>
|
||||
```
|
||||
|
||||
`minikube start` 가 완료되면, 아래 명령을 실행해서 클러스터의 상태를 확인한다.
|
||||
|
||||
```shell
|
||||
minikube status
|
||||
```
|
||||
|
||||
만약 클러스터가 실행 중이면, `minikube status` 의 출력은 다음과 유사해야 한다.
|
||||
|
||||
```
|
||||
host: Running
|
||||
kubelet: Running
|
||||
apiserver: Running
|
||||
kubeconfig: Configured
|
||||
```
|
||||
|
||||
Minikube가 선택한 하이퍼바이저와 작동하는지 확인한 후에는, Minikube를 계속 사용하거나 클러스터를 중지할 수 있다. 클러스터를 중지하려면 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
minikube stop
|
||||
```
|
||||
|
||||
## 새롭게 시작하기 위해 모두 정리하기 {#cleanup-local-state}
|
||||
|
||||
이전에 Minikube를 설치했었다면, 다음을 실행한다.
|
||||
```shell
|
||||
minikube start
|
||||
```
|
||||
|
||||
그리고 `minikube start`는 에러를 보여준다.
|
||||
```shell
|
||||
machine does not exist
|
||||
```
|
||||
|
||||
이제 구성 파일을 삭제해야 한다.
|
||||
```shell
|
||||
minikube delete
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Minikube로 로컬에서 쿠버네티스 실행하기](/ko/docs/setup/learning-environment/minikube/)
|
||||
|
|
@ -137,6 +137,9 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
|||
`--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기
|
||||
원한다는 뜻이다.
|
||||
|
||||
`k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
|
||||
사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
|
||||
|
||||
2. 방금 생성한 서비스 살펴보기
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ weight: 10
|
|||
방식으로 패키지할 필요가 있다. 즉, 컨테이너화 해야 한다. 컨테이너화된 애플리케이션은 호스트에
|
||||
매우 깊이 통합된 패키지로써, 특정 머신에 직접 설치되는 예전의 배포 모델보다 유연하고 가용성이 높다.
|
||||
<b>쿠버네티스는 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 보다 효율적으로
|
||||
자동화한다.</b>
|
||||
자동화한다.</b>
|
||||
쿠버네티스는 오픈소스 플랫폼이고 운영 수준의 안정성을 가졌다.
|
||||
</p>
|
||||
<p>쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.
|
||||
|
|
@ -56,7 +56,7 @@ weight: 10
|
|||
</div>
|
||||
<div class="content__box content__box_fill">
|
||||
<p><i>
|
||||
쿠버네티스는 컴퓨터 클러스터에 걸쳐서 애플리케이션 컨테이너의 위치(스케줄링)와 실행을
|
||||
쿠버네티스는 컴퓨터 클러스터에 걸쳐서 애플리케이션 컨테이너의 위치(스케줄링)와 실행을
|
||||
오케스트레이션하는 운영 수준의 오픈소스 플랫폼이다.
|
||||
</i></p>
|
||||
</div>
|
||||
|
|
@ -84,7 +84,7 @@ weight: 10
|
|||
클러스터 내 모든 활동을 조율한다.</p>
|
||||
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로써 동작하는 VM 또는 물리적인 컴퓨터다.</b>
|
||||
각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는
|
||||
컨테이너 운영을 담당하는 Docker 또는 rkt와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스
|
||||
컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스
|
||||
클러스터는 최소 세 대의 노드를 가져야한다.</p>
|
||||
|
||||
</div>
|
||||
|
|
@ -103,10 +103,10 @@ weight: 10
|
|||
사용해서 클러스터와 상호작용할 수 있다.</p>
|
||||
|
||||
<p>쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면
|
||||
Minikube를 사용할 수 있다. Minikube는 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한
|
||||
클러스터를 배포하는 가벼운 쿠버네티스 구현체다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서
|
||||
구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인
|
||||
부트스트래핑 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는
|
||||
Minikube를 사용할 수 있다. Minikube는 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한
|
||||
클러스터를 배포하는 가벼운 쿠버네티스 구현체다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서
|
||||
구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인
|
||||
부트스트래핑 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는
|
||||
온라인 터미널을 사용할 것이다.</p>
|
||||
|
||||
<p>이제 쿠버네티스가 무엇인지 알아봤으니, 온라인 튜토리얼로 이동해서 우리의 첫 번째 클러스터를
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ weight: 10
|
|||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="content__box content__box_fill">
|
||||
<p><i> 노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러개의 파드는 하나의 노드 위에서 동작할 수 있다.</i></p>
|
||||
<p><i> 노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러 개의 파드는 하나의 노드 위에서 동작할 수 있다.</i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,8 @@ metadata:
|
|||
tier: backend
|
||||
spec:
|
||||
ports:
|
||||
- port: 6379
|
||||
- name: redis
|
||||
port: 6379
|
||||
targetPort: 6379
|
||||
selector:
|
||||
app: redis
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ spec:
|
|||
- wget
|
||||
- "-O"
|
||||
- "/work-dir/index.html"
|
||||
- http://kubernetes.io
|
||||
- http://info.cern.ch
|
||||
volumeMounts:
|
||||
- name: workdir
|
||||
mountPath: "/work-dir"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
FROM nginx:1.17.3
|
||||
|
||||
RUN rm /etc/nginx/conf.d/default.conf
|
||||
COPY frontend.conf /etc/nginx/conf.d
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
upstream hello {
|
||||
server hello;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
|
||||
location / {
|
||||
proxy_pass http://hello;
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: frontend
|
||||
ports:
|
||||
- protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 80
|
||||
type: LoadBalancer
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello
|
||||
tier: frontend
|
||||
track: stable
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: frontend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: "gcr.io/google-samples/hello-frontend:1.0"
|
||||
lifecycle:
|
||||
preStop:
|
||||
exec:
|
||||
command: ["/usr/sbin/nginx","-s","quit"]
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: backend
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: http
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello
|
||||
tier: backend
|
||||
track: stable
|
||||
replicas: 7
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: backend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: "gcr.io/google-samples/hello-go-gke:1.0"
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
Loading…
Reference in New Issue