위 영상을 보고 정리한 것입니다.
마이크로 서비스
가능한 서비스를 쪼개는 것
기존처럼 서버 하나하나마다 서비스를 올렸다고 하면
서비스를 쪼갤 때마다 서버를 구매하고 세팅해서 올려야 함
컨테이너
격리를 통해 한 호스트에서 분리된 컨테이너들이 돌아가게 됨
Docker Container
Docker Engine -> 여러 컨테이너 기술 중 하나
Docker의 목적 -> 어디서나 이미지를 빌드해서 운반하고 Docker Engine이 돌아가고 있는 아무 호스트에서나 돌아갈 수 있게 함
컨테이너 관리
Container Orchestration이 왜 필요한가?
컨테이너를 하나하나 돌리는 것은 간단하다.
여러 개 까지는 docker-compose를 사용해서 돌릴 수 있다.
컨테이너가 몇십 개, 몇백 개가 되어서 한 호스트에서 돌릴 수 없다.
여러 호스트에서 돌려야 되고, 얘네들 간의 서비스 Discovery, Networking을 고려해야 될 때는 어떻게 해야 되는가?
이게 문제가 되어서, 특히 운영 환경에서 필요한 Container Orchestration을 제안하게 된다.
Container Orchestration -> 컨테이너 여러 개, 호스트 여러 개를 한꺼번에 관리하고 서로 연동시키는 것
이게 하는 일
- 스케줄링: 내가 지금 어떤 컨테이너를 띄워야 되는가, 죽을 때 살려야 되는가?
- Cluster 관리: 서버들을 켜고, 내리고, 어떻게 살아있는 것을 체크해야 되는가?
- 서비스 Discovery: 서버 10대로 구성된 Cluster인데 올라간 서비스가 어디있는지 어떻게 찾는가?
- 모니터링: 컨테이너들이 잘 돌아가고 있는지, log 같은 것을 볼 수 있는가?
- 설정
Kubernetes
- Google이 오픈소스로 만들어서 공개했다.
- 컨테이너 오케스트레이션을 해 준다.
Kubernetes 특징
- Automatic binpacking: 쿠버네티스는 클러스터 안에 여러 개의 워커 노드를 돌리는 것을 기본으로 하고 있다. 그 중에 어떤 워커 노드에 컨테이너를 올릴 것인가?
- Self-healing: 문제가 발생한 노드를 어떻게 할 것인가? 노드의 컨테이너들이 죽었을 때 자동으로 살려주고, 노드 자체가 죽었을 때 다른 노드에 여기 있던 컨테이너들을 띄워준다.
- Horizontal scaling: 언제 서버들을 확장할 것인가?
- Service discovery and Load balancing
- Automatic rollouts and rollbacks: 알아서 다운타임 없이 롤아웃/롤백이 된다.
Canary Deployment: 일부 서버에만 새 버전을 배포하여 운영한 후에, 문제가 없는 것이 확인되면 전체 서버에 새 버전을 배포하는 방식
Blue-Green Deployment: 블루, 그린 2개의 환경을 라우터로 전환하는 방법
- Secret and configuration management: 기존에는 서버 접속정보를 파일로 관리했었는데, 이런 중요한 설정 정보들을 저장하고 관리하는 시스템을 제공한다.
- Storage orchestration: 생성된 데이터들을 어디에 저장할 것인가? 사용자가 업로드한 데이터를 어디에 저장할 것인가?
- Batch-execution: batch 작업도 쿠버네티스에서 지원한다.
Kubernetes 아키텍쳐
Kubernetes Master -> 워커 노드들을 모니터링
Kubernetes Master
- kube-apiserver: API 서버
- kube-scheduler
- kube-controller-manager
- cube-cloud-manager
- etcd: 저장소
Kubernetes Worker Node
팀원, 실제로 일하는 애들
- Container runtime: Docker Engine이 올라감
- kubelet: 명령을 실행시키는 역할을 함
- kube-proxy: 요청이 들어왔을 때 어떤 Pod한테 요청을 전달할 것인가?
- cAdvisor: 리소스 사용률
Ingress Controller -> Internet을 통해 들어오는 요청들을 처음에 처리한다.
Kubernetes Object Model
yml로 Kubernetes Object를 정의한다.
Kubernetes를 관리하는 모든 것들(Pod, Deployment, Ingress, …) 하나하나가 Object이다.
Kubernetes Objects
- Basic objects
- Pod
- Service
- Volume
- Namespace
- Controllers
- ReplicaSet
- ReplicationController
- Deployment
- StatefulSets
- DaemonSet
- Garbage Collection
- Jobs
- CronJob
나머지는 이런 것도 있구나 하고 넘어가면 된다.
Pod -> 컨테이너를 돌리는 최소한의 단위
Pod이 가장 중요하다.
- Pod -> Worker 노드에서 돌아가는 컨테이너의 집합
일반적으로 1개의 컨테이너를 1개의 Pod에 돌리게 됨
(한 Pod에 Django(uwsgi)랑 Nginx를 같이 깔아서 컨테이너 2개가 돌아가는 Pod을 만들수도 있음)
- 한 Pod에서는 PID namespace, network, hostname을 공유한다.
Service
Pod만 만들면 Pod끼리는 접속이 가능하지만 외부접속이 안 된다.
내부/외부에서 한꺼번에 접속하고자 할 때는 서비스로 노출하게 된다.
Pod에 Label을 붙이고, Label Selector로 선택하여 하나의 endpoint로 노출된다.
종류: ClusterIP, NodePort, LoadBalancer, ExternalName
Ingress
Apache나 Nginx의 Virtual Host와 비슷
(중요하지 않음)
ConfigMap -> 사전 정보 저장
Secret -> 민감한 접속 정보 저장
Kubernetes Objects — Controllers (중요)
ReplicaSet
Pod들이 늘어날 때는 어떻게 관리해야 되는가?
같은 역할을 하는 Pod들을 한 번에 ReplicaSet으로 관리한다.
Deployment
Pod의 개수는 ReplicaSet으로 줄였다 늘렸다 하는데, 이 ReplicaSet을 관리하는 것이 Deployment
Deployment를 만들었을 때 특정 버전에 대한 ReplicaSet이 나오고, 새 버전이 나오면 ReplicaSet을 새로 만든다.
다른 ReplicaSet이지만, 같은 Deployment로 관리한다.
Deployment를 만들게 되면, Deployment가 ReplicaSet을 만들고, Pod을 만들게 된다.
Kubernetes Objects — Controllers (안 중요)
StatefulSet
Pod에 Identity(name, network id 등)를 고정시킨다. 죽었다 띄워도 똑같이 띄운다.
DaemonSet
노드마다 하나씩 박아놔야 되는 게 있다고 하면, 그건 DaemonSet으로 뿌리면 모든 노드에 1개씩 실행된다.
Job
batch 형태로 돌아가는 것, 계속 돌아갈 필요가 없는 것은 Job으로 돌리면 된다.
Kubernetes Objects — Storages (살짝 중요)
Volume
Docker에서도 데이터를 Volume으로 관리. 일반적으로 host path에 연결한다.
docker-compose나 호스트가 1개인 엔진을 돌릴 때는 어차피 호스트가 1개니까 여기다 관리하면 되었다.
PersistentVolume
- k8s 클러스터 관리자가 관리해준다.
- Volume하고 비슷한데 Pod하고 독립적이다.
- 영구적으로 유지되어야 하는 데이터는 PV로 저장하게 된다.
- PVC(PersistentVolumeClaim), PVC를 갖다 쓸거야 라고 Claim을 해서 사용할 수 있다.
Kubernetes Tools
- kuberctl
- kubeadm
- minikube: 테스트로 로컬에서 kubernetes를 돌릴 때 씀
- Helm: chart로 해서 올리는 것
- Kompose: docker-compose를 kubernetes에서 올릴 수 있게 함
중요한 것 3가지는 기억하자.
Pod, ReplicaSet, Deployment
Pod에 컨테이너가 들어가고, Pod이 여러 개로 들어나면 Replica Set으로 관리하는데, Replica Set들이 여러 개 있을 수 있으니까 Deployment로 관리한다.
