Warden — Cluster

Solo CorellixOS

Warden è un componente dell’appliance on-premise. Su Corellix Cloud le stesse responsabilità sono assolte dai servizi gestiti di Azure.

Warden è il primo servizio che parte su un nodo CorellixOS e l’ultimo di cui si può fare a meno. Gira come servizio systemd (corellix-warden.service), sotto Kubernetes: esiste perché Kubernetes possa esistere.

Di che cosa risponde

Bootstrap del cluster. Installa e configura RKE2, genera la configurazione del nodo, avvia il control plane Kubernetes.

Il VIP. Installa e mantiene l’indirizzo IP flottante del cluster. RKE2 — diversamente da distribuzioni più piccole — non include un load balancer: il VIP va installato al momento della creazione del cluster, non aggiunto dopo. È il motivo per cui non si può “aggiungere l’alta disponibilità” a un cluster nato senza.

Ingresso e uscita dei nodi. Genera i token di join, ammette i nuovi nodi, rimuove quelli dismessi, riallinea il fattore di replica dello storage al numero di nodi presenti.

Certificati. Gestisce la CA interna, emette e rinnova i certificati dei servizi e quello dell’ingress, e mantiene coerente l’elenco dei nomi che il certificato deve coprire — che cresce insieme agli hostname pubblicati dalla piattaforma.

Segreti di piattaforma. Crea, prima dell’installazione del chart, i segreti Kubernetes che i servizi consumano: credenziali del database, chiave JWT, chiave API interna, licenza, token del registro immagini.

Deploy dei servizi applicativi. Applica il chart Helm del Layer 9 passando a ciascun componente la versione da installare, per conto di CoreLCM.

Salute e recovery. Sorveglia i nodi, rileva le condizioni degradate e riporta il cluster in uno stato sano dove può farlo da solo.

Come lo si comanda

Non direttamente. Warden espone gRPC ed è raggiunto da Meridian-South, che a sua volta serve Citadel e CoreCLI.

Le operazioni che passano da Warden si fanno quindi da lì:

core cluster status          # stato del cluster e dei nodi
core cluster token create    # token per aggiungere un nodo
core cluster expand          # espansione del cluster
core cert list               # certificati e scadenze
core service status          # stato dei servizi

Certificato dell’ingress

Warden mantiene il certificato che serve gli hostname pubblici della piattaforma. L’elenco dei nomi che deve coprire è calcolato, non configurato: comprende il portale, l’API, l’endpoint degli agent, Beacon Studio, la wildcard delle console e il portale documentazione.

Quando aggiungete un hostname alla piattaforma, il certificato viene riemesso con il nome in più. Quando il certificato lo fornite voi, deve coprirli tutti: un nome mancante non degrada l’esperienza, la interrompe — un client .NET o Java rifiuta l’handshake senza chiedere conferma, a differenza di un browser. Vedi Certificati e TLS.

Riconciliazione

Warden confronta periodicamente lo stato desiderato con quello reale e corregge le differenze che può correggere: un componente non installato viene installato, un certificato in scadenza viene rinnovato, una replica mancante viene ricreata.

Questo rende un deploy interrotto ripartibile invece che da rifare, ed è il motivo per cui un’appliance che ha subito un riavvio brusco torna in genere da sola in uno stato sano.