쿠버네티스와 컨테이너 전반적 영역에 대한 최신 뉴스도 읽고, 방금 나온 따끈따끈한 기술적 노하우도 알아보세요.
+--- +{{< comment >}} + +블로그에 기여하는 방법에 대한 자세한 내용은 +https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post 를 참고하세요. + +{{< /comment >}} diff --git a/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md new file mode 100644 index 0000000000..de7d44ecad --- /dev/null +++ b/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -0,0 +1,104 @@ +--- +layout: blog +title: "당황하지 마세요. 쿠버네티스와 도커" +date: 2020-12-02 +slug: dont-panic-kubernetes-and-docker +--- + +**작성자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas + +쿠버네티스는 v1.20 이후 컨테이너 런타임으로서 +[도커를 +사용 중단(deprecating)](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)합니다. + +**당황할 필요는 없습니다. 말처럼 극적이진 않습니다.** + +요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 [컨테이너 런타임 인터페이스(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)를 +사용하는 런타임으로써는 더 이상 사용되지 않습니다(deprecated). +도커가 생성한 이미지는 늘 그래왔듯이 모든 런타임을 통해 클러스터에서 +계속 작동될 것입니다. + +쿠버네티스의 엔드유저에게는 많은 변화가 없을 것입니다. +이 내용은 도커의 끝을 의미하지 않으며, 도커를 더 이상 개발 도구로 사용할 수 없다거나, +사용하면 안 된다는 의미도 아닙니다. 도커는 여전히 컨테이너를 +빌드하는 데 유용한 도구이며, `docker +build` 실행 결과로 만들어진 이미지도 여전히 쿠버네티스 클러스터에서 동작합니다. + +GKE, EKS 또는 AKS([containerd가 기본](https://github.com/Azure/AKS/releases/tag/2020-11-16)인)와 같은 관리형 쿠버네티스 서비스를 +사용하는 경우 쿠버네티스의 향후 버전에서 도커에 대한 지원이 +없어지기 전에, 워커 노드가 지원되는 컨테이너 런타임을 사용하고 있는지 확인해야 합니다. 노드에 +사용자 정의가 적용된 경우 사용자 환경 및 런타임 요구 사항에 따라 업데이트가 필요할 수도 +있습니다. 서비스 공급자와 협업하여 적절한 업그레이드 +테스트 및 계획을 확인하세요. + +자체 클러스터를 운영하는 경우에도, 클러스터의 고장을 피하기 위해서 +변경을 수행해야 합니다. v1.20에서는 도커에 대한 지원 중단 경고(deprecation warning)가 표시됩니다. +도커 런타임 지원이 쿠버네티스의 향후 릴리스(현재는 2021년 하반기의 +1.22 릴리스로 계획됨)에서 제거되면 더 이상 지원되지 +않으며, containerd 또는 CRI-O와 같은 다른 호환 컨테이너 런타임 중 +하나로 전환해야 합니다. 선택한 런타임이 현재 사용 중인 +도커 데몬 구성(예: 로깅)을 지원하는지 확인하세요. + +## 많은 사람들이 걱정하는 이유는 무엇이며, 왜 이런 혼란이 야기되었나요? + +우리는 여기서 두 가지 다른 환경에 대해 이야기하고 있는데, 이것이 혼란을 야기하고 +있습니다. 쿠버네티스 클러스터 내부에는 컨테이너 이미지를 가져오고 +실행하는 역할을 하는 컨테이너 런타임이라는 것이 있습니다. 도커를 +컨테이너 런타임(다른 일반적인 옵션에는 containerd 및 CRI-O가 있음)으로 많이 +선택하지만, 도커는 쿠버네티스 내부에 포함(embedded)되도록 설계되지 않았기에 문제를 +유발합니다. + +우리가 "도커"라고 부르는 것은 실제로는 하나가 아닙니다. 도커는 +전체 기술 스택이고, 그 중 한 부분은 그 자체로서 고수준(high-level)의 +컨테이너 런타임인 "containerd" 입니다. 도커는 개발을 하는 동안 +사람이 정말 쉽게 상호 작용할 수 있도록 많은 UX 개선을 포함하므로 +도커는 멋지고 유용합니다. 하지만, 쿠버네티스는 사람이 아니기 때문에 +이런 UX 개선 사항들이 필요하지 않습니다. + +이 인간 친화적인 추상화 계층의 결과로, 쿠버네티스 클러스터는 +containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심(Dockershim)이라는 +다른 도구를 사용해야 합니다. 이것은 좋지 않습니다. 왜냐하면, 이는 추가적인 유지 관리를 +필요로 하고 오류의 가능성도 높이기 때문입니다. 여기서 실제로 일어나는 일은 +도커심이 빠르면 v1.23 릴리스에 Kubelet에서 제거되어, 결과적으로 +도커에 대한 컨테이너 런타임으로서의 지원이 제거된다는 것입니다. 여러분 +스스로도 생각할 수 있을 것입니다. containerd가 도커 스택에 포함되어 있는 것이라면, 도커심이 +쿠버네티스에 왜 필요할까요? + +도커는 [컨테이너 런타임 인터페이스](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)인 CRI를 준수하지 않습니다. +만약 이를 준수했다면, 심(shim)이 필요하지 않았을 것입니다. 그러나 +이건 세상의 종말이 아니며, 당황할 필요도 없습니다. 여러분은 단지 +컨테이너 런타임을 도커에서 지원되는 다른 컨테이너 런타임으로 변경하기만 하면 됩니다. + +참고할 사항 한 가지: 현재 클러스터 내 워크플로의 일부가 기본 도커 소켓 +(/var/run/docker.sock)에 의존하고 있는 경우, 다른 +런타임으로 전환하는 것은 해당 워크플로의 사용에 문제를 일으킵니다. 이 패턴은 종종 +도커 내의 도커라고 합니다. 이런 특정 유스케이스에 대해서 +[kaniko](https://github.com/GoogleContainerTools/kaniko), +[img](https://github.com/genuinetools/img)와 +[buildah](https://github.com/containers/buildah) +같은 것들을 포함해 많은 옵션들이 있습니다. + +## 그렇지만, 이 변경이 개발자에게는 어떤 의미인가요? 여전히 Dockerfile을 작성나요? 여전히 도커로 빌드하나요? + +이 변경 사항은 사람들(folks)이 보통 도커와 상호 작용하는 데 사용하는 것과는 다른 환경을 +제시합니다. 개발에 사용하는 도커의 설치는 쿠버네티스 클러스터 내의 +도커 런타임과 관련이 없습니다. 혼란스럽죠, 우리도 알고 있습니다. 개발자에게 +도커는 이 변경 사항이 발표되기 전과 마찬가지로 여전히 +유용합니다. 도커가 생성하는 이미지는 실제로는 +도커에만 특정된 이미지가 아니라 OCI([Open Container Initiative](https://opencontainers.org/)) 이미지입니다. +모든 OCI 호환 이미지는 해당 이미지를 빌드하는 데 사용하는 도구에 관계없이 +쿠버네티스에서 동일하게 보입니다. [containerd](https://containerd.io/)와 +[CRI-O](https://cri-o.io/)는 모두 해당 이미지를 가져와 실행하는 방법을 알고 있습니다. 이것이 +컨테이너가 어떤 모습이어야 하는지에 대한 표준이 있는 이유입니다. + +변경은 다가오고 있습니다. 이 변경이 일부 문제를 일으킬 수도 있지만, 치명적이지는 +않으며, 일반적으로는 괜찮은 일입니다. 사용자가 쿠버네티스와 상호 작용하는 +방식에 따라 이 변경은 아무런 의미가 없거나 약간의 작업만을 의미할 수 있습니다. +장기적으로는 일이 더 쉬워질 것입니다. 이것이 여전히 +혼란스럽더라도 괜찮습니다. 이에 대해서 많은 일이 진행되고 있습니다. 쿠버네티스에는 변화되는 +부분이 많이 있고, 이에 대해 100% 전문가는 없습니다. 경험 수준이나 +복잡성에 관계없이 어떤 질문이든 하시기 바랍니다! 우리의 목표는 +모든 사람이 다가오는 변경 사항에 대해 최대한 많은 교육을 받을 수 있도록 하는 것입니다. `<3` 이 글이 +여러분이 가지는 대부분의 질문에 대한 답이 되었고, 불안을 약간은 진정시켰기를 바랍니다! + +더 많은 답변을 찾고 계신가요? 함께 제공되는 [도커심 사용 중단 FAQ](/blog/2020/12/02/dockershim-faq/)를 확인하세요. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index b9e6b92435..18133b6577 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -327,6 +327,26 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. +## 그레이스풀(Graceful) 노드 셧다운 + +{{< feature-state state="alpha" for_k8s_version="v1.20" >}} + +`GracefulNodeShutdown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한 경우 kubelet은 노드 시스템 종료를 감지하고 노드에서 실행 중인 파드를 종료한다. +Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다. + +`GracefulNodeShutdown` 기능 게이트가 활성화되면 kubelet은 [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 사용하여 주어진 기간 동안 노드 종료를 지연시킨다. 종료 중에 kubelet은 두 단계로 파드를 종료시킨다. + +1. 노드에서 실행 중인 일반 파드를 종료시킨다. +2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다. + +그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다. +* `ShutdownGracePeriod`: + * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다. +* `ShutdownGracePeriodCriticalPods`: + * 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이는 `ShutdownGracePeriod`보다 작아야 한다. + +예를 들어 `ShutdownGracePeriod=30s`, `ShutdownGracePeriodCriticalPods=10s` 인 경우 kubelet은 노드 종료를 30 초까지 지연시킨다. 종료하는 동안 처음 20(30-10) 초는 일반 파드의 유예 종료에 할당되고, 마지막 10 초는 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다. + ## {{% heading "whatsnext" %}} @@ -335,3 +355,4 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 섹션을 읽어본다. * [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다. + diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index d749710484..228e0af585 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -17,7 +17,7 @@ weight: 70 ## 이미지 수집 -쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의 +쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의 라이프사이클을 관리한다. 이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다: @@ -36,26 +36,26 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 ## 사용자 설정 -사용자는 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다. +여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다. 1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로 기본값은 85% 이다. 2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로 기본값은 80% 이다. -또한 사용자는 다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의 할 수 있다. +다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다. -1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집 -되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다. +1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집 +되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다. 2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된 인스턴스의 최대 수. 기본 값은 1 이다. 3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수. 기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다. 컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은 -문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도 -1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container` -값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers` +문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도 +1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container` +값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers` 의 값도 상대적으로 더 큰 값을 권장한다. 자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다. @@ -82,5 +82,3 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다. - - diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index a24b3bb93f..b72d38a360 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -55,11 +55,12 @@ weight: 50 주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고 프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다. -쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내 +쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내 컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두 `localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한 `Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도 -VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다. +VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 +한다. 이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index e4dedb068a..b897a0e79a 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -128,6 +128,25 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` +### kube-scheduler 메트릭 + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다. + +kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다. +- 네임스페이스 +- 파드 이름 +- 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열 +- 우선순위 +- 해당 파드에 할당된 스케줄러 +- 리소스 이름 (예: `cpu`) +- 알려진 경우 리소스 단위 (예: `cores`) + +파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다. + +메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트 +와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 1f01481270..8f499fbc6a 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -600,6 +600,10 @@ spec: example.com/foo: 1 ``` +## PID 제한 + +프로세스 ID(PID) 제한은 kubelet의 구성에 대해 주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다. 자세한 내용은 [Pid 제한](/docs/concepts/policy/pid-limiting/)을 참고한다. + ## 문제 해결 ### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index e75beb8666..557fb50397 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -134,7 +134,7 @@ data: [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면 서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다. 또한 파드에서 서비스 어카운트를 참조하는 방법을 -[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의 +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의 `automountServiceAccountToken` 필드와 `serviceAccountName` 필드를 통해 확인할 수 있다. @@ -152,7 +152,7 @@ data: 인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지 확실히 확인해야 한다. -`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의 +`kubernetes.io/dockerconfigjson` 타입은 `~/.dockercfg` 의 새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을 따르는 직렬화 된 JSON의 저장을 위해 디자인되었다. 이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를 @@ -347,22 +347,21 @@ data: usage-bootstrap-signing: dHJ1ZQ== ``` -부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다. +부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다. - `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. -- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 +- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 문자열. 선택 사항. - `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를 사용하는 절대 UTC 시간. 선택 사항. - `usage-bootstrap->
+ # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
- apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
+ apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
- apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
-{{% /tab %}}
-{{% tab name="CentOS, RHEL 또는 Fedora" %}}
- # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
- yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
-{{% /tab %}}
+ apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
+
+{{< /tab >}}
+{{< tab name="CentOS, RHEL 또는 Fedora" >}}
+
+ # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
+ yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+
+{{< /tab >}}
{{< /tabs >}}
-kubelet을 다시 시작한다.
+- kubelet을 다시 시작한다.
```shell
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
+### 노드 uncordon
+
+- 노드를 스케줄 가능으로 표시하여 노드를 다시 온라인 상태로 전환한다.
+
+ ```shell
+ #