Fourth Korean l10n work for release-1.15 (#16063)
* ko: update translation in reference/glossary/* (#15776) * Update outdated files partly in dev-1.15-ko.4 (#15856) * ko: update translation in tasks/debug-application-cluster/resource-metrics-pipeline (#15798) * ko: translate setup/production-environment/tools/control-plane-flags (#15820) * ko: translate user-guide-windows-containers (#15730) * ko: update translation in reference/glossary/* (#15761) * ko: Update outdated files partly in dev-1.15-ko.4 (#15790) * ko: fix corrupt date in glossary/static-pod (#15911) * ko: translate user-guide-windows-nodes (#15759) * Translate /docs/concepts/configuration/overview/ in Korean (#15803) * ko: translate setup/production-environment/tools/ha-topology (#15819) * ko: translate tasks/administer-cluster/network-policy-provider (#15846) * Translate tasks/inject-data-application/define-command-argument-container in Korea (#15933) * ko: translate concepts/configuration/organize-cluster-access-kubeconfig (#15871) * Translate working-with-objects/common-labels.md in Korean (#15832) * Translate concepts/workloads/pods/disruptions.md in Korean (#15926) * Translate tasks/access-application-cluster/web-ui/dashboard in Korean (#15852) * Translate concepts/overview/working-with-objects/labels.md in Korean (#15831) * ko: translate guestbook-logs-metrics-with-elk (#15894) * ko: translate tasks/administer-cluster/highly-available-master (#15928) Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: Eden <longlg88@naver.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com> Co-Authored-By: alice_k106 <alice_k106@naver.com> Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
This commit is contained in:
Seokho Son
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
270aaf1f16
commit
c82a912e29
@@ -0,0 +1,165 @@
|
||||
---
|
||||
title: 웹 UI (대시보드)
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 30
|
||||
title: Use the Web UI Dashboard
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
|
||||
|
||||
또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다.
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 대시보드 UI 배포
|
||||
|
||||
대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다.
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
## 대시보드 UI 접근
|
||||
|
||||
클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user) 가이드를 따른다.
|
||||
|
||||
{{< warning >}}
|
||||
시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다.
|
||||
{{< /warning >}}
|
||||
|
||||
### 커맨드 라인 프록시
|
||||
kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로써 대시보드를 사용할 수 있다.
|
||||
|
||||
```
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
kubectl은 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
|
||||
|
||||
UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 인증서를 지원하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
## 웰컴 뷰
|
||||
|
||||
초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. 이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. 게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` [네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
|
||||
|
||||
|
||||
|
||||
## 컨테이너화 된 애플리케이션 배포
|
||||
|
||||
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
|
||||
|
||||
시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
|
||||
|
||||
### 애플리케이션 세부 정보 지정
|
||||
|
||||
배포 마법사는 다음 정보를 제공한다.
|
||||
|
||||
- **앱 이름** (필수): 애플리케이션 이름. [레이블](/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다.
|
||||
|
||||
애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
|
||||
|
||||
- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다.
|
||||
|
||||
- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다.
|
||||
|
||||
클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
|
||||
|
||||
- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
|
||||
|
||||
클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다.
|
||||
|
||||
서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
|
||||
|
||||
만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
|
||||
|
||||
- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
|
||||
|
||||
- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
|
||||
|
||||
예를 들면:
|
||||
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
|
||||
- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다.
|
||||
|
||||
대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
|
||||
네임스페이스 이름은 숫자로만 구성할 수 없다. 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
|
||||
|
||||
네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
|
||||
|
||||
- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다.
|
||||
|
||||
대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다.
|
||||
|
||||
이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
|
||||
|
||||
- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
|
||||
|
||||
- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/user-guide/containers/#containers-and-commands)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
|
||||
|
||||
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
|
||||
|
||||
- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
|
||||
|
||||
### YAML 또는 JSON 파일 업로드
|
||||
|
||||
쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
|
||||
|
||||
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
|
||||
|
||||
## 대시보드 사용
|
||||
다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
|
||||
|
||||
### 탐색
|
||||
|
||||
클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
|
||||
|
||||
대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
|
||||
|
||||
#### 어드민 개요
|
||||
클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
|
||||
|
||||
#### 워크로드
|
||||
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
|
||||
|
||||
워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
|
||||
|
||||
#### 서비스(Service)
|
||||
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
|
||||
|
||||
#### 스토리지
|
||||
스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
|
||||
|
||||
#### 컨피그 맵과 시크릿
|
||||
클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
|
||||
|
||||
#### 로그 뷰어
|
||||
파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. 뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 고가용성 쿠버네티스 클러스터 마스터 설정하기
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.5" state="alpha" >}}
|
||||
|
||||
구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 마스터를 복제할 수 있다.
|
||||
이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## HA 호환 클러스터 시작
|
||||
|
||||
새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다.
|
||||
|
||||
* `MULTIZONE=true` - 서버의 기본 존(zone)과 다른 존에서 마스터 복제본의 kubelet이 제거되지 않도록 한다.
|
||||
다른 존에서 마스터 복제본을 실행하려는 경우에 권장하고 필요하다.
|
||||
|
||||
* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다.
|
||||
true인 경우, Etcd의 리더 복제본에서 읽는다.
|
||||
이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다.
|
||||
|
||||
선택적으로 첫 번째 마스터 복제본이 생성될 GCE 존을 지정할 수 있다.
|
||||
다음 플래그를 설정한다.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - 첫 마스터 복제본이 실행될 존.
|
||||
|
||||
다음 샘플 커맨드는 europe-west1-b GCE 존에 HA 호환 클러스터를 구성한다.
|
||||
|
||||
```shell
|
||||
MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
위에 커맨드는 하나의 마스터로 클러스터를 생성한다.
|
||||
그러나 후속 커맨드로 새 마스터 복제본을 추가할 수 있다.
|
||||
|
||||
## 새 마스터 복제본 추가
|
||||
|
||||
HA 호환 클러스터를 생성한 다음 그것의 마스터 복제본을 추가할 수 있다.
|
||||
`kube-up` 스크립트에 다음 플래그를 사용하여 마스터 복제본을 추가한다.
|
||||
|
||||
* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 마스터의 복제본을
|
||||
만든다.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 실행될 존.
|
||||
반드시 다른 복제본 존과 동일한 존에 있어야 한다.
|
||||
|
||||
HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로
|
||||
설정할 필요는 없다.
|
||||
|
||||
다음 샘플 커맨드는 기존 HA 호환 클러스터에서 마스터를 복제한다.
|
||||
|
||||
```shell
|
||||
KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## 마스터 복제본 제거
|
||||
|
||||
다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 마스터 복제본을 제거할 수 있다.
|
||||
|
||||
* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 제거될 존.
|
||||
|
||||
* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 마스터 복제본의 이름.
|
||||
비어있는 경우, 해당 존의 모든 복제본이 제거된다.
|
||||
|
||||
다음 샘플 커맨드는 기존 HA 클러스터에서 마스터 복제본을 제거한다.
|
||||
|
||||
```shell
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
## 마스터 복제 실패 처리
|
||||
|
||||
HA 클러스터의 마스터 복제본 중 하나가 실패하면,
|
||||
클러스터에서 복제본을 제거하고 동일한 존에서 새 복제본을 추가하는 것이 가장 좋다.
|
||||
다음 샘플 커맨드로 이 과정을 시연한다.
|
||||
|
||||
1. 손상된 복제본을 제거한다.
|
||||
|
||||
```shell
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
1. 기존 복제본 대신 새 복제본을 추가한다.
|
||||
|
||||
```shell
|
||||
KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## HA 클러스터에서 마스터 복제에 관한 모범 사례
|
||||
|
||||
* 다른 존에 마스터 복제본을 배치하도록 한다. 한 존이 실패하는 동안, 해당 존에 있는 마스터도 모두 실패할 것이다.
|
||||
존 장애를 극복하기 위해 노드를 여러 존에 배치한다
|
||||
(더 자세한 내용은 [멀티 존](/docs/setup/best-practices/multiple-zones/)를 참조한다).
|
||||
|
||||
* 두 개의 마스터 복제본은 사용하지 않는다. 두 개의 복제 클러스터에 대한 합의는 지속적 상태를 변경해야 할 때 두 복제본 모두 실행해야 한다.
|
||||
결과적으로 두 복제본 모두 필요하고, 어떤 복제본의 장애에도 클러스터가 대부분 장애 상태로 변한다.
|
||||
따라서 두 개의 복제본 클러스터는 HA 관점에서 단일 복제 클러스터보다 열등하다.
|
||||
|
||||
* 마스터 복제본을 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
|
||||
클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
|
||||
이 작업은 [여기](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) 기술한 대로
|
||||
Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## 구현 지침
|
||||
|
||||
|
||||
|
||||
### 개요
|
||||
|
||||
각 마스터 복제본은 다음 모드에서 다음 구성 요소를 실행한다.
|
||||
|
||||
* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다.
|
||||
|
||||
* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다.
|
||||
|
||||
* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다.
|
||||
|
||||
* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다.
|
||||
|
||||
또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다.
|
||||
|
||||
### 로드 밸런싱
|
||||
|
||||
두 번째 마스터 복제본을 시작할 때, 두 개의 복제본을 포함된 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다.
|
||||
비슷하게 끝에서 두 번째의 마스터 복제본을 제거한 후에는 로드 밸런서가 제거되고
|
||||
해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
|
||||
로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
|
||||
|
||||
### 마스터 서비스와 Kubelet
|
||||
|
||||
쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
|
||||
시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
|
||||
|
||||
* 단일 마스터 클러스터에서 IP 주소는 단일 마스터를 가리킨다.
|
||||
|
||||
* 다중 마스터 클러스터에서 IP 주소는 마스터 앞에 로드밸런서를 가리킨다.
|
||||
|
||||
마찬가지로 Kubelet은 외부 IP 주소를 사용하여 마스터와 통신한다.
|
||||
|
||||
### 마스터 인증서
|
||||
|
||||
쿠버네티스는 각 복제본의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 마스터 TLS 인증서를 발급한다.
|
||||
복제본의 임시 공개 IP 주소에 대한 인증서는 없다.
|
||||
임시 퍼블릭 IP 주소를 통해 복제본에 접근하려면, TLS 검증을 건너뛰어야 한다.
|
||||
|
||||
### etcd 클러스터화
|
||||
|
||||
etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용).
|
||||
이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다.
|
||||
|
||||
## 추가 자료
|
||||
|
||||
[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 네트워크 폴리시 제공자(Network Policy Provider) 설치
|
||||
weight: 30
|
||||
---
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 네트워크 폴리시로 캘리코(Calico) 사용하기
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 쿠버네티스에서 캘리코(Calico) 클러스터를 생성하는 몇 가지 빠른 방법을 살펴본다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
[클라우드](#creating-a-calico-cluster-with-google-kubernetes-engine-gke)나 [지역](#creating-a-local-calico-cluster-with-kubeadm) 클러스터 중에 어디에 배포할지 결정한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
## 구글 쿠버네티스 엔진(GKE)에 캘리코 클러스터 생성하기 {#creating-a-calico-cluster-with-google-kubernetes-engine-gke}
|
||||
|
||||
**사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
|
||||
|
||||
1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다.
|
||||
|
||||
**문법**
|
||||
```shell
|
||||
gcloud container clusters create [클러스터_이름] --enable-network-policy
|
||||
```
|
||||
|
||||
**예시**
|
||||
```shell
|
||||
gcloud container clusters create my-calico-cluster --enable-network-policy
|
||||
```
|
||||
|
||||
1. 배포를 확인하기 위해, 다음 커맨드를 이용하자.
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
캘리코 파드는 `calico`로 시작한다. 각각의 상태가 `Running`임을 확인하자.
|
||||
|
||||
## kubeadm으로 지역 캘리코 클러스터 생성하기 {#creating-a-local-calico-cluster-with-kubeadm}
|
||||
|
||||
Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러스터를 생성하려면,
|
||||
[캘리코 빠른 시작](https://docs.projectcalico.org/latest/getting-started/kubernetes/)을 참고한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해
|
||||
[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 네트워크 폴리시로 실리움(Cilium) 사용하기
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 어떻게 네트워크 폴리시(NetworkPolicy)로 실리움(Cilium)를 사용하는지 살펴본다.
|
||||
|
||||
실리움의 배경에 대해서는 [실리움 소개](https://cilium.readthedocs.io/en/stable/intro)를 읽어보자.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
## 기본 시험을 위해 실리움을 Minikube에 배포하기
|
||||
|
||||
실리움에 쉽게 친숙해지기 위해
|
||||
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
|
||||
[실리움 쿠버네티스 시작하기 안내](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
|
||||
|
||||
Minikube를 시작하려면 최소 버전으로 >= v0.33.1 이 필요하고,
|
||||
다음의 실행 파라미터로 실행한다.
|
||||
|
||||
```shell
|
||||
minikube version
|
||||
```
|
||||
```
|
||||
minikube version: v0.33.1
|
||||
```
|
||||
|
||||
```shell
|
||||
minikube start --network-plugin=cni --memory=4096
|
||||
```
|
||||
|
||||
Minikube에서 실리움의 데몬셋 구성과 Minikube에 배포된 etcd 인스턴스로 접속하는데 필요한 구성 뿐만 아니라
|
||||
RBAC 설정을 포함하는 필요한 구성을
|
||||
이 간단한 ``올인원`` YAML 파일로 배포할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
daemonset.apps/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium created
|
||||
serviceaccount/cilium created
|
||||
```
|
||||
|
||||
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
|
||||
L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예, HTTP)의 보안 정책을
|
||||
적용하는 방법을 설명한다.
|
||||
|
||||
## 실리움을 실 서비스 용도로 배포하기
|
||||
|
||||
실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
|
||||
[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)를 살펴본다.
|
||||
이 문서는 자세한 요구사항, 방법과
|
||||
실제 데몬셋 예시를 포함한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
## 실리움 구성요소 이해하기
|
||||
|
||||
실리움으로 클러스터를 배포하면 파드가 `kube-system` 네임스페이스에 추가된다.
|
||||
파드의 목록을 보려면 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
다음과 유사한 파드의 목록을 볼 것이다.
|
||||
|
||||
```console
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-6rxbd 1/1 Running 0 1m
|
||||
...
|
||||
```
|
||||
|
||||
알고 있어야 할 두 가지 주요 구성요소는 다음과 같다.
|
||||
|
||||
- 먼저는 `cilium` 파드가 클러스터의 각 노드에서 운영되고,
|
||||
노드의 파드로 보내고/받는 트래픽을 리눅스 BPF를 이용하여 네트워크 폴리시를 적용한다.
|
||||
- 실 서비스에 배포하는 경우 실리움은 키-값 저장소(예, etcd)를 활용해야 한다.
|
||||
[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)에서
|
||||
키-값 저장소를 설치하는 방법과 실리움에서 이를 구성하는 필수 단계를
|
||||
제공할 것이다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
클러스터가 동작하면,
|
||||
실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해
|
||||
[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
재미있게 즐기고, 질문이 있다면
|
||||
[실리움 슬랙 채널](https://cilium.herokuapp.com/)을 이용하여 연락한다.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기
|
||||
content_template: templates/task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
운영 중인 쿠버네티스 클러스터가 필요하다. 클러스터가 없다면, Kops, Bootkube, Kubeadm 등을 이용해서 클러스터를 생성할 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
## 큐브 라우터 애드온 설치하기
|
||||
큐브 라우터 애드온은 갱신된 모든 네트워크 폴리시 및 파드에 대해 쿠버네티스 API 서버를 감시하고, 정책에 따라 트래픽을 허용하거나 차단하도록 iptables 규칙와 ipset을 구성하는 네트워크 폴리시 컨트롤러와 함께 제공된다. 큐브 라우터 애드온을 설치하는 [큐브 라우터를 클러스터 인스톨러와 함께 사용하기](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 안내서를 따라해 봅니다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 네트워크 폴리시로 로마나(Romana)
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
[kubeadm 시작하기](/docs/getting-started-guides/kubeadm/)의 1, 2, 3 단계를 완료하자.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## kubeadm으로 로마나 설치하기
|
||||
|
||||
Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/romana/romana/tree/master/containerize)를 따른다.
|
||||
|
||||
## 네트워크 폴리시 적용하기
|
||||
|
||||
네트워크 폴리시를 적용하기 위해 다음 중에 하나를 사용하자.
|
||||
|
||||
* [Romana 네트워크 폴리시](https://github.com/romana/romana/wiki/Romana-policies).
|
||||
* [Romana 네트워크 폴리시의 예](https://github.com/romana/core/blob/master/doc/policy.md).
|
||||
* 네트워크 폴리시 API.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+58
@@ -0,0 +1,58 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기
|
||||
content_template: templates/task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네트워크 폴리시(NetworkPolicy)로 위브넷(Weave Net)를 사용하는 방법을 살펴본다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 [kubeadm 시작하기 안내서](/docs/getting-started-guides/kubeadm/)를 따른다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Weave Net 애드온을 설치한다
|
||||
|
||||
[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다.
|
||||
|
||||
쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의 네크워크 정책 어노테이션을 자동으로 모니터링하며, 정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는 [네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다.
|
||||
|
||||
## 설치 시험
|
||||
|
||||
위브넷이 동작하는지 확인한다.
|
||||
|
||||
다음 커맨드를 입력한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -n kube-system -o wide
|
||||
```
|
||||
|
||||
출력은 다음과 유사하다.
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
weave-net-1t1qg 2/2 Running 0 9d 192.168.2.10 worknode3
|
||||
weave-net-231d7 2/2 Running 1 7d 10.2.0.17 worknodegpu
|
||||
weave-net-7nmwt 2/2 Running 3 9d 192.168.2.131 masternode
|
||||
weave-net-pmw8w 2/2 Running 0 9d 192.168.2.216 worknode2
|
||||
```
|
||||
|
||||
위브넷 파드를 가진 각 노드와 모든 파드는 `Running`이고 `2/2 READY`이다(`2/2`는 각 파드가 `weave`와 `weave-npc`를 가지고 있음을 뜻한다).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ content_template: templates/concept
|
||||
{{% capture overview %}}
|
||||
|
||||
쿠버네티스 1.8 부터 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
|
||||
쿠버네티스의 Metrics API를 통해 사용할 수 있다. 이 메트릭은
|
||||
쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
|
||||
`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
|
||||
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
|
||||
|
||||
@@ -15,9 +15,9 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Metrics API
|
||||
## 메트릭 API
|
||||
|
||||
Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인
|
||||
메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인
|
||||
리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
|
||||
않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
|
||||
가져오는 것과 같은 일을 할 수는 없다.
|
||||
@@ -31,23 +31,23 @@ Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인
|
||||
리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
이 API를 사용하려면 Metrics server를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
|
||||
이 API를 사용하려면 메트릭 서버를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
|
||||
{{< /note >}}
|
||||
|
||||
## Metrics Server
|
||||
## 메트릭 서버
|
||||
|
||||
[Metrics server](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
|
||||
쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 Metrics server가
|
||||
[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
|
||||
쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
|
||||
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
|
||||
[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 Metrics server를 배포할 수 있다.
|
||||
[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 메트릭 서버를 배포할 수 있다.
|
||||
이 방식은 쿠버네티스 1.7 이상에서 지원된다. (상세 사항은 아래를 참조)
|
||||
|
||||
Metric server는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
|
||||
메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
|
||||
|
||||
Metrics server는 쿠버네티스 1.7에서 도입된
|
||||
메트릭 서버는 쿠버네티스 1.7에서 도입된
|
||||
[쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를
|
||||
통해 메인 API 서버에 등록된다.
|
||||
|
||||
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 Metrics server에 대해 자세하게 배울 수 있다.
|
||||
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
title: 컨테이너를 위한 커맨드와 인자 정의하기
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
본 페이지는 {{< glossary_tooltip text="파드" term_id="pod" >}} 안에서 컨테이너를 실행할
|
||||
때 커맨드와 인자를 정의하는 방법에 대해 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 파드를 생성할 때 커맨드와 인자를 정의하기
|
||||
|
||||
파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 커맨드와 인자를
|
||||
정의할 수 있다. 커맨드를 정의하기 위해서는, 파드 안에서 실행되는 컨테이너에
|
||||
`command` 필드를 포함시킨다. 커맨드에 대한 인자를 정의하기 위해서는, 구성
|
||||
파일에 `args` 필드를 포함시킨다. 정의한 커맨드와 인자들은 파드가 생성되고
|
||||
난 이후에는 변경될 수 없다.
|
||||
|
||||
구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가
|
||||
제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을
|
||||
정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와
|
||||
함께 사용된다.
|
||||
|
||||
{{< note >}}
|
||||
`command` 필드는 일부 컨테이너 런타임에서 `entrypoint`에 해당된다.
|
||||
아래의 [참고사항](#참고사항)을 확인하자.
|
||||
{{< /note >}}
|
||||
|
||||
이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
|
||||
파일에서 커맨드와 두 개의 인자를 정의한다.
|
||||
|
||||
{{< codenew file="pods/commands.yaml" >}}
|
||||
|
||||
1. YAML 구성 파일을 활용해 파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/commands.yaml
|
||||
```
|
||||
|
||||
1. 실행 중인 파드들의 목록을 조회한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
출력은 command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 표시할
|
||||
것이다.
|
||||
|
||||
1. 컨테이너 안에서 실행된 커맨드의 출력을 보기 위해, 파드의 로그를
|
||||
확인한다.
|
||||
|
||||
```shell
|
||||
kubectl logs command-demo
|
||||
```
|
||||
|
||||
출력은 HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들을 표시할
|
||||
것이다.
|
||||
|
||||
```
|
||||
command-demo
|
||||
tcp://10.3.240.1:443
|
||||
```
|
||||
|
||||
## 인자를 정의하기 위해 환경 변수를 사용하기
|
||||
|
||||
이전 예제에서는, 문자열을 제공하면서 직접 인자를 정의해보았다.
|
||||
문자열을 직접 제공하는 것에 대한 대안으로, 환경 변수들을 사용하여 인자들을
|
||||
정의할 수 있다.
|
||||
|
||||
```yaml
|
||||
env:
|
||||
- name: MESSAGE
|
||||
value: "hello world"
|
||||
command: ["/bin/echo"]
|
||||
args: ["$(MESSAGE)"]
|
||||
```
|
||||
|
||||
이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure
|
||||
-pod-configmap/)과 [시크릿](/docs/concepts/configuration/secret/)을
|
||||
포함해, 환경 변수를 정의하는데 활용할 수 있는 모든 방법들을 활용해서 파드를 위한 인자를
|
||||
정의할
|
||||
수 있다는 것을 의미한다.
|
||||
|
||||
{{< note >}}
|
||||
환경 변수는 `"$(VAR)"`와 같이 괄호 안에 나타난다. 이는 변수가 `command`나 `args`
|
||||
필드 안에서 전개되기 위해 필요한 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
## 셸 안에서 커맨드 실행하기
|
||||
|
||||
일부 경우들에서는 커맨드를 셸 안에서 실행해야할 필요가 있다. 예를 들어, 실행할 커맨드가
|
||||
서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서
|
||||
커맨드를 실행하려고 한다면, 이런 방식으로 감싸주면 된다.
|
||||
|
||||
```shell
|
||||
command: ["/bin/sh"]
|
||||
args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
```
|
||||
|
||||
## 참고사항
|
||||
|
||||
이 테이블은 도커와 쿠버네티스에서 사용되는 필드 이름들을 정리한 것이다.
|
||||
|
||||
| 설명 | 도커 필드 이름 | 쿠버네티스 필드 이름 |
|
||||
|----------------------------------------|------------------------|-----------------------|
|
||||
| 컨테이너에서 실행되는 커맨드 | Entrypoint | command |
|
||||
| 커맨드에 전달되는 인자들 | Cmd | arg |
|
||||
|
||||
기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다.
|
||||
|
||||
* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에
|
||||
제공되는 기본 값들이 사용된다.
|
||||
|
||||
* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면,
|
||||
제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본
|
||||
Cmd 값은 덮어쓰여진다.
|
||||
|
||||
* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint
|
||||
값이 정의한 `args` 값들과 함께 실행된다.
|
||||
|
||||
* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본
|
||||
EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께
|
||||
실행된다.
|
||||
|
||||
여기 몇 가지 예시들이 있다.
|
||||
|
||||
| 이미지 Entrypoint | 이미지 Cmd | 컨테이너 command | 컨테이너 args | 실행되는 커맨드 |
|
||||
|--------------------|------------------|---------------------|--------------------|------------------|
|
||||
| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | <설정되지 않음> | `[ep-1 foo bar]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <설정되지 않음> | `[ep-2]` |
|
||||
| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | `[zoo boo]` | `[ep-1 zoo boo]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다.
|
||||
* [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
|
||||
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ index.php는 CPU 과부하 연산을 수행한다.
|
||||
첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다.
|
||||
|
||||
```shell
|
||||
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
|
||||
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80
|
||||
```
|
||||
```
|
||||
service/php-apache created
|
||||
|
||||
@@ -18,17 +18,19 @@ card:
|
||||
{{< tabs name="minikube_before_you_begin" >}}
|
||||
{{% tab name="리눅스" %}}
|
||||
리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다.
|
||||
```shell
|
||||
egrep --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
grep -E --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="맥OS" %}}
|
||||
맥OS에서 가상화 지원 여부를 확인하려면, 아래 명령어를 터미널에서 실행한다.
|
||||
```
|
||||
sysctl -a | grep machdep.cpu.features
|
||||
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
|
||||
```
|
||||
만약 출력 중에 `VMX`를 볼 수 있다면 VT-x 기능을 운영체제에서 지원한다.
|
||||
만약 출력 중에 (색상으로 강조된) `VMX`를 볼 수 있다면, VT-x 기능이 머신에서 활성화된 것이다.
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="윈도우" %}}
|
||||
윈도우 8 이후 버전에서 가상화 지원 여부를 확인하려면, 다음 명령어를 윈도우 터미널이나 명령 프롬프트에서 실행한다.
|
||||
```
|
||||
@@ -73,7 +75,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경을 필요로 한다.
|
||||
Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다.
|
||||
{{< /note >}}
|
||||
|
||||
### 패키지를 이용하여 Minikube 설치
|
||||
@@ -158,14 +160,14 @@ Hyper-V는 다음 세 버전의 윈도우 10에서 실행할 수 있다. Windows
|
||||
윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다(관리자 권한으로 실행).
|
||||
|
||||
```shell
|
||||
choco install minikube kubernetes-cli
|
||||
choco install minikube
|
||||
```
|
||||
|
||||
Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube 실행 파일의 경로는 실행 경로(path)에 자동으로 추가된다.
|
||||
|
||||
### 인스톨러 실행파일을 통한 Minikube 설치
|
||||
|
||||
윈도우에서 수동으로 [Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다.
|
||||
[윈도우 인스톨러](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 설치
|
||||
|
||||
|
||||
Reference in New Issue
Block a user