Container와 Kubernetes 소개

 

1. 모놀리식 아키텍처

• Monolithic Architecture(레거시 시스템)
• 기능이 한 번에 다 들어있다.
• 하나의 기능을 위해 다른 기능까지 수정해야 할 수 있다.
• 장점
  • 간단한 개발
  • 간편한 배포
  • 단순한 확장성 
    -> 코드의 확장.
    -> 결국 재배포를 해야 한다..

 

• 단점
  • 코드 품질이 낮아짐
  • 애플리케이션 시작이 오래 걸림
  • 애플리케이션의 지속적인 배포가 어려움
  • 어플리케이션의 확장이 어려움
  • 컴포넌트별 개발의 어려움
  • 다양한 기술 적용의 어려움

 

 

2. 마이크로 서비스 아키텍처

• 기능별로 서비스를 더 세밀화한다.
• 세분화되고 독립적으로 작동하는 방식 사용.
• 나눠놓은 상태에서 서로 통신할 수 있는 인터페이스를 만들어 놓는다  ->  API
• 동기방식과 비동기 방식이 존재한다.
  • 참고로 Openstack은 비동기!

 

• 동기방식 (HTTP/RESTful API)
  • session이 맺어져있어야한다.
  • 명령어를 실행하고 결과값이 나올때까지 연결이 이루어져있어야한다.
  • 계속 동기화하는 것.

 

• 비동기방식 (AMQP)
  • 요청값을 전달  ->  그 요청값에 따라서 실행
  • 통신이 끊겨도 상관없다.
  • 요청값을 전달하면 끝

 

• API가 반드시 필요.
  • 각 컴포넌트간에 연결한다.
  • API 주소와 Endpoint가 같다?
    • Endpoint 종류가 세가지 있다.
      • public, internal, admin

 

• 장점
  • 크고 복잡한 어플리케이션을 지속적으로 배포할 수 있음.
    • 향상된 유지 보수성 : 코드에 대해서 보수를 해야함  ->  그 코드만 수정
    • 테스트 용이성
    • 배포 효율성
    • 개발에 생산성이 높고 배포 속도가 빠르다 : 각각의 어플리케이션을 각각의 개발자가 개발하고 여러개의 프로젝트를 분리해서 하다보니 빠름.
    • 향상된 장애 격리 : 장애가 발생한 서비스만 영향을 받는다.
      but!!  어떠한 기능 때문에 연쇄적인 장애가 발생할 수 있다  ->  어디서 장애가 발생했는지 모를 수 있다.
    • 다양한 기술 적용 가능

 

• 단점
  • 분산시스템 설계에 따른 복잡성 : 규모가 커지면 커질수록 복잡하다.
    • 서비스 간 통신 매커니즘을 따로 구현 : API 통신을 할 수 있는 기능을 따로 구현해야한다.
    • 서비스 간 상호작용 테스트
  • 배포 및 관리 운영상의 복잡성
  • 증가된 리소스 소비

 

 

3. DevOps

• 개발, 품질보증, 운영 모두 전체 라이프사이클을 다 같이 작업.
• 마이크로서비스 및 DevOps를 가능하게 하는 기술 = kubernetes
• kubernetes는 컨테이너 기술을 이용하여 표준화 되고 일관성 있는 환경을 제공하고, DevOps 문화를 가능하게 해준다.

 

 

 

<  컨테이너 >

1. 컨테이너란?

• 운영체제에서 실행되는 여러 프로세스는 컨테이너 라는 개념으로 격리되어 별도의 운영 환경을 제공.
• 컨테이너 환경을 실행할 수 있는 기술
  • Docker
  • chroot
  • LCX
  • Solaris Containers(Zones)
  • FreeBSD Jail
  • WPARS(AIX)
  • rkt

 

 

2. 컨테이너 아키텍처

• 리눅스 시스템에서 컨테이너를 이용하여 격리 구조를 만드는 기법은, 격리를 담당하는 linux namespace와 리소스를 제어하는 control group(cgroup)을 사용하여 격리된 컨테이너 환경을 제공한다.
• 리눅스 시스템에서 namespace는 기본적으로 단일 네임스페이스를 사용하여 동작
• namespace의 종류
  • mount point
  • process
  • network - IPC
  • UTS
  • user

 

• 제어 그룹은 프로세스 또는 컨테이너가 사용할 수 있는 리소스의 양을 제한할 수 있다.
• 제어 그룹이 제한 할 수 있는 리소스
  • CPU
  • memory
  • network 대역폭
  • 디스크 입출력

 

 

3. 도커 컨테이너

• docker는 namespace와 cgroup을 사용하여 어플리케이션을 패키징, 배포, 실행하는 플랫폼
• image
  • 실행할 어플리케이션과 라이브러리 및 환경을 하나의 패키지로 묶은 것

 

• registry
  • 이미지를 저장하고 공유할 수 있는 스토리지
  • 도커 허브 등과 같은 공용 레지스트리와 개인 및 특정 시스템만 사용할 수 있는 사설 레지스트리를 직접 구축할 수 있다.

 

• container
  • 이미지를 실행한 컨테이너

 

• docker는 kubernetes에서 기본적으로 어플리케이션을 구동하기 위한 구성요소 중 하나.

 

 

4. 컨테이너 vs 가상머신

• 가상머신은 어플리케이션 동작을 위해 어플리케이션이 사용하는 리소스와 운영체제가 동작하기 위한 리소스가 필요하다.
• 컨테이너는 어플리케이션이 동작하기위한 리소스만 사용하기 때문에 훨씬 빠르고 가볍게 동작할 수 있다.

 

 

 

< 쿠버네티스 >

1.쿠버네티스란?

• 컨테이너 기반의 확장 가능한 오픈소스 플랫폼.
• 개발자와 관리자가 수천개의 어플리케이션과 서비스를 관리하는데 도움을 주기 위해 개발함.
• C++로 만들어졌던 Borg 시스템(1세대)을 현재 Go lang과 docker 기반으로 개발함.

 

 

2. 쿠버네티스가 제공하는 기능

• 컨테이너 플랫폼
• 마이크로서비스 플랫폼
• 이식성 있는 클라우드 플랫폼 : object를 만들 때 yaml 형태로 만든다  ->  다른 클러스터에서도 실행 가능.
• orchestration

 

• 쿠버네티스는 컨테이너 기반의 분산 클러스터 환경을 제공하며 워크로드를 위해 컴퓨팅, 네트워킹 및 스토리지 인프라를 오케스트레이션 한다.
  • cluster : 여러개의 하드웨어가 하나의 서비스처럼 동작하게 만들어주는 기능
  • orchestration : 여러개의 도커 호스트가 있고 어떤 호스트를 띄울지는 스케줄러가 정한다.

 

• 쿠버네티스는 IaaS의 유연함을 더해주며, PaaS를 제공

 

 

3. 쿠버네티스가 제공하지 않는 기능

• 쿠버네티스는 하드웨어 레벨이 아니라 컨테이너 레벨에서 운영되기 때문에 PaaS의 일부 기능만 제공
• CI/CD pipeline
  • 기본적으로 쿠버네티스가 제공하지 않는다.
  • 지속적 통합, 지속적 배포를 제공하지 않는다.
  • 소스코드 배포 및 어플리케이션을 빌드하지 않음

 

• 어플리케이션 레벨의 서비스
  • ex) 미들웨어, 빅데이터, 데이터베이스, 캐시 등..

 

• 로깅, 모니터링, 경고 솔루션

 

• 쿠버네티스에 포함되지 않을 뿐 쿠버네티스에 붙여서 사용가능한 것은 많다.