강의를 들으면서 정리한 것 업로드 예정입니다

Cluster

• 함께 묶인 Node의 집합
• Node가 실패해도 다른 Node App 실행 가능

Worker Node

• k8s가 설치되는 물리적, 가상의 머신
• Container가 호스팅 되는 곳이다
• Node가 죽을 수 있다(응용프로그램 다운됨) → 여러개의 Node 필요

Container Runtime

• Docker 등의 옵션
• 컨테이너 실행을 담당하는 SW이다

Kublet

• 클러스터의 각 Node에서 실행되는 에이전트
• 예상대로 컨테이너가 노드에서 실행되는지 확인하는 책임이 있다
• master와 상호작용하는 에이전트

Master Node

• Contol plane 역할
• 클러스터 관리
  • 전반적인 결정(예를 들어, 스케줄링)을 수행
  • 클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동시키는 것) 감지 및 반응

kube-apiserver

• k8s controle plane의 frontend처럼 동작한다
• 명령어 인터페이스 등 모두 API 통신을 사용하여 k8s 클러스터와 상호작용한다
• 수평확장이 가능하여 인스턴스 간 트래픽을 균형있게 조절가능

Etcd

• 클러스터 관리에 사용되는 모든 key-value 저장소이다
• Cluster의 정보를 분산 방식으로 저장한다

Scheduler(kube-scheduler)

• 컨테이너 배포하는 것을 책임진다
• 새로 생성된 컨테이너를 찾아 노드에 할당

Controller(kube-contoller-manager)

• 오케스트레이션
• Node, 컨테이너, endpoint가 다운될 때를 인지하고, 대응하는 역할이다

Kubectl

• Cluster의 contol plane과 통신에 사용되는 명령줄 도구
• 클러스터 정보를 얻고, 클러스터 내의 다른 노드 상태를 얻고, 배포 등에 사용됨
• pod를 생성해 container 배포
• container image는 어디서? → Docker Hub(Docker image 저장소)

Pod

• K8S는 WorkerNode에 직접 컨테이너를 배포하지 않는다

• Container은 Pod라는 캡슐형태로 포장된다

• 보통 Pod는 Container과 1:1 관계이다(여러개도 가능)

  • 보통 같은 application이 같은 Pod에 Contatiner로 존재하지 않음
  • Helper Container 등은 같은 Pod에 배치될 수 있다
  • 두 컨테이너는 localhost로 통신 가능
  • 같은 저장공간 공유 가능
  • 만약 pod로 묶지 못한다면 각 application container과 helper container를 매핑하는 작업이 필요하다

• 응용 프로그램 규모를 키우기위해 기존 Pod에 Container를 추가하는게 아니라, Pod하나를 더 만들거나 Worker Node를 만든다