diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md
index 038501820d94a..c2720da0863e9 100644
--- a/content/ko/docs/concepts/_index.md
+++ b/content/ko/docs/concepts/_index.md
@@ -53,7 +53,7 @@ weight: 40
클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다.
-> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 이 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
+> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 모든 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다.
### 쿠버네티스 노드
diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md
index ddc8abaad3a4b..effa7313a270a 100644
--- a/content/ko/docs/concepts/architecture/cloud-controller.md
+++ b/content/ko/docs/concepts/architecture/cloud-controller.md
@@ -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)
diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md
new file mode 100644
index 0000000000000..1d807e434bf51
--- /dev/null
+++ b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md
@@ -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 %}}
diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md
index 77aaf80acec91..ae91f70ffd39b 100755
--- a/content/ko/docs/concepts/overview/_index.md
+++ b/content/ko/docs/concepts/overview/_index.md
@@ -1,5 +1,4 @@
---
title: "개요"
weight: 20
----
-
+---
\ No newline at end of file
diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/_index.md b/content/ko/docs/concepts/overview/object-management-kubectl/_index.md
deleted file mode 100644
index d3c7c78c4e193..0000000000000
--- a/content/ko/docs/concepts/overview/object-management-kubectl/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: "kubectl을 이용한 오브젝트 관리"
-weight: 50
----
diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/overview.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md
similarity index 94%
rename from content/ko/docs/concepts/overview/object-management-kubectl/overview.md
rename to content/ko/docs/concepts/overview/working-with-objects/object-management.md
index 9fb93ffca3685..43ab232e4681f 100644
--- a/content/ko/docs/concepts/overview/object-management-kubectl/overview.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md
@@ -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" >}}/)
diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md
index 0b262c495cb86..c05c27de6142e 100644
--- a/content/ko/docs/concepts/workloads/pods/init-containers.md
+++ b/content/ko/docs/concepts/workloads/pods/init-containers.md
@@ -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`이 항상으로 설정되어 있는,
diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md
index bf0b2e47297c8..79cd31753b18c 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md
@@ -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 %}}
diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md
new file mode 100644
index 0000000000000..4c9340aa71096
--- /dev/null
+++ b/content/ko/docs/concepts/workloads/pods/pod.md
@@ -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를 통한 파드-레벨 수준의 동작 지원
+* 부트스트랩과 같이 컨트롤러의 생에와 파드의 생애 분리
+* 컨트롤러와 서비스의 분리 — 파드를 감시하는 엔드 포인트 컨트롤러
+* 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 — 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=
` 옵션을 지원한다. `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 %}}
diff --git a/content/ko/docs/reference/glossary/docker.md b/content/ko/docs/reference/glossary/docker.md
index d2b65351a4c24..64d264479dce6 100755
--- a/content/ko/docs/reference/glossary/docker.md
+++ b/content/ko/docs/reference/glossary/docker.md
@@ -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" >}} 로도 알려져 있다.
-
+
-Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, "컨테이너"가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다.
+Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다.
diff --git a/content/ko/docs/setup/certificates.md b/content/ko/docs/setup/certificates.md
index 50962fb03538f..7b9630c2820b8 100644
--- a/content/ko/docs/setup/certificates.md
+++ b/content/ko/docs/setup/certificates.md
@@ -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 |
diff --git a/content/ko/docs/setup/multiple-zones.md b/content/ko/docs/setup/multiple-zones.md
index 1ba33c20ca108..8b9804cc0e48b 100644
--- a/content/ko/docs/setup/multiple-zones.md
+++ b/content/ko/docs/setup/multiple-zones.md
@@ -187,8 +187,8 @@ Create a volume using the dynamic volume creation (only PersistentVolumes are su
```json
kubectl apply -f - <
-
-[1]: https://gist.github.com/erictune/4cabc010906afbcc5061
-
-[2]: https://gist.github.com/derekwaynecarr/505e56036cdf010bf6b6
-
-[3]: https://gist.github.com/erictune/2f39b22f72565365e59b
-
-{{% /capture %}}
diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
new file mode 100644
index 0000000000000..2cbc6f69bc2b7
--- /dev/null
+++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
@@ -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 %}}
+
+
+
diff --git a/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md
new file mode 100644
index 0000000000000..f79a417dfb92a
--- /dev/null
+++ b/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md
@@ -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 %}}
diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/_index.md b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md
new file mode 100644
index 0000000000000..3c6566741c72e
--- /dev/null
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md
@@ -0,0 +1,4 @@
+---
+title: "쿠버네티스 오브젝트 관리"
+weight: 25
+---
diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
similarity index 96%
rename from content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md
rename to content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
index 3fc67a48c380e..8c62597a891ee 100644
--- a/content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -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 %}}
diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
similarity index 91%
rename from content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md
rename to content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
index 9245e43d9350d..695ec57d095de 100644
--- a/content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -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 %}}
\ No newline at end of file
+* [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/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 %}}
diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
similarity index 83%
rename from content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md
rename to content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
index 39b4b1063f3ca..243596d0707d7 100644
--- a/content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -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 --edit
```
@@ -100,14 +108,14 @@ kubectl create -f --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 %}}
diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md
index aeeefc5fedcb2..24d22266933db 100644
--- a/content/ko/docs/tasks/tools/install-minikube.md
+++ b/content/ko/docs/tasks/tools/install-minikube.md
@@ -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를 설치할 수 있다.
diff --git a/content/ko/docs/tutorials/clusters/_index.md b/content/ko/docs/tutorials/clusters/_index.md
new file mode 100644
index 0000000000000..70df366b8622d
--- /dev/null
+++ b/content/ko/docs/tutorials/clusters/_index.md
@@ -0,0 +1,5 @@
+---
+title: "클러스터"
+weight: 60
+---
+
diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md
new file mode 100644
index 0000000000000..b370a7e613ae1
--- /dev/null
+++ b/content/ko/docs/tutorials/clusters/apparmor.md
@@ -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/:
+```
+
+``은 프로파일을 적용하는 컨테이너 이름이고, ``는
+적용할 프로파일을 지정한다. `profile_ref`는 다음 중에 하나이다.
+
+* 런타임의 기본 프로파일을 적용하기 위한 `runtime/default`
+* ``로 이름한 호스트에 적재되는 프로파일을 적용하기 위한 `localhost/`
+* 적재할 프로파일이 없음을 나타내는 `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 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 <
+
+profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
+ #include
+
+ 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 <
+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:
+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:
+ 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:
+Tolerations:
+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:
+apparmor.security.beta.kubernetes.io/allowedProfileNames: [,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/`
+ ``는 파드 내에 컨테이너 이름과 일치한다.
+ 분리된 프로파일은 파드 내에 각 컨테이너로 지정할 수 있다.
+- **값**: 아래 기술된 프로파일 참조
+
+### 프로파일 참조 {#profile-reference}
+
+- `runtime/default`: 기본 런타임 프로파일을 참조한다.
+ - (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
+ AppArmor를 사용하는 것과 동등하다.
+ - 도커에서는 권한없는 컨테이너의 경우는
+ [`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
+ 권한이 있는 컨테이너의 경우 unconfined(프로파일 없음)으로 해석한다.
+- `localhost/`: 노드(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 %}}
diff --git a/content/ko/docs/tutorials/clusters/deny-write.profile b/content/ko/docs/tutorials/clusters/deny-write.profile
new file mode 100644
index 0000000000000..af56e5cd7d67f
--- /dev/null
+++ b/content/ko/docs/tutorials/clusters/deny-write.profile
@@ -0,0 +1,10 @@
+#include
+
+profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
+ #include
+
+ file,
+
+ # 모든 파일에 저장을 금지한다.
+ deny /** w,
+}
diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
index 66dfa237d6ac5..be7cb5f61d548 100644
--- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
@@ -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 <>./kustomization.yaml
resources:
diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md
index b343988827b1d..2463c5a69d8f5 100644
--- a/content/ko/docs/tutorials/online-training/overview.md
+++ b/content/ko/docs/tutorials/online-training/overview.md
@@ -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)
diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md
index 2677499cf1759..92bcf00693682 100644
--- a/content/ko/docs/tutorials/stateful-application/cassandra.md
+++ b/content/ko/docs/tutorials/stateful-application/cassandra.md
@@ -47,7 +47,7 @@ weight: 30
* 실행 중인 쿠버네티스 클러스터를 소유
{{< note >}}
-아직 클러스터가 없다면 [시작하기](/docs/setup/pick-right-solution/)를 읽도록 하자.
+아직 클러스터가 없다면 [설치](/docs/setup/)를 읽도록 하자.
{{< /note >}}
### 추가적인 Minikube 설정 요령
diff --git a/content/ko/examples/pods/config/redis-pod.yaml b/content/ko/examples/pods/config/redis-pod.yaml
index 4fc868e6af0ca..b1714c26e5ff8 100644
--- a/content/ko/examples/pods/config/redis-pod.yaml
+++ b/content/ko/examples/pods/config/redis-pod.yaml
@@ -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"
diff --git a/content/ko/examples/pods/security/hello-apparmor.yaml b/content/ko/examples/pods/security/hello-apparmor.yaml
new file mode 100644
index 0000000000000..2aca197e76669
--- /dev/null
+++ b/content/ko/examples/pods/security/hello-apparmor.yaml
@@ -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" ]
\ No newline at end of file
diff --git a/content/ko/examples/pods/two-container-pod.yaml b/content/ko/examples/pods/two-container-pod.yaml
new file mode 100644
index 0000000000000..6ca629732576c
--- /dev/null
+++ b/content/ko/examples/pods/two-container-pod.yaml
@@ -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"]