본문 바로가기
  • 노션에서 삽질한 내용을 정리하는 블로그
자기발전소/# Docker and K8s

K8s 공부 : 쿠버네티스의 개요

by iamlucia 2020. 10. 1.

 

쿠버네티스 란,

 

 

오케스트레이션?
바이올린 소리가 더 필요하면 바이올린 대수를 더 많이 배치하고 다른 악기와의 배치를 고려하여 위치를 선정하는 기능 


쿠버네티스를 쓰는 이유 :  편리한 "Scale Out "

Scale Up : 서버 수를 유지하되, 해당 서버의 스펙을 점점 증가시키기 

Scale Out  :  사람들의 커넥션이 너무 많아져서 서버 한대로 모자를 때, 동일한 스펙의 서버를 여러 대 더 추가 배치

요즘의 애플리케이션 운영에서는 Scale Out > Up 더 많이 사용 

 

개발자가 서비스하고자 하는 소스 코드를 컨테이너화하여 도커 허브에 push로 업로드 해놓고,
쿠버네티스 마스터에게 해당 컨테이너를 10 개 컨테이너로 만들어 달라고 요청 (=Scale out)

 

쿠버네티스는 "컨테이너 Orchestration 도구" 이다.

Layer 6 "Development Workflow(CI/CD)" - OpenShift /  Cloud Foundary / Docker Cloud / ... 
Layer 5 "Orchestration/Scheduling" - Kubernetes / Docker Swarm / Msos /  Nomad / ...
Layer 4 "Container Engine" - Docker / Rocket / LXC / ...
Layer 3  "Operating System" - Ubuntu / RHEL / CoreOS / ... 리눅스에 대한 지식 중요!
Layer 2 "Virtual Infrastructure" - vSphere / EC2 / GCP/ Openstack / ...
Layer 1 "Physical Infrastructure" - Raw Computer / Network / Storage 

 

단순한 구조의 쿠버네티스

단일 마스터 워커3노드 구조

 

 

 

쿠버네티스가 하는 일

사용자입장에서는 웹서버가 5대인지 6대인지 알 수 없음 -> CLOUD에 가려져있다

 


쿠버네티스 Cluster Architecture

K8s의 Master Node 와 Worker Node를 더 자세히 살펴보자.

 

컨테이너를 싣고 가는 여러 개의  cargo ship(worker)과 
이 배에 컨테이너를 싣고 컨테이너들을 관리하는 control ship(master:관리, 계획, 스케줄, 모니터링)이라고
나누어 생각하면 
이해가 편하다! 


Control Plane (Master Node) Components 

kube-scheduler* 각 노드의 상태를 보고 어떤 컨테이너를 배치할 지 관리
Worker Node에 컨테이너를 고르게 분포
Controller-Manager 
서로 다른 area 들의 상태를 고루 살펴보며
전체적인 컨테이너들의 damage 관련된 task를 관리하는 컴포넌트
  - Node Controller
노드의 health Check 
  - Replication Controller
각 컨테이너의 health check 통해 정해진 수만큼 컨테이너들이 유지될 수 있게 조절
Replica Group 이 잘 유지되고 있는지 확인
API Server Client의 명령어를 받는 곳 
외부 사용자들이 클러스터 관리하게 되는 인터페이스 
etcd 전체 운영 환경에 대한 로그를 저장하는 저장소 (제대로 운영되는지 여부 확인)
어떤 종류의 컨테이너, 몇 개의 컨테이너가 키-밸류 형태로 저장되는 데이터 스토어 

 

 

Worker Node Components

마스터 노드에 있는 모든 컴포넌트들은 컨테이너 형태로 호스트 되기 때문에, 

컨테이너와 호환가능한 애플리케이션이 필요

-> 즉, 컨테이너를 실행할 수 있는 소프트웨어가 필요:  Container Runtime Engine

대표적인 Engine: Docker, Rocket

kubelet  각 마스터 노드가 컨테이너를 싣고 있는 cargo ship이라고 한다면, kubelet은 그 배의 선장
control plane의 api 요청을 받는 곳 
kube-proxy 서로 다른 노드에 있는 컨테이너 (클러스터 내 서비스_)간 통신을 위한 것