작성한 질문수 12

0

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 해도 데이터가 보존된다.

0

해결했습니다. 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와 테이블이 남아 있는것을 확인 했습니다. 후속 진도를 진행해보면 완전히 해결된건지 알수 있겠죠.

0

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

0

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

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

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

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

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

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

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

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

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

0

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

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

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

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

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

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

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

    

0

안녕하세요, 인프런 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 파일 등)를 추가적으로 제공해 주시면 더욱 정확한 답변을 드릴 수 있습니다.

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