인프런 커뮤니티 질문&답변

MySQL Kubernetes Deployment 매뉴얼

1. 작업 개요

• 목표: MySQL을 Kubernetes 환경(Docker Desktop, Windows)에서 Deployment로 실행하고, rollout 재시작 시에도 데이터가 보존되도록 PVC 기반 영속 스토리지를 구성한다.

• 문제 상황: 초기 hostPath 기반 PV/PVC 설정에서 MySQL이 데이터 디렉토리 초기화 실패(Data Dictionary initialization failed) 발생.

• 해결 전략:

1. emptyDir로 테스트하여 정상 구동 확인

2. PVC를 기본 StorageClass 기반으로 재구성하여 영속성 확보

    

2. 시도한 방법 순서

(1) 초기 설정

• mysql-deployment.yaml에서 subPath: data

• (subPath는 권한해결 방법을 찾다가 추가했던 내용임) 제거 후 실행 → 여전히 데이터 디렉토리 오류 발생.

• 원인: PVC가 연결된 디렉토리에 MySQL 초기화 파일이 남아 있거나 권한 문제.

   

(2) 디렉토리 정리

• 호스트 VM 내부에서 /mnt/data/mysql-data 파일 삭제:

   

  rm -rf /mnt/data/mysql-data/*

   

• 권한 확인:

   

  ls -ld /mnt/data/mysql-data stat /mnt/data/mysql-data

   

• UID/GID가 999:999로 설정되어 있음 확인.

   

(3) emptyDir 테스트

• Deployment에서 emptyDir로 /var/lib/mysql 마운트:

   

  volumes: 
  - name: mysql-storage 
  emptyDir: {}

   

• Pod 상태 확인:

   

  kubectl get pods kubectl describe pod

   

• 결과: Pod가 Running + Ready 상태로 정상 구동됨.

• 단점: Pod 재시작 시 데이터 소실.

   

(4) PVC 기반 영속성 설정

• 기존 리소스 삭제:

kubectl delete deployment mysql-deployment 

kubectl delete pvc mysql-pvc 

kubectl delete pv mysql-pv

• PVC 생성 (storageClassName 제거 → 기본 StorageClass 사용):

   

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: mysql-pvc
  spec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 1Gi

• Deployment 수정 (PVC 연결):

  volumes: 
  - name: mysql-persistent-storage    persistentVolumeClaim: 
  claimName: mysql-pvc 
  volumeMounts: 
  - name: mysql-persistent-storage 
  mountPath: /var/lib/mysql

   

• 적용:

kubectl apply -f mysql-pvc.yaml
kubectl apply -f mysql-deployment.yaml 
kubectl apply -f mysql-service.yaml

3. 확인한 내용

• Pod 상태:

   

  kubectl get pods kubectl describe pod mysql-deployment-xxxx

   

  • → Running, Ready: True 확인.

  • DBeaver 접속 정보:

    • Host: 127.0.0.1

    • Port: 30002

    • Database: kub-practice

    • User: root

    • Password: password123

  • DB 선택:

   

  USE kub_practice; 
  SHOW TABLES;

   

  4. 정상 확인 방법

  1. DBeaver에서 접속 후 SHOW DATABASES; 실행 → kub-practice 확인.

  2. 테이블 생성 및 데이터 입력:

  3.  

     CREATE TABLE test_table (id INT PRIMARY KEY, name VARCHAR(50)); 
     INSERT INTO test_table VALUES (1, 'hello');

      

  4. Deployment 재시작:

  5.  

     kubectl rollout restart deployment mysql-deployment

      

  6. 다시 DBeaver 접속 후:

   

  SELECT * FROM test_table;

   

• → 데이터가 그대로 남아 있으면 PVC 기반 영속성 정상 동작.

•  

  🚀 최종 결론

  • emptyDir로 정상 구동을 확인한 뒤, PVC 기반으로 되돌려서 영속성을 확보하는 방식이 올바른 접근이다.

  • 이제 Deployment를 재배포하거나 rollout restart 해도 데이터가 보존된다.

해결했습니다. windows에 설치된 docker.desktop 문제인지는 모르겠으나... 3일동안 ChatGPT,Gemini를 넘나들며 수십번 반복해도 error와 crash났는데. 도커데스크탑을 재설치 해도 마찬가지였어요. 마지막으로 VM에 접속해서 mysql-data 폴더에 퍼미션을 999로 부여하고,

mysql-pvc.yaml에서 storageClassName 제거하고

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

mysql-deployment.yaml 에서

      volumes:
        - name: mysql-storage
          emptyDir: {}

empty로 한번 털고 나서 mysql-deployment.yaml 만 강의 내용으로 원복하고 rollout 테스트 해보니 db와 테이블이 남아 있는것을 확인 했습니다. 후속 진도를 진행해보면 완전히 해결된건지 알수 있겠죠.

인프런AI가 답하는건 이상황에 아무 도움이 않되요. Gemini나 ChatGPT도 똑같은 답을 하는데 해결않되요. 저도 2일째 여러방법을 적용해봤는데. 아무래도 Docker.desktop을 재설치하는것 밖에 방법이 없는것 같은데. 다시 설치해도 않되면 멘붕올듯 하군요.

경호님 ! 에러 원인이 될만한 짐작가는 포인트가 있어서 추가로 답변 남깁니다:)

우선 해당 에러들이 발생하는 주요 원인은 Docker Desktop 혹은

Docker Desktop의 쿠버네티스의 버전이 낮을 경우 발생을 해요 !

Docker Desktop에 접속하신 뒤 첨부한 이미지의 설정 버전들을

확인해보시고 공유해주실수 있을까요 ~?

버전이 낮으신 경우 업데이트 하신 뒤 다시 실습 진행 해보시면 잘 될거라 생각됩니다 !

참고로 Docker Desktop 앱에서 UI 버튼을 통한 업데이트는 종종 적용이 잘 안되는 버그가 있어

Docker Desktop를 삭제하신 뒤 재설치 해보시는걸 추천드려요 :)

위 과정을 디버깅 해보시고도 어떤 게 문제인지 파악이 안 될 경우 또 질문 남겨주세요~~ 😊

안녕하세요 경호님! 질문 잘 해주셨습니다~!!

에러 상황을 조금 더 디테일하게 파악하기 위해 몇 가지 내용에 대해서만 답변해주실 수 있을까요~??

1. 현재 사용하고 계신 OS가 윈도우이실까요 ? 아니면 맥이실까요 ?

2. Docker Desktop을 활용해 Kubernetes를 활용하고 계신 상태이실까요~?

3. 실습 과정에서 어떤 명령어를 입력했을 때 위와 같은 에러가 발생하신 걸까요~?

4. 에러 화면을 캡쳐 한 번만 해주실 수 있을까요~??

5. 사용하고 계신 터미널의 종류가 어떻게 되실까요 ? (ex. Powershell, wsl2, git bash 등)

    

안녕하세요, 인프런 AI 인턴입니다. 경호님!

CrashLoopBackOff와 관련하여 MySQL 컨테이너 로그에서 발생하는 오류를 분석해 보겠습니다. 주로 발생하는 오류는 “Operating system error number 22 in a file operation.“으로, 이는 파일 시스템 문제와 관련되어 있습니다. 특히, 쿠버네티스에서 PVC(Persistent Volume Claim)를 사용할 때 발생할 수 있는 문제 중 하나입니다.

문제의 원인

1. PVC 권한 문제: MySQL이 데이터를 저장하기 위해 접근하려는 디렉토리에 적절한 권한이 없을 수 있습니다. 이는 PVC와 Pod 간의 권한 설정 문제에서 기인할 수 있습니다.
   
2. 파일 경로 문제: PVC가 마운트되는 경로가 올바르지 않거나, 실제로 데이터가 저장될 디렉토리가 생성되지 않았을 가능성이 있습니다.
   
3. 잘못된 설정: PVC 또는 PV(Persistent Volume)의 설정 오류가 의심됩니다.
   

해결 방법

1. PVC와 PV 설정 검토: 사용 중인 PVC와 PV의 설정을 확인해 보세요. PVC가 올바르게 바인딩되었는지, 권한 설정이 정상인지 점검해야 합니다.
   
2. 디렉토리 및 권한 확인: MySQL의 데이터가 저장되는 /var/lib/mysql 디렉토리에 올바르게 접근할 수 있는지 확인하고, 필요한 경우 chown 명령어로 디렉토리의 소유자와 그룹을 변경하여 권한을 조정하세요.
   
3. PVC와 Pod 로그 분석: PVC와 관련된 이벤트 로그를 확인하여 오류의 원인을 더욱 상세히 파악하실 수 있습니다.
   

해결에 도움이 될 유사한 질문 사례를 소개해 드립니다:
- Kubernetes에서 PVC 권한 문제 사례
- Persistent Volume 관련 문제 해결

잘 해결되지 않는 부분이 있다면, 관련 컨텍스트 (예: YAML 파일 등)를 추가적으로 제공해 주시면 더욱 정확한 답변을 드릴 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.