A verdict on adding Windows minions to Kubernetes clusters in AWS
As of Kubernetes 1.5, Windows containers support was introduced in an alpha release. With the beta version just around the corner, we put the Windows support to the test. Is it mature enough for production environments?
Container solutions, like Docker, have become a popular software development and deployment trend, that enable developers to easily ship applications “anywhere,” without worrying about environment setup. Kubernetes(aka k8s) helps us to manage the lifecycles of containerized applications by providing an orchestration framework (i.e. auto-scaling, health checking and recovery).
Another current trend in software development is microservices, where applications are split into smaller, lightweight, distributed (containerized) services. Since containers stemmed from Linux, Docker (and consequently k8s) initially supported only Linux. However, whether we like it or not, there are still many applications (legacy or new) that are Windows specific. Furthermore, in microservices, some services might need to run in a windows environment. This made Microsoft team up with Docker Inc. to introduce windows containers with the release of Windows Server 2016.
Windows containers still need to run on Windows hosts. So, if you want to utilize the power of k8s for managing container applications running partially (or fully) on Windows, then you will need to have Windows nodes in your k8s cluster. Consequently, a Windows special interest group (SIG) was formed to provide support for adding Windows minions (nodes) to a Kubernetes clusters. In Kubernetes 1.5 , Windows support was in the alpha release, with the roadmap targeting a beta release by the time Kubernetes 1.8 is out. The million dollar question, though, is whether it is mature enough for production environments?
The alpha release comes with some limitations, as stated in its announcement. First, Windows does not support network namespaces, which means containers in the same pod cannot communicate over localhost. This restricts the number of containers per pod to only one. Additionally, DNS capabilities were not fully implemented, and UDP was not supported inside a container.
We tested the alpha release of the Windows support for k8s on a cluster created by Kops on AWS. Kops makes it easy to deploy and manage a k8s cluster on AWS. Kops supports creating a Linux-based cluster (for both master and minions) which means you have to manually add Windows minions to the cluster by following the guide provided on k8s. The guide takes you through configuring the networking, building the kubelet and kube-proxy binaries for Windows, and starting both of them. Once you have the Windows minions successfully joined to your k8s cluster, you can tell the k8s scheduler to schedule specific pods (logical group of containers) to the Windows minions using NodeSelector.
The alpha release approach when used with Kops on AWS faces multiple challenges which makes it not well suited for production use:
As it stands, Windows support in k8s clusters is maturing but it’s not ready for production environments, especially if you want to use a cluster management tool. So what to do if you still need to have Windows minions in your Kubernetes clusters? You have two options:
The past year has seen rapid developments in the evolution of Windows support around Docker and k8s, and Microsoft (and its partners) seem determined to take it further. We shall keep an eye on this space over the next few months as Windows Server 2017 gets released and Windows support in k8s matures.
Helm charts lifecycle management is a manual task. Helmsman allows you to automate your Helm charts lifecycle management using declarative configuration files.
How to automatically deploy Helm charts to a Kubernetes cluster
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
A major challenge of software development is that our work is by and large invisible. This makes our folklore essential in business matters. Some of our commonly used arguments and visualizations are digital urban legends rather than solid foundations for informed decisions. Here, we’ll go through a few examples and some measures to address our misconceptions.
How the stories we tell influence our decisions
When you embark on your cloud native journey there will be important choices to make about cloud providers, continuous deployment, environments’ setup and separation. This guide will help you make the right choices by sharing lessons learnt from running cloud native apps in production.
Kubernetes has become the de facto container orchestration platform. When we help clients of different sizes and domains start their cloud native journeys in Kubernetes, we assist them in making sound decisions and technology choices. There is no one-size-fits-all solution when it comes to choosing cloud providers, CI tools, continuous deployment pipelines etc., so it is important to make the right decisions at the start. Failing to do so can be very costly in terms of lost time and money.
How to make the right technical choices on your cloud native journey
Learn how Docker and Kubernetes work and the key benefits they bring. Using real demos, I show how Docker is a great packaging and distribution technology, and how Kubernetes provides a powerful runtime for containerized applications.
Watch this introduction to Docker and Kubernetes at the Trondheim Developer Conference (TDC)
In the world of Agile and DevOps we use many figures, charts and diagrams to argue and reason about our world and how we prioritize and make choices. However, at all levels of the organization, we misuse and misinterpret figures. It’s time to be explicit, measure the right things and act on them. Watch this talk from DevOpsDays Zurich in May 2019.
Watch this talk from DevOpsDays Zurich
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps