Sunyoung Kim

Sunyoung Kim

뒤뚱뒤뚱 개발일기

쿠버네티스란

5 minute read

쿠버네티스 란?

  • 개발된 시스템의 배포관리나 서비스 유지보수를 담당
  • 쿠버네티스를 써야되는 이유?
    • 대규모 서비스를 운영시 최대한 자원을 효율적으로 써야 비용적으로 유리하다.
  • 서버 자원을 효율적으로 쓰기 위해서는 가상화기술에 대해 관심을 가질 수 밖에 없다.
  • 쿠버네티스를 좀 더 잘 이해하기 위해 가상화 기술에 대한 히스토리를 살펴보자

쿠버네티스의 등장

image-20210402011145646

이미지 출처

  1. 리눅스 - 자원격리기술

    • 리눅스에는 자원을 격리해서 프로세스들이 독립적인 환경에서 돌아갈 수 있도록 해주는 기술이 있었지만, 사용법이 어려워서 대중적으로 사용되지 않았다.

  2. VM - 가상화 기술

    • 많은 기업들이 openstack으로 운영환경을 자동화하려고 시도함

    • 자동화는 되는거 같은데 생각보다 시스템 효율이 나지 않음을 느낌

    • why?
      • VM가상화를 하기 위해서 무거운 OS를 띄워야한다는 근본적인 원인
      • 가벼운 서비스 하나를 띄우기 위해서 이보다 더 큰 OS를 띄워야 하는 경우가 생긴다.

  3. Container - 가상화 기술

    • dotCloud라는 회사가 내장 리눅스의 어려운 자원 격리 기술을 Container라는 개념으로 누구나 쉽게 사용할 수 있게 만들었고, 회사를 docker라는 이름으로 변경했다.

    • 이 기술을 오픈소스로 공개하였다.

    • 컨테이너 가상화기술

      • 서비스간에 자원격리를 하는데 OS를 별도로 안 띄워도 된다.
      • OS 가동시간이 없기 때문에 자동화시에 엄청 빠르고, 자원 효율도 매우 높다.

    • 도커

      • 도커자체는 하나의 서비스를 컨테이너로 가상화시켜서 배포하는 것이다.

      • 엄청 많은 서비스를 운영할 때 그걸 일일이 배포하고 운영하는 역할을 해주진 않는다.

        ⇒ 이러한 역할을 해주는 것이 컨테이너 오케스트레이터 라는 개념이다.

  4. 컨테이너 - 오케스트레이터

    • 여러 컨테이너들을 관리해주는 솔루션
    • 도커의 컨테이너 기술이 오픈소스이기 때문에 많은 회사들이 이를 이용해 자신들만의 오케스트레이터를 내놓게 된다.
    • 구글이 쿠버네티스 release를 내놓은 것은 다른 회사보다 조금 늦었지만, 쿠버네티스는 구글에서 주도했지만 많은 회사들이 참여해서 저마다 시스템 노하우를 녹여내서 기업들이 쿠버네티스를 사용하면서 만족도가 높아졌다.

  5. 쿠버네티스 - 클라우드 서비스

    • 쿠버네티스가 서비스 배포운영의 표준으로 자리잡아가고 있고, 이 기술을 바탕으로 많은 클라우드 서비스를 제공하는 기업들은 쿠버네티스 환경이 설치되어있는 인프라를 서비스하고 있다.
    • 쿠버네티스를 별도로 설치할 필요없이 이런 서비스를 사용해도 된다.
    • 쿠버네티스가 오픈소스이기 때문에 직접 설치해서 자신의 운영 환경에 맞게 최적화 시킬 수 있다.

컨테이너의 인기 비결

컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.

  • 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
  • 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
  • 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
  • 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
  • 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
  • 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
  • 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
  • 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
  • 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
  • 자원 사용량: 리소스 사용량: 고효율 고집적.

쿠버네티스가 왜 필요하고 무엇을 할 수 있나

컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?

그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.

쿠버네티스는 다음을 제공한다.

  • 서비스 디스커버리와 로드 밸런싱 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
  • 스토리지 오케스트레이션 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
  • 자동화된 롤아웃과 롤백 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
  • 자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
  • 자동화된 복구(self-healing) 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
  • 시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

쿠버네티스가 아닌 것

쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.

쿠버네티스는:

  • 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
  • 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
  • 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
  • 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
  • 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
  • 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
  • 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

쿠버네티스 구성

  • 쿠버네티스 클러스터를 운영하는 운영자
  • 쿠버네티스 기능들을 활용해서 자신의 서비스를 배포하는 사용자

image-20210402011340560

이미지 출처

You may also enjoy