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

Fifth Korean localization work for release-1.14 (#14578) (#14874) 

Change List
* ko: add tutorials/clusters/apparmor #12455 (#14613)
* ko: add tasks/access-application-cluster/configure-dns-cluster (#14628)
* ko: add tasks/access-application-cluster/communicate-containers-same-… (#14627)
* ko: Update outdated files of setup and tasks in dev-1.14-ko.5 partly (#14683)
* translate to content/ko/docs/concepts/cluster-administration/cluster-… (#14237)
* Update renamed or deleted files in dev-1.14-ko.5 (#14710)
* Create pod.md (#13927)

Co-Authored-By:    Yoon <learder@gmail.com>
Co-Authored-By:    Woojin Na(Eddie) <kimchigood1130@gmail.com>
Co-Authored-By:    Claudia J. Kang <claudiajkang@gmail.com>
pull/15380/head
June Yi 2019-06-15 21:16:10 -07:00 committed by Kubernetes Prow Robot
parent 1d874b911c
commit 0f7cb401ee
30 changed files with 1101 additions and 414 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
content/ko/_index.html
View File

@ -44,12 +44,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019" button id="desktopKCButton">Attend KubeCon in Barcelona on May 20-23, 2019</a>
<br>
<br>
<br>
<br>
<a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019" button id="desktopKCButton">Attend KubeCon in Shanghai on June 24-26, 2019</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">Attend KubeCon in San Diego on Nov. 18-21, 2019</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

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

@ -53,7 +53,7 @@ weight: 40
클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다.
> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 이 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 모든 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
### 쿠버네티스 노드

6
content/ko/docs/concepts/architecture/cloud-controller.md
View File

@ -225,9 +225,9 @@ rules:
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
* [Linode](https://github.com/linode/linode-cloud-controller-manager)

69
content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md Normal file
View File

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

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

@ -1,5 +1,4 @@
---
title: "개요"
weight: 20
---
---

4
content/ko/docs/concepts/overview/object-management-kubectl/_index.md
View File

@ -1,4 +0,0 @@
---
title: "kubectl을 이용한 오브젝트 관리"
weight: 50
---

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

@ -1,7 +1,7 @@
---
title: 쿠버네티스 오브젝트 관리
content_template: templates/concept
weight: 10
weight: 15
---
{{% capture overview %}}
@ -176,9 +176,10 @@ kubectl apply -R -f configs/
{{% /capture %}}
{{% capture whatsnext %}}
- [명령형 명령어를 이용한 쿠버네티스 오브젝트 관리하기](/docs/concepts/overview/object-management-kubectl/imperative-command/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Kustomize를 사용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/tasks/manage-kubernetes-objects/kustomization/)
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
- [Kubectl 서적](https://kubectl.docs.kubernetes.io)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

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

@ -152,8 +152,8 @@ spec:
아래의 yaml file은 `mydb`와 `myservice` 서비스의 개요를 보여준다.
```yaml
kind: Service
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
@ -162,8 +162,8 @@ spec:
port: 80
targetPort: 9376
---
kind: Service
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
@ -313,7 +313,8 @@ myapp-pod 1/1 Running 0 9m
있다.
* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
앱 컨테이너 이미지의 변경은 앱 컨테이너만 재시작시킨다.
Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너
이미지의 변경은 앱 컨테이너만 재시작시킨다.
* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는,

22
content/ko/docs/concepts/workloads/pods/pod-overview.md
View File

@ -15,25 +15,25 @@ card:
{{% capture body %}}
## 파드에 대해 이해하기
*파드* 는 쿠버네티스의 기본 구성 요소이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 클러스터에서의 Running 프로세스를 나타낸다.
*파드* 는 쿠버네티스의 기본 구성 요소이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다.
파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, 컨테이너가 동작하기 위해 만들어진 옵션들을 캡슐화 한다.
파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다.
파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.
> [Docker](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다.
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다.
쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다.
* **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다.
* **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.
[쿠버네티스 블로그](http://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다.
* [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)
* [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)
각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
@ -46,7 +46,9 @@ card:
단일 파드 내부에서 함께 배치되고 관리되는 컨테이너 그룹은 상대적으로 심화된 사용 예시임에 유의하자. 컨테이너가 강하게 결합된 특별한 인스턴스의 경우에만 이 패턴을 사용하는게 좋다. 예를 들어, 공유 볼륨 내부 파일의 웹 서버 역할을 하는 컨테이너와 원격 소스로부터 그 파일들을 업데이트하는 분리된 "사이드카" 컨테이너가 있는 경우 아래 다이어그램의 모습일 것이다.
{{< figure src="/images/docs/pod.svg" title="pod diagram" width="50%" >}}
{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
몇몇의 파드는 {{< glossary_tooltip text="init containers" term_id="init-container" >}} 뿐만 아니라 {{< glossary_tooltip text="app containers" term_id="app-container" >}} 도 가진다. 초기 컨테이너는 앱 컨테이너 시작이 완료되기 전에 동작한다.
파드는 같은 파드 안에 속한 컨테이너에게 두 가지 공유 리소스를 제공한다. *네트워킹* 과 *저장소*.
@ -56,11 +58,11 @@ card:
#### 저장소
파드는 공유 저장소 집합인 *볼륨* 을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/docs/concepts/storage/volumes/)를 참고하길 바란다.
파드는 공유 저장소 집합인 {{< glossary_tooltip text="Volumes" term_id="volume" >}} 을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/docs/concepts/storage/volumes/)를 참고하길 바란다.
## 파드 작업
직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 노드에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다.
직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다.
{{< note >}}
파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다.
@ -104,7 +106,7 @@ spec:
{{% /capture %}}
{{% capture whatsnext %}}
* 파드의 다른 동작들을 더 배워보자.
* [파드](/docs/concepts/workloads/pods/pod/)의 다른 동작들을 더 배워보자.
* [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
{{% /capture %}}

205
content/ko/docs/concepts/workloads/pods/pod.md Normal file
View File

@ -0,0 +1,205 @@
---
title: 파드
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다.
{{% /capture %}}
{{% capture body %}}
## 파드는 무엇인가?
_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) 컨테이너 그룹이다.
이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다.
파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다.
파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다.
이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다.
컨테이너 이전의 세상에서 같은 물리적 또는 가상의 머신에서 실행되는 것은
같은 논리적 호스트에서 실행되고 있는 것을 의미한다.
쿠버네티스는는 도커 이외에도 많은 컨테이너 런타임을 지원하지만,
도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다.
파드의 공유 컨텍스트는 Linux 네임 스페이스, 컨트롤 그룹(cgroup) 및
도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
파드의 컨텍스트 내에서 개별 응용 프로그램은
추가적으로 하위 격리가 적용된다.
컨테이너들 안의 파드는 IP주소와 포트 공간을 공유하고,
서로를 `localhost` 를 통해 찾을 수 있다.
그들은 또한 SystemV 세마포어나, POSIX 공유 메모리와 같은 표준 프로세스 간 통신 방식으로
서로 통신할 수 있다.
다른 파드의 컨테이너에는 고유한 IP 주소가 있고,
[특별한 구성](/docs/concepts/policy/pod-security-policy/) 없이는 IPC에 의해서 통신 할 수 없다.
컨테이너는 주로 서로의 IP 주소를 통해 소통한다.
또한 파드 안의 애플리케이션은 파드의 일부로 정의되어,
각각의 애플리케이션의 파일시스템에 마운트 할 수 있도록 만들어진
공유 볼륨에 엑세스 할 수 있다.
[도커](https://www.docker.com/)의 구조 관점에서 보면
파드는 공유 네임스페이스와 공유 [볼륨](/docs/concepts/storage/volumes/)을 가진
도커 컨테이너 그룹으로 모델링 된다.
개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다.
[파드의 생애](/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
파드가 만들어지고 고유한 ID(UID)가 할당되고,
재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.
노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다.
해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로,
원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다.
더 자세한 내용은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
볼륨과 같이 파드와 동일한 수명이 있다고 하면,
UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것을 의미한다.
어떤 이유로든 해당 파드가 삭제 된 경우,
동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다.
{{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}}
*파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는
웹 서버를 포함하는 멀티 컨테이너 파드.*
## 파드의 의의
### 관리
파드는 응집력 있는 서비스 단위를 형성하는 여러 개의 협력 프로세스를 모델로 한다.
파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써
애플리케이션 배포 및 관리를 단순화한다.
파드는 전개 단위, 수평 확장 및 복제를 한다.
공동 스케줄링, 공유 된 생애주기 (예 : 종료), 조정 된 복제, 자원 공유 및 종속성 관리는
파드의 컨테이너에 대해 자동으로 처리된다.
### 리소스 공유 및 통신
파드는 그 구성 요소 간에 데이터 공유 및 통신이 가능하다.
파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로
서로를 찾고 통신하는데 `localhost`를 사용할 수 있다.
이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다.
각 파드에는 다른 물리적 컴퓨터 및 파드들과 네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다.
호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다.
더 자세한 내용은 [네트워킹의 더 자세한 내용](/docs/concepts/cluster-administration/networking/)을 참조한다.
파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다.
볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고,
파드 안의 애플리케이션들끼리 데이터를 공유할 수 있게 해준다.
## 파드의 사용
파드는 수직으로 통합 된 애플리케이션 스택(예 : LAMP)을 호스팅하는 데 사용할 수 있다.
하지만, 주요 동기는 공동 배치 및 공동 관리되는 헬퍼(helper) 프로그램을 지원하는 것이다.
예를 들면,
* 컨텐츠 관리 시스템, 파일과 데이터 로더, 로컬 캐시 관리 등.
* 로그와 백업 체크포인트, 압축, 로테이션, 스냅샷 등.
* 데이터 변동 감시자, 로그 추적자, 로깅 및 모니터링 어댑터, 이벤트 관리 등.
* 프록시, 브릿지, 어댑터
* 컨트롤러, 매니저, 설정, 업데이트
일반적으로 하나의 파드는
동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다.
더 자세한 설명을 보려면 [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴] (https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 참조한다.
## 고려된 대안
_싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_
1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면,
인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 제공할 수 있다.
이 기능들은 사용자에게 편의를 제공한다.
1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리,
재빌드, 재배포될 수 있다.
언젠가는 쿠버네티스에서 개별 컨테이너의 실시간 업데이트도 할 수 있을 것이다.
1. 사용의 편의성. 사용자는 자신의 프로세스 매니저를 따로 실행 할 필요가 없고,
시그널이나 종료 코드(exit-code) 전파 등에 대해 걱정할 필요가 없다.
1. 효율성. 인프라측에서 많은 책임을 가지고 있으므로,
컨테이너는 더 가벼워 질 수 있다.
_컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하지 않는 이유는 무엇인가?_
이와 같은 접근은 공동위치를 제공하지만,
리소스 공유, IPC, 보장된 생애 공유, 관리의 단순화와 같은
파드가 가진 대부분의 장점을 제공하지 못한다.
## 파드의 내구성 (또는 결핍)
파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패,
노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
일반적으로 사용자는 파드를 직접 만들 필요가 없다.
싱글톤이라도 대부분 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
컨트롤러는 클러스터 범위에서
복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다.
[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
위와 같은 기능 제공을 할 수 있다.
사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다:
* 스케줄러 및 컨트롤러 연결 가능
* "프록시" 없이 컨트롤러 API를 통한 파드-레벨 수준의 동작 지원
* 부트스트랩과 같이 컨트롤러의 생에와 파드의 생애 분리
* 컨트롤러와 서비스의 분리 &mdash; 파드를 감시하는 엔드 포인트 컨트롤러
* 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 &mdash; Kubelet은 효과적인 "파드 컨트롤러" 이다.
* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고,
삭제 전에는 확실히 교체되는 고가용성 애플리케이션.
## 파드의 종료
파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로 이러한 프로세스가 더 이상 필요하지 않을 때 (KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다.
사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐 만 아니라, 삭제가 결국 완료되는 것을 확인 할 수 있어야 한다.
사용자가 파드를 삭제하도록 요청하면 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고 TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다.
유예 기간이 만료되면 KILL 신호가 해당 프로세스로 전송되고 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면 종료가 전체 유예 기간과 함께 재시도된다.
흐름 예시:
1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초)
1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.
1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
1. 파드의 컨테이너 중 하나에 [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자.
1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다.
1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다.
기본적으로 모든 삭제는 30초 이내에 끝이난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드 하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0`값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). kubectl 버전 >= 1.5 에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0`와 함께 추가 플래그인 `--force`를 지정해야 한다.
### 파드 강제 삭제
파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, apiserver는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다.
API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다.
노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.
강제 삭제는 일부 파드의 경우 잠재적으로 위험 할 수 있으므로 주의해서 수행해야 한다.
스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업문서를 참조한다.
## 파드 컨테이너의 특권(Privileged) 모드
Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.
마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다.
사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다.
`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다.
`The Pod "FooPodName" is invalid.
spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
## API 오브젝트
파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
[파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
{{% /capture %}}

12
content/ko/docs/reference/glossary/docker.md
View File

@ -1,18 +1,18 @@
---
title: docker
title: 도커(Docker)
id: docker
date: 2018-04-12
full_link: /docs/reference/kubectl/docker-cli-to-kubectl/
full_link: https://docs.docker.com/engine/
short_description: >
Docker는 운영 시스템 수준의 가상화를 제공하는 소프트웨어 기술이며, 컨테이너로도 알려져 있다.
aka:
aka:
tags:
- fundamental
---
Docker는 운영 시스템 수준의 가상화를 제공하는 소프트웨어 기술이며, 컨테이너로도 알려져 있다.
도커(구체적으로, 도커 엔진)는 운영 시스템 수준의 가상화를 제공하는 소프트웨어 기술이며, {{< glossary_tooltip text="containers" term_id="container" >}} 로도 알려져 있다.
<!--more-->
<!--more-->
Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, "컨테이너"가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다.
Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다.

2
content/ko/docs/setup/certificates.md
View File

@ -82,7 +82,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm][kubeadm]에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다.
| 기본 CN | 권고하는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 |
| 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 |
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
| etcd-ca | | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
| etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |

2
content/ko/docs/setup/multiple-zones.md
View File

@ -187,8 +187,8 @@ Create a volume using the dynamic volume creation (only PersistentVolumes are su
```json
kubectl apply -f - <<EOF
{
"kind": "PersistentVolumeClaim",
"apiVersion": "v1",
"kind": "PersistentVolumeClaim",
"metadata": {
"name": "claim1",
"annotations": {

325
content/ko/docs/setup/pick-right-solution.md
View File

@ -1,325 +0,0 @@
---
title: 알맞은 솔루션 선정
weight: 10
content_template: templates/concept
card:
name: setup
weight: 20
anchors:
- anchor: "#호스트-된-솔루션"
title: 호스트 된 솔루션
- anchor: "#턴키-클라우드-솔루션"
title: 턴키 클라우드 솔루션
- anchor: "#온-프레미스-턴키-클라우드-솔루션"
title: 온-프레미스 솔루션
- anchor: "#사용자-지정-솔루션"
title: 사용자 지정 솔루션
- anchor: "#로컬-머신-솔루션"
title: 로컬 머신
---
{{% capture overview %}}
쿠버네티스는 랩탑부터 클라우드 공급자의 VM들, 베어메탈 서버 랙까지 다양한 플랫폼에서 작동 가능하다.
클러스터 구성을 위해 필요한 노력은 하나의 단일 명령어를 실행시키는 수준에서 직접 자신만의 맞춤형 클러스터를 세밀하게 만드는 수준에 이르기까지 다양하다.
알맞은 솔루션을 선택하기 위해서 이 가이드를 사용하자.
쿠버네티스를 시도해보기를 원한다면, [로컬 Docker 기반의 솔루션](#로컬-머신-솔루션)을 사용하자.
더 많은 머신과 높은 가용성으로 확장할 준비가 되었다면, [호스트 된 솔루션](#호스트-된-솔루션)이 생성하고 유지하기에 가장 쉽다.
[턴키 클라우드 솔루션](#턴키-클라우드-솔루션)은 클라우드 공급자들의 넓은 범위를 다루고 생성하기 위해서 약간의 명령어가 필요하다.
[온-프레미스 턴키 클라우드 솔루션](#온-프레미스-턴키-클라우드-솔루션)은 프라이빗 네트워크의 보안과 결합된 턴키 클라우드 솔루션의 단순함을 가진다.
호스팅한 자원을 구성하는 방법을 이미 가지고 있다면, 머신 당 단일 명령어로 클러스터를 만들어내기 위해서 [kubeadm](/docs/setup/independent/create-cluster-kubeadm/)을 사용하자.
[사용자 지정 솔루션](#사용자-지정-솔루션)은 단계별 지침부터
쿠버네티스 클러스터를 처음부터 설정하기 위한 일반적인 조언까지 다양하다.
{{% /capture %}}
{{% capture body %}}
## 로컬 머신 솔루션
### 커뮤니티 지원 도구
* [Minikube](/docs/setup/minikube/)는 개발과 테스트를 위한 단일 노드 쿠버네티스 클러스터를 로컬에 생성하기 위한 하나의 방법이다. 설치는 완전히 자동화 되어 있고, 클라우드 공급자 계정 정보가 필요하지 않다.
* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster)는 다중 노드 (minikube는 단일 노드인 반면) docker 데몬만 필요로 하는 쿠버네티스 클러스터이다. docker-in-docker 기술을 사용하여 쿠버네티스 클러스터를 생성한다.
* [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind)는 Docker 컨테이너 "노드"를 사용하여 로컬 쿠버네티스 클러스터를 실행하기 위한 도구이다. 이것은 주로 쿠버네티스 1.11+를 테스트하기 위해 설계되었다. 이를 사용하여 다중 노드 또는 다중 컨트롤 플레인 쿠버네티스 클러스터를 만들 수 있다.
### 생태계 도구
* [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local)는 LXD 컨테이너가 존재하는 로컬호스트에서 9개 인스턴스 디플로이먼트를 지원한다.
* [Docker Desktop](https://www.docker.com/products/docker-desktop)는
Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다.
수 분 내에 단일 노드 쿠버네티스 클러스터에서 컨테이너로 코딩과 배포를
시작할 수 있게 해준다.
* [Minishift](https://docs.okd.io/latest/minishift/)는 커뮤니티 버전의 쿠버네티스 엔터프라이즈 플랫폼 OpenShift를 로컬 개발과 테스트 용으로 설치한다. Windows, macOS와 리눅스를 위한 all-in-one VM (`minishift start`)과 컨테이너 기반의 `oc cluster up` (리눅스 전용)을 지원하고 [포함된 애드온](https://github.com/minishift/minishift-addons/tree/master/add-ons)을 설치할 수 있다.
* [Microk8s](https://microk8s.io/)는 개발과 테스트를 위한 쿠버네티스 최신 버전을 단일 명령어로 로컬 머신 상의 설치를 제공한다. 설치는 신속하고 빠르며(~30초) 단일 명령어로 Istio를 포함한 많은 플러그인을 지원한다.
* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private)는 개발과 테스트 시나리오를 위해 1개 또는 더 많은 VM에 쿠버네티스를 배포하기 위해서 머신의 VirtualBox를 사용할 수 있다. 이는 전체 멀티 노드 클러스터로 확장할 수 있다.
* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)는 Terraform/Packer/BASH 기반의 리눅스 호스트 상의 LXD 클러스터에 7개의 노드(부트 1개, 마스터 1개, 관리 1개, 프록시 1개 그리고 워커 3개)를 생성하기 위한 Infrastructure as Code (IaC) 스크립트이다.
* [k3s](https://k3s.io)는 경량의 생산-등급 쿠버네티스 베포판이다. 간단한 설치 과정과 40MB의 바이너리 footprint로, 로컬-머신 개발에 이상적이다.
* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/)는 로컬호스트에서 9개 인스턴스 디플로이먼트를 지원한다.
## 호스트 된 솔루션
* [AppsCode.com](https://appscode.com/products/cloud-deployment/)는 AWS와 Google Cloud Platform을 포함하여 다양한 퍼블릭 클라우드의 관리형 쿠버네티스 클러스터를 제공한다.
* [APPUiO](https://appuio.ch)는 쿠버네티스 워크로드를 지원하는 OpenShift 퍼블릭 클라우드 플랫폼을 구동한다. 게다가 APPUiO는 퍼블릭 또는 프라이빗 클라우드에서 구동 중인 프라이빗 OpenShift 클러스터 관리를 제공한다.
* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/)는 관리형 쿠버네티스 서비스를 제공한다.
* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/)는 관리형 쿠버네티스 클러스터를 제공한다.
* [Containership Kubernetes Engine (CKE)](https://containership.io/containership-platform)는 GCP, Azure, AWS, Packet과 DigitalOcean 상에서 직관적인 쿠버네티스 클러스터 프로비저닝과 관리 기능을 제공한다. 매끄러운 버전 업그레이드, 오토스케일링, 메트릭, 워크로드 생성 등을 지원한다.
* [DigitalOcean Kubernetes](https://www.digitalocean.com/products/kubernetes/) 관리형 쿠버네티스 서비스를 제공한다.
* [Giant Swarm](https://giantswarm.io/product/)은 온-프레미스 또는 퍼블릭 클라우드 데이터센터 내에서 관리형 쿠버네티스 클러스터를 제공한다.
* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)은 관리형 쿠버네티스 클러스터를 제공한다.
* [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index)는 관리형 쿠버네티스 클러스터를 제공한다. 그와 함께 격리 종류, 운영 도구, 이미지와 컨테이너 통합된 보안 통찰력, Watson, IoT, 데이터와의 통합도 제공한다.
* [Kubermatic](https://www.loodse.com)는 AWS와 Digital Ocean을 포함한 다양한 퍼블릭 클라우드뿐만 아니라 온-프레미스 상의 OpenStack 통합을 위한 관리형 쿠버네티스 클러스터를 제공하는 여러 쿠버네티스에서 쿠버네티스를 운영한다.
* [Kublr](https://kublr.com)는 AWS, Azure, GCP 및 온-프레미스에서 기업 수준의 안전하고, 확장 가능하며, 신뢰성 높은 쿠버네티스 클러스터를 제공한다. 여기에는 즉시 사용 가능한 백업 및 재해 복구, 중앙 집중식 다중 클러스터 로깅 및 모니터링, 내장 경고 서비스가 포함된다.
* [KubeSail](https://kubesail.com)는 쿠버네티스를 쉽고, 무료로 시도할 수 있는 방법이다.
* [Madcore.Ai](https://madcore.ai)는 AWS에서 쿠버네티스 인프라를 배포하기 위한 devops 중심의 CLI 도구이다. 또한 마스터, 스팟 인스턴스 그룹 노드 오토-스케일링, ingress-ssl-lego, Heapster, Grafana를 지원한다.
* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)는 다중 클러스터의 고 가용성 쿠버네티스 관리 운영 플랫폼으로, 쿠버네티스의 프로비저닝, 운영 및 라이프 사이클 관리를 단순화해준다.
* [OpenShift Dedicated](https://www.openshift.com/dedicated/)는 OpenShift의 관리형 쿠버네티스 클러스터를 제공한다.
* [OpenShift Online](https://www.openshift.com/features/)은 쿠버네티스 애플리케이션을 위해 호스트 된 무료 접근을 제공한다.
* [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm)는 컨테이너 애플리케이션을 클라우드에 배포하는 데 사용할 수 있는 완벽하게 관리되고, 확장 가능하며, 가용성이 높은 서비스이다.
* [Platform9](https://platform9.com/products/kubernetes/)는 온-프레미스 또는 모든 퍼블릭 클라우드에서 99.9% SLA를 보장하는 관리형 쿠버네티스를 제공한다.
* [Stackpoint.io](https://stackpoint.io)는 다중 퍼블릭 클라우드에서 쿠버네티스 인프라 자동화 및 관리 기능을 제공한다.
* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/)는 자체 OpenStack 퍼블릭 클라우드 상에서 서비스로써 관리형 쿠버네티스를 제공한다. 라이프사이클 관리, 관리 대시보드, 모니터링, 오토스케일링과 그 밖에 많은 기능을 포함한다.
* [VEXXHOST](https://vexxhost.com/public-cloud/container-services/kubernetes/) VEXXHOST는 VEXXHOST의 공공 클라우드에서 공인된 쿠버네티스를 제공하며, 캐나다에서 가장 큰 OpenStack 퍼블릭 클라우드이다.
* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)는 사용하기 쉽고, 기본적으로 안전하며, 비용 효율적인 SaaS 기반의 쿠버네티스 클러스터를 제공하는 VMWare 클라우드 서비스 포트폴리오의 엔터프라이즈 Kubernetes-as-a-Service 오퍼링이다.
## 턴키 클라우드 솔루션
다음 솔루션들은 클라우드 IaaS 공급자의 범위에서 몇 안 되는 명령어로 쿠버네티스 클러스터를 생성을 허용한다.
이러한 솔루션은 활발히 개발되었고 활발한 커뮤니티 지원을 한다.
* [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
* [Alibaba Cloud](/docs/setup/turnkey/alibaba-cloud/)
* [APPUiO](https://appuio.ch)
* [AWS](/docs/setup/turnkey/aws/)
* [Azure](/docs/setup/turnkey/azure/)
* [CenturyLink Cloud](/docs/setup/turnkey/clc/)
* [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](https://www.ubuntu.com/kubernetes/docs/quickstart)
* [Containership](https://containership.io/containership-platform)
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
* [Gardener](https://gardener.cloud/)
* [Giant Swarm](https://giantswarm.io)
* [Google Compute Engine (GCE)](/docs/setup/turnkey/gce/)
* [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer)
* [k3s](https://k3s.io)
* [Kontena Pharos](https://kontena.io/pharos/)
* [Kubermatic](https://www.loodse.com/product/)
* [Kublr](https://kublr.com/)
* [Madcore.Ai](https://madcore.ai/)
* [Nirmata](https://nirmata.com/)
* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)
* [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm)
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/)
* [Rancher](https://rancher.com/docs/rancher/v2.x/en/)
* [Stackpoint.io](/docs/setup/turnkey/stackpoint/)
* [Supergiant.io](https://supergiant.io/)
* [VEXXHOST](https://vexxhost.com/private-cloud/)
* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)
* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)
## 온-프레미스 턴키 클라우드 솔루션
다음 솔루션들은 몇 안 되는 명령어를 사용하여
내부의 안전한 클라우드 네트워크에서 쿠버네티스 클러스터를 생성할 수 있다.
* [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
* [APPUiO](https://appuio.ch)
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
* [Giant Swarm](https://giantswarm.io)
* [GKE On-Prem | Google Cloud](https://cloud.google.com/gke-on-prem/)
* [IBM Cloud Private](https://www.ibm.com/cloud/private)
* [k3s](https://k3s.io)
* [Kontena Pharos](https://kontena.io/pharos/)
* [Kubermatic](https://www.loodse.com)
* [Kublr](https://kublr.com/)
* [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)
* [Nirmata](https://nirmata.com/)
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com)
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/)
* [Rancher](https://rancher.com/docs/rancher/v2.x/en/)
* [SUSE CaaS Platform](https://www.suse.com/products/caas-platform)
* [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/)
* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)
## 사용자 지정 솔루션
쿠버네티스는 넓은 범위의 클라우드 공급자와 베어메탈 환경에서,
그리고 많은 기반 운영 체제에서 동작할 수 있다.
필요에 맞는 가이드를 아래에서 찾았다면, 그것을 사용하자.
### 일반
호스팅한 리소스를 구성하는 방법을 이미 알고 있다면,
[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)을 사용하면
머신당 단일 명령어로 클러스터를 가지고 올 수 있다.
### 클라우드
다음 솔루션은 위의 솔루션에서 다루지 않는 클라우드 공급자와 운영체제의 조합이다.
* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
* [Gardener](https://gardener.cloud/)
* [Kublr](https://kublr.com/)
* [Kubernetes on Ubuntu](https://www.ubuntu.com/kubernetes/docs/quickstart)
* [Kubespray](/docs/setup/custom-cloud/kubespray/)
* [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke)
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
### 온-프레미스 VM
* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (uses Ansible)
* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (uses Fedora and flannel)
* [Kubermatic](https://www.loodse.com/product/)
* [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization/)
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
* [oVirt](/docs/setup/on-premises-vm/ovirt/)
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/) works on any infrastructure: on-premises, bare metal, or private/hybrid cloud.
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
* [VMware vSphere](https://github.com/kubernetes/cloud-provider-vsphere)
* [VMware vSphere, OpenStack, or Bare Metal](https://www.ubuntu.com/kubernetes/docs/quickstart) (uses Juju, Ubuntu and flannel)
### 베어 메탈
* [Digital Rebar](/docs/setup/on-premises-metal/krib/)
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
* [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/)
* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)
* [k3s](https://k3s.io)
* [Kubermatic](https://www.loodse.com/product/)
* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
* [Kubernetes on Ubuntu](https://www.ubuntu.com/kubernetes/docs/quickstart)
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/) works on any infrastructure: on-premises, bare metal, or private/hybrid cloud.
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
### 통합
다음 솔루션들은 타사 스케줄러, 자원 관리자, 낮은 레벨의 플랫폼의 통합을 제공한다.
* [DCOS](/docs/setup/on-premises-vm/dcos/)
* Community Edition DCOS는 AWS를 사용한다.
* Enterprise Edition DCOS는 클라우드 호스팅, 온-프레미스 VM, 베어메탈을 지원한다.
## 솔루션 표
아래는 위에 리스트 된 모든 솔루션의 표이다.
IaaS 공급자 | 구성 관리 | OS | 네트워킹 | 문서 | 지원 레벨
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ----------------------------
Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial
Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial
any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))
any | any | any | any | [docs](/docs/setup/release/building-from-source/) | Community ([@erictune](https://github.com/erictune))
any | any | any | any | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/) | Commercial and Community
any | Kubermatic | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial
any | RKE | multi-support | flannel or canal | [docs](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/) | [Commercial](https://rancher.com/what-is-rancher/overview/) and [Community](https://github.com/rancher/rancher)
any | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/)
AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial
AWS | CoreOS | CoreOS | flannel | [docs](/docs/setup/turnkey/aws/) | Community
AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb))
AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb))
AWS | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Azure | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine)
Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial
Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap))
Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project
Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Bare-metal | custom | Ubuntu | flannel | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa))
DCOS | Marathon | CoreOS/Alpine | custom | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar))
Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial
Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial
GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires))
GCE | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project
Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial
IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial
IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial
IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) |
Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial
Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial
KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
lxd | Juju | Ubuntu | flannel/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai))
Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial
Oracle Cloud Infrastructure | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) | | | multi-support | [docs](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | Commercial
oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z))
Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial
Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes)
Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial
Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial
Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
VMware vSphere | any | multi-support | multi-support | [docs](https://github.com/kubernetes/cloud-provider-vsphere/tree/master/docs) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html)
VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial
VMware Enterprise PKS | BOSH | Ubuntu | VMware NSX-T/flannel | [docs](https://docs.vmware.com/en/VMware-Enterprise-PKS/) | Commercial
VMware Essential PKS | any | multi-support | multi-support | [docs](https://cloud.vmware.com/vmware-essential-PKS) | Commercial
### 열 정의
* **IaaS 공급자**는 쿠버네티스가 구동되는 가상 또는 물리적 머신(노드)를 제공하는 제품 또는 조직이다.
* **OS**는 노드의 기본 운영 체제이다.
* **구성 관리**는 노드에서 쿠버네티스를 설치하고 유지 관리하는 데 도움이 되는
구성 관리 시스템이다.
* **네트워킹**은 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)을 구현하는 것이다. 네트워크 유형이
_none_인 노드는 단일 노드 이상을 지원하지 않거나, 단일 물리 노드에서 여러 VM 노드를 지원할 수 있다.
* **지원 레벨**
* **프로젝트**: 쿠버네티스 커미터는 현재 구성을 정기적으로 사용하므로,
일반적으로 최신 쿠버네티스 릴리즈와 함께 동작한다.
* **상업용**: 자체 지원 계약을 가진 상업용 제품.
* **커뮤니티**: 커뮤니티 기여를 바탕으로 활발하게 지원. 쿠버네티스 최신 릴리즈에는 작동하지 않을 수도 있다.
* **비활성**: 현재 유지되지 않는다. 쿠버네티스 최초 사용자에게 권장하지 않으며, 삭제될 수도 있다.
* **참고**는 사용된 쿠버네티스 버전 같은 기타 관련 정보가 있다.
<!-- reference style links below here -->
<!-- GCE conformance test result -->
[1]: https://gist.github.com/erictune/4cabc010906afbcc5061
<!-- Vagrant conformance test result -->
[2]: https://gist.github.com/derekwaynecarr/505e56036cdf010bf6b6
<!-- Google Kubernetes Engine conformance test result -->
[3]: https://gist.github.com/erictune/2f39b22f72565365e59b
{{% /capture %}}

151
content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md Normal file
View File

@ -0,0 +1,151 @@
---
title: 공유 볼륨을 이용하여 동일한 파드의 컨테이너 간에 통신하기
content_template: templates/task
weight: 110
---
{{% capture overview %}}
이 페이지는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지
살펴본다.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 두 개의 컨테이너를 실행하는 파드 생성
이 실습에서 두 개의 컨테이너를 실행하는 파드를 생성한다. 이 컨테이너들은
통신에 사용할 수 있는 볼륨을 공유한다.
아래는 이 파드의 구성 파일이다.
{{< codenew file="pods/two-container-pod.yaml" >}}
이 구성 파일에는 파드가 `shared-data`로 명명한 볼륨을 가진 것을
알 수 있다.
첫 번째 컨테이너에는 nginx 웹 서버를 실행하는 구성 파일이 나열되어 있다.
공유 볼륨의 마운트 경로는 `/usr/share/nginx/html`이다.
두 번째 컨테이너는 debian 이미지 기반이고, 마운트 경로는 `/pod-data`이다.
두 번째 컨테이너는 다음 명령어를 실행한 후에 종료한다.
echo debian 컨테이너에서 안녕하세요 > /pod-data/index.html
두 번째 컨테이너는 `index.html` 파일을
nginx 웹 서버에서 호스팅하는 문서의 루트 디렉터리(`/usr/share/nginx/html/`)에 저장한다.
이제, 파드와 두 개의 컨테이너를 생성한다.
kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml
파드와 컨테이너의 정보를 확인한다.
kubectl get pod two-containers --output=yaml
출력의 일부는 다음과 같다.
apiVersion: v1
kind: Pod
metadata:
...
name: two-containers
namespace: default
...
spec:
...
containerStatuses:
- containerID: docker://c1d8abd1 ...
image: debian
...
lastState:
terminated:
...
name: debian-container
...
- containerID: docker://96c1ff2c5bb ...
image: nginx
...
name: nginx-container
...
state:
running:
...
Debian 컨테이너가 종료되었음을 알 수 있고, nginx 컨테이너는
아직 실행 중이다.
nginx 컨테이너의 쉘(shell)을 실행한다.
kubectl exec -it two-containers -c nginx-container -- /bin/bash
쉘에서 nginx 웹 서버가 실행 중인지 확인한다.
root@two-containers:/# apt-get update
root@two-containers:/# apt-get install curl procps
root@two-containers:/# ps aux
출력은 아래와 유사하다.
USER PID ... STAT START TIME COMMAND
root 1 ... Ss 21:12 0:00 nginx: master process nginx -g daemon off;
Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 디렉터리에 `index.html` 파일을 생성했었음을 상기하자.
`curl`을 이용하여 nginx 웹 서버에 HTTP GET 요청을 보낸다.
root@two-containers:/# curl localhost
출력을 보면, nginx 웹 서버에서 debian 컨테이너에서 쓰여진 웹 페이지를 제공하는 것을 알 수 있다.
debian 컨테이너에서 안녕하세요
{{% /capture %}}
{{% capture discussion %}}
## 토의
파드가 여러 컨테이너를 갖을 수 있는 우선적인 이유는 근본 애플리케이션을 보조할
도우미(helper) 애플리케이션을 제공하기 위해서이다. 도우미 애플리케이션의 일반적인 예로는
데이터를 가지고 오는 경우(data puller)나 데이터를 보내주는 경우(data pusher)이거나 프록시가 있다.
도우미와 근본 애플리케이션은 종종 서로 간에 통신을 해야 할 수 있다.
보통 이는 이번 예제에서 살펴본 것 같이, 공유 파일 시스템을 통하거나,
루프백 네트워크 인터페이스 곧 로컬 호스트(localhost)를 통해서 이뤄진다. 이 패턴의 한가지 예는
웹 서버가 도우미 프로그램과 함께 Git 저장소에서 새 업데이트를 받아오는 경우이다.
이 예제에서 볼륨은 파드의 생명 주기 동안 컨테이너를 위한 통신 방법으로 이용했다.
파드가 삭제되고 재생성되면, 공유 볼륨에 저장된 데이터는
잃어버린다.
{{% /capture %}}
{{% capture whatsnext %}}
* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여
더 공부한다.
* [모듈 구조를 위한 컴포지트 컨테이너](http://www.slideshare.net/Docker/slideshare-burns)에 관하여
공부한다.
* [저장소로 볼륨을 사용하는 파드 구성 방법](/docs/tasks/configure-pod-container/configure-volume-storage/)을
참고한다.
* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 확인한다.
* [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 확인한다.
{{% /capture %}}

13
content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md Normal file
View File

@ -0,0 +1,13 @@
---
title: 클러스터의 DNS 구성하기
weight: 120
content_template: templates/concept
---
{{% capture overview %}}
쿠버네티스는 지원하는 모든 환경에서 기본으로 활성화된 DNS 클러스터 애드온을 제공한다.
{{% /capture %}}
{{% capture body %}}
쿠버네티스 클러스터 DNS 설정에 대한 더 많은 정보를 원하면, [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 살펴본다.
{{% /capture %}}

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

@ -0,0 +1,4 @@
---
title: "쿠버네티스 오브젝트 관리"
weight: 25
---

44
content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md → content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
View File

@ -1,7 +1,7 @@
---
title: 구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리
content_template: templates/concept
weight: 40
content_template: templates/task
weight: 10
---
{{% capture overview %}}
@ -13,7 +13,15 @@ weight: 40
`apply`가 어떠한 변경사항을 이루어질지에 대한 프리뷰를 제공한다.
{{% /capture %}}
{{% capture body %}}
{{% capture prerequisites %}}
[`kubectl`](/docs/tasks/tools/install-kubectl/)를 설치한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 트레이드 오프
@ -23,17 +31,17 @@ weight: 40
* 명령형 오브젝트 구성
* 선언형 오브젝트 구성
오브젝트 관리 방식의 종류별 장단점에 대한 논의는 [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)를
오브젝트 관리 방식의 종류별 장단점에 대한 논의는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를
참고한다.
## 시작하기 전에
## 개요
선언형 오브젝트 구성은 쿠버네티스 오브젝트 정의와
구성에 대한 확실한 이해가 필요하다. 아직 그렇지 못하다면,
먼저 다음 문서를 읽고 이해한다.
- [명령형 커맨드를 사용한 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/)
- [구성 파일을 사용한 쿠버네티스 오브젝트 명령형 관리](/ko/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [명령형 커맨드를 사용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [구성 파일을 사용한 쿠버네티스 오브젝트 명령형 관리](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
다음은 이 문서에서 사용되는 용어에 대한 정의이다.
@ -130,7 +138,7 @@ spec:
# ...
```
## How to update objects
## 오브젝트 업데이트 방법
또한 오브젝트가 기존에 존재하더라도 디렉터리 내 정의된 모든 오브젝트를 업데이트하기 위해 `kubectl apply`를
사용할 수 있다. 이러한 접근방식은 다음을 수행할 수 있게 해준다.
@ -278,18 +286,18 @@ kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml
`kubectl get`을 사용하여 활성 구성을 출력한다.
```
```shell
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
```
출력은 활성 구성에 다음의 변경사항을 보여준다.
- `replicas` 필드는 `kubectl scale`에 의해 설정된 값 2를 유지한다.
* `replicas` 필드는 `kubectl scale`에 의해 설정된 값 2를 유지한다.
이는 구성 파일에서 생략되었기 때문에 가능하다.
- `image` 필드는 `nginx:1.7.9`에서 `nginx:1.11.9`로 업데이트되었다.
- `last-applied-configuration` 어노테이션은 새로운 이미지로 업데이트되었다.
- `minReadySeconds` 필드는 지워졌다.
- `last-applied-configuration` 어노테이션은 더 이상 `minReadySeconds` 필드를 포함하지 않는다.
* `image` 필드는 `nginx:1.7.9`에서 `nginx:1.11.9`로 업데이트되었다.
* `last-applied-configuration` 어노테이션은 새로운 이미지로 업데이트되었다.
* `minReadySeconds` 필드는 지워졌다.
* `last-applied-configuration` 어노테이션은 더 이상 `minReadySeconds` 필드를 포함하지 않는다.
```yaml
apiVersion: apps/v1
@ -983,8 +991,8 @@ template:
```
{{% capture whatsnext %}}
- [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/)
- [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}

25
content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md → content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
View File

@ -1,7 +1,7 @@
---
title: 명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기
content_template: templates/concept
weight: 20
content_template: templates/task
weight: 30
---
{{% capture overview %}}
@ -10,7 +10,14 @@ weight: 20
이를 사용하여 활성 오브젝트를 어떻게 관리하는 지에 대해 설명한다.
{{% /capture %}}
{{% capture body %}}
{{% capture prerequisites %}}
[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 트레이드 오프
@ -20,7 +27,7 @@ weight: 20
* 명령형 오브젝트 구성
* 선언형 오브젝트 구성
각 종류별 오브젝트 관리의 장점과 단점에 대한 논의는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/object-management-kubectl/overview/)
각 종류별 오브젝트 관리의 장점과 단점에 대한 논의는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)
를 참고한다.
## 오브젝트 생성 방법
@ -155,8 +162,8 @@ kubectl create --edit -f /tmp/srv.yaml
{{% /capture %}}
{{% capture whatsnext %}}
- [오브젝트 구성을 이용하여 쿠베네티스 관리하기(명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}

40
content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md → content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
View File

@ -1,7 +1,7 @@
---
title: 구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리
content_template: templates/concept
weight: 30
content_template: templates/task
weight: 40
---
{{% capture overview %}}
@ -10,7 +10,15 @@ weight: 30
이 문서는 구성파일을 이용하여 어떻게 오브젝트를 정의하고 관리할 수 있는지에 대해 설명한다.
{{% /capture %}}
{{% capture body %}}
{{% capture prerequisites %}}
[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 트레이드 오프
@ -29,7 +37,7 @@ weight: 30
보다 상세한 정보는 [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)를
참조한다.
- `kubectl create -f <파일명|url>`
* `kubectl create -f <파일명|url>`
## 오브젝트 업데이트 방법
@ -46,21 +54,21 @@ weight: 30
구성파일에 따라 활성 오브젝트를 업데이트하기 위해 `kubectl replace -f`
를 사용할 수 있다.
- `kubectl replace -f <파일명|url>`
* `kubectl replace -f <파일명|url>`
## 오브젝트 삭제 방법
구성파일에 정의한 오브젝트를 삭제하기 위해 `kubectl delete -f`를
사용할 수 있다.
- `kubectl delete -f <파일명|url>`
* `kubectl delete -f <파일명|url>`
## 오브젝트 삭제 방법
## 오브젝트 확인 방법
구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
명령을 사용할 수 있다.
- `kubectl get -f <파일명|url> -o yaml`
* `kubectl get -f <파일명|url> -o yaml`
`-o yaml` 플래그는 전체 오브젝트 구성이 출력되도록 정의한다. 옵션의 리스트를 확인하기
위해서는 `kubectl get -h`를 사용한다.
@ -90,7 +98,7 @@ weight: 30
구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성파일을
가르키는 튜토리얼과 작업에 특히 유용하다.
```sh
```shell
kubectl create -f <url> --edit
```
@ -100,14 +108,14 @@ kubectl create -f <url> --edit
몇 가지 수동 단계를 포함한다.
1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성파일로 내보낸다.
```sh
kubectl get <종류>/<이름> -o yaml --export > <종류>_<이름>.yaml
```shell
kubectl get <종류>/<이름> -o yaml > <종류>_<이름>.yaml
```
1. 수동으로 오브젝트 구성파일에서 상태 필드를 제거한다.
1. 이후 오브젝트 관리를 위해, `replace`만 사용한다.
```sh
```shell
kubectl replace -f <종류>_<이름>.yaml
```
@ -136,8 +144,8 @@ template:
{{% /capture %}}
{{% capture whatsnext %}}
- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/)
- [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/)
* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}

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

@ -95,7 +95,7 @@ sudo mv minikube /usr/local/bin
### 리눅스 {#linux}
{{< note >}}
이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다. 리눅스에 설치에 다른 방법은 공식 Minikube GitHub 저장소의 [다른 방법으로 설치하기](https://github.com/kubernetes/minikube#other-ways-to-install)를 참조한다.
이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다.
{{< /note >}}
정적 바이너리를 내려받아서 리눅스에 Minikube를 설치할 수 있다.

5
content/ko/docs/tutorials/clusters/_index.md Normal file
View File

@ -0,0 +1,5 @@
---
title: "클러스터"
weight: 60
---

468
content/ko/docs/tutorials/clusters/apparmor.md Normal file
View File

@ -0,0 +1,468 @@
---
reviewers:
title: AppArmor
content_template: templates/tutorial
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.4" state="beta" >}}
AppArmor는 표준 리눅스 사용자와 그룹 기반의 권한을 보완하여, 한정된 리소스 집합으로
프로그램을 제한하는 리눅스 커널 보안 모듈이다. AppArmor는 임의의 애플리케이션에 대해서
잠재적인 공격범위를 줄이고 더욱 심층적인 방어를 제공하도록 구성할 수 있다.
이 기능은 특정 프로그램이나 컨테이너에서 필요한 리눅스 기능, 네트워크 사용, 파일 권한 등에 대한
접근 허용 목록를 조정한 프로파일로 구성한다. 각 프로파일은
허용하지 않은 리소스 접근을 차단하는 *강제(enforcing)* 모드 또는
위반만을 보고하는 *불평(complain)* 모드로 실행할 수 있다.
AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한하고 또는
시스템 로그를 통해 더 나은 감사를 제공하여 더 안전한 배포를 실행할 수 있다.
그러나 AppArmor가 은탄환(언제나 통하는 무적의 방법)이 아니며,
애플리케이션 코드 취약점을 보호하기 위한 여러 조치를 할 수 있는 것 뿐임을 잊으면 안된다.
양호하고 제한적인 프로파일을 제공하고, 애플리케이션과 클러스터를 여러 측면에서 강화하는 것이 중요하다.
{{% /capture %}}
{{% capture objectives %}}
* 노드에 프로파일을 어떻게 적재 하는지 예시를 본다.
* 파드(Pod)에 프로파일을 어떻게 강제 적용하는지 배운다.
* 프로파일이 적재되었는지 확인하는 방법을 배운다.
* 프로파일을 위반하는 경우를 살펴본다.
* 프로파일을 적재할 수 없을 경우를 살펴본다.
{{% /capture %}}
{{% capture prerequisites %}}
다음을 보장해야 한다.
1. 쿠버네티스 버전은 최소 1.4 이다. -- 쿠버네티스 v1.4부터 AppArmor 지원을 추가했다.
v1.4 이전 쿠버네티스 컴포넌트는 새로운 AppArmor 어노테이션을 인식하지 못하고
제공되는 AppArmor 설정을 **조용히 무시**할 것이다. 파드에서 예상하는 보호를 받고 있는지 확인하려면
해당 노드의 Kubelet 버전을 확인하는 것이 중요하다.
```shell
$ kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}'
```
```
gke-test-default-pool-239f5d02-gyn2: v1.4.0
gke-test-default-pool-239f5d02-x1kf: v1.4.0
gke-test-default-pool-239f5d02-xwux: v1.4.0
```
2. AppArmor 커널 모듈을 사용 가능해야 한다. -- 리눅스 커널에 AppArmor 프로파일을 강제 적용하기 위해 AppArmor 커널 모듈은 반드시 설치되어 있고
사용 가능해야 한다. 예를 들어 Ubnutu 및 SUSE 같은 배포판은 모듈을 기본값으로 지원하고, 그 외 많은 다른 배포판들은 선택적으로 지원한다.
모듈이 사용 가능한지 확인하려면
`/sys/module/apparmor/parameters/enabled` 파일을 확인한다.
```shell
$ cat /sys/module/apparmor/parameters/enabled
Y
```
Kubelet(>=v1.4)이 AppArmor 기능 지원을 포함하지만 커널 모듈을 사용할 수 없으면
파드에서 AppArmor 옵션을 실행하는 것을 거부된다.
{{< note >}}
우분투에는 추가적인 훅(hook)이나 추가 기능 패치를 포함한 리눅스 커널의 상위 스트림에 머지되지 않은
많은 AppArmor 패치를 가지고 있다. 쿠버네티스는
상위 스트림 버전에서 테스트한 패치만을 가지고 있어서 다른 기능은 지원을 보장하지 않는다.
{{< /note >}}
3. 컨테이너 런타임이 도커이다. -- 이는 현재 쿠버네티스에서 지원하는 컨테이너 런타임이며 AppArmor도 지원한다.
더 많은 런타임에서 AppArmor 지원을 추가할수록 설정은 확장될 것이다.
노드가 도커로 운영되고 있는지 확인할 수 있다.
```shell
$ kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.containerRuntimeVersion}\n{end}'
```
```
gke-test-default-pool-239f5d02-gyn2: docker://1.11.2
gke-test-default-pool-239f5d02-x1kf: docker://1.11.2
gke-test-default-pool-239f5d02-xwux: docker://1.11.2
```
Kubelet(>=v1.4)은 AppArmor 지원을 포함하지만, 도커 런타임이 아니라면
파드를 AppArmor 옵션으로 실행하는 것은 거부된다.
4. 프로파일이 적재되어 있다. -- AppArmor는 각 컨테이너와 함께 실행해야 하는 AppArmor 프로파일을 지정하여 파드에 적용한다.
커널에 지정한 프로파일이 적재되지 않았다면, Kubelet(>= v1.4)은 파드를 거부한다. 해당 노드에 어떤 프로파일이 적재되었는지는
`/sys/kernel/security/apparmor/profiles` 파일을 통해 확인할 수 있다.
예를 들어,
```shell
$ ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
```
```
apparmor-test-deny-write (enforce)
apparmor-test-audit-write (enforce)
docker-default (enforce)
k8s-nginx (enforce)
```
노드에 프로파일을 적재하는 것에 대해 더 자세한 내용은
[프로파일과 함께 노드 설정하기](#setting-up-nodes-with-profiles).
AppArmor 지원이 포함된 Kubelet (>= v1.4)이면
어떤 전제 조건이 충족되지 않으면 AppArmor와 함께한 파드를 거부한다.
노드 상에 AppArmor 지원 여부는
노드 준비 조건 메시지를 확인하여(이후 릴리즈에서는 삭제될 것 같지만) 검증할 수 있다.
```shell
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
```
```
gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
```
{{% /capture %}}
{{% capture lessoncontent %}}
## 파드 보안 강화하기 {#securing-a-pod}
{{< note >}}
AppArmor는 현재 베타라서 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면,
어노테이션은 최상위 종류의 필드로 대체될 것이다(자세한 내용은
[일반 사용자 버전으로 업그레이드 방법](#upgrade-path-to-general-availability) 참고)
{{< /note >}}
AppArmor 프로파일은 *컨테이너 마다* 지정된다. 함께 실행할 파드 컨테이너에 AppArmor 프로파일을 지정하려면
파드의 메타데이터에 어노테이션을 추가한다.
```yaml
container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
```
`<container_name>`은 프로파일을 적용하는 컨테이너 이름이고, `<profile_ref>`는
적용할 프로파일을 지정한다. `profile_ref`는 다음 중에 하나이다.
* 런타임의 기본 프로파일을 적용하기 위한 `runtime/default`
* `<profile_name>`로 이름한 호스트에 적재되는 프로파일을 적용하기 위한 `localhost/<profile_name>`
* 적재할 프로파일이 없음을 나타내는 `unconfined`
어노테이션과 프로파일 이름 형식의 자세한 내용은 [API 참조](#api-reference)를 살펴본다.
쿠버네티스 AppArmor 의 작동 순서는 모든 선행 조건이 충족되었는지 확인하고,
적용을 위해 선택한 프로파일을 컨테이너 런타임으로 전달하여 이루어진다.
만약 선행 조건이 충족되지 않으면 파드는 거부되고 실행되지 않는다.
프로파일이 적용되었는지 확인하기 위해, 컨테이너 생성 이벤트에 나열된 AppArmor 보안 옵션을 찾아 볼 수 있다.
```shell
kubectl get events | grep Created
```
```
22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-minion-group-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
```
컨테이너의 루트 프로세스가 올바른 프로파일로 실행되는지는 proc attr을 확인하여 직접 검증할 수 있다.
```shell
kubectl exec <pod_name> cat /proc/1/attr/current
```
```
k8s-apparmor-example-deny-write (enforce)
```
## 예시 {#example}
*이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.*
먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 단순히
파일 쓰기를 거부할 것이다.
{{< code language="text" file="deny-write.profile" >}}
파드를 언제 스케줄할지 알지 못하므로 모든 노드에 프로파일을 적재해야 한다.
이 예시에서는 SSH를 이용하여 프로파일을 설치할 것이나 다른 방법은
[프로파일과 함께 노드 설정하기](#setting-up-nodes-with-profiles)에서 논의한다.
```shell
NODES=(
# The SSH-accessible domain names of your nodes
gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s
gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s
gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s)
for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
# Deny all file writes.
deny /** w,
}
EOF'
done
```
다음으로 쓰기 금지 프로파일된 "Hello AppArmor" 파드를 실행한다.
{{< codenew file="pods/security/hello-apparmor.yaml" >}}
```shell
kubectl create -f ./hello-apparmor.yaml
```
파드 이벤트를 살펴보면, 'k8s-apparmor-example-deny-write' AppArmor 프로파일로 생성된 파드 컨테이너를
확인할 수 있다.
```shell
kubectl get events | grep hello-apparmor
```
```
14s 14s 1 hello-apparmor Pod Normal Scheduled {default-scheduler } Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2
14s 14s 1 hello-apparmor Pod spec.containers{hello} Normal Pulling {kubelet gke-test-default-pool-239f5d02-gyn2} pulling image "busybox"
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Pulled {kubelet gke-test-default-pool-239f5d02-gyn2} Successfully pulled image "busybox"
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet gke-test-default-pool-239f5d02-gyn2} Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Started {kubelet gke-test-default-pool-239f5d02-gyn2} Started container with docker id 06b6cd1c0989
```
proc attr을 확인하여 컨테이너가 실제로 해당 프로파일로 실행 중인지 확인할 수 있다.
```shell
kubectl exec hello-apparmor cat /proc/1/attr/current
```
```
k8s-apparmor-example-deny-write (enforce)
```
마지막으로 파일 쓰기를 통해 프로파일을 위반하면 어떻게 되는지 확인할 수 있다.
```shell
kubectl exec hello-apparmor touch /tmp/test
```
```
touch: /tmp/test: Permission denied
error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1
```
이제 정리하면서, 적재되지 않은 프로파일을 지정하면 어떻게 되는지 살펴본다.
```shell
kubectl create -f /dev/stdin <<EOF
```
```yaml
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor-2
annotations:
container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write
spec:
containers:
- name: hello
image: busybox
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF
pod/hello-apparmor-2 created
```
```shell
kubectl describe pod hello-apparmor-2
```
```
Name: hello-apparmor-2
Namespace: default
Node: gke-test-default-pool-239f5d02-x1kf/
Start Time: Tue, 30 Aug 2016 17:58:56 -0700
Labels: <none>
Annotations: container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write
Status: Pending
Reason: AppArmor
Message: Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
IP:
Controllers: <none>
Containers:
hello:
Container ID:
Image: busybox
Image ID:
Port:
Command:
sh
-c
echo 'Hello AppArmor!' && sleep 1h
State: Waiting
Reason: Blocked
Ready: False
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro)
Conditions:
Type Status
Initialized True
Ready False
PodScheduled True
Volumes:
default-token-dnz7v:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-dnz7v
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
23s 23s 1 {default-scheduler } Normal Scheduled Successfully assigned hello-apparmor-2 to e2e-test-stclair-minion-group-t1f5
23s 23s 1 {kubelet e2e-test-stclair-minion-group-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
```
파드 상태는 Failed이며 오류메시지는 `Pod Cannot enforce AppArmor: profile
"k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다.
## 관리 {#administration}
### 프로파일과 함께 노드 설정하기 {#setting-up-nodes-with-profiles}
현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다.
프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다.
* 각 노드에서 파드를 실행하는 [데몬셋](/docs/concepts/workloads/controllers/daemonset/)을 통해서
올바른 프로파일이 적재되었는지 확인한다. 예시 구현은
[여기](https://git.k8s.io/kubernetes/test/images/apparmor-loader)에서 찾아 볼 수 있다.
* 노드 초기화 시간에 노드 초기화 스크립트(예를 들어 Salt, Ansible 등)나
이미지를 이용
* [예시](#example)에서 보여준 것처럼,
프로파일을 각 노드에 복사하고 SSH를 통해 적재한다.
스케줄러는 어떤 프로파일이 어떤 노드에 적재되는지 고려하지 않으니, 프로파일 전체 집합이
모든 노드에 적재되어야 한다. 대안적인 방법은
각 프로파일(혹은 프로파일의 클래스)을 위한 노드 레이블을 노드에 추가하고,
[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/)를 이용하여
파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
```
--enable-admission-plugins=PodSecurityPolicy[,others...]
```
AppArmor 옵션은 PodSecurityPolicy의 어노테이션으로 지정할 수 있다.
```yaml
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]
```
기본 프로파일 이름 옵션은 프로파일을 지정하지 않았을 때에
컨테이너에 기본으로 적용하는 프로파일을 지정한다.
허용하는 프로파일 이름 옵션은 파드 컨테이너가 함께 실행하도록 허용되는 프로파일 목록을 지정한다.
두 옵션을 모두 사용하는 경우, 기본값은 반드시 필요하다.
프로파일은 컨테이너에서 같은 형식으로 지정된다. 전체 사양은 [API 참조](#api-reference)를 찾아본다.
### AppArmor 비활성화 {#disabling-apparmor}
클러스터에서 AppArmor 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다.
```
--feature-gates=AppArmor=false
```
비활성화되면 AppArmor 프로파일을 포함한 파드는 "Forbidden" 오류로 검증 실패한다.
기본적으로 도커는 항상 비특권 파드에 "docker-default" 프로파일을 활성화하고(AppArmor 커널모듈이 활성화되었다면),
기능 게이트가 비활성화된 것처럼 진행한다.
AppArmor를 비활성화하는 이 옵션은
AppArmor가 일반 사용자 버전이 되면 제거된다.
### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}
클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다.
그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
파드의 권한을 docker-default 보다 높일 수 있다.
이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
모든 파드의 클러스터를 제거하는 것이 좋다.
### 일반 사용자 버전으로 업그레이드 방법 {#upgrade-path-to-general-availability}
AppArmor는 일반 사용자 버전(general available)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다.
모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니
전환이 필요할 때에 상세히 설명할 것이다.
최소 두번의 릴리즈에 대해서는 필드와 어노테이션 모두를 지원할 것이고,
그 이후부터는 어노테이션은 명확히 거부된다.
## 프로파일 제작 {#authoring-profiles}
AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까다로울 수 있다.
다행히 이 작업에 도움되는 도구가 있다.
* `aa-genprof`와 `aa-logprof`는 애플리케이션 활동과 로그와 수행에 필요한 행동을 모니터링하여
일반 프로파일 규칙을 생성한다. 자세한 사용방법은
[AppArmor 문서](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools)에서 제공한다.
* [bane](https://github.com/jfrazelle/bane)은 단순화된 프로파일 언어를 이용하는 도커를 위한
AppArmor 프로파일 생성기이다.
개발 장비의 도커를 통해 애플리케이션을 실행하여
프로파일을 생성하는 것을 권장하지만,
파드가 실행 중인 쿠버네티스 노드에서 도구 실행을 금하지는 않는다.
AppArmor 문제를 디버깅하기 위해서 거부된 것으로 보이는 시스템 로그를 확인할 수 있다.
AppArmor 로그는 `dmesg`에서 보여지며, 오류는 보통 시스템 로그나
`journalctl`에서 볼 수 있다. 더 많은 정보는
[AppArmor 실패](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)에서 제공한다.
## API 참조 {#api-reference}
### 파드 어노테이션 {#pod-annotation}
컨테이너를 실행할 프로파일을 지정한다.
- **키**: `container.apparmor.security.beta.kubernetes.io/<container_name>`
`<container_name>`는 파드 내에 컨테이너 이름과 일치한다.
분리된 프로파일은 파드 내에 각 컨테이너로 지정할 수 있다.
- **값**: 아래 기술된 프로파일 참조
### 프로파일 참조 {#profile-reference}
- `runtime/default`: 기본 런타임 프로파일을 참조한다.
- (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
AppArmor를 사용하는 것과 동등하다.
- 도커에서는 권한없는 컨테이너의 경우는
[`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
권한이 있는 컨테이너의 경우 unconfined(프로파일 없음)으로 해석한다.
- `localhost/<profile_name>`: 노드(localhost)에 적재된 프로파일을 이름으로 참조한다.
- 가용한 프로파일 이름의 상세 내용은
[핵심 정책 참조](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)에 설명되어 있다.
- `unconfined`: 이것은 컨테이너에서 AppArmor를 효과적으로 비활성시킨다.
다른 어떤 프로파일 참조 형식도 유효하지 않다.
### PodSecurityPolicy 어노테이션 {#podsecuritypolicy-annotations}
아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기
* **키**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
* **값**: 프로파일 참조. 위에 기술됨.
파드 컨테이너에서 지정을 허용하는 프로파일 목록 지정하기
* **키**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
* **값**: 컴마로 구분된 참조 프로파일 목록(위에 기술함)
- 비록 이스케이프된 쉼표(%2C ',')도 프로파일 이름에서 유효한 문자이지만
여기에서 명시적으로 허용하지 않는다.
{{% /capture %}}
{{% capture whatsnext %}}
참고 자료
* [퀵 가이드 AppArmor 프로파일 언어](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
* [AppArmor 코어 정책 참고](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout)
{{% /capture %}}

10
content/ko/docs/tutorials/clusters/deny-write.profile Normal file
View File

@ -0,0 +1,10 @@
#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
# 모든 파일에 저장을 금지한다.
deny /** w,
}

2
content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
View File

@ -54,7 +54,7 @@ EOF
{{< codenew file="pods/config/redis-pod.yaml" >}}
```shell
curl -OL https://k8s.io/examples/pods/config/redis-pod.yaml
curl -OL https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
cat <<EOF >>./kustomization.yaml
resources:

28
content/ko/docs/tutorials/online-training/overview.md
View File

@ -11,10 +11,16 @@ content_template: templates/concept
{{% capture body %}}
* [Certified Kubernetes Administrator 준비 과정 (Linux Academy)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course)
* [AIOps Essentials (Autoscaling Kubernetes with Prometheus Metrics) with Hands-On Labs (Linux Academy)](https://linuxacademy.com/devops/training/course/name/using-machine-learning-to-scale-kubernetes-clusters)
* [Amazon EKS Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/amazon-web-services/training/course/name/amazon-eks-deep-dive)
* [Cloud Native Certified Kubernetes Administrator (CKA) with Hands-On Labs & Practice Exams (Linux Academy)](https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
* [Certified Kubernetes Administrator Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
* [Certified Kubernetes Application Developer (CKAD) with Hands-On Labs & Practice Exams (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
* [Certified Kubernetes Application Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
* [Google Kubernetes Engine 시작하기 (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
@ -31,16 +37,32 @@ content_template: templates/concept
* [쿠버네티스 소개 (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
* [Kubernetes Essentials (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
* [Helm Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)
* [초보자를 위한 쿠버네티스 실습 랩 (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
* [Kubernetes Quick Start (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
* [쿠버네티스 심화 학습 (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
* [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
* [Kubernetes the Hard Way with Hands-On Labs (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
* [Kubernetes Security with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-security)
* [Launch Your First OpenShift Operator with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/red-hat-open-shift)
* [Learn Kubernetes by Doing - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)
* [대화식 실습 시나리오를 사용하여 쿠버네티스 배우기 (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
* [Microservice Applications in Kubernetes - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)
* [Monitoring Kubernetes With Prometheus with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
* [Service Mesh with Istio with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)
* [Prometheus로 쿠버네티스 모니터링 (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
* [쿠버네티스와 확장 가능한 마이크로서비스(Microservices) (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)

2
content/ko/docs/tutorials/stateful-application/cassandra.md
View File

@ -47,7 +47,7 @@ weight: 30
* 실행 중인 쿠버네티스 클러스터를 소유
{{< note >}}
아직 클러스터가 없다면 [시작하기](/docs/setup/pick-right-solution/)를 읽도록 하자.
아직 클러스터가 없다면 [설치](/docs/setup/)를 읽도록 하자.
{{< /note >}}
### 추가적인 Minikube 설정 요령

3
content/ko/examples/pods/config/redis-pod.yaml
View File

@ -6,6 +6,9 @@ spec:
containers:
- name: redis
image: redis:5.0.4
command:
- redis-server
- "/redis-master/redis.conf"
env:
- name: MASTER
value: "true"

13
content/ko/examples/pods/security/hello-apparmor.yaml Normal file
View File

@ -0,0 +1,13 @@
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
# 쿠버네티스에 'k8s-apparmor-example-deny-write' AppArmor 프로파일을 적용함을 알린다.
# 잊지 말 것은 쿠버네티스 노드에서 실행 중인 버전이 1.4 이상이 아닌 경우에는 이 설정은 무시된다는 것이다.
container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
containers:
- name: hello
image: busybox
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

27
content/ko/examples/pods/two-container-pod.yaml Normal file
View File

@ -0,0 +1,27 @@
apiVersion: v1
kind: Pod
metadata:
name: two-containers
spec:
restartPolicy: Never
volumes:
- name: shared-data
emptyDir: {}
containers:
- name: nginx-container
image: nginx
volumeMounts:
- name: shared-data
mountPath: /usr/share/nginx/html
- name: debian-container
image: debian
volumeMounts:
- name: shared-data
mountPath: /pod-data
command: ["/bin/sh"]
args: ["-c", "echo debian 컨테이너에서 안녕하세요 > /pod-data/index.html"]