Udemy CKA 강의 정리 76: Multiple Schedulers

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이번 강의에서는 Kubernetes 클러스터에 여러 스케줄러를 배포하는 방법을 살펴봅니다.

이전 강의에서 기본 스케줄러가 Kubernetes에서 어떻게 작동하는지 살펴보았습니다. 파드를 노드 전체에 균등하게 분배하는 알고리즘을 가지고 있을 뿐만 아니라, 우리가 지정하는 다양한 조건(taints, tolerations, node affinity 등)을 고려합니다. 그러나 이들 중 어느 것도 요구사항을 충족시키지 못하면 어떻게 될까요?

몇 가지 체크를 한 후에 노드에 배치해야 하는 애플리케이션이 있다고 가정해 봅시다. 커스텀 조건을 추가하여 체크할 수 있는 자체 스케줄링 알고리즘을 만들어봅시다.

Kubernetes는 확장성이 뛰어납니다. Kubernetes 자체 스케줄러 프로그램을 작성하고 패키징하여 디폴트 스케줄러로 배포하거나 Kubernetes 클러스터의 추가 스케줄러로 배포할 수 있습니다. 다른 모든 애플리케이션은 기존 디폴트 스케줄러를 사용하고, 일부 특정 애플리케이션은 커스텀 스케줄러를 사용할 수도 있습니다.

Kubernetes 클러스터는 한 번에 여러 스케줄러를 가질 수 있습니다. 파드 또는 deployment를 생성할 때 특정 스케줄러에서 파드를 스케쥴링하도록 Kubernetes에 지시할 수 있습니다. 어떻게 하는지 살펴보겠습니다.

여러 스케줄러가 있는 경우, 별도의 스케줄러로 식별할 수 있도록 서로 다른 이름을 가져야 합니다. 따라서 디폴트 스케줄러의 이름은 default-scheduler입니다. 그리고 이 이름은 다음과 같은 scheduler-config 파일에 구성됩니다.

디폴트 스케줄러는 이름을 지정하지 않으면 이름을 디폴트 스케줄러로 설정하기 때문에 실제로 설정할 필요는 없습니다. 다른 스케줄러에 대해서는 별도의 구성 파일을 만들고 스케줄러 이름을 이렇게 설정할 수 있습니다.

Deploy Additional Scheduler

추가 스케줄러를 배포하는 가장 간단한 방법을 알아보겠습니다. 이전에 Kubernetes kube-scheduler를 배포하는 방법을 살펴보았습니다. kube-scheduler 바이너리를 다운로드하고 일련의 옵션을 사용하여 서비스로 실행했었습니다. 이제 추가 스케줄러를 배포하기 위해 동일한 kube-scheduler 바이너리를 사용하거나 직접 빌드한 것을 사용할 수 있습니다. 이는 스케줄러가 다르게 작동해야 하는 경우 수행할 작업입니다.

이 경우에는 동일한 바이너리를 사용하여 추가 스케줄러를 배포할 것입니다. 이번에는 우리가 만든 custom configuration 파일에 대한 구성을 가리킵니다.

따라서 각 스케줄러는 별도의 구성 파일을 사용하며, 각 파일에는 자체 스케줄러의 이름이 있습니다. 그리고 쿠버네티스 API에 인증하기 위한 kubeconfig 파일과 같이 전달해야 할 다른 옵션이 있다는 점에 유의하세요.

Deploy additional scheduler - kubeadm

kubeadm 배포를 사용하면 모든 컨트롤 플레인 컴포넌트가 파드 또는 Kubernetes 클러스터 내 배포로 실행되기 때문에, 오늘날 커스텀 스케줄러를 배포할 때 99%의 경우 이런 방식으로 배포하지 않습니다.

그럼 다른 방법을 알아보겠습니다. 스케줄러를 파드로 배포하는 경우 어떻게 작동하는지 살펴보겠습니다. 파드 definition 파일을 생성하고 쿠버네티스 API 서버에 연결하기 위한 인증 정보가 있는 스케줄러 config 파일의 경로인 kubeconfig 속성을 지정합니다. 그런 다음 사용자 지정 kube-scheduler 구성 파일을 --config 옵션으로 스케줄러에 전달합니다. 아래 처럼 파일에 스케줄러 이름이 지정되어 있습니다. 이것이 스케줄러가 선택하는 방식입니다.

여기에서 살펴볼 또 다른 중요한 옵션은 리더 선출 옵션입니다. 이것은 kube-scheduler 구성에 들어갑니다. 리더 선출 옵션은 서로 다른 마스터 노드에서 여러 개의 스케줄러 복사본이 고가용성 설정으로 실행되고 있을 때 사용됩니다. 이 경우 두 노드 모두에서 Kubernetes 스케줄러 프로세스가 실행되는 여러 마스터 노드가 있습니다. 동일한 스케쥴러의 여러 복사본이 서로 다른 노드에서 실행되는 경우, 한 번에 하나만 활성화할 수 있으며 여기에서 리더 선출 옵션이 스케쥴링 활동을 이끌 리더를 선택하는 데 도움이 됩니다. 다른 섹션에서 HA 설정에 대해 더 자세히 설명하겠습니다.

마스터가 여러 개인 경우 이 추가 파라미터를 전달하여 로그 오브젝트 이름을 설정할 수 있으며, 이는 새 사용자 지정 스케줄러를 디플트 프로세스와 구별하기 위한 것입니다.

이제 추가 스케줄러를 배포로 배포하는 방법을 살펴보겠습니다. 이를 위해 Kubernetes 설명서 페이지로 이동하여 여러 스케줄러를 구성하는 방법을 살펴보겠습니다.

여기를 보면 우선 방법을 보여줍니다. 자체 스케줄러를 구축하려는 경우 Kubernetes 리포지토리를 복제한 다음, kube-scheduler를 변경하고 빌드하여 Docker 이미지로 패키징하는 방법이 나와 있습니다. 그런 다음 여기에서 스케줄러를 배포로 만드는 구성 파일을 볼 수 있습니다. 그리고 처음에는 이 모든 것을 무시할 수 있습니다. 이것이 바로 실제 deployment입니다.
여기에는 고객 큐브 스케줄러 이미지가 있고, 이것은 방금 말씀드린 구성 파일로, 사용자 정의 내 스케줄러 구성 파일이 있습니다.  그리고 바이너리는 큐브 스케줄러 바이너리입니다.  이제 이것이 작동하려면 몇 가지 추가 전제 조건이 있는데, 그 중 일부는 서비스 계정과 클러스터 역할 바인딩과 같은 것으로, 기본적으로 인증을 위한 것입니다.  클러스터 역할 바인딩, 클러스터 역할, 서비스 계정에 대해서는 인증 섹션에서 설명합니다.  따라서 아직 읽어보지 않으셨다면 이 부분은 잠시 미루세요. 

그리고 이 파일을 배포에 전달하는 방법만 남았습니다.  따라서 이 파일을 로컬로 생성한 다음 다른 파드에서 일반적으로 수행되는 것처럼 볼륨 마운트로 전달할 수 있습니다.  또는 여기서 사용하는 또 다른 방법은 기본적으로 컨피그맵을 생성하는 것입니다.  그래서 이것은 리플리케이트가 하나라고 생각하기 때문에 리더 선출 옵션을 거짓으로 설정한 상태에서 방금 이야기한 큐브 스케줄러 구성입니다.  그리고 여기에 스케줄러 이름이 있습니다.  그래서 이것이 구성 파일이고 이 구성 파일은 여기에 볼륨으로 전달됩니다, 구성 파일로.  따라서 기본적으로 특정 구성 맵의 콘텐츠가 무엇이든 볼륨 마운트, 이 특정 위치의 볼륨에 매핑됩니다.  그리고 이 위치에서 기본적으로 이 콘텐츠가 포함된 YAML 파일을 갖게 됩니다.  이것이 매핑되는 방식입니다.  

하지만 이 과정의 볼륨 및 볼륨 마운트 섹션을 살펴보지 않으셨다면 지금은 잠시 보류하고 나중에 설명할 때 이해하실 수 있을 것입니다.  그리고 다시 한 번, liveness probe, readiness probes,  resources 및 보안 컨텍스트는 모두 나중에 설명하는 섹션입니다.  따라서 지금은 무시해도 됩니다.  

하지만 여기서 이해해야 할 것은 이 파일이 사용자 지정 스케줄러로 전달되는 방법에 대한 이 섹션입니다.  

View Schedulers

자, 여기까지입니다.  이제 강의를 계속 진행하겠습니다.  이제 kube-system 네임스페이스에서 get pods 명령을 실행하면 새 사용자 정의 스케줄러가 실행되는 것을 볼 수 있습니다.  이것은 파드로 실행한 경우이고, 배포로 실행한 경우에는 명명 규칙이 약간 다를 수 있지만 파드를 볼 수 있을 것입니다.  올바른 네임스페이스를 확인하고 있는지 확인하기만 하면 됩니다.  

이제 사용자 정의 스케줄러를 배포했으면 다음 단계는 이 새 스케줄러를 사용하도록 파드 또는 배포를 구성하는 것입니다.  그렇다면 사용자 정의 스케줄러는 어떻게 사용하나요?

Use the Custom Scheduler

여기에는 파드 정의 파일이 있으며, 스케줄러 이름이라는 새 필드를 추가하고 새 스케줄러의 이름을 지정하기만 하면 기본적으로 끝입니다.  이렇게 하면 파드가 생성될 때 올바른 스케줄러가 선택되고 스케줄링 프로세스가 작동합니다.  

이제 kubectl create 명령어를 사용하여 파드를 생성합니다.  

kubectl create -f pod-definition.yaml

스케줄러가 올바르게 구성되지 않은 경우, 파드는 계속 보류 상태로 유지됩니다.  그리고 모든 것이 정상이라면, 파드는 실행 상태가 됩니다.  따라서 파드가 보류 중인 상태라면, 파드 describe 명령인 kubectl describe 명령에서 로그를 확인할 수 있습니다.  그리고 대부분 스케줄러가 올바르게 구성되지 않았음을 알 수 있을 것입니다.  

View Events

어떤 스케줄러가 그것을 선택했는지 어떻게 알 수 있을까요? 스케줄러가 여러 개 있습니다.  어떤 스케줄러가 특정 파드를 스케줄링했는지 어떻게 알 수 있을까요? -o wide 옵션과 함께 kubectl get events 명령을 사용하여 이벤트에서 이를 확인할 수 있습니다.  

그러면 현재 네임스페이스의 모든 이벤트가 나열되고 예약된 이벤트를 찾을 수 있으며, 보시다시피 이벤트의 소스는 우리가 생성한 사용자 정의 스케줄러입니다.  이것이 바로 사용자 지정 스케줄러에 부여한 이름입니다.  그리고 메시지에는 이미지가 성공적으로 할당되었다고 나와 있습니다.  이는 작동 중임을 나타냅니다.  문제가 발생할 경우를 대비하여 스케줄러의 로그를 볼 수도 있습니다.  그러기 위해서는 kubectl logs 명령을 사용하여 로그를 보고 스케줄러 이름(파드 이름 또는 디플로이먼트 이름)과 올바른 네임스페이스를 제공하면 됩니다.