Eu tenho o seguinte StorageClassdefinido para aws ekscluster (3 nós)
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: aws-gp2
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
zones: us-west-2a, us-west-2b, us-west-2c, us-west-2d
fsType: ext4
reclaimPolicy: Retain
allowVolumeExpansion: true
e ter eksnós em execução em us-west-2a, us-west-2b, us-west-2czonas.
Quando estou tentando implantar mysqlcom volume persistente dinâmico
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mysql-pv-claim
namespace: default
labels:
app: mysql
env: prod
spec:
storageClassName: aws-gp2
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
---
kind: Deployment
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
metadata:
name: mysql
namespace: default
labels:
app: mysql
env: prod
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: root-password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
Mas o pod não vai além do Pendingstatus.
O log de eventos do pod diz:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 8s (x7 over 20s) default-scheduler pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
Warning FailedScheduling 8s (x2 over 8s) default-scheduler 0/3 nodes are available: 3 node(s) had volume node affinity conflict.
Não estou entendendo por que o pod não consegue montar o PVC.
Eu adicionei mais 1 nó ao cluster eks, para que todos os 4 nós possam abranger 4 az e, em seguida, reimplante mysqle funcionou. Ainda não sei qual foi o verdadeiro problema.
Sim, eu sei que isso já foi discutido milhões de vezes e estou respondendo 2 anos depois da sua pergunta. Muito provavelmente você já esqueceu essa pergunta, mas a comunidade lembra de tudo.
Resposta da comunidade para as próximas gerações...
Tudo já foi discutido em uma pergunta de pilha semelhante Aviso de pod do Kubernetes: 1 nó(s) teve conflito de afinidade de nó de volume
Resposta de @Sownak Roy : Completo, sem minhas modificações. Eles simplesmente não precisam de lá ..
O erro "conflito de afinidade do nó de volume" ocorre quando o volume persistente afirma que o pod está sendo agendado em zonas diferentes, em vez de em uma zona e, portanto, o pod real não pôde ser agendado porque não pode se conectar ao volume de outra zona. Para verificar isso, você pode ver os detalhes de todos os Volumes Persistentes. Para verificar isso, primeiro pegue seus PVCs:
Em seguida, obtenha os detalhes dos volumes persistentes (não das reivindicações de volume)
Encontre os PVs que correspondem aos seus PVCs e descreva-os
Você pode verificar o Source.VolumeID para cada um dos PV, provavelmente serão zonas de disponibilidade diferentes, e assim seu pod dá o erro de afinidade. Para corrigir isso, crie uma classe de armazenamento para uma única zona e use essa classe de armazenamento em seu PVC.