CKA-7일차

📍 CKA 7일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 76-93

---

76. Multiple Schedulers

앞에서 스케줄러가 노드에 걸쳐 파드를 고르게 분배하는 알고리즘을 가지고 있다는 것을 배웠다.
스케줄러는 Taints, Toleration, nodeAffinity 등을 통해 우리가 지정하는 다양한 조건들을 고려한다.

쿠버네티스는 확장이 아주 쉽다. 그래서 쿠버네티스 스케줄러 프로그램을 작성해 기본 스케줄러로 패키지하거나 쿠버네티스 클러스터에서 추가 스케줄러로 배포할 수 있다.
그래야 다른 모든 응용 프로그램이 기본 스케줄러를 통과할 수 있다.
하지만 일부 특정 응용 프로그램은 우리가 작성한 사용자 지정 스케줄러를 사용할 수 있다.

쿠버네티스 클러스터는 한번에 여러 스케줄러를 가질 수 있다.
파드를 만들거나 배치할 때 쿠버네티스에게 특정 스케줄러가 파드를 지정하도록 지시할 수 있다.

스케줄러가 여러개일 경우 반드시 이름이 달라야 한다. 그래야 각각의 스케줄러를 구분할 수 있다.
스케줄러 설정 파일을 통해 각각의 스케줄러의 이름을 설정한다.
이때 이름을 지정하지 않으면 default-scheduler이다.

추가적인 스케줄러를 배포하는 방법은 다음과 같다.
kube-scheduler 바이너리를 다운로드해서 여러 옵션과 함께 kube-scheduler.service로 실행한다.
추가적인 스케줄러를 배포하기 위해서는 동일한 kube-scheduler 바이너리를 이용할 수 있다. 혹은 우리가 구축한 것을 이용할 수 있다.
아래 사진에서는 같은 바이너리를 이용해 추가적인 스케줄러를 배포했다.

각 스케줄러는 별도의 config 파일을 사용하고 파일마다 고유한 스케줄러 이름을 갖는다.

99%의 경우 사용자 지정 스케줄러를 이렇게 배포하지 않는다.
kubeadm에선 모든 컨트롤 플레인의 구성요소가 쿠버네티스 클러스터 안에서 pod 또는 deployment로 배포되기 때문이다.

스케줄러를 파드로 배포할 경우 파드 정의 파일을 생성하고 --kubeconfig 속성을 명시한다.
이는 스케줄러의 conf 파일로 가는 경로로서 kube-api server에 연결하기 위한 인증 정보가 있는 파일이다.
그런 다음 사용자가 작성한 config 파일 경로를 --config 속성으로 지정한다. config 파일에는 스케줄러 이름이 명시되어 있다.

또 다른 중요한 옵션은 config 파일에 명시되는leaderElection 옵션이다.
leaderElection 옵션은 스케줄러의 복사본 여럿이 다른 마스터 노드에서 실행할 때 사용된다. 고가용성을 위해 여러 개의 마스터 노드에서 쿠버네티스 스케줄러 프로세스가 양쪽에서 실행된다.
동일한 스케줄러의 복사본 여러 개가 다른 노드에서 실행될 경우 한 번에 하나만 활성화될 수 있다.
leaderElection 옵션은 스캐줄 활동을 이끌 리더를 선택하는데 도움이 된다.

어려워서 일단 생략... 뭄샤드 쌤이 아직은 몰라도 된다고 하심..

아래 사진처럼 config 파일을 스케줄러에게 전달하기 위해 볼륨 마운트나 ConfigMap을 사용한다.

새 스케줄러를 사용하기 위해 schdulerName 필드를 파드 정의 파일에 추가하고 사용할 스케줄러 이름을 명시하면 된다.

스케줄러가 잘 동작하는지 알기 위해서 이벤트를 확인하면 된다.
kubectl get events -o wide 명령으로 현재 네임스페이스에 있는 모든 이벤트를 열거하고 예정된 이벤트를 확인할 수 있다.
아래 사진에서 성공적으로 nginx를 node01에 할당했음을 확인할 수 있다.

문제가 생겼다면 kubectl logs {스케줄러 이름} 명령어를 통해 스케줄러의 로그를 확인해보면 된다.

---

78. Solution - Multiple Schedulers

새로운 스케줄러를 사용하기 위해 파드 정의 파일에 schedulerName을 지정해야 한다.

---

79. Configuring Scheduler Profiles

파드들은 Scheduling Queue에서 스케줄되기를 기다린다. 이때 파드를 분류하는 기준은 우선순위이다. 우선순위를 설정하기 위해서는 PriorityClass를 정의하면 된다.

우선순위에 따라 파드들이 정렬되어 우선순위가 높은 파드는 이렇게 가장 먼저 대기자 명단에 오르게 된다.

그 다음 필터링 단계에 돌입한다. 파드를 실행할 수 없는 노드는 여기서 걸러진다.
파드의 requests가 CPU 10이기 때문에 두 개의 노드가 리소스 부족으로 걸러진다.

그 다음은 점수 매기는 단계이다. 스케줄러는 해당 파드에 필요한 CPU를 제외하고 남은 공간을 근거로 각 노드에 점수를 매긴다.
이 경우 첫 번째 노드는 2개, 두 번째 노드는 6개 남는다.
두 번째 노드가 더 높은 점수를 갖기 때문에 선택된다.

마지막으로 바인딩 단계에서 파드가 마침내 가장 높은 점수를 가진 노드에 바인딩된다.

이 모든 작업의 특징은 플러그 인으로 이루어진다는 점이다.

• Scheduling Queue

  • PrioritySort: 파드에서 우선순위로 설정된 기준에 따라 순서대로 정렬한다.

• Filtering

  • NodeResourcesFit: 파드에서 요구하는 자원이 충분한 노드를 식별하고 부족한 노드를 필터링한다.

  • NodeName: 파드 정의 파일에서 지정된 nodeName이 있는지 확인하고 이름과 일치하지 않는 모든 노드를 거른다.
    

  • NodeUnschedulable: Unschedulable이 true로 설정된 노드들을 거른다.
    

• Scoring: 이 단계에서 특정 노드를 거부하지 않는다. 조립만 해보는 것이다.

  • NodeResourcesFit: 파드가 할당된 후 사용 가능한 리소스를 기반으로 점수를 매긴다.
  • ImageLocality: 파드의 이미지가 노드에서 컨테이너 이미지로 사용된다면 높은 점수를 준다.

• Binding

  • DefaultBinder: 바인딩 메커니즘을 제공한다.

쿠버네티스 제품은 확장성이 매우 뛰어나기 때문에 어떤 플러그인을 어디에 둘지 커스터마이징할 수 있고 자신만의 플러그인을 작성해서 사용할 수 있다.
각 단계마다 플러그인이 연결될 수 있는 확장 지점이 있다.
확장 지점에 생성한 플러그인을 연결하면 된다.

추가적인 플러그인들에 대한 세부사항들은 다음과 같다.
보다시피 일부 플러그인은 여러 확장 지점에 걸쳐 있다.

이제 어떻게 플러그인을 호출하고 어떻게 우리만의 플러그인을 사용할 수 있는지 알아보자.

단일 스케줄러에게 다중 프로필을 지원한다.
config 파일을 통해 단일 스케줄러에게 다중 프로필을 구성할 수 있다.
각각의 스케줄러는 분리된 개별 프로필을 갖는다.
각각의 스케줄러는 분리된 스케줄러처럼 작동한다. 단지 여러 개의 스케줄러가 하나의 바이너리로 실행되는 것 뿐이다.

어떻게 각 스케줄러가 다르게 작동하도록 구성할 수 있을까?

각 스케줄러의 프로필 아래에 확장 지점과 가능/불가능 여부, 플러그인 이름을 명시해서 우리가 원하는 방식으로 플러그인을 구성할 수 있다.

---

83. Monitor Cluster Components

오늘날 사용 가능한 오픈소스 모니터링 솔루션이 많다.

• Metrics Server
  • 쿠버네티스 클러스터 당 메트릭 서버가 1개이다.
  • 서버는 각 쿠버네티스 노드와 파드에서 메트릭을 회수한다.
  • 메트릭을 모아서 메모리에 저장한다. 즉, IN-MEMORY 모니터링 솔루션이기 때문에 디스크에 메트릭을 저장하지 않는다.
  • 그래서 과거 데이터는 볼 수 없다.
    

이 노드의 파드에 대한 지표는 어떻게 생성될까?

kubelet은 각 노드에 위치하여 kube-api server로부터 지시를 받고 노드에서 파드를 실행하는 역할을 한다.
또한 kubelet은 CAdvisor로 알려진 하위 요소를 포함하고 있다.
CAdvisor는 파드에서 성능 메트릭을 회수하고 kubelet API를 통해 메트릭을 노출시켜 Metric Server에서 사용가능하게 한다.

minikube 환경과 다른 환경에서 각각 다음 명령어를 실행하여 Metric Server를 시작할 수 있다.

Metric Server가 클러스터 내 노드에서 성능을 측정할 수 있도록 데이터를 수집하고 처리할 시간을 주어야 한다.
kubectl top 명령어를 통해 노드와 파드의 성능 지표를 확인할 수 있다.

Metric-server는 Kubernetes 내에 존재하는 Pod의 메트릭을 실시간으로 수집해 kube-api 서버에 안정적으로 전달하는 역할을 합니다.
참고: https://nangman14.tistory.com/81

---

84. Solution: Monitor Cluster Components

Metric Server 배포하기 (단, 다른 production에 해당 깃허브 레포지토리를 사용하지 말 것! 쉬운 배포를 위해 일부를 변경하였음)

node와 pod의 성능 지표 확인하기

---

86. Managing Applicaion Logs

도커에서 docker logs 명령어로 로그를 확인할 수 있다. '-f' 옵션은 실시간으로 로그를 확인할 수 있도록 해준다.

쿠버네티스도 도커와 마찬가지로 kubectl logs 명령어로 파드의 로그를 확인할 수 있으며 '-f' 옵션을 통해 실시간 로그 확인도 가능하다.

하나의 파드는 여러 개의 도커 컨테이너를 실을 수 있다.
파드 안에 여러 개의 컨테이너가 있다면 명령에 컨테이너 이름을 명시해야 한다.

---

88. Solution: Logging

webapp-2는 2개의 컨테이너를 가진 파드이기 때문에 어떤 컨테이너의 로그를 확인할 것인지 명시해야 한다.

---

91. Rolling Updates and Rollbacks

새로운 rollout은 새로운 revision을 생성한다.
향후 컨테이너 버전이 새 것으로 업데이트되면 새로운 rollout이 생기고 새로운 revision이 생성된다.
이렇게 하면 변화를 추적할 수 있고 필요하다면 배포 이전 버전으로 되돌아갈 수 있다.

kubectl rollout 명령어를 통해 rollout 상태와 rollout 기록을 확인할 수 있다.

배포 전략에는 두 가지 유형이 있다.

• Recreate
  • 인스턴스들을 모두 파괴하고 인스턴스의 새 버전을 생성한다.
  • 구버전이 다운되고 새 버전이 업되기 전 기간 동안 응용 프로그램은 다운되고 사용자가 접근할 수 없다.
  • 기본 전략이 아니다.
• RollingUpdate
  • 구 버전을 제거하고 신 버전을 하나씩 올린다.
  • 앱이 다운되지 않고 업그레이드가 원활하게 이루어진다.
  • 기존 전략이다.
    

두 명령어는 각각 deployment를 업데이트하여 새로운 rollout을 생성하고 새로운 revision이 만들어진다.
후자의 방법은 deployment 정의 파일과 다른 구성을 갖게 되기 때문에 주의해야 한다.

업그레이드를 잘못해서 새 버전 빌드에 문제가 있다면 kubectl rollout undo 명령어를 사용해서 이전 리비전으로 롤백할 수 있다.
새 replicaset의 파드가 파괴되고 이전의 replicaset으로 돌아간다.

이번 강의에서 배운 명령어를 요약하자면 다음과 같다.

---

93. Solution: Rolling update

deployment의 이미지를 수정하는 명령어이다.
kubectl set image deployment {deployment명} {컨테이너명}={이미지명}

배포 전략 바꾸기(RollingUpdate -> Recreate)

kubectl edit deployment 명령어로 파드 정의 파일에 접속해서 strategy의 type을 'Recreate'으로 수정한다.