+)선 요약
하나의 OS에서 컨테이너를 여러 개를 만들어 관리하는데 최적화하는 것이 도커.
하지만 머신이 여러 개(=클러스터 환경)일 때, 전체적인 컨테이너 관리가 필요.
(지휘자가 필요해짐) (전체 워커노드의 스케쥴링)
이러한 거대한 역할을 하는 것을 컨테이너 오케스트레이션.
이를 위한 도구가 필요함 (특히, 구글과 같은 글로벌 IT기업에서 이것이 필요
구글이 쿠버네티스를 개발
쿠버네티스는 전체 클라우드 클러스터를 마스터와 워커노드로 나누어 마스터가 워커노드를 지휘
워커노드는 마스터에게 지시를 받아야 하므로(Kubelet이 존재)
인터넷으로 서비스를 제공하기 위해(Kube-Proxy)가 존재하여 네트워크 통신을 담당
결과적으로 머신에서 컨테이너를 배포하고 관리하는 런타임인 ‘도커’가 들어가고
도커 속에 컨테이너들을 묶은 파드 단위가 존재
쿠버네티스: 전체 클러스터와 컨테이너를 관리하기 위해 나옴 (오케스트레이션을 위해)
Chapter 4. 쿠버네티스 개요
컨테이너
VM을 통한 가상화의 단점 (리마인드)을 극복하기 위해 만든 “Container” (컨테이너)
- 애플리케이션 실행의 기본 환경 or 단위
- 소프트웨어 표준단위 (Self-contained Unit of SW)
- 애플리케이션 실행에 필요한 코드와 환경을 패키지로 묶어서 제공 (= self contained)
- 코드, 실행환경, 의존성, 시스템 라이브러리 등을 하나로 묶은 배포단위
- OS 수준에서 가상화를 하기 때문에 컨테이너는 커널을 공유하지만 각각 격리된 형태로 인스턴스를 배포하고 실행할 수 있음
- 어떤 운영환경(서버간, 서버-노트북간 등)으로도 배포와 이동이 쉽다는 장점 (= 이식성이 좋다)
(VM와 컨테이너의 가장 큰 차이: OS의 유무)
(VM마다 OS가 있지만 – 게스트 OS)
(컨테이너는 호스트 OS 위에서 존재)(게스트OS 없음)
(VM의 App들은 게스트 OS가 실행) (컨테이너의 App은 호스트OS가 실행)
➔ 운영체제 수준에서 가상화를 하기 때문에 커널을 공유
➔ 즉, 컨테이너는 OS를 공유. 공유하는 게 많아지므로 격리성이 떨어짐. 보안성이 취약함
이러한 컨테이너를 만들고 관리하는 장치: 컨테이너 런타임 (대표적으로 도커)
- 컨테이너는 리눅스OS에서 10년 이상된 기술
- 멀티 프로세스를 실행할 때 간섭없이 실행하기 위해 리눅스커널기능인 네임스페이스와 컨트롤 그룹을 사용
- 네임스페이스는 각 컨테이너에 대해 파일 시스템이나 네트워킹과 같은 시스템 리소스를 가상화
- 컨트롤 그룹은 각 컨테이너가 사용할 수 있는 CPU 및 메모리와 같은 리소스 양을 제한하는 역할
- 그러나 이 기능들은 너무 복잡하고 어려웠음
- 그래서 커널기능의 어떤 부분을 사용해야 하는지 익숙치 않은 개발자를 위해 리눅스 컨테이너가 나오게 됨
(컨테이너의 시발점)
가상머신과 컨테이너 비교 (가장 큰 차이는 Guest OS의 유무)
| 구분 | 가상머신 | 컨테이너 |
| 게스트OS | Windows, Linux 등 다양하게 선택 | X |
| 시작시간 | 길다(몇 분) | 짧다(몇 초) |
| 이미지 사이즈 | 크다 (수 GB ~ 수백 GB) | 작다 ( ~ 수백 MB) |
| 환경관리 | 각 VM마다 OS 패치가 필요 | 호스트 OS 만 패치 |
| 데이터 관 | VM 내부 또는 연결된 스토리지에 저장 | 컨테이너 내부의 데이터는 컨테이너 종료 시 소 멸, 필요시 스토리지를 이용하여 저장 |
Monolithic vs Micro Service
Monolithic Architecture
– 고용량 고성능의 단일 서버로 구성
• MicroService Architecture (MSA)
– Monolithic Architecture 와 비교하여 작은 서버들의 집합체로 구성
Docker
- 리눅스컨테이너는 복잡한 기술로 조합된 컨테이너를 추상화해서 사용하기 쉽게 해줌 (그러나 여전히 어려웠음)
- 도커는 개발자에게 익숙한 방법으로 리눅스컨테이너의 커널기능을 묶어 제공
- 구글은 매주 20억개 이상의 컨테이너를 구동(2014) (2013년 도커 개발 이후 단 1년만에)
- 도커: 컨테이너를 주류로 만든 리눅스 시반의 컨테이너 실행환경 오픈소스
- 기존 LXC 기술을 기반으로 이식성 향상, 데이터와 코드 분산 관리, 프로그램 스택의 간결/명료함
➔ 이동성과 유연성을 높임
- 쉽고 빠른 워크로드(=APP) 배포복제이동 가능
- 컨테이너와 이미지가 가장 중요한 요소 (도커는 컨테이너와 이미지를 관리하는 플랫폼)
• 컨테이너 엔진
(컨테이너를 실행하고 관리하는 도구)
• 컨테이너 기반의 오픈소스 가상화 플랫폼
• 도커는 도커허브라는 공개된 저장소서버를 통해, 컨테이너 자료들을 관리
(컨테이너 자료는 곧 이미지)
• 컨테이너를 생성하고 실행하기 위해서는 Dockerfile과 Image가 필요
도커의 특징
- 컨테이너 이미지 생성 기능 제공(컨테이너 안에서 실행될 APP, SW의 구동 방식 등을 미리 정해놓은 것)
- 도커에서 지원하는 컨테이너 이미지 도구를 활용하여 쉽게 이미지를 생성하여 원격으로 배포하여 실행이 가능
- 고도의 분산 시스템 생성이 단순해짐
- VM와 유사하나 프로세스 격리 중심으로 VM보다 훨씬 가벼움 (결국 VM이나 도커의 목적은 APP의 실행)
(자원 효율성을 높이면서도 격리성을 높인다)
(공유하되, 격리한다)
(도커의 컨테이너 생성 시간은 불과 1-2초 내)
- Host OS만 커널을 가지며, 컨테이너는 Host OS 커널을 공유
(그래서 가볍다)
(여기서 Host OS는 주로 리눅스 우분투)
Dockerfile
• 컨테이너 이미지를 생성하기 위한 레시피 파일입니다.
• 이 파일에 이미지 생성과정을 문법에 따라 작성하여 저장합니다
• FROM, WORKDIR, RUN, CMD 등 용도에 따른 명령어 모음
Docker Image
- 컨테이너 실행에 모든 필요한 파일과 설정값 등을 포함하고 있는 것으로 상태값을 가지지 않고 변하지 않음
(수정이 불가능)
(이미지는 수정이 불가능한 형태도 배포되고 상태값을 가지지 않는다, stateless)
➔ (복제가 가능하다)
- 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장
(이미지 자체에는 상태값이 없음)
(컨테이너 실행에 필요한 모든 것이 이미지)
(이미지를 실행한 상태가 컨테이너)
(이미지는 statelss)
- 같은 이미지에서 여러 개의 컨테이너를 생성할 수 있음
- MySQL 이미지는 debian을 기반으로 MySQL을 실행하는데 필요파일, 실행명령어, 포트 정보 등을 가지고 있음
- 새로운 서버가 추가되면 미리 만들어 놓은 이미지를 다운받고 컨테이너를 생성만 하면 되는 간단한 상황
- 도커 이미지는 컨테이너 실행의 모든 정보를 가지므로 보통 용량이 수백메가(기가 이상인 경우도 있음) (OS포함 시)
- 도커 이미지를 만드려면 DSL이라는 자체언어를 이용. 도커파일에 이미지 생성과정을 적어놓고 관리
- 도커의 유통방식은 2가지. 도커허브에 등록/도커저장소를 직접 만들어 관리 가능
- 공개된 도커이미지는 50만개가 넘고, 도커 허브 이미지 다운로드수는 80억회 이상(무료)
➔ 누구나 쉽게 이미지 생성 배포 가능
(이식성이 높아 분산시스템에 유리)
(원격으로 생성 배포가 가능)
• 서비스 운영에 필요한 프로그램, 소스코드, 라이브러리 등을 묶는 형태
• 도커 이미지는 Dockerfile을 사용하여 생성할 수 있습니다. (Build)
• 도커 이미지를 사용하여 다수의 Container를 실행할 수 있습니다. (Run)
• 도커 이미지는 url 방식으로 관리하고, 태그를 붙일 수 있습니다.
• 도커 이미지의 형식
• Private 한 이미지저장소를 구축하여 이미지를 관리한다면,
<Namespace>부분을 해당 서버주소 및 포트번호 등으로 사용가능
<Namespace>/<ImageName>:<Tag> private:10000/mynginx:latest저장소/이름:Tag(이미지의 버전)
ex. docker.io / library / nginx : latest
➔ 도커 허브에서 nginx 중 최신버전
Docker HUB
• 수많은 컨테이너 이미지들을 서버에 저장하고 관리
• 공개 이미지를 무료로 관리
• https://hub.docker.com/
- 쌓여있는 이미지가 너무 많음
➔ 너무 잘 나가다보니 클라우드 비용이 상승
도커 허브 정책 변경 (20년 11월 이후~)
- 6개월 간 풀 리퀘스트(이미지 다운로드)가 없는 무료 사용자의 컨테이너 이미지는 자동 삭제
(아무도 다운 안한 이미지는 삭제)
- 비회원, 무료회원, 유료회원간 차등 적용
무료 도커의 문제점: 악성코드 배포의 장으로 이용되어 옴(심각한 보안 취약성을 갖는 도커 허브)
Docker 간단 명령
컨테이너 오케스트레이션
• 다수의 컨테이너를, 다수의 시스템에서, 각각의 목적에 따라, 배포/복제/장애복구 등 총괄적으로 관리하는 것.
• 컨테이너 오케스트레이션 도구들의 일반적 기능
– 스케줄링
– 자동확장 및 축소
– 장애복구
– 로깅 및 모니터링
– 검색 및 통신
– 업데이트 및 롤백
컨테이너 오케스트레이터
• 컨테이너 오케스트레이션을 해주는 도구
• 컨테이너 오케스트레이터의 종류
– Kubernetes
– Docker Swarm
– AWS ECS
– Azure Container Instance
– Azure Service Fabric
– Marathon
– Nomad
컨테이너 오케스트레이터의 배포위치
• 컨테이너 오케스트레이터의 배포 위치
– 베어 메탈
– 가상머신
– 온프레미스
– 클라우드
K8S
Kubernetes
• 컨테이너형 애플리케이션의 배포, 확장, 관리를
자동화하는 오픈 소스 시스템
k8s - 'k' 와 's' 사이에 8글자가 존재
- 대표적인 클라우드 오픈소스 프로젝트
(클라우드는 오픈소스가 짱) (글로벌 기업들은 오픈소스 개발을 지원) (자사에 도입)
- CNCF재단에서 관리하는 컨테이너를 실행하고 관리하는 오픈소스 프로젝트
- 컨테이너 오케스트레이션을 위해 구글이 개발
(구글은 거의 모든 서비스를 컨테이너에서 실행) (지메일, 구글검색, 구글맵 등)
- CaaS, 마이크로서비스 플랫폼, 오케스트레이션 플랫폼이라고도 불림
- 구글, 아마존, MS 등 대부분 클라우드 업체가 지원
왜 쿠버네티스가 필요한가?
- 도커만 사용하면 되지 왜 컨테이너 플랫폼이 필요한가?
컨테이너 수가 적으면 수동으로 VM이나 하드웨어 직접 배포
하지만 VM이나 하드웨어의 수, 컨테이너 수가 많아지면 이 컨테이너를 어디에 배포해야할 지 종합적 판단이 필요
자원을 최대한 최적으로 사용하기 위해 적절한 위치에 배포해야 함
앱 특성에 따라 같은 물리 서버에 배포하거나 or 가용성을 위해 일부러 다른 물리 서버에 배포해야하는 경우 발생
- 컨테이너는 프로세스나 App을 격리하기 위해 만들어졌기 때문에 개별 컨테이너 생성과 배치는 도커가 유리
그러나 도커는 여러 컨테이너를 모아 하나의 단위로 관리할 수 있는 큰 APP으로 만들고자 한다면 대응이 어려움
(여러 개의 컨테이너가 각자 기능을 해야할 때, 도커는 이들의 조화를 돕는데는 어려움이 있음)
특히, 컨테이너 각각을 독립적으로 배치하고 연결하고 관리하고 확장해야 한다면,
이 구성요소들을 전체로 기능하도록 조직할 방법이 필요
쿠버네티스는 여러 컨테이너 APP을 여러 대의 호스트에 배치, 관리하는 작업을 자동화. 컨테이너를 직접 하나씩 관리X
- 오케스트레이션 vs 코리아그러피 – 차이점은 지휘자의 유무. 다양한 서비스의 동시동작을 지휘하는
- 쿠버네티스는 서비스 오케스트레이션 도구. 지휘자가 존재하여 각각의 컨테이너들을 지휘
- CaaS의 대표적 플랫폼 (도커 + 쿠버네티스)
1. 컨테이너를 적절한 서버에 배포해주는 스케쥴링 역할이 필요
2. 컨테이너가 정상적으로 작동하고 있는지 체크하고 문제가 있으면 재기동하는 역할이 필요
3. 모니터링, 삭제/관리 등 컨테이너에 대한 종합 환경 필요
쿠버네티스가 필요한 경우
- 복잡한 앱: 두개 이상의 컨테이너가 관련되는 앱이라면 쿠버네티스(오케스트레이션)이 유용
(하지만, 사용자 수가 많지 않고 크기도 보통이라면 도커스웜와 같은 최소화된 솔루션이 유용)
- 확장성과 복구성이 중요한 앱: 조건이 바뀔 때마다 코딩으로 대응하지 않고 원하는 시스템 상태를 서술하는 방식
(워크로드와 컨테이너 간의 균형을 맞출 수 있음)
- 현대적인 CI/CD기법을 적용하고 싶을 때: 블루/그린 배치나 롤링 업그레이드를 사용하는 앱을 위한 배치 패턴을 지원
(컨테이너 단위로 개선) (ex. 은행 어플) (시스템을 셧다운 하지않고 특정한 부분만 수정)
(PaaS 상에서 MSA로 구현된 앱이 DevOps 기반으로 개선운영되고 있으면, 그러한 앱을 클라우드 네이티브라고 함)
쿠버네티스의 특징
- GO 언어로 구현. 벤더나 플랫폼에 종속되지 않음
- 하이브리드 클라우드 구성에 유리 (내부 + 외부 클라우드) -> 클라우드 섞어쓰기가 가능
- 쿠버네티스는 여러 대의 서버가 하나의 클러스터로 연결
CNCF(Cloud Native Computing Foundation)
• 대표적으로 Kubernetes 와 Prometheus 와 같은 클라우드 네이티브 오픈소스 기술들을 추진하고 관리하는 단체
쿠버네티스 아키텍처: 큰 시스템이므로 규모와 구조가 도커랑은 다름
- 마스터노드와 워커 노드로 구성 (전체 관제와 일꾼들) (마스터노드는 각 워커 서버들을 관리)
- 파드: 쿠버네티스의 핵심
쿠버네티스 플랫폼 상에서 최소 단위
파드 안에 컨테이너가 들어감. (1개 이상의 컨테이너)
파드 안의 컨테이너들은 볼륨과 같은 공유 스토리지를 공유 가능, IP주소, 컨테이너 동작방식 역시 공유 가능
컨테이너 이미지도 공유.
파드 – 연결성과 목적성이 강한 컨테이너들의 모음
(같이 동작해야 하는, 같은 이미지를 공유하는)
- 마스터 노드: 워커노드를 통제. 클러스터의 모든 데이터를 저장. KUBE API를 지원, 파드 스케쥴링, (=컨트롤 플레인 )
- 워커 노드: 클러스터 내 모든 노드에서 실행하는 데이터 플레인 (일하는 애)
(쿠버네티스에서 노드는 워커 머신: 클러스터에 따라 가상 또는 물리 머신, 각 노드는 마스터에 의해 관리)
(하나의 노드는 여러 개의 파드를 가질 수 있음) (마스터는 파드에 대한 스케쥴링을 담당)
Kubelet: 쿠버네티스 마스터와 노드간 통신을 책임지고 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리 = 통제
KubeProxy: 노드와 마스터 간의 네트워크 통신을 관리
컨테이너 런타임(도커): 레지스트리에서 컨테이너 이미지를 가져와 압축을 풀고 APP을 동작
노드는 머신.
머신은 가상 or 물리 -> 머신은 OS가 필요
(도커이므로 보통 리눅스가 필요) (컨테이너용 LXC = 도커)
도커가 워커노드의 런타임 환경을 구성. 그 안에 컨테이너들을 묶은 파드가 동작.
K8S 아키텍처
마스터 노드의 구성요소
API Server
• API를 사용할 수 있게 해주는 프로세스
(쉽게 말해, 명령어를 쓰게 해주고 명령을 검증하는 놈)
(각 구성 요소 전체 통신 담당)
(마스터 노드의 핵심)
Scheduler
• Pod의 생성 명령이 있을경우 어떤 Node에 배포할지 결정
(처음엔, 파드는 곧 컨테이너로 이해하면 쉬움) (같은 의미는 아니지만)
Controller Managers
• 클러스터의 상태를 조절 하는 컨트롤러들을 생성, 배포
(사용자나 관리자가 원하는 상태를 유지하는 역할 - 컨트롤러)
etcd
• 모든 클러스터의 구성 데이터를 저장하는 저장소
(주기적인 백업이나 복제본이 필요)
워커 노드의 구성요소
• 컨테이너가 배포될 워커머신
Container Runtime
• 컨테이너를 실행하고 노드에서 컨테이너 이미지를 관리
• 컨테이너 Runtime
– 도커 (22. 5월 이후로 x)
– CRI-O
– containerd
– rkt
– rktlet
kubelet
• 각 Node의 에이전트
(작업 반장님)
kube-proxy
• 쿠버네티스 클러스터의 각 노드마다 실행되고 있으면서, 각 노드간의 통신을 담당합니다.
(통신담당관)
Kubernetes 전체 아키텍처
Addons
• Addons 은 Kubernetes에서 추가적으로 설치하여 Kubernetes의 기능을 확장 시킬 수 있는 도구
• Kubernetes Addons의 종류
– DNS
– Dashboard
– Monitoring
– Logging
– Etc...
'KT-Aivle School (AI) > 클라우드' 카테고리의 다른 글
| [클라우드] k8s 컨테이너 배포, 통신, 볼륨 관리 (2) | 2022.11.08 |
|---|---|
| [클라우드] 쿠버네티스 클러스터 배포 (0) | 2022.11.06 |
| [클라우드] AWS 고가용성 구현 (Region, AZ, ELB, ASG) (0) | 2022.11.04 |
| [클라우드] AWS 기본 서비스 (0) | 2022.11.04 |
| [클라우드] 가상화 및 클라우드 (0) | 2022.11.04 |