Wanneer je je applicatie of database bij Kinsta host, draaien je projecten op de top-infrastructuur van Google Cloud Platform. In deze gids leggen we een en ander uit over de infrastructuur van onze Applicatie Hosting en Database Hosting.
Deployment
Git repository
De code van je applicatie wordt opgeslagen in een Git repository. Je kunt kiezen uit een (of alle) van de volgende:
MyKinsta applicatie toevoegen/deployen
In MyKinsta wordt, wanneer je een applicatie toevoegt, verbinding gemaakt met de Git repository om de applicatie op te halen.
MyKinsta bot
Als je Automatic deployment on commit hebt ingeschakeld in de instellingen van je applicatie, detecteert de MyKinsta bot dit als je een wijziging of merge in je repository commit, waarna hij de applicatie van je Git service provider pullt en de bijgewerkte versie van de applicatie deployt.
Google Cloud Build
MyKinsta stuurt de applicatie naar Google Cloud Build om vanuit de code een image van de applicatie te bouwen. Deze weet welke applicaties of modules voor de applicatie geïnstalleerd moeten worden uit de informatie in de buildpacks of het Dockerbestand. De output is een image dat in een container kan worden omgezet.
Google Artifact Register
Hierin worden de container images opgeslagen die klaar zijn om te deployen. Elke applicatie heeft een enkel image dat kan worden gebruikt wanneer het moet worden gedeployt.
Kubernetes Cluster
Het image uit het artifact register wordt naar het cluster gepusht. Dit is een virtuele machine (VM) waar meerdere containers kunnen draaien. De clusters worden zo afgestemd dat het verzoek van het Artifact Register de juiste container vindt, de containers goed draaien, en ze over de juiste resources beschikken. Als er problemen zijn met een container, wordt de applicatie opnieuw gedeployt in een andere container. We gebruiken cri-o v1.23.x op onze infrastructuur; deze versie is echter niet statisch en kan worden geüpgraded bij het upgraden van verschillende componenten in de stack.
Onze Kubernetes infrastructuur ondersteunt een multi-tenant opstelling, waarbij elke applicatie in zijn eigen gecontaineriseerde omgeving draait. Netwerkisolatie en meerlaagse virtualisatie zorgen voor veiligheid en voorkomen ongeautoriseerde toegang tussen applicaties. Dit ontwerp biedt je een betrouwbaar en veilig hostingplatform, waardoor jij je kunt richten op je kernactiviteiten, terwijl wij de onderliggende infrastructuur verzorgen. Wij deployen ten minste één cluster per regio, met het potentieel voor extra clusters op basis van het aantal applicaties in elke regio. Dit systeem zorgt voor een optimale toewijzing van resources en schaalbaarheid om te voldoen aan de groeiende behoeften van onze klanten.
Verzoeken
Cloudflare
Wanneer een bezoeker toegang zoekt tot de website van een applicatie, gaat deze eerst naar Cloudflare, die weet welk cluster de website host. Het stuurt vervolgens het verzoek om toegang naar de juiste cluster.
Momenteel bevat Cloudflare voor Applicatie Hosting en Database hosting de standaard firewallregels, de standaard DDoS bescherming, en andere defaults.
Cloud Load Balancing
Elk cluster heeft een loadbalancer die het toegangsverzoek van Cloudflare ontvangt en willekeurig een VM worker node pusht.
Ingress
Het VM worker node ontvangt het verzoek op het Ingress systeem, dat weet welke container verantwoordelijk is voor de aangevraagde hostnaam. Het Ingress systeem stuurt het verzoek naar de juiste container, en als de container een database heeft gekoppeld, communiceert het met de database en stuurt een antwoord op dezelfde route.
Virtuele Machines (VM)
Een virtuele machine (VM) kan meerdere containers en meerdere databases bevatten.
Containers
Elke container of applicatie kan meerdere kopieën op de VM hebben. In dit geval weet het Ingress systeem dit en stuurt willekeurig een van de kopieën van dezelfde container door.