diff --git a/content/ko/_index.html b/content/ko/_index.html index 49d18a9b4447b..06581018e830f 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -10,27 +10,27 @@ {{% blocks/feature image="flower" %}} ### [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. -It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community. +애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다. {{% /blocks/feature %}} {{% blocks/feature image="scalable" %}} #### 행성 규모 확장성 -Designed on the same principles that allows Google to run billions of containers a week, Kubernetes can scale without increasing your ops team. +Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 원칙들에 따라 디자인되었기 때문에, 쿠버네티스는 운영팀의 규모를 늘리지 않고도 확장될 수 있습니다. {{% /blocks/feature %}} {{% blocks/feature image="blocks" %}} #### 무한한 유연성 -Whether testing locally or running a global enterprise, Kubernetes flexibility grows with you to deliver your applications consistently and easily no matter how complex your need is. +지역적인 테스트든지 글로벌 기업 운영이든지 상관없이, 쿠버네티스의 유연성은 사용자의 복잡한 니즈를 모두 수용하기 때문에 사용자의 애플리케이션들을 끊임없고 쉽게 전달할 수 있습니다. {{% /blocks/feature %}} {{% blocks/feature image="suitcase" %}} #### 어디서나 동작 -Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you. +쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. {{% /blocks/feature %}} diff --git a/content/ko/docs/concepts/architecture/_index.md b/content/ko/docs/concepts/architecture/_index.md new file mode 100644 index 0000000000000..cc87b49e1f006 --- /dev/null +++ b/content/ko/docs/concepts/architecture/_index.md @@ -0,0 +1,4 @@ +--- +title: "쿠버네티스 아키텍처" +weight: 30 +--- diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000000..5df6f29396ab2 --- /dev/null +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -0,0 +1,198 @@ +--- +title: 노드 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +하나의 노드는 쿠버네티스에서 하나의 워커 머신으로, 이전에는 `미니언`으로 알려졌다. 노드는 클러스터에 따라, VM 또는 물리 머신이 될 수 있다. 각 노드는 [파드](/docs/concepts/workloads/pods/pod/)를 동작시키기 위해 필요한 서비스를 포함하며 마스터 컴포넌트에 의해 관리된다. 노드 상의 서비스는 [컨테이너 런타임](/docs/concepts/overview/components/#node-components), kubelet 그리고 kube-proxy를 포함한다. 보다 상세한 내용은 아키텍처 문서 내 [쿠버네티스 노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 섹션을 확인한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 노드 상태 + +노드의 상태는 다음의 정보를 포함한다. + +* [주소](#주소) +* [컨디션](#컨디션) +* [용량](#용량) +* [정보](#정보) + +각 섹션은 아래 상세하게 기술되었다. + +### 주소 + +이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다. + +* HostName: 노드의 커널에 의해 알려진 호스트명이다. `--hostname-override` 파라미터를 통해 치환될 수 있다. +* ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능 (클러스터 외부에서 이용 가능) 하다 . +* InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다. + + +### 컨디션 + +`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. + +| Node Condition | Description | +|----------------|-------------| +| `OutOfDisk` | 노드 상에 새로운 파드를 추가하기 위한 여유 공간이 부족할 경우 `True`, 반대의 경우 `False` | +| `Ready` | 노드가 상태 양호하며 파드를 수용할 준비가 되어 있는 경우 `True`, 노드의 상태가 불량하여 파드를 수용하지 못할 경우 `False`, 그리고 노드 컨트롤러가 마지막 `node-monitor-grace-period` (기본값 40 기간 동안 노드로부터 응답을 받지 못한 경우) `Unknown` | +| `MemoryPressure` | 노드 메모리 상에 압박이 있는 경우, 즉 노드 메모리가 넉넉치 않은 경우 `True`, 반대의 경우 `False` | +| `PIDPressure` | 프로세스 상에 압박이 있는 경우, 즉 노드 상에 많은 프로세스들이 존재하는 경우 `True`, 반대의 경우 `False` | +| `DiskPressure` | 디스크 사이즈 상에 압박이 있는 경우, 즉 디스크 용량이 넉넉치 않은 경우 `True`, 반대의 경우 `False` | +| `NetworkUnavailable` | 노드에 대해 네트워크가 올바르게 구성되지 않은 경우 `True`, 반대의 경우 `False` | + +노드 컨디션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다. + +```json +"conditions": [ + { + "type": "Ready", + "status": "True" + } +] +``` +ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controller-manager/)에 인수로 넘겨지는 `pod-eviction-timeout` 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. + +1.5 이전의 쿠버네티스 버전에서는, 노드 컨트롤러가 apiserver로부터 접근 불가한 이러한 파드를 [강제 삭제](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) +시킬 것이다. 그러나 1.5 이상에서는, 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. + +1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는 +[taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다. 마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다. 대신 노드의 taint와 toleration을 살펴본다. + +현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다. 아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의 taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다. + +{{< caution >}} +이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다. +{{< /caution >}} + +### 용량 + +노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다. + +### 정보 + +커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은 노드에 대한 일반적인 정보이다. 정보는 Kubelet에 의해 노드로부터 수집된다. + +## 관리 + +[파드](/docs/concepts/workloads/pods/pod/)와 [서비스](/docs/concepts/services-networking/service/)와 달리, 노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해 외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다. 그래서 쿠버네티스가 노드를 생성할 때, 노드를 나타내는 오브젝트를 생성한다. 생성 이후, 쿠버네티스는 노드의 유효성 여부를 검사한다. 예를 들어, 다음 내용으로 노드를 생성하려 한다면, + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +쿠버네티스는 내부적으로 (표현을) 노드 오브젝트를 생성하고, `metadata.name` 필드를 근거로 상태 체크를 수행하여 노드의 유효성을 확인한다. 노드가 유효하면, 즉 모든 필요한 서비스가 동작 중이면, 파드를 동작시킬 자격이 된다. 그렇지 않으면, 유효하게 될때까지 어떠한 클러스터 활동에 대해서도 무시된다. + +{{< note >}} +쿠버네티스는 유효하지 않은 노드로부터 오브젝트를 보호하고 유효한 상태로 이르는지 확인하기 위해 지속적으로 체크한다. 이러한 프로세스를 중지시키기 위해는 명시적으로 노드 오브젝트를 삭제해야 한다. +{{< /note >}} + +현재, 쿠버네티스 노드 인터페이스와 상호작용 하는 3개의 컴포넌트가 존재하는데, 노드 컨트롤러, kubelet, 그리고 kubectl 이다. + +### 노드 컨트롤러 + +노드 컨트롤러는 노드의 다양한 측면을 관리하는 쿠버네티스 마스터 컴포넌트다. + +노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에 (CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다. + +두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다. + +세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, 노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. (ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. + +쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가 된다. 쿠버네티스 1.13을 시작으로 node lease 기능이 알파 기능으로 (기능 게이트 `NodeLease`, +[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)) 소개되었다. node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해 갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고 NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다. NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만 (기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.) 노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다. 노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과 성능 두 가지 측면에서 노드 하트비트를 상당히 경제적이도록 해준다. + +쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에 문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) 더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로, 노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터 내 모든 노드를 살핀다. + +대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다. + +노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` 기본값 0.55) 가 되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 `--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당 `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, 오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다. + +노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 정상 비율 `--node-eviction-rate`로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 복원될 때까지 모든 축출을 중지하는 것으로 여긴다. + +쿠버네티스 1.6을 시작으로 NodeController는 파드가 taint를 허용하지 않을 때, NoExecute taint 상태의 노드 상에 동작하는 파드 축출에 대한 책임 또한 지고 있다. 추가로, 기본적으로 비활성화 된 알파 기능으로, NodeController는 노드 접근 불가 또는 준비 부족과 같은 노드 문제에 상응하는 taint 추가에 대한 책임을 진다. `NoExecute` taints와 알파 기능에 대한 보다 상세한 내용은 [이 문서](/docs/concepts/configuration/taint-and-toleration/)를 참고한다. + +1.8 버전을 시작으로, 노드 컨트롤러는 노드 상태를 나타내는 taint 생성에 대한 책임을 지도록 만들 수 있다. 이는 버전 1.8 의 알파 기능이다. + +### 노드에 대한 자체-등록 + +kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다. + +자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다. + + - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로. + - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 클라우드 제공사업자와 소통할지에 대한 방법. + - `--register-node` - 자동으로 API 서버에 등록. + - `--register-with-taints` - 주어진 taint 리스트 (콤마로 분리된 `=:`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안함. + - `--node-ip` - 노드의 IP 주소. + - `--node-labels` - 클러스터 내 노드를 등록할 경우 추가되는 레이블 (1.13+ 에서 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 강제되는 레이블 제약사항 참고). + - `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의. + +[Node authorization mode](/docs/reference/access-authn-authz/node/)와 +[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면, kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다. + +#### 수동 노드 관리 + +클러스터 관리자는 노드 오브젝트를 생성하고 수정할 수 있다. + +관리자가 수동으로 오브젝트를 생성하고자 한다면, kubelet 플래그를 `--register-node=false`로 설정한다. + +관리자는 노드 리소스를 수정할 수 있다(`--register-node`설정과 무관하게). 수정은 노드 상에 레이블 설정과 스케줄 불가 마킹을 포함한다. + +노드 상의 레이블은 스케줄링을 제어하기 위해, 즉 하나의 파드가 오직 노드의 서브셋 상에 동작할 수 있도록 제한하기 위해 노드 셀렉터와 함께 이용될 수 있다. + +노드를 스케줄 불가로 마킹하게 되면, 해당 노드에 새로운 파드가 스케줄되는 것을 막아주지만, 노드 상의 임의의 기존 파드에 대해서는 영향을 미치치 않는다. 이는 노드 리부트 전이나 기타 등의 준비 조치로 유용하다. 예를 들어, 노드를 스케줄 불가로 마크하기 위해 다음 명령을 수행한다. + +```shell +kubectl cordon $NODENAME +``` + +{{< note >}} +DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄러를 우회하고 노드 상에 스케줄 불가 속성을 고려하지 않는다. 심지어 리부트를 준비하는 동안 애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다. +{{< /note >}} + +### 노드 용량 + +노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다. 일반적으로, 노드는 스스로 등록하고 노드 오브젝트를 생성할 때 자신의 용량을 알린다. 만약 [수동 노드 관리](#manual-node-administration)를 수행 한다면, 노드를 추가할 때 노등 용량을 설정해야 한다. + +쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다. kubelet에 의해 구동된 모든 컨테이너를 포함하지만, [컨테이너 런타임](/docs/concepts/overview/components/#node-components)에 의해 직접 구동된 컨테이너 또는 컨테이너 외부에서 동작하는 임의의 프로세스는 해당되지 않는다. + +파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, 플레이스홀더 파드를 생성할 수 있다. 다음 템플릿을 이용한다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: resource-reserver +spec: + containers: + - name: sleep-forever + image: k8s.gcr.io/pause:0.8.0 + resources: + requests: + cpu: 100m + memory: 100Mi +``` + +`cpu`와 `memory`값을 확보하고자 하는 리소스의 양만큼 설정한다. 메니페스트 디렉토리 내 파일을 둔다(kubelet 의 `--config=DIR` 플래그). 리소스를 확보하고자 하는 위치에 각 kubelet 에 대해 이를 수행한다. + + +## API 오브젝트 + +노드는 쿠버네티스 REST API 내 탑-레벨 리소스 이다. API 오브젝트에 대한 보다 자세한 내용은 [노드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)에서 확인할 수 있다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md new file mode 100755 index 0000000000000..77aaf80acec91 --- /dev/null +++ b/content/ko/docs/concepts/overview/_index.md @@ -0,0 +1,5 @@ +--- +title: "개요" +weight: 20 +--- + diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 332af17e9e42b..39afd4c517be6 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -9,13 +9,13 @@ weight: 10 {{% /capture %}} {{% capture body %}} -쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, -확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 +쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, +확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. -구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 -15여년에 걸친 대규모 운영 워크로드 운영 +구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 +15여년에 걸친 대규모 운영 워크로드 운영 경험](https://research.google.com/pubs/pub43438.html)을 기반으로 만들어졌으며 커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다. @@ -28,32 +28,32 @@ weight: 10 - 이식성 있는 클라우드 플랫폼 그리고 더 많은 기능. -쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. 이 환경은 사용자 -워크로드를 위해서 컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를 -오케스트레이션한다. 이는 Platform as a Service(PaaS)의 매우 단순명료함에 -Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처 +쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. 이 환경은 사용자 +워크로드를 위해서 컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를 +오케스트레이션한다. 이는 Platform as a Service(PaaS)의 매우 단순명료함에 +Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처 제공자 간 이식이 가능하게 해준다. ## 어떻게 쿠버네티스가 플랫폼이 될 수 있는가? 쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는 새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록 -애플리케이션에 특화된 워크플로우를 최적화할 수 있다. 초기에 수용 가능한 애드혹 -오케스트레이션은 대규모의 견고한 자동화를 필요로 하곤 한다. 이것이 쿠버네티스가 -애플리케이션을 더 쉽게 배포하고, 스케일링하며, 관리하는 컴포넌트와 툴의 생태계를 +애플리케이션에 특화된 워크플로우를 최적화할 수 있다. 초기에 수용 가능한 애드혹 +오케스트레이션은 대규모의 견고한 자동화를 필요로 하곤 한다. 이것이 쿠버네티스가 +애플리케이션을 더 쉽게 배포하고, 스케일링하며, 관리하는 컴포넌트와 툴의 생태계를 만드는 플랫폼의 기능을 하도록 설계된 이유이다. [레이블](/docs/concepts/overview/working-with-objects/labels/)은 사용자가 원하는 -방식대로 자원을 정리할 수 있도록 해준다. +방식대로 자원을 정리할 수 있도록 해준다. [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)은 -자원에 사용자 정의 정보를 추가해서 사용자의 워크플로우에 활용할 수 있도록 하고 +자원에 사용자 정의 정보를 추가해서 사용자의 워크플로우에 활용할 수 있도록 하고 관리 툴이 상태를 쉽게 체크할 수 있는 방법을 제공해 준다. -추가로, [쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은 -개발자와 사용자가 공통으로 사용할 수 있는 [API](/docs/reference/using-api/api-overview/)를 -기반으로 하고 있다. 사용자는 범용의 [명령줄 도구]((/docs/user-guide/kubectl-overview/))를 -대상으로 하는 [자체 API](/docs/concepts/api-extension/custom-resources/)를 가진 -[스케줄러](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)와 +추가로, [쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은 +개발자와 사용자가 공통으로 사용할 수 있는 [API](/docs/reference/using-api/api-overview/)를 +기반으로 하고 있다. 사용자는 범용의 [명령줄 도구]((/docs/user-guide/kubectl-overview/))를 +대상으로 하는 [자체 API](/docs/concepts/api-extension/custom-resources/)를 가진 +[스케줄러](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)와 같은 사용자만의 컨트롤러를 작성할 수 있다. 이 [설계](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)를 통해 @@ -63,39 +63,39 @@ Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스 쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, -PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 +PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)하지 -않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 -개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 +않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 +개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. 쿠버네티스는 * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, - 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 + 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서 매우 잘 동작할 것이다. * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합, 지속적인 배포(Delivery, Deployment)(CI/CD) 워크플로우는 기술적인 요구사항은 물론 조직 문화와 취향에 따라 결정된다. * 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), - 캐시 또는 클러스터 스토리지 시스템(예, Ceph)와 같은 애플리케이션 레벨의 서비스를 - 제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 + 캐시 또는 클러스터 스토리지 시스템(예, Ceph)와 같은 애플리케이션 레벨의 서비스를 + 제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. -* 기본 설정 언어/시스템(예, [jsonnet](https://github.com/google/jsonnet))을 제공하거나 +* 기본 설정 언어/시스템(예, [jsonnet](https://github.com/google/jsonnet))을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. -추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템*이 아니다. 사실, -쿠버네티스는 오케스트레이션의 필요성을 없애준다. *오케스트레이션*의 -기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 -수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 -있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. -A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 +추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템* 이 아니다. 사실, +쿠버네티스는 오케스트레이션의 필요성을 없애준다. *오케스트레이션* 의 +기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 +수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 +있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. +A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. ## 왜 컨테이너인가? @@ -104,32 +104,32 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 ![Why Containers?](/images/docs/why_containers.svg) -애플리케이션을 배포하는 *구식의 방법*은 운영 체제의 패키지 관리자를 -사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은 -애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과 -호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을 -위해서 불변의 가상 머신 이미지를 만들 수도 있지만, VM은 너무 크고 +애플리케이션을 배포하는 *구식의 방법* 은 운영 체제의 패키지 관리자를 +사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은 +애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과 +호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을 +위해서 불변의 가상 머신 이미지를 만들 수도 있지만, VM은 너무 크고 이식 가능하지 않다. -*새로운 방법*은 하드웨어 가상화가 아닌 운영 체제 수준의 가상화에 기반한 +*새로운 방법* 은 하드웨어 가상화가 아닌 운영 체제 수준의 가상화에 기반한 컨테이너를 배포하는 것이다. 이 컨테이너는 서로 격리되고 호스트와도 격리된다. 컨테이너는 컨테이너 자체의 파일시스템을 갖고, 다른 컨테이너의 프로세스를 알 수 없으며, 연산에 필요한 자원을 제한할 수 있다. VM보다 빌드하기 쉬우며, 기반이 되는 인프라스트럭처와 호스트 파일시스템에서 디커플되었기(decoupled) 때문에 클라우드나 OS 배포판 간 이식성이 있다. -컨테이너는 작고 빠르기 때문에, 애플리케이션 각각을 컨테이너 이미지로 -패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록 -하면 컨테이너의 혜택을 만끽할 수 있게 된다. 불변의 컨테이너 이미지는 -배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. 왜냐하면 각각의 -애플리케이션은 애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기 -때문이고, 운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기 -때문이다. 컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발 +컨테이너는 작고 빠르기 때문에, 애플리케이션 각각을 컨테이너 이미지로 +패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록 +하면 컨테이너의 혜택을 만끽할 수 있게 된다. 불변의 컨테이너 이미지는 +배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. 왜냐하면 각각의 +애플리케이션은 애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기 +때문이고, 운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기 +때문이다. 컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발 환경부터 운영 환경까지 일관된 환경을 가져갈 수 있게 된다. 마찬가지로, 컨테이너는 VM보다 훨씬 더 투명해서 모니터링과 관리가 용이하다. -컨테이너의 프로세스 라이프사이클이 수퍼바이저 프로세스에 의해 컨테이너 -내에 감추어지지 않고, 인프라스트럭처에 의해 관리될 때 더욱 이는 -용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, 궁극적으로 +컨테이너의 프로세스 라이프사이클이 수퍼바이저 프로세스에 의해 컨테이너 +내에 감추어지지 않고, 인프라스트럭처에 의해 관리될 때 더욱 이는 +용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, 궁극적으로 컨테이너를 관리하는 것이 애플리케이션의 배포를 관리하는 것과 같아진다. 컨테이너의 혜택 요약: @@ -140,7 +140,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다. * **개발과 운영의 관심사 분리**: - 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 + 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 디커플된다. * **가시성** OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 @@ -150,11 +150,11 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 * **클라우드 및 OS 배포판 간 이식성**: Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine 및 다른 어디에서든 구동된다. * **애플리케이션 중심 관리**: - 가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의 - 논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 + 가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의 + 논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 수준이 높아진다. * **느슨하게 커플되고, 분산되고, 유연하며, 자유로운 [마이크로서비스](https://martinfowler.com/articles/microservices.html)**: - 애플리케이션은 단일 목적의 머신에서 비대한 모놀리식 스택으로 + 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다. * **자원 격리**: @@ -164,9 +164,9 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 ## 쿠버네티스(Kubernetes)의 뜻은? K8s? -**쿠버네티스**는 *키잡이*나 *파일럿*을 뜻하는 그리스어에서 유래했으며, -이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의 -어원이다. *K8s*는 "ubernete" 8 글자를 "8"로 대체한 약어이다. +**쿠버네티스**는 *키잡이* 나 *파일럿* 을 뜻하는 그리스어에서 유래했으며, +이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의 +어원이다. *K8s* 는 "ubernete" 8 글자를 "8"로 대체한 약어이다. {{% /capture %}} @@ -174,5 +174,3 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 * [시작할](/docs/setup/) 준비가 되었는가? * 보다 자세한 내용은 [쿠버네티스 문서](/ko/docs/home/)를 참조한다. {{% /capture %}} - - diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000000..45e44b5c28e83 --- /dev/null +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,30 @@ +--- +title: 이름(Name) +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +쿠버네티스 REST API의 모든 오브젝트는 이름과 UID로 명백히 식별된다. + +유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다. + +이름과 UID에 대한 정확한 구문 규칙은 [식별자 설계 문서](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)를 참고한다. + +{{% /capture %}} + + +{{% capture body %}} + +## Names + +{{< glossary_definition term_id="name" length="all" >}} + +관례에 따라, 쿠버네티스 리소스의 이름은 최대 253자까지 허용되고 소문자 알파벳과 숫자(alphanumeric), `-`, 그리고 `.`로 구성되며 특정 리소스는 보다 구체적인 제약을 갖는다. + +## UIDs + +{{< glossary_definition term_id="uid" length="all" >}} + +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000000..83d7c3ff3d6a0 --- /dev/null +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,105 @@ +--- +title: 네임스페이스 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +쿠버네티스는 동일 물리 클러스터를 기반으로 하는 복수의 가상 클러스터를 지원한다. +이들 가상 클러스터를 네임스페이스라고 한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 복수의 네임스페이스를 사용하는 경우 + +네임스페이스는 복수의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 +만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는, 네임스페이스를 고려할 +필요가 전혀 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자. + +네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만, 네임스페이스를 통틀어서 유일할 필요는 없다. + +네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다. + +다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근 +제어 정책을 갖게 된다. + +같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서 +복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를 +구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다. + +## 네임스페이스 다루기 + +네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에 +기술되어 있다. + +### 네임스페이스 조회 + +사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다. + +```shell +$ kubectl get namespaces +NAME STATUS AGE +default Active 1d +kube-system Active 1d +kube-public Active 1d +``` + +쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다. + + * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 + * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 + * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. + +### 요청에 네임스페이스 설정하기 + +임시로 네임스페이스를 요청에 설정하기 위해서는, `--namespace` 플래그를 사용한다. + +예를 들면, + +```shell +$ kubectl --namespace= run nginx --image=nginx +$ kubectl --namespace= get pods +``` + +### 선호하는 네임스페이스 설정하기 + +이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에 영구적으로 저장할 수 있다. + +```shell +$ kubectl config set-context $(kubectl config current-context) --namespace= +# 확인하기 +$ kubectl config view | grep namespace: +``` + +## 네임스페이스와 DNS + +[서비스](/docs/user-guide/services)를 생성하면, 대응되는 +[DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다. +이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데, +이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 +연결된다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 +사용하는 경우에 유용하다. 네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 +이름(FQDN)을 사용해야 한다. + +## 모든 오브젝트가 네임스페이스에 속하지는 않음 + +대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 +네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. +그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 +네임스페이스에도 속하지 않는다. + +네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는, + +```shell +# 네임스페이스에 속하는 리소스 +$ kubectl api-resources --namespaced=true + +# 네임스페이스에 속하지 않는 리소스 +$ kubectl api-resources --namespaced=false +``` + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index bdb9770e5d4ea..c704540b85ed6 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -1,4 +1,4 @@ --- title: "워크로드" -weight: 60 +weight: 50 --- diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md new file mode 100644 index 0000000000000..5ec9794c8c57a --- /dev/null +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -0,0 +1,340 @@ +--- +title: 파드 라이프사이클 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +{{< comment >}}Updated: 4/14/2015{{< /comment >}} +{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} + +이 페이지는 파드의 라이프사이클을 설명한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 파드의 단계(phase) + +파드의 `status` 필드는 `phase` 필드를 포함하는 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) 오브젝트로 정의된다. + +파드의 phase는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한 +고수준의 요약이다. Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인 +롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았다. + +파드 phase 값에서 숫자와 의미는 엄격하게 지켜진다. +여기에 문서화된 내용 이외에는, 파드와 파드에 주어진 `phase` 값에 대해서 +어떤 사항도 가정되어서는 안 된다. + +`phase`에 가능한 값은 다음과 같다. + +값 | 의미 +:-----|:----------- +`Pending` | 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다. +`Running` | 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다. +`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다. +`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. +`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다. + +## 파드의 조건(condition) + +파드는 하나의 PodStatus를 가지며, 그것은 파드가 통과했거나 통과하지 못한 조건에 대한 [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. PodCondition +배열의 각 요소는 다음 여섯 가지 필드를 가질 수 있다. + + +* `lastProbeTime` 필드는 파드의 조건이 마지막으로 조사된 시점의 타임스탬프를 제공한다. + +* `lastTransitionTime` 필드는 파드가 마지막으로 한 상태에서 다른 상태로 전환된 시점의 타임스탬프를 제공한다. + +* `message` 전환에 대한 세부 정보를 표시한, 사람이 읽을 수 있는 메시지이다. + +* `reason` 필드는 마지막으로 발생한 전환의 이유다. 이유는 유일하게, 한 단어로, 카멜 표기법(CamelCase)으로 표기된다. + +* `status` 필드는 `True`", "`False`", 그리고 "`Unknown`"으로 지정될 수 있는 문자열이다. + +* `type` 필드는 다음과 같은 가능한 값들의 문자열이다. + + * `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음. + * `Ready`: 파드는 요청들을 수행할 수 있으며 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함. + * `Initialized`: 모든 [초기화 컨테이너](/docs/concepts/workloads/pods/init-containers)가 성공적으로 시작 완료되었음. + * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서 지금 당장은 파드를 스케줄할 수 없음. + * `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임. + + + +## 컨테이너 프로브(probe) + +[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, +kubelet은 컨테이너에 의해서 구현된 +[핸들러](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)를 호출한다. +핸들러에는 다음과 같이 세 가지 타입이 있다. + +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core) + 은 컨테이너 내에서 지정된 명령어를 실행한다. + 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다. + +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core) + 은 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. + 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. + +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) + 은 지정한 포트 및 경로에서 컨테이너의 IP주소에 + 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200보다 크고 400보다 작으면 + 진단이 성공한 것으로 간주한다. + +각 probe는 다음 세 가지 결과 중 하나를 가진다. + +* Success: 컨테이너가 진단을 통과함. +* Failure: 컨테이너가 진단에 실패함. +* Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨. + +kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 종류의 프로브를 수행하고 +그에 반응할 수 있다. + +* `livenessProbe`는 컨테이너가 동작 중인지 여부를 나타낸다. 만약 + 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 + [재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가 + 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다. + +* `readinessProbe`는 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. + 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 + 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 + 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를 + 지원하지 않는다면, 기본 상태는 `Success`이다. + +### 언제 활성 또는 준비성 프로브를 사용해야 하는가? + +만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 +상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 +반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 `restartPolicy`에 +따라서 올바른 대처를 자동적으로 수행할 것이다. + +프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 +지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다. + +프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, +준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 +보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 +시작되고 프로브가 성공하기 시작한 이후에만 +트래픽을 받는다는 뜻이다. + +만약 컨테이너가 대량의 데이터, 설정 파일들, 또는 시동 중 마그레이션을 처리해야 한다면, +준비성 프로브를 지정하길 바란다. + +만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, 준비성 +프로브를 지정하길 바란다. 준비성 프로브는 활성 프로브와는 +다르게 준비성에 특정된 엔드포인트를 확인한다. + +파드가 삭제될 때 단지 요청들이 흘려 보낼(drain) 목적으로, +준비성 프로브가 필요하지는 않다는 점을 유념해야한다. 삭제 시에, 파드는 +프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다. +파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로 +남아있는다. + +활성 프로브 및 준비성 프로브를 설정하는 방법에 대한 추가적인 정보는, +[활성 프로브 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다. + +## 파드 및 컨테이너 상태 + +파드 및 컨테이너 상태에 대한 자세한 정보는, [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +및 +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참조하면 된다. +파드의 상태로서 보고되는 정보는 현재의 +[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)에 의존적이라는 점에 유의하길 바란다. + +## 파드의 준비성 게이트(readiness gate) + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +파드의 준비성에 대한 확장성을 추가하기 위해서 +추가적인 피드백이나 신호를 `PodStatus`에 주입하는 방법인, +[파드 준비++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)라는 특징이 쿠버네티스 1.11에서 소개되었다. +파드의 준비성을 평가하기 위한 추가적인 조건들을 `PodSpec` 내의 새로운 `ReadinessGate` 필드를 +통해서 지정할 수 있다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 +조건을 찾지 못한다면, 그 조건의 상태는 +기본 값인 "`False`"가 된다. 아래는 한 예제를 보여준다. + +```yaml +Kind: Pod +... +spec: + readinessGates: + - conditionType: "www.example.com/feature-1" +status: + conditions: + - type: Ready # 이것은 내장된 PodCondition이다 + status: "True" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + - type: "www.example.com/feature-1" # 추가적인 PodCondition + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + containerStatuses: + - containerID: docker://abcd... + ready: true +... +``` +파드의 새로운 조건들은 쿠버네티스의 [레이블 키 포멧](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)을 준수해야 한다. +`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에, +새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 +통한 `PATCH` 액션을 통해서 주입되어야 한다. + +새로운 파드 조건들이 적용된 경우, 파드는 **오직** +다음 두 문장이 모두 참일 때만 준비 상태로 평가된다. + +* 파드 내의 모든 컨테이너들이 준비 상태이다. +* `ReadinessGates`에 지정된 모든 조건들이 "`True`"이다. + +파드 준비성 평가에 대한 변경을 촉진하기 위해서, 이전 파드 조건인 +`Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다. + +K8s 1.11에서, 알파 특징으로서, "파드 준비++" 특징을 사용하기 +위해서는 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 `PodReadinessGates`를 참으로 설정함으로써 명시적으로 +활성화해야 한다. + +K8s 1.12에서는, 해당 특징이 기본으로 활성화되어 있다. + +## 재시작 정책 + +PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 +가지고 있다. 기본 값은 항상(Always)이다. +`restartPolicy`는 파드 내의 모든 컨테이너들에 적용된다. `restartPolicy`는 +같은 노드에 있는 kubelet에 의한 컨테이너들의 재시작에만 관련되어 있다. kubelet에 의해서 재시작되는 종료된 +컨테이너는 5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 +기준으로 재시작되며, 10분의 성공적 실행 후에 재설정된다. +[파드 문서](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)에서 의논된 바와 같이, +파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다. + +## 파드의 일생(lifetime) + +일반적으로, 파드는 누군가 파드를 파괴할 때까지 사라지지 않는다. 그것은 주로 +사람이나 컨트롤러에 의해서 일어난다. 이 법칙에 대한 유일한 예외는 +일정 기간(마스터의 `terminated-pod-gc-threshold`에 의해 결정되는) +이상 파드의 `phase`가 Succeeded 또는 Failed라서 파드가 만료되고 자동적으로 파괴되는 경우이다. + +세 가지 유형의 컨트롤러를 사용할 수 있다. + +- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 + 사용하길 바란다. 잡은 `restartPolicy`가 실패 시(OnFailure) 또는 절대 안 함(Never)으로 + 지정된 경우에 적합하다. + +- 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), + [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/), 또는 + [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다. + 레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된 + 경우에만 적합하다. + +- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)을 사용하길 + 바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다. + +세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를 +직접적으로 생성하는 것 보다는, 적절한 컨트롤러를 생성하고 컨트롤러가 파드를 +생성하도록 하는 것이 추천된다. 그 이유는 파드 +혼자서는 머신의 실패에 탄력적(resilient)이지 않지만, 컨트롤러는 탄력적이기 때문이다. + +만약 노드가 죽거나 다른 클러스터의 다른 노드들로부터 연결이 끊기면, 쿠버네티스는 +잃어버린 노드에 있는 모든 파드의 `phase`를 실패된(Failed)으로 설정하는 정책을 적용한다. + +## 예제 + +### 고급 활성 프로브 예제 + +활성 프로브는 kubelet에 의해서 실행된다. 따라서 모든 요청은 +kubelet 네트워크 네임스페이스에서 이루어진다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + test: liveness + name: liveness-http +spec: + containers: + - args: + - /server + image: k8s.gcr.io/liveness + livenessProbe: + httpGet: + # "host"가 정의되지 않은 경우, "PodIP" 가 사용될 것이다. + # host: my-host + # "scheme"이 정의되지 않은 경우, "HTTP" 스키마가 사용될 것이다. "HTTP"와 "HTTPS"만 허용된다. + # scheme: HTTPS + path: /healthz + port: 8080 + httpHeaders: + - name: X-Custom-Header + value: Awesome + initialDelaySeconds: 15 + timeoutSeconds: 1 + name: liveness +``` + +### 상태 예제 + + * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 성공으로 종료됐다. + * 완료 이벤트를 기록한다. + * 만약 `restartPolicy`가 : + * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 실패 시(OnFailure)이면: 파드의 `phase`는 Succeeded가 된다. + * 절대 안 함(Never)이면: 파드의 `phase`는 Succeeded가 된다. + + * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 실패로 종료됐다. + * 실패 이벤트를 기록한다. + * 만약 `restartPolicy`가 : + * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 절대 안 함(Never)이면: 파드의 `phase`는 Failed가 된다. + + * 파드가 동작 중이고 두 개의 컨테이너를 가지고 있다. 컨테이너 1이 실패로 종료됐다. + * 실패 이벤트를 기록한다. + * 만약 `restartPolicy`가 : + * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 절대 안 함(Never)이면: 컨테이너는 재시작되지 않고, 파드의 `phase`는 Running으로 유지된다. + * 만약 컨테이너 1이 동작 중이 아니고, 컨테이너 2가 종료됐다면 : + * 실패 이벤트를 기록한다. + * 만약 `restartPolicy`가 : + * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 절대 안 함(Never)이면: 파드의 `phase`는 Failed가 된다. + + * 파드는 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너의 메모리가 부족하다. + * 컨테이너는 실패로 종료된다. + * 메모리 부족(OOM) 이벤트를 기록한다. + * 만약 `restartPolicy`가 : + * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. + * 절대 안 함(Never)이면: 로그 실패 이벤트가 발생되고, 파드의 `phase`는 Failed가 된다. + + * 파드 동작 중에, 디스크가 죽었다. + * 모든 컨테이너들을 죽인다. + * 적절한 이벤트를 기록한다. + * 파드의 `phase`는 Failed가 된다. + * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다. + + * 파드 동작 중에, 파드가 있는 노드가 세그먼티드 아웃되었다. + * 노드 컨트롤러가 타임아웃을 기다린다. + * 노드 컨트롤러가 파드의 `phase`를 Failed로 설정한다. + * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다. + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* Hands-on 경험하기 + [컨테이너 라이프사이클 이벤트에 핸들러 부착하기](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +* Hands-on 경험하기 + [활성 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). + +* [컨테이너 라이프사이클 후크(hook)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기. + +{{% /capture %}} + + + diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 06ace4c72db7e..f71c1b920d404 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -27,7 +27,7 @@ weight: 10 * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. -[쿠버네티스 블로그](http://blog.kubernetes.io)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다. +[쿠버네티스 블로그](http://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다. * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns) @@ -60,7 +60,7 @@ weight: 10 직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 노드에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다. {{< note >}} -**참고:** 파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다. +파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다. {{< /note >}} 파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 542d38e7f3f95..2725cd32cb3fd 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -9,6 +9,7 @@ display_browse_numbers: true linkTitle: "홈" main_menu: true weight: 10 +hide_feedback: true menu: main: title: "문서" diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 899f39f4f374e..1884f2a5128d5 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -18,6 +18,7 @@ content_template: templates/concept * [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 * 쿠버네티스 API 버전 + * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) * [1.12](/docs/reference/generated/kubernetes-api/v1.12/) * [1.11](/docs/reference/generated/kubernetes-api/v1.11/) * [1.10](https://v1-10.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/) @@ -33,6 +34,8 @@ content_template: templates/concept - [Kubernetes Go client library](https://github.com/kubernetes/client-go/) - [Kubernetes Python client library](https://github.com/kubernetes-client/python) +- [Kubernetes Java client library](https://github.com/kubernetes-client/java) +- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) ## CLI 레퍼런스 diff --git a/content/ko/docs/reference/glossary/controller.md b/content/ko/docs/reference/glossary/controller.md index 5c810e2b47280..e6b6416d9b67f 100644 --- a/content/ko/docs/reference/glossary/controller.md +++ b/content/ko/docs/reference/glossary/controller.md @@ -4,16 +4,16 @@ id: controller date: 2018-04-12 full_link: /docs/admin/kube-controller-manager/ short_description: > - A control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. + API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키도록 하는 컨트롤 루프. aka: tags: - architecture - fundamental --- - A control loop that watches the shared state of the cluster through the {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} and makes changes attempting to move the current state towards the desired state. + {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키도록 하는 컨트롤 루프. -Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller. +현재 쿠버네티스에 포함된 컨트롤러의 예시로는 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스어카운트 컨트롤러가 있다. diff --git a/content/ko/docs/reference/glossary/etcd.md b/content/ko/docs/reference/glossary/etcd.md index 6e8d5186bc3a3..1727f92d2aab1 100644 --- a/content/ko/docs/reference/glossary/etcd.md +++ b/content/ko/docs/reference/glossary/etcd.md @@ -4,16 +4,16 @@ id: etcd date: 2018-04-12 full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ short_description: > - Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data. + 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소. aka: tags: - architecture - storage --- - Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data. + 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소. -Always have a backup plan for etcd's data for your Kubernetes cluster. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md). +쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다. etcd에 대해 자세히 알아보려면 [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고하라. diff --git a/content/ko/docs/reference/glossary/kube-apiserver.md b/content/ko/docs/reference/glossary/kube-apiserver.md index d6855edb385df..1bfecd1448900 100644 --- a/content/ko/docs/reference/glossary/kube-apiserver.md +++ b/content/ko/docs/reference/glossary/kube-apiserver.md @@ -4,16 +4,15 @@ id: kube-apiserver date: 2018-04-12 full_link: /docs/reference/generated/kube-apiserver/ short_description: > - Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. + 쿠버네티스 API를 노출하는 마스터 상의 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드이다. aka: tags: - architecture - fundamental --- - Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. + 쿠버네티스 API를 노출하는 마스터 상의 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드이다. -It is designed to scale horizontally -- that is, it scales by deploying more instances. See [Building High-Availability Clusters](/docs/admin/high-availability/). - +수평적 스케일(즉, 더 많은 인스턴스를 디플로이하는 스케일)을 위해 설계되었다. [고가용성 클러스터 구축하기](/docs/admin/high-availability/)를 참고하라. diff --git a/content/ko/docs/reference/glossary/kube-controller-manager.md b/content/ko/docs/reference/glossary/kube-controller-manager.md index 0b039ae536e39..eed9ec2ac9719 100644 --- a/content/ko/docs/reference/glossary/kube-controller-manager.md +++ b/content/ko/docs/reference/glossary/kube-controller-manager.md @@ -4,16 +4,16 @@ id: kube-controller-manager date: 2018-04-12 full_link: /docs/reference/generated/kube-controller-manager/ short_description: > - Component on the master that runs controllers. + 컨트롤러를 구동하는 마스터 상의 컴포넌트. aka: tags: - architecture - fundamental --- - Component on the master that runs {{< glossary_tooltip text="controllers" term_id="controller" >}}. + {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 구동하는 마스터 상의 컴포넌트. -Logically, each {{< glossary_tooltip text="controller" term_id="controller" >}} is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process. +논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다. diff --git a/content/ko/docs/reference/glossary/name.md b/content/ko/docs/reference/glossary/name.md new file mode 100755 index 0000000000000..5b43002737bde --- /dev/null +++ b/content/ko/docs/reference/glossary/name.md @@ -0,0 +1,18 @@ +--- +title: 이름(Name) +id: name +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + `/api/v1/pods/some-name`과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열. + +aka: +tags: +- fundamental +--- + `/api/v1/pods/some-name`과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열. + + + +특정 시점에 같은 종류(kind) 내에서는 한 오브젝트만이 부여된 이름을 가질 수 있다. 하지만, 오브젝트를 삭제한 경우, 새로운 오브젝트를 같은 이름으로 만들 수 있다. + diff --git a/content/ko/docs/reference/glossary/uid.md b/content/ko/docs/reference/glossary/uid.md new file mode 100755 index 0000000000000..e32c7e85e2bc9 --- /dev/null +++ b/content/ko/docs/reference/glossary/uid.md @@ -0,0 +1,18 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + 오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열. + +aka: +tags: +- fundamental +--- + 오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열. + + + +쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록 상 유사한 개체의 출현을 서로 구분하기 위함이다. + diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index f65754922c33f..21a79f6775141 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -8,84 +8,69 @@ content_template: templates/concept {{% capture overview %}} -Use this page to find the type of solution that best fits your needs. +니즈에 가장 적합한 솔루션 유형을 찾기 위해서는 이 페이지를 사용하길 바란다. -Deciding where to run Kubernetes depends on what resources you have available -and how much flexibility you need. You can run Kubernetes almost anywhere, -from your laptop to VMs on a cloud provider to a rack of bare metal servers. -You can also set up a fully-managed cluster by running a single command or craft -your own customized cluster on your bare metal servers. +쿠버네티스를 어디에서 동작시킬지 결정하는 것은 가용한 자원과 요구되는 유연성의 정도에 의존적이다. 쿠버네티스는 랩톱부터, 클라우드 프로바이더의 VM, 베어메탈(bare metal) 서버로 이루어진 랙까지 거의 모든 곳에서 동작시킬 수 있다. 또한 단 하나의 명령어 실행으로 완전-관리되는(fully-managed) 클러스터를 설치할 수도 있고, 베어메탈 서버에 자신만의 맞춤형 클러스터를 만들 수도 있다. {{% /capture %}} {{% capture body %}} -## Local-machine Solutions +## 로컬 머신(Local-machine) 솔루션 -A local-machine solution is an easy way to get started with Kubernetes. You -can create and test Kubernetes clusters without worrying about consuming cloud -resources and quotas. +로컬 머신 솔루션은 쿠버네티스를 시작하기에 쉬운 방법이다. 클라우드 자원(resource)과 한도(quota)에 대한 걱정 없이 쿠버네티스 클러스터를 생성하고 테스트할 수 있다. -You should pick a local solution if you want to: +다음과 같은 사항을 원한다면 로컬 솔루션을 선택해야 한다. -* Try or start learning about Kubernetes -* Develop and test clusters locally +* 쿠버네티스를 써 보거나 배우기 시작하려고 함 +* 내부적으로 클러스터를 개발하거나 테스트하려고 함 -Pick a [local-machine solution](/docs/setup/pick-right-solution/#local-machine-solutions). +[로컬 머신 솔루션](/docs/setup/pick-right-solution/#local-machine-solutions) 중 하나를 선택하길 바란다. -## Hosted Solutions +## 호스트 된(Hosted) 솔루션 -Hosted solutions are a convenient way to create and maintain Kubernetes clusters. They -manage and operate your clusters so you don’t have to. +호스트 된 솔루션은 쿠버네티스 클러스터를 생성하고 유지 관리하는데 편리한 방법이다. 호스트가 사용자의 클러스터를 관리하고 운영하기 때문에 사용자는 관리와 운영에서 자유롭다. -You should pick a hosted solution if you: +다음의 경우 호스트 된 솔루션이 필요하다. -* Want a fully-managed solution -* Want to focus on developing your apps or services -* Don’t have dedicated site reliability engineering (SRE) team but want high availability -* Don't have resources to host and monitor your clusters +* 완전히 관리된 솔루션을 원함 +* 사용자의 앱 또는 서비스를 개발에만 집중하고 싶음 +* 지정된 사이트 신뢰성 엔지니어링(SRE) 팀은 없지만 고가용성을 원함 +* 클러스터를 호스팅하고 모니터할 자원이 없음 -Pick a [hosted solution](/docs/setup/pick-right-solution/#hosted-solutions). +[호스트 된 솔루션](/docs/setup/pick-right-solution/#hosted-solutions) 중 하나를 선택하길 바란다. -## Turnkey – Cloud Solutions +## 턴키(Turnkey) – 클라우드 솔루션 +이와 같은 솔루션들은 쿠버네티스 클러스터를 단지 몇 가지 명령어로 생성하게 해준다. 솔루션들은 활발히 개발되며 활동적인 커뮤니티의 지원을 받는다. 또한 넓은 범위의 IaaS 클라우드 프로바이더들에 호스트 될 수 있음에도, 노력의 대가로 솔루션들은 더욱 더 큰 자유와 유연성을 제공한다. -These solutions allow you to create Kubernetes clusters with only a few commands and -are actively developed and have active community support. They can also be hosted on -a range of Cloud IaaS providers, but they offer more freedom and flexibility in -exchange for effort. +다음의 경우 턴키 클라우드 솔루션을 선택해야 한다. -You should pick a turnkey cloud solution if you: +* 호스트 된 솔루션이 허용하는 것보다는 클러스터에 대한 더 높은 제어권을 원함 +* 운영에 대한 더 큰 소유권을 가지고 싶음 -* Want more control over your clusters than the hosted solutions allow -* Want to take on more operations ownership +[턴키 클라우드 솔루션](/docs/setup/pick-right-solution/#turnkey-cloud-solutions) 중 하나를 선택하길 바란다. -Pick a [turnkey cloud solution](/docs/setup/pick-right-solution/#turnkey-cloud-solutions) +## 턴키(Turnkey) – 온-프레미스(On-Premise) 솔루션 -## Turnkey – On-Premises Solutions +이와 같은 솔루션들은 내부의, 안전한, 클라우드 네트워크에 쿠버네티스 클러스터를 단 몇 가지 명령어로 생성하게 해준다. -These solutions allow you to create Kubernetes clusters on your internal, secure, -cloud network with only a few commands. +다음의 경우 온-프레미스 턴키 솔루션을 선택해야 한다. -You should pick a on-prem turnkey cloud solution if you: +* 프라이빗 클라우드 네트워크에 클러스터를 디플로이하길 원함 +* 지정된 사이트 신뢰성 엔지니어링(SRE) 팀을 보유함 +* 클러스터를 호스팅하고 모니터할 수 있는 자원을 보유함 -* Want to deploy clusters on your private cloud network -* Have a dedicated SRE team -* Have the resources to host and monitor your clusters +[온-프레미스 턴키 클라우드 솔루션](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions) 중 하나를 선택하길 바란다. -Pick an [on-prem turnkey cloud solution](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions). +## 사용자 지정(Custom) 솔루션 -## Custom Solutions +사용자 지정 솔루션들은 클러스터에 대해서 가장 큰 자유를 제공하지만, 그 대신 높은 전문성을 필요로 한다. 이 솔루션들은 서로 다른 운영체제들에 대해서 베어메탈부터 클라우드 프로바이더들까지의 지원을 포함한다. -Custom solutions give you the most freedom over your clusters but require the -most expertise. These solutions range from bare-metal to cloud providers on -different operating systems. - -Pick a [custom solution](/docs/setup/pick-right-solution/#custom-solutions). +[사용자 지정 솔루션](/docs/setup/pick-right-solution/#custom-solutions) 중 하나를 선택하길 바란다. {{% /capture %}} {{% capture whatsnext %}} -Go to [Picking the Right Solution](/docs/setup/pick-right-solution/) for a complete -list of solutions. +완전한 솔루션 리스트를 확인하기 위해서는 [올바른 솔루션 선택하기](/docs/setup/pick-right-solution/)로 가길 바란다. {{% /capture %}} diff --git a/content/ko/docs/setup/building-from-source.md b/content/ko/docs/setup/building-from-source.md deleted file mode 100644 index 12290041c4cae..0000000000000 --- a/content/ko/docs/setup/building-from-source.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: 소스로부터 빌드 ---- - -You can either build a release from source or download a pre-built release. If you do not plan on developing Kubernetes itself, we suggest using a pre-built version of the current release, which can be found in the [Release Notes](/docs/setup/release/notes/). - -The Kubernetes source code can be downloaded from the [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repo. - -## 소스로부터 빌드 - -If you are simply building a release from source there is no need to set up a full golang environment as all building happens in a Docker container. - -Building a release is simple. - -```shell -git clone https://github.com/kubernetes/kubernetes.git -cd kubernetes -make release -``` - -For more details on the release process see the kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) directory. diff --git a/content/ko/docs/setup/cri.md b/content/ko/docs/setup/cri.md new file mode 100644 index 0000000000000..e06d0e5fdf50c --- /dev/null +++ b/content/ko/docs/setup/cri.md @@ -0,0 +1,229 @@ +--- +reviewers: +- vincepri +- bart0sh +title: CRI 설치 +content_template: templates/concept +weight: 100 +--- +{{% capture overview %}} +v1.6.0에서부터, 쿠버네티스는 CRI(컨테이너 런타임 인터페이스) 사용을 기본으로 지원한다. +이 페이지는 다양한 런타임들에 대한 설치 지침을 담고 있다. + +{{% /capture %}} + +{{% capture body %}} + +다음의 커맨드들은 사용자의 운영체제에 따라 root로서 실행하길 바란다. +각 호스트에 SSH 접속 후 `sudo -i` 실행을 통해서 root 사용자가 될 수 있을 것이다. + +## Docker + +각 머신들에 대해서, Docker를 설치한다. +버전 18.06이 추천된다. 그러나 1.11, 1.12, 1.13, 그리고 17.03도 동작하는 것으로 알려져 있다. +쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다. + +시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다. + +{{< tabs name="tab-cri-docker-installation" >}} +{{< tab name="Ubuntu 16.04" codelang="bash" >}} +# Ubuntu 저장소를 통한 Docker 설치: +apt-get update +apt-get install -y docker.io + +# 또는 Docker 저장소를 통한 Ubuntu 또는 Debian 용 Docker CE 18.06 설치: + +## 선행 조건들 설치. +apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common + +## GPG 키 다운로드. +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - + +## Docker apt 저장소 추가. +add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" + +## Docker 설치. +apt-get update && apt-get install docker-ce=18.06.0~ce~3-0~ubuntu + +# 데몬 설정. +cat > /etc/docker/daemon.json <}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} + +# CentOS/RHEL 저장소를 통한 Docker 설치: +yum install -y docker + +# 또는 Docker의 CentOS 저장소를 통한 Docker CE 18.06 설치: + +## 선행 조건들 설치. +yum install yum-utils device-mapper-persistent-data lvm2 + +## Docker 저장소 추가. +yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo + +## Docker 설치. +yum update && yum install docker-ce-18.06.1.ce + +## /etc/docker 디렉토리 생성. +mkdir /etc/docker + +# 데몬 설정. +cat > /etc/docker/daemon.json <}} +{{< /tabs >}} + +자세한 내용은 [공식 Docker 설치 가이드](https://docs.docker.com/engine/installation/) +를 참고한다. + +## CRI-O + +이 섹션은 `CRI-O`를 CRI 런타임으로 설치하는 필수적인 단계를 담고 있다. + +시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다. + +### 선행 조건 + +```shell +modprobe overlay +modprobe br_netfilter + +# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다. +cat > /etc/sysctl.d/99-kubernetes-cri.conf <}} +{{< tab name="Ubuntu 16.04" codelang="bash" >}} + +# 선행 조건 설치 +apt-get update +apt-get install software-properties-common + +add-apt-repository ppa:projectatomic/ppa +apt-get update + +# CRI-O 설치 +apt-get install cri-o-1.11 + +{{< /tab >}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} + +# 선행 조건 설치 +yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/ + +# CRI-O 설치 +yum install --nogpgcheck cri-o + +{{< /tab >}} +{{< /tabs >}} + +### CRI-O 시작 + +``` +systemctl start crio +``` + +자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started) +를 참고한다. + +## Containerd + +이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다. + +Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사용한다. + +### 선행 조건 + +```shell +modprobe overlay +modprobe br_netfilter + +# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅에서도 유지된다. +cat > /etc/sysctl.d/99-kubernetes-cri.conf <}} +{{< tab name="Ubuntu 16.04+" codelang="bash" >}} +apt-get install -y libseccomp2 +{{< /tab >}} +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +yum install -y libseccomp +{{< /tab >}} +{{< /tabs >}} + +### Containerd 설치 + +[Containerd 릴리스](https://github.com/containerd/containerd/releases)는 주기적으로 출판된다. 아래의 값들은 작성 당시에 가용한 최신 버전을 기준으로 하드코드 되었다. 새로운 버전과 해시는 [여기](https://storage.googleapis.com/cri-containerd-release)에서 참고한다. + +```shell +# 요구되는 환경 변수 export. +export CONTAINERD_VERSION="1.1.2" +export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218" + +# containerd tar 다운로드. +wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz + +# 해시 확인. +echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check - + +# 풀기. +tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz + +# containerd 시작. +systemctl start containerd +``` + +## 다른 CRI 런타임: rktlet과 frakti + +자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart) 및 [Rktlet 시작하기 가이드](https://github.com/kubernetes-incubator/rktlet/blob/master/docs/getting-started-guide.md)를 참고한다. + +{{% /capture %}} diff --git a/content/ko/docs/setup/custom-cloud/kops.md b/content/ko/docs/setup/custom-cloud/kops.md new file mode 100644 index 0000000000000..f19e0488d638c --- /dev/null +++ b/content/ko/docs/setup/custom-cloud/kops.md @@ -0,0 +1,148 @@ +--- +title: Kops로 AWS에 쿠버네티스 설치하기 +content_template: templates/concept +--- + +{{% capture overview %}} + +이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다. +[`kops`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다. + +kops는 강력한 프로비저닝 시스템인데, + +* 완전 자동화된 설치 +* DNS를 통해 클러스터들의 신원 확인 +* 자체 복구: 모든 자원이 Auto-Scaling Groups에서 실행 +* 다양한 OS 지원(Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md) 보기 +* 고가용성 지원 - [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md) 보기 +* 직접 프로비저닝 하거나 또는 할 수 있도록 terraform 매니페스트를 생성 - [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md) 보기 + +만약 클러스터를 구축하는데 있어 이런 방법이 사용자의 생각과 다르다면 일종의 블록처럼 [kubeadm](/docs/admin/kubeadm/)를 이용할 수도 있다. +kops는 kubeadmin 위에서도 잘 동작한다. + +{{% /capture %}} + +{{% capture body %}} + +## 클러스터 구축 + +### (1/5) kops 설치 + +#### 요구사항 + +kops를 이용하기 위해서는 [kubectl](/docs/tasks/tools/install-kubectl/)이 설치되어 있어야 한다. + +#### 설치 + +[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스코드로부터 빌드하는것도 역시 어렵지 않다). + +MacOS에서: + +```shell +curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64 +chmod +x kops-darwin-amd64 +mv kops-darwin-amd64 /usr/local/bin/kops +# Homebrew를 통해 설치할 수도 있다. +brew update && brew install kops +``` + +Linux에서: + +```shell +wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64 +chmod +x kops-linux-amd64 +mv kops-linux-amd64 /usr/local/bin/kops +``` + +### (2/5) 클러스터에 사용할 route53 domain 생성 +kops는 디스커버리를 위해 클러스터 내외부에서 DNS를 이용하고 이를 통해 사용자는 쿠버네티스 API서버에 도달할 수 있다. + +이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써 +사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며, IP를 기억할 필요없이 접근할 수 있다. + +그렇게 하고 있겠지만, 클러스터를 구분하기 위해 서브도메인을 활용할 수 있다. 예를 들어 `useast1.dev.example.com`을 이용한다면, API 서버 엔드포인트는 `api.useast1.dev.example.com`가 될 것이다. + +Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone은 `useast1.dev.example.com`, `dev.example.com` 그리고 `example.com` 같은 것도 될 수 있다. +kops는 이것들 모두와 잘 동작하며, 사용자는 보통 조직적인 부분을 고려해 결정한다(예를 들어, 사용자가 `dev.example.com`하위에 레코드를 생성하는것은 허용되지만, +`example.com`하위에는 그렇지 않을 수 있다). + +`dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자. +보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 +`aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다. +그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는, `dev` NS 레코드를 `example.com`에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은 도메인 등록기관을 통해서 생성해야 한다(예를 들어, `example.com`는 `example.com`를 구매한 곳에서 설정 할 수 있다). + +이 단계에서 문제가 되기 쉽다.(문제를 만드는 가장 큰 이유이다!) dig 툴을 실행해서 클러스터 설정이 정확한지 한번 더 확인 한다. + +`dig NS dev.example.com` + +당신의 hosted zone용으로 할당된 3~4개의 NS 레코드를 Route53에서 확인할 수 있어야 한다. + +### (3/5) 클러스터 상태 저장용 S3 버킷 생성 +kops는 설치 이후에도 클러스터를 관리할 수 있다. 이를 위해 사용자가 생성한 클러스터의 상태나 사용하는 키 정보들을 지속적으로 추적해야 한다. 이 정보가 S3에 저장된다. +이 버킷의 접근은 S3 권한으로 제어한다. + +다수의 클러스터는 동일한 S3 버킷을 이용할 수 있고, 사용자는 이 S3 버킷을 같은 클러스트를 운영하는 동료에게 공유할 수 있다. 하지만 이 S3 버킷에 접근 가능한 사람은 사용자의 모든 클러스터에 관리자 접근이 가능하게 되니, 운영팀 이외로 공유되지 않도록 해야 한다. + +그래서 보통 한 운영팀 당 하나의 S3 버킷을 가지도록 하기도 한다.(그리고 종종 운영팀 이름은 위에서 언급한 hosted zone과 동일하게 짓기도 한다!) + +우리 예제에서는, `dev.example.com`를 hosted zone으로 했으니 `clusters.dev.example.com`를 S3 버킷 이름으로 정하자. + +* `AWS_PROFILE`를 선언한다. (AWS CLI 동작을 위해 다른 profile을 선택해야 할 경우) + +* `aws s3 mb s3://clusters.dev.example.com`를 이용해 S3 버킷을 생성한다. + +* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다. + 이 부분을 bash profile등에 넣어두는것을 권장한다. + +### (4/5) 클러스터 설정 구성 +클러스터 설정하려면, `kops create cluster` 를 실행한다: + +`kops create cluster --zones=us-east-1c useast1.dev.example.com` + +kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ 만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 `kops update cluster` 으로 구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다. + +더 자세한 내용을 알아보기 위한 커맨드가 출력된다. + +* 클러스터 조회: `kops get cluster` +* 클러스트 수정: `kops edit cluster useast1.dev.example.com` +* 인스턴스 그룹 수정: `kops edit ig --name=useast1.dev.example.com nodes` +* 마스터 인스턴스 그룹 수정: `kops edit ig --name=useast1.dev.example.com master-us-east-1c` + +만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은 쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를 통해 만들어진다. 사용자는 여러개의 인스턴스 그룹을 관리할 수 있는데, 예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다. + + +### (5/5) AWS에 클러스터 생성 + +`kops update cluster`를 실행해 AWS에 클러스터를 생성한다. + +`kops update cluster useast1.dev.example.com --yes` + +실행은 수 초 만에 되지만, 실제로 클러스터가 준비되기 전까지 수 분이 걸릴 수 있다. +언제든 `kops update cluster`로 클러스트 설정을 변경할 수 있다. 사용자가 변경한 클러스트 설정을 그대로 반영해 줄 것이며, 필요다하면 AWS 나 쿠버네티스를 재설정 해 줄것이다. + +예를 들면, `kops edit ig nodes` 뒤에 `kops update cluster --yes`를 실행해 설정을 반영한다. 그리고 `kops rolling-update cluster`로 설정을 즉시 원복시킬 수 있다. + +`--yes`를 명시하지 않으면 `kops update cluster` 커맨드 후 어떤 설정이 변경될지가 표시된다. 운영계 클러스터 관리할 때 사용하기 좋다! + + +### 다른 애드온 탐험 +[애드온 리스트](/docs/concepts/cluster-administration/addons/) 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다. + +## 정리하기 + +* `kops delete cluster useast1.dev.example.com --yes` 로 클러스터를 삭제한다. + +## Feedback + +* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/) +* [GitHub Issues](https://github.com/kubernetes/kops/issues) + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 쿠버네티스 [개념](/docs/concepts/) 과 [`kubectl`](/docs/user-guide/kubectl-overview/)에 대해 더 알아보기. +* `kops` [고급 사용법](https://github.com/kubernetes/kops) 알아보기. +* 튜토리얼, 모범사례, 고급 설정 옵션을 위해 `kops` [문서](https://github.com/kubernetes/kops) 부분 보기. + +{{% /capture %}} diff --git a/content/ko/docs/setup/node-conformance.md b/content/ko/docs/setup/node-conformance.md index c59e89e8a759f..3af869d905e47 100644 --- a/content/ko/docs/setup/node-conformance.md +++ b/content/ko/docs/setup/node-conformance.md @@ -6,43 +6,37 @@ title: 노드 구성 검증하기 ## 노드 적합성 테스트 -*Node conformance test* is a containerized test framework that provides a system -verification and functionality test for a node. The test validates whether the -node meets the minimum requirements for Kubernetes; a node that passes the test -is qualified to join a Kubernetes cluster. +*노드 적합성 테스트* 는 노드의 시스템 검증과 기능 테스트를 제공하기 위해 컨테이너화된 테스트 프레임워크이다. +테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다. 그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참 +여할 자격이 주어진다. ## 제한 사항 -In Kubernetes version 1.5, node conformance test has the following limitations: +쿠버네티스 1.5에서는 노드 적합성 테스트가 아래의 제약이 있다. -* Node conformance test only supports Docker as the container runtime. +* 노드 적합성 테스트는 컨테이너 런타임으로 Docker만 지원한다. ## 노드 필수 구성 요소 -To run node conformance test, a node must satisfy the same prerequisites as a -standard Kubernetes node. At a minimum, the node should have the following -daemons installed: +노드 적합성 테스트를 실행하기 위해서는, 해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다. +노드는 최소한 아래 데몬들이 설치되어 있어야 한다. -* Container Runtime (Docker) +* 컨테이너 런타임 (Docker) * Kubelet ## 노드 적합성 테스트 실행 -To run the node conformance test, perform the following steps: +노드 적합성 테스트는 다음 순서로 진행된다. -1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`, -because the test framework starts a local master to test Kubelet. There are some -other Kubelet flags you may care: - * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR - to Kubelet, for example `--pod-cidr=10.180.0.0/24`. - * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should - remove the flag to run the test. +1. 테스트 프레임워크는 Kublet을 테스트하기 위해 로컬 마스터를 시작하기 때문에, Kublet이 localhost를 가르키도록 `--api-servers="http://localhost:8080"`를 사용한다. 고려해야 할 다른 Kubelet 플래그들은 다음과 같다. + * `--pod-cidr`: `kubenet`을 사용 중이라면, 임의의 CIDR을 Kubelet에 지정해주어야 한다. 예) `--pod-cidr=10.180.0.0/24`. + * `--cloud-provider`: `--cloud-provider=gce`를 사용 중이라면, 테스트 실행 시에는 제거해야 한다. -2. Run the node conformance test with command: +2. 다음 커맨드로 노드 적합성 테스트를 실행한다. ```shell -# $CONFIG_DIR is the pod manifest path of your Kubelet. -# $LOG_DIR is the test output path. +# $CONFIG_DIR는 Kublet의 파드 매니페스트 경로이다. +# $LOG_DIR는 테스트 출력 경로이다. sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ k8s.gcr.io/node-test:0.2 @@ -50,8 +44,7 @@ sudo docker run -it --rm --privileged --net=host \ ## 다른 아키텍처에서 노드 적합성 테스트 실행 -Kubernetes also provides node conformance test docker images for other -architectures: +쿠버네티스는 다른 아키텍쳐용 노드 적합성 테스트 Docker 이미지도 제공한다. Arch | Image | --------|:-----------------:| @@ -61,37 +54,31 @@ architectures: ## 선택된 테스트 실행 -To run specific tests, overwrite the environment variable `FOCUS` with the -regular expression of tests you want to run. +특정 테스트만 실행하기 위해서는 환경 변수 `FOCUS`에 테스트하고자 하는 테스트를 정규식으로 지정한다. ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e FOCUS=MirrorPod \ # Only run MirrorPod test + -e FOCUS=MirrorPod \ # MirrorPod 테스트만 실행 k8s.gcr.io/node-test:0.2 ``` -To skip specific tests, overwrite the environment variable `SKIP` with the -regular expression of tests you want to skip. +특정 테스트를 건너뛰기 위해서는, 환경 변수 `SKIP`에 건너뛰고자 하는 테스트를 정규식으로 지정한다. ```shell sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test + -e SKIP=MirrorPod \ # MirrorPod 테스트만 건너뛰고 모든 적합성 테스트를 실행한다 k8s.gcr.io/node-test:0.2 ``` -Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md). -By default, it runs all conformance tests. +노드 적합성 테스트는 [노드 e2e 테스트](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md)를 컨테이너화한 버전이다. +기본적으로, 모든 적합성 테스트를 실행한다. -Theoretically, you can run any node e2e test if you configure the container and -mount required volumes properly. But **it is strongly recommended to only run conformance -test**, because it requires much more complex configuration to run non-conformance test. +이론적으로, 컨테이너와 필요한 볼륨을 적절히 설정했다면 어떤 노드 e2e 테스트도 수행할 수 있다. +하지만, 적합성 테스트가 아닌 테스트들은 훨씬 복잡한 설정이 필요하기 때문에 **적합성 테스트만 실행하기를 강하게 추천한다.** ## 주의 사항 -* The test leaves some docker images on the node, including the node conformance - test image and images of containers used in the functionality - test. -* The test leaves dead containers on the node. These containers are created - during the functionality test. +* 테스트 후, 노드 적합성 테스트 이미지 및 기능 테스트에 사용된 이미지들을 포함하여 몇 개의 Docker 이미지들이 노드에 남는다. +* 테스트 후, 노드에 죽은 컨테이너가 남는다. 기능 테스트 도중에 생성된 컨테이너들이다. diff --git a/content/ko/docs/setup/pick-right-solution.md b/content/ko/docs/setup/pick-right-solution.md index 0ff7c2c136593..d184047eb5284 100644 --- a/content/ko/docs/setup/pick-right-solution.md +++ b/content/ko/docs/setup/pick-right-solution.md @@ -71,6 +71,10 @@ content_template: templates/concept * [Stackpoint.io](https://stackpoint.io)는 다중 퍼블릭 클라우드에서 쿠버네티스 인프라 자동화 및 관리 기능을 제공한다. +* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offers managed Kubernetes as a service powered on our OpenStack public cloud. It includes lifecycle management, administration dashboards, monitoring, autoscaling and much more. + +* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) is an enterprise Kubernetes-as-a-Service offering in the VMware Cloud Services portfolio that provides easy to use, secure by default, cost effective, SaaS-based Kubernetes clusters. + ## 턴키 클라우드 솔루션 다음 솔루션들은 클라우드 IaaS 공급자의 범위에서 몇 안 되는 명령어로 쿠버네티스 클러스터를 생성을 허용한다. 이러한 솔루션은 활발히 개발되었고 활발한 커뮤니티 지원을 한다. @@ -199,7 +203,7 @@ AWS | Juju | Ubuntu | flannel/calico/canal | [docs] Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) Oracle Cloud | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Rackspace | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes) VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb)) @@ -214,7 +218,7 @@ Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/T Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://console.bluemix.net/docs/containers/container_index.html) | Commercial Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar)) - +VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial {{< note >}} 위의 표는 버전 테스트/사용된 노드의 지원 레벨을 기준으로 정렬된다. @@ -236,7 +240,6 @@ Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/ * **비활성**: 현재 유지되지 않는다. 쿠버네티스 최초 사용자에게 권장하지 않으며, 삭제될 수도 있다. * **참고**는 사용된 쿠버네티스 버전 같은 기타 관련 정보가 있다. - [1]: https://gist.github.com/erictune/4cabc010906afbcc5061 diff --git a/content/ko/docs/setup/release/_index.md b/content/ko/docs/setup/release/_index.md new file mode 100755 index 0000000000000..9ced1d7beeffa --- /dev/null +++ b/content/ko/docs/setup/release/_index.md @@ -0,0 +1,5 @@ +--- +title: "쿠버네티스 다운로드" +weight: 20 +--- + diff --git a/content/ko/docs/setup/release/building-from-source.md b/content/ko/docs/setup/release/building-from-source.md new file mode 100644 index 0000000000000..795800182f319 --- /dev/null +++ b/content/ko/docs/setup/release/building-from-source.md @@ -0,0 +1,21 @@ +--- +title: 소스로부터 빌드 +--- + +소스로부터 빌드하거나 이미 빌드된 릴리스를 다운받을 수 있다. 쿠버네티스를 자체를 개발할 계획이 없다면, [릴리스 노트](/docs/setup/release/notes/)에 있는 현재 릴리스 빌드 버전을 사용하는 것을 추천한다. + +쿠버네티스 소스 코드는 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 리포지토리에서 다운받을 수 있다. + +## 소스로부터 빌드 + +소스 코드를 빌드만 하려면, 모든 빌드 과정이 Docker 컨테이너 안에서 실행되기 때문에 golang 환경을 구축할 필요가 없다. + +릴리스를 빌드하는 것은 간단하다. + +```shell +git clone https://github.com/kubernetes/kubernetes.git +cd kubernetes +make release +``` + +릴리스 절차에 대한 더 자세한 설명은 kubernetes/kubernetes [`빌드`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) 디렉토리를 참조한다. diff --git a/content/ko/docs/setup/scratch.md b/content/ko/docs/setup/scratch.md index 9732925d8cd9b..4067591717332 100644 --- a/content/ko/docs/setup/scratch.md +++ b/content/ko/docs/setup/scratch.md @@ -163,10 +163,8 @@ You can use a Kubernetes binary release (recommended) or build your Kubernetes b Download the [latest binary release](https://github.com/kubernetes/kubernetes/releases/latest) and unzip it. Server binary tarballs are no longer included in the Kubernetes final tarball, so you will need to locate and run -`./kubernetes/cluster/get-kube-binaries.sh` to download the client and server binaries. -Then locate `./kubernetes/server/kubernetes-server-linux-amd64.tar.gz` and unzip *that*. -Then, within the second set of unzipped files, locate `./kubernetes/server/bin`, which contains -all the necessary binaries. +`./kubernetes/cluster/get-kube-binaries.sh` to download and extract the client and server binaries. +Then locate `./kubernetes/server/bin`, which contains all the necessary binaries. #### 이미지 선택 diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index 6e9fc1b326770..1dc8e65b5bdef 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -9,79 +9,79 @@ content_template: templates/concept {{% capture overview %}} -This section of the Kubernetes documentation contains pages that -show how to do individual tasks. A task page shows how to do a -single thing, typically by giving a short sequence of steps. +쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을 +보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은 +시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다. {{% /capture %}} {{% capture body %}} -## Web UI (Dashboard) +## 웹 UI (대시보드) -Deploy and access the Dashboard web user interface to help you manage and monitor containerized applications in a Kubernetes cluster. +쿠버네티스 클러스터에서 컨테이너화 된 애플리케이션을 관리 및 모니터하는 것을 돕기 위해서 대시보드 웹 유저 인터페이스를 디플로이하고 접속한다. -## Using the kubectl Command-line +## kubectl 명령줄 사용하기 -Install and setup the `kubectl` command-line tool used to directly manage Kubernetes clusters. +쿠버네티스 클러스터를 직접 관리하기 위해서 사용되는 `kubectl` 명령줄 도구를 설치 및 설정한다. -## Configuring Pods and Containers +## 파드 및 컨테이너 구성하기 -Perform common configuration tasks for Pods and Containers. +파드 및 컨테이너에 대한 일반적인 구성 태스크를 수행한다. -## Running Applications +## 애플리케이션 동작시키기 -Perform common application management tasks, such as rolling updates, injecting information into pods, and horizontal Pod autoscaling. +롤링 업데이트, 파드에 정보 주입하기, 파드 수평적 오토스케일링 등, 일반적인 애플리케이션 관리 태스크를 수행한다. -## Running Jobs +## 잡 동작시키기 -Run Jobs using parallel processing. +병렬 프로세싱을 사용하는 잡을 동작시킨다. -## Accessing Applications in a Cluster +## 클러스터의 애플리케이션에 접근하기 -Configure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster. +클러스터 내에 있는 애플리케이션에 접근할 수 있도록 로드 밸런싱, 포트 포워딩, 방화벽 또는 DNS 구성 등을 구성한다. -## Monitoring, Logging, and Debugging +## 모니터링, 로깅, 디버깅 -Setup monitoring and logging to troubleshoot a cluster or debug a containerized application. +클러스터 문제를 해결하거나 컨테이너화 된 애플리케이션을 디버깅하기 위해서 모니터링과 로깅을 설정한다. -## Accessing the Kubernetes API +## 쿠버네티스 API에 접근하기 -Learn various methods to directly access the Kubernetes API. +쿠버네티스 API에 직접 접근하는 다양한 방법을 배운다. -## Using TLS +## TLS 사용하기 -Configure your application to trust and use the cluster root Certificate Authority (CA). +클러스터 루트 인증 기관(CA)을 신뢰 및 사용하도록 애플리케이션을 구성한다. -## Administering a Cluster +## 클러스터 운영하기(administering) -Learn common tasks for administering a cluster. +클러스터를 운영하기 위한 일반적인 태스크를 배운다. -## Administering Federation +## 페더레이션(federation) 운영하기(administering) -Configure components in a cluster federation. +클러스터 페더레이션의 컴포넌트들을 구성한다. -## Managing Stateful Applications +## 스테이트풀 애플리케이션 관리하기 -Perform common tasks for managing Stateful applications, including scaling, deleting, and debugging StatefulSets. +스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. -## Cluster Daemons +## 클러스터 데몬 -Perform common tasks for managing a DaemonSet, such as performing a rolling update. +롤링 업데이트를 수행과 같은, 데몬 셋 관리를 위한 일반적인 태스크를 수행한다. -## Managing GPUs +## GPU 관리하기 -Configure and schedule NVIDIA GPUs for use as a resource by nodes in a cluster. +클러스터의 노드들에 의해서 리소스로 사용될 NVIDIA GPU들을 구성 및 스케줄한다. -## Managing HugePages +## HugePage 관리하기 -Configure and schedule huge pages as a schedulable resource in a cluster. +클러스터에서 스케줄 가능한 리소스로서 Huge Page들을 구성 및 스케줄한다. {{% /capture %}} {{% capture whatsnext %}} -If you would like to write a task page, see -[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/). +만약 태스크 페이지를 작성하고 싶다면, +[문서 풀 리퀘스트(Pull Request) 생성하기](/docs/home/contribute/create-pull-request/)를 참조한다. {{% /capture %}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index b52ca2dac59fa..c402d2740d302 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -17,7 +17,7 @@ Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플 {{% capture prerequisites %}} 이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. 이는 Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. ([GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다.) +[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, 버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. 마지막으로, 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우 버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다. 자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)를 참고하길 바란다. @@ -60,7 +60,7 @@ deployment.apps/php-apache created ## Horizontal Pod Autoscaler 생성 이제 서비스가 동작중이므로, [kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_autoscale.md)를 사용하여 오토스케일러를 생성한다. 다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다. -간략히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. ([kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)으로 각 파드는 200 밀리코어까지 요청할 수 있고, 따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.) 이에 대한 자세한 알고리즘은 [여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)를 참고하기 바란다. +간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. ([kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)으로 각 파드는 200 밀리코어까지 요청할 수 있고, 따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.) 이에 대한 자세한 알고리즘은 [여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)를 참고하기 바란다. ```shell $ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 @@ -107,7 +107,9 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE php-apache 7 7 7 7 19m ``` -**참고** 때로는 레플리카의 개수를 안정화시키는데 몇 분이 걸릴 수 있다. 부하의 양은 환경에 따라 다르기 때문에, 최종 레플리카의 개수는 본 예제와 다를 수 있다. +{{< note >}} +레플리카의 개수를 안정화시키는데 몇 분이 걸릴 수 있다. 부하의 양은 환경에 따라 다르기 때문에, 최종 레플리카의 개수는 본 예제와 다를 수 있다. +{{< /note >}} ## 부하 중지 @@ -127,7 +129,7 @@ php-apache 1 1 1 1 27m CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮췄다. {{< note >}} -**참고** 레플리카 오토스케일링은 몇 분 정도 소요된다. +레플리카 오토스케일링은 몇 분 정도 소요된다. {{< /note >}} {{% /capture %}} @@ -144,7 +146,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 $ kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml ``` -에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML이 보일 것입니다. +에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다. ```yaml apiVersion: autoscaling/v2beta2 @@ -203,7 +205,7 @@ pods: averageValue: 1k ``` -두 번째 대체 메트릭 타입은 *오브젝트 메트릭*이다. 이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다. 이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다. 오브젝트 메트릭은 `Value`과 `AverageValue`의 `target` 타입을 지원한다. `Value`를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다. `AverageValue`를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다. 다음은 `requests-per-second` 메트릭을 YAML로 기술한 예제이다. +두 번째 대체 메트릭 타입은 *오브젝트 메트릭* 이다. 이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다. 이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다. 오브젝트 메트릭은 `Value`과 `AverageValue`의 `target` 타입을 지원한다. `Value`를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다. `AverageValue`를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다. 다음은 `requests-per-second` 메트릭을 YAML로 기술한 예제이다. ```yaml type: Object @@ -301,7 +303,7 @@ object: ### 쿠버네티스 오브젝트와 관련이 없는 메트릭을 기초로한 오토스케일링 -쿠버네티스 위에서 동작하는 애플리케이션은 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여 오토스케일링을 할 수도 있다. 예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다. 쿠버네티스 버전 1.10 포함 이후 버전에서, *외부 메트릭*을 사용하여 이러한 유스케이스를 해결할 수 있다. +쿠버네티스 위에서 동작하는 애플리케이션은 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여 오토스케일링을 할 수도 있다. 예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다. 쿠버네티스 버전 1.10 포함 이후 버전에서, *외부 메트릭* 을 사용하여 이러한 유스케이스를 해결할 수 있다. 외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다. 이 설치는 사용자 정의 메트릭과 유사하다. 외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다. diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md new file mode 100755 index 0000000000000..799bc028f6231 --- /dev/null +++ b/content/ko/docs/tasks/tools/_index.md @@ -0,0 +1,5 @@ +--- +title: "도구 설치" +weight: 10 +--- + diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md new file mode 100644 index 0000000000000..ecfa9464af88a --- /dev/null +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -0,0 +1,55 @@ +--- +title: Minikube 설치 +content_template: templates/task +weight: 20 +--- + +{{% capture overview %}} + +이 페이지는 Minikube 설치 방법을 보여준다. + +{{% /capture %}} + +{{% capture prerequisites %}} + +컴퓨터의 바이오스에서 VT-x 또는 AMD-v 가상화가 필수적으로 활성화되어 있어야 한다. + +{{% /capture %}} + +{{% capture steps %}} + +## 하이퍼바이저 설치 + +하이퍼바이저가 설치되어 있지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다. + +* macOS: [VirtualBox](https://www.virtualbox.org/wiki/Downloads), +[VMware Fusion](https://www.vmware.com/products/fusion), 또는 +[HyperKit](https://github.com/moby/hyperkit). + +* Linux: [VirtualBox](https://www.virtualbox.org/wiki/Downloads) 또는 +[KVM](http://www.linux-kvm.org/). + + {{< note >}} + Minikube는 쿠버네티스 컴포넌트들이 VM 안에서가 아닌 호스트에서도 동작하도록 `-\-vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 Docker와 linux 환경을 필요로한다. + {{< /note >}} + +* Windows: [VirtualBox](https://www.virtualbox.org/wiki/Downloads) 또는 +[Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install). + +## kubectl 설치 + +* [kubectl 설치 및 설정](/docs/tasks/tools/install-kubectl/)의 지침에 따라 kubectl을 설치한다. + +## Minikube 설치 + +* [최신 릴리스](https://github.com/kubernetes/minikube/releases)의 지침에 따라 Minikube를 설치한다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [Minikube를 통해서 로컬에서 쿠버네티스 운영하기](/docs/getting-started-guides/minikube/) + +{{% /capture %}} + + diff --git a/content/ko/docs/templates/feature-state-beta.txt b/content/ko/docs/templates/feature-state-beta.txt new file mode 100644 index 0000000000000..25bd7ca72935e --- /dev/null +++ b/content/ko/docs/templates/feature-state-beta.txt @@ -0,0 +1,8 @@ +This feature is currently in a *beta* state, meaning: + +* The version names contain beta (e.g. v2beta3). +* Code is well tested. Enabling the feature is considered safe. Enabled by default. +* Support for the overall feature will not be dropped, though details may change. +* The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature. +* Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction. +* **Please do try our beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.** diff --git a/content/ko/docs/templates/index.md b/content/ko/docs/templates/index.md new file mode 100644 index 0000000000000..9d7bccd143f5f --- /dev/null +++ b/content/ko/docs/templates/index.md @@ -0,0 +1,13 @@ +--- +headless: true + +resources: +- src: "*alpha*" + title: "alpha" +- src: "*beta*" + title: "beta" +- src: "*deprecated*" + title: "deprecated" +- src: "*stable*" + title: "stable" +--- diff --git a/content/ko/docs/tutorials/configuration/_index.md b/content/ko/docs/tutorials/configuration/_index.md new file mode 100755 index 0000000000000..095b811cbd1f7 --- /dev/null +++ b/content/ko/docs/tutorials/configuration/_index.md @@ -0,0 +1,5 @@ +--- +title: "설정" +weight: 30 +--- + diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md new file mode 100644 index 0000000000000..1e630cd8d2089 --- /dev/null +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -0,0 +1,105 @@ +--- +title: 컨피그 맵을 사용해서 Redis 설정하기 +content_template: templates/tutorial +--- + +{{% capture overview %}} + +이 페이지에서는 컨피그 맵을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다. + +{{% /capture %}} + +{{% capture objectives %}} + +* 컨피그 맵을 생성한다. +* 컨피그 맵을 사용해서 파드 명세를 생성한다. +* 파드를 생성한다. +* 설정이 올바르게 적용되었는지 검증한다. + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다. + +{{% /capture %}} + +{{% capture lessoncontent %}} + + +## 실세상 예제: 컨피그 맵을 사용해서 Redis 설정하기 + +아래의 단계를 통해서 컨피그 맵에 저장된 데이터를 사용해서 Redis 캐시를 설정할 수 있다. + +첫째, `redis-config` 파일에서 컨피그 맵을 생성한다. + +{{< codenew file="pods/config/redis-config" >}} + +```shell +curl -OL https://k8s.io/examples/pods/config/redis-config +kubectl create configmap example-redis-config --from-file=redis-config +``` + +```shell +configmap/example-redis-config created +``` + +생성된 컨피그 맵을 점검한다. + +```shell +kubectl get configmap example-redis-config -o yaml +``` + +```yaml +apiVersion: v1 +data: + redis-config: | + maxmemory 2mb + maxmemory-policy allkeys-lru +kind: ConfigMap +metadata: + creationTimestamp: 2016-03-30T18:14:41Z + name: example-redis-config + namespace: default + resourceVersion: "24686" + selfLink: /api/v1/namespaces/default/configmaps/example-redis-config + uid: 460a2b6e-f6a3-11e5-8ae5-42010af00002 +``` + +이제, 컨피그 맵에 저장된 설정 데이터를 사용하는 파드 명세를 생성한다. + +{{< codenew file="pods/config/redis-pod.yaml" >}} + +파드를 생성한다. + +```shell +kubectl create -f https://k8s.io/examples/pods/config/redis-pod.yaml +``` + +이 예제에서는 설정 볼륨이 `/redis-master`에 마운트되어 있다. +`redis-config` 키를 `redis.conf`라는 이름의 파일에 추가하기 위해 `path`를 사용한다. +따라서, Redis 설정을 위한 파일 경로는 `/redis-master/redis.conf`이다. +이곳이 이미지가 Redis 마스터를 위한 설정 파일을 찾는 곳이다. + +설정이 올바르게 적용되었는지 확인하기 위해서, `kubectl exec`를 사용해 파드 속에서 `redis-cli` 툴을 실행해 본다. + +```shell +kubectl exec -it redis redis-cli +127.0.0.1:6379> CONFIG GET maxmemory +1) "maxmemory" +2) "2097152" +127.0.0.1:6379> CONFIG GET maxmemory-policy +1) "maxmemory-policy" +2) "allkeys-lru" +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [컨피그 맵](/docs/tasks/configure-pod-container/configure-pod-configmap/) 배우기. + +{{% /capture %}} + + diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index 9c02ebea83f25..25907bedb62a7 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -45,25 +45,25 @@

쿠버네티스 기초 모듈

- +
-
1. 쿠버네티스 클러스터 생성하기
 +
1. 쿠버네티스 클러스터 생성하기
- +
-
2. 애플리케이션 배포하기
 +
2. 애플리케이션 배포하기
- +
-
3. 앱 조사하기
 +
3. 앱 조사하기
@@ -73,25 +73,25 @@

쿠버네티스 기초 모듈

- +
-
4. 앱 외부로 노출하기
 +
4. 앱 외부로 노출하기
- +
-
5. 애플리케이션 스케일링하기
 +
5. 애플리케이션 스케일링하기
- +
-
6. 앱 업데이트하기
 +
6. 앱 업데이트하기
@@ -102,7 +102,7 @@

쿠버네티스 기초 모듈

- 튜토리얼 시작하기› + 튜토리얼 시작하기›
diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 58bf5a5848db2..579b6bc3adcf5 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -28,7 +28,7 @@
- + 모듈 2로 진행하기›
diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 576686ae6f319..03f92cf5384ad 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -119,7 +119,7 @@

클러스터 다이어그램

- 대화형 튜토리얼 시작하기 ›
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index f3d3f4c9df75b..b205265cb4f49 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -32,7 +32,7 @@
- + 모듈 3으로 진행하기›
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 7b8c344961b1f..0e6ec54197045 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -86,7 +86,7 @@

쿠버네티스에 첫 번째 애플리케이션 배

디플로이먼트를 생성할 때, 애플리케이션에 대한 컨테이너 이미지와 구동시키고자 하는 복제 수를 지정해야 한다. 디플로이먼트를 업데이트해서 이런 정보를 나중에 변경할 수 있다. 모듈 - 5와 6의 부트캠프에서 어떻게 + 5와 6의 부트캠프에서 어떻게 스케일하고 업데이트하는지에 대해 다룬다.

@@ -105,7 +105,7 @@

쿠버네티스에 첫 번째 애플리케이션 배

우리의 첫 번째 디플로이먼트로, Docker 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자. Node.js 애플리케이션을 작성하고 Docker 컨테이너를 배포하기 위해서, - Hello Minikube 튜토리얼의 지시를 따른다.

+ Hello Minikube 튜토리얼의 지시를 따른다.

이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!

@@ -115,7 +115,7 @@

쿠버네티스에 첫 번째 애플리케이션 배
- 대화형 튜토리얼 시작하기 ›
diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index b6a8c51ec0513..01e7fcbf11aa2 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -32,7 +32,7 @@
- 모듈 4로 + 모듈 4로 진행하기›
diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html index c2a174a9d7c4c..542b6dce089e6 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -29,7 +29,7 @@

목표

쿠버네티스 파드

-

모듈 2에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 파드를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커 또는 rkt와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:

+

모듈 2에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 파드를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커 또는 rkt와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:

  • 볼륨과 같은, 공유 스토리지
  • 클러스터 IP 주소와 같은, 네트워킹
    • @@ -108,7 +108,7 @@

    노드 개요

    kubectl로 문제해결하기

    -

    모듈 2에서, 여러분은 Kubectl 커맨드-라인 인터페이스를 사용하였다. 여러분은 배포된 애플리케이션과 그 환경에 대한 정보를 얻기 위해 모듈 3에서도 계속 그것을 사용하게 될 것이다. 가장 보편적인 운용업무는 다음 kubectl 명령어를 이용해 처리될 수 있다:

    +

    모듈 2에서, 여러분은 Kubectl 커맨드-라인 인터페이스를 사용하였다. 여러분은 배포된 애플리케이션과 그 환경에 대한 정보를 얻기 위해 모듈 3에서도 계속 그것을 사용하게 될 것이다. 가장 보편적인 운용업무는 다음 kubectl 명령어를 이용해 처리될 수 있다:

    • kubectl get - 자원을 나열한다
    • kubectl describe - 자원에 대해 상세한 정보를 보여준다.
      • @@ -131,7 +131,7 @@

      kubectl로 문제해결하기

      - 대화형 튜토리얼 시작하기 › + 대화형 튜토리얼 시작하기 ›
      diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index 0c14e5dd7b562..f81c1fd09a9f7 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -26,7 +26,7 @@
    - 모듈 5로 진행하기› + 모듈 5로 진행하기›
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html index e883381f9c38f..2eb5301fbf475 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@

    목표

    쿠버네티스 서비스들에 대한 개요

    -

    쿠버네티스 파드들 은 언젠가는 죽게된다. 실제 파드들은 생명주기를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. 레플리케이션 컨트롤러는 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 대체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.

    +

    쿠버네티스 파드들 은 언젠가는 죽게된다. 실제 파드들은 생명주기를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. 레플리케이션 컨트롤러는 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.

    쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML (보다 선호하는) 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 LabelSelector에 의해 결정된다 (여러분이 왜 스펙에 selector가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).

    @@ -104,7 +104,7 @@

    서비스와 레이블


    - 대화형 튜토리얼 시작› + 대화형 튜토리얼 시작›
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index cdab6ad81020d..a4e3aa4ed175a 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -29,7 +29,7 @@
    - + 모듈 6으로 진행하기›
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 6c369c1a5db8c..db88345168e01 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -123,7 +123,7 @@

    스케일링 개요

    - 대화형 튜토리얼 시작하기 ›
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html index 16ea8d01c1dca..029acc6331f3e 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -26,7 +26,7 @@
    - 쿠버네티스 기초로 돌아가기› + 쿠버네티스 기초로 돌아가기›
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html index 398fd149e3b26..b7e7f81d422bb 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -129,7 +129,7 @@

    롤링 업데이트 개요

    - 대화형 튜토리얼 시작하기 ›
    diff --git a/content/ko/docs/tutorials/online-training/_index.md b/content/ko/docs/tutorials/online-training/_index.md new file mode 100755 index 0000000000000..7d3447fd4eef9 --- /dev/null +++ b/content/ko/docs/tutorials/online-training/_index.md @@ -0,0 +1,5 @@ +--- +title: "온라인 트레이닝 코스" +weight: 20 +--- + diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md new file mode 100644 index 0000000000000..08d6d8c9419f0 --- /dev/null +++ b/content/ko/docs/tutorials/online-training/overview.md @@ -0,0 +1,34 @@ +--- +title: 쿠버네티스 온라인 트레이닝 개요 +content_template: templates/concept +--- + +{{% capture overview %}} + +이 페이지에서는 쿠버네티스 온라인 트레이닝을 제공하는 사이트를 소개한다: + +{{% /capture %}} + +{{% capture body %}} + +* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) + +* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) + +* [Getting Started with Kubernetes (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes) + +* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes) + +* [Learn Kubernetes using Interactive Hands-on Scenarios (Katacoda)](https://www.katacoda.com/courses/kubernetes/) + +* [Certified Kubernetes Administrator Preparation Course (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course) + +* [Kubernetes the Hard Way (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way) + +* [Certified Kubernetes Application Developer Preparation Course (KodeKloud.com)](https://kodekloud.com/p/kubernetes-certification-course) + +{{% /capture %}} + + + + diff --git a/content/ko/docs/tutorials/stateless-application/_index.md b/content/ko/docs/tutorials/stateless-application/_index.md new file mode 100755 index 0000000000000..7f3c70ef62f80 --- /dev/null +++ b/content/ko/docs/tutorials/stateless-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "상태 유지를 하지 않는 애플리케이션" +weight: 40 +--- + diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md new file mode 100644 index 0000000000000..81455b8b70087 --- /dev/null +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -0,0 +1,143 @@ +--- +title: 외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기 +content_template: templates/tutorial +weight: 10 +--- + +{{% capture overview %}} + +이 페이지에서는 외부 IP 주소를 노출하는 쿠버네티스 서비스 오브젝트를 생성하는 방법에 대해 설명한다. + +{{% /capture %}} + + +{{% capture prerequisites %}} + + * [kubectl](/docs/tasks/tools/install-kubectl/)을 설치한다. + + * Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여 쿠버네티스 클러스터를 생성한다. 이 튜토리얼은 [외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데, 클라우드 공급자가 필요하다. + + * `kubectl`이 쿠버네티스 API 서버와 통신하도록 설정한다. 자세한 내용은 클라우드 공급자의 설명을 참고한다. + +{{% /capture %}} + + +{{% capture objectives %}} + +* Hello World 애플리케이션을 다섯 개의 인스턴스로 실행한다. +* 외부 IP 주소를 노출하는 서비스를 생성한다. +* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다. + +{{% /capture %}} + + +{{% capture lessoncontent %}} + +## 다섯 개의 파드에서 실행되는 애플리케이션에 대한 서비스 만들기 + +1. 클러스터에서 Hello World 애플리케이션을 실행한다. + + kubectl run hello-world --replicas=5 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080 + + 위의 명령어는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/) + 오브젝트와 관련된 + [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/) + 오브젝트를 생성한다. 레플리카 셋은 다섯 개의 + [파드](/docs/concepts/workloads/pods/pod/)가 있으며, + 각 파드는 Hello World 애플리케이션을 실행한다. + +1. 디플로이먼트에 대한 정보를 확인한다. + + kubectl get deployments hello-world + kubectl describe deployments hello-world + +1. 레플리카 셋 오브젝트에 대한 정보를 확인한다. + + kubectl get replicasets + kubectl describe replicasets + +1. 디플로이먼트를 외부로 노출시키는 서비스 오브젝트를 생성한다. + + kubectl expose deployment hello-world --type=LoadBalancer --name=my-service + +1. 서비스에 대한 정보를 확인한다. + + kubectl get services my-service + + 결과는 아래와 같은 형태로 나타난다. + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + my-service ClusterIP 10.3.245.137 104.198.205.71 8080/TCP 54s + + 참고: 만약 외부 IP 주소가 \으로 표시되면 잠시 기다린 다음, 동일한 명령어를 다시 입력한다. + +1. 서비스에 대한 자세한 정보를 확인한다. + + kubectl describe services my-service + + 결과는 아래와 같은 형태로 나타난다. + + Name: my-service + Namespace: default + Labels: run=load-balancer-example + Annotations: + Selector: run=load-balancer-example + Type: LoadBalancer + IP: 10.3.245.137 + LoadBalancer Ingress: 104.198.205.71 + Port: 8080/TCP + NodePort: 32377/TCP + Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... + Session Affinity: None + Events: + + 서비스에 의해 노출된 외부 IP 주소 (`LoadBalancer Ingress`)를 기억해두자. + 예시에서 외부 IP 주소는 104.198.205.71이다. + 그리고 `Port`와`NodePort`의 값을 기억해두자. 예시에서 `Port`는 8080이고 `NodePort`는 32377이다. + +1. 위의 출력 결과를 통해, 서비스에 여러 엔드포인트가 있음을 알 수 있다. + 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2. 이 주소는 Hello World 애플리케이션을 실행 중인 파드의 내부 주소다. 해당 주소가 파드 주소인지 확인하려면, 아래 명령어를 입력하면 된다. + + kubectl get pods --output=wide + + 결과는 아래와 같은 형태로 나타난다. + + NAME ... IP NODE + hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a + hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc + +1. Hello World 애플리케이션에 접근하기 위해 외부 IP 주소 (`LoadBalancer Ingress`)를 사용한다. + + curl http://: + + ``는 서비스의 외부 IP 주소 (`LoadBalancer Ingress`)를 의미하며, + ``는 서비스 정보에서 `Port` 값을 의미한다. + 만약 minikube를 사용하고 있다면, `minikube service my-service` 명령어를 통해 자동으로 브라우저 내에서 Hello World 애플리케이션에 접근할 수 있다. + + 성공적인 요청에 대한 응답으로 hello 메세지가 나타난다. + + Hello Kubernetes! + +{{% /capture %}} + + +{{% capture cleanup %}} + +서비스를 삭제하려면, 아래의 명령어를 입력한다. + + kubectl delete services my-service + +Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카 셋, 파드를 삭제하려면, 아래의 명령어를 입력한다. + + kubectl delete deployment hello-world + +{{% /capture %}} + + +{{% capture whatsnext %}} + +[애플리케이션과 서비스 연결하기](/docs/concepts/services-networking/connect-applications-service/)에 대해 더 배워 본다. +{{% /capture %}} diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md new file mode 100644 index 0000000000000..e1854461721ce --- /dev/null +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -0,0 +1,363 @@ +--- +title: "예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기" +content_template: templates/tutorial +weight: 20 +--- + +{{% capture overview %}} +이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다. + +* 방명록을 저장하는 단일 인스턴스 [Redis](https://redis.io/) 마스터 +* 읽기를 제공하는 여러 개의 [복제된 Redis](https://redis.io/topics/replication) 인스턴스 +* 여러 개의 웹 프론트엔드 인스턴스 + +{{% /capture %}} + +{{% capture objectives %}} +* Redis 마스터를 실행한다. +* Redis 슬레이브를 실행한다. +* 방명록 프론트엔드를 실행한다. +* 프론트엔드 서비스를 노출시키고 확인한다. +* 제거한다. +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} + +{{< version-check >}} + +{{% /capture %}} + +{{% capture lessoncontent %}} + +## Redis 마스터를 실행하기 + +방명록 애플리케이션은 Redis를 사용하여 데이터를 저장한다. Redis 마스터 인스턴스에 데이터를 기록하고 여러 Redis 슬레이브 인스턴스에서 데이터를 읽는다. + +### Redis 마스터의 디플로이먼트를 생성하기 + +아래의 매니페스트 파일은 단일 복제본 Redis 마스터 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다. + +{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} + +1. 매니페스트 파일을 다운로드한 디렉토리에서 터미널 창을 시작한다. +1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용시킨다. + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + ``` + +1. 파드의 목록을 질의하여 Redis 마스터 파드가 실행 중인지 확인한다. + + ```shell + kubectl get pods + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 28s + ``` + +1. Redis 마스터 파드에서 로그를 보려면 다음 명령어를 실행한다. + + ```shell + kubectl logs -f POD-NAME + ``` + +{{< note >}} +POD-NAME을 해당 파드 이름으로 수정해야 한다. +{{< /note >}} + +### Redis 마스터 서비스 생성하기 + +방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. + +{{< codenew file="application/guestbook/redis-master-service.yaml" >}} + +1. `redis-master-service.yaml` 파일을 통해 Redis 마스터 서비스에 적용시킨다. + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + ``` + +1. 서비스의 목록을 질의하여 Redis 마스터 서비스가 실행 중인지 확인한다. + + ```shell + kubectl get service + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 1m + redis-master ClusterIP 10.0.0.151 6379/TCP 8s + ``` + +{{< note >}} +이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `redis-master`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 Redis 마스터 파드로 라우팅한다. +{{< /note >}} + + +## Redis 슬레이브 실행하기 + +Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추가하여 트래픽 요구 사항을 충족시킬 수 있다. + +### Redis 슬레이브의 디플로이먼트 생성하기 + +디플로이먼트는 매니페스트 파일에 설정된 구성에 따라 확장된다. 이 경우, 디플로이먼트 오브젝트는 두 개의 복제본을 지정한다. + +실행 중인 복제본이 없으면, 이 디플로이먼트는 컨테이너 클러스터에 있는 두 개의 복제본을 시작한다. 반대로 두 개 이상의 복제본이 실행 중이면, 두 개의 복제본이 실행될 때까지 축소된다. + +{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}} + +1. `redis-slave-deployment.yaml` 파일을 통해 Redis 슬레이브의 디플로이먼트에 적용시킨다. + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml + ``` + +1. 파드의 목록을 질의하여 Redis 슬레이브 파드가 실행 중인지 확인한다. + + ```shell + kubectl get pods + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ```shell + NAME READY STATUS RESTARTS AGE + redis-master-1068406935-3lswp 1/1 Running 0 1m + redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s + redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s + ``` + +### Redis 슬레이브 서비스 생성하기 + +방명록 애플리케이션은 Redis 슬레이브와 통신하여 데이터를 읽는다. Redis 슬레이브를 확인할 수 있도록 하기 위해 서비스를 설정해야 한다. 서비스는 파드 집합에 투명한 로드 밸런싱을 제공한다. + +{{< codenew file="application/guestbook/redis-slave-service.yaml" >}} + +1. `redis-slave-service.yaml` 파일을 통해 Redis 슬레이브 서비스에 적용시킨다. + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml + ``` + +1. 서비스의 목록을 질의하여 Redis 슬레이브 서비스가 실행 중인지 확인한다. + + ```shell + kubectl get services + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 2m + redis-master ClusterIP 10.0.0.151 6379/TCP 1m + redis-slave ClusterIP 10.0.0.223 6379/TCP 6s + ``` + +## 방명록 프론트엔드를 설정하고 노출시키기 + +방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 쓰기 요청을 위한 `redis-master` 서비스와 읽기 요청을 위한 `redis-slave` 서비스에 연결하도록 설정된다. + +### 방명록 프론트엔드의 디플로이먼트 생성하기 + +{{< codenew file="application/guestbook/frontend-deployment.yaml" >}} + +1. `frontend-deployment.yaml` 파일을 통해 프론트엔드의 디플로이먼트에 적용시킨다. + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml + ``` + +1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다. + + ```shell + kubectl get pods -l app=guestbook -l tier=frontend + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-dsvc5 1/1 Running 0 54s + frontend-3823415956-k22zn 1/1 Running 0 54s + frontend-3823415956-w9gbt 1/1 Running 0 54s + ``` + +### 프론트엔드 서비스 생성하기 + +서비스의 기본 유형은 [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. + +게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다. + +{{< note >}} +Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : NodePort`를 삭제하거나 주석 처리하고 `type : LoadBalancer`의 주석을 제거해야 한다. +{{< /note >}} + +{{< codenew file="application/guestbook/frontend-service.yaml" >}} + +1. `frontend-service.yaml` 파일을 통해 프론트엔드 서비스에 적용시킨다. + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml + ``` + +1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다. + + ```shell + kubectl get services + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.0.0.112 80:31323/TCP 6s + kubernetes ClusterIP 10.0.0.1 443/TCP 4m + redis-master ClusterIP 10.0.0.151 6379/TCP 2m + redis-slave ClusterIP 10.0.0.223 6379/TCP 1m + ``` + +### `NodePort`를 통해 프론트엔드 서비스 확인하기 + +애플리케이션을 Minikube 또는 로컬 클러스터에 배포한 경우, 방명록을 보려면 IP 주소를 찾아야 한다. + +1. 프론트엔드 서비스의 IP 주소를 얻기 위해 아래 명령어를 실행한다. + + ```shell + minikube service frontend --url + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + http://192.168.99.100:31323 + ``` + +1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다. + +### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기 + +`frontend-service.yaml` 매니페스트를 `LoadBalancer`와 함께 배포한 경우, 방명록을 보기 위해 IP 주소를 찾아야 한다. + +1. 프론트엔드 서비스의 IP 주소를 얻기 위해 아래 명령어를 실행한다. + + ```shell + kubectl get service frontend + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m + ``` + +1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다. + +## 웹 프론트엔드 확장하기 + +서버가 디플로이먼트 컨트롤러를 사용하는 서비스로 정의되어 있기 때문에 확장 또는 축소가 쉽다. + +1. 프론트엔드 파드의 수를 확장하기 위해 아래 명령어를 실행한다. + + ```shell + kubectl scale deployment frontend --replicas=5 + ``` + +1. 파드의 목록을 질의하여 실행 중인 프론트엔드 파드의 수를 확인한다. + + ```shell + kubectl get pods + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-70qj5 1/1 Running 0 5s + frontend-3823415956-dsvc5 1/1 Running 0 54m + frontend-3823415956-k22zn 1/1 Running 0 54m + frontend-3823415956-w9gbt 1/1 Running 0 54m + frontend-3823415956-x2pld 1/1 Running 0 5s + redis-master-1068406935-3lswp 1/1 Running 0 56m + redis-slave-2005841000-fpvqc 1/1 Running 0 55m + redis-slave-2005841000-phfv9 1/1 Running 0 55m + ``` + +1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다. + + ```shell + kubectl scale deployment frontend --replicas=2 + ``` + +1. 파드의 목록을 질의하여 실행 중인 프론트엔드 파드의 수를 확인한다. + + ```shell + kubectl get pods + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME READY STATUS RESTARTS AGE + frontend-3823415956-k22zn 1/1 Running 0 1h + frontend-3823415956-w9gbt 1/1 Running 0 1h + redis-master-1068406935-3lswp 1/1 Running 0 1h + redis-slave-2005841000-fpvqc 1/1 Running 0 1h + redis-slave-2005841000-phfv9 1/1 Running 0 1h + ``` + +{{% /capture %}} + +{{% capture cleanup %}} +디플로이먼트 및 서비스를 삭제하면 실행 중인 모든 파드도 삭제된다. 레이블을 사용하여 하나의 명령어로 여러 자원을 삭제해보자. + +1. 모든 파드, 디플로이먼트, 서비스를 삭제하기 위해 아래 명령어를 실행한다. + + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment -l app=guestbook + kubectl delete service -l app=guestbook + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + deployment.apps "redis-master" deleted + deployment.apps "redis-slave" deleted + service "redis-master" deleted + service "redis-slave" deleted + deployment.apps "frontend" deleted + service "frontend" deleted + ``` + +1. 파드의 목록을 질의하여 실행 중인 파드가 없는지 확인한다. + + ```shell + kubectl get pods + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + No resources found. + ``` + +{{% /capture %}} + +{{% capture whatsnext %}} +* [쿠버네티스 기초](/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료한다. +* [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨 사용하기](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)를 통해 블로그를 만들어본다. +* [애플리케이션 접속](/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아본다. +* [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아본다. +{{% /capture %}} + diff --git a/content/ko/examples/application/guestbook/frontend-deployment.yaml b/content/ko/examples/application/guestbook/frontend-deployment.yaml new file mode 100644 index 0000000000000..50d6e1f0d4819 --- /dev/null +++ b/content/ko/examples/application/guestbook/frontend-deployment.yaml @@ -0,0 +1,38 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: frontend + labels: + app: guestbook +spec: + selector: + matchLabels: + app: guestbook + tier: frontend + replicas: 3 + template: + metadata: + labels: + app: guestbook + tier: frontend + spec: + containers: + - name: php-redis + image: gcr.io/google-samples/gb-frontend:v4 + resources: + requests: + cpu: 100m + memory: 100Mi + env: + - name: GET_HOSTS_FROM + value: dns + # Using `GET_HOSTS_FROM=dns` requires your cluster to + # provide a dns service. As of Kubernetes 1.3, DNS is a built-in + # service launched automatically. However, if the cluster you are using + # does not have a built-in DNS service, you can instead + # access an environment variable to find the master + # service's host. To do so, comment out the 'value: dns' line above, and + # uncomment the line below: + # value: env + ports: + - containerPort: 80 diff --git a/content/ko/examples/application/guestbook/frontend-service.yaml b/content/ko/examples/application/guestbook/frontend-service.yaml new file mode 100644 index 0000000000000..6f283f347b93f --- /dev/null +++ b/content/ko/examples/application/guestbook/frontend-service.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Service +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # comment or delete the following line if you want to use a LoadBalancer + type: NodePort + # if your cluster supports it, uncomment the following to automatically create + # an external load-balanced IP for the frontend service. + # type: LoadBalancer + ports: + - port: 80 + selector: + app: guestbook + tier: frontend diff --git a/content/ko/examples/application/guestbook/redis-master-deployment.yaml b/content/ko/examples/application/guestbook/redis-master-deployment.yaml new file mode 100644 index 0000000000000..fc6f418c39ed1 --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-master-deployment.yaml @@ -0,0 +1,29 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: redis-master + labels: + app: redis +spec: + selector: + matchLabels: + app: redis + role: master + tier: backend + replicas: 1 + template: + metadata: + labels: + app: redis + role: master + tier: backend + spec: + containers: + - name: master + image: k8s.gcr.io/redis:e2e # or just image: redis + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 diff --git a/content/ko/examples/application/guestbook/redis-master-service.yaml b/content/ko/examples/application/guestbook/redis-master-service.yaml new file mode 100644 index 0000000000000..a484014f1fe3b --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-master-service.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Service +metadata: + name: redis-master + labels: + app: redis + role: master + tier: backend +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis + role: master + tier: backend diff --git a/content/ko/examples/application/guestbook/redis-slave-deployment.yaml b/content/ko/examples/application/guestbook/redis-slave-deployment.yaml new file mode 100644 index 0000000000000..ec4e48bc211a0 --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-slave-deployment.yaml @@ -0,0 +1,40 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: redis-slave + labels: + app: redis +spec: + selector: + matchLabels: + app: redis + role: slave + tier: backend + replicas: 2 + template: + metadata: + labels: + app: redis + role: slave + tier: backend + spec: + containers: + - name: slave + image: gcr.io/google_samples/gb-redisslave:v1 + resources: + requests: + cpu: 100m + memory: 100Mi + env: + - name: GET_HOSTS_FROM + value: dns + # Using `GET_HOSTS_FROM=dns` requires your cluster to + # provide a dns service. As of Kubernetes 1.3, DNS is a built-in + # service launched automatically. However, if the cluster you are using + # does not have a built-in DNS service, you can instead + # access an environment variable to find the master + # service's host. To do so, comment out the 'value: dns' line above, and + # uncomment the line below: + # value: env + ports: + - containerPort: 6379 diff --git a/content/ko/examples/application/guestbook/redis-slave-service.yaml b/content/ko/examples/application/guestbook/redis-slave-service.yaml new file mode 100644 index 0000000000000..238fd63fb6a29 --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-slave-service.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Service +metadata: + name: redis-slave + labels: + app: redis + role: slave + tier: backend +spec: + ports: + - port: 6379 + selector: + app: redis + role: slave + tier: backend diff --git a/content/ko/examples/pods/config/redis-config b/content/ko/examples/pods/config/redis-config new file mode 100644 index 0000000000000..ead340713c830 --- /dev/null +++ b/content/ko/examples/pods/config/redis-config @@ -0,0 +1,2 @@ +maxmemory 2mb +maxmemory-policy allkeys-lru diff --git a/content/ko/examples/pods/config/redis-pod.yaml b/content/ko/examples/pods/config/redis-pod.yaml new file mode 100644 index 0000000000000..259dbf853aa4c --- /dev/null +++ b/content/ko/examples/pods/config/redis-pod.yaml @@ -0,0 +1,30 @@ +apiVersion: v1 +kind: Pod +metadata: + name: redis +spec: + containers: + - name: redis + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + resources: + limits: + cpu: "0.1" + volumeMounts: + - mountPath: /redis-master-data + name: data + - mountPath: /redis-master + name: config + volumes: + - name: data + emptyDir: {} + - name: config + configMap: + name: example-redis-config + items: + - key: redis-config + path: redis.conf diff --git a/content/ko/includes/task-tutorial-prereqs.md b/content/ko/includes/task-tutorial-prereqs.md new file mode 100644 index 0000000000000..762d3210d70fb --- /dev/null +++ b/content/ko/includes/task-tutorial-prereqs.md @@ -0,0 +1,6 @@ +쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 합니다. +만약, 클러스터를 이미 가지고 있지 않다면, [Minikube](/docs/setup/minikube)를 사용해서 만들거나, +다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있습니다: + +* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Play with Kubernetes](http://labs.play-with-k8s.com/)