GCP34 :: 쿠버네티스 정리

✓. 쿠버네티스
⇢ 컨테이너 기반의 환경은 배포에 강점이 있습니다. 또, 마이크로 서비스 아키텍쳐 구조에 잘 맞습니다. 컨테이너 운영환경입니다.
⇢ 클러스터 이해를 선행해야 합니다. 컨트롤러로써 마스터가 존재하고 컨테이너가 배포되는 머신(가상머신 이나 물리적인 서버머신) 노드가 존재된다. 

✓. Pod
⇢ 쿠버네티스에서 가장 기본적인 배포 단위, 컨테이너를 포함하는 단위이다. 
⇢ 컨테이너를 개별적으로 하나씩 배포하지 않고 Pod 라는 단위로 배포(Pod, 하나 이상의 컨테이너 포함)
⇢ 컨테이너는 IP와 Port를 공유합니다. 


✓. Vargant 
⇢ 설정 스크립트 기반으로 특정 환경의 가상 머신을 만들어서 신속하게 개발 환경 구축

✓. 마이크로 서비스 아키텍처 
⇢ 1~2코어로도 운영할 수 있기 때문에 작은 서비스를 VM 환경으로 운영하기에 낭비가 심해집니다. VM이나 컨테이너 단위로 배포하는 피닉스 서버 패턴, Spinnaker 솔루션 제공 그리고 이를 중앙에서 통제하기 위해 서비스 메쉬 솔루션이 나옵니다. 
⇢ 각각의 메모리 머신들이 다른 컨테이너를 배포할때 컨테이너 사이즈가 CPU 크기 별로 다를 수 있기 때문에 자원을 최적으로 사용하기 위해서 적절한 서버에 배포되어야 하는데 컨테이너를 적절한 서버에 배포해주는 역할을 스케쥴링입니다.

✓. 도커 
⇢ VM올린 후에 쿠버네티스 배포하는 구조를 갖습니다. (=하드웨어 자원 활용의 효율성)
⇢ 도커가 컨테이너 엔진중 하나 입니다. 컨테이너 환경은 하드웨어 자원을 컨테이너화하여 isolation 하는 기능입니다. 가상화 환경은 isolation 기능이 있지만 가상화를 통해 자원(CPU 수)를 늘릴 수 있습니다. 
⇢ 8CPU 머신을 쿠버네티스 관리 운영하면 오직 8CPU사용할 수 있지만, 가상화 환경을 중간에 끼면 가상화해서 2배해서 가상화 하여 자원을 나눠서 사용할 수 있습니다.
⇢ Guest OS를 Isolation 해줍니다.

✓. 서비스 배포해보기
⇢ node.js 간단한 웹 서버 만들어서 도커 컨테이너로 패키징 
⇢ 설정파일을 만든 후에 도커 컨테이너 파일을 만들기
⇢ 컨테이너 이미지를 생성하고 로컬 환경에서 실행
⇢ 빌드된 컨테이너 이미지를 구글 클라우드 컨테이너 레지스트리에 업로드
⇢ 쿠버네티스에 배포하기 위해 쿠버네티스 클러스터 준비
⇢ 도커 이미지를 패키징해서 쿠버네티스 클러스테 배포(도커 이미지를 구글 클라우드내에 도커 컨테이너 레지스트리에 등록하게 되면 이미지를 이용해 replicationController 로 3개의 Pod를 구성하고 서비스를 만들고 이 Pod들의 외부 IP를 사용해 서비스를 제공합니다.)
⇢ Pod의 경우 지정되는 IP가 랜덤하게 지정되고 리스타트 될때 변하기 때문에 고정된 엔드포인트 호출이 어렵다. Pod간의 로드밸런싱 지원해야 하는데 서비스가 이런 역할 수항

✓. 서비스
⇢ 서비스는 지정된 IP생성, 여러 Pod 묶어 로드밸런싱 가능하고 고유한 DNS이름을 가질 수 있습니다. 
⇢ 멀티포트 지원 (HTTP, HTTPS)

✓. 롤링업데이트
⇢ 블루/그린, 카날리 배포, 롤링 업데이트
⇢ 새 버전을 배포하면 새 버전 인스턴스는 하나씩 늘려가고 기존 버전을 하나씩 줄여준다. 

✓. 쿠버네티스 모니터링
⇢ 운영 관점에서 중요한것은 시스템에 대한 모니터링(호스트(노드), 컨테이너, 애플리케이션, 쿠버네티스)

✓. 인증(Authentication)
⇢ 쿠버네티스 계정 체계를 관리하는데 있어서 사용자 어카운트, 서비스 어카운트 두가지 개념 제공, 
⇢ [ 사용자 어카운트 ] : 별도의 외부 계정 시스템을 이용해서 인증해야 합니다. OAuth, Webhook 계정 연동 방식 지원
⇢ [ 서비스 어카운트 ] : 쿠버네티스 API를 호출할때 실제 사람이 아니라 시스템이 되어서 일반 사용자와 분리해서 관리하는것을 서비스 어카운트

✓. 모노리틱 아키텍처 vs 마이크로 서비스 아키텍처
⇢ [ 모노리틱 아키텍처 ] : 애플리케이션이 하나의 서버에 배포 되고, 데이타 베이스도 마찬가지로 하나의 DB에 모든 데이터를 저장합니다. 
⇢ [ 마이크로 서비스 아키텍처 ] : MSA, 비지니스 기능 마다 애플리케이션 서버, DB 분리하는 방식입니다. 각 조직에 서비스 기획, 개발, 운영에 대한 독립적인 권한을 부여합니다. 의존성이 없이 개발할 수 있는것, 같은 기술 사용할때 프레임웍이나 코드 표준화 개발 프로세스 표준화 등에서 어려움이 있습니다. 

✓. devOps 
⇢ 운영과 개발을 한팀에서 하는 모델, 두 영역간의 간극을 해결하고 개발된 시스템을 빠르게 배포하고 운영 과정에서 얻은 노하우를 개발에 반영해서 시장 요구 사항에 빠르게 반응하는데 목적이 있습니다. 
⇢ 벤더 종속적이지 않고, 개발자가 손쉽게 운영 및 접근할 수 있는 인프라 관리 기술이 요구되는데 이러한 기술로 가장 많이 언급되는것이 컨테이너 입니다. 

✓. 서비스매쉬
⇢ 마이크로 서비스 아키텍처 장점도 있지만 기능을 서비스 단위로 나눠서 서비스 간의 연결이 복잡해지면 문제가 발생합니다. 또한 문제를 추적하기 어렵다. 장애 전파 현상을 해결하기 위해서 써킷 브레이커 패턴(중간에 Bypass traffic 을 둬서 네트워크 트래픽을 통과 시키고 서비스에 장애가 나거나 응답이 없으면 그 네트워크를 끊어서 다른 한편의 서비스 에러를 바로 받도록 합니다.) 
⇢ 이를 인프라 측면에서 해결하기 위해서 서비스 매쉬 아키텍처 컨셉이 존재합니다. 서비스 마다 프록시를 넣는다. 서비스 수에 따라 프록시 수도 증가하지만 프록시에 대한 설정이 어려워지기 때문에 각 프록시에 대한 설정 정보를 중앙 집중화된 컨트롤러를 통제하는 구조를 가질 수 있습니다. 

✓. argo
⇢ 컨테이너 워크플로우 솔루션 입니다. 
⇢ 빅데이터 분석, CI/CD, 머신러닝 파이프라인을 만들때 유용하게 사용할 수 있는 오픈 소스 솔루션 
⇢ 워크플로우 각각의 스텝을 컨테이너로 정의, YAML 정의하면 실행할 때마다 컨테이너를 생성하면 작업을 수행합니다. 
⇢ Workflow spec(YAML) 을 제출 시 Kubernetes 위에 Argo 작업을 수행할 수 있습니다. 

✓. knative
⇢ 구글에서 주도하는 오픈소스 기반의 서버리스 솔루션으로 쿠버네티스 위에도 실행됩니다. 
⇢ 특정 클라우드 종속성이 없고, On-premise 설치 가능합니다. 
⇢ 스테이리스 웹 서비스 뿐만 아니고, 큐에서 이벤트 받아서 처리할 수 있는 이벤트 핸들링 위한 서버리스 모델 지원, 여기에서 컨테이너 빌딩할 수 있는 빌드 기능 제공
⇢ [ serving ] : 무상태 웹서비스 구축하기 위한 프레임워크로 간단하게 웹서비스 컨테이너 배포하게 되면 로드밸런서 배치, 오토 스케일링, 복잡한 배포(롤링/카날리) 지원합니다. 또, 서비스 매쉬 솔루션인 istio 통합과 함께 여러 모니터링을 제공합니다. 

✓. Helm 
⇢ 리눅스의 apt툴, node.js의 npm과 같이 쿠버네티스용 패키지 매니지먼트 도구입니다. 처음부터 모든것을 설치해야 하고 반복적인 작업의 경우에 배포 도구로는 다소 어려움이 따릅니다. 따라서, Helm으로 애플리케이션 컨테이너 배포는 물론 쿠버네티스 리소스 모두 배포해주는 역할을 수행하는데 이 배포를 패키지 형태로 하게 됩니다. (Infrastructure as a code (이하 IaaC)를 구현하는 Terraform + 패키지 매니저인 npm)

*ref : https://bcho.tistory.com/1255?category=731548(조대협님 블로그)

https://www.lesstif.com/laravelprog/vagrant-24445417.html