Continuous delivery, Spinnaker, and Kubernetes

Continuous delivery is a hot topic these days, mostly because of the DevOps movement which aims to improve collaboration among different people involved in the process of software delivery, by embracing automation and constant communication.

Continuous Integration (CI) is related to the set of stages after which the final product is a deployable artifact, for example, a docker container. CI is something you would normally implement with a continuous integration server such Jenkins.

The continuous delivery process (CD) should take care of validation and deployment of the artifact through the different environments (e.g. QA, Staging, Production) in a reliable and repeatable way.

Spinnaker is a tool for Continuous Delivery. It aims to provide the means for defining a delivery pipeline to different cloud providers (e.g. AWS, Google Cloud, k8s), defining best practices which are transparently translated to those providers infrastructure. That includes; security, monitoring, load balancing, clusters and so on.

Kubernetes provides a great platform for software/containers orchestration. It aims to be a software platform on top of your infrastructure allowing you to solve common problems (networking, scaling, monitoring, orchestration) with help of its great API. It is up to us to decide which Kubernetes tools to use, which might be selecting from a wide array of available options or implementing them by ourselves.

Everything is about the process

There’s something I have learned during these years working with software infrastructure «Everything is about the process». You could have selected or implemented tools using the greatest and latest technologies, but no one will want or know how to use them if you do not define and document a decent process to put some order over the potential chaos. I think that does not apply just to technology but in general when working with groups of people.

Talking about Continuous Delivery, Spinnaker is a great tool for defining delivery processes, it will allow you to orchestrate the delivery process with the multiple existing steps in an explicit way, by defining Pipelines, and administering your infrastructure easily for different providers.

Spinnaker Pipelines

From the spinnaker documentation: Pipelines are your way of managing deployments in a consistent, repeatable and safe way.

I was talking about how important the process is, Pipelines are the Spinnaker means for defining processes explicitly. You can define different types of stages, from functions to manipulate infrastructure (deploy, resize, disable) and utility functions (manual judgment, wait, run a Job) with the goal of deploying an artifact to one of your environments.

Pipelines UI

You can learn more about Pipelines here: https://www.spinnaker.io/concepts/pipelines/

Spinnaker Concepts/Abstractions and how they map to Kubernetes

Concepts

One of the things I enjoy the most about Spinnaker is that it abstracts multiple elements of the infrastructure and deployment best practices, also how it maps those elements to the different cloud providers so you can keep a consistent mental model of your infrastructure. It supports a wide array of cloud infrastructure providers, among them:

  • Google App Engine
  • Amazon Web Services
  • Azure
  • Kubernetes

And many more … https://www.spinnaker.io/concepts/providers

Server Groups

It is the base resource, represents a deployable artifact which is normally associated with configuration settings for example number of instances, auto-scaling policies, metadata, etc. This resource can be associated with a Load Balancer and a Security Group.

Kubernetes Server Groups: A server group maps to Kubernetes pods via Replica Sets or Deployments. You can imagine how autoscaling and metadata from pods can naturally match a server group definition.

Cluster

Clusters are logical groupings of Server Groups.

Kubernetes Cluster: A Spinnaker Cluster can optionally map to a Kubernetes Deployment.

check more information about this mapping here: https://www.spinnaker.io/reference/providers/kubernetes/#cluster

Applications

Applications are logical groupings of Clusters in Spinnaker.

Kubernetes Applications: It doesn’t have a direct mapping since it is a logical grouping inside Spinnaker.

Load Balancer

A Load Balancer is associated with an ingress protocol and a port range. It balances traffic among instances in its Server Groups.

Kubernetes Load Balancers: A Load Balancer maps to a Kubernetes Service.

Security Group

A Security Group defines network traffic access. It is effectively a set of firewall rules defined by an IP range, along with the communication protocol.

Kubernetes Security Groups: A security group maps to a Kubernetes Ingress, which manages external access to services in a cluster.

Conclusion

Continuous integration (CI) and Continuous Delivery (CD), are practices that can help you make your software delivery process better, by embracing automation, monitoring and constant quality improvement. In order to apply CI/CD effectively, you must select the right tools, but most importantly focus on a well defined process, once you have that process you can actually make it better over time, which might give you a big advantage when trying to figure out your client needs, by providing them with quick improvements and features based on their needs quickly and with higher quality.


comments powered by Disqus