programing

호스트 경로 볼륨이 있는 kubernetes 포드 내에서 mariadb가 크래시함

goodjava 2022. 11. 2. 00:30

호스트 경로 볼륨이 있는 kubernetes 포드 내에서 mariadb가 크래시함

Linux 서버의 여러 도커 컨테이너를 다른 Linux 시스템에서 실행 중인 테스트 Kubernets 기반 배포로 이동하려고 합니다. 여기서 kbernetes를 vagrant 가상 머신 내에 k3s 인스턴스로 설치했습니다.

이러한 컨테이너 중 하나는 바인딩 볼륨이 매핑된 mariadb 컨테이너 인스턴스입니다.

사용하고 있는 도커 컴포넌트의 관련 부분은 다음과 같습니다.

  academy-db:
    image: 'docker.io/bitnami/mariadb:10.3-debian-10'
    container_name: academy-db
    environment:
      - ALLOW_EMPTY_PASSWORD=yes
      - MARIADB_USER=bn_moodle
      - MARIADB_DATABASE=bitnami_moodle
    volumes:
      - type: bind
        source: ./volumes/moodle/mariadb
        target: /bitnami/mariadb
    ports:
      - '3306:3306'

이것은 올바르게 동작하는 것에 주의해 주세요.(컨테이너는 다른 응용 프로그램컨테이너에 의해 사용되며, 컨테이너에 접속하여 DB에서 데이터를 문제없이 읽습니다).

그런 다음 볼륨 폴더를 타깃 머신에 복사하고 다음 kubernetes.yaml 배포 파일을 사용하여 이 설정을 kubernetes 구성으로 변환하려고 했습니다.여기에는 배포 .yaml, 영구 볼륨 클레임 및 영구 볼륨뿐만 아니라 컨테이너에 액세스할 수 있도록 하는 NodePort 서비스도 포함됩니다.데이터 볼륨에는 도커 컴포지트의 바인드 마운트에서 복사된 콘텐츠를 가리키는 단순한 hostPath 볼륨을 사용하고 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: academy-db
spec:
  replicas: 1
  selector:
    matchLabels:
      name: academy-db
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        name: academy-db
    spec:
      containers:
        - env:
            - name: ALLOW_EMPTY_PASSWORD
              value: "yes"
            - name: MARIADB_DATABASE
              value: bitnami_moodle
            - name: MARIADB_USER
              value: bn_moodle
          image: docker.io/bitnami/mariadb:10.3-debian-10
          name: academy-db
          ports:
            - containerPort: 3306
          resources: {}
          volumeMounts:
            - mountPath: /bitnami/mariadb
              name: academy-db-claim
      restartPolicy: Always
      volumes:
        - name: academy-db-claim
          persistentVolumeClaim:
            claimName: academy-db-claim
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: academy-db-pv
  labels:
    type: local
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "<...full path to deployment folder on the server...>/volumes/moodle/mariadb"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: academy-db-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: ""
  volumeName: academy-db-pv
---
apiVersion: v1
kind: Service
metadata:
  name: academy-db-service
spec:
  type: NodePort
  ports:
    - name: "3306"
      port: 3306
      targetPort: 3306
  selector:
    name: academy-db

도입 후 모든 것이 정상적으로 동작하고 있는 것 같습니다.kubectl get ...팟과 볼륨이 올바르게 실행되고 있는 것 같습니다.

kubectl get pods

NAME                             READY   STATUS    RESTARTS   AGE
academy-db-5547cdbc5-65k79       1/1     Running   9          15d
.
.
.

kubectl get pv
NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                              STORAGECLASS   REASON   AGE
academy-db-pv           1Gi        RWO            Retain           Bound    default/academy-db-claim                                   15d
.
.
.

kubectl get pvc
NAME                       STATUS   VOLUME                  CAPACITY   ACCESS MODES   STORAGECLASS   AGE
academy-db-claim           Bound    academy-db-pv           1Gi        RWO                           15d
.
.
.

다음은 포드의 로그입니다.

kubectl logs pod/academy-db-5547cdbc5-65k79

mariadb 10:32:05.66
mariadb 10:32:05.66 Welcome to the Bitnami mariadb container
mariadb 10:32:05.66 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mariadb
mariadb 10:32:05.66 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mariadb/issues
mariadb 10:32:05.66
mariadb 10:32:05.67 INFO  ==> ** Starting MariaDB setup **
mariadb 10:32:05.68 INFO  ==> Validating settings in MYSQL_*/MARIADB_* env vars
mariadb 10:32:05.68 WARN  ==> You set the environment variable ALLOW_EMPTY_PASSWORD=yes. For safety reasons, do not use this flag in a production environment.
mariadb 10:32:05.69 INFO  ==> Initializing mariadb database
mariadb 10:32:05.69 WARN  ==> The mariadb configuration file '/opt/bitnami/mariadb/conf/my.cnf' is not writable. Configurations based on environment variables will not be applied for this file.
mariadb 10:32:05.70 INFO  ==> Using persisted data
mariadb 10:32:05.71 INFO  ==> Running mysql_upgrade
mariadb 10:32:05.71 INFO  ==> Starting mariadb in background

및 descript pod 명령어:

Name:         academy-db-5547cdbc5-65k79
Namespace:    default
Priority:     0
Node:         zdmp-kube/192.168.33.99
Start Time:   Tue, 22 Dec 2020 13:33:43 +0000
Labels:       name=academy-db
              pod-template-hash=5547cdbc5
Annotations:  <none>
Status:       Running
IP:           10.42.0.237
IPs:
  IP:           10.42.0.237
Controlled By:  ReplicaSet/academy-db-5547cdbc5
Containers:
  academy-db:
    Container ID:   containerd://68af105f15a1f503bbae8a83f1b0a38546a84d5e3188029f539b9c50257d2f9a
    Image:          docker.io/bitnami/mariadb:10.3-debian-10
    Image ID:       docker.io/bitnami/mariadb@sha256:1d8ca1757baf64758e7f13becc947b9479494128969af5c0abb0ef544bc08815
    Port:           3306/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Thu, 07 Jan 2021 10:32:05 +0000
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Thu, 07 Jan 2021 10:22:03 +0000
      Finished:     Thu, 07 Jan 2021 10:32:05 +0000
    Ready:          True
    Restart Count:  9
    Environment:
      ALLOW_EMPTY_PASSWORD:  yes
      MARIADB_DATABASE:      bitnami_moodle
      MARIADB_USER:          bn_moodle
      MARIADB_PASSWORD:      bitnami
    Mounts:
      /bitnami/mariadb from academy-db-claim (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-x28jh (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  academy-db-claim:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  academy-db-claim
    ReadOnly:   false
  default-token-x28jh:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-x28jh
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason          Age                  From     Message
  ----    ------          ----                 ----     -------
  Normal  Pulled          15d (x8 over 15d)    kubelet  Container image "docker.io/bitnami/mariadb:10.3-debian-10" already present on machine
  Normal  Created         15d (x8 over 15d)    kubelet  Created container academy-db
  Normal  Started         15d (x8 over 15d)    kubelet  Started container academy-db
  Normal  SandboxChanged  18m                  kubelet  Pod sandbox changed, it will be killed and re-created.
  Normal  Pulled          8m14s (x2 over 18m)  kubelet  Container image "docker.io/bitnami/mariadb:10.3-debian-10" already present on machine
  Normal  Created         8m14s (x2 over 18m)  kubelet  Created container academy-db
  Normal  Started         8m14s (x2 over 18m)  kubelet  Started container academy-db

그러나 나중에 클라이언트애플리케이션 접속에 문제가 있는 것을 알게 되었습니다.조사 결과, 팟은 동작하고 있지만, 그 안에서 동작하고 있는 mariadb 프로세스가 기동 직후에 크래쉬 했을 가능성이 있는 것이 판명되었습니다.컨테이너에 들어가면kubectl exec예를 들어 mysql 클라이언트를 실행해 보겠습니다.

kubectl  exec -it pod/academy-db-5547cdbc5-65k79 -- /bin/bash

I have no name!@academy-db-5547cdbc5-65k79:/$ mysql
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/opt/bitnami/mariadb/tmp/mysql.sock' (2)

문제의 원인이 무엇인지, 또는 어떻게 하면 문제를 더 조사할 수 있을까요?(주의: 저는 Kubernetes에 대한 전문가는 아니지만 최근에 배우기 시작했습니다.)

편집: @Novo님의 코멘트에 따라 볼륨 폴더를 삭제하고 mariadb가 처음부터 전개를 재현하도록 했습니다.이제 내 팟은 시동도 안 걸리고...CrashLoopBackOff!

포드 로그를 비교하면 이전 mariabd 로그에 다음과 같은 메시지가 있음을 알 수 있습니다.

...
mariadb 10:32:05.69 WARN  ==> The mariadb configuration file '/opt/bitnami/mariadb/conf/my.cnf' is not writable. Configurations based on environment variables will not be applied for this file.
mariadb 10:32:05.70 INFO  ==> Using persisted data
mariadb 10:32:05.71 INFO  ==> Running mysql_upgrade
mariadb 10:32:05.71 INFO  ==> Starting mariadb in background

다음으로 대체하겠습니다.

...
mariadb 14:15:57.32 INFO  ==> Updating 'my.cnf' with custom configuration
mariadb 14:15:57.32 INFO  ==> Setting user option
mariadb 14:15:57.35 INFO  ==> Installing database

호스트 vagrant 시스템의 볼륨 폴더에 대한 액세스 권한 문제와 관련된 문제일 수 있습니다.

기본적으로 hostPath 디렉토리는 kubelet 사용자 및 그룹이 소유한 권한 755로 생성됩니다.디렉토리를 사용하려면 , 다음의 항목을 전개에 추가할 수 있습니다.

  spec:
     securityContext:
       fsGroup: <gid>

여기서 gid는 컨테이너 내의 프로세스에서 사용되는 그룹입니다.

또한 컨테이너에 마운트할 폴더의 사용 권한을 변경하여 호스트 자체의 문제를 해결할 수 있습니다.

chown-R <uid>:<gid> /path/to/volume

여기서 uid와 gid는 앱의 userId와 groupId입니다.

chmod -R 777 /path/to/volume

이것으로 문제가 해결됩니다.

그러나 배포는 상태를 가질 수 없기 때문에 전체적으로 이 경우 작성하려는 배포가 아닙니다.상태 저장 앱의 경우 Kubernetes에 StatefulSets가 있습니다.Volume Claim과 함께 사용Template' + spec.securityContext.fsgroup 및 k3s는 기본 스토리지 클래스인 로컬 스토리지를 사용하여 영구 볼륨과 영구 볼륨 클레임을 생성합니다.

언급URL : https://stackoverflow.com/questions/65611027/mariadb-crashes-inside-kubernetes-pod-with-hostpath-volume