클라우드 환경을 위한 리눅스
리눅스 강의에 왜 Docker, Kubernetes?
인프라 환경의 변화
- 기존 : 온프레미스
- 직접 구매, 설치, 관리 => 서버 사용에 긴 시간이 소요되었음.
- 클라우드 환경으로의 전환
- 필요한 만큼 할당받을 수 있음 => 사용한 만큼 비용 지불.
- 간단하고 즉각적으로 할당.
- 클라우드 벤더사에서 제공하는 API/SDK를 사용해 모든 자원 자동화 가능.
- 금융이나 국방도 클라우드 사용 추세가 나타나고 있음
컴퓨팅 환경의 변화
- 기존 : 가상머신
- 하드웨어 가상화 기반으로 가상머신 할당
- 가상머신 단위로 확장 (스케일 업, 스케일 아웃. 크기를 늘리거나 개수를 늘리거나)
- 컨테이너 기술로 전환
- 운영체제 기반의 가상화 기술. 컨테이너 패키지 단위로 가상화.
- 컨테이너 단위로 확장한다.
- 빠른 확장성
- 기존 : 컴퓨터 가동 → 운영체제 구동 → 애플리케이션 실행
- 컨테이너 환경 : (단계 생략)애플리케이션 실행
- 가상머신 환경에서는 빨라도 수 분 단위의 스케일링 시간이 필요했지만, 컨테이너 환경에서는 수초정도면 실행 가능.
- 리눅스 기반 기술로 자원의 격리 수행.
- 각 애플리케이션의 아이솔레이션이 잘 이루어지게 됨.
서버 관리 측면의 변화
- 기존 : 쉘 스크립트
- 커스텀 쉘 스크립트
- 담당자 부재 시 대응이 어려움. (친절한 환경이 아님)
- 스크립트 자체 오류 존재 가능
- 자동화 도구로 전환
- 필요한 부분에는 쉘 스크립트 사용
- 한 단계 추상화된 형태로 자원을 기술하는 도구들 사용하여 관리(예, Ansible)
- 멱등성 지원 : 동일한 인프라 설정을 반복적으로 시행하더라도 항상 동일한 형상을 유지하도록 관리할 수 있음.
장애 대응 측면
- 기존 : 리눅스 명령의 이해
- 서버에 직접 접속
- 리눅스 명령어 기반으로 복구/분석
- 리눅스의 이해로 변화
- 구성이 늘어나면서 관리해야할 애플리케이션이 증가.
- 중앙 집중화된 로깅/모니터링 환경
- 수집된 데이터를 기반으로 장애를 판단한다.
- 리눅스 커널의 주요 개념을 이해하고 주요 개념, 주요 컴포넌트 관련되어 수집된 데이터를 추적, 분석할 수 있는 능력이 중요.
과정
입문
- 리눅스기반 컨테이너 개발환경 구축 → 리눅스 관점에서 컨테이너 기술 리뷰
- 리눅스 관점의 클라우드 기반 컨테이너 운영 → 컨테이너 오케스트레이션 실습 및 쿠버네티스 환경 구성의 이해 (시스템 어드민 관점)
기본
- 리눅스 입문과 운영 → 클라우드 환경에서의 리눅스 관리자의 기본 지식 이해
고급
- 리눅스 시스템 성능 분석과 최적화 → DevOps/SRE 엔지니어로서 한단계 성장하기 위한 리눅스 역량 확보
roadmap.sh 개발자 로드맵!
컨테이너 기반 가상화 소개
컨테이너 기술의 소개
- 컨테이너 : Docker로 대표되며, 프로세스 자원을 격리하는 기술.
Google app engine. PaaS 환경
- 주목할 부분은 컨테이너의 개념
- 애플리케이션의 코드, 종속성, 그리고 실행환경을 하나의 패키지로 구성.
- 컨테이너 런타임이 있는 곳이라면, 동일한 패키지가 실행됨.
- Local, Staging/QA, Production 등등. 환경에 구애받지 않는 것이 장점.
컨테이너의 장점
민첩성
- 개발자가 애플리케이션을 빌드하고 더 빠르게 배포할 수 있음.
- 기존의 모놀리틱한 어플을 가지고 있다면 수 시간 단위의 통빌드를 기다리는 (지루한) 시간이 필요했고, 그 과정에서 빌드 브레이크가 발생하면 문제가 생기게 된다.
- 컨테이너는 개발자가 자기 어플을 직접 빌드, 배포할 수 있다.
이식성
- OS 플랫폼 간 및 클라우드 간 이식 가능
- 개발 시스템에서 프로덕션 환경까지 일관된 형식 사용
신속한 확장성
- 같은 인프라에 더 많은 컨테이너 지원 가능
- 신속한 스케일링 지원.
- 가상 머신 기반일 경우 호스트에 가상머신을 위한 OS 등 여러 시스템 등이 있고 그 위에 어플이 실행되게된다. 확장을 하게되면 어플을 구동하기 위한 환경들이 중복돼서 증가하게 된다.
- 컨테이너의 경우 어플 단위로 스케일링을 할 수 있고, 작은 아티팩트 단위로 구동이 가능하다.
- 결과적으로 하나의 호스트에서 더 많은 수의 어플 구동이 가능.
VM과 컨테이너
Hypervisor
- 가상머신 모니터, VMM
- 호스트 컴퓨터에서 다수의 운영 체제를 동시에 실행하기 위한 논리적 플랫폼.
- CPU, 메모리, 스토리지 등 리소스를 에뮬레이션 > 한 대의 서버에 독립된 여러 머신 환경을 구성 가능.
- Type 1
- HARD WARE → HYPER VISOR → OS(다수)
- KVM, Hyper-V, vSphere 등등
- 서버, 워크스테이션, 클라우드 환경에서 사용
- Type 2
- HARD WARE → (HOST)OS → HYPER VISOR → (GUEST)OS
- VMware, Workstation, VirtualBox, Parallels 등등
- 데스크탑, 노트북 등에서 사용
비교
Virtual machines
- 저수준 하드웨어 장치(CPU, Disk, Network) 가상화
- 장점
- 같은 서버에 다양한 운영체제 실행
- 물리머신 대비 동일한 자원을 더 효율적으로 사용
- 물리 머신 대비 빠른 서버 프로비저닝
- 단점
- OS 이미지, 라이브러리, 어플리케이션 등을 반복적으로 포함함.
Containers
- 어플 구동에 필요한 모든 종속성을 포함한 소프트웨어 패키지를 운영체제 위에서 가상화
- 장점
- 어느 환경에나 컨테이너 배포 가능
- OS를 부팅하거나 라이브러리 로드할 필요 없음.
- 가상환경을 더 효율적이고 경량으로 생성 가능.
- 수초 이내의 빠른 시작시간
- 하나의 호스트에 더 많은 어플 실행 가능
- OS 패치 업데이트 등 유지 관리와 관련된 오버헤드 감소(Host OS를 공유하기 때문에)
- 단점
- 컨테이너가 정의된 운영체제의 종속성. Host OS를 공유한다.
- 다중 고객-멀티 테넌트 환경에서는 리스크를 갖고 있는 구조이다. Ligntweight 가상화를 구현해서 사용하기도 함.
다중 운영체제 지원
- Docker에 다중 운영체제 사용이 가능할까요?
Docker 컨테이너는 우분투 runtime인데 거기에 CentOS 기반 어플을 구동시킬 수 있을까? > 가능.
Docker는 OS 레벨 가상화 기술입니다.
OS레벨 가상화
- 커널이 여러 격리된 사용자 공간 인스턴스의 존재를 허용하는 운영체제 패러다임.
- 호스트 OS의 커널을 공유
- 확인해보면 호스트 OS와 컨테이너 안 OS의 커널의 버전이 같은 것을 알 수 있다.
리눅스, 리눅스 배포판, 리눅스 커널의 차이?
리눅스, 리눅스 배포판 차이
- Ubuntu, Redhat, SUSE, CentOS 등등.. 은 리눅스 배포판
- 리눅스 배포판 = 리눅스 커널 + 컴포넌트(윈도우 시스템, 데스크톱 환경, 서비스 데몬, 패키지 매니저, 어플 등등)
리눅스, 리눅스 커널 차이
- 리눅스 커널 : 하드웨어 자원을 관리하고 추상화하여 프로세스에게 할당하고 관리하는 역할 수행.
- Ubuntu 호스트에 Windows 컨테이너는 동작할까?
- 커널이 다르기 때문에 동작하지 않는다.
- Linux 환경을 지원하는 Windows 이미지도 존재하지 않음.
- Windows/MacOS 호스트에 Ubuntu 컨테이너는 동작하는가?
- yes. 동작함. 하지만 추가적인 레이어(가상화 환경+LinuxKit)가 더 구성되며, Docker는 Linux 환경에서 구성되게 된다.
- 추가 오버헤드가 발생하기 때문에 개발환경에서는 괜찮아도 운영환경이라면 Docker는 Linux에서 구동하는 것으로.
Alpine Linux
- 보안, 간편성, 리소스 효율을 위해 디자인된 리눅스 배포판.
- 용량 줄이기 위해 다양한 노력.
예시) glibc > musl libc, Linux commands > 단일 명령(BusyBox)으로 변경
- 다른 이미지 배포판에 비해 아주 가볍다.
- 작은 이미지 크기가 중요한 이유 :
- 컨테이너 이미지를 베이스로 해서 이미지가 만들어지게 되고, 이미지 단위로 클라우드/쿠버네티스/도커 환경에서 실행되게 된다. 사이즈가 작으면 차지하는 메모리/디스크 공간이 작고, 빠른 로딩이 가능하기 때문에 어플을 빠르게, 비용 효율적으로 확장할 수 있다.
- 작은 크기만큼 라이브러리도, 디펜던시도 많이 빠져있다. 멀티 스테이지 빌드 방식으로 빌드된다.
컨테이너 관련 에코시스템
용어
- CNCF (Cloud Native Computing Foundation)
- 벤더 중립적인 클라우드향 오픈소스 프로젝트를 관리하는 재단
- 대표 프로젝트 : 쿠버네티스, HELM, CoreDNS, etcd, fluentd ...
- 클라우드 네이티브
- 퍼블릭/프라이빗/하이브리드 클라우드 환경에서 확장 가능한 형태로 빠르고 민첩하게 애플리케이션을 빌드하고 실행하는 것이 목표
- 급증하는 워크로드도 클라우드의 속성을 이용해 대응 가능
- 뒷받침하는 기술 : 컨테이너, 마이크로서비스, 서비스 메시, 변경할 수 없는 인프라 등
- CNCF에 등록된 프로젝트 100개 이상 + 벤더 제품들
- 개별 툴의 기능을 살펴보는 방식으로 접근은 한계
풀어야하는 문제나 프로세스를 이해하고, 거기에 맞는 도구를 선택.
- 개별 툴의 기능/개념 등에는 겹치는 부분이 존재한다.
- 9~10가지 분류로 매핑할 수 있다.
- 쿠버네티스는 도커를 기반으로 구동할 수 있지만, 다양한 런타임이 나타나게 된다. 그리고 다양한 런타임이 등장하면서 인터페이스가 분화되는 문제가 발생하게 된다.
- 동일한 역할을 하는 기술들을 묶을 수 있도록 인터페이스를 제작하게 되고 처음 나온것이 OCI 인터페이스. 컨테이너의 형식과 런타임의 업계 표준 구성, 도커를 포함한 여러 회사가 참여하였다.
- OCI : Open Container Initiative
- CRI : Container Runtime Interface
- 저수준 컨테이너 런타임 표준 구성
- 리눅스 커널에 있는 주요 작업 관리
- OCI 런타임을 이용해서 리눅스 커널의 아이솔레이션 기능을 이용할 수 있음.
- OCI(Open Container Initiative)
- 컨테이너 형식(farmat)과 런타임(runtime)의 업계 표준을 구성
(Docker, IBM, CoreOS, Google, MS ...)
- 현재 대부분의 컨테이너 런타임이 이 형식을 따름.
- OCI 런타임
- 컨테이너 실행에 필요한 저수준 컨테이너 런타임
Cgroups, namespace, security ... 구성
- runc
- OCI 스펙에 따라 컨테이너를 생성 및 실행하기 위한 CLI 도구
- 고수준 컨테이너 런타임
- CRI(Container Runtime Interface)
- 쿠버네티스에서 다양한 컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스. 현재 대부분의 컨테이너 런타임이 이 형식을 따름.
- 컨테이너 라이프 사이클과 컨테이너 이미지 관리.
- CRI runtime
- 컨테이너 실행에 필요한 고수준 컨테이너 런타임
- 컨테이너 라이프사이클, 이미지 등 관리.
- 쿠버네티스에서 지원하는 컨테이너 런타임 종류 : containerd, CRI-O, Mirantis Container Runtime ...
- 경량 가상머신을 이용해 안전한 컨테이너 런타임 구성.
- 쿠버네티스가 '도커 런타임을 지원하지 않는다'는 의미는 컨테이너 런타임을 관리하기 위한 기능 외의 기능들을 사용하지 않겠다는 의미.
- Firecracker : AWS에서 개발한 경량 microVM(마이크로 가상머신)을 위한 VMM.
- 장점 : 보안, 고성능, 운영환경 적용, 낮은 오버헤드, 오픈소스
- Kata Containers : 쿠버네티스에서 다양한 컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스.