kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #26837 from kubernetes/dev-1.20-ko.5 

[ko] Fifth Korean l10n work for release-1.20
This commit is contained in:
Kubernetes Prow Robot 2021-03-04 21:58:22 -08:00 committed by GitHub
parent b23edad5d1 ffeaf39228
commit fa7ece8903
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
73 changed files with 816 additions and 1099 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
content/ko/community/_index.html
View File

@ -19,6 +19,7 @@ cid: community
<div class="community__navbar"> <div class="community__navbar">
<a href="#values">커뮤니티 가치</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#conduct">행동 강령 </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="#conduct">행동 강령 </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#videos">비디오</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="#videos">비디오</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#discuss">토론</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="#discuss">토론</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
@ -41,10 +42,28 @@ cid: community
<img src="/images/community/kubernetes-community-final-05.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;margin-right:0% important" class="desktop"> <img src="/images/community/kubernetes-community-final-05.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;margin-right:0% important" class="desktop">
</div> </div>
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;margin-bottom:3%" class="mobile"> <img src="/images/community/kubernetes-community-04-mobile.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;margin-bottom:3%" class="mobile">
<a name="values"></a>
<a name="conduct"></a>
</div> </div>
<div><a name="values"></a></div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1>커뮤니티 가치</h1>
쿠버네티스 커뮤니티가 추구하는 가치는 프로젝트의 지속적인 성공의 핵심입니다.<br>
이러한 원칙은 쿠버네티스 프로젝트의 모든 측면을 이끌어 갑니다.
<br>
<a href="/community/values/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
더 읽어 보기
</span>
</a>
</div><a name="conduct"></a>
</div>
</div>
<div class="conduct"> <div class="conduct">

2
content/ko/docs/concepts/architecture/controller.md
View File

@ -102,7 +102,7 @@ weight: 30
온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가 온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가
서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는 서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는
[쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해 [쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자 APIS 및 IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API들 및
기타 서비스 등과 간접적으로 연동하여 이를 구현한다. 기타 서비스 등과 간접적으로 연동하여 이를 구현한다.
## 의도한 상태와 현재 상태 {#desired-vs-current} ## 의도한 상태와 현재 상태 {#desired-vs-current}

2
content/ko/docs/concepts/architecture/nodes.md
View File

@ -10,7 +10,7 @@ weight: 10
노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 의해 관리되며 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 의해 관리되며
{{< glossary_tooltip text="파드" term_id="pod" >}}를 {{< glossary_tooltip text="파드" term_id="pod" >}}를
실행하는데 필요한 서비스를 포함한다. 실행하는 데 필요한 서비스를 포함한다.
일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는 일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는
환경에서는 하나만 있을 수도 있다. 환경에서는 하나만 있을 수도 있다.

4
content/ko/docs/concepts/cluster-administration/_index.md
View File

@ -22,12 +22,12 @@ no_list: true
가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다. 가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다.
- 컴퓨터에서 쿠버네티스를 그냥 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다. - 컴퓨터에서 쿠버네티스를 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
- [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가? - [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가?
- 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다. - 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
- **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다. - **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
- 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가? - 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
- **단지 클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약 - **클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약
후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만, 후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
더 다양한 선택을 제공한다. 더 다양한 선택을 제공한다.
- 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자. - 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.

137
content/ko/docs/concepts/cluster-administration/logging.md
View File

@ -1,4 +1,7 @@
--- ---
title: 로깅 아키텍처 title: 로깅 아키텍처
content_type: concept content_type: concept
weight: 60 weight: 60
@ -6,23 +9,22 @@ weight: 60
<!-- overview --> <!-- overview -->
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. 애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다. 그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다.
예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다.
클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다.
<!-- body --> <!-- body -->
클러스터-레벨 로깅 아키텍처는 로깅 백엔드가 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는
클러스터 내부 또는 외부에 존재한다고 가정하여 설명한다. 클러스터-레벨 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만,
로깅에 관심이 없는 경우에도, 노드에서 로그를 저장하고 쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다.
처리하는 방법에 대한 설명이 여전히 유용할 수 있다.
## 쿠버네티스의 기본 로깅 ## 쿠버네티스의 기본 로깅
이 섹션에서는, 쿠버네티스에서 표준 출력 스트림으로 데이터를 이 예시는 텍스트를 초당 한 번씩 표준 출력에 쓰는
출력하는 기본 로깅의 예시를 볼 수 있다. 이 데모에서는 컨테이너에 대한 `Pod` 명세를 사용한다.
일부 텍스트를 초당 한 번씩 표준 출력에 쓰는 컨테이너와 함께
파드 명세를 사용한다.
{{< codenew file="debug/counter-pod.yaml" >}} {{< codenew file="debug/counter-pod.yaml" >}}
@ -31,8 +33,10 @@ weight: 60
```shell ```shell
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
``` ```
출력은 다음과 같다. 출력은 다음과 같다.
```
```console
pod/counter created pod/counter created
``` ```
@ -41,69 +45,69 @@ pod/counter created
```shell ```shell
kubectl logs counter kubectl logs counter
``` ```
출력은 다음과 같다. 출력은 다음과 같다.
```
```console
0: Mon Jan 1 00:00:00 UTC 2001 0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001
... ...
``` ```
컨테이너가 크래시된 경우, `kubectl logs` 의 `--previous` 플래그를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. 파드에 여러 컨테이너가 있는 경우, 명령에 컨테이너 이름을 추가하여 접근하려는 컨테이너 로그를 지정해야 한다. 자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다. `kubectl logs --previous` 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. 파드에 여러 컨테이너가 있는 경우, 명령에 컨테이너 이름을 추가하여 접근하려는 컨테이너 로그를 지정해야 한다. 자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다.
## 노드 레벨에서의 로깅 ## 노드 레벨에서의 로깅
![노드 레벨 로깅](/images/docs/user-guide/logging/logging-node-level.png) ![노드 레벨 로깅](/images/docs/user-guide/logging/logging-node-level.png)
컨테이너화된 애플리케이션이 `stdout(표준 출력)` 및 `stderr(표준 에러)` 에 쓰는 모든 것은 컨테이너 엔진에 의해 어딘가에서 처리와 리디렉션 된다. 예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 json 형식의 파일에 작성하도록 구성된다. 컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 엔진이 처리 및 리디렉션 한다.
예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 JSON 형식의 파일에 작성하도록 구성된다.
{{< note >}} {{< note >}}
도커 json 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다. 도커 JSON 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다.
{{< /note >}} {{< /note >}}
기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다. 기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다.
노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여, 노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여,
로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는 로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는
현재 로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로 로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로
이를 해결하기 위한 솔루션을 설정해야 한다. 이를 해결하기 위한 솔루션을 설정해야 한다.
예를 들어, `kube-up.sh` 스크립트에 의해 배포된 쿠버네티스 클러스터에는, 예를 들어, `kube-up.sh` 스크립트에 의해 배포된 쿠버네티스 클러스터에는,
매시간 실행되도록 구성된 [`logrotate`](https://linux.die.net/man/8/logrotate) 매시간 실행되도록 구성된 [`logrotate`](https://linux.die.net/man/8/logrotate)
도구가 있다. 예를 들어, 도커의 `log-opt` 를 사용하여 애플리케이션의 로그를 도구가 있다. 애플리케이션의 로그를 자동으로
자동으로 로테이션을 하도록 컨테이너 런타임을 설정할 수도 있다. 로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
`kube-up.sh` 스크립트에서, 후자의 접근 방식은 GCP의 COS 이미지에 사용되며,
전자의 접근 방식은 다른 환경에서 사용된다. 두 경우 모두,
기본적으로 로그 파일이 10MB를 초과하면 로테이션이 되도록 구성된다.
예를 들어, `kube-up.sh` 가 해당 예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
[스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)에서 [`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 찾을 수 있다. 자세히 알 수 있다.
기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
실행하면, 노드의 kubelet이 요청을 처리하고 실행하면, 노드의 kubelet이 요청을 처리하고
로그 파일에서 직접 읽은 다음, 응답의 내용을 반환한다. 로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다.
{{< note >}} {{< note >}}
현재, 일부 외부 시스템에서 로테이션을 수행한 경우, 만약, 일부 외부 시스템이 로테이션을 수행한 경우,
`kubectl logs` 를 통해 최신 로그 파일의 내용만 `kubectl logs` 를 통해 최신 로그 파일의 내용만
사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가 사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가
로테이션을 수행하고 두 개의 파일이 생긴다(크기가 10MB인 파일 하나와 비어있는 파일). 로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일)
그 후 `kubectl logs` 는 빈 응답을 반환한다. `kubectl logs` 는 이 예시에서는 빈 응답에 해당하는 최신 로그 파일을 반환한다.
{{< /note >}} {{< /note >}}
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
### 시스템 컴포넌트 로그 ### 시스템 컴포넌트 로그
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. 시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
예를 들면 다음과 같다. 예를 들면 다음과 같다.
* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다. * 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
* Kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다. * Kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다.
systemd를 사용하는 시스템에서, kubelet과 컨테이너 런타임은 journald에 작성한다. systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 journald에 작성한다.
systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 작성한다. systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/log` 디렉터리의
컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, `.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고,
항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog](https://github.com/kubernetes/klog) 항상 `/var/log` 디렉터리에 기록한다.
시스템 컴포넌트는 [klog](https://github.com/kubernetes/klog)
로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서 로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서
해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다. 해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다.
@ -126,13 +130,14 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에
각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다. 각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다.
로깅 에이전트는 모든 노드에서 실행해야 하므로, 이를 데몬셋 레플리카, 매니페스트 파드 또는 노드의 전용 네이티브 프로세스로 구현하는 것이 일반적이다. 그러나 후자의 두 가지 접근법은 더 이상 사용되지 않으며 절대 권장하지 않는다. 로깅 에이전트는 모든 노드에서 실행해야 하므로, 에이전트는
`DaemonSet` 으로 동작시키는 것을 추천한다.
쿠버네티스 클러스터는 노드-레벨 로깅 에이전트를 사용하는 것이 가장 일반적이며 권장되는 방법으로, 이는 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션을 변경할 필요가 없기 때문이다. 그러나, 노드-레벨 로깅은 _애플리케이션의 표준 출력과 표준 에러에 대해서만 작동한다_ . 노드-레벨 로깅은 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션에 대한 변경은 필요로 하지 않는다.
쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/tasks/debug-application-cluster/logging-stackdriver/)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다. 컨테이너는 stdout과 stderr를 동의되지 않은 포맷으로 작성한다. 노드-레벨 에이전트는 이러한 로그를 수집하고 취합을 위해 전달한다.
### 로깅 에이전트와 함께 사이드카 컨테이너 사용 ### 로깅 에이전트와 함께 사이드카 컨테이너 사용 {#sidecar-container-with-logging-agent}
다음 중 한 가지 방법으로 사이드카 컨테이너를 사용할 수 있다. 다음 중 한 가지 방법으로 사이드카 컨테이너를 사용할 수 있다.
@ -143,28 +148,27 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에
![스트리밍 컨테이너가 있는 사이드카 컨테이너](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) ![스트리밍 컨테이너가 있는 사이드카 컨테이너](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)
사이드카 컨테이너를 자체 `stdout` 및 `stderr` 스트림으로 사이드카 컨테이너가 자체 `stdout` 및 `stderr` 스트림으로
스트리밍하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 쓰도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를
활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다.
또는 journald에서 로그를 읽는다. 각 개별 사이드카 컨테이너는 자체 `stdout` 각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다.
또는 `stderr` 스트림에 로그를 출력한다.
이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을 이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을
분리할 수 ​​있고, 이 중 일부는 `stdout` 또는 `stderr` 에 분리할 수 ​​있고, 이 중 일부는 `stdout` 또는 `stderr` 에
작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은 작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은
미미하기 때문에, 큰 오버헤드가 거의 없다. 또한, 최소화되어 있기 때문에, 심각한 오버헤드가 아니다. 또한,
`stdout` 및 `stderr` 가 kubelet에서 처리되므로, `kubectl logs` 와 같은 `stdout` 및 `stderr` 가 kubelet에서 처리되므로, `kubectl logs` 와 같은
빌트인 도구를 사용할 수 있다. 빌트인 도구를 사용할 수 있다.
다음의 예를 고려해보자. 파드는 단일 컨테이너를 실행하고, 컨테이너는 예를 들어, 파드는 단일 컨테이너를 실행하고, 컨테이너는
서로 다른 두 가지 형식을 사용하여, 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한 서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한
구성 파일은 다음과 같다. 구성 파일은 다음과 같다.
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}} {{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
두 컴포넌트를 컨테이너의 `stdout` 스트림으로 리디렉션한 경우에도, 동일한 로그 두 컴포넌트를 컨테이너의 `stdout` 스트림으로 리디렉션한 경우에도, 동일한 로그
스트림에 서로 다른 형식의 로그 항목을 갖는 것은 스트림에 서로 다른 형식의 로그 항목을 작성하는 것은
알아보기 힘들다. 대신, 두 개의 사이드카 컨테이너를 도입할 수 있다. 각 사이드카 추천하지 않는다. 대신, 두 개의 사이드카 컨테이너를 생성할 수 있다. 각 사이드카
컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를 컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를
자체 `stdout` 스트림으로 리디렉션할 수 있다. 자체 `stdout` 스트림으로 리디렉션할 수 있다.
@ -178,7 +182,10 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에
```shell ```shell
kubectl logs counter count-log-1 kubectl logs counter count-log-1
``` ```
```
출력은 다음과 같다.
```console
0: Mon Jan 1 00:00:00 UTC 2001 0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001
@ -188,7 +195,10 @@ kubectl logs counter count-log-1
```shell ```shell
kubectl logs counter count-log-2 kubectl logs counter count-log-2
``` ```
```
출력은 다음과 같다.
```console
Mon Jan 1 00:00:00 UTC 2001 INFO 0 Mon Jan 1 00:00:00 UTC 2001 INFO 0
Mon Jan 1 00:00:01 UTC 2001 INFO 1 Mon Jan 1 00:00:01 UTC 2001 INFO 1
Mon Jan 1 00:00:02 UTC 2001 INFO 2 Mon Jan 1 00:00:02 UTC 2001 INFO 2
@ -204,11 +214,10 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2
`stdout` 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에 `stdout` 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에
쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍 쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍
사이드카 컨테이너 방식을 구현하는 대신 `/dev/stdout` 을 대상으로 사이드카 컨테이너 방식을 구현하는 대신 `/dev/stdout` 을 대상으로
설정하는 것이 더 낫다. 설정하는 것을 추천한다.
사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는 사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는
로그 파일을 로테이션할 수도 있다. 이 방법의 예로는 로그 파일을 로테이션할 수도 있다. 이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다.
정기적으로 logrotate를 실행하는 작은 컨테이너를 두는 것이다.
그러나, `stdout` 및 `stderr` 을 직접 사용하고 로테이션과 그러나, `stdout` 및 `stderr` 을 직접 사용하고 로테이션과
유지 정책을 kubelet에 두는 것이 권장된다. 유지 정책을 kubelet에 두는 것이 권장된다.
@ -223,21 +232,17 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2
{{< note >}} {{< note >}}
사이드카 컨테이너에서 로깅 에이전트를 사용하면 사이드카 컨테이너에서 로깅 에이전트를 사용하면
상당한 리소스 소비로 이어질 수 있다. 게다가, kubelet에 의해 상당한 리소스 소비로 이어질 수 있다. 게다가, kubelet에 의해
제어되지 않기 때문에, `kubectl logs` 명령을 사용하여 해당 로그에 제어되지 않기 때문에, `kubectl logs` 를 사용하여 해당 로그에
접근할 수 없다. 접근할 수 없다.
{{< /note >}} {{< /note >}}
예를 들어, 로깅 에이전트로 fluentd를 사용하는 [스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)를 여기에 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 구성 파일이 있다. 첫 번째 파일에는
사용할 수 있다. 여기에 이 방법을 구현하는 데 사용할 수 있는 fluentd를 구성하기 위한 [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다.
두 가지 구성 파일이 있다. 첫 번째 파일에는
fluentd를 구성하기 위한 [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다.
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
{{< note >}} {{< note >}}
fluentd의 구성은 이 문서의 범위를 벗어난다. fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](https://docs.fluentd.org/)를 참고한다.
fluentd를 구성하는 것에 대한 자세한 내용은,
[공식 fluentd 문서](https://docs.fluentd.org/)를 참고한다.
{{< /note >}} {{< /note >}}
두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다. 두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다.
@ -245,16 +250,10 @@ fluentd를 구성하는 것에 대한 자세한 내용은,
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} {{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
얼마 후 스택드라이버 인터페이스에서 로그 메시지를 찾을 수 있다. 이 예시 구성에서, 사용자는 애플리케이션 컨테이너 내의 모든 소스을 읽는 fluentd를 다른 로깅 에이전트로 대체할 수 있다.
이것은 단지 예시일 뿐이며 실제로 애플리케이션 컨테이너 내의
모든 소스에서 읽은 fluentd를 로깅 에이전트로 대체할 수 있다는 것을
기억한다.
### 애플리케이션에서 직접 로그 노출 ### 애플리케이션에서 직접 로그 노출
![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png) ![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png)
모든 애플리케이션에서 직접 로그를 노출하거나 푸시하여 클러스터-레벨 로깅을 모든 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다.
구현할 수 있다. 그러나, 이러한 로깅 메커니즘의 구현은
쿠버네티스의 범위를 벗어난다.

27
content/ko/docs/concepts/cluster-administration/manage-deployment.md
View File

@ -1,4 +1,6 @@
--- ---
title: 리소스 관리 title: 리소스 관리
content_type: concept content_type: concept
weight: 40 weight: 40
@ -43,7 +45,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
`kubectl` 은 접미사가 `.yaml`, `.yml` 또는 `.json` 인 파일을 읽는다. `kubectl` 은 접미사가 `.yaml`, `.yml` 또는 `.json` 인 파일을 읽는다.
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 일괄로 배포할 수 있다. 동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다.
URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다. URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
@ -68,7 +70,7 @@ deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted service "my-nginx-svc" deleted
``` ```
두 개의 리소스만 있는 경우, 리소스/이름 구문을 사용하여 커맨드 라인에서 둘다 모두 쉽게 지정할 수도 있다. 두 개의 리소스가 있는 경우, 리소스/이름 구문을 사용하여 커맨드 라인에서 둘다 모두 지정할 수도 있다.
```shell ```shell
kubectl delete deployments/my-nginx services/my-nginx-svc kubectl delete deployments/my-nginx services/my-nginx-svc
@ -85,10 +87,11 @@ deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted service "my-nginx-svc" deleted
``` ```
`kubectl` 은 입력을 받아들이는 것과 동일한 구문으로 리소스 이름을 출력하므로, `$()` 또는 `xargs` 를 사용하여 작업을 쉽게 연결할 수 있다. `kubectl` 은 입력을 받아들이는 것과 동일한 구문으로 리소스 이름을 출력하므로, `$()` 또는 `xargs` 를 사용하여 작업을 연결할 수 있다.
```shell ```shell
kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service) kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {}
``` ```
```shell ```shell
@ -262,7 +265,7 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
## 레이블 업데이트 ## 레이블 업데이트
새로운 리소스를 만들기 전에 기존 파드 및 기타 리소스의 레이블을 다시 지정해야 하는 경우가 있다. 이것은 `kubectl label` 로 수행할 수 있다. 새로운 리소스를 만들기 전에 기존 파드 및 기타 리소스의 레이블을 다시 지정해야 하는 경우가 있다. 이것은 `kubectl label` 로 수행할 수 있다.
예를 들어, 모든 nginx 파드에 프론트엔드 티어로 레이블을 지정하려면, 간단히 다음과 같이 실행한다. 예를 들어, 모든 nginx 파드에 프론트엔드 티어로 레이블을 지정하려면, 다음과 같이 실행한다.
```shell ```shell
kubectl label pods -l app=nginx tier=fe kubectl label pods -l app=nginx tier=fe
@ -299,6 +302,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
kubectl get pods my-nginx-v4-9gw19 -o yaml kubectl get pods my-nginx-v4-9gw19 -o yaml
``` ```
```shell ```shell
apiVersion: v1 apiVersion: v1
kind: pod kind: pod
@ -312,11 +316,12 @@ metadata:
## 애플리케이션 스케일링 ## 애플리케이션 스케일링
애플리케이션의 로드가 증가하거나 축소되면, `kubectl` 을 사용하여 쉽게 스케일링할 수 있다. 예를 들어, nginx 레플리카 수를 3에서 1로 줄이려면, 다음을 수행한다. 애플리케이션의 로드가 증가하거나 축소되면, `kubectl` 을 사용하여 애플리케이션을 스케일링한다. 예를 들어, nginx 레플리카 수를 3에서 1로 줄이려면, 다음을 수행한다.
```shell ```shell
kubectl scale deployment/my-nginx --replicas=1 kubectl scale deployment/my-nginx --replicas=1
``` ```
```shell ```shell
deployment.apps/my-nginx scaled deployment.apps/my-nginx scaled
``` ```
@ -326,6 +331,7 @@ deployment.apps/my-nginx scaled
```shell ```shell
kubectl get pods -l app=nginx kubectl get pods -l app=nginx
``` ```
```shell ```shell
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
my-nginx-2035384211-j5fhi 1/1 Running 0 30m my-nginx-2035384211-j5fhi 1/1 Running 0 30m
@ -336,6 +342,7 @@ my-nginx-2035384211-j5fhi 1/1 Running 0 30m
```shell ```shell
kubectl autoscale deployment/my-nginx --min=1 --max=3 kubectl autoscale deployment/my-nginx --min=1 --max=3
``` ```
```shell ```shell
horizontalpodautoscaler.autoscaling/my-nginx autoscaled horizontalpodautoscaler.autoscaling/my-nginx autoscaled
``` ```
@ -404,11 +411,12 @@ JSON 병합 패치 그리고 전략적 병합 패치를 지원한다.
## 파괴적(disruptive) 업데이트 ## 파괴적(disruptive) 업데이트
경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 간단히 수정할 수 있다. 경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 수정할 수 있다.
```shell ```shell
kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
``` ```
```shell ```shell
deployment.apps/my-nginx deleted deployment.apps/my-nginx deleted
deployment.apps/my-nginx replaced deployment.apps/my-nginx replaced
@ -425,19 +433,22 @@ nginx 1.14.2 버전을 실행한다고 가정해 보겠다.
```shell ```shell
kubectl create deployment my-nginx --image=nginx:1.14.2 kubectl create deployment my-nginx --image=nginx:1.14.2
``` ```
```shell ```shell
deployment.apps/my-nginx created deployment.apps/my-nginx created
``` ```
3개의 레플리카를 포함한다(이전과 새 개정판이 공존할 수 있음). 3개의 레플리카를 포함한다(이전과 새 개정판이 공존할 수 있음).
```shell ```shell
kubectl scale deployment my-nginx --current-replicas=1 --replicas=3 kubectl scale deployment my-nginx --current-replicas=1 --replicas=3
``` ```
``` ```
deployment.apps/my-nginx scaled deployment.apps/my-nginx scaled
``` ```
1.16.1 버전으로 업데이트하려면, 위에서 배운 kubectl 명령을 사용하여 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 간단히 변경한다. 1.16.1 버전으로 업데이트하려면, 위에서 배운 kubectl 명령을 사용하여 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 변경한다.
```shell ```shell
kubectl edit deployment/my-nginx kubectl edit deployment/my-nginx
@ -452,5 +463,3 @@ kubectl edit deployment/my-nginx
- [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/docs/tasks/debug-application-cluster/debug-application-introspection/)에 대해 알아본다. - [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/docs/tasks/debug-application-cluster/debug-application-introspection/)에 대해 알아본다.
- [구성 모범 사례 및 팁](/ko/docs/concepts/configuration/overview/)을 참고한다. - [구성 모범 사례 및 팁](/ko/docs/concepts/configuration/overview/)을 참고한다.

4
content/ko/docs/concepts/configuration/overview.md
View File

@ -59,13 +59,13 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
- `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.
- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. - `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
## 레이블 사용하기 ## 레이블 사용하기
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. - `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.

20
content/ko/docs/concepts/configuration/secret.md
View File

@ -1,4 +1,6 @@
--- ---
title: 시크릿(Secret) title: 시크릿(Secret)
content_type: concept content_type: concept
feature: feature:
@ -24,8 +26,8 @@ weight: 30
{{< caution >}} {{< caution >}}
쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다. 쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에 기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색 할 수 있다. 액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다. 시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/). 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
@ -280,9 +282,9 @@ API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
검증도 한다. 검증도 한다.
{{< caution >}} {{< caution >}}
SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버간에 신뢰할 수있는 통신을 SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버 간에 신뢰할 수 있는 통신을
설정하지 않는다. ConfigMap에 추가된 `known_hosts` 파일과 같은 설정하지 않는다. 컨피그맵(ConfigMap)에 추가된 `known_hosts` 파일과 같은
"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는 "중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는
2차 수단이 필요하다. 2차 수단이 필요하다.
{{< /caution >}} {{< /caution >}}
@ -667,7 +669,7 @@ kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신
그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다. 그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다. `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다.
시크릿은 watch(기본값), ttl 기반 또는 단순히 API 서버로 모든 요청을 직접 시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접
리디렉션하여 전파할 수 있다. 리디렉션하여 전파할 수 있다.
결과적으로, 시크릿이 업데이트된 순간부터 새로운 키가 파드에 투영되는 결과적으로, 시크릿이 업데이트된 순간부터 새로운 키가 파드에 투영되는
순간까지의 총 지연 시간은 kubelet 동기화 시간 + 캐시 순간까지의 총 지연 시간은 kubelet 동기화 시간 + 캐시
@ -799,11 +801,6 @@ immutable: true
해당 프로세스에 대한 자세한 설명은 해당 프로세스에 대한 자세한 설명은
[서비스 어카운트에 ImagePullSecrets 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 참고한다. [서비스 어카운트에 ImagePullSecrets 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 참고한다.
### 수동으로 생성된 시크릿의 자동 마운트
수동으로 생성된 시크릿(예: GitHub 계정에 접근하기 위한 토큰이 포함된 시크릿)은
시크릿의 서비스 어카운트를 기반한 파드에 자동으로 연결될 수 있다.
## 상세 내용 ## 상세 내용
### 제약 사항 ### 제약 사항
@ -1249,4 +1246,3 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 - [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기

30
content/ko/docs/concepts/containers/container-lifecycle-hooks.md
View File

@ -1,4 +1,7 @@
--- ---
title: 컨테이너 라이프사이클 훅(Hook) title: 컨테이너 라이프사이클 훅(Hook)
content_type: concept content_type: concept
weight: 30 weight: 30
@ -33,10 +36,13 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
`PreStop` `PreStop`
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다. 이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합
그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로, 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미
컨테이너를 중지하기 위한 신호가 전송되기 전에 완료되어야 한다. terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실패하며,
파라미터는 핸들러에 전달되지 않는다. 훅은 컨테이너를 중지하기 위한 TERM 신호가 보내지기 이전에 완료되어야 한다. 파드의 그레이스 종료
기간(termination grace period)의 초읽기는 `PreStop` 훅이 실행되기 전에 시작되어,
핸들러의 결과에 상관없이 컨테이너가 파드의 그레이스 종료 기간 내에 결국 종료되도록 한다.
어떠한 파라미터도 핸들러에게 전달되지 않는다.
종료 동작에 더 자세한 대한 설명은 종료 동작에 더 자세한 대한 설명은
[파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다. [파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다.
@ -62,17 +68,13 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면, 그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면,
컨테이너는 `running` 상태에 이르지 못한다. 컨테이너는 `running` 상태에 이르지 못한다.
`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로 `PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로 실행되지 않는다. 훅은
실행되지 않는다. 훅은 신호를 보내기 전에 실행을 TERM 신호를 보내기 전에 실행을 완료해야 한다. 실행 중에 `PreStop` 훅이 중단되면,
완료해야 한다.
실행 중에 `PreStop` 훅이 중단되면,
파드의 단계는 `Terminating` 이며 `terminationGracePeriodSeconds` 가 파드의 단계는 `Terminating` 이며 `terminationGracePeriodSeconds` 가
만료된 후 파드가 종료될 때까지 남아 있다. 만료된 후 파드가 종료될 때까지 남아 있다. 이 유예 기간은 `PreStop` 훅이
이 유예 기간은 `PreStop` 훅이 실행되고 컨테이너가 실행되고 컨테이너가 정상적으로 중지되는 데 걸리는 총 시간에 적용된다. 예를 들어,
정상적으로 중지되는 데 걸리는 총 시간에 적용된다. `terminationGracePeriodSeconds` 가 60이고, 훅이 완료되는 데 55초가 걸리고,
예를 들어, `terminationGracePeriodSeconds` 가 60이고, 훅이 컨테이너가 신호를 수신한 후 정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후
완료되는 데 55초가 걸리고, 컨테이너가 신호를 수신한 후
정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후
컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데 컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데
걸리는 총 시간(55+10)보다 적다. 걸리는 총 시간(55+10)보다 적다.

5
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -1,5 +1,8 @@
--- ---
title: 커스텀 리소스 title: 커스텀 리소스
content_type: concept content_type: concept
weight: 10 weight: 10
--- ---
@ -117,7 +120,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다. 쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다.
애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것과 같다. 애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다.
CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다. CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다.

6
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
View File

@ -1,4 +1,8 @@
--- ---
title: 네트워크 플러그인 title: 네트워크 플러그인
content_type: concept content_type: concept
weight: 10 weight: 10
@ -20,7 +24,7 @@ weight: 10
kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다. kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다. * `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 단순히 "cni"이다. * `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
## 네트워크 플러그인 요구 사항 ## 네트워크 플러그인 요구 사항

9
content/ko/docs/concepts/extend-kubernetes/service-catalog.md
View File

@ -1,5 +1,7 @@
--- ---
title: 서비스 카탈로그 title: 서비스 카탈로그
content_type: concept content_type: concept
weight: 40 weight: 40
--- ---
@ -24,7 +26,7 @@ weight: 40
클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다. 클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다.
따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다. 따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다.
애플리케이션은 그것을 서비스로 간단하게 사용할 수 있다. 애플리케이션은 메시지 큐에 서비스로 접속할 수 있다.
## 아키텍처 ## 아키텍처
@ -229,8 +231,3 @@ spec:
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 * [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기 * [svc-cat.io](https://svc-cat.io/docs/) 살펴보기

5
content/ko/docs/concepts/overview/what-is-kubernetes.md
View File

@ -1,4 +1,7 @@
--- ---
title: 쿠버네티스란 무엇인가? title: 쿠버네티스란 무엇인가?
description: > description: >
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다. 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다.
@ -40,7 +43,7 @@ sitemap:
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다. 컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임. * 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다. * 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다. * 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. * 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다. * 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.

25
content/ko/docs/concepts/overview/working-with-objects/labels.md
View File

@ -1,4 +1,6 @@
--- ---
title: 레이블과 셀렉터 title: 레이블과 셀렉터
content_type: concept content_type: concept
weight: 40 weight: 40
@ -40,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
* `"partition" : "customerA"`, `"partition" : "customerB"` * `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"` * `"track" : "daily"`, `"track" : "weekly"`
레이블 예시는 일반적으로 사용하는 상황에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다. 이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
## 구문과 캐릭터 셋 ## 구문과 캐릭터 셋
@ -90,14 +92,13 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
{{< /note >}} {{< /note >}}
{{< caution >}} {{< caution >}}
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
필터 구문이 적절히 구성되어있는지 확인해야 한다.
{{< /caution >}} {{< /caution >}}
### _일치성 기준_ 요건 ### _일치성 기준_ 요건
_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다. _일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다.
`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_ 를 의미한다. 예를 들면, `=`,`==`,`!=` 이 세 가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 동의어), 나머지는 _불일치_ 를 의미한다. 예를 들면,
``` ```
environment = production environment = production
@ -108,8 +109,9 @@ tier != frontend
후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다. 후자는 `tier`를 키로 가지고, 값을 `frontend`를 가지는 리소스를 제외한 모든 리소스를 선택하고, `tier`를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다.
`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다. `environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다.
균등-기반 레이블의 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다. 일치성 기준 레이블 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다. 예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`"
레이블을 가진 노드를 선택한다.
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@ -148,16 +150,17 @@ _집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=productio
_집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa` _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa`
## API ## API
### LIST와 WATCH 필터링 ### LIST와 WATCH 필터링
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함). LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 두 가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
* _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` * _일치성 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `apiserver`를 대상으로 _불일치 기준_ 으로 하는 셀렉터를 다음과 같이 이용할 수 있다. 두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, `kubectl`로 `apiserver`를 대상으로 _일치성 기준_ 으로 하는 셀렉터를 다음과 같이 이용할 수 있다.
```shell ```shell
kubectl get pods -l environment=production,tier=frontend kubectl get pods -l environment=production,tier=frontend
@ -192,7 +195,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다. `services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다.
서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다. 서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _일치성 기준_ 요구사항의 셀렉터만 지원한다.
```json ```json
"selector": { "selector": {
@ -208,7 +211,6 @@ selector:
`json` 또는 `yaml` 서식에서 셀렉터는 `component=redis` 또는 `component in (redis)` 모두 같은 것이다. `json` 또는 `yaml` 서식에서 셀렉터는 `component=redis` 또는 `component in (redis)` 모두 같은 것이다.
#### 세트-기반 요건을 지원하는 리소스 #### 세트-기반 요건을 지원하는 리소스
[`Job`](/ko/docs/concepts/workloads/controllers/job/), [`Job`](/ko/docs/concepts/workloads/controllers/job/),
@ -232,4 +234,3 @@ selector:
레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다. 자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다.

6
content/ko/docs/concepts/overview/working-with-objects/object-management.md
View File

@ -32,7 +32,7 @@ weight: 15
지정한다. 지정한다.
이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한 이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한
가장 단순한 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인 추천 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인
영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다. 영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다.
### 예시 ### 예시
@ -47,7 +47,7 @@ kubectl create deployment nginx --image nginx
오브젝트 구성에 비해 장점은 다음과 같다. 오브젝트 구성에 비해 장점은 다음과 같다.
- 커맨드는 간단해서 배우기 쉽고, 기억하기 쉽다. - 커맨드는 하나의 동작을 나타내는 단어로 표현된다.
- 커맨드는 클러스터를 수정하기 위해 단 하나의 단계만을 필요로 한다. - 커맨드는 클러스터를 수정하기 위해 단 하나의 단계만을 필요로 한다.
오브젝트 구성에 비해 단점은 다음과 같다. 오브젝트 구성에 비해 단점은 다음과 같다.
@ -125,7 +125,7 @@ kubectl replace -f nginx.yaml
선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 `kubectl`에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해
다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다. 다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
{{< note >}} {{< note >}}

29
content/ko/docs/concepts/policy/resource-quotas.md
View File

@ -1,4 +1,6 @@
--- ---
title: 리소스 쿼터 title: 리소스 쿼터
content_type: concept content_type: concept
weight: 20 weight: 20
@ -608,17 +610,28 @@ plugins:
values: ["cluster-services"] values: ["cluster-services"]
``` ```
이제 "cluster-services" 파드는 `scopeSelector`와 일치하는 쿼터 오브젝트가 있는 네임스페이스에서만 허용된다. 그리고, `kube-system` 네임스페이스에 리소스 쿼터 오브젝트를 생성한다.
예를 들면 다음과 같다.
```yaml {{< codenew file="policy/priority-class-resourcequota.yaml" >}}
scopeSelector:
matchExpressions: ```shell
- scopeName: PriorityClass $ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
operator: In
values: ["cluster-services"]
``` ```
```
resourcequota/pods-cluster-services created
```
이 경우, 파드 생성은 다음의 조건을 만족해야 허용될 것이다.
1. 파드의 `priorityClassName` 가 명시되지 않음.
1. 파드의 `priorityClassName` 가 `cluster-services` 이외의 다른 값으로 명시됨.
1. 파드의 `priorityClassName` 가 `cluster-services` 로 설정되고, 파드가 `kube-system`
네임스페이스에 생성되었으며 리소스 쿼터 검증을 통과함.
파드 생성 요청은 `priorityClassName` 가 `cluster-services` 로 명시되고
`kube-system` 이외의 다른 네임스페이스에 생성되는 경우, 거절된다.
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다. - 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다.

2
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -261,7 +261,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
`topologyKey` 의 빈 값을 허용하지 않는다. `topologyKey` 의 빈 값을 허용하지 않는다.
2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는
`topologyKey` 의 빈 값을 허용하지 않는다. `topologyKey` 의 빈 값을 허용하지 않는다.
3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다. 3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 이를 비활성화해야 한다.
4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다. 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를

2
content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
View File

@ -1,4 +1,6 @@
--- ---
title: 스케줄러 성능 튜닝 title: 스케줄러 성능 튜닝
content_type: concept content_type: concept
weight: 80 weight: 80

2
content/ko/docs/concepts/security/controlling-access.md
View File

@ -132,7 +132,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다. 이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다. API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다. 기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
1. `로컬호스트 포트`: 1. `로컬호스트 포트`:

2
content/ko/docs/concepts/security/overview.md
View File

@ -119,6 +119,7 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r
컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다. 컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다.
이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다. 이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다.
권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다. 권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다.
더 강력한 격리로 컨테이너 런타임 사용 | 더 강력한 격리를 제공하는 [컨테이너 런타임 클래스](/ko/docs/concepts/containers/runtime-class/)를 선택한다.
## 코드 ## 코드
@ -151,3 +152,4 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
* [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/) * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
* [런타임 클래스](/ko/docs/concepts/containers/runtime-class)

8
content/ko/docs/concepts/services-networking/dual-stack.md
View File

@ -35,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
* 쿠버네티스 1.20 이상 * 쿠버네티스 1.20 이상
이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보 이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
문서 참조 문서 참조
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인 * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
@ -69,9 +69,9 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,
클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다. 클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다.
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-controller-manager에 구성) 서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를
다음 값 중 하나로 설정한다. 다음 값 중 하나로 설정한다.
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
@ -158,7 +158,7 @@ status:
loadBalancer: {} loadBalancer: {}
``` ```
1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-controller-manager에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다. 1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}

10
content/ko/docs/concepts/services-networking/ingress-controllers.md
View File

@ -23,7 +23,7 @@ weight: 40
{{% thirdparty-content %}} {{% thirdparty-content %}}
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다. * [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
컨트롤러다. 컨트롤러다.
* [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
@ -31,13 +31,14 @@ weight: 40
* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를 * F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다. 이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
오픈소스 인그레스 컨트롤러다. 오픈소스 인그레스 컨트롤러다.
* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의 * [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](https://www.haproxy.org/#desc)의
인그레스 컨트롤러다. 인그레스 컨트롤러다.
* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용 * [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](https://www.haproxy.org/#desc) 용
인그레스 컨트롤러이기도 하다. 인그레스 컨트롤러이기도 하다.
* [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/) * [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/)
기반 인그레스 컨트롤러다. 기반 인그레스 컨트롤러다.
@ -48,8 +49,9 @@ weight: 40
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다. * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는 * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
[Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다. [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
* [Tyk 오퍼레이터](https://github.com/TykTechnologies/tyk-operator)는 사용자 지정 리소스로 인그레스를 확장하여 API 관리 기능을 인그레스로 가져온다. Tyk 오퍼레이터는 오픈 소스 Tyk 게이트웨이 및 Tyk 클라우드 컨트롤 플레인과 함께 작동한다.
* [Voyager](https://appscode.com/products/voyager)는 * [Voyager](https://appscode.com/products/voyager)는
[HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다. [HAProxy](https://www.haproxy.org/#desc)의 인그레스 컨트롤러다.
## 여러 인그레스 컨트롤러 사용 ## 여러 인그레스 컨트롤러 사용

8
content/ko/docs/concepts/services-networking/service.md
View File

@ -430,8 +430,8 @@ CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위
예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는 예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는
서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여 서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
`my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은 `my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은
간단히 `my-service`에 대한 이름 조회를 수행하여 찾을 수 있어야 한다 `my-service`(`my-service.my-ns` 역시 동작함)에 대한 이름 조회를
(`my-service.my-ns` 역시 동작함). 수행하여 서비스를 찾을 수 있어야 한다.
다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은 다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은
서비스에 할당된 클러스터 IP로 변환된다. 서비스에 할당된 클러스터 IP로 변환된다.
@ -463,7 +463,7 @@ DNS SRV 쿼리를 수행할 수 있다.
셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는 셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하여 API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하여
`서비스` 를 지원하는 `파드` 를 직접 가리키는 레코드 (주소)를 반환한다. `서비스` 를 지원하는 `파드` 를 직접 가리키는 A 레코드(IP 주소)를 반환한다.
### 셀렉터가 없는 경우 ### 셀렉터가 없는 경우
@ -1164,7 +1164,7 @@ IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정
이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을 이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을
의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에 의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에
간단히 연결할 수 있다. 연결할 수 있다.
#### iptables #### iptables

7
content/ko/docs/concepts/storage/persistent-volumes.md
View File

@ -487,7 +487,7 @@ PV는 `storageClassName` 속성을
* VsphereVolume * VsphereVolume
* iSCSI * iSCSI
마운트 옵션의 유효성이 검사되지 않으므로 마운트 옵션이 유효하지 않으면 마운트가 실패한다. 마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다.
이전에는 `mountOptions` 속성 대신 `volume.beta.kubernetes.io/mount-options` 어노테이션이 이전에는 `mountOptions` 속성 대신 `volume.beta.kubernetes.io/mount-options` 어노테이션이
사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만, 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만,
@ -629,6 +629,11 @@ spec:
퍼시스턴트볼륨 바인딩은 배타적이며, 퍼시스턴트볼륨클레임은 네임스페이스 오브젝트이므로 "다중" 모드(`ROX`, `RWX`)를 사용한 클레임은 하나의 네임스페이스 내에서만 가능하다. 퍼시스턴트볼륨 바인딩은 배타적이며, 퍼시스턴트볼륨클레임은 네임스페이스 오브젝트이므로 "다중" 모드(`ROX`, `RWX`)를 사용한 클레임은 하나의 네임스페이스 내에서만 가능하다.
### `hostPath` 유형의 퍼시스턴트볼륨
`hostPath` 퍼시스턴트볼륨은 노드의 파일이나 디렉터리를 사용하여 네트워크 연결 스토리지를 에뮬레이션한다.
[`hostPath` 유형 볼륨의 예](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)를 참고한다.
## 원시 블록 볼륨 지원 ## 원시 블록 볼륨 지원
{{< feature-state for_k8s_version="v1.18" state="stable" >}} {{< feature-state for_k8s_version="v1.18" state="stable" >}}

4
content/ko/docs/concepts/storage/storage-classes.md
View File

@ -143,8 +143,8 @@ CSI | 1.14 (alpha), 1.16 (beta)
클래스의 `mountOptions` 필드에 지정된 마운트 옵션을 가진다. 클래스의 `mountOptions` 필드에 지정된 마운트 옵션을 가진다.
만약 볼륨 플러그인이 마운트 옵션을 지원하지 않는데, 마운트 만약 볼륨 플러그인이 마운트 옵션을 지원하지 않는데, 마운트
옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV 에서 옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV에서
검증되지 않으므로 PV 마운트가 유효하지 않으면 마운트가 실패하게 된다. 검증되지 않는다. PV 마운트가 유효하지 않으면, 마운트가 실패하게 된다.
### 볼륨 바인딩 모드 ### 볼륨 바인딩 모드

4
content/ko/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -19,7 +19,7 @@ weight: 30
복제는 표준 볼륨처럼 소비할 수 있는 쿠버네티스 볼륨의 복제본으로 정의된다. 유일한 차이점은 프로비저닝할 때 "새" 빈 볼륨을 생성하는 대신에 백엔드 장치가 지정된 볼륨의 정확한 복제본을 생성한다는 것이다. 복제는 표준 볼륨처럼 소비할 수 있는 쿠버네티스 볼륨의 복제본으로 정의된다. 유일한 차이점은 프로비저닝할 때 "새" 빈 볼륨을 생성하는 대신에 백엔드 장치가 지정된 볼륨의 정확한 복제본을 생성한다는 것이다.
쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어있고, 사용가능해야 한다(사용 중이 아니어야함). 쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어 있고, 사용 가능해야 한다(사용 중이 아니어야 함).
사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다. 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.
@ -64,5 +64,3 @@ spec:
## 사용 ## 사용
새 PVC를 사용할 수 있게 되면, 복제된 PVC는 다른 PVC와 동일하게 소비된다. 또한, 이 시점에서 새롭게 생성된 PVC는 독립된 오브젝트이다. 원본 dataSource PVC와는 무관하게 독립적으로 소비하고, 복제하고, 스냅샷의 생성 또는 삭제를 할 수 있다. 이는 소스가 새롭게 생성된 복제본에 어떤 방식으로든 연결되어 있지 않으며, 새롭게 생성된 복제본에 영향 없이 수정하거나, 삭제할 수도 있는 것을 의미한다. 새 PVC를 사용할 수 있게 되면, 복제된 PVC는 다른 PVC와 동일하게 소비된다. 또한, 이 시점에서 새롭게 생성된 PVC는 독립된 오브젝트이다. 원본 dataSource PVC와는 무관하게 독립적으로 소비하고, 복제하고, 스냅샷의 생성 또는 삭제를 할 수 있다. 이는 소스가 새롭게 생성된 복제본에 어떤 방식으로든 연결되어 있지 않으며, 새롭게 생성된 복제본에 영향 없이 수정하거나, 삭제할 수도 있는 것을 의미한다.

6
content/ko/docs/concepts/storage/volumes.md
View File

@ -103,6 +103,8 @@ spec:
fsType: ext4 fsType: ext4
``` ```
EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition number>"` 를 제공하여 마운트할 파티션을 지정할 수 있다.
#### AWS EBS CSI 마이그레이션 #### AWS EBS CSI 마이그레이션
{{< feature-state for_k8s_version="v1.17" state="beta" >}} {{< feature-state for_k8s_version="v1.17" state="beta" >}}
@ -207,8 +209,8 @@ spec:
Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI
드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)를
를 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack` 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack`
베타 기능을 활성화해야 한다. 베타 기능을 활성화해야 한다.
### 컨피그맵(configMap) {#configmap} ### 컨피그맵(configMap) {#configmap}

5
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -89,6 +89,11 @@ kube-controller-manager 컨테이너에 설정된 시간대는
`concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은 `concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은
실행될 것이다. 실행될 것이다.
{{< caution >}}
`startingDeadlineSeconds` 가 10초 미만의 값으로 설정되면, 크론잡이 스케줄되지 않을 수 있다. 이는 크론잡 컨트롤러가 10초마다 항목을 확인하기 때문이다.
{{< /caution >}}
모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. 모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
```` ````

4
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -141,8 +141,8 @@ nodeAffinity:
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | | `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | | `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | | `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | 데몬셋 파드는 기본 스케줄러에서 디스크-압박(disk-pressure) 속성을 허용한다. |
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | | `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | 데몬셋 파드는 기본 스케줄러에서 메모리-압박(memory-pressure) 속성을 허용한다. |
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | | `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. |
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. |

23
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -45,7 +45,7 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
* `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다. * `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다.
* `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. * `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다.
* `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. * `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다.
이 사례에서는 간단하게 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다. 이 사례에서는 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다.
그러나 파드 템플릿 자체의 규칙이 만족되는 한, 그러나 파드 템플릿 자체의 규칙이 만족되는 한,
보다 정교한 선택 규칙의 적용이 가능하다. 보다 정교한 선택 규칙의 적용이 가능하다.
@ -169,13 +169,15 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```shell ```shell
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
``` ```
또는 간단하게 다음의 명령어를 사용한다.
또는 다음의 명령어를 사용한다.
```shell ```shell
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
``` ```
이와 유사하게 출력된다. 다음과 유사하게 출력된다.
``` ```
deployment.apps/nginx-deployment image updated deployment.apps/nginx-deployment image updated
``` ```
@ -186,7 +188,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
kubectl edit deployment.v1.apps/nginx-deployment kubectl edit deployment.v1.apps/nginx-deployment
``` ```
이와 유사하게 출력된다. 다음과 유사하게 출력된다.
``` ```
deployment.apps/nginx-deployment edited deployment.apps/nginx-deployment edited
``` ```
@ -198,10 +201,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
``` ```
이와 유사하게 출력된다. 이와 유사하게 출력된다.
``` ```
Waiting for rollout to finish: 2 out of 3 new replicas have been updated... Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
``` ```
또는 또는
``` ```
deployment "nginx-deployment" successfully rolled out deployment "nginx-deployment" successfully rolled out
``` ```
@ -210,10 +216,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
* 롤아웃이 성공하면 `kubectl get deployments` 를 실행해서 디플로이먼트를 볼 수 있다. * 롤아웃이 성공하면 `kubectl get deployments` 를 실행해서 디플로이먼트를 볼 수 있다.
이와 유사하게 출력된다. 이와 유사하게 출력된다.
```
NAME READY UP-TO-DATE AVAILABLE AGE ```ini
nginx-deployment 3/3 3 3 36s NAME READY UP-TO-DATE AVAILABLE AGE
``` nginx-deployment 3/3 3 3 36s
```
* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, * `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고,
새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다. 새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다.

9
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -180,7 +180,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용
Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를 Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를
삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다. 삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다.
REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다 (레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
레플리케이션 컨트롤러를 삭제). 레플리케이션 컨트롤러를 삭제).
### 레플리케이션 컨트롤러만 삭제 ### 레플리케이션 컨트롤러만 삭제
@ -189,7 +189,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라. kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라.
REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러 오브젝트를 삭제하라. REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면, 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
@ -208,7 +208,8 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
### 스케일링 ### 스케일링
레플리케이션 컨트롤러는 `replicas` 필드를 업데이트함으로써 수동으로 또는 오토 스케일링 제어 에이전트로 레플리카의 수를 쉽게 스케일 업하거나 스케일 다운할 수 있다. 레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다.
레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다.
### 롤링 업데이트 ### 롤링 업데이트
@ -239,7 +240,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
## 레플리케이션 컨트롤러의 책임 ## 레플리케이션 컨트롤러의 책임
레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다. 레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 셀렉터와 일치하고 동작하는지를 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.
레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된)가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019))을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170))까지도 고려해야 한다. 레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된)가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019))을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170))까지도 고려해야 한다.

2
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
View File

@ -100,7 +100,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
"apiVersion": "v1", "apiVersion": "v1",
"kind": "EphemeralContainers", "kind": "EphemeralContainers",
"metadata": { "metadata": {
"name": "example-pod" "name": "example-pod"
}, },
"ephemeralContainers": [{ "ephemeralContainers": [{
"command": [ "command": [

2
content/ko/docs/contribute/participate/roles-and-responsibilities.md
View File

@ -51,7 +51,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
- 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다. - 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다.
{{< note >}} {{< note >}}
`/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다! `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, "LGTM" 코멘트를 남기는 것도 좋다!
{{< /note >}} {{< /note >}}
- `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다. - `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다.

11
content/ko/docs/reference/access-authn-authz/authorization.md
View File

@ -99,6 +99,9 @@ DELETE | delete(개별 리소스), deletecollection(리소스 모음)
```bash ```bash
kubectl auth can-i create deployments --namespace dev kubectl auth can-i create deployments --namespace dev
``` ```
다음과 유사하게 출력된다.
``` ```
yes yes
``` ```
@ -106,6 +109,9 @@ yes
```shell ```shell
kubectl auth can-i create deployments --namespace prod kubectl auth can-i create deployments --namespace prod
``` ```
다음과 유사하게 출력된다.
``` ```
no no
``` ```
@ -116,6 +122,9 @@ no
```bash ```bash
kubectl auth can-i list secrets --namespace dev --as dave kubectl auth can-i list secrets --namespace dev --as dave
``` ```
다음과 유사하게 출력된다.
``` ```
no no
``` ```
@ -145,7 +154,7 @@ EOF
``` ```
생성된 `SelfSubjectAccessReview` 는 다음과 같다. 생성된 `SelfSubjectAccessReview` 는 다음과 같다.
``` ```yaml
apiVersion: authorization.k8s.io/v1 apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview kind: SelfSubjectAccessReview
metadata: metadata:

4
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -634,8 +634,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다. - `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
- `KubeletPodResources`: kubelet의 파드 리소스 GPRC 엔드포인트를 활성화한다. 자세한 내용은 - `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
[장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을
참고한다. 참고한다.
- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
`NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여

4
content/ko/docs/reference/kubectl/cheatsheet.md
View File

@ -191,7 +191,7 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
# 외부 도구 없이 디코딩된 시크릿 출력 # 외부 도구 없이 디코딩된 시크릿 출력
kubectl get secret ${secret_name} -o go-template='{{range $k,$v := .data}}{{$k}}={{$v|base64decode}}{{"\n"}}{{end}}' kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'
# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회 # 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
@ -334,7 +334,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
### 리소스 타입 ### 리소스 타입
단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-그룹)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: 단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-그룹과-버전-규칙)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열:
```bash ```bash
kubectl api-resources kubectl api-resources

4
content/ko/docs/reference/tools.md
View File

@ -20,9 +20,9 @@ content_type: concept
## Minikube ## Minikube
[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로 하는 [`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로
단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서 단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서
쉽게 구동시키는 도구이다. 실행하는 도구이다.
## 대시보드 ## 대시보드

2
content/ko/docs/setup/production-environment/container-runtimes.md
View File

@ -420,7 +420,7 @@ CRI-O를 시작한다.
```shell ```shell
sudo systemctl daemon-reload sudo systemctl daemon-reload
sudo systemctl start crio sudo systemctl enable crio --now
``` ```
자세한 사항은 [CRI-O 설치 가이드](https://github.com/cri-o/cri-o/blob/master/install.md)를 자세한 사항은 [CRI-O 설치 가이드](https://github.com/cri-o/cri-o/blob/master/install.md)를

8
content/ko/docs/setup/production-environment/tools/kops.md
View File

@ -39,7 +39,7 @@ kops는 자동화된 프로비저닝 시스템인데,
#### 설치 #### 설치
[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스코드로부터 빌드하는것도 역시 어렵지 않다). [releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스 코드로부터 빌드하는 것도 역시 편리하다).
{{< tabs name="kops_installation" >}} {{< tabs name="kops_installation" >}}
{{% tab name="macOS" %}} {{% tab name="macOS" %}}
@ -51,7 +51,7 @@ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://
| grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64 | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
``` ```
특정 버전을 다운로드 받는다면 명령의 다음부분을 특정 kops 버전으로 변경한다. 특정 버전을 다운로드 받는다면 명령의 다음 부분을 특정 kops 버전으로 변경한다.
```shell ```shell
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
@ -147,8 +147,8 @@ Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone
`dev` NS 레코드를 `example.com`에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은 `dev` NS 레코드를 `example.com`에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은
도메인 등록기관을 통해서 생성해야 한다(예를 들어, `example.com`는 `example.com`를 구매한 곳에서 설정 할 수 있다). 도메인 등록기관을 통해서 생성해야 한다(예를 들어, `example.com`는 `example.com`를 구매한 곳에서 설정 할 수 있다).
이 단계에서 문제가 되기 쉽다.(문제를 만드는 가장 큰 이유이다!) dig 툴을 실행해서 route53 도메인 설정을 확인한다(문제를 만드는 가장 큰 이유이다!). dig 툴을 실행해서
클러스터 설정이 정확한지 한번 더 확인 한다. 클러스터 설정이 정확한지 한번 더 확인한다.
`dig NS dev.example.com` `dig NS dev.example.com`

4
content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
View File

@ -76,9 +76,7 @@ kind: ClusterConfiguration
kubernetesVersion: v1.16.0 kubernetesVersion: v1.16.0
scheduler: scheduler:
extraArgs: extraArgs:
address: 0.0.0.0 bind-address: 0.0.0.0
config: /home/johndoe/schedconfig.yaml config: /home/johndoe/schedconfig.yaml
kubeconfig: /home/johndoe/kubeconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml
``` ```

321
content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md Normal file
View File

@ -0,0 +1,321 @@
---
title: kubeadm 설치하기
content_type: task
weight: 10
card:
name: setup
weight: 20
title: kubeadm 설정 도구 설치
---
<!-- overview -->
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">이 페이지에서는 `kubeadm` 툴박스를 설치하는 방법을 보여준다.
이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm을 사용하여 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다.
## {{% heading "prerequisites" %}}
* 다음 중 하나를 실행하는 하나 이상의 머신이 필요하다.
- Ubuntu 16.04+
- Debian 9+
- CentOS 7+
- Red Hat Enterprise Linux (RHEL) 7+
- Fedora 25+
- HypriotOS v1.0.1+
- Flatcar Container Linux (2512.3.0으로 테스트됨)
* 2 GB 이상의 램을 장착한 머신. (이 보다 작으면 사용자의 앱을 위한 공간이 거의 남지 않음)
* 2 이상의 CPU.
* 클러스터의 모든 머신에 걸친 전체 네트워크 연결. (공용 또는 사설 네트워크면 괜찮음)
* 모든 노드에 대해 고유한 호스트 이름, MAC 주소 및 product_uuid. 자세한 내용은 [여기](#verify-mac-address)를 참고한다.
* 컴퓨터의 특정 포트들 개방. 자세한 내용은 [여기](#check-required-ports)를 참고한다.
* 스왑의 비활성화. kubelet이 제대로 작동하게 하려면 **반드시** 스왑을 사용하지 않도록 설정한다.
<!-- steps -->
## MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인 {#verify-mac-address}
* 사용자는 `ip link` 또는 `ifconfig -a` 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 확인할 수 있다.
* product_uuid는 `sudo cat /sys/class/dmi/id/product_uuid` 명령을 사용하여 확인할 수 있다.
일부 가상 머신은 동일한 값을 가질 수 있지만 하드웨어 장치는 고유한 주소를 가질
가능성이 높다. 쿠버네티스는 이러한 값을 사용하여 클러스터의 노드를 고유하게 식별한다.
이러한 값이 각 노드에 고유하지 않으면 설치 프로세스가
[실패](https://github.com/kubernetes/kubeadm/issues/31)할 수 있다.
## 네트워크 어댑터 확인
네트워크 어댑터가 두 개 이상이고, 쿠버네티스 컴포넌트가 디폴트 라우트(default route)에서 도달할 수 없는
경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다.
## iptables가 브리지된 트래픽을 보게 하기
`br_netfilter` 모듈이 로드되었는지 확인한다. `lsmod | grep br_netfilter` 를 실행하면 된다. 명시적으로 로드하려면 `sudo modprobe br_netfilter` 를 실행한다.
리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables` 가 1로 설정되어 있는지 확인해야 한다. 다음은 예시이다.
```bash
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system
```
자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다.
## 필수 포트 확인 {#check-required-ports}
### 컨트롤 플레인 노드
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용자 |
|----------|-----------|------------|-------------------------|---------------------------|
| TCP | 인바운드 | 6443* | 쿠버네티스 API 서버 | 모두 |
| TCP | 인바운드 | 2379-2380 | etcd 서버 클라이언트 API | kube-apiserver, etcd |
| TCP | 인바운드 | 10250 | kubelet API | 자체, 컨트롤 플레인 |
| TCP | 인바운드 | 10251 | kube-scheduler | 자체 |
| TCP | 인바운드 | 10252 | kube-controller-manager | 자체 |
### 워커 노드
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용자 |
|----------|-----------|-------------|-----------------------|-------------------------|
| TCP | 인바운드 | 10250 | kubelet API | 자체, 컨트롤 플레인 |
| TCP | 인바운드 | 30000-32767 | NodePort 서비스† | 모두 |
† [NodePort 서비스](/ko/docs/concepts/services-networking/service/)의 기본 포트 범위.
*로 표시된 모든 포트 번호는 재정의할 수 있으므로, 사용자 지정 포트도
열려 있는지 확인해야 한다.
etcd 포트가 컨트롤 플레인 노드에 포함되어 있지만, 외부 또는 사용자 지정 포트에서
자체 etcd 클러스터를 호스팅할 수도 있다.
사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한
플러그인 문서를 참고한다.
## 런타임 설치 {#installing-runtime}
파드에서 컨테이너를 실행하기 위해, 쿠버네티스는
{{< glossary_tooltip term_id="container-runtime" text="컨테이너 런타임" >}}을 사용한다.
{{< tabs name="container_runtime" >}}
{{% tab name="리눅스 노드" %}}
기본적으로, 쿠버네티스는
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를
사용하여 사용자가 선택한 컨테이너 런타임과 인터페이스한다.
런타임을 지정하지 않으면, kubeadm은 잘 알려진 유닉스 도메인 소켓 목록을 검색하여
설치된 컨테이너 런타임을 자동으로 감지하려고 한다.
다음 표에는 컨테이너 런타임 및 관련 소켓 경로가 나열되어 있다.
{{< table caption = "컨테이너 런타임과 소켓 경로" >}}
| 런타임 | 유닉스 도메인 소켓 경로 |
|------------|-----------------------------------|
| 도커 | `/var/run/docker.sock` |
| containerd | `/run/containerd/containerd.sock` |
| CRI-O | `/var/run/crio/crio.sock` |
{{< /table >}}
<br />
도커와 containerd가 모두 감지되면 도커가 우선시된다. 이것이 필요한 이유는 도커 18.09에서
도커만 설치한 경우에도 containerd와 함께 제공되므로 둘 다 감지될 수 있기
때문이다.
다른 두 개 이상의 런타임이 감지되면, kubeadm은 오류와 함께 종료된다.
kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다.
자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을
참고한다.
{{% /tab %}}
{{% tab name="다른 운영 체제" %}}
기본적으로, kubeadm은 컨테이너 런타임으로 {{< glossary_tooltip term_id="docker" >}}를 사용한다.
kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다.
자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을
참고한다.
{{% /tab %}}
{{< /tabs >}}
## kubeadm, kubelet 및 kubectl 설치
모든 머신에 다음 패키지들을 설치한다.
* `kubeadm`: 클러스터를 부트스트랩하는 명령이다.
* `kubelet`: 클러스터의 모든 머신에서 실행되는 파드와 컨테이너 시작과
같은 작업을 수행하는 컴포넌트이다.
* `kubectl`: 클러스터와 통신하기 위한 커맨드 라인 유틸리티이다.
kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으므로**, kubeadm이
설치하려는 쿠버네티스 컨트롤 플레인의 버전과 일치하는지
확인해야 한다. 그렇지 않으면, 예상치 못한 버그 동작으로 이어질 수 있는
버전 차이(skew)가 발생할 위험이 있다. 그러나, kubelet과 컨트롤 플레인 사이에 _하나의_
마이너 버전 차이가 지원되지만, kubelet 버전은 API 서버 버전 보다
높을 수 없다. 예를 들어, 1.7.0 버전의 kubelet은 1.8.0 API 서버와 완전히 호환되어야 하지만,
그 반대의 경우는 아니다.
`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다.
{{< warning >}}
이 지침은 모든 시스템 업그레이드에서 모든 쿠버네티스 패키지를 제외한다.
이는 kubeadm 및 쿠버네티스를
[업그레이드 하는 데 특별한 주의](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)가 필요하기 때문이다.
{{</ warning >}}
버전 차이에 대한 자세한 내용은 다음을 참고한다.
* 쿠버네티스 [버전 및 버전-차이 정책](/docs/setup/release/version-skew-policy/)
* Kubeadm 관련 [버전 차이 정책](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
```bash
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
```bash
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF
# permissive 모드로 SELinux 설정(효과적으로 비활성화)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
sudo systemctl enable --now kubelet
```
**참고:**
- `setenforce 0` 및 `sed ...` 를 실행하여 permissive 모드로 SELinux를 설정하면 효과적으로 비활성화된다.
컨테이너가 호스트 파일시스템(예를 들어, 파드 네트워크에 필요한)에 접근하도록 허용하는 데 필요하다.
kubelet에서 SELinux 지원이 개선될 때까지 이 작업을 수행해야 한다.
- 구성 방법을 알고 있는 경우 SELinux를 활성화된 상태로 둘 수 있지만 kubeadm에서 지원하지 않는 설정이 필요할 수 있다.
{{% /tab %}}
{{% tab name="Fedora CoreOS 또는 Flatcar Container Linux" %}}
CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
```bash
CNI_VERSION="v0.8.2"
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
```
명령어 파일을 다운로드할 디렉터리 정의
{{< note >}}
`DOWNLOAD_DIR` 변수는 쓰기 가능한 디렉터리로 설정되어야 한다.
Flatcar Container Linux를 실행 중인 경우, `DOWNLOAD_DIR=/opt/bin` 을 설정한다.
{{< /note >}}
```bash
DOWNLOAD_DIR=/usr/local/bin
sudo mkdir -p $DOWNLOAD_DIR
```
crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요)
```bash
CRICTL_VERSION="v1.17.0"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
```
`kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가
```bash
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}
RELEASE_VERSION="v0.4.0"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
sudo mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
```
`kubelet` 활성화 및 시작
```bash
systemctl enable --now kubelet
```
{{< note >}}
Flatcar Container Linux 배포판은 `/usr` 디렉터리를 읽기 전용 파일시스템으로 마운트한다.
클러스터를 부트스트랩하기 전에, 쓰기 가능한 디렉터리를 구성하기 위한 추가 단계를 수행해야 한다.
쓰기 가능한 디렉터리를 설정하는 방법을 알아 보려면 [Kubeadm 문제 해결 가이드](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only/)를 참고한다.
{{< /note >}}
{{% /tab %}}
{{< /tabs >}}
kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로
기다려야 하므로 몇 초마다 다시 시작된다.
## 컨트롤 플레인 노드에서 kubelet이 사용하는 cgroup 드라이버 구성
도커를 사용할 때, kubeadm은 kubelet 용 cgroup 드라이버를 자동으로 감지하여
런타임 중에 `/var/lib/kubelet/config.yaml` 파일에 설정한다.
다른 CRI를 사용하는 경우, 다음과 같이 `cgroupDriver` 값을 `kubeadm init` 에 전달해야 한다.
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: <value>
```
자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)을 참고한다.
`cgroupfs` 가 이미 kubelet의 기본값이기 때문에, 사용자의
CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이 설정해야 한다.
{{< note >}}
`--cgroup-driver` 플래그가 kubelet에 의해 사용 중단되었으므로, `/var/lib/kubelet/kubeadm-flags.env`
또는 `/etc/default/kubelet`(RPM에 대해서는 `/etc/sysconfig/kubelet`)에 있는 경우, 그것을 제거하고 대신 KubeletConfiguration을
사용한다(기본적으로 `/var/lib/kubelet/config.yaml` 에 저장됨).
{{< /note >}}
CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의
자동 감지에 대한 작업이 진행 중이다.
## 문제 해결
kubeadm에 문제가 있는 경우, [문제 해결 문서](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)를 참고한다.
## {{% heading "whatsnext" %}}
* [kubeadm을 사용하여 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)

4
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -12,7 +12,7 @@ weight: 65
## 쿠버네티스의 윈도우 컨테이너 ## 쿠버네티스의 윈도우 컨테이너
쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다. 쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다.
윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다. 윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다.
@ -544,7 +544,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
1. `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다. 1. `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다.
이 [조사 중인 이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때 타이밍 이슈일 가능성이 높다. 해결 방법은 간단히 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다. 이 [이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다.
```powershell ```powershell
PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>") PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")

4
content/ko/docs/setup/release/notes.md
View File

@ -92,7 +92,7 @@ We expect this implementation to progress from alpha to beta and GA in coming re
### go1.15.5 ### go1.15.5
go1.15.5 has been integrated to Kubernets project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776). go1.15.5 has been integrated to Kubernetes project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776).
### CSI 볼륨 스냅샷(CSI Volume Snapshot)이 안정 기능으로 전환 ### CSI 볼륨 스냅샷(CSI Volume Snapshot)이 안정 기능으로 전환
@ -190,7 +190,7 @@ Currently, cadvisor_stats_provider provides AcceleratorStats but cri_stats_provi
PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible. PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible.
kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly. kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly.
Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle]
- The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration infromation available in --help description for --exprimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123)) - The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration information available in --help description for --experimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123))
- Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] - Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows]
- The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42), [SIG API Machinery, Node, Testing]) - The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42), [SIG API Machinery, Node, Testing])
- Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. - Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API.

2
content/ko/docs/tasks/access-application-cluster/access-cluster.md
View File

@ -280,7 +280,7 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi
#### 수작업으로 apiserver proxy URL을 구축 #### 수작업으로 apiserver proxy URL을 구축
위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다.
당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다.

2
content/ko/docs/tasks/administer-cluster/access-cluster-api.md
View File

@ -216,7 +216,7 @@ for i in ret.items:
#### Java 클라이언트 {#java-client} #### Java 클라이언트 {#java-client}
* [Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다. [Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다.
```shell ```shell
# java 라이브러리를 클론한다 # java 라이브러리를 클론한다

2
content/ko/docs/tasks/administer-cluster/access-cluster-services.md
View File

@ -83,7 +83,7 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi
#### apiserver 프록시 URL 수동 구성 #### apiserver 프록시 URL 수동 구성
위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 단순히 서비스의 프록시 URL에 추가하면 된다. 위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다.
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy` `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. 포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다.

2
content/ko/docs/tasks/administer-cluster/change-default-storage-class.md
View File

@ -32,7 +32,7 @@ content_type: task
수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
하여 스토리지의 동적 프로비저닝을 방지할 수 있다. 하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동 중인
애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. 및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.

16
content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
View File

@ -9,18 +9,13 @@ weight: 100
이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을
사용하는 파드를 생성하는 방법을 보여준다. 사용하는 파드를 생성하는 방법을 보여준다.
## {{% heading "prerequisites" %}} ## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* 이 실습을 수행하기 위해, * 이 실습을 수행하기 위해,
[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다. [도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다.
<!-- steps --> <!-- steps -->
## 도커 로그인 ## 도커 로그인
@ -106,7 +101,8 @@ kubectl create secret docker-registry regcred --docker-server=<your-registry-ser
아래의 각 항목에 대한 설명을 참고한다. 아래의 각 항목에 대한 설명을 참고한다.
* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다. (도커허브(DockerHub)의 경우, https://index.docker.io/v1/) * `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다.
도커허브(DockerHub)는 `https://index.docker.io/v2/` 를 사용한다.
* `<your-name>` 은 도커 사용자의 계정이다. * `<your-name>` 은 도커 사용자의 계정이다.
* `<your-pword>` 은 도커 사용자의 비밀번호이다. * `<your-pword>` 은 도커 사용자의 비밀번호이다.
* `<your-email>` 은 도커 사용자의 이메일 주소이다. * `<your-email>` 은 도커 사용자의 이메일 주소이다.
@ -192,7 +188,8 @@ your.private.registry.example.com/janedoe/jdoe-private:v1
``` ```
프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다. 프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다.
구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가 `regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다. 구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가
`regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다.
시크릿을 사용해서 파드를 생성하고, 파드가 실행되는지 확인하자. 시크릿을 사용해서 파드를 생성하고, 파드가 실행되는지 확인하자.
@ -201,16 +198,11 @@ kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg kubectl get pod private-reg
``` ```
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기. * [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
* [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기. * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
* [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기. * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
* [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기. * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기. * [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기.
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기. * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기.

1
content/ko/docs/tasks/configure-pod-container/static-pod.md
View File

@ -22,6 +22,7 @@ Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버
생성하려고 자동으로 시도한다. 생성하려고 자동으로 시도한다.
즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, 즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만,
API 서버에서 제어될 수는 없다. API 서버에서 제어될 수는 없다.
파드 이름에는 노드 호스트 이름 앞에 하이픈을 붙여 접미사로 추가된다.
{{< note >}} {{< note >}}
만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여

121
content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
View File

@ -1,121 +0,0 @@
---
content_type: concept
title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로깅
---
<!-- overview -->
Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은
[스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는
[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다.
이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로,
[엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고
[키바나](https://www.elastic.co/products/kibana)를 사용하여 볼 수 있도록
클러스터를 설정하는 방법에 대해 설명한다.
{{< note >}}
Google 쿠버네티스 엔진(Kubernetes Engine)에서 호스팅되는 쿠버네티스 클러스터에는 엘라스틱서치 및 키바나를 자동으로 배포할 수 없다. 수동으로 배포해야 한다.
{{< /note >}}
<!-- body -->
클러스터 로깅에 엘라스틱서치, 키바나를 사용하려면 kube-up.sh를 사용하여
클러스터를 생성할 때 아래와 같이 다음의 환경 변수를
설정해야 한다.
```shell
KUBE_LOGGING_DESTINATION=elasticsearch
```
또한 `KUBE_ENABLE_NODE_LOGGING=true`(GCE 플랫폼의 기본값)인지 확인해야 한다.
이제, 클러스터를 만들 때, 각 노드에서 실행되는 Fluentd 로그 수집 데몬이
엘라스틱서치를 대상으로 한다는 메시지가 나타난다.
```shell
cluster/kube-up.sh
```
```
...
Project: kubernetes-satnam
Zone: us-central1-b
... calling kube-up
Project: kubernetes-satnam
Zone: us-central1-b
+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
Looking for already existing resources
Starting master and configuring firewalls
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
NAME ZONE SIZE_GB TYPE STATUS
kubernetes-master-pd us-central1-b 20 pd-ssd READY
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
+++ Logging using Fluentd to elasticsearch
```
노드별 Fluentd 파드, 엘라스틱서치 파드 및 키바나 파드는
클러스터가 활성화된 직후 kube-system 네임스페이스에서 모두 실행되어야
한다.
```shell
kubectl get pods --namespace=kube-system
```
```
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
kibana-logging-v1-bhpo8 1/1 Running 0 2h
kube-dns-v3-7r1l9 3/3 Running 0 2h
monitoring-heapster-v4-yl332 1/1 Running 1 2h
monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
```
`fluentd-elasticsearch` 파드는 각 노드에서 로그를 수집하여
`elasticsearch-logging` 파드로 전송한다. 이 로그는 `elasticsearch-logging` 이라는
[서비스](/ko/docs/concepts/services-networking/service/)의 일부이다. 이
엘라스틱서치 파드는 로그를 저장하고 REST API를 통해 노출한다.
`kibana-logging` 파드는 엘라스틱서치에 저장된 로그를 읽기 위한 웹 UI를
제공하며, `kibana-logging` 이라는 서비스의 일부이다.
엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에
있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해,
[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에
대한 지침을 참고한다.
브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면,
다음과 같은 상태 페이지가 표시된다.
![엘라스틱서치 상태](/images/docs/es-browser.png)
원할 경우, 이제 엘라스틱서치 쿼리를 브라우저에 직접 입력할 수
있다. 수행 방법에 대한 자세한 내용은 [엘라스틱서치의 문서](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)를
참조한다.
또는, 키바나를 사용하여 클러스터의 로그를 볼 수도 있다(다시
[클러스터에서 실행되는 서비스에 접근하기 위한 지침](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)을 참고).
키바나 URL을 처음 방문하면 수집된 로그 보기를
구성하도록 요청하는 페이지가 표시된다. 시계열 값에
대한 옵션을 선택하고 `@timestamp` 를 선택한다. 다음 페이지에서
`Discover` 탭을 선택하면 수집된 로그를 볼 수 있다.
로그를 정기적으로 새로 고치려면 새로 고침 간격을 5초로
설정할 수 있다.
키바나 뷰어에서 수집된 로그의 일반적인 보기는 다음과 같다.
![키바나 로그](/images/docs/kibana-logs.png)
## {{% heading "whatsnext" %}}
키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한
아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다.

24
content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md
View File

@ -22,7 +22,7 @@ content_type: task
## kubectl 플러그인 설치 ## kubectl 플러그인 설치
플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 간단히 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다. 플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.
[Krew](https://krew.dev/)를 사용하여 오픈소스에서 사용 가능한 [Krew](https://krew.dev/)를 사용하여 오픈소스에서 사용 가능한
kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는 kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는
@ -57,9 +57,9 @@ Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사
플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은 플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은
`kubectl` 바이너리에서 상속된 환경을 받는다. `kubectl` 바이너리에서 상속된 환경을 받는다.
플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다. 예를 플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다.
들어, 새로운 명령인 `kubectl foo` 를 제공하려는 플러그인은 단순히 이름이 예를 들어, `kubectl-foo` 라는 플러그인은 `kubectl foo` 명령을 제공한다.
`kubectl-foo` 이고, `PATH` 의 어딘가에 있다. `PATH` 어딘가에 플러그인 실행 파일을 설치해야 한다.
### 플러그인 예제 ### 플러그인 예제
@ -85,30 +85,31 @@ echo "I am a plugin named kubectl-foo"
### 플러그인 사용 ### 플러그인 사용
위의 플러그인을 사용하려면, 간단히 실행 가능하게 만든다. 플러그인을 사용하려면, 실행 가능하게 만든다.
``` ```shell
sudo chmod +x ./kubectl-foo sudo chmod +x ./kubectl-foo
``` ```
그리고 `PATH` 의 어느 곳에나 옮겨 놓는다. 그리고 `PATH` 의 어느 곳에나 옮겨 놓는다.
``` ```shell
sudo mv ./kubectl-foo /usr/local/bin sudo mv ./kubectl-foo /usr/local/bin
``` ```
이제 플러그인을 `kubectl` 명령으로 호출할 수 있다. 이제 플러그인을 `kubectl` 명령으로 호출할 수 있다.
``` ```shell
kubectl foo kubectl foo
``` ```
``` ```
I am a plugin named kubectl-foo I am a plugin named kubectl-foo
``` ```
모든 인수와 플래그는 그대로 실행 파일로 전달된다. 모든 인수와 플래그는 그대로 실행 파일로 전달된다.
``` ```shell
kubectl foo version kubectl foo version
``` ```
``` ```
@ -120,6 +121,7 @@ kubectl foo version
```bash ```bash
export KUBECONFIG=~/.kube/config export KUBECONFIG=~/.kube/config
kubectl foo config kubectl foo config
``` ```
``` ```
/home/<user>/.kube/config /home/<user>/.kube/config
@ -128,6 +130,7 @@ kubectl foo config
```shell ```shell
KUBECONFIG=/etc/kube/config kubectl foo config KUBECONFIG=/etc/kube/config kubectl foo config
``` ```
``` ```
/etc/kube/config /etc/kube/config
``` ```
@ -373,11 +376,8 @@ kubectl 플러그인의 배포 패키지를
컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가 컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가
더 쉬워진다. 더 쉬워진다.
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* Go로 작성된 플러그인의 * Go로 작성된 플러그인의
[자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는 [자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는
샘플 CLI 플러그인 리포지터리를 확인한다. 샘플 CLI 플러그인 리포지터리를 확인한다.

2
content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md
View File

@ -35,7 +35,7 @@ weight: 30
## 메시지 대기열 서비스 시작 ## 메시지 대기열 서비스 시작
이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다. 이 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 유형의 메시지 서비스를 사용하도록 예시를 조정할 수 있다.
실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번 실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번
구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다. 구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다.

2
content/ko/docs/tasks/job/parallel-processing-expansion.md
View File

@ -12,7 +12,7 @@ weight: 20
있다. 있다.
이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다. 이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다.
샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다. 샘플 잡들은 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면 이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면
[실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다. [실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다.

2
content/ko/docs/tasks/run-application/delete-stateful-set.md
View File

@ -60,7 +60,7 @@ PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
### 스테이트풀셋의 완벽한 삭제 ### 스테이트풀셋의 완벽한 삭제
연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다. 연결된 파드를 포함해서 스테이트풀셋의 모든 것을 삭제하기 위해 다음과 같이 일련의 명령을 실행한다.
```shell ```shell
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}') grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')

22
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -190,7 +190,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다. `kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다. 마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
또한 Horizontal Pod Autoscaler를 쉽게 생성 할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다. 또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을 예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`, 실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
그리고 2와 5 사이의 레플리카 개수로 설정된다. 그리고 2와 5 사이의 레플리카 개수로 설정된다.
@ -220,9 +220,10 @@ v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한 v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
필요성을 제거하였다. 필요성을 제거하였다.
- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은 - `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을 안정화되기까지의 시간 간격을 지정한다.
수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다. Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
이 시간 간격에서의 가장 큰 크기에서만 작동한다.
기본값은 5분(`5m0s`)이다. 기본값은 5분(`5m0s`)이다.
{{< note >}} {{< note >}}
@ -382,7 +383,12 @@ behavior:
periodSeconds: 60 periodSeconds: 60
``` ```
파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다. `periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
첫 번째 정책은 _(파드들)_ 이 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
두 번째 정책은 _비율_ 로 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
기본적으로 가장 많은 변경을 허용하는 정책이 선택되기에 두 번째 정책은
파드의 레플리카 수가 40개를 초과하는 경우에만 사용된다. 레플리카가 40개 이하인 경우 첫 번째 정책이 적용된다.
예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는 예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때 경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의 다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
@ -390,10 +396,6 @@ behavior:
미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에 미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에
4개의 레플리카가 줄어든다. 4개의 레플리카가 줄어든다.
`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다. 확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다. 레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히 값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
@ -440,7 +442,7 @@ behavior:
periodSeconds: 15 periodSeconds: 15
selectPolicy: Max selectPolicy: Max
``` ```
안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된 안정화 윈도우의 스케일링 다운의 경우 _300_ 초 (또는 제공된
경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재 경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재
실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링 실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다. 대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.

6
content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
View File

@ -65,6 +65,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
kubectl describe deployment mysql kubectl describe deployment mysql
출력은 다음과 유사하다.
Name: mysql Name: mysql
Namespace: default Namespace: default
CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700 CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700
@ -105,6 +107,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
kubectl get pods -l app=mysql kubectl get pods -l app=mysql
출력은 다음과 유사하다.
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
mysql-63082529-2z3ki 1/1 Running 0 3m mysql-63082529-2z3ki 1/1 Running 0 3m
@ -112,6 +116,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
kubectl describe pvc mysql-pv-claim kubectl describe pvc mysql-pv-claim
출력은 다음과 유사하다.
Name: mysql-pv-claim Name: mysql-pv-claim
Namespace: default Namespace: default
StorageClass: StorageClass:

2
content/ko/docs/tutorials/_index.md
View File

@ -33,7 +33,7 @@ content_type: concept
* [외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기](/ko/docs/tutorials/stateless-application/expose-external-ip-address/) * [외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기](/ko/docs/tutorials/stateless-application/expose-external-ip-address/)
* [예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/) * [예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/)
## 상태 유지가 필요한(stateful) 애플리케이션 ## 상태 유지가 필요한(stateful) 애플리케이션

3
content/ko/docs/tutorials/clusters/apparmor.md
View File

@ -168,8 +168,7 @@ k8s-apparmor-example-deny-write (enforce)
*이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.* *이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.*
먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 단순히 먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 파일 쓰기를 거부한다.
파일 쓰기를 거부할 것이다.
```shell ```shell
#include <tunables/global> #include <tunables/global>

2
content/ko/docs/tutorials/kubernetes-basics/_index.html
View File

@ -41,7 +41,7 @@ card:
<div class="row"> <div class="row">
<div class="col-md-9"> <div class="col-md-9">
<h2>쿠버네티스가 어떤 도움이 될까?</h2> <h2>쿠버네티스가 어떤 도움이 될까?</h2>
<p>오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 쉽고 빠르게 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.</p> <p>오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.</p>
</div> </div>
</div> </div>

6
content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
View File

@ -64,12 +64,6 @@ weight: 10
</div> </div>
</div> </div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg" width="150%" height="150%"></p>
</div>
</div>
<div class="row"> <div class="row">
<div class="col-md-8"> <div class="col-md-8">
<p>서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다. 여러분의 애플리케이션에 영향을 주지 않으면서 쿠버네티스에서 파드들이 죽게도 하고, 복제가 되게도 해주는 추상적 개념이다. 종속적인 파드들 사이에서의 디스커버리와 라우팅은 (하나의 애플리케이션에서 프로트엔드와 백엔드 컴포넌트와 같은) 쿠버네티스 서비스들에 의해 처리된다.</p> <p>서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다. 여러분의 애플리케이션에 영향을 주지 않으면서 쿠버네티스에서 파드들이 죽게도 하고, 복제가 되게도 해주는 추상적 개념이다. 종속적인 파드들 사이에서의 디스커버리와 라우팅은 (하나의 애플리케이션에서 프로트엔드와 백엔드 컴포넌트와 같은) 쿠버네티스 서비스들에 의해 처리된다.</p>

11
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
View File

@ -921,7 +921,7 @@ web-2 0/1 Terminating 0 3m
`web` 스테이트풀셋이 다시 생성될 때 먼저 `web-0` 시작한다. `web` 스테이트풀셋이 다시 생성될 때 먼저 `web-0` 시작한다.
`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로 `web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로
전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고 전환될 때는 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고
`web-0`을 재생성했다면 `web-1`이 `web-0`을 재생성했다면 `web-1`이
이미 Running과 Ready 상태이고, 이미 Running과 Ready 상태이고,
`web-2`은 종료되었을 것이다. `web-2`은 종료되었을 것이다.
@ -932,6 +932,7 @@ web-2 0/1 Terminating 0 3m
```shell ```shell
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
``` ```
``` ```
web-0 web-0
web-1 web-1
@ -957,6 +958,7 @@ kubectl get pods -w -l app=nginx
```shell ```shell
kubectl delete statefulset web kubectl delete statefulset web
``` ```
``` ```
statefulset.apps "web" deleted statefulset.apps "web" deleted
``` ```
@ -966,6 +968,7 @@ statefulset.apps "web" deleted
```shell ```shell
kubectl get pods -w -l app=nginx kubectl get pods -w -l app=nginx
``` ```
``` ```
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 11m web-0 1/1 Running 0 11m
@ -997,6 +1000,7 @@ web-1 0/1 Terminating 0 29m
```shell ```shell
kubectl delete service nginx kubectl delete service nginx
``` ```
``` ```
service "nginx" deleted service "nginx" deleted
``` ```
@ -1006,6 +1010,7 @@ service "nginx" deleted
```shell ```shell
kubectl apply -f web.yaml kubectl apply -f web.yaml
``` ```
``` ```
service/nginx created service/nginx created
statefulset.apps/web created statefulset.apps/web created
@ -1017,6 +1022,7 @@ statefulset.apps/web created
```shell ```shell
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
``` ```
``` ```
web-0 web-0
web-1 web-1
@ -1031,13 +1037,16 @@ web-1
```shell ```shell
kubectl delete service nginx kubectl delete service nginx
``` ```
``` ```
service "nginx" deleted service "nginx" deleted
``` ```
그리고 `web` 스테이트풀셋을 삭제한다. 그리고 `web` 스테이트풀셋을 삭제한다.
```shell ```shell
kubectl delete statefulset web kubectl delete statefulset web
``` ```
``` ```
statefulset "web" deleted statefulset "web" deleted
``` ```

55
content/ko/docs/tutorials/stateful-application/zookeeper.md
View File

@ -15,17 +15,17 @@ weight: 40
이 튜토리얼을 시작하기 전에 이 튜토리얼을 시작하기 전에
다음 쿠버네티스 개념에 친숙해야 한다. 다음 쿠버네티스 개념에 친숙해야 한다.
- [파드](/ko/docs/concepts/workloads/pods/) - [파드](/ko/docs/concepts/workloads/pods/)
- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) - [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) - [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/) - [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) - [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) - [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets) - [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) - [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
- [kubectl CLI](/ko/docs/reference/kubectl/kubectl/) - [kubectl CLI](/ko/docs/reference/kubectl/kubectl/)
최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. 반드시 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 축출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
이 튜토리얼은 클러스터가 동적으로 퍼시스턴트볼륨을 프로비저닝하도록 구성한다고 가정한다. 이 튜토리얼은 클러스터가 동적으로 퍼시스턴트볼륨을 프로비저닝하도록 구성한다고 가정한다.
그렇게 설정되어 있지 않다면 그렇게 설정되어 있지 않다면
@ -37,15 +37,15 @@ weight: 40
이 튜토리얼을 마치면 다음에 대해 알게 된다. 이 튜토리얼을 마치면 다음에 대해 알게 된다.
- 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가. - 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
- 어떻게 앙상블을 일관되게 설정하는가. - 어떻게 앙상블을 일관되게 설정하는가.
- 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
- 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. - 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
<!-- lessoncontent --> <!-- lessoncontent -->
### ZooKeeper 기본 {#zookeeper-basics} ### ZooKeeper
[아파치 ZooKeeper](https://zookeeper.apache.org/doc/current/)는 [아파치 ZooKeeper](https://zookeeper.apache.org/doc/current/)는
분산 애플리케이션을 위한 분산 오픈 소스 코디네이션 서비스이다. 분산 애플리케이션을 위한 분산 오픈 소스 코디네이션 서비스이다.
@ -438,8 +438,8 @@ datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi R
```shell ```shell
volumeMounts: volumeMounts:
- name: datadir - name: datadir
mountPath: /var/lib/zookeeper mountPath: /var/lib/zookeeper
``` ```
`zk` 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 `퍼시스턴트볼륨`을 `zk` 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 `퍼시스턴트볼륨`을
@ -462,6 +462,7 @@ ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한
```shell ```shell
kubectl get sts zk -o yaml kubectl get sts zk -o yaml
``` ```
``` ```
… …
command: command:
@ -551,11 +552,9 @@ kubectl logs zk-0 --tail 20
2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client) 2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client)
``` ```
쿠버네티스는 더 강력하지만 조금 복잡한 로그 통합을 쿠버네티스는 많은 로그 솔루션과 통합된다. 클러스터와 애플리케이션에
[스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)와 가장 적합한 로그 솔루션을 선택할 수 있다. 클러스터 수준의
[Elasticsearch와 Kibana](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)를 지원한다. 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 [사이드카 컨테이너](/ko/docs/concepts/cluster-administration/logging/#로깅-에이전트와-함께-사이드카-컨테이너-사용)를 배포하는 것을 고려한다.
클러스터 수준의 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해
[사이드카](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 컨테이너를 배포하는 것을 고려한다.
### 권한 없는 사용자를 위해 구성하기 ### 권한 없는 사용자를 위해 구성하기
@ -623,6 +622,7 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data
```shell ```shell
kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]' kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
``` ```
``` ```
statefulset.apps/zk patched statefulset.apps/zk patched
``` ```
@ -632,6 +632,7 @@ statefulset.apps/zk patched
```shell ```shell
kubectl rollout status sts/zk kubectl rollout status sts/zk
``` ```
``` ```
waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664... waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready... Waiting for 1 pods to be ready...
@ -872,8 +873,8 @@ kubernetes-node-2g2d
## 생존 유지 ## 생존 유지
**이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면, 이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면,
다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.** 다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.
이전 섹션은 계획되지 않은 노드 실패에서 살아남도록 이전 섹션은 계획되지 않은 노드 실패에서 살아남도록
어떻게 파드를 확산할 것인가에 대해 알아보았다. 어떻게 파드를 확산할 것인가에 대해 알아보았다.
@ -1008,6 +1009,7 @@ zk-1 0/1 Pending 0 0s
```shell ```shell
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
``` ```
``` ```
node "kubernetes-node-i4c4" cordoned node "kubernetes-node-i4c4" cordoned
@ -1051,6 +1053,7 @@ numChildren = 0
```shell ```shell
kubectl uncordon kubernetes-node-pb41 kubectl uncordon kubernetes-node-pb41
``` ```
``` ```
node "kubernetes-node-pb41" uncordoned node "kubernetes-node-pb41" uncordoned
``` ```
@ -1060,6 +1063,7 @@ node "kubernetes-node-pb41" uncordoned
```shell ```shell
kubectl get pods -w -l app=zk kubectl get pods -w -l app=zk
``` ```
``` ```
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 2 1h zk-0 1/1 Running 2 1h
@ -1125,7 +1129,6 @@ drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인
- `kubectl uncordon`은 클러스터 내에 모든 노드를 통제 해제한다. - `kubectl uncordon`은 클러스터 내에 모든 노드를 통제 해제한다.
- 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 - 반드시 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 퍼시스턴트 스토리지 미디어를 삭제하자.
퍼시스턴트 스토리지 미디어를 삭제하자.
귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서 귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서
모든 스토리지가 재확보되도록 하자. 모든 스토리지가 재확보되도록 하자.

457
content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
View File

@ -1,457 +0,0 @@
---
title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
content_type: tutorial
weight: 21
card:
name: tutorials
weight: 31
title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
---
<!-- overview -->
이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼을 기반으로 한다. Elastic의 경량 로그, 메트릭, 네트워크 데이터 오픈소스 배송기인 *Beats* 를 방명록과 동일한 쿠버네티스 클러스터에 배포한다. Beats는 데이터를 수집하고 구문분석하여 Elasticsearch에 색인화하므로, Kibana에서 동작 정보를 결과로 보며 분석할 수 있다. 이 예시는 다음과 같이 구성되어 있다.
* [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 실행한 인스턴스
* Elasticsearch와 Kibana
* Filebeat
* Metricbeat
* Packetbeat
## {{% heading "objectives" %}}
* Redis를 이용한 PHP 방명록 시작.
* kube-state-metrics 설치.
* 쿠버네티스 시크릿 생성.
* Beats 배포.
* 로그와 메트릭의 대시보드 보기.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
{{< version-check >}}
추가로 다음이 필요하다.
* 실행 중인 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼의 배포본.
* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나,
[파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)
워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다.
<!-- lessoncontent -->
## Redis를 이용한 PHP 방명록 시작
이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자.
## 클러스터 롤 바인딩 추가
[클러스터 단위 롤 바인딩](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다.
```shell
kubectl create clusterrolebinding cluster-admin-binding \
--clusterrole=cluster-admin --user=<your email associated with the k8s provider account>
```
## kube-state-metrics 설치
[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다.
```shell
git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
kubectl apply -f kube-state-metrics/examples/standard
```
### kube-state-metrics 실행 여부 확인
```shell
kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
```
출력
```
NAME READY STATUS RESTARTS AGE
kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s
```
## Elastic의 예제를 GitHub 리포지터리에 클론한다.
```shell
git clone https://github.com/elastic/examples.git
```
나머지 커맨드는 `examples/beats-k8s-send-anywhere` 디렉터리의 파일을 참조할 것이라서, 그쪽으로 현재 디렉터리를 변경한다.
```shell
cd examples/beats-k8s-send-anywhere
```
## 쿠버네티스 시크릿 만들기
쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}은 암호나 토큰, 키 같이 소량의 민감한 데이터를 포함하는 오브젝트이다. 이러한 정보는 다른 방식으로도 파드 스펙이나 이미지에 넣을 수 있을 것이다. 시크릿 오브젝트에 넣으면 이것이 어떻게 사용되는지 다양하게 제어할 수 있고, 우발적인 노출 사고의 위험이 줄일 수 있다.
{{< note >}}
여기에는 방식이 나뉘는데, 하나는 *자체 관리(Self managed)* 로 Elasticsearch와 Kibana(Elastic의 Helm 차트를 이용하여 사용자 서버를 구동하는)를 사용하는 경우이고 다른 경우는 Elastic Cloud의 Elasticsearch 서비스의 *관리 서비스(Managed service)* 를 사용하는 방식이다. 이 튜토리얼에서는 사용할 Elasticsearch와 Kibana 시스템의 종류에 따라 시크릿을 만들어야 한다.
{{< /note >}}
{{< tabs name="tab_with_md" >}}
{{% tab name="자체 관리(Self Managed)" %}}
### 자체 관리
Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스** 탭으로 전환한다.
### 자격증명(credentials) 설정
자체 관리 Elasticsearch와 Kibana(자체 관리는 사실상 Elastic Cloud의 관리 서비스 Elasticsearch와 다르다) 서비스에 접속할 때에 4개 파일을 수정하여 쿠버네티스 시크릿을 생성한다. 파일은 다음과 같다.
1. `ELASTICSEARCH_HOSTS`
1. `ELASTICSEARCH_PASSWORD`
1. `ELASTICSEARCH_USERNAME`
1. `KIBANA_HOST`
이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시(또는 [*이 구성*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)을 본다)가 있다.
#### `ELASTICSEARCH_HOSTS`
1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup).
```
["http://elasticsearch-master.default.svc.cluster.local:9200"]
```
1. Mac을 위한 Docker에서 Beats를 운영 중인 Mac에서 운영하는 단일 Elasticsearch 노드.
```
["http://host.docker.internal:9200"]
```
1. VM이나 물리 장비에서 운영 중인 두 개의 ELASTICSEARCH 노드.
```
["http://host1.example.com:9200", "http://host2.example.com:9200"]
```
`ELASTICSEARCH_HOSTS` 를 수정한다.
```shell
vi ELASTICSEARCH_HOSTS
```
#### `ELASTICSEARCH_PASSWORD`
화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 암호이다.
```
<사용자시크릿암호>
```
`ELASTICSEARCH_PASSWORD` 를 수정한다.
```shell
vi ELASTICSEARCH_PASSWORD
```
#### `ELASTICSEARCH_USERNAME`
화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 이름이다.
```
<Elasticsearch를 위한 수집 사용자 이름>
```
`ELASTICSEARCH_USERNAME` 을 수정한다.
```shell
vi ELASTICSEARCH_USERNAME
```
#### `KIBANA_HOST`
1.Elastic의 Kibana Helm 차트의 인스턴스이다. 하위 도메인 `default`는 기본 네임스페이스를 참조한다. 다른 네임스페이스를 사용하여 Helm 차트를 배포한 경우 하위 도메인이 다릅니다.
```
"kibana-kibana.default.svc.cluster.local:5601"
```
1. Mac 용 Docker에서 실행하는 Beats가 있는 Mac에서 실행하는 Kibana 인스턴스
```
"host.docker.internal:5601"
```
1. 가상머신이나 물리적 하드웨어에서 실행 중인 두 개의 Elasticsearch 노드
```
"host1.example.com:5601"
```
`KIBANA_HOST` 를 편집한다.
```shell
vi KIBANA_HOST
```
### 쿠버네티스 시크릿 만들기
이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 만든다.
```shell
kubectl create secret generic dynamic-logging \
--from-file=./ELASTICSEARCH_HOSTS \
--from-file=./ELASTICSEARCH_PASSWORD \
--from-file=./ELASTICSEARCH_USERNAME \
--from-file=./KIBANA_HOST \
--namespace=kube-system
```
{{% /tab %}}
{{% tab name="관리 서비스(Managed service)" %}}
## 관리 서비스
이 탭은 Elastic Cloud에서 Elasticsearch 서비스 만에 대한 것으로, 이미 자체 관리 Elasticsearch와 Kibana 배포로 시크릿을 생성했다면, [Beats 배포](#deploy-the-beats)를 계속한다.
### 자격증명(credentials) 설정
Elastic Cloud에서 관리되는 Elastic 서비스에 연결할 때, 쿠버네티스 시크릿을 생성하기 위해 편집할 두 파일이 있다. 파일은 다음과 같다.
1. `ELASTIC_CLOUD_AUTH`
1. `ELASTIC_CLOUD_ID`
디플로이먼트를 생성할 때에 Elasticsearch 콘솔에서 제공한 정보로 이를 설정한다. 여기 예시들이 있다.
#### `ELASTIC_CLOUD_ID`
```
devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
```
#### `ELASTIC_CLOUD_AUTH`
사용자 이름, 콜론(`:`) 및 비밀번호인데, 공백 또는 따옴표는 없다.
```
elastic:VFxJJf9Tjwer90wnfTghsn8w
```
### 필요 파일 편집하기
```shell
vi ELASTIC_CLOUD_ID
vi ELASTIC_CLOUD_AUTH
```
### 쿠버네티스 시크릿 생성하기
이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 생성한다.
```shell
kubectl create secret generic dynamic-logging \
--from-file=./ELASTIC_CLOUD_ID \
--from-file=./ELASTIC_CLOUD_AUTH \
--namespace=kube-system
```
{{% /tab %}}
{{< /tabs >}}
## Beats 배포하기 {#deploy-the-beats}
각 Beat마다 메니페스트 파일을 제공한다. 이 메니페스트 파일은 앞서 생성한 시크릿을 사용하여, Elasticsearch 및 Kibana 서버에 연결하도록 Beats를 구성한다.
### Filebeat에 대해
Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파드에서 실행되는 컨테이너의 로그를 수집한다. Filebeat는 {{< glossary_tooltip text="데몬 셋" term_id="daemonset" >}}으로 배포한다. Filebeat는 쿠버네티스 클러스터에서 실행 중인 애플리케이션을 자동 검색할 수 있다. 시작시에 Filebeat는 기존 컨테이너를 검색하고 이에 적절한 구성을 시작하고 새 시작/종료 이벤트를 감시한다.
아래 내용은 Filebeat가 방명록 애플리케이션과 함께 배포된 Redis 컨테이너에서 Redis 로그를 찾아 구문분석할 수 있게 하는 자동 검색 구성이다. 이 구성은 `filebeat-kubernetes.yaml`파일에 있다.
```yaml
- condition.contains:
kubernetes.labels.app: redis
config:
- module: redis
log:
input:
type: docker
containers.ids:
- ${data.kubernetes.container.id}
slowlog:
enabled: true
var.hosts: ["${data.host}:${data.port}"]
```
이것은 `redis` 컨테이너가 `app` 문자열을 포함하는 레이블로 감지될 때에 Filebeat 모듈 `redis`를 적용하도록 Filebeat를 구성한다. Redis 모듈은 Docker 입력 유형을 사용하여 컨테이너에서 `로그` 스트림을 수집할 수 있다(이 Redis 컨테이너의 STDOUT 스트림과 연관된 쿠버네티스 노드에서 파일 읽기). 또한 이 모듈은 컨테이너 메타 데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 Redis의 `slowlog` 항목을 수집할 수 있다.
### Filebeat 배포
```shell
kubectl create -f filebeat-kubernetes.yaml
```
#### 확인
```shell
kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic
```
### Metricbeat에 대해
Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음은 Redis 컨테이너에 대한 Metricbeat의 자동 검색 구성이다. 이 구성은 `metricbeat-kubernetes.yaml`에 있다.
```yaml
- condition.equals:
kubernetes.labels.tier: backend
config:
- module: redis
metricsets: ["info", "keyspace"]
period: 10s
# Redis hosts
hosts: ["${data.host}:${data.port}"]
```
이것은 컨테이너가 `tier` 레이블이 `backend` 문자열과 같은 레이블로 감지될 때에 Metricbeat 모듈 `redis`를 적용하도록 Metricbeat를 구성한다. `redis` 모듈은 컨테이너 메타데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 컨테이너에서 `info` 및 `keyspace` 메트릭을 수집할 수 있다.
### Metricbeat 배포
```shell
kubectl create -f metricbeat-kubernetes.yaml
```
#### 확인
```shell
kubectl get pods -n kube-system -l k8s-app=metricbeat
```
### Packetbeat에 대해
Packetbeat 구성은 Filebeat와 Metricbeat와는 다르다. 컨테이너 레이블과 일치시킬 패턴을 지정하지 않고, 구성은 관련 프로토콜 및 포트 번호를 기반으로 한다. 아래는 포트 번호의 하위 집합이다.
{{< note >}}
비표준 포트로 서비스를 실행했다면 해당 포트를 `filebeat.yaml`에 적절한 유형에 추가하고, Packetbeat 데몬 셋을 삭제하고 생성한다.
{{< /note >}}
```yaml
packetbeat.interfaces.device: any
packetbeat.protocols:
- type: dns
ports: [53]
include_authorities: true
include_additionals: true
- type: http
ports: [80, 8000, 8080, 9200]
- type: mysql
ports: [3306]
- type: redis
ports: [6379]
packetbeat.flows:
timeout: 30s
period: 10s
```
#### Packetbeat 배포하기
```shell
kubectl create -f packetbeat-kubernetes.yaml
```
#### 확인하기
```shell
kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic
```
## Kibana에서 보기
브라우저에서 Kibana를 열고, **대시보드** 애플리케이션을 열어보자. 검색창에 kubernetes를 입력하고 쿠버네티스를 위한 Metricbeat 대시보드를 클릭한다. 이 대시보드에는 노드 상태, 배포 등의 보고 내용이 있다.
대시보드 페이지에 Packetbeat를 검색하고 Packetbeat의 개요 페이지를 살펴보자.
마찬가지로 Apache와 Redis를 위한 대시보드를 확인한다. 각 로그와 메트릭에 대한 대시보드가 표시된다. 이 Apache Metricbeat 대시보드는 비어 있다. Apache Filebeat 대시보드를 보고, 맨 아래로 스크롤하여 Apache 오류 로그를 확인한다. Apache에서 보여줄 메트릭이 없는 이유를 알려줄 것이다.
Metricbeat에서 Apache 메트릭을 가져올 수 있게 하려면, mod-status 구성 파일을 포함한 컨피그맵을 추가하고 방명록을 재배포하여 서버 상태를 활성화해야 한다.
## 디플로이먼트를 확장하고 모니터링중인 새 파드를 확인하기
기존 디플로이먼트를 확인한다.
```shell
kubectl get deployments
```
출력
```
NAME READY UP-TO-DATE AVAILABLE AGE
frontend 3/3 3 3 3h27m
redis-master 1/1 1 1 3h27m
redis-slave 2/2 2 2 3h27m
```
front의 디플로이먼트를 두 개의 파드로 축소한다.
```shell
kubectl scale --replicas=2 deployment/frontend
```
출력
```
deployment.extensions/frontend scaled
```
frontend의 파드를 최대 3개의 파드로 확장한다.
```shell
kubectl scale --replicas=3 deployment/frontend
```
## Kibana에서 변화 확인하기
스크린 캡처를 확인하여, 표시된 필터를 추가하고 해당 열을 뷰에 추가한다. ScalingReplicaSet 항목이 표시되고, 여기에서 이벤트 목록의 맨 위에 풀링되는 이미지, 마운트된 볼륨, 파드 시작 등을 보여준다.
![Kibana 디스커버리](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png)
## {{% heading "cleanup" %}}
디플로이먼트와 서비스를 삭제하면 실행중인 파드도 삭제된다. 한 커맨드로 여러 개의 리소스를 삭제하기 위해 레이블을 이용한다.
1. 다음 커맨드를 실행하여 모든 파드, 디플로이먼트, 서비스를 삭제한다.
```shell
kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment -l app=guestbook
kubectl delete service -l app=guestbook
kubectl delete -f filebeat-kubernetes.yaml
kubectl delete -f metricbeat-kubernetes.yaml
kubectl delete -f packetbeat-kubernetes.yaml
kubectl delete secret dynamic-logging -n kube-system
```
1. 실행 중인 파드가 없음을 확인하기 위해 파드 목록을 조회한다.
```shell
kubectl get pods
```
출력은 다음과 같아야 한다.
```
No resources found.
```
## {{% heading "whatsnext" %}}
* [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다.
* [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 더 읽어본다.
* [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다.
* [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다.

185
content/ko/docs/tutorials/stateless-application/guestbook.md
View File

@ -1,26 +1,25 @@
--- ---
title: "예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기" title: "예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기"
content_type: tutorial content_type: tutorial
weight: 20 weight: 20
card: card:
name: tutorials name: tutorials
weight: 30 weight: 30
title: "상태를 유지하지 않는 예제: Redis를 사용한 PHP 방명록" title: "상태를 유지하지 않는 예제: MongoDB를 사용한 PHP 방명록"
min-kubernetes-server-version: v1.14
--- ---
<!-- overview --> <!-- overview -->
이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다. 이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 _(운영 준비가 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다.
* 방명록을 저장하는 단일 인스턴스 [Redis](https://redis.io/) 마스터 * 방명록을 저장하는 단일 인스턴스 [MongoDB](https://www.mongodb.com/)
* 읽기를 제공하는 여러 개의 [복제된 Redis](https://redis.io/topics/replication) 인스턴스
* 여러 개의 웹 프론트엔드 인스턴스 * 여러 개의 웹 프론트엔드 인스턴스
## {{% heading "objectives" %}} ## {{% heading "objectives" %}}
* Redis 마스터를 시작 * Mongo 데이터베이스를 시작
* Redis 슬레이브를 시작
* 방명록 프론트엔드를 시작 * 방명록 프론트엔드를 시작
* 프론트엔드 서비스를 노출하고 확인 * 프론트엔드 서비스를 노출하고 확인
* 정리 하기 * 정리 하기
@ -37,24 +36,28 @@ card:
<!-- lessoncontent --> <!-- lessoncontent -->
## Redis 마스터를 실행하기 ## Mongo 데이터베이스를 실행
방명록 애플리케이션은 Redis를 사용하여 데이터를 저장한다. Redis 마스터 인스턴스에 데이터를 기록하고 여러 Redis 슬레이브 인스턴스에서 데이터를 읽는다. 방명록 애플리케이션은 MongoDB를 사용해서 데이터를 저장한다.
### Redis 마스터의 디플로이먼트를 생성하기 ### Mongo 디플로이먼트를 생성하기
아래의 매니페스트 파일은 단일 복제본 Redis 마스터 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다. 아래의 매니페스트 파일은 단일 복제본 Mongo 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다.
{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} {{< codenew file="application/guestbook/mongo-deployment.yaml" >}}
1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다. 1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다.
1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다. 1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다.
```shell ```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
``` ```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
-->
1. 파드의 목록을 질의하여 Redis 마스터 파드가 실행 중인지 확인한다. 1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다.
```shell ```shell
kubectl get pods kubectl get pods
@ -64,32 +67,32 @@ card:
```shell ```shell
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 28s mongo-5cfd459dd4-lrcjb 1/1 Running 0 28s
``` ```
1. Redis 마스터 파드에서 로그를 보려면 다음 명령어를 실행한다. 2. MongoDB 파드에서 로그를 보려면 다음 명령어를 실행한다.
```shell ```shell
kubectl logs -f POD-NAME kubectl logs -f deployment/mongo
``` ```
{{< note >}} ### MongoDB 서비스 생성하기
POD-NAME을 해당 파드 이름으로 수정해야 한다.
{{< /note >}}
### Redis 마스터 서비스 생성하기 방명록 애플리케이션에서 데이터를 쓰려면 MongoDB와 통신해야 한다. MongoDB 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다.
방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. {{< codenew file="application/guestbook/mongo-service.yaml" >}}
{{< codenew file="application/guestbook/redis-master-service.yaml" >}} 1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다.
1. `redis-master-service.yaml` 파일을 통해 Redis 마스터 서비스에 적용한다.
```shell ```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
``` ```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
-->
1. 서비스의 목록을 질의하여 Redis 마스터 서비스가 실행 중인지 확인한다. 1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다.
```shell ```shell
kubectl get service kubectl get service
@ -100,77 +103,17 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다.
```shell ```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 8s mongo ClusterIP 10.0.0.151 <none> 6379/TCP 8s
``` ```
{{< note >}} {{< note >}}
이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `redis-master`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 Redis 마스터 파드로 라우팅한다. 이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `mongo`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 MongoDB 파드로 라우팅한다.
{{< /note >}} {{< /note >}}
## Redis 슬레이브 실행하기
Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추가하여 트래픽 요구 사항을 충족시킬 수 있다.
### Redis 슬레이브의 디플로이먼트 생성하기
디플로이먼트는 매니페스트 파일에 설정된 구성에 따라 확장된다. 이 경우, 디플로이먼트 오브젝트는 두 개의 복제본을 지정한다.
실행 중인 복제본이 없으면, 이 디플로이먼트는 컨테이너 클러스터에 있는 두 개의 복제본을 시작한다. 반대로 두 개 이상의 복제본이 실행 중이면, 두 개의 복제본이 실행될 때까지 축소된다.
{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}}
1. `redis-slave-deployment.yaml` 파일을 통해 Redis 슬레이브의 디플로이먼트에 적용한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
```
1. 파드의 목록을 질의하여 Redis 슬레이브 파드가 실행 중인지 확인한다.
```shell
kubectl get pods
```
결과는 아래와 같은 형태로 나타난다.
```shell
NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 1m
redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s
redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s
```
### Redis 슬레이브 서비스 생성하기
방명록 애플리케이션은 Redis 슬레이브와 통신하여 데이터를 읽는다. Redis 슬레이브를 확인할 수 있도록 하기 위해 서비스를 설정해야 한다. 서비스는 파드 집합에 투명한 로드 밸런싱을 제공한다.
{{< codenew file="application/guestbook/redis-slave-service.yaml" >}}
1. `redis-slave-service.yaml` 파일을 통해 Redis 슬레이브 서비스에 적용한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml
```
1. 서비스의 목록을 질의하여 Redis 슬레이브 서비스가 실행 중인지 확인한다.
```shell
kubectl get services
```
결과는 아래와 같은 형태로 나타난다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 2m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 1m
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 6s
```
## 방명록 프론트엔드를 설정하고 노출하기 ## 방명록 프론트엔드를 설정하고 노출하기
방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 쓰기 요청을 위한 `redis-master` 서비스와 읽기 요청을 위한 `redis-slave` 서비스에 연결하도록 설정된다. 방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 방명록 항목들을 저장하기 위해 `mongo` 서비스에 연결하도록 구성 한다.
### 방명록 프론트엔드의 디플로이먼트 생성하기 ### 방명록 프론트엔드의 디플로이먼트 생성하기
@ -182,6 +125,11 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
``` ```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
-->
1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다. 1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.
```shell ```shell
@ -199,12 +147,12 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추
### 프론트엔드 서비스 생성하기 ### 프론트엔드 서비스 생성하기
서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. 서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 `mongo` 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.
게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다. 게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 쿠버네티스 클러스터 외부에서 서비스를 요청할 수 있다. 그러나 쿠버네티스 사용자는 `ClusterIP`를 사용하더라도 `kubectl port-forward`를 사용해서 서비스에 접근할 수 있다.
{{< note >}} {{< note >}}
Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : NodePort`를 삭제하거나 주석 처리하고 `type : LoadBalancer`의 주석을 제거해야 한다. Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : LoadBalancer`의 주석을 제거해야 한다.
{{< /note >}} {{< /note >}}
{{< codenew file="application/guestbook/frontend-service.yaml" >}} {{< codenew file="application/guestbook/frontend-service.yaml" >}}
@ -215,6 +163,11 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
``` ```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
-->
1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다. 1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다.
```shell ```shell
@ -225,29 +178,27 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
``` ```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend NodePort 10.0.0.112 <none> 80:31323/TCP 6s frontend ClusterIP 10.0.0.112 <none> 80/TCP 6s
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 2m mongo ClusterIP 10.0.0.151 <none> 6379/TCP 2m
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 1m
``` ```
### `NodePort`를 통해 프론트엔드 서비스 확인하기 ### `kubectl port-forward`를 통해 프론트엔드 서비스 확인하기
애플리케이션을 Minikube 또는 로컬 클러스터에 배포한 경우, 방명록을 보려면 IP 주소를 찾아야 한다. 1. 다음 명령어를 실행해서 로컬 머신의 `8080` 포트를 서비스의 `80` 포트로 전달한다.
1. 프론트엔드 서비스의 IP 주소를 얻기 위해 아래 명령어를 실행한다.
```shell ```shell
minikube service frontend --url kubectl port-forward svc/frontend 8080:80
``` ```
결과는 아래와 같은 형태로 나타난다. 결과는 아래와 같은 형태로 나타난다.
``` ```
http://192.168.99.100:31323 Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
``` ```
1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다. 1. 방명록을 보기위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다.
### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기 ### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기
@ -270,7 +221,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
## 웹 프론트엔드 확장하기 ## 웹 프론트엔드 확장하기
서버가 디플로이먼트 컨트롤러를 사용하는 서비스로 정의되어 있기 때문에 확장 또는 축소가 쉽다. 서버가 디플로이먼트 컨르롤러를 사용하는 서비스로 정의되어 있기에 필요에 따라 확장 또는 축소할 수 있다.
1. 프론트엔드 파드의 수를 확장하기 위해 아래 명령어를 실행한다. 1. 프론트엔드 파드의 수를 확장하기 위해 아래 명령어를 실행한다.
@ -293,9 +244,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
frontend-3823415956-k22zn 1/1 Running 0 54m frontend-3823415956-k22zn 1/1 Running 0 54m
frontend-3823415956-w9gbt 1/1 Running 0 54m frontend-3823415956-w9gbt 1/1 Running 0 54m
frontend-3823415956-x2pld 1/1 Running 0 5s frontend-3823415956-x2pld 1/1 Running 0 5s
redis-master-1068406935-3lswp 1/1 Running 0 56m mongo-1068406935-3lswp 1/1 Running 0 56m
redis-slave-2005841000-fpvqc 1/1 Running 0 55m
redis-slave-2005841000-phfv9 1/1 Running 0 55m
``` ```
1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다. 1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다.
@ -316,9 +265,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
frontend-3823415956-k22zn 1/1 Running 0 1h frontend-3823415956-k22zn 1/1 Running 0 1h
frontend-3823415956-w9gbt 1/1 Running 0 1h frontend-3823415956-w9gbt 1/1 Running 0 1h
redis-master-1068406935-3lswp 1/1 Running 0 1h mongo-1068406935-3lswp 1/1 Running 0 1h
redis-slave-2005841000-fpvqc 1/1 Running 0 1h
redis-slave-2005841000-phfv9 1/1 Running 0 1h
``` ```
@ -330,19 +277,18 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
1. 모든 파드, 디플로이먼트, 서비스를 삭제하기 위해 아래 명령어를 실행한다. 1. 모든 파드, 디플로이먼트, 서비스를 삭제하기 위해 아래 명령어를 실행한다.
```shell ```shell
kubectl delete deployment -l app=redis kubectl delete deployment -l app.kubernetes.io/name=mongo
kubectl delete service -l app=redis kubectl delete service -l app.kubernetes.io/name=mongo
kubectl delete deployment -l app=guestbook kubectl delete deployment -l app.kubernetes.io/name=guestbook
kubectl delete service -l app=guestbook kubectl delete service -l app.kubernetes.io/name=guestbook
``` ```
결과는 아래와 같은 형태로 나타난다. 결과는 아래와 같은 형태로 나타난다.
``` ```
deployment.apps "redis-master" deleted deployment.apps "mongo" deleted
deployment.apps "redis-slave" deleted service "mongo" deleted
service "redis-master" deleted deployment.apps "frontend" deleted
service "redis-slave" deleted
deployment.apps "frontend" deleted deployment.apps "frontend" deleted
service "frontend" deleted service "frontend" deleted
``` ```
@ -363,7 +309,6 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* [ELK 로깅과 모니터링](/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)을 방명록 애플리케이션에 추가하기
* [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료 * [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료
* [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기 * [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기
* [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 * [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기

24
content/ko/examples/application/guestbook/frontend-deployment.yaml
View File

@ -3,22 +3,24 @@ kind: Deployment
metadata: metadata:
name: frontend name: frontend
labels: labels:
app: guestbook app.kubernetes.io/name: guestbook
app.kubernetes.io/component: frontend
spec: spec:
selector: selector:
matchLabels: matchLabels:
app: guestbook app.kubernetes.io/name: guestbook
tier: frontend app.kubernetes.io/component: frontend
replicas: 3 replicas: 3
template: template:
metadata: metadata:
labels: labels:
app: guestbook app.kubernetes.io/name: guestbook
tier: frontend app.kubernetes.io/component: frontend
spec: spec:
containers: containers:
- name: php-redis - name: guestbook
image: gcr.io/google-samples/gb-frontend:v4 image: paulczar/gb-frontend:v5
# image: gcr.io/google-samples/gb-frontend:v4
resources: resources:
requests: requests:
cpu: 100m cpu: 100m
@ -26,13 +28,5 @@ spec:
env: env:
- name: GET_HOSTS_FROM - name: GET_HOSTS_FROM
value: dns value: dns
# Using `GET_HOSTS_FROM=dns` requires your cluster to
# provide a dns service. As of Kubernetes 1.3, DNS is a built-in
# service launched automatically. However, if the cluster you are using
# does not have a built-in DNS service, you can instead
# access an environment variable to find the master
# service's host. To do so, comment out the 'value: dns' line above, and
# uncomment the line below:
# value: env
ports: ports:
- containerPort: 80 - containerPort: 80

10
content/ko/examples/application/guestbook/frontend-service.yaml
View File

@ -3,16 +3,14 @@ kind: Service
metadata: metadata:
name: frontend name: frontend
labels: labels:
app: guestbook app.kubernetes.io/name: guestbook
tier: frontend app.kubernetes.io/component: frontend
spec: spec:
# comment or delete the following line if you want to use a LoadBalancer
type: NodePort
# if your cluster supports it, uncomment the following to automatically create # if your cluster supports it, uncomment the following to automatically create
# an external load-balanced IP for the frontend service. # an external load-balanced IP for the frontend service.
# type: LoadBalancer # type: LoadBalancer
ports: ports:
- port: 80 - port: 80
selector: selector:
app: guestbook app.kubernetes.io/name: guestbook
tier: frontend app.kubernetes.io/component: frontend

31
content/ko/examples/application/guestbook/mongo-deployment.yaml Normal file
View File

@ -0,0 +1,31 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: mongo
labels:
app.kubernetes.io/name: mongo
app.kubernetes.io/component: backend
spec:
selector:
matchLabels:
app.kubernetes.io/name: mongo
app.kubernetes.io/component: backend
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: mongo
app.kubernetes.io/component: backend
spec:
containers:
- name: mongo
image: mongo:4.2
args:
- --bind_ip
- 0.0.0.0
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 27017

14
content/ko/examples/application/guestbook/mongo-service.yaml Normal file
View File

@ -0,0 +1,14 @@
apiVersion: v1
kind: Service
metadata:
name: mongo
labels:
app.kubernetes.io/name: mongo
app.kubernetes.io/component: backend
spec:
ports:
- port: 27017
targetPort: 27017
selector:
app.kubernetes.io/name: mongo
app.kubernetes.io/component: backend

29
content/ko/examples/application/guestbook/redis-master-deployment.yaml
View File

@ -1,29 +0,0 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-master
labels:
app: redis
spec:
selector:
matchLabels:
app: redis
role: master
tier: backend
replicas: 1
template:
metadata:
labels:
app: redis
role: master
tier: backend
spec:
containers:
- name: master
image: k8s.gcr.io/redis:e2e # or just image: redis
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 6379

17
content/ko/examples/application/guestbook/redis-master-service.yaml
View File

@ -1,17 +0,0 @@
apiVersion: v1
kind: Service
metadata:
name: redis-master
labels:
app: redis
role: master
tier: backend
spec:
ports:
- name: redis
port: 6379
targetPort: 6379
selector:
app: redis
role: master
tier: backend

40
content/ko/examples/application/guestbook/redis-slave-deployment.yaml
View File

@ -1,40 +0,0 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-slave
labels:
app: redis
spec:
selector:
matchLabels:
app: redis
role: slave
tier: backend
replicas: 2
template:
metadata:
labels:
app: redis
role: slave
tier: backend
spec:
containers:
- name: slave
image: gcr.io/google_samples/gb-redisslave:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
# Using `GET_HOSTS_FROM=dns` requires your cluster to
# provide a dns service. As of Kubernetes 1.3, DNS is a built-in
# service launched automatically. However, if the cluster you are using
# does not have a built-in DNS service, you can instead
# access an environment variable to find the master
# service's host. To do so, comment out the 'value: dns' line above, and
# uncomment the line below:
# value: env
ports:
- containerPort: 6379

15
content/ko/examples/application/guestbook/redis-slave-service.yaml
View File

@ -1,15 +0,0 @@
apiVersion: v1
kind: Service
metadata:
name: redis-slave
labels:
app: redis
role: slave
tier: backend
spec:
ports:
- port: 6379
selector:
app: redis
role: slave
tier: backend

10
content/ko/examples/policy/priority-class-resourcequota.yaml Normal file
View File

@ -0,0 +1,10 @@
apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-cluster-services
spec:
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["cluster-services"]