Fairy ' s

CPU 메모리와 디스크 리소스가 있는 노드가 3개 있는 클러스터가 있다. 모든 파드는 리소스 집합(CPU 2개, 메모리 1개, 디스크 공간 일부)을 사용한다. 파드가 노드에 배치될 때마다 해당 노드에서 사용할 수 있는 리소스를 소비한다. 파드가 이동할 노드를 결정하는 것은 Scheduler인데, 스케줄러는 파드에 필요한 리소스와 노드에서 사용 가능한 리소스의 양을 고려한다. 노드에 충분한 리소스가 없으면 스케줄러는 해당 노드에 파드를 배치하지 않고, 충분한 리소스를 사용할 수 있는 곳에 파드를 배치한다. 노드에서 사용할 수 있는 리소스가 충분하지 않은 경우 파드 예약을 보류(Pending)한다. Pending 상태인 파드는 우리가 직접 확인할 수 있으며, 이벤트 섹션을 보면 보류가 된 이유를 알 수 있다..

taint와 toleration을 이용해 blue, red, green 노드에 각각 색에 맞는 파드만 배치되도록 하려면 어떻게 해야할까? 노드에 taint를 색에 맞게 작용하고, 각 색상을 허용하도록 파드에 toleration을 설정하면 알맞는 toleration을 가진 파드만 수용할 수 있다. 하지만, taint와 toleration를 적용해도, 파드가 같은 색 노드에만 배치된다고 보장할 순 없다. 이 말은 즉, red 파드는 taint와 toleration 세트가 없는 다른 노드 중 하나에 배치될 수도 있다. Node Affinity를 이용하면 이 문제를 해결할 수 있다. Node Affinity로 알맞는 색상으로 노드에 label을 지정하고, Node Selector를 설정해서 파드를 노드에 연결하..

클러스터에 3개의 노드가 있다. 노드 중 2개는 더 낮은 하드웨어 리소스를 가진 더 작은 노드이고,나머지 노드 하나는 더 높은 리소스로 구성된 더 큰 노드이다. 다양한 종류의 워크로드가 클러스터에서 실행중이다. 더 높은 마력이 필요한 데이터 처리 워크로드를 더 큰 노드 전용으로 사용하려 한다. 하지만, 현재 기본 설정에서는 모든 파드는 모든 노드로 이동할 수 있기 때문에, 파드 C는 노드 2 또는 3으로 배치되어 죽을 수도 있다. 이를 해결하기 위해, 파드가 특정 노드에서만 실행되도록 제한할 수 있는 두 가지 방법이 있다. 1. Node Selector 이전에 생성한 파드 definition file을 살펴보면, 데이터 처리 이미지와 함께 파드를 생성하기 위한 간단한 정의가 있을 것이다. 이 파드가 더 ..

Taint : 노드에 유지 관리 중이거나 리소스가 제한된 것과 같은 특정 특성이 있음을 나타내는 노드에 적용되는 레이블이다. taint는 노드에 적용되며, 스케줄러가 내린 결정에 영향을 미치는 데에 사용된다. (노드에 설정) Toleration : 특정 taint가 있는 노드에 파드를 예약할 수 있도록 파드에 설정된 속성이다. 본질적으로 일치하는 taint가 있는 노드에서 예약되도록 파드에서 부여한 권한이며, 특정 taint에 대한 toleration이 있는 파드는 해당 taint가 있는 노드에서 예약할 수 있지만, 일치하는 toleration이 없는 다른 포드는 예약을 할 수 없다. toleration을 사용하면 어떤 파드가 어떤 노드에 배치되는지 제어하기 쉽다. (파드에 설정) 세 개의 워커 노드가 ..

우리는 Pod, Service, ReplicaSet, Deployment 등 다양한 유형의 서로 다른 오브젝트를 만들었다. 시간이 지나면 이런 오브젝트가 수없이 많아질 수 있는데, 그렇기 때문에 유형별로 오브젝트를 그룹화하거나, 기능별로 개체를 보는 것과 같이 다양한 범주별로 개체를 필터링하고 볼 수 있는 방법이 필요하다. 이럴 때 label과 selector를 사용하면 오브젝트를 애플리케이션이나 기능에 따라 레이블을 부착하여 그룹화하고 선택할 수 있다. 선택하는 동안 특정 오브젝트를 필터링할 조건을 지정할 수 있다. (ex. app=App1) Labels # pod-definition.yaml apiVersion: v1 kind: Pod metadata: name: simple-webapp labels..

스케줄러에 의존하지 않고 직접 파드를 예약하려고 할 때, 스케줄러는 어떻게 동작할까? 모든 파드에는 Node Name이라는 필드가 있다. 디폴트로는 값이 들어가 있지 않은데, 일반적으로 definition file을 만들 때 지정하지 않고, 쿠버네티스가 자동으로 추가하는 필드이다. 스케줄러는 모든 파드들을 검사하면서 Node Name 속성이 설정되지 않은 파드를 찾는데. 이들이 스케줄링의 후보가 되고, 그 다음 스케줄링 알고리즘을 사용해 파드에 적합한 노드를 고른 뒤 파드를 그 노드에 스케줄링한다. 이 때 바인딩 오브젝트를 생성하고, 파드의 Node Name에 그 노드의 이름이 들어가게 된다. 만약 모니터링하고 스케줄링할 스케줄러가 없다면, 파드는 계속 보류(Pending)중이게 된다. 이 경우 수동으로..

apply 명령은 변경사항을 적용하기 전에 로컬의 definition file과 kubernetes의 live configuration file 그리고 last applied configuration을 고려한다. apply 명령을 실행할 때, 오브젝트가 아직 존재하지 않는 경우에는 오브젝트가 생성 되고, 오브젝트가 생성되면, 오브젝트 구성은(우리가 로컬에서 만든 것과 유사한 형식) 쿠버네티스 내에서 생성된다. 쿠버네티스에서 live configuration이 오브젝트의 상태를 저장하는 추가 필드이다. live configuration을 통해 내부적으로 정보를 저장하고, 오브젝트를 생성하기 위해 kubectl apply 커맨드를 사용한다. 우리가 작성한 로컬 오브젝트 configuration 파일의 YAM..

쿠버네티스 인프라를 관리하는 것은 imperative(명령형) 접근 방식과 declarative(선언적) 접근 방식으로 분류할 수 있다. Provisioning Infrastructure Imperative : ' How ' 를 중요하게 두는 방식 Provision a VM by the name 'web server' Install NGINX software on it Edit configuration file to use port '8080' Edit configuration file to web path '/var/www/nginx' Load web pages to 'var/www/nginx' from Git Repo - X Starting NGINX server 무엇이 필요한지, 그것을 완료하려면 ..