ParanBlog.

일단 Pod이 생성되면 Scheduling Queue에 들어가게 된다그 다음 Pod에 선언된 spec.priorityClassName에 의해 정렬된다.PrioritySort 플러그인에 의해 처리그 다음엔 필터링 단계에 들어가게 된다.Pod을 구동할 수 없는 노드(Affinity, Tint, Resource 등의 제한)들은 튕겨나간다.NodeResourceFit, NodeName, NodeUnschedulable 플러그인 등에 의해 처리그 다음엔 스코어링 단계이다.해당 Pod가 차지하는 공간을 제외하고 남는 free space의 크기에 따라 점수 부여남는 free space가 클수록 높은 점수가 나온다NodeResourcesFit, ImageLocality 플러그인에 의해 처리ImageLocality: 컨..

쿠버의 아키텍처 돌아보기마스터 노드kube-apiserveretcd clusterController Managerkube-scheduler워커 노드Kubelet워커노드의 Kublet은 Pod을 어떻게 배치할지에 대해 마스터노드의 Kube-apiserver에 의존이 결정은 Kube-scheduler에서 내림이것은 etcd에 저장됨만약 마스터노드가 없다면?워커노드 혼자서 떠있다면?Kubelet 혼자서 노드를 독립적으로 관리하는 것은 가능하다!이런 상황에서 Pod을 만드려고 한다면, kube-apiserver 없이 kublet에 어떻게 Pod definition file을 넣을것인가?kubelet이 특정 디렉토리에서 설정파일을 읽도록 설정할 수 있음이렇게 설정하면, Kubelet이 설정파일을 읽은 뒤에 Pod..

하나의 Pod가 모든 노드에서 하나씩 Replicate되도록 해 줌새 Node가 추가되면 자동으로 Pod의 Replica가 해당 노드에 추가됨새 노드가 삭제되면 자동으로 Pod도 삭제됨로그 뷰어라든지, 모니터링 agent 같은 데에 쓰면 좋다클러스터의 모든 Worker Node에는 Kube-Proxy가 존재사실 이것도 DaemonSet로 Replicated된 거거든요생성방법생긴 것은 ReplicaSet과 비슷하다apiVersion: apps/v1 // apps/v1임에 주의kind: DaemonSetmetadata: name: monitoring-daemonspec: template: metadata: labels: app: monitoring-agent spec:..

"Resources" - CPU, Memory, ...특징: 각 컨테이너에 대해 할당되는 값이다. 하나의 Pod에 여러 컨테이너가 있다면, 각각의 컨테이너는 다른 Resource Limit을 가진다.spec: containers: - name: asdf resources: requests: memory: "4Gi" cpu: 2 limits: memory: "8Gi" cpu: 4메모리야 4GiB라고 하지만 이 CPU 숫자는 무엇인가?CPU count1 CPU = 1 vCPU Core를 가리킨다 (SMT 시스템의 경우 1 SMT 쓰레드)0...

Taints, Tolerations특정 "Taint"가 씌워진 노드에는 Toleration이 없는 Pod가 배치될 수 없다강의에서는 "모기기피제를 뿌린 사람과 내성 없는 벌레"라는 비유를 쓴하지만, 만약 특정 Taint에 대한 Toleration이 있는 Pod라면 해당 Taint가 씌워진 노드에 배치될 수 있다.다만, 어떤 Pod이 특정 Taint에 대한 Toleration을 가지고 있다고 해서, Taint가 일치하는 노드에만 배치된다는 것은 아님스케줄러의 마음에 따라서는, 그냥 Taint 없는 다른 노드에 갈 수도 있음이것은 "특정 노드가 어떤 Pod을 받아들일것인가"에 대한 문제이기 때문에, "특정 Pod을 어떤 노드에 지정하고 싶다"라는 경우 Node Selector를 이용하여야 함즉 Taint는 ..

Imperative어떠한 목표를 달성하기 위한 자세한 instruction을 작성함(중간에 절차가 멈추고 뻗는다든가 했을 때에 resume하기가 귀찮아진다)'web-server'라는 이름으로 VM 생성Nginx 설치Nginx 설정파일 변경: 포트 8080 사용Nginx 설정파일 변경: 웹 경로 /var/www/nginx 사용Git Repo X에서 /var/www/nginx 경로에 pullnginx 시작Kubernetes에서의 imperative way장점:시험 볼 때같이 간단한 환경을 잠깐 쓸 때에는 좋음단점: 특정 Session에서 실행했을 때 해당 Session에서만 유효함.기능이 제약되어 있음 (multi-container pod deployment 등은 불가)Imperative command 이용..

지금까지는 Default 네임서페이스를 사용하고있었다.쿠버 내부에서 사용하는 Pod, Service에 대해서는, (DNS, 네트워킹 등) kube-system 네임서비스를 사용한다모든 사용자들이 사용할 수 있는 리소스는 kube-public으로 지정된다클러스터가 작으면 default 네임스페이스로 상관없지만, 엔터프라이즈/프로덕션 환경에서는 namespace로 나눠 쓰는 편이 좋다예를 들어, 개발환경과 프로덕션환경에서 똑같은 클러스터를 사용하면서도 리소스는 isolate하고 싶은 경우, Dev와 Prod 네임스페이스를 따로 만들어 사용할수있을것이다각네임스페이스는 누가 무엇을 할 수 있는지에 대한 정책을 가지고있다네임스페이스별로 최대사용가능 리소스 리밋을 걸 수 있다각각의 네임스페이스 구성원들끼리는 그냥 ..

앱 외부와 내부의 컴포넌트 간의 연결을 가능하게 함프론트와 백엔드 Pod group 간의 연결end user와의 연결 DB와의 연결서비스란, 노드상에 떠 있는 일종의 가상-서버같은 역할을 한다192.168.1.2라는 IP를 가진 Node 위에 있는 Pod의 네트워크 범위가 10.244.0.0/24 라고 하고, Pod의 IP가 10.0.244.2라고 하자.NodePortNodePort 서비스는 노드에서 외부 IP로 들어오는 특정 포트에 대해 listen하고 있다가, 해당 포트로 들어오는 연결을 Pod의 포트로 포워딩하는 역할을 한다.TargetPort: Pod에서 Listen하고 있는 포트Port: NodePort 서비스의 포트ClusterIP: NodePort 서비스의 내부 IPNodePort: 실제 노..

ReplicationController는 구세대 기술로 ReplicaSet으로 대체되고있다ReplicationControllerReplicationController/ReplicaSet은 쿠버네티스 클러스터 상에서 하나의 Pod에 대한 인스턴스 여려 개를 구동할 수 있게 하여 HA(High Availability)를 제공하나의 Pod만 존재하는 상황에서도 ReplicationController는 Pod 하나가 죽더라도 자동으로 Pod를 새로 만들어주므로, 쓸모가 있음단일 ReplicationController 아래에 여러 노드의 Pod이 있을 수 있음apiVersion: v1kind: ReplicationControllermetadata: name: myapp-rc labels: app: mya..

쿠버의 Object를 생성하기 위한 YAML은, Pod, Deployment, Service, ReplicaSet, 뭐든 상관없이 대강 아래처럼 생겼으며, 아래의 3가지 root level properties를 꼭 가져야한다.apiVersion: v1kind: Podmetadata: name: myapp-pod labels: app: myapp type: frontendspec: containers: - name: nginx-container # -는 YAML에서 리스트의 첫 항목임을 가리킴 image: nginx - name: busybox image: busyboxapiVersion / kindPod, Service: v1ReplicaSet, Deployment: ap..