本文介紹了GKE Kubernetes MySQL輸入/輸出錯誤Ext4Error的處理方法，對大家解決問題具有一定的參考價值，需要的朋友們下面隨著小編來一起學習吧！
問題描述
我在Kubernetes分區集群上部署了一個MySQL數據庫(狀態集)，在Google Cloud平臺上作為服務(GKE)運行。
分區群集由類型為e2-Medium的3個實例組成。
由于以下錯誤，MySQL容器無法啟動。
kubectl logs mysql-statefulset-0
2022-02-07 05:55:38+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.35-1debian10 started.
find: '/var/lib/mysql/': Input/output error
上次查看的事件。
4m57s Warning Ext4Error gke-cluster-default-pool-rnfh kernel-monitor, gke-cluster-default-pool-rnfh EXT4-fs error (device sdb): __ext4_find_entry:1532: inode #2: comm mysqld: reading directory lblock 0 40d 8062 gke-cluster-default-pool-rnfh
3m22s Warning BackOff pod/mysql-statefulset-0 spec.containers{mysql} kubelet, gke-cluster-default-pool-rnfh Back-off restarting failed container
節點。
kubectl get node -owide
gke-cluster-default-pool-ayqo Ready <none> 54d v1.21.5-gke.1302 So.Me.I.P So.Me.I.P Container-Optimized OS from Google 5.4.144+ containerd://1.4.8
gke-cluster-default-pool-rnfh Ready <none> 54d v1.21.5-gke.1302 So.Me.I.P So.Me.I.P Container-Optimized OS from Google 5.4.144+ containerd://1.4.8
gke-cluster-default-pool-sc3p Ready <none> 54d v1.21.5-gke.1302 So.Me.I.P So.Me.I.P Container-Optimized OS from Google 5.4.144+ containerd://1.4.8
我還注意到rnfh節點內存不足。
kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-cluster-default-pool-ayqo 117m 12% 992Mi 35%
gke-cluster-default-pool-rnfh 180m 19% 2953Mi 104%
gke-cluster-default-pool-sc3p 179m 19% 1488Mi 52%
MySQL Mainfest
# HEADLESS SERVICE
apiVersion: v1
kind: Service
metadata:
name: mysql-headless-service
labels:
kind: mysql-headless-service
spec:
clusterIP: None
selector:
tier: mysql-db
ports:
- name: 'mysql-http'
protocol: 'TCP'
port: 3306
---
# STATEFUL SET
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql-statefulset
spec:
selector:
matchLabels:
tier: mysql-db
serviceName: mysql-statefulset
replicas: 1
template:
metadata:
labels:
tier: mysql-db
spec:
terminationGracePeriodSeconds: 10
containers:
- name: my-mysql
image: my-mysql:latest
imagePullPolicy: Always
args:
- "--ignore-db-dir=lost+found"
ports:
- name: 'http'
protocol: 'TCP'
containerPort: 3306
volumeMounts:
- name: mysql-pvc
mountPath: /var/lib/mysql
env:
- name: MYSQL_ROOT_USER
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-root-username
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-root-password
- name: MYSQL_USER
valueFrom:
configMapKeyRef:
name: mysql-config
key: mysql-username
- name: MYSQL_PASSWORD
valueFrom:
configMapKeyRef:
name: mysql-config
key: mysql-password
- name: MYSQL_DATABASE
valueFrom:
configMapKeyRef:
name: mysql-config
key: mysql-database
volumeClaimTemplates:
- metadata:
name: mysql-pvc
spec:
storageClassName: 'mysql-fast'
resources:
requests:
storage: 120Gi
accessModes:
- ReadWriteOnce
- ReadOnlyMany
MySQL存儲類清單：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: mysql-fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: Immediate
為什么Kubernetes嘗試將Pod調度到內存不足的節點？
更新
我已向MySQL清單添加了請求和限制，以改進Qos Class?，F在Qos Class為Guaranteed。
遺憾的是，Kubernetes仍在嘗試調度到內存不足rnfh節點。
kubectl describe po mysql-statefulset-0 | grep node -i
Node: gke-cluster-default-pool-rnfh/So.Me.I.P
kubectl describe po mysql-statefulset-0 | grep qos -i
QoS Class: Guaranteed
推薦答案
我又運行了幾個測試，但無法復制。
要正確回答這個問題，我們需要更多的日志。不確定你是否還留著它們。如果我能猜到哪個是這個問題的根本原因，我會說它與PersistentVolume有關。
在其中一個Github issue – Volume was remounted as read only after error #752中，我發現其行為與OP的行為非常相似。
您已經為您的MySQL創建了special存儲類。您已設置reclaimPolicy: Retain，因此未刪除PV。當StatefulsetPod(具有相同后綴-0)重新創建(由于連接錯誤、數據庫上的一些問題而重新啟動，很難說)時，它會嘗試重新認領此卷。在提到的Github問題中，用戶也有非常相似的情況。也有inode #262147: comm mysqld: reading directory lblock問題，但在下面也有條目[ +0.003695] EXT4-fs (sda): Remounting filesystem read-only?？赡茉谥匦卵b載時更改了權限？
您的volumeClaimTemplates包含的另一件事
accessModes:
- ReadWriteOnce
- ReadOnlyMany
因此，一個PersistentVolume可以被一個節點用作ReadWriteOnce，也可以被多個節點僅用作ReadOnlyMany。有可能使用Read-Only評估模式在不同節點中重新創建POD。
[ +35.912075] EXT4-fs warning (device sda): htree_dirblock_to_tree:977: inode #2: lblock 0: comm mysqld: error -5 reading directory block
[ +6.294232] EXT4-fs error (device sda): ext4_find_entry:1436: inode #262147: comm mysqld: reading directory lblock ...
[ +0.005226] EXT4-fs error (device sda): ext4_find_entry:1436: inode #2: comm mysqld: reading directory lblock 0
[ +1.666039] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal
[ +0.003695] EXT4-fs (sda): Remounting filesystem read-only
它適合OP的評論：
兩天前，由于我不知道的原因，Kubernetes重新啟動了容器，并一直嘗試在rnfa機器上運行它。容器可能已從另一個節點逐出。
另外，可能會更新節點或群集(取決于是否打開了自動更新選項)，這可能會強制重新啟動Pod。
'/var/lib/mysql/': Input/output error問題可能指向數據庫損壞，如前面提到的here。
通常，該問題已由cordoning受影響的節點解決。有關cordon和drain之間差異的其他信息，請參閱here。
與添加一樣，要將實例分配給特定節點或具有指定標簽的節點，可以使用Affinity
這篇關于GKE Kubernetes MySQL輸入/輸出錯誤Ext4Error的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，
