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

Merge pull request #21662 from kubernetes/dev-1.18-ko.5-fix-conflict 

Fifth Korean l10n work for release 1.18
pull/21676/head
Kubernetes Prow Robot 2020-06-11 16:19:55 -07:00 committed by GitHub
parent b635757bc0 6c1edf3c1f
commit a78456d87c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
42 changed files with 1983 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -400,9 +400,9 @@ IBM 클라우드 쿠버네티스 서비스 제공자를 사용하면, 단일 영
쿠버네티스 노드 오브젝트의 이름은 IBM 클라우드 쿠버네티스 서비스 워커 노드 인스턴스의 프라이빗 IP 주소이다.
### 네트워킹
IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [인-클러스터(in-cluster) 및 프라이빗 네트워킹 계획](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)을 참고한다.
IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [클러스터 네트워킹 구성](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)을 참고한다.
퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [외부 네트워킹으로 앱 노출 계획](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다.
퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [앱을 노출할 서비스 선택하기](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다.
### 스토리지
IBM 클라우드 쿠버네티스 서비스 제공자는 쿠버네티스-네이티브 퍼시스턴트 볼륨을 활용하여 사용자가 파일, 블록 및 클라우드 오브젝트 스토리지를 앱에 마운트할 수 있도록 한다. 데이터를 지속적으로 저장하기 위해 서비스로서의-데이터베이스(database-as-a-service)와 써드파티 애드온을 사용할 수도 있다. 자세한 정보는 [고가용성 퍼시스턴트 스토리지 계획](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)을 참고한다.

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

@ -154,7 +154,7 @@ deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created
```
`kubectl` 에 대해 더 자세히 알고 싶다면, [kubectl 개요](/docs/reference/kubectl/overview/)를 참조한다.
`kubectl` 에 대해 더 자세히 알고 싶다면, [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참조한다.
## 효과적인 레이블 사용

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

@ -57,8 +57,7 @@ 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`으로 가지는)를 사용한다.
## 레이블 사용하기
@ -76,7 +75,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다.
- `imagePullPolicy: Always`: 파드가 시작될 때마다 이미지가 풀(Pull) 된다.
- `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다.

2
content/ko/docs/concepts/containers/images.md
View File

@ -148,7 +148,7 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
### IBM 클라우드 컨테이너 레지스트리 사용
IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, IAM 역할과 정책으로 IBM 클라우드 컨테이너 레지스트리 네임스페이스의 접근 권한을 부여해서 사용할 수 있다.
IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=registry-getting-started)를 참고한다.
IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started)를 참고한다.
다른 추가적인 구성이 없는 IBM 클라우드 쿠버네티스 서비스 클러스터의 IBM 클라우드 컨테이너 레지스트리 내 기본 네임스페이스에 저장되어 있는 배포된 이미지를 동일 계정과 동일 지역에서 사용하려면 [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 본다. 다른 구성 옵션에 대한 것은 [레지스트리부터 클러스터에 이미지를 가져오도록 권한을 부여하는 방법 이해하기](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth)를 본다.

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

@ -79,11 +79,13 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인
#### 트래픽 셰이핑 지원
**실험적인 기능입니다**
CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도 지원한다. CNI 플러그인 팀에서 제공하는 공식 [대역폭(bandwidth)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다.
트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을
추가해야 한다.
추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어있는지 확인한다.
```json
{

2
content/ko/docs/concepts/overview/kubernetes-api.md
View File

@ -15,7 +15,7 @@ API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/referen
API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다.
쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다.
쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다.

10
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -47,11 +47,11 @@ weight: 30
kubectl get namespace
```
```
NAME STATUS AGE
default Active 1d
kube-system Active 1d
kube-public Active 1d
kube-node-lease Active 1d
NAME STATUS AGE
default Active 1d
kube-node-lease Active 1d
kube-public Active 1d
kube-system Active 1d
```
쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다.

6
content/ko/docs/concepts/policy/pod-security-policy.md
View File

@ -371,6 +371,8 @@ podsecuritypolicy "example" deleted
{{< codenew file="policy/restricted-psp.yaml" >}}
더 많은 예제는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/#policy-instantiation)을 본다.
## 정책 레퍼런스
### 특권을 가진
@ -631,6 +633,8 @@ spec:
## {{% heading "whatsnext" %}}
API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조
폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.

15
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
View File

@ -72,21 +72,10 @@ tolerations:
두 가지 특별한 경우가 있다.
* operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로
operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로
모든 것이 톨러레이션 된다.
```yaml
tolerations:
- operator: "Exists"
```
* 비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다.
```yaml
tolerations:
- key: "key"
operator: "Exists"
```
비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다.
{{< /note >}}

2
content/ko/docs/concepts/services-networking/connect-applications-service.md
View File

@ -15,7 +15,7 @@ weight: 30
컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다. 동일한 원칙이 보다 완전한 [Jenkins CI 애플리케이션](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)에서 구현된다.
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다.

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

@ -118,7 +118,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본
스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
스케줄러를 사용해서 대상 호스트에 파드를 바인딩 한다. 만약 데몬셋 파드에
이미 노드 선호도가 존재한다면 교체한다. 데몬셋 컨트롤러는
이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
데몬셋의 `spec.template` 은 변경되지 않는다.

2
content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md
View File

@ -469,7 +469,7 @@ spec:
스파크 드라이버를 실행한 다음, 정리한다.
이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
파드 생성과 작업 할당 방법을 완전히 제어할 수 있다는 점이다.
파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다.
## 크론 잡 {#cron-jobs}

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

@ -320,7 +320,7 @@ myapp-pod 1/1 Running 0 9m
## {{% heading "whatsnext" %}}
* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기

11
content/ko/docs/contribute/generate-ref-docs/_index.md Normal file
View File

@ -0,0 +1,11 @@
---
title: 참조 문서 개요
main_menu: true
weight: 80
---
이 섹션은 쿠버네티스 참조 가이드를 생성하는 방법에 대해 설명한다.
참조 문서화 시스템을 빌드하려면, 다음의 가이드를 참고한다.
* [참조 문서 생성에 대한 퀵스타트 가이드](/docs/contribute/generate-ref-docs/quickstart/)

3
content/ko/docs/contribute/new-content/overview.md
View File

@ -54,5 +54,8 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동
PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다.
## 기여자를 위한 도구들
`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다.

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

@ -13,7 +13,7 @@ menu:
title: "문서"
weight: 20
post: >
<p>개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, <a href="/editdocs/" data-auto-burger-exclude>문서에 기여하는 것도 도움을 줄 수 있다</a>!</p>
<p>개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, <a href="/editdocs/" data-auto-burger-exclude data-proofer-ignore>문서에 기여하는 것도 도움을 줄 수 있다</a>!</p>
description: >
쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈소스 컨테이너 오케스트레이션 엔진이다. 오픈소스 프로젝트는 Cloud Native Computing Foundation에서 주관한다.
overview: >

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

@ -8,7 +8,7 @@ content_type: concept
<!-- overview -->
쿠버네티스 문서의 본 섹션에서는 레퍼런스를 다룬다.
쿠버네티스 문서의 본 섹션에서는 레퍼런스를 다룬다.
@ -21,8 +21,8 @@ content_type: concept
## API 클라이언트 라이브러리
프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서,
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서,
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
공식적으로 지원되는 클라이언트 라이브러리는 다음과 같다.
- [쿠버네티스 Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)
@ -32,7 +32,7 @@ content_type: concept
## CLI 레퍼런스
* [kubectl](/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
* [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.

5
content/ko/docs/reference/kubectl/_index.md Executable file
View File

@ -0,0 +1,5 @@
---
title: "kubectl CLI"
weight: 60
---

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

@ -8,7 +8,7 @@ card:
<!-- overview -->
참고 항목: [Kubectl 개요](/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath).
참고 항목: [Kubectl 개요](/ko/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath).
이 페이지는 `kubectl` 커맨드의 개요이다.
@ -203,7 +203,7 @@ kubectl diff -f ./my-manifest.yaml
```bash
kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크
kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크
kubectl rollout undo deployment/frontend # 이전 디플로이먼트로 롤백
kubectl rollout undo deployment/frontend --to-revision=2 # 특정 리비전으로 롤백
kubectl rollout status -w deployment/frontend # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시
@ -355,7 +355,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
```
More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns).
더 많은 예제는 kubectl [참조 문서](/ko/docs/reference/kubectl/overview/#custom-columns)를 참고한다.
### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅
@ -378,7 +378,7 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
## {{% heading "whatsnext" %}}
* [kubectl 개요](/docs/reference/kubectl/overview/)에 대해 더 배워보자.
* [kubectl 개요](/ko/docs/reference/kubectl/overview/)에 대해 더 배워보자.
* [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다.

495
content/ko/docs/reference/kubectl/overview.md Normal file
View File

@ -0,0 +1,495 @@
---
title: kubectl 개요
content_template: templates/concept
weight: 20
card:
name: reference
weight: 20
---
{{% capture overview %}}
Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다.
이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다.
{{% /capture %}}
{{% capture body %}}
## 구문
터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다.
```shell
kubectl [command] [TYPE] [NAME] [flags]
```
다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다.
* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. 예: `create`, `get`, `describe`, `delete`
* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
```shell
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
```
* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods`
여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
* 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.
* 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`<br/>
예: `kubectl get pod example-pod1 example-pod2`
* 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>
예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
* 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`
* YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
예: `kubectl get pod -f ./pod.yaml`
* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>
{{< caution >}}
커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다.
{{< /caution >}}
도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다.
## 명령어
다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
명령어 | 구문 | 설명
-------------------- | -------------------- | --------------------
`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다.
`annotate` | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다.
`api-resources` | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다.
`api-versions` | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다.
`apply` | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다.
`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다.
`auth` | `kubectl auth [flags] [options]` | 승인을 검사한다.
`autoscale` | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다.
`certificate` | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다.
`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다.
`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
`delete` | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다.
`describe` | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 하나 이상의 리소스의 자세한 상태를 표시한다.
`diff` | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다.
`drain` | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다.
`edit` | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다.
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다.
`explain` | `kubectl explain [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
`expose` | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다.
`get` | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 하나 이상의 리소스를 나열한다.
`kustomize` | `kubectl kustomize <dir> [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다.
`label` | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다.
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다.
`options` | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다.
`patch` | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다.
`plugin` | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다.
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다.
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다.
`replace` | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다.
`rollout` | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다.
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 클러스터에서 지정된 이미지를 실행한다.
`scale` | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다.
`set` | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다.
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다.
`top` | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다.
`uncordon` | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다.
`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
`wait` | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다.
기억하기: 명령 동작에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다.
## 리소스 타입
다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치한다.)
| 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 |
|---|---|---|---|---|
| `bindings` | | | true | Binding|
| `componentstatuses` | `cs` | | false | ComponentStatus |
| `configmaps` | `cm` | | true | ConfigMap |
| `endpoints` | `ep` | | true | Endpoints |
| `limitranges` | `limits` | | true | LimitRange |
| `namespaces` | `ns` | | false | Namespace |
| `nodes` | `no` | | false | Node |
| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
| `persistentvolumes` | `pv` | | false | PersistentVolume |
| `pods` | `po` | | true | Pod |
| `podtemplates` | | | true | PodTemplate |
| `replicationcontrollers` | `rc` | | true| ReplicationController |
| `resourcequotas` | `quota` | | true | ResourceQuota |
| `secrets` | | | true | Secret |
| `serviceaccounts` | `sa` | | true | ServiceAccount |
| `services` | `svc` | | true | Service |
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
| `apiservices` | | apiregistration.k8s.io | false | APIService |
| `controllerrevisions` | | apps | true | ControllerRevision |
| `daemonsets` | `ds` | apps | true | DaemonSet |
| `deployments` | `deploy` | apps | true | Deployment |
| `replicasets` | `rs` | apps | true | ReplicaSet |
| `statefulsets` | `sts` | apps | true | StatefulSet |
| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
| `cronjobs` | `cj` | batch | true | CronJob |
| `jobs` | | batch | true | Job |
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
| `leases` | | coordination.k8s.io | true | Lease |
| `events` | `ev` | events.k8s.io | true | Event |
| `ingresses` | `ing` | extensions | true | Ingress |
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
| `roles` | | rbac.authorization.k8s.io | true | Role |
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
| `csinodes` | | storage.k8s.io | false | CSINode |
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
## 출력 옵션
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다.
### 출력 서식화
모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다.
#### 구문
```shell
kubectl [command] [TYPE] [NAME] -o <output_format>
```
`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다.
출력 형식 | 설명
--------------| -----------
`-o custom-columns=<spec>` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다.
`-o custom-columns-file=<filename>` | `<filename>` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다.
`-o json` | JSON 형식의 API 오브젝트를 출력한다.
`-o jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
`-o name` | 리소스 이름만 출력한다.
`-o wide` | 추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다.
`-o yaml` | YAML 형식의 API 오브젝트를 출력한다.
##### 예제
이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.
```shell
kubectl get pod web-pod-13je7 -o yaml
```
기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다.
#### 사용자 정의 열 {#custom-columns}
사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다. 사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
##### 예제
인라인:
```shell
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
```
템플릿 파일:
```shell
kubectl get pods <pod-name> -o custom-columns-file=template.txt
```
`template.txt` 파일에 포함된 내용은 다음과 같다.
```
NAME RSRC
metadata.name metadata.resourceVersion
```
두 명령 중 하나를 실행한 결과는 다음과 같다.
```shell
NAME RSRC
submit-queue 610995
```
#### 서버측 열
`kubectl` 는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다.
이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다.
이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.
이 기능은 기본적으로 `kubectl` 1.11 이상에서 활성화되어 있다. 사용하지 않으려면,
`kubectl get` 명령에 `--server-print=false` 플래그를 추가한다.
##### 예제
파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.
```shell
kubectl get pods <pod-name> --server-print=false
```
출력 결과는 다음과 같다.
```shell
NAME AGE
pod-name 1m
```
### 오브젝트 목록 정렬
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
#### 구문
```shell
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
```
##### 예제
이름별로 정렬된 파드 목록을 출력하려면, 다음을 실행한다.
```shell
kubectl get pods --sort-by=.metadata.name
```
## 예제: 일반적인 작업
다음 예제 세트를 사용하여 일반적으로 사용되는 `kubectl` 조작 실행에 익숙해진다.
`kubectl apply` - 파일 또는 표준입력에서 리소스를 적용하거나 업데이트한다.
```shell
# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
kubectl apply -f example-service.yaml
# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
kubectl apply -f example-controller.yaml
# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
kubectl apply -f <directory>
```
`kubectl get` - 하나 이상의 리소스를 나열한다.
```shell
# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
kubectl get pods
# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
kubectl get pods -o wide
# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
kubectl get replicationcontroller <rc-name>
# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
kubectl get rc,services
# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
kubectl get ds
# 노드 server01에서 실행 중인 모든 파드를 나열한다.
kubectl get pods --field-selector=spec.nodeName=server01
```
`kubectl describe` - 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.
```shell
# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
kubectl describe nodes <node-name>
# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
kubectl describe pods/<pod-name>
# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.
# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
kubectl describe pods <rc-name>
# 모든 파드의 정보를 출력한다.
kubectl describe pods
```
{{< note >}}
`kubectl get` 명령은 일반적으로 동일한 리소스 타입의 하나 이상의
리소스를 검색하는 데 사용된다. 예를 들어, `-o` 또는 `--output` 플래그를
사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다.
`-w` 또는 `--watch` 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수
있다. `kubectl describe` 명령은 지정된 리소스의 여러 관련 측면을
설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여
사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, `kubectl describe node`
명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의
정보도 검색한다.
{{< /note >}}
`kubectl delete` - 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.
```shell
# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
kubectl delete -f pod.yaml
# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
kubectl delete pods,services -l <label-key>=<label-value>
# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
kubectl delete pods --all
```
`kubectl exec` - 파드의 컨테이너에 대해 명령을 실행한다.
```shell
# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec <pod-name> -- date
# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
kubectl exec <pod-name> -c <container-name> -- date
# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec -ti <pod-name> -- /bin/bash
```
`kubectl logs` - 파드의 컨테이너에 대한 로그를 출력한다.
```shell
# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
kubectl logs <pod-name>
# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
kubectl logs -f <pod-name>
```
`kubectl diff` - 제안된 클러스터 업데이트의 차이점을 본다.
```shell
# "pod.json"에 포함된 리소스의 차이점을 출력한다.
kubectl diff -f pod.json
# 표준입력에서 파일을 읽어 차이점을 출력한다.
cat service.yaml | kubectl diff -f -
```
## 예제: 플러그인 작성 및 사용
`kubectl` 플러그인 작성과 사용에 익숙해지려면 다음의 예제 세트를 사용한다.
```shell
# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로
# 시작하도록 실행 파일의 이름을 지정한다.
cat ./kubectl-hello
#!/bin/bash
# 이 플러그인은 "hello world"라는 단어를 출력한다
echo "hello world"
# 작성한 플러그인을 실행 가능하게 한다
sudo chmod +x ./kubectl-hello
# 그리고 PATH의 위치로 옮긴다
sudo mv ./kubectl-hello /usr/local/bin
# 이제 kubectl 플러그인을 만들고 "설치했다".
# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
kubectl hello
```
```
hello world
```
```shell
# PATH에서 플러그인 파일을 간단히 삭제하여, 플러그인을 "제거"할 수 있다
sudo rm /usr/local/bin/kubectl-hello
```
`kubectl` 에 사용할 수 있는 모든 플러그인을 보려면,
`kubectl plugin list` 하위 명령을 사용할 수 있다.
```shell
kubectl plugin list
```
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
```
```shell
# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나,
# 다른 플러그인에 의해 가려진 플러그인에 대해
# 경고할 수 있다
sudo chmod -x /usr/local/bin/kubectl-foo
kubectl plugin list
```
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
```
플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을
구축하는 수단으로 생각할 수 있다.
```shell
cat ./kubectl-whoami
#!/bin/bash
# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한
# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
```
위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재 선택된 컨텍스트에 대한
사용자가 포함된 출력이 제공된다.
```shell
# 파일을 실행 가능하게 한다
sudo chmod +x ./kubectl-whoami
# 그리고 PATH로 옮긴다
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
```
플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다.
{{% /capture %}}
{{% capture whatsnext %}}
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다.
{{% /capture %}}

2
content/ko/docs/reference/using-api/api-overview.md
View File

@ -18,7 +18,7 @@ API 오브젝트로 취급되고,
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
대부분의 작업은 API에 의존하고 있는
[kubectl](/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는
[kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 같은 다른 커맨드라인 툴을 통해 수행할 수 있다.
그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.

5
content/ko/docs/setup/production-environment/tools/kubeadm/ha-topology.md
View File

@ -16,6 +16,11 @@ weight: 50
HA 클러스터를 구성하기 전에 각 토플로지의 장단점을 주의 깊게 고려해야 한다.
{{< note >}}
kubeadm은 etcd 클러스터를 정적으로 부트스트랩한다. 자세한 내용은 etcd [클러스터 구성 가이드](https://github.com/etcd-io/etcd/blob/release-3.4/Documentation/op-guide/clustering.md#static)
를 읽는다.
{{< /note >}}
<!-- body -->

6
content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
View File

@ -20,7 +20,7 @@ weight: 75
## 시작하기 전에
* [윈도우 서버에서 운영하는 마스터와 워커 노드](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다.
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다.
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다.
## 시작하기: 윈도우 컨테이너 배포하기
@ -114,7 +114,7 @@ LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리
## 설정 가능한 컨테이너 username 사용하기
쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다.
쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다.
## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기
@ -170,7 +170,7 @@ tolerations:
### RuntimeClass로 단순화
[RuntimeClass] 를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. 클러스터 관리자는
[RuntimeClass] 를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. 클러스터 관리자는
이 테인트와 톨러레이션을 캡슐화하는데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다.

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

@ -115,7 +115,7 @@ track=stable
- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/user-guide/containers/#containers-and-commands)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.

91
content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md Normal file
View File

@ -0,0 +1,91 @@
---
title: 초기화 컨테이너에 대한 구성
content_template: templates/task
weight: 130
---
{{% capture overview %}}
이 페이지는 애플리케이션 실행 전에 파드를 초기화하기 위해 어떻게 초기화 컨테이너를
구성해야 하는지 보여준다.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 초기화 컨테이너를 갖는 파드 생성
이 연습에서 하나의 애플리케이션 컨테이너와 하나의 초기화 컨테이너를 갖는
파드를 생성한다. 초기화 컨테이너는 애플리케이션 시작
전에 실행을 종료한다.
아래는 해당 파드의 구성 파일이다.
{{< codenew file="pods/init-containers.yaml" >}}
이 구성 파일에서, 파드가 가진 볼륨을 초기화
컨테이너와 애플리케이션 컨테이너가 공유하는 것을 볼 수 있다.
초기화 컨테이너는 공유된 볼륨을
`/work-dir` 에 마운트하고, 애플리케이션 컨테이너는 공유된 볼륨을
`/usr/share/nginx/html` 에 마운트한다. 초기화 컨테이너는 다음 명령을 실행 후
종료한다.
wget -O /work-dir/index.html http://kubernetes.io
초기화 컨테이너는 nginx 서버의 루트 디렉터리 내 `index.html` 파일을
저장한다.
파드를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml
nginx 컨테이너가 실행 중인지 확인한다.
kubectl get pod init-demo
출력 결과는 nginx 컨테이너가 실행 중임을 보여준다.
NAME READY STATUS RESTARTS AGE
init-demo 1/1 Running 0 1m
init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
kubectl exec -it init-demo -- /bin/bash
셸에서 GET 요청을 nginx 서버로 전송한다.
root@nginx:~# apt-get update
root@nginx:~# apt-get install curl
root@nginx:~# curl localhost
출력 결과는 nginx가 초기화 컨테이너에 의해 저장된 웹 페이지를 제공하고 있음을 보여준다.
<!Doctype html>
<html id="home">
<head>
...
"url": "http://kubernetes.io/"}</script>
</head>
<body>
...
<p>Kubernetes is open source giving you the freedom to take advantage ...</p>
...
{{% /capture %}}
{{% capture whatsnext %}}
* [같은 파드 내 실행 중인 컨테이너들간 통신](/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)에
대해 배우기.
* [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)에 대해 배우기.
* [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기.
* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기.
{{% /capture %}}

117
content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md Normal file
View File

@ -0,0 +1,117 @@
---
title: 파드 실패의 원인 검증하기
content_template: templates/task
---
{{% capture overview %}}
이 페이지는 컨테이너 종료 메시지를 읽고 쓰는
방법을 보여준다.
종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를,
대시보드나 모니터링 소프트웨어 도구와 같이
쉽게 조회 및 표시할 수 있는 위치에
기록하는 방법을 제공한다.
대부분의 경우에 종료 메시지에 넣는 정보는
일반
[쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 종료 메시지 읽기 및 쓰기
이 예제에서는, 하나의 컨테이너를 실행하는 파드를 생성한다.
하단의 설정 파일은 컨테이너가 시작될 때 수행하는
명령어를 지정한다.
{{< codenew file="debug/termination.yaml" >}}
1. 다음의 YAML 설정 파일에 기반한 파드를 생성한다.
kubectl apply -f https://k8s.io/examples/debug/termination.yaml
YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에
"Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는
것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를
기록한 후에 종료된다.
1. 파드와 관련된 정보를 출력한다.
kubectl get pod termination-demo
파드가 더 이상 실행되지 않을 때까지 앞선 명령어를 반복한다.
1. 파드에 관한 상세 정보를 출력한다.
kubectl get pod termination-demo --output=yaml
결과는 "Sleep expired" 메시지를 포함한다.
apiVersion: v1
kind: Pod
...
lastState:
terminated:
containerID: ...
exitCode: 0
finishedAt: ...
message: |
Sleep expired
...
1. 종료 메시지만을 포함하는 출력 결과를 보기
위해서는 Go 템플릿을 사용한다.
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
## 종료 메시지 사용자 정의하기
쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된
종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은
`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써
쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다.
쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다.
다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
`/tmp/my-log` 파일에 종료 메시지를 기록한다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: msg-path-demo
spec:
containers:
- name: msg-path-demo-container
image: debian
terminationMessagePath: "/tmp/my-log"
```
또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy`
필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며,
이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다.
`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로
설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우
쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다.
로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다.
{{% /capture %}}
{{% capture whatsnext %}}
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
에 있는 `terminationMessagePath` 에 대해 읽어보기.
* [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기.
* [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기.
{{% /capture %}}

386
content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md Normal file
View File

@ -0,0 +1,386 @@
---
title: 플러그인으로 kubectl 확장
description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다.
content_template: templates/task
---
{{% capture overview %}}
이 가이드는 [kubectl](/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는
플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 `kubectl` 을 확장하고, 주요 배포판에 포함되지 않은 `kubectl` 의 새로운 사용자 정의 기능을 허용한다.
{{% /capture %}}
{{% capture prerequisites %}}
동작하는 `kubectl` 바이너리가 설치되어 있어야 한다.
{{% /capture %}}
{{% capture steps %}}
## kubectl 플러그인 설치
플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 간단히 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.
[Krew](https://krew.dev/)를 사용하여 오픈소스에서 사용 가능한
kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는
플러그인 관리자이다.
{{< caution >}}
Krew [플러그인 인덱스](https://index.krew.dev/)를 통해 사용할 수 있는 kubectl 플러그인은
보안 감사를 받지 않는다. 써드파티 플러그인은 시스템에서 실행되는 임의의
프로그램이므로, 사용자는 이를 인지한 상태에서 설치하고 실행해야 한다.
{{< /caution >}}
### 플러그인 디스커버리
`kubectl` 은 유효한 플러그인 실행 파일을 `PATH` 에서 검색하는 `kubectl plugin list` 명령을 제공한다.
이 명령을 실행하면 `PATH` 에 있는 모든 파일을 탐색한다. 실행 가능하고, `kubectl-` 로 시작하는 모든 파일은 이 명령의 출력 결과에 *`PATH` 에 있는 순서대로* 표시된다.
실행 파일이 *아닌* 파일이 `kubectl-` 시작하는 경우 경고가 포함된다.
서로의 이름과 겹치는 유효한 플러그인 파일에 대한 경고도 포함된다.
[Krew](https://krew.dev/)를 사용하여 커뮤니티가 관리하는
[플러그인 인덱스](https://index.krew.dev/)에서 `kubectl`
플러그인을 검색하고 설치할 수 있다.
#### 제한 사항
현재 기존 `kubectl` 명령을 덮어 쓰는 플러그인을 생성할 수 없다. 예를 들어, 플러그인 `kubectl-version` 을 만들면 기존의 `kubectl version` 명령이 항상 우선하므로, 플러그인이 실행되지 않는다. 이 제한으로 인해, 플러그인을 사용하여 기존 `kubectl` 명령에 새로운 하위 명령을 추가할 수도 *없다*. 예를 들어, 플러그인 이름을 `kubectl-create-foo` 로 지정하여 `kubectl create foo` 하위 명령을 추가하면 해당 플러그인이 무시된다.
`kubectl plugin list` 는 이를 시도하는 유효한 플러그인에 대한 경고를 표시한다.
## kubectl 플러그인 작성
커맨드-라인 명령을 작성할 수 있는 프로그래밍 언어나 스크립트로 플러그인을 작성할 수 있다.
플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은
`kubectl` 바이너리에서 상속된 환경을 받는다.
플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다. 예를
들어, 새로운 명령인 `kubectl foo` 를 제공하려는 플러그인은 단순히 이름이
`kubectl-foo` 이고, `PATH` 의 어딘가에 있다.
### 플러그인 예제
```bash
#!/bin/bash
# 선택적 인수 처리
if [[ "$1" == "version" ]]
then
echo "1.0.0"
exit 0
fi
# 선택적 인수 처리
if [[ "$1" == "config" ]]
then
echo "$KUBECONFIG"
exit 0
fi
echo "I am a plugin named kubectl-foo"
```
### 플러그인 사용
위의 플러그인을 사용하려면, 간단히 실행 가능하게 만든다.
```
sudo chmod +x ./kubectl-foo
```
그리고 `PATH` 의 어느 곳에나 옮겨 놓는다.
```
sudo mv ./kubectl-foo /usr/local/bin
```
이제 플러그인을 `kubectl` 명령으로 호출할 수 있다.
```
kubectl foo
```
```
I am a plugin named kubectl-foo
```
모든 인수와 플래그는 그대로 실행 파일로 전달된다.
```
kubectl foo version
```
```
1.0.0
```
모든 환경 변수도 실행 파일로 그대로 전달된다.
```bash
export KUBECONFIG=~/.kube/config
kubectl foo config
```
```
/home/<user>/.kube/config
```
```shell
KUBECONFIG=/etc/kube/config kubectl foo config
```
```
/etc/kube/config
```
또한, 플러그인으로 전달되는 첫 번째 인수는 항상 호출된 위치의 전체 경로이다(위의 예에서 `$0` 은 `/usr/local/bin/kubectl-foo` 와 동일하다).
### 플러그인 이름 지정
위 예제에서 볼 수 있듯이, 플러그인은 파일명을 기반으로 구현할 명령 경로를 결정한다. 플러그인이 대상으로 하는 명령 경로의 모든 하위 명령은 대시(`-`)로 구분된다.
예를 들어, 사용자가 `kubectl foo bar baz` 명령을 호출할 때마다 호출되는 플러그인은 파일명이 `kubectl-foo-bar-baz` 이다.
#### 플래그와 인수 처리
{{< note >}}
플러그인 메커니즘은 플러그인 프로세스에 대한 사용자 정의, 플러그인 특정 값 또는 환경 변수를 생성하지 *않는다*.
이전 kubectl 플러그인 메커니즘은 `KUBECTL_PLUGINS_CURRENT_NAMESPACE` 와 같이 더이상 사용하지 않는 환경 변수를 제공했다.
{{< /note >}}
kubectl 플러그인은 전달된 모든 인수를 파싱하고 유효성을 검사해야 한다.
플러그인 작성자를 대상으로 하는 Go 라이브러리에 대한 자세한 내용은 [커맨드 라인 런타임 패키지 사용](#커맨드-라인-런타임-패키지-사용)을 참고한다.
다음은 사용자가 추가 플래그와 인수를 제공하면서 플러그인을 호출하는 추가 사례이다. 이것은 위 시나리오의 `kubectl-foo-bar-baz` 플러그인을 기반으로한다.
`kubectl foo bar baz arg1 --flag=value arg2` 를 실행하면, kubectl의 플러그인 메커니즘은 먼저 가장 긴 가능한 이름을 가진 플러그인을 찾으려고 시도한다. 여기서는
`kubectl-foo-bar-baz-arg1` 이다. 해당 플러그인을 찾지 못하면, kubectl은 대시로 구분된 마지막 값을 인수(여기서는 `arg1`)로 취급하고, 다음으로 가장 긴 가능한 이름인 `kubectl-foo-bar-baz` 를 찾는다.
이 이름의 플러그인을 찾으면, kubectl은 해당 플러그인을 호출하여, 플러그인 이름 뒤에 모든 인수와 플래그를 플러그인 프로세스의 인수로 전달한다.
예:
```bash
# 플러그인 생성
echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz
# $PATH에 있는 디렉터리로 옮겨 플러그인을 "설치"
sudo mv ./kubectl-foo-bar-baz /usr/local/bin
# 플러그인을 kubectl이 인식하는지 확인
kubectl plugin list
```
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-foo-bar-baz
```
```
# test that calling your plugin via a "kubectl" command works
# even when additional arguments and flags are passed to your
# plugin executable by the user.
kubectl foo bar baz arg1 --meaningless-flag=true
```
```
My first command-line argument was arg1
```
보시다시피, 사용자가 지정한 `kubectl` 명령을 기반으로 플러그인을 찾았으며, 모든 추가 인수와 플래그는 플러그인 실행 파일이 발견되면 그대로 전달된다.
#### 대시와 언더스코어가 있는 이름
`kubectl` 플러그인 메커니즘은 플러그인 파일명에 대시(`-`)를 사용하여 플러그인이 처리하는 하위 명령 시퀀스를 분리하지만, 파일명에
언더스코어(`_`)를 사용하여 커맨드 라인 호출에 대시를 포함하는 플러그인 명령을 생성할 수 있다.
예:
```bash
# 파일명에 언더스코어(_)가 있는 플러그인 생성
echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar
# $PATH에 플러그인을 옮긴다
sudo mv ./kubectl-foo_bar /usr/local/bin
# 이제 kubectl을 통해 플러그인을 사용할 수 있다
kubectl foo-bar
```
```
I am a plugin with a dash in my name
```
참고로 플러그인 파일명에 언더스코어를 추가해도 `kubectl foo_bar` 와 같은 명령을 사용할 수 있다.
위 예에서 명령은 대시(`-`) 또는 언더스코어(`_`)을 사용하여 호출할 수 있다.
```bash
# 대시를 포함한 사용자 정의 명령을 사용할 수 있다
kubectl foo-bar
```
```
I am a plugin with a dash in my name
```
```bash
# 언더스코어를 포함한 사용자 정의 명령을 사용할 수도 있다
kubectl foo_bar
```
```
I am a plugin with a dash in my name
```
#### 이름 충돌과 오버셰도잉(overshadowing)
`PATH` 의 다른 위치에 동일한 파일명을 가진 여러 플러그인이 있을 수 있다.
예를 들어, `PATH` 값이 `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins` 로 주어지고, `kubectl-foo` 플러그인을 복사한 파일이 `/usr/local/bin/plugins` 와 `/usr/local/bin/moreplugins` 에 있을 수 있다.
`kubectl plugin list` 명령의 출력 결과는 다음과 같다.
```bash
PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
```
```
The following kubectl-compatible plugins are available:
/usr/local/bin/plugins/kubectl-foo
/usr/local/bin/moreplugins/kubectl-foo
- warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo
error: one plugin warning was found
```
위 시나리오에서, `/usr/local/bin/moreplugins/kubectl-foo` 아래의 경고는 이 플러그인이 실행되지 않을 것임을 알려준다. 대신, `PATH` 에 먼저 나타나는 실행 파일인 `/usr/local/bin/plugins/kubectl-foo` 는 항상 발견되고 `kubectl` 플러그인 메카니즘에 의해 먼저 실행된다.
이 문제를 해결하는 방법은 `kubectl` 와 함께 사용하려는 플러그인의 위치가 `PATH` 에 항상에서 먼저 오도록 하는 것이다. 예를 들어, `kubectl` 명령 `kubectl foo` 가 호출될 때마다 항상 `/usr/local/bin/moreplugins/kubectl-foo` 를 사용하려면, `PATH` 의 값을 `/usr/local/bin/moreplugins:/usr/local/bin/plugins` 로 변경한다.
#### 가장 긴 실행 파일명의 호출
플러그인 파일명으로 발생할 수 있는 또 다른 종류의 오버셰도잉이 있다. 사용자의 `PATH` 에 `kubectl-foo-bar` 와 `kubectl-foo-bar-baz` 라는 두 개의 플러그인이 있다면, `kubectl` 플러그인 메커니즘은 항상 주어진 사용자의 명령에 대해 가장 긴 가능한 플러그인 이름을 선택한다. 아래에 몇 가지 예가 있다.
```bash
# 주어진 kubectl 명령의 경우, 가장 긴 가능한 파일명을 가진 플러그인이 항상 선호된다
kubectl foo bar baz
```
```
Plugin kubectl-foo-bar-baz is executed
```
```bash
kubectl foo bar
```
```
Plugin kubectl-foo-bar is executed
```
```bash
kubectl foo bar baz buz
```
```
Plugin kubectl-foo-bar-baz is executed, with "buz" as its first argument
```
```bash
kubectl foo bar buz
```
```
Plugin kubectl-foo-bar is executed, with "buz" as its first argument
```
이 디자인 선택은 필요한 경우 여러 파일에 플러그인 하위 명령을 구현할 수 있도록 하고 이러한 하위 명령을 "부모" 플러그인 명령 아래에 중첩할 수 있도록 한다.
```bash
ls ./plugin_command_tree
```
```
kubectl-parent
kubectl-parent-subcommand
kubectl-parent-subcommand-subsubcommand
```
### 플러그인 경고 확인
위에서 언급한 `kubectl plugin list` 명령을 사용하여 `kubectl` 에 의해 플러그인이 표시되는지 확인하고, `kubectl` 명령으로 호출되지 못하게 하는 경고가 없는지 확인할 수 있다.
```bash
kubectl plugin list
```
```
The following kubectl-compatible plugins are available:
test/fixtures/pkg/kubectl/plugins/kubectl-foo
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-invalid
- warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable
error: 2 plugin warnings were found
```
### 커맨드 라인 런타임 패키지 사용
kubectl 용 플러그인을 작성하고 있고 Go를 사용한다면,
[cli-runtime](https://github.com/kubernetes/cli-runtime) 유틸리티 라이브러리를
사용할 수 있다.
이 라이브러리는 사용자의
[kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
파일을 파싱이나 업데이트하거나, REST 스타일의 요청을 API 서버에 작성하거나, 구성 및 출력과
관련된 플래그를 바인딩하기 위한 헬퍼를 제공한다.
CLI 런타임 리포지터리에 제공된 도구 사용법의 예제는
[샘플 CLI 플러그인](https://github.com/kubernetes/sample-cli-plugin)을 참고한다.
## kubectl 플러그인 배포
다른 사람이 사용할 수 있는 플러그인을 개발한 경우, 이를 패키징하고, 배포하고
사용자에게 업데이트를 제공하는 방법을 고려해야 한다.
### Krew {#distributing-krew}
[Krew](https://krew.dev/)는 플러그인을 패키징하고 배포하는 크로스-플랫폼
방식을 제공한다. 이렇게 하면, 모든 대상 플랫폼(리눅스, 윈도우, macOS 등)에
단일 패키징 형식을 사용하고 사용자에게 업데이트를 제공한다.
Krew는 또한 다른 사람들이 여러분의 플러그인을 검색하고 설치할 수 있도록
[플러그인 인덱스](https://index.krew.dev/)를
유지 관리한다.
### 네이티브 / 플랫폼 별 패키지 관리 {#distributing-native}
다른 방법으로는, 리눅스의 `apt` 나 `yum`,
윈도우의 Chocolatey, macOS의 Homebrew와 같은 전통적인 패키지 관리자를 사용할 수 있다.
새 실행 파일을 사용자의 `PATH` 어딘가에 배치할 수 있는 패키지 관리자라면
어떤 패키지 관리자도 괜찮다.
플러그인 작성자로서, 이 옵션을 선택하면 각 릴리스의 여러 플랫폼에서
kubectl 플러그인의 배포 패키지를
업데이트해야 한다.
### 소스 코드 {#distributing-source-code}
소스 코드를 게시(예를 들어, Git 리포지터리)할 수 있다. 이
옵션을 선택하면, 해당 플러그인을 사용하려는 사람이 코드를 가져와서,
빌드 환경을 설정하고(컴파일이 필요한 경우), 플러그인을 배포해야 한다.
컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가
더 쉬워진다.
{{% /capture %}}
{{% capture whatsnext %}}
* Go로 작성된 플러그인의
[자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는
샘플 CLI 플러그인 리포지터리를 확인한다.
궁금한 사항이 있으면,
[SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다.
* kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다.
{{% /capture %}}

4
content/ko/docs/tasks/manage-daemon/_index.md Normal file
View File

@ -0,0 +1,4 @@
---
title: "클러스터 데몬 관리"
weight: 130
---

155
content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md Normal file
View File

@ -0,0 +1,155 @@
---
title: 데몬셋(DaemonSet)에서 롤백 수행
content_template: templates/task
weight: 20
---
{{% capture overview %}}
이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다.
{{% /capture %}}
{{% capture prerequisites %}}
* 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은
쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다.
* [데몬셋에서 롤링 업데이트를
수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다.
{{% /capture %}}
{{% capture steps %}}
## 데몬셋에서 롤백 수행
### 1단계: 롤백할 데몬셋 리비전 찾기
마지막 리비전으로 롤백하려는 경우 이 단계를 건너뛸 수 있다.
데몬셋의 모든 리비전을 나열한다.
```shell
kubectl rollout history daemonset <daemonset-name>
```
이 명령은 데몬셋 리비전 목록을 반환한다.
```shell
daemonsets "<daemonset-name>"
REVISION CHANGE-CAUSE
1 ...
2 ...
...
```
* 변경 원인은 데몬셋 어노테이션 `kubernetes.io/change-cause` 에서
생성 시의 리비전으로 복사된다. 변경 원인 어노테이션에서 실행된 명령을 기록하도록
`kubectl` 에 `--record=true` 를 지정할 수 있다.
특정 리비전의 세부 사항을 보려면 다음을 수행한다.
```shell
kubectl rollout history daemonset <daemonset-name> --revision=1
```
이 명령은 해당 리비전의 세부 사항을 반환한다.
```shell
daemonsets "<daemonset-name>" with revision #1
Pod Template:
Labels: foo=bar
Containers:
app:
Image: ...
Port: ...
Environment: ...
Mounts: ...
Volumes: ...
```
### 2단계: 특정 리비전으로 롤백
```shell
# --to-revision에 1단계에서 얻는 리비전 번호를 지정한다
kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>
```
성공하면, 명령은 다음을 반환한다.
```shell
daemonset "<daemonset-name>" rolled back
```
`--to-revision` 플래그를 지정하지 않은 경우, 마지막 리비전이 선택된다.
### 3단계: 데몬셋 롤백 진행 상황 확인
`kubectl rollout undo daemonset` 은 서버에 데몬셋 롤백을 시작하도록
지시한다. 실제 롤백은 서버 측에서 비동기적으로 수행된다.
롤백 진행 상황을 보려면 다음의 명령을 수행한다.
```shell
kubectl rollout status ds/<daemonset-name>
```
롤백이 완료되면, 출력 결과는 다음과 비슷하다.
```shell
daemonset "<daemonset-name>" successfully rolled out
```
{{% /capture %}}
{{% capture discussion %}}
## 데몬셋 리비전의 이해
이전 `kubectl rollout history` 단계에서, 데몬셋 리비전 목록을
얻었다. 각 리비전은 `ControllerRevision` 이라는 리소스에 저장된다.
`ControllerRevision` 은 쿠버네티스 릴리스 1.7 이상에서만 사용할 수 있는
리소스이다.
각 리비전에 저장된 내용을 보려면, 데몬셋 리비전 원시 리소스를
찾는다.
```shell
kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value>
```
이 명령은 `ControllerRevisions` 의 목록을 반환한다.
```shell
NAME CONTROLLER REVISION AGE
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 1 1h
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 2 1h
```
각 `ControllerRevision` 은 데몬셋 리비전의 어노테이션과 템플릿을
저장한다. ControllerRevision 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
`kubectl rollout undo` 는 특정 `ControllerRevision` 을 가져와 데몬셋
템플릿을 `ControllerRevision` 에 저장된 템플릿으로 바꾼다.
`kubectl rollout undo` 는 `kubectl edit` 또는 `kubectl apply` 와 같은 다른 명령을 통해
데몬셋 템플릿을 이전 리비전으로 업데이트하는 것과
같다.
{{< note >}}
데몬셋 리비전은 롤 포워드만 한다. 즉, 롤백이
완료된 후, 롤백될 `ControllerRevision` 의
리비전 번호(`.revision` 필드)가 증가한다. 예를 들어,
시스템에 리비전 1과 2가 있고, 리비전 2에서 리비전 1으로 롤백하면,
`ControllerRevision` 은 `.revision: 1` 에서 `.revision: 3` 이 된다.
{{< /note >}}
## 문제 해결
* [데몬셋 롤링 업데이트
문제 해결](/ko/docs/tasks/manage-daemon/update-daemon-set/#문제-해결)을 참고한다.
{{% /capture %}}

200
content/ko/docs/tasks/manage-daemon/update-daemon-set.md Normal file
View File

@ -0,0 +1,200 @@
---
title: 데몬셋(DaemonSet)에서 롤링 업데이트 수행
content_template: templates/task
weight: 10
---
{{% capture overview %}}
이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다.
{{% /capture %}}
{{% capture prerequisites %}}
* 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다.
{{% /capture %}}
{{% capture steps %}}
## 데몬셋 업데이트 전략
데몬셋에는 두 가지 업데이트 전략 유형이 있다.
* OnDelete: `OnDelete` 업데이트 전략을 사용하여, 데몬셋 템플릿을 업데이트한 후,
이전 데몬셋 파드를 수동으로 삭제할 때 *만* 새 데몬셋 파드가
생성된다. 이것은 쿠버네티스 버전 1.5 이하에서의 데몬셋의 동작과
동일하다.
* RollingUpdate: 기본 업데이트 전략이다.
`RollingUpdate` 업데이트 전략을 사용하여, 데몬셋 템플릿을
업데이트한 후, 오래된 데몬셋 파드가 종료되고, 새로운 데몬셋 파드는
제어 방식으로 자동 생성된다. 전체 업데이트 프로세스 동안 데몬셋의 최대 하나의 파드가 각 노드에서 실행된다.
## 롤링 업데이트 수행
데몬셋의 롤링 업데이트 기능을 사용하려면,
`.spec.updateStrategy.type` 에 `RollingUpdate` 를 설정해야 한다.
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable)(기본값은 1)과
[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)(기본값은 0)으로 설정할 수도 있다.
### `RollingUpdate` 업데이트 전략으로 데몬셋 생성
이 YAML 파일은 'RollingUpdate'를 업데이트 전략으로 사용하여 데몬셋을 명시한다.
{{< codenew file="controllers/fluentd-daemonset.yaml" >}}
데몬셋 매니페스트의 업데이트 전략을 확인한 후, 데몬셋을 생성한다.
```shell
kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
```
또는, `kubectl apply` 로 데몬셋을 업데이트하려는 경우, 동일한 데몬셋을
생성하는 데 `kubectl apply` 를 사용한다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
```
### 데몬셋 `RollingUpdate` 업데이트 전략 확인
데몬셋의 업데이트 전략을 확인하고, `RollingUpdate` 로 설정되어 있는지
확인한다.
```shell
kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system
```
시스템에서 데몬셋을 생성하지 않은 경우, 대신 다음의 명령으로
데몬셋 매니페스트를 확인한다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
```
두 명령의 출력 결과는 다음과 같아야 한다.
```shell
RollingUpdate
```
출력 결과가 `RollingUpdate` 가 아닌 경우, 이전 단계로 돌아가서 데몬셋 오브젝트나 매니페스트를
적절히 수정한다.
### 데몬셋 템플릿 업데이트
`RollingUpdate` 데몬셋 `.spec.template` 에 대한 업데이트는 롤링 업데이트를
트리거한다. 새 YAML 파일을 적용하여 데몬셋을 업데이트한다. 이것은 여러 가지 다른 `kubectl` 명령으로 수행할 수 있다.
{{< codenew file="controllers/fluentd-daemonset-update.yaml" >}}
#### 선언적 커맨드
[구성 파일](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)을
사용하여 데몬셋을 업데이트하는 경우,
`kubectl apply` 를 사용한다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.yaml
```
#### 명령형 커맨드
[명령형 커맨드](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)를
사용하여 데몬셋을 업데이트하는 경우,
`kubectl edit` 를 사용한다.
```shell
kubectl edit ds/fluentd-elasticsearch -n kube-system
```
##### 컨테이너 이미지만 업데이트
데몬셋 템플릿에서 컨테이너 이미지를 업데이트해야 하는
경우(예: `.spec.template.spec.containers[*].image`), `kubectl set image` 를 사용한다.
```shell
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
```
### 롤링 업데이트 상태 관찰
마지막으로, 최신 데몬셋 롤링 업데이트의 롤아웃 상태를 관찰한다.
```shell
kubectl rollout status ds/fluentd-elasticsearch -n kube-system
```
롤아웃이 완료되면, 출력 결과는 다음과 비슷하다.
```shell
daemonset "fluentd-elasticsearch" successfully rolled out
```
## 문제 해결
### 데몬셋 롤링 업데이트가 더 이상 진행되지 않는다(stuck)
가끔씩, 데몬셋 롤링 업데이트가 더 이상 진행되지 않을 수 있다. 이와 같은 상황이 발생할 수 있는 원인은
다음과 같다.
#### 일부 노드에 리소스가 부족하다
적어도 하나의 노드에서 새 데몬셋 파드를 스케줄링할 수 없어서 롤아웃이
중단되었다. 노드에 [리소스가 부족](/docs/tasks/administer-cluster/out-of-resource/)할 때
발생할 수 있다.
이 경우, `kubectl get nodes` 의 출력 결과와 다음의 출력 결과를 비교하여
데몬셋 파드가 스케줄링되지 않은 노드를 찾는다.
```shell
kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
```
해당 노드를 찾으면, 데몬셋이 아닌 파드를 노드에서 삭제하여
새 데몬셋 파드를 위한 공간을 생성한다.
{{< note >}}
삭제된 파드가 컨트롤러에 의해 제어되지 않거나 파드가 복제되지 않은 경우 서비스 중단이
발생한다. 이 때 [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)정책도 적용되지
않는다.
{{< /note >}}
#### 롤아웃 실패
최근 데몬셋 템플릿 업데이트가 중단된 경우(예를 들어, 컨테이너가
계속 크래시되거나, 컨테이너 이미지가 존재하지 않는 경우(종종 오타로 인해)),
데몬셋 롤아웃이 진행되지 않는다.
이 문제를 해결하려면, 데몬셋 템플릿을 다시 업데이트한다. 이전의 비정상 롤아웃으로 인해
새로운 롤아웃이 차단되지 않는다.
#### 클럭 차이(skew)
데몬셋에 `.spec.minReadySeconds` 가 명시된 경우, 마스터와 노드 사이의
클럭 차이로 인해 데몬셋이 올바른 롤아웃 진행 상황을 감지할 수
없다.
## 정리
네임스페이스에서 데몬셋을 삭제한다.
```shell
kubectl delete ds fluentd-elasticsearch -n kube-system
```
{{% /capture %}}
{{% capture whatsnext %}}
* [태스크: 데몬셋에서 롤백
수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다.
* [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다.
{{% /capture %}}

126
content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md Normal file
View File

@ -0,0 +1,126 @@
---
title: HugePages 관리
content_template: templates/task
---
{{% capture overview %}}
{{< feature-state state="stable" >}}
쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된
huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가
huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다.
{{% /capture %}}
{{% capture prerequisites %}}
1. 쿠버네티스 노드는 노드에 대한 huge page 용량을 보고하기 위해
huge page를 미리 할당해야 한다. 노드는 여러 크기의 huge page를 미리 할당할 수
있다.
노드는 모든 huge page 리소스를 스케줄 가능한 리소스로 자동 검색하고
보고한다.
{{% /capture %}}
{{% capture steps %}}
## API
리소스 이름 `hugepages-<size>` (`<size>` 는 특정 노드에서 지원되는 정수값을
사용하는 가장 간단한 2진 표기법)를 사용하여 컨테이너 레벨의 리소스
요구 사항을 통해 huge page를 사용할 수 있다. 예를 들어,
노드가 2048KiB 및 1048576KiB 페이지 크기를 지원하는 경우, 스케줄 가능한
리소스인 `hugepages-2Mi` 와 `hugepages-1Gi` 를 노출한다. CPU나 메모리와 달리,
huge page는 오버커밋을 지원하지 않는다. 참고로 hugepage 리소스를 요청하는 경우,
메모리 또는 CPU 리소스도 요청해야 한다.
파드는 단일 파드 스펙에 여러 개의 huge page 크기를 사용할 수 있다. 이 경우
모든 볼륨 마운트에 대해 `medium: HugePages-<hugepagesize>` 표기법을 사용해야 한다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: huge-pages-example
spec:
containers:
- name: example
image: fedora:latest
command:
- sleep
- inf
volumeMounts:
- mountPath: /hugepages-2Mi
name: hugepage-2mi
- mountPath: /hugepages-1Gi
name: hugepage-1gi
resources:
limits:
hugepages-2Mi: 100Mi
hugepages-1Gi: 2Gi
memory: 100Mi
requests:
memory: 100Mi
volumes:
- name: hugepage-2mi
emptyDir:
medium: HugePages-2Mi
- name: hugepage-1gi
emptyDir:
medium: HugePages-1Gi
```
파드는 동일한 크기의 huge page들을 요청하는 경우에만 `medium: HugePages` 를 사용할 수 있다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: huge-pages-example
spec:
containers:
- name: example
image: fedora:latest
command:
- sleep
- inf
volumeMounts:
- mountPath: /hugepages
name: hugepage
resources:
limits:
hugepages-2Mi: 100Mi
memory: 100Mi
requests:
memory: 100Mi
volumes:
- name: hugepage
emptyDir:
medium: HugePages
```
- Huge page 요청(requests)은 제한(limits)과 같아야 한다. 제한이 지정되었지만, 요청은 지정되지 않은 경우
이것이 기본값이다.
- Huge page는 컨테이너 범위에서 격리되므로, 각 컨테이너에는 컨테이너 사양에서 요청한대로 cgroup 샌드박스에 대한 제한이 있다.
- Huge page가 지원하는 EmptyDir 볼륨은 파드 요청보다 더 많은 huge page 메모리를
사용하지 말아야 한다.
- `shmget()` 의 `SHM_HUGETLB` 를 통해 huge page를 사용하는 애플리케이션은
`proc/sys/vm/hugetlb_shm_group` 과 일치하는 보충 그룹(supplemental group)으로 실행해야 한다.
- 네임스페이스에서의 huge page 사용은 `hugepages-<size>` 토큰을 사용하는 `cpu` 또는 `memory` 와 같은
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
있다.
- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다. {{<
glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{<
glossary_tooltip text="kube-apiserver"
term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
`HugePageStorageMediumSize` [기능
게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.
## 향후 버전
- NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다.
- 리밋레인지(LimitRange)를 지원할 예정이다.
{{% /capture %}}

14
content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
View File

@ -48,12 +48,12 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다.
### 리소스 생성
컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다.
컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일같이 다른 곳에서 가져온다.
컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다.
#### configMapGenerator
파일에서 컨피그 맵을 생성하려면 `configMapGenerator` 내의 `files` 리스트에 항목을 추가한다. 다음은 하나의 파일 콘텐츠에서 데이터 항목으로 컨피그 맵을 생성하는 예제이다.
파일에서 컨피그 맵을 생성하려면 `configMapGenerator` 내의 `files` 리스트에 항목을 추가한다. 다음은 하나의 `.properties` 파일에서 데이터 항목으로 컨피그 맵을 생성하는 예제이다.
```shell
# application.properties 파일을 생성
@ -69,7 +69,7 @@ configMapGenerator:
EOF
```
생성된 컨피그 맵은 다음 명령어를 통해 확인할 수 있다.
생성된 컨피그 맵은 다음 명령어로 검사할 수 있다.
```shell
kubectl kustomize ./
@ -173,7 +173,7 @@ type: Opaque
#### generatorOptions
생성된 컨피그 맵과 시크릿은 콘텐츠를 해쉬화하여 덧붙이는 접미사를 가진다. 이는 콘텐츠가 변경될 때 새로운 컨피그 맵 이나 시크릿이 생성되는 것을 보장한다. 접미사를 추가하는 동작을 비활성화하는 방법으로 `generatorOptions`를 사용할 수 있다. 그밖에, 생성된 컨피그 맵과 시크릿에 교차 편집 옵션들을 지정해주는 것도 가능하다.
생성된 컨피그 맵과 시크릿은 콘텐츠 해시 접미사가 추가된다. 이는 콘텐츠가 변경될 때 새로운 컨피그 맵 이나 시크릿이 생성되는 것을 보장한다. 접미사를 추가하는 동작을 비활성화하는 방법으로 `generatorOptions`를 사용할 수 있다. 그밖에, 생성된 컨피그 맵과 시크릿에 교차 편집 옵션들을 지정해주는 것도 가능하다.
```shell
cat <<EOF >./kustomization.yaml
@ -290,7 +290,7 @@ Kustomize는 서로 다른 파일들로 리소스를 구성하고 패치나 다
#### 구성
Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다.
다음 예제는 디플로이먼트와 서비스를 가지는 nginx 애플리케이션이다.
다음 예제는 디플로이먼트와 서비스로 구성된 NGINX 애플리케이션이다.
```shell
# deployment.yaml 파일 생성
@ -340,11 +340,11 @@ resources:
EOF
```
`kubectl kustomize ./`의 리소스는 디플로이먼트와 서비스 오브젝트 모두를 포함한다.
`kubectl kustomize ./`의 리소스에는 디플로이먼트와 서비스 오브젝트가 모두 포함되어 있다.
#### 사용자 정의
리소스 위에 패치를 적용하는 것으로 서로 다른 사용자 정의들을 적용할 수 있다. Kustomize는
패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는
`patchesStrategicMerge`와 `patchesJson6902`를 통해 서로 다른 패치 메커니즘을 지원한다. `patchesStrategicMerge`는 파일 경로들의 리스트이다. 각각의 파일은 [전략적 병합 패치](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)로 분석될 수 있어야 한다. 패치 내부의 네임은 반드시 이미 읽혀진 리소스 네임과 일치해야 한다. 한 가지 일을 하는 작은 패치가 권장된다. 예를 들기 위해 디플로이먼트 레플리카 숫자를 증가시키는 하나의 패치와 메모리 상한을 설정하는 다른 패치를 생성한다.
```shell

196
content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md Normal file
View File

@ -0,0 +1,196 @@
---
title: 단일 인스턴스 스테이트풀 애플리케이션 실행하기
content_template: templates/tutorial
weight: 20
---
{{% capture overview %}}
이 페이지에서는 쿠버네티스 클러스터에서 퍼시스턴트볼륨(PersistentVolume)과 디플로이먼트(Deployment)를
사용하여, 단일 인스턴스 스테이트풀 애플리케이션을 실행하는 방법을 보인다.
해당 애플리케이션은 MySQL이다.
{{% /capture %}}
{{% capture objectives %}}
* 사용자 환경의 디스크를 참조하는 퍼시스턴트볼륨 생성하기
* MySQL 디플로이먼트 생성하기
* 알려진 DNS 이름으로 클러스터의 다른 파드에 MySQL 서비스 노출하기
{{% /capture %}}
{{% capture prerequisites %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "default-storage-class-prereqs.md" >}}
{{% /capture %}}
{{% capture lessoncontent %}}
## MySQL 배포하기
쿠버네티스 디플로이먼트를 생성하고 퍼시스턴트볼륨클레임(PersistentVolumeClaim)을
사용하는 기존 퍼시스턴트볼륨에 연결하여 스테이트풀
애플리케이션을 실행할 수 있다. 예를 들어, 다음 YAML 파일은
MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로이먼트를 기술한다.
이 파일은 /var/lib/mysql에 대한 볼륨 마운트를 정의한 후에,
20G의 볼륨을 요청하는 퍼시트턴트볼륨클레임을 생성한다.
이 클레임은 요구 사항에 적합한 기존 볼륨이나
동적 프로비저너에 의해서 충족된다.
참고: config yaml 파일에 정의된 비밀번호는 안전하지 않다. 더 안전한 해결방법을 위해
[쿠버네티스 시크릿](/docs/concepts/configuration/secret/)
을 보자
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
{{< codenew file="application/mysql/mysql-pv.yaml" >}}
1. YAML 파일의 PV와 PVC를 배포한다.
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
1. YAML 파일의 다른 오브젝트들을 배포한다.
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
1. 디플로이먼트에 관한 정보를 확인한다.
kubectl describe deployment mysql
Name: mysql
Namespace: default
CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700
Labels: app=mysql
Annotations: deployment.kubernetes.io/revision=1
Selector: app=mysql
Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType: Recreate
MinReadySeconds: 0
Pod Template:
Labels: app=mysql
Containers:
mysql:
Image: mysql:5.6
Port: 3306/TCP
Environment:
MYSQL_ROOT_PASSWORD: password
Mounts:
/var/lib/mysql from mysql-persistent-storage (rw)
Volumes:
mysql-persistent-storage:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: mysql-pv-claim
ReadOnly: false
Conditions:
Type Status Reason
---- ------ ------
Available False MinimumReplicasUnavailable
Progressing True ReplicaSetUpdated
OldReplicaSets: <none>
NewReplicaSet: mysql-63082529 (1/1 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
1. 디플로이먼트로 생성된 파드를 나열한다.
kubectl get pods -l app=mysql
NAME READY STATUS RESTARTS AGE
mysql-63082529-2z3ki 1/1 Running 0 3m
1. 퍼시스턴트볼륨클레임을 살펴본다.
kubectl describe pvc mysql-pv-claim
Name: mysql-pv-claim
Namespace: default
StorageClass:
Status: Bound
Volume: mysql-pv-volume
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed=yes
pv.kubernetes.io/bound-by-controller=yes
Capacity: 20Gi
Access Modes: RWO
Events: <none>
## MySQL 인스턴스 접근하기
이전의 YAML 파일은 클러스터의 다른 파드가 데이터베이스에
접근할 수 있는 서비스를 생성한다. `clusterIP: None`
서비스 옵션을 사용하면 서비스의 DNS 이름을 직접 파드의 IP 주소로
해석하도록 처리한다. 이 방법은 서비스에서 연결되는 파드가 오직 하나 뿐이고,
파드의 수를 더 늘릴 필요가 없는 경우에 가장 적합하다.
서버에 접속하기 위하여 MySQL 클라이언트를 실행한다.
```
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
```
이 명령어는 MySQL 클라이언트를 실행하는 파드를 클러스터에 생성하고,
서비스를 통하여 서버에 연결한다. 연결된다면, 스테이트풀
MySQL 데이터베이스가 실행 중임을 알 수 있다.
```
Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.
mysql>
```
## 업데이트하기
`kubectl apply` 명령을 사용하여 기존과 동일한 방식으로 디플로이먼트의
이미지나 다른 부분을 변경할 수 있다. 스테이트풀 애플리케이션과 관련하여 몇 가지
주의 사항이 있다.
* 애플리케이션을 스케일링하지 않는다. 이 설정은 단일 인스턴스 애플리케이션 전용이다.
기본적인 퍼시스턴트볼륨은 하나의 파드에서만 마운트할 수 있다.
클러스터 형태의 스테이트풀 애플리케이션에 대해서는
[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 보자.
* 디플로이먼트 구성 YAML 파일에서 `strategy:`
`type: Recreate` 를 사용한다. 이는 쿠버네티스가
롤링 업데이트를 사용하지 _않도록_ 지시한다. 동시에 두 개 이상의 파드를 생성할
수 없으므로, 롤링 업데이트는 일어나지 않게 된다. `Recreate` 전략을 사용하면
변경된 구성으로 새로운 파드를 생성하기에 앞서 기존의 파드를 중단한다.
## 디플로이먼트 삭제하기
이름으로 배포된 오브젝트를 삭제한다.
```
kubectl delete deployment,svc mysql
kubectl delete pvc mysql-pv-claim
kubectl delete pv mysql-pv-volume
```
퍼시스턴트볼륨을 수동으로 프로비저닝한 경우라면,
동일하게 수동으로 삭제하고 기본 리소스도 해제해야 한다.
동적 프로비저너를 사용한 경우, 퍼시스턴트볼륨클레임이
삭제되었을 때에 퍼시스턴트볼륨 또한 자동으로 삭제된다.
일부 동적 프로비저너(EBS 와 PD와 같은)는
퍼시스턴트볼륨을 삭제할 때에 기본 리소스도 해제한다.
{{% /capture %}}
{{% capture whatsnext %}}
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기
* [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기
* [kubectl run 문서](/docs/reference/generated/kubectl/kubectl-commands/#run)
* [볼륨](/ko/docs/concepts/storage/volumes/)과 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)
{{% /capture %}}

2
content/ko/docs/tasks/tools/install-kubectl.md
View File

@ -9,7 +9,7 @@ card:
---
<!-- overview -->
쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/user-guide/kubectl/)을 사용하면, 쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며 로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는, [kubectl 개요](/docs/reference/kubectl/overview/)를 참고한다.
쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/user-guide/kubectl/)을 사용하면, 쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며 로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는, [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다.
## {{% heading "prerequisites" %}}

8
content/ko/docs/tutorials/hello-minikube.md
View File

@ -49,7 +49,9 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
{{< kat-button >}}
{{< note >}}Minikube를 로컬에 설치했다면 `minikube start`을 실행한다.{{< /note >}}
{{< note >}}
Minikube를 로컬에 설치했다면 `minikube start`를 실행한다.
{{< /note >}}
2. 브라우저에서 쿠버네티스 대시보드를 열어보자.
@ -114,7 +116,9 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
kubectl config view
```
{{< note >}}`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개관](/docs/user-guide/kubectl-overview/)을 살펴보자.{{< /note >}}
{{< note >}}
`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/docs/user-guide/kubectl-overview/)을 살펴보자.
{{< /note >}}
## 서비스 만들기

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

@ -716,7 +716,6 @@ zk-0 1/1 Running 1 29m
쿠버네티스에게 알리도록 활성도 검사를 이용해야 한다.
`zk` `스테이트풀셋`에 파드 `template`에 활성도 검사를 명시한다.
``
```yaml
livenessProbe:

48
content/ko/examples/controllers/fluentd-daemonset-update.yaml Normal file
View File

@ -0,0 +1,48 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# 이 톨러레이션(toleration)은 마스터 노드에서 실행 가능한 데몬셋이
# 마스터에서 파드를 실행할 수 없는 경우 이를 제거하는 것이다
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers

42
content/ko/examples/controllers/fluentd-daemonset.yaml Normal file
View File

@ -0,0 +1,42 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# 이 톨러레이션(toleration)은 마스터 노드에서 실행 가능한 데몬셋이
# 마스터에서 파드를 실행할 수 없는 경우 이를 제거하는 것이다
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers

10
content/ko/examples/debug/termination.yaml Normal file
View File

@ -0,0 +1,10 @@
apiVersion: v1
kind: Pod
metadata:
name: termination-demo
spec:
containers:
- name: termination-demo-container
image: debian
command: ["/bin/sh"]
args: ["-c", "sleep 10 && echo Sleep expired > /dev/termination-log"]

29
content/ko/examples/pods/init-containers.yaml Normal file
View File

@ -0,0 +1,29 @@
apiVersion: v1
kind: Pod
metadata:
name: init-demo
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: workdir
mountPath: /usr/share/nginx/html
# 이 컨테이너들은 파드 초기화 중에 실행된다.
initContainers:
- name: install
image: busybox
command:
- wget
- "-O"
- "/work-dir/index.html"
- http://kubernetes.io
volumeMounts:
- name: workdir
mountPath: "/work-dir"
dnsPolicy: Default
volumes:
- name: workdir
emptyDir: {}

5
content/ko/includes/default-storage-class-prereqs.md Normal file
View File

@ -0,0 +1,5 @@
여기에서 사용된 [퍼시스턴트볼륨클레임](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)을 만족하기 위하여,
기본 [스토리지클래스](/ko/docs/concepts/storage/storage-classes/)나
[정적으로(statically) 프로비저닝 된 퍼시스턴트볼륨](/docs/user-guide/persistent-volumes/#provisioning)을
갖는 퍼시스턴트 볼륨 프로비저너가
필요하다.

2
content/ko/training/_index.html
View File

@ -97,7 +97,7 @@ class: training
</h5>
<p>공인 쿠버네티스 관리자(CKA) 프로그램은 CKA가 쿠버네티스 관리자 직무을 수행할 수 있는 기술, 지식과 역량을 갖추고 있음을 보장합니다.</p>
<br>
<a href=https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">인증으로 이동하기</a>
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">인증으로 이동하기</a>
</center>
</div>
</div>