Continuous Delivery of HashiCorp Vault on Google Kubernetes Engine: Kubernetes Architecture
This is Part 3 of a series: Index
Overview:
The Kubernetes cluster is broken up into a few custom namespaces to separate out operational services from application services. Kubernetes also has several different resource types I will use across the services and applications. Below are some of the notable resource types in use in the cluster.
StatfulSets: The primary reason I use a StatefulSet for the application is to dealing with ordering since we do not want Vault fighting over who initializes first. It also provides predictable names to the PODs.
- Also worth noting the concept of anti-affinity here which spreads the PODs across all the nodes in the cluster. In this case keeping an instance of the Vault server running in each zone across the region.
Deployments: I use Deployments for the operational services. Deployments have some advantages around rolling back and just a more managed configuration.
Ingress (v1beta1) : Specifically I use ingress-gce to to create an external GCP HTTP(S) Load Balancer for the application.
Containers:
Containers (will be) stored “locally” in Google Container Registry and analyzed by Container Analysis for security vulnerabilities.
Application
vault: Vault is the app for securely accessing secrets and config.
vault-init: Used for automate the process of initializing and unsealing Vault.
Operational Services
external-dns: Used to synchronize and expose Kubernetes ingress with Google Cloud DNS.
cert-manager: Used to automate the management and issuance of TLS certificates.
