50 Kubernetes Concepts Every DevOps Engineer Should Know E-Book

Michael Levan

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 286

Veröffentlichungsjahr: 2023

Beschreibung

Kubernetes is a trending topic among engineers, CTOs, CIOs, and other technically sound professionals. Due to its proliferation and importance for all cloud technologies, DevOps engineers nowadays need a solid grasp of key Kubernetes concepts to help their organization thrive.
This book equips you with all the requisite information about how Kubernetes works and how to use it for the best results. You’ll learn everything from why cloud native is important to implementing Kubernetes clusters to deploying applications in production. This book takes you on a learning journey, starting from what cloud native is and how to get started with Kubernetes in the cloud, on-premises, and PaaS environments such as OpenShift. Next, you’ll learn about deploying applications in many ways, including Deployment specs, Ingress Specs, and StatefulSet specs. Finally, you’ll be comfortable working with Kubernetes monitoring, observability, and security. Each chapter of 50 Kubernetes Concepts Every DevOps Engineer Should Know is built upon the previous chapter, ensuring that you develop practical skills as you work through the code examples in GitHub, allowing you to follow along while giving you practical knowledge.
By the end of this book, you’ll be able to implement Kubernetes in any environment, whether it’s an existing environment, a greenfield environment, or your very own lab running in the cloud or your home.

Leseprobe

50 Kubernetes Concepts Every DevOps Engineer Should Know

Your go-to guide for making production-level decisions on how and why to implement Kubernetes

Michael Levan

BIRMINGHAM—MUMBAI

50 Kubernetes Concepts Every DevOps Engineer Should Know

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Rahul Nair

Publishing Product Manager: Niranjan Naikwadi

Senior Editor: Tanya D’cruz

Technical Editor: Rajat Sharma

Copy Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Nilesh Mohite

Senior Marketing Coordinator: Nimisha Dua

First published: February 2023

Production reference: 1130123

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80461-147-0

www.packtpub.com

To my son, Zachary, for one day, once you’re older, understanding why I work so hard, and to my mother for always being there to help out. To the community – thank you for enjoying the work that I put out and taking this journey with me.

– Michael Levan

Contributors

About the author

Michael Levan is a seasoned engineer and consultant in the Kubernetes space who spends his time working with start-ups and enterprises around the globe on Kubernetes and cloud-native projects. He also performs technical research, creates real-world, project-focused content, and coaches engineers on how to cognitively embark on their engineering journey. He is a DevOps pro, a HashiCorp Ambassador, and an AWS Community Builder, and loves helping the tech community by speaking internationally, blogging, and authoring technical books.

About the reviewer

Chad Crowell has been in the tech industry for 15 years, working as an Engineer, a DevOps Consultant, Kubernetes Instructor, and a Microsoft Certified Trainer. Chad has also authored the book Acing the Certified Kubernetes Administrator Exam. He is passionate about helping others overcome obstacles in their life and work, and embraces the community and open-source aspects of working in teams.

Table of Contents

Preface

Part 1: First 20 Kubernetes Concepts – In and Out of the Cloud

1

Kubernetes in Today’s World

Technical requirements

The shift to the cloud

Why organizations care about the cloud

What the cloud did for engineers

Kubernetes, the new cloud OS and data center

Kubernetes in the cloud

Why Kubernetes?

Kubernetes as a data center

Cloud-native apps and why they’re important

What cloud-native apps do for organizations

The world is cloud-based

Engineering talent is toward the cloud

Abstraction is easier, but with a twist

What abstraction does

What abstraction doesn’t do

Start slow and go fast

Understanding the engineering need for Kubernetes

Understanding the business need for Kubernetes

Planning is the hard part

Summary

Further reading

2

Getting the Ball Rolling with Kubernetes and the Top Three Cloud Platforms

Technical requirements

Azure Kubernetes Service

Creating an AKS cluster manually

Creating an AKS cluster with automation

Scaling an AKS cluster

AKS and Virtual Kubelet

Managing and maintaining AKS clusters

AWS EKS

Creating an EKS cluster manually

Creating an EKS cluster with Terraform

Scaling an EKS cluster

EKS Fargate profiles

GKE

Creating a GKE cluster with Terraform

GKE Autopilot

A quick note on multi-cloud

Summary

Further reading

3

Running Kubernetes with Other Cloud Pals

Technical requirements

Understanding Linode Kubernetes Engine

Why LKE?

Setting up LKE manually

Automating LKE deployments

Exploring DigitalOcean Managed Kubernetes

Why DigitalOcean Kubernetes Engine?

Setting up DigitalOcean Managed Kubernetes manually

Automating DigitalOcean Managed Kubernetes

What is Kubernetes PaaS and how does it differ?

OpenShift

OpenShift in the enterprise

Getting started with OpenShift Sandbox

OpenShift on AWS

Summary

Further reading

4

The On-Prem Kubernetes Reality Check

Technical requirements

Understanding operating systems and infrastructure

Kubeadm Deployment

System size

System location

Operating system

Troubleshooting on-prem Kubernetes clusters

Server logs and infrastructure troubleshooting

Network observability

Kubernetes metrics

crictl

kubectl

Introducing hybrid services

Azure Stack HCI

Google Anthos

A quick note about other infrastructure managers

Exploring networking and system components

kube-proxy

CNI

Kubernetes resource communication

DNS

Service mesh and Ingress

Getting to know virtualized bare metal

Virtualizing your environment

Where to run Kubernetes

Summary

Further reading

Part 2: Next 15 Kubernetes Concepts – Application Strategy and Deployments

5

Deploying Kubernetes Apps Like a True Cloud Native

Technical requirements

Understanding cloud-native apps

What’s a cloud-native app?

Cloud-specific cloud native

What are microservices?

Learning about Kubernetes app deployments

Kubernetes manifests

Controllers and operators

Different ways to deploy with higher-level controllers

Scaling

Multi-container Pods

Liveness and readiness probes

Exploring segregation and namespaces

Namespaces

Single tenancy

Multi-tenancy

Investigating stateless and stateful apps

Stateful versus stateless

Container Storage Interface

Volumes

Resource requests and limits

Upgrading Kubernetes apps

Types of upgrades

What happens to an app being upgraded?

Rolling updates

Rollbacks

Summary

Further reading

6

Kubernetes Deployment– Same Game, Next Level

Technical requirements

Getting to know Helm charts and Kustomize

Why think about deployment methods for manifests?

Helm charts

Kustomize

Deploying with CI/CD and GitOps

What is CI/CD?

Using CI/CD for Kubernetes deployments

What is GitOps?

Using GitOps for automated deployments

Production use cases for CI/CD and GitOps

Troubleshooting application deployments

Troubleshooting Pods

Troubleshooting Services

Troubleshooting Deployments

Service meshes and Ingresses

Why Ingress?

Why service meshes?

Summary

Further reading

Part 3: Final 15 Kubernetes Concepts – Security and Monitoring

7

Kubernetes Monitoring and Observability

Technical requirements

How is monitoring different than observability?

What’s monitoring?

What’s observability?

Monitoring versus observability examples

Monitoring and observability tools for Kubernetes

The Kubernetes Dashboard

Azure Monitor

AWS Container Insights

Grafana/Prometheus

Observability practices

Logging

Metrics

Traces

Monitoring Kubernetes resources

Monitoring Pods

Summary

Further reading

8

Security Reality Check

Technical requirements

Out-of-the-box Kubernetes security

Security breakdown

Kubernetes security

Investigating cluster security

Cluster hardening and benchmarks

System scanning

Cluster network security

Upgrading the Kubernetes API

Audit logging and troubleshooting

Understanding RBAC

What is RBAC?

Roles and ClusterRoles

RoleBindings and ClusterRoleBindings

Kubernetes resource (object) security

Pod security

Policy enforcement

Scanning container images

Kubernetes Secrets

Creating Kubernetes Secrets

Don’t use Kubernetes Secrets

Summary

Further reading

Index

Other Books You May Enjoy

Part 1: First 20 Kubernetes Concepts – In and Out of the Cloud

When engineers first dive into Kubernetes, it can almost feel like a tool of sorts. You use it to run and deploy containers. However, that’s not the case. Kubernetes in itself is a platform. It’s almost like a subset of a methodology to run containers. Kubernetes, among many other platforms, is why the whole platform engineer title is becoming so popular. The DevOps space is moving away from thinking about just tools and focusing on the entire platform and environment.

With different platforms comes the question – where do you run it? The first set of concepts in the 50 concepts will be explained here with the overall architecture of Kubernetes.

Kubernetes is something that’s heavily utilized in the cloud, but it’s also heavily utilized on-premises. An example of this is certain regulatory requirements. I was recently chatting with a colleague that works in the defense space. Because of the obvious heavy security requirements that they have, along with the need to stay as close to certain areas as possible, using Kubernetes at the edge was a crucial part of success. Some of the edge Kubernetes nodes were running on k3s, which is a popular method of running Kubernetes for ARM devices. Those ARM devices are on-premises, so not in the cloud.

On the flip side, a lot of organizations don’t have this regulatory requirement, so running Kubernetes in the cloud as a managed service is perfectly valid. It’s also an easier approach to hit the ground running with Kubernetes. For example, utilizing Azure Kubernetes Service (AKS) is a lot easier from the start than bootstrapping a five-node cluster with Kubeadm.

By the end of this part, you should fully understand how to get started with Kubernetes, how to run it in the cloud, and the different popular cloud services that are available for you to use. Although not every single managed Kubernetes service is covered in these four chapters, these chapters will get you through the most popular along with giving you a solid idea of how the other services will look and be utilized.

This part of the book comprises the following chapters:

Chapter 1, Kubernetes in Today’s WorldChapter 2, Getting the Ball Rolling with Kubernetes and the Top Three Cloud PlatformsChapter 3, Running Kubernetes with Other Cloud PalsChapter 4, The On-Prem Kubernetes Reality Check

1

Kubernetes in Today’s World

If you’re reading this book, chances are you’ve been, or still are, in the tech/IT world in some capacity, whether it’s from the operations side, the development side, or both – perhaps even technical leadership or product management. In any case, you’ve most likely heard about a platform/technology called Kubernetes. From how every company, both small and large, is talking about Kubernetes, a lot of engineers and leadership personnel think it’s going to solve many problems. Although that’s true, there’s a twist, and with everything that makes our lives easier, there are caveats.

This chapter is primarily theoretical and will answer a lot of the questions you most likely have about moving to the cloud, hybrid environments, cloud-native/specific applications, and how Kubernetes is taking over the microservice ecosystem.

By the end of this chapter, you’ll be able to answer some of the questions about the pros and cons of implementing Kubernetes. You’ll have a solid understanding of why engineers and leadership teams alike are moving to Kubernetes. The gears will also start moving in your head concerning what your current application(s) look like and whether Kubernetes would be a good fit.

In this chapter, we’re going to cover the following topics:

The shift to the cloudKubernetes, the new cloud OS and data centerCloud-native applications and why they’re importantAbstraction is easier, but with a twistStart slow and go fast

Technical requirements

This chapter will be more theory than hands-on, so you don’t have to worry about any coding or labs. To follow along with this chapter, and this book in general, you should have beginner-level knowledge of Kubernetes, intermediate knowledge of the cloud, and some experience with applications and architecture.

Moving forward, a lot of the chapters in this book will include labs and hands-on work. You can find the code for each exercise in this book’s GitHub repository at https://github.com/PacktPublishing/50-Kubernetes-Concepts-Every-DevOps-Engineer-Should-Know.

The shift to the cloud

Before diving into Kubernetes, there’s an important question to ask: Why use Kubernetes? The reality is that organizations have been deploying applications without Kubernetes for years. There wasn’t Kubernetes in the 1980s when engineers were writing software to floppy disks. So, why now?

The answer to this question is a complicated one and the best place to start is by thinking about what the cloud does for us – not necessarily what the cloud is, but instead what the cloud helps us think about when deploying software and systems from an architect, engineering, and management perspective. In this section, you’re going to learn about the following aspects of the cloud:

Why organizations care about the cloudWhat the cloud did for engineersHow abstraction can help us learn from our mistakesHow the cloud doesn’t exactly do what people think it does

Let’s take a closer look.

Why organizations care about the cloud

Leadership teams in organizations, whether it’s the CIO, CTO, or someone in a technical leadership position, tend to tie Kubernetes to the cloud. However, this couldn’t be any further from the truth. The reason why could be anything from incredibly good technical marketing to not having enough experience from a hands-on perspective to truly understand what’s happening underneath the hood in a cloud environment. However, let’s digress from that and think about why everyone cares about the cloud. The best way to do this is with a visual, so let’s take a look at the following diagram:

Figure 1.1 – Data center web app architecture

The preceding diagram is of a data center architecture. There are a lot of pieces, some marked and some not, including the following:

ServersNetwork equipmentConnections between serversEthernet cables and power cables

With all of that hardware not only comes costs of actually buying it, but also costs around hiring engineers to manage it, maintain it, and keep the lights on in the data center. Not to mention it takes about 4 to 6 months for a full data center to be up and running. With the time that it takes the data center to get up and running, on top of all of the costs and management of hardware, having cloud-based systems starts to make a lot of sense to senior leadership teams for any organization ranging from start-ups to the Fortune 500.

Now, let’s take a look at the architecture in Figure 1.2. This diagram shows a few things, including the following:

RDS (Amazon’s database service)Load balancersCDNsS3 buckets (cloud storage in AWS)Route 53 (AWS DNS)

The architecture diagram in Figure 1.2 is similar to Figure 1.1, in that they are both data centers, but only Figure 1.2 is virtualized as exactly what you would see in a data center. You have network components, storage, databases, servers, and everything in between. The biggest difference is what you’re seeing here is virtualized. It’s a virtual data center with virtual services. Because there are engineers that work at AWS managing the hardware, networking, and other peripherals for you, you no longer have to do it. You only have to worry about the services themselves and making sure they’re working as expected.

No more buying hardware. No more replacing hard drives. No more waiting 4 to 8 months for hardware to arrive at your data center so you can finally build it. Instead, an entire data center is only a few button clicks or a few lines of automation code away:

Figure 1.2 – Cloud web app architecture

Going off of the preceding diagram, here’s where Kubernetes comes into play. Regardless of what option you go with, on-premises or in the cloud, there’s still a ton of stuff to manage. Even though the cloud makes infrastructure easier, there are still major staffing needs and a big cost behind creating all of the cloud infrastructures.

The following are a few pieces of the puzzle to manage:

Load balancersVirtual machines (or bare-metal servers)Network equipment (virtual or physical)Subnets, private IPs, public IPs, and gatewaysSecurity for multiple pieces of virtualized hardware and services

And that’s just to name the general categories. Within each category, there are multiple components (physical and/or virtual) to manage. With Kubernetes, it’s all abstracted away from you. There aren’t any firewalls or gateways because that’s managed via kube-proxy. There are no virtual machines that you have to deploy other than the Kubernetes nodes because the apps are running in Kubernetes Pods.

If you run Kubernetes in a Kubernetes service such as Azure Kubernetes Service (AKS) or GKE, the management of the Control Plane, sometimes referred to as the API server or the master nodes (a now deprecated way to describe Control Planes), is completely abstracted away from you.

What AKS, GKE, or another one of the cloud Kubernetes services does underneath the hood is the same thing that you would do if you ran a raw Kubernetes cluster in a bunch of virtual machines. The underlying technology, how it works, and how it’s used don’t change. The only thing that changes is the abstraction.

That’s why the cloud is important for Kubernetes and that’s why CIOs, CTOs, and engineers should care.

What the cloud did for engineers

“The cloud is just someone else’s computer,” as some may say in passing or on funny stickers. As we all know, in every joke is a little truth. The truth is, it’s correct. When you’re interacting with the cloud, it’s not that you’re interacting with some magical service that is just there. Instead, you’re interacting with services that are managed by other engineers.

For example, let’s say you’re working with Azure virtual machines or EC2 instances in AWS. From your perspective, you log into one of the portals or write some Infrastructure as Code (IaC) and in a few minutes, your new virtual server/cloud server is deployed. On the backend, there’s way more that goes into it. There are a ton of different parts, some of which include the following:

Autoscaling the serversDoing multiple checks to ensure that there’s enough hard disk, CPU, and RAM space on the physical/bare-metal server that’s being usedNetworking setupLots of automation

Remember, because the cloud servers that you’re deploying are running on bare-metal servers, people have to be there to manage those servers and maintain them. The cloud is an abstraction layer that you don’t see. With that being said, the cloud has done a lot for engineers.

Let’s take a start-up company for example. Years ago, if a start-up company wanted to do anything in the tech space, they needed servers to host applications and websites. For a small company that’s working out of a tiny office or even from someone’s house, it’s not possible to have a layer of high availability, redundancy, and scalability. They simply cannot afford the hardware, the space, and the employees to do it.

With the cloud, they no longer have to worry about having to do all of that. Instead, the start-up can focus on building applications and deploying them to the cloud. Deploying applications to the cloud is not easy and it certainly has its own complexity, but the idea behind it is to abstract away physical needs (servers, infrastructure, and so on) that your company may not want to/have to worry about.

Kubernetes, the new cloud OS and data center

Kubernetes is a topic that’s on everyone’s mind, but at the same time, a lot of individuals don’t understand why. Is it the actual platform itself? Or what the platform does for engineers in today’s world? The answer to those questions is – sort of both. Kubernetes does several things, but the primary pieces include the following:

Deploying your containerized applicationScaling your applicationEnsuring that your application is highly availableGiving you the ability to secure your application and the users accessing the application

These four points sound like what engineers have already been doing with computers since the inception of the first mainframe. The question now becomes, why is Kubernetes so popular?

Kubernetes in the cloud

Everywhere you look, it feels like there’s a new way to utilize the Kubernetes platform or some new tool that’s supposed to make your life easier. Some of these platforms include the following (you’ll learn more about these in the upcoming chapters):

Cloud Kubernetes services such as AKS, Google Kubernetes Engine (GKE), and Amazon Elastic Kubernetes Service (EKS)Platform-as-a-Service (PaaS) offerings such as OpenShiftServerless Kubernetes platforms such as Azure Container Apps and AWS Fargate profiles on EKS

Although that’s not an extensive list, you can see that just the sheer number of platforms that are at your disposal can make it extremely difficult to pick and choose what you should ultimately go with. The semi-agreed-upon answer to this question is that it all depends on your current ecosystem. If you’re in AWS, use EKS. If you’re in Azure, use AKS. If you’re a Red Hat Enterprise customer, check out OpenShift. The reason why is that, at the end of the day, all of the Kubernetes services are doing the same thing. They’re all using Kubernetes under the hood and utilizing cloud services to make your life easier.

For example, if you’re using AKS, chances are you probably want to use Azure Active Directory (AAD) to manage who has access to what in the AKS cluster. Azure makes it extremely straightforward to implement this because the goal of a Kubernetes service in the cloud is to do exactly that. All public clouds in general are trying to make your life easier, regardless of what cloud you’re using. A great example of this is how you can use AAD inside of GKE via federation with Cloud Identity to map AAD tenants, users, and groups.

Why Kubernetes?

The question from the beginning of this chapter around why people want to use Kubernetes has sort of been answered, but there’s still more to think about. Primarily, we must think about why everyone is flocking toward Kubernetes, especially Kubernetes services in the cloud. The answer to why people are using Kubernetes services in the cloud is typically something similar to one of the following:

You don’t have to worry about the underlying infrastructureWorker nodes and Control Planes are scaled for you automagically

And although those are great answers, you’re still not any closer to the answer as to why you should use Kubernetes if all it’s doing is what everyone has been doing in tech for years. It’s not implementing anything new or out of the ordinary.

Simply put, the reason why people like Kubernetes is that it allows you to interact with your infrastructure via an API. When you run a Kubernetes command such as kubectl apply -f deployment.yaml, you’re interacting with the Kubernetes API. When you run a command such as kubectl get deployments, you’re interacting with an API. 99% of what you do when interacting with Kubernetes is all API-based. It’s a bunch of GET and POST requests. The reason why Kubernetes makes engineers’ lives easier is that what you used to have to do to get an application up and running on multiple servers is now abstracted away and it’s all now at the programmatic level. All APIs.

Kubernetes as a data center

Remember data centers? Those things that have the loud, big computers running with a bunch of fans and air conditioners? Perhaps you’re from the era of spending hours in a data center, racking and stacking servers, and taking a nap on the data center floor using your backpack as a pillow. If you’ve never done any of that, consider yourself a lucky person!

When thinking about a data center, there are several components, but let’s think about the main ones that engineers care about:

ServersNetwork equipment (firewalls, load balancers, routers, switches, gateways, and so on)Outbound and inbound connectivitySecurityThe ability to run software and virtualization on the servers

Containerization platforms such as LXC and Docker were able to give us the fifth point mentioned here – virtualization of OSes and the ability to run software – but what about the rest? Engineers needed a way to orchestrate and manage the software and virtualized OSes. That’s where Kubernetes comes into play.

Kubernetes fills every piece of the data center puzzle:

Networking, including Pod-to-Pod communication, services, service meshes, Ingress, load balancing, and routing.Security and encryption between Pods and servicesHigh availability for clustersThe ability to deploy, manage, scale, and maintain applications of any kind (must be containerized)Authentication and authorization capabilities from third-party tools such as AAD and IAM users/roles

Kubernetes is a one-stop shop for everything that you would find in a data center. The biggest difference is that the infrastructure (if you’re running in the cloud and not on-premises) is completely abstracted away. You don’t have to worry about the day-one operations; you only have to worry about getting an application deployed, orchestrated, and working as you and your team see fit.

One important piece of information to think about here is with new technology comes new problems. Kubernetes isn’t easy. Just because you don’t have to deal with sleeping on a data center floor doesn’t mean you won’t have an entirely new set of problems to understand and fix. Does Kubernetes make your life easier as an engineer? Yes. Does Kubernetes make your life harder? Yes. Although, the goal is to make your life a little less hard with Kubernetes, please keep in mind that it isn’t a magic box that you set and forget.

Cloud-native apps and why they’re important