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..695ca57c04a7a 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)에 대해 읽기 +* 노드 수준 토폴로지에 대해 읽기: [Control Topology Management Policies on a node](/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..5bb67bc5750f5 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 더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다 (위를 참조). +### 더 읽기 + +- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) +- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) +- [Pod Overhead](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 +- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) + {{% /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/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/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 %}}