Ko: Second Korean l10n work for release-1.20
- Update outdated files in the dev-1.20-ko.2(p1) (#25915) - Update outdated files in the dev-1.20-ko.2(p2) (#25916) - Fix issue with links to already translated ko documents (#25991) - Translate reference/glossary/dynamic-volume-provisioning.md in Korean (#26047) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: santachopa <santachopa@naver.com>pull/26089/head
seokho-son
parent
85933681d0
commit
bfd90bff5f
|
|
@ -2,44 +2,44 @@
|
|||
https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
|
||||
## CNCF 커뮤니티 행동 강령 v1.0
|
||||
|
||||
### 참여자 행동 강령
|
||||
### 기여자 행동 강령
|
||||
|
||||
본 프로젝트의 기여자 및 유지 관리자로서, 환영하는 분위기의 공개 커뮤니티를
|
||||
육성하기 위하여, 저희는 이슈를 보고하고, 기술 요청을 작성하며, 문서를 업데이트하며,
|
||||
pull 요청 또는 패치를 제출하고, 다른 활동에 참여하는
|
||||
모든 분들을 존중하겠다고 약속드립니다.
|
||||
본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의
|
||||
커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트,
|
||||
풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는
|
||||
모든 분들을 존중할 것을 약속합니다.
|
||||
|
||||
저희는 경험 수준, 성별, 성 정체성과 표현, 성적 지향,
|
||||
장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, 또는
|
||||
국적에 상관 없이 모두가 괴롭힘 없는 환경에서
|
||||
본 프로젝트에 참여하도록 최선을 다하고 있습니다.
|
||||
우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression),
|
||||
성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교,
|
||||
또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에
|
||||
참여할 수 있도록 최선을 다하고 있습니다.
|
||||
|
||||
참여자에게 금지하는 행동의 예는 다음과 같습니다.:
|
||||
참여자에게 금지하는 행위의 예시는 다음과 같습니다.
|
||||
|
||||
* 성적 언어 또는 이미지 사용
|
||||
* 개인적인 공격
|
||||
* 시비 걸기 또는 모욕/경멸적인 코멘트
|
||||
* 공적 및 사적 괴롭힘
|
||||
* 분명한 허락을 받지 않은 타인의 사적 정보 출판,
|
||||
예를 들어 물리적 또는 전자 주소
|
||||
* 다른 비윤리적 또는 비전문적인 행동
|
||||
- 성적인 언어 또는 이미지 사용
|
||||
- 인신 공격
|
||||
- 도발적이거나 모욕/경멸적인 코멘트
|
||||
- 공개적이거나 사적인 괴롭힘
|
||||
- 타인의 주소 및 전자주소와 같은 개인 정보의
|
||||
동의 없는 공개
|
||||
- 기타 비윤리적이거나 비전문적인 행동
|
||||
|
||||
프로젝트 유지 관리자는 본 행동 강령을 위반하는 코멘트, 협약, 강령,
|
||||
위키 수정, 이슈와 다른 참여자를 제거, 수정, 삭제할 권한과
|
||||
책임을 가집니다. 본 행동 강령을 적용하여, 프로젝트 유지 관리자는 본
|
||||
프로젝트를 유지하는 모든 상황에 공정하고 일관적으로 이러한 원칙들을
|
||||
적용하기 위해 헌신해야 합니다. 프로젝트 유지 관리자는
|
||||
행동 강령이 프로젝트 팀에서 영구적으로 사라지도록 하거나 강요해서는 안됩니다.
|
||||
프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit),
|
||||
코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정,
|
||||
거부할 수 있는 권한과 책임이 있습니다. 프로젝트 메인테이너는 프로젝트 관리의
|
||||
모든 관점에서 이러한 행동 강령 원칙을 공정하고 일관되게 적용할 것을 약속해야 합니다.
|
||||
행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서
|
||||
영구적으로 제적될 수 있습니다.
|
||||
|
||||
본 행동 강령은 프로젝트 공간과 개인이 프로젝트 또는
|
||||
그 커뮤니티를 대표하는 공적 공간에 모두 적용됩니다.
|
||||
본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트
|
||||
또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다.
|
||||
|
||||
Kubernetes에서의 폭력, 학대 또는 기타 허용되지 않는 행동 사례는 이메일 주소 <conduct@kubernetes.io>를 통해 [Kubernetes 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)로 신고하실 수 있습니다. 다른 프로젝트는 CNCF 프로젝트 관리자 또는 저희 중재자인 Mishi Choudhary에게 이메일 <mishi@linux.com>으로 연락하십시오.
|
||||
쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 <mishi@linux.com>으로 문의해 주시기 바랍니다.
|
||||
|
||||
본 행동강령은 참여자 Contributor Covenant (http://contributor-covenant.org)의
|
||||
버전 1.2.0을 적용하였으며,
|
||||
해당 내용은 여기 http://contributor-covenant.org/version/1/2/0/에서 확인할 수 있습니다.
|
||||
본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서
|
||||
제공하는 버전 1.2.0을 적용하였으며, 해당 내용은
|
||||
https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다.
|
||||
|
||||
### CNCF 커뮤니티 행동 강령
|
||||
### CNCF 이벤트 행동 강령
|
||||
|
||||
CNCF 이벤트는 리눅스 재단의 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/) 을 따르며, 해당 내용은 이벤트 페이지에서 확인할 수 있습니다. 본 강령은 위 정책과 호환할 수 있도록 설계되었으며, 또한 사건에 따라 더 많은 세부 내용을 포함합니다.
|
||||
CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다.
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
|
|||
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
|
||||
사용한다.
|
||||
|
||||
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다.
|
||||
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다.
|
||||
|
||||
### API 서버에서 노드, 파드 및 서비스로의 통신
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ no_list: true
|
|||
### kubelet 보안
|
||||
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
|
||||
* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
|
||||
|
||||
## 선택적 클러스터 서비스
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
|
||||
title: kubelet 가비지(Garbage) 수집 설정하기
|
||||
content_type: concept
|
||||
weight: 70
|
||||
|
|
@ -6,7 +7,7 @@ weight: 70
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
|
||||
가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
|
||||
|
||||
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다.
|
||||
|
||||
|
|
@ -20,7 +21,7 @@ weight: 70
|
|||
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
|
||||
라이프사이클을 관리한다.
|
||||
|
||||
이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
|
||||
이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
|
||||
`HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는
|
||||
디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
|
||||
이미지들을 삭제한다.
|
||||
|
|
|
|||
|
|
@ -1,18 +1,19 @@
|
|||
---
|
||||
title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
|
||||
|
||||
|
||||
|
||||
|
||||
content_type: concept
|
||||
weight: 60
|
||||
aliases:
|
||||
- controller-metrics.md
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
|
||||
|
||||
쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다.
|
||||
|
||||
|
||||
쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
|
||||
이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -49,18 +50,20 @@ rules:
|
|||
|
||||
## 메트릭 라이프사이클
|
||||
|
||||
알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제
|
||||
알파(Alpha) 메트릭 → 안정적인(Stable) 메트릭 → 사용 중단된(Deprecated) 메트릭 → 히든(Hidden) 메트릭 → 삭제된(Deleted) 메트릭
|
||||
|
||||
알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다.
|
||||
|
||||
안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다.
|
||||
안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다.
|
||||
* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다.
|
||||
* 안정적인 메트릭의 유형(type)은 수정되지 않는다.
|
||||
|
||||
* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다
|
||||
* 메트릭 유형은 수정되지 않는다
|
||||
사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다.
|
||||
이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다.
|
||||
|
||||
사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다.
|
||||
예를 들면,
|
||||
|
||||
사용 중단되기 전에는 아래와 같다.
|
||||
* 사용 중단 이전에는 다음과 같다.
|
||||
|
||||
```
|
||||
# HELP some_counter this counts things
|
||||
|
|
@ -68,7 +71,7 @@ rules:
|
|||
some_counter 0
|
||||
```
|
||||
|
||||
사용 중단된 이후에는 아래와 같다.
|
||||
* 사용 중단 이후에는 다음과 같다.
|
||||
|
||||
```
|
||||
# HELP some_counter (Deprecated since 1.15.0) this counts things
|
||||
|
|
@ -76,9 +79,9 @@ some_counter 0
|
|||
some_counter 0
|
||||
```
|
||||
|
||||
메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다.
|
||||
히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다.
|
||||
|
||||
메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다.
|
||||
삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다.
|
||||
|
||||
|
||||
## 히든 메트릭 표시
|
||||
|
|
@ -128,6 +131,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
|||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
|
||||
### kube-scheduler 메트릭
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
|
|
|
|||
|
|
@ -225,7 +225,6 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
|
|||
그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
|
||||
캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
|
||||
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
|
||||
|
||||
컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
|
||||
모든 요청을 리디렉션할 수 있다.
|
||||
따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의
|
||||
|
|
@ -262,12 +261,10 @@ data:
|
|||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
|
||||
`data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만
|
||||
삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
|
||||
유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -349,7 +349,7 @@ data:
|
|||
|
||||
부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다.
|
||||
|
||||
- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
|
||||
- `token-id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
|
||||
- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
|
||||
- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
|
||||
문자열. 선택 사항.
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ card:
|
|||
최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할
|
||||
수 있도록 HTTP API를 제공한다.
|
||||
|
||||
쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
|
||||
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.
|
||||
쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
|
||||
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
|
||||
|
||||
대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
|
||||
커맨드 라인 인터페이스 또는 API를 사용하는
|
||||
|
|
|
|||
|
|
@ -58,14 +58,14 @@ metadata:
|
|||
|
||||
## 애플리케이션과 애플리케이션 인스턴스
|
||||
|
||||
애플리케이션은 동일한 쿠버네티스 클러스터에,
|
||||
애플리케이션은 동일한 쿠버네티스 클러스터에,
|
||||
심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
|
||||
워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
|
||||
WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
|
||||
|
||||
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
|
||||
예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
|
||||
애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
|
||||
`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
|
||||
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
|
||||
예를 들어 WordPress는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
|
||||
애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
|
||||
`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
|
||||
식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
|
||||
|
||||
## 예시
|
||||
|
|
@ -169,4 +169,3 @@ metadata:
|
|||
```
|
||||
|
||||
MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 파드 시큐리티 폴리시
|
||||
content_type: concept
|
||||
weight: 30
|
||||
|
|
@ -213,12 +216,17 @@ kubectl-user create -f- <<EOF
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pause
|
||||
name: pause
|
||||
spec:
|
||||
containers:
|
||||
- name: pause
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause
|
||||
EOF
|
||||
```
|
||||
|
||||
이것의 출력은 다음과 같을 것이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
|
||||
```
|
||||
|
||||
|
|
@ -261,12 +269,17 @@ kubectl-user create -f- <<EOF
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pause
|
||||
name: pause
|
||||
spec:
|
||||
containers:
|
||||
- name: pause
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause
|
||||
EOF
|
||||
```
|
||||
|
||||
이것의 출력은 다음과 같을 것이다.
|
||||
|
||||
```
|
||||
pod "pause" created
|
||||
```
|
||||
|
||||
|
|
@ -278,14 +291,19 @@ kubectl-user create -f- <<EOF
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: privileged
|
||||
name: privileged
|
||||
spec:
|
||||
containers:
|
||||
- name: pause
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause
|
||||
securityContext:
|
||||
privileged: true
|
||||
EOF
|
||||
```
|
||||
|
||||
이것의 출력은 다음과 같을 것이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -186,7 +186,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
|||
| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
|
||||
| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
|
||||
| `NotBestEffort` | 서비스 품질이 나쁜 파드 |
|
||||
| `PriorityClass` | 지정된 [프라이올리티 클래스](/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
|
||||
| `PriorityClass` | 지정된 [프라이올리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
|
||||
|
||||
`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -77,8 +77,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
|
|||
스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지
|
||||
방법이 있다.
|
||||
|
||||
1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
|
||||
1. [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
|
||||
1. [스케줄링 정책](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
|
||||
1. [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -420,5 +420,5 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
|
|||
|
||||
|
||||
* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
|
||||
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
|
||||
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/ko/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
|
||||
* [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
|
||||
|
|
|
|||
|
|
@ -8,50 +8,73 @@ no_list: true
|
|||
|
||||
{{< glossary_definition term_id="workload" length="short" >}}
|
||||
워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의
|
||||
[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
|
||||
쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
|
||||
[_파드_](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
|
||||
쿠버네티스에서 `Pod` 는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
|
||||
집합을 나타낸다.
|
||||
|
||||
파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고
|
||||
해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서
|
||||
심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
|
||||
최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다.
|
||||
쿠버네티스 파드에는 [정의된 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)이 있다.
|
||||
예를 들어, 일단 파드가 클러스터에서 실행되고 나서
|
||||
해당 파드가 동작 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에
|
||||
심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
|
||||
최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 `Pod` 를 새로 생성해야 한다.
|
||||
|
||||
그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다.
|
||||
그러나, 작업이 훨씬 쉽도록, 각 `Pod` 를 직접 관리할 필요는 없도록 만들었다.
|
||||
대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다.
|
||||
이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이
|
||||
실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를
|
||||
구성한다.
|
||||
|
||||
이러한 워크로드 리소스에는 다음이 포함된다.
|
||||
쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다.
|
||||
|
||||
* [디플로이먼트(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/cron-jobs/)
|
||||
* [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 및 [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)
|
||||
(레거시 리소스
|
||||
{{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체).
|
||||
`Deployment` 는 `Deployment` 의 모든 `Pod` 가 필요 시 교체 또는 상호 교체 가능한 경우,
|
||||
클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.
|
||||
* [`StatefulSet`](/ko/docs/concepts/workloads/controllers/statefulset/)는
|
||||
어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가
|
||||
데이터를 지속적으로 기록하는 경우, 사용자는 `Pod` 와
|
||||
[`PersistentVolume`](/ko/docs/concepts/storage/persistent-volumes/)을 연계하는 `StatefulSet` 을 실행할 수 있다.
|
||||
전체적인 회복력 향상을 위해서, `StatefulSet` 의 `Pods` 에서 동작 중인 코드는 동일한 `StatefulSet` 의
|
||||
다른 `Pods` 로 데이터를 복제할 수 있다.
|
||||
* [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)은 노드-로컬 기능(node-local facilities)을 제공하는 `Pods` 를 정의한다.
|
||||
이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다.
|
||||
예를 들면, 네트워킹 지원 도구 또는
|
||||
{{< glossary_tooltip text="add-on" term_id="addons" >}} 등이 있다.
|
||||
`DaemonSet` 의 명세에 맞는 노드를 클러스터에 추가할 때마다,
|
||||
컨트롤 플레인은 해당 신규 노드에 `DaemonSet` 을 위한 `Pod` 를 스케줄한다.
|
||||
* [`Job`](/ko/docs/concepts/workloads/controllers/job/) 및
|
||||
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)은
|
||||
실행 완료 후 중단되는 작업을 정의한다. `CronJobs` 이 스케줄에 따라 반복되는 반면,
|
||||
잡은 단 한 번의 작업을 나타낸다.
|
||||
|
||||
관련성을 찾을 수 있는 두 가지 지원 개념도 있다.
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
제거된 후 클러스터에서 오브젝트를 정리한다.
|
||||
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
|
||||
완료된 이후 정의된 시간이 경과되면 잡을 제거한다.
|
||||
더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드
|
||||
리소스도 찾을 수 있다.
|
||||
[커스텀 리소스 데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)을 사용하면,
|
||||
쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를
|
||||
추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 `Pods` 의 그룹을 실행하되
|
||||
_모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은),
|
||||
사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
|
||||
|
||||
* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
* [`Deployment` 를 사용하여 스테이트리스(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/)
|
||||
* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
|
||||
|
||||
코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는,
|
||||
[구성](/ko/docs/concepts/configuration/)을 참고하길 바란다.
|
||||
|
||||
다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는
|
||||
두 가지 개념이다.
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
제거된 후 클러스터에서 오브젝트를 정리한다.
|
||||
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는
|
||||
잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.
|
||||
|
||||
일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로
|
||||
사용하거나, 웹 애플리케이션의 경우에만
|
||||
[인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다.
|
||||
|
||||
[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의
|
||||
메커니즘에 대해 알아볼 수도 있다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,8 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
title: 크론잡
|
||||
content_type: concept
|
||||
weight: 80
|
||||
|
|
@ -45,6 +49,36 @@ kube-controller-manager 컨테이너에 설정된 시간대는
|
|||
([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는
|
||||
이 예시를 더 자세히 설명한다.)
|
||||
|
||||
### 크론 스케줄 문법
|
||||
|
||||
```
|
||||
# ┌───────────── 분 (0 - 59)
|
||||
# │ ┌───────────── 시 (0 - 23)
|
||||
# │ │ ┌───────────── 일 (1 - 31)
|
||||
# │ │ │ ┌───────────── 월 (1 - 12)
|
||||
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
|
||||
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
|
||||
# │ │ │ │ │
|
||||
# │ │ │ │ │
|
||||
# * * * * *
|
||||
```
|
||||
|
||||
|
||||
| 항목 | 설명 | 상응 표현 |
|
||||
| ------------- | ------------- |------------- |
|
||||
| @yearly (or @annually) | 매년 1월 1일 자정에 실행 | 0 0 1 1 * |
|
||||
| @monthly | 매월 1일 자정에 실행 | 0 0 1 * * |
|
||||
| @weekly | 매주 일요일 자정에 실행 | 0 0 * * 0 |
|
||||
| @daily (or @midnight) | 매일 자정에 실행 | 0 0 * * * |
|
||||
| @hourly | 매시 0분에 시작 | 0 * * * * |
|
||||
|
||||
|
||||
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
|
||||
|
||||
`0 0 13 * 5`
|
||||
|
||||
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
|
||||
|
||||
## 크론잡의 한계 {#cron-job-limitations}
|
||||
|
||||
크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 잡
|
||||
content_type: concept
|
||||
feature:
|
||||
|
|
@ -35,6 +38,7 @@ weight: 50
|
|||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
|
||||
```
|
||||
출력 결과는 다음과 같다.
|
||||
```
|
||||
job.batch/pi created
|
||||
```
|
||||
|
|
@ -44,6 +48,7 @@ job.batch/pi created
|
|||
```shell
|
||||
kubectl describe jobs/pi
|
||||
```
|
||||
출력 결과는 다음과 같다.
|
||||
```
|
||||
Name: pi
|
||||
Namespace: default
|
||||
|
|
@ -88,6 +93,7 @@ Events:
|
|||
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
|
||||
echo $pods
|
||||
```
|
||||
출력 결과는 다음과 같다.
|
||||
```
|
||||
pi-5rwd7
|
||||
```
|
||||
|
|
@ -100,7 +106,7 @@ pi-5rwd7
|
|||
```shell
|
||||
kubectl logs $pods
|
||||
```
|
||||
다음과 유사하게 출력된다.
|
||||
출력 결과는 다음과 같다.
|
||||
```shell
|
||||
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
|
||||
```
|
||||
|
|
@ -395,10 +401,11 @@ spec:
|
|||
잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_.
|
||||
삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl get job old -o yaml
|
||||
```
|
||||
```
|
||||
출력 결과는 다음과 같다.
|
||||
```yaml
|
||||
kind: Job
|
||||
metadata:
|
||||
name: old
|
||||
|
|
@ -417,7 +424,7 @@ spec:
|
|||
시스템이 일반적으로 자동 생성하는 셀렉터를 사용하지 않도록 하기 위해
|
||||
새 잡에서 `manualSelector: true` 를 지정해야 한다.
|
||||
|
||||
```
|
||||
```yaml
|
||||
kind: Job
|
||||
metadata:
|
||||
name: new
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: 파드
|
||||
content_type: concept
|
||||
weight: 10
|
||||
|
|
@ -189,6 +191,34 @@ spec:
|
|||
시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을
|
||||
확장할 수 있게 한다.
|
||||
|
||||
## 파드 갱신 및 교체
|
||||
|
||||
이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드
|
||||
템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신
|
||||
갱신된 템플릿을 기반으로 신규 파드를 생성한다.
|
||||
|
||||
쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다.
|
||||
동작 중인 파드의 필드를 갱신하는 것도 가능하다.
|
||||
그러나,
|
||||
[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 및
|
||||
[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)와 같은
|
||||
파드 갱신 작업에는 다음과 같은 제약이 있다.
|
||||
|
||||
- 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는
|
||||
`namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다.
|
||||
그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는
|
||||
갱신만 허용한다.
|
||||
- `metadata.deletionTimestamp` 가 설정된 경우,
|
||||
`metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다.
|
||||
- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`,
|
||||
`spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는
|
||||
변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다.
|
||||
- `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만
|
||||
허용한다.
|
||||
|
||||
1. 지정되지 않은 필드를 양수로 설정;
|
||||
1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신.
|
||||
|
||||
## 리소스 공유와 통신
|
||||
|
||||
파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: 초기화 컨테이너
|
||||
content_type: concept
|
||||
weight: 40
|
||||
|
|
@ -47,9 +49,9 @@ weight: 40
|
|||
또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다.
|
||||
왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
|
||||
|
||||
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을
|
||||
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을
|
||||
한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다.
|
||||
모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을
|
||||
모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을
|
||||
초기화하고 평소와 같이 실행한다.
|
||||
|
||||
## 초기화 컨테이너 사용하기
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ graph TB
|
|||
|
||||
API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다.
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
|
@ -290,7 +290,7 @@ graph BT
|
|||
- `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
|
||||
- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
|
||||
|
||||
기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서
|
||||
기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서
|
||||
`PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
|
||||
제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
|
||||
제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
|
||||
|
|
@ -315,7 +315,7 @@ profiles:
|
|||
|
||||
{{< note >}}
|
||||
기본 스케줄링 제약 조건에 의해 생성된 점수는
|
||||
[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에
|
||||
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에
|
||||
의해 생성된 점수와 충돌 할 수 있다.
|
||||
`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
|
||||
이 플러그인을 비활성화 하는 것을 권장한다.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: 레퍼런스
|
||||
|
||||
|
||||
linkTitle: "레퍼런스"
|
||||
main_menu: true
|
||||
weight: 70
|
||||
|
|
@ -16,7 +18,7 @@ content_type: concept
|
|||
|
||||
## API 레퍼런스
|
||||
|
||||
* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
|
||||
* [쿠버네티스 API 레퍼런스 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
|
||||
|
||||
## API 클라이언트 라이브러리
|
||||
|
|
@ -33,7 +35,7 @@ content_type: concept
|
|||
## CLI 레퍼런스
|
||||
|
||||
* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
|
||||
* [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
|
||||
* [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
|
||||
* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
|
||||
|
||||
## 컴포넌트 레퍼런스
|
||||
|
|
|
|||
|
|
@ -419,10 +419,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
|
||||
참고한다.
|
||||
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
|
||||
마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
|
||||
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
|
||||
마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
|
||||
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
|
||||
`kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
|
||||
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
|
||||
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
|
||||
확인한다.
|
||||
- `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다.
|
||||
-`CronJobControllerV2` : {{< glossary_tooltip text="크론잡" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
|
||||
|
|
@ -508,7 +508,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
[엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
|
||||
- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
|
||||
- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
|
||||
-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown)을 참조한다.
|
||||
-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을 참조한다.
|
||||
- `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다.
|
||||
- `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다.
|
||||
- `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다.
|
||||
|
|
@ -582,7 +582,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
- `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다.
|
||||
자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다.
|
||||
- `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다.
|
||||
- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다.
|
||||
- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다.
|
||||
- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다.
|
||||
자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
|
||||
- `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: 동적 볼륨 프로비저닝(Dynamic Volume Provisioning)
|
||||
id: dynamicvolumeprovisioning
|
||||
date: 2018-04-12
|
||||
full_link: /ko/docs/concepts/storage/dynamic-provisioning
|
||||
short_description: >
|
||||
사용자가 스토리지 볼륨의 자동 생성을 요청할 수 있게 해준다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- storage
|
||||
---
|
||||
사용자가 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의 자동 생성을 요청할 수 있게 해준다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
동적 프로비저닝은 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없다. 대신 사용자 요청에 따라 자동으로 스토리지를 프로비저닝한다. 동적 볼륨 프로비저닝은 API 오브젝트인 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 기반으로 한다. 이 스토리지클래스는 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 및 {{< glossary_tooltip text="볼륨 플러그인" term_id="volume-plugin" >}}에 전달할 파라미터 세트를 프로비저닝하는 볼륨 플러그인을 참조한다.
|
||||
|
||||
|
|
@ -18,10 +18,10 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는
|
||||
[kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)는
|
||||
노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크
|
||||
세션이나 클러스터 바깥에서 파드로 네트워크 통신을
|
||||
할 수 있도록 해준다.
|
||||
|
||||
kube-proxy는 운영 체제에 가용한 패킷
|
||||
kube-proxy는 운영 체제에 가용한 패킷
|
||||
필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
|
||||
|
|
|
|||
|
|
@ -356,8 +356,8 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든
|
|||
`-o=custom-columns=<명세>` | 쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블 출력
|
||||
`-o=custom-columns-file=<파일명>` | `<파일명>`파일에서 사용자 정의 열 템플릿을 사용하여 테이블 출력
|
||||
`-o=json` | JSON 형식의 API 오브젝트 출력
|
||||
`-o=jsonpath=<템플릿>` | [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
|
||||
`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
|
||||
`-o=jsonpath=<템플릿>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
|
||||
`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
|
||||
`-o=name` | 리소스 명만 출력하고 그 외에는 출력하지 않음
|
||||
`-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함
|
||||
`-o=yaml` | YAML 형식의 API 오브젝트 출력
|
||||
|
|
@ -395,10 +395,10 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자.
|
||||
* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자.
|
||||
|
||||
* [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다.
|
||||
* [kubectl](/ko/docs/reference/kubectl/kubectl/) 옵션을 참고한다.
|
||||
|
||||
* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다.
|
||||
* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/ko/docs/reference/kubectl/conventions/)을 참고한다.
|
||||
|
||||
* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다.
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
|
||||
`wait` | <code>kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다.
|
||||
|
||||
명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
|
||||
명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
|
||||
|
||||
## 리소스 타입
|
||||
|
||||
|
|
@ -188,7 +188,7 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
|
||||
## 출력 옵션
|
||||
|
||||
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
|
||||
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
|
||||
|
||||
### 출력 서식화
|
||||
|
||||
|
|
@ -207,8 +207,8 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
|
|||
`-o custom-columns=<spec>` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다.
|
||||
`-o custom-columns-file=<filename>` | `<filename>` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다.
|
||||
`-o json` | JSON 형식의 API 오브젝트를 출력한다.
|
||||
`-o jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
|
||||
`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
|
||||
`-o jsonpath=<template>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
|
||||
`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
|
||||
`-o name` | 리소스 이름만 출력한다.
|
||||
`-o wide` | 추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다.
|
||||
`-o yaml` | YAML 형식의 API 오브젝트를 출력한다.
|
||||
|
|
@ -222,7 +222,7 @@ kubectl get pod web-pod-13je7 -o yaml
|
|||
```
|
||||
|
||||
기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
|
||||
[kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
|
||||
[kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
|
||||
|
||||
#### 사용자 정의 열 {#custom-columns}
|
||||
|
||||
|
|
@ -282,7 +282,7 @@ pod-name 1m
|
|||
|
||||
### 오브젝트 목록 정렬
|
||||
|
||||
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
|
||||
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
|
||||
|
||||
#### 구문
|
||||
|
||||
|
|
|
|||
|
|
@ -73,6 +73,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
|
|||
| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
|
||||
| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
|
||||
| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
|
||||
| Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) |
|
||||
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
|
||||
| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
|
||||
| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 컨테이너 런타임
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -122,6 +125,24 @@ sudo mkdir -p /etc/containerd
|
|||
sudo containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Ubuntu 18.04/20.04" %}}
|
||||
|
||||
```shell
|
||||
# (containerd 설치)
|
||||
sudo apt-get update && sudo apt-get install -y containerd
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 구성
|
||||
sudo mkdir -p /etc/containerd
|
||||
sudo containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# containerd 재시작
|
||||
sudo systemctl restart containerd
|
||||
|
|
@ -167,7 +188,6 @@ cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.
|
|||
cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz
|
||||
```
|
||||
|
||||
```shell
|
||||
```powershell
|
||||
# 추출 및 구성
|
||||
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
|
||||
|
|
@ -262,6 +282,7 @@ curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/
|
|||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Ubuntu" %}}
|
||||
|
|
@ -361,11 +382,14 @@ sudo systemctl start crio
|
|||
자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를
|
||||
참고한다.
|
||||
|
||||
|
||||
|
||||
### 도커
|
||||
|
||||
각 노드에 도커 CE를 설치한다.
|
||||
|
||||
쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는 도커 버전을 찾을 수 있다.
|
||||
쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는
|
||||
도커 버전을 찾을 수 있다.
|
||||
|
||||
사용자의 시스템에서 다음의 명령을 이용해 도커를 설치한다.
|
||||
|
||||
|
|
@ -388,7 +412,7 @@ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring
|
|||
```shell
|
||||
# 도커 apt 리포지터리 추가:
|
||||
sudo add-apt-repository \
|
||||
deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@ weight: 100
|
|||
|
||||
kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
|
||||
해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
|
||||
통해 kubelet에 구성된 [스태틱(static) 파드](/docs/tasks/configure-pod-container/static-pod/)
|
||||
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/docs/concepts/workloads/controllers/daemonset/)
|
||||
통해 kubelet에 구성된 [스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)
|
||||
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/ko/docs/concepts/workloads/controllers/daemonset/)
|
||||
로 실행된다.
|
||||
|
||||
자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
|
||||
|
|
@ -32,7 +32,7 @@ kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플
|
|||
_컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._
|
||||
|
||||
1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는
|
||||
[`hostPath`](/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
|
||||
[`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
|
||||
자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해
|
||||
관리되지 않는다.
|
||||
|
||||
|
|
@ -63,5 +63,3 @@ kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플
|
|||
|
||||
1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
|
||||
리스닝 포트에 바인딩하여 활성화할 수 있다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
|
|||
* Flatcar Container Linux by Kinvolk
|
||||
* 지속적인 통합 (CI) 테스트
|
||||
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ upgrade-cluster 플레이북을 실행해 클러스터를 업그레이드 할
|
|||
|
||||
[reset 플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml)을 이용하여 노드들을 리셋하고 Kubespray로 설치된 모든 구성요소를 삭제할 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
{{< caution >}}
|
||||
reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타겟으로 삼지 않도록 해야 한다!
|
||||
{{< /caution >}}
|
||||
|
||||
|
|
@ -116,4 +116,3 @@ reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타
|
|||
|
||||
|
||||
Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ weight: 65
|
|||
지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 [윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다.
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다.
|
||||
모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/ko/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다.
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
윈도우 서버 호스트 운영 체제에는 [윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) 라이선스가 적용된다. 윈도우 컨테이너 이미지에는 [윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다.
|
||||
|
|
@ -527,7 +527,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
|
|||
|
||||
1. 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다.
|
||||
|
||||
이 문제는 `hostname-override` 파라미터가 [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.
|
||||
이 문제는 `hostname-override` 파라미터가 [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.
|
||||
|
||||
```powershell
|
||||
C:\k\kube-proxy.exe --hostname-override=$(hostname)
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ card:
|
|||
|
||||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
|
||||
`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
|
||||
[마이너 버전 하나 차이 이내](/docs/setup/release/version-skew-policy/#kubectl)여야
|
||||
[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
|
||||
한다.
|
||||
|
||||
|
||||
|
|
@ -383,7 +383,3 @@ export KUBECONFIG=$KUBECONFIG_SAVED
|
|||
|
||||
* [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -125,6 +125,7 @@ min-kubernetes-server-version: v1.10
|
|||
|
||||
1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
|
||||
|
||||
|
||||
```shell
|
||||
# redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
|
||||
kubectl port-forward redis-master-765d459796-258hz 7000:6379
|
||||
|
|
@ -157,10 +158,16 @@ min-kubernetes-server-version: v1.10
|
|||
위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
|
||||
|
||||
```
|
||||
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
|
||||
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
|
||||
Forwarding from 127.0.0.1:7000 -> 6379
|
||||
Forwarding from [::1]:7000 -> 6379
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
`kubectl port-forward` 는 프롬프트를 리턴하지 않으므로, 이 연습을 계속하려면 다른 터미널을 열어야 한다.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
2. Redis 커맨드라인 인터페이스를 실행한다.
|
||||
|
||||
```shell
|
||||
|
|
@ -179,7 +186,23 @@ min-kubernetes-server-version: v1.10
|
|||
PONG
|
||||
```
|
||||
|
||||
### 선택적으로 _kubectl_ 이 로컬 포트를 선택하게 하기 {#let-kubectl-choose-local-port}
|
||||
|
||||
만약 특정 로컬 포트가 필요하지 않다면, `kubectl` 이 로컬 포트를 선택 및 할당하게 하여,
|
||||
조금 더 단순한 문법으로 로컬 포트 충돌 관리를 위한
|
||||
부담을 줄일 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl port-forward deployment/redis-master :6379
|
||||
```
|
||||
|
||||
`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다. (낮은 포트 번호는
|
||||
다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서) 출력은 다음과 같을 것이다.
|
||||
|
||||
```
|
||||
Forwarding from 127.0.0.1:62162 -> 6379
|
||||
Forwarding from [::1]:62162 -> 6379
|
||||
```
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
|
@ -193,8 +216,7 @@ min-kubernetes-server-version: v1.10
|
|||
{{< note >}}
|
||||
`kubectl port-forward` 는 TCP 포트에서만 구현된다.
|
||||
UDP 프로토콜에 대한 지원은
|
||||
[이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)
|
||||
에서 추적되고 있다.
|
||||
[이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)에서 추적되고 있다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한
|
|||
|
||||
일부 클러스터에서, API 서버는 인증이 필요하지 않다.
|
||||
로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
|
||||
없다. [쿠버네티스 API에 대한 접근 제어](/docs/concepts/security/controlling-access)은
|
||||
없다. [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)은
|
||||
클러스터 관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
|
||||
고 가용성 지원과 충돌할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: kubeadm 클러스터 업그레이드
|
||||
content_type: task
|
||||
weight: 20
|
||||
|
|
@ -229,6 +231,14 @@ sudo systemctl restart kubelet
|
|||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### "kubeadm upgrade" 호출
|
||||
|
||||
- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.
|
||||
|
||||
```shell
|
||||
sudo kubeadm upgrade node
|
||||
```
|
||||
|
||||
### 노드 드레인
|
||||
|
||||
- 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다.
|
||||
|
|
@ -238,14 +248,6 @@ sudo systemctl restart kubelet
|
|||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
|
||||
### kubeadm 업그레이드 호출
|
||||
|
||||
- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.
|
||||
|
||||
```shell
|
||||
sudo kubeadm upgrade node
|
||||
```
|
||||
|
||||
### kubelet과 kubectl 업그레이드
|
||||
|
||||
- kubelet 및 kubectl을 업그레이드한다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: 파드와 레플리케이션컨트롤러(ReplicationController) 디버그하기
|
||||
content_type: task
|
||||
---
|
||||
|
|
@ -48,7 +50,7 @@ kubectl describe pods ${POD_NAME}
|
|||
* 클러스터에 노드를 더 추가하기.
|
||||
|
||||
* pending 상태인 파드를 위한 공간을 확보하기 위해
|
||||
[불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination)
|
||||
[불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
|
||||
|
||||
* 파드가 노드보다 크지 않은지 확인한다. 예를 들어 모든
|
||||
노드가 `cpu:1` 의 용량을 가지고 있을 경우, `cpu: 1.1` 을 요청하는 파드는
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ content_type: task
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
이 가이드는 [kubectl](/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는
|
||||
이 가이드는 [kubectl](/ko/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는
|
||||
플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 `kubectl` 을 확장하고, 주요 배포판에 포함되지 않은 `kubectl` 의 새로운 사용자 정의 기능을 허용한다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: HugePages 관리
|
||||
content_type: task
|
||||
description: 클러스터에서 huge page를 스케줄할 수 있는 리소스로 구성하고 관리한다.
|
||||
|
|
@ -102,17 +104,18 @@ spec:
|
|||
|
||||
- Huge page 요청(requests)은 제한(limits)과 같아야 한다. 제한이 지정되었지만, 요청은 지정되지 않은 경우
|
||||
이것이 기본값이다.
|
||||
- Huge page는 컨테이너 범위에서 격리되므로, 각 컨테이너에는 컨테이너 사양에서 요청한대로 cgroup 샌드박스에 대한 제한이 있다.
|
||||
- Huge page는 컨테이너 범위에서 격리되므로, 각 컨테이너에는 컨테이너 사양에서 요청한대로
|
||||
cgroup 샌드박스에 대한 제한이 있다.
|
||||
- Huge page가 지원하는 EmptyDir 볼륨은 파드 요청보다 더 많은 huge page 메모리를
|
||||
사용하지 말아야 한다.
|
||||
- `shmget()` 의 `SHM_HUGETLB` 를 통해 huge page를 사용하는 애플리케이션은
|
||||
`proc/sys/vm/hugetlb_shm_group` 과 일치하는 보충 그룹(supplemental group)으로 실행해야 한다.
|
||||
- 네임스페이스에서의 huge page 사용은 `hugepages-<size>` 토큰을 사용하는 `cpu` 또는 `memory` 와 같은
|
||||
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
|
||||
있다.
|
||||
- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다. {{<
|
||||
glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{<
|
||||
glossary_tooltip text="kube-apiserver"
|
||||
term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
|
||||
`HugePageStorageMediumSize` [기능
|
||||
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 비활성화할 수 있다.
|
||||
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
|
||||
있다.
|
||||
- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다.
|
||||
{{<glossary_tooltip text="kubelet" term_id="kubelet" >}} 및
|
||||
{{<glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}
|
||||
(`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
사용하여 비활성화할 수 있다.
|
||||
|
|
|
|||
|
|
@ -47,8 +47,7 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다.
|
|||
|
||||
### 리소스 생성
|
||||
|
||||
컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다.
|
||||
컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
|
||||
컨피그 맵과 시크릿은 파드와 같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
|
||||
Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다.
|
||||
|
||||
#### configMapGenerator
|
||||
|
|
@ -591,7 +590,7 @@ spec:
|
|||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
command: ["start", "--host", "\$(MY_SERVICE_NAME)"]
|
||||
command: ["start", "--host", "$(MY_SERVICE_NAME)"]
|
||||
EOF
|
||||
|
||||
# service.yaml 파일 생성
|
||||
|
|
@ -655,10 +654,10 @@ spec:
|
|||
|
||||
## Base와 Overlay
|
||||
|
||||
Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는
|
||||
Kustomize는 **base** 와 **overlay** 의 개념을 가지고 있다. **base** 는 `kustomization.yaml` 과 함께 사용되는 디렉터리다. 이는
|
||||
사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가
|
||||
될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로
|
||||
다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
|
||||
될 수 있다. **overlay** 는 `kustomization.yaml`이 있는 디렉터리로
|
||||
다른 kustomization 디렉터리들을 `bases`로 참조한다. **base** 는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
|
||||
한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며,
|
||||
이들의 위에 사용자 정의도 가질 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ card:
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/reference/kubectl/kubectl/)을 사용하면,
|
||||
쿠버네티스 커맨드 라인 도구인 [kubectl](/ko/docs/reference/kubectl/kubectl/)을 사용하면,
|
||||
쿠버네티스 클러스터에 대해 명령을 실행할 수 있다.
|
||||
kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며
|
||||
로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는,
|
||||
|
|
@ -526,4 +526,4 @@ compinit
|
|||
* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
* 직접 생성하지 않은 클러스터에 접근해야하는 경우,
|
||||
[클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
|
||||
* [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기
|
||||
* [kubectl 레퍼런스 문서](/ko/docs/reference/kubectl/kubectl/) 읽기
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ weight: 10
|
|||
* [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/)
|
||||
* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
|
||||
* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [kubectl](/docs/reference/kubectl/kubectl/) 커맨드 라인 도구
|
||||
* [kubectl](/ko/docs/reference/kubectl/kubectl/) 커맨드 라인 도구
|
||||
|
||||
{{< note >}}
|
||||
이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ weight: 40
|
|||
- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
|
||||
- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
|
||||
- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
|
||||
- [kubectl CLI](/docs/reference/kubectl/kubectl/)
|
||||
- [kubectl CLI](/ko/docs/reference/kubectl/kubectl/)
|
||||
|
||||
최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,78 +9,73 @@ weight: 10
|
|||
이 페이지에서는 외부 IP 주소를 노출하는
|
||||
쿠버네티스 서비스 오브젝트를 생성하는 방법에 대해 설명한다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
|
||||
|
||||
* Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여
|
||||
쿠버네티스 클러스터를 생성한다.
|
||||
이 튜토리얼은 [외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데,
|
||||
클라우드 공급자가 필요하다.
|
||||
|
||||
쿠버네티스 클러스터를 생성한다. 이 튜토리얼은
|
||||
[외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데,
|
||||
클라우드 공급자가 필요하다.
|
||||
* `kubectl`이 쿠버네티스 API 서버와 통신하도록 설정한다.
|
||||
자세한 내용은 클라우드 공급자의 설명을 참고한다.
|
||||
|
||||
|
||||
|
||||
자세한 내용은 클라우드 공급자의 설명을 참고한다.
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* Hello World 애플리케이션을 다섯 개의 인스턴스로 실행한다.
|
||||
* 외부 IP 주소를 노출하는 서비스를 생성한다.
|
||||
* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## 다섯 개의 파드에서 실행되는 애플리케이션에 대한 서비스 만들기
|
||||
|
||||
1. 클러스터에서 Hello World 애플리케이션을 실행한다.
|
||||
|
||||
{{< codenew file="service/load-balancer-example.yaml" >}}
|
||||
{{< codenew file="service/load-balancer-example.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
||||
```
|
||||
|
||||
|
||||
위의 명령어는
|
||||
{{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
|
||||
오브젝트와 관련된
|
||||
{{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}
|
||||
오브젝트를 생성한다. 레플리카셋은 다섯 개의
|
||||
{{< glossary_tooltip text="파드" term_id="pod" >}}가 있으며,
|
||||
각 파드는 Hello World 애플리케이션을 실행한다.
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
||||
```
|
||||
위의 명령어는
|
||||
{{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
|
||||
오브젝트와 관련된
|
||||
{{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}
|
||||
오브젝트를 생성한다. 레플리카셋은 다섯 개의
|
||||
{{< glossary_tooltip text="파드" term_id="pod" >}}가 있으며,
|
||||
각 파드는 Hello World 애플리케이션을 실행한다.
|
||||
|
||||
1. 디플로이먼트에 대한 정보를 확인한다.
|
||||
|
||||
kubectl get deployments hello-world
|
||||
kubectl describe deployments hello-world
|
||||
```shell
|
||||
kubectl get deployments hello-world
|
||||
kubectl describe deployments hello-world
|
||||
```
|
||||
|
||||
1. 레플리카셋 오브젝트에 대한 정보를 확인한다.
|
||||
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
```shell
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
```
|
||||
|
||||
1. 디플로이먼트를 외부로 노출시키는 서비스 오브젝트를 생성한다.
|
||||
|
||||
kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
|
||||
```shell
|
||||
kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
|
||||
```
|
||||
|
||||
1. 서비스에 대한 정보를 확인한다.
|
||||
|
||||
kubectl get services my-service
|
||||
```shell
|
||||
kubectl get services my-service
|
||||
```
|
||||
|
||||
결과는 아래와 같은 형태로 나타난다.
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s
|
||||
```console
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
|
|
@ -96,23 +91,27 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
|||
|
||||
1. 서비스에 대한 자세한 정보를 확인한다.
|
||||
|
||||
kubectl describe services my-service
|
||||
```shell
|
||||
kubectl describe services my-service
|
||||
```
|
||||
|
||||
결과는 아래와 같은 형태로 나타난다.
|
||||
출력 결과는 다음과 유사하다.
|
||||
|
||||
Name: my-service
|
||||
Namespace: default
|
||||
Labels: app.kubernetes.io/name=load-balancer-example
|
||||
Annotations: <none>
|
||||
Selector: app.kubernetes.io/name=load-balancer-example
|
||||
Type: LoadBalancer
|
||||
IP: 10.3.245.137
|
||||
LoadBalancer Ingress: 104.198.205.71
|
||||
Port: <unset> 8080/TCP
|
||||
NodePort: <unset> 32377/TCP
|
||||
Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```console
|
||||
Name: my-service
|
||||
Namespace: default
|
||||
Labels: app.kubernetes.io/name=load-balancer-example
|
||||
Annotations: <none>
|
||||
Selector: app.kubernetes.io/name=load-balancer-example
|
||||
Type: LoadBalancer
|
||||
IP: 10.3.245.137
|
||||
LoadBalancer Ingress: 104.198.205.71
|
||||
Port: <unset> 8080/TCP
|
||||
NodePort: <unset> 32377/TCP
|
||||
Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
서비스에 의해 노출된 외부 IP 주소 (`LoadBalancer Ingress`)를 기억해두자.
|
||||
예시에서 외부 IP 주소는 104.198.205.71이다.
|
||||
|
|
@ -124,21 +123,27 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
|||
이 주소는 Hello World 애플리케이션을 실행 중인 파드의 내부 주소다.
|
||||
해당 주소가 파드 주소인지 확인하려면, 아래 명령어를 입력하면 된다.
|
||||
|
||||
kubectl get pods --output=wide
|
||||
```shell
|
||||
kubectl get pods --output=wide
|
||||
```
|
||||
|
||||
결과는 아래와 같은 형태로 나타난다.
|
||||
출력 결과는 다음과 유사하다.
|
||||
|
||||
NAME ... IP NODE
|
||||
hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc
|
||||
hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc
|
||||
hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a
|
||||
hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc
|
||||
hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc
|
||||
```console
|
||||
NAME ... IP NODE
|
||||
hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc
|
||||
hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc
|
||||
hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a
|
||||
hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc
|
||||
hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc
|
||||
```
|
||||
|
||||
1. Hello World 애플리케이션에 접근하기 위해
|
||||
외부 IP 주소 (`LoadBalancer Ingress`)를 사용한다.
|
||||
|
||||
curl http://<external-ip>:<port>
|
||||
```shell
|
||||
curl http://<external-ip>:<port>
|
||||
```
|
||||
|
||||
`<external-ip>`는 서비스의 외부 IP 주소 (`LoadBalancer Ingress`)를 의미하며,
|
||||
`<port>`는 서비스 정보에서 `Port` 값을
|
||||
|
|
@ -148,28 +153,26 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
|||
|
||||
성공적인 요청에 대한 응답으로 hello 메세지가 나타난다.
|
||||
|
||||
Hello Kubernetes!
|
||||
|
||||
|
||||
|
||||
```shell
|
||||
Hello Kubernetes!
|
||||
```
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
||||
서비스를 삭제하려면, 아래의 명령어를 입력한다.
|
||||
|
||||
kubectl delete services my-service
|
||||
```shell
|
||||
kubectl delete services my-service
|
||||
```
|
||||
|
||||
Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하려면,
|
||||
아래의 명령어를 입력한다.
|
||||
|
||||
kubectl delete deployment hello-world
|
||||
|
||||
|
||||
|
||||
```shell
|
||||
kubectl delete deployment hello-world
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[애플리케이션과 서비스 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해
|
||||
더 배워 본다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue