StarLord

디플로이먼트의 파드 템플릿(즉, .spec.template)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. 예를 들면 템플릿의 레이블이나 컨테이너 이미지가 업데이트된 경우이다. 디플로이먼트의 스케일링과 같은 다른 업데이트는 롤아웃을 트리거하지 말아야 한다. Deployment Strategy recreate : 기존 POD 모두 shutdown > 일괄 업그레이드 rolling update : 하나씩 shutdown > 업그레이드 롤오버(일명 인-플라이트 다중 업데이트) 디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 .spec.selector 레이블과 일치..

Metrics API를 사용하면 유용한 정보들을 볼 수 있다. kubectl top nodes kubectl top pods Metrics Server 구축 minikube : minikube addons enable metrics-server 그 외 : git clone https://github.com/kubernetes-incubator/metrics-server.git 에서 받은 YAML 실행 Metrics Server metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의 Kubelet에 CPU와 메모리 사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서 머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는 컨테..

새로 생성된 모든 파드 또는 예약되지 않은 다른 파드에 대해 kube-scheduler는 실행할 최적의 노드를 선택한다. 그러나 파드의 모든 컨테이너에는 리소스에 대한 요구사항이 다르며 모든 파드에도 요구사항이 다르다. 따라서 기존 노드들은 특정 스케줄링 요구사항에 따라 필터링 되어야 한다. 클러스터에서 파드에 대한 스케줄링 요구사항을 충족하는 노드를 실행 가능한(feasible) 노드라고 한다. 적합한 노드가 없으면 스케줄러가 배치할 수 있을 때까지 파드가 스케줄 되지 않은 상태로 유지된다. 스케줄러는 파드가 실행 가능한 노드를 찾은 다음 실행 가능한 노드의 점수를 측정하는 기능 셋을 수행하고 실행 가능한 노드 중에서 가장 높은 점수를 가진 노드를 선택하여 파드를 실행한다. 그런 다음 스케줄러는 바인딩..

데몬셋 데몬셋 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다. 데몬셋의 일부 대표적인 용도는 다음과 같다. 모든 노드에서 클러스터 스토리지 데몬 실행 모든 노드에서 로그 수집 데몬 실행 모든 노드에서 노드 모니터링 데몬 실행 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. DaemonSet을 Create하려면 ..

기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 컴퓨팅 리소스로 실행된다. 리소스 쿼터을 사용하면 클러스터 관리자는 네임스페이스별로 리소스 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다. 각 NameSpace에 Resource Limit을 정할 수 있다. apiVersion: v1 kind: LimitRange metadata: name: cpu-limit-range spec: limits: - default: cpu: 1 defau..

NodeSelector nodeSelector 는 가장 간단하고 권장되는 노드 선택 제약 조건의 형태이다. nodeSelector 는 PodSpec의 필드이다. 이는 키-값 쌍의 매핑으로 지정한다. 파드가 노드에서 동작할 수 있으려면, 노드는 키-값의 쌍으로 표시되는 레이블을 각자 가지고 있어야 한다(이는 추가 레이블을 가지고 있을 수 있다). 일반적으로 하나의 키-값 쌍이 사용된다. Node affinity Node affinity는 Pod가 특정 node로 배포되도록 하는 기능이다. 예전에 label에서 설명했던 node selector 도 node의 label과 pod의 selector label이 매칭되는 node에만 배포하도록 하기 때문에, 사실상 Node affinity와 같은 기능을 한다 N..

Taint And Tolerance ■ 조회 kubectl get pods --selector [env=dev] : 'dev' labeled POD를 조회 kubectl get pods --selector [env=dev,bu=finance] : 'env=dev' and 'bu=finance' labeled POD를 조회 ■ 생성 kubectl taint nodes [node1] [key=value1]:NoSchedule : node1 노드에 테인트을 배치한다. 이는 일치하는 톨러레이션이 없으면 파드를 node1 에 스케줄할 수 없음을 의미한다. ■ 삭제 kubectl taint nodes [node1] [key1=value1]:NoSchedule- kubectl taint nodes controlpla..

taint 노드마다 설정가능. 설정한 노드에는 POD가 스케줄되려면 조건이 붙음 toleration taint를 무시할 수 있음 주로 노드를 지정된 역할만 하게할 때 사용합니다. 옵션 - NoSchedule : toleration이 없으면 pod이 스케쥴되지 않음, 기존 실행되던 pod에는 적용 안됨 - PreferNoSchedule : toleration이 없으면 pod을 스케줄링안하려고 하지만 필수는 아님, 클러스터내에 자원이 부족하거나 하면 taint가 걸려있는 노드에서도 pod이 스케줄링될 수 있음 - NoExecute : toleration이 없으면 pod이 스케줄되지 않으며 기존에 실행되던 pod도 toleration이 없으면 종료시킴 명령어 kubectl taint node {nodename..

kube-scheduler kuber-scheduler는 이름에서 알 수 있듯이 새로운 포드들이 만들어질때 현재 클러스터내에서 자원할당이 가능한 노드들 중에서 알맞은 노드를 선택해서 그곳에 포드를 띄우는 역할을 합니다. 포드는 처음 실행될때 여러가지 조건을 지정해서 실행하는데, kube-scheduler가 그 조건에 맞는 노드를 찾아주는 역할을 합니다. 필요한 하드웨어 요구사항이라던가, 어피니티/안티어피니티(affinity/anti-affinity) 조건을 만족하는지, 특정 데이터가 있는 노드에 할당한다던가 하는 다양한 설정을 할 수 있습니다. ※ Scheduler가 없으면 노드 배치를 자동으로 못한다. ※ 그때는 수동으로 nodeName을 지정해서 배치하면 POD가 Running되긴한다. ■kube-s..

NameSpace When you grow and use a kubernetes cluster for enterprise or production purpose you want to consider the use of namespace as you can create your own namespaces as well. Service 쿠버네티스 외부 또는 내부에서 Pod에 접근할 때 사용하는 기능이다. service를 사용하는 이유는 Pod는 서버와 같이 영구적인 것이 아니라 일회적인 것이기 때문이다. 서버는 문제가 생기면 서버를 재 시작하고 서비스를 재 시작 하지만 Pod는 문제가 생기면 문제가 생긴 Pod를 삭제한 뒤 새로운 Pod를 생성한다. 그렇기 때문에 Pod의 IP는 고정적이지 않고 가변적이다...