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

Update outdated files in dev-1.20-ko.5 (1)

Browse Source
This commit is contained in:
seokho-son
2021-02-24 13:35:40 +09:00
parent 2daeee3424
commit 9cc8d0d329
19 changed files with 199 additions and 141 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/community/_index.html
+21 -2
View File
@@ -19,6 +19,7 @@ cid: community
<div class="community__navbar">
<a href="#values">커뮤니티 가치</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="#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">
</div>
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;margin-bottom:3%" class="mobile">
<a name="conduct"></a>
<a name="values"></a>
</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">
content/ko/docs/concepts/architecture/controller.md
+1 -1
View File
@@ -102,7 +102,7 @@ weight: 30
온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가
서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는
[쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자 APIS 및
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API들 및
기타 서비스 등과 간접적으로 연동하여 이를 구현한다.
## 의도한 상태와 현재 상태 {#desired-vs-current}
content/ko/docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -10,7 +10,7 @@ weight: 10
노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 의해 관리되며
{{< glossary_tooltip text="파드" term_id="pod" >}}를
실행하는데 필요한 서비스를 포함한다.
실행하는 데 필요한 서비스를 포함한다.
일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는
환경에서는 하나만 있을 수도 있다.
content/ko/docs/concepts/cluster-administration/_index.md
+2 -2
View File
@@ -22,12 +22,12 @@ no_list: true
가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다.
- 컴퓨터에서 쿠버네티스를 그냥 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
- 컴퓨터에서 쿠버네티스를 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
- [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가?
- 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
- **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
- 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
- **단지 클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약
- **클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약
후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
더 다양한 선택을 제공한다.
- 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.
content/ko/docs/concepts/cluster-administration/logging.md
+68 -69
View File
@@ -1,4 +1,7 @@
---
title: 로깅 아키텍처
content_type: concept
weight: 60
@@ -6,23 +9,22 @@ weight: 60
<!-- overview -->
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다.
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다.
예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다.
클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다.
<!-- body -->
클러스터-레벨 로깅 아키텍처는 로깅 백엔드가
클러스터 내부 또는 외부에 존재한다고 가정하여 설명한다. 클러스터-레벨
로깅에 관심이 없는 경우에도, 노드에서 로그를 저장하고
처리하는 방법에 대한 설명이 여전히 유용할 수 있다.
클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는
로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만,
쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다.
## 쿠버네티스의 기본 로깅
이 섹션에서는, 쿠버네티스에서 표준 출력 스트림으로 데이터를
출력하는 기본 로깅의 예시를 볼 수 있다. 이 데모에서는
일부 텍스트를 초당 한 번씩 표준 출력에 쓰는 컨테이너와 함께
파드 명세를 사용한다.
이 예시는 텍스트를 초당 한 번씩 표준 출력에 쓰는
컨테이너에 대한 `Pod` 명세를 사용한다.
{{< codenew file="debug/counter-pod.yaml" >}}
@@ -31,8 +33,10 @@ weight: 60
```shell
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
```
출력은 다음과 같다.
```
```console
pod/counter created
```
@@ -41,69 +45,69 @@ pod/counter created
```shell
kubectl logs counter
```
출력은 다음과 같다.
```
```console
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 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)
컨테이너화된 애플리케이션이 `stdout(표준 출력)` 및 `stderr(표준 에러)` 에 쓰는 모든 것은 컨테이너 엔진에 의해 어딘가에서 처리와 리디렉션 된다. 예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 json 형식의 파일에 작성하도록 구성된다.
컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 엔진이 처리 및 리디렉션 한다.
예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 JSON 형식의 파일에 작성하도록 구성된다.
{{< note >}}
도커 json 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다.
도커 JSON 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다.
{{< /note >}}
기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다.
노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여,
로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는
현재 로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로
로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로
이를 해결하기 위한 솔루션을 설정해야 한다.
예를 들어, `kube-up.sh` 스크립트에 의해 배포된 쿠버네티스 클러스터에는,
매시간 실행되도록 구성된 [`logrotate`](https://linux.die.net/man/8/logrotate)
도구가 있다. 예를 들어, 도커의 `log-opt` 를 사용하여 애플리케이션의 로그를
자동으로 로테이션을 하도록 컨테이너 런타임을 설정할 수도 있다.
`kube-up.sh` 스크립트에서, 후자의 접근 방식은 GCP의 COS 이미지에 사용되며,
전자의 접근 방식은 다른 환경에서 사용된다. 두 경우 모두,
기본적으로 로그 파일이 10MB를 초과하면 로테이션이 되도록 구성된다.
도구가 있다. 애플리케이션의 로그를 자동으로
로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
예를 들어, `kube-up.sh` 가 해당
[스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)에서
GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 찾을 수 있다.
예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
자세히 알 수 있다.
기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
실행하면, 노드의 kubelet이 요청을 처리하고
로그 파일에서 직접 읽은 다음, 응답의 내용을 반환한다.
로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다.
{{< note >}}
현재, 일부 외부 시스템에서 로테이션을 수행한 경우,
만약, 일부 외부 시스템이 로테이션을 수행한 경우,
`kubectl logs` 를 통해 최신 로그 파일의 내용만
사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가
로테이션을 수행하고 두 개의 파일이 생긴다(크기가 10MB인 파일 하나와 비어있는 파일).
그 후 `kubectl logs` 는 빈 응답을 반환한다.
로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일)
`kubectl logs` 는 이 예시에서는 빈 응답에 해당하는 최신 로그 파일을 반환한다.
{{< /note >}}
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
### 시스템 컴포넌트 로그
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
예를 들면 다음과 같다.
* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
* Kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다.
* Kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다.
systemd를 사용하는 시스템에서, kubelet과 컨테이너 런타임은 journald에 작성한다.
systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 작성한다.
컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고,
항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog](https://github.com/kubernetes/klog)
systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 journald에 작성한다.
systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/log` 디렉터리의
`.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고,
항상 `/var/log` 디렉터리에 기록한다.
시스템 컴포넌트는 [klog](https://github.com/kubernetes/klog)
로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서
해당 컴포넌트의 로깅 심각도(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)
사이드카 컨테이너를 자체 `stdout` 및 `stderr` 스트림으로
스트리밍하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를
활용할 수 있다. 사이드카 컨테이너는 파일, 소켓
또는 journald에서 로그를 읽는다. 각 개별 사이드카 컨테이너는 자체 `stdout`
또는 `stderr` 스트림에 로그를 출력한다.
사이드카 컨테이너가 자체 `stdout` 및 `stderr` 스트림으로
쓰도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를
활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다.
각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다.
이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을
분리할 수 ​​있고, 이 중 일부는 `stdout` 또는 `stderr` 에
작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은
미미하기 때문에, 큰 오버헤드가 거의 없다. 또한,
최소화되어 있기 때문에, 심각한 오버헤드가 아니다. 또한,
`stdout` 및 `stderr` 가 kubelet에서 처리되므로, `kubectl logs` 와 같은
빌트인 도구를 사용할 수 있다.
다음의 예를 고려해보자. 파드는 단일 컨테이너를 실행하고, 컨테이너는
서로 다른 두 가지 형식을 사용하여, 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한
예를 들어, 파드는 단일 컨테이너를 실행하고, 컨테이너는
서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한
구성 파일은 다음과 같다.
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
두 컴포넌트를 컨테이너의 `stdout` 스트림으로 리디렉션한 경우에도, 동일한 로그
스트림에 서로 다른 형식의 로그 항목을 갖는 것은
알아보기 힘들다. 대신, 두 개의 사이드카 컨테이너를 도입할 수 있다. 각 사이드카
스트림에 서로 다른 형식의 로그 항목을 작성하는 것은
추천하지 않는다. 대신, 두 개의 사이드카 컨테이너를 생성할 수 있다. 각 사이드카
컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를
자체 `stdout` 스트림으로 리디렉션할 수 있다.
@@ -178,7 +182,10 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에
```shell
kubectl logs counter count-log-1
```
```
출력은 다음과 같다.
```console
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
@@ -188,7 +195,10 @@ kubectl logs counter count-log-1
```shell
kubectl logs counter count-log-2
```
```
출력은 다음과 같다.
```console
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:02 UTC 2001 INFO 2
@@ -204,11 +214,10 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2
`stdout` 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에
쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍
사이드카 컨테이너 방식을 구현하는 대신 `/dev/stdout` 을 대상으로
설정하는 것이 더 낫다.
설정하는 것을 추천한다.
사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는
로그 파일을 로테이션할 수도 있다. 이 방법의 예로는
정기적으로 logrotate를 실행하는 작은 컨테이너를 두는 것이다.
로그 파일을 로테이션할 수도 있다. 이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다.
그러나, `stdout` 및 `stderr` 을 직접 사용하고 로테이션과
유지 정책을 kubelet에 두는 것이 권장된다.
@@ -223,21 +232,17 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2
{{< note >}}
사이드카 컨테이너에서 로깅 에이전트를 사용하면
상당한 리소스 소비로 이어질 수 있다. 게다가, kubelet에 의해
제어되지 않기 때문에, `kubectl logs` 명령을 사용하여 해당 로그에
제어되지 않기 때문에, `kubectl logs` 를 사용하여 해당 로그에
접근할 수 없다.
{{< /note >}}
예를 들어, 로깅 에이전트로 fluentd를 사용하는 [스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)를
사용할 수 있다. 여기에 이 방법을 구현하는 데 사용할 수 있는
두 가지 구성 파일이 있다. 첫 번째 파일에는
fluentd를 구성하기 위한 [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다.
여기에 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 구성 파일이 있다. 첫 번째 파일에는
fluentd를 구성하기 위한 [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다.
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
{{< note >}}
fluentd의 구성은 이 문서의 범위를 벗어난다.
fluentd를 구성하는 것에 대한 자세한 내용은,
[공식 fluentd 문서](https://docs.fluentd.org/)를 참고한다.
fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](https://docs.fluentd.org/)를 참고한다.
{{< /note >}}
두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다.
@@ -245,16 +250,10 @@ fluentd를 구성하는 것에 대한 자세한 내용은,
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
얼마 후 스택드라이버 인터페이스에서 로그 메시지를 찾을 수 있다.
이것은 단지 예시일 뿐이며 실제로 애플리케이션 컨테이너 내의
모든 소스에서 읽은 fluentd를 로깅 에이전트로 대체할 수 있다는 것을
기억한다.
이 예시 구성에서, 사용자는 애플리케이션 컨테이너 내의 모든 소스을 읽는 fluentd를 다른 로깅 에이전트로 대체할 수 있다.
### 애플리케이션에서 직접 로그 노출
![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png)
모든 애플리케이션에서 직접 로그를 노출하거나 푸시하여 클러스터-레벨 로깅을
구현할 수 있다. 그러나, 이러한 로깅 메커니즘의 구현은
쿠버네티스의 범위를 벗어난다.
모든 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다.
content/ko/docs/concepts/cluster-administration/manage-deployment.md
+18 -9
View File
@@ -1,4 +1,6 @@
---
title: 리소스 관리
content_type: concept
weight: 40
@@ -43,7 +45,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
`kubectl` 은 접미사가 `.yaml`, `.yml` 또는 `.json` 인 파일을 읽는다.
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 일괄로 배포할 수 있다.
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다.
URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
@@ -68,7 +70,7 @@ deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted
```
두 개의 리소스만 있는 경우, 리소스/이름 구문을 사용하여 커맨드 라인에서 둘다 모두 쉽게 지정할 수도 있다.
두 개의 리소스가 있는 경우, 리소스/이름 구문을 사용하여 커맨드 라인에서 둘다 모두 지정할 수도 있다.
```shell
kubectl delete deployments/my-nginx services/my-nginx-svc
@@ -85,10 +87,11 @@ deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted
```
`kubectl` 은 입력을 받아들이는 것과 동일한 구문으로 리소스 이름을 출력하므로, `$()` 또는 `xargs` 를 사용하여 작업을 쉽게 연결할 수 있다.
`kubectl` 은 입력을 받아들이는 것과 동일한 구문으로 리소스 이름을 출력하므로, `$()` 또는 `xargs` 를 사용하여 작업을 연결할 수 있다.
```shell
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
@@ -262,7 +265,7 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
## 레이블 업데이트
새로운 리소스를 만들기 전에 기존 파드 및 기타 리소스의 레이블을 다시 지정해야 하는 경우가 있다. 이것은 `kubectl label` 로 수행할 수 있다.
예를 들어, 모든 nginx 파드에 프론트엔드 티어로 레이블을 지정하려면, 간단히 다음과 같이 실행한다.
예를 들어, 모든 nginx 파드에 프론트엔드 티어로 레이블을 지정하려면, 다음과 같이 실행한다.
```shell
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 get pods my-nginx-v4-9gw19 -o yaml
```
```shell
apiVersion: v1
kind: pod
@@ -312,11 +316,12 @@ metadata:
## 애플리케이션 스케일링
애플리케이션의 로드가 증가하거나 축소되면, `kubectl` 을 사용하여 쉽게 스케일링할 수 있다. 예를 들어, nginx 레플리카 수를 3에서 1로 줄이려면, 다음을 수행한다.
애플리케이션의 로드가 증가하거나 축소되면, `kubectl` 을 사용하여 애플리케이션을 스케일링한다. 예를 들어, nginx 레플리카 수를 3에서 1로 줄이려면, 다음을 수행한다.
```shell
kubectl scale deployment/my-nginx --replicas=1
```
```shell
deployment.apps/my-nginx scaled
```
@@ -326,6 +331,7 @@ deployment.apps/my-nginx scaled
```shell
kubectl get pods -l app=nginx
```
```shell
NAME READY STATUS RESTARTS AGE
my-nginx-2035384211-j5fhi 1/1 Running 0 30m
@@ -336,6 +342,7 @@ my-nginx-2035384211-j5fhi 1/1 Running 0 30m
```shell
kubectl autoscale deployment/my-nginx --min=1 --max=3
```
```shell
horizontalpodautoscaler.autoscaling/my-nginx autoscaled
```
@@ -404,11 +411,12 @@ JSON 병합 패치 그리고 전략적 병합 패치를 지원한다.
## 파괴적(disruptive) 업데이트
경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 간단히 수정할 수 있다.
경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 수정할 수 있다.
```shell
kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
```
```shell
deployment.apps/my-nginx deleted
deployment.apps/my-nginx replaced
@@ -425,19 +433,22 @@ nginx 1.14.2 버전을 실행한다고 가정해 보겠다.
```shell
kubectl create deployment my-nginx --image=nginx:1.14.2
```
```shell
deployment.apps/my-nginx created
```
3개의 레플리카를 포함한다(이전과 새 개정판이 공존할 수 있음).
```shell
kubectl scale deployment my-nginx --current-replicas=1 --replicas=3
```
```
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
kubectl edit deployment/my-nginx
@@ -452,5 +463,3 @@ kubectl edit deployment/my-nginx
- [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/docs/tasks/debug-application-cluster/debug-application-introspection/)에 대해 알아본다.
- [구성 모범 사례 및 팁](/ko/docs/concepts/configuration/overview/)을 참고한다.
content/ko/docs/concepts/configuration/overview.md
+2 -2
View File
@@ -59,13 +59,13 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
- `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/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
content/ko/docs/concepts/configuration/secret.md
+8 -12
View File
@@ -1,4 +1,6 @@
---
title: 시크릿(Secret)
content_type: concept
feature:
@@ -24,8 +26,8 @@ weight: 30
{{< caution >}}
쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색 할 수 있다.
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
@@ -280,9 +282,9 @@ API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
검증도 한다.
{{< caution >}}
SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버간에 신뢰할 수있는 통신을
설정하지 않는다. ConfigMap에 추가된 `known_hosts` 파일과 같은
"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는
SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버 간에 신뢰할 수 있는 통신을
설정하지 않는다. 컨피그맵(ConfigMap)에 추가된 `known_hosts` 파일과 같은
"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는
2차 수단이 필요하다.
{{< /caution >}}
@@ -667,7 +669,7 @@ kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신
그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다.
시크릿은 watch(기본값), ttl 기반 또는 단순히 API 서버로 모든 요청을 직접
시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접
리디렉션하여 전파할 수 있다.
결과적으로, 시크릿이 업데이트된 순간부터 새로운 키가 파드에 투영되는
순간까지의 총 지연 시간은 kubelet 동기화 시간 + 캐시
@@ -799,11 +801,6 @@ immutable: true
해당 프로세스에 대한 자세한 설명은
[서비스 어카운트에 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/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+16 -14
View File
@@ -1,4 +1,7 @@
---
title: 컨테이너 라이프사이클 훅(Hook)
content_type: concept
weight: 30
@@ -33,10 +36,13 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
`PreStop`
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다.
그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로,
컨테이너를 중지하기 위한 신호가 전송되기 전에 완료되어야 한다.
파라미터는 핸들러에 전달되지 않는다.
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합
등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미
terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실패하며,
훅은 컨테이너를 중지하기 위한 TERM 신호가 보내지기 이전에 완료되어야 한다. 파드의 그레이스 종료
기간(termination grace period)의 초읽기는 `PreStop` 훅이 실행되기 전에 시작되어,
핸들러의 결과에 상관없이 컨테이너가 파드의 그레이스 종료 기간 내에 결국 종료되도록 한다.
어떠한 파라미터도 핸들러에게 전달되지 않는다.
종료 동작에 더 자세한 대한 설명은
[파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다.
@@ -62,17 +68,13 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면,
컨테이너는 `running` 상태에 이르지 못한다.
`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로
실행되지 않는다. 훅은 신호를 보내기 전에 실행을
완료해야 한다.
실행 중에 `PreStop` 훅이 중단되면,
`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로 실행되지 않는다. 훅은
TERM 신호를 보내기 전에 실행을 완료해야 한다. 실행 중에 `PreStop` 훅이 중단되면,
파드의 단계는 `Terminating` 이며 `terminationGracePeriodSeconds` 가
만료된 후 파드가 종료될 때까지 남아 있다.
이 유예 기간은 `PreStop` 훅이 실행되고 컨테이너가
정상적으로 중지되는 데 걸리는 총 시간에 적용된다.
예를 들어, `terminationGracePeriodSeconds` 가 60이고, 훅이
완료되는 데 55초가 걸리고, 컨테이너가 신호를 수신한 후
정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후
만료된 후 파드가 종료될 때까지 남아 있다. 이 유예 기간은 `PreStop` 훅이
실행되고 컨테이너가 정상적으로 중지되는 데 걸리는 총 시간에 적용된다. 예를 들어,
`terminationGracePeriodSeconds` 가 60이고, 훅이 완료되는 데 55초가 걸리고,
컨테이너가 신호를 수신한 후 정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후
컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데
걸리는 총 시간(55+10)보다 적다.
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+4 -1
View File
@@ -1,5 +1,8 @@
---
title: 커스텀 리소스
content_type: concept
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 애그리게이션을 이해할 필요는 없다.
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+5 -1
View File
@@ -1,4 +1,8 @@
---
title: 네트워크 플러그인
content_type: concept
weight: 10
@@ -20,7 +24,7 @@ weight: 10
kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 단순히 "cni"이다.
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
## 네트워크 플러그인 요구 사항
content/ko/docs/concepts/extend-kubernetes/service-catalog.md
+3 -6
View File
@@ -1,5 +1,7 @@
---
title: 서비스 카탈로그
content_type: concept
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) 살펴보기
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기
content/ko/docs/concepts/overview/what-is-kubernetes.md
+4 -1
View File
@@ -1,4 +1,7 @@
---
title: 쿠버네티스란 무엇인가?
description: >
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다.
@@ -40,7 +43,7 @@ sitemap:
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
content/ko/docs/concepts/overview/working-with-objects/labels.md
+9 -8
View File
@@ -1,4 +1,6 @@
---
title: 레이블과 셀렉터
content_type: concept
weight: 40
@@ -40,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
* `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"`
레이블 예시는 일반적으로 사용하는 상황에 해당한다. 당신의 규약에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
## 구문과 캐릭터 셋
@@ -90,14 +92,13 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
{{< /note >}}
{{< caution >}}
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다.
필터 구문이 적절히 구성되어있는지 확인해야 한다.
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
{{< /caution >}}
### _일치성 기준_ 요건
_일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다.
`=`,`==`,`!=` 이 3가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 단순히 동의어일 뿐임), 나머지는 _불일치_ 를 의미한다. 예를 들면,
`=`,`==`,`!=` 이 세 가지 연산자만 허용한다. 처음 두 개의 연산자의 _일치성_(그리고 동의어), 나머지는 _불일치_ 를 의미한다. 예를 들면,
```
environment = production
@@ -109,7 +110,8 @@ tier != frontend
`environment=production,tier!=frontend` 처럼 쉼표를 통해 한 문장으로 `frontend`를 제외한 `production`을 필터링할 수 있다.
일치성 기준 레이블 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`" 레이블을 가진 노드를 선택한다.
예를 들어, 아래 샘플 파드는 "`accelerator=nvidia-tesla-p100`"
레이블을 가진 노드를 선택한다.
```yaml
apiVersion: v1
@@ -148,11 +150,12 @@ _집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=productio
_집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 수 있다. 예를 들어 `partition in (customerA, customerB),environment!=qa`
## API
### LIST와 WATCH 필터링
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 두 가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
* _일치성 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
@@ -208,7 +211,6 @@ selector:
`json` 또는 `yaml` 서식에서 셀렉터는 `component=redis` 또는 `component in (redis)` 모두 같은 것이다.
#### 세트-기반 요건을 지원하는 리소스
[`Job`](/ko/docs/concepts/workloads/controllers/job/),
@@ -232,4 +234,3 @@ selector:
레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다.
content/ko/docs/concepts/overview/working-with-objects/object-management.md
+3 -3
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 >}}
content/ko/docs/concepts/policy/resource-quotas.md
+21 -8
View File
@@ -1,4 +1,6 @@
---
title: 리소스 쿼터
content_type: concept
weight: 20
@@ -608,17 +610,28 @@ plugins:
values: ["cluster-services"]
```
이제 "cluster-services" 파드는 `scopeSelector`와 일치하는 쿼터 오브젝트가 있는 네임스페이스에서만 허용된다.
예를 들면 다음과 같다.
그리고, `kube-system` 네임스페이스에 리소스 쿼터 오브젝트를 생성한다.
```yaml
scopeSelector:
matchExpressions:
- scopeName: PriorityClass
operator: In
values: ["cluster-services"]
{{< codenew file="policy/priority-class-resourcequota.yaml" >}}
```shell
$ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
```
```
resourcequota/pods-cluster-services created
```
이 경우, 파드 생성은 다음의 조건을 만족해야 허용될 것이다.
1. 파드의 `priorityClassName` 가 명시되지 않음.
1. 파드의 `priorityClassName` 가 `cluster-services` 이외의 다른 값으로 명시됨.
1. 파드의 `priorityClassName` 가 `cluster-services` 로 설정되고, 파드가 `kube-system`
네임스페이스에 생성되었으며 리소스 쿼터 검증을 통과함.
파드 생성 요청은 `priorityClassName` 가 `cluster-services` 로 명시되고
`kube-system` 이외의 다른 네임스페이스에 생성되는 경우, 거절된다.
## {{% heading "whatsnext" %}}
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다.
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+1 -1
View File
@@ -261,7 +261,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
`topologyKey` 의 빈 값을 허용하지 않는다.
2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는
`topologyKey` 의 빈 값을 허용하지 않는다.
3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다.
3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 이를 비활성화해야 한다.
4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다.
`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+2
View File
@@ -1,4 +1,6 @@
---
title: 스케줄러 성능 튜닝
content_type: concept
weight: 80
content/ko/examples/policy/priority-class-resourcequota.yaml
+10
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"]