Kubernetes?
구글에서 개발한 오픈소스 Constiner orchestration tool
클라우드, 가상머신 그리고 실제 물리적인 머신 등 다양한 환경에서 실행되는 수많은 컨테이너 Apps를 관리해주는 도구
컨테이너가 크래시 되었을 때 다른 컨테이너로 대체하거나, 컨테이너 간의 통신 등의 작업을 관리해서 원활한 운영을 지원
Kube
클라우드 컨테이너 구현 기술 중 하나
Kubernetes 기반의 Container 개발 및 운영을 위한 Add-on 서비스를 All-in-one 형태로 구성, Production 환경에 바로 적용 할 수 있는 플랫폼을 제공함.
특정 클라우드에 종속되지 않기에 원하는 시스템으로 kube 적용 가능, 통합관리
체계적인 컨테이너 조작, 관리도구로써 스케줄링, 클러스터 관리, 서비스 발견 모니터링 등을 설정해줌
kube로 할 수 있는 것들
- 환경설정: 컨테이너 서비스 선정, 저장 용량 산정, 개발환경 검토 및 산정
- 환경구성: 개발환경 개발/도입, 플랫폼 아키텍처 구성, 컨테이너 서비스 설치 및 설정
- APP개발: APP 아키텍처 수립, 설계 및 개발 , 개발자 기술지원, 성능 테스트 지원, 성능 모니터링 체계 구축(로그, APP 상태등)
- 플랫폼 운영과 유지: 모니터링, 백업/복구, 알림, 버전변경관리(플랫폼 패킷 및 업그레이드), 장애관리, 기술지원, 성능 점검 등
🚀 정리
Kubernetes의 computer를 통해서 virtual server와 auto scaling management를 통한 monitoring이 가능
개발자가 직접 서버에 애플리케이션을 설치하고 배포할 필요가 없음.
스케일 조절을 통해 애플리케이션을 수평적으로 확장, 트래픽 몰리면 여러 애플리케이션으로 부하가 분산되게 해주는 로드 밸런싱도 수행
Kube의 장점
- H/W 비용 대비 클라우드 리소스 비용 최대화: H/W 초기 도입 비용 불필요와 클라우드 리소스를 탄력적으로 활용 할 수 있으므로, APP 리소스 최적화를 통해서 비용 절감
- Add-on: 서비스 개발/구축비용 절감: 개발 및 운영에 대한 필요한 Add-on 서비스들을 All-in-One 형태로 제공하므로 별도의 비용이 발생하지 않음
- 운영업무 축소에 다른 비용절감: 플랫폼 운영을 지원하기에, 서버 OS 운영, 업그레이드, 패키지 관리 등의 운영 인건비가 필요하지 않음
Docker와 Container
도커와 컨테이너의 등장으로 애플리케이션의 배포와 관리 방식이 많은 부분에서 변화
모든 setting을 서버에서 직접 할 필요가 없으며, 컴파일 할 필요도 없음
애플리케이션 관리도 컨테이너 중심으로 관리하게되는 변화(관리 도구가 Kubernetes)
kubernetes 노드 시스템이 모듈 사용 시
Monolith 방식에서 Microservice 방식으로 전환해서 컨테이너 사용을 증가하게 함
컨테이너의 고가용성, 컨테이너의 downtime 감소, 확장성과 성능증가, 백업과 복원을 통한 재난극복 등을 가능하게함.
K8s 구성
- CLI
- VOLUMES
- Network
컨테이너의 Apps(APIs)를 배포하고 관리하는 사용량 요청(Demand)에 따라서 APIs의 규모를 늘리거나 줄여서 Downtime이 없게 함(Scaling)
문제가 있을 때 되돌릴 수 있음(Rollback)
=> 쿠버네지스에서는 자신이 관리하는 각 컨테이너를 Pod(파트)라고 부름.
Cluster
K8S에서 관리하는 가장 큰 단위, 여러 서버를 논리적으로 묶은 하나의 단위로 볼 수 있음
클러스터는 마스터인 master노드와 worker 노드들로 구성
Master: Sechduler, Cluster Store인 etcd, Controller Manager, API server, Cloud Controller Manager 등을 가짐
Worker: Apps가 실행되고 있는 여러 Docker들을 가지고 있는데 이들끼리 Ip주소를 가지고 통신
K8s는 key-value 구조로 Worker 노드들의 정보를 저장, 메인 Master에 문제가 있을 경우를 대비해서 backup-master 구성해 두기도 하는데 Worker 노드들은 문제가 있으면 교체/대체할 수 있지만, Master노드에 문제가 생기면 클라우드 전체가 실행되지 않을 수 있기 때문
Node
노드는 물리적/가상 호스트(서버)를 의미하는데 1개의 노드는 곧 1대의 머신이고, 노드는 여러 컨테이너를 가지고 있을 수 있으며, 각 컨테이너에서 Apps이 실행됨. K8S에서는 이들이 외부에 Pod로 표시
Pod
파드는 K8s의 최소 단위이며 컨테이너의 추상화된 객체. 하나의 Apps 당 하나의 컨테이너가 조냊, 하나의 Pod인 셈
애플리케이션 이미지가 있는 docker hub 링크를 설정한 뒤, 이미지 기반으로 컨테이너 가지고 있는 pod를 생성 할 수 있음.
pod는 하나 이상의 컨테이너를 묶어서 표현
=> 노드 내부에서는 여러 컨테이너가 돌아가고 있고, 컨테이너에 외부에서 접근 할 수 잇는 인터페이스가 Pod라고 보면 됨
Pod의 특징
- 쿠버네티스에서 Pod를 언제든지 버리고 새로 만들 수 있음
- Pod는 자신만의 가상 IP를 부여받지만 Pod가 새로 생성될 때마다 이 IP는 바뀜
즉 IP가 유동적으로 바뀌기 때문에 Pod를 독자적으로 배포한다면 IP 설정하기가 까다로움.
가상 IP를 가지고 있기 때문에 외부에서 Pod로 직접 접근할 수 없어서 실제로 접근 할 수 있는 경로 설정이 별도로 필요 - Pod 언제든지 장애가 발생하면 죽을 수 있음.
-> 애플리케이션이 중단될 가능성을 가지고 있음 - 사용하는 Image를 새로운 버전으로 업데이트하고 싶다면, 모든 Pod를 새로운 애플리케이션으로 업데이트해야 함
Pod는 이미 만들어진 컨테이너로만 작동하기 때문에 업데이트된 버전으로 실행하고자 한다면 현재 존재하는 Pod를 하나씩 제거하고 새로운 버전의 이미지를 가진 새 Pod를 생성해서 하나씩 교체하는 방식으로 진행
Service
Pod의 유동적 IP주소의 문제를 해결
Pod는 Service를 가지고 있음, Service는 영구적 IP주소를 가지고 있음, 언제든지 바뀔 수 있는 Pod의 IP를 사용하지 않고, Pod를 참조 할 수 있는 IP를 미리 정하여, Pod의 Ip가 변경될 때 자동으로 연결해주는 역할을 함
service는 고정적인 가상 ip를 가지고 있기에, 제거하지 않는 한 IP가 변하지 않아 API를 외부와 연동시키기에 적합
컨테이너의 서비스는 웹브라우저만 통신이 가능, DB Apps 브라우저를 통해서 외부브라우저의 ingress 과정 -> 파드의 External Service 과정으로 실행
Pod가 대신하는 내부 컨테이너 DB의 Service에 직접 접속하는 Internal Service 불가
ReplicaSet
Pod가 언제든지 죽을 수 있기 때문에 직접적으로 Pod가 관리해서
문제가 발생하면, 새로운 Pod 생성해서 대체하는 역할, 한 번에 여러 Pod 생성 할 수 있기 때문에 Pod 공장으로 볼 수 있음
Service는 Pod와 연결되어있으나, 연결을 도와주는 역할을 할 뿐 생성하거나 관리하는 것음 아님
Pod가 죽었을 때 살려주는 것은 ReplicaSet
Pod 생성하기 위해서 Pod와 관련된 생성 정보를 가지고 있어야 하므로 생성할 때 Pod 생성 정보를 함께 지정 명세 해줘야 함. 이 명세를 Template
Template은 Pod 생성하는데 필요한 모든 정보를 가지고 있는 명세표
