Book Image

Hands-On Kubernetes on Windows

By : Piotr Tylenda
Book Image

Hands-On Kubernetes on Windows

By: Piotr Tylenda

Overview of this book

With the adoption of Windows containers in Kubernetes, you can now fully leverage the flexibility and robustness of the Kubernetes container orchestration system in the Windows ecosystem. This support will enable you to create new Windows applications and migrate existing ones to the cloud-native stack with the same ease as for Linux-oriented cloud applications. This practical guide takes you through the key concepts involved in packaging Windows-distributed applications into containers and orchestrating these using Kubernetes. You'll also understand the current limitations of Windows support in Kubernetes. As you advance, you'll gain hands-on experience deploying a fully functional hybrid Linux/Windows Kubernetes cluster for development, and explore production scenarios in on-premises and cloud environments, such as Microsoft Azure Kubernetes Service. By the end of this book, you'll be well-versed with containerization, microservices architecture, and the critical considerations for running Kubernetes in production environments successfully.
Table of Contents (23 chapters)
1
Section 1: Creating and Working with Containers
5
Section 2: Understanding Kubernetes Fundamentals
9
Section 3: Creating Windows Kubernetes Clusters
12
Section 4: Orchestrating Windows Containers Using Kubernetes

Upgrading clusters

Running a Kubernetes cluster in production will definitely require upgrading the Kubernetes components to newer versions at some point. How you perform the upgrade itself depends on the tools that you use to bootstrap and manage the cluster. But in general, the high-level procedure looks as follows:

  1. Upgrade the components running on the primary master node.
  2. Upgrade the components running on the additional master nodes.
  3. Upgrade the worker nodes.

There is an important rule that you have to follow to ensure safe upgrades: you can only upgrade the cluster by one minor version at once. It means that, for example, a cluster that has version 1.16 can be only upgraded to 1.17you cannot make a jump straight to 1.18. The reason for this is the version skew policy for Kubernetes master components, which allows running one minor version difference at most only...