Debugging eines NoDiskConflict in kubernetes

Wir hatten einen Pod gut für etwa einen Monat, und plötzlich kann es nicht mehr geplant werden. Die Beschreibung des Pods deutet darauf hin, dass eine Festplatte voll oder anderweitig nicht verfügbar ist, aber sie ist nicht sehr spezifisch (siehe die vollständige Ausgabe der Beschreibung des Pods unten).Debugging eines NoDiskConflict in kubernetes

Ich habe bestätigt, dass die Festplatte auf diesem Knoten viel Platz (95G) hat und die GCEPersistentDisk, die es verweist, hat auch viel Platz (450G). Was kann ich sonst noch tun, damit das wieder funktioniert?

Bisher habe ich versucht, den Knoten neu zu starten und sogar den Knoten von Grund auf neu zu löschen. Dies ist ein Ein-Knoten-Cluster auf GKE.

Danke für irgendwelche Tipps!

> kubectl --namespace=bakery-production describe pods bakery-deployment-3841321805-l84nc 
Name:  bakery-deployment-3841321805-l84nc 
Namespace: bakery-production 
Node:  /
Labels:  pod-template-hash=3841321805,service=bakery 
Status:  Pending 
IP:  
Controllers: ReplicaSet/bakery-deployment-3841321805 
Containers: 
    bakery: 
    Image: gcr.io/pear-deck-production/bakery:38fda09f727493e4e88def14d49fe36883414e08 
    Port: 80/TCP 
    QoS Tier: 
     cpu: BestEffort 
     memory: BestEffort 
    Environment Variables: 
     PEARDECK_CONTAINER_REGISTRY: gcr.io/pear-deck-production 
Volumes: 
    docker-images: 
    Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine) 
    PDName: bakery-docker-images 
    FSType: ext4 
    Partition: 0 
    ReadOnly: false 
    bakery-secret-volume: 
    Type: Secret (a volume populated by a Secret) 
    SecretName: bakery-secret 
    default-token-z3ew1: 
    Type: Secret (a volume populated by a Secret) 
    SecretName: default-token-z3ew1 
Events: 
    FirstSeen LastSeen Count From   SubobjectPath Type  Reason   Message 
    --------- -------- ----- ----   ------------- -------- ------   ------- 
    20s  13s  4 {default-scheduler }   Warning  FailedScheduling pod (bakery-deployment-3841321805-l84nc) failed to fit in any node 
fit failure on node (gke-peardeck-infrastructure-0f42f748-node-qa5a): NoDiskConflict

Quelle

2016-06-03 Riley Lark

NoDiskConflict wird durch den Scheduler zurückgegeben, wenn Sie versuchen, eine Schote zu planen, die ein Volumen verweist, die bereits von einem anderen (bereits geplant) pod verwiesen wird und das Volumen nicht unterstützt mehrere Halterungen. GCE PD erlauben mehrere Mounts nur, wenn sie alle schreibgeschützt sind.

Stellen Sie sicher, dass Sie nicht mehr als einen Pod haben, der auf eine GCE PD im Lese-Schreib-Modus verweist.

Siehe https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/scheduler/algorithm/predicates/predicates.go#L105

Quelle

2016-06-03 20:59:14

Ich bin mir nicht sicher, ob ich das richtig verstehen !? Wenn wir mehrere Pods haben, die auf den PD zugreifen, müssen sie alle schreibgeschützt sein oder können sie gelesen werden - schreiben Sie dann? – pkyeck

@PhilippKeyck Wenn mehrere Pods auf dasselbe GCE PD zugreifen, muss das PD angehängt und schreibgeschützt installiert sein. –

Debugging eines NoDiskConflict in kubernetes

Antwort

Verwandte Themen