Primes's Infra Tech

쿠버네티스의 Monitoring 쿠버네티스에서는 자체적인 모니터링 솔루션이 없다. 따라서 별도의 오픈소스 모니터링 툴을 이용해야 한다. 주로 사용되는 것은 Prometheus, Elastic Stack 등이 있겠다. 과거에는 Heapster 라는 모니터링 프로젝트를 사용했으나, 현재는 사용하지 않고 Metric Server 라는 간소화된 방식을 사용한다. Metric Server 동작 방식은 아래와 같다. - 클러스터당 메트릭 서버를 1개 생성한다. 해당 서버는 각 쿠버네티스의 노드 및 파드에서 메트릭을 가져와 메모리에 저장한다. - Metric Server는 In-Memory 방식으로 동작한다. 따라서 메트릭을 디스크에 저장하지 않아 오랜 기간 동안의 누적 지표와 같은 데이터는 확인할 수 없다. => ..

처음은 정렬 단계이다. 파드들은 스케줄링 될 때, 노드에 스케줄 되는 것을 기다린다. 파드는 생성될 때, 우선순위가 정해져 있다. 이는 파드 정의 파일에서 필드로 정의할 수 있다. 우선순위 클래스를 생성하고, 우선순위 값을 설정해야 한다. 파드의 우선순위 필드에서는 해당 클래스를 불러와 우선순위를 적용한다. 이렇게 우선순위를 적용하면, value가 높은 파드부터 스케줄링이 우선으로 노드에 배정된다. 다음은 필터링 단계이다. 파드를 실행할 수 없는 노드는 이 단계에서 배제된다. 리소스 부족, 적합하지 않은 조건 등에 따라 파드에 맞는 노드를 "필터링" 하는 단계이다. 다음은 스코어링을 진행한다. 선별된 노드들에 점수를 매겨 가장 적합한 노드를 최종 결정한다. 마지막 바인딩 단계에서 최종 결정된 노드에 파드..

스케줄러는 각 노드에 알맞는 조건, 리소스에 맞추어 파드를 배포하는 기본적인 알고리즘을 따른다. 이 때, 관리자 입장에서는 기본 스케줄러의 설정을 따르는 것이 아닌 몇몇 특정 프로그램들은 특별한 스케줄링 알고리즘을 가진 스케줄러를 사용을 원하는 상황이 발생할 수 있다. 이러할 경우 사용자 지정 스케줄러를 생성하여 배포를 진행할 수 있다. 쿠버네티스에서 파드를 배포할 때, 어떠한 스케줄러를 따를지 결정할 수 있다. 사용자 지정 스케줄러는 위와같이 정의할 수 있다. --kubeconfig 파일의 경로에 있는 scheduler.conf 파일은 kube-api server에 연결하기 위한 인증 정보가 담긴 파일이다. leaderElection 필드도 주목해야할 필요가 있다. 해당 옵션은 스케줄러 복사본을 여러 ..

DaemonSets DaemonSets는 각 노드가 생성될 때 같이 생성되는 기본 파드라고 이해할 수 있다. 노드가 생성되면 같이 생성되며, 삭제될 때 같이 삭제된다. DaemonSets은 파드의 복제본을 노드에 항상 존재하도록 하는 리소스라고 볼 수 있다. Monitoring 에이전트나, kube-proxy와 같이 모든 노드에 필수적으로 설치 및 설정되어야 할 요소들을 Daemonsets을 활용하면 간단하게 Scale-out/in 시 파드에 바로 적용할 수 있다. 데몬셋의 yaml 파일 정의 요소는 replicaset과 거의 동일하다. 이는 수행하는 역할이 비슷하기 때문인 것으로 보인다. Static Pods Static Pods는 kube-apiserver 에 의존하지 않고 pod-definition..

파드가 노드에 할당될 때, 노드에 가용량이 존재하지 않으면 할당이 될 수 없다. 스케줄러는 노드의 가용량을 확인하고 파드의 할당을 결정한다. 가용량이 전혀 없다면, 파드의 배포를 중단한다. yaml 파일로 리소스를 정의할 때, 리소스의 스펙을 기입할 수 있다. 이 때, cpu 갯수를 정의하게 된다면 1cpu = 1vCPU를 뜻하게 된다. memory는 1G, 1Gi 와 같이 기입할 수 있다. CPU의 경우에는 쿠버네티스가 자체적으로 가용량을 조절하여 한도를 넘지 않도록 한다. 하지만 메모리를 한도 이상으로 컨테이너가 사용하려고 한다면 그 파드는 즉시 종료된다. 이는 유의하여야 한다.

Node Selectors 리소스 가용량이 큰 Node1과, 가용량이 적은 Node 2/3이 있다고 가정한다. 많은 자원을 요구하는 애플리케이션을 Node1 에 할당하여야 할 때, Node Selector를 활용한다. pod 생성 시, nodeselector 필드를 추가하여 원하는 node에 할당될 수 있도록 설정한다. 위의 이미지에서는 Large 태그를 부여하고, Node1 도 large 속성을 가지도록 한다. Node1에 large 속성을 부여할 때는 아래와 같은 명령어를 사용한다. # kubectl label nodes = ==> kubectl label nodes Node1 size=Large 이렇게, Node Selector를 통해 원하는 조건에 맞는 노드에 파드를 할당할 수 있다. 하지만 더 ..

Taints ? - 비유하자면, 사람이 벌레에게 물리지 않기위해 몸에 해충제를 뿌리는 것과 같다. - Node에 Taint를 설정함으로써, pod가 노드에 할당되지 않도록 막는다. - 완전히 규제를 하는 것은 아니기 때문에, Scheduling 상 할당이 될 수도 있다. (설정으로 조정가능) Tolerations? - 위의 이미지에서, Taint를 위와 같이 설정하였을 때, D에게 하는 작업이 Toleration 이다. - D는 Node 1에 할당될 수 있도록 작업을 거쳤다. 따라서 D만 할당될 수 있다. Node에 Taint 부여하기 # kubectl taint nodes node-name key=value:taint-effect => taint-effect : 이 taint 를 설정하였고, 이 tai..

Labels - 라벨은 흔히 SNS, 유튜브/블로그에서 볼 수 있는 태그, 키워드와 비슷한 역할이라 볼 수 잇다. - 각 객체에 속성을 부여해 공통된 속성을 가진 객체끼리 모아 관리를 하기 위한 용도이다. Labels 는 yaml 파일 작성 시 지정할 수 있으며 갯수는 제한이 없다. 원하는 만큼 지정할 수 있다. 이렇게 지정하여 생성한 객체는 아래와 같은 방법으로 호출할 수 있다. # kubectl get pods --selector app=App1 => app=App1 를 label 로 가진 pod 출력 이러한 Labels는 Replicaset과 Service 에서, 지정한 속성의 파드들을 생성할 수 있도록 설정할 때 많이 사용된다. ※ Annotation - 주석의 의미이다. Labels, Selec..

Scheduler 동작방식 - 클러스터에 스케쥴러가 없다고 가정할 때, 직접 스케줄링을 해 본다고 생각하자. - pod-definition.yaml 파일을 통해 파드를 생성한다. - 모든 pod에는 nodeName 이라는 필드를 가진다. 해당 필드는 쿠버테니스가 일반적으로는 자동으로 추가하므로, 필드를 별도로 지정하진 않지만. 스케쥴러가 없다고 가정하기 때문에 직접 작성한다. - 스케줄러는 자동으로 각 파드에 적합한 노드를 바인딩한다. 하지만 스케줄러가 없다면, 위와같이 nodeName을 지정하여 직접 바인딩할 수 있도록 한다. - nodeName은 파드 생성 시에만 지정할 수 있다. - 그렇다면 기 생성된 파드에 노드를 할당하고 싶을 경우에는, API를 활용한다. => binding 개체를 생성하고 A..

Imperative / Declarative ? 비유하자면, 위의 사진과 같다. Imperative : 목적지에 도달하기 위해, "어떻게" 갈 것인지를 지정하는 방식 Declarative : 목적지만 지정하면 알아서 길을 찾아 도달하는 방식 => 정리하자면 Imperative는 수동적이고, Declarative는 능동적인 방식이라고 볼 수 있다. 쿠버네티스에서 위 사항을 적용해본다면, 아래와 같다. Imperative : 각종 리소스 생성 시 커맨드, yaml 파일을 통해 일일히 옵션들을 지정한다. ex) kubectl create deployment / pod, kubectl run 등등 각종 명령어들을 예로 들 수 있다. ex2) kubectl create -f ~~~.yaml 명령어를 통해 yaml..