whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sixth Korean l10n work for release 1.18

Browse Source 
- Update outdated files in dev-1.18-ko.6 partly (#21714)
- Translate StorageClass to Korean word (#21805)
- Translate StatefulSet to Korean word in pods.md (#21794)
- Translate tasks/run-application/delete-stateful-set/ in Korean (#21686)
- Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801)
- update outdated docs (#21940)
- Modify spacing term StatefulSet in Korean (#21871)
- Translate /tasks/administer-cluster/coredns in Korean (#21876)
- Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975)
- Translation error correction in /concepts/containers/runtime-class.md (#21868)
- Translate tasks/tls/certificate-rotation/ in Korean (#21838)
- Translate /tasks/configure-pod-container/static-pod in Korean (#21798)
- Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911)
- Fix English bugs in Korean documentation (#21994)
- Update outdated dev-1.18-ko.6 partly (#22067)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: PyungHo Yoon <learder@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
Co-authored-by: Dajin Gwon <d.gweon@samsung.com>
Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com>
Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr>
Co-authored-by: coolguyhong <podolsmith@naver.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
2020-06-14 01:11:06 +09:00
parent a78456d87c
commit 34be3c1d39
133 changed files with 2074 additions and 1226 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/_index.md
+1 -1
View File
@@ -59,7 +59,7 @@ content_type: concept
## 스테이트풀 애플리케이션 관리하기
스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다.
스테이트풀셋(StatefulSet)의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다.
## 클러스터 데몬
content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+1 -1
View File
@@ -6,7 +6,7 @@ weight: 110
<!-- overview -->
이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지
이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지
살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자.
content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+46 -41
View File
@@ -10,14 +10,14 @@ card:
<!-- overview -->
이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록
설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의
구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를
이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록
설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의
구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를
사용하여 클러스터를 빠르게 변경할 수 있다.
{{< note >}}
클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고
불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이
클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고
불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이
반드시 존재해야 한다는 것을 의미하는 것은 아니다.
{{< /note >}}
@@ -26,7 +26,12 @@ card:
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< include "task-tutorial-prereqs.md" >}}
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
한다.
@@ -34,14 +39,14 @@ card:
## 클러스터, 사용자, 컨텍스트 정의
당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자.
`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서
작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다.
`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조
네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자.
`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서
작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다.
`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조
네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다.
`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에
`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에
다음 내용을 가진 `config-demo`라는 파일을 생성한다.
```shell
@@ -68,10 +73,10 @@ contexts:
name: exp-scratch
```
구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과
구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과
두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다.
`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
세부사항들을 추가한다.
```shell
@@ -100,7 +105,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
```
`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는
`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는
것 대신에 `config view` 커맨드를 사용할 수도 있다.
```shell
@@ -150,16 +155,16 @@ users:
username: exp
```
위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한
플레이스홀더(placeholder)이다.
위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한
플레이스홀더(placeholder)이다.
당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다.
만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면
이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`,
만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면
이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`,
`client-certificate-data`, `client-key-data` 같이 사용할 수 있다.
컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어
`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데
컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어
`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데
`developer` 사용자 자격증명을 사용하라고 알려준다."
현재 컨텍스트를 설정한다.
@@ -168,11 +173,11 @@ users:
kubectl config --kubeconfig=config-demo use-context dev-frontend
```
이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와
네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된
이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와
네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된
사용자 자격증명을 사용할 것이다.
현재 컨텍스트에 관련된 구성 정보만을 보려면
현재 컨텍스트에 관련된 구성 정보만을 보려면
`--minify` 플래그를 사용한다.
```shell
@@ -212,8 +217,8 @@ users:
kubectl config --kubeconfig=config-demo use-context exp-scratch
```
이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의
default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된
이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의
default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된
사용자의 자격증명을 사용할 것이다.
현재의 컨텍스트인 `exp-scratch`에 관련된 설정을 보자.
@@ -222,7 +227,7 @@ default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열
kubectl config --kubeconfig=config-demo view --minify
```
마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서
마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서
잠시 작업을 하려고 한다고 가정해보자.
현재 컨텍스트를 `dev-storage`로 변경한다.
@@ -259,7 +264,7 @@ contexts:
## KUBECONFIG 환경 변수 설정
`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면,
`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면,
이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다.
예:
@@ -271,9 +276,9 @@ export KUBECONFIG_SAVED=$KUBECONFIG
```shell
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
```
`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다.
`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다.
`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
익숙해지길 바란다.
다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.
@@ -293,9 +298,9 @@ $Env:KUBECONFIG=("config-demo;config-demo-2")
kubectl config view
```
당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로
표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up`
컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을
당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로
표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up`
컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을
가지고 있다는 것에 주목하길 바란다.
```shell
@@ -322,22 +327,22 @@ contexts:
name: exp-scratch
```
kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
[kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다.
## $HOME/.kube 디렉토리 탐색
만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여
해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는
만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여
해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는
파일을 가지고 있을 것이다.
`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자.
보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다.
`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자.
보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다.
간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다.
## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가
당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG`
당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG`
환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자.
예:
@@ -350,7 +355,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
```
이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
config-exercise 디렉토리에서 다음 커맨드를 실행한다.
```shell
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+16 -12
View File
@@ -61,7 +61,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
## 컨테이너화 된 애플리케이션 배포
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
@@ -69,7 +69,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
배포 마법사는 다음 정보를 제공한다.
- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다.
- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
@@ -79,17 +79,21 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다.
클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다.
{{< note >}}
외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다.
{{< /note >}}
서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다.
서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
예를 들면:
@@ -119,13 +123,13 @@ track=stable
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
### YAML 또는 JSON 파일 업로드
쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
## 대시보드 사용
다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
@@ -140,12 +144,12 @@ track=stable
클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
#### 워크로드
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
#### 서비스(Service)
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
#### 서비스
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
#### 스토리지
스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
@@ -163,7 +167,7 @@ track=stable
## {{% heading "whatsnext" %}}
더 많은 정보는
더 많은 정보는
[쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다.
content/ko/docs/tasks/administer-cluster/change-default-storage-class.md
+101
View File
@@ -0,0 +1,101 @@
---
title: 기본 스토리지클래스(StorageClass) 변경하기
content_type: task
---
<!-- overview -->
이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝
하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 왜 기본 스토리지 클래스를 변경하는가?
설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존
스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정
스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를
동적으로 프로비저닝 하기 위해 사용된다.
더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를
보자.
미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지
않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할
수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인
애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.
## 기본 스토리지클래스 변경하기
1. 사용자의 클러스터에 있는 스토리지클래스 목록을 조회한다.
```bash
kubectl get storageclass
```
결과는 아래와 유사하다.
```bash
NAME PROVISIONER AGE
standard (default) kubernetes.io/gce-pd 1d
gold kubernetes.io/gce-pd 1d
```
기본 스토리지클래스는 `(default)` 로 표시되어 있다.
1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다.
기본 스토리지클래스에는
`storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다.
다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다.
스토리지클래스를 기본값이 아닌 것으로 표시하려면, 그 값을 `false` 로 변경해야 한다.
```bash
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
```
여기서 `standard` 는 사용자가 선택한 스토리지클래스의 이름이다.
1. 스토리지클래스를 기본값으로 표시한다.
이전 과정과 유사하게, 어노테이션을 추가/설정 해야 한다.
`storageclass.kubernetes.io/is-default-class=true`.
```bash
kubectl patch storageclass gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
```
최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약
2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다.
1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다.
```bash
kubectl get storageclass
```
결과는 아래와 유사하다.
```bash
NAME PROVISIONER AGE
standard kubernetes.io/gce-pd 1d
gold (default) kubernetes.io/gce-pd 1d
```
## {{% heading "whatsnext" %}}
* [퍼시스턴트볼륨(PersistentVolume)](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기.
content/ko/docs/tasks/administer-cluster/coredns.md
+98
View File
@@ -0,0 +1,98 @@
---
title: 서비스 디스커버리를 위해 CoreDNS 사용하기
min-kubernetes-server-version: v1.9
content_type: task
---
<!-- overview -->
이 페이지는 CoreDNS 업그레이드 프로세스와 kube-dns 대신 CoreDNS를 설치하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## CoreDNS 소개
[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버이다.
쿠버네티스와 동일하게, CoreDNS 프로젝트도 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다.
사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는
kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다.
## CoreDNS 설치
Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트](https://github.com/coredns/deployment/tree/master/kubernetes)에
있는 문서를 확인하자.
## CoreDNS로 이관하기
### Kubeadm을 사용해 기존 클러스터 업그레이드하기
쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여
`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은
`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의
설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다.
예를 들어, `v1.11.0` 로 업그레이드 하는 경우는 다음과 같다.
```
kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
```
쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다.
업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에
설명된 지침 가이드를 참고하자.
1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**.
**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이
시작된 후에 변경 사항을 다시 적용해야 할 수도 있다.
만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서,
기존의 Corefile이 유지된다.
### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기
{{< note >}}
쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며,
기본적으로 설치된다.
{{< /note >}}
{{< warning >}}
쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다.
{{< /warning >}}
1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS`
값을 `false` 로 변경해야 한다.
```
kubeadm init --feature-gates=CoreDNS=false
```
1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자.
## CoreDNS 업그레이드하기
CoreDNS는 쿠버네티스 1.9 버전부터 사용할 수 있다.
쿠버네티스와 함께 제공되는 CoreDNS의 버전과 CoreDNS의 변경 사항은 [여기](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)에서 확인할 수 있다.
CoreDNS는 사용자 정의 이미지를 사용하거나 CoreDNS만 업그레이드 하려는 경우에 수동으로 업그레이드할 수 있다.
업그레이드를 원활하게 수행하는 데 유용한 [가이드라인 및 연습](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)을 참고하자.
## CoreDNS 튜닝하기
리소스 활용이 중요한 경우, CoreDNS 구성을 조정하는 것이 유용할 수 있다.
더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인하자.
## {{% heading "whatsnext" %}}
`Corefile` 을 수정하여 kube-dns 보다 더 많은 유스케이스를 지원하도록
[CoreDNS](https://coredns.io)를 구성할 수 있다.
더 자세한 내용은 [CoreDNS 웹사이트](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)을 확인하자.
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+4
View File
@@ -241,4 +241,8 @@ CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지
[cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca
[cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서
## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation}
Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다.
CA의 수동 순환이나 교체에 대한 보다 상세한 정보는 [CA 인증서 수동 순환](/docs/tasks/tls/manual-rotation-of-ca-certificates/) 문서를 참조한다.
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+2
View File
@@ -294,6 +294,7 @@ sudo kubeadm upgrade apply
kubelet을 다시 시작한다.
```shell
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
@@ -372,6 +373,7 @@ sudo systemctl restart kubelet
- kubelet을 다시 시작한다.
```shell
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
+2
View File
@@ -199,3 +199,5 @@ kubectl delete namespace default-mem-example
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
+5
View File
@@ -136,3 +136,8 @@ kubectl delete namespace quota-pod-example
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
-2
View File
@@ -1,5 +1,4 @@
---
reviewers:
title: 네트워크 폴리시로 캘리코(Calico) 사용하기
content_type: task
weight: 10
@@ -52,4 +51,3 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러
클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해
[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
+2 -1
View File
@@ -1,10 +1,11 @@
---
reviewers:
title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기
content_type: task
weight: 30
---
<!-- overview -->
이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다.
content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+2 -1
View File
@@ -1,10 +1,11 @@
---
reviewers:
title: 네트워크 폴리시로 로마나(Romana)
content_type: task
weight: 40
---
<!-- overview -->
이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다.
content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
-1
View File
@@ -1,5 +1,4 @@
---
reviewers:
title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기
content_type: task
weight: 50
content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md
+14 -8
View File
@@ -25,7 +25,8 @@ weight: 10
서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면
다음 단계를 건너뛸 수 있다.
Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화 할 수 있다.
Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를
활성화할 수 있다.
```shell
minikube addons enable metrics-server
@@ -52,7 +53,8 @@ v1beta1.metrics.k8s.io
## 네임스페이스 생성
이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다.
이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해
네임스페이스를 생성한다.
```shell
kubectl create namespace mem-example
@@ -110,8 +112,9 @@ resources:
kubectl top pod memory-demo --namespace=mem-example
```
출력은 파드가 약 150MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다.
이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다.
출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다.
이는 파드의 100 MiB 요청 보다 많으나
파드의 200 MiB 상한보다는 적다.
```
NAME CPU(cores) MEMORY(bytes)
@@ -138,7 +141,7 @@ kubectl delete pod memory-demo --namespace=mem-example
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
구성 파일의 'args' 섹션에서 컨테이너가
구성 파일의 `args` 섹션에서 컨테이너가
100 MiB 상한을 훨씬 초과하는 250 MiB의 메모리를 할당하려는 것을 볼 수 있다.
파드 생성:
@@ -242,7 +245,8 @@ kubectl delete pod memory-demo-2 --namespace=mem-example
이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다.
다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는
컨테이너를 갖는 파드의 구성 파일이다.
컨테이너를 갖는
파드의 구성 파일이다.
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
@@ -302,8 +306,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example
컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다.
* 컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가
실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행 될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이
없는 컨테이너가 종료될 가능성이 크다.
실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 없는 컨테이너가 종료될 가능성이 크다.
* 기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는
자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은
@@ -356,3 +359,6 @@ kubectl delete namespace mem-example
* [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/)
content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md
+13 -9
View File
@@ -1,22 +1,23 @@
---
title: 초기화 컨테이너에 대한 구성
content_template: templates/task
content_type: task
weight: 130
---
{{% capture overview %}}
<!-- overview -->
이 페이지는 애플리케이션 실행 전에 파드를 초기화하기 위해 어떻게 초기화 컨테이너를
구성해야 하는지 보여준다.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 초기화 컨테이너를 갖는 파드 생성
@@ -78,9 +79,10 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
<p>Kubernetes is open source giving you the freedom to take advantage ...</p>
...
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [같은 파드 내 실행 중인 컨테이너들간 통신](/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)에
대해 배우기.
@@ -88,4 +90,6 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
* [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기.
* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기.
{{% /capture %}}
content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
+1 -1
View File
@@ -7,7 +7,7 @@ weight: 100
<!-- overview -->
이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을
사용하는 파드(Pod)를 생성하는 방법을 보여준다.
사용하는 파드를 생성하는 방법을 보여준다.
content/ko/docs/tasks/configure-pod-container/static-pod.md
+238
View File
@@ -0,0 +1,238 @@
---
title: 스태틱(static) 파드 생성하기
weight: 170
content_template: task
---
<!-- overview -->
*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
없이 특정 노드에 있는 kubelet 데몬에 의해
직접 관리된다.
컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리,
kubelet 이 각각의 스태틱 파드를 감시한다.
(만약 충돌이 날 경우 다시 구동한다.)
스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다.
Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드(mirror pod)" term_id="mirror-pod" >}}를
생성하려고 자동으로 시도한다.
즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만,
API 서버에서 제어될 수는 없다.
{{< note >}}
만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여
모든 노드에서 파드를 구동하고 있다면,
스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}}
을 사용하는 것이 바람직하다.
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며,
노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다.
다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.
<!-- steps -->
## 스태틱 파드 생성하기 {#static-pod-creation}
[파일 시스템이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다.
### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files}
매니페스트는 특정 디렉토리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉토리를 정기적으로 스캔하여, 디렉토리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다.
1. 스태틱 파드를 실행할 노드를 선택한다. 이 예제에서는 `my-model` 이다.
```shell
ssh my-node1
```
2. `/etc/kubelet.d` 와 같은 디렉토리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다.
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
mkdir /etc/kubelet.d/
cat <<EOF >/etc/kubelet.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
EOF
```
3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉토리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다.
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: <the directory>` 필드를 추가한다.
4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
```
### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http}
Kubelet은 `--manifest-url=<URL>` 의 인수로 지정된 파일을 주기적으로 다운로드하여
해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다.
[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과
유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에
변경된 부분이 있을 경우, kubelet 은 이를 적용한다.
이 방법을 사용하기 위하여 다음을 수행한다.
1. kubelet 에게 파일의 URL을 전달하기 위하여 YAML 파일을 생성하고 이를 웹 서버에 저장한다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
```
2. 선택한 노드에서 `--manifest-url=<manifest-url>` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다.
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>"
```
3. Kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
```
## 스태틱 파드 행동 관찰하기 {#behavior-of-static-pods}
Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다.
스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱
파드가 이미 실행 중이어야 한다.
(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다.
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
docker ps
```
결과는 다음과 유사하다.
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
```
API 서버에서 미러 파드를 볼 수 있다.
```shell
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
```
{{< note >}}
Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다.
[파드시큐리티폴리시(PodSecurityPolicy)](/docs/concepts/policy/pod-security-policy/) 에 대해 보기.
{{< /note >}}
스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은
미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을
통하여 이러한 레이블을 사용할 수 있다.
만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도,
kubelet 은 스태틱 파드를 지우지 _않는다._
```shell
kubectl delete pod static-web-my-node1
```
```
pod "static-web-my-node1" deleted
```
파드가 여전히 구동 중인 것을 볼 수 있다.
```shell
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
```
kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로
중지할 수 있다.
일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는
것을 볼 수 있다.
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
sleep 20
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
```
## 스태틱 파드의 동적 추가 및 제거
실행 중인 kubelet 은 주기적으로, 설정된 디렉토리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉토리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다.
```shell
# 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다.
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
#
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
docker ps
# 구동 중인 nginx 컨테이너가 없는 것을 확인한다.
mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
```
content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+17 -8
View File
@@ -3,7 +3,7 @@ title: 파드 실패의 원인 검증하기
content_template: templates/task
---
{{% capture overview %}}
<!-- overview -->
이 페이지는 컨테이너 종료 메시지를 읽고 쓰는
방법을 보여준다.
@@ -16,17 +16,18 @@ content_template: templates/task
일반
[쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 종료 메시지 읽기 및 쓰기
@@ -82,6 +83,11 @@ content_template: templates/task
쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다.
쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다.
종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다.
kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는
12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다.
파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다.
다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
`/tmp/my-log` 파일에 종료 메시지를 기록한다.
@@ -105,13 +111,16 @@ spec:
쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다.
로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
에 있는 `terminationMessagePath` 에 대해 읽어보기.
* [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기.
* [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기.
{{% /capture %}}
content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+2 -6
View File
@@ -18,15 +18,11 @@ title: 리소스 모니터링 도구
<!-- body -->
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다.
신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한
메트릭 파이프라인](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를
수집할 수 있다.
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다.
## 리소스 메트릭 파이프라인
리소스 메트릭 파이프라인은
[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는
메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)에
content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md
+11 -9
View File
@@ -1,23 +1,24 @@
---
title: 플러그인으로 kubectl 확장
description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다.
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
이 가이드는 [kubectl](/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는
플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 `kubectl` 을 확장하고, 주요 배포판에 포함되지 않은 `kubectl` 의 새로운 사용자 정의 기능을 허용한다.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
동작하는 `kubectl` 바이너리가 설치되어 있어야 한다.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## kubectl 플러그인 설치
@@ -372,9 +373,10 @@ kubectl 플러그인의 배포 패키지를
컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가
더 쉬워진다.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Go로 작성된 플러그인의
[자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는
@@ -383,4 +385,4 @@ kubectl 플러그인의 배포 패키지를
[SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다.
* kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다.
{{% /capture %}}
content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md
+17 -4
View File
@@ -30,7 +30,7 @@ weight: 20
이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는
값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 파일
값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트
예시이다.
{{< codenew file="pods/inject/envars.yaml" >}}
@@ -63,7 +63,8 @@ weight: 20
1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다.
```shell
root@envar-demo:/# printenv
# 컨테이너 내 셸에서 다음을 실행한다.
printenv
```
출력은 아래와 비슷할 것이다.
@@ -81,12 +82,24 @@ weight: 20
{{< note >}}
`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지
안에서 명시된 어떠한 환경 변수들보다 더 우선시된다.
안에서 명시된 모든 환경 변수들을 오버라이딩한다.
{{< /note >}}
{{< note >}}
환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다.
사용하기 전에 순서에 주의한다.
{{< /note >}}
## 설정 안에서 환경 변수 사용하기
파드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드들과 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 `NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, 그리고 `Kubernetes`로 설정되어 있다. 이들 환경 변수들은 이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 사용된다.
파드의 구성 파일 안에서 정의한 환경 변수는
파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이,
구성 파일 안의 다른 곳에서 사용할 수 있다.
아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고
`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`,
그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은
이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서
사용된다.
```yaml
apiVersion: v1
content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md
+14 -9
View File
@@ -1,27 +1,30 @@
---
title: 데몬셋(DaemonSet)에서 롤백 수행
content_template: templates/task
content_type: task
weight: 20
---
{{% capture overview %}}
<!-- overview -->
이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은
쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다.
* [데몬셋에서 롤링 업데이트를
수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 데몬셋에서 롤백 수행
@@ -102,10 +105,10 @@ kubectl rollout status ds/<daemonset-name>
daemonset "<daemonset-name>" successfully rolled out
```
{{% /capture %}}
{{% capture discussion %}}
<!-- discussion -->
## 데몬셋 리비전의 이해
@@ -152,4 +155,6 @@ NAME CONTROLLER REVISION AGE
* [데몬셋 롤링 업데이트
문제 해결](/ko/docs/tasks/manage-daemon/update-daemon-set/#문제-해결)을 참고한다.
{{% /capture %}}
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
+13 -9
View File
@@ -1,24 +1,27 @@
---
title: 데몬셋(DaemonSet)에서 롤링 업데이트 수행
content_template: templates/task
content_type: task
weight: 10
---
{{% capture overview %}}
<!-- overview -->
이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## 데몬셋 업데이트 전략
@@ -188,13 +191,14 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
kubectl delete ds fluentd-elasticsearch -n kube-system
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [태스크: 데몬셋에서 롤백
수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다.
* [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다.
{{% /capture %}}
content/ko/docs/tasks/manage-gpus/scheduling-gpus.md
+3 -3
View File
@@ -1,10 +1,10 @@
---
content_type: concept
title: GPU 스케줄링
---
<!-- overview -->
{{< feature-state state="beta" for_k8s_version="v1.10" >}}
@@ -98,7 +98,7 @@ kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device
- Kubelet은 자신의 컨테이너 런타임으로 도커를 사용해야 한다.
- 도커는 runc 대신 `nvidia-container-runtime` 이 [기본 런타임](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)으로
설정되어야 한다.
- NVIDIA 드라이버의 버전은 조건 ~= 361.93 을 만족해야 한다.
- NVIDIA 드라이버의 버전은 조건 ~= 384.81을 만족해야 한다.
클러스터가 실행 중이고 위의 요구 사항이 만족된 후, NVIDIA 디바이스 플러그인을 배치하기 위해서는
아래 명령어를 실행한다.
content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
+9 -7
View File
@@ -1,18 +1,19 @@
---
title: HugePages 관리
content_template: templates/task
content_type: task
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="stable" >}}
쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된
huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가
huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
1. 쿠버네티스 노드는 노드에 대한 huge page 용량을 보고하기 위해
huge page를 미리 할당해야 한다. 노드는 여러 크기의 huge page를 미리 할당할 수
@@ -21,9 +22,9 @@ huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한
노드는 모든 huge page 리소스를 스케줄 가능한 리소스로 자동 검색하고
보고한다.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## API
@@ -123,4 +124,5 @@ term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)
- NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다.
- 리밋레인지(LimitRange)를 지원할 예정이다.
{{% /capture %}}
content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
+5 -1
View File
@@ -65,7 +65,7 @@ weight: 10
kubectl apply -f <디렉터리>/
```
이것은  각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
이것은 각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
어노테이션을 설정한다. 해당 어노테이션은 오브젝트를 생성하기 위해 사용했던
오브젝트 구성 파일의 내용을 포함한다. 
@@ -78,9 +78,11 @@ kubectl apply -f <디렉터리>/
{{< codenew file="application/simple_deployment.yaml" >}}
생성될 오브젝트를 출력하려면 `kubectl diff`를 실행한다. 
```shell
kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
```
{{< note >}}
`diff`는 `kube-apiserver`의 활성화가 필요한
[서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다.
@@ -1000,8 +1002,10 @@ template:
## {{% heading "whatsnext" %}}
* [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
+2
View File
@@ -164,8 +164,10 @@ kubectl create --edit -f /tmp/srv.yaml
## {{% heading "whatsnext" %}}
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
+2
View File
@@ -147,8 +147,10 @@ template:
## {{% heading "whatsnext" %}}
* [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
content/ko/docs/tasks/run-application/delete-stateful-set.md
+88
View File
@@ -0,0 +1,88 @@
---
title: 스테이트풀셋(StatefulSet) 삭제하기
content_type: task
weight: 60
---
<!-- overview -->
이 작업은 {{< glossary_tooltip term_id="StatefulSet"text="스테이트풀셋">}}을 삭제하는 방법을 설명한다.
## {{% heading "prerequisites" %}}
* 이 작업은 클러스터에 스테이트풀셋으로 표시되는 애플리케이션이 있다고 가정한다.
<!-- steps -->
## 스테이트풀셋 삭제
쿠버네티스에서 다른 리소스를 삭제하는 것과 같은 방식으로 스테이트풀셋을 삭제할 수 있다. `kubectl delete` 명령어를 사용하고 파일 또는 이름으로 스테이트풀셋을 지정하자.
```shell
kubectl delete -f <file.yaml>
```
```shell
kubectl delete statefulsets <statefulset-name>
```
스테이트풀셋 자체를 삭제한 후 연결된 헤드리스 서비스는 별도로 삭제해야 할 수도 있다.
```shell
kubectl delete service <service-name>
```
kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다.
파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다.
```shell
kubectl delete -f <file.yaml> --cascade=false
```
`kubectl delete` 에 `--cascade=false` 를 사용함으로써, 스테이트풀셋 객체가 삭제 된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
```shell
kubectl delete pods -l app=myapp
```
### 퍼시스턴트볼륨(PersistentVolume)
스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#termination-of-pods)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.
{{< note >}}
PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
{{< /note >}}
### 스테이트풀셋의 완벽한 삭제
연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다.
```shell
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
kubectl delete statefulset -l app=myapp
sleep $grace
kubectl delete pvc -l app=myapp
```
위의 예에서 파드에는 `app=myapp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자.
### 스테이트풀셋 파드의 강제 삭제
스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
## {{% heading "whatsnext" %}}
[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -8,7 +8,7 @@ weight: 100
Horizontal Pod Autoscaler는
CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다.
레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+9 -13
View File
@@ -9,13 +9,17 @@ content_type: concept
weight: 90
---
<!-- overview -->
Horizontal Pod Autoscaler는 CPU 사용량
(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md),
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. Horizontal
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬 셋)에는 적용되지 않는다.
컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다.
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
리소스는 컨트롤러의 동작을 결정한다.
@@ -160,11 +164,7 @@ HPA가 여전히 확장할 수 있음을 의미한다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이
기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장
사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은
`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트
동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한
스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을
사용하여 설정할 수 있고, 기본 값은 5분이다.
사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본값은 5분이다.
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
영향을 완만하게 한다.
@@ -233,11 +233,6 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
있다.
{{< /note >}}
v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds`
를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다.
[구성가능한 스케일링
동작 지원](#구성가능한-스케일링-동작-지원)을 본다.
## 멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
@@ -265,7 +260,7 @@ Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용
기본적으로 HorizontalPodAutoscaler 컨트롤러는 일련의 API에서 메트릭을 검색한다. 이러한
API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
* [API 집합 레이어](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 활성화
* [API 애그리게이션 레이어](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 활성화
* 해당 API 등록:
@@ -445,3 +440,4 @@ behavior:
* kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제.
content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
+16 -11
View File
@@ -1,37 +1,39 @@
---
title: 단일 인스턴스 스테이트풀 애플리케이션 실행하기
content_template: templates/tutorial
content_type: tutorial
weight: 20
---
{{% capture overview %}}
<!-- overview -->
이 페이지에서는 쿠버네티스 클러스터에서 퍼시스턴트볼륨(PersistentVolume)과 디플로이먼트(Deployment)를
사용하여, 단일 인스턴스 스테이트풀 애플리케이션을 실행하는 방법을 보인다.
해당 애플리케이션은 MySQL이다.
{{% /capture %}}
{{% capture objectives %}}
## {{% heading "objectives" %}}
* 사용자 환경의 디스크를 참조하는 퍼시스턴트볼륨 생성하기
* MySQL 디플로이먼트 생성하기
* 알려진 DNS 이름으로 클러스터의 다른 파드에 MySQL 서비스 노출하기
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "default-storage-class-prereqs.md" >}}
{{% /capture %}}
{{% capture lessoncontent %}}
<!-- lessoncontent -->
## MySQL 배포하기
@@ -180,10 +182,11 @@ kubectl delete pv mysql-pv-volume
일부 동적 프로비저너(EBS 와 PD와 같은)는
퍼시스턴트볼륨을 삭제할 때에 기본 리소스도 해제한다.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기
@@ -193,4 +196,6 @@ kubectl delete pv mysql-pv-volume
* [볼륨](/ko/docs/concepts/storage/volumes/)과 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)
{{% /capture %}}
content/ko/docs/tasks/tls/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "TLS"
weight: 100
---
content/ko/docs/tasks/tls/certificate-rotation.md
+83
View File
@@ -0,0 +1,83 @@
---
title: Kubelet의 인증서 갱신 구성
content_type: task
---
<!-- overview -->
이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다.
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
## {{% heading "prerequisites" %}}
* 쿠버네티스 1.8.0 버전 혹은 그 이상의 버전이 요구됨
<!-- steps -->
## 개요
kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다.
기본적으로 이러한 인증서는 1년 만기로 발급되므로
너무 자주 갱신할 필요는 없다.
쿠버네티스 1.8은 [kubelet 인증서
갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며,
이 기능은 현재 인증서의 만료 시한이 임박한 경우,
새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다.
새로운 인증서를 사용할 수 있게 되면
쿠버네티스 API에 대한 연결을 인증하는데 사용된다.
## 클라이언트 인증서 갱신 활성화하기
`kubelet` 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라
kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는
`--rotate-certificates` 인자를 허용한다.
인증서 갱신은 베타 기능이므로 기능 플래그는
`--feature-gates = RotateKubeletClientCertificate=true` 를 사용하여 활성화해야 한다.
`kube-controller-manager` 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는
`--experimental-cluster-signing-duration` 인자를
허용한다.
## 인증서 갱신 구성에 대한 이해
kubelet이 시작할 때 부트 스트랩 (`--bootstrap-kubeconfig` 플래그를 사용)
을 구성하면 초기 인증서를 사용하여 쿠버네티스 API에 연결하고
인증서 서명 요청을 발행한다.
다음을 사용하여 인증서 서명 요청 상태를 볼 수 있다.
```sh
kubectl get csr
```
초기에 노드의 kubelet에서 인증서 서명 요청은 `Pending` 상태이다.
인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가
자동으로 승인한 후 상태가 `Approved` 가 된다.
다음으로, 컨트롤러 관리자는
`--experimental-cluster-signing-duration` 파라미터에 의해 지정된 기간 동안
발행된 인증서에 서명하고
서명된 인증서는 인증서 서명 요청에 첨부된다.
kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서
`--cert-dir`에 지정된 위치에 디스크에 기록한다.
그런 다음 kubelet은 쿠버네티스 API에 연결해서 새로운 인증서를 사용한다.
서명된 인증서의 만료가 다가오면 kubelet은 쿠버네티스 API를 사용하여
새로운 인증서 서명 요청을 자동으로 발행한다.
또한, 컨트롤러 관리자는 인증서 요청을 자동으로 승인하고
서명된 인증서를 인증서 서명 요청에 첨부한다.
kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다.
그런 다음 새로운 인증서를 사용한 재연결을 위해서
가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다.
content/ko/docs/tasks/tools/install-minikube.md
+5 -2
View File
@@ -200,7 +200,6 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini
{{% /tab %}}
{{< /tabs >}}
## 설치 확인
하이퍼바이저와 Minikube의 성공적인 설치를 확인하려면, 다음 명령어를 실행해서 로컬 쿠버네티스 클러스터를 시작할 수 있다.
@@ -211,6 +210,10 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini
{{< /note >}}
{{< caution >}}
KVM을 사용할 때 Debian과 다른 시스템에서 libvirt의 기본 QEMU URI는 `qemu:///session`이고, Minikube의 기본 QEMU URI는 `qemu:///system`이다. 시스템이 이런 환경이라면, `--kvm-qemu-uri qemu:///session`을 `minikube start`에 전달해야 한다.
{{< /caution >}}
```shell
minikube start --driver=<driver_name>
```
@@ -256,4 +259,4 @@ minikube delete
## {{% heading "whatsnext" %}}
* [Minikube로 로컬에서 쿠버네티스 실행하기](/docs/setup/minikube/)
* [Minikube로 로컬에서 쿠버네티스 실행하기](/ko/docs/setup/learning-environment/minikube/)