PowerFlex 4.X: La lentitud de la base de datos etcd causa problemas de inestabilidad en el clúster PFMP
Resumen: La lentitud de la base de datos etcd causa problemas de inestabilidad en el clúster de PowerFlex Manager Platform (PFMP).
Síntomas
Resumen:
Un clúster implementado comienza a mostrar varios reinicios de pods y puede hacer que el nodo entre en un estado no listo, lo que hace que no se pueda acceder a la interfaz de usuario de PFMP.
Escenario:
Una instancia de PowerFlex Management Platform (PFMP) implementada en una infraestructura suministrada por el cliente que tiene un almacenamiento lento y no cumple con los requisitos de almacenamiento para PFMP. Los síntomas que se muestran a continuación pueden identificar este problema. Esto puede causar problemas de estabilidad con el clúster de K8 o los miembros de la base de datos Postgres (como cambios de estado frecuentes).
En una implementación nueva, no se pueden observar problemas hasta que se active la automatización de PowerFlex Manager para implementar el clúster de PowerFlex. Varios pods pueden reiniciarse varias veces o entrar en un estado de retroceso de bucle de bloqueo (CLBO).
A continuación, se muestran los síntomas que se observan en un entorno de producción.
Ejecute el siguiente comando para ver los eventos en el clúster:
kubectl get events kubectl describe node
Eventos:
Type Reason Age From Message ---- ------ ---- ---- ------- Normal RegisteredNode 36m node-controller Node pfmp-mvm-cl1-02 event: Registered Node pfmp-mvm-cl1-02 in Controller Normal NodeNotReady 35m node-controller Node pfmp-mvm-cl1-02 status is now: NodeNotReady Normal Starting 33m kubelet Starting kubelet. Warning InvalidDiskCapacity 33m kubelet invalid capacity 0 on image filesystem Normal NodeHasSufficientMemory 33m (x2 over 33m) kubelet Node pfmp-mvm-cl1-02 status is now: NodeHasSufficientMemory Normal NodeHasNoDiskPressure 33m (x2 over 33m) kubelet Node pfmp-mvm-cl1-02 status is now: NodeHasNoDiskPressure Normal NodeHasSufficientPID 33m (x2 over 33m) kubelet Node pfmp-mvm-cl1-02 status is now: NodeHasSufficientPID Normal NodeNotReady 33m kubelet Node pfmp-mvm-cl1-02 status is now: NodeNotReady Normal NodeAllocatableEnforced 33m kubelet Updated Node Allocatable limit across pods Normal NodeReady 33m kubelet Node pfmp-mvm-cl1-02 status is now: NodeReady
A continuación, se muestra el resultado de muestra con fallas para Kubelet. Los registros se encuentran en la siguiente ruta para cada nodo:
/var/lib/rancher/rke2/agent/logs/kubelet.log Aug 04 17:12:11 pfmp-mvm-cl1-02 rke2[31392]: time="2023-08-04T17:12:11+09:00" level=debug msg="Wrote ping" Aug 04 17:12:12 pfmp-mvm-cl1-02 rke2[31392]: E0804 17:12:12.654816 31392 leaderelection.go:367] Failed to update lock: etcdserver: request timed out Aug 04 17:12:13 pfmp-mvm-cl1-02 rke2[31392]: time="2023-08-04T17:12:13+09:00" level=debug msg="Wrote ping" Aug 04 17:12:14 pfmp-mvm-cl1-02 rke2[31392]: I0804 17:12:14.526253 31392 leaderelection.go:283] failed to renew lease kube-system/rke2: timed out waiting for the condition Aug 04 17:12:16 pfmp-mvm-cl1-02 rke2[31392]: time="2023-08-04T17:12:16+09:00" level=debug msg="Wrote ping" Aug 04 17:12:17 pfmp-mvm-cl1-02 systemd[1]: run-containerd-runc-k8s.io-1ee2f8a41e076afeb4f14eb53d7faea3b1b11c59ecc44aeed0c3ee1333b07a01-runc.DLNAIb.mount: Succeeded. Aug 04 17:12:23 pfmp-mvm-cl1-02 rke2[31392]: time="2023-08-04T17:12:23+09:00" level=debug msg="Wrote ping" Aug 04 17:12:26 pfmp-mvm-cl1-02 rke2[31392]: E0804 17:12:26.235602 31392 leaderelection.go:306] Failed to release lock: Operation cannot be fulfilled on configmaps "rke2": the object has been modified; please apply your changes to the latest version and try again Aug 04 17:12:26 pfmp-mvm-cl1-02 rke2[31392]: time="2023-08-04T17:12:26+09:00" level=fatal msg="leaderelection lost for rke2
etcd loggings:
Ejecute el siguiente comando para encontrar el pod de cada etcd y extraiga los registros:
# kubectl get pods -n kube-system |grep etcd etcd-node1 1/1 Running 1 92d etcd-node2 1/1 Running 1 92d etcd-node3 1/1 Running 1 92d # kubectl logs --follow -n kube-system etcd-node1 >> etcd.txt
Iniciar sesión en etcd trozas:
2023-08-04T17:12:12.223766355+09:00 stderr F {"level":"warn","ts":"2023-08-04T08:12:12.223Z","caller":"etcdserver/util.go:166","msg":"apply request took too long","took":"16.840314464s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/operator.tigera.io/installations/\" range_end:\"/registry/operator.tigera.io/installations0\" count_only:true ","response":"","error":"etcdserver: request timed out"}
Como alternativa, también se pueden encontrar los mismos registros para cada nodo en la siguiente ruta:
/var/log/pods/kube-system_etcd-_e18aa5e5b83a5a3c56d78e4054612394/etcd
Impacto:
Esto puede provocar problemas de estabilidad en los nodos del clúster de PFMP y hacer que los pods se reinicien varias veces, lo que provoca que no se pueda acceder a la interfaz de usuario.
Causa
El comando etcd El tiempo de respuesta es sensible a la lentitud de respuesta del almacenamiento. Si el almacenamiento subyacente de los MVM no cumple con los requisitos, es posible que se observen problemas de rendimiento lento en etcd medio ambiente. Los tiempos de respuesta de almacenamiento superiores a 1 s también pueden dar lugar a varias Kubelet El proceso se bloquea. Por ejemplo, el almacenamiento que consta de unidades híbridas (HDD y SSD) puede provocar problemas de rendimiento con etcd.
Se puede ejecutar el siguiente comando para verificar la etcd rendimiento:
for x in $(kubectl get pods -n kube-system |grep etcd |awk '{print $1}') ; do echo "------------------------"; echo $x; echo;kubectl exec -it -n kube-system $x -- etcdctl check perf --cacert="/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt" --cert="/var/lib/rancher/rke2/server/tls/etcd/server-client.crt" --key="/var/lib/rancher/rke2/server/tls/etcd/server-client.key"; echo "------------------------"; echo; sleep 5; done
A continuación, se muestra el resultado de muestra de etcd Falla de rendimiento:
for x in $(kubectl get pods -n kube-system |grep etcd |awk '{print $1}') ; do echo "------------------------"; echo $x; echo;kubectl exec -it -n kube-system $x -- etcdctl check perf --cacert="/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt" --cert="/var/lib/rancher/rke2/server/tls/etcd/server-client.crt" --key="/var/lib/rancher/rke2/server/tls/etcd/server-client.key"; echo "------------------------"; echo; sleep 5; done
------------------------
etcd-sio-car-pfmp-mvm-01
60 / 60 Boooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00% 1m0s
PASS: Throughput is 144 writes/s
Slowest request took too long: 1.282354s <<<<<<<<<<<<<<<<<<<<<<<
Stddev too high: 0.151896s
FAIL
command terminated with exit code 1
------------------------
------------------------
etcd-sio-car-pfmp-mvm-02
60 / 60 Boooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00% 1m0s
PASS: Throughput is 150 writes/s
Slowest request took too long: 0.517011s
PASS: Stddev is 0.064465s
FAIL
command terminated with exit code 1
------------------------
------------------------
etcd-sio-car-pfmp-mvm-03
60 / 60 Boooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00% 1m0s
FAIL: Throughput is 138 writes/s
Slowest request took too long: 2.505517s <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Stddev too high: 0.207719s
FAIL
command terminated with exit code 1
El comando etcd La prueba de rendimiento falla si no se cumplen los siguientes parámetros:
|
Medir
|
Límite
|
|---|---|
| Rendimiento | > 140 escrituras |
| Solicitud más lenta | < 500 ms |
| Desviación estándar | < 100 ms |
Resolución
El problema no está en la versión de PFMP, sino en la manera en que se implementan las VM del clúster. El almacenamiento subyacente de los MVM debe residir localmente en el nodo donde se implementan, y las unidades deben ser al menos SSD.
Versiones
afectadas4. X
Solucionado en la versión
Ninguno