The Kubernetes Bible - Gineesh Madapparambath - E-Book

The Kubernetes Bible E-Book

Gineesh Madapparambath

0,0
43,19 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.
Mehr erfahren.
Beschreibung

Kubernetes has become the go-to orchestration platform for containerized applications. As a Kubernetes user, you know firsthand how powerful yet complex this tool can be. The Kubernetes Bible cuts through the complexity, offering hands-on examples and expert advice to conquer containerization challenges
With this new edition, you will master cutting edge security practices, deploy seamlessly and scale effortlessly, ensuring unwavering service availability. You will gain the expertise to craft production-grade applications, secure development environments, navigate complex deployments with ease, and become a security maestro. You will be able to optimize network communication and data management across major cloud platforms. Additionally, this book dives deep into these challenges, offering solutions such as multi-container Pods, advanced security techniques, and expert networking guidance. You will also explore persistent storage advancements, cloud-specific cluster management updates, and best practices for traffic routing
By the end of this comprehensive guide, you will possess the skills and knowledge to orchestrate your containerized applications with precision, ensuring their optimal performance and scalability. Stop settling for basic container management. Order your copy today and orchestrate your containers to greatness.

Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:

EPUB
MOBI

Seitenzahl: 1024

Veröffentlichungsjahr: 2024

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



The Kubernetes Bible

Second Edition

The definitive guide to deploying and managing Kubernetes across cloud and on-prem environments

Gineesh Madapparambath

Russ McKendrick

The Kubernetes Bible

Second Edition

Copyright © 2024 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.

Senior Publishing Product Manager: Rahul Nair

Acquisition Editor – Peer Reviews: Gaurav Gavas, Jane D'Souza

Project Editor: Amisha Vathare

Content Development Editor: Shikha Parashar

Copy Editor: Safis Editing

Technical Editor: Simanta Rajbangshi

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Presentation Designer: Ganesh Bhadwalkar

Developer Relations Marketing Executive: Maran Fernandes

First published: January 2022

Second edition: November 2024

Production reference: 1271124

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK.

ISBN 978-1-83546-471-7

www.packt.com

Contributors

About the authors

Gineesh Madapparambath has over 15 years of experience in IT service management and consultancy, specializing in Linux, automation, and containerization. He has worked extensively in planning, deploying, and supporting automation solutions with Ansible and the Ansible Automation Platform, across private clouds, public clouds, bare metal, and network environments. His experience spans globally, with roles including Systems Engineer, Automation Specialist, and Infrastructure Designer. Gineesh is also the author of Ansible for Real Life Automation.

To my wife, Deepthy, for supporting and motivating me as always. To my son, Abhay, and my daughter, Anu, for allowing me to take time away from playing with them to write the book. To my parents and my ever-supportive friends, for their motivation and help.

- Gineesh Madapparambath

Russ McKendrick is an experienced DevOps practitioner and system administrator with a passion for automation and containers. He has been working in IT and related industries for the better part of 30 years. During his career, he has had responsibilities in many different sectors, including first-line, second-line, and senior support in client-facing and internal teams for small and large organizations.

He works primarily with Linux, using open-source systems and tools across dedicated hardware and virtual machines hosted in both public and private clouds at Node4, where he is the practice manager (SRE and DevOps). He also buys way too many records!

About the reviewers

Rom Adams (né Romuald Vandepoel) is an open source and C-Suite advisor with 20 years of experience in the IT industry. He is a cloud-native expert who helps organizations to modernize and transform with open-source solutions. He advises companies and lawmakers on their open- and inner-source strategies. He has previously worked as a Principal Architect at Ondat, a cloud-native storage company acquired by Akamai, where he designed products and hybrid cloud solutions. He has also held roles at Tyco, NetApp, and Red Hat, becoming a Subject Matter Expert in hybrid cloud.

Adams has been a moderator and speaker for several events, sharing his insights into culture, process, and technology adoption, as well as his passion for open innovation.

To my grandmother, for her kindness; my grandfather, for his wisdom; and my partner and best friend, Mercedes Adams, for her love, patience, and continuous support.

– Rom Adams

Shane Boulden is a Solution Architect at Red Hat, supporting organisations to deploy, manage, and secure open-source platforms and technologies.

He is a contributor to several open-source security projects, including the “Compliance as Code” project, building SCAP profiles, and Ansible playbooks aligned with Australian security guidelines. He also supported the Keycloak project to achieve Australian Consumer Data Right (CDR) certification through the OpenID foundation and has contributed a number of new policies to the StackRox Kubernetes-native security project.

Shane has a keen interest in artificial intelligence and machine learning, publishing peer-reviewed papers on genetic algorithms and their applications and running sessions at conferences helping others get started with open-source Generative AI frameworks.

Shane regularly publishes articles on platform operations and security on his blog, stb.id.au.

Foreword

You can bundle and run your applications by using containers. You get to package your dependencies, libraries, and frameworks into a single unit. But then, you’ll need to manage those containers and, well, orchestrate them. For example, you’ll need to schedule containers across a cluster of nodes, automatically restart your failed containers, and replace the failed nodes. That was the need that Google recognized, and Kubernetes was born out of that need.

For me, I first got into Kubernetes right after it was created (late 2015). I was helping run customer feedback programs for developers who were building solutions on Microsoft Azure. We needed our services to work with container orchestration systems, and that especially included Kubernetes. By the time Azure Kubernetes Services (AKS) launched in 2018, I was publishing architectural content on the Azure Architecture Center, as well as whitepapers, e-books, and blog posts. Naturally, I worked with Microsoft’s top solution architects to help publish AKS architecture design guidance and reference architectures. For example, in 2022, I was heavily involved in a series of content called “AKS for Amazon EKS professionals.” I later helped publish content about Google Kubernetes Engine (GKE) on the Google Cloud Architecture Center.

“What makes Kubernetes so incredible is its implementation of Google’s own experience with Borg. Nothing beats the scale of Google. Borg launches more than 2-billion containers per week, an average of 3,300 per second... Kubernetes was born in a cauldron of fire, battle-tested and ready for massive workloads.”

– Swapnil Bhartiya, OpenSource.com

Swapnil Bhartiya gets to the heart of the success of Kubernetes… it was born out of need and refined to become incredibly effective. But words alone won’t save your application. Let’s see what Scott Adams has his characters say about cloud-native application design, containerization, and, yes, Kubernetes.

“I need to know why moving our app to the cloud didn’t automatically solve all our problems.”

– Pointy-Haired Boss (PHB)

“You wouldn’t let me re-architect the app to be cloud native.”

– Dilbert

“Just put it in containers.”

– PHB

“You can’t solve a problem just by saying techy things.”

– Dilbert

“Kubernetes.”

– PHB

And that’s where The Kubernetes Bible comes in. As Scott Adams explained, you can’t just say the terms; you have to do the work. That means you need to know how to get up and running on Kubernetes, how to design and deploy large clusters, and, in general, how to deploy, debug, and recover containerized applications. In this book, Gineesh Madapparambath and Russ McKendrick take you through everything from installing your first Kubernetes cluster to using and configuring pods to deploying stateless and stateful applications. You’ll learn how to launch your Kubernetes clusters on Google Cloud (GKS), Amazon Web Services (EKS), and Microsoft Azure (AKS). You’ll also explore further techniques, including using Helm charts, security, advanced Pod techniques, traffic management, and much more!

Be sure to study each chapter of the Kubernetes Bible. Soak in the wisdom of Gineesh and Russ like a sponge. The more you engage with the content of this book, the more you’ll remember and apply it. And keep this book close. You’re going to need it as you continue to manage and orchestrate your containers.

Ed Price

Technical Writer, Cloud Architecture Content Manager

Co-author of 8 books, including The Azure Cloud Native Architecture Mapbook from Packt

Join our community on Discord

Join our community’s Discord space for discussions with the authors and other readers:

https://packt.link/cloudanddevops

Contents

Preface

Who this book is for

What this book covers

To get the most out of this book

Get in touch

Leave a Review!

Kubernetes Fundamentals

Understanding monoliths and microservices

Understanding the growth of the internet since the late 1990s

Understanding the need for more frequent software releases

Understanding the organizational shift to agile methodologies

Understanding the shift from on-premises to the cloud

Understanding why the cloud is well suited for scalability

Exploring the monolithic architecture

Exploring the microservices architecture

Choosing between monolithic and microservices architectures

Understanding containers

Understanding why containers are good for microservices

Understanding the benefits of container isolation

Container engines

The basics of containers

Container image

Container

Container registry

Dockerfile or Containerfile

Docker Compose or Podman Compose

How can Kubernetes help you to manage your containers?

Kubernetes – designed to run workloads in production

KubeVirt – a bridge between containers and VMs

Understanding the history of Kubernetes

Understanding how and where Kubernetes started

Who manages Kubernetes today?

Where is Kubernetes today?

Where is Kubernetes going?

Exploring the problems that Kubernetes solves

Ensuring high availability

Release management and container deployment

Autoscaling containers

Network isolation

Role-Based Access Control (RBAC)

Stateful workloads

Resource management

When and where is Kubernetes not the solution?

Summary

Further reading

Kubernetes Architecture – from Container Images to Running Pods

Technical requirements

The name – Kubernetes

Understanding the difference between the control plane nodes and compute nodes

The master and worker nodes

Linux and Windows containers

Kubernetes components

Control plane components

Compute node components

Add-on components

Control plane in managed Kubernetes clusters

The Control Plane Components

kube-apiserver

The role of kube-apiserver

How do you run kube-apiserver?

Where do you run kube-apiserver?

The etcd datastore

Where do you run etcd?

Operating etcd clusters for Kubernetes

Learning more about etcd

kube-scheduler

Where do you install kube-scheduler?

kube-controller-manager

Where do you run kube-controller-manager?

cloud-controller-manager

Where do you run cloud-controller-manager?

The compute node components

Container engine and container runtime

Container Runtime Interface

kubelet

The kube-proxy component

Exploring the kubectl command-line tool and YAML syntax

Installing the kubectl command-line tool

Kubernetes Legacy Package Repositories

Installing kubectl on Linux

Installing kubectl on macOS

Installing kubectl on Windows

The role of kubectl

How does kubectl work?

kubectl auto-completion

The imperative syntax

The declarative syntax

How to make Kubernetes highly available

The single-node cluster

The single-master cluster

The multi-master multi-node cluster

Managing etcd in Kubernetes with multiple control plane nodes

Summary

Further reading

Installing Your First Kubernetes Cluster

Technical requirements

Installing a Kubernetes cluster with minikube

Installing minikube

Installing minikube on Linux

Installing minikube on macOS

Installing minikube on Windows

minikube configurations

Drivers for minikube

Launching a single-node Kubernetes cluster using minikube

Setting up minikube using VMs

Setting up minikube using a container

Accessing the Kubernetes cluster created by minikube

Stopping and deleting the local minikube cluster

Multi-node Kubernetes cluster using minikube

Multi-master Kubernetes cluster using minikube

Multiple Kubernetes clusters using minikube

Multi-node Kubernetes cluster with kind

Installing kind onto your local system

Creating a Kubernetes cluster with kind

Stopping and deleting the local kind cluster

Alternative Kubernetes learning environments

Play with Kubernetes

Killercoda Kubernetes playground

Production-grade Kubernetes clusters

Managed Kubernetes clusters using cloud services

Kubernetes distributions

Kubernetes installation tools

Hybrid and multi-cloud solutions

Choosing the right environment

Running Kubernetes On-Premises: Challenges and Considerations

Summary

Further reading

Running Your Containers in Kubernetes

Technical requirements

Let’s explain the notion of Pods

What are Pods?

Each Pod gets an IP address

How should you design your Pods?

Launching your first Pods

Creating a Pod with imperative syntax

Tags versus digests – ensuring image consistency

Creating a Pod with declarative syntax

Namespaces in Kubernetes

Reading the Pod’s information and metadata

Listing the objects in JSON or YAML

Backing up your resource using the list operation

Getting more information from the list operation

Accessing a Pod from the outside world

Entering a container inside a Pod

Deleting a Pod

Labeling and annotating the Pods

What are labels and why do we need them?

What are annotations and how do they differ from labels?

Adding a label

Listing labels attached to a Pod

Adding or updating a label to/of a running Pod

Deleting a label attached to a running Pod

Adding an annotation

Launching your first Job

What are Jobs?

Creating a job with restartPolicy

Understanding the job’s backoffLimit

Running a task multiple times using completions

Running a task multiple times in parallel

Terminating a job after a specific amount of time

What happens if a job succeeds?

Deleting a job

Launching your first CronJob

What are CronJobs?

Preparing your first CronJob

Understanding the schedule key

Understanding the role of the jobTemplate section

Controlling the CronJob execution deadline

Managing the history limits of jobs

Creating a CronJob

Deleting a CronJob

Summary

Further reading

Using Multi-Container Pods and Design Patterns

Technical requirements

Understanding what multi-container Pods are

Concrete scenarios where you need multi-container Pods

Creating a Pod made up of two containers

What happens when Kubernetes fails to launch one container in a Pod?

Deleting a multi-container Pod

Understanding the Pod deletion grace period

Accessing a specific container inside a multi-container Pod

Running commands in containers

Overriding the default commands run by the containers

Introducing initContainers

Accessing the logs of a specific container

Sharing volumes between containers in the same Pod

What are Kubernetes volumes?

Creating and mounting an emptyDir volume

Creating and mounting a hostPath volume

The ambassador design pattern

What is the ambassador design pattern?

Ambassador multi-container Pod – an example

The sidecar design pattern

What is the sidecar design pattern?

When to use a Sidecar design pattern?

Sidecar multi-container Pod – an example

The adapter design pattern

Adapter multi-container Pod – an example

Sidecars versus Kubernetes Native Sidecars

Summary

Further reading

Namespaces, Quotas, and Limits for Multi-Tenancy in Kubernetes

Technical requirements

Introduction to Kubernetes namespaces

The importance of namespaces in Kubernetes

How namespaces are used to split resources into chunks

Understanding default namespaces

How namespaces impact your resources and services

Listing namespaces inside your cluster

Retrieving the data of a specific namespace

Creating a namespace using imperative syntax

Creating a namespace using declarative syntax

Deleting a namespace

Creating a resource inside a namespace

Listing resources inside a specific namespace

Setting the current namespace using kubectl config set-context

Listing all the resources inside a specific namespace

Recognizing how names are scoped within a namespace

Understanding that not all resources are in a namespace

Resolving a service using namespaces

Best practices for Kubernetes namespaces

Configuring ResourceQuota and Limit at the namespace level

Understanding the need to set ResourceQuotas

Understanding how Pods consume these resources

Understanding how Pods can require computing resources

But what do these metrics mean?

Understanding how you can limit resource consumption

Understanding why you need ResourceQuota

Creating a ResourceQuota

Storage resource quotas

Listing ResourceQuota

Deleting ResourceQuota

Introducing LimitRange

Listing LimitRanges

Deleting LimitRange

Summary

Further reading

Configuring Your Pods Using ConfigMaps and Secrets

Technical requirements

Understanding what ConfigMaps and Secrets are

Decoupling your application and your configuration

Understanding how Pods consume ConfigMaps and Secrets

Configuring your Pods using ConfigMaps

Listing ConfigMaps

Creating a ConfigMap

Creating a ConfigMap from literal values

Storing entire configuration files in a ConfigMap

Creating a ConfigMap from an env file

Reading values inside a ConfigMap

Linking ConfigMaps as environment variables

Using kubectl port-forward

Mounting a ConfigMap as a volume mount

Deleting a ConfigMap

Updating a ConfigMap

Immutable ConfigMaps

Managing sensitive configuration with the Secret object

Listing Secrets

Creating a Secret imperatively with --from-literal

Creating a Secret declaratively with a YAML file

Creating a Secret with content from a file

Reading a Secret

Consuming a Secret as an environment variable

Consuming a Secret as a volume mount

Deleting a Secret

Updating a Secret

Summary

Further reading

Exposing Your Pods with Services

Technical requirements

Why would you want to expose your Pods?

Cluster networking in Kubernetes

IP address management in Kubernetes

Learning about network plugins

What is a service mesh?

Understanding Pod IP assignment

Understanding the dynamics of Pod IP assignment in Kubernetes

Not hardcoding the Pod’s IP address in application development

Understanding how Services route traffic to Pods

Understanding round-robin load balancing in Kubernetes

Understanding how to call a Service in Kubernetes

Understanding how DNS names are generated for Services

How Services discover and route traffic to Pods in Kubernetes

Using a utility Pod for debugging your Services

Understanding the drawbacks of direct kubectl expose in Kubernetes

Understanding how DNS names are generated for Services

Understanding the different types of Services

The NodePort Service

Why do you need NodePort Services?

Creating two containous/whoami Pods

Understanding NodePort YAML definition

Making sure NodePort works as expected

Is this setup production-ready?

Listing NodePort Services

Adding more Pods to NodePort Services

Describing NodePort Services

Deleting Services

NodePort or kubectl port-forward?

The ClusterIP Service

Why do you need ClusterIP Services?

How do I know if I need NodePort or ClusterIP Services to expose my Pods?

Listing ClusterIP Services

Creating ClusterIP Services using the imperative way

Describing ClusterIP Services

Creating ClusterIP Services using the declarative way

Understanding headless Services

The LoadBalancer Service

Supported cloud providers for the LoadBalancer Service type

Should the LoadBalancer Service type be used?

The ExternalName Service type

Implementing Service readiness using probes

What is ReadinessProbe and why do you need it?

Implementing ReadinessProbe

What is LivenessProbe and why do you need it?

Implementing LivenessProbe

HTTP livenessProbe

Command livenessProbe

TCP livenessProbe

Using named Port with TCP and HTTP livenessProbe

Using startupProbe

Using ReadinessProbe and LivenessProbe together

Summary

Further reading

Persistent Storage in Kubernetes

Technical requirements

Why use persistent storage?

Introducing Volumes

Introducing PersistentVolumes

Introducing PersistentVolume types

Benefits brought by PersistentVolume

Introducing PersistentVolume access modes

Creating our first PersistentVolume object

How does Kubernetes PersistentVolumes handle storage?

Creating PersistentVolume with raw block volume

Can Kubernetes handle the provisioning or creation of the resource itself?

Understanding how to mount a PersistentVolume to your Pod

Introducing PersistentVolumeClaim

Splitting storage creation and storage consumption

Understanding the PersistentVolume workflow

Creating a Pod with a PersistentVolumeClaim object

Understanding the life cycle of a PersistentVolume object in Kubernetes

Understanding why PersistentVolume objects are not bound to namespaces

Reclaiming a PersistentVolume object

Updating a reclaim policy

Understanding PersistentVolume and PersistentVolumeClaim statuses

Understanding static and dynamic PersistentVolume provisioning

Static versus dynamic provisioning

Introducing dynamic provisioning

Introduction to CSI

Introducing StorageClasses

Understanding the role of PersistentVolumeClaim for dynamic storage provisioning

Advanced storage topics

Ephemeral volumes for temporary storage in Kubernetes

CSI volume cloning and volume snapshots

Learning how to expand PersistentVolumeClaim

Summary

Further reading

Running Production-Grade Kubernetes Workloads

Technical requirements

Ensuring High Availability and Fault Tolerance on Kubernetes

High availability

Fault tolerance

HA and FT for Kubernetes applications

What is ReplicationController?

What is ReplicaSet?

How does ReplicaSet differ from ReplicationController?

Creating a ReplicaSet object

Testing the behavior of ReplicaSet

Testing HA and FT with a ReplicaSet

Scaling ReplicaSet

Using Pod liveness probes together with ReplicaSet

Deleting a ReplicaSet object

Summary

Further reading

Using Kubernetes Deployments for Stateless Workloads

Technical requirements

Introducing the Deployment object

Creating a Deployment object

Exposing Deployment Pods using Service objects

Creating a Service declaratively

Creating a Service imperatively

Role of readiness, liveness, and startup probes

Scaling a Deployment object

Deleting a Deployment object

How Kubernetes Deployments seamlessly handle revisions and version rollouts

Updating a Deployment object

Rolling back a Deployment object

Canary deployment strategy

Deployment object best practices

Use declarative object management for Deployments

Do not use the Recreate strategy for production workloads

Do not create Pods that match an existing Deployment label selector

Carefully set up your container probes

Use meaningful and semantic image tags

Migrate from older versions of Kubernetes

Include resource management in the Deployment

Scaling and replica management

Security considerations

Summary

Further reading

StatefulSet – Deploying Stateful Applications

Technical requirements

Introducing the StatefulSet object

Managing state in containers

Managing state in Kubernetes Pods

StatefulSet and how it differs from a Deployment object

Exploring the limitations of StatefulSet

Data management in Statefulset

Replication management

Managing StatefulSet

Creating a StatefulSet

Using the headless Service and stable network identities

State persistence

Scaling StatefulSet

Deleting a StatefulSet

Releasing a new version of an app deployed as a StatefulSet

Updating StatefulSet

Rolling back StatefulSet

StatefulSet best practices

Use declarative object management for StatefulSets

Do not use the TerminationGracePeriodSeconds Pod with a 0 value for StatefulSets

Scale down StatefulSets before deleting

Ensure state compatibility during StatefulSet rollbacks

Do not create Pods that match an existing StatefulSet label selector

Use Remote Storage for the PV

Define liveness and readiness probes

Monitor your StatefulSets

Summary

Further reading

DaemonSet – Maintaining Pod Singletons on Nodes

Technical requirements

Introducing the DaemonSet object

How DaemonSet Pods are scheduled

Checking DaemonSets

Creating and managing DaemonSets

Creating a DaemonSet

Prioritizing critical DaemonSets in Kubernetes

Modifying a DaemonSet

Rolling back the DaemonSet

Deleting a DaemonSet

Common use cases for DaemonSets

DaemonSet best practices

Alternatives to DaemonSets

Summary

Further reading

Working with Helm Charts and Operators

Technical requirements

Understanding Helm

Releasing software to Kubernetes using Helm

Installing Helm on Linux

Installing Helm on Windows

Installing Helm on macOS

Installing from the binary releases

Deploying an example chart – WordPress

Deleting a Helm release

Helm chart anatomy

Installing Kubernetes Dashboard using Helm Charts

Secure access to the Kubernetes Dashboard

Accessing Dashboard WEBUI

Installing other popular solutions using Helm charts

Elasticsearch with Kibana

Prometheus with Grafana

Security considerations for Helm Charts

Introducing Kubernetes Operators

From humans to software

Helm Charts versus Kubernetes Operators

How can the Operators help in the application deployment?

Reusability of the automation

How Operators ensure the application state

Custom resource definitions – building blocks for Operators

Benefits of CRDs

Operator distribution mechanism

Building your own Operator

Operator Lifecycle Manager (OLM)

Enabling Kubernetes monitoring using Prometheus and Grafana

Installing Operator Lifecycle Manager

Installing Prometheus and Grafana Operators using OLM

Configuring Prometheus and Grafana instances using Operators

Summary

Further reading

Kubernetes Clusters on Google Kubernetes Engine

Technical requirements

What are Google Cloud Platform and Google Kubernetes Engine?

Google Cloud Platform

Google Kubernetes Engine

Preparing your local environment

Creating a project

Installing the GCP command-line interface

Installing on macOS

Installing on Windows

Installing on Linux

Cloud Shell

Initialization

Launching your first Google Kubernetes Engine cluster

Deploying a workload and interacting with your cluster

Configuring your local client

Launching an example workload

Exploring Google Cloud Console

Workloads

Gateways, Services, and Ingress

Other GKE features

Deleting your cluster

More about cluster nodes

Summary

Further reading

Launching a Kubernetes Cluster on Amazon Web Services with Amazon Elastic Kubernetes Service

Technical requirements

What are Amazon Web Services and Amazon Elastic Kubernetes Service?

Amazon Web Services

Amazon Elastic Kubernetes Service

Preparing your local environment

Signing up for an AWS account

Installing the AWS command-line interface

Installing on macOS

Installing on Linux

Installing on Windows

AWS CLI configuration

Installing eksctl, the official CLI for Amazon EKS

Launching your Amazon Elastic Kubernetes Service cluster

Deploying a workload and interacting with your cluster

Deploying the workload

Exploring the AWS console

Deleting your Amazon Elastic Kubernetes Service cluster

Summary

Further reading

Kubernetes Clusters on Microsoft Azure with Azure Kubernetes Service

Technical requirements

What are Microsoft Azure and Azure Kubernetes Service?

Microsoft Azure

Azure Kubernetes Service

Preparing your local environment

Creating a free Microsoft Azure account

The Azure CLI

Installing on macOS

Installing on Linux

Installing on Windows

Configuring the Azure CLI

Accessing Azure Cloud Shell

Launching your Azure Kubernetes Service cluster

Deploying a workload and interacting with your cluster

Launching the workload

Exploring the Azure portal

Namespaces (Kubernetes resources)

Workloads (Kubernetes resources)

Services and ingresses (Kubernetes resources)

Storage (Kubernetes resources)

Configuration (Kubernetes resources)

Custom resources (Kubernetes resources)

Events (Kubernetes resources)

Run command (Kubernetes resources)

Node pools (Settings)

Cluster configuration (Settings)

Application scaling (Settings)

Networking (Settings)

Extensions + applications (Settings)

Backup (Settings)

Other options (Settings)

Insights (Monitoring)

Deleting your Azure Kubernetes Service cluster

Comparing the three public cloud offerings

Summary

Further reading

Security in Kubernetes

Technical Requirements

Authentication and Authorization – User Access Control

Authentication and User Management

The authentication workflow in Kubernetes

Authentication to the Kubernetes API

Authentication Methods in Kubernetes

Authorization and introduction to RBAC

RBAC mode in Kubernetes

Admission Control – Security Policies and Checks

The Two-Phase Admission Process

Mutation Phase

Validation Phase

Enabling and disabling Admission controllers

Common Admission Controllers

Benefits of Admission Controllers

Securing Pods and Containers

Securing Pods and Containers in Kubernetes Using Security Context

Key Components of SecurityContext

Applying SecurityContext at Pod and Container Levels

Applying Security Context to a Pod

Securing Pods using the NetworkPolicy object

Why do you need NetworkPolicy?

Understanding Pods are not isolated by default

Configuring NetworkPolicy with labels and selectors

Securing Communication – TLS Certificates Between Kubernetes Components

Container Security – gVisor and Kata Containers

gVisor (Guest Virtual Machine Supervisor)

Kata Containers

Using RuntimeClass for Security Profiles

Managing Secrets and Registry Credentials

Using kubectl to create a Docker registry secret

Summary

Further reading

Advanced Techniques for Scheduling Pods

Technical requirements

Refresher – What is kube-scheduler?

Managing Node affinity

Using nodeName for Pods

Using nodeSelector for Pods

Using the nodeAffinity configuration for Pods

Using Node taints and tolerations

Understanding Static Pods in Kubernetes

Extended scheduler configurations in Kubernetes

Scheduler configuration

Node isolation and restrictions

Tuning Kubernetes scheduler performance

Summary

Further reading

Autoscaling Kubernetes Pods and Nodes

Technical requirements

Pod resource requests and limits

Autoscaling Pods vertically using a VerticalPodAutoscaler

Enabling InPlacePodVerticalScaling

Enabling a VPA in GKE

Enabling a VPA for other Kubernetes clusters

Using a VPA

Autoscaling Pods horizontally using a HorizontalPodAutoscaler

Deploying the app for HPA demonstration

Implementing an HPA

Autoscaling Kubernetes Nodes using a Cluster Autoscaler

CA limitations

Enabling the CA in GKE

Enabling a CA in Amazon Elastic Kubernetes Service

Enabling a CA in Azure Kubernetes Service

Using the CA

Alternative autoscalers for Kubernetes

KEDA

Karpenter

Summary

Further reading

Advanced Kubernetes: Traffic Management, Multi-Cluster Strategies, and More

Technical Requirements

Advanced Traffic Routing with Ingress

Refresher – Kubernetes Services

Overview of the Ingress object

Using nginx as an Ingress Controller

Deploying the NGINX Ingress Controller in minikube

Deploying Ingress Resources in Kubernetes

ingressClass and Multiple Ingress Controllers

Azure Application Gateway Ingress Controller for AKS

Why Choose AGIC for AKS?

Gateway API

Understanding Endpoints and EndpointSlices

Modern Advancements with Kubernetes

Serverless with Knative and OpenFaaS

Kubeflow – Machine Learning on Kubernetes

KubeVirt – Virtual Machines on Kubernetes

Maintaining Kubernetes Clusters – Day 2 Tasks

Kubernetes Cluster Backup and Restore

Taking Backup of etcd

etcd Snapshot Restore with etcdutl

Reconfiguring the Kubernetes API Server

Leveraging Infrastructure as Code (IaC) and Configuration as Code (CaC) for Resilient Cluster Management

Kubernetes Cluster Upgrades

Pre-Upgrade Checklist

Upgrade Process

Post-Upgrade Tasks

Rollback Plan

Additional Tips

Multi-Cluster Management

Securing a Kubernetes Cluster – Best Practices

Controlling Access to the Kubernetes API

Controlling Access to the Kubelet

Controlling Workload or User Capabilities at Runtime

Restricting Network Access

Protecting Cluster Components

Troubleshooting Kubernetes

Getting details about resources

Kubernetes Logs and Events for troubleshooting

kubectl explain – the inline helper

Interactive troubleshooting using kubectl exec

Ephemeral Containers in Kubernetes

Common troubleshooting tasks in Kubernetes

Summary

Further reading

Other Books You May Enjoy

Leave a Review!

Index

Landmarks

Cover

Index

Preface

Containers have allowed a real leap forward since their massive adoption in the world of virtualization because they have allowed greater flexibility, especially these days, when buzzwords such as cloud, agile, and DevOps are on everyone’s lips.

Today, almost no one questions the use of containers—they’re basically everywhere, especially after the success of Docker and the rise of Kubernetes as the leading platform for container orchestration.

Containers have brought tremendous flexibility to organizations, but they have remained questionable for a very long time when organizations face the challenge of deploying them in production. For years, companies have been using containers for proof-of-concept projects, local development, and similar purposes, but the idea of using containers for real production workloads was inconceivable for many organizations.

Container orchestrators were the game-changer, with Kubernetes in the lead. Originally built by Google, today, Kubernetes is the leading container orchestrator that provides you with all the features you need in order to deploy containers in production at scale. Kubernetes is popular, but it is also complex. This tool is so versatile that getting started with it and progressing to advanced usage is not an easy task: it is not an easy tool to learn and operate.

As an orchestrator, Kubernetes has its own concepts independent of those of a container engine. But when both container engines and orchestrators are used together, you get a very strong platform ready to deploy your cloud-native applications in production. As engineers working with Kubernetes daily, we were convinced, like many, that it was a technology to master, and we decided to share our knowledge in order to make Kubernetes accessible by covering most of this orchestrator.

This book is entirely dedicated to Kubernetes and is the result of our work. It provides a broad view of Kubernetes and covers a lot of aspects of the orchestrator, from pure container Pod creation to deploying the orchestrator on the public cloud. We didn’t want this book to be a Getting Started guide.

We hope this book will teach you everything you want to learn about Kubernetes!

Who this book is for

This book is for people who intend to use Kubernetes with container runtimes. Although Kubernetes supports various container engines through the Container Runtime Interface (CRI) and is not tied to any specific one, the combination of Kubernetes with containerd remains one of the most common use cases.

This book is highly technical, with a primary focus on Kubernetes and container runtimes from an engineering perspective. It is intended for engineers, whether they come from a development or system administration background and is not aimed at project managers. It is a Kubernetes bible for people who are going to use Kubernetes daily, or for people who wish to discover this tool. You shouldn’t be afraid of typing some commands on a terminal.

Being a total beginner to Kubernetes or having an intermediate level is not a problem for following this book. While we cover some container fundamentals within the chapters, it’s helpful to have basic technical familiarity with containers. This book can also serve as a guide if you are in the process of migrating an existing application to Kubernetes.

The book incorporates content that will allow readers to deploy Kubernetes on public cloud offerings such as Amazon EKS or Google GKE. Cloud users who wish to add Kubernetes to their stack on the cloud will appreciate this book.

What this book covers

Chapter 1, Kubernetes Fundamentals, is an introduction to Kubernetes. We’re going to explain what Kubernetes is, why it was created, who created it, who keeps this project alive, and when and why you should use it as part of your stack.

Chapter 2, Kubernetes Architecture – from Container Images to Running Pods, covers how Kubernetes is built as a distributed software and is technically not a single monolith binary but built as a set of microservices interacting with each other. We’re going to explain this architecture and how Kubernetes proceeds to translate your instructions into running containers in this chapter.

Chapter 3, Installing Your First Kubernetes Cluster, explains that Kubernetes is really difficult to install due to its distributed nature, so as to make the learning process easier, it is possible to install Kubernetes clusters by using one of its distributions. Kind and minikube are two options we’re going to discover in this chapter to have a Kubernetes cluster working on your machine.

Chapter 4, Running Your Containers in Kubernetes, is an introduction to the concept of Pods.

Chapter 5, Using Multi-Container Pods and Design Patterns, introduces multi-container Pods and design patterns such as a proxy, adapter, or sidecar that you can build when running several containers as part of the same Pod.

Chapter 6, Namespaces, Quotas, and Limits for Multi-Tenancy in Kubernetes, explains how using namespaces is a key aspect of cluster management and, inevitably, you’ll have to deal with namespaces during your journey with Kubernetes. Though it’s a simple notion, it is a key one, and you’ll have to master namespaces perfectly in order to be successful with Kubernetes. We will also learn how to implement multi-tenancy in Kubernetes using Namespaces, Quotas and Limits.

Chapter 7, Configuring Your Pods Using ConfigMaps and Secrets, explains how, in Kubernetes, we separate Kubernetes applications from their configurations. Both applications and configurations have their own life cycle, thanks to the ConfigMap and Secret resources. This chapter will be dedicated to these two objects and how to mount data in a ConfigMap or Secret as environment variables or volumes mounted on your Pod.

Chapter 8, Exposing Your Pods with Services, teaches you about the notion of services in Kubernetes. Each Pod in Kubernetes gets assigned its own IP address dynamically. Services are extremely useful if you want to provide a consistent one to expose Pods within your cluster to other Pods or to the outside world, with a single static DNS name. You’ll learn here that there are three main service types, called ClusterIp, NodePort, and LoadBalancer, which are all dedicated to a single use case in terms of Pod exposition.

Chapter 9, Persistent Storage in Kubernetes, covers how, by default, Pods are not persistent. As they’re just managing raw containers, destroying them will result in the loss of your data. The solution to that is the usage of persistent storage thanks to the PersistentVolume and PersistentVolumeClaim resources. This chapter is dedicated to these two objects and the StorageClass object: it will teach you that Kubernetes is extremely versatile in terms of storage and that your Pods can be interfaced with a lot of different storage technologies.

Chapter 10, Running Production-Grade Kubernetes Workloads, takes a deep dive into high availability and fault tolerance in Kubernetes using ReplicationController and ReplicaSet.

Chapter 11, Using Kubernetes Deployments for Stateless Workloads, is a continuation of the previous chapter and explains how to manage multiple versions of ReplicaSets using the Deployment object. This is the basic building block for stateless applications running on Kubernetes.

Chapter 12, StatefulSet – Deploying Stateful Applications, takes a look at the next important Kubernetes object: StatefulSet. This object is the backbone of running stateful applications on Kubernetes. We’ll explain the most important differences between running stateless and stateful applications using Kubernetes.

Chapter 13, DaemonSet – Maintaining Pod Singletons on Nodes, covers DaemonSet, which are a special Kubernetes object that can be used for running operational or supporting workloads on Kubernetes clusters. Whenever you need to run precisely one container Pod on a single Kubernetes node, DaemonSet is what you need.

Chapter 14, Working with Helm Charts and Operators, covers Helm Charts, which is a dedicated packaging and redistribution tool for Kubernetes applications. Armed with knowledge from this chapter, you will be able to quickly set up your Kubernetes development environment or even plan for the redistribution of your Kubernetes application as a dedicated Helm Chart. In this chapter, we will also introduce the Kubernetes operators and how they will help you to deploy application stacks.

Chapter 15, Kubernetes Clusters on Google Kubernetes Engine, looks at how we can move our Kubernetes workload to Google Cloud using both the native command-line client and the Google Cloud console.

Chapter 16, Launching a Kubernetes Cluster on Amazon Web Services with Amazon Elastic Kubernetes Service, looks at moving the workload we launched in the previous chapter to Amazon’s Kubernetes offering.

Chapter 17, Kubernetes Clusters on Microsoft Azure with Azure Kubernetes Service, looks at launching a cluster in Microsoft Azure.

Chapter 18, Security in Kubernetes, covers authorization using built-in role-based access control and authorization schemes together with user management. This chapter also teaches you about admission controllers, TLS certificates based communication, and security context implementations.

Chapter 19, Advanced Techniques for Scheduling Pods, takes a deeper look at Node affinity, Node taints and tolerations, and advanced scheduling policies in general.

Chapter 20, Autoscaling Kubernetes Pods and Nodes, introduces the principles behind autoscaling in Kubernetes and explains how to use Vertical Pod Autoscaler, Horizontal Pod Autoscaler, and Cluster Autoscaler.

Chapter 21, Advanced Kubernetes: Traffic Management, Multi-Cluster Strategies, and More, covers Ingress objects and IngressController in Kubernetes. We explain how to use nginx as an implementation of IngressController and how you can use Azure Application Gateway as a native IngressController in Azure environments. We will also explain advanced Kubernetes topics including Cluster Day 2 tasks, best practices, and troubleshooting.

To get the most out of this book

While we cover container fundamentals in the chapters, this book is focused on Kubernetes. Although Kubernetes supports multiple container engines, the content primarily discusses using Kubernetes with containerd as the runtime. You don’t need to be an expert, but having a basic understanding of launching and managing applications with containers will be helpful before diving into this book.

While it is possible to run Windows containers with Kubernetes, most of the topics covered in this book will be Linux-based. Having a good knowledge of Linux will be helpful, but is not required. Again, you don’t have to be an expert: knowing how to use a terminal session and basic Bash scripting should be enough.

Lastly, having some general knowledge of software architecture such as REST APIs will be beneficial.

Software/hardware covered in the book

OS Requirements

Kubernetes >= 1.31

Windows, macOS, Linux

kubectl >= 1.31

Windows, macOS, Linux

We strongly advise you to not attempt to install Kubernetes or kubectl on your machine for now. Kubernetes is not a single binary but is distributed software composed of several components and, as such, it is really complex to install a complete Kubernetes cluster from scratch. Instead, we recommend that you follow the third chapter of this book, which is dedicated to the setup of Kubernetes.

If you are using the digital version of this book, we advise you to type the code yourself or access the code via the GitHub repository (link available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Please note that kubectl, helm, etc. are the tools we’re going to use most frequently in this book, but there is a huge ecosystem around Kubernetes and we might install additional software not mentioned in this section. This book is also about using Kubernetes in the cloud, and we’re going to discover how to provision Kubernetes clusters on public cloud platforms such as Amazon Web Services and Google Cloud Platform. As part of this setup, we might install additional software dedicated to these platforms that are not strictly bound to Kubernetes, but also to other services provided by these platforms.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/The-Kubernetes-Bible-Second-Edition. In case there’s an update to the code, it will be updated on the existing GitHub repository.

We also have other code bundles from our rich catalogue of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781835464717_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in the text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “Now, we need to create a kubeconfig file for our local kubectl CLI.”

A block of code is set as follows:

apiVersion:v1kind:Podmetadata:name:nginx-Pod

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

apiVersion:v1kind:ReplicationControllermetadata:name:nginx-replicationcontroller-example

Any command-line input or output is written as follows:

$ kubectl get nodes

Bold: Indicates a new term, an important word, or words that you see on screen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: “On this screen, you should see an Enable Billing button.”

IMPORTANT NOTES

appear like this

Tips

appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Leave a Review!

Thank you for purchasing this book from Packt Publishing—we hope you enjoy it! Your feedback is invaluable and helps us improve and grow. Once you’ve completed reading it, please take a moment to leave an Amazon review; it will only take a minute, but it makes a big difference for readers like you.

Scan the QR code below to receive a free ebook of your choice.

https://packt.link/NzOWQ

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily.

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below:

https://packt.link/free-ebook/9781835464717

Submit your proof of purchase.That’s it! We’ll send your free PDF and other benefits to your email directly.

1

Kubernetes Fundamentals

Welcome to The Kubernetes Bible, and we are happy to accompany you on your journey with Kubernetes. If you are working in the software development industry, you have probably heard about Kubernetes. This is normal because the popularity of Kubernetes has grown a lot in recent years.

Built by Google, Kubernetes is the leading container orchestrator solution in terms of popularity and adoption: it’s the tool you need if you are looking for a solution to manage containerized applications in production at scale, whether it’s on-premises or on a public cloud. Be focused on the word. Deploying and managing containers at scale is extremely difficult because, by default, container engines such as Docker do not provide any way on their own to maintain the availability and scalability of containers at scale.

Kubernetes first emerged as a Google project, and Google has put a lot of effort into building a solution to deploy a huge number of containers on their massively distributed infrastructure. By adopting Kubernetes as part of your stack, you’ll get an open source platform that was built by one of the biggest companies on the internet, with the most critical needs in terms of stability.

Although Kubernetes can be used with a lot of different container runtimes, this book is going to focus on the Kubernetes and containers (Docker and Podman) combination.

Perhaps you are already using Docker on a daily basis, but the world of container orchestration might be completely unknown to you. It is even possible that you do not even see the benefits of using such technology because everything looks fine to you with just raw Docker. That’s why, in this first chapter, we’re not going to look at Kubernetes in detail. Instead, we will focus on explaining what Kubernetes is and how it can help you manage your application containers in production. It will be easier for you to learn a new technology if you understand why it was built.

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

Understanding monoliths and microservicesUnderstanding containers How can Kubernetes help you to manage containers?Understanding the history of KubernetesExploring the problems that Kubernetes solves

You can download the latest code samples for this chapter from the official GitHub repository at https://github.com/PacktPublishing/The-Kubernetes-Bible-Second-Edition/tree/main/Chapter01

Understanding monoliths and microservices

Let’s put Kubernetes and Docker to one side for the moment, and instead, let’s talk a little bit about how the internet and software development evolved together over the past 20 years. This will help you to gain a better understanding of where Kubernetes sits and the problems it solves.

Understanding the growth of the internet since the late 1990s

Since the late 1990s, the popularity of the internet has grown rapidly. Back in the 1990s, and even in the early 2000s, the internet was only used by a few hundred thousand people in the world. Today, almost 2 billion people are using the internet for email, web browsing, video games, and more.

There are now a lot of people on the internet, and we’re using it for tons of different needs, and these needs are addressed by dozens of applications deployed on dozens of devices.

Additionally, the number of connected devices has increased, as each person can now have several devices of a different nature connected to the internet: laptops, computers, smartphones, TVs, tablets, and more.

Today, we can use the internet to shop, to work, to entertain, to read, or to do whatever. It has entered almost every part of our society and has led to a profound paradigm shift in the last 20 years. All of this has given the utmost importance to software development.

Understanding the need for more frequent software releases

To cope with this ever-increasing number of users who are always demanding more in terms of features, the software development industry had to evolve in order to make new software releases faster and more frequent.

Indeed, back in the 1990s, you could build an application, deploy it to production, and simply update it once or twice a year. Today, companies must be able to update their software in production, sometimes several times a day, whether to deploy a new feature, integrate with a social media platform, support the resolution of the latest fashionable smartphone, or even release a patch to a security breach identified the day before. Everything is far more complex today, and you must go faster than before.

We constantly need to update our software, and in the end, the survival of many companies directly depends on how often they can offer releases to their users. But how do we accelerate software development life cycles so that we can deliver new versions of our software to our users more frequently?

IT departments of companies had to evolve, both in an organizational sense and a technical sense. Organizationally, they changed the way they managed projects and teams in order to shift to agile methodologies, and technically, technologies such as cloud computing platforms, containers, and virtualization were adopted widely and helped a lot to align technical agility with organizational agility. All of this is to ensure more frequent software releases! So, let’s focus on this evolution next.

Understanding the organizational shift to agile methodologies

From a purely organizational point of view, agile methodologies such as Scrum, Kanban, and DevOps became the standard way to organize IT teams.

Typical IT departments that do not apply agile methodologies are often made of three different teams, each of them having a single responsibility in the development and release process life cycle.

Rest assured, even though we are currently discussing agile methodologies and the history of the internet, this book is really about Kubernetes! We just need to explain some of the problems that we have faced before introducing Kubernetes for real!

Before the adoption of agile methodologies, development and operations often worked in separate silos. This could lead to inefficiency and communication gaps. Agile methodologies helped bridge these gaps and foster collaboration. The three isolated teams are shown below.

The business team: They’re like the voice of the customer. Their job is to explain what features are needed in the app to meet user needs. They translate business goals into clear instructions for the developers. The development team: These are the engineers who bring the app to life. They translate the business team’s feature requests into code, building the functionalities and features users will interact with. Clear communication from the business team is crucial. If the instructions aren’t well defined, it can be like a game of telephone – misunderstandings lead to delays and rework. The operation team: They’re the keepers of the servers. Their main focus is keeping the app running smoothly. New features can be disruptive because they require updates, which can be risky. In the past, they weren’t always aware of what new features were coming because they weren’t involved in the planning.

These are what we call silos, as illustrated in Figure 1.1:

Figure 1.1: Isolated teams in a typical IT department

The roles are clearly defined, people from the different teams do not work together that much, and when something goes wrong, everyone loses time finding the right information from the right person.

This kind of siloed organization has led to major issues:

A significantly longer development timeGreater risk in the deployment of a release that might not work at all in production

And that’s essentially what agile methodologies and DevOps fixed. The change agile methodologies made was to make people work together by creating multidisciplinary teams.

DevOps is a collaborative culture and set of practices that aims to bridge the gap between development (Dev) and operations (Ops) teams. DevOps promotes collaboration and automation throughout the software lifecycle, from development and testing to deployment and maintenance.

An agile team consists of a product owner describing concrete features by writing them as user stories that are readable by the developers who are working in the same team as them. Developers should have visibility of the production environment and the ability to deploy on top of it, preferably using a continuous integration and continuous deployment (CI/CD) approach. Testers should also be part of agile teams in order to write tests.

With the collaborative approach, the teams will get better and clearer visibility of the full picture, as illustrated in the following diagram.

Figure 1.2: Team collaboration breaks silos

Simply understand that, by adopting agile methodologies and DevOps, these silos were broken and multidisciplinary teams capable of formalizing a need, implementing it, testing it, releasing it, and maintaining it in the production environment were created. Table 1.1 presents a shift from traditional development to agile and DevOps methodology.

Feature

Traditional Development

Agile & DevOps

Team Structure

Siloed departments (Development, Operations)

Cross-functional, multi-disciplinary teams

Work Style

Isolated workflows, limited communication

Collaborative, iterative development cycles

Ownership

Development hands off to Operations for deployment and maintenance

“You Build It, You Run It” - Teams own the entire lifecycle

Focus

Features and functionality

Business value, continuous improvement

Release Cycle

Long release cycles, infrequent deployments

Short sprints, frequent releases with feedback loops

Testing

Separate testing phase after development

Integrated testing throughout the development cycle

Infrastructure

Static, manually managed infrastructure

Automated infrastructure provisioning and management (DevOps)

Table 1.1: DevOps vs traditional development – a shift in collaboration

So, we’ve covered the organizational transition brought about by the adoption of agile methodologies. Now, let’s discuss the technical evolution that we’ve gone through over the past several years.

Understanding the shift from on-premises to the cloud

Having agile teams is very nice, but agility must also be applied to how software is built and hosted.

With the aim to always achieve faster and more recurrent releases, agile software development teams had to revise two important aspects of software development and release:

HostingSoftware architecture

Today, apps are not just for a few hundred users but potentially for millions of users concurrently. Having more users on the internet also means having more computing power capable of handling them. And, indeed, hosting an application became a very big challenge.

In the early days of web hosting, businesses primarily relied on two main approaches to housing their applications: one of these approaches is on-premises hosting. This method involved physically owning and managing the servers that ran their applications. There are two main ways to achieve on-premises hosting:

Dedicated Servers: Renting physical servers from established data center providers: This involved leasing dedicated server hardware from a hosting company. The hosting provider would manage the physical infrastructure (power, cooling, security) but the responsibility for server configuration, software installation, and ongoing maintenance fell to the business. This offered greater control and customization compared to shared hosting, but still required significant in-house technical expertise.Building Your Own Data Center: Constructing and maintaining a private data center: This option involved a massive investment by the company to build and maintain its own physical data center facility. This included purchasing server hardware, networking equipment, and storage solutions, and implementing robust power, cooling, and security measures. While offering the highest level of control and security, this approach was very expensive and resource-intensive and was typically only undertaken by large corporations with significant IT resources.

Also note that on-premises hosting also encompasses managing the operating system, security patches, backups, and disaster recovery plans for the servers. Companies often needed a dedicated IT staff to manage and maintain their on-premises infrastructure, adding to the overall cost.

When your user base grows, you need to get more powerful machines to handle the load. The solution is to purchase a more powerful server and install your app on it from the start or to order and rack new hardware if you manage your data center. This is not very flexible. Today, a lot of companies are still using an on-premises solution, and often, it’s not very flexible.

The game-changer was the adoption of the other approach, which is the public cloud, which is the opposite of on-premises. The idea behind cloud computing is that big companies such as Amazon, Google, and Microsoft, which own a lot of datacenters, decided to build virtualization on top of their massive infrastructure to ensure the creation and management of virtual machines was accessible by APIs. In other words, you can get virtual machines with just a few clicks or just a few commands.

The following table provides high-level information about why cloud computing is good for organizations.

Feature

On-Premises

Cloud

Scalability

Limited – requires purchasing new hardware when scaling up

Highly scalable – easy to add or remove resources on demand

Flexibility

Inflexible – changes require physical hardware adjustments

Highly flexible – resources can be provisioned and de-provisioned quickly

Cost

High upfront cost for hardware, software licenses, and IT staff

Low upfront cost – pay-as-you-go model for resources used

Maintenance

Requires dedicated IT staff for maintenance and updates

Minimal maintenance required – cloud provider manages infrastructure

Security

High level of control over security, but requires significant expertise

Robust security measures implemented by cloud providers

Downtime

Recovery from hardware failures can be time-consuming

Cloud providers offer high availability and disaster recovery features

Location

Limited to the physical location of datacenter

Access from anywhere with an internet connection

Table 1.2: Importance of cloud computing for organizations

We will learn how cloud computing technology has helped organizations scale their IT infrastructure in the next section.

Understanding why the cloud is well suited for scalability

Today, virtually anyone can get hundreds or thousands of servers, in just a few clicks, in the form of virtual machines or instances created on physical infrastructure maintained by cloud providers such as Amazon Web Services, Google Cloud Platform, and Microsoft Azure