2015-11-12 4 views
2

Je suis en train de mettre en place un petit cluster Kubernetes en utilisant un VM (maître) et 3 serveurs bare metal (tous sous Ubuntu 14.04). J'ai suivi les Kubernetes install tutorial for Ubuntu. Chaque serveur bare metal dispose également de 2 To d'espace disque exporté en utilisant Ceph 0.94.5. Tout fonctionne très bien, mais quand je tente de démarrer un contrôleur de réplication je reçois les suivantes (kubectl obtenir gousses):Kubernetes pod ne se prépare jamais

NAME   READY  STATUS           RESTARTS AGE 
site2-zecnf 0/1  Image: site-img is ready, container is creating 0  12m 

La nacelle sera dans cet état Non prêt pour toujours, mais, si je le tue et le démarrage Encore une fois, ça fonctionnera bien (parfois je dois répéter cette opération quelques fois). Une fois que le pod fonctionne, tout fonctionne correctement.

Si, pour une raison quelconque, le module meurt, il est redémarré par Kubernetes, mais peut à nouveau entrer dans cet état Non prêt. Exécution:

kubectl describe pod java-site2-crctv 

Je reçois (certains champs supprimés):

Namespace:   default 
Status:    Pending 
Replication Controllers: java-site2 (1/1 replicas created) 
Containers: 
    java-site: 
    Image:  javasite-img 
    State:  Waiting 
     Reason:  Image: javasite-img is ready, container is creating 
    Ready:  False 
    Restart Count: 0 
Conditions: 
    Type  Status 
    Ready  False 
Events: 
    FirstSeen    LastSeen   Count From   SubobjectPath Reason  Message 
    Sat, 14 Nov 2015 12:37:56 -0200 Sat, 14 Nov 2015 12:37:56 -0200 1 {scheduler }    scheduled Successfully assigned java-site2-crctv to 10.70.2.3 
    Sat, 14 Nov 2015 12:37:57 -0200 Sat, 14 Nov 2015 12:45:29 -0200 46 {kubelet 10.70.2.3}   failedMount Unable to mount volumes for pod "java-site2-crctv_default": exit status 22 
    Sat, 14 Nov 2015 12:37:57 -0200 Sat, 14 Nov 2015 12:45:29 -0200 46 {kubelet 10.70.2.3}   failedSync Error syncing pod, skipping: exit status 22 

La nacelle ne peut pas monter le volume. Mais, si je monte les volumes (blocs rdb) à la main dans un dossier local dans tous les noeuds, le problème est parti (les pods démarrent sans problèmes).

Il me semble que Kubernetes n'est pas capable de les mapper (sudo rbd map java-site-vol), seulement pour les monter (sudo mount /dev/rbd/rbd/java-site-vol /...). Dois-je cartographier tous les volumes de Ceph que j'utilise ou est-ce que Kubernetes devrait faire cela?

+0

Avez-vous essayé d'exécuter 'kubectl describe pod' sur le pod à l'état Non prêt? Il peut être clair à partir du flux d'événements pour le pod ce qui l'empêche de s'exécuter. Alternativement, vous devriez regarder '/ var/log/kubelet.log' sur l'hôte où le pod est bloqué dans l'état Non Prêt pour voir s'il y a quelque chose d'intéressant dans les journaux. –

+0

J'ai exécuté la commande et mis à jour la question. Merci. – dilvan

+0

J'ai rencontré un problème similaire: je crois qu'il est lié à un bogue en cours, où un conteneur défaillant ne redémarrera pas s'il se trouve sur le même nœud que celui sur lequel il a démarré, car le support de stockage d'origine n'est pas disponible sur un noeud différent. – MrE

Répondre

2

J'ai finalement résolu le problème. Dans les fichiers YAML décrivant les contrôleurs de réplication, j'utilisais keyring: dans la section de volume:

keyring: "ceph.client.admin.keyring" 

Après avoir generated a Ceph secret et changé les fichiers YAML à utiliser secretRef:

secretRef: 
    name: "ceph-secret" 

Kubernetes a pu cartographier et monter les volumes de Ceph et les gousses ont commencé à démarrer normalement. Je ne sais pas pourquoi utiliser keyring: ne fonctionne pas dans ce cas.

+0

Pouvez-vous accepter cela comme réponse. Cela aidera les autres utilisateurs ayant le même problème. – Faizan