A Shared View of the Universe
Before Kubernetes, provisioning and deployment of infrastructure and applications were two different tasks: on the infrastructure side, we could use tools like Puppet, Ansible or CloudFormations and Terraform to setup and configure our servers and infrastructure components; on the application deployment side, however, the tools were not as well defined and mostly dependent on the application framework. Kubernetes mostly brings these two under the same umbrella, but the more important part of this unification of deployment flow is not about the disparate Dev or Ops parts, but about the concept of “recipes vs. resources”.
Cakes vs. Houses
What’s the difference between a recipe for a cake and a blueprint for a house? A recipe has steps that, once followed, will get you a cake (of some quality). On the other hand, a blueprint doesn’t include the steps needed to get from a piece of land to a house, instead it includes a representation of what a desired state is (the house).
Crucially, the difference between those two ways of getting from A to B (ingredients to cake, materials to a house), becomes clear after we get to point B: once you make the cake, the recipe is useless; the blueprint is just as useful after the house is built, since it helps us find out where the burst pipe might be, or what would be the best way to build an annex to your kitchen.
The new generation of infrastructure configuration tools (infra-as-code)—AWS CloudFormations, Terraform and even Kubernetes, for example—build the infrastructure you need from a blueprint and not from a recipe. By doing so, these tools provide a reliable, reference-able and always-up-to-date representation of how your infrastructure is setup. This is extremely valuable in any organisation striving to run an immutable and well-documented infrastructure, used by and shared between different teams and applications.
Kubernetes achieves this by using configuration files, usually expressed in YAML format and applied with the kubectl apply command (kubectl is the Kubernetes CLI). As its name suggests, this command applies the configuration file it was given to the existing one on the server.
A strong trend in the world of application deployment is “build once, deploy many”—where “many” could stand for complex environments, clusters and/or clouds. This, together with the power of the Kubernetes API, easily accessed by developers, makes the need for reliable, traceable and auditable configuration files even more pertinent.
Better Kubernetes Configuration Files
To make generation, management and deployment of Kubernetes configurations easier—in other words, to make “deploy many” a reality—Cloud 66 Skycap has two main features: Formations and Stencils.
Formations
To understand what Formations are, let’s start with a question: how many different environments does your application have? QA, Staging, Production? Some companies have UAT, Integration and some more on top of that. Now imagine you want to deploy the same environment on different clouds and/or different Kubernetes clusters. What would you call those environments? Staging 1 and Staging 2?
For example, if I have QA, Staging and Production (3) deployed on-prem and on GKE (2) on one test and one production cluster (2), effectively the number of environments is the product of all of those (3 x 2 x 2 = 12). This is hard to manage, and it is exactly when Formations come in handy. Formations are like a superset for Environments. A Formation is a single deployment of your application to a single Kubernetes cluster, pre-defined and pre-configured by Ops. You can have as many Formations as you like for your application with slight different variations to make it work for different cluster types.
Stencils
Kubernetes configuration files are flexible and can be used in many different ways. You can put all of your resources into a single file, or break them up based on the application, type or deployment order. Decisions on how to break your configuration files into smaller pieces, how to annotate your Kubernetes resources, or how to name your deployments and services are usually taken using a mix of industry best practices and your own conventions based on your specific use cases.
Living alongside Helm Charts, Stencils are like Kubernetes template files you develop for your applications in your team and future use. They are simple to create, are version-controlled and can be reused for different applications. Unlike Helm charts that are usually developed for deployment of specific off-the-shelf components (like Redis or Memcached), Stencils are templates of how a Kubernetes deployment or Ingress should look like within your organisation, with all the configuration and security complexity that would suggest. Developers put Stencils together like Lego blocks to construct the entire deployment configuration. They can make changes to those templates or use them as they want but with a great starting point, and with auditability and best practices applied throughout the pipeline. With Copper’s policy-as-code built into Cloud 66 Skycap, you can also enforce structure, content and style conventions for your Kubernetes configuration files (like an FX Cop for your code).
Stencils deliberately have a simple templating syntax that stops users from overcomplicating the file structure (like using if then else or for loops to generate YAML files), while being rich in container- and Kubernetes- specific primitives.
Combined with full version control for configuration and application variables like environment variables, tagging, search features and template repositories, Stencils deliver a powerful toolkit for reliable and developer friendly application deployment to Kubernetes clusters anywhere.
Write-only ACLs for Secrets
One important feature in Kubernetes is its ability to provide applications with secrets during runtime. These secrets can be sent to Kubernetes using the same configuration files. However, this might compromise the security of your secrets as they shouldn’t be committed into a git repository, or managed by developers in general. Skycap Formations and Stencils have a flexible and powerful ACL system that lets developers change the way secrets are provided and used in Kubernetes without revealing their content—for example, developers would need to point each service to the relevant Vault where the secret is, but wouldn’t necessarily have to have access to the actual key (nor would they need to write them on a post-it…).
Skycap also integrates with HashiCorp Vault as the source of your application secrets to make the entire flow of application deployment safe and secure within the organisation.
Summary
Setting up a Kubernetes cluster is becoming easier every day: whether you build it yourself, use a multi-cloud solution like Cloud 66 Maestro, or managed services like GKE; Cloud 66 Skycap can vastly improve the way your team uses Kubernetes to deploy their applications onto it, bridging your CI with your kubectl in complex environments.