⚡ Kubernetes & MSA 3일차
📌 kubernetes
⭐ Kubernetes가 필요한 이유
🔷 대부분의 애플리케이션 : 하나의 프로세스 또는 몇 개의 서버에 분산된 프로세스로 실행되는 거대한 모놀리스
- 이러한 시스템은 릴리즈 주기가 느리고 업데이트가 자주 일어나지 않는게 특징
- 개발자는 전체 릴리즈 주기가 끝날 때 마다 전체 시스템을 패키징하고 운영팀은 이를 배포하고 모니터링한다.
- 운영팀은 하드웨어 장애가 발생하면 이를 사용 가능한 서버로 직접 마이그레이션 한다.
🔷 거대한 모놀리스 레거시 애플리케이션은 점점MSA로 더 작은 구성 요소로 세분화
- 마이크로서비스는 서로 분리돼 있기 때문에 개별적으로 개발, 배포, 업데이트, 확장 가능
- 배포 가능한 구성요소가 많아지고 데이터센터 규모가 커지면서 전체 시스템을 구성, 관리, 유지하기는 쉽지 않은 일
- 리소스 활용을 높이고 하드웨어 비용을 낮추고 각 구성요소를 배치할 위치를 파악하기에 너무어려움
- 수동으로 불가능
- 이런 구성요소를 자동으로 스케쥴링하고 구성, 관리, 장애처리를 포함하는 자동화가 필요
🔷 마이크로서비스 배포 단점
- 시스템이 소수의 구성 요소로 되어 있으면 그 구성요소를 쉽게 관리할 수 있음
- 각 구성 요소를 어디에 배포할지 결정하는 일은 선택사항이 많지 않기 때문에 간단함
- 하지만 구성 요소가 많아지면 배포 조합의 수 뿐만 아니라 구성 요소간의 상호 종속성 수가 훨씬 더 많아지므로 배포 관련 결정이 어려움
- 마이크로서비스는 여러 개가 서로 함께 작업을 수행하므로 서로를 찾아 통신해야 함
- 배포할 때 전체가 하나의 시스템처럼 동작할 수 있도록 누군가 또는 무언가 제대로 구성해야 함
- 마이크로서비스 수가 증가함에 따라 서버 장애 상황에서 시스템 운영 팀이 해야 할 일을 생각해보면, 이 구성 작업은 오류가 날 가능성이 높아짐
- 또한 마이크로서비스는 여러 프로세스와 시스템에 분산돼 있기 때문에 실행 호출을 디버깅하고 추적이 어려움
⭐ kubernetes 개념
🔷 시스템에 배포 가능한 어플리케이션 구성 요소가 많아짐에 따라 점점 관리가 어려워진다.
- 오랜 세월 구글은 Borg(이후 Omega로 바뀐 시스템)라는 시스템을 개발해 애플리케이션 개발자와 시스템 관리자가 수천 개 어플리케이션과 서비스를 관리하는데 도움을 줬다. 구글은 10 여년 간 보그와 오메가를 비밀로 유지하다가 2014년 보그, 오메가, 기타 내부 구글 시스템으로 얻은 경험으로 2014년에 kubernetes 프로젝트를 오픈소스화했다. Kubernets는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.
🔷 k8s
- k8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다.
- k8s는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다.
- 선언적 구성과 자동화를 모두 용이하게 해준다.
- 크고, 빠르게 성장하는 생태계를 가지고 있다.
- 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
📌 컨테이너(Container)
⭐ 컨테이너를 쓰는 이유
🔷 VM과 비교하여, 컨테이너의 주요 장점은 경량화와 이식성을 제공하는 추상화 레벨을 제공하는 것이다.
- 경량: 컨테이너는 시스템 OS 커널을 공유함으로써 애플리케이션마다 전체 OS 인스턴스가 필요하지 않으며, 리소스에서 컨테이너 파일의 소형화와 간편함을 제공
- 이식성 및 플랫폼 독립성: 컨테이너가 모든 종속 항목들을 자신과 함께 전달하므로, 일단 소프트웨어를 한 번만 작성하면 랩탑, 클라우드 및 온프레미스 컴퓨팅 환경에서 이를 재구성하지 않고도 바로 실행 가능
- 최신형 개발 및 아키텍처 지원: 플랫폼 간의 배치 이식성/일관성 및 소형 크기의 조합 덕분에, 컨테이너는 최신형 개발에 매우 이상적
- 활용도 향상: 이전의 VM처럼, 컨테이너를 사용하여 개발자와 운영자는 물리적 시스템의 CPU 및 메모리 활용도를 향상시킬 수 있다. 컨테이너의 보다 큰 장점은 마이크로서비스 아키텍처도 허용하므로 애플리케이션 컴포넌트를 보다 미세하게 배치 및 스케일링할 수 있다는 점이다. 이는 단일 컴포넌트의 과중한 로드로 인해 전체 모놀리식 애플리케이션을 확장해야 하는데 대한 매력적인 대안이 될 수 있다.
🔷 컨테이너는 특히 클라우드 환경에서 점점 더 두각을 나타내고 있다.
🔷 많은 기업들은 심지어 자체 애플리케이션과 워크로드에 대한 범용 컴퓨팅 플랫폼으로서 VM의 대용으로 컨테이너를 고려하고 있다. 그러나 이러한 광범위한 분야 내에서, 컨테이너가 특히 의미가 있는 주요 유스케이스가 있다.
🔷 마이크로서비스
- 컨테이너는 소형이고 경량이다. 따라서 이는 애플리케이션이 다수의 느슨하게 결합되고 독립적인 배치가 가능한 소형 서비스들로 구성되는 마이크로서비스 아키텍처에 매우 적절하다.
🔷 DevOps
- 아키텍처로서 마이크로서비스와 플랫폼으로서 컨테이너의 결합은 소프트웨어의 구축, 장착 및 실행 방안으로서 DevOps를 채택하는 많은 팀들의 공통 기반이다.
🔷 하이브리드, 멀티클라우드
- 컨테이너가 랩탑, 온프레미스 및 클라우드 환경의 어디서나 일관되게 실행될 수 있으므로, 이는 기업들이 자체 데이터 센터와 결합하여 다수의 혼합형 퍼블릭 클라우드에서 운영을 수행하는 하이브리드 클라우드 및 멀티 클라우드 시나리오의 이상적인 기반 아키텍처다.
🔷 애플리케이션 현대화 및 마이그레이션
⭐ Kubernetes의 컨테이너 오케스트레이션
🔷 기업들이 종종 최신형 클라우드 네이티브 아키텍처의 일부로서 컨테이너를 채택하기 시작하면서, 개별 컨테이너의 단순성은 분산형 시스템에서 수백 개(심지어 수천 개)의 컨테이너를 관리하는 복잡성과 충돌하기 시작했다.
- 이러한 문제를 해결하기 위해, 다음을 포함하여 해당 라이프사이클 전체에서 방대한 볼륨의 컨테이너를 관리하는 방법으로서 컨테이너 오케스트레이션이 부상하게 되었다.
1. 프로비저닝
2. 중복성(상태 모니터링)
3. 리소스 할당
4. 스케일링 및 로드 밸런싱
5. 물리적 호스트 간의 이동
📌 Kubernetes 아키텍처
🔷 하드웨어 수준에서 쿠버네티스 클러스터는 여러 노드로 구성되며, 두 가지 유형으로 나눌 수 있다.
- 마스터 노드: 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인(Control Plane)을 실행
- 워커 노드: 실제 배포되는 컨테이너 애플리케이션을 실행
⭐ Control Plane
🔷 클러스터를 제어하고 작동시킨다. 하나의 마스터 노드에서 실행하거나 여러 노드로 분할되고 복제돼 고가용성을 보장할 수 있는 여러 구성 요소로 구성된다
- 쿠버네티스 API Server: 사용자, 컨트롤 플레인 구성 요소와 통신한다
- 스케쥴러: 애플리케이션의 배포를 담당한다
- 컨트롤 매니저: 구성 요소 복제본, 워커 노드 추적, 노드 장애 처리등과 같은 클러스터단의 기능을 수행한다
- Etcd: 클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소다
⭐ Node
🔷 워커 노드는 컨테이너화된 애플리케이션을 실행하는 시스템이다. 애플리케이션을 실행하고 모니터링하며 애플리케이션에 서비스를 제공하는 작업은 다음 구성 요소에 의해 수행된다.
1. 컨테이너를 실행하는 도커 런타임
2. API 서버와 통신하고 노드의 컨테이너를 관리하는 kubelet
3. 애플리케이션 구성 요소간의 네트워크 트래픽을 로드밸런싱하는 쿠버네티스 서비스 프록시 kube-proxy
📌 Kubernetes 용어
🔷 마스터: 쿠버네티스 노드를 제어하는 머신. 여기에서 모든 태스크 할당이 시작.
🔷 노드: 할당된 태스크를 요청대로 수행하는 시스템. 쿠버네티스 마스터가 이러한 노드를 제어.
🔷 파드: 단일 노드에 배포된 하나 이상의 컨테이너 그룹. 포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유하며 포드는 기본 컨테이너에서 네트워크와 스토리지를 추상화.
💡 이렇게 하면 클러스터에서 컨테이너를 더 쉽게 이동이 가능하다.
🔷 복제 컨트롤러: 이 컨트롤러는 클러스터에서 실행되어야 하는 동일한 포드 사본의 개수를 제어
🔷 서비스: 포드에서 작업 정의를 분리한다. 쿠버네티스 서비스 프록시는 클러스터에서 다른 위치로 이동한 경우든 교체된 경우든 서비스 요청을 적절한 포드로 자동 수신한다.
🔷 Kubelet: 이 서비스는 노드에서 실행되며 컨테이너 매니페스트를 읽고, 정의된 컨테이너가 시작되어 실행중인지 확인한다.
🔷 kubectl: 쿠버네티스의 명령줄 설정 툴
📌 Kubernetes 워크로드 용어
🔷 데몬 셋
- 워크로드는 쿠버네티스에서 구동되는 애플리케이션이다. 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 파드 집합 내에서 실행한다. 쿠버네티스에서 파드는 클러스터에서 실행 중인 컨테이너 집합을 나타낸다.
🔷 디플로이먼트
- 디플로이먼트는 쿠버네티스가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다. 디플로이먼트가 만들어지면, 쿠버네티스 컨트롤 플레인이 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다.
🔷 잡
- 잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다. 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의 성공 완료에 도달하면, 작업(잡) 이 완료된다. 잡을 삭제하면 잡이 생성한 파드가 정리된다. 작업을 일시 중지하면 작업이 다시 재개될 때까지 활성 파드가 삭제된다.
📌 Minikube
🔷 Minikube는 로컬에서 쿠버네티스를 테스트하고 애플리케이션을 개발하는 목적으로 단일 노드 클러스터를 설치하는 도구이다.
- 쿠버네티스를 가장 간단하고 빠르게 접근할 수 있는 방법은 Minikube를 사용하는 것이다.
