Becoming KCNA Certified E-Book

Dmitry Galkin

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 361

Veröffentlichungsjahr: 2023

Beschreibung

Kick-start your learning journey and implement both Kubernetes and cloud-native technologies in real-life scenarios with this essential, practical guide to the KCNA exam

Purchase of the print or Kindle book includes a free PDF eBook

Key Features

• Gain an in-depth understanding of cloud-native computing and Kubernetes concepts
• Prepare for the KCNA exam with the help of practical examples and mock exams
• Manage your applications better with Kubernetes container orchestration

Book Description

The job market related to the cloud and cloud-native technologies is both growing and becoming increasingly competitive, making certifications like KCNA a great way to stand out from the crowd and learn about the latest advancements in cloud technologies.

Becoming KCNA Certified doesn't just give you the practical skills needed to deploy and connect applications in Kubernetes, but it also prepares you to pass the Kubernetes and Cloud Native Associate (KCNA) exam on your first attempt.

The book starts by introducing you to cloud-native computing, containers, and Kubernetes through practical examples, allowing you to test the theory out for yourself. You'll learn how to configure and provide storage for your Kubernetes-managed applications and explore the principles of modern cloud-native architecture and application delivery, giving you a well-rounded view of the subject. Once you've been through the theoretical and practical aspects of the book, you'll get the chance to test what you've learnt with two mock exams, with explanations of the answers, so you'll be well-prepared to appear for the KCNA exam.

By the end of this Kubernetes book, you'll have everything you need to pass the KCNA exam and forge a career in Kubernetes and cloud-native computing.

What you will learn

• Get to grips with Cloud Native Computing Foundation (CNCF) and its projects
• Build, configure, and run containers with Docker
• Bootstrap minimal Kubernetes clusters for learning
• Manage and encrypt container traffic with Service Mesh
• Deploy, configure, and update applications on Kubernetes
• Control and connect the applications that run on Kubernetes
• Manage storage and provide observability on Kubernetes
• Automate software development with CI/CD and GitOps

Who this book is for

This book is for DevOps engineers, system administrators, developers, fresh IT graduates, or anyone interested in cloud native architecture, applications, and technologies. Those with relevant work experience looking to upskill themselves in order to manage their applications with Kubernetes in a better way will also find this book helpful. Familiarity with IT fundamentals, networks, and command line interface (CLI) is required, but no prior knowledge of Kubernetes, docker, or cloud services is needed to get started with this book.

Leseprobe

Becoming KCNA Certified

Build a strong foundation in cloud native and Kubernetes and pass the KCNA exam with ease

Dmitry Galkin

BIRMINGHAM—MUMBAI

Becoming KCNA Certified

Copyright © 2023 Packt Publishing

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

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

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

Group Product Manager: Rahul Nair

Publishing Product Manager: Surbhi Suman

Senior Content Development Editor: Sayali Pingale

Technical Editor: Nithik Cheruvakodan

Copy Editor: Safis Editing

Project Manager: Sean Lobo

Proofreader: Safis Editing

Indexer: Hemangini Bari

Production Designer: Prashant Ghare

Senior Marketing Coordinator: Nimisha Dua

First published: February 2023

Production reference: 1130123

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80461-339-9

www.packtpub.com

I would like to thank my beloved, Solongo, for her endless support, patience, and understanding throughout the 9-month-long journey of writing this book.

I would also like to thank my brother, German, who has been a great teacher and who inspired me to tie my life to IT at a very young age.

– Dmitry Galkin

Contributors

About the author

Dmitry Galkin is a cloud expert and a founder of Cloudification. For 12+ years, he has been working with cloud technologies, cloud-native solutions, DevOps, infrastructure, and service automation domains in a variety of roles. He has consulted international enterprises and supported small start-ups, mentored students, and developed IT certification programs for non-profit organizations as a subject matter expert.

Dmitry is an open source contributor, and he holds more than 10 professional certifications, including all four Kubernetes certifications from CNCF (namely, KCNA, CKA, CKAD, and CKS). He is based in Berlin and holds a master of science degree from the University of Bremen, Germany.

About the reviewers

Werner Dijkerman is a freelance cloud, Kubernetes (certified), and DevOps engineer. He’s currently focused on, and working with, cloud-native solutions and tools, including AWS, Ansible, Kubernetes, and Terraform. He is also focused on infrastructure as code and monitoring the correct thing, with tools such as Zabbix, Prometheus, and the ELK stack, and has a passion for automating everything and avoiding doing anything that resembles manual work. He is an active reader of comics and non-fictional and IT-related books, and he is a technical reviewer for various books about DevOps, CI/CD, and Kubernetes.

Johann Gyger is a passionate software engineer living in Switzerland. He has over 20 years of industry experience working as a developer, architect, trainer, and consultant in various domains and for different customers and employers. Besides being a Cloud Native Ambassador, Johann is enthusiastic about the cloud-native movement and organizes the Swiss Cloud Native Day and the Cloud Native Bern Meetup. He strongly believes in open source software and vendor-neutral standards.

Table of Contents

Preface

Part 1: The Cloud Era

1

From Cloud to Cloud Native and Kubernetes

The cloud and Before Cloud (B.C.)

Virtualization

The cloud

Evolution of the cloud and cloud-native

Containers and container orchestration

Monolithic versus microservices applications

Kubernetes and its origins

Summary

Questions

2

Overview of CNCF and Kubernetes Certifications

OSS and open standards

Open standards

Linux and CNCF

CNCF

CNCF community and governance

Cloud roles and personas

Kubernetes certification path

Summary

Questions

Part 2: Performing Container Orchestration

3

Getting Started with Containers

Technical requirements

Introducing Docker

Exploring container technology

Installing Docker and running containers

Building container images

Summary

Questions

Further reading

4

Exploring Container Runtimes, Interfaces, and Service Meshes

Container runtimes

Container networking

Container storage

Container security

Introducing service meshes

Summary

Questions

Further reading

Part 3: Learning Kubernetes Fundamentals

5

Orchestrating Containers with Kubernetes

Kubernetes architecture

The Kubernetes API

K8s – the Swiss Army knife of container orchestration

Installing and exploring K8s with minikube

Summary

Questions

Further reading

6

Deploying and Scaling Applications with Kubernetes

Deployments, ReplicaSets, and DaemonSets

Running stateful workloads

Application configuration and service discovery

Ensuring applications are alive and healthy

Summary

Questions

Further reading

7

Application Placement and Debugging with Kubernetes

Scheduling in Kubernetes

Resource requests and limits

Debugging applications in Kubernetes

Summary

Questions

Further reading

8

Following Kubernetes Best Practices

Kubernetes networking essentials

RBAC

Helm – the package manager for K8s

Kubernetes best practices

Summary

Questions

Further reading

Part 4: Exploring Cloud Native

9

Understanding Cloud Native Architectures

Cloud Native architectures

Resiliency and autoscaling

Serverless

Cloud Native best practices

Summary

Questions

Further reading

10

Implementing Telemetry and Observability in the Cloud

Telemetry and observability

Prometheus for monitoring and alerting

FinOps and cost management

Summary

Questions

Further reading

11

Automating Cloud Native Application Delivery

Delivery of Cloud Native applications

CI/CD and GitOps

GitOps

Infrastructure as a Code (IaC)

Summary

Questions

Further reading

Part 5: KCNA Exam and Next Steps

12

Practicing for the KCNA Exam with Mock Papers

About the KCNA exam

Tips on getting ready

Mock exam A

Mock exam B

13

The Road Ahead

Advancing a cloud-native career

Contributing to open source

Further reading

Assessments

Chapter 1 – From Cloud to Cloud Native and Kubernetes

Chapter 2 – Overview of CNCF and Kubernetes Certifications

Chapter 3 – Getting Started with Containers

Chapter 4 – Exploring Container Runtimes, Interfaces, and Service Meshes

Chapter 5 – Orchestrating Containers with Kubernetes

Chapter 6 – Deploying and Scaling Applications with Kubernetes

Chapter 7 – Application Placement and Debugging with Kubernetes

Chapter 8 – Following Kubernetes Best Practices

Chapter 9 – Understanding Cloud Native Architectures

Chapter 10 – Implementing Telemetry and Observability in the Cloud

Chapter 11 – Automating Cloud Native Application Delivery

Chapter 12 – Practicing for the KCNA Exam

Mock exam A

Mock exam B

Index

Other Books You May Enjoy

Preface

With more than 20 releases to date, Kubernetes is as hot as ever, even several years after its initial appearance in 2014. Kubernetes, along with other cloud-native technologies, is massively reshaping the IT landscapes in some of the most advanced and progressive companies around the world.

According to the 10th annual Open Source Jobs Report by the Linux Foundation, cloud and containers are highlighted as the most demanded skills categories. Hence, having a strong command of Kubernetes and cloud-native skills is essential for advancing your career and working at some of the best organizations today. Becoming a certified Kubernetes and Cloud Native Associate helps you to stand out and prove your competence in the field.

This book will take you on a cloud-native journey from the very beginning and will teach you both the theoretical and practical aspects of Kubernetes. You’ll learn how to build, configure, and run containers with Docker; how to bootstrap minimal Kubernetes clusters; how to deploy, configure, and manage containerized applications with Kubernetes; how to automate software delivery with CI/CD, and much more. You’ll build a solid foundation to pass the KCNA exam on the first attempt and get a well-rounded view of today’s industry standards.

The book is divided into five parts:

The Cloud EraPerforming Container OrchestrationLearning Kubernetes FundamentalsExploring Cloud NativeKCNA Exam and Next Steps

In the first part, you’ll be introduced to cloud native computing, explaining how the industry evolved and why modern applications often run in containers. Next, you’ll learn about Docker and get hands-on with running containers locally.

In Part 3, the largest part, you’ll learn about Kubernetes: its features, architecture, API, and components. You’ll find the best practices, recap questions, and lots of practical assignments to support your journey. In Part 4, we’ll focus on cloud-native architectures and other technologies from the cloud-native ecosystem. We’ll see how to monitor, observe, and deliver cloud-native applications. Finally, in Part 5, you’ll find mock exams and tips on passing KCNA, as well as some advice on how to proceed after becoming certified.

Who this book is for

Kubernetes and Cloud Native Associate (KCNA) is a pre-professional certification designed for candidates interested in advancing to the professional level through a demonstrated understanding of Kubernetes foundational knowledge and skills.

A certified KCNA will confirm conceptual knowledge of the entire cloud native ecosystem, particularly focusing on Kubernetes. KCNA will demonstrate the candidate’s basic knowledge of Kubernetes and cloud-native technologies, including how to deploy an application using basic kubectl commands, the architecture of Kubernetes, understanding the cloud native landscape and projects, and understanding the basics of cloud-native security.

Whether a fresh IT graduate, a developer, a system administrator, or a DevOps engineer, regardless of experience, anyone interested in learning about Kubernetes and cloud-native technologies will find this book practical and easy to follow. Familiarity with IT fundamentals (Git), operating systems, and command-line interfaces is required, but no prior knowledge of Kubernetes, Docker, or cloud-native technologies is needed to get started.

What this book covers

Chapter 1, From Cloud to Cloud Native and Kubernetes, shares how computing has evolved over the past 20+ years. It explains what the cloud is, how it appeared, and how IT landscapes have changed with the introduction of containers. You will learn about fundamentals such as IaaS, PaaS, SaaS, and FaaS, as well as take a first look at Kubernetes.

Chapter 2, Overview of CNCF and Kubernetes Certifications, introduces the Cloud Native Computing Foundation (CNCF) and its parent organization – the Linux Foundation. It will share what is behind those foundations, how they appeared, and which projects are curated in their ecosystems. This chapter will explain about the CNCF community, governance, cloud roles, and Kubernetes certification path.

Chapter 3, Getting Started with Containers, provides a closer look at containers, diving deeper into container technology and container ecosystem, and discovering commonly used Docker tooling. This chapter includes practical assignments.

Chapter 4, Exploring Container Runtimes, Interfaces, and Service Meshes, takes you further to explore container runtimes, networking, and interfaces, and learn about service meshes. You will learn how containers can communicate with each other over the network, which container interfaces exist in Kubernetes, and get to know what a service mesh is and its applications.

Chapter 5, Orchestrating Containers with Kubernetes, starts the coverage of the most important and perhaps the hardest part of KCNA certification – Kubernetes Fundamentals. You will learn about the features and the basics of Kubernetes architecture, its API, components, and the smallest deployable unit, called a Pod. The practical part includes the local installation of Kubernetes with the help of minikube.

Chapter 6, Deploying and Scaling Applications with Kubernetes, takes you further to explore the Kubernetes functionality and rich ecosystem. The chapter provides an overview of other Kubernetes resources and their purpose; it discusses how to implement self-healing and scaling of applications with Kubernetes, how to use Kubernetes service discovery, and how to run stateful workloads with Kubernetes. More practical Kubernetes exercises are an essential part of the chapter.

Chapter 7, Application Placement and Debugging with Kubernetes, demonstrates how to control the placement of workloads on Kubernetes, how its scheduler works, and how applications running on K8s can be debugged. The chapter covers aspects from the Kubernetes Fundamentals as well as Cloud Native Observability domains of the KCNA exam at the same time.

Chapter 8, Following Kubernetes Best Practices, talks about Kubernetes networking and network policies for traffic control, restricting access with Role-Based Access Control (RBAC), using Helm as a K8s package manager, and more. The final chapter of the Kubernetes part includes a few more hands-on exercises.

Chapter 9, Understanding Cloud Native Architectures, explores aspects of cloud native in more detail. The chapter shares core concepts that are a part of Cloud Native and Cloud Native architectures. This chapter covers further requirements of the Cloud Native Architecture domain of the KCNA exam.

Chapter 10, Implementing Telemetry and Observability in the Cloud, emphasizes the need to monitor and optimize Cloud Native applications based on observations for best performance with cost in mind. The chapter covers further requirements from the Cloud Native Observability domain of KCNA.

Chapter 11, Automating Cloud Native Application Delivery, talks about the Cloud Native application life cycle. You will learn about best practices for the development and delivery of Cloud Native apps and see how automation helps to develop better and ship faster.

Chapter 12, Practicing for the KCNA Exam with Mock Papers, shares a few tips on passing the exam and includes two mock exams to test the knowledge during final preparations.

Chapter 13, The Road Ahead, concludes the book with tips on how to advance and what to do next for a successful Cloud Native career.

To get the most out of this book

You’ll install a number of tools; therefore, a system with administrative privileges will be needed.

Software/hardware covered in the book

Operating system requirements

Kubernetes

Windows, macOS, or Linux (macOS or Linux are recommended)

minikube

Docker

Prometheus

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

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Becoming-KCNA-Certified. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog 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 and diagrams used in this book. You can download it here: https://packt.link/OnZI3.

Conventions used

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

Code in text: Indicates code words in text, table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and so on. Here is an example: “Let’s delete the old nginx-deployment that we created at the beginning of this chapter.”

A block of code is set as follows:

apiVersion: v1 kind: PersistentVolumeClaim metadata:   name: kcna-pv-claim spec:   storageClassName: standard   accessModes:     - ReadWriteOnce   resources:     requests:       storage: 3Gi

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

Normal   Scheduled  85s                default-scheduler   Successfully assigned kcna/liveness-exec to minikube   Normal   Pulled     81s                kubelet            Successfully pulled image "k8s.gcr.io/busybox" in 3.4078911s   Warning  Unhealthy  41s (x3 over 51s)  kubelet            Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory  Normal   Killing    41s                kubelet            Container liveness failed liveness probe, will be restarted   Normal   Pulling    11s (x2 over 85s)  kubelet            Pulling image "k8s.gcr.io/busybox"

Bold: Indicates a term, an important word, or words. For instance, major points can appear in bold.

Tips or important notes

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, email us at [email protected] and mention the book title in the subject of your message.

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 and fill in the form.

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.

Share Your Thoughts

Once you’ve read Becoming KCNA Certified, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

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/9781804613399

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

Part 1: The Cloud Era

In this part, you’ll get a quick overview of how computing has evolved since the inception of the cloud, how traditional IT operated before, and what today’s cloud native landscape looks like. We’ll discuss the Cloud Native Computing Foundation, the Linux Foundation, and look at their projects and certifications.

This part contains the following chapters:

Chapter 1, From Cloud to Cloud Native and KubernetesChapter 2, Overview of CNCF and Kubernetes Certifications

1

From Cloud to Cloud Native and Kubernetes

In this chapter, you’ll see how computing has evolved over the past 20 or so years, what the cloud is and how it appeared, and how IT landscapes have changed with the introduction of containers. You’ll learn about fundamentals such as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), and Function-as-a-Service (FaaS), as well as learning about the transition from monolithic to microservice architectures and getting a first glimpse at Kubernetes.

This chapter does not map directly to a specific KCNA exam objective, but these topics are crucial for anyone who’d like to tie their career to modern infrastructures. If you are already familiar with the basic terms, feel free to quickly verify your knowledge by going directly to the recap questions. If not, don’t be surprised that things are not covered in great detail, as this is an introductory chapter, and we’ll dive deeper into all of the topics in later chapters.

We’re going to cover the following topics in this chapter:  

The cloud and Before Cloud (B.C.) Evolution of the cloud and cloud-nativeContainers and container orchestrationMonolithic versus microservices applicationsKubernetes and its origins

Let’s get started!

The cloud and Before Cloud (B.C.)

The cloud has triggered a major revolution and accelerated innovation, but before we learn about the cloud, let’s see how things were done before the era of the cloud.

In the times before the term cloud computing was used, one physical server would only be able to run a single operating system (OS) at a time. These systems would typically host a single application, meaning two things:

If an application was not used, the computing resources of the server where it ran were wastedIf an application was used very actively and needed a larger server or more servers, it would take days or even weeks to get new hardware procured, delivered, cabled, and installed

Moving on, let’s have a look at an important aspect of computing – virtualization.

Virtualization

Virtualization technology and virtual machines (VMs) first appeared back in the 1960s, but it was not until the early 2000s that virtualization technologies such as XEN and Kernel-based Virtual Machines (KVMs) started to become mainstream.

Virtualization would allow us to run multiple VMs on a single physical server using hypervisors, where a hypervisor is a software that acts as an emulator of the hardware resources, such as the CPU and RAM. Effectively, it allows you to share the processor time and memory of the underlying physical server by slicing it between multiple VMs.

It means that each VM will be very similar to the physical server, but with a virtual CPU, memory, disks, and network cards instead of physical ones. Each VM will also have an OS on which you can install applications. The following figure demonstrates a virtualized deployment with two VMs running on the same physical server:

Figure 1.1 – Comparison of traditional and virtualized deployments

This concept of sharing hardware resources between the so-called guest VMs is what made it possible to utilize hardware more effectively and reduce any waste of computing resources. It means we might not need to purchase a whole new server in order to run another application.

The obvious benefits that came along with virtualization are as follows:

Less physical hardware requiredFewer data center personnel requiredLower acquisition and maintenance costsLower power consumption

Besides, provisioning a new VM would take minutes and not days or weeks of waiting for new hardware. However, to scale beyond the capacities of the hardware already installed in the corporate data center, we would still need to order, configure, and cable new physical servers and network equipment – and that has all changed with the introduction of cloud computing.

The cloud

At a very basic level, the cloud is virtualization on demand. It allows us to spawn VMs accessible over the network as a service, when requested by the customers.

Cloud computing

This is the delivery of computational resources as a service, where the actual hardware is owned and managed by the cloud provider rather than a corporate IT department.

The cloud has ignited a major revolution in computing. It became unnecessary to buy and manage your own hardware anymore to build and run applications and VMs. The cloud provider takes full care of hardware procurement, installation, and maintenance and ensures the efficient utilization of resources by serving hundreds and thousands of customers on shared hardware securely. Each customer will only pay for the resources they use. Today, it is common to distinguish the following three cloud types:

Public – The most popular type. A public cloud is operated by a third-party company and available for use by any paying customer. Public clouds are typically used by thousands of organizations at the same time. Examples of public cloud providers include Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).Private – Used by one typically large organization or an enterprise. The operations and maintenance might be done by the organization itself or a private cloud provider. Examples include Rackspace Private Cloud and VMware Private Cloud.Hybrid – This is the combination of a public and private cloud, in a case where an organization has a private cloud but uses some of the services from a public cloud at the same time.

However, the cloud is not just VMs reachable over the network. There are tens and hundreds of services offered by cloud providers. Today, you can request and use network-attached storage, virtual network devices, firewalls, load balancers, VMs with GPUs or specialized hardware, managed databases, and more almost immediately.

Now, let’s see in more detail how cloud services can be delivered and consumed.

Evolution of the cloud and cloud-native

Besides the huge variety of cloud services you can find today, there is also a difference in how the services are offered. It is common to distinguish between four cloud service delivery models that help meet different needs:

IaaS – The most flexible model with the basic services provided: VMs, virtual routers, block devices, load balancers, and so on. This model also assumes the most customer responsibility. Users of IaaS have access to their VMs and must configure their OS, install updates, and set up, manage, and secure their applications. AWS Elastic Compute Cloud (EC2), AWS Elastic Block Store (EBS), and Google Compute Engine VMs are all examples of IaaS.PaaS – This helps to focus on the development and management of applications by taking away the need to install OS upgrades or do any lower-level maintenance. As a PaaS customer, you are still responsible for your data, identity and access, and your application life cycle. Examples include Heroku and Google App Engine.SaaS – Takes the responsibilities even further away from the customers. Typically, these are fully managed applications that just work, such as Slack or Gmail.FaaS – A newer delivery model that appeared around 2010. It is also known as Serverless today. A FaaS customer is responsible for defining the functions that are triggered by the events. Functions can be written in one of the popular programming languages and customers don’t have to worry about server or OS management, deployment, or scaling. Examples of FaaS include AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions.

These models might sound a bit complicated, so let’s draw a simple analogy with cars and transportation.

On-premises, traditional data centers are like having your own car. You are buying it, and you are responsible for its insurance and maintenance, the replacement of broken parts, passing regular inspections, and so on.

IaaS is more like leasing a car for some period of time. You pay monthly lease payments, you drive it, you fill it with gas, and you wash it, but you don’t actually own the car and you can give it back when you don’t need it anymore.

PaaS can be compared with car-sharing. You don’t own the car, you don’t need to wash it, do any maintenance, or even refill it most of the time, but you still drive it yourself.

Following the analogy, SaaS is like calling a taxi. You don’t need to own the car or even drive it.

Finally, Serverless or FaaS can be compared to a bus from a user perspective. You just hop on and ride to your destination – no maintenance, no driving, and no ownership.

Hopefully, this makes things clearer. The big difference between traditional on-premises setups where a company is solely responsible for the organization, hardware maintenance, data security, and more is that a so-called shared responsibility model applies in the cloud.

Shared responsibility model

Defines the obligations of the cloud provider and the cloud customer. These responsibilities depend on the service provided – in the case of an IaaS service, the customer has more responsibility compared to PaaS or SaaS. For example, the cloud provider is always responsible for preventing unauthorized access to data center facilities and the stability of the power supply and underlying network connectivity.

The following figure visually demonstrates the difference between the responsibilities:

Figure 1.2 – Comparison of cloud delivery models

As cloud technologies and providers evolved over the past 20 years, so did the architectures of the applications that run on the cloud; a new term has emerged – cloud-native. Most of the time, it refers to the architectural approach, but you will often encounter cloud-native applications or cloud-native software as well.

Cloud-native

Is an approach to building and running applications on modern, dynamic infrastructures such as clouds. It is emphasizing application workloads with high resiliency, scalability, high degree of automation, ease of management, and observability.

Despite the presence of the word cloud, it does not mean that a cloud-native application must run strictly in a public, private, or hybrid cloud. You can develop a cloud-native application and run it on-premises with Kubernetes as an example.

Cloud-native should not be confused with Cloud Service Providers (CSPs), or simply cloud providers, and cloud-native is also not the same as cloud-first, so remember the following:

Cloud-native ≠ CSP ≠ cloud-first

For the sake of completeness, let’s define the other two.

A CSP is a third-party company offering cloud computing services such as IaaS, PaaS, SaaS, or FaaS. Cloud-first simply stands for a strategy where the cloud is the default choice for either optimizing existing IT infrastructure or for launching new applications.

Don’t worry if those definitions do not make total sense just yet – we will dedicate a whole section to cloud-native that explains all its aspects in detail. For now, let’s have a quick introduction to containers and their orchestration.

Containers and container orchestration

At a very high level, containers are another form of lightweight virtualization, also known as OS-level virtualization. However, containers are different from VMs with their own advantages and disadvantages.

The major difference is that with VMs, we can slice and share one physical server between many VMs, each running their own OS. With containers, we can slice and share an OS kernel between multiple containers and each container will have its own virtual OS. Let’s see this in more detail.

Containers

These are portable units of software that include application code with runtimes, dependencies, and system libraries. Containers share one OS kernel, but each container can have its own isolated OS environment with different packages, system libraries, tools, its own storage, networking, users, processes, and groups.

Portable is important and needs to be elaborated. An application packaged into a container image is guaranteed to run on another host because the container includes its own isolated environment. Starting a container on another host does not interfere with its environment or the application containerized.

A major advantage is also that containers are a lot more lightweight and efficient compared to VMs. They consume less resources (the CPU and RAM) than VMs and start almost instantly because they don’t need to bootstrap a complete OS with a kernel. For example, if a physical server is capable of running 10 VMs, then the same physical server might be able to run 30, 40, or possibly even more containers, each with its own application (the exact number depends on many factors, including the type of workload, so those values are for demonstration purposes only and do not represent any formula).

Containers are also much smaller than VMs in disk size, because they don’t package a full OS with thousands of libraries. Only applications with dependencies and a minimal set of OS packages are included in container images. That makes container images small, portable, and easy to download or share.

Container images

These are essentially templates of container OS environments that we can use to create multiple containers with the same application and environment. Every time we execute an image, a container is created.

Speaking in numbers, a container image of a popular Linux distribution such as Ubuntu Server 20.04 weighs about 70 MB, whereas a KVM QCOW2 virtual machine image of the same Ubuntu Server will weigh roughly 500 MB. Specialized Linux container images such as Alpine can be as small as 5 to 10 MB and provide the bare minimum functionality to install and run applications.

Containers are also agnostic to where they run – whether on physical servers, on-premises VMs, or the cloud, containers can run in any of these locations with the help of container runtimes.

Container runtimes

A container runtime is a special software needed to run containers on a host OS. It is responsible for creating, starting, stopping, and deleting containers based on the container images it downloads. Examples of container runtimes include containerd, CRI-O, and Docker Engine.

Figure 1.3 demonstrates the differences between virtualized and containerized deployments:

Figure 1.3 – Comparison of virtualized and container deployments

Now, a question you might be asking yourself is if containers are so great, why would anyone use VMs and why do cloud providers still offer so many VM types?

Here is the scenario where VMs have an advantage over containers: they provide better security due to stronger isolation because they don’t directly share the same host kernel. That means if an application running in a container has been breached by a hacker, the chances that they can get to all the other containers on the same host are much higher than compared to regular VMs.

We will dive deeper into the technology behind OS-level virtualization and explore the low-level differences between VMs and containers in later chapters.

As containers gained momentum and received wider adoption over the years, it quickly became apparent that managing containers on a large scale can be quite a challenge. The industry needed tools to orchestrate and manage the life cycle of container-based applications.

This had to do with the increasing number of containers that companies and teams had to operate because as the infrastructure tools evolved, so did the application architectures too, transforming from large monolithic architectures into small, distributed, and loosely coupled microservices.

Monolithic versus microservices applications

To understand the difference between monolithic and microservice-based applications, let us reflect on a real-world example. Imagine that a company runs an online hotel booking business. All reservations are made and paid for by the customers via a corporate web service.

The traditional monolithic architecture for this kind of web application would have bundled all the functionality into one single, complex software that might have included the following:

Customer dashboardCustomer identity and access managementSearch engine for hotels based on criteriaBilling and integration with payment providersReservation system for hotelsTicketing and support chat

A monolithic application will be tightly coupled (bundled) with all the business and user logic and must be developed and updated at once. That means if a change to a billing code has to be made, the entire application will have to be updated with the changes. After that, it should be carefully tested and released to the production environment. Each (even a small) change could potentially break the whole application and impact business by making it unavailable for a longer time.

With a microservices architecture, this very same application could be split into several smaller pieces communicating with each other over the network and fulfilling its own purpose. Billing, for example, can be performed by four smaller services:

Currency converterCredit card provider integrationBank wire transfer processingRefund processing

Essentially, microservices are a group of small applications where each is responsible for its own small task. These small applications communicate with each other over the network and work together as a part of a larger application.

The following figure demonstrates the differences between monolithic and microservice architectures:

Figure 1.4 – Comparison of monolithic and microservice architectures

This way, all other parts of the web application can also be split into multiple smaller independent applications (microservices) communicating over the network. The advantages of this approach include the following:

Each microservice can be developed by its own teamEach microservice can be released and updated separatelyEach microservice can be deployed and scaled independently of othersA single microservice outage will only impact a small part of the overall functionality of the app

Microservices are an important part of cloud-native architectures, and we will review in detail the benefits as well as the challenges associated with microservices in Chapter 9, Understanding Cloud Native Architectures. For the moment, let’s get back to containers and why they need to be orchestrated.

When each microservice is packaged into a container, the total number of containers can easily reach tens or even hundreds for especially large and complex applications. In such a complex distributed environment, things can quickly get out of our control.

A container orchestration system is what helps us to keep control over a large number of containers. It simplifies the management of containers by grouping application containers into deployments and automating operations such as the following:

Scaling microservices depending on the workloadReleasing new versions of microservices and their updatesScheduling containers based on host utilizations and requirementsAutomatically restarting containers that fail or failing over the traffic

As of today, there are many container and workload orchestration systems available, including these:

KubernetesOpenShift (also known as Open Kubernetes Distribution (OKD))Hashicorp NomadDocker SwarmApache Mesos

As you already know from the book title, we will only focus on Kubernetes and there won’t be any sort of comparison made between these five. In fact, Kubernetes has overwhelmingly higher market shares and over the years, has become the de facto platform for orchestrating containers. With a high degree of confidence, you can concentrate on learning about Kubernetes and forget about the others, at least for the moment.

Kubernetes and its origins

Let’s start with a brief history first. The name Kubernetes originates from Greek and means pilot or helmsman – a person steering a ship (that is why there is a steering wheel in the logo). The steering wheel has seven bars and the number seven has a special meaning for Kubernetes. The team originally working on Kubernetes called it Project Seven – named after seven of nine characters from the well-known TV series,Star Trek.

Figure 1.5 – The Kubernetes logo

Kubernetes was initially developed by Google and released as an open source project in 2014. Google has been a pioneer, having run its services in containers already for more than a decade by that time, and the release of Kubernetes triggered another small revolution in the industry. By that time, many businesses had realized the benefits of using containers and were in need of a solution that would simplify container orchestration at scale. Kubernetes turned out to be this solution, as we will see soon.

Kubernetes (K8s)

Kubernetes is an open source platform for container orchestration. Kubernetes features an extensible and declarative API that allows you to automatically reach the desired state of resources. It allows flexible scheduling, autoscaling, rolling update, and self-healing of container-based payloads.

(Online and in documentation, a shorter abbreviation, K8s, can often be encountered – where eight is the number of letters between “K” and “s”.)

Kubernetes has inherited many of its features and best ideas from Borg – an internal container cluster management system powering thousands of different applications at Google. Many Borg engineers participated in the development of Kubernetes and were able to address relevant pain points based on their experience of operating a huge fleet of containers over the years.

Soon after its initial release, Kubernetes rapidly gained the attention of the open source community and attracted many talented contributors from all over the world. Today, Kubernetes is among the top three biggest open source projects on GitHub (https://github.com/kubernetes) with more than 80,000 stars and 3,000 contributors. It was also the first project to graduate from the Cloud Native Computing Foundation (CNCF), a non-profit organization that split off from the Linux Foundation created with the goal of advancing container and cloud-native technologies.

One of the most important features of Kubernetes is the concept of the desired state. Kubernetes operates in a way where we define the state of the application containers we want to have, and Kubernetes will automatically ensure the state is reached. Kubernetes constantly observes the state of all deployed containers and makes sure this state matches what we’ve requested.

Let’s consider the following example. Imagine that we run a simple microservice-based application on Kubernetes cluster with three hosts. We define a specification that requires Kubernetes to run these:

Two identical containers for the frontendThree identical containers for the backendTwo containers with volumes serving the data persistence

Unexpectedly, one of the three hosts fails, and two containers running on the frontend and backend become unavailable. Kubernetes observes the changed number of hosts in the cluster and reduced number of containers responsible for the frontend and the backend. Kubernetes automatically starts one frontend and one backend container on the other two operational hosts to bring the system back to its desired state. This process is knownas self-healing.

Kubernetes can do way more than scheduling and restarting failed containers – we can also define a Kubernetes specification that requires the number of microservice containers to automatically increase based on the current demand. For example, in the preceding example, we can specify that with an increased workload, we want to run five replicas of the frontend and five replicas of the backend. Alternatively, in case of low application demand, we can automatically decrease the number of each microservice containers to two. This process is known as autoscaling.

This example demonstrates the basic capabilities of Kubernetes. In Part 3, we will explore more Kubernetes features and try some of them firsthand.

Important note

While being a container orchestrator, Kubernetes does not have its own container runtime. Instead, it has integration with popular container runtimes such as containerd and can work with multiple runtimes within a Kubernetes cluster.

You often see references to Kubernetes clusters because a typical Kubernetes installation will be used to manage hundreds of containers spread across multiple hosts. Single-host Kubernetes installations are only suitable for learning or local development, but not for production usage.

To sum up, Kubernetes has laid down the path for massive container adoption and is a thriving open source ecosystem that is still growing with new projects graduating from the CNCF every year. In this book, we will cover the Kubernetes API, components, resources, features, and operational aspects in depth, and learn more about projects that can be used with Kubernetes to extend its functionality.

Summary

In this chapter, we learned about the concepts of the cloud and containers, and the evolution of computing over the last 20 to 30 years. In the era before the cloud, traditional deployments with one or a few applications per physical server caused a lot of inefficiency and wasted resources with underutilized hardware and high costs of ownership.

When virtualization technologies came along, it became possible to run many applications per physical server using VMs. This addressed the pitfalls of traditional deployments and allowed us to deliver new applications more quickly and with significantly lower costs.

Virtualization paved the way for the cloud services that are delivered via four different models today: IaaS, PaaS, SaaS, and FaaS or Serverless. Customer responsibilities differ by cloud service and delivery model.

This progress never stopped – now, cloud-native as an approach to building and running applications has emerged. Cloud-native applications are designed and built with an emphasis on scalability, resilience, ease of management, and a high degree of automation.

Over recent years, container technology has developed and gained momentum. Containers use virtualization at the OS level and each container represents a virtual OS environment. Containers are faster, more efficient, and more portable compared to VMs.

Containers enabled us to develop and manage modern applications based on a microservices architecture. Microservices were a step ahead compared to traditional monoliths – all-in-one, behemoth applications.

While containers are one of the most efficient ways to run cloud-native applications, it becomes hard to manage large numbers of containers. Therefore, containers are best managed using an orchestrator such as Kubernetes.

Kubernetes is an open source container orchestration system that originated from Google and automates many operational aspects of containers. Kubernetes will schedule, start, stop, and restart containers and increase or decrease the number of containers based on the provided specification automatically. Kubernetes makes it possible to implement self-healing and autoscaling based on the current demand.

Questions

At the end of each chapter, you’ll find recap questions that allow to test your understanding. Questions might have multiple correct answers. Correct answers can be found in the Assessment section of the Appendix:

Which of the following describes traditional deployments on physical servers (pick two)?Easy maintenanceUnderutilized hardwareLow energy consumptionHigh upfront costsWhich advantages do VMs have compared to containers?They are more reliableThey are more portableThey are more secureThey are more lightweightWhat describes the difference between VMs and containers (pick two)?VM images are small and container images are largeVM images are large and container images are smallVMs share the OS kernel and containers don’tContainers share the OS kernel and