Enterprise’s adoption of containers has become mainstream, and Kubernetes is the default container management platform of choices across enterprises. Also, Enterprises have adopted a variety of Kubernetes flavors. Popular flavors of Kubernetes include RedHat OpenShift and Kubernetes provided by Cloud Service providers such as AWS EKS, Azure AKS, and GCP GKE.
Spinnaker, an open-source project from Netflix, has quickly evolved as one of the leading multi-cloud scalable continuous delivery tools of choice. Enterprises are increasingly considering Spinnaker for automating and simplifying their Kubernetes applications deployments.
Spinnaker provides self-service for developers via pipeline-as-code and templates for deploying applications. Spinnaker shines in its ability to support deployments across multiple clusters with full visibility for the deployed applications. Enterprises can enable governance and policy control with an audit trail using commercial solutions like OpsMx Enterprise.
Challenges with Deploying to Kubernetes Anywhere with Spinnaker
In a typical enterprise, each development group has one or more Kubernetes clusters to deploy their applications. Spinnaker is installed in a shared services cluster with full access to those target Kubernetes clusters. Spinnaker needs a privileged access to deploy applications and retrieve the deployed application status or perform scale-up/down or rollback functions.
However, we see an increasing need for the Spinnaker to connect to the Kubernetes cluster from a different security domain. This requirement typically arises as development teams deploy their Kubernetes clusters independently or if the enterprise adopts Spinnaker SaaS service (like OpsMx Cloud). Private VPC or private cloud’s standard security policy prevents externally initiated connections. In this case, it means centralized or SaaS Spinnaker can not communicate with the Kubernetes clusters.
The below figures depict the above scenarios.
The above constraint limits the architecture choices of the location of Spinnaker or Kubernetes clusters that it can deploy. It also eliminates the ability to adopt SaaS Spinnaker.
Another big security challenge with the current Spinnaker support of Kubernetes is that Spinnaker needs the credentials for privileged access to each of the Kubernetes clusters where it deploys applications. The Kubernetes cluster admins also can’t easily revoke these credentials.
OpsMx Kubernetes Anywhere Agent Solution for Spinnaker
To address these security challenges and also allowing Spinnaker to deploy to private Kubernetes clusters, OpsMx has created the Kubernetes Anywhere agent.
Kubernetes Anywhere agents are deployed in target Kubernetes clusters, and it establishes a secure connection to the central/SaaS Spinnaker services.
Benefits of the solution include:
- Allows Spinnaker to deploy to Kubernetes anywhere – private VPC or private cloud.
- Allows adoption of Spinnaker SaaS – OpsMx Cloud.
- Eliminates the need for configuring Spinnaker with the credentials of each of the Kubernetes clusters. Cluster admins can also remove permissions for Spinnaker independently if needed.
- Kubernetes cluster dynamically self-registers with the Spinnaker avoiding the need to restart Spinnaker for each Kubernetes account addition.
The below figure depicts possible deployment options of Spinnaker and Kubernetes clusters.
If you are interested in this solution, contact us, and we would be happy to help you with Spinnaker scaling and deployments with Kubernetes or other public clouds.