쿠버네티스 뜨게 된 이유와 컴포넌트 정리

---

목차

1. 쿠버네티스 전에 도커 : 도커가 뜨게 된 이유

2. 도커와 쿠버네티스의 활성화

3. 쿠버네티스 컴포넌트 구성

4. 쿠버네티스 컴포넌트 - 컨트롤 플레인

5. 쿠버네티스 컴포넌트 - 노드 컴포넌트 

6. 쿠버네티스 API

 

1. 쿠버네티스 전에 도커 : 도커가 뜨게 된 이유

전통적인 배포 에서는 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에,

리소스 할당의 문제가 발생한다.

 

전통적인 물리 서버의 단점 : 호스트에도 개발환경에 필요한 설정을 똑같이 해야함.

         앞으로 나올 컨테이너 배포 구조 보다 레이어가 복잡함. 

         vm이 추가 되면 os도 하나가 추가되어야 함. 

---

도커에서 제시하는 가상화된 배포는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 하고

리소스를 보다 효율적으로 활용한다. 

각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.

 

가상화된 배포의 장점

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

 

이렇게 장점이 많은데 안쓸 이유가 있을까??

 

 

2. 도커와 쿠버네티스의 활성화

 

컨테이너가 새로운건 아니지만 도커로 인해 애플리케이션 개발 과정에 혁신을 가져왔다. 

5년전에 도커를 알았는데 이제 공부하게되었다..  ㅠㅠ 어차피 결국에 하게 될꺼 미리할껄.. 

컨테이너를 사용하지 않을때 수많은 환경과 운영의 차이 때문에 발생한 에러를 경험해본 사람은 

이게 얼마나 내 퇴근시간을 단축시켜주는지 알수 있다.

 

하지만 컨테이너만으로는 실제 서비스 운용하기는 부족하다. 

-> 쿠버네티스가 나오게 된 배경 

K8s라고도 알려진 쿠버네티스는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 

오픈소스 시스템이고 Google에서 15년간 프로덕션 워크로드 운영한 경험을 토대로 구축되었다. 

 

1. 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다

2. 서비스로 운용할때 보통 한대만 요영하지 않기 떈문에 여러대 서버 이용이 필요함. 

->  서비스 디스커버리(유레카와 같은 역할)와 로드 밸런싱  ( 네트워크 트래픽을 로드밸런싱하고 배포) 

3.  서버가 1대든 100대든 한번의 명령으로 자동배포가능 

4. 일부가 고장나면 자동화된 롤아웃과 롤백을 지원 -

->  쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.

 

쿠버네티스 공식 홈페이지에서 설명하는 장점

 

쿠버네티스 특징 3가지 

• declarative api
  컨테이너가 어떤 상태이길 원하지는만 설정하면 지속해서 컨테이서 상태를 확인해고 그 상태가 아니면 그것에 맞춤
  
  
• 워크 로드 분리
  분산시스템을 개발할 떄는 분산된 프로세스 각각이 실행이 잘되는지 이상이 생겼을떄는 어떻게 처리해야하는지 안정성 고민을 해야함.
  k8s는 운영체제 처럼 분산된 프로세스의 관리를 추상화하는 레이어가 되므로 시스템 운영에 관한 고민을 덜어줌.
  
  
• 어디서나 실행 가능

 

 

쿠버네티스 컴포넌트 구성 

 

쿠버네티스를 배포하면 클러스터를 얻는다.

쿠버네티스 클러스터는 노드의 집합. 

모든 클러스터는 최소 한 개의 워커 노드를 가진다.

파드 : 클러스터에서 실행 중인 컨테이너의 집합 

노드 : 컨테이너화된 애플리케이션을 실행하는 워커 머신의 집합. 

워커 노드 : 애플리케이션의 구성요소인 파드를 호스트한다.

컨트롤 플레인 : 워커 노드와 클러스터 내 파드를 관리한다.

 

공식 io에서 본 쿠버네티스 클러스터 구성요소

 

 

책에서 본 쿠버네티스 클러스터 구성요소

 

마스터와 컨트롤 플레인이 설명하는게 같기 때문에 같다고 생각하면 될것 같다. (이하 컨트롤 플레인)

노드에서는 kubelet, proxy, docker 가 실행된다.

 

쿠버네티스 컴포넌트 - 컨트롤 플레인 

 

컨트롤 플레인이란

• 컨테이너의 라이플사이클을 정의, 배포, 관리하기 위한 api와 인터페이스들을 노출하는
  컨테이너 오케스트레이션 레이어 
  
  
• 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동시키는 것)를 감지하고 반응한다.
  
  

 

컨트롤 플레인 컴포넌트 

• etcd : 고가용성을 제공하는 key - value 저장소, 쿠버네티스에서 필요한 데이터를 저장하는 db 역할
  
  
• kube-apiserver :  쿠버네티스 클러스터의 api를 사용할수 있도록 하는 컴포넌트, 요청이 유효한지 검증
  
  
• kube-scheduler :  노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컴포넌트.
  클러스터 안에서 자원 할당이 가능한 노드중 알맞은 노드를 선택해서 새롭게 만든 파드를 실행
  
  
• kube-controller-manager : 파드들을 관리하는 컨트롤러가 있는데, 이 컨트롤러 각각을 실행하는 컴포넌트.
  
  
• cloud-controller-manager : 쿠베 컨트롤러들을 클라우드 서비스와 연결해 관리하는 컴포넌트

---

컨트롤러 : api 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프 

 

쿠버네티스 컴포넌트 - 노드 컴포넌트

 

노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다.

• kubelet -  클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 스펙 조건 담긴 설정을 전달 받아 컨터이너 실행하고 정상적으로 실행되는지 헬스체크 진행
  
  
• kube-proxy - 쿠버네티스는 클러스터 안 별도의 가상 네트워크를 설정 하고 관리한다.
  kube-proxy는 가상 네트워크 동작을 관리하는 컴포넌트이다.
  
  
• 컨테이너 런타임 -  컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.
  주로 docker를 많이 사용한다. Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어등등 이 있음. (애드온, dns, 웹 UI , 컨테이너 리소스 모니터링, 클러스터-레벨 로깅)

 

쿠버네티스 API

쿠버네티스 컨트롤 플레인의 핵심은 API 서버(쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트)이다. 
API 서버는 최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API를 제공한다.  


쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예: 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.


 kubectl 커맨드 라인 인터페이스 또는 API를 사용하는 kubeadm과 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다. 

---

 

 

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