DevOps 마스터 kit -1

김재현·2022년 12월 5일
0

FastCampus

목록 보기
8/9

클라우드 환경을 위한 리눅스

리눅스 강의에 왜 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 : 쿠버네티스에서 다양한 컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스.

0개의 댓글