diff --git a/content/ko/_index.html b/content/ko/_index.html index 06581018e8..89753c9f3b 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -8,7 +8,7 @@ cid: home {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} -### [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. +### [쿠버네티스 (k8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. 애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다. {{% /blocks/feature %}} @@ -44,12 +44,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준


- Attend KubeCon in Shanghai on Nov. 13-15, 2018 + Attend KubeCon in Barcelona on May 20-23, 2019



- Attend KubeCon in Seattle on Dec. 11-13, 2018 + Attend KubeCon in Shanghai on June 24-26, 2019
diff --git a/content/ko/docs/concepts/architecture/master-node-communication.md b/content/ko/docs/concepts/architecture/master-node-communication.md new file mode 100644 index 0000000000..7ab5615255 --- /dev/null +++ b/content/ko/docs/concepts/architecture/master-node-communication.md @@ -0,0 +1,88 @@ +--- +title: 마스터-노드 커뮤니케이션 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의 커뮤니케이션 경로를 나열해 본다. +그 목적은 사용자로 하여금 untrusted network(신뢰할 수 없는 네트워크) 상에서 +(또는 클라우드 제공사업자 환경에서 완전히 공인 IP로) 동작될 수 있는 +그러한 클러스터의 네트워크 구성을 강화하기 위해 사용자의 설치를 커스터마이즈 할 수 있도록 해주기 위함이다. + +{{% /capture %}} + + +{{% capture body %}} + +## 클러스터에서 마스터로 + +클러스터에서 마스터로의 모든 커뮤니케이션 경로는 apiserver에서 끝난다 +(어떤 다른 마스터 컴포넌트도 원격 서비스를 노출하기 위해 설계되지 않는다). +전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형태가 +사용가능토록 하여 안전한 HTTPS 포트(443)를 통해 원격 연결에 대해 서비스 리슨하도록 구성된다. +특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) +또는 [서비스 계정 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 +허용된 경우에는 하나 또는 그 이상의 [인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다. + +노드는 유효한 클라이언트 자격증명과 함께 apiserver에 안전하게 접속할 수 있는 +그런 클러스터용 공인 루트 인증서를 가지고 제공되어야 한다. +예를 들어, 기본 GKE 배포의 경우, kubelet에 제공되는 클라이언트 자격증명은 +클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에 대한 자동화 프로비저닝에 대해서는 +[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다. + +apiserver에 접속하려는 파드는 서비스 계정에 영향력을 발휘함으로써 안전하게 +그리 행할 수 있으며 따라서 쿠버네티스는 인스턴스화 될 때 공인 루트 인증서와 +유효한 베어러 토큰을 파드 속으로 자동 주입할 수 있게 된다. +(모든 네임스페이스 내) `kubernetes` 서비스는 apiserver 상의 HTTPS 엔드포인트로 +(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를 가지고 구성된다. + +마스터 컴포넌트는 또한 신뢰할 수 있는 포트를 통해 클러스터 apiserver와 소통한다. + +결과적으로, 클러스터 (노드 그리고 노드에서 동작하는 파드)에서 +마스터로의 기본 동작 모드는 기본적으로 안전하며 +신뢰할 수 없는그리고/또는 공인 네트워크 상에서 동작할 수 있다. + +## 마스터에서 클러스터로 + +마스터(apiserver)에서 클러스터로의 두 가지 주된 커뮤니케이션 경로가 존재한다. +첫 번째는 클러스터 내 각 노드를 동작시키는 apiserver에서 kubelet 프로세스로의 +경로이다. 두 번째는 apiserver에서 apiserver의 프록시 기능을 통한 임의의 노드, +파드 또는 서비스로의 경로이다. + +### apiserver에서 kubelet으로 + +apiserver에서 kubelet으로의 연결은 다음을 위해 이용된다. + + * 파드에 대한 로그 가져오기 + * 동작중인 파드에 (kubectl을 통해) 연관짓기 + * kubelet의 포트 포워딩 기능 제공하기 + +이 연결은 kubelet의 HTTPS 엔드포인트에서 끝난다. 기본적으로, +apiserver는 kubelet의 제공 인증서를 확인하지 않는데, +이는 연결에 대한 중간자 공격을 당하게 하고, 신뢰할 수 없는 +그리고/또는 공인 네트워크에서 운영하기에는 **불안** 하게 만든다. + +이 연결을 확인하려면, apiserver에 kubelet의 제공 인증서 확인을 위해 사용하는 +루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다 + +그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면, +apiserver와 kubelet 사이에 [SSH 터널링](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)을 +사용한다. + +마지막으로, kubelet API를 안전하게 하기 위해 +[Kubelet 인증 그리고/또는 인가](/docs/admin/kubelet-authentication-authorization/)가 활성화 되어야만 한다. + +### apiserver에서 노드, 파드, 그리고 서비스로 + +apiserver에서 노드, 파드, 또는 서비스로의 연결은 보통 HTTP 연결을 +기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드, 파드, 또는 서비스 이름에 +`https:` 프리픽스를 붙임으로써 안전한 HTTPS 연결로 동작될 수 있지만, +HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며 +클라이언트 자격증명 또한 제공하지 않는다. +그래서 연결이 암호화될 동안, 어떠한 무결성도 제공되지 않을 것이다. +이러한 연결들은 신뢰할 수 없는 그리고/또는 공인 네트워크에서 동작하기에 +**현재로서는 안전하지 않다**. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 5df6f29396..4061f7c7b8 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -171,24 +171,7 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄 쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다. 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 에 대해 이를 수행한다. +파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다. ## API 오브젝트 diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md new file mode 100755 index 0000000000..bdcb03bde5 --- /dev/null +++ b/content/ko/docs/concepts/containers/_index.md @@ -0,0 +1,5 @@ +--- +title: "컨테이너" +weight: 40 +--- + diff --git a/content/ko/docs/concepts/containers/container-environment-variables.md b/content/ko/docs/concepts/containers/container-environment-variables.md new file mode 100644 index 0000000000..c476a557bb --- /dev/null +++ b/content/ko/docs/concepts/containers/container-environment-variables.md @@ -0,0 +1,60 @@ +--- +title: 컨테이너 환경 변수 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +이 페이지는 컨테이너 환경에서 컨테이너에 가용한 리소스에 대해 설명한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 컨테이너 환경 + +쿠버네티스 컨테이너 환경은 컨테이너에 몇 가지 중요한 리소스를 제공한다. + +* 하나의 [이미지](/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템. +* 컨테이너 자신에 대한 정보. +* 클러스터 내의 다른 오브젝트에 대한 정보. + +### 컨테이너 정보 + +컨테이너의 *호스트네임* 은 컨테이너가 동작 중인 파드의 이름과 같다. +그것은 `hostname` 커맨드 또는 libc의 +[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) +함수 호출을 통해서 구할 수 있다. + +파드 이름과 네임스페이스는 +[다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다. + +Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로, +파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다. + +### 클러스터 정보 + +컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수 +있다. +이러한 환경 변수는 Docker 링크 구문과 일치한다. + +*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는, +다음의 형태로 변수가 정의된다. + +```shell +FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> +FOO_SERVICE_PORT=<서비스가 동작 중인 포트> +``` + +서비스에 지정된 IP 주소가 있고 [DNS 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [컨테이너 라이프사이클 훅(hooks)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기. +* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index bc84f00b6c..33703bba05 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -123,6 +123,6 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 데몬셋, 디플로이먼트, HorizontalPodAutoscaler, 인그레스, 잡 및 레플리카셋이 기본적으로 활성화되어 있다. 다른 확장 리소스는 apiserver의 `--runtime-config`를 설정해서 활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어 디플로이먼트와 인그레스를 비활성화 시키려면, -`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`와 같이 설정한다. +`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`와 같이 설정한다. {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md new file mode 100644 index 0000000000..7db4d9918c --- /dev/null +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -0,0 +1,323 @@ +--- +title: 초기화 컨테이너 +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} +이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는 +앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는 +유틸리티 또는 설정 스크립트 등을 포함할 수 있다. +{{% /capture %}} + +이 특징은 1.6에서 베타를 빠져나왔다. 초기화 컨테이너는 앱 `containers` 배열과 나란히 +파드 스펙에 명시될 수 있다. 베타 어노테이션의 값은 여전히 존중되며 파드 스펙 필드 값을 덮어쓴다. +하지만, 베타 어노테이션은 1.6과 1.7에서 사용 중단(deprecated)되었다. +1.8에서 어노테이션은 더는 지원되지 않으므로 파드 스펙 필드로 변환되어야 한다. + +{{% capture body %}} +## 초기화 컨테이너 이해하기 + +[파드](/ko/docs/concepts/workloads/pods/pod-overview/)는 앱들을 실행하는 다수의 컨테이너를 +포함할 수 있다. 또한, 파드는 앱 컨테이너 실행 전에 동작되는 하나 이상의 +초기화 컨테이너도 포함할 수 있다. + +다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다. + +* 초기화 컨테이너는 항상 완료를 목표로 실행된다. +* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다. + +만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를 +반복적으로 재시작한다. 그러나, 만약 파드가 `restartPolicy`을 절대 하지 않음(Never)으로 설정한다면, 파드는 재시작되지 않는다. + +컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 앱 `containers` 배열과 나란히 +`initContainers` 필드를 +[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +타입 오브젝트들의 JSON 배열로서 추가한다. +초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를 +통해서 컨테이너 상태 배열로 반환된다 (`.status.containerStatuses`와 +유사하게). + +### 일반적인 컨테이너와의 차이점 + +초기화 컨테이너는 앱 컨테이너의 리소스 상한, 볼륨, 보안 세팅을 포함한 +모든 필드와 특징을 지원한다. 그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은 +약간 다르게 처리된다. 이것에 대해서는 아래 [리소스](#리소스)에 문서화되어 있다. 또한, 초기화 컨테이너는 +준비성 프로브(readiness probe)를 지원하지 않는다. 왜냐하면 초기화 컨테이너는 +파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 +때문이다. + +만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, 해당 초기화 컨테이너들은 순차적으로 +한 번에 하나씩 실행된다. 각 초기화 컨테이너들은 다음 초기화 컨테이너가 실행되기 전에 성공되어야 한다. +모든 초기화 컨테이너들이 실행 완료되었을 때, 쿠버네티스는 파드를 초기화하고 +애플리케이션 컨테이너를 평소와 같이 실행한다. + +## 초기화 컨테이너는 무엇을 위해서 사용될 수 있는가? + +초기화 컨테이너는 앱 컨테이너와는 별도의 이미지를 가지고 있기 때문에, 시동(start-up)에 +관련된 코드에 몇 가지 이점을 가진다. + +* 보안 상 앱 컨테이너 이미지에서는 바람직하지 않은 유틸리티를 포함하고 + 실행시킬 수 있다. +* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함한다. + 예를 들어, 셋업 중에 단지 `sed`, `awk`, `python`, 또는 `dig`와 같은 도구를 사용하기 위해서 + 다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다. +* 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서 + 공동의 단일 앱 이미지 형태로 빌드될 필요가 없다. +* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다. + 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 시크릿에 접근 권한이 주어질 수 있다. +* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱 + 컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이 + 충족될 때까지 앱 컨테이너가 시동되는 것을 막거나 지연시키는 간편한 방법을 제공한다. + +### 예제 +초기화 컨테이너를 사용하는 방법에 대한 몇 가지 아이디어는 다음과 같다. + +* 다음과 같은 셀 커맨드로, 서비스가 생성될 때까지 기다리기. + + for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 + +* 다음과 같은 커맨드로, 다운워드 API(Downward API)를 통한 원격 서버에 해당 파드를 등록하기. + + curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()' + +* `sleep 60`와 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기. +* git 저장소를 볼륨 안에 클론하기. +* 설정 파일에 값을 지정하고 메인 앱 컨테이너를 위한 설정 파일을 동적으로 생성하기 위한 템플릿 도구를 실행하기. + 예를 들어, 설정에 POD_IP 값을 지정하고 메인 앱 설정 파일을 Jinja를 통해서 생성. + +더 자세한 사용 예제는 [스테이트풀 셋 문서](/docs/concepts/workloads/controllers/statefulset/) +과 [프로덕션 파드 가이드](/docs/tasks/configure-pod-container/configure-pod-initialization/)에서 확인한다. + +### 사용되고 있는 초기화 컨테이너 + +쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다. +첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이 +완료되면, 파드가 시작될 것이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp + annotations: + pod.beta.kubernetes.io/init-containers: '[ + { + "name": "init-myservice", + "image": "busybox", + "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] + }, + { + "name": "init-mydb", + "image": "busybox", + "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] + } + ]' +spec: + containers: + - name: myapp-container + image: busybox + command: ['sh', '-c', 'echo The app is running! && sleep 3600'] +``` + +쿠버네티스 1.6에는 새로운 구문이 있다. 다만, 예전 어노테이션 구문도 1.6과 1.7에서는 여전히 동작한다. 새로운 구문은 +1.8 또는 더 높은 버전에서 사용되어야 한다. 초기화에 대한 선언은 `spec`으로 옮겨졌다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp +spec: + containers: + - name: myapp-container + image: busybox + command: ['sh', '-c', 'echo The app is running! && sleep 3600'] + initContainers: + - name: init-myservice + image: busybox + command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] + - name: init-mydb + image: busybox + command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] +``` + +1.5 구문도 1.6에서 여전히 동작하지만, 1.6 구문 사용을 추천한다. 쿠버네티스 1.6에서는, 초기화 컨테이너가 API에서 필드로 +만들어졌었다. 베타 어노테이션은 1.6과 1.7에서 여전히 지원되지만, 1.8이나 더 높은 버전에서는 지원되지 않는다. + +아래의 yaml file은 `mydb`와 `myservice` 서비스의 개요를 보여준다. + +```yaml +kind: Service +apiVersion: v1 +metadata: + name: myservice +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +--- +kind: Service +apiVersion: v1 +metadata: + name: mydb +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9377 +``` + +다음 커맨드들을 이용하여 파드를 시작하거나 디버깅할 수 있다. + +```shell +$ kubectl create -f myapp.yaml +pod/myapp-pod created +$ kubectl get -f myapp.yaml +NAME READY STATUS RESTARTS AGE +myapp-pod 0/1 Init:0/2 0 6m +$ kubectl describe -f myapp.yaml +Name: myapp-pod +Namespace: default +[...] +Labels: app=myapp +Status: Pending +[...] +Init Containers: + init-myservice: +[...] + State: Running +[...] + init-mydb: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Containers: + myapp-container: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201 + 16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 +$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container +$ kubectl logs myapp-pod -c init-mydb # Inspect the second init container +``` + +`mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 +`myapp-pod`가 생성된 것을 볼 수 있다. + +```shell +$ kubectl create -f services.yaml +service/myservice created +service/mydb created +$ kubectl get -f myapp.yaml +NAME READY STATUS RESTARTS AGE +myapp-pod 1/1 Running 0 9m +``` + +이 예제는 매우 단순하지만 사용자만의 초기화 컨테이너를 생성하는데 +영감을 줄 것이다. + +## 자세한 동작 + +파드 시동 시, 네트워크와 볼륨이 초기화되고 나면, 초기화 컨테이너가 +순서대로 시작된다. 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로 +종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이 +실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만, +파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 +`restartPolicy`을 실패 시(OnFailure)로 사용한다. + +파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는 +서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만 +`Initializing`이 참이 되는 조건을 가져야 한다. + +만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는 +반드시 다시 실행된다. + +초기화 컨테이너 스펙 변경은 컨테이너 이미지 필드에서만 한정적으로 가능하다. +초기화 컨테이너 이미지 필드를 변경하는 것은 파드를 재시작하는 것과 같다. + +초기화 컨테이너는 재시작되거나, 재시도, 또는 재실행 될 수 있기 때문에, 초기화 컨테이너 +코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는 +출력 파일이 이미 존재할 가능성에 대비해야 한다. + +초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는 +`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 +구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다. + +초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서 +파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 +사용한다. + +파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤 +컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다. + +### 리소스 + +초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한 +다음의 규칙이 적용된다. + +* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장 + 높은 것은 *유효한 초기화 요청량/상한* 이다. +* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다. + * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계 + * 리소스에 대한 유효한 초기화 요청량/상한 +* 스케줄링은 유효한 요청/상한에 따라 이루어진다. 즉, + 초기화 컨테이너는 파드의 삶에서는 사용되지 않는 초기화를 위한 리소스를 + 예약할 수 있다. +* 파드의 *유효한 QoS 계층* 에서 QoS 계층은 초기화 컨테이너들과 + 앱 컨테이너들의 QoS 계층과 같다. + +쿼터 및 상한은 유효한 파드의 요청량 및 상한에 따라 +적용된다. + +파드 레벨 cgroup은 유효한 파드 요청량 및 상한을 기반으로 한다. 이는 스케줄러와 같다. + +### 파드 재시작 이유 + +파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수 +있다. + +* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다. + 앱 컨테이너 이미지의 변경은 앱 컨테이너만 재시작시킨다. +* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에 + 대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다. +* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는, + 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 + 때문에 유실되었다. + +## 지원 및 호환성 + +Api서버 버전 1.6.0 또는 더 높은 버전으로 구성된 클러스터는 `.spec.initContainers` +필드를 사용하여 초기화 컨테이너를 지원한다. 이전 버전들은 초기화 컨테이너를 알파 또는 +베타 어노테이션을 사용하여 지원한다. `.spec.initContainers` 필드는 알파 또는 베타 +어노테이션에도 반영되어 있어서 버전 1.3.0 이상의 Kubelet이 초기화 컨테이너를 실행할 수 +있도록 한다. 따라서, 버전 1.6 api서버가 기존에 생성된 파드들의 초기화 컨테이너 기능 손실 없이 +안전하게 버전 1.5.x로 롤백할 수 있게 한다. + +Api서버 및 Kubelet 버전 1.8.0 이상에서는, 사용 중단된 어노테이션을 +`.spec.initContainers` 필드로 변환하는 것이 필요한, 알파 및 베타 어노테이션의 지원이 중단되었다. + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md new file mode 100644 index 0000000000..71436db493 --- /dev/null +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -0,0 +1,81 @@ +--- +title: 파드 프리셋 +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} +이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에 +특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는 +시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다. +{{% /capture %}} + + +{{% capture body %}} +## 파드 프리셋 이해하기 + +`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을 +주입하기 위한 API 리소스이다. +주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는 +[레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다. + +파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로 +제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드 +템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다. + +그 배경에 대한 자세한 정보를 위해서는, [파드 프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 참고한다. + +## 어떻게 동작하는가 + +쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면, +파드 프리셋을 파드 생성 요청에 적용한다. +파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다. + +1. 사용 가능한 모든 `PodPresets`을 검색한다. +1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는 + 것이 있는지 확인한다. +1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에 + 병합되도록 시도한다. +1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로 + 부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다. +1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서 + 수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다. + `podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`. + +각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의 +파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을 +때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의 +변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을 +수정한다. `Volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다. + +{{< note >}} +파드 프리셋은 적절한 경우 파드 스펙의 `.spec.containers` 필드를 +수정할 수도 있다. 파드 프리셋으로부터의 리소스 정의 *없음* 은 `initContainers` +필드에 적용될 것이다. +{{< /note >}} + +### 특정 파드의 파드 프리셋 비활성화하기 + +어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가 +있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에 +추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`. + +## 파드 프리셋 활성화하기 + +클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다. + +1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다. 예를 + 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 + 포함하여 완료할 수 있다. +1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는 + API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다. +1. 사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여 + 파드 프리셋을 정의하였다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [파드 프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/) + +{{% /capture %}} diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 1884f2a512..98556ec6c9 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -23,8 +23,6 @@ content_template: templates/concept * [1.11](/docs/reference/generated/kubernetes-api/v1.11/) * [1.10](https://v1-10.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/) * [1.9](https://v1-9.docs.kubernetes.io/docs/api-reference/v1.9/) - * [1.8](https://v1-8.docs.kubernetes.io/docs/api-reference/v1.8/) - * [1.7](https://v1-7.docs.kubernetes.io/docs/api-reference/v1.7/) ## API 클라이언트 라이브러리 diff --git a/content/ko/docs/reference/glossary/kube-scheduler.md b/content/ko/docs/reference/glossary/kube-scheduler.md index b9672b6e03..8c05d992c7 100644 --- a/content/ko/docs/reference/glossary/kube-scheduler.md +++ b/content/ko/docs/reference/glossary/kube-scheduler.md @@ -4,15 +4,15 @@ id: kube-scheduler date: 2018-04-12 full_link: /docs/reference/generated/kube-scheduler/ short_description: > - Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on. + 노드가 배정되지 않은 새로 생성된 파드를 감지하고 그것이 구동될 노드를 선택하는 마스터 상의 컴포넌트. aka: tags: - architecture --- - Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on. + 노드가 배정되지 않은 새로 생성된 파드를 감지하고 그것이 구동될 노드를 선택하는 마스터 상의 컴포넌트. -Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines. +스케줄링 결정을 위한 어카운트 내 요소들로는 개별 및 공동의 리소스 요건, 하드웨어/소프트웨어/정책 제약, 친밀 및 배격 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인들이 포함된다. diff --git a/content/ko/docs/setup/cluster-large.md b/content/ko/docs/setup/cluster-large.md index 731313dbf4..5463923ba2 100644 --- a/content/ko/docs/setup/cluster-large.md +++ b/content/ko/docs/setup/cluster-large.md @@ -5,12 +5,12 @@ weight: 80 ## 지원 -At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria: +{{< param "version" >}} 버전에서, 쿠버네티스는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는, 다음 기준을 *모두* 만족하는 설정을 지원한다. -* No more than 5000 nodes -* No more than 150000 total pods -* No more than 300000 total containers -* No more than 100 pods per node +* 노드 5000개 이하 +* 전체 파드 150000개 이하 +* 전체 컨테이너 300000개 이하 +* 노드 당 파드 100개 이하
diff --git a/content/ko/docs/setup/cri.md b/content/ko/docs/setup/cri.md index e06d0e5fdf..0fc2f41b04 100644 --- a/content/ko/docs/setup/cri.md +++ b/content/ko/docs/setup/cri.md @@ -27,25 +27,24 @@ v1.6.0에서부터, 쿠버네티스는 CRI(컨테이너 런타임 인터페이 {{< 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 CE 설치 +## 저장소 설정 +### apt 패키지 인덱스 업데이트 + apt-get update -# 또는 Docker 저장소를 통한 Ubuntu 또는 Debian 용 Docker CE 18.06 설치: +### apt가 HTTPS 저장소를 사용할 수 있도록 해주는 패키지 설치 + apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common -## 선행 조건들 설치. -apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common +### Docker의 공식 GPG 키 추가 + curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -## 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 저장소 추가. -add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" - -## Docker 설치. +## Docker ce 설치. apt-get update && apt-get install docker-ce=18.06.0~ce~3-0~ubuntu # 데몬 설정. @@ -68,20 +67,17 @@ systemctl restart docker {{< /tab >}} {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -# CentOS/RHEL 저장소를 통한 Docker 설치: -yum install -y docker +# Docker CE 설치 +## 저장소 설정 +### 필요한 패키지 설치. + yum install yum-utils device-mapper-persistent-data lvm2 -# 또는 Docker의 CentOS 저장소를 통한 Docker CE 18.06 설치: - -## 선행 조건들 설치. -yum install yum-utils device-mapper-persistent-data lvm2 - -## Docker 저장소 추가. +### Docker 저장소 추가 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo -## Docker 설치. +## Docker ce 설치. yum update && yum install docker-ce-18.06.1.ce ## /etc/docker 디렉토리 생성. diff --git a/content/ko/docs/setup/minikube.md b/content/ko/docs/setup/minikube.md index 0246b91cc6..ca501a7f2c 100644 --- a/content/ko/docs/setup/minikube.md +++ b/content/ko/docs/setup/minikube.md @@ -1,31 +1,36 @@ --- title: Minikube로 로컬 상에서 쿠버네티스 구동 +content_template: templates/concept --- -Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day. +{{% capture overview %}} -{{< toc >}} +Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. +Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 VM 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다. -### Minikube 특징 +{{% /capture %}} -* Minikube supports Kubernetes features such as: +{{% capture body %}} + +## Minikube 특징 + +* Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. * DNS - * NodePorts - * ConfigMaps and Secrets - * Dashboards - * Container Runtime: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) and [containerd](https://github.com/containerd/containerd) - * Enabling CNI (Container Network Interface) - * Ingress + * 노드 포트 + * 컨피그 맵과 시크릿 + * 대시보드 + * 컨테이너 런타임: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd) + * CNI(Container Network Interface) 사용 + * 인그레스 ## 설치 -See [Installing Minikube](/docs/tasks/tools/install-minikube/). +[Minikube 설치](/ko/docs/tasks/tools/install-minikube/) 항목을 보자. ## 빠른 시작 -Here's a brief demo of minikube usage. -If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports -the following drivers: +여기부터는 Minikube 사용에 대한 간단한 데모이다. +VM 드라이버를 바꾸기 원하면 적절한 `--vm-driver=xxx` 플래그를 `minikube start`에 추가한다. Minikube는 다음의 드라이버를 지원한다. * virtualbox * vmwarefusion @@ -34,7 +39,8 @@ the following drivers: * hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) * xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated) -Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`. +아래 나오는 IP 주소는 동적이므로 바뀔 수 있다. `minikube ip`를 하면 알 수 있다. + ```shell $ minikube start @@ -101,7 +107,7 @@ Stopping "minikube"... #### containerd -To use [containerd](https://github.com/containerd/containerd) as the container runtime, run: +[containerd](https://github.com/containerd/containerd)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```bash $ minikube start \ @@ -110,7 +116,7 @@ $ minikube start \ --bootstrapper=kubeadm ``` -Or you can use the extended version: +혹은 확장 버전을 사용할 수 있다. ```bash $ minikube start \ @@ -123,7 +129,7 @@ $ minikube start \ #### CRI-O -To use [CRI-O](https://github.com/kubernetes-incubator/cri-o) as the container runtime, run: +[CRI-O](https://github.com/kubernetes-incubator/cri-o)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```bash $ minikube start \ @@ -132,7 +138,7 @@ $ minikube start \ --bootstrapper=kubeadm ``` -Or you can use the extended version: +혹은 확장 버전을 사용할 수 있다. ```bash $ minikube start \ @@ -145,7 +151,7 @@ $ minikube start \ #### rkt 컨테이너 엔진 -To use [rkt](https://github.com/rkt/rkt) as the container runtime run: +[rkt](https://github.com/rkt/rkt)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```shell $ minikube start \ @@ -153,37 +159,41 @@ $ minikube start \ --container-runtime=rkt ``` -This will use an alternative minikube ISO image containing both rkt, and Docker, and enable CNI networking. +이것은 rkt와 Docker와 CNI 네트워킹을 포함하는 대안적인 Minikube ISO 이미지를 이용한다. ### 드라이버 플러그인 -See [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) for details on supported drivers and how to install -plugins, if required. +지원하는 드라이버 상세 정보와 설치방법은 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 살펴보자 꼭 필요하다면 말이다. -### 도커 데몬 재사용 +### Docker 데몬 재사용 -When using a single VM of Kubernetes, it's really handy to reuse the minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet. +쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 Docker 데몬을 재사용하기에 매우 간편하다. +이 경우는 호스트 장비에 Docker 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. +또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 Docker 데몬 안에서 이미지를 빌드하기 때문이다. +Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. +혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, +만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다. -To be able to work with the docker daemon on your mac/linux host use the `docker-env command` in your shell: +맥이나 리눅스 호스트의 Docker 데몬에서 이 작업이 가능하게 하려면 `docker-env command`를 쉘에서 사용해야 한다. -``` +```shell eval $(minikube docker-env) ``` -You should now be able to use docker on the command line on your host mac/linux machine talking to the docker daemon inside the minikube VM: +맥이나 리눅스 호스트에서 Minikube VM안에 Docker 데몬과 통신하도록 Docker를 명령행에서 사용할 수 있어야 한다. -``` +```shell docker ps ``` -On Centos 7, docker may report the following error: +Centos 7 에서 Docker는 아래와 같은 오류를 발생한다. -``` +```shell Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory ``` -The fix is to update /etc/sysconfig/docker to ensure that minikube's environment changes are respected: +해결 방법은 /etc/sysconfig/docker를 Minikube의 환경 변화를 기대한 것대로 바꾸도록 업데이트하는 것이다. -``` +```shell < DOCKER_CERT_PATH=/etc/docker --- > if [ -z "${DOCKER_CERT_PATH}" ]; then @@ -191,32 +201,32 @@ The fix is to update /etc/sysconfig/docker to ensure that minikube's environment > fi ``` -Remember to turn off the imagePullPolicy:Always, as otherwise Kubernetes won't use images you built locally. +imagePullPolicy:Always를 꺼야하는 것은 명심하자. 그렇지 않으면 쿠버네티스가 로컬에서 빌드한 이미지를 사용하지 않는다. ## 클러스터 관리 ### 클러스터 시작 -The `minikube start` command can be used to start your cluster. -This command creates and configures a virtual machine that runs a single-node Kubernetes cluster. -This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster. +`minikube start` 명령은 클러스터를 시작하는데 사용할 수 있다. +이 명령은 단일 노드 쿠버네티스 클러스터를 실행하는 가상머신을 생성하고 구성한다. +또한 클러스터와 통신하기 위해 [kubectl](/docs/user-guide/kubectl-overview/)를 구성한다. -If you are behind a web proxy, you will need to pass this information in e.g. via +만약 웹 프록시를 사용 중이라면 `minikube start` 명령에서 이 정보를 포함해야 한다. -``` +```shell https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 ``` -Unfortunately just setting the environment variables will not work. +불행히 환경 설정 변수만으로는 동작하지 않는다. + +Minikube는 또한 "minikube" 컨텍스트를 생성하고, kubectl의 기본값으로 설정한다. +나중에 이 컨택스트를 변경하려면, `kubectl config use-context minikube` 명령을 실행하자. -Minikube will also create a "minikube" context, and set it to default in kubectl. -To switch back to this context later, run this command: `kubectl config use-context minikube`. #### 쿠버네티스 버전 지정 -You can specify the specific version of Kubernetes for Minikube to use by -adding the `--kubernetes-version` string to the `minikube start` command. For -example, to run version `v1.7.3`, you would run the following: +Minikube에서 사용할 쿠버네티스 버전은 `--kubernetes-version` 문자열을 `minikube start` 명령에 추가하여 지정할 수 있다. +예를 들어, `v1.7.3`을 이용한다면 아래처럼 할 수 있다. ``` minikube start --kubernetes-version v1.7.3 @@ -224,57 +234,54 @@ minikube start --kubernetes-version v1.7.3 ### 쿠버네티스 구성 -Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values. -To use this feature, you can use the `--extra-config` flag on the `minikube start` command. +Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설정할 수 있도록 하는 '설정기' 기능이 있다. +이 기능을 사용하려면, `--extra-config` 플래그를 `minikube start` 명령어에 추가하여야 한다. -This flag is repeated, so you can pass it several times with several different values to set multiple options. +이 플래그는 여러번 쓸 수 있어 여러 옵션 설정을 전달 할 수 있다. -This flag takes a string of the form `component.key=value`, where `component` is one of the strings from the below list, `key` is a value on the -configuration struct and `value` is the value to set. +이 플래그는 `component.key=value`형식의 문자열로, 앞에 `component`는 아래 목록에 하나의 문자열이며 `key`는 configuration struct의 값이고 `value`는 설정할 값이다(역주: key는 struct의 맴버명). -Valid keys can be found by examining the documentation for the Kubernetes `componentconfigs` for each component. -Here is the documentation for each supported configuration: +올바른 키들은 각 컴포넌트의 쿠버네티스 `componentconfigs` 문서에서 찾아 볼 수 있다. +다음은 각각의 지원하는 설정에 대한 문서이다. * [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig#KubeletConfiguration) * [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions) -* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/kubeproxyconfig#KubeProxyConfiguration) -* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/apis/componentconfig#KubeControllerManagerConfiguration) +* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration) +* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration) * [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig) -* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/apis/componentconfig#KubeSchedulerConfiguration) +* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration) #### 예제 -To change the `MaxPods` setting to 5 on the Kubelet, pass this flag: `--extra-config=kubelet.MaxPods=5`. +쿠블렛에서 `MaxPods` 설정을 5로 바꾸려면 `--extra-config=kubelet.MaxPods=5` 플래그를 전달하자. -This feature also supports nested structs. To change the `LeaderElection.LeaderElect` setting to `true` on the scheduler, pass this flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`. +이 기능은 또한 중첩 구조를 지원한다. 스케쥴러에서 `LeaderElection.LeaderElect` 설정을 `true`로 하려면, `--extra-config=scheduler.LeaderElection.LeaderElect=true` 플래그를 전달하자. -To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.Authorization.Mode=RBAC`. +`apiserver`에서 `AuthorizationMode`를 `RBAC`으로 바꾸려면, `--extra-config=apiserver.authorization-mode=RBAC`를 사용할 수 있다. ### 클러스터 중지 -The `minikube stop` command can be used to stop your cluster. -This command shuts down the minikube virtual machine, but preserves all cluster state and data. -Starting the cluster again will restore it to it's previous state. +`minikube stop` 명령어는 클러스터를 중지하는데 사용할 수 있다. +이 명령어는 Minikube 가상 머신을 종료하지만, 모든 클러스터 상태와 데이터를 보존한다. +클러스터를 다시 시작하면 이전의 상태로 돌려줍니다. ### 클러스터 삭제 -The `minikube delete` command can be used to delete your cluster. -This command shuts down and deletes the minikube virtual machine. No data or state is preserved. +`minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. +이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. ## 클러스터와 상호 작용 ### Kubectl -The `minikube start` command creates a "[kubectl context](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)" called "minikube". -This context contains the configuration to communicate with your minikube cluster. +`minikube start` 명령어는 Minikube로 부르는 "[kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)" 를 생성한다. +이 컨텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. -Minikube sets this context to default automatically, but if you need to switch back to it in the future, run: +Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 `kubectl config use-context minikube`을 실행하자. -`kubectl config use-context minikube`, - -Or pass the context on each command like this: `kubectl get pods --context=minikube`. +혹은 각 명령어를 `kubectl get pods --context=minikube`처럼 컨텍스트를 전달하십시오. ### 대시보드 -To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting minikube to get the address: +[쿠버네티스 대시보드](/docs/tasks/access-application-cluster/web-ui-dashboard/)를 이용하려면, Minikube를 실행한 후 쉘에서 아래 명령어를 실행하여 주소를 확인한다. ```shell minikube dashboard @@ -282,7 +289,7 @@ minikube dashboard ### 서비스 -To access a service exposed via a node port, run this command in a shell after starting minikube to get the address: +노드 포트로 노출된 서비스를 접근하기 위해, Minikube를 시작한 이후 쉘에서 아래 명령어를 실행하여 주소를 확인하자. ```shell minikube service [-n NAMESPACE] [--url] NAME @@ -290,25 +297,25 @@ minikube service [-n NAMESPACE] [--url] NAME ## 네트워킹 -The minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command. -Any services of type `NodePort` can be accessed over that IP address, on the NodePort. +Minikube VM은 host-only IP 주소를 통해 호스트 시스템에 노출되고, 이 IP 주소는 `minikube ip` 명령어로 확인할 수 있다. +`NodePort` 서비스 타입은 IP 주소에 해당 노드 포트로 접근할 수 있다. -To determine the NodePort for your service, you can use a `kubectl` command like this: +서비스의 NodePort를 확인하려면 `kubectl` 명령어로 아래와 같이 하면 된다. `kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'` ## 퍼시스턴트 볼륨 -Minikube supports [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) of type `hostPath`. -These PersistentVolumes are mapped to a directory inside the minikube VM. +Minikube는 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 `hostPath` 타입으로 지원한다. +이런 퍼시스턴트 볼륨은 Minikube VM 내에 디렉터리로 매핑됩니다. -The Minikube VM boots into a tmpfs, so most directories will not be persisted across reboots (`minikube stop`). -However, Minikube is configured to persist files stored under the following host directories: +Minikube VM은 tmpfs에서 부트하는데, 매우 많은 디렉터리가 재부트(`minikube stop`)까지는 유지되지 않다. +그러나, Minikube는 다음의 호스트 디렉터리 아래 파일은 유지하도록 설정되어 있다. * `/data` -* `/var/lib/localkube` +* `/var/lib/rinikube` * `/var/lib/docker` -Here is an example PersistentVolume config to persist data in the `/data` directory: +이것은 `/data` 디렉터리에 데이터를 보존하도록 한 퍼시스턴트 볼륨 환경설정의 예이다. ```yaml apiVersion: v1 @@ -325,9 +332,11 @@ spec: ``` ## 호스트 폴더 마운트 -Some drivers will mount a host folder within the VM so that you can easily share files between the VM and host. These are not configurable at the moment and different for the driver and OS you are using. +몇몇 드라이버는 VM 안에 호스트 폴더를 마운트하여 VM과 호스트 사이에 쉽게 파일을 공유할 수 있게 한다. 이들은 지금 설정할 수 없고 사용하는 드라이버나 운영체제에 따라 다르다. -**Note:** Host folder sharing is not implemented in the KVM driver yet. +{{< note >}} +호스트 폴더 공유는 KVM 드라이버에서 아직 구현되어 있지 않다. +{{< /note >}} | Driver | OS | HostFolder | VM | | --- | --- | --- | --- | @@ -337,62 +346,62 @@ Some drivers will mount a host folder within the VM so that you can easily share | VMware Fusion | macOS | /Users | /Users | | Xhyve | macOS | /Users | /Users | - ## 프라이빗 컨테이너 레지스트리 -To access a private container registry, follow the steps on [this page](/docs/concepts/containers/images/). +프라이빗 컨테이너 레지스트리를 이용하려면, [이 페이지](/docs/concepts/containers/images/)의 단계를 따르자. -We recommend you use `ImagePullSecrets`, but if you would like to configure access on the minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory. +`ImagePullSecrets`를 이용하기를 권하지만, Minikube VM 상에서 설정하려 한다면 `/home/docker` 디렉터리에 `.dockercfg`를 두거나 `/home/docker/.docker` 디렉터리에 `config.json`을 둘 수 있다. ## 애드온 -In order to have minikube properly start or restart custom addons, -place the addons you wish to be launched with minikube in the `~/.minikube/addons` -directory. Addons in this folder will be moved to the minikube VM and -launched each time minikube is started or restarted. +Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, +Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터리에 두자. +폴더 내부의 애드온은 Minikube VM으로 이동되어 Minikube가 시작하거나 재시작될 때에 함께 실행된다. ## HTTP 프록시 환경에서 Minikube 사용 -Minikube creates a Virtual Machine that includes Kubernetes and a Docker daemon. -When Kubernetes attempts to schedule containers using Docker, the Docker daemon may require external network access to pull containers. +Minikube는 쿠버네티스와 Docker 데몬을 포함한 가상 머신을 생성한다. +쿠버네티스가 Docker를 이용하여 컨테이너를 스케쥴링 시도할 때에, Docker 데몬은 컨테이너 이미지를 풀링하기 위해 외부 네트워크를 이용해야 한다. -If you are behind an HTTP proxy, you may need to supply Docker with the proxy settings. -To do this, pass the required environment variables as flags during `minikube start`. +HTTP 프록시 내부라면, Docker에서 프록시 설정을 해야 한다. +이를 하기 위해서 요구되는 환경 변수를 `minikube start` 중에 플래그로 전달한다. -For example: +예를 들어: ```shell $ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ --docker-env https_proxy=https://$YOURPROXY:PORT ``` -If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent kubectl from directly reaching it. -To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with: +만약 가상 머신 주소가 192.168.99.100 이라면 프록시 설정이 `kubectl`에 직접적으로 도달하지 못할 수도 있다. +이 IP 주소에 대해 프록시 설정을 지나치게 하려면 no_proxy 설정을 수정해야 한다. 다음과 같이 할 수 있다. ```shell $ export no_proxy=$no_proxy,$(minikube ip) ``` ## 알려진 이슈 -* Features that require a Cloud Provider will not work in Minikube. These include: - * LoadBalancers -* Features that require multiple nodes. These include: - * Advanced scheduling policies +* 클라우드 공급자를 필요로 하는 기능은 Minikube에서 동작하지 않는다. 여기에는 다음이 포함된다. + * 로드밸런서 +* 다중 노드를 위한 기능들이다. 여기에는 다음이 포함된다. + * 진보된 스케쥴링 정책 ## 설계 -Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [localkube](https://git.k8s.io/minikube/pkg/localkube) (originally written and donated to this project by [RedSpread](https://github.com/redspread)) for running the cluster. +Minikube는 VM 프로비저닝을 위해서 [libmachine](https://github.com/docker/machine/tree/master/libmachine)를 사용하고, 쿠버네티스 클러스터를 프로비저닝하기 위해 [kubeadm](https://github.com/kubernetes/kubeadm)을 사용한다. -For more information about minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md). +Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md) 부분을 읽어보자. ## 추가적인 링크: -* **Goals and Non-Goals**: For the goals and non-goals of the minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md). -* **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests. -* **Building Minikube**: For instructions on how to build/test minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md) -* **Adding a New Dependency**: For instructions on how to add a new dependency to minikube see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md) -* **Adding a New Addon**: For instruction on how to add a new addon for minikube see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md) -* **Updating Kubernetes**: For instructions on how to update kubernetes see the [updating Kubernetes guide](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md) + +* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://git.k8s.io/minikube/docs/contributors/roadmap.md)을 살펴보자. +* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [참여 가이드](https://git.k8s.io/minikube/CONTRIBUTING.md)를 살펴보자. +* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://git.k8s.io/minikube/docs/contributors/build_guide.md)를 살펴보자. +* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는 [의존성 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)를 보자. +* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는 [애드온 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)를 보자. ## 커뮤니티 -Contributions, questions, and comments are all welcomed and encouraged! minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ". +컨트리뷰션, 질문과 의견은 모두 환영하며 격려한다! Minikube 개발자는 [슬랙](https://kubernetes.slack.com)에 #minikube 채널(초청받으려면 [여기](http://slack.kubernetes.io/))에 상주하고 있다. 또한 [kubernetes-dev 구글 그룹 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-dev)도 있다. 메일링 리스트에 포스팅한다면 제목에 "minikube: "라는 접두어를 사용하자. + +{{% /capture %}} diff --git a/content/ko/docs/setup/multiple-zones.md b/content/ko/docs/setup/multiple-zones.md index e00d6f6dba..b2360a9fe2 100644 --- a/content/ko/docs/setup/multiple-zones.md +++ b/content/ko/docs/setup/multiple-zones.md @@ -122,10 +122,10 @@ and `failure-domain.beta.kubernetes.io/zone` for the zone: NAME STATUS ROLES AGE VERSION LABELS -kubernetes-master Ready,SchedulingDisabled 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master -kubernetes-minion-87j9 Ready 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 -kubernetes-minion-9vlv Ready 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv -kubernetes-minion-a12q Ready 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q +kubernetes-master Ready,SchedulingDisabled 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master +kubernetes-minion-87j9 Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 +kubernetes-minion-9vlv Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv +kubernetes-minion-a12q Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q ``` ### 두번째 영역에 더 많은 노드 추가하기 @@ -157,13 +157,13 @@ in us-central1-b: > kubectl get nodes --show-labels NAME STATUS ROLES AGE VERSION LABELS -kubernetes-master Ready,SchedulingDisabled 16m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master -kubernetes-minion-281d Ready 2m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d -kubernetes-minion-87j9 Ready 16m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 -kubernetes-minion-9vlv Ready 16m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv -kubernetes-minion-a12q Ready 17m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q -kubernetes-minion-pp2f Ready 2m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f -kubernetes-minion-wf8i Ready 2m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i +kubernetes-master Ready,SchedulingDisabled 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master +kubernetes-minion-281d Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d +kubernetes-minion-87j9 Ready 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 +kubernetes-minion-9vlv Ready 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv +kubernetes-minion-a12q Ready 17m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q +kubernetes-minion-pp2f Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f +kubernetes-minion-wf8i Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i ``` ### 볼륨 어피니티 @@ -286,9 +286,9 @@ Node: kubernetes-minion-olsh/10.240.0.11 > kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels NAME STATUS ROLES AGE VERSION LABELS -kubernetes-minion-9vlv Ready 34m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv -kubernetes-minion-281d Ready 20m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d -kubernetes-minion-olsh Ready 3m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh +kubernetes-minion-9vlv Ready 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv +kubernetes-minion-281d Ready 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d +kubernetes-minion-olsh Ready 3m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh ``` diff --git a/content/ko/docs/setup/pick-right-solution.md b/content/ko/docs/setup/pick-right-solution.md index d184047eb5..2484badf98 100644 --- a/content/ko/docs/setup/pick-right-solution.md +++ b/content/ko/docs/setup/pick-right-solution.md @@ -29,6 +29,8 @@ content_template: templates/concept * [Minikube](/docs/setup/minikube/)는 개발과 테스트를 위한 단일 노드 쿠버네티스 클러스터를 로컬에 생성하기 위한 하나의 방법이다. 설치는 완전히 자동화 되어 있고, 클라우드 공급자 계정 정보가 필요하지 않다. +* [Minishift](https://docs.okd.io/latest/minishift/)는 커뮤니티 버전의 쿠버네티스 엔터프라이즈 플랫폼 OpenShift를 로컬 개발과 테스트 용으로 설치한다. Windows, macOS와 리눅스를 위한 All-In-One VM (`minishift start`)과 컨테이너 기반의 `oc cluster up` (리눅스 전용)을 지원하고 [쉬운 설치가 가능한 몇 가지 애드온도 포함](https://github.com/minishift/minishift-addons/tree/master/add-ons)한다. + * [microk8s](https://microk8s.io/)는 개발과 테스트를 위한 쿠버네티스 최신 버전을 단일 명령어로 로컬 머신 상의 설치를 제공한다. 설치는 신속하고 빠르며(~30초) 단일 명령어로 Istio를 포함한 많은 플러그인을 지원한다. * [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private)는 개발과 테스트 시나리오를 위해 1개 또는 더 많은 VM에 쿠버네티스를 배포하기 위해서 머신의 VirtualBox를 사용할 수 있다. 이는 전체 멀티 노드 클러스터로 확장할 수 있다. @@ -49,6 +51,10 @@ content_template: templates/concept * [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/)는 관리형 쿠버네티스 클러스터를 제공한다. +* [Containership Kubernetes Engine (CKE)](https://containership.io/containership-platform)는 GCP, Azure, AWS, Packet과 DigitalOcean 상에서 직관적인 쿠버네티스 클러스터 프로비저닝과 관리 기능을 제공한다. 매끄러운 버전 업그레이드, 오토스케일링, 메트릭, 워크로드 생성 등을 지원한다. + +* [DigitalOcean Kubernetes](https://www.digitalocean.com/products/kubernetes/) 관리형 쿠버네티스 서비스를 제공한다. + * [Giant Swarm](https://giantswarm.io/product/)은 온-프레미스 또는 퍼블릭 클라우드 데이터센터 내에서 관리형 쿠버네티스 클러스터를 제공한다. * [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)은 관리형 쿠버네티스 클러스터를 제공한다. @@ -71,9 +77,9 @@ 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. +* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/)는 자체 OpenStack 퍼블릭 클라우드 상에서 서비스로써 관리형 쿠버네티스를 제공한다. 라이프사이클 관리, 관리 대시보드, 모니터링, 오토스케일링과 그 밖에 많은 기능을 포함한다. -* [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. +* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)는 사용하기 쉽고, 기본적으로 안전하며, 비용 효율적인 SaaS 기반의 쿠버네티스 클러스터를 제공하는 VMWare 클라우드 서비스 포트폴리오의 엔터프라이즈 Kubernetes-as-a-Service 오퍼링이다. ## 턴키 클라우드 솔루션 @@ -86,6 +92,7 @@ content_template: templates/concept * [Azure](/docs/setup/turnkey/azure/) * [CenturyLink Cloud](/docs/setup/turnkey/clc/) * [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](/docs/getting-started-guides/ubuntu/) +* [Containership](https://containership.io/containership-platform) * [Gardener](https://gardener.cloud/) * [Google Compute Engine (GCE)](/docs/setup/turnkey/gce/) * [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer) @@ -93,6 +100,7 @@ content_template: templates/concept * [Kubermatic](https://cloud.kubermatic.io) * [Kublr](https://kublr.com/) * [Madcore.Ai](https://madcore.ai/) +* [Nirmata](https://nirmata.com/) * [Oracle Container Engine for K8s](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm) * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) * [Giant Swarm](https://giantswarm.io) @@ -111,6 +119,8 @@ content_template: templates/concept * [Kontena Pharos](https://kontena.io/pharos/) * [Kubermatic](https://www.loodse.com) * [Kublr](https://kublr.com/) +* [Nirmata](https://nirmata.com/) +* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com) * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) * [Giant Swarm](https://giantswarm.io) * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) @@ -146,6 +156,7 @@ content_template: templates/concept * [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (Ansible, CoreOS와 flannel를 사용) * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (Fedora와 flannel를 사용) +* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) * [oVirt](/docs/setup/on-premises-vm/ovirt/) * [Vagrant](/docs/setup/custom-cloud/coreos/) (CoreOS와 flannel를 사용) * [VMware](/docs/setup/custom-cloud/coreos/) (CoreOS와 flannel를 사용) @@ -159,6 +170,7 @@ content_template: templates/concept * [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/) * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) +* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) ### 통합 @@ -176,6 +188,7 @@ IaaS 공급자 | 구성 관리 | OS | 네트워킹 | 문서 -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------------------------- any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle)) Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial +Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai)) diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index ecfa9464af..bc8a8d0a56 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -22,27 +22,83 @@ weight: 20 하이퍼바이저가 설치되어 있지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다. -* macOS: [VirtualBox](https://www.virtualbox.org/wiki/Downloads), -[VMware Fusion](https://www.vmware.com/products/fusion), 또는 -[HyperKit](https://github.com/moby/hyperkit). +Operating system | Supported hypervisors +:----------------|:--------------------- +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/) +Windows | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) -* 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). +{{< note >}} +Minikube는 쿠버네티스 컴포넌트들이 VM 안에서가 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 Docker와 linux 환경을 필요로 한다. +{{< /note >}} ## kubectl 설치 -* [kubectl 설치 및 설정](/docs/tasks/tools/install-kubectl/)의 지침에 따라 kubectl을 설치한다. +* [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) 지침에 따라 kubectl을 설치한다. ## Minikube 설치 -* [최신 릴리스](https://github.com/kubernetes/minikube/releases)의 지침에 따라 Minikube를 설치한다. +### macOS + +macOS에 Minikube를 설치하는 가장 쉬운 방법은 [Homebrew](https://brew.sh)을 사용하는 것이다. + +```shell +brew cask install minikube +``` + +정적 바이너리를 내려받아서 macOS에 설치할 수도 있다. + +```shell +curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ + && chmod +x minikube +``` + +Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같다. + +```shell +sudo cp minikube /usr/local/bin && rm minikube +``` + +### Linux + +{{< note >}} +이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다. 리눅스에 설치하는 다른 방법은, 공식 Minikube GitHub 저장소의 [Other Ways to Install](https://github.com/kubernetes/minikube#other-ways-to-install)를 참조한다. +{{< /note >}} + +정적 바이너리를 내려받아서 리눅스에 Minikube를 설치할 수 있따. + +```shell +curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \ + && chmod +x minikube +``` + +Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같다. + +```shell +sudo cp minikube /usr/local/bin && rm minikube +``` + +### Windows + +{{< note >}} +Minikube를 Windows에서 실행하려면, 우선 [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)를 설치할 필요가 있다. Hyper-V는 Windows 10 Enterprise, Windows 10 Professional 과 Windows 10 Education 세 버전의 Windows 10에서 동작한다. +{{< /note >}} + +Windows에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다. (관리자 권한으로 실행) + +```shell +choco install minikube kubernetes-cli +``` + +Minikube 설치를 마친 뒤에, 현재 CLI 세션을 닫고 재시작한다. Minikube가 경로에 자동으로 추가되어 있어야 정상이다. + +#### Windows 수동 설치 + +Windows에 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서, 이름을 `minikube.exe`로 변경하고, 경로에 추가한다. + +#### Windows 인스톨러 + +[Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)를 사용해서 Windows에 Minikube를 수동으로 설치하려면 [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 인스톨러를 실행한다. {{% /capture %}} diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index b422d3f17c..0909d4cb9a 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -12,428 +12,246 @@ menu: {{% capture overview %}} -이 튜토리얼의 목표는 Node.js 로 작성된 간단한 Hello World 애플리케이션을 쿠버네티스에서 실행되는 -애플리케이션으로 변환하는 것이다. 튜토리얼을 통해 로컬에서 작성된 코드를 Docker 컨테이너 이미지로 -변환한 다음, [Minikube](/docs/getting-started-guides/minikube)에서 해당 이미지를 실행하는 -방법을 보여 준다. Minikube는 무료로 로컬 머신을 이용해서 쿠버네티스를 실행할 수 있는 간단한 방법을 -제공한다. +이 튜토리얼에서는 [Minikube](/docs/getting-started-guides/minikube)와 Katacoda를 이용하여 +쿠버네티스에서 Node.js 로 작성된 간단한 Hello World 애플리케이션을 어떻게 실행하는지 살펴본다. +Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. + +{{< note >}} +[로컬에서 Minikube](/ko/docs/tasks/tools/install-minikube/)를 설치했다면 이 튜토리얼도 따라할 수 있다. +{{< /note >}} {{% /capture %}} {{% capture objectives %}} -* Node.js로 hello world 애플리케이션을 실행한다. -* Minikube에 만들어진 애플리케이션을 배포한다. -* 애플리케이션 로그를 확인한다. -* 애플리케이션 이미지를 업데이트한다. - +* hello world 애플리케이션을 Minikube에 배포한다. +* 배포한 애플리케이션을 실행한다. +* 애플리케이션의 로그를 확인한다. {{% /capture %}} {{% capture prerequisites %}} -* macOS의 경우, [Homebrew](https://brew.sh)를 사용하여 Minikube를 설치할 수 있다. +이 튜토리얼에서 아래 파일들을 빌드한 컨테이너 이미지를 제공한다. - {{< note >}} - **참고:** macOS 10.13 버전으로 업데이트 후 `brew update`를 실행 시 Homebrew에서 다음과 같은 오류가 발생할 경우에는, +{{< codenew language="js" file="minikube/server.js" >}} - ```shell - Error: /usr/local is not writable. You should change the ownership - and permissions of /usr/local back to your user account: - sudo chown -R $(whoami) /usr/local - ``` - Homebrew를 다시 설치하여 문제를 해결할 수 있다. - ```shell - /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" - ``` - {{< /note >}} - -* 예제 애플리케이션을 실행하기 위해서는 [NodeJS](https://nodejs.org/en/)가 필요하다. - -* Docker를 설치한다. macOS의 경우, -[Docker for Mac](https://docs.docker.com/engine/installation/mac/)를 권장한다. +{{< codenew language="conf" file="minikube/Dockerfile" >}} +`docker build`명령에 대한 자세한 설명은 [Docker 문서](https://docs.docker.com/engine/reference/commandline/build/)를 읽어보자. {{% /capture %}} {{% capture lessoncontent %}} -## Minikube 클러스터 만들기 +## Minikubue 클러스터 만들기 -이 튜토리얼에서는 [Minikube](https://github.com/kubernetes/minikube)를 사용하여 -로컬 클러스터를 만든다. 이 튜토리얼에서는 macOS에서 -[Docker for Mac](https://docs.docker.com/engine/installation/mac/)을 -사용한다고 가정하였다. Docker for Mac 대신 Linux 혹은 VirtualBox와 같이 다른 플랫폼을 -사용하는 경우, Minikube를 설치하는 방법이 약간 다를 수 있다. 일반적인 Minikube 설치 지침은 -[Minikube installation guide](/docs/getting-started-guides/minikube/) -를 참조한다. +1. **Launch Terminal** 을 클릭 -Homebrew를 사용하여 최신 버전의 Minikube를 설치한다. -```shell -brew cask install minikube -``` + {{< kat-button >}} -[Minikube driver installation guide](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperkit-driver)에 -설명한 것과 같이 HyperKit 드라이버를 설치한다. + {{< note >}}Minikube를 로컬에 설치했다면 `minikube start`을 실행한다.{{< /note >}} -Homebrew를 사용하여 쿠버네티스 클러스터와 상호 작용을 위한 -`kubectl` 명령줄 도구를 다운로드한다. +2. 브라우저에서 쿠버네티스 대시보드를 열어보자. -```shell -brew install kubernetes-cli -``` + ```shell + minikube dashboard + ``` -프록시를 거치지않고 직접 [https://cloud.google.com/container-registry/](https://cloud.google.com/container-registry/)같은 사이트에 액세스 할 수 있는지 확인하려면 새 터미널을 열고 다음과 같이 실행한다. +3. Katacoda 환경에서는: 터미널 패널의 상단에서 플러스를 클릭하고, 이어서 **Select port to view on Host 1**를 클릭 -```shell -curl --proxy "" https://cloud.google.com/container-registry/ -``` - -Docker 데몬이 시작되었는지 확인한다. Docker가 실행 중인지는 다음과 같은 커맨드를 사용하여 확인할 수 있다. - -```shell -docker images -``` - -프록시가 필요하지 않은 경우, Minikube 클러스터를 시작한다. - -```shell -minikube start --vm-driver=hyperkit -``` -프록시가 필요한 경우, 다음 방법을 사용하여 프록시 설정과 함께 Minikube 클러스터를 시작할 수 있다. - -```shell -minikube start --vm-driver=hyperkit --docker-env HTTP_PROXY=http://your-http-proxy-host:your-http-proxy-port --docker-env HTTPS_PROXY=http(s)://your-https-proxy-host:your-https-proxy-port -``` - -`--vm-driver=hyperkit` 플래그는 Docker for Mac을 사용하고 있음을 의미한다. -기본 VM 드라이버는 VirtualBox이다. - -이제 Minikube 컨텍스트를 설정한다. 컨텍스트는 'kubectl'이 어떠한 클러스터와 상호 작용하려고 -하는지를 결정한다. `~/.kube/config` 파일에 사용 가능한 모든 컨텍스트가 들어있다. - -```shell -kubectl config use-context minikube -``` - -`kubectl`이 클러스터와 통신할 수 있도록 설정되어 있는지 확인한다. - -```shell -kubectl cluster-info -``` - -브라우저에서 쿠버네티스 대시보드를 연다. - -```shell -minikube dashboard -``` - -## Node.js 애플리케이션 만들기 - -다음 단계에서는 애플리케이션을 작성해 본다. 아래 코드를 `hellonode` 폴더에 -`server.js`라는 이름으로 저장한다. - -{{< codenew language="js" file="minikube/server.js" >}} - -작성된 애플리케이션을 실행한다. - -```shell -node server.js -``` - -[http://localhost:8080/](http://localhost:8080/)에 접속하면 "Hello World!"라는 메시지를 확인할 수 있을 것이다. - -**Ctrl-C**를 입력하면 실행 중인 Node.js 서버가 중단된다. - -다음 단계는 작성된 애플리케이션을 Docker 컨테이너에 패키지하는 것이다. - -## Docker 컨테이너 이미지 만들기 - -앞에서 사용하였던 `hellonode` 폴더에 `Dockerfile`이라는 이름으로 파일을 만든다. Dockerfile -은 빌드하고자 하는 이미지를 기술한 파일이다. 기존 이미지를 확장하여 Docker -컨테이너 이미지를 빌드할 수 있다. 이 튜토리얼에서는 기존 Node.js 이미지를 확장하여 사용한다. - -{{< codenew language="conf" file="minikube/Dockerfile" >}} - -본 레시피는 Docker 레지스트리에 있는 공식 Node.js LTS 이미지로부터 시작해서, -8080 포트를 열고, `server.js` 파일을 이미지에 복사하고 -Node.js 서버를 시작한다. - -기본적으로, Docker는 로컬 머신의 Docker 레지스트리에 이미지를 생성하고 저장한다. -이 튜토리얼에서는, 로컬 머신의 Docker 레지스트리를 사용하지 않고 Minikube의 -VM 인스턴스 _속에서_ 구동 중인 Docker 데몬의 레지스트리를 사용한다. 'docker' 명령이 -Minikube의 Docker 데몬을 가르키도록 하려면 다음과 같이 입력한다. (unix 셀) - -```shell -eval $(minikube docker-env) -``` - -powershell에서는 다음과 같이 입력한다. -```shell -minikube docker-env | Invoke-Expression -``` - - - -{{< note >}} -**참고:** 나중에 Minikube 호스트를 더 이상 사용하고 싶지 않은 경우, -`eval $ (minikube docker-env -u)`를 실행하여 변경을 되돌릴 수 있다. -{{< /note >}} - -Minikube Docker 데몬을 사용하여 Docker 이미지를 빌드한다. (마지막의 점에 주의) - -```shell -docker build -t hello-node:v1 . -``` - -Minikube의 Docker 레지스트리에 이미지가 있는 것을 확인한다. - -```shell -minikube ssh docker images -``` - -Output: - -```shell -REPOSITORY TAG IMAGE ID CREATED SIZE -hello-node v1 f82485ca953c 3 minutes ago 655MB -... -node 6.9.2 faaadb4aaf9b 20 months ago 655MB -``` - - -이제 Minikube VM에서 빌드한 이미지를 실행할 수 있다. +4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port**을 클릭. ## 디플로이먼트 만들기 -쿠버네티스 [*파드*](/docs/concepts/workloads/pods/pod/)는 관리 및 네트워크 구성을 목적으로 -함께 묶은 하나 이상의 컨테이너 그룹이다. -이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. -쿠버네티스 [*디플로이먼트*](/docs/concepts/workloads/controllers/deployment/)는 파드의 -헬스를 검사해서 파드의 컨테이너가 종료되면 다시 시작해준다. -파드의 생성 및 확장을 관리하는 방법으로 디플로이먼트를 권장한다. +쿠버네티스 [*파드*](/docs/concepts/workloads/pods/pod/)는 관리와 네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다. +이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스 [*디플로이먼트*](/docs/concepts/workloads/controllers/deployment/)는 파드의 +헬스를 검사해서 파드의 컨테이너가 종료되었다면 재시작해준다. +파드의 생성 및 스케일링을 관리하는 방법으로 디플로이먼트를 권장한다. -`kubectl create` 커맨드를 사용하여 파드를 관리하는 디플로이먼트를 만든다. -파드는 `hello-node:v1` Docker 이미지를 기반으로 한 컨테이너를 실행한다. -(이미지를 레지스트리에 Push하지 않았기 때문에) Docker 레지스트리에서 이미지를 가져오기 보다는, -항상 로컬 이미지를 사용하기 위해 `--image-pull-policy` 플래그를 `Never`로 설정한다. +1. `kubectl create` 명령어를 실행하여 파드를 관리할 디플로이먼트를 만든다. 이 파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다. -```shell -kubectl create deployment hello-node --image=hello-node:v1 --port=8080 --image-pull-policy=Never -``` + ```shell + kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + ``` -디플로이먼트를 확인한다. +2. 디플로이먼트 보기 + ```shell + kubectl get deployments + ``` -```shell -kubectl get deployments -``` + 출력: -출력: + ```shell + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + hello-node 1 1 1 1 1m + ``` +3. 파드 보기 -```shell -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -hello-node 1 1 1 1 3m -``` + ```shell + kubectl get pods + ``` + 출력: -파드를 확인한다. + ```shell + NAME READY STATUS RESTARTS AGE + hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m + ``` +4. 클러스터 이벤트 보기 -```shell -kubectl get pods -``` + ```shell + kubectl get events + ``` -출력: +5. `kubectl` 환경설정 보기 - -```shell -NAME READY STATUS RESTARTS AGE -hello-node-714049816-ztzrb 1/1 Running 0 6m -``` - -클러스터 이벤트를 확인한다. - -```shell -kubectl get events -``` - -`kubectl`의 설정을 확인한다. - -```shell -kubectl config view -``` - -`kubectl` 커맨드에 대한 더 많은 정보를 원하는 경우, -[kubectl overview](/docs/user-guide/kubectl-overview/)를 확인한다. + ```shell + kubectl config view + ``` + + {{< note >}}`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개관](/docs/user-guide/kubectl-overview/)을 살펴보자.{{< /note >}} ## 서비스 만들기 -기본적으로 파드는 쿠버네티스 클러스터 내의 내부 IP 주소로만 접속 가능하다. -쿠버네티스 가상 네트워크 밖에서 `hello-node` 컨테이너에 접속하기 위해서는 파드를 -쿠버네티스 [*서비스*](/docs/concepts/services-networking/service/)로 -노출해야 한다. +기본적으로 파드는 쿠버네티스 클러스터 내부의 IP 주소로만 접근할 수 있다. +`hello-node` 컨테이너를 쿠버네티스 가상 네트워크 외부에서 접근하려면 +파드를 쿠버네티스 [*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다. -개발 환경에서, `kubectl expose` 커맨드를 사용해서 파드를 퍼블릭 인터넷에 -노출할 수 있다. +1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출시키기 -```shell -kubectl expose deployment hello-node --type=LoadBalancer -``` + ```shell + kubectl expose deployment hello-node --type=LoadBalancer --port=8080 + ``` + + `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출시키기 원한다는 뜻이다. -방금 생성한 서비스를 확인한다. +2. 방금 생성한 서비스 살펴보기 -```shell -kubectl get services -``` + ```shell + kubectl get services + ``` -출력: + 출력: -```shell -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -hello-node ClusterIP 10.0.0.71 8080/TCP 6m -kubernetes ClusterIP 10.0.0.1 443/TCP 14d -``` + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s + kubernetes ClusterIP 10.96.0.1 443/TCP 23m + ``` -`--type=LoadBalancer` 플래그는 해당 서비스를 클러스터 바깥으로 노출시키는 -것을 지시한다. 로드 밸런서를 지원하는 클라우드 제공 업체의 경우, 외부 -IP 주소가 프로비저닝되어서 서비스에 접근할 수 있도록 해준다. Minikube에서 -`LoadBalancer` 타입의 서비스는 `minikube service` 커맨드를 통해 접근할 수 있다. + 로드 밸런서를 지원하는 클라우드 공급자의 경우에는 서비스에 접근할 수 있도록 외부 IP 주소가 프로비저닝 한다. + Minikube에서 `LoadBalancer`타입은 `minikube service` 명령어를 통해서 해당 서비스를 접근할 수 있게 한다. -```shell -minikube service hello-node -``` +3. 다음 명령어를 실행한다 -위 커맨드는 앱을 서비스하는 로컬 IP 주소로 브라우저를 자동으로 열어서 -"Hello World" 메세지를 보여준다. + ```shell + minikube service hello-node + ``` -브라우저 또는 curl을 통해 새 웹서비스에 요청을 보내면, 로그가 쌓이는 -것을 확인할 수 있을 것이다. +4. Katacoda 환경에서만: 플러스를 클릭한 후에 **Select port to view on Host 1** 를 클릭. -```shell -kubectl logs -``` +5. Katacoda 환경에서만: 포트 번호를 `8080`로 입력하고, **Display Port** 클릭. -## App 업데이트 + 이렇게 하면 당신의 앱을 서비스하는 브라우저 윈도우를 띄우고 Hellow World" 메시지를 보여준다. -새로운 메시지를 출력하도록 `server.js` 파일을 수정한다. +## 애드온 사용하기 -```javascript -response.end('Hello World Again!'); +Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 애드온 셋이 있다. -``` +1. 현재 지원하는 애드온 목록을 확인한다. -새로운 버전의 이미지를 빌드한다. (마지막의 점에 주의하라) + ```shell + minikube addons list + ``` -```shell -docker build -t hello-node:v2 . -``` + 출력: -디플로이먼트의 이미지를 업데이트한다. + ```shell + addon-manager: enabled + coredns: disabled + dashboard: enabled + default-storageclass: enabled + efk: disabled + freshpod: disabled + heapster: disabled + ingress: disabled + kube-dns: enabled + metrics-server: disabled + nvidia-driver-installer: disabled + nvidia-gpu-device-plugin: disabled + registry: disabled + registry-creds: disabled + storage-provisioner: enabled + ``` + +2. 한 애드온을 활성화 한다. 예를 들어 `heapster` -```shell -kubectl set image deployment/hello-node hello-node=hello-node:v2 -``` + ```shell + minikube addons enable heapster + ``` + + 출력: -앱을 다시 실행하여 새로운 메시지를 확인한다. + ```shell + heapster was successfully enabled + ``` -```shell -minikube service hello-node -``` +3. 방금 생성한 파드와 서비스를 확인한다. -## 애드온 활성화하기 + ```shell + kubectl get pod,svc -n kube-system + ``` -Minikube에는 활성화하거나 비활성화할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 애드온이 있다. + 출력: -우선 현재 지원되는 애드온 목록을 확인한다. + ```shell + NAME READY STATUS RESTARTS AGE + pod/heapster-9jttx 1/1 Running 0 26s + pod/influxdb-grafana-b29w8 2/2 Running 0 26s + pod/kube-addon-manager-minikube 1/1 Running 0 34m + pod/kube-dns-6dcb57bcc8-gv7mw 3/3 Running 0 34m + pod/kubernetes-dashboard-5498ccf677-cgspw 1/1 Running 0 34m + pod/storage-provisioner 1/1 Running 0 34m -```shell -minikube addons list -``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + service/heapster ClusterIP 10.96.241.45 80/TCP 26s + service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m + service/kubernetes-dashboard NodePort 10.109.29.1 80:30000/TCP 34m + service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s + service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s + ``` -출력: +4. `heapster` 비활성화 -```shell -- storage-provisioner: enabled -- kube-dns: enabled -- registry: disabled -- registry-creds: disabled -- addon-manager: enabled -- dashboard: disabled -- default-storageclass: enabled -- coredns: disabled -- heapster: disabled -- efk: disabled -- ingress: disabled -``` + ```shell + minikube addons disable heapster + ``` + + 출력: -이하의 커맨드를 적용하기 위해서는 Minikube가 실행 중이어야 한다. 예를 들어, `heapster` 애드온을 활성화하기 위해서는 -다음과 같이 실행한다. - -```shell -minikube addons enable heapster -``` - -출력: - -```shell -heapster was successfully enabled -``` - -생성한 파드와 서비스를 확인한다. - -```shell -kubectl get po,svc -n kube-system -``` - -출력: - -```shell -NAME READY STATUS RESTARTS AGE -pod/heapster-zbwzv 1/1 Running 0 2m -pod/influxdb-grafana-gtht9 2/2 Running 0 2m - -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -service/heapster NodePort 10.0.0.52 80:31655/TCP 2m -service/monitoring-grafana NodePort 10.0.0.33 80:30002/TCP 2m -service/monitoring-influxdb ClusterIP 10.0.0.43 8083/TCP,8086/TCP 2m -``` - -브라우저에서 엔드포인트를 열어 heapster와 상호 작용한다. - -```shell -minikube addons open heapster -``` - -출력: - -```shell -Opening kubernetes service kube-system/monitoring-grafana in default browser... -``` + ```shell + heapster was successfully disabled + ``` ## 제거하기 -이제 클러스터에서 만들어진 리소스를 제거한다. +이제 클러스터에서 만들어진 리소스를 제거할 수 있다. ```shell kubectl delete service hello-node kubectl delete deployment hello-node ``` -필요 시, 생성된 Docker 이미지를 강제로 제거한다. - -```shell -docker rmi hello-node:v1 hello-node:v2 -f -``` - -필요 시, Minikube VM을 정지한다. +필요시 Minikube 가상 머신(VM)을 정지한다. ```shell minikube stop -eval $(minikube docker-env -u) ``` -필요 시, Minikube VM을 삭제한다. +필요시 minikube VM을 삭제한다. ```shell minikube delete @@ -441,7 +259,6 @@ minikube delete {{% /capture %}} - {{% capture whatsnext %}} * [Deployment objects](/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다. @@ -449,5 +266,3 @@ minikube delete * [Service objects](/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. {{% /capture %}} - - diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index 25907bedb6..ff57ddc2d3 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -1,7 +1,7 @@ --- title: 쿠버네티스 기초 학습 linkTitle: 쿠버네티스 기초 학습 -weight: 5 +weight: 10 --- @@ -17,7 +17,7 @@ weight: 5

쿠버네티스 기초

-

이 튜토리얼에서는 쿠버네티스 클러스터 오케스트레이션 시스템의 기초를 익힐 수 있는 가이드를 제공한다. 각각의 모듈에는 쿠버네티스의 주요 기능과 개념에 대한 배경 지식이 담겨 있으며 대화형 온라인 튜토리얼도 포함되어 있다. 대화형 튜토리얼에서 간단한 클러스터와 그 클러스터 상의 컨테이너화된 애플리케이션을 직접 관리해볼 수 있다.

+

이 튜토리얼에서는 쿠버네티스 클러스터 오케스트레이션 시스템의 기초를 익힐 수 있는 가이드를 제공한다. 각각의 모듈에는 쿠버네티스의 주요 기능과 개념에 대한 배경 지식이 담겨 있으며 대화형 온라인 튜토리얼도 포함되어 있다. 대화형 튜토리얼에서 간단한 클러스터와 그 클러스터 상의 컨테이너화 된 애플리케이션을 직접 관리해볼 수 있다.

대화형 튜토리얼을 사용해서 다음의 내용을 배울 수 있다.

  • 컨테이너화된 애플리케이션을 클러스터에 배포하기
    • @@ -34,7 +34,7 @@ weight: 5

    쿠버네티스가 어떤 도움이 될까?

    -

    오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 쉽고 빠르게 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.

    +

    오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 쉽고 빠르게 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.

    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 03f92cf538..38b4620b80 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 @@ -35,8 +35,8 @@ weight: 10 방식으로 패키지할 필요가 있다. 즉, 컨테이너화 해야 한다. 컨테이너화된 애플리케이션은 호스트에 매우 깊이 통합된 패키지로써, 특정 머신에 직접 설치되는 예전의 배포 모델보다 유연하고 가용성이 높다. 쿠버네티스는 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 보다 효율적으로 - 자동화한다. 쿠버네티스는 오픈소스 - 플랫폼이고 운영 수준의 안정성을 가졌다. + 자동화한다. + 쿠버네티스는 오픈소스 플랫폼이고 운영 수준의 안정성을 가졌다.

    쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.

      @@ -84,14 +84,13 @@ weight: 10 클러스터 내 모든 활동을 조율한다.

      노드는 쿠버네티스 클러스터 내 워커 머신으로써 동작하는 VM 또는 물리적인 컴퓨터다. 각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 - 컨테이너 운영을 담당하는 Docker 또는 - rkt과 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 + 컨테이너 운영을 담당하는 Docker 또는 rkt와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야한다.

-

마스터는 클러스터를 관리하고 노드는 구동되는 애플리케이션을 수용하는데 사용된다.

+

마스터는 클러스터를 관리하고 노드는 구동되는 애플리케이션을 수용하는데 사용된다.

@@ -104,11 +103,11 @@ weight: 10 사용해서 클러스터와 상호작용할 수 있다.

쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면 - Minikube를 사용할 수 있다. Minikube는 로컬 - 머신에 VM을 만들고 하나의 노드로 구성된 간단한 클러스터를 배포하는 가벼운 쿠버네티스 구현체다. - Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 구동이 가능하다. Minikube CLI는 클러스터에 대해 - 시작, 중지, 상태 조회 및 삭제 등의 기본적인 부트스트래핑 기능을 제공한다. 하지만, 본 튜토리얼에서는 - Minikube가 미리 설치된 채로 제공되는 온라인 터미널을 사용할 것이다.

+ Minikube를 사용할 수 있다. Minikube는 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 + 클러스터를 배포하는 가벼운 쿠버네티스 구현체다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 + 구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인 + 부트스트래핑 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는 + 온라인 터미널을 사용할 것이다.

이제 쿠버네티스가 무엇인지 알아봤으니, 온라인 튜토리얼로 이동해서 우리의 첫 번째 클러스터를 시작해보자!

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 0e6ec54197..bc72f718a4 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 @@ -103,9 +103,9 @@ weight: 10
-

우리의 첫 번째 디플로이먼트로, Docker 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자. +

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

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

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

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 2eb5301fbf..cf49a82505 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 @@ weight: 10

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

-

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

+

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

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

diff --git a/content/ko/examples/application/deployment.yaml b/content/ko/examples/application/deployment.yaml index 0f526b16c0..68ab8289b5 100644 --- a/content/ko/examples/application/deployment.yaml +++ b/content/ko/examples/application/deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 # apps/v1beta2를 사용하는 1.9.0보다 더 이전의 버전용 kind: Deployment metadata: name: nginx-deployment @@ -6,7 +6,7 @@ spec: selector: matchLabels: app: nginx - replicas: 2 # tells deployment to run 2 pods matching the template + replicas: 2 # 템플릿에 매칭되는 파드 2개를 구동하는 디플로이먼트임 template: metadata: labels: