컨테이너 가상화 방식에서, 어플리케이션 방법, 서버가상화, 전통적인 방법에 의해 배포하는 방식에 대한 차이점

1. 전통적 방식
   하나의 물리적인 서버가 가지고 있는 리소스를 여러 가지 애플리케이션이 공유해서 사용하는 개념, 특정 어플리케이션에서 리소스를 많이 점유하고 사용하게 되면 다른 어플리케이션은 상대적으로 성능이 떨어진다

2. 서버 가상화 기술
   물리적인 하드웨어 위에 OS, 그 위에 Hypervisor 기술로 각각의 VM에 개별적인 운영체제를 넣을 수 있었다. VM간에 독립적으로 운영 가능해서 보안도 좋았다. 하지만 이 방식은 궁극적으로 하드웨어 리소스를 쪼개서 VM들이 사용하는거여서, VM이 늘어날 수록 서버에 부담이 컸다

3. 컨테이너 가상화
   VM과 유사하지만, 격리면에서 완화하여, 어플리케이션간 운영체제를 서로 공유할 수 있도록 하는 가상화 기술, 운영체제에 필요한 리소스를 서비스간 서로 공유함으로써 컨테이너 가상화 기술은, 서버 가상화에 비해 훨씬 가볍게 어플리케이션을 운영할 수 있게 되었다. 무엇보다 인프라 종속성을 분리가 가능해서, 다양한 클라우드에 이식하여 운영 가능

   Cloud Native Architecture
   MSA
   CI/CD
   DEVOPS -> 개발에 대한 사이클을 지속적으로 반복하는 환경 구축
   컨테이너 가상화 -> 서비가 운영될 수 있는 클라우드 환경의 리소스를 사용할 수 있음

컨테이너 환경에서 마이크로서비스아키텍처에 대한 어플리케이션 개발하고, 어떻게 설계하고, 어떤 기술을 사용해야하는지에 대해, CNCF라는 조직이 있다

쿠버네티스는 컨테이너 가상화 기술을 사용하기위한 컨테이너화 되어 있는 서비스/패키지를 위해 다양한 자동 배포/스케일링 작업을 제공해주는 관리 플랫폼이다

쿠버네티스는 도커같은 컨테이너 엔진 자체를 대체할 수 있는건 아니다

Kubernetes

장단점

Kubernetes Cluster

Masternode : 설정정보, 스케줄관리, API 처리
Node : 운영하고자 하는 컨테이너를 관리하기 위한 Pod, Pod를 운영하기 위한 Kubelet이라는 개념 포함되어 있음

개발자가 UI/CLI로 API 사용하여 명령어 사용, Kube Proxy가 명령어 받음
이 Kube Proxy는 각 클러스터 노드에서 실행되고 있는 네트워크 프록시임(쿠버네티스 서비스 개념), 네트워크에 대한 유지 관리 함
네트워크에 대한 규칙이 외부에 있는 네트워크 세션이나, 클러스터 밖에서 pod 형태로 사용할 수 있도록 하는 것도 kube proxy 역할

이후 사용자들은 Kubernetes 노드에 붙어서 원했던 서비스나 어플리케이션을 사용할 수 있음

Kubernetes work

마스터에서 가용 가능한 노드에 명령어를 전달
사용할 수 있는 컨테이너를 pod형태로 묶어서 사용
쿠버네티스의 사용 가능한 최소 단위를 Pod라는 형태로 묶어서 배포

여러가지 컨테이너 묶임 -> Pod

각각의 노드들은 컨테이너 엔진 가지고 있음

멀티 노드 쿠버네티스 클러스터로 안정적으로 운영

Service, Pod -> 쿠버네티스가 사용할 수 있는 오브젝트/리소스

Service : Pod간 데이터 주고 받을 수 있는 네트워크 관련 작업 해줌
Pod : 컨테이너들이 패키징되어 있는 형태

CI/CD를 활용해 쿠버네티스로 배포한다?
컨테이너 배포 -> 파드로 감싸서 배포 -> 결과물을 외부에서 사용할 수 있도록 서비스 오브젝트를 붙여서 사용할 수 있도록 한다

목표

CI/CD 파이프라인 연결 과정에서, 쿠버네티스 마스터 노드에다 데이터 요청을 하게 되면, 가지고 있는 워커노드에 만들어 놓았던 결과물(Webapp)을 Pod형태로 배포하는 작업 하고자 한다