01.쿠버네티스의 등장

리얼브로·2023년 3월 29일
0

쿠버네티스

목록 보기
2/3

1.1 컨테이너 환경으로의 진화

1.1.1 IT 환경의 진화

  • 90년대 - 클라이언트 / 서버

    서비스를 요청하는 클라이언트와, 그 요청에 응답하는 서버로 구성

  • 2000년대 - 가상화 환경

    가상화 환경은 인프라를 확장할 때 스케일 아웃 방식을 사용하고 메인프레임은 스케일 업 방식으로 확장한다.

    • 스케일 아웃 : 기존 서버와 같은 사양 또는 비슷한 사양의 서버 대수를 늘려서 처리하는 것을 의미

    • 스케일 업 : 서버 자체 성능 을 향상 시키는 것으로 CPU나 메모리를 추가하는 것을 의미

  • 2010년대 - 클라우드

    내부에 자체적으로 시스템을 도입하고 구축하기보다 이미 구축된 외부의 서버를 빌려서 필요할 때만 사용.

    • IaaS - Infrastructure as a Service

      인프라만 클라우드 벤더의 장비를 빌려서 사용하는 모델

    • PaaS - Platform as a Service

      개발 환경까지 클라우드 벤더가 책임지고 유지 관리하는 모델

    • SaaS - Software as a Service

      서비스 영역까지 클라우드 벤더가 책임지고 관리하는 모델

하지만 더 빠르고 혁신적인 기술을 요구함에 따라 컨테이너 환경이 등장한다.

기업의 서비스(애플리케이션)를 컨테이너에 올려 더욱더 빠르게 개발하고 배포할 수 있는 환경으로 진화하고 있다.

컨테이너의 개념을 IT로 가져오면, 배는 서버(리눅스)에 해당하고 컨테이너는 애플리케이션(경량의 리눅스)에 해당한다.

1.1.2 컨테이너란?

컨테이너(container)는 데스크톱, 기존의 IT환경 또는 클라우드 등 어디서나 애플리케이션 및 서비스를 실행하는 데 필요한

모든 요소를 포함하는 소프트웨어 패키지 다.

즉 호스트운영 체제 위에 논리적인 구획(컨테이너)을 만들고 애플리케이션을 작동시키는 데 필요한 라이브러리나 애플리케이션

등을 하나로 모아 마치 별도의 서버인 것처럼 사용할 수 있게 만든 것. 애플리케이션을 구동하기 위한 환경

컨테이너 환경에서는 도커 같은 컨테이너 런타임 위에 컨테이너를 올려 사용한다.

일반적인 가상화 환경은 하드웨어 수준에서 가상화 되지만, 컨테이너는 운영 체제 수준에서 가상화 된다.

컨테이너는 운영 체제의 커널을 공유 하기 때문에 상대적으로 가볍고 유연하게 운영할 수 있다.

커널이란 운영체제 일부로, 하드웨어와 프로세스의 운용을 위한 소프트웨어다.

가상 머신과 비교했을 때 자원을 더 적게 사용해서 하나의 시스템에서 더 많은 애플리케이션을 구동할 수 있다.

컨테이너 런타임 도구

  • 컨테이너디(containerd)

    도커 사에서 개발한 오픈 소스 런타임 이다. 컨테이너 이미지를 내려받고 압축을 푸는 과정부터 컨테이너를

    실행하고 감독하는 과정까지 컨테이너의 전체 수명 주기를 관리하는 기능을 제공한다.

  • 도커(docker)

    도커는 컨테이너디 위에 설치되는 데몬 이다. 도커는 컨테이너를 생성하고 관리하는 데 필요한 모든 기능을

    제공한다.

  • 크라이오(CRI-O)

    레드햇(Redhat), 인텔(Intel), 수세(SUSE), Hyper, IBM 등의 관리자 및 커뮤니티를 중심으로 개발된

    오픈 소스 런타임. 도커를 대체하기 위한 툴로 개발되엇다.

컨테이너 오케스트레이션 도구

여러 시스템(노드)에 컨테이너를 분산해서 배치하거나 문제가 생긴 컨테이너를 교체하는 등 컨테이너를 효과적으로

관리하도록 도와주는 도구. 대표적으로 쿠버네티스가 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화해서 컨테이너

관리가 쉬워진다.

  • 쿠버네티스(Kubernetes)

    구글에서 개발한 오케스트레이션 툴. 기능이 가장 많고 가상화 및 퍼블릭 클라우드 등 다양한 환경에서 작동하기

    때문에 널리 사용되고 있다.

  • 도커 스웜(Docker Swarm)

    도커가 설치된 여러 대의 서버를 클러스터로 묶어 단일 환경으로 사용할 수 있는 툴. 설치와 관리가 쉽다.

  • 아파치 메소스(Apache Mesos)

    수만 대의 시스템으로 확장할 수 있도록 설계된 오케스트레이션 툴.

    하둡, 스파크 같은 응용 프로그램의 리소스 공유 및 분리를 유연하게 운영할 수 있다.

1.1.3 컨테이너, 도구, 쿠버네티스의 관계

도커는 컨테이너를 실행하는 런타임이며, 쿠버네티스는 다수의 컨테이너를 관리하는 툴이다.

그래서 컨테이너를 실행할 때 도커는 꼭 있어야 하지만, 쿠버네티스는 선택 사항이라고 할 수 있다.

하지만 쿠버네티스는 여러 컨테이너 애플리케이션을 다수의 시스템(노드)에 배포, 확장, 연결하는

작업을 자동화한다.

1.2 쿠버네티스를 학습하기 전에 알아 두면 좋은 개념

1.2.1 데브옵스

데브옵스(DevOps)는 개발(development)과 운영(operation)을 결합해 탄생한 개발 방법론 이다.

시스템 개발자와 운영자의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론 또는 문화다.

이러한 문화는 개발자와 운영자의 입장 차이가 불거지면서 등장하게 되었다.

개발자는 잦은 요구사항과 버그를 수정 후 반영하기 위해 수시로 변경 및 적용을 하려 하지만

운영자 입장에서는 장애율을 낮추고 싶어 하기에 안정화된 소스를 두고 검증되지 않은 소스를 반영 하기를 꺼려 한다.

이러한 문제를 해결하고자 등장한 것이 데브옵스 다.

데브옵스가 가능하려면 CI/CD 방법론이 필요한데 이를 도와주는 것이 쿠버네티스다.

1.2.2 모놀리식 아키텍처와 마이크로서비스 아키텍처

애플리케이션 개발 아키텍처로는 모놀리식 아키텍처(monolithic architecture)와

마이크로서비스 아키텍처(microservice architecture)가 있다.

  • 모놀리식 아키텍처

    전통적인 애플리케이션 아키텍처를 지칭하는 의미로, 모든 모듈이 하나의 덩어리로 구성된 서비스 또는 애플리케이션을

    말한다. 모듈끼리 서로 의존하는 성질이 강해서 모듈의 작은 변화라도 전체 애플리케이션에 영향을 미칠 수 있다.

  • 마이크로서비스 아키텍처

    모듈들이 모두 분리되어 API로 통신하는 서비스 혹은 애플리케이션 이다. 각각의 모듈들이 개별적으로 분리되어 있어서

    하나의 모듈을 변경한다고 해도 전체 애플리케이션에 영향을 주지 않는다. 즉, 유지보수가 편리하며 비즈니스 변화에 능

    동적으로 대처할 수 있다.

1.2.3. CI/CD

CI/CD 는 데브옵스를 가능하게 하는 개발 방법론 이다.

CI(Continuos Intergration, 지속적통합) 는 데브옵스의 소프트웨어 개발 방식 중 하나다.

다수의 개발자가 개별적인 모듈을 개발한 후 병합하는 과정을 거치는데, 이때 병합 시간도 오래 걸리고 버그도 많이 발생한다.

이때 필요한 것이 CI 다. 지속적으로 통합하되 사람이 개입하는 것이 아니라 젠킨스 같은 툴을 사용해 자동으로 통합한다.

CD(Continous Deployment, 지속적 배포) 역시 소트프웨어 개발 방식 중 하나다.

애플리케이션에 변경 사항이 발생하면 이에 대한 오류가 있는지 테스트한 후 프로그램을 리포지터리에 업로드 하고,

마지막으로 운영 환경에 자동으로 배포한다. 이때 운영 환경에 자동으로 배포할 수 있는 ArgoCD 같은 자동화 툴을

이용한다.

1.3 쿠버네티스 이해하기

쿠버네티스(Kubernates)는 컨테이너 기반의 애플리케이션을 개발하고 배포할 수 있도록 설계된 오픈 소스 플랫폼 이다.

하나의 애플리케이션을 생성하기 위해서는 하나 이상의 파드(pod)가 필요하다. 이 파드는 쿠버네티스에서 생성할 수 있는

가장 작은 배포 단위이면서 단일 혹은 다수의 컨테이너를 포함한다.

또한 파드 외에 서비스(service), 볼륨(volume), 네임스페이스(namespace)등을 묶어서 오브젝트(object)라고

부르는데, 오브젝트는 쿠버네티스에서 상태 관리가 필요한 대상이라고 이해하면 된다.

  • 파드 : 쿠버네티스의 가장 기본적인 배포 단위 다.
  • 서비스 : 배포한 파드를 외부에서 접근할 수 있게 한다.
  • 네임스페이스 : 쿠버네티스 클러스터의 논리적인 분리 단위 다.
  • 볼륨 : 컨테이너의 파일을 저장하고 컨테이너 간 파일을 공유할 수 있는 저장소 다.

쿠버네티스의 특징 중 하나는 컨테이너를 개별적으로 하나씩 배포하는 것이 아니라 유사한 역할을 하는 컨테이너를

파드라는 단위로 묶어서 배포한다는 것이다. 예를 들어 쇼핑몰 웹 사이트에는 사용자가 상품을 검색하고 주문을 하는

애플리케이션과 상품 정보 및 이미지를 저장하는 저장소(데이터베이스)가 있을 때 이 둘은 서로 유기적인 관계를 갖는다.

그래서 애플리케이션과 저장소는 각각 하나의 컨테이너지만 이 둘을 쇼핑몰 웹 사이트 용도의 파드 하나로 묶에서 배포할

수 있다.

위 그림처럼 도커 런타임이 설치된 환경에서 컨테이너 혹은 도커를 실행, 유지 및 관리하는 것을 워커 노드라고 한다.

아래 그림과 같이 리눅스 위에 도커 엔진을 설치하고 그 위에 하나 이상의 컨테이너가 포함된 파드를 실행한다.

이때 각 컨테이너에서는 그 목적에 맞는 서비스가 실행 된다.

쿠버네티스는 기본적으로 마스터 노드 1대와 워커 노드 1대로 구성된다.

마스터 노드는 전체 쿠버네티스 환경을 관리하며, 워커 노드는 컨테이너를 실행하고 관리한다. 워커 노드의 자원(CPU,

메모리 등) 사용률이 높을 때에는 워커 노드의 개수를 늘릴 수도 있다. 워커 노드의 개수와 상관없이 마스터 노드와 워커

노드로 구성된 쿠버네티스를 하나의 클러스터 라고 부른다.

컨테이너 환경을 구축하고자 한다면 쿠버네티스는 필수 사항이다. 쿠버네티스를 사용하지 않고는 수많은 컨테이너를

관리하기 힘들기 때문이다. 이 밖에도 쿠버네티스를 사용하면 다음의 효과를 얻을 수 있다.

(1) 무중단 서비스

서버가 내려갔다가 올라오는 서비스 중단 없이 서비스를 배포할 수 있다.

(2) 클라우드 벤더 종속성 해결

특정 클라우드 벤더의 제품을 사용하게 되면 그 클라우드 벤더의 유사한 제품들을 도입해야 하는 경우가 종종 있다.

제품의 호환성 문제로 특정 클라우드 벤더에 의존하는 현상을 락인(lock-in) 현상이라고 한다. 클라우드의 경우에도

AWS를 사용하는 기업이면 또 다른 클라우드 벤더인 마이크로 소프트의 제품을 사용하는 것이 어렵다. 두 클라우드

벤더의 제품을 사용하기에는 제약 사항이 많고 비용 무넺도 무시할 수 없기 때문이다. 하지만 오픈 소스인 쿠버네티스

는 특정 클라우드 벤더에 종속되어 있지 않기 때문에 락인 현상이 없다. 뿐만 아니라 다른 오픈 소스 제품 혹은 사용 제품

과의 호환성도 뛰어나다.

(3) 효율적인 자원 사용

파드가 사용할 수 있는 자원(CPU, 메모리 등 )을 사전에 지정할 수 있어서 시스템(노드)의 전체 자원을 관리할수 있어

효율적으로 사용할 수 있다.

(4) 유연한 확장성

파드의 자원 사용률에 따라 파드의 개수를 늘리거나 줄일 수 있다. 예를 들어 CPU 사용률이 200%로 증가하면 파드를

1개에서 5개로 늘리고, CPU 사용률이 감소하면 파드를 다시 1개로 줄일 수 있다.

(5) 애플리케이션 개발의 단순화

java 버전을 업그레이드 해야 하는 상황이 발생했을때 운영 환경에 배포한 뒤 며칠이 지나서 오류가 발생하면 복구하기

어렵지만 컨테이너 환경에서는 이전 환경으로 복구하거나 기존 환경은 그대로 두고 새로운 컨테이너를 띄우면 되므로

개발이 훨씬 편리해 진다.

(6) 애플리케이션 배포의 가속화

CI/CD 기술로 개발자는 인프라 구성에 대한 정보 없이도 컨테이너화된 애플리케이션을 손쉽게 배포할 수 있다.

0개의 댓글