/examples

Examples for The Book of Kubernetes

Primary LanguageJinjaMIT LicenseMIT

The Book of Kubernetes

This repository provides examples for The Book of Kubernetes by Alan Hohn, published by No Starch Press. The examples for each chapter are self-contained in a directory for each chapter.

The examples make extensive use of virtual machines, both to enable running a complete cluster and to isolate experimentation into a temporary environment. The examples support both Vagrant and Amazon Web Services (AWS).

Getting Started

Start by following the instructions in the setup directory's README.md file. Then you'll be ready to use the README.md file in each chapter's folder to run examples for that chapter.

Automated Configuration

The examples use Ansible to provide automated configuration of the virtual machines once they're started. The setup instructions will help you get Ansible installed. All of the chapters have a base playbook.yaml file that provides essential configuration to run the chapter's examples. Some of the chapters also provide an extra.yaml playbook that can be used to skip some of the less exciting installation and configuration. Instructions for using the playbooks are found in each chapter's README.md file.

The book itself will walk you through everything you need to know about installing, configuring, and using container runtimes and Kubernetes. However, the Ansible roles in the setup/roles directory are also an excellent resource to understand the setup of container runtimes and Kubernetes. You're welcome to reuse this Ansible automation in your own work, consistent with the license found in the LICENSE file. Of course, specific design choices I made to keep this content easy to use as examples for a book will not be suitable for production use, so be sure to modify accordingly and test thoroughly.

High Availability

One difference between Vagrant and AWS is load balancing to provide a high-availability solution for the API server and ingress. In Vagrant, these examples use kube-vip. In AWS, they use an Elastic Load Balancer (specifically a network load balancer). Here I provide some background in case it's helpful.

For the Vagrant solution, I started with Keepalived, an excellent library for sharing an IP address between two or more servers. It is a great fit for a shared IP on bare metal servers as it doesn't require any special network configuration or a separate set of load balancing servers. However, after some playing with kube-vip, I became convinced that it represents a better solution for Kubernetes high availability outside of cloud environments, as it provides similar functionality and can be easily integrated into the cluster itself.

Unfortunately, what works well in bare metal and Vagrant does not work as well in AWS. What keepalived and kube-vip both require is for the underlying network to be OK with a server suddenly ARPing an additional IP address, and AWS Virtual Private Cloud (VPC) is definitely not OK with that, thank you very much. There is a clever workaround that watches Keepalived to follow the shared IP and configures AWS to add that IP to the current master, but I did not feel that the added complexity of that solution lends itself to being reliable enough for the examples for a book.

Additionally, the right way to deploy a cluster to a cloud environment is to take advantage of the available features. In the case of AWS, this means deploying an Elastic Load Balancer (ELB). I was initially concerned about the complexity of this approach and the risk of exposing a lab cluster to the outside Internet, so I started with a separate EC2 instance to carry the 172.31.1.10 IP address and run HAProxy to load balance traffic across the cluster's API server instances. That was not a real high availability solution, as HAProxy and its AWS instance are single points of failure, so I was never satisfied with it.

Ultimately, I was able to get a network load balancer going with an address solely on the private 172.31/16 network I'm using for the examples. This required only minimal additions to the aws-instances Ansible role, which is good, because that is already the most complex in the whole set of roles used for these examples, not least because I have to create and remove resources without interfering with the rest of someone's AWS account, as well as automate SSH access to these temporary instances without leaving a bunch of cruft in $HOME/.ssh. Solving this with Ansible is also good because I didn't want to introduce a whole 'nother tool like Terraform that readers would have to install and configure.

The only remaining evidence of this churn is the existence of keepalived and haproxy roles in setup/roles. I decided to leave them there in case they are useful to someone, but they are not used in the playbook files in the chapters.

So long story short, as I said above, the Vagrant cluster uses kube-vip, while the AWS cluster uses a network load balancer. In both cases, the Kubernetes cluster setup is largely identical, which was one of my purposes in offering two ways to deploy the same cluster. If you're deploying a real production cluster, you can use the kube-vip and AWS load balancer setup for your own purposes, though you'll have to make some changes to make a cluster available publicly.

Better yet, use a Kubernetes provider that will set up your cloud provider for you properly. There are many good options, including Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS), as well as cloud-agnostic Kubernetes distributions like Rancher Kubernetes Engine (RKE), Tanzu Kubernetes Grid (TKG), and Red Hat OpenShift.