Primes's Infra Tech

파드가 노드에 할당될 때, 노드에 가용량이 존재하지 않으면 할당이 될 수 없다. 스케줄러는 노드의 가용량을 확인하고 파드의 할당을 결정한다. 가용량이 전혀 없다면, 파드의 배포를 중단한다. 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 같은 접근 방식..

다수의 애플리케이션들을 업데이트 할 때, 여러가지의 기법들이 사용된다. Rolling Update : 한 번에 모든 인스턴스의 애플리케이션들을 업그레이드 해버리면 서비스에 영향이 미친다. 따라서 각 인스턴스를 하나씩 돌아가면서 업데이트를 진행한다. Rollback : 업그레이드를 했는데, 오류가 발생하여 이전 버전으로 되돌릴 필요가 있을 때 롤백을 수행한다. 지금까지 학습한 쿠버네티스의 구조를 따르면 아래와 같다. 애플리케이션 > 파드 > 컨테이너 > ReplicaSet 여기서 ReplicaSet은 서비스 가용성을 위해 일정 갯수의 파드를 보장하는 역할을 수행한다. 그리고 이번에 학습할 Deployment는 애플리케이션의 버전을 관리할 때 필요한 기능을 제공하는 역할이며, ReplicaSet보다 상위에 ..

Replica 란? 단일 파드에서 애플리케이션이 죽었을 때, 외부 유저는 애플리케이션에 접속할 수 없게 된다. 이런 경우를 방지하기 위해 일반적으로 이중화 구성을 하게 된다. 쿠버네티스에서는 그러한 이중화 구성을 하지 않아도, Replication Controller 를 이용하여 고가용성을 챙길 수 있다. 단일 파드로만 애플리케이션을 구성하여도, Replication Controller가 가용성을 보장한다. 기존 파드가 죽었을 때, 새로운 파드를 자동으로 생성하고 불러오도록 동작한다. Replication controller는 단일 가용성 외에, 부하 분산에도 이용한다. 여러 파드를 배포하고, 파드에 로드 밸런싱을 구성하였을 때, Cloud 에서의 Auto Scaling 과 같이 트래픽 유입이 늘어나면 ..