diff --git a/content/ko/_index.html b/content/ko/_index.html index f932ba6c2ec66..f179c6576214a 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -3,6 +3,7 @@ abstract: "자동화된 컨테이너 배포, 스케일링과 관리" cid: home --- +{{< announcement >}} {{< deprecationwarning >}} diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index effa7313a270a..bb6e199445264 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -223,13 +223,14 @@ rules: 다음은 클라우드 제공사업자들이 구현한 CCM들이다. -* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [Linode](https://github.com/linode/linode-cloud-controller-manager) +* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) ## 클러스터 관리 diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 2028073489c89..ee8e2661b8815 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -190,9 +190,20 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄 파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다. +## 노드 토폴로지 + +{{< feature-state state="alpha" >}} + +`TopologyManager` +[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. ## API 오브젝트 노드는 쿠버네티스 REST API 내 탑-레벨 리소스 이다. API 오브젝트에 대한 보다 자세한 내용은 [노드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)에서 확인할 수 있다. {{% /capture %}} +{{% capture whatsnext %}} +* [노드 컴포넌트](https://kubernetes.io/docs/concepts/overview/components/#node-components)에 대해 읽기 +* 노드 수준 토폴로지에 대해 읽기: [노드의 토폴로지 정책 제어하기](/docs/tasks/administer-cluster/topology-manager/) +{{% /capture %}} diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 86dd09209c728..71995aa22cce3 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -54,10 +54,9 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. 연관된 문서를 통해서 확인한다([아래](#cri-configuration)). {{< note >}} -런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정 -(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한 -설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다 -([파드를 노드에 할당하기](/docs/concepts/configuration/assign-pod-node/) 참고). +런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 +(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. +이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄링](#scheduling)을 참고한다. {{< /note >}} 해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. @@ -144,6 +143,42 @@ https://github.com/containerd/cri/blob/master/docs/config.md 더 자세한 cri-o의 구성 문서를 살펴본다. https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go +### 스케줄 + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다. +이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다. +이 스케줄링 기능을 사용하려면, 런타임 클래스 [어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다. + +파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면, +해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다. +런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로 +각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다. + +지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면, +`tolerations`를 런타임 클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 +해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 +노드의 합집합을 취한다. + +노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 +[노드에 파드 할당](/docs/concepts/configuration/assign-pod-node/)을 참고한다. + +[어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/ + +### 파드 오버헤드 + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +쿠버네티스 v1.16 부터는, 런타임 클래스에는 구동 중인 파드와 관련된 오버헤드를 +지정할 수 있는 기능이 [`PodOverhead`](/docs/concepts/configuration/pod-overhead.md) 기능을 통해 지원된다. +`PodOverhead`를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화 시켜야 한다. (기본 값으로는 비활성화 되어 있다.) + + +파드 오버헤드는 런타임 클래스에서 `Overhead` 필드를 통해 정의된다. 이 필드를 사용하면, +해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 +쿠버네티스 내에서 처리된다는 것을 보장할 수 있다. ### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta} @@ -172,4 +207,11 @@ https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go 더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다 (위를 참조). +### 더 읽기 + +- [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) +- [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) +- [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 +- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) + {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 58d29c2532204..1a207f42a4c16 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -148,7 +148,7 @@ _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할 ### LIST와 WATCH 필터링 -LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함). +LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함). * _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` @@ -181,11 +181,11 @@ kubectl get pods -l 'environment,environment notin (frontend)' [`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다. -#### 서비스와 리플리케이션 컨트롤러 +#### 서비스와 레플리케이션 컨트롤러 -`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다. +`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `레플리케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다. -서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다. +서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다. ```json "selector": { diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index 63229eb600a20..62b622a7f4eeb 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -27,16 +27,16 @@ weight: 30 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다. -다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근 제어 정책을 갖게 된다. +다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근 제어 정책을 갖게 된다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다. 같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서 복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를 -구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다. +구분하기 위해서는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다. ## 네임스페이스 다루기 -네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에 +네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. ### 네임스페이스 조회 @@ -94,7 +94,7 @@ kubectl config view | grep namespace: 대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. -그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 +그리고 [nodes](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않는다. 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는, diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md new file mode 100644 index 0000000000000..101f141102572 --- /dev/null +++ b/content/ko/docs/concepts/services-networking/_index.md @@ -0,0 +1,4 @@ +--- +title: "서비스, 로드밸런싱, 네트워킹" +weight: 60 +--- diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md new file mode 100644 index 0000000000000..10da72fb2d7bf --- /dev/null +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -0,0 +1,273 @@ +--- +title: 서비스 및 파드용 DNS +content_template: templates/concept +weight: 20 +--- + + + +{{% capture overview %}} +이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다. +{{% /capture %}} + +{{% capture body %}} + +## 소개 + +쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, +개별 컨테이너들이 DNS 네임을 해석할 때 +DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. + +### DNS 네임이 할당되는 것들 + +클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. +기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 +클러스터의 기본 도메인을 포함한다. +이 예시는 다음과 같다. + +쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는 +단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다. +네임스페이스 `quux`에서 실행 중인 파드는 +`foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다. + +다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다. +이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 경고 없이 변경될 수 있다. +최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다. + +[쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md). + +## 서비스 + +### A 레코드 + +"노멀"(헤드리스가 아닌) 서비스는 +`my-svc.my-namespace.svc.cluster-domain.example` +형식의 이름을 가진 DNS A 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다. + +"헤드리스"(클러스터 IP가 없는) 서비스 또한 +`my-svc.my-namespace.svc.cluster-domain.example` +형식의 이름을 가진 DNS A 레코드가 할당된다. +노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. +클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다. + +### SRV 레코드 + +SRV 레코드는 노멀 서비스 또는 +[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)에 +속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. +`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. +정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. +`my-svc.my-namespace.svc.cluster-domain.example`. +헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 +포트 번호와 도메인 이름을 포함한다. +`auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. + +## 파드 + +### 파드의 hostname 및 subdomain 필드 + +파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다. + +파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. +이 필드는 파드의 호스트네임을 지정할 수 있다. +`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. +예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다. + +또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. +예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, +`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. +"`foo.bar.my-namespace.svc.cluster-domain.example`". + +예시: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: default-subdomain +spec: + selector: + name: busybox + clusterIP: None + ports: + - name: foo # 사실 포트는 필요하지 않다. + port: 1234 + targetPort: 1234 +--- +apiVersion: v1 +kind: Pod +metadata: + name: busybox1 + labels: + name: busybox +spec: + hostname: busybox-1 + subdomain: default-subdomain + containers: + - image: busybox:1.28 + command: + - sleep + - "3600" + name: busybox +--- +apiVersion: v1 +kind: Pod +metadata: + name: busybox2 + labels: + name: busybox +spec: + hostname: busybox-2 + subdomain: default-subdomain + containers: + - image: busybox:1.28 + command: + - sleep + - "3600" + name: busybox +``` + +파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, +클러스터의 KubeDNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 레코드를 반환한다. +예를 들어 호스트네임이 "`busybox-1`"이고, +서브도메인이 "`default-subdomain`"이고, +같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, +파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. +"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". +DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 레코드를 제공한다. +"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 레코드를 가지고 있다. + +엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다. + +{{< note >}} +A 레코드는 파드의 이름으로 생성되지 않기 때문에 +파드의 A 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. +`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 +A 레코드만 생성할 수 있다. +(`default-subdomain.my-namespace.svc.cluster-domain.example`) +또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. +그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다. +{{< /note >}} + +### 파드의 DNS 정책 + +DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. +이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다. + +- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. + 자세한 내용은 + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) + 에서 확인할 수 있다. +- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 + 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. + 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. + 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) + 에서 확인할 수 있다. +- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 + "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. +- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. + 모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다. + 아래 절인 + [파드의 DNS 설정](#파드의-dns-설정) + 에서 자세한 내용을 확인할 수 있다. + +{{< note >}} +"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 +“ClusterFirst”가 기본값으로 사용된다. +{{< /note >}} + + +아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서 +DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + containers: + - image: busybox:1.28 + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + name: busybox + restartPolicy: Always + hostNetwork: true + dnsPolicy: ClusterFirstWithHostNet +``` + +### 파드의 DNS 설정 + +사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다. + +`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. +이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 `dnsConfig` 필드를 지정할 수 있다. + +사용자는 `dnsConfig` 필드에서 다음과 같은 속성들을 지정할 수 있다. + +- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다. + 파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는 + 적어도 하나의 IP 주소가 포함되어야 하며, + 그렇지 않으면 이 속성은 생략할 수 있다. + `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 중복되는 주소는 제거된다. +- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다. + 이 속성은 생략이 가능하며, + 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. + 병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. +- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. + 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. + 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, + 병합 시 중복되는 항목은 제거된다. + +다음은 커스텀 DNS 세팅을 한 파드의 예시이다. + +{{< codenew file="service/networking/custom-dns.yaml" >}} + +위에서 파드가 생성되면, +컨테이너 `test`의 `/etc/resolv.conf` 파일에는 다음과 같은 내용이 추가된다. + +``` +nameserver 1.2.3.4 +search ns1.svc.cluster-domain.example my.dns.search.suffix +options ndots:2 edns0 +``` + +IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같아야 한다: + +```shell +kubectl exec -it dns-example -- cat /etc/resolv.conf +``` + +출력은 다음과 같은 형식일 것이다. + +```shell +nameserver fd00:79:30::a +search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example +options ndots:5 +``` + +### 기능 지원 여부 + +파드 DNS 구성 및 DNS 정책 "`None`"에 대한 지원 정보는 아래에서 확인 할 수 있다. + +| k8s 버전 | 기능 지원 | +| :---------: |:-----------:| +| 1.14 | 안정 | +| 1.10 | 베타 (기본)| +| 1.9 | 알파 | + +{{% /capture %}} + +{{% capture whatsnext %}} + +DNS 구성 관리에 대한 지침은 +[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/) +에서 확인 할 수 있다. + +{{% /capture %}} + + diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md new file mode 100644 index 0000000000000..0348adccbb01b --- /dev/null +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -0,0 +1,238 @@ +--- +title: 데몬셋 +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 +파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 +수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다. + +데몬셋의 일부 대표적인 용도는 다음과 같다. + +- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. +- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행. +- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행. + +단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. +더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, +각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. + +{{% /capture %}} + + +{{% capture body %}} + +## 데몬셋 사양 작성 + +### 데몬셋 생성 + +YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다. + +{{< codenew file="controllers/daemonset.yaml" >}} + +* YAML 파일을 기반으로 데몬셋을 생성한다. +``` +kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml +``` + +### 필수 필드 + +다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. +일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), +[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. + +데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다. + +### 파드 템플릿 + +`.spec.template` 는 `.spec` 의 필수 필드 중 하나이다. + +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. + +데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 +한다([파드 셀렉터](#파드-셀렉터)를 본다). + +데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/)는 `Always` 를 가져야 하며, + 명시되지 않은 경우 기본으로 `Always`가 된다. + +### 파드 셀렉터 + +`.spec.selector` 필드는 파드 셀렉터이다. 이것은 +[잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다. + +쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다. +파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다. +셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다. +또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다. +파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다. + +`.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다. + +* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 `.spec.selector` 와 동일하게 작동한다. +* `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를 + 명시해서 보다 정교한 셀렉터를 만들 수 있다. + +2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다. + +만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다. + +또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 +레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 +컨트롤러는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 +막지 못한다. 사용자가 이와 같은 일을 하게되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 +수동으로 생성하는 것이다. + +### 오직 일부 노드에서만 파드 실행 + +만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 +[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/#nodeselector)와 +일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 +데몬셋 컨트롤러는 [노트 어피니티](/docs/concepts/configuration/assign-pod-node/#node-affinity)와 일치하는 노드에 파드를 생성한다. +만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. + +## 데몬 파드가 스케줄 되는 방법 + +### 데몬셋 컨트롤러에 의해서 스케줄(1.12 이후로 기본값으로 사용 안함) + +일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 머신이 선택된다. 그러나 데몬셋 +컨트롤러에 의해 생성된 파드는 이미 머신이 선택되어 있다(`.spec.nodeName` 이 +파드가 생성될 때 명시되므로, 스케줄러에서는 무시된다). 그러므로 다음과 같다. + + - 데몬셋 컨트롤러는 노드의 [`unschedulable`](/ko/docs/concepts/architecture/nodes/#수동-노드-관리) + 필드를 존중하지 않는다. + - 데몬셋 컨트롤러는 스케줄러가 시작되지 않은 경우에도 파드를 만들 수 있어 클러스터 부트스트랩을 + 도울 수도 있다. + + +### 기본 스케줄러로 스케줄(1.12 이후로 기본값으로 사용) + +{{< feature-state state="beta" for-kubernetes-version="1.12" >}} + +데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 +쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 +데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다. +이에 대한 이슈를 소개한다. + + * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다. + 그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다. + 이것은 사용자에게 혼란을 준다. + * [파드 선점](/docs/concepts/configuration/pod-priority-preemption/) + 은 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 + 파드 우선순위와 선점을 고려하지 않고 스케줄 한다. + +`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 +`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 +스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 +스케줄러를 사용해서 대상 호스트에 파드를 바인딩 한다. 만약 데몬셋 파드에 +이미 노드 선호도가 존재한다면 교체한다. 데몬셋 컨트롤러는 +데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, +데몬셋의 `spec.template` 은 변경되지 않는다. + +```yaml +nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchFields: + - key: metadata.name + operator: In + values: + - target-host-name +``` + +또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로 +자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를 +스케줄링시 `unschedulable` 노드를 무시한다. + + +### 테인트(taints)와 톨러레이션(tolerations) + +데몬 파드는 +[테인트와 톨러레이션](/docs/concepts/configuration/taint-and-toleration)을 존중하지만, +다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에 +톨러레이션을 추가한다. + +| 톨러레이션 키 | 영향 | 버전 | 설명 | +| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | + + + + +## 데몬 파드와 통신 + +데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다. + +- **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 + 구성되어있다. 그들은 클라이언트들을 가지지 않는다. +- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. +- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 만들고, + 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 + 검색한다. +- **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 + 임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다). + +## 데몬셋 업데이트 + +만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 +일치하지 않는 노드에서 파드를 삭제한다. + +사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 +필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 +다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다. + +사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면 +파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, +새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 +`updateStrategy` 에 따라 파드를 교체한다. + +사용자는 데몬셋에서 [롤링 업데이트를 수행](/docs/tasks/manage-daemon/update-daemon-set/) 할 수 있다. + +## 데몬셋의 대안 + +### 초기화 스크립트 + +데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다. +(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 +프로세스를 실행하면 몇 가지 이점 있다. + +- 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다. +- 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`). +- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 + 데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다 + (예: 도커에서 직접적으로 시작). + +### 베어(Bare) 파드 + +직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 +데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여 +어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 +생성하는 것보다는 데몬 셋을 사용해야 한다. + +### 스태틱(static) 파드 + +Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 +[스태틱 파드](/docs/tasks/configure-pod-container/static-pod/)라고 부른다. +데몬셋과는 다르게 스태틱 파드는 kubectl +또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 +않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단(deprecated)될 수 있다. + +### 디플로이먼트 + +데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고, +해당 파드에서는 프로세스가 종료되지 않을 것으로 +예상한다(예: 웹 서버). + +파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, +업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 +디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, +다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index bf373c8d2bb59..effb86d249f08 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -227,7 +227,7 @@ _디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/p 다음에 이러한 파드를 업데이트 하려면 디플로이먼트의 파드 템플릿만 다시 업데이트 하면 된다. 디플로이먼트는 업데이트되는 동안 일정한 수의 파드만 중단되도록 보장한다. 기본적으로 - 적어도 의도한 파드 수의 25% 이상이 동작하도록 보장한다(최대 25% 이상 불가). + 적어도 의도한 파드 수의 75% 이상이 동작하도록 보장한다(최대 25% 불가). 또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다. 기본적으로, 의도한 파드의 수 기준 최대 25%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지). diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md new file mode 100644 index 0000000000000..4fb5f4c4ca0f5 --- /dev/null +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -0,0 +1,264 @@ +--- +title: 스테이트풀셋 +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +스테이트풀셋은 애플리케이션의 스테이트풀을 관리하는데 사용하는 워크로드 API 오브젝트이다. + +{{< glossary_definition term_id="statefulset" length="all" >}} +{{% /capture %}} + +{{% capture body %}} + +## 스테이트풀셋 사용 + +스테이트풀셋은 다음 중 하나 또는 이상이 필요한 애플리케이션에 +유용하다. + +* 안정된, 고유한 네트워크 식별자. +* 안정된, 지속성을 갖는 스토리지. +* 순차적인, 정상 배포(graceful deployment)와 스케일링. +* 순차적인, 자동 롤링 업데이트. + +위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다. +만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, +삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을 +제공하는 컨트롤러로 애플리케이션을 배포해야 한다. 아마도 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 +[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다. + +## 제한사항 + +* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. +* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. +* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. +* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다. +* [롤링 업데이트](#롤링-업데이트)와 기본 + [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를 + 함께 사용시 [복구를 위한 수동 개입](#강제-롤백)이 + 필요한 파손 상태로 빠질 수 있다. + +## 구성 요소 +아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다. + +* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다. +* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다. +* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: nginx + labels: + app: nginx +spec: + ports: + - port: 80 + name: web + clusterIP: None + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + selector: + matchLabels: + app: nginx # has to match .spec.template.metadata.labels + serviceName: "nginx" + replicas: 3 # by default is 1 + template: + metadata: + labels: + app: nginx # has to match .spec.selector.matchLabels + spec: + terminationGracePeriodSeconds: 10 + containers: + - name: nginx + image: k8s.gcr.io/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: "my-storage-class" + resources: + requests: + storage: 1Gi +``` + +## 파드 셀렉터 +스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다. + +## 파드 신원 +스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고 +안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은 +파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다. + +### 순서 색인 + +N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있는 +각 파드에 0에서 N-1 까지의 정수가 순서대로 할당되며 해당 스테이트풀셋 내에서 고유 하다. + +### 안정적인 네트워크 신원 + +스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 +호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 +`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 +`web-0,web-1,web-2` 이다. +스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 +[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 사용할 수 있다. +이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, +여기서 "cluster.local"은 클러스터 도메인이다. +각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 +일치되는 DNS 서브도메인을 가지며, 여기서 governing service는 +스테이트풀셋의 `serviceName` 필드에 의해 정의된다. + +[제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는 +파드의 네트워크 신원을 책임지는 +[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 생성할 책임이 있다. + +여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, +그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다. + +클러스터 도메인 | 서비스 (ns/이름) | 스테이트풀셋 (ns/이름) | 스테이트풀셋 도메인 | 파드 DNS | 파드 호스트 이름 | +-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ | + cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | + cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | + kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | + +{{< note >}} +클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 +아니라면 `cluster.local`로 설정된다. +{{< /note >}} + +### 안정된 스토리지 + +쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 +생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 +1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게된다. 만약 스토리지 클래스가 +명시되지 않은 경우 기본 스토리지 클래스를 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이되면 +파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다. +참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 +파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다. +이것은 반드시 수동으로 해야한다. + +### 파드 이름 레이블 + +스테이트풀셋 컨트롤러가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` +레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 +연결할 수 있다. + +## 디플로이먼트와 스케일링 보증 + +* N개의 레플리카가 있는 스테이트풀셋이 파드를 배포할 때 연속해서 {0..N-1}의 순서로 생성한다. +* 파드가 삭제될 때는 {N-1..0}의 순서인 역순으로 종료된다. +* 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다. +* 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다. + +스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. + +위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 +배포된다. web-1은 web-0이 +[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며, +web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후, +web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고, +Running 및 Ready 상태가 되기 전까지 시작되지 않는다. + +만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서 +스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기 +전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에 +web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 +되기 전까지 종료되지 않는다. + +### 파드 관리 정책 +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 +통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. + +#### OrderedReady 파드 관리 + +`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. +이것은 [위에서](#디플로이먼트와-스케일-보증) 설명한 행위를 구현한다. + +#### 병렬 파드 관리 + +`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 +병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 +종료에 앞서 파드가 Running 및 Ready 상태가 되거나 완전히 종료되기를 기다리지 않는다. +이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 +받지 않는다. + +## 업데이트 전략 + +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 +파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 +구성하거나 비활성화 할 수 있다. + +### 삭제 시(On Delete) + +`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 +`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 +스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 +`.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다. + +### 롤링 업데이트 + +`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 +구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 +스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 +순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), +각 파드의 업데이트는 한번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 +때까지 기다린다. + +#### 파티션(Partition) + +`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` +를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 +업데이트 될 때 부여된 수가 파티션보다 크거나 같은 모든 파드가 업데이트 된다. +파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, +삭제 된 경우라도 이전 버전에서 재생성된다. +만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 +`.spec.replicas` 보다 큰 경우 `.spec.template` 의 업데이트는 해당 파드에 전달하지 않는다. +대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, +카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다. + +#### 강제 롤백 + +기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 +함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 +직접 수동으로 복구를 해야하는 고장난 상태가 될 수 있다. + +만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는 +경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한) +스테이트풀셋은 롤아웃을 중지하고 기다린다. + +이 상태에서는 파드 템플릿을 올바른 구성으로 되돌리는 것으로 충분하지 않다. +[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로 +인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며 +작동하는 구성으로 되돌아가는 시도를 하기 +전까지 기다린다. + +템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 +실행하려고 시도한 모든 파드를 삭제해야 한다. +그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다. + +{{% /capture %}} +{{% capture whatsnext %}} + +* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다. +* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다. + +{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index d565d7751ee9a..a0d3abedfb9ae 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -101,21 +101,29 @@ kubelet은 컨테이너에 의해서 구현된 * Failure: 컨테이너가 진단에 실패함. * Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨. -kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 종류의 프로브를 수행하고 +kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고 그에 반응할 수 있다. -* `livenessProbe`는 컨테이너가 동작 중인지 여부를 나타낸다. 만약 +* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 [재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다. -* `readinessProbe`는 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. +* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 `Success`이다. -### 언제 활성 또는 준비성 프로브를 사용해야 하는가? +* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. + 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 + 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, + 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 + 프로브가 없는 경우, 기본 상태는 `Success`이다. + +### 언제 활성 프로브를 사용해야 하는가? + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} 만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 @@ -125,6 +133,10 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다. +### 언제 준비성 프로브를 사용해야 하는가? + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + 프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 @@ -142,6 +154,13 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로 남아있는다. +### 언제 스타트업 프로브를 사용해야 하는가? + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds` 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 체크하도록 명시해야 한다. `periodSeconds`의 기본 값은 30s 이다. +이 때 컨테이너가 활성화 프로브의 기본 값 변경 없이 기동되도록 하려면 `failureThreshold`를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다. + 활성 프로브 및 준비성 프로브를 설정하는 방법에 대한 추가적인 정보는, [활성 프로브 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 8ca5921f15215..0df4d59fe1a7b 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -18,11 +18,11 @@ content_template: templates/concept * [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 * 쿠버네티스 API 버전 + * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) * [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/) ## API 클라이언트 라이브러리 diff --git a/content/ko/docs/reference/glossary/applications.md b/content/ko/docs/reference/glossary/applications.md index 7719f0a1fca77..c8c7c0d029ca3 100644 --- a/content/ko/docs/reference/glossary/applications.md +++ b/content/ko/docs/reference/glossary/applications.md @@ -5,7 +5,6 @@ date: 2019-05-12 full_link: short_description: > 컨테이너화된 다양한 애플리케이션들이 실행되는 레이어. - aka: tags: - fundamental diff --git a/content/ko/docs/reference/glossary/static-pod.md b/content/ko/docs/reference/glossary/static-pod.md index 6b80d40e24b17..19e1f4bbc689a 100755 --- a/content/ko/docs/reference/glossary/static-pod.md +++ b/content/ko/docs/reference/glossary/static-pod.md @@ -2,13 +2,17 @@ title: 스태틱 파드(Static Pod) id: static-pod date: 2019-02-12 -full_link: /docs/tasks/administer-cluster/static-pod/ +full_link: /docs/tasks/configure-pod-container/static-pod/ short_description: > 특정 노드의 Kubelet 데몬이 직접 관리하는 파드 -aka: +aka: tags: - fundamental --- - API 서버가 관찰하지 않고, 특정 노드의 Kubelet 데몬이 - 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}. + +특정 노드의 Kubelet 데몬이 + 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}로, + + +API 서버가 관찰하지 않는다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/workload.md b/content/ko/docs/reference/glossary/workload.md index 80aaa95d34c20..55dcc3167bcdc 100644 --- a/content/ko/docs/reference/glossary/workload.md +++ b/content/ko/docs/reference/glossary/workload.md @@ -9,20 +9,15 @@ short_description: > aka: tags: - fundamental -- core-object -- workload --- - 워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다. + 워크로드는 쿠버네티스에서 구동되는 애플리케이션이다. -쿠버네티스는 -애플리케이션의 현재 상태에 따라 워크로드의 디플로이먼트와 업데이트를 수행한다. -워크로드는 데몬셋, 디플로이먼트, 잡, 파드, 레플리카셋, 레플리케이션컨트롤러, 스테이트풀셋과 같은 오브젝트를 포함한다. +데몬셋, 디플로이먼트, 잡, 레플리카셋, 그리고 스테이트풀셋 오브젝트를 포함해서 +서로 다른 워크로드의 유형이나 부분을 대표하는 다양한 핵심 오브젝트. -예를 들어, 웹 요소와 데이터베이스 요소가 있는 워크로드는 -데이터베이스를 {{< glossary_tooltip text="파드" term_id="pod" >}}의 한 -{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, -웹서버를 많은 웹 앱 {{< glossary_tooltip text="파드" term_id="pod" >}}로 구성된 -{{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다. +예를 들어, 웹 서버와 데이터베이스가 있는 워크로드는 +데이터베이스를 한 {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, +웹서버를 {{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다. diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 3a036102991ff..2eca06d667563 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -78,7 +78,7 @@ card: | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ | [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ | [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ -| [Gardener](https://gardener.cloud/) | |✔ | | ✔ | | +| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ (via OpenStack) | ✔ | | | [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | | [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | @@ -105,5 +105,6 @@ card: | [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | | [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | | [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) +| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | | {{% /capture %}} diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 12d213bb8fe3e..2520f1ed2d971 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -40,7 +40,7 @@ kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니 ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration -kubernetesVersion: v1.13.0 +kubernetesVersion: v1.16.0 apiServer: extraArgs: advertise-address: 192.168.0.103 @@ -57,7 +57,7 @@ apiServer: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration -kubernetesVersion: v1.13.0 +kubernetesVersion: v1.16.0 controllerManager: extraArgs: cluster-signing-key-file: /home/johndoe/keys/ca.key @@ -73,7 +73,7 @@ controllerManager: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration -kubernetesVersion: v1.13.0 +kubernetesVersion: v1.16.0 scheduler: extraArgs: address: 0.0.0.0 diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index af58c4965e105..deb5aadb72d15 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -102,6 +102,10 @@ weight: 75 윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다. {{< /note >}} +## 설정 가능한 컨테이너 username 사용하기 + +쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다. + ## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기 쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md index 6e60bffaa8d63..a96f183e58f0b 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md @@ -1,26 +1,35 @@ --- reviewers: title: 쿠버네티스에서 윈도우 노드 추가 가이드 -content_template: templates/concept +min-kubernetes-server-version: v1.14 +content_template: templates/tutorial weight: 70 --- {{% capture overview %}} -쿠버네티스 플랫폼은 이제 리눅스와 윈도우 컨테이너 모두 운영할 수 있다. 윈도우 노드도 클러스터에 등록할 수 있다. 이 가이드는 다음을 어떻게 하는지 보여준다. +쿠버네티스 플랫폼은 이제 리눅스와 윈도우 컨테이너 모두 운영할 수 있다. 윈도우 노드도 클러스터에 등록할 수 있다. 이 페이지에서는 어떻게 하나 또는 그 이상의 윈도우 노드를 클러스터에 등록할 수 있는지 보여준다. +{{% /capture %}} -* 윈도우 노드를 클러스터에 등록하기 -* 리눅스와 윈도우에서 동작하는 파드가 상호 간에 통신할 수 있게 네트워크를 구성하기 + +{{% capture prerequisites %}} + +* 윈도우 컨테이너를 호스트하는 윈도우 노드를 구성하려면 [윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)를 소유해야 한다. 클러스터를 위해서 소속 기관의 라이선스를 사용하거나, Microsoft, 리셀러로 부터 취득할 수 있으며, GCP, AWS, Azure와 같은 주요 클라우드 제공자의 마켓플레이스를 통해 윈도우 서버를 운영하는 가상머신을 프로비저닝하여 취득할 수도 있다. [사용시간이 제한된 시험판](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial)도 활용 가능하다. + +* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 클러스터를 구축한다.(몇 가지 예시는 [kubeadm으로 단일 컨트롤플레인 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/docs/setup/production-environment/turnkey/azure/), [GCE](/docs/setup/production-environment/turnkey/gce/), [AWS](/docs/setup/production-environment/turnkey/aws/)를 포함한다) {{% /capture %}} -{{% capture body %}} -## 시작하기 전에 +{{% capture objectives %}} -* 윈도우 컨테이너를 호스트하는 윈도우 노드를 구성하려면 [윈도우 서버 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)를 소유해야 한다. 클러스터를 위해서 소속 기관의 라이선스를 사용하거나, Microsoft, 리셀러로 부터 취득할 수 있으며, GCP, AWS, Azure와 같은 주요 클라우드 제공자의 마켓플레이스를 통해 윈도우 서버를 운영하는 가상머신을 프로비저닝하여 취득할 수도 있다. [사용시간이 제한된 시험판](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial)도 활용 가능하다. +* 윈도우 노드를 클러스터에 등록하기 +* 리눅스와 윈도우에서 동작하는 파드와 서비스가 상호 간에 통신할 수 있게 네트워크를 구성하기 -* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 클러스터를 구축한다.(몇 가지 예시는 [kubeadm으로 단일 컨트롤플레인 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/docs/setup/production-environment/turnkey/azure/), [GCE](/docs/setup/production-environment/turnkey/gce/), [AWS](/docs/setup/production-environment/turnkey/aws/)를 포함한다) +{{% /capture %}} + + +{{% capture lessoncontent %}} ## 시작하기: 사용자 클러스터에 윈도우 노드 추가하기 @@ -51,9 +60,9 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes ### 네트워크 구성 -리눅스 기반의 쿠버네티스 마스터 노드를 가지고 있다면 네트워킹 솔루션을 선택할 준비가 된 것이다. 이 가이드는 단순화를 위해 VXLAN 방식의 플라넬(Flannel)을 사용하여 설명한다. +리눅스 기반의 쿠버네티스 컨트롤 플레인("마스터") 노드를 가지고 있다면 네트워킹 솔루션을 선택할 준비가 된 것이다. 이 가이드는 단순화를 위해 VXLAN 방식의 플라넬(Flannel)을 사용하여 설명한다. -#### 리눅스 컨트롤러에서 VXLAN 방식으로 플라넬 구성하기 +#### 리눅스 컨트롤 플레인에서 VXLAN 방식으로 플라넬 구성하기 1. 플라넬을 위해 쿠버네티스 마스터를 준비한다. @@ -120,7 +129,7 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes } ``` -1. 플라넬 yaml 을 적용하고 확인하기 +1. 플라넬 매니페스트를 적용하고 확인하기 플라넬 구성을 적용하자. @@ -167,132 +176,168 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d ``` -#### 윈도우 워커 조인 -이번 단원은 맨 땅에서부터 온프레미스 클러스터에 가입하기까지 윈도우 노드 구성을 다룬다. 클러스터가 클라우드상에 있다면, 다음 단원에 있는 클라우드에 특정한 가이드를 따르도록 된다. + +### 윈도우 워커 노드 추가하기 + +이번 단원은 맨 땅에서부터 온프레미스 클러스터에 가입하기까지 윈도우 노드 구성을 다룬다. 클러스터가 클라우드상에 있다면, [퍼블릭 클라우드 제공자 단원](#퍼블릭-클라우드-제공자)에 있는 클라우드에 특정한 가이드를 따르도록 된다. #### 윈도우 노드 준비하기 {{< note >}} -윈도우 단원에서 모든 코드 부분은 높은 권한(Admin)으로 파워쉘(PowerShell) 환경에서 구동한다. +윈도우 단원에서 모든 코드 부분은 윈도우 워커 노드에서 높은 권한(Administrator)으로 파워쉘(PowerShell) 환경에서 구동한다. {{< /note >}} -1. 도커(Docker) 설치(시스템 리부팅 필요) - - 쿠버네티스는 [도커](https://www.docker.com/)를 컨테이너 엔진으로 사용하므로, 도커를 설치해야 한다. [공식 문서 설치 요령](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#install-docker), [도커 명령](https://store.docker.com/editions/enterprise/docker-ee-server-windows)을 따라 해보거나 다음의 *권장하는* 단계를 시도하자. +1. 설치 및 참여(join) 스크립트가 포함된 [SIG Windows tools](https://github.com/kubernetes-sigs/sig-windows-tools) 리포지터리를 내려받는다. + ```PowerShell + [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 + Start-BitsTransfer https://github.com/kubernetes-sigs/sig-windows-tools/archive/master.zip + tar -xvf .\master.zip --strip-components 3 sig-windows-tools-master/kubeadm/v1.15.0/* + Remove-Item .\master.zip + ``` - ```PowerShell - Enable-WindowsOptionalFeature -FeatureName Containers - Restart-Computer -Force - Install-Module -Name DockerMsftProvider -Repository PSGallery -Force - Install-Package -Name Docker -ProviderName DockerMsftProvider - ``` - - 네트워크 프록시 안쪽에서 작업한다면 다음 파워쉘 환경 변수를 반드시 정의하자. +1. 쿠버네티스 [구성 파일](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/Kubeclustervxlan.json)을 커스터마이즈한다. - ```PowerShell - [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) - [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) - ``` - - 리부팅 후에 다음 오류를 보게되면, 도커 서비스를 수동으로 재시작해야 한다. - - ```PowerShell - docker version ``` + { + "Cri" : { // Contains values for container runtime and base container setup + "Name" : "dockerd", // Container runtime name + "Images" : { + "Pause" : "mcr.microsoft.com/k8s/core/pause:1.2.0", // Infrastructure container image + "Nanoserver" : "mcr.microsoft.com/windows/nanoserver:1809", // Base Nanoserver container image + "ServerCore" : "mcr.microsoft.com/windows/servercore:ltsc2019" // Base ServerCore container image + } + }, + "Cni" : { // Contains values for networking executables + "Name" : "flannel", // Name of network fabric + "Source" : [{ // Contains array of objects containing values for network daemon(s) + "Name" : "flanneld", // Name of network daemon + "Url" : "https://github.com/coreos/flannel/releases/download/v0.11.0/flanneld.exe" // Direct URL pointing to network daemon executable + } + ], + "Plugin" : { // Contains values for CNI network plugin + "Name": "vxlan" // Backend network mechanism to use: ["vxlan" | "bridge"] + }, + "InterfaceName" : "Ethernet" // Designated network interface name on Windows node to use as container network + }, + "Kubernetes" : { // Contains values for Kubernetes node binaries + "Source" : { // Contains values for Kubernetes node binaries + "Release" : "1.15.0", // Version of Kubernetes node binaries + "Url" : "https://dl.k8s.io/v1.15.0/kubernetes-node-windows-amd64.tar.gz" // Direct URL pointing to Kubernetes node binaries tarball + }, + "ControlPlane" : { // Contains values associated with Kubernetes control-plane ("Master") node + "IpAddress" : "kubemasterIP", // IP address of control-plane ("Master") node + "Username" : "localadmin", // Username on control-plane ("Master") node with remote SSH access + "KubeadmToken" : "token", // Kubeadm bootstrap token + "KubeadmCAHash" : "discovery-token-ca-cert-hash" // Kubeadm CA key hash + }, + "KubeProxy" : { // Contains values for Kubernetes network proxy configuration + "Gates" : "WinOverlay=true" // Comma-separated key-value pairs passed to kube-proxy feature gate flag + }, + "Network" : { // Contains values for IP ranges in CIDR notation for Kubernetes networking + "ServiceCidr" : "10.96.0.0/12", // Service IP subnet used by Services in CIDR notation + "ClusterCidr" : "10.244.0.0/16" // Cluster IP subnet used by Pods in CIDR notation + } + }, + "Install" : { // Contains values and configurations for Windows node installation + "Destination" : "C:\\ProgramData\\Kubernetes" // Absolute DOS path where Kubernetes will be installed on the Windows node + } +} + ``` - 만약 다음과 같은 에러 메시지를 보게되면, 도커 서비스를 수동으로 시작해야 한다. +{{< note >}} +사용자는 쿠버네티스 컨트롤 플레인("마스터") 노드에서 `kubeadm token create --print-join-command`를 실행해서 `ControlPlane.KubeadmToken`과 `ControlPlane.KubeadmCAHash` 필드를 위한 값을 생성할 수 있다. +{{< /note >}} - ``` - Client: - Version: 17.06.2-ee-11 - API version: 1.30 - Go version: go1.8.7 - Git commit: 06fc007 - Built: Thu May 17 06:14:39 2018 - OS/Arch: windows / amd64 - error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c - annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to - connect. This error may also indicate that the docker daemon is not running. - ``` +1. 컨테이너와 쿠버네티스를 설치 (시스템 재시작 필요) - 다음과 같이 도커 서비스를 수동으로 시작할 수 있다. +기존에 내려받은[KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/KubeCluster.ps1) 스크립트를 사용해서 쿠버네티스를 윈도우 서버 컨테이너 호스트에 설치한다. - ```PowerShell - Start-Service docker - ``` + ```PowerShell + .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -install + ``` + 이 때 `-ConfigFile`는 쿠버네티스 구성 파일의 경로를 가리킨다. {{< note >}} -`pause`(인프라스트럭처) 이미지는 Microsoft 컨테이너 레지스트리(MCR)에 등록되어 있다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`로 접근할 수 있다. `DOCKERFILE`은 https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat 에 있다. +아래 예제에서, 우리는 오버레이 네트워킹 모드를 사용한다. 이는 [KB4489899](https://support.microsoft.com/help/4489899)를 포함한 윈도우 서버 버전 2019와 최소 쿠버네티스 v1.14 이상이 필요하다. 이 요구사항을 만족시키기 어려운 사용자는 구성 파일의 [플러그인](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/Kubeclusterbridge.json#L18)으로 `bridge`를 선택하지 말고 `L2bridge` 네트워킹을 사용해야만 한다. {{< /note >}} -1. 쿠버네티스를 위한 윈도우 디렉터리 준비하기 + ![alt_text](../kubecluster.ps1-install.gif "KubeCluster.ps1 install output") - 쿠버네티스 바이너리와 배포 스크립트와 구성 파일을 저장할 "윈도우를 위한 쿠버네티스" 디렉터리를 생성한다. - ```PowerShell - mkdir c:\k - ``` +대상으로 하는 윈도우 노드에서, 본 단계는 -1. 쿠버네티스 인증서 복사하기 +1. 윈도우 서버 컨테이너 역할을 활성화(및 재시작) 한다. +1. 선택된 컨테이너 런타임을 내려받아 설치한다. +1. 필요한 컨테이너 이미지를 모두 내려받는다. +1. 쿠버네티스 바이너리를 내려받아서 `$PATH` 환경 변수에 추가한다. +1. 쿠버네티스 구성 파일에서 선택한 내용을 기반으로 CNI 플러그인을 내려받는다. +1. (선택적으로) 참여(join) 중에 컨트롤 플레인("마스터") 노드에 접속하기 위한 새로운 SSH 키를 생성한다. - 쿠버네티스 인증서 파일인 `$HOME/.kube/config`을 [리눅스 컨트롤러](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/creating-a-linux-master#collect-cluster-information)에서 윈도우 노드의 새로운 `C:\k` 디렉터리로 복사한다. + {{< note >}}또한, SSH 키 생성 단계에서 생성된 공개 SSH 키를 (리눅스) 컨트롤 플레인 노드의 `authorized_keys` 파일에 추가해야 한다. 이는 한 번만 수행하면 된다. 스크립트가 출력물의 마지막 부분에 이를 따라 할 수 있도록 단계를 출력해 준다.{{< /note >}} - 팁: 노드 간에 구성 파일 전송을 위해 [xcopy](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy), [WinSCP](https://winscp.net/eng/download.php)나 [WinSCP 파워쉘 래퍼](https://www.powershellgallery.com/packages/WinSCP/5.13.2.0)같은 도구를 이용할 수 있다. +일단 설치가 완료되면, 생성된 모든 구성 파일이나 바이너리는 윈도우 노드가 참여하기 전에 수정될 수 있다. -1. 쿠버네티스 바이너리 다운로드 하기 +#### 윈도우 노드를 쿠버네티스 클러스터에 참여시키기 - 쿠버네티스르 운영을 가능하게 하기 위해 먼저 `kubelet`과 `kube-proxy` 바이너리를 다운로드해야 한다. 이 바이너리를 [최신 릴리스](https://github.com/kubernetes/kubernetes/releases/)의 CHANGELOG.md 파일에 노드 바이너리 링크에서 다운로드 한다. 예를 들어 'kubernetes-node-windows-amd64.tar.gz'. 또한 클라이언트 바이너리 항목에서 찾을 수 있는 윈도우에서 실행되는 `kubectl`을 선택적으로 다운로드 받을 수 있다. +이 섹션에서는 클러스터를 구성하기 위해서 [쿠버네티스가 설치된 윈도우 노드](#윈도우-노드-준비하기)를 기존의 (리눅스) 컨트롤 플레인에 참여시키는 방법을 다룬다. - 압축 파일을 풀고, `C:\k`로 바이너리를 위치하기 위해 [Expand-Archive](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/expand-archive?view=powershell-6) 파워쉘 커맨드를 이용할 수 있다. +앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/KubeCluster.ps1) 스크립트를 사용해서 윈도우 노드를 클러스터에 참여시킨다. -#### 윈도우 노드를 플라넬 클러스터에 가입하기 + ```PowerShell + .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -join + ``` + 이 때 `-ConfigFile` 쿠버네티스 구성 파일의 경로를 가리킨다. -플라넬 오버레이 배포 스크립트와 문서는 [이 리포지터리](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/overlay)에 있다. 다음 단계는 그곳에 있는 자세한 요령을 따라서 단순히 진행하는 것이다. - -[Flannel start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) 스크립트를 다운로드받고, 그 내용을 `C:\k`에 풀어 넣자. - -```PowerShell -cd c:\k -[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/start.ps1 -o c:\k\start.ps1 -``` +![alt_text](../kubecluster.ps1-join.gif "KubeCluster.ps1 join output") {{< note >}} -[start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1)은 [install.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/install.ps1)을 참고하는데, 이는 사용자를 위해 `flanneld` 실행 **파일 같은** 추가 파일과 [인프라스트럭처 파드를 위한 Dockerfile](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/Dockerfile)을 다운로드하고 설치한다. 오버레이 네트워킹 방식에서 [방화벽](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/helper.psm1#L111)은 지역 UDP 4789 포트에 대해 열려있다. 여러 파워쉘 윈도우가 열렸다 닫히며, 포드 네트워크를 위한 새로운 외부 vSwitch가 처음 생성되는 동안 몇 초간은 네트워크가 중단된다. 아래 지정한 인수를 사용하여 스크립트를 실행하자. +어떤 이유에서든 부트스트랩 동안이나 참여 과정에서 스크립트가 실패하면, 뒤따르는 참여 시도를 시작하기 전에 신규 PowerShell 세션을 시작해야한다. {{< /note >}} -```PowerShell -cd c:\k -.\start.ps1 -ManagementIP ` - -NetworkMode overlay ` - -ClusterCIDR ` - -ServiceCIDR ` - -KubeDnsServiceIP ` - -LogDir -``` +본 단계는 다음의 행위를 수행한다. -| 파라미터 | 기본값 | 비고 | -| --- | --- | --- | -| -ManagementIP | N/A (필요함) | 윈도우 노드에 할당할 IP 주소. 이 값을 찾기 위해 `ipconfig` 이용할 수 있다. | -| -NetworkMode | l2bridge | 여기서는 `overlay`를 사용한다. | -| -ClusterCIDR | 10.244.0.0/16 | 클러스터 IP 설계을 참고한다. | -| -ServiceCIDR | 10.96.0.0/12 | 클러스터 IP 설계을 참고한다. | -| -KubeDnsServiceIP | 10.96.0.10 | | -| -InterfaceName | Ethernet | 윈도우 호스트의 네트워크 인터페이스 이름. 이 값을 찾기 위해 ipconfig 이용할 수 있다. | -| -LogDir | C:\k | Kubelet과 Kube-proxy가 각각의 로그 출력 파일을 리다이렉션하는 디렉터리이다. | +1. 컨트롤 플레인("마스터") 노드에 SSH로 접속해서 [Kubeconfig 파일](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 얻어온다. +1. kubelet을 윈도우 서비스로 등록한다. +1. CNI 네트워크 플러그인을 구성한다. +1. 선택된 네트워크 인터페이스 상에서 HNS 네트워크를 생성한다. + {{< note >}} + 이는 vSwitch가 생성되는 동안 몇 초간의 네트워크 순단현상을 야기할 수 있다. + {{< /note >}} +1. (vxlan 플러그인을 선택한 경우) 오버레이 트래픽을 위해서 인바운드(inbound) 방화벽의 UDP 포트 4789를 열어준다. +1. flanneld를 윈도우 서비스로 등록한다. +1. kube-proxy를 윈도우 서비스로 등록한다. -이제 다음을 실행하여 사용자 클러스터 내에 윈도우 노드를 볼 수 있다. +이제 클러스터에서 다음의 명령을 실행해서 윈도우 노드를 볼 수 있다. ```bash kubectl get nodes ``` -{{< note >}} -Kubelet, kueb-proxy 같은 윈도우 노드 구성요소를 윈도우 서비스로 구성할 수 있다. 추가적인 방법은 [문제 해결](#troubleshooting)의 서비스와 백그라운드 프로세스 단원을 보자. 노드의 구성요소를 서비스로 실행하면 로그 수집하는 것이 문제 해결에 있어 중요한 부분이 된다. 추가 지침으로 기여 가이드에서 [로그 수집하기](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) 단원을 보자. -{{< /note >}} +#### 윈도우 노드를 쿠버네티스 클러스터에서 제거하기 +이 섹션에서는 윈도우 노드를 쿠버네티스 클러스터에서 제거하는 방법을 다룬다. + +앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/KubeCluster.ps1) 스크립트를 사용해서 클러스터에서 윈도우 노드를 제거한다. + + ```PowerShell + .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -reset + ``` + 이 때 `-ConfigFile` 쿠버네티스 구성 파일의 경로를 가리킨다. + +![alt_text](../kubecluster.ps1-reset.gif "KubeCluster.ps1 reset output") -### 공개 클라우드 제공자 +본 단계는 다음의 행위를 대상이되는 윈도우 노드에서 수행한다. + +1. 윈도우 노드를 쿠버네티스 클러스터에서 삭제한다. +1. 구동 중인 모든 컨테이너를 중지시킨다. +1. 모든 컨테이너 네트워킹(HNS) 자원을 삭제한다. +1. 등록된 모든 쿠버네티스 서비스(flanneld, kubelet, kube-proxy)를 해지한다. +1. 쿠버네티스 바이너리(kube-proxy.exe, kubelet.exe, flanneld.exe, kubeadm.exe)를 모두 삭제한다. +1. CNI 네트워크 플러그인 바이너리를 모두 삭제한다. +1. 쿠버네티스 클러스터에 접근하기 위한 [Kubeconfig 파일](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 삭제한다. + + +### 퍼블릭 클라우드 제공자 #### Azure @@ -304,10 +349,12 @@ AKS-Engine은 완전하고, 맞춤 설정이 가능한 쿠버네티스 클러스 #### kubeadm과 클러스터 API로 배포하기 -Kubeadm은 쿠버네티스 클러스터를 배포하는 사용자에게 산업 표준이 되었다. Kubeadm에서 윈도우 노드 지원은 미래 릴리스에 나올 것이다. 또한 윈도우 노드가 올바르게 프로비저닝되도록 클러스터 API에 투자하고 있다. +Kubeadm은 쿠버네티스 클러스터를 배포하는 사용자에게 산업 표준이 되었다. Kubeadm에서 윈도우 노드 지원은 쿠버네티스 v1.16 이후 부터 알파 기능이다. 또한 윈도우 노드가 올바르게 프로비저닝되도록 클러스터 API에 투자하고 있다. 보다 자세한 내용은, [Windows KEP를 위한 kubeadm](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/kubeadm/20190424-kubeadm-for-windows.md)을 통해 상담하도록 하자. + ### 다음 단계 이제 클러스터 내에 윈도우 컨테이너를 실행하도록 윈도우 워커를 구성했으니, 리눅스 컨테이너를 실행할 리눅스 노드를 1개 이상 추가할 수 있다. 이제 윈도우 컨테이너를 클러스터에 스케줄링할 준비가 됬다. {{% /capture %}} + diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index 97eb33b87b2c9..1733b756018c6 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -9,6 +9,7 @@ card: --- {{% capture overview %}} + 대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다. 또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다. @@ -25,7 +26,7 @@ card: 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta4/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근 @@ -160,6 +161,7 @@ track=stable {{% capture whatsnext %}} -더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다. +더 많은 정보는 +[쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다. {{% /capture %}} diff --git a/content/ko/examples/controllers/daemonset.yaml b/content/ko/examples/controllers/daemonset.yaml new file mode 100644 index 0000000000000..f6c598c9bf3df --- /dev/null +++ b/content/ko/examples/controllers/daemonset.yaml @@ -0,0 +1,42 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: fluentd-elasticsearch + namespace: kube-system + labels: + k8s-app: fluentd-logging +spec: + selector: + matchLabels: + name: fluentd-elasticsearch + template: + metadata: + labels: + name: fluentd-elasticsearch + spec: + tolerations: + - key: node-role.kubernetes.io/master + effect: NoSchedule + containers: + - name: fluentd-elasticsearch + image: gcr.io/fluentd-elasticsearch/fluentd:v2.5.1 + resources: + limits: + memory: 200Mi + requests: + cpu: 100m + memory: 200Mi + volumeMounts: + - name: varlog + mountPath: /var/log + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + terminationGracePeriodSeconds: 30 + volumes: + - name: varlog + hostPath: + path: /var/log + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers diff --git a/content/ko/examples/service/networking/custom-dns.yaml b/content/ko/examples/service/networking/custom-dns.yaml new file mode 100644 index 0000000000000..02f77a9efe09d --- /dev/null +++ b/content/ko/examples/service/networking/custom-dns.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + namespace: default + name: dns-example +spec: + containers: + - name: test + image: nginx + dnsPolicy: "None" + dnsConfig: + nameservers: + - 1.2.3.4 + searches: + - ns1.svc.cluster-domain.example + - my.dns.search.suffix + options: + - name: ndots + value: "2" + - name: edns0