1. Algorithm Study
2. Backend Class
Kubernetes
-
쿠버네티스는 컨테이너 관리자로
컨테이너 운영을 자동화하기 위한 도구i.e ) 메소스, 도커스웜
→오케스트레이션 도구: 많은 수의 컨테이너를 협조적으로 연동시키기 위한 통합 시스템이며 이 컨테이너를 다루기 위한 API 및 명령행 도구등이 함께 제공 -
컨테이너를 이용한 애플리케이션 배포 외에도 다양한 운영 관리 업무를 자동화
→ 도커 호스트 관리, 서버 리소스의 여유를 고려한 컨테이너 배치, 스케일링, 여러 개의 컨테이너 그룹에 대한 로드 밸런싱, 헬스 체크 등의 기능 -
쿠버네티스의 리소스란 애플리케이션을 구성하는 부품과 같은 것으로
노드, 네임스페이스, 파드
Kubernetes를 통해서 여러 가지 일을 할 수 있지만 부화 모니터링을 통한 부화 분산 역할도 진행 가능
📍여기서 같은 역할을 하는 **Load balancer 와 Kubernetes 차이점은 실행 환경
Kubernetes는 cluster라는 큰 컴퓨터 안에서 docker container가 실행되기 때문에 따로 가상 컴퓨터(instance)를 실행하지 않아도 분산 부화 가능 당연히 속도 면에서 Load balncer 보다 이점 있음
Cluster
- Kubernetes 클러스터(cluster)는
Kubernetes의 여러 리소스를 관리하기 위한 집합체 - Kubernetes 리소스 중에서 가장 큰 개념은
노드(node)입니다. 노드(node)는 클러스터(cluster)의 관리 대상으로 등록된 도커 호스트로, 도커 컨테이너가 배치되는 대상 - Kubernetes 클러스터(cluster) 전체를 관리하는 서버인 마스터가 적어도 하나 이상 있어야함
→하나 이상이라는 의미는 클러스터가 작동하기 위한 최소 조건이지만 실제 프러덕 환경에서는 절대 하나로 클러스터(cluster)를 구성하지 않으며, 최소 3개 이상의 마스터 노드를 갖음
Master Node
Kubernetes Cluster 전체를 컨트롤하는 역할로 API서버,스케줄러,컨트롤러 매니저, etcd 로 구성
- API서버(명령, 통신 관련): 모든 명령과 통신을 API를 통해서 함. 모든 기능은 REST API로 제공하고 그에 따른 명령을 처리
- Etec (정보 저장): Cluster의 데이터베이스 역할로 서버로 설정값이나 클러스터의 상태를 저장→ 분산형 Key/Value 형식이고 오픈소스이며, 빠른 응답과 신뢰성등의 장점이 있음
- 스케줄러(리소스들을 할당할지 선정): 파드나 서비스들을 적절한 노드에 저장하게 정리해주는 역할
- 컨트롤러 매니져(RC,SC,VC,NC 관리): Replica controller, Service controller, Volume Controller, Node controller를 생성하고 각 노드에 배포하여 관리
Example
Master Node = 본사
- api서버 = 본사 전산직
- etcd = 정보를 수집하는 직원
- 스케줄러 = 공장의 업무를 담당해주는 직원
- 컨트롤러 매니저 = 업무를 구체화 시켜주는 직원
Node
Master Node에 의해 주어진 명령어를 받고 실제 워크로드에 생성하여 서비스하는 컴포넌트 → Kubelet, kube-proxy, cAdvisor 와 컨테이너 런타임으로 구성
- Kubelet(통신):노드에 배포되는 에이전트로, 마스터의 API서버와 통신하면서 노드가 수행해야 할 명령을 받아 수행하고, 반대로 노드의 상태등을 마스터로 전달하는 역활
- Kube-proxy(노드 안에 트래픽 정리) : 노드로 들어오는 네트워크 트래픽을 적절한 컨테이너로 라우팅하고, 로드밸런싱등을 노드로 들어오고 나가는 네트워크 트래픽을 프록시하고 , 노드와 마스터간의 네티워크 통신을 관리
- container runtime: pod를 통해 배포된 컨데이너를 실행하는 역할, 컨테이너 런타임은 보통 도커컨데이너를 생각 / 이외에도 rkt,hyper container
- cAdvisor(모니터링): 각 노드에서 기동되는 모니터링 에이전트로, 노드내에서 가동되는 컨테이너들의 상태와 성능등의 정보를 수집하여, 마스터에게 전달
Example
Node = 공장- kubelet = 공장 전산직
- kube-proxy = 공장 직원에 업무를 명령을 일하는 직원에게 전송 직원
- container runtime= 공장기계 또는 일하는 직원
- cAdisor = 공장에 기계가 잘 돌아가는 지 확인하는 직원
Namespace
클러스터 안의 가상 클러스터를 네임스페이스(namespace)
→전체 클러스터에서 리소스의 구분 용도 즉, 전체 클러스터에서 특정 이름으로 클러스터의 영역을 구분
Pod
컨테이너가 모인 집합체의 단위로, 적어도 하나 이상의 컨테이너로 이뤄짐
📍앞서 언급한 컨테이너는 도커 컨테이너를 의미하는데 쿠버네티스를 도커와 함께 사용한다면 파드는 컨테이너 하나 혹은 컨테이너의 집합체가 됨
배포
블루 그린 배포 (Blue Green Deployment)
현재 운영하고 있는, 기존 버전을 가진 서버를 Blue 컴퓨터 → 모든 유저 연결
새로운 버전을 배포해야할 때, 새로운 버전을 가진 서버를 Green 컴퓨터에 켬
유저 트래픽 이동 : Blue → Green
Blue는 계속 대기하고 있다가, 혹시 Green에 문제가 생기면 다시 Blue로 트래픽을 옮김
✅ 단점은 현재 운영중인 서버의 2배 가량의 자원이 필요
카나리 배포 (Canary Deployment)
카나리 배포는 일부 유저 트래픽만 새로운 버전을 배포한 서버로 보내서, 문제가 없는지 체크
괜찮다면 더 많은 유저 트래픽을 새로운 배포한 서버로 보내고, 이를 반복
롤링 배포 (Rolling Deployment)
현재 운영중인 서버 중에서 하나의 컴퓨터를 끔
껐던 컴퓨터에 새로운 버전을 담아 배포 → 두번째 컴퓨터를 끔
이런식으로 기존버전에서 새로운 버전으로 트래픽을 점진적으로 전환하는 것
3. HW
