쿠버네티스란?
패러다임의 전환 : 모놀리스 레거시 -> 마이크로 서비스로 발전 되면서..
- 작은 구성 요소로 개별 개발,배포,업데이트,확장 가능해짐
- 배포 가능한 구성요소가 많아지며 전체 요소들을 구성, 관리, 유지하는 일이 어려워짐
- 리소스 사용률을 높이고 구성요소를 적재적소에 배치하는 것을 자동으로 해주는게 필요함
-> 쿠버네티스 (오케스트레이션!) 등장이유
쿠버네티스는 이런 것들을 해줘요!
- 하드웨어 인프라 추상화
- 개발자가 세세한 서버 하드웨어에 대한 정보 몰라도 어플리케이션 구성요소를 배포하고 실행할 수 있음
- 구성요소가 많아지며 뭐를 어디에 배포할지 정하는 경우의 수 많아짐, 복잡. 구성 요소간 상호 종속성 수가 많아져 결국 배포 결정이 어려움 -> 쉽고 편하게 배포할 구성요소를 선택하고 배포할 수 있게 해줌.
- 구성요소간 쉽게 찾고 통신할 수 있게 해줌 -> 마이크로 서비스는 일반적으로 RESTful API 를 제공하는 HTTP 로 통신한다
- 실행호출을 디버그하고 추적하기 어려움 -> 시스템 전체가 하나의 시스템으로 동작할 수 있게 해줌
쿠버네티스를 쓰면 뭐가 좋아져?
어플리케이션에 일관된 환경 제공
- 개발환경 / 운영환경이 다르면 문제가 생길 수 있다
- 쿠버네티스를 이용하면 환경 그대로를 본 떠 이식할 수 있다
- 환경 : 운영체제, 라이브러리, 시스템 구성, 네트워킹 환경 등
지속적 배포 : 데브옵스, 노옵스
- 개발하고 프로덕션에서 어플리케이션 배포하는 과정과 관리하는 방식이 바뀌었다
- 노옵스 : 하드웨어 인프라를 전혀 알지 못하더라도 운영 팀을 거치지 않고 개발자가 어플리케이션을 직접 배포하는 방식
- 쿠버네티스는 하드웨어를 추상화하고 어플리케이션 배포, 실행을 위한 플랫폼으로 제공한다
컨테이너 기술 소개
쿠버네티스는 '어플리케이션 격리'를 위해 리눅스 컨테이너 기술을 사용함
도커와 같은 컨테이너 기술이 어떤 문제를 해결하기 위해 나왔는지 알 필요가 있다
동일한 머신에서 실행되는 서로 다른 SW 가 각자 가진 종속 라이브러리 버전을 관리하려면 어떻게 해야하나?
-> 전용 가상머신을 제공하고 고유의 OS 를 제공하여 환경을 격리하면 된다.
이를 하드웨어 리소스를 낭비하지 않으며 해야한다.
가상머신은 리소스 낭비가 심하다 -> 컨테이너 기술을 사용하자
- 동일 호스트 시스템에서 여러 서비스 실행
- 오버헤드가 가상머신보다 적다
컨테이너와 가상머신 기술 비교
가상머신보다 컨테이너가 가볍고 효율적
가상머신
- 각자 GUEST OS 를 가지고 있다. 각자 커널을 가지고 있다. 그렇기 때문에 구성 요소 프로세스 뿐 아니라 시스템 프로세스를 실행해야함
- 어플리케이션이 시스템 콜 수행하면 게스트 OS 통해 커널은 하이퍼바이저로 호스트의 물리적 CPU 에서 명령 수행
컨테이너
- HOST OS 위에서 실행되는 하나의 격리된 프로세스일 뿐. 시스템 프로세스 실행의 오버헤드가 없다
- 어플리케이션이 시스템 콜 수행하면 HOST OS에서 실행되는 커널에 시스템 콜 수행됨
컨테이너 격리를 가능케 하는 메커니즘
- 리눅스 네임 스페이스 (namespace)
- 리눅스 컨트롤 그룹 (cgroups)
리눅스 네임스페이스 (namespace)
각 프로세스가 시스템에 대한 독립된 뷰만 볼수 있도록 함
- 시스템 : 파일, 프로세스, 네트워크 인터페이스, 호스트 이름 등
프로세스는 자신이 속한 동일 네임스페이스들 안에 있는 리소스만 볼 수 있다
한 프로세스는 여러 네임스페이스에 속할 수 있다
네임스페이스 종류
- mnt : 마운트
- pid : 프로세스 id
- net : 네트워크
- ipc : 프로세스 간 통신
- uts : 호스트와 도메인 이름
- user : 사용자 id
각 네임스페이스는 특정 리소스 그룹을 격리하는 데 사용
각 컨테이너는 자신이 속한 고유한 네트워크 네임스페이스들을 사용하므로 고유한 네트워크 인터페이스 세트에 속한 리소스만 볼 수 있다
리눅스 컨트롤 그룹 (cgroups)
각 프로세스가 사용할 수 있는 리소스의 양을 제한
- 리소스 : CPU, 메모리, 디스크, 네트워크 대역폭 등
컨테이너가 사용할 수 있는 시스템의 리소스 양을 제한
프로세스 (컨테이너)는 설정된 양 이상의 CPU, 메모리, 네트워크 대역폭등을 사용할 수 없다
도커 소개
도커는 컨테이너를 여러 시스템에 쉽게 이식 가능케 하는 시스템, 도구
어플리케이션을 패키징, 배포, 실행하기 위한 플랫폼
어플리케이션 뿐 아니라 라이브러리, 운영체제의 파일시스템 까지도 도커를 실행하는 컴퓨터에 어플리케이션을 프로비저닝하는 데 사용할 수 있음
간편하게 이식 가능한 패키지로 패키징 하는 과정을 단순화 했음
EX) RHEL OS 전체 파일과 함께 어플리케이션을 패키징 한 경우, 다른 OS 서버에서 실행되더라도 어플리케이션은 항상 RHEL 에서 실행된다고 생각됨. 커널만 다를 뿐.
가상머신에 OS 설치 후 그 안에 어플리케이션 설치하고 이미지 배포하고 실행하는 것과 유사 (큰 모놀리스 가상 머신 이미지를 사용)
이에 비해 도커는 훨씬 가벼운 컨테이너 이미지를 사용
컨테이너 이미지는 여러 이미지에서 공유되고 재사용될 수 있는 레이어로 구성되어 있다는 점이 중요
* 가상머신과의 차이점 잘 모르겠네..
도커 이미지
어플리케이션과 해당 환경을 패키지화한 것
도커를 통해 생성한다
도커 레지스트리
도커 이미지를 저장하고 공유할 수 있는 저장소
푸시 -> 풀 하면서 사용한다
도커 컨테이너
이미지에서 생성된 일반적인 리눅스 컨테이너
도커를 실행하는 호스트에서 실행되는 프로세스. 호스트와 호스트에서 실행중인 다른 프로세스와 완전히 격리
쿠버네티스와 컨테이너
쿠버네티스 : 컨테이너화된 어플리케이션을 배포, 관리할 수 있게 해주는 SW
리눅스 컨테이너 기능에 의존해 어플리케이션 내부 세부사항을 몰라도 이기종 어플리케이션을 쉽게 실행할 수 있음
호스팅된 어플리케이션을 완전히 격리하면서 하드웨어를 최대한 효율적으로 사용함
기본 인프라를 추상화하여 개발, 운영, 배포, 관리를 단순화함
전체 데이터 센터를 하나의 배포 플랫폼으로 제공한다.
마스터 노드와 여러 워커노드로 구성
개발자가 어플리케이션 매니페스트를 마스터에 게시 -> 어플리케이션을 워커 노드 클러스터에 배포
스케줄링, 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더선출 등의 기능을 제공한다
쿠버네티스 클러스터 아키텍처 이해
구성요소
1. 마스터 노드
2. 워커 노드
마스터 노드
전체 쿠버네티스 시스템 제어하고 관리
컨트롤 플레인을 실행
컨트롤 플레인 이란?
클러스터를 제어하고 작동시킴
마스터 노드에서 실행됨
- 쿠버네티스 API : 사용자, 컨트롤 플레인 구성요소와 통신
- 스케줄러 : 어플리케이션 배포 담당 (배포 가능한 구성요소를 워커노드에 할당)
- 컨트롤러 매니저 : 구성요소 복제본, 워커 노드 추적, 노드 장애 처리와 같은 클러스터 단의 기능 수행
- Etcd : '클러스터 구성'을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소
워커 노드
실제 배포되는 컨테이너 어플리케이션을 실행
그림 1.9
노드
워커 노드는 컨테이너화된 어플리케이션을 실행하고 모니터링하는 시스템
- 컨테이너 런타임 : 도커, rkt
- Kubelet : API 서버와 통신, 노드의 컨테이너 관리
- Kube-proxy : 어플리케이션 구성요소 간 네트워크 트래픽 로드밸런싱 (서비스 프록시)
쿠버네티스에서 어플리케이션 실행
어플리케이션 디스크립션
- API 서버에 게시
- 컨테이너 이미지, 구성요소간 통신방법, 동일 서버에 배치해야할 구성요소 정보, 구성요소의 복제본 수, IP 주소등 네트워크 정보
디스크립션이 제출되면 쿠버네티스의 각 구성요소는 무얼하나?
스케줄러 : 각 컨테이너에 필요한 리소스 계싼, 워커노드에 컨테이너 할당
Kubelet : 도커를 이용해 컨테이너 이미지 가져오고 컨테이너 실행
쿠버네티스는 어플리케이션 배포 상태가 디스크립션과 일치하는지 지속적으로 확인.
일치하지 않으면 일치하는 상태로 만든다
클러스터간 어플리케이션을 이동시키고 배치시키는 걸 자동으로 해준다 -> 이는 사람이 수동으로 하는 것보다 리소스활용 최적화를 잘해줌
