라즈베리파이를 이용한 멀티 노드 클러스터링 (3) - MySQL

쿠버네티스 공부를 하겠다고 한 후 한참이 지났다.

사실 그 동안 정말 오케스트레이션을 쓰는게 좋은 것인가?를 두고 많이 고민했다.

정확히는 내가 만드는 서비스, 프로젝트에서 쿠버네티스가 정말 효용성이 있는지를 따지다보니 후순위로 밀린 감이 없지 않아 있다.

이번에 진행 중인 프로젝트를 위해서 데이터베이스와 API 서버를 k3s에 배포해보려고 한다.

 

다시금 쿠버네티스를 만져보면서 이전에 써둔 글을 그대로 따라했다. 물론 별 내용은 없지만 매 번 검색하고 찾는 것보다는 내가 정리한 글이 따라해보기 편한 것 같다. 그래서 이 글도 계속 작성하려한다.

 

#pv-local.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "pv-local"
  labels:
    type: local
spec:
  storageClassName: db-storage-class
  capacity:
    storage: "10Gi"
  accessModes:
    - "ReadWriteOnce"
  hostPath:
    path: /tmp/k3s/db
  persistentVolumeReclaimPolicy: Recycle

# local-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-local-claim
spec:
  storageClassName: db-storage-class
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

 

우선 두 개의 파일을 생성하자.

PV(Persistent Volume)와  PVC(Persistent Volume Claim)에 관한 스토리지 클래스이다.

클러스터는 서비스를 동작시킬 수도 있지만 그와 별개로 스토리지에 대한 관리도 수행해야 한다.

이때, PV와 PVC가 1대1로 매핑되면서 PV가 파일 시스템에 대한 동작을 수행하고 PVC는 그에 따라 적절한 자원을 요청한다.

 

sudo kubectl create -f pv-local.yaml
sudo kubectl create -f local-pvc.yaml
sudo kubectl describe pv pv-local-volume

 

내가 작성한 PV를 생성하고 다음 파일을 작성하자.

echo "secret_key" | base64

# mysql-keys.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
data:
  password: bWVnYV9zZWNyZXRfa2V5Cg==

sudo kubectl create -f db-keys.yaml
sudo kubectl describe secret mysql-secret

이제 우리는 DB에서 사용할 패스워드를 등록해줄 것이다.

시크릿은 암호, 토큰, 키와 같은 소량의 중요한 정보를 담는 오브젝트다. 

중요한 정보를 별도로 Key-Value를 통해 관리할 수 있다.

 

#mysql-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3307
  selector:
    app: mysql

#mysql-dep.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mariadb # 수정)mysql은 이미지 Pull 에러가 발생할 수 있다.
        name: mysql
        imagePullPolicy: Always
        ports:
        - containerPort: 3307 
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: pv-local-claim

마지막으로 우리가 배포할 mysql 서비스와 배치본에 대해 작성한다.

나는 이것을 우리가 흔히 사용하는 도커의 이미지-컨테이너와 같은 인스턴스를 생성하는 관계라고 이해했다.

이것 또한 마찬가지로 생성해주자.

 

사실 수정하기 귀찮아서 여기다 적지만 MySQL 이미지는 Pull 에러가 발생할 수 있다.

나도 에러가 나서 그냥 mariadb로 이미지를 바꾸었다.

sudo kubectl create -f mysql-svc.yaml
sudo kubectl create -f mysql-dep.yaml

 

 

sudo kubectl delete pvc/pv-local-claim

혹여 잘못 생성한 객체가 있다면 위와 같이 객체타입/객체명을 통해 삭제할 수 있다.

 

sudo kubectl get pvc
sudo kubectl get svc
sudo kubectl get secret
sudo kubectl get pods

위 명령으로 각각 생성했던 여러 타입의 객체들과 우리가 배포한 파드(mysql)가 동작 중인 것을 확인해볼 수 있다.

 

이번에 등록한 데이터베이스는 웹 서비스에서 계속 접근해야한다.

이전에도 사실 Nginx를 통해서 웹 서비스를 쿠버네티스에 잠깐 배포해보면서 레플리카 셋을 적용해보았던 적이 있다.

이번에는 거기까지는 조금 힘들 것 같다. 실제 해본 적은 없지만 올라갈 서비스들이 API 요청을 해야하는데 레플리카 셋이 발생하면 그 수 많큼... 더 발생할 것 같아서 걱정이 된다.