Plusieurs instances

Les instances d’un deploiement se trouvent et se parlent sur un port a elles, en TLS 1.3 dans les deux sens, admises par le certificat qu’elles partagent. Le chart Kubernetes pose tout cela des que replicaCount depasse 1.

[cluster]
listen = "0.0.0.0:8083"
peers = "dns:craft-file-gate-cluster:8083"
cert_file = "/var/lib/craft-file-gate/cluster/tls.crt"
key_file = "/var/lib/craft-file-gate/cluster/tls.key"

Toutes les cles : Reference [cluster].

Le certificat partage

Son empreinte SHA-256 est l’identite du cluster : ni nom ni date ne sont verifies, l’expiration est dite par craftfilegate_cluster_cert_not_after_seconds. Pour le changer, retirez la paire et redemarrez toutes les instances ; pendant le roulement, un pair a l’ancien certificat est certificate_mismatch.

kubectl patch secret sftp-cluster --type=json \
  -p '[{"op":"remove","path":"/data/tls.crt"},{"op":"remove","path":"/data/tls.key"}]'
kubectl rollout restart deployment/sftp

Detecteurs et retrait du service

Apres chaque tour, chaque instance juge trois detecteurs : storage_alone (un backend down ici qu’un pair joignable voit up : une panne que tous voient ne compte pas), isolated (moins de min_peers pairs joignables depuis isolated_after_secs) et isolated_and_storage_down (isolee, et chaque backend non local down ici ; un backend local, le disque du pod, ne compte pas : sans backend non local, il ne se declenche jamais). Par defaut ils alertent seulement : WARN cluster detector active, craftfilegate_unready_detector{detector}, craftfilegate_cluster_isolated, checks.cluster de /admin/health.

Nommes dans unready_when, ils retirent l’instance du service : /readyz non pret apres unready_after_secs d’un detecteur actif, pret de nouveau apres ready_after_secs sans aucun ; /livez ne bouge pas. storage_alone ne retire un pod que si un autre pod, en service et sans aucun backend en panne, voit chacun de ses backends en panne disponible, et un seul pod a la fois : si chaque pod a une panne quelque part, aucun ne part.

[cluster]
min_peers = 1                    # le chart : floor(replicaCount / 2)
unready_when = ["storage_alone", "isolated_and_storage_down"]  # le chart : auto

isolated seul peut retirer chaque pod : coupure du port du cluster, perte d’une majorite de noeuds, partage en deux moities egales, reduction manuelle du nombre de replicas. Ne le nommez qu’en connaissance de cause, et ne descendez jamais sous 2 × min_peers + 1 replicas sans helm upgrade.

Avec les defauts, une panne de stockage est vue en 35 s au pire, le retrait suit 60 s plus tard, et Kubernetes sort le pod du Service apres 3 sondes de readiness a 10 s : environ 2 min.

Ce que vous verrez

Au demarrage, INFO cluster channel listening (TLS 1.3, pinned on the shared certificate) ; a chaque pair qui repond, INFO cluster peer reachable ; par statut : craftfilegate_cluster_peers{status}. Les onglets Instances, Sessions et Bans de la console lisent chaque pair avec votre credential, qu’il juge lui-meme (scope=cluster) ; un kick va au seul pair qui tient la session, une levee a chaque pair, sauf sur une liste ConfigMap ; par appel : craftfilegate_cluster_relay_total{route,result}.

Un ban y est un garde contre les essais, pas un retrait d’acces : une adresse bannie sur un pair le lit encore a travers une autre instance avec une credential valide (une session revoquee reste refusee).