[구글 클라우드 스터디 잼] 전체 과정 정리

해당 글은 https://www.cloudskillsboost.google/quests/29 의 실습을 완료하고 작성하는 글입니다.

이전 글에서 이미 쿠버네티스 진행과정에서 이미 설명하는 내용 위주로 진행한 것 같아 실습 과정은 간략하게 작성하고, 배운점 위주로 기술해보고자 한다. 또, 글을 여러개로 쪼개는 것보다는 한번에 합치는 것이 나을 거 같아 이번 글에 전부 작성하게 되었다.(나중에 다시 쪼갤지도?)

Intro: 입문반 완수!

강의 중간중간 자세한 설명과 실습을 진행했는지 확인하는 체크 과정이 매우 잘 구성되어 있다고 생각했다. 입문 과정이라, 기초적인 내용을 최대한 간단하게 설명해준다는 느낌을 많이 받았고 대부분의 실습이 적힌 시간보다는 빠르게 수행할 수 있었던 점도 좋은 점이었다.

Kubernetes Engine: Qwik Start

이 실습에서는 Kubernetes Engine으로 컨테이너화된 애플리케이션을 배포하는 방법을 배울 수 있었다. 실습 과정에서 설명하는 쿠버네티스 클러스터는 "Kubernetes Engine 환경은 컨테이너 클러스터를 형성하도록 그룹화된 여러 머신(구체적으로 Compute Engine 인스턴스)으로 구성되어 있다." 고 적혀있으나, 쿠버네티스를 잘 알지 못하는 상태였기에 학습 전에 쿠버네티스 클러스터 가 무엇인지 찾는 과정이 먼저 필요할 것 같았다.

쿠버네티스 클러스터

쿠버네티스 클러스터에 대해 작성하기 전에 나는, GKE(Google Kubernetes Engine) 과 쿠버네티스 를 혼동하여 조사 중 문제가 있었다. 일단 둘은 클러스터 아키텍처가 다르다. (두 공식문서의 아키텍처 페이지이다. 쿠버네티스 공식 문서의 클러스터 아키텍처 GKE 공식 문서의 클러스터 아키텍처 )GKE의 경우 Google 인프라를 사용하여 컨테이너식 애플리케이션을 배포, 관리, 확장할 수 있는 관리형 환경을 제공하는, 즉 google이 관여된 클러스터였다. (더 자세한 비교는 [GCP] 쿠버네티스(Kubernetes)와 GKE(Google Kubernetes Engine) 를 참고하면 좋을 것 같다.)

다시 돌아와서 GKE 쿠버네티스는(Autopilot 기준) 컨테이너화된 애플리케이션을 나타내는 Kubernetes 객체가 모두 이 클러스터에서 실행되게 된다. 클러스터는 가용성이 높은 제어 영역과 노드라고 하는 여러 작업자 머신으로 구성된다.



각 역할을 간단히 보면, Node는 컴퓨터 리소스, Pod는 노드 안에서 컨테이너 실행 권한을 가지며 실제 실행되는 애플리케이션 컨테이너가 존재한다. Control Plane 쪽의 다양한 기능들은 Node를 관리하는 역할을 한다. (Autopilot 모드의 클러스터의 경우 GKE에서 제어 영역, 노드, 모든 시스템 구성요소를 비롯해 클러스터의 전체 기본 인프라를 관리한다.)

Autopilot 클러스터 아키텍처

추가적으로, KGE가 아닌 쿠버네티스의 아키텍처가 궁금하다면, 위 공식 문서와 https://no-easy-dev.tistory.com/16 이 블로그를 참조하면 잘 알 수 있을 것 같다.

실습

이번 실습은 기본 컴퓨팅 영역 설정 - GKE 클러스터 만들기 - 클러스터의 사용자 인증 정보 얻기 - 클러스터에 애플리케이션 배포 의 과정으로 이루어졌다. 자세한 코드는 실습과정 에 자세히 나와 있으므로 참조하면 될 것이다.

이번 과정에서는 KGE의 클러스터에 대한 개념을 확실히 알게 되었고, 클러스터를 직접 배포하는 과정과 클러스터를 삭제하는 과정까지 마무리 할 수 있었다. 오히려 본문의 실습은 간단하였으나, KGE의 클러스터를 제대로 파악하는 과정이 더 오래걸린 것 같다.

Kubernetes를 통한 클라우드 조정

이번 실습의 목표는 아래 세가지였다.

- Kubernetes Engine을 사용하여 완전한 Kubernetes 클러스터를 프로비저닝합니다.

- kubectl을 사용하여 Docker 컨테이너를 배포하고 관리합니다.

- Kubernetes의 디플로이먼트 및 서비스를 사용하여 애플리케이션을 마이크로서비스로 분할합니다.

쿠버네티스 클러스터를 만들고, 클러스터를 배포하고 관리하는 과정을 진행하는 것 같아 기대되었다.

실습

실습을 위해 먼저 샘플 코드를 가져오고 kubectl create 명령어를 사용하여 nginx 컨테이너의 단일 인스턴스를 실행했다.

Pod

Kubernetes의 핵심에는 포드가 있다. 포드는 1개 이상의 컨테이너가 포함된 모음을 나타내며, 일반적으로 상호 의존성이 높은 컨테이너가 여러 개 있으면 이를 하나의 포드에 패키징한다.

포드의 역할은 아래와 같이 나눌 수 있다.

- 포드에는 볼륨도 포함되어 있다. 볼륨은 포드가 존재하는 한 계속해서 존재하는 데이터 디스크이며 포드에 포함된 컨테이너에 의해 사용될 수 있다.

- 포드는 콘텐츠에 공유된 네임스페이스를 제공한다. 즉, 이 예시의 포드 안에 있는 2개의 컨테이너는 서로 통신할 수 있으며 첨부된 볼륨도 공유한다.

- 포드는 네트워크 네임스페이스도 공유합니다. 즉, 포드는 IP 주소를 1개씩 갖고 있습니다.

- 포드는 포드 구성 파일을 사용하여 만들 수 있다. (이번 실습에서는 모놀리식 포드 구성 파일을 살펴보았다.)

- 포드에는 기본적으로 비공개 IP 주소가 부여되며 클러스터 밖에서는 접근할 수 없다. kubectl port-forward 명령어를 사용하여 로컬 포트를 모놀리식 포드 안의 포트로 매핑합니다.

서비스

포드는 영구적으로 지속되지 않는다. 활성 여부 또는 준비 상태 검사 오류와 같은 다양한 이유로 중지되거나 시작될 수 있으며, 이로 인해 문제가 발생한다. 그럼, 포드 집합과 통신해야 하는 경우 어떻게 해야 할까? 포드가 다시 시작되면 IP 주소가 바뀔 수도 있다. 이와 같은 상황에서 서비스를 사용할 수 있다. 서비스는 포드를 위해 안정적인 엔드포인트를 제공한다.

서비스는 라벨을 사용하여 어떤 포드에서 작동할지 결정한다. 포드에 라벨이 정확히 지정되어 있다면 서비스가 이를 자동으로 감지하고 노출시킨다.

서비스가 제공하는 포드 집합에 대한 액세스 수준은 서비스 유형에 따라 다르며, 현재 3가지 유형이 있다.

• ClusterIP(내부) -- 기본 유형이며 이 서비스는 클러스터 안에서만 볼 수 있습니다.
• NodePort 클러스터의 각 노드에 외부에서 액세스 가능한 IP 주소를 제공합니다.
• LoadBalancer는 클라우드 제공업체로부터 부하 분산기를 추가하며 서비스에서 유입되는 트래픽을 내부에 있는 노드로 전달합니다.

실습에서는 아래의 내용을 진행하였다.

• 서비스 만들기
• 라벨 셀랙터를 사용하여 제한된 포드 집합을 외부에 노출하기

서비스를 만들기 전에 https 트래픽을 처리할 수 있는 보안이 설정된 포드를 만든다.또, 현재 모놀리식 서비스에는 엔드포인트가 없기 때문에 포드에 라벨을 추가할 것이다. (라벨 쿼리와 함께 kubectl get pods 명령어를 사용)

Kubernetes로 애플리케이션 배포하기

실습의 목표는 프로덕션의 컨테이너를 확장하고 관리하는 것이다.이때 디플로이먼트를 사용할 수 있는데, 디플로이먼트는 실행 중인 포드의 개수가 사용자가 명시한 포드 개수와 동일하게 만드는 선언적 방식이다.

배포의 주요 이점은 pod 관리에서 낮은 수준의 세부정보를 추상화하는 데 있다. 배포는 백그라운드에서 복제본 집합을 사용하여 pod의 시작 및 중지를 관리한다. Pod를 업데이트하거나 확장해야 하는 경우 배포가 이를 처리하며 디플로이먼트는 어떤 이유로든 포드가 중지되면 재시작을 담당하여 처리한다. 아래는 그 예시이다.

포드는 생성 기반 노드의 전체 기간과 연결되어 있다. 위 예시에서는 Node3이 중단되면서 포드도 중단되었다. 직접 새로운 포드를 만들고 이를 위한 노드를 찾는 대신, 디플로이먼트가 새로운 포드를 만들고 Node2에서 실행하는 편리한 방식을 적용할 수 있었다.

이제 디플로이먼트를 사용하여 모놀리식 애플리케이션을 작은 서비스로 분할하는 과정을 진행하자.

디플로이먼트 만들기

모놀리식 앱을 다음의 3가지 부분으로 나눈다.

• auth - 인증된 사용자를 위한 JWT 토큰을 생성
• hello - 인증된 사용자를 안내
• frontend - 트래픽을 auth 및 hello 서비스로 전달

각 서비스용 디플로이먼트를 만들 준비가 끝났으니 auth 및 hello 디플로이먼트용 내부 서비스와 frontend 디플로이먼트용 외부 서비스를 정의하자. 이렇게 하면 모놀리식과 같은 방식으로 마이크로서비스와 상호작용할 수 있으며, 각 서비스를 독립적으로 확장하고 배포할 수 있다. 이 실습의 자세한 내용은 (Kubernetes를 통한 클라우드 조정 의 디플로이먼트 만들기 과정에서 확인할 수 있다.)

 

* 이후 학습 과정인 클라우드 조정, 배포 관리, 젠킨스를 이용한 지속적 배포는 조금 더 학습이 필요하다는 생각이 들어 비공개 게시물로 빼두었다. 공개할 수 있도록 더 열심히 공부해야겠다.