4. 쿠버네티스 개요 및 주요 아키텍쳐
컨테이너 | OS 가상화 기술 |
프로세스 격리 | |
리눅스 커널 공유(리눅스의 핵심적인 부분=커널) |
GuestOS의 유무
App1 | App2 | App3 | App4 | App1 | App2 | App3 | App4 | |
Guest OS | Guest OS | Guest OS | Guest OS | Container Engine (ex. Docker) | ||||
Hypervisor | OS | |||||||
Infrastructure | Infrastructure | |||||||
가상머신(Virtual Machine) 환경 | 컨테이너(Container) 환경 |
* Guest OS => img OS파일(win10.iso), 컨테이너에 비해서 용량이 크다(상대적으로 커스터마이징 어려움)
가상머신과 컨테이너 상대적인 비교
구분 | 가상머신(Virtual Machine) | 컨테이너(Container) |
게스트 OS | 다양한 OS(운영체제) 선택 가능 | 게스트 OS가 없다. |
시작시간 | 분 단위 | 초 단위 |
이미지 사이즈 | GB 단위 | MB 단위 |
환경 관리 | 각 VM 마다 OS 패치 필요 | 호스트 OS만 패치(Linux 권) |
데이터 관리 | VM 내부 또는 연결된 스토리지에 저장 | 컨테이너 내부의 데이터는 컨테이너 종료 시 소멸, 필요시 스토리지를 이요하여 저장 |
Monolithic vs Micro Service
구분 | Monolithic Architecture | Micro Service Architecture |
서버 구성 | 단일 서버 구성 | 서버 집합체 구성 추가) 하나하나 관리 어려움 -> 쿠버네티스로 관 |
서버 성능 | 고용량 고성능 | 상대적으로 저용량 저성능 |
Docker
Docker | 컨테이너 엔진(컨테이너를 실행하고 관리하는 도구) 컨테이너 기반의 오픈소스 가상화 플랫폼 도커허브라는 공개된 저장소서버를 통해, 컨테이너 자료들을 관리 컨테이너를 생성하고 실행하기 위해서는 Docker file, Docker Image 필요 |
나만의 정리: 이미지 = iso 파일
Docker file | 컨테이너 이미지를 생성하기 위한 레시피 파일 이 파일에 이미지 생성과정을 문법에 따라 작성하여 저장 FROM, WORKDIR, RUN, CMD 등 용도에 따른 명령어 모음 |
Docker Image | 서비스 운영에 필요한 프로그램, 소스코드, 라이브러리 등을 묶는 형태 도커 이미지는 Dockerfile을 사용하여 생성할 수 있습니다. (Build) 도커 이미지를 사용하여 다수의 Container를 실행할 수 있습니다. (Run) |
나만의 정리: 도커이미지: 운영체제에 프로그램 설치 및 설정된 것을 다시 이미지 파일로 만든 거(설치하면 설정값이 기본값)
도커파일로 도커 이미지를 만들어서 가상머신에 적용, 당연히 다수의 Container를 실행
도커랑은 조금 다른데 개념은 비슷한 거 win server인가 Hyper-v 에서 비슷한거 했는데 뭐더라,, 아무튼 테스터 서버 구축 시 tool을 활용해서 생성 가능, 아마 On-premises이라서 다른가??
-> 테스트 서버 트러블 슈팅 때 문제 해결하고 확인하면서 도메인서버 갈고 살리면서 확인했던 거 아무튼 기억나면 내용 추가하기
Docker Image 경로 | 도커 이미지는 url 방식으로 관리하고, 태그를 붙일 수 있다. 도커 이미지 형식 <Namespace>/<ImageName>:<Tag> docker.io/library/nginx:latest nginx:latest nginx |
Docker Image 경로 (Private) |
Private 한이미지저장소를구축하여이미지를관리한다면, <Namespace>부분을해당서버주소및포트번호등으로사용가능 <Namespace>/<ImageName>:<Tag> private:10000/mynginx:latest |
Docker HUB |
|
Docker 간단명령 |
|
Docker 명령구조 |
|
컨테이너오케스트레이션
컨테이너 오케스트레이션 | 다수의 컨테이너를, 다수의 시스템에서, 각각의 목적에 따라, 배포/복제/장애복구 등 총괄적으로 관리하는 것. |
도구들의 일반적 기능 | 스케줄링, 자동확장및축소, 장애복구, 로깅및모니터링, 검색및통신, 업데이트및롤백 |
컨테이너 오 케스트레이터 = 묻지도 말고 따지지도 말고 쿠버네티스!!
컨테이너 오케스트레이터 | 컨테이너오케스트레이션을해주는도구 |
컨테이너 오케스트레이터의 종류 | Kubernetes, Docker Swarm, AWS ECS, Azure Container Instance, Azure Service Fabric, Marathon, Nomad |
컨테이너 오케스트레이터의 배포위치 |
베어메탈(서버), 가상머신, 온프레미스, 클라우드
|
->개꿀이네,,
킹 갓 제네럴 더 임페럴 유스풀 엔드 프리 Kubernetes (=k8s)
Kubernetes | 컨테이너형 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈 소스 시스템 |
사용하는 이유 | 높은 확장성, 원활한 이동성(이식성) 퍼블릭/프라이빗/하이브리드/멀티 클라우드, 로컬 또는 원격 가상 머신, 베어메탈과 같은 여러 환경에 구축 가능 오픈 소스 도구의 장점 플러그가 가능한 모듈 형식 |
Kubernetes 도입 기업 |
CNCF(Cloud Native Computing Foundation)
CNCF (Cloud Native Computing Foundation) |
대표적으로 Kubernetes 와 Prometheus 와 같은 클라우드 네이티브 오픈소스 기술 들을 추진하고 관리하는 단체 |
CNCF의 완료 프로젝트 | Kubernetes for container orchestration Prometheus for monitoring Envoy for service mesh CoreDNS for service discovery containerd for container runtime Fluentd for logging |
Kubernetes 아키텍처(구성 요소)
마스터 노드의 구성요소
API Server | API를 사용할 수 있게 해주는 프로세스 명령어가 전달되는 중간 다리 |
Scheduler | Pod의 생성 명령이 있을 경우 어떤 Node에 배포할지 결정 |
Controller Managers | 클러스터의 상태를 조절 하는 컨트롤러들을 생성, 배포 |
etcd | db와 같음 모든 클러스터의 구성 데이터를 저장하는 저장 |
워커 노드의 구성 요소( + addons)
컨테이너가 배포 워커머신
Container Runtime | 컨테이너 엔진과 거의 유사 파드안에 들어가는 컨테이너를 생성하고 이미지를 다운로드 받아서 관리 컨테이너를 실행하고 노드에서 컨테이너 이미지를 관리합니다. Kubernetes에서 지원하는 컨테이너 Runtime은 다음과 같습니다. 도커, CRI-O, containerd, rkt, rktlet |
kubelet | 워커 노드의 팀장과 같음, 파드안에 컨테이너들이 있는데 컨테이너가 잘 작동 되고 있는지 감시, 보고 각 Node의 에이전트, 감시 역할 주기적으로 API 서버에 보고 |
kube-proxy | 쿠버네티스 클러스터의 각 노드마다 실행되고 있으면서, 각 노드간 혹은 외부(인터넷 환경)의 통신을 담당합니다. |
Kubernetes 아키텍처
Addons
워커 노드의 하드로(컨테이너로) 설치되어서 사용 가능
Addons 은 Kubernetes에서 추가적으로 설치하여 Kubernetes의 기능을 확장시킬 수 있는 도구입니다.(플러그인 형식)
Kubernetes Addons의 종류 | DNS |
Dashboard | |
Monitoring | |
Logging | |
Etc... |
5. 쿠버네티스 클러스터 배포
Kubernetes 배포 유형
Kubernetes 배포 유형 | All-in-One Single-Node Installation |
Single-Node etcd, Single-Master and Multi-Worker Installation |
|
Single-Node etcd, Multi-Master and Multi-Worker Installation |
|
Multi-Node etcd, Multi-Master and Multi-Worker Installation |
Kubernetes 설치 도구
kubeadm | kubespray(자동화 도구, IaC, Ausible, Terraform) |
kops |
Kubernetes 배포 순서
1 | 2 | 3 |
Container Runtime 설치 | Kubernetes 설치 | Master와 Worker 연동 |
6. 쿠버네티스 컨테이너 배포, 통신, 볼륨 관리
Kubernetes Object
Object 개념 | 가장 기본적인 구성단위 클러스터 상태를 관리하는 역할 |
종류 | 가장 기본적인 오브젝트 – Pod(컨테이너를 담는 통), Service, Volume, Namespace |
오브젝트의 Spec, Status 필드 | Spec : 컨테이너에 정의된 상태(사용자가 원하는 상태를 정의해서 적어놈) Status : 현재 상태(정의된 상태로 creat(생성)하게 되면 현재상태로 매칭) |
ex)
컨테이너를 담는 통인 pod 안에 img, port name 등등 설정을 Spec에 작성해서 생성 -> 정상 작동 -> 상태 Status에 저장
Kubernetes Controlle (+컨트롤러는 컨트롤러 매니저가 관리)
클러스터의 상태를 관찰하고, 필요한 경우에 오브젝트를 생성, 변경을 요청하는 역할
각 컨트롤러는 현재 상태를 정의된 상태에 같게 유지하려는 특징(Status == Spec)
컨트롤러 유형 :
– Deployment, Replicaset, Daemonset, Job, CronJob 등
Controller Cycle
사용자가 원하는 상태로 유지
컨트롤러의 기능: Pod Auto Healing
pod가 삭제된 경우 | 이상이 생겨 pod1이 삭제된 경우 Controller는 이상 감지를 하고 Pod1을 재생성 한다. |
Node 통신이 끊긴 경우 | pod1은 삭제 되지 않았지만 Node1과의 통신이 끊긴 경우 Controller는 pod1을 봐야 하기 때문에 Node2에 Pod1을 재배포 한다. |
컨트롤러의 기능: Pod Auto Scaling
리소스 부하가 증가하게 되면 Pod를 하나 더 붙이고, 부하가 줄어들면 다시 원래 Pod 구성으로 되돌린다.
Pod Update & Rollback
Pod를 출시해서 사용 중이다, 기능추가 및 디테일 수정을 통해 업데이트하게 되었을 때
업데이트 버전에서 치명적인 오류가 발견된다면 안정적인 구버전으로 롤백 후 추 후 업데이트
Pod Job
계산, 이메일 발송, 파일 백업 등 1회성 작업일 경우(한 번만 수행) Job 기능 활용 -> 자원의 효율적인 관리 가능
YAML 구조
쿠버네티스 object트 관리는 yaml 또는 jason 형식으로 관리 가능
yaml이 시각적으로 확인이 더 쉬움
apiVersion | 연결할 API server의 버전 |
kind | 리소스의 유형 |
metadata | 리소스가 기본 정보를 갖고 있는 필드 name, label, namespace 등 |
spec | 배포되는 리소스의 원하는 상태 |
Kubectl
Kubernetes에 명령을 내리는 CLI(Command Line Interface)
kubectl 명령 구조 :
– kubectl [COMMAND] [TYPE] [NAME] [FLAGS]
오브젝트와 컨트롤러를 생성, 수정, 삭제
Kubectl 명령어 더 알아보기: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
세줄 요약(개념이 완벽해질 때까지 수정 계속될 예정)
Hyper-V: Guest OS 이거 무겁다(=비용증가) -> 리눅스 기반 컨테이너 환경: 빠르고 가볍고 좋다!
컨테이너 엔진으로 도커가 있고 도커허브로 Dockerfile과 Image관리, 컨테이너 오 케스트레이터로 컨테이너 유지보수, 컨테이너형 애플리케이션 유지보수 자동화 오픈소스 시스템으로 쿠버네티스가 있다.