[GCP] 2 - Container and Kubernetes in GCP

 

이전 글에서 GCP에 대한 기본적인 내용을 알아보았다면, GKE(Google Kubernetes Engine)을 알아보기전에 Container와 Kubernetes에 대해서 알아보자. 

 

---

> 일반적으로 application을 빌드하고 수행하는 경우, Dedicated Server(ex.물리적인 서버)에서 수행을 하게되면 H/W에 종속된 S/W가 만들어진다. 이렇게 개발된 S/W는 개발된 H/W와 호환성을 갖는 장비에서만 수행이 가능해진다. 

> VM(Virtual Machine)을 사용하는 경우 H/W를 가상으로 생성할 수 있기 때문에 H/W에 대한 의존성이 줄어들지만 대신 Kernel(OS)에 대한 의존성은 여전히 존재하게 되며, 여러개의 app이 동일한 VM에서 수행이 되는 경우 Dependencies들이 충돌이 발생할 수 있다. 

> Applicaiton마다 VM을 생성하여 별도의 실행환경을 구축할 수 있겠으나, 모든 VM이 Kernel을 각자 가지고 있기 때문에 kernel영역에서 오버헤드가 발생하여 여러개의 app을 수행시키는 경우 비효율적으로 자원이 관리되게 된다. 또한 VM마다 kernel을 가지고 있기 때문에 부팅을 위한 시간이 소요됨으로 기동시간이 매우 느려진다. 

 

> Container는 VM 의 단점을 보안하여 발전된 것으로 여러 app에 대해서 별도의 dependencies를 갖게 한다. 
> Container는 중앙에서 관리할 수 있으며 매우 빠르게 배포하고 확장할 수 있다. 
> Container는 기존에 운영되고 있는 images를 기반으로 점증적 변경을 통해 생성될 수 있다. 
> Kernel 영역은 서로 공유됨으로 Container에서 따로 신경쓸 필요가 없으며, 매우 가볍게 동작한다. 
> 이러한 구성은 application을 설계할때 micro service 디자인패턴을 사용할 수 있게 하는데, 이것을 통해 containerized app 들은 서로 덜 결합되고 매우 세분화되어질 수 있어 더 쉽게 유지보수 할 수 있다. 

 

---

 

> Container는 Linux의 다양한 기술을 사용하여 개발되었다. 

1) Processes : Linux의 process는 각각 독립된 가상 메모리 주소공간을 가지고 있는데, container 또한 서로 독립적으로 별도의 메모리 주소공간을 갖는다.  또한 process는 빠르게 생성되고 종료될 수 있다. 

2) Linux namespace : container는 linux namespace를 이용하여 application이 접근할 수 있는 resource를 제어한다. (PID, directory tree, IP addr 등). 주의할 점은 Linux namespace는 k8s의 namespace와 개념이 다름으로 구분해야 한다. 

3) cgroups : Linux cgroup은 app이 사용하는 리소스를 제어한다. (ex. 최대로 사용할 수 있는 CPU 시간, memory, IO 대역폭 등) 

4) Union file system : app을 효과적으로 캡슐화 하고, 가장 적은 수의 dependency 계층들을 사용하여 최소의 layer를 갖도록 캡슐화 하여 명확하게 해준다. 

 

---

 

> Container는 manifest로 부터 명령어를 읽어 이미지를 빌드한다. Docker 형식의 container 이미지인 경우 이 파일은 Dockerfile 이라는 이름으로 사용된다. 

> Dockerfile의 각 명령어들은 container안에서 특정한 layer를 구성한다. 이렇게 사전에 정의한 선언적 layer는 오직 읽기전용read-only으로 구성된다. 이와는 별도로 continer가 이미지를 실행 시키면 쓰기가 가능한 최상의 layer가 임시로 생성이된다. 

> Dockerfile은 4가지 명령어로 구성이 되는데, 이러한 명령어를 통해서 images layer가 생성이 된다.
- FROM : public repository로부터 이미지의 base가 될 layer를 불러온다. 
- COPY : 현재 directory로 부터 일부 파일들을 image로 복사하며, 새로운 layer를 추가한다. 
- RUN :  특정 linux 명령을 수행하여 그 결과를 layer로 추가한다. (주로 make를 이용한 빌드작업) 
- CMD : container가 수행되었을 때 container 내부적으로 수행할 명령어를 지정한다. 

> Layer들은 이전 레이어에서 변경사항들만을 가지고 있게 된다. 따라서 Dockerfile에서 명령어를 이용하여 작성하는 경우 이전 layer로 부터 변경사항을 최소화 하도록 만들어야 한다. 

> 최종 실행 가능한 이미지는 Dockerfile 안에서 여러 단계를 거쳐서 빌드가 되고 그 결과 image layer는 여러 계층을 갖게 된다. 반면에 container가 실행되면 app을 처리하기 위해 임시 layer가 생성이 되는데 이것을 container layer라고 한다. 만약 container가 삭제된다면 container layer는 삭제가 된다. container layer를 image layer에 추가하는 것도 가능하다. conatiner가 삭제된다고 하더라도 image layer는 그대로 존재하기 때문에 차후 작업에서 변경사항을 활용할 수 있다.

Dockerfile

---

 

> Container 들은 각각 container layer를 가지고 있기 때문에 모든 변경사항들은 각자의 container layer에 저장된다. 
> 여러개의 container는 자신의 container layer와는 별도로 image layer를 공유할 수 있어 리소스를 효율적으로 사용할 수 있다. 
> Container를 빌드할 때 전체 이미지를 복사하는 것이 아니라, 변경된 부분만 layer로 추가하여 사용할 수 있다. 
> Container를 실행시킬 때는 그들이 필요한 layer에 대해서만 pull 할 수 있다. 

 

---

> Google은 GCR(Google Cloud Repository, grc.io)와 같은 container registry를 유지하고 있다. 
> Ecloud 고객은 자신의 private images를 이곳에 저장할 수 있으며 IAM과 연계할 수도 있다. 
> IAM을 통해 private 이미지를 public을 공개하지 않을 수 있다. 
> GCP에서 container를 빌드하기 위한 많은 서비스를 제공하고 있는데 이것을 Cloud build라고 한다. 

 

> Cloud build는 다양한 storage로 부터 소스코드를 가져올 수 있다. 
- Cloud source repository, git, cloud storage 

> Cloud build를 통해 빌드하려면 몇가지 정의작업이 필요하다. 
- 의존성 fetch , 소스컴파일, integration 테스트, maven 등 도구

> 각 빌드 단계들은 Docker Container로 cloud build데서 제공된다. cloud build는 다양한 실행화녁ㅇ에서 이미지를 빌드할 수 있도록 제공한다. 단지 GKE를 대상으로 빌드하는 것이 아니라 App Engine, Cloud Function 에서도 수행할 수 있도록 빌드가 가능하다.