This PR is the third Korean l10n work for release-1.14. (#14185)
* Fixed the ko-typo (#13983) * ko: Update outdated files in dev-1.14-ko.3 (#14055) * Translate concepts/overview/working-with-objects/annotations in Korean (#14115) Co-authored-by: Chirag Shah <programmergeekynerd9696@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Claudia J. Kang <claudiajkang@gmail.com> Co-authored-by: uncle-elephant <48449695+uncle-elephant@users.noreply.github.com> Co-authored-by: Seokho <shsongist@gmail.com>pull/14233/head^2
Claudia J.Kang
Kubernetes Prow Robot
parent
df287989b2
commit
1054269082
|
|
@ -17,7 +17,7 @@ weight: 40
|
|||
|
||||
쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트로* 클러스터에 대해 사용자가 *바라는 상태를* 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다.
|
||||
|
||||
일단 바라는 상태를 설정하고 나면, *쿠버네티스 컨트롤 플레인이* 클러스터의 현재 상태를 바라는 상태와 일치시키기 위한 일을 하게 된다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작 시키거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행할 수 있게 된다. 쿠버네티스 컨트롤 플레인은 클러스터에서 돌아가는 프로세스의 집합으로 구성된다.
|
||||
일단 바라는 상태를 설정하고 나면, *쿠버네티스 컨트롤 플레인*이 Pod Lifecycle Event Generator (PLEG) 를 사용하여 클러스터의 현재 상태를 바라는 상태와 일치시키기 위한 일을 하게 된다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작 시키거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행할 수 있게 된다. 쿠버네티스 컨트롤 플레인은 클러스터에서 돌아가는 프로세스의 집합으로 구성된다.
|
||||
|
||||
* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 집합이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다.
|
||||
* 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다.
|
||||
|
|
@ -47,7 +47,7 @@ weight: 40
|
|||
|
||||
쿠버네티스 마스터와 kubelet 프로세스와 같은 쿠버네티스 컨트롤 플레인의 다양한 구성 요소는 쿠버네티스가 클러스터와 통신하는 방식을 관장한다. 컨트롤 플레인은 시스템 내 모든 쿠버네티스 오브젝트의 레코드를 유지하면서, 오브젝트의 상태를 관리하는 제어 루프를 지속적으로 구동시킨다. 컨트롤 플레인의 제어 루프는 클러스터 내 변경이 발생하면 언제라도 응답하고 시스템 내 모든 오브젝트의 실제 상태가 사용자가 바라는 상태와 일치시키기 위한 일을 한다.
|
||||
|
||||
예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트 오브젝트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다.
|
||||
예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다.
|
||||
|
||||
### 쿠버네티스 마스터
|
||||
|
||||
|
|
|
|||
|
|
@ -48,8 +48,6 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시
|
|||
* 라우트 컨트롤러
|
||||
* 서비스 컨트롤러
|
||||
|
||||
추가적으로, PersistentVolumeLabels 컨트롤러라 불리는 다른 컨트롤러를 작동시킨다. 이 컨트롤러는 GCP와 AWS 클라우드 내 생성된 PersistentVolumes 상에 영역과 지역 레이블을 설정하는 책임을 가진다.
|
||||
|
||||
{{< note >}}
|
||||
볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
|
||||
{{< /note >}}
|
||||
|
|
@ -69,7 +67,6 @@ CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급
|
|||
* 노드 컨트롤러
|
||||
* 라우트 컨트롤러
|
||||
* 서비스 컨트롤러
|
||||
* PersistentVolumeLabels 컨트롤러
|
||||
|
||||
#### 노드 컨트롤러
|
||||
|
||||
|
|
@ -86,15 +83,7 @@ CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급
|
|||
|
||||
#### 서비스 컨트롤러
|
||||
|
||||
서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB 또는 구글 LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다.
|
||||
|
||||
#### PersistentVolumeLabels 컨트롤러
|
||||
|
||||
PersistentVolumeLabels 컨트롤러는 AWS EBS/GCE PD 볼륨이 생성되는 시점에 레이블을 적용한다. 이로써 사용자가 수동으로 이들 볼륨에 레이블을 설정할 필요가 없어진다.
|
||||
|
||||
이들 볼륨은 오직 그것들이 속한 지역/영역 내에서만 동작되도록 제한되므로 파드 스케줄에 필수적이다. 이들 볼륨을 이용하는 모든 파드는 동일한 지역/영역 내에서 스케줄 되어야 한다.
|
||||
|
||||
PersistentVolumeLabels 컨트롤러는 특별하게 CCM을 위해 생성되었다. 즉, CCM이 생성되기 전에는 없었다. 쿠버네티스 API 서버의 PV에 레이블을 붙이는 로직(어드미션 컨트롤러였다)을 CCM에 옮겨서 그렇게 만들었다.
|
||||
서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucutre LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다.
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
|
|
@ -102,10 +91,6 @@ PersistentVolumeLabels 컨트롤러는 특별하게 CCM을 위해 생성되었
|
|||
|
||||
이 새로운 모델에서, kubelet은 클라우드 특유의 정보 없이 노드를 초기화 해준다. 그러나, kubelet은 새로 생성된 노드에 taint를 추가해서 CCM이 클라우드에 대한 정보를 가지고 노드를 초기화하기 전까지는 스케줄되지 않도록 한다. 그러고 나서 이 taint를 제거한다.
|
||||
|
||||
### 3. 쿠버네티스 API 서버
|
||||
|
||||
PersistentVolumeLabels 컨트롤러는 이전 섹션에서 기술한 바와 같이, 쿠버네티스 API 서버의 클라우드 종속적인 기능을 CCM으로 이전한다.
|
||||
|
||||
## 플러그인 메커니즘
|
||||
|
||||
클라우드 컨트롤러 매니저는 어떠한 클라우드에서든지 플러그 인 되어 구현될 수 있도록 Go 인터페이스를 이용한다. 구체적으로, [여기](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)에 정의된 CloudProvider 인터페이스를 이용한다.
|
||||
|
|
@ -156,17 +141,6 @@ v1/Service:
|
|||
- Patch
|
||||
- Update
|
||||
|
||||
### PersistentVolumeLabels 컨트롤러
|
||||
|
||||
PersistentVolumeLabels 컨트롤러는 PersistentVolume(PV) 생성 이벤트에 대해 귀기울이고 그것을 업데이트 한다. 이 컨트롤러는 PV를 get 하고 update 하기 위한 접근을 요한다.
|
||||
|
||||
v1/PersistentVolume:
|
||||
|
||||
- Get
|
||||
- List
|
||||
- Watch
|
||||
- Update
|
||||
|
||||
### 그 외의 것들
|
||||
|
||||
CCM의 코어에 대한 구현은 이벤트를 create 하고, 보안 작업을 보장하기 위한 접근을 요하며, ServiceAccount를 create 하기 위한 접근을 요한다.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ card:
|
|||
Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처
|
||||
제공자 간 이식이 가능하게 해준다.
|
||||
|
||||
## 어떻게 쿠버네티스가 플랫폼이 될 수 있는가?
|
||||
## 어떻게 쿠버네티스가 플랫폼인가
|
||||
|
||||
쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는
|
||||
새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록
|
||||
|
|
@ -101,7 +101,7 @@ PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로
|
|||
A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이
|
||||
보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
|
||||
|
||||
## 왜 컨테이너인가?
|
||||
## 왜 컨테이너인가
|
||||
|
||||
왜 컨테이너를 써야하는지 이유를 알고 싶은가?
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
|
|||
* **지원 사용량**:
|
||||
고효율 고집적.
|
||||
|
||||
## 쿠버네티스(Kubernetes)의 뜻은? K8s?
|
||||
## 쿠버네티스의 뜻은? K8s?
|
||||
|
||||
**쿠버네티스**는 *키잡이* 나 *파일럿* 을 뜻하는 그리스어에서 유래했으며,
|
||||
이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의
|
||||
|
|
|
|||
|
|
@ -0,0 +1,76 @@
|
|||
---
|
||||
title: 어노테이션
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를
|
||||
오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## 오브젝트에 메타데이터 첨부
|
||||
|
||||
레이블이나 어노테이션을 사용하여 쿠버네티스
|
||||
오브젝트에 메타데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트
|
||||
컬렉션을 찾을 수 있다. 반면에, 어노테이션은
|
||||
오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타데이터는
|
||||
작거나 크고, 구조적이거나 구조적이지 않을 수 있으며, 레이블에서
|
||||
허용되지 않는 문자를 포함할 수 있다.
|
||||
|
||||
어노테이션은 레이블과 같이 키/값 맵이다.
|
||||
|
||||
```json
|
||||
"metadata": {
|
||||
"annotations": {
|
||||
"key1" : "value1",
|
||||
"key2" : "value2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
|
||||
|
||||
* 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은
|
||||
클라이언트 또는 서버가 설정한 기본 값,
|
||||
자동 생성된 필드, 그리고
|
||||
오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.
|
||||
|
||||
* 빌드, 릴리스, 또는 타임 스탬프, 릴리즈 ID, git 브랜치,
|
||||
PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.
|
||||
|
||||
* 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.
|
||||
|
||||
* 디버깅 목적으로 사용될 수 있는 클라이언트 라이브러리 또는 도구 정보:
|
||||
예를 들면, 이름, 버전, 그리고 빌드 정보.
|
||||
|
||||
* 다른 생태계 구성 요소의 관련 오브젝트 URL과 같은
|
||||
사용자 또는 도구/시스템 출처 정보.
|
||||
|
||||
* 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
|
||||
|
||||
* 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
|
||||
해당 정보를 찾을 수 있는 디렉토리 진입점.
|
||||
|
||||
* 행동을 수정하거나 비표준 기능을 수행하기 위한
|
||||
최종 사용자의 지시 사항.
|
||||
|
||||
어노테이션을 사용하는 대신, 이 유형의 정보를
|
||||
외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
|
||||
공유 클라이언트 라이브러리와 도구 생성을
|
||||
훨씬 더 어렵게 만들 수 있다.
|
||||
|
||||
## 문법과 캐릭터 셋
|
||||
|
||||
_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 하위 도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
|
||||
|
||||
접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :`kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.
|
||||
|
||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
|
||||
{{% /capture %}}
|
||||
|
|
@ -20,13 +20,13 @@ card:
|
|||
* 그 애플리케이션이 이용할 수 있는 리소스
|
||||
* 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
|
||||
|
||||
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 **의도한 상태** 가 된다.
|
||||
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
|
||||
|
||||
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [Kubernetes API](/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [Client Libraries](/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
|
||||
|
||||
### 오브젝트 스펙(spec)과 상태(status)
|
||||
|
||||
모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 *의도한 상태* 를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
|
||||
모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 의도한 상태를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
|
||||
|
||||
|
||||
예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해 줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 (상태 변경에) 실패가 난다면, 쿠버네티스 시스템은 보정을 통해, 이 경우에는 인스턴스 대체를 착수하여, spec과 status 간의 차이에 대응한다.
|
||||
|
|
@ -61,9 +61,10 @@ deployment.apps/nginx-deployment created
|
|||
|
||||
* `apiVersion` - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
|
||||
* `kind` - 어떤 종류의 오브젝트를 생성하고자 하는지
|
||||
* `metadata` - `이름` 문자열, UID, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
|
||||
* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
|
||||
|
||||
여러분은 또한 오브젝트 `spec` 필드를 제공해야만 할 것이다. 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. 예를 들어, `파드` 오브젝트에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 확인할 수 있고, `디플로이먼트` 오브젝트에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
|
||||
여러분은 또한 오브젝트 `spec` 필드를 제공해야만 할 것이다. 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
|
||||
예를 들어, `파드`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,8 @@ weight: 30
|
|||
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
|
||||
|
||||
다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근
|
||||
제어 정책을 갖게 된다.
|
||||
제어 정책을 갖게 된다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스
|
||||
리소스는 하나의 네임스페이스에만 있을 수 있다.
|
||||
|
||||
같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
|
||||
복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
|
||||
|
|
|
|||
|
|
@ -37,8 +37,6 @@ weight: 30
|
|||
`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다.
|
||||
`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
|
||||
`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다.
|
||||
`Completed` | 완료된 잡(Job)과 같이 다 실행되어서 더 작동하고 있을 필요 없이 완료된 상태가 되었다.
|
||||
`CrashLoopBackOff` | 파드 내 컨테이너 중 하나가 예상과는 달리 종료(exit)되었고, [restart policy](#restart-policy)에 따라 재시작된 뒤에도 0이 아닌 에러 코드가 발생했을 것이다.
|
||||
|
||||
## 파드의 조건(condition)
|
||||
|
||||
|
|
|
|||
|
|
@ -271,11 +271,14 @@ kubectl -n my-ns delete po,svc --all # 초
|
|||
|
||||
```bash
|
||||
kubectl logs my-pod # 파드 로그(stdout) 덤프
|
||||
kubectl logs -l name=myLabel # name이 myLabel인 파드 로그 덤프 (stdout)
|
||||
kubectl logs my-pod --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout) 덤프
|
||||
kubectl logs my-pod -c my-container # 파드 로그(stdout, 멀티-컨테이너 경우) 덤프
|
||||
kubectl logs -l name=myLabel -c my-container # name이 myLabel인 파드 로그 덤프 (stdout)
|
||||
kubectl logs my-pod -c my-container --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout, 멀티-컨테이너 경우) 덤프
|
||||
kubectl logs -f my-pod # 실시간 스트림 파드 로그(stdout)
|
||||
kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
|
||||
kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행
|
||||
kubectl attach my-pod -i # 실행중인 컨테이너에 연결
|
||||
kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달
|
||||
|
|
|
|||
|
|
@ -51,6 +51,14 @@ Control group은 프로세스에 할당된 리소스를 제한하는데 사용
|
|||
컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면
|
||||
시스템이 안정화된다. 아래의 Docker 설정에서 `native.cgroupdriver=systemd` 옵션을 확인하라.
|
||||
|
||||
{{< caution >}}
|
||||
클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 권장하지 않는다.
|
||||
하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면,
|
||||
컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 PodSandBox를 재생성을 시도할 때, 에러가 발생할 수 있다.
|
||||
kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
|
||||
추천하는 방법은 워크로드에서 노드를 제거하고, 클러스터에서 제거한 다음 다시 결합시키는 것이다.
|
||||
{{< /caution >}}
|
||||
|
||||
## Docker
|
||||
|
||||
각 머신들에 대해서, Docker를 설치한다.
|
||||
|
|
|
|||
|
|
@ -51,6 +51,8 @@ card:
|
|||
|
||||
### 생태계 도구
|
||||
|
||||
* [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local)는 LXD 컨테이너가 존재하는 로컬호스트에서 9개 인스턴스 디플로이먼트를 지원한다.
|
||||
|
||||
* [Docker Desktop](https://www.docker.com/products/docker-desktop)는
|
||||
Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다.
|
||||
수 분 내에 단일 노드 쿠버네티스 클러스터에서 컨테이너로 코딩과 배포를
|
||||
|
|
@ -64,7 +66,9 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
|||
|
||||
* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)는 Terraform/Packer/BASH 기반의 리눅스 호스트 상의 LXD 클러스터에 7개의 노드(부트 1개, 마스터 1개, 관리 1개, 프록시 1개 그리고 워커 3개)를 생성하기 위한 Infrastructure as Code (IaC) 스크립트이다.
|
||||
|
||||
* [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local)는 로컬 호스트에서 9개의 인스턴스 배포를 지원한다.
|
||||
* [k3s](https://k3s.io)는 경량의 생산-등급 쿠버네티스 베포판이다. 간단한 설치 과정과 40MB의 바이너리 footprint로, 로컬-머신 개발에 이상적이다.
|
||||
|
||||
* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/)는 로컬호스트에서 9개 인스턴스 디플로이먼트를 지원한다.
|
||||
|
||||
## 호스트 된 솔루션
|
||||
|
||||
|
|
@ -108,7 +112,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
|||
|
||||
* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/)는 자체 OpenStack 퍼블릭 클라우드 상에서 서비스로써 관리형 쿠버네티스를 제공한다. 라이프사이클 관리, 관리 대시보드, 모니터링, 오토스케일링과 그 밖에 많은 기능을 포함한다.
|
||||
|
||||
* [VEXXHOST](https://vexxhost.com/public-cloud/container-services/kubernetes/) VEXXHOST는 공공 클라우드에서 공인된 쿠버네티스를 제공하며, 캐나다에서 가장 큰 OpenStack 퍼블릭 클라우드이다.
|
||||
* [VEXXHOST](https://vexxhost.com/public-cloud/container-services/kubernetes/) VEXXHOST는 VEXXHOST의 공공 클라우드에서 공인된 쿠버네티스를 제공하며, 캐나다에서 가장 큰 OpenStack 퍼블릭 클라우드이다.
|
||||
|
||||
* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)는 사용하기 쉽고, 기본적으로 안전하며, 비용 효율적인 SaaS 기반의 쿠버네티스 클러스터를 제공하는 VMWare 클라우드 서비스 포트폴리오의 엔터프라이즈 Kubernetes-as-a-Service 오퍼링이다.
|
||||
|
||||
|
|
@ -129,6 +133,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
|||
* [Giant Swarm](https://giantswarm.io)
|
||||
* [Google Compute Engine (GCE)](/docs/setup/turnkey/gce/)
|
||||
* [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer)
|
||||
* [k3s](https://k3s.io)
|
||||
* [Kontena Pharos](https://kontena.io/pharos/)
|
||||
* [Kubermatic](https://cloud.kubermatic.io)
|
||||
* [Kublr](https://kublr.com/)
|
||||
|
|
@ -138,7 +143,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
|||
* [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm)
|
||||
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
|
||||
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/)
|
||||
* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [Rancher](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [Stackpoint.io](/docs/setup/turnkey/stackpoint/)
|
||||
* [Supergiant.io](https://supergiant.io/)
|
||||
* [VEXXHOST](https://vexxhost.com/private-cloud/)
|
||||
|
|
@ -154,16 +159,17 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
|||
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
|
||||
* [Giant Swarm](https://giantswarm.io)
|
||||
* [GKE On-Prem | Google Cloud](https://cloud.google.com/gke-on-prem/)
|
||||
* [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/)
|
||||
* [IBM Cloud Private](https://www.ibm.com/cloud/private)
|
||||
* [k3s](https://k3s.io)
|
||||
* [Kontena Pharos](https://kontena.io/pharos/)
|
||||
* [Kubermatic](https://www.loodse.com)
|
||||
* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution)
|
||||
* [Kublr](https://kublr.com/)
|
||||
* [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)
|
||||
* [Nirmata](https://nirmata.com/)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com)
|
||||
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
|
||||
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/)
|
||||
* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [Rancher](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [SUSE CaaS Platform](https://www.suse.com/products/caas-platform)
|
||||
* [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/)
|
||||
* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)
|
||||
|
|
@ -185,7 +191,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
|||
|
||||
* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
|
||||
* [Gardener](https://gardener.cloud/)
|
||||
* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution)
|
||||
* [Kublr](https://kublr.com/)
|
||||
* [Kubernetes on Ubuntu](https://www.ubuntu.com/kubernetes/docs/quickstart)
|
||||
* [Kubespray](/docs/setup/custom-cloud/kubespray/)
|
||||
* [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke)
|
||||
|
|
@ -210,6 +216,8 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
|||
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
|
||||
* [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/)
|
||||
* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)
|
||||
* [k3s](https://k3s.io)
|
||||
* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
|
||||
* [Kubernetes on Ubuntu](https://www.ubuntu.com/kubernetes/docs/quickstart)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
|
||||
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/) works on any infrastructure: on-premises, bare metal, or private/hybrid cloud.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,8 @@ deployment.apps/php-apache created
|
|||
|
||||
## Horizontal Pod Autoscaler 생성
|
||||
|
||||
이제 서비스가 동작중이므로, [kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_autoscale.md)를 사용하여 오토스케일러를 생성한다. 다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
|
||||
이제 서비스가 동작중이므로, [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를
|
||||
사용하여 오토스케일러를 생성한다. 다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
|
||||
간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. ([kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)으로 각 파드는 200 밀리코어까지 요청할 수 있고, 따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.) 이에 대한 자세한 알고리즘은 [여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)를 참고하기 바란다.
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
|
|||
|
||||
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는
|
||||
구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
|
||||
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization-window` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
|
||||
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
|
||||
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
|
||||
영향을 완만하게 한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -86,9 +86,10 @@ sudo cp minikube /usr/local/bin && rm minikube
|
|||
```
|
||||
|
||||
### Windows
|
||||
or [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v). Hyper-V can be run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education. See the official Minikube GitHub repository for additional [installation information](https://github.com/kubernetes/minikube/#installation).
|
||||
|
||||
{{< note >}}
|
||||
Minikube를 Windows에서 실행하려면, 우선 [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)를 설치할 필요가 있다. Hyper-V는 Windows 10 Enterprise, Windows 10 Professional 과 Windows 10 Education 세 버전의 Windows 10에서 동작한다.
|
||||
Minikube를 Windows에서 실행하려면, 우선 첫번째로 [VirtualBox](https://www.virtualbox.org/) 또는 [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)를 설치할 필요가 있다. Hyper-V는 Windows 10 Enterprise, Windows 10 Professional 과 Windows 10 Education 세 버전의 Windows 10에서 동작한다.
|
||||
{{< /note >}}
|
||||
|
||||
Windows에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다. (관리자 권한으로 실행)
|
||||
|
|
|
|||
|
|
@ -13,7 +13,9 @@ content_template: templates/concept
|
|||
|
||||
* [Certified Kubernetes Administrator 준비 과정 (Linux Academy)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course)
|
||||
|
||||
* [Certified Kubernetes Application Developer 준비 과정 및 모의 시험 (KodeKloud.com)](https://kodekloud.com/p/kubernetes-certification-course)
|
||||
* [Certified Kubernetes Administrator Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
|
||||
|
||||
* [Certified Kubernetes Application Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
|
||||
|
||||
* [Google Kubernetes Engine 시작하기 (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
|
||||
|
||||
|
|
@ -21,7 +23,7 @@ content_template: templates/concept
|
|||
|
||||
* [쿠버네티스 시작하기 (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)
|
||||
|
||||
* [Getting Started with Kubernetes Clusters on OCI Oracle Kubernetes Engine (OKE) (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
|
||||
* [OCI Oracle Kubernetes Engine (OKE)에서 쿠버네티스 클러스터 시작하기 (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
|
||||
|
||||
* [쿠버네티스 소개 및 실습 (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
|
||||
|
||||
|
|
@ -31,7 +33,7 @@ content_template: templates/concept
|
|||
|
||||
* [Kubernetes Essentials (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
|
||||
|
||||
* [초보자를 위한 쿠버네티스 실습 랩 (KodeKloud.com)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
|
||||
* [초보자를 위한 쿠버네티스 실습 랩 (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
|
||||
|
||||
* [Kubernetes Quick Start (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
|
||||
|
||||
|
|
@ -39,7 +41,7 @@ content_template: templates/concept
|
|||
|
||||
* [대화식 실습 시나리오를 사용하여 쿠버네티스 배우기 (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
|
||||
|
||||
* [Monitoring Kubernetes With Prometheus (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
|
||||
* [Prometheus로 쿠버네티스 모니터링 (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
|
||||
|
||||
* [쿠버네티스와 확장 가능한 마이크로서비스(Microservices) (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 40
|
|||
이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org)
|
||||
쿠버네티스에서 [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과
|
||||
[파드디스룹선버짓(PodDisruptionBudget)](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과
|
||||
[파드안티어피피니티(PodAntiAffinity)](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
|
||||
[파드안티어피니티(PodAntiAffinity)](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
|
|
|||
|
|
@ -66,8 +66,8 @@ weight: 10
|
|||
|
||||
결과는 아래와 같은 형태로 나타난다.
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-service ClusterIP 10.3.245.137 104.198.205.71 8080/TCP 54s
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s
|
||||
|
||||
참고: 만약 외부 IP 주소가 \<pending\>으로 표시되면 잠시 기다린 다음, 동일한 명령어를 다시 입력한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ spec:
|
|||
replicas: 3
|
||||
updateStrategy:
|
||||
type: RollingUpdate
|
||||
podManagementPolicy: Parallel
|
||||
podManagementPolicy: OrderedReady
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
|
|
|
|||
Loading…
Reference in New Issue