ZeusK8s
Un DNS qui prouve sa santé

Votre plan de failover, c'est un enregistrement DNS que vous n'avez jamais testé.

Pour la plupart des équipes, le failover inter-régions c'est un enregistrement pondéré, un health check configuré une fois, et de l'espoir. ZeusK8s donne à chaque service un seul nom sur chaque cluster — health-checké de l'intérieur et de l'extérieur, et rerouté en moins d'une seconde quand quelque chose casse vraiment.

Route 53 et Cloud DNS sont excellents — dans leur propre cloud.

Les produits DNS managés et de health check d'AWS et Google sont vraiment bons. C'est aussi comme ça qu'on reste lock-in : les enregistrements, les health checks et la logique de failover vivent tous dans la console d'un seul fournisseur, câblés à l'infrastructure de ce fournisseur. Le jour où vous devez faire passer du trafic entre GCP et AWS — ou vers votre propre matériel — est le jour où ils cessent d'aider.

Faire tourner sa propre couche de routage globale a traditionnellement signifié un travail de spécialiste, ou un traffic manager tiers cher assis devant tout.

Zeus le fait pour vous. Une couche de routage sur chaque cloud et chaque cluster que vous possédez, avec monitoring de santé automatique et routage de failover intégrés — en utilisant Route 53 ou Cloud DNS en dessous comme simples registries, jamais comme le cerveau.

Global fabric
AWS · GCP · private cloud · self-healing
Maillage sain
pdx-prodAWS · us-west-2sjc-prodAWS · us-west-1den-edgeProxmox · private clouddfw-prodGCP · us-south1oma-prodGCP · us-central1chs-prodGCP · us-east1iad-prodAWS · us-east-1
Sept clusters, un seul système
AWS, GCP et votre propre matériel — chaque requête servie par la région saine la plus proche.
Endpoints globaux

Un nom pour un service, peu importe quel cluster répond.

Un nom, chaque cluster

Donnez à un service ou une base un seul nom stable sur tous vos clusters. Routez par latence, par poids, ou unissez les cibles saines entre clusters — sans écrire à la main les règles DNS du fournisseur.

Failover en moins d'une seconde

Les décisions de routage sont poussées vers chaque cluster dès que la santé change — vous n'attendez pas l'expiration des TTL ni la propagation de reloads de config. Le trafic bouge avant que vos utilisateurs ne le remarquent.

Health checks, dedans et dehors

Des probes TCP, UDP, HTTP/S et Kubernetes locales surveillent chaque cible depuis l'intérieur du cluster. Des probers indépendants dans plusieurs régions vérifient vos endpoints publics de l'extérieur et s'accordent par quorum — pour que « up » signifie réellement atteignable, pas juste en train de tourner.

Fail safe, pas silencieux

Quand l'état est ambigu, Zeus répond fail-closed au lieu de pointer le trafic vers une cible morte. Chaque cluster garde son dernier routage known-good sur disque, pour que la résolution continue de marcher même si le plan de contrôle est injoignable.

Fonctionne avec le maillage

La même couche de routage couvre le trafic privé inter-clusters sur le maillage chiffré et le trafic public sur vos domaines. Un seul modèle mental pour les deux.

Domaines & TLS inclus

Apportez vos domaines, obtenez des certificats automatiques et du DNS white-label par marque par-dessus — même plan de contrôle, pas d'outillage supplémentaire.

Related: réseau inter-clusters · domaines, certificats & white-label

La partie dont personne n'est confiant

Le failover DNS marche soit par accident, soit c'est le bazar que plus personne ne veut toucher.

À quoi ça ressemble d'habitude
  • · Enregistrements pondérés écrits à la main dans une console fournisseur configurée une fois
  • · Health checks qui testent le load balancer, pas l'application derrière
  • · Un failover qui n'a jamais été exercé hors d'une vraie panne
  • · Chaque changement fait avec précaution, parce que plus personne n'est sûr de ce qui dépend de quoi
À quoi ça ressemble dans Zeus
  • · Endpoints, cibles et politiques de santé définis en un seul endroit, visibles par toute l'équipe
  • · Un aperçu exact de ce que chaque région résout, avant d'appliquer
  • · Verdicts de santé depuis l'intérieur du cluster et depuis des probers externes indépendants
  • · Un failover qui tourne de la même façon à chaque fois — parce qu'il tourne en continu

Vérifiez que votre failover marche avant qu'une panne ne le fasse.

Book a demo