The DevOps Toolkit Series (volumes 4, 5, 6, and 7): Kubernetes Extended
The DevOps Toolkit Series (volumes 4, 5, 6, and 7): Kubernetes Extended
About the Bundle
From Kubernetes fundamentals, continuous deployment with Jenkins, advanced monitoring, alerting and scaling, and the next generation of CD with Jenkins X
The DevOps 2.3 Toolkit: Kubernetes
Deploying and managing highly-available and fault-tolerant applications at scale
The goal of this book is not to convince you to adopt Kubernetes but to provide a detailed overview of its features. I want you to become confident in your Kubernetes knowledge and only then choose whether to embrace it. That is, unless you already made up your mind and stumbled upon this book in search of Kubernetes guidance.
The plan is to cover all aspect behind Kubernetes, from basic to advanced features. We'll go not only through the tools behind the official project but also third-party add-ons. I hope that, by the time you finish reading this book, you will be able to call yourself "Kubernetes ninja". I cannot say that you will know everything there is to know about the Kubernetes ecosystem. That would be impossible to accomplish since its growing faster than any single person could follow. What I can say is that you will be very confident in running a Kubernetes cluster of any scale in production.
Like all my other books, this one is very hands-on. There will be just enough theory for you to understand the principles behind each topic. The book is packed with examples, so I need to give you a heads up. Do not buy this book if you're planning to read it on a bus or in bed before going to sleep. You will need to be in front of your computer. A terminal will be your best friend. `kubectl` will be your lover.
The book assumes that you feel comfortable with containers, especially Docker. We won't go into details how to build an image, what is container registry, and how to write Dockerfile. I hope you already know all that. If that's not the case, you might want to postpone reading this and learn at least basic container operations. This book is about things that happen after you built your images and stored them in a registry.
This book is about running containers at scale and not panicking when problems arise. It is about the present and the future of software deployment and monitoring. It's about embracing the challenges and staying ahead of the curve.
The DevOps 2.4 Toolkit: Continuous Deployment To Kubernetes
Continuously deploying applications with Jenkins to a Kubernetes cluster
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, even though AKS is available, it is, at this moment (June 2018), still too unstable and it's missing a lot of features. So, I'm forced to scale down from the trio to the GKE and EKS duo as representatives of 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.
To summarize the guidelines, it explores continuous delivery and deployment in Kubernetes using Jenkins. All the examples are tested in minikube, Docker for Mac (or Windows), AWS with kops, GKE, OpenShift with minishift, and EKS.
The DevOps 2.5 Toolkit: Monitoring, Logging, and Auto-Scaling...
Making Resilient, Self-Adaptive, And Autonomous Kubernetes Clusters
Kubernetes is probably the biggest project we know. It is vast, and yet many think that after a few weeks or months of reading and practice they know all there is to know about it. It's much bigger than that, and it is growing faster than most of us can follow. How far did you get in Kubernetes adoption?
From my experience, there are four main phases in Kubernetes adoption.
In the first phase, we create a cluster and learn intricacies of Kube API and different types of resources (e.g., Pods, Ingress, Deployments, StatefulSets, and so on). Once we are comfortable with the way Kubernetes works, we start deploying and managing our applications. By the end of this phase, we can shout "look at me, I have things running in my production Kubernetes cluster, and nothing blew up!" I explained most of this phase in The DevOps 2.3 Toolkit: Kubernetes.
The second phase is often automation. Once we become comfortable with how Kubernetes works and we are running production loads, we can move to automation. We often adopt some form of continuous delivery (CD) or continuous deployment (CDP). We create Pods with the tools we need, we build our software and container images, we run tests, and we deploy to production. When we're finished, most of our processes are automated, and we do not perform manual deployments to Kubernetes anymore. We can say that things are working and I'm not even touching my keyboard. I did my best to provide some insights into CD and CDP with Kubernetes in The DevOps 2.4 Toolkit: Continuous Deployment To Kubernetes.
The third phase is in many cases related to monitoring, alerting, logging, and scaling. The fact that we can run (almost) anything in Kubernetes and that it will do its best to make it fault tolerant and highly available, does not mean that our applications and clusters are bulletproof. We need to monitor the cluster, and we need alerts that will notify us of potential issues. When we do discover that there is a problem, we need to be able to query metrics and logs of the whole system. We can fix an issue only once we know what the root cause is. In highly dynamic distributed systems like Kubernetes, that is not as easy as it looks.
Further on, we need to learn how to scale (and de-scale) everything. The number of Pods of an application should change over time to accommodate fluctuations in traffic and demand. Nodes should scale as well to fulfill the needs of our applications.
Kubernetes already has the tools that provide metrics and visibility into logs. It allows us to create auto-scaling rules. Yet, we might discover that Kuberentes alone is not enough and that we might need to extend our system with additional processes and tools. This phase is the subject of this book. By the time you finish reading it, you'll be able to say that your clusters and applications are truly dynamic and resilient and that they require minimal manual involvement. We'll try to make our system self-adaptive.
I mentioned the fourth phase. That, dear reader, is everything else. The last phase is mostly about keeping up with all the other goodies Kubernetes provides. It's about following its roadmap and adapting our processes to get the benefits of each new release.
The DevOps 2.6 Toolkit: Jenkins X
Cloud-Native Kubernetes-First Continuous Delivery
To understand intricacies and inner workings of Jenkins X, we need to understand Kubernetes. But, you do not need to understand Kubernetes to use Jenkins X. That is one of the main contributions of the project. Jenkins X allows us to harness the power of Kubernetes without spending eternity learning the ever-growing list of the things it does. Jenkins X helps us by simplifying complex processes into concepts that can be adopted quickly and without spending months in trying to figure out "the right way to do stuff." It helps by removing and simplifying some of the problems caused by the overall complexity of Kubernetes and its ecosystem. If you are indeed a Kubernetes ninja, you will appreciate all the effort put into Jenkins X. If you're not, you will be able to jump right in and harness the power of Kubernetes without ripping your hair out of frustration caused by Kubernetes complexity.
I'll skip telling you that Kubernetes is a container orchestrator, how it manages our deployments, and how it took over the world by the storm. You hopefully already know all that. Instead, I'll define Kubernetes as a platform to rule them all. Today, most software vendors are building their next generation of software to be Kubernetes-native or, at least, to work better inside it. A whole ecosystem is emerging and treating Kubernetes as a blank canvas. As a result, new tools are being added on a daily basis, and it is becoming evident that Kubernetes offers near-limitless possibilities. However, with that comes increased complexity. It is harder than ever to choose which tools to use. How are we going to develop our applications? How are we going to manage different environments? How are we going to package our applications? Which process are we going to apply for application lifecycles? And so on and so forth. Assembling a Kubernetes cluster with all the tools and processes takes time, and learning how to use what we assembled feels like a never-ending story. Jenkins X aims to remove those and quite other obstacles.
Jenkins X is opinionated. It defines many aspects of the software development lifecycle, and it makes decisions for us. It tells us what to do and how. It is like a tour guide on your vacation that shows you where to go, what to look at, when to take a photo, and when it's time to take a break. At the same time, it is flexible and allows power users to tweak it to fit their own needs.
The real power behind Jenkins X is the process, the selection of tools, and the glue that wraps everything into one cohesive unit that is easy to learn and use. We (people working in the software industry) tend to reinvent the wheel all the time. We spend countless hours trying to figure out how to develop our applications faster and how to have a local environment that is as close to production as possible. We dedicate time searching for tools that will allow us to package and deploy our applications more efficiently. We design the steps that form a continuous delivery pipeline. We write scripts that automate repetitive tasks. And yet, we cannot escape the feeling that we are likely reinventing things that were already done by others. Jenkins X is designed to help us with those decisions, and it helps us to pick the right tools for a job. It is a collection of industry's best practices. In some cases, Jenkins X is the one defining those practices, while in others it helps us adopting those made by others.
If we are about to start working on a new project, Jenkins X will create the structure and the required files. If we need a Kubernetes cluster with all the tools selected, installed, and configured, Jenkins X will do that. If we need to create Git repositories, set webhooks, and create continuous delivery pipelines, all we need to do is execute a single `jx` command. The list of what Jenkins X does is vast, and it grows every day.
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
Free Updates. Free App. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets), MOBI (for Kindle) and in the free Leanpub App (for Mac, Windows, iOS and Android). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.