Soon after I started working on The DevOps 2.3 Toolkit: Kubernetes, I realized that a single book could only scratch the surface. Kubernetes is vast, and no single book can envelop even all the core components. If we add community projects, the scope becomes even more extensive. Then we need to include hosting vendors and different ways to set up and manage Kubernetes. That would inevitably lead us to third-party solutions like OpenShift, Rancher, and DockerEE, to name a few. It doesn’t end there. We’d need to explore other types of community and third-party additions like those related to networking and storage. And don’t forget the processes like, for example, continuous delivery and deployment. All those things could not be explored in a single book so The DevOps 2.3 Toolkit: Kubernetes ended up being an introduction to Kubernetes. It can serve as the base for exploring everything else.

The moment I published the last chapter of The DevOps 2.3 Toolkit: Kubernetes, I started working on the next material. A lot of ideas and tryouts came out of it. It took me a while until the subject and the form of the forthcoming book materialized. After a lot of consultation with the readers of the previous book, the decision was made to explore continuous delivery and deployment processes in a Kubernetes cluster. The high-level scope of the book you are reading right now was born.

Overview

Just like the other books I wrote, this one does not have a fixed scope. I did not start with an index. I didn’t write a summary of each chapter in an attempt to define the scope. I do not do such things. There is only a high-level goal to explore continuous delivery and deployment inside Kubernetes clusters. What I did do, though, was to set a few guidelines.

The first guideline is that all the examples will be tested on all major Kubernetes platforms. Well, that might be a bit far-fetched. I’m aware that any sentence that mentions “all” together with “Kubernetes” is bound to be incorrect. New platforms are popping out like mushrooms after rain. Still, what I can certainly do is to choose a few of the most commonly used ones.

Minikube and Docker for Mac or Windows should undoubtedly be there for those who prefer to “play” with Docker locally.

AWS is the biggest hosting provider so Kubernetes Operations (kops) must be included as well.

Since it would be silly to cover only un-managed cloud, I had to include managed Kubernetes clusters as well. Google Kubernetes Engine (GKE) is the obvious choice. It is the most stable and features rich managed Kubernetes solution. Adding GKE to the mix means that Azure Container Service (AKS) and Amazon’s Elastic Container Service (EKS) should be included as well so that we can have the “big trio” of the hosting vendors that offer managed Kubernetes. Unfortunately, at the time of this writing (May 2018), Elastic Container Service (EKS) is in the preview stage and Amazon is providing access only to a relatively small number of people. AKS, on the other hand, is available but, at this moment, it is too unstable. So, I’m forced to scale down from the trio to GKE as the only managed Kubernetes we’ll explore.

Finally, a possible on-prem solution should be included as well. Since OpenShift shines in that area, the choice was relatively easy.

All in all, I decided to test everything in minikube and Docker for Mac locally, AWS with kops as the representative of a cluster in the cloud, GKE for managed Kubernetes clusters, and OpenShift (with minishift) as a potential on-prem solution. That, in itself, already constitutes a real challenge that might prove to be more than I can chew. Still, making sure that all the examples work with all those platforms and solutions should provide some useful insights.

Some of you already chose the Kubernetes flavor you’ll use. Others might still wonder whether to adopt one or the other. Even though the comparison of different Kubernetes platforms is not the primary scope of the book, I’ll do my best to explain the differences as they come.

Once I decided that many different platforms should be used in the book, I had to make a similar decision for CD tools as well. Just as exploring different Kubernetes platforms gives us knowledge that’ll allow us to make better choices, the same is true for continuous deployment processes as well. Should we use a self-hosted solution like Jenkins or a service like CodeShip? If we’re hosting the solution ourselves, should it be open source Jenkins or the enterprise edition? How about Jenkins X? It was made public for the first time when I just started thinking about this book. It’s a solution built on top of Kubernetes, and only for Kubernetes. How can I not include a CD tool specifically designed to work with Kubernetes? So, the potential set of tools could be Jenkins open source, Jenkins enterprise, Jenkins X, and CodeShip.

To summarize the guidelines, it should be a smaller book that explores continuous delivery and deployment using Jenkins OSS, Jenkins EE, Jenkins X, and CodeShip. All the examples will the tested in minikube, Docker for Mac (or Windows), AWS with kops, GKE, and OpenShift with minishift.

The moment I finished writing the previous paragraph I realized that I am repeating the same mistakes from the past. I start with something that looks like a reasonable scope, and I end up with something much bigger and longer. Will I be able to follow all of those guidelines? I honestly don’t know. I’ll do my best.

I was supposed to follow the “best practice” by writing the overview at the end. I’m not doing that. Instead, you are reading about the plans for the book, not the end result. This is not an overview. You can consider this as the first page of the diary. The end of the story is still unknown.

The DevOps 2.4 Toolkit: Continuous Deployment To Kubernetes

The article you just read is an extract from The DevOps 2.4 Toolkit: Continuous Deployment To Kubernetes.

This book explores continuous deployment to a Kubernetes cluster. It uses a wide range of Kubernetes platforms and provides instructions on how to develop a pipeline on few of the most commonly used CI/CD tools.

I am assuming that you are already proficient with Deployments, ReplicaSets, Pods, Ingress, Services, PersistentVolumes, PersistentVolumeClaims, Namespaces and a few other things. This book assumes that we do not need to go through the basic stuff. At least, not through all of it. The book assumes a certain level of Kubernetes knowledge and hands-on experience. If that’s not the case, what follows might be too confusing and advanced. Please read The DevOps 2.3 Toolkit: Kubernetes first, or consult the Kubernetes documentation. Come back once you’re done and once you think you can claim that you understand at least basic Kubernetes concepts and resource types.

Give it a try and let me know what you think.