43,19 €
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:
Seitenzahl: 1024
Veröffentlichungsjahr: 2024
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
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!
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.
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’s Discord space for discussions with the authors and other readers:
https://packt.link/cloudanddevops
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
Cover
Index
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!
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.
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.
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.
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!
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.
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-PodWhen 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-exampleAny command-line input or output is written as follows:
$ kubectl get nodesBold: 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.
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.
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
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.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 solvesYou 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
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.
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.
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.
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 productionAnd 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.
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 architectureToday, 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.
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