Utilisation de VirtualBox et de 4 installations de système d'exploitation Centos7.
Suite à une installation de base de Kubernetes sur un seul cluster:
https://kubernetes.io/docs/setup/independent/install-kubeadm/ https://kubernetes.io/docs/setup/independent/create-cluster -kubeadm /
[root@k8s-slave1 kubernetes]# kubectl logs cockroachdb-0 ++ hostname -f + exec /cockroach/cockroach start --logtostderr --insecure --advertise-host cockroachdb-0.cockroachdb.default.svc.cluster.local --http-host 0.0.0.0 --join cockroachdb-0.cockroachdb,cockroachdb-1.cockroachdb,cockroachdb-2.cockroachdb --cache 25% --max-sql-memory 25% W190113 17:00:46.589470 1 cli/start.go:1055 RUNNING IN INSECURE MODE! - Your cluster is open for any client that can access <all your IP addresses>. - Any user, even root, can log in without providing a password. - Any user, connecting as root, can read or write any data in your cluster. - There is no network encryption nor authentication, and thus no confidentiality. Check out how to secure your cluster: https://www.cockroachlabs.com/docs/v2.1/secure-a-cluster.html I190113 17:00:46.595544 1 server/status/recorder.go:609 available memory from cgroups (8.0 EiB) exceeds system memory 3.7 GiB, using system memory I190113 17:00:46.600386 1 cli/start.go:1069 CockroachDB CCL v2.1.3 (x86_64-unknown-linux-gnu, built 2018/12/17 19:15:31, go1.10.3) I190113 17:00:46.759727 1 server/status/recorder.go:609 available memory from cgroups (8.0 EiB) exceeds system memory 3.7 GiB, using system memory I190113 17:00:46.759809 1 server/config.go:386 system total memory: 3.7 GiB I190113 17:00:46.759872 1 server/config.go:388 server configuration: max offset 500000000 cache size 947 MiB SQL memory pool size 947 MiB scan interval 10m0s scan min idle time 10ms scan max idle time 1s event log enabled true I190113 17:00:46.759896 1 cli/start.go:913 using local environment variables: COCKROACH_CHANNEL=kubernetes-insecure I190113 17:00:46.759909 1 cli/start.go:920 process identity: uid 0 euid 0 gid 0 egid 0 I190113 17:00:46.759919 1 cli/start.go:545 starting cockroach node I190113 17:00:46.762262 22 storage/engine/rocksdb.go:574 opening rocksdb instance at "/cockroach/cockroach-data/cockroach-temp632709623" I190113 17:00:46.803749 22 server/server.go:851 [n?] monitoring forward clock jumps based on server.clock.forward_jump_check_enabled I190113 17:00:46.804168 22 storage/engine/rocksdb.go:574 opening rocksdb instance at "/cockroach/cockroach-data" I190113 17:00:46.828487 22 server/config.go:494 [n?] 1 storage engine initialized I190113 17:00:46.828526 22 server/config.go:497 [n?] RocksDB cache size: 947 MiB I190113 17:00:46.828536 22 server/config.go:497 [n?] store 0: RocksDB, max size 0 B, max open file limit 60536 W190113 17:00:46.838175 22 gossip/gossip.go:1499 [n?] no incoming or outgoing connections I190113 17:00:46.838260 22 cli/start.go:505 initial startup completed, will now wait for `cockroach init` or a join to a running cluster to start accepting clients. Check the log file(s) for progress. I190113 17:00:46.841243 22 server/server.go:1402 [n?] no stores bootstrapped and --join flag specified, awaiting init command. W190113 17:01:16.841095 89 cli/start.go:535 The server appears to be unable to contact the other nodes in the cluster. Please try: - starting the other nodes, if you haven't already; - double-checking that the '--join' and '--listen'/'--advertise' flags are set up correctly; - running the 'cockroach init' command if you are trying to initialize a new cluster. If problems persist, please see https://www.cockroachlabs.com/docs/v2.1/cluster-setup-troubleshooting.html. I190113 17:01:31.357765 1 cli/start.go:756 received signal 'terminated' I190113 17:01:31.359529 1 cli/start.go:821 initiating graceful shutdown of server initiating graceful shutdown of server I190113 17:01:31.361064 1 cli/start.go:872 too early to drain; used hard shutdown instead too early to drain; used hard shutdown instead
J'ai créé 3 x PV NFS sur le maître pour que mes esclaves les récupèrent dans le cadre du fichier cockroachdb-statefulset.yaml comme décrit ici:
https://www.cockroachlabs.com/ blog / running-cockroachdb-on-kubernetes /
Cependant, mes POD de cafards ne parviennent pas à communiquer entre eux.
[root@k8s-slave1 kubernetes]# kubectl get pods NAME READY STATUS RESTARTS AGE cockroachdb-0 0/1 CrashLoopBackOff 6 8m47s cockroachdb-1 0/1 CrashLoopBackOff 6 8m47s cockroachdb-2 0/1 CrashLoopBackOff 6 8m47s [root@k8s-slave1 kubernetes]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE datadir-cockroachdb-0 Bound cockroachdbpv0 10Gi RWO 17m datadir-cockroachdb-1 Bound cockroachdbpv2 10Gi RWO 17m datadir-cockroachdb-2 Bound cockroachdbpv1 10Gi RWO 17m
. ..les journaux de pod de cafards ne me disent pas vraiment pourquoi ...
[root@k8s-master cockroach]# kubectl get nodes NAME STATUS ROLES AGE VERSION k8s-master Ready master 41m v1.13.2 k8s-slave1 Ready <none> 39m v1.13.2 k8s-slave2 Ready <none> 39m v1.13.2 k8s-slave3 Ready <none> 39m v1.13.2
... des idées pour déboguer cela davantage?
3 Réponses :
J'ai parcouru le fichier * .yaml à https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/cockroachdb-statefulset.yaml
J'ai remarqué que vers le bas, il n'y a pas de storageClassName mentionné, ce qui signifie que pendant le processus de revendication de volume, les pods vont rechercher une classe de stockage standard.
Je ne sais pas si vous avez utilisé l'annotation ci-dessous lors de l'approvisionnement de 3 volumes NFS -
kubectl describe cockroachdb-{statefulset}
Vous devriez pouvoir vérifier la même chose en utilisant -
kubectl get storageclass
Si la sortie n'affiche pas la classe de stockage Standard , je suggérerais de réajuster les définitions de volumes persistants en ajoutant une annotation ou d'ajouter une chaîne vide comme storageClassName vers la fin du fichier cafard-statefulset.yaml
Plus de journaux peuvent être consultés en utilisant -
storageclass.kubernetes.io/is-default-class=true
Merci. Je ne suis pas convaincu que ce soit un problème de stockage car chaque statefulset de cafard lié à un pv et vérifiant le système de fichiers, je peux voir que le cafard a créé ses fichiers et répertoires par défaut. La description me montre simplement les mêmes messages de journaux que ci-dessus. Je me demande s'il est possible d'ajouter de la verbosité à la commande de démarrage de cafard. Je vais vérifier cela.
Pour info, j'ai fait un test en changeant mon PV pour avoir un stroageClassName de "mypv" et en utilisant ensuite cette même définition dans la spécification du statefulset. Encore une fois, cela a bien fonctionné et les gousses de cafards se sont liées aux PV. Les PODS continuent de planter :(
OK, cela se résumait au fait que j'avais NAT comme adaptateur réseau externe de virtualbox. Je l'ai changé en Bridged et tout a commencé à fonctionner parfaitement. Si quelqu'un peut me dire pourquoi, ce serait génial :)
Dans mon cas, en utilisant le graphique de barre, comme ci-dessous:
$ kubectl get csr -o json | \
jq -r '.items[] | select(.metadata.name | contains("cockroach.")) | .metadata.name' | \
xargs -n 1 kubectl certificate approve
Après avoir attendu pour terminer l'ajout de csr pour cafard:
$ kubectl get csr NAME AGE REQUESTOR CONDITION cockroachdb.client.root 130m system:serviceaccount:cockroachdb:cockroachdb-cockroachdb Pending cockroachdb.node.cockroachdb-cockroachdb-0 130m system:serviceaccount:cockroachdb:cockroachdb-cockroachdb Pending cockroachdb.node.cockroachdb-cockroachdb-1 129m system:serviceaccount:cockroachdb:cockroachdb-cockroachdb Pending cockroachdb.node.cockroachdb-cockroachdb-2 130m system:serviceaccount:cockroachdb:cockroachdb-cockroachdb Pending
Plusieurs Les csr sont en attente:
$ watch kubectl get csr
Pour approuver cette exécution, suivez la commande:
$ helm install stable/cockroachdb \ -n cockroachdb \ --namespace cockroach \ --set Storage=10Gi \ --set NetworkPolicy.Enabled=true \ --set Secure.Enabled=true
Je peux me connecter au conteneur docker créé pour le cafard, mais le crash entraîne sa recréation dans les 20 secondes, ce qui m'empêche de rechercher les problèmes.