Primes's Infra Tech

스케줄러는 각 노드에 알맞는 조건, 리소스에 맞추어 파드를 배포하는 기본적인 알고리즘을 따른다. 이 때, 관리자 입장에서는 기본 스케줄러의 설정을 따르는 것이 아닌 몇몇 특정 프로그램들은 특별한 스케줄링 알고리즘을 가진 스케줄러를 사용을 원하는 상황이 발생할 수 있다. 이러할 경우 사용자 지정 스케줄러를 생성하여 배포를 진행할 수 있다. 쿠버네티스에서 파드를 배포할 때, 어떠한 스케줄러를 따를지 결정할 수 있다. 사용자 지정 스케줄러는 위와같이 정의할 수 있다. --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..

쿠버네티스는 각종 리소스들을 서비스 구성을 위해 자동으로 생성한다. 이 때, 원활한 리소스 관리 및 휴먼 폴트를 방지하기 위해 유저로부터 중요한 리소스들을 격리한다. 위의 이미지와 같이, Namespaces 를 따라 리소스들을 분리하여 생성하게 된다. kube-system 은 클러스터를 시작할 때 생성하고, kube-public 은 모든 사용자가 사용할 수 있어야 하는 리소스들이 생성되는 namespace 이다. 기본적으로, 유저가 작업하는 namespace는 Default 공간이 된다. 일반적인 테스트 환경이나 작은 환경에서는 Default 공간에서만 작업해도 크게 문제가 없다. 하지만 기업 규모로 쿠버네티스를 도입하게 되면 모든 리소스 관리를 Default 에서만 생성하고 관리하기 어렵다. 이러할 때..

쿠버네티스에서 서비스는 애플리케이션 간 통신, 외부 사용자와 애플리케이션의 통신을 가능하게 하는 역할을 담당한다. 위의 이미지에서 처럼, 각각 다른 애플리케이션을 담당하는 파드들이 있고 각 파드들이 모두 원활히 통신을 하여야 제대로 된 서비스를 유저에게 제공할 수 있다. 위와 같이 구성된 예시에서, 외부 사용자는 파드와 같은 내부 네트워크에 위치하고 있지 않기 때문에 일반적으로는 접속할 수 없는 것이 정상이다. 이러할 경우 외부 사용자가 내부 애플리케이션에 접근할 수 있는 방법은, 노드에 SSH로 접속한 뒤, 노드 내부에서 파드의 애플리케이션을 불러와 접속하는 방식으로 접근을 할 수 있다. 하지만 일반적인 외부 사용자에 대한 서비스는 이러한 방식으로 제공되지 않는다. 외부 사용자가 SSH 같은 접근 방식..