쿠버네티스에서의 컨테이너, 가상화 기술 정리

IT에는 어떤 직군들이 있을까?

 

• 네트워크 엔지니어: cisco의 제품으로 네트워크를 세팅하고 성능, 문제를 분석하는 엔지니어. 서버가 죽으면 서비스가 죽지만 네트워크가 죽으면 전사가 마비되기 때문에 매우 중요하다.
• 스토리지 엔지니어: 보통 스토리지 전문 기업에서 설치부터 지원까지 담당한다.
• 서버 엔지니어: 현재는 대부분의 서버를 가상화해서 VM(Virtual Machine)으로 나누기 때문에 서버 엔지니어가 OS 및 가상화 세팅까지 담당한다.
• 미들웨어 엔지니어: app이 os위에서 잘 돌아가도록 하는 보조 프로그램(e.g. tomcat)을 다루는 엔지니어. 트래픽을 전달하거나 로그를 저장한다. 특정 기업의 WAS 솔루션을 사용할 수 있고 이런 경우 운영팀에서 병행한다.
• 데이터: 데이터 분야는 다양한 직군이 존재할 수 있다
  • 데이터 애널리스트: 고객 의사 결정을 위한 데이터 분석
  • 데이터 사이언티스트: 데이터 알고리즘 개발
  • 데이터 엔지니어: 데이터 처리 파이프라인 구축
  • 데이터 관리자: 데이터 표준, 정책 관리
  • 데이터베이스 관리자: DB 솔루션 제품 관리
• 어플리케이션: 프론트엔드, 백엔드 개발자
• DevOps 엔지니어: 개발과 운영을 결합하여 전반적인 소프트웨어 개발 라이프사이클을 관리한다.
• MLOps 엔지니어: AI 분야의 DevOps 관리자. 데이터 처리, 모델 학습, 배포 까지의 머신러닝 라이프사이클을 관리한다.

한번쯤 알고 넘어가면 좋을 서비스 모델

 

• On-Premises: 기업 자체에서 IT 인프라를 가지고 있고 직접 운영.
• IaaS(Infrastructure As A Service): 인프라 구간에 대한 서비스 제공
• PaaS(Platform As A Service): 쿠버네티스 기능은 제공해주지만 내 앱을 배포해주는 프로세스를 만들어 주지는 않음. DevOps 역할을 기대하면 안된다.
• SaaS(Software As A Service): 사용자는 인프라에 대해 아무것도 몰라도 되고, 소프트웨어만 사용하면 된다. 이외에도 DBAAS, EAAS 등도 있음.

 

쿠버네티스의 등장 이후 새롭게 KaaS(KubernetesAs A Service)란 용어도 등장한다.

보통 os부터 데이터 영역의 범위에서의 업무를 담당하게 된다.

• On-Premises: 전담 IT 인프라 개발팀이 있어 서버, 스토리지, 네트워크 분야의 담당자와 협업을 하며 서버에 직접 쿠버네티스 클러스터를 구축하고 관리한다. 어플리케이션 개발팀에서 리소스와 사용 요청을 받아 클러스터를 제공해준다.
• IaaS: 클라우드 서비스를 제공하는 회사마다 각 쿠버네티스 서비스가 존재한다. 어플리케이션의 데브옵스팀이 해당 쿠버네티스 서비스를 운용한다.
• PaaS: 자체적으로 서버실은 있다. 하지만 자체적으로 쿠버네티스를 운영할 여력이 없을 수 있음. 보통 외주 개발을 투입한다. 솔루션 엔지니어에게 기술 지원을 받아 쿠버네티스 위에 앱을 띄우고 배포하고, 이 과정을 운영팀에게 인수인계 하는 형식.
• SaaS: 쿠버네티스 오픈소스인 서버리스 서비스를 이용하여 외부 사용자에게 서비스를 오픈한다.

쿠버네티스에서 가장 어려운 리소스 - Pod, Service PV

 

먼저 어떤 회사의 인프라, 그것도 서버-스토리지-네트워킹 레벨에서의 구축단계를 간단하게 정리하면 다음과 같다.

회사 내 서버는 게이트웨이에 연결되어 사내 네트워크 망이 만들어진다.

이 게이트웨이에 라우터를 붙이게 되면 외부에서 접속이 가능하다.

서버에 대한 데이터를 안전하게 하기 위해서는 스토리지를 추가한다.

 

이러한 서버-스토리지-네트워킹은 어떤 앱 서비스를 운영하기 위한 기본이다. 이를 편리하게 설정하기 위한 것이 바로 클라우드 서비스.

이러한 내용을 쿠버네티스에서는 Pod, Service, PV로 추상화하여 사용한다.

 

보통 서버는 커다란 고사양 서버 한 대를 가상화하여 효율적으로 분할하여 사용한다.

쿠버네티스 또한 가상화된 VM 위에 올라간다.

어플리케이션을 실행하기 위해서는 CRI를 설치하고 컨테이너를 생성하여 App을 띄운다. 컨테이너가 하나의 App이 되는 개념.

쿠버네티스는 파드(Pod)라는 개념 안에 컨테이너가 존재하기 때문에 파드가 앱 배포를 수행한다.

 

앱으로 사용자의 트래픽이 유입되어야 하고 또한 사용자의 데이터를 관리해야 한다. 이러한 역할을 각각 서비스(service), PV가 수행한다.

컨테이너 간 통신은 CNI를 통해 네트워크를 만들어준다. 이 네트워크는 내 os의 IPTABLE과 연결되어 실제 물리적인 서버로 전달된다. 이 가상화-서버 구간에 네트워크를 넣어야 하는데, 이를 VM Network이라고 하며 다음과 같은 유형이 존재한다.

1. Bridge: 호스트 서버와 똑같은 네트워크 망에서 사용. 게이트웨이-호스트와 동일한 대역의 IP가 VM에 설정된다.
2. Host Only Network: 호스트와 타 VM에서는 연결되지만 외부에서는 연결되지 않는다.
3. NAT: 인터넷을 사용하기 위한 네트워크
4. Nat Network: 인터넷 + VM간 통신 가능, 하지만 호스트와 연결이 되지 않는다.

이렇게 가상화 구간의 네트워크와 물리적 공간의 네트워크 설정이 별도로 존재한다.

 

쿠버네티스의 서비스 종류는 다음과 같다.

1. ClusterIP: 컨테이너 간의 네트워크
2. NodePort: VM의 네트워크
3. LoadBalancer: 클라우드 서비스 상의 네트워크
4. ExternalName: 외부 DNS 서버를 upstream 서버로 등록하고 호출.

마지막으로 파드를 다루기 위해 스토리지의 유형과 PV의 유형에 대해 알아야 한다.

1. 오브젝트 스토리지
2. 파일 스토리지: ReadWriteMany
3. 블록 스토리지: ReadWriteOnce

쿠버네티스에서는 실제 스토리지까지 연결해주는 솔루션이 존재하는데 이를 CSI라고 한다.

누구나 알고 있는 가상화 기술 비교

쿠버네티스 도입 이전의 가상화 타입은 다음과 같다.

1. 호스트 가상화: guest os를 위한 패키지들이 필요해 사이즈가 크고, 추가적인 리소스가 필요하다
2. 하이퍼바이저 가상화: VDI로 외부 사용자에 대한 인증을 거친다. VM에서 내 PC로 데이터를 가져올 수 없다.

컨테이너 가상화

쿠버네티스가 도입되고 계속되면서 VM과 컨테이너 가상화를 구분한다.

Host OS 위에 CRI, VM  대신 컨테이너를 생성한다. 컨테이너 내부에는 guest os도 없고 App 실행을 위한 패키지들만 포함한다. 이는 컨테이너가 host os와 커널을 공유하기 때문이다. 따라서 사이즈가 작고 시작/종료도 빠르며 이로인해 리소스 사용에 대한 효율이 높아진다.

 

컨테이너 런타임

high level인 docker, containerd, cri-o는 모두 low level의 runc를 사용하여 컨테이너를 생성한다. runc는 oci라는 표준화된 컨테이너를 생성해준다.

컨테이너의 실체인 리눅스 커널에는 다음 기술들이 존재한다.

• chroot: 프로세스 별로 디렉토리 분리
• namespace: 프로세스 별로 시스템 분리(mnt, pid, net, user, ipc, uts)
• cgroup: 프로세스 별로 리소스 분리 (memory, cpu, network, disk I/O)

따라서 한 프로세스에 대해 디렉토리, 시스템, 리소스가 할당이 되고 독립적으로 관리되며 이를 컨테이너라고 부른다.

host os의 커널, os 기본 패키지를 함께 공유해서 사용하여 컨테이너마다 별도의 os가 필요하지 않는 것이다.

컨테이너의 장점은 의존성 충돌이 없고 확장에 유리하다는 점.

 

아무나 모르는 컨테이너 기술 장점 - 일관성 있는 배포 환경

 

기존 VM 환경에서의 배포 환경은 다음과 같은 단점이 존재했다.

• 개발자 환경과 서버 개발 환경이 다를 경우 상이한 동작 발생
• guest os를 보안 때문에 패치해야 할 수 있음. 이 경우 앱 개발에 필요한 패키지 버전도 함께 패치해야할 수 있음. 즉 Host OS 패치에 따라 라이브러리의 버전이 달라지게 된다.
• 인프라 담당자, 데브옵스 엔지니어는 각 환경마다 작업을 별도로 수행해야 하기 때문에 작업 빈도가 많음. 또한 클라우드로 확장 시 OS가 달라질 수 있다.

반면 컨테이너 환경에서의 배포는 굉장히 편리하다.

• 개발자가 컨테이너 환경 세팅만 하면 모두 동일한 Linux 환경에서 실행이 가능하다. 개발 환경 또한 컨테이너 환경으로 설정.
• 새로운 App을 배포한다고 해서 추가적인 작업이 없으므로 담당자간 협의가 필요 없다.
• Host OS 패치에 따른 JDK 버전 영향 없고, 각 환경은 컨테이너 이미지와 배포 파이프라인 구성에 따라 자동으로 분리된다.
• 클라우드로 확장하여 다른 OS, Runtime을 사용해도 컨테이너를 사용하면 추가적인 충돌을 피할 수 있다.

쿠버네티스에 대한 단점 - 그럼에도 불구하고 써야하는 이유

 

쿠버네티스가 꼭 좋은 것만은 아니다.

일단 쿠버네티스의 난이도가 쉽지 않다.

환경 구축이 어렵고, 장애 시 원인 파악, 또한 생소한 쿠버네티스 개념을 이해하는게 힘들 수 있다.

또한 리소스 절감 측면에서도 구성하기 나름이라 쿠버네티스를 사용한다고 해서 모두 해결되진 않음.

많은 오픈소스들을 사용해 라이선스 비용 절감 또한 오픈소스를 관리하는 인원이 필요하여 투입 비용이 증가한다.

 

그럼에도 불구하고 쿠버네티스는 MSA 운영 환경에 매우 유리하다. App을 확장하고 상태 관리, 트래픽 관리가 굉장히 편리하기 때문.

또한 많은 오픈소스들로 이루어진 쿠버네티스 생태계가 어느정도 표준화 되었고, 많은 레퍼런스가 존재하여 스스로 공부하여 전문가가 될 수 있다.

또한 쿠버네티스를 사용하면 선진 IT 기업의 이미지를 갖게되어 많은 회사들이 선호하게 된다.