쿠버네티스 개요
쿠버네티스 개요
배경
클라우드 네이티브 환경
CNCF의 클라우드 네이티브 정의
클라우드의 장점을 최대한 활용하여 정보 시스템을 구축 및 실행하는 환경
클라우드 환경을 통해 이뤄지는 다양한 기술, 패턴, 방법론을 포괄함
클라우드 네이티브 환경의 특징
NIA에서는 네이티브 환경의 특징을 4가지로 정의
마이크로서비스
빠른 배포를 가능하게 하는 업무 구조
서비스를 각각 고유한 논리, 상태 및 데이터가 있는 독립적인 서비스로 기능을 분리
- 빠른 개발
- 개발자는 특정 비즈니스 로직에만 집중하여 빠르게 개발
- 유연한 스케줄링
- 팀 단위 개발, 빌드, 테스트, 배포를 통해 자유로운 일정 조정
- 효율적 자원 활용
- 필요한 서비스에 대한 리소스만 추가 확장을 통해 확보
- 고효율 저비용의 스케일아웃 실현
- 복잡하고 불필요한 종속성 해소
- 서비스 별로 각각의 종속성을 확보
컨테이너
빠른 배포를 가능하게 하는 기술적 토대
경량화된 독립 가상환경
기존 방식
- 앱을 물리 서버에서 실행
- 세팅에 비용이 발생함
- 리소스가 중첩되어 의존성 문제 일어날 가능성 높음
- 불필요한 자원 낭비 가능
가상 머신 환경
- 기본적으로 OS 위에 하이퍼바이저를 가동시켜 독립된 OS 환경 실행
- 하이퍼바이저
- 하드웨어를 파티셔닝하고 물리적 리소스를 분리
- 1형, 2형이 존재하고 조금씩 다름
- 하이퍼바이저
- 호스트 OS 위에 클라이언트 OS가 다수 존재하는 방식
- OS 중복으로 인한 오버헤드
컨테이너 환경
- 컨테이너 런타임을 통해 프로세스만 분리하여 독립된 환경 구축
- 대표적으로 도커, containerD 등
- 원리
- namspace - 프로세스 별로 파일 시스템, 네트워크 등을 격리
- cgroups - 프로세스 별로 리소스 제한, 관리
- union filesystem - 파일 시스템 겹치기
- 세팅이 간편하고 리소스 낭비 적음
데브옵스
빠른 배포를 가능하게 하는 업무 프로세스
개발과 운영의 협업을 통해 전체 라이프사이클을 관리하는 철학 또는 운동.
팀 간의 프로세스를 자동화하는 일련의 과정으로도 정의
빠른 개발, 빠른 배포, 안정성을 갖출 수 있음
- 개발자의 관점
- 기능을 개발하여 사용자 경험 개선
- 운영에 필요한 최적화는 시스템 관리자한테 짬 때림
- 시스템 관리자의 관점
- 배포와 운영의 인프라, 보안 담당
- 개발자의 작업물을 받아먹는 존재..
- 앱들 간의 암묵적 상호의존성을 관리하기 힘듬
- 버전 차이로 발생하는 이슈를 빠르게 알기 힘듬
개발자와 엔지니어의 간극을 메꾸는 것이 바로 데브옵스
CICD
빠른 배포를 가능하게 하는 자동화된 업무
그냥 배포, 운영 자동화
Why Kubernetes?
상황
- 마이크로서비스에서 일일이 컨테이너 관리 어려움..
- 트래픽따라 자동 스케일링하고픔..
- 잦은 개발 주기에 따라 세분화된 배포를 일일히 하기 어려움..
- 장애 나면 일일히 대응 어려움..
- 각 서비스에 대한 보안 챙기기 어려움..
- 모니터링도 힘듬...
What is Kubernetes?
개요
다량의 컨테이너를 운영하는 툴
컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼
2014년 구글이 사내에서 운영하던 Borg를 오픈소스화시켜 공개
컨테이너 운영 노하우가 담긴 기술 집약적 툴
많은 시스템을 통합하고 컨테이너를 제공하기 위한 API 제공
기능
- 서비스 디스커버리와 로드 밸런싱
- 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
- 네트워크 관리 가능!
- 스토리지 오케스트레이션
- 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다.
- 스토리지 관리 가능!
- 자동화된 롤아웃과 롤백
- 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
- 스케일링 가능!
- 자동화된 빈 패킹(bin packing)
- 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
- 스케쥴링 가능!
- 자동화된 복구(self-healing)
- 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
- 장애 복구 가능!
- 시크릿과 구성 관리
- 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다.
- 보안 가능!
쿠버네티스 아키텍처
- 클러스터 쿠버네티스가 관리하는 한 단위
- 노드 단위 컴퓨팅 리소스(ec2, 내 노트북)
컨트롤 플레인과 데이터 플레인으로 구성
컨트롤 플레인에 해당하는 마스터 노드가 데이터 플레인에 해당하는 워커 노드에 작업을 지시
실제 사용자는 kubectl 명령어를 통해 컨트롤 플레인에 http api지시를 내림
컨트롤 플레인
- kube-apiserver
- 쿠버네티스의 API를 노출하는 프론트엔드
- 모든 사용자 요청 수행
- 클러스터 내모든 컴포넌트와 상호작용
- etcd
- 클러스터의 모든 데이터를 백업하는 분산 가능한 KV 저장소
- 사용자가 정한 스펙, 현재 클러스터 내의 상태 등 모든 값을 저장
- HTTP 통신, 트리 파일시스템, 변화 추적
- 일관성, 고가용성, 단순성, 내구성, 성능
- 비교
- redis - etcd 만큼의 일관성 보장 어려움
- mongodb - 단순하지 않아 성능 상 불리
- kube-scheduler
- 파드(쿠버네티스 기본 객체 단위로, 컨테이너보다 큰 개념)를 만들고 노드에 할당하는 컴포넌트
- 노드 내 자원 상황, 제약 조건 등의 요소를 파악하고 적절한 노드에 할당
- kube-controller-manager
- 컨트롤러 프로세스를 담당하는 컴포넌트
- 컨트롤 사용자가 지정한 사양과 클러스터의 현재 상태를 맞추는 행위
- 노드 상태, 잡(태스크 예약), 엔드포인트슬라이스(네트워킹), 서비스어카운트 등의 컨트롤링 진행
- 컨트롤러 프로세스를 담당하는 컴포넌트
- cloud-controller-manager
- 클라우드 벤더 사마다 존재하는 클러스터 관리 컴포넌트
데이터 플레인
- kubelet
- 각 노드에 들어가는 에이전트
- 컨테이너들을 한 파드로 묶음
- 노드 내에서 파드를 관리하는 실질적 관리자
- kube-proxy
- 서비스(쿠버네티스의 네트워크 관련 기본 객체)를 실질적으로 구현하는 네트워크 프록시
- 이를 통해 노드 내에서, 클러스터 내에서도, 클러스터 외부까지도 파드가 통신이 가능해짐
- 노드 내에 iptables와 같은 패킷 필터링 계층이 있다면 활용하지만, 없다면 그 자체가 필터링 역할을 진행
- container runtime
- 컨테이너 환경
- 컨테이너를 만들 수 있는 토대
- containerD, CRI-O가 주로 쓰임
- 도커는 지원되지 않음
애드온
이밖에도 CNCF 산하의 많은 오픈소스들이 쿠버네티스 생태계로 편입되어 활용될 수 있도록 설계됨
오히려 쿠버네티스에 종속되는 것들도 존재함
이들을 통해 보다 네트워킹, 모니터링 등의 복잡한 클러스터 관리를 행할 수 있음
세부적으로 알아야할 개념
스토리지, 네트워크, 워크로드, 보안, 옵셔빌리티, 헬름차트....
To be Contnued...