쿠버네티스를 시작하기에 앞서

쿠버네티스

컨테이너 기반 오픈소스 가상화 프로젝트

• 단점
  • 큰 러닝 커브
  • 시스템 도입으로 따라오는 개발 문화와 시스템의 변경 비용이 큼
  • 학습이 부족 시 보안 이슈

 

클라우드 네이티브

클라우드의 장점을 최대한 활용하여 정보 시스템을 구축 및 실행하는 환경으로 기술, 애플리케이션, 아키텍처, 개발방법론, 조직, 프로세스 등 다양한 용어와 결합하여 다양한 의미로 사용

• CNCF Cloud Native Definition
  • 클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API가 이러한 접근 방식의 예시들이다.

 

기존 애플리케이션과 클라우드 네이티브 애플리케이션의 차이점

구분	기존 애플리케이션	클라우드 네이티브 애플리케이션
애플리케이션 구조	모놀리식 구조	마이크로서비스
결합	크고, 조밀한 결합	느슨한, 서비스 기반
실행환경	물리서버 중심	가상 컨테이너 중심
확장	수직 확장(Scale-Up)	수평 확장(Scale-Out)
인프라 의존성	인프라 의존	인프라 독립, 이식성 보장
개발방법	폭포수	애자일
빌드, 배포	수작업, 긴 시간	CI/CD 자동화, 짧은 시간 & 지속적
조직구조	단절된 개발, 운영, 보안 팀	데브옵스 협업

 

클라우드 네이티브 구성 요소

1. 마이크로서비스 : 독립적인 실행 및 배포 가능한 마이크로서비스
2. 컨테이너 : 경량화된 컨테이너 단위 수평적 확장
3. DevOps : 개발팀과 운영팀간 단일한 협업 프로세스
4. CI/CD : 소규모 개발팀별 자율적, 독립적 서비스 운영

 

모놀리식(Monolithic architecture) 아키텍처

• 단점
  • 모놀리식 서비스 아키텍처를 스케일아웃
    • 기존의 애플리케이션을 그대로 복제하여 로드벨런싱
    • 불필요한 서비스까지 모두 복제하여 리소스가 낭비
  • 종속적인 라이브러리의 충돌
    • 각각의 기능들은 서로 다른 기능을 제공하여 버전의 종속성을 필요한 경우가 존재
    • 각 기능의 따른 라이브러리를 매 업데이트마다 관리하기 매우 어려움
  • 조금만 수정해도 전체 빌드 및 배포 필요
    • 소스코드 전체가 하나로써 동작해 작은 수정만 있더라도 전체를 빌드하여 다시 배포
    • 프로그램의 크기가 커지면 한 번만 컴파일해서 전체 테스트를 돌려도 수 시간 소모
    • 하루에 버그가 여러 개 순차적으로 발견된다면.. (끔찍)

 

마이크로서비스 아키텍처

모놀리식 아키텍처의 대안으로 애플리케이션의 기능을 분리하여 개발 및 관리

• 장점
  • 개발자가 특정 비즈니스 로직에 대해서만 집중하여 개발 가능해 빠른 개발
  • 개별 서비스 단위로 개발, 패키징, 빌드, 테스트, 배포로 각 서비스마다 유연한 스케줄
  • 서비스 단위로 스케일아웃이 가능하여 불필요한 서비스는 줄이고 더 많은 자원이 필요한 서비스는 확장 가능
• 단점
  • 분산 시스템 환경에서 Transaction 보장, 테스트, 배포, 관리 복잡
• 해결책
  • 쿠버네티스

 

데브옵스(DevOps) 모델

소프트웨어 개발과 IT 운영을 결합한 합성어. 기존의 분리된 개발팀과 운영팀의 협업으로 전체 라이프사이클을 함께 관리하며, 더 빠르고 안정적으로 소프트웨어를 빌드, 릴리즈할 수 있도록 두 팀 간의 프로세스를 자동화하는 일련의 과정

• 이점
  • 서로의 업무에 대해 더 잘 이해하여 신속하게 사용자에게 필요한 업데이트를 수행 가능
  • 개발자는 소비자가 무엇을 원하는지, 운영자는 애플리케이션을 제공하는데 해결할 문제를 인지 가능
  • 컨테이너와 마이크로서비스를 사용하면 자주 빠르게 릴리즈가 가능해, 빠르게 좋은 기능을 제공
  • 개발자가 운영에 필요한 인프라와 하드웨어에 대해 잘 몰라도 릴리즈가 가능
  • 개발과 릴리즈가 편해지므로 안정성이 확보, 협업 강화

 

가상화

하드웨어에 종속된 리소스를 사용해 유용한 IT 서비스를 만드는 기술
물리적 머신의 기능을 여러 사용자 또는 환경에 배포해 물리적 머신을 최대한 활용

 

가상화 역사

• 시작
  • IBM에 의해 1960년 시작, 2000년대 초 도입
  • 하이퍼바이저와 같은 가상화 지원 기술이 일괄 처리를 수행하는 컴퓨터에 여러 명의 사용자가 동시에 액세스 가능하게 함
• 가상화 기술을 활용해 다양한 벤더사의 애플리케이션 배포
  • 1990년대 대부분의 기업이 물리 서버와 단일 벤더 IT 스택을 사용하고 있었기 때문에 다른 벤더의 하드웨어에서 레거시 애플리케이션 실행 불가능
  • 가상화를 통해 기업은 서버를 파티셔닝하고 여러 유형 및 버전의 운영체제에서 레거시 애플리케이션 수행
  • 서버를 더 효율적으로 사용해 구매, 셋업, 냉각, 유지관리와 관련된 비용 감소

 

하이퍼바이저

물리 리소스를 분리하여 가상 환경에 사용, 호스트 컴퓨터 1대에서 다수의 운영체제를 동시에 실행하는 논리적 플랫폼

• Native - type1
  • 하드웨어/베어메탈에 직접 설치
  • 게스트 운영체제는 두 번째 수준으로 실행
  • Xen, KVM, Xen Server 등
• Hosted - type2
  • 일반 프로그램처럼 호스트 OS에서 실행
  • 게스트 운영체제는 세번째 수준으로 실행
  • Virtualbox, Vmware, Parrallels 등

 

가상화 방식

• 전가상화 (Full Virtualization)
  • 하드웨어를 모두 가상화
  • 게스트 운영체제를 변경하지 않음
  • 물리적인 가상화를 지원하는 CPU 가상화 기술(VT 필요)
  • 네이티브 방식은 이 가상화를 사용
• 반가상화 (Para Virtualization)
  • 하드웨어를 완전히 가상화하지 않음
  • 게스트 운영체제 커널 일부 수정이 필요(오픈소스가 아니면 사용 불가)
  • 하이퍼바이저가 모든 제어를 담당하므로 높은 성능을 유지
  • Qemu가 대표적 도구

 

컨테이너

가상환경을 사용해 각 마이크로 서비스를 격리(isolate)하는 기술로 가상머신처럼 하드웨어를 전부 구현하지 않기 때문에 빠른 실행 가능

• 리눅스 네임 스페이스
  • 각 프로세스가 파일 시스템 마운트, 네트워크, 유저(uid), 호스트 네임(uts) 등에 대해 시스템에 독립 뷰를 제공
• 리눅스 컨트롤 그룹
  • 프로세스로 소비할 수 있는 리소스 양(CPI, 메모리, I/O, 네트워크 대역대, device 노드 등)을 제한
• Union Mount File System
  • 동일한 디렉토리에 여러 파일시스템을 마운트하는 기능

 

도커(Docker)

• 컨테이너 기술을 지원하는 프로젝트 중에 하나
• 다양한 운영체제에서 사용 가능(리눅스, 윈도우, MacOS)
• 애플케이션에 국한 되지 않고 의존성 및 파일 시스템까지 패키징하여 빌드, 배포, 실행을 단순화
• 리눅스의 네임 스페이스와 cgroups와 같은 커널 기능을 사용하여 가상화

 

도커 아키텍처

• docker CLI : 컨테이너를 컨트롤하는 프로그램
• CRI : OCI에서 제시하는 컨테이너 런타임 표준
• Containerd, CRI-O : 컨테이너 표준을 만족하는 오픈소스 프로젝트
• runC : 컨테이너 생성 및 실행을 위한 OCI호환 경량 저수준 런타임

 

Containerd

• Docker의 구성 요소로 레지스트리에서 이미지 가져오기, 컨테이너 시작 및 중지와 같은 컨테이너 관리와 관련된 하위 수준 작업을 처리하기 위해 개발
• 2017년 Docker에서 독립형 프로젝트로 Containerd가 추출되어 CNCF 프로젝트가 됨
• Docker에서 추출된 이후 containerd는 성능, 안정성 및 보안에 중점을 두고 크게 발전
• 2018년 containerd 1.0은 프로젝트의 안정성과 성숙도에 중요한 이정표를 세움
• 2019년 Kubernetes의 기본 컨테이너 런타임으로 containerd 채택
• 2020년 CNCF Landscape에 containerd 포함

 

컨테이너 레지스트리

• 사용자가 사용할 수 있도록 데이터베이스를 통해 Image를 제공
  • 이미지
    • 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 만든 하나의 파일
    • 누구나 이미지를 만들어 푸시할 수 있으며 푸시된 이미지는 다른 사람들에게 공유 가능
  • 컨테이너
    • 이미지를 격리하여 독립된 공간에서 실행한 가상 환경
• Docker Hub Registry 가 대표적으로 public, private 하게 사용 가능
• On-premise에서 사용할 시, Harbor 등의 솔루션 사용

 

도커의 한계

• 서비스가 커지면 커질수록 관리해야 하는 컨테이너의 양이 급격히 증가
• 도커를 사용하여 관리를 해도 쉽지 않은 형태
• 이를 해결하기 위해 쿠버네티스 등장

 

쿠버네티스

• 2014년 구글이 컨테이너 운영 노하우가 담긴 오픈소스 공개
• 고대 그리스어로 항해사라는 의미
• 다수의 컨테이너를 자동으로 운영하기 위한 오케스트레이션 도구
• 많은 시스템을 통합, 컨테이너를 다루기 위한 API 제공

 

 

데브옵스(DevOps)를 위한 쿠버네티스 마스터 강의 | 보안프로젝트 - 인프런

데브옵스(DevOps)를 위한 쿠버네티스 마스터 강의 | 보안프로젝트 - 인프런