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

Eighth Korean l10n work for release 1.18 

- Translate tasks/administer-cluster/declare-network-policy in Korean (#22526)
- Translate tasks/debug-application-cluster/debug-init-containers in Korean (#22608)
- Fix a missing markdown syntax to enable external link (#22661)
- Translate tasks/administer-cluster/change-pv-reclaim-policy in Korean (#22551)
- Update docs/contribute/participate/ for Korean (#22605)
- Update outdated files in dev-1.18-ko.8 (#22466)
- Translate tasks/administer-cluster/dns-custom-nameservers in Korean (#22524)

Co-authored-by: Daehyun Paik <paik@a30a.dev>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
bluefriday 2020-07-15 10:59:52 +09:00 committed by June Yi
parent 6bf2feba74
commit fe296af187
46 changed files with 1454 additions and 654 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
content/ko/docs/concepts/_index.md
View File

@ -12,59 +12,3 @@ weight: 40
<!-- body -->
## 개요
쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다.
바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다.
* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다.
* 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다.
* 쿠버네티스 마스터와 통신하는 **[kubelet](/docs/admin/kubelet/)**.
* 각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시인 **[kube-proxy](/docs/admin/kube-proxy/)**.
## 쿠버네티스 오브젝트
쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다.
기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다.
* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
* [서비스](/ko/docs/concepts/services-networking/service/)
* [볼륨](/ko/docs/concepts/storage/volumes/)
* [네임스페이스(Namespace)](/ko/docs/concepts/overview/working-with-objects/namespaces/)
또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)
* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/)
* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
* [잡(Job)](/ko/docs/concepts/workloads/controllers/job/)
## 쿠버네티스 컨트롤 플레인
쿠버네티스 마스터와 kubelet 프로세스와 같은 쿠버네티스 컨트롤 플레인의 다양한 구성 요소는 쿠버네티스가 클러스터와 통신하는 방식을 관장한다. 컨트롤 플레인은 시스템 내 모든 쿠버네티스 오브젝트의 레코드를 유지하면서, 오브젝트의 상태를 관리하는 제어 루프를 지속적으로 구동시킨다. 컨트롤 플레인의 제어 루프는 클러스터 내 변경이 발생하면 언제라도 응답하고 시스템 내 모든 오브젝트의 실제 상태가 사용자가 바라는 상태와 일치시키기 위한 일을 한다.
예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다.
### 쿠버네티스 마스터
클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다.
> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 모든 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
### 쿠버네티스 노드
클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신(VM, 물리 서버 등)이다. 쿠버네티스 마스터는 각 노드를 관리한다. 직접 노드와 직접 상호 작용할 일은 거의 없을 것이다.
## {{% heading "whatsnext" %}}
개념 페이지를 작성하기를 원하면,
개념 페이지 타입에 대한 정보가 있는
[페이지 컨텐츠 타입](/docs/contribute/style/page-content-types/#concept)을 참고한다.

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

@ -1,4 +1,6 @@
---
title: "클러스터 아키텍처"
weight: 30
description: >
쿠버네티스 뒤편의 구조와 설계 개념들
---

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

@ -1,5 +1,71 @@
---
title: "클러스터 관리"
title: 클러스터 관리
weight: 100
content_type: concept
description: >
쿠버네티스 클러스터 생성 또는 관리에 관련된 로우-레벨(lower-level)의 세부 정보를 설명한다.
no_list: true
---
<!-- overview -->
클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.
<!-- body -->
## 클러스터 계획
쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다. 이 문서에 나열된 솔루션을 *배포판* 이라고 한다.
{{< note >}}
모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된 배포판을 선택한다.
{{< /note >}}
가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다.
- 컴퓨터에서 쿠버네티스를 그냥 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
- [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가?
- 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
- **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
- 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
- **단지 클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약
후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
더 다양한 선택을 제공한다.
- 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.
## 클러스터 관리
* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터 라이프사이클과 관련된 몇 가지 주제를 설명한다. 새로운 클러스터 생성, 클러스터의 마스터 및 워커 노드 업그레이드, 노드 유지 관리 수행(예: 커널 업그레이드) 및 실행 중인 클러스터의 쿠버네티스 API 버전 업그레이드
* [노드 관리](/ko/docs/concepts/architecture/nodes/) 방법을 배운다.
* 공유 클러스터에 대한 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하고 관리하는 방법을 배운다.
## 클러스터 보안
* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
* [인가](/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
### kubelet 보안
* [마스터-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/)
## 선택적 클러스터 서비스
* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다.
* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다.

66
content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md
View File

@ -1,66 +0,0 @@
---
title: 클러스터 관리 개요
content_type: concept
weight: 10
---
<!-- overview -->
클러스터 관리 개요는 쿠버네티스 클러스터를 만들거나 관리하는 모든 사람들을 위한 것이다.
여기서는 쿠버네티스의 핵심 [개념](/ko/docs/concepts/)에 대해 잘 알고 있다고 가정한다.
<!-- body -->
## 클러스터 계획
[올바른 솔루션 고르기](/ko/docs/setup/pick-right-solution/)에서 쿠버네티스 클러스터를 어떻게 계획하고, 셋업하고, 구성하는 지에 대한 예시를 참조하자. 이 글에 쓰여진 솔루션들은 *배포판* 이라고 부른다.
가이드를 고르기 전에, 몇 가지 고려사항이 있다.
- 단지 자신의 컴퓨터에 쿠버네티스를 테스트를 하는지, 또는 고가용성의 멀티 노드 클러스터를 만들려고 하는지에 따라 니즈에 가장 적절한 배포판을 고르자.
- [구글 쿠버네티스 엔진](https://cloud.google.com/kubernetes-engine/)과 같은 **호스팅된 쿠버네티스 클러스터** 를 사용할 것인지, **자신의 클러스터에 호스팅할 것인지**?
- 클러스터가 **온프레미스** 인지, 또는 **클라우드(IaaS)** 인지? 쿠버네티스는 하이브리드 클러스터를 직접적으로 지원하지는 않는다. 대신에, 사용자는 여러 클러스터를 구성할 수 있다.
- **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다.
- 쿠버네티스 실행을 **"베어메탈" 하드웨어** 또는, **가상 머신 (VMs)** 중 어디에서 할 것 인지?
- **단지 클러스터 동작** 만 할 것인지, 아니면 **쿠버네티스 프로젝트 코드의 적극적인 개발** 을 원하는지? 만약 후자의 경우라면,
적극적으로 개발된 배포판을 선택한다. 몇몇 배포판은 바이너리 릴리스 밖에 없지만,
매우 다양한 선택권을 제공한다.
- 스스로 클러스터 구동에 필요한 [구성요소](/ko/docs/concepts/overview/components/)에 익숙해지자.
참고: 모든 배포판이 적극적으로 유지되는 것은 아니다. 최근 버전의 쿠버네티스로 테스트 된 배포판을 선택하자.
## 클러스터 관리
* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터의 라이프사이클과 관련된 몇 가지 주제를 설명한다. 이는 새 클러스터 생성, 마스터와 워커노드 업그레이드, 노드 유지보수 실행 (예: 커널 업그레이드), 그리고 동작 중인 클러스터의 쿠버네티스 API 버전 업그레이드 등을 포함한다.
* 어떻게 [노드 관리](/ko/docs/concepts/architecture/nodes/)를 하는지 배워보자.
* 공유된 클러스터의 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 어떻게 셋업하고 관리할 것인지 배워보자.
## 클러스터 보안
* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다.
* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증을 설명한다.
* [인가](/docs/reference/access-authn-authz/authorization/)은 인증과 다르며, HTTP 호출이 처리되는 방법을 제어한다.
* [어드미션 컨트롤러 사용](/docs/reference/access-authn-authz/admission-controllers/)은 쿠버네티스 API 서버에서 인증과 인가 후 요청을 가로채는 플러그인을 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 툴을 사용하여 커널 파라미터를 설정하는 방법을 설명한다.
* [감시](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스 감시 로그가 상호작용 하는 방법을 설명한다.
### kubelet 보안
* [마스터노드 커뮤니케이션](/ko/docs/concepts/architecture/master-node-communication/)
* [TLS 부트스트래핑](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/)
## 선택적 클러스터 서비스
* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
* [클러스터 활동 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.

3
content/ko/docs/concepts/configuration/_index.md
View File

@ -1,5 +1,6 @@
---
title: "구성"
weight: 80
description: >
쿠버네티스가 파드 구성을 위해 제공하는 리소스
---

33
content/ko/docs/concepts/configuration/configmap.md
View File

@ -126,25 +126,32 @@ spec:
configMap:
# 마운트하려는 컨피그맵의 이름을 제공한다.
name: game-demo
# 컨피그맵에서 파일로 생성할 키 배열
items:
- key: "game.properties"
path: "game.properties"
- key: "user-interface.properties"
path: "user-interface.properties"
```
컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을
구분하지 않는다.
더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다.
이 예제에서, 볼륨을 정의하고 `demo` 컨테이너에
`/config` 로 마운트하면 4개의 파일이 생성된다.
`/config` 로 마운트하면 컨피그맵에 4개의 키가 있더라도
`/config/game.properties` 와 `/config/user-interface.properties`
2개의 파일이 생성된다. 이것은 파드 정의가
`volume` 섹션에서 `items` 배열을 지정하기 때문이다.
`items` 배열을 완전히 생략하면, 컨피그맵의 모든 키가
키와 이름이 같은 파일이 되고, 4개의 파일을 얻게 된다.
- `/config/player_initial_lives`
- `/config/ui_properties_file_name`
- `/config/game.properties`
- `/config/user-interface.properties`
## 컨피그맵 사용하기
`/config` 에 `.properties` 확장자를 가진 파일만
포함시키려면, 두 개의 다른 컨피그맵을 사용하고, 파드에
대해서는 `spec` 의 두 컨피그맵을 참조한다. 첫 번째 컨피그맵은
`player_initial_lives` 와 `ui_properties_file_name` 을 정의한다. 두 번째
컨피그맵은 kubelet이 `/config` 에 넣는 파일을 정의한다.
컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로
노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
{{< note >}}
컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의
@ -157,12 +164,6 @@ spec:
사용할 수도 있다.
{{< /note >}}
## 컨피그맵 사용하기
컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로
노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
### 파드에서 컨피그맵을 파일로 사용하기
파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.

4
content/ko/docs/concepts/configuration/manage-resources-containers.md
View File

@ -657,7 +657,7 @@ Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
```
위의 출력에서, ​파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를
@ -758,5 +758,3 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기
* XFS의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기

40
content/ko/docs/concepts/configuration/pod-overhead.md
View File

@ -11,7 +11,7 @@ weight: 20
노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다.
_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해
_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해
소비되는 리소스를 계산하는 기능이다.
@ -20,25 +20,25 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
<!-- body -->
쿠버네티스에서 파드의 오버헤드는 파드의
[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라
[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
쿠버네티스에서 파드의 오버헤드는 파드의
[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라
[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
이 수행될 때 지정된다.
파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에
파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나
파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에
파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나
파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다.
## 파드 오버헤드 활성화하기 {#set-up}
기능 활성화를 위해 클러스터에서
`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화),
기능 활성화를 위해 클러스터에서
`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화),
`overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다.
## 사용 예제
파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다.
예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는
예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는
가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다.
```yaml
@ -54,7 +54,7 @@ overhead:
cpu: "250m"
```
`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산,
`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산,
노드 스케줄링 및 파드 cgroup 크기 조정을 위하여 메모리와 CPU 오버헤드를 고려한다.
주어진 예제 워크로드 test-pod의 구동을 고려해보자.
@ -83,9 +83,9 @@ spec:
memory: 100Mi
```
어드미션 수행 시에, [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는
런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면,
파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가
어드미션 수행 시에, [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는
런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면,
파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가
`overhead` 를 포함하도록 변경한다.
런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다.
@ -99,11 +99,11 @@ kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
map[cpu:250m memory:120Mi]
```
만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는
만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는
`overhead` 필드도 추가된다.
kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와
해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는
kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와
해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는
리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다.
일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다.
@ -142,7 +142,7 @@ CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는
## 파드 cgroup 상한 확인하기
워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며,
워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며,
CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다.
파드의 오버헤드 동작을 보여주는 좋은 예이며,
사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
@ -178,8 +178,8 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
```
### 관찰성
`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고,
`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고,
정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다.
그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다.
@ -191,5 +191,3 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)
* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)

38
content/ko/docs/concepts/containers/_index.md
View File

@ -1,5 +1,41 @@
---
title: "컨테이너"
title: 컨테이너
weight: 40
description: 런타임 의존성과 함께 애플리케이션을 패키징하는 기술
content_type: concept
no_list: true
---
<!-- overview -->
실행하는 각 컨테이너는 반복 가능하다. 의존성이 포함된 표준화는
어디에서 실행하던지 동일한 동작을 얻는다는 것을
의미한다.
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 ​​배포할 수 있다.
<!-- body -->
## 컨테이너 이미지
[컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다.
여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
그리고 모든 필수 설정에 대한 기본값이 포함된다.
설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를
변경할 수 없다. 컨테이너화된 애플리케이션이 있고
변경하려는 경우, 변경 사항이 포함된 새 컨테이너를 빌드한
다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다.
## 컨테이너 런타임
{{< glossary_definition term_id="container-runtime" length="all" >}}
## {{% heading "whatsnext" %}}
* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기
* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기

43
content/ko/docs/concepts/containers/overview.md
View File

@ -1,43 +0,0 @@
---
title: 컨테이너 개요
content_type: concept
weight: 10
---
<!-- overview -->
컨테이너는 런타임에 필요한 종속성과 애플리케이션의
컴파일 된 코드를 패키징 하는 기술이다. 실행되는 각각의
컨테이너는 반복해서 사용 가능하다. 종속성이 포함된 표준화를
통해 컨테이너가 실행되는 환경과 무관하게 항상 동일하게
동작한다.
컨테이너는 기본 호스트 인프라 환경에서 애플리케이션의 실행환경을 분리한다.
따라서 다양한 클라우드 환경이나 운영체제에서 쉽게 배포 할 수 있다.
<!-- body -->
## 컨테이너 이미지
[컨테이너 이미지](/ko/docs/concepts/containers/images/) 는 즉시 실행할 수 있는
소프트웨어 패키지이며, 애플리케이션을 실행하는데 필요한 모든 것
(필요한 코드와 런타임, 애플리케이션 및 시스템 라이브러리 등의 모든 필수 설정에 대한 기본값)
을 포함한다.
원칙적으로, 컨테이너는 변경되지 않는다. 이미 구동 중인 컨테이너의
코드를 변경할 수 없다. 컨테이너화 된 애플리케이션이 있고 그
애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든
새로운 이미지를 통해 컨테이너를 다시 생성해야 한다.
## 컨테이너 런타임
{{< glossary_definition term_id="container-runtime" length="all" >}}
## {{% heading "whatsnext" %}}
* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기
* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기

204
content/ko/docs/concepts/extend-kubernetes/_index.md
View File

@ -1,4 +1,206 @@
---
title: 쿠버네티스 확장하기
title: 쿠버네티스 확장
weight: 110
description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
content_type: concept
no_list: true
---
<!-- overview -->
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
거의 없다.
이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
쿠버네티스 클러스터를 업무 환경의 요구에 맞게
조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다.
잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
어떤 익스텐션(extension) 포인트와 패턴이 있는지,
그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
<!-- body -->
## 개요
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
## 구성
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
* [kubelet](/docs/admin/kubelet/)
* [kube-apiserver](/docs/admin/kube-apiserver/)
* [kube-controller-manager](/docs/admin/kube-controller-manager/)
* [kube-scheduler](/docs/admin/kube-scheduler/).
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다.
## 익스텐션
익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
## 익스텐션 패턴
쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다.
쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다.
*자동화* 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라
고가용성과 강력한 자동화를 작성할 수 있다.
자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든
쿠버네티스 클러스터에서 작동한다.
쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다.
컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음
오브젝트의 `.status`를 업데이트 한다.
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를
*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
추가한다.
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예:
[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
kubectl에서
사용한다.
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
보여주는 다이어그램이다.
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
## 익스텐션 포인트
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다.
5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
## API 익스텐션
### 사용자 정의 유형
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
### 새로운 API와 자동화의 결합
사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
### 빌트인 리소스 변경
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
### API 접근 익스텐션
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
이러한 각 단계는 익스텐션 포인트를 제공한다.
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
### 인증
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다.
쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
### 인가
[인가](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
### 동적 어드미션 컨트롤
요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다.
* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
## 인프라스트럭처 익스텐션
### 스토리지 플러그인
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
### 장치 플러그인
장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
발견할 수 있게 해준다.
### 네트워크 플러그인
노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
### 스케줄러 익스텐션
스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
기본 스케줄러를 완전히 교체하거나,
[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를
동시에 실행할 수 있다.
이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할
필요가 없다는 것을 알게 된다.
스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가
파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는
[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을
지원한다.
## {{% heading "whatsnext" %}}
* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기
* 인프라스트럭처 익스텐션에 대해 더 알아보기
* [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
* [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기
* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기

3
content/ko/docs/concepts/overview/_index.md
View File

@ -1,4 +1,5 @@
---
title: "개요"
weight: 20
---
description: 쿠버네티스와 그 컴포넌트에 대한 하이-레벨(high-level) 개요를 제공한다.
---

2
content/ko/docs/concepts/overview/working-with-objects/_index.md
View File

@ -2,6 +2,6 @@
title: "쿠버네티스 오브젝트로 작업하기"
weight: 40
description: >
쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다.
쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다.
쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다.
---

2
content/ko/docs/concepts/policy/_index.md
View File

@ -1,4 +1,6 @@
---
title: "정책"
weight: 90
description: >
리소스의 그룹에 적용되도록 구성할 수 있는 정책
---

3
content/ko/docs/concepts/scheduling-eviction/_index.md
View File

@ -1,4 +1,7 @@
---
title: "스케줄링과 축출(eviction)"
weight: 90
description: >
쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다.
축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다.
---

1
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -95,4 +95,3 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기

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

@ -1,4 +1,6 @@
---
title: "보안"
weight: 81
description: >
클라우드 네이티브 워크로드를 안전하게 유지하기 위한 개념
---

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

@ -1,4 +1,12 @@
---
title: "서비스, 로드밸런싱, 네트워킹"
weight: 60
description: >
쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다.
---
쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.
- 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다.
- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
- 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다.
- 또한 서비스를 사용하여 클러스터 내부에서 사용할 수 있는 서비스만 게시할 수 있다.

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

@ -31,7 +31,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
VMware에서 제공하고 지원한다.
* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
[지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
* [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다.
* [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.

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

@ -88,7 +88,7 @@ spec:
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은,
들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP 트래픽을
들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을
지시하는 규칙만 지원한다.
### 인그레스 규칙

3
content/ko/docs/concepts/storage/_index.md
View File

@ -1,5 +1,6 @@
---
title: "스토리지"
weight: 70
description: >
클러스터의 파드에 장기(long-term) 및 임시 스토리지를 모두 제공하는 방법
---

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

@ -24,7 +24,7 @@ weight: 20
_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다.
_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음).
_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고).
퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.

2
content/ko/docs/concepts/workloads/_index.md
View File

@ -1,4 +1,6 @@
---
title: "워크로드"
weight: 50
description: >
쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화
---

3
content/ko/docs/contribute/_index.md
View File

@ -3,6 +3,7 @@ content_type: concept
title: 쿠버네티스 문서에 기여하기
linktitle: 기여
main_menu: true
no_list: true
weight: 80
card:
name: contribute
@ -23,8 +24,6 @@ card:
쿠버네티스 문서는 새롭고 경험이 풍부한 모든 기여자의 개선을 환영합니다!
<!-- body -->
## 시작하기

63
content/ko/docs/contribute/advanced.md
View File

@ -17,67 +17,6 @@ weight: 98
<!-- body -->
## 일주일 동안 PR 랭글러(Wrangler) 되기
SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 리포지터리에 대해 1주일 정도씩 [PR을 조정(wrangling)](https://github.com/kubernetes/website/wiki/PR-Wranglers)하는 역할을 맡는다.
PR 랭글러의 임무는 다음과 같다.
- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다.
- 가장 작은 PR(`size/XS`)을 먼저 리뷰한 다음, 가장 큰(`size/XXL`) PR까지 옮겨가며 리뷰를 반복한다.
- 가능한 한 많은 PR을 리뷰한다.
- 각 기여자가 CLA에 서명했는지 확인한다.
- 새로운 기여자가 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명하도록 도와준다.
- CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 자동으로 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다.
- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버로부터의 기술 리뷰가 잘 진행되게 조율한다.
- 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다.
- 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다.
- 관련 `sig/` 레이블을 할당한다.
- 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다.
- PR의 리뷰 상태를 표시하기 위해 `Docs Review` 와 `Tech Review` 레이블을 할당한다.
- 아직 리뷰되지 않은 PR에 `Needs Doc Review` 나 `Needs Tech Review` 를 할당한다.
- 리뷰가 진행되었고, 병합하기 전에 추가 입력이나 조치가 필요한 PR에 `Doc Review: Open Issues` 나 `Tech Review: Open Issues` 를 할당한다.
- 병합할 수 있는 PR에 `/lgtm` 과 `/approve` 를 할당한다.
- PR이 준비가 되면 병합하거나, 수락해서는 안되는 PR을 닫는다.
- 콘텐츠가 문서의 [스타일 가이드라인](/docs/contribute/style/style-guide/) 중 일부만 충족하더라도 정확한 기술 콘텐츠를 수락하는 것이 좋다. 스타일 문제를 해결하기 위해 `good first issue` 라는 레이블로 새로운 이슈를 연다.
- 새로운 이슈를 매일 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다.
## 랭글러에게 유용한 GitHub 쿼리
다음의 쿼리는 랭글러에게 도움이 된다. 이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은
일반적으로 작다. 이 쿼리들은 특히 현지화 PR을 제외하고, `master` 브랜치만 포함한다(마지막 쿼리는 제외).
- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고
CLA에 서명한 후 PR을 열 수 있음을 알린다.
**작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 문서 리뷰나
교정이 필요한 경우, 변경 사항을 제안하거나 교정하는 커밋을 PR에 추가하여 진행한다.
- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
PR을 병합하기 위해 추가 변경이나 업데이트가 필요한지 여부를 결정한다. PR을 병합할 준비가 되었다고 생각되면, `/approve` 코멘트를 남긴다.
- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 master에 대한 작은 PR인 경우. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
- [master 이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 코멘트로 추가하여 [릴리스 마이스터](https://github.com/kubernetes/sig-release/tree/master/release-team)가 그것에 대해 알고 있는지 확인한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
### 풀 리퀘스트를 종료하는 시기
리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다.
- CLA가 2주 동안 서명되지 않은 모든 PR을 닫는다.
PR 작성자는 CLA에 서명한 후 PR을 다시 열 수 있으므로, 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다.
- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않은 모든 PR을 닫는다.
풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다.
풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다.
{{< note >}}
[`fejta-bot`](https://github.com/fejta-bot)이라는 자동화 서비스는 90일 동안 활동이 없으면 자동으로 이슈를 오래된 것으로 표시한 다음, 그 상태에서 추가로 30일 동안 활동이 없으면 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.
{{< /note >}}
## 개선 제안
SIG Docs [멤버](/ko/docs/contribute/participating/#멤버)는 개선을 제안할 수 있다.
@ -245,5 +184,3 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs
녹화를 중지하려면, Stop을 클릭한다.
비디오가 자동으로 유튜브에 업로드된다.

24
content/ko/docs/contribute/new-content/open-a-pr.md
View File

@ -97,10 +97,12 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
### 로컬 클론 생성 및 업스트림 설정
3. 터미널 창에서, 포크를 클론한다.
3. 터미널 창에서, 포크를 클론하고 [Docsy Hugo 테마](https://github.com/google/docsy#readme)를 업데이트한다.
```bash
git clone git@github.com/<github_username>/website
cd website
git submodule update --init --recursive --depth 1
```
4. 새 `website` 디렉터리로 이동한다. `kubernetes/website` 리포지터리를 `upstream` 원격으로 설정한다.
@ -263,18 +265,26 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다.
5. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
6. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다.
테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
```bash
git submodule update --init --recursive --depth 1
```
3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
```bash
cd <path_to_your_repo>/website
hugo server
hugo server --buildFuture
```
7. 브라우저의 주소 표시줄에 `https://localhost:1313` 을 입력한다.
4. 웹 브라우저에서 `https://localhost:1313` 으로 이동한다. Hugo는
변경 사항을 보고 필요에 따라 사이트를 다시 구축한다.
8. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,
5. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,
    터미널 창을 닫는다.
{{% /tab %}}
@ -498,4 +508,4 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
## {{% heading "whatsnext" %}}
- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다.
- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/review/reviewing-prs)를 읽어본다.

120
content/ko/docs/contribute/participate/_index.md Normal file
View File

@ -0,0 +1,120 @@
---
title: SIG Docs에 참여하기
content_type: concept
weight: 60
card:
name: contribute
weight: 60
---
<!-- overview -->
SIG Docs는 쿠버네티스 프로젝트의
[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md)
중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다.
분과회에 대한 보다 자세한 정보는
[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
를 참조한다.
SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
누구나 풀 리퀘스트(PR)를 요청할 수 있고,
누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.
[멤버](/ko/docs/contribute/participating/roles-and-responsibilities/#멤버), [리뷰어](/ko/docs/contribute/participating/roles-and-responsibilities/#리뷰어), 또는 [승인자](/ko/docs/contribute/participating/roles-and-responsibilities/#승인자)가 될 수 있다.
이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
문서를 확인한다.
문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와
문서를 관리하는 책임을 가지는 SIG Docs에서,
이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.
<!-- body -->
## SIG Docs 의장
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다.
현재 의장의 목록을 확인하려면
[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
문서를 참조한다.
## SIG Docs 팀과 자동화
SIG Docs의 자동화는 다음의 두 가지 메커니즘에 의존한다.
GitHub 팀과 OWNERS 파일이다.
### GitHub 팀
GitHub의 SIG Docs [팀]에는 두 분류가 있다.
- 승인자와 리더를 위한 `@sig-docs-{language}-owners`
- 리뷰어를 위한 `@sig-docs-{language}-reviewers`
그룹의 전원과 의사소통하기 위해서
각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다.
가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다. 이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서
자동화 시스템이 `OWNERS` 파일의 정보를 활용한다.
### OWNERS 파일과 전문(front-matter)
쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다.
[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는
다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을
사용한다.
- blunderbuss
- approve
이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
파일을 사용해서
해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수
있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다.
일반적인 OWNERS 파일에 대한 보다 많은 정보는
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
문서를 참고한다.
추가로, 개별 마크다운(Markdown) 파일 내 전문에
리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다.
OWNERS 파일과 마크다운 파일 내 전문의 조합은
자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
PR 소유자에게 조언하는데 활용된다.
## 병합 작업 방식
풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는
브랜치에 병합되면, 해당 콘텐츠는 http://kubernetes.io 에 공개된다. 게시된 콘텐츠의
품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
작동 방식은 다음과 같다.
- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는
`/lgtm` 코멘트 보류).
- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
[PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과
같은 특정 역할도 수행한다.
## {{% heading "whatsnext" %}}
쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
- [문서 스타일 가이드](/ko/docs/contribute/style/)

70
content/ko/docs/contribute/participate/pr-wranglers.md Normal file
View File

@ -0,0 +1,70 @@
---
title: PR 랭글러(PR Wrangler)
content_type: concept
weight: 20
---
<!-- overview -->
SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다.
이 섹션은 PR 랭글러의 의무에 대해 다룬다. 좋은 리뷰 제공에 대한 자세한 내용은 [Reviewing changes](/ko/docs/contribute/review/)를 참고한다.
<!-- body -->
## 의무
PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)를 참고한다.
- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다.
- 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다.
- PR 기여자들이 [CLA]()에 서명했는지 확인한다.
- CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다.
- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버에게 기술 리뷰를 요청한다.
- 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다.
- 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다.
- 관련 `sig/` 레이블을 할당한다.
- 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다.
- PR을 병합하려면 승인을 위한 `approve` 코멘트를 사용한다. 준비가 되면 PR을 병합한다.
- 병합하기 전에 PR은 다른 멤버의 `/lgtm` 코멘트를 받아야 한다.
- [스타일 지침]을 충족하지 않지만 기술적으로는 정확한 PR은 수락하는 것을 고려한다. 스타일 문제를 해결하는 `good first issue` 레이블의 새로운 이슈를 올리면 된다.
### 랭글러를 위해 도움이 되는 GitHub 쿼리
다음의 쿼리는 랭글러에게 도움이 된다.
이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 일반적으로 작다.
이 쿼리들은 특히 현지화 PR을 제외한다. 모든 쿼리는 마지막 쿼리를 제외하고 메인 브렌치를 대상으로 한다.
- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고
CLA에 서명한 후 PR을 열 수 있음을 알린다.
**작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을
지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다.
- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
### 풀 리퀘스트를 종료하는 시기
리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다.
다음의 상황에서 PR을 닫는다.
- 작성자가 CLA에 2주 동안 서명하지 않았다.
작성자는 CLA에 서명한 후 PR을 다시 열 수 있다. 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다.
- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않았다.
풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다.
풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다.
{{< note >}}
[`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.
{{< /note >}}

195
content/ko/docs/contribute/participate/roles-and-responsibilties.md Normal file
View File

@ -0,0 +1,195 @@
---
title: 역할과 책임
content_type: concept
weight: 10
---
<!-- overview -->
누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라, 커뮤니티의 다양한 멤버십을 신청할 수 있다.
이러한 역할을 통해 커뮤니티 내에서 더 많은 책임을 질 수 있다.
각 역할마다 많은 시간과 노력이 필요하다. 역할은 다음과 같다.
- 모든 사람: 쿠버네티스 문서에 정기적으로 기여하는 기여자
- 멤버: 이슈를 할당, 심사하고 풀 리퀘스트에 대한 구속력 없는 리뷰를 제공할 수 있다.
- 리뷰어: 문서의 풀 리퀘스트에 대한 리뷰를 리딩할 수 있으며 변경 사항에 대한 품질을 보증할 수 있다.
- 승인자: 문서에 대한 리뷰를 리딩하고 변경 사항을 병합할 수 있다
<!-- body -->
## 모든 사람
GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG Docs는 모든 새로운 기여자를 환영한다!
모든 사람은 다음의 작업을 할 수 있다.
- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든 [쿠버네티스] 리포지터리에서 이슈를 올린다.
- 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다.
- 현지화에 기여한다.
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
- 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다.
자세한 내용은 [새로운 콘텐츠 기여하기](/ko/docs/contribute/new-content/)를 참고한다.
## 멤버
멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한 사람이다. 멤버는 [쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다.
멤버는 다음의 작업을 할 수 있다.
- [모든 사람](#모든-사람)에 나열된 모든 것을 한다.
- 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다.
{{< note >}}
`/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다!
{{< /note >}}
- `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다.
- `/assign` 코멘트를 사용하여 풀 리퀘스트에 리뷰어를 지정한다.
- 풀 리퀘스트에 구속력 없는 리뷰를 제공한다.
- 자동화를 사용하여 이슈를 심사하고 분류한다.
- 새로운 기능에 대한 문서를 작성한다.
### 멤버 되기
최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른 [요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다.
1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 [리뷰어](#리뷰어) 또는 [승인자](#승인자)를 찾는다.
[슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는
[SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다.
{{< note >}}
SIG Docs 멤버 개인에게 직접 email을 보내거나
슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다.
{{< /note >}}
2. [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에 GitHub 이슈를 등록한다. **Organization Membership Request** 이슈 템플릿을 사용한다.
3. 후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다.
- 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@<GitHub-username>`)
- 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다.
후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면, 쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다. 축하한다!
만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자.
4. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다.
{{< note >}}
GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다.
{{< /note >}}
## 리뷰어
리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, 여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 팀의 멤버이다.
리뷰어는 다음의 작업을 수행할 수 있다.
- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행한다.
- 풀 리퀘스트 리뷰와 구속력 있는 피드백을 제공한다.
{{< note >}}
구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다.
{{< /note >}}
- 코드에서 사용자 화면 문자열 편집
- 코드 코멘트 개선
여러분은 SIG DOcs 리뷰어이거나, 특정 주제 영역의 문서에 대한 리뷰어일 수 있다.
### 풀 리퀘스트에 대한 리뷰어 할당
자동화 시스템은 모든 풀 리퀘스트에 대해 리뷰어를 할당한다. `/assign
[@_github_handle]` 코멘트를 남겨 특정 사람에게 리뷰를 요청할 수
있다.
지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수 있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다.
### `/lgtm` 사용하기
LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가 필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다.
리뷰어의 `/lgtm` 코멘트는 구속력 있고 자동화 시스템이 `lgtm` 레이블을 추가하도록 트리거한다.
### 리뷰어 되기
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 반드시 별도로 지원해야 한다.
지원하려면, 다음을 수행한다.
1. `kubernetes/website` 리포지터리 내
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에
여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다.
{{< note >}}
자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다.
{{< /note >}}
2. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 나열된 사용자 이름)에게 지정한다.
승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다.
## 승인자
승인자는 병합하기 위해 풀 리퀘스트를 리뷰하고 승인한다. 승인자는
[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 팀의 멤버이다.
승인자는 다음의 작업을 할 수 있다.
- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다.
- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다.
- 스타일 가이드 개선을 제안한다.
- 문서 테스트 개선을 제안한다.
- 쿠버네티스 웹사이트 또는 다른 도구 개선을 제안한다.
PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면, PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만 `/lgtm` 을 남겨야 한다.
### 풀 리퀘스트 승인
승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는 유일한 사람들이다. 이것은 특정한 책임이 따른다.
- 승인자는 PR들을 리포지터리에 병합하는 `/approve` 명령을 사용할 수 있다.
{{< warning >}}
부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.
{{< /warning >}}
- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다.
질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다.
- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="승인 전에 반드시 Netlify 테스트를 통과해야 한다" />
- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다.
- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할
것으로 기대한다. 자세한 내용은 [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를
참고한다.
## 승인자 되기
[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 충족하면 SIG Docs 승인자가 될 수 있다. 다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해 별도로 신청해야 한다.
지원하려면 다음을 수행한다.
1. `kubernetes/website` 리포지터리 내 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다.
{{< note >}}
자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-owners` 에 추가한다.
{{< /note >}}
2. PR에 한 명 이상의 현재 SIG Docs 승인자를 지정한다.
승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다.
## {{% heading "whatsnext" %}}
- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participating/pr-wranglers)에 대해 읽어보기

314
content/ko/docs/contribute/participating.md
View File

@ -1,314 +0,0 @@
---
title: SIG Docs에 참여하기
content_type: concept
weight: 60
card:
name: contribute
weight: 60
---
<!-- overview -->
SIG Docs는 쿠버네티스 프로젝트의
[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md)
중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다.
분과회에 대한 보다 자세한 정보는
[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
를 참조한다.
SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
누구나 풀 리퀘스트(PR)를 요청할 수 있고,
누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.
[멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수 있다.
이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
문서를 확인한다.
문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와
문서를 관리하는 책임을 가지는 SIG Docs에서,
이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.
<!-- body -->
## 역할과 책임
- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다.
- 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다.
- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로
문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에
의해 GitHub 리포지터리에 있는 GitHub
그룹과 `OWNER` 파일에 추가되었다.
- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준
좋은 멤버이다. 승인자는 쿠버네티스 조직을 대신해서
풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다.
또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다.
릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는
상당한 시간 투입이 필요하다.
## 모든 사람
누구나 다음 작업을 할 수 있다.
- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기.
- 풀 리퀘스트에 대한 구속력 없는 피드백 제공
- 기존 컨텐츠를 현지화하는데 도움주는 것
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다.
- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다.
{{< note >}}
만약 쿠버네티스 조직의 멤버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다.
{{< /note >}}
[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
## 멤버
멤버는 [멤버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 멤버로부터 기여를 환경하며,
기술적 정확성에 대한 다른 SIG 멤버들의 검토를 수시로 요청한다.
쿠버네티스 조직의 모든 멤버는 다음 작업을 할 수 있다.
- [모든 사람](#모든-사람) 하위에 나열된 모든 것
- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다.
- 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다.
- 코멘트에 `/assign` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다.
### 멤버 되기
최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의
[멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을
요청할 수 있다. 다음의 단계를 따른다.
1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 리뷰어 또는 승인자를
찾는다.
[쿠버네티스 Slack 인스턴스의 #sig-docs 채널](https://kubernetes.slack.com) 또는
[SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서
후원을 요청한다.
{{< note >}}
SIG Docs 멤버 개인에게 직접 email을 보내거나
Slack 다이렉트 메시지를 보내지 않는다.
{{< /note >}}
2. `kubernetes/org` 리포지터리에 멤버십을 요청하는 GitHub 이슈를 등록한다.
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
문서의 가이드라인을 따라서 양식을 채운다.
3. 해당 GitHub 이슈에 후원자를 at-mentioning(`@<GitHub-username>`을 포함한 코멘트를 추가)하거나
링크를 직접 보내주어서
후원자가 해당 GitHub 이슈를 확인하고 `+1` 표를 줄 수 있도록 한다.
4. 멤버십이 승인되면, 요청에 할당된 GitHub 관리자 팀 멤버가 승인되었음을 업데이트해주고
해당 GitHub 이슈를 종료한다.
축하한다, 이제 멤버가 되었다!
만약 멤버십 요청이 받아들여지지 않으면,
멤버십 위원회에서 재지원 전에
필요한 정보나 단계를 알려준다.
## 리뷰어
리뷰어는
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을
제공한다. 리뷰어는 다음 작업을 수행할 수 있다.
- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행
- 새 기능의 문서화
- 이슈 해결 및 분류
- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공
- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성
- 코드에서 사용자 화면 문자열 편집
- 코드 코멘트 개선
### 풀 리퀘스트에 대한 리뷰어 할당
자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 사용자는 해당 풀 리퀘스트에
`/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다.
풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로,
리뷰어는 `/lgtm` 코멘트를
해당 풀 리퀘스트에 추가할 수 있다.
할당된 리뷰어가 내용을 아직 리뷰하지 않은 경우,
다른 리뷰어가 나설 수 있다. 추가로, 기술 리뷰어를
할당해서 그들이 `/lgtm`을 주기를 기다릴 수도 있다.
사소한 변경이나 기술적 리뷰가 필요한 PR의 경우, SIG Docs [승인자](#승인자)가 `/lgtm`을 줄
수도 있다.
리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다.
### 리뷰어 되기
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
충족하면, SIG Docs 리뷰어가 될 수 있다.
다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
반드시 별도로 지원해야 한다.
지원하려면, `kubernetes/website` 저장소의
[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS)
내 `reviewers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs
승인자에게 할당한다.
풀 리퀘스트가 승인되면, 이제 SIG Docs 리뷰어가 된다.
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다.
일단 승인되면, 현재 SIG Docs 승인자가
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.
## 승인자
승인자는
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub 그룹의 멤버이다. [SIG Docs 팀과 자동화](#sig-docs-팀과-자동화) 문서를 참조한다.
승인자는 다음의 작업을 할 수 있다.
- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다.
- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다.
만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다.
- 쿠버네티스 릴리즈팀에 문서 담당자로 참여
- 스타일 가이드 개선 제안
- 문서 테스트 개선 제안
- 쿠버네티스 웹사이트 또는 다른 도구 개선 제안
PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는
해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만
`/lgtm`을 남겨야한다.
### 승인자 되기
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을
충족하면, SIG Docs 승인자가 될 수 있다.
다른 SIG의 승인자는 SIG Docs의 승인자 자격에
반드시 별도로 지원해야 한다.
지원하려면, `kubernetes/website` 저장소의
[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS)
내 `approvers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs
승인자에게 할당한다.
풀 리퀘스트가 승인되면, 이제 SIG Docs 승인자가 된다.
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다.
일단 승인되면, 현재 SIG Docs 승인자가
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.
### 승인자의 책임
승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다.
- 승인자는 PR들을 리포에 머지하는 `/approve` 명령을 사용할 수 있다.
부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.
- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다.
질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다.
- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="승인 전에 반드시 Netlify 테스트를 통과해야 한다" />
- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다.
- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할
것으로 기대한다. [일주일 간 PR Wrangler 되기](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기)
문서를 참고한다.
## SIG Docs 의장
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다.
현재 의장의 목록을 확인하려면
[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
문서를 참조한다.
## SIG Docs 팀과 자동화
SIG Docs의 자동화는 다음의 두 가지 자동화 메커니즘에 의존한다.
GitHub 그룹과 OWNERS 파일이다.
### GitHub 그룹
GitHub의 SIG Docs 그룹은 두 팀을 정의한다.
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
그룹의 전원과 의사소통하기 위해서
각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다.
이 팀은 중복되지만, 정확히 일치하지는 않으며, 이 그룹은 자동화 툴에서 사용된다.
이슈, 풀 리퀘스트를 할당하고,
PR 승인을 지원하기 위해서 자동화 시스템이 OWNERS 파일의 정보를 활용한다.
### OWNERS 파일과 전문(front-matter)
쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다.
[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는
다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을
사용한다.
- blunderbuss
- approve
이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
파일을 사용해서
해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수
있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다.
일반적인 OWNERS 파일에 대한 보다 많은 정보는
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
문서를 참고한다.
추가로, 개별 마크다운(Markdown) 파일 내 전문에
리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다.
OWNERS 파일과 마크다운 파일 내 전문의 조합은
자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
PR 소유자에게 조언하는데 활용된다.
## 병합 작업 방식
풀 리퀘스트 요청이 콘텐츠(현재 `master`)를 발행하는데 사용하는
브랜치에 병합되면 그 내용이 전 세계에 공개된다. 게시된 콘텐츠의
품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
작동 방식은 다음과 같다.
- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는
`/lgtm` 코멘트 보류).
- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
[PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과
같은 특정 역할도 수행한다.
## {{% heading "whatsnext" %}}
쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
- [문서 스타일 가이드](/ko/docs/contribute/style/)

12
content/ko/docs/contribute/style/write-new-topic.md
View File

@ -28,9 +28,17 @@ weight: 20
튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
{{< /table >}}
### 새 페이지 작성
작성하는 각각의 새 페이지에 대해 [콘텐츠 타입](/docs/contribute/style/page-content-types/)을
사용하자. 페이지 타입을 사용하면
지정된 타입의 문서 간에 일관성을 보장할 수 있다.
사용하자. 문서 사이트는 새 콘텐츠 페이지를 작성하기 위한 템플리트 또는
[Hugo archetypes](https://gohugo.io/content-management/archetypes/)을
제공한다. 새로운 타입의 페이지를 작성하려면, 작성하려는 파일의 경로로 `hugo new` 를
실행한다. 예를 들면, 다음과 같다.
```
hugo new docs/concepts/my-first-concept.md
```
## 제목과 파일 이름 선택

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

@ -129,12 +129,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
| `RuntimeClass` | `true` | 베타 | 1.14 | |
| `SCTPSupport` | `false` | 알파 | 1.12 | |
| `ServiceAppProtocol` | `false` | 알파 | 1.18 | |
| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
| `ServerSideApply` | `true` | 베타 | 1.16 | |
| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
| `ServiceAppProtocol` | `false` | 알파 | 1.18 | |
| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | |
| `ServiceTopology` | `false` | 알파 | 1.17 | |
| `StartupProbe` | `false` | 알파 | 1.16 | |
| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
| `StartupProbe` | `true` | 베타 | 1.18 | |
| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | 베타 | 1.15 | |
| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
@ -412,7 +414,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
- `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로
기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
재 매핑이 활성화된 경우에만 활성화해야 한다.
@ -472,6 +474,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다.
- `SCTPSupport`: SCTP를 `Service`, `Endpoint`, `NetworkPolicy` 및 `Pod` 정의에서 `protocol` 값으로 사용하는 것을 활성화한다.
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다.
- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다.
- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다.

7
content/ko/docs/reference/glossary/volume.md
View File

@ -6,16 +6,15 @@ full_link: /ko/docs/concepts/storage/volumes/
short_description: >
데이터를 포함하고 있는 디렉터리이며, 파드의 컨테이너에서 접근 가능하다.
aka:
aka:
tags:
- core-object
- fundamental
---
데이터를 포함하고 있는 디렉터리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다.
<!--more-->
<!--more-->
쿠버네티스 볼륨은 그것을 포함하고 있는 파드만큼 오래 산다. 결과적으로, 볼륨은 파드 안에서 실행되는 모든 컨테이너 보다 오래 지속되며, 데이터는 컨테이너의 재시작 간에도 보존된다.
더 많은 정보는 [스토리지](https://kubernetes.io/ko/docs/concepts/storage/)를 본다.
더 많은 정보는 [스토리지](/ko/docs/concepts/storage/)를 본다.

23
content/ko/docs/setup/_index.md
View File

@ -16,30 +16,17 @@ card:
<!-- overview -->
본 섹션에서는 쿠버네티스를 구축하고 실행하는 여러가지 옵션을 다룬다.
각각의 쿠버네티스 솔루션은 유지보수의 용이성, 보안, 제어, 가용 자원, 클러스터를 운영하고 관리하기 위해 필요한 전문성과 같은 제각각의 요구사항을 충족한다.
쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 넓은 범위의 클라우드 프로바이더에 걸치거나 베어 메탈 환경을 사용하는 커스텀 솔루션을 만들 수도 있다.
더 간단하게 정리하면, 쿠버네티스 클러스터를 학습 환경과 운영 환경에 만들 수 있다.
본 섹션에는 쿠버네티스를 설정하고 실행하는 다양한 방법이 나열되어 있다.
쿠버네티스를 설치할 때는 유지보수의 용이성, 보안, 제어, 사용 가능한 리소스, 그리고
클러스터를 운영하고 관리하기 위해 필요한 전문성을 기반으로 설치 유형을 선택한다.
쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 광범위한 클라우드 제공 업체 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 맞춤형 솔루션도 있다.
<!-- body -->
## 학습 환경
쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구와 같은 도커 기반의 솔루션을 사용하자.
{{< table caption="쿠버네티스를 배포하기 위해 커뮤니티와 생태계에서 지원하는 도구를 나열한 로컬 머신 솔루션 표." >}}
|커뮤니티 |생태계 |
| ------------ | -------- |
| [Minikube](/ko/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)|
| | [MicroK8s](https://microk8s.io/)|
쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용하자.
## 운영 환경

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

@ -27,7 +27,7 @@ kops는 자동화된 프로비저닝 시스템인데,
* 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다.
* [AWS 계정](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)이 있고 [IAM 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 생성하고 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) 해야 한다.
* [AWS 계정](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)이 있고 [IAM 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 생성하고 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration)해야 한다. IAM 사용자는 [적절한 권한](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user)이 필요하다.

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

@ -86,7 +86,7 @@ card:
### SIG CLI의 kubectl 디버그 소개
SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](https://kubernetes.io/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다.
SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다.
### 쿠버네티스를 위한 윈도우 CSI 지원 알파 소개

4
content/ko/docs/tasks/_index.md
View File

@ -11,9 +11,5 @@ content_type: concept
보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은
시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다.
## {{% heading "whatsnext" %}}
만약 태스크 페이지를 작성하고 싶다면,
[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다.

12
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
View File

@ -97,12 +97,12 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
예를 들면:
```conf
release=1.0
tier=frontend
environment=pod
track=stable
```
```conf
release=1.0
tier=frontend
environment=pod
track=stable
```
- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다.

97
content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md Normal file
View File

@ -0,0 +1,97 @@
---
title: 퍼시스턴트볼륨 반환 정책 변경하기
content_type: task
---
<!-- overview -->
이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
변경하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가?
`PersistentVolumes` 은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한
다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 `PersistentVolumes` 의 경우
기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면,
동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다.
볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다.
이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다.
"Retain" 정책에서, 사용자가 `PersistentVolumeClaim` 을 삭제할 경우 해당하는
`PersistentVolume` 은 삭제되지 않는다.
대신, `Released` 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다.
## 퍼시스턴트볼륨 반환 정책 변경하기
1. 사용자의 클러스터에서 퍼시스턴트볼륨을 조회한다.
```shell
kubectl get pv
```
결과는 아래와 같다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다.
1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다.
```shell
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
```
`<your-pv-name>` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다.
{{< note >}}
윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.(bash에 대해 위에서 표시된 홑 따옴표가 아니다.) 따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다.
```cmd
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
```
{{< /note >}}
1. 선택한 PersistentVolume이 올바른 정책을 갖는지 확인한다.
```shell
kubectl get pv
```
결과는 아래와 같다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
볼륨은 자동으로 삭제 되지 않는다.
## {{% heading "whatsnext" %}}
* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 배워 보기.
* [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)에 대해 더 배워 보기.
### Reference
* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기.

145
content/ko/docs/tasks/administer-cluster/declare-network-policy.md Normal file
View File

@ -0,0 +1,145 @@
---
title: 네트워크 폴리시(Network Policy) 선언하기
min-kubernetes-server-version: v1.8
content_type: task
---
<!-- overview -->
이 문서는 사용자가 쿠버네티스 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 제공하는 많은 네트워크 제공자들이 있다.
* [캘리코(Calico)](/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
* [실리움(Cilium)](/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
* [Kube-router](/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
* [로마나(Romana)](/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [위브넷(Weave Net)](/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
{{< note >}}
위 목록은 추천순이나 선호도순이 아닌, 제품 이름의 알파벳 순으로 정렬되어 있다. 이 예제는 이러한 제공자 중 하나를 사용하는 쿠버네티스 클러스터에 유효하다.
{{< /note >}}
<!-- steps -->
## `nginx` 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기
쿠버네티스 네트워크 폴리시가 어떻게 동작하는지 확인하기 위해서, `nginx` 디플로이먼트를 생성한다.
```console
kubectl create deployment nginx --image=nginx
```
```none
deployment.apps/nginx created
```
`nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다.
```console
kubectl expose deployment nginx --port=80
```
```none
service/nginx exposed
```
위 명령어들은 nginx 파드에 대한 디플로이먼트를 생성하고, `nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다. `nginx` 파드와 디플로이먼트는 `default` 네임스페이스(namespace)에 존재한다.
```console
kubectl get svc,pod
```
```none
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes 10.100.0.1 <none> 443/TCP 46m
service/nginx 10.100.0.16 <none> 80/TCP 33s
NAME READY STATUS RESTARTS AGE
pod/nginx-701339712-e0qfq 1/1 Running 0 35s
```
## 다른 파드에서 접근하여 서비스 테스트하기
사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.
```console
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
```
사용자 쉘에서, 다음의 명령을 실행한다.
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
remote file exists
```
## `nginx` 서비스에 대해 접근 제한하기
`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다.
{{< codenew file="service/networking/nginx-policy.yaml" >}}
네트워크폴리시 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
{{< note >}}
네트워크폴리시는 정책이 적용되는 파드의 그룹을 선택하는 `podSelector` 를 포함한다. 사용자는 이 정책이 `app=nginx` 레이블을 갖는 파드를 선택하는 것을 볼 수 있다. 레이블은 `nginx` 디플로이먼트에 있는 파드에 자동으로 추가된다. 빈 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
{{< /note >}}
## 서비스에 정책 할당하기
kubectl을 사용하여 위 `nginx-policy.yaml` 파일로부터 네트워크폴리시를 생성한다.
```console
kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml
```
```none
networkpolicy.networking.k8s.io/access-nginx created
```
## access 레이블이 정의되지 않은 서비스에 접근 테스트
올바른 레이블이 없는 파드에서 `nginx` 서비스에 접근하려 할 경우, 요청 타임 아웃이 발생한다.
```console
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
```
사용자 쉘에서, 다음의 명령을 실행한다.
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
wget: download timed out
```
## 접근 레이블을 정의하고 다시 테스트
사용자는 요청이 허용되도록 하기 위하여 올바른 레이블을 갖는 파드를 생성한다.
```console
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
```
사용자 쉘에서, 다음의 명령을 실행한다.
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
remote file exists
```

261
content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md Normal file
View File

@ -0,0 +1,261 @@
---
title: DNS 서비스 사용자 정의하기
content_type: task
min-kubernetes-server-version: v1.12
---
<!-- overview -->
이 페이지는 클러스터 안에서 사용자의
DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고
DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기)
는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다.
{{% version-check %}}
<!-- steps -->
## 소개
DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
사용하여 자동으로 시작되는 쿠버네티스
내장 서비스이다.
쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
{{< note >}}
CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
{{< /note >}}
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를
통하여 로컬 도메인을 설정할 수 있다.
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다.
더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우,
파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다.
파드의 DNS 변환도 노드와 동일하게 작동해야 한다.
그 외에는 [알려진 이슈](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참고한다.
만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우,
사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다.
파드가 DNS를 상속받지 못하도록 하기 위해 이 플래그를 ""로 설정한다.
DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유효한 파일 경로를 설정한다.
## CoreDNS
CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
### CoreDNS 컨피그맵(ConfigMap) 옵션
CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다.
클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
해당 클러스터에 대한 DNS 서비스 검색 동작을
변경할 수 있다.
쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
```
Corefile의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins)을 포함한다.
* [errors](https://coredns.io/plugins/errors/): 오류가 표준 출력(stdout)에 기록된다.
* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
`pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다.
* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다.
* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
* [cache](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다.
* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다.
* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다.
* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다.
사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다.
### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(nameserver)의 설정
CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 스텁 도메인 및 업스트림 네임서버를 구성할 수 있다.
#### 예시
만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다.
```
consul.local:53 {
errors
cache 30
forward . 10.150.0.1
}
```
모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다.
```
forward . 172.16.0.1
```
기본 `Corefile` 구성에 따른 최종 컨피그맵은 다음과 같다.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . 172.16.0.1
cache 30
loop
reload
loadbalance
}
consul.local:53 {
errors
cache 30
forward . 10.150.0.1
}
```
`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
자동 변환을 지원한다.
{{< note >}}
kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다.
변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다.
{{< /note >}}
## kube-dns에 대응되는 CoreDNS 설정
CoreDNS는 kube-dns 이상의 기능을 지원한다.
`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다.
마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다.
### 예시
kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다.
```yaml
apiVersion: v1
data:
federations: |
{"foo" : "foo.feddomain.com"}
stubDomains: |
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
upstreamNameservers: |
["8.8.8.8", "8.8.4.4"]
kind: ConfigMap
```
CoreDNS에서는 동등한 설정으로 Corefile을 생성한다.
* federations 에 대응하는 설정:
```
federation cluster.local {
foo foo.feddomain.com
}
```
* stubDomains 에 대응하는 설정:
```yaml
abc.com:53 {
errors
cache 30
forward . 1.2.3.4
}
my.cluster.local:53 {
errors
cache 30
forward . 2.3.4.5
}
```
기본 플러그인으로 구성된 완전한 Corefile.
```
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
federation cluster.local {
foo foo.feddomain.com
}
prometheus :9153
forward . 8.8.8.8 8.8.4.4
cache 30
}
abc.com:53 {
errors
cache 30
forward . 1.2.3.4
}
my.cluster.local:53 {
errors
cache 30
forward . 2.3.4.5
}
```
## CoreDNS로의 이관
kube-dns에서 CoreDNS로 이관하기 위하여,
kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는
[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다.
또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를
사용하여 이관할 수도 있다.
## {{% heading "whatsnext" %}}
- [DNS 변환 디버깅하기](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) 읽기

125
content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md Normal file
View File

@ -0,0 +1,125 @@
---
title: 초기화 컨테이너(Init Containers) 디버그하기
content_type: task
---
<!-- overview -->
이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로,
초기화 컨테이너를 `<init-container-1>` 과
`<init-container-2>` 로 표시한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의
기본 사항에 익숙해야 한다.
* 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다.
<!-- steps -->
## 초기화 컨테이너의 상태 체크하기
사용자 파드의 상태를 표시한다.
```shell
kubectl get pod <pod-name>
```
예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중
하나가 성공적으로 완료되었음을 나타낸다.
```
NAME READY STATUS RESTARTS AGE
<pod-name> 0/1 Init:1/2 0 7s
```
상태값과 그 의미에 대한 추가 예제는
[파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다.
## 초기화 컨테이너에 대한 상세 정보 조회하기
초기화 컨테이너의 실행에 대한 상세 정보를 확인한다.
```shell
kubectl describe pod <pod-name>
```
예를 들어, 2개의 초기화 컨테이너가 있는 파드는 다음과 같이 표시될 수 있다.
```
Init Containers:
<init-container-1>:
Container ID: ...
...
State: Terminated
Reason: Completed
Exit Code: 0
Started: ...
Finished: ...
Ready: True
Restart Count: 0
...
<init-container-2>:
Container ID: ...
...
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: ...
Finished: ...
Ready: False
Restart Count: 3
...
```
파드 스펙의 `status.initContainerStatuses` 필드를 읽어서
프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다.
```shell
kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
```
이 명령은 원시 JSON 방식으로 위와 동일한 정보를 반환한다.
## 초기화 컨테이너의 로그 조회하기
초기화 컨테이너의 로그를 확인하기 위해
파드의 이름과 초기화 컨테이너의 이름을 같이 전달한다.
```shell
kubectl logs <pod-name> -c <init-container-2>
```
셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가
실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에
`set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다.
<!-- discussion -->
## 파드의 상태 이해하기
`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의
실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는
동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다.
상태 | 의미
------ | -------
`Init:N/M` | 파드가 `M` 개의 초기화 컨테이너를 갖고 있으며, 현재까지 `N` 개가 완료.
`Init:Error` | 초기화 컨테이너 실행 실패.
`Init:CrashLoopBackOff` | 초기화 컨테이너가 반복적으로 실행 실패.
`Pending` | 파드가 아직 초기화 컨테이너를 실행하지 않음.
`PodInitializing` or `Running` | 파드가 이미 초기화 컨테이너 실행을 완료.

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

@ -1,6 +1,7 @@
---
title: 튜토리얼
main_menu: true
no_list: true
weight: 60
content_type: concept
---
@ -14,8 +15,6 @@ content_type: concept
각 튜토리얼을 따라하기 전에, 나중에 참조할 수 있도록
[표준 용어집](/ko/docs/reference/glossary/) 페이지를 북마크하기를 권한다.
<!-- body -->
## 기초
@ -64,13 +63,8 @@ content_type: concept
* [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/)
## {{% heading "whatsnext" %}}
튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는
[콘텐츠 페이지 유형](/docs/contribute/style/page-content-types/)
페이지를 참조한다.

8
content/ko/docs/tutorials/services/source-ip.md
View File

@ -226,7 +226,7 @@ client_address=10.240.0.3
다른 노드로 트래픽 전달하지 않는다. 이 방법은 원본
소스 IP 주소를 보존한다. 만약 로컬 엔드 포인트가 없다면,
그 노드로 보내진 패킷은 버려지므로
패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로,
패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로,
패킷을 엔드포인트까지 전달할 수 있다.
다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자.
@ -249,7 +249,7 @@ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i cli
client_address=104.132.1.79
```
엔드포인트 파드가 실행 중인 노드에서 *올바른* 클라이언트 IP 주소인
엔드포인트 파드가 실행 중인 노드에서 *올바른* 클라이언트 IP 주소인
딱 한 종류의 응답만 수신한다.
어떻게 이렇게 되었는가:
@ -319,7 +319,7 @@ client_address=10.240.0.5
그러나 구글 클라우드 엔진/GCE 에서 실행 중이라면 동일한 `service.spec.externalTrafficPolicy` 필드를 `Local`로 설정하면
서비스 엔드포인트가 *없는* 노드는 고의로 헬스 체크에 실패하여
강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서
강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서
자신을 스스로 제거한다.
시각적으로:
@ -448,5 +448,3 @@ kubectl delete deployment source-ip-app
* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 더 자세히 본다.
* 어떻게 [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다.

2
content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
View File

@ -84,7 +84,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
{{< note >}}
`type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer를 참조한다.
`type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer)를 참조한다.
{{< /note >}}

13
content/ko/examples/service/networking/nginx-policy.yaml Normal file
View File

@ -0,0 +1,13 @@
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: access-nginx
spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
access: "true"