컨테이너 개발 환경의 등장 배경과 쿠버네티스

등장 배경

https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

 

 

https://samsungsds.com/kr/story/220222_kubernetes1.html

 

개발 & 배포 환경의 변화

1. 전통적인 배포 시대(Traditional Deployment)

• 물리 서버 위에서 애플리케이션을 운영
• 물리 서버에서는 애플리케이션들 사이에 리소스 경계를 정의할 방법이 없었고, 이로 인해 리소스 할당 문제가 발생
• 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 대부분을 차지하는 애플리케이션 때문에 다른 애플리케이션 성능이 저하
• 애플리케이션 마다 서로 다른 물리 서버를 사용하는 방법도 있지만 많은 비용이 발생함

2. 가상화된 배포 시대

• 가상화의 도입
• 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행
• VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공
• 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트
• 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공
• 각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신

3. 컨테이너 개발 시대

• VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유, 컨테이너는 가볍다
• VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다
• 본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식 가능

 

그 밖의 컨테이너의 장점

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

 

쿠버네티스란 무엇인가?

쿠버네티스(Kubernetes, k8s)는 컨테이너화된 프로세스를 관리하기 위한 컨테이너 오케스트레이션 플랫폼

쿠버네티스의 장점

• 서비스 배포, 운영에 필요한 대부분의 오케스트레이션 기능을 지원
• 스케줄링
• 정상/비정상 상태 체크 및 재기동
• 컨테이너 리소스 모니터링
• 컨테이너 동적으로 삭제 관리

 

컨테이너 오케스트레이션이란?

• 여러 서버에 걸친 컨테이너의 전반적인 라이프사이클을 관리하는 것
• 여러 서버(노드)에 컨테이너를 분산해서 배치
• 문제가 생긴 컨테이너를 교체
• 컨테이너가 사용할 비밀번호나 환경 설정을 관리하고 주입

 

쿠버네티스 구성 요소

• 클러스터는 하나의 마스터 노드와 여러 노드로 이루어져 있다
• 쿠버네티스 오브젝트
  • 상태를 관리하기 위한 대상
  • 오브젝트와 컨트롤러로 구성됨

오브젝트의 종류

• Pod
  
  • 가장 기본적인 배포 단위
  • 컨테이너를 포함한 단위
  • 1개 이상의 컨테이너로 구성
  • Pod 내 컨테이너 간에는 IP와 Port를 공유한다
    • 2개의 컨테이너가 하나의 Pod으로 배포됐을 때, Localhost로 서로 통신 가능
  • 쿠버네티스는 컨테이너 하나씩 배포하는 것이 아닌 Pod의 단위로 배포함
• Volume
  
  • 컨테이너의 외장 디스크
  • 컨테이너 restart와 상관없이 파일을 영속적으로 저장해야 하는 경우 사용
• Service
  • Pod은 컨트롤러에 의해 관리되기 때문에 클러스터 내를 옮겨 다님
  • Pod이 클러스터의 어디에 있든지 고정된 주소를 이용해 접근 가능
  • 여러 개의 Pod들을 서비스할 때, 현재 요청이 어느 Pod으로 갈지 선택하는 오브젝트
  • 부하가 많을 때 이를 분산시키는 로드밸런서 역할
• 네임스페이스
  • 한클러스터 내에 논리적인 분리 단위
  • 네임스페이스 별로 자원들을 나누어 관리할 수 있고, 접근권한, 리소스 할당량 등을 정할 수 있음

컨트롤러

• Controller
  • 여러 개의 Pod 배포를 적절하게 관리하는 오브젝트
  • ReplicaSet, Deployment 등이 컨트롤러에 속함
  • ReplicaSet
    • 똑같은 정의를 갖는 Pod을 여러개 복제하여 관리하기 위한 리소스
  • Deployment
    • ReplicaSet보다 상위의 개념으로, ReplicaSet 배포의 기본 단위가 되는 리소스
    • Pod 배포를 위해 ReplicaSet을 생성하고 관리하는 역할, 롤백을 위한 기존 버전의 ReplicaSet 관리 등의 여러 기능

그외

• 라벨
  • 리소스를 선택하는데 사용되는 메타데이터

 

쿠버네티스 아키텍처

1. 마스터 노드

• 쿠버네티스 클러스터 전체를 컨트롤 하는 시스템
• 구성
  • API 서버
    • 모든 요청을 처리하는 마스터의 핵심 모듈
    • RESTful API 제공
  • Etcd
    • 분산형 Key-Value 스토어, 여러 개로 분산하여 복제할 수 있음
    • 쿠버네티스 클러스터 상태나 설정 정보 저장
    • 상태 변화를 체크하여 로직을 실행할 수도 있다
  • 스케줄러
    • Pod, Service 등의 각 리소스를 적절한 노드에 할당
  • 컨트롤러 매니저
    • kube-controller-manager와 cloud-controller-manager로 나뉨
    • kube-controller-manager
      
      • 쿠버네티스에 있는 거의 모든 오브젝트의 상태를 관리
      • 오브젝트별로 분업화하여 Deployment는 ReplicaSet 생성, ReplicaSet은 Pod 생성, Pod는 스케줄러가 관리
    •  cloud-controller-manager
      • AWS, GCE, Azure 등 클라우드에 특화된 모듈
  • DNS
    • 동적으로 생성되는 Pod, Service 등의 IP를 담는 DNS

2. 노드

• kubelet
  • 노드에 할당된 Pod의 생명주기를 관리
• kube-proxy
  • 각 노드에서 실행되는 네트워크 프록시
  • Pod으로 연결되는 네트워크를 관리
  • 로드밸런싱을 제공하고, 단지 서비스에 도달하는데 사용

 

참고자료

https://dalsacoo-log.tistory.com/entry/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-Kubernetes

쿠버네티스 (Kubernetes) 한번에 정리하기