Private Kubernetes Deployment for Autonomous Reliability Infrastructure
Run Zof execution-compatible agents in customer-managed Kubernetes clusters. Control plane and execution plane stay separable; Zof does not claim to install a full Kubernetes platform for you.
Cluster gestiti dal cliente
Separazione tra piano di controllo ed esecuzione
Pattern di isolamento dei namespace
Compatibile con modelli ibridi e in enclave
Perché le aziende richiedono l'orchestrazione privata
Molti team adottano già Kubernetes come standard per le piattaforme interne. Zof supporta la collocazione dell'esecuzione in quei cluster senza richiedere di abbandonare gli investimenti già fatti in orchestrazione.
- -Standard di cluster esistenti e pipeline GitOps
- -Gestione di nodi e rete a carico del platform team
- -Necessità di mantenere i workload sensibili al di fuori dell'esecuzione SaaS multi-tenant
- -Ambienti regolamentati con isolamento a livello di namespace
Eseguire l'infrastruttura di esecuzione in cluster gestiti dal cliente
Gli agent di esecuzione possono essere distribuiti come workload nei cluster che gestisci. La pianificazione e le approvazioni possono essere eseguite su piani di controllo in cloud, private cloud o on-prem a seconda delle policy.
- -Agent schedulati come gli altri servizi interni
- -Compatibili con i CNI e i policy engine del cliente
- -Nessun requisito di accesso in entrata al cluster
- -Supporta nel tempo flotte multi-cluster
Separazione tra piano di controllo e piano di esecuzione
Il piano di controllo gestisce policy, contesto del graph, approvazioni e scheduling. Il piano di esecuzione esegue le capsule firmate sulle applicazioni all'interno del cluster o delle reti connesse.
Esecuzione su Kubernetes privato
Agenti compatibili con l'esecuzione in cluster gestiti dal cliente, non un'installazione completa della piattaforma.
- -Confine chiaro per la revisione di sicurezza
- -I dati di runtime sensibili restano nei namespace di esecuzione
- -Le API del piano di controllo non eseguono direttamente i test sulle app protette
- -Le suddivisioni ibride sono comuni nei rollout enterprise
Agent di esecuzione Kubernetes
Gli agent sono progettati per essere compatibili con il Kubernetes del cliente, non per sostituire il tuo platform team. Dimensionamento, HA e aggiornamenti seguono gli standard del tuo cluster.
- -Distribuzione tramite manifest o operator approvati dal cliente
- -Limiti di risorse e pod security policy rispettati
- -Identità dei runner e allowlist per gli host di esecuzione
- -Rollout graduali per namespace o cluster
Confini di esecuzione sicuri
Namespace, network policy e service account isolano l'esecuzione dai workload non correlati. I segreti vengono montati a runtime, non archiviati in Zof Cloud.
- -RBAC con ambito di namespace
- -Integrazione con secrets manager esterni dove supportata
- -Allineamento opzionale con la service mesh
- -Audit degli eventi del ciclo di vita degli agent
Test di applicazioni solo interne
Convalida microservizi, API interne e UI di amministrazione raggiungibili dalle reti del cluster senza esporli alla rete internet pubblica.
- -Test service-to-service all'interno del cluster
- -Solo ingress dove le policy lo consentono
- -Abbinabile a edge runner per i sistemi legacy off-cluster
- -Il targeting basato sul graph riduce il rumore
Isolamento dei namespace
I team associano unità di business o ambienti ai namespace con policy, conservazione e modalità di evidenza distinte.
- -Separazione tra dev, staging e prod
- -Quote per team e limiti di concorrenza
- -Archivi di evidenze con ambito di namespace
- -Flussi di promozione tra namespace
Gestione dei segreti
Le credenziali vengono mediate al momento dell'esecuzione tramite PAM o integrazioni con i secret del cluster. Per impostazione predefinita, i segreti a lunga durata non vengono copiati su SaaS esterni.
- -Token a breve durata preferiti
- -Pattern compatibili con PAM
- -Nessuna persistenza dei segreti nel piano di pianificazione senza approvazione
- -Rotazione allineata ai tuoi standard
Routing degli artefatti
Gli artefatti di test e i bundle restano nello storage controllato dal cliente, a meno che non configuri l'egress sanitizzato o solo-metadati.
Architettura di esecuzione ibrida
Orchestrazione nel cloud con flotte di esecuzione locali distribuite.
- -Volumi S3-compatibili, NFS o on-cluster
- -Policy di conservazione per namespace
- -Checksum e firma per i bundle
- -Promozione opzionale verso un catalogo centrale delle evidenze
Confini della telemetria
Le metriche e i log degli agent possono restare negli stack di observability in-cluster. Le dashboard centrali possono ricevere riepiloghi con soli metadati.
- -Pattern compatibili con OpenTelemetry dove supportati
- -Redazione prima dell'esportazione oltre i confini
- -ID di correlazione per l'audit
- -Nessuna esfiltrazione obbligatoria dei log completi
Governance enterprise
La firma delle capsule, l'approvazione umana e i gate di remediation si applicano in modo uniforme, sia che l'esecuzione avvenga su VM, bare metal o Kubernetes.
- -Versione della policy ancorata alle esecuzioni
- -Catene di approvazione per i percorsi di produzione
- -Integrazione con i record di change ITSM
- -Esportazione per GRC e audit interno
Pattern di architettura ibrida
L'esecuzione Kubernetes spesso coesiste con runner VPC, siti edge e agent endpoint sotto un unico piano di controllo.
- -Graph unico e orchestrazione della flotta
- -Modello di capsule coerente su tutte le superfici
- -Policy di evidenza per superficie
- -L'architecture review definisce l'ordine di rollout
Domande sul deployment on-prem
Domande frequenti dai team di infrastruttura e sicurezza.
Discuti il deployment sicuro con Zof
Esamina la segmentazione, la governance delle capsule e il posizionamento dei runner con team che supportano le imprese regolamentate.
