Next Generation Kubernetes Deployments

INTRODUCTION

In my last article, Automated Build and Deploy Pipelines for Kubernetes, I introduced you to Halyard, CodeZero’s next generation build and deployment feature that enables developers to ship code easier, faster, and with a higher level of quality.

I also went over traditional Continuous Integration, Continuous Delivery, and Continuous Deployment (collectively referred to as CI/CD), and explained how difficult and costly they can be to set up and maintain. It’s not unheard of for larger companies to spend millions of dollars maintaining their pipelines. And the reality is that very few (<10%) development teams have realized fully automated Continuous Deployment.

Let’s discuss some of the reasons for this before I get into how Halyard can help you set up a hassle-free, next generation automated development pipeline with Kubernetes.

THE PROBLEMS WITH CI/CD

One of the core problems with traditional CI/CD is that there lacks a definitive “best way” to implement the pipelines, especially for Kubernetes. Tools like Jenkins, CircleCI, TeamCity, and Travis CI mandate complicated scripting, a heavy setup, and a significant maintenance investment.

Let’s expand on some of the common pitfalls and complexities of CI/CD.

Deploying Consistently and Reliably

In addition to the lack of a standard, the CI/CD pipelines that are built in a typical development model, more often than not, result in complicated, specialized machines, built as discrete tools to automate individual human tasks rather than architected as a whole with development principles at the core. Consequently the deployments are unreliable, complicated and often fail for reasons other than those related to actual development and quality assurance.

Mistakes Made while Deploying

When problems occur in production or as part of the deployment pipeline and processes, remediation involves manual steps that are subject to human error. The reality is that nothing should be done in production without first automating both roll-forward and rollback contingencies. However, this level of automation is hard to do and costs money and time. For most development teams, it’s just not possible to automate all their manual processes, and so these “known and unavoidable” pain points remain unaddressed.

Knowing if Infrastructure is Configured Correctly

DevOps is consistently having to deal with the complexity of cloud provider (e.g. Google, AWS, Microsoft) interfaces. Often there is more than one way to configure something, and there can be so many options that it becomes uncertain as to what the best practice is, let alone how to implement it. AWS alone has over 200 products and services.

Tool Complexity

The current CI/CD tools are geared towards accommodating any pipeline you can imagine, and they require an investment into learning how they operate, how to properly write the necessary scripts, and the need for constant updates and maintenance. They best service experienced DevOps professionals. And very few of them focus on CI/CD for Kubernetes.

Imperative Pipelines

Current development teams still predominantly implement CI/CD pipelines using a scripted (imperative) implementation. Most developers still think about CI/CD as a set of discrete tasks that are executed in a particular order to move code from a local system into a production system. Pipelines must be constructed from the ground up to get code from the source code repo to a production environment.

With CodeZero Halyard the CI/CD pipeline is built in a declarative manner instead, leading to a far superior developer experience and time to delivery.

HALYARD

Halyard is an opinionated build and deployment feature for developers using Kubernetes, that streamlines the software delivery pipeline and makes it simple to implement, so that developers are freed from time-consuming DevOps configurations; they can simply focus on writing and shipping their code, fearlessly. With just a little bit of knowledge of Kubernetes, a Docker image, and some configuration (done through a UI), a developer can set up a powerful and robust pipeline without getting bogged down in traditional CI/CD.

The core principles driving Halyard are automation and visibility, enabling developers to move faster and more efficiently in a way that allows them to concentrate on writing features, saving them from wasting cycles operating a build/deployment pipeline.

Automation

Automation is the conversion of manual processes into automated process flows. By automating the build, delivery, and deployment processes developers are freed from having to remember command line incantations, secret passwords, complex configurations, and convoluted processes. Automation is achieved using pipelines, which I will get into momentarily.

Visibility

Visibility is about providing a clear overview and a clear contextual view of running code and automated processes. Two things must be visualized:

1. What services are deployed and how they are connected to the structure of the deployed code.
2. Logs of the running code and the automation processes.

DECLARATIVE DEVELOPMENT

Halyard turns the typical CI/CD pipeline on its head by thinking of DevOps as a set of “documents”, manifests, or declarations that describe what the system should “look like”, and passing that description to a monitoring controller that makes the real world match the declared description. The pipeline is simply a set of documents that describe the artifacts that are produced in each step, with the final artifact being a running environment. This new paradigm leverages learnings from the “Kubernetes Way” where a document is created which describes the desired end state, and a controller constantly works to achieve the desired state. This is Declarative Development.

Declarative Development is a way to define DevOps in an assertive way that converts tasks and scripts that serve to create environments, to documents and declarations that “describe the environments” that get created. In using a declarative style, and defining the desired outcomes, the implementation gains the benefits of IoC (Inversion of Control) and REST principles like idempotency, uniform interface, increased modularity, and extensibility.

EPHEMERAL ENVIRONMENTS

The all-too-common scenario for development teams is to have “develop”, “staging”, and “production” environments onto which code gets deployed. Halyard takes the position that this is wildly inefficient, and it’s most certainly costly (running and maintaining three long-lasting environments is expensive, in man-hours and/or hosting charges).

GitOps and “infrastructure as code” are built directly into Halyard’s pipeline so that environments can be ephemeral — created and recreated as often as necessary with each push to the remote code repository. And destroyed without fear.

But what is an “environment” in Halyard? Traditionally, when using Kubernetes and working with multiple long-lasting environments (i.e. develop, staging, production) you might have a cluster for each one. Develop would have just enough nodes to support developers and an internal QA team, staging might have slightly more, with production being provisioned for end-user traffic loads. When develop and staging aren’t being used, though, all that computing power is just sitting idle.

Halyard solves this by using Kubernetes namespaces as environments, on a single cluster. “Production” becomes just another namespace in your cluster. It is no longer precious, and can be fixed or reconstructed easily without causing disruptions to end-users.

TRAFFIC SHAPING

With Halyard, users control who sees what code in a remote environment through traffic shaping to environments that are built from specific SHAs, including the production environment. Users can easily manage multiple audiences for each remote environment, expanding and contracting who sees what code when.

CUSTOMIZATION

Although the default behaviour of the pipeline will be sufficient for most users, developers can also write hooks in their native language or use bash scripts at various stages of the pipeline to customize it as needed.

THE FLOW

Let’s see how it would look to use Halyard in practice. I’ve included Teleport and Intercept (discussed in another article) in the following diagram so you can see how all the CodeZero tools and features start to fit together.

• You install Halyard to your Kubernetes cluster and launch its web interface in a browser. You log in (or create a new account).
• You create a new Halyard pipeline and provide some information, like a link to a Git repo and your container registry (or you can use Halyard’s built-in registry). You set up your build and deployment triggers.
• This results in a number of Kubernetes and Halyard manifest files being added to the repo. This is what enables a declarative pipeline.
• You set up some traffic shaping rules.
• You write code on your local machine, make a commit, and push it to the remote repository.
• Your push is detected by Halyard, and the commit hash enters the pipeline.
• The SHA gets built, compiled, tested, and packaged into artifacts (e.g. a Docker image).

Paradigm shift: You don’t need your code to be merged back to the main branch before it’s deployed. Your pipeline can be configured such that every new branch gets built, deployed, and run in its own environment/namespace.

• Any image artifacts that are produced are automatically pushed to your container registry.
• The deployment phase of the pipeline now kicks in and the Kubernetes manifest files are used to deploy the image to its own namespace in your cluster.

Paradigm shift: Instead of running an application in a cluster (or a server), you now run them in namespaces.

• Your traffic shaping rules determine who can see your application running in the newly created namespace. For example, you might have configured it to direct traffic to this namespace using a specific key:value pair in a request header.

CONCLUSION

Hopefully this article has given you a better understanding of the pitfalls and complexities associated with traditional CI/CD, and shown how CodeZero can help you more easily take advantage of the power of Kubernetes, and shed the burden of cumbersome and convoluted CI/CD pipelines. Learn more about CodeZero.