1. 쿠버네티스에 관하여

서용준·2024년 5월 9일

쿠버네티스

목록 보기
3/4

Kubernetes의 기원(?)

출처 : https://www.openmaru.io/구글-과-컨테이너-기술-그리고-쿠버네티스/

  • 구글에서 개발한 최초의 통합 컨테이너 관리시스템 - Borg
    • 구글에서 개발한 최초의 통합 컨테이너 관리 시스템은 Borg라는 이름의 시스템이었다.
    • Borg는 리소스 활용도를 높이고 비용을 절감하는 방법으로 서로 다른 애플리케이션간에 시스템을 공유한다.
    • 이러한 공유는 Linux 커널에서 컨테이너을 이용하여 지연 시간에 민감한 사용자 서비스와 CPU를 많이 사용하는 일괄 처리 사이의 분리를 통해 자원 효율성을 향상 시켰기 때문에 가능했다.
  • 공유 상태 방식을 자원 할당 스케줄링 – OMEGA
    • Google 은 Borg 다음으로 공유 상태  모델에 의한 스케줄링 우선 순위를 가진 선점과 경쟁을 통한 스케줄링을 가능하게 합니다.
    • 공유 상태 모델의 주요 목적이 Scalability보다는 오히려 소프트웨어 개발의 유연성에 두고 있습니다.
  • 자원할당을 위한 스케쥴링 방식 비교 – Monolithic, Two-level, Shared-state
    • Monolithic 방식은 클러스터 내에 단일 스케줄러가 존재하며 복수개의 프레임워크에 대한 스케줄링을 지원한다. 이 경우 스케줄러 내에서 각 프레임워크에 특화된 스케줄링 로직 때문에 지원할 수 있는 프레임워크를 추가하기 어렵다.
    • 또한 단일 스케줄러라는 특징 때문에 대기중인 다른 작업들이 한 작업의 스케줄링 시간 동안 지연되느 Head-Of-Line Blocking 문제가 있다.
    • 반면 Two-Level 방식은 전체 클러스터 내에서 동작하는 다수의 스케줄러를 배치하고 이들을 조정하는 단일 중앙 조정자 (Central Coordinator)를 둔다. 그러나 이경우에는 단일한 중앙 조정자가 스케줄링의 병목 지점이 되는 문제가 존재한다.
    • 공유 상태 (Shared-State) 방식은 각 클러스터의 스케줄러에서 클러스터 전테 상태의 동기화가 이루어진다. 이 특징으로 인해 클러스터의 크기와 스케줄러 수에 비례하여 각 스케줄러에 동기화로 가해지는 부하와 지연이 증가하는 문제가 있다.
  • Google 에서 만든 오픈소스 클라우드 플랫폼 – Kubernetes
    • Kubernetes ( 쿠버네티스 ) 는 컨테이너화된 애플리케이션(Containerized Application)의 배포, 확장 그리고 관리를 할 수 있는 오픈 소스 컨테이너 오케스트레이션 시스템이다.
    • 쿠버네티스는 구글 엔지니어들이 개발하고 설계한 플랫폼으로서 수 년 전부터 내부에서 이용하던 컨테이너 클러스터 관리 도구인  “Borg” 와 ” Omega” 의 아이디어를 바탕으로 만들어진 오픈소스 소프트웨어이다.
    • 쿠버네티스는 2014 년 6 월에 시작하여 2015 년 7 월에 버전 1.0을 발표하였고, 현재에는  구글, 아마존, 애저 등 주요 클라우드 벤더와 Red Hat, IBM , Oracle 과 같은 소프트웨어 벤더 들이 각자의 브랜드로 Kubernetes 배포판을 제공하고 있다.
  • 구글과 컨테이너 기술
    • 컨테이너가 제공하는 리소스에 대한 고립 덕분에 Google은 업계 표준보다 훨씬 높은 서버 활용도를 높일 수 있었다.
  • 애플리케이션 지향 인프라스트럭처
    • 컨테이너화는 데이터 센터를 머신 지향에서 애플리케이션 지향으로 변화시킨다.
    • 잘 설계된 컨테이너와 컨테이너 이미지는 단일 애플리케이션으로 범위가 지정되기 때문에 컨테이너 관리는 머신이 아닌 애플리케이션 관리를 의미한다.
    • 컨테이너는 애플리케이션 환경을 캡슐화하여 애플리케이션 개발자 및 배포 인프라로부터 머신 및 운영 체제의 많은 세부 정보를 추상화한다.
    • 머신 지향에서 애플리케이션 지향으로의 전환은 애플리케이션 배포 및 인트로스펙션 (Introspection) 를 크게 향상시킨다.
  • 애플리케이션 지향 인프라 장점
    1. 애플리케이션 개발자와 운영 팀이 서버와 운영 체제에 대한 세부 사항에 대해 고려하지 않아도 된다.
    2. 실행중인 애플리케이션과 개발자에 미치는 영향을 최소화하면서 새로운 하드웨어를 출시하고 운영 체제를 업그레이드 할 수있는 인프라 팀의 유연성을 제공한다.
    3. 관리 시스템에서 수집한 메트릭 정보(예 : CPU 및 메모리 사용량과 같은 메트릭)을 머신뿐만 아니라 애플리케이션에 연결하여 특히 스케일 업, 머신 장애 또는 유지 보수로 인해 애플리케이션 인스턴스가 발생할 때 애플리케이션 모니터링 할 수 있다.
  • 구글은 컨테이너 관리 시스템을 구축 한 10 년의 경험을 통해 많은 것을 배웠으며 이러한 교훈을 Google의 최신 컨테이너 관리 시스템 인 Kubernetes에 포함시켰다.
  • 그 목표는 컨테이너의 기능을 기반으로 프로그래머 생산성을 크게 향상시키고 수동 및 자동 시스템 관리의 용이성을 제공하는 것이다.

CNCF (Cloud Native Computing Foundation)란?

출처 : https://www.cncf.io/about/who-we-are/

  • CNCF는 글로벌 기술 인프라의 중요한 구성 요소를 호스팅한다.
    • 세계 최고의 개발자, 최종 사용자 및 공급업체를 모아 최대 규모의 오픈 소스 개발자 컨퍼런스를 운영.
    • 비영리 Linux Foundation의 일부.
  • 클라우드 네이티브란?
    • 컴퓨팅 환경에서 현대적 애플리케이션을 구축, 배포 및 관리할 때의 소프트웨어 접근 방식.
    • 현대적인 회사는 고객의 요구를 충족하기 위해 신속하게 업데이트할 수 있는 확장성, 유연성 및 복원력이 뛰어난 애플리케이션을 구축하려 함. 이를 위해 클라우드 인프라에서 애플리케이션 개발을 기본적으로 지원하는 현대적인 도구와 기술을 사용. ⇒ 이러한 클라우드 네이티브 기술은 서비스 제공에 미치는 영향 없이 애플리케이션을 빠르게 자주 변경할 수 있도록 지원하여 혁신 역량과 경쟁력 제공.

Kubernetes 는 기능이 어떤 것들이 있을까?

기본적으로 Kubernetes 는 컨테이너 이미지를 실행시키는 등 관리하는 역할 수행

출처 : https://kubernetes.io/ko/docs/concepts/overview/

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

0개의 댓글