이번 포스팅은 강의를 듣고 쿠버네티스에 대해
정리한 포스팅. 아래 내용은 모두 강의에 있는 내용을 정리한 것입니다.
강의 링크 : https://www.youtube.com/watch?v=l42GttmnnZ4
Container의 개념,
S/W 실행에 필요한 것을 패키지로 구성하여 표준화된 하나의 독립 컨테이너에 저장
VM과 달리 컨테이너는 전체 os가 아닌 s/w 필요로 하는 라이브러리와 설정만 포함
Linux Container란,
단일 Linux 호스트에서 Container 독립 실행을 위한 OS 가상화 기술
Linux Kernel의 cgroups, namespace를 공유함
파일 실행은 호스트에서 직접 실행하여 빠름
Docker Container / Docker Mission,
Linux Container 기술을 적용한 Docker Engine
Docker Hub Registry를 통한 Docker Image 관리
어디서나 이미지를 빌드하고, 이동하고, 어느 엔진 에서나 이미지를 돌아가게 하는 것이 미션
Docker Image 란,
Docker Image Layer Model
- Base Image를 기반으로 생성
- 이전 이미지의 정보에서 변경된 내용이 새로운 이미지로 생성
- 서로 다른 컨테이너를 독립적으로 실행
Container Orchestration,
컨테이너 관리가 필요한 이유? 컨테이너가 많아질수록 관리하기 힘들어짐
변수를 통제하고 안정적인 서비스를 목표로 하는 운영계에서 체계적으로 관리해야 함
스케줄링, Cluster 관리, 서비스 Discovery, 모니터링, 설정
Container Orchestration Players,
아래 이미지는 컨테이너의 레이어
Kubernetes, Docker는 Layer 5에 해당한다.
Kubernetes란,
컨테이너 오케스트레이터 (실행 및 관리), 다양한 클라우드 및 베어 메탈 환경 지원
100% go 언어로 작성, 개발 속도가 빠른 장점이 있음
Kubernetes 특징,
Automatic binpacking
: 가용성에 대한 희생 없이, 리소스 사용과 제약 사항을 기준으로 자동으로 컨테이너를 스케줄
Self-healing
: 자동으로 문제가 발생한 노드의 컨테이너를 대체 (룰/정책에 따른 헬스 체크)
Horizontal scaling
: CPU와 메모리와 같은 리소스 사용에 따라 자동으로 어플리케이션을 확장
: 경우에 따라서, 사용자 정의 측정값을 기준으로 한 동적인 확장 가능
Service discovery and Load balancing
: Container에 고유한 IP 부여
: 여러 개의 Container을 묶어 단일 service로 부여하는 경우 단일 DNS name으로 접근하도록 로드 밸런싱을 제공함
Automatic rollouts and rollbacks
: 다운 타임 없이 애플리케이션의 새로운 버전 및 설정에 대한 롤아웃/롤백 가능
Secret and configuration management (pv, pvc)
: 애플리케이션의 secret과 configuration 정보를 이미지와 독립적으로 구분하여 별도의 이미지 재생성 없이 관리
Storage orchestration
: 소프트웨어 정의 저장장치를 기반으로 로컬, 외부 및 저장소 솔루션을 위한 동일한 방법으로 컨테이너에 마운트 할 수 있음
Batch execution
: CI 워크로드와 같은 batch성 작업 지원, crontab 형식으로도 스케줄링 가능
Kubernetes Architecture
- 팀장 : 마스터 노드, 팀원 : 워커 노드(N개)로 생각하면 됨
- Master node - Worker node - Registry로 연결되어 있음
마스터 노드
- kube-adviserver : cluster와 상호 작용을 위한 k8s API 서버 (명령어를 받아 처리를 담당함)
- kube-scheduler : Worker node에 있는 pod를 스케줄
- kube-controller-manager : Deployments나 Replication Controller 등 관리
- kube-cloud-manager : Public Cloud Provider 연동 관리
- etcd : Master cluster에서 k8s object 저장소로 사용
워커노드 (Worker or Minion)
- Container runtime : 컨테이너 실행을 위한 Docker Engine 포함
- kubelet : Master의 명령 수행을 위한 k8s 에이전트
- kube-proxy : 인바운드 또는 아웃바운드 트래픽에 대한 네트워크 프록시 담당
: 워커가 받은 요청을 파드로 전달하는 역할을 함
- cAdvisor : Container Advisor는 리소스 사용/성능 통계를 제공
Kubernetes Cluster Control Plane
<< 마스터 노드 >>
<<워커 노드>>
- Ingress Controller : 인터넷/외부에서 들어오는 요청을 처음으로 처리하는 곳, 클러스터로 들어오는 모든 트래픽을 분배해주는 곳 (실 서비스할 경우 꼭 필요)
Kubernetes Object Model
k8s object에 대한 manifest를 YAML 형식으로 작성
Master 노드의 API Server를 통해 클러스터에 k8s object 작성
- Kubernetes Object API Version
버전이 지속적으로 업데이트가 된다. 사용해보고 돌아가는 것으로 사용, 혹은 기본 예제 그대로 사용
- Kubernetes Object - Basic
Pod
Service
Volume
Namespace
- Kubernetes Object - Controllers
ReplicaSet
ReplicationController
Deployment
StatefulSets
DaemonSet
Garbage Collection
Jobs
CronJob
// Kubernetes Objects - Pod
Worker Node에서 실행되는 컨테이너의 집합
하나의 pod안에 여러 개의 컨테이너가 들어갈 수 있음 ex) nginx, wsgi, django가 하나의 pod 안에
하나의 pod에는 한 개 이상의 서비스로 지정될 수 있음 (외부에서 접근하려면 서비스로 지정이 되어야 함)
각각의 pod에는 고유한 IP가 할당됨(내부 IP)
하나의 pod내에서는 PID namespace, network와 hostname을 공유함, 같은 서버처럼 보임
// Kubernetes Objects - Service
Label Selector로 선택하며 하나의 endpoint로 노출되는 pod의 집합
종류 : ClusterIP, NodePort, LoadBalancer, ExternalName
현재 위 그림으로 보면, 하나의 워커 노드 안에 pod가 떠 있고 그 안에 앱이 떠있는 컨테이너가 있음, 이때 kubeproxy를 통해 pod에 연결하게 됨(pod안의 Container안의 App한테 연결), 외부 서비스에 연결하려면 pod에 접속할 수 있는 서비스에게 접근해야 함
결국 서비스는 외부에서 pod로 접속하기 위한 중간 다리 역할을 한다
// Kubernetes Objects - Ingress
서비스에 대한 L7(애플리케이션 레이어) 라우터 정의
사용자가 직접 서비스에 접근하지 않고 Ingress를 통해 접근
보통 기본 포트는 80 혹은 443을 사용함
Ingress 가 받은 요청은 kubeproxy로 전달되어 해당하는 파드로 요청이 넘어가게 됨
// Kubernetes Object - Deployment Controller
pod의 배포 및 관리에 사용
ReplicaSet을 자동으로 생성
Pod에 대한 rolling 업데이트 관리
API Server를 대표하는 게 실질적인 Deployment임
// Kubernetes Object - ReplicaSet
Replication Controller의 새로운 버전
가용성과 확장성 보장
사용자의 요청에 따른 pod의 숫자를 유지하고 관리
각각의 pod가 필요로 하는 정보 명세가 있는 template을 이용
// Kubernetes Object - else
ConfigMap : pod에 담긴 container에서 사용되는 구성 값
Secret : 컨테이너에서 사용되는 소량의 민감한 정보, volume이 자동으로 연결되어 container에서 사용
**다음과 같은 순서로 생성이 된다고 보면 됨 : Deployment >> ReplicaSet >> Pod