이제까지 배워온 내용을 바탕으로 칸반보드 API 서버를 쿠버네티스에 배포하는 시간을 가져보도록하자!

구조

칸반보드 API 서버를 워커 노드 3개로 로드밸런싱 설정하는 것이 목표이며 이를 효율적으로 구현하기 위해 쿠버네티스 Deployment Controller, Service(Cluster IP)를 활용할 것이다.

칸반보드 API 서버의 경우 컨테이너를 실행시키기 위해 환경변수를 필수로 선언해주어야 하는데 ConfigMap을 이용하여 설정해줄 수 있다. 파드를 생성하기 이전에 ConfigMap을 먼저 생성해주는 것을 잊지말자

ConfigMap 설정

ConfigMap을 사용하는 방법엔 여러가지가 있지만 나는 단순하게 env 설정을 분리하고 Deployment에서 env 전체를 참조하는 방식을 사용했다.

configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: kanban-api-config
data:
  SERVER_PORT: "3000"
  POSTGRESQL_USER: ""
  POSTGRESQL_PASSWORD: ""
  POSTGRESQL_HOST: ""
  POSTGRESQL_PORT: "5432"
  POSTGRESQL_DATABASE: ""
  POSTGRESQL_SYNCHRONIZE: "true"
  POSTGRESQL_LOGGING: "true"
  JWT_ACCESS_SECRET_KEY: ""
  JWT_ACCESS_EXPIRATION_TIME: ""
  JWT_REFRESH_SECRET_KEY: ""
  JWT_REFRESH_EXPIRATION_TIME: ""

data 하위에 key-value 형식의 데이터들을 선언해주는 것으로 환경 변수를 적용했다.

$ kubectl apply -f configmap.yaml
configmap/kanban-api-config created

성공적으로 생성이 되었다면 kubectl로 확인할 수 있다.

물론 ConfigMap을 생성되었다고 끝난게 아니다. 내가 배포할 설정 파일에서 읽어들일 수 있도록 선언해야한다. 관련 설정은 아래에서 보도록 하자.

Deployment 설정

Deployment Controller는 Pod를 지속적으로 모니터링하고 정의된 상태와 다를 경우 자동으로 복구하거나 생성하는 특징이 있다.

이를 이용하여 3개의 Pod 레플리카를 생성해보자.

kanban-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kanban-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kanban-api
  template:
    metadata:
      labels:
        app: kanban-api
    spec:
      containers:
      - name: kanban-api
        image: haeseung/kanban-server
        envFrom:
        - configMapRef:
            name: kanban-api-config
        ports:
        - containerPort: 3000

특별할 것 없는 3개의 Pod를 배포하게 될 설정 파일이다. 여기서 하나 주목할 점은 앞서 우리가 생성한 ConfigMap을 해당 파일에서 읽어들일 수 있게 설정해줘야 한다는 것이다.

$ kubectl create -f kanban-deployment.yaml --record
deployment.apps/kanban-deploy created

이제 yaml에서 정의했던 metadata의 이름으로 생성된 3개의 Pod를 확인할 수 있는데 여기서 각각의 worker 노드로 분산되어 실행된 것까지 알 수 있다.

다음으로 해야할 일은 무엇일까? 바로 서비스를 이용하여 Pod들을 하나로 묶어 로드밸런싱하는 작업이다.

Service 설정

Service에서는 특별히 설정하지 않는 이상 ClusterIP가 default로 동작하게 되는데 ClusterIP는 Pod 그룹의 단일 진입점을 생성하고 해당 Pod들을 동일한 비율로 로드밸런싱한다는 특징이 있다.

그러나 외부에서 접근이 안되기 때문에 외부 트래픽을 통신하게 하기 위해선 Ingress와 같은 서비스를 사용하여 클러스터 내부의 서비스를 외부로 노출시키는 작업이 별도로 필요하다.

해당 프로젝트의 경우 현재 서비스를 하지 않는 API 서버이기 때문에 단일 진입점을 통해 서버가 정상적으로 동작하는지 확인하는 정도면 충분할 것 같다.

kanban-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: kanban-service
spec:
  type: ClusterIP
  selector:
    app: kanban-api
  ports:
  - protocol: TCP
    port: 3030
    targetPort: 3000

Service에서는 selector를 통해 deployment.yaml에 작성했던 label과 일치하는 Pod 그룹을 하나로 묶을 수 있다. 나의 경우에는 app: kanban-api이 된다.

$ kubectl create -f kanban-service.yaml 
service/kanban-service created

이제 10.96.29.73:3030을 통해 내부에서 Pod들에 접근할 수 있게 되었다.

describe 명령어로 Endpoints까지 확인해보자.

아름답게 묶여있다!

마지막으로 실제로 내부에서 10.96.29.73:3030로 접근이 가능한지 확인해보도록 하자.

/api 경로로 curl 테스트를 해보니 API 서버의 스웨거 문서가 잘 조회된다. 이로써 쿠버네티스 배포가 원하는대로 완료되었다고 할 수 있다.

다음 시간에는 실제 외부에 서버를 배포하고 배포 자동화까지 할 수 있도록 해보겠다. 굿빠이