[Docker/K8S] 웹 서비스를 GKE로 배포하기(2) - 백엔드 워크로드 구성파일 만들기

이번에 업무과정에서 썼던 툴들을 정리해보면서 k8s 웹 배포를 작년에 했던 기억을 되살려 다시 공부해보면서 포스팅하기로 했다. 지난 포스팅에서는 먼저 쿠버네티스에 올릴 dockerfile을 만들어서 docker compose를 이용해 묶어서 실행해 동작 테스트까지 해보았다. 이 포스팅에서는 kubectl, gcloud를 설치하고 fastapi 측 워크로드 컨테이너를 gke 위에 올려본다.

목표

• GKE(Google Kubernetes Engine)와 GCE(Google Compute Engine) 등을 활용한 풀스택 웹 서비스 배포하기
  1. docker file 구성하기
  2. kubectl 활용하기
  3. 쿠버네티스 구성에 관한 이해 및 적용
     • Deployment
     • StatefulSet
     • Persistent Volume
     • Service
     • Gateway 

 

1. kubectl, gcloud 설치

• Kubernetes의 명령줄 도구인 kubectl이다. 연결한 클러스터의 정보를 보거나, 인스턴스를 생성하거나, 직접 내부로 접속하는 등 대부분의 명령 처리를 이걸 이용해서 한다. 

도구 설치

• gcloud CLI는 google cloud 리소스를 생성, 삭제, 관리하기 위한 명령줄 도구이다. google에서 제공하는 gke(google kubernetes engine)을 사용해보기로 했으니 같이 설치해준다. 
• 만일 gke가 아니라 로컬 환경에서 kubernetes를 활용해보고 싶다면 minikube를 사용해도 된다. 어차피 yaml 파일 구성은 똑같고, 기본적으로 google kubernetes engine을 사용해서 클러스터를 생성하고 테스트하다 보면 몇천원이지만 돈이 나가기 때문에... 
  • minikube는 k3s라고도 불리는 kubernetes 경량화 솔루션이다. 로컬에서 돌리기 위한 목적에 가깝고, 최소 사양을 만족하면 내 호스트머신 위에서 클러스터를 올려볼 수 있는 대신 멀티노드라던가 k8s가 제공하는 몇몇 기능 사용은 제약이 따른다.

gcloud CLI 설치  |  Google Cloud SDK  |  Google Cloud Documentation

 

minikube start

• 설치 후 커맨드라인에 kubectl, gcloud(혹은 minikube)를 쳐보고 잘 나오면 넘어가자.

 

A. google cloud에서 kubernetes cluster 생성하기

Google 클라우드 플랫폼

• 클러스터는 쿠버네티스 아키택처이다.

• 개념을 설명하는 것이 포스트의 주요 목표가 아니므로 노드 부분 위주로 보자. 클러스터는 pod를 실행하기 위해 최소 하나 이상의 워커 노드를 필요로 한다.
• 워커 노드는 애플리케이션 워크로드의 구성 요소인 파드를 호스팅하고, control plane으로 묶여있는 친구들이 워커노드와 pod를 관리감독한다.
• google kubernetes의 경우 multi node를 지원하므로 여러 개의 노드를 하나의 클러스터 안에서 생성하고 관리할 수 있다.

 

GKE 클러스터 생성

• gcp에서 클러스터는 autopilot과 standard가 있는데, 당장 배포해서 사용할 것도 아니거니와 자동 운영/관리되는 autopilot이 기본적으로 더 비싸므로 standard에서 비용을 좀 줄여서 테스트해보기로 했다. 
• 어떻게 구성할지는 개인 자유지만, 반드시 확인해야할 점은 cluster를 지역(region)으로 할당해야한다. 영역(zone)으로 하는게 더 저렴하지만, 나중에 배포할 때 gateway api를 통해 할 예정인데 영역 클러스터는 복잡하다. 처음부터 지역으로 잡아두자. 
• 나는 노드 개수를 줄이고, 머신을 small로 선택하고, 부팅디스크 크기를 줄여서 가격을 좀 낮췄다.
• 네트워킹 탭 최하단에 load balancer, ingress, gateway에서 gateway 사용설정에 체크해준다.
  • 체크하지 않은 경우에도 하는 방법이 다 있다. 그런데 좀 더 복잡하다.
• 그리고 만들기. 좀 걸리니까 여유롭게 기다리자.

 

2. 웹 yaml 파일 구성하기

• 이 예제에서 사용한 도커 이미지는 fastapi 와 jquery로 동작하는 프론트-백엔드 이미지 하나, postgres 공식 이미지 하나이다.
• 지난 포스팅에서 만들었던 도커 이미지 중 web에 해당하는 커스텀 이미지를 활용한다.
• postgres 는 공식 이미지에서 이전 포스팅에서 했던 작업과 비슷한 작업을 새로 해줄 것이다.

 

A. Deployment 만들기

• Deployment 는 쿠버네티스 애플리케이션 워크로드를 실행하기 위해 pod와 replica set을 관리 및 배포한다.
• 주로 Stateless 애플리케이션을 올린다.
• 주요 개념으로 Replica set이 있는데, 실행하는 pod들의 복제본 세트를 가지고 있다가 어떤 것이 다운되거나 삭제되면 복제본을 바로 올려서 서비스를 운영할 수 있도록 한다.
  • 이걸 활용해서 서비스의 버전 관리(업데이트, 롤백) 등에도 사용된다.

 

• kubernetes yaml 파일은 거의 비슷한 구조를 갖는다.
  • apiVersion
  • kind
  • metadata
  • 이 네 가지가 필수적으로 들어가고, secret이나 configmap이 아닌 애플리케이션 워크로드 들은 spec이 추가된다.

1. 공통 요소

apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  namespace: web
  labels:
    app: server

• apiVersion은 kind에 따라 다르다. Deployment의 경우 apps/v1.
• kind에 종류를 쓴다.
• metadata는 말 그대로 메타데이터다. name은 pod의 이름, namespace는 이 deployment를 배포할 namespace, labels:app 은 일종의 식별을 위한 태그라고 보면 된다. app 이름이 같은 pod 끼리 매핑할 수 있다.
  • namespace는 별도로 지정해주지 않으면 default를 사용한다. 그런데 default에는 다른 기본 pod들도 있기 때문에 헷갈림 방지를 위해서 새로 하나 만들어서 쓰기로 했다. 

2. spec

• spec 하위에는 replicas, selector, template가 있다. 
  • replicas : 복제본 개수
  • selector : replica set이 복제할 pod 참조를 위한 구별자
  • template : replica set이 복제할 때 사용할 pod 정보 입력

spec:
  replicas: 6
  selector:
    matchLabels:
      app: server
  template:

• template 아래에 들어가는 정보들이 container 정보라고 볼 수 있다.

spec:
  containers:
    - name: server
      image: mysterias/web-service:251111
      env:
        - name: db_user
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: DB_USER
        - name: db_password
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: DB_PASSWORD
        - name: db_host
          value: "postgresql"
        - name: db_port
          value: "5432"
        - name: db_name
          value: "energy_monitor"
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgres-credentials
              key: POSTGRES_USER
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-credentials
              key: POSTGRES_PASSWORD
      ports:
        - containerPort: 8080
          name: server

• containers 내부에 크게 4가지가 확인된다.
  • name : 기본 pod 이름
  • image : container의 image, docker hub에서 pull 하도록 했다.
  • env : 환경 변수
  • ports : 컨테이너 포트 정의
• env 환경변수 파트를 보면 두 가지 형태로 나누어져 있는 것을 볼 수 있다. 

- name: db_name
  value: "energy_monitor"
  
- name: POSTGRES_USER
  valueFrom:
    secretKeyRef:
      name: postgres-credentials
      key: POSTGRES_USER

• 이는 아래 형태는 kind 중 하나인 Secret 으로 미리 정의해둔 값을 참조해서 가져올 때 사용할 수 있는 방법이다. 
• 처음에는 위 형태로 환경변수를 설정했었는데, 이렇게 deployment를 클러스터에 올리면 yaml 파일을 조회할 수 있기 때문에 보안상 취약할 것이라고 생각했다. 파일로 나누어서 숨기거나, 다르게 정의하는 방법을 찾다가 만난 것이 바로 Secret 형태이다.

B. Secrets

# Secret
apiVersion: v1
kind: Secret
metadata:
  name: postgres-credentials
  namespace: web
type: Opaque
stringData:
  POSTGRES_USER: "postgres"
  POSTGRES_PASSWORD: "postgres"

• Secret에서 지정할 수 있는 type은 여러가지가 있는데, Opaque 는 사용자 지정 타입이라는 의미이다.
• data 필드는 data 혹은 stringData로 나뉘는데, stringData로 할 경우 base64 인코딩 없이 문자열 등의 데이터를 넣고, data를 쓸 경우에는 base64 인코딩이 요구된다.
• 이제 kubernetes cluster에 등록하면 secret에 있는 값을 환경변수로 받아와서 사용할 수 있다. 

kubectl create -f postgres-secret.yaml

바로 확인이 가능한 deployment의 yaml

console에서 보안이 유지되는 secret'

 

• 먼저 secret을 올려야 이후 deployment에서 참조할 수 있다. 순서에 유의할 것.

 

C. Service 만들기

• 이렇게 해서 만일 deployment를 클러스터에 올렸다면 이것은 pod로 동작한다. 다른 pod에서 이 Pod로 직접 연결해서 통신할 수도 있지만, replica set을 만들었던 것을 생각해보면 Pod는 언제든 대체할 수 있고 바뀌거나 사라진다면 이전과 ip가 같으리라는 보장이 없다.
• 때문에 이 Pod, Container와 통신할 때 좀 더 안정적으로 통신할 수 있도록 서비스(reverse proxy or load balancer)를 붙인다.
  • 클라이언트에서 서비스 ip 쪽으로 연결하면 서버 목록을 reverse proxy가 확인하면서 살아있는 pod로 트래픽을 연결해준다.

# Service
apiVersion: v1
kind: Service
metadata:
  name: server-svc
  namespace: web
  labels:
    app: server
spec:
  selector:
    app: server
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: loadBalancer

• spec의 selector를 보면 우리가 deployment에서 labels를 app: server로 설정했었기 때문에, 이 서비스가 label app = server인 Pod 중에 살아있는 것을 찾아서 연결하리라는 것을 알 수 있다.
• ports 부분이 중요한데(맨날 target이랑 그냥 port랑 헷갈림) targetPort는 container 내부 포트이고, port는 외부에 노출할 포트를 의미한다.
  • 8080 포트는 pod 내부에서 클라이언트 요청을 기다리고 있는 gunicorn 포트
  • 80 포트는 이 워크로드 바깥의 다른 워크로드에서 서비스를 통해서 요청을 보낼 포트
  • 서비스는 80 포트로 들어온 요청을 받아서 > 살아있는 pod를 확인하고 > 그 pod의 8080 포트로 요청을 보내준다.
• type을 보면 loadBalancer로 되어있다. GKE에서 loadBalancer type의 service는 고유의 ip 주소를 갖고 외부 접속이 허용된다. GKE를 사용 중일 경우 ip가 할당되면 <IP_ADDRESS>:80 주소로 접속해볼 수 있다.
• 추후 gateway api를 사용해서 정식으로 접속하도록 만들 때에는 Cluster IP 타입으로 바꾸어주어야한다. 이 내용은 추후에...