27,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Docker containers promise to radicalize the way developers and operations build, deploy, and manage applications running on the cloud. Kubernetes provides the orchestration tools you need to realize that promise in production.
Kubernetes on AWS guides you in deploying a production-ready Kubernetes cluster on the AWS platform. You will then discover how to utilize the power of Kubernetes, which is one of the fastest growing platforms for production-based container orchestration, to manage and update your applications. Kubernetes is becoming the go-to choice for production-grade deployments of cloud-native applications. This book covers Kubernetes from first principles. You will start by learning about Kubernetes' powerful abstractions - Pods and Services - that make managing container deployments easy. This will be followed by a guided tour through setting up a production-ready Kubernetes cluster on AWS, while learning the techniques you need to successfully deploy and manage your own applications.
By the end of the book, you will have gained plenty of hands-on experience with Kubernetes on Amazon Web Services. You will also have picked up some tips on deploying and managing applications, keeping your cluster and applications secure, and ensuring that your whole system is reliable and resilient to failure.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 336
Veröffentlichungsjahr: 2018
Ähnliche
Kubernetes on AWS
Copyright © 2018 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.
Commissioning Editor: Gebin GeorgeAcquisition Editor:Rahul NairContent Development Editor:Abhishek JadhavTechnical Editor:Aditya KhadyeCopy Editor:Safis EditingProject Coordinator: Jagdish PrabhuProofreader: Safis EditingIndexer:Pratik ShirodkarGraphics:Tom ScariaProduction Coordinator: Aparna Bhagat
First published: November 2018
Production reference: 1291118
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78839-007-1
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
Packt.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Ed Robinson works as a senior site reliability engineer at Cookpad's global headquarters in Bristol, UK. He has been working with Kubernetes for the last three years, deploying clusters on AWS to deliver resilient and reliable services for global audiences. He is a contributor to several open source projects and is a maintainer of Træfɪk, the modern HTTP reverse proxy designed for containers and microservices.
About the reviewer
Manuel Tiago Pereira is a software engineer with vast experience of automating infrastructure provisioning and configuration for systems from development environments to highly available platforms for web applications. For the last couple of years, he has been invested in providing solid platforms for application deployments using Kubernetes. He has dedicated most of his professional career to SaaS companies and he's currently working at Talkdesk in order to make life easier for call-center operators and increase their customers' happiness.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Kubernetes on AWS
Dedication
About Packt
Why subscribe?
Packt.com
Contributors
About the author
About the reviewer
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Conventions used
Get in touch
Reviews
Google's Infrastructure for the Rest of Us
Why do I need a Kubernetes cluster?
The roots of containers
Enter the container
Cgroups
Namespaces
Putting the pieces together
Here, schedule this...
The basics of Kubernetes
The pod
Labeling all the things
Replica sets
Services
Under the hood
API server
Controller manager
Scheduler
Kubelet
Summary
Start Your Engines
Your own Kubernetes
Installation
macOS
Linux
Windows
Starting Minikube
First steps with kubectl
Building Docker containers inside the cluster
Building and launching a simple application on Minikube
What just happened?
Rolling out changes
Resilience and scaling
Using the dashboard
Configuration as code
Troubleshooting Minikube
Summary
Reach for the Cloud
Cluster architecture
Creating an AWS account
Creating an IAM user
Getting the CLI
Setting up a key pair
Preparing the network
Setting up a bastion
sshuttle
Instance profiles
Kubernetes software
Docker
Installing Kubeadm
Building an AMI
Bootstrapping the cluster
What just happened?
Access the API from your workstation
Setting up pod networking
Launching worker nodes
Demo time
Summary
Managing Change in Your Applications
Running pods directly
Jobs
CronJob
Cron syntax
Concurrency policy
History limits
Managing long running processes with deployments
kubectl patch
kubectl edit
kubectl apply
Kubernetes dashboard
Greater control of your deployments
RollingUpdate deployment
Recreate deployment
DaemonSet
Summary
Managing Complex Applications with Helm
Installing Helm
macOS
Linux and Windows
Installing Tiller
Installing a chart
Configuring a chart
Creating your own charts
Chart.yaml
values.yaml
templates
Making it your own
Developing and debugging
Templating language
Functions
Flow control
Hooks
Packaging Helm charts
You can test building an index
Using your repository
Organizational patterns for Helm
Chart per application
Shared charts
Library charts
Next steps
Planning for Production
The design process
Initial planning
Planning for success
Planning for a successful roll out
Discovering requirements
Availability
Capacity
EC2 instance types
EC2 instance types
Breadth versus depth
Performance
Disk performance
gp2
io2
st1
sc1
Networking
Security
Always be updating
In-place updates
Immutable images
Network security
Infra-node networking
Node-master networking
External networking
Kubernetes infra-pod networking
IAM roles
Validation
Observability
Logging
Monitoring
Blackbox monitoring
Alerting
Tracing
Summary
A Production-Ready Cluster
Building a cluster
Getting started with Terraform
Variables
Networking
Plan and apply
Control Plane
Preparing node images
Installing Packer
Packer configuration
Node group
Provisioning add-ons
Managing change
Summary
Sorry My App Ate the Cluster
Resource requests and limits
Resource units
How pods with resource limits are managed
Quality of Service (QoS)
Resource quotas
Default limits
Horizontal Pod Autoscaling
Deploying the metrics server
Verifying the metrics server and troubleshooting
Autoscaling pods based on CPU usage
Autoscaling pods based on other metrics
Autoscaling the cluster
Deploying the cluster autoscaler
Summary
Storing State
Volumes
EBS volumes
Persistent volumes
Persistent volumes example
Storage classes
StatefulSet
Summary
Further reading
Managing Container Images
Pushing Docker images to ECR
Creating a repository
Pushing and pulling images from your workstation
Setting up privileges for pushing images
Use images stored on ECR in Kubernetes
Tagging images
Version Control System (VCS) references
Semantic versions
Upstream version numbers
Labelling images
Summary
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
Docker containers promise to radically change the way developers and operations build, deploy, and manage applications running on the cloud. Kubernetes provides the orchestration tools you need to realize that promise in production.
Kubernetes on AWS guides you in deploying a production-ready Kubernetes cluster on the Amazon Web Services (AWS) platform. You will discover how to use the power of Kubernetes, which is one of the fastest growing platforms for production-based container orchestration, to manage and update your applications. Kubernetes is becoming the go-to choice for production-grade deployments of cloud-native applications. This book covers Kubernetes from first principles. You will start by learning about Kubernetes' powerful abstractions—pods and services—which make managing container deployments easy. This will be followed by a guided tour through setting up a production-ready Kubernetes cluster on AWS, while learning the techniques you need to successfully deploy and manage your own applications.
By the end of the book, you will have gained plenty of hands-on experience with Kubernetes on AWS. You will also have picked up some tips on deploying and managing applications, keeping your cluster and applications secure, and ensuring that your whole system is reliable and resilient to failure.
Who this book is for
If you're a cloud engineer, cloud solution provider, sysadmin, site reliability engineer, or developer with an interest in DevOps and are looking for an extensive guide to running Kubernetes in the AWS environment, this book is for you. Though any previous knowledge of Kubernetes is not expected, some experience with Linux and Docker containers would be a bonus.
What this book covers
Chapter 1, Google's Infrastructure for the Rest of Us, helps you understand how Kubernetes can give you some of the same superpowers that the site reliability engineers at Google use to ensure that Google's services are resilient, reliable, and efficient.
Chapter 2, Start Your Engines, helps you take your first steps with Kubernetes. You will learn how to start a cluster suitable for learning and development use on your own workstation, and will begin to learn how to use Kubernetes itself.
Chapter 3, Reach for the Cloud, teaches you how to build a Kubernetes cluster running on AWS from first principles.
Chapter 4, Managing Change in Your Applications, gets into depth with tools that Kubernetes provide to manage the Pods that you run on your cluster.
Chapter 5, Managing Complex Applications with Helm, teaches you about how you can deploy a service to your cluster using a community-maintained chart.
Chapter 6, Planning for Production, gives you an idea of the myriad different options and decisions you can make when deciding to run Kubernetes in a production environment.
Chapter 7, A Production-Ready Cluster, helps you build a fully functional cluster that will serve as a base configuration to build upon for many different use cases.
Chapter 8, Sorry My App Ate the Cluster, delves into configuring pods with a different quality of service so important workloads are guaranteed the resources they need, but less important workloads can make use of idle resources when they are available without needing dedicated resources.
Chapter 9, Storing State, is all about using the deep integration that Kubernetes has with the AWS native storage solution Elastic Block Store (EBS).
Chapter 10,Managing Container Images, helps you understand how to leverage the AWS Elastic Container Registry (ECR) service to store your container images in a manner that tackles all these needs.
Chapter 11, Monitoring and Logging, teaches you how to set up a log management pipeline, and will help you understand some of the pitfalls and potential issues with logs. By the end of the chapter, you will have set up a metrics and alerting system. For this chapter refer to https://www.packtpub.com/sites/default/files/downloads/Monitoring_and_Logging.pdf.
Chapter 12, Best Practices of Security, teaches you how to manage a secure network for your Kubernetes cluster using both AWS and Kubernetes networking primitives. You will also learn how to keep your host operating systems secured. For this chapter refer to https://www.packtpub.com/sites/default/files/downloads/Best_Practices_of_Security.pdf.
To get the most out of this book
You will need access to an AWS account for performing the examples given in this book.
Download the example code files
You can download the example code files for this book from your account at www.packt.com. If you purchased this book elsewhere, you can visit www.packt.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packt.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub athttps://github.com/PacktPublishing/Kubernetes-on-AWS. 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 catalog of books and videos available athttps://github.com/PacktPublishing/. Check them out!
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system."
A block of code is set as follows:
html, body, #map { height: 100%; margin: 0; padding: 0}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
[default]exten => s,1,Dial(Zap/1|30)exten => s,2,Voicemail(u100)
exten => s,102,Voicemail(b100)
exten => i,1,Voicemail(s0)
Any command-line input or output is written as follows:
$ mkdir css
$ cd css
Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select System info from the Administration panel."
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packt.com/submit-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.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packt.com.
Google's Infrastructure for the Rest of Us
Kubernetes was originally built by some of the engineers at Google who were responsible for their internal container scheduler, Borg.
Learning how to run your own infrastructure with Kubernetes can give you some of the same superpowers that the site reliability engineers at Google utilize to ensure that Google's services are resilient, reliable, and efficient. Using Kubernetes allows you to make use of the knowledge and expertise that engineers at Google and other companies have built up by virtue of their massive scale.
Your organization may never need to operate at the scale of a company such as Google. You will, however, discover that many of the tools and techniques developed in companies that operate on clusters of tens of thousands of machines are applicable to organizations running much smaller deployments.
While it is clearly possible for a small team to manually configure and operate tens of machines, the automation needed at larger scales can make your life simpler and your software more reliable. And if you later need to scale up from tens of machines to hundreds or even thousands, you'll know that the tools you are using have already been battle tested in the harshest of environments.
The fact that Kubernetes even exists at all is both a measure of the success and a vindication of the open source/free software movement. Kubernetes began as a project to open source an implementation of the ideas and research behind Google's internal container orchestration system, Borg. Now it has taken on a life of its own, with the majority of its code now being contributed by engineers outside of Google.
The story of Kubernetes is not only one of Google seeing the benefits that open sourcing its own knowledge would indirectly bring to its own cloud business, but it's also one of the open source implementations of the various underlying tools that were needed coming of age.
Linux containers had existed in some form or another for almost a decade, but it took the Docker project (first open sourced in 2013) for them to become widely used and understood by a large enough number of users. While Docker did not itself bring any single new underlying technology to the table, its innovation was in packaging the tools that already existed in a simple and easy-to-use interface.
Kubernetes was also made possible by the existence of etcd, a key-value store based on the Raft consensus algorithm that was also first released in 2013 to form the underpinnings of another cluster scheduling tool that was being built by CoreOS. For Borg, Google had used an underlying state store based on the very similar Paxos algorithm, making etcd the perfect fit for Kubernetes.
Google were prepared to take the initiative to create an open source implementation of the knowledge which, up until that point, had been a big competitive advantage for their engineering organization at a time when Linux containers were beginning to become more popular thanks to the influence of Docker.
Why do I need a Kubernetes cluster?
At its core, Kubernetes is a container scheduler, but it is a much richer and fully featured toolkit that has many other features. It is possible to extend and augment the functionality that Kubernetes provides, as products such as RedHat's OpenShift have done. Kubernetes also allows you to extend it's core functionality yourself by deploying add-on tools and services to your cluster.
Here are some of the key features that are built into Kubernetes:
Self-healing
: Kubernetes controller-based orchestration ensures that containers are restarted when they fail, and rescheduled when the nodes they are running on fail. User-defined health checks allow users to make decisions about how and when to recover from failing services, and how to direct traffic when they do.
Service discovery
: Kubernetes is designed from the ground up to make service discovery simple without needing to make modifications to your applications. Each instance of your application gets its own IP address, and standard discovery mechanisms such as DNS and load balancing let your services communicate.
Scaling
: Kubernetes makes horizontal scaling possible at the push of a button, and also provides autoscaling facilities.
Deployment orchestration
: Kubernetes not only helps you to manage running applications, but has tools to roll out changes to your application and its configuration. Its flexibility allows you to build complex deployment patterns for yourself or to use one of a number of add-on tools.
Storage management
: Kubernetes has built-in support for managing the underlying storage technology on cloud providers, such as AWS Elastic Block Store volumes, as well as other standard networked storage tools, such as NFS.
Cluster optimization
: The Kubernetes scheduler automatically assigns your workloads to machines based on their requirements, allowing for better utilization of resources.
Batch workloads
: As well as long-running workloads, Kubernetes can also manage batch jobs, such as CI, batch processing, and cron jobs.
The roots of containers
Ask the average user what a Docker container is and you might get any one of a dozen responses. You might be told something about lightweight virtual machines, or how it is that this hot new disruptive technology is going to revolutionize computing. In reality, Linux containers are certainly not a new idea, nor are they really all that much like a virtual machine.
Back in 1979, the chroot syscall was added to Version 7 of Unix. Calling chroot changes the apparent root directory for the current running process and its subprocesses. Running a program in a so-called chroot jail prevents it from accessing files outside of the specified directory tree.
One of the first uses of chroot was for testing of the BSD build system, something that is inherited by the package build systems of most of our modern Linux distributions, such as Debian, RedHat, and SuSE. By testing packages in a clean chrooted environment, build scripts can detect missing dependency information.
Chroot is also commonly used to sandbox untrusted processes-for example, shell processes on shared FTP or SFTP servers. Systems designed specifically with security in mind, such as the Postfix mail transfer agent, utilize chroot to isolate individual components of a pipeline in order to prevent a security issue in one component from rippling across the system.
Chroot is in fact a very simple isolation tool that was never intended to provide either security or control over anything other than the filesystem access of the processes. For its intended purpose of providing filesystem isolation for the likes of build tools, it is perfect. But for isolating applications in a production environment, we need a little more control.
Enter the container
Trying to understand what a Linux container is can be a little difficult. As far as the Linux kernel is concerned, there is no such thing as a container. The kernel has a number of features that allow a process to be isolated, but these features are much lower-level and granular than what we now think of as a container. Container engines such as Docker use two main kernel features to isolate processes:
Cgroups
Cgroups, or control groups, provide an interface for controlling one or a group of processes, hence the name. They allow the control of several aspects of the group's use of resources. Resource utilization can be controlled using a limit (for example, by limiting memory usage). Cgroups also allow priorities to be set to give processes a greater or lesser share of time-bound resources, such as CPU utilization or I/O. Cgroups can also be used to snapshot (and restore) the state of running processes.
Namespaces
The other part of the container puzzle is kernel namespaces. They operate in a manner that is somewhat similar to our use of the chroot syscall in that a container engine instructs the kernel to only allow the process a particular view of the system's resources.
Instead of just limiting access to the filesystem kernel, namespaces limit access to a number of different resources.
Each process can be assigned to a namespace and can then only see the resources connected to that namespace. The kinds of resources that can be namespaced are as follows:
Mount
: Mount namespaces control access to the filesystem.
Users
: Each namespace has its own set of user IDs. User ID namespaces are nested, and thus a user in a higher-level namespace can be mapped to another in a lower level. This is what allows a container to run processes as root, without giving that process full permission to the root system.
PID
: The process ID namespace, like the users namespace, is nested. This is why the host can see the processes running inside of the containers when inspecting the process list on a system that is running containers. However, inside of the namespace the numbers are different; this means that the first process created inside a PID namespace, can be assigned PID 1, and can inherit zombie processes if required.
Network
: A network namespace contains one or more network interfaces. The namespace has its own private network resources, such as addresses, the routing table, and firewall.
Putting the pieces together
It is the job of the container engine (software such as Docker or rkt) to put these pieces together and make something usable and understandable for us mere mortals.
While a system that directly exposed all of the details of Cgroups and namespaces would be very flexible, it would be far harder to understand and manage. Using a system such as Docker gives us a simple-to-understand abstraction over these low-level concepts, but necessarily makes many decisions for us about how these low-level concepts are used.
The fundamental breakthrough that Docker made over previous container technologies was to take great defaults for isolating a single process and combine them with an image format that allows developers to provide all the dependencies that the process requires to run correctly.
This is an incredibly good thing because it allows anyone to install Docker and quickly understand what is going on. It also makes this kind of Linux container the perfect building block to build larger and more complex systems, such as Kubernetes.
Here, schedule this...
At its heart, Kubernetes is a system for scheduling work to a cluster of computers—a scheduler. But why would you want a scheduler?
If you think about your own systems, then you'll realize that you probably already have a scheduler, but unless you are already using something like Kubernetes, it might look very different.
Perhaps your scheduler is a team of people, with spreadsheets and documentation about which services run on each server in your data center. Perhaps that team of people looks at past traffic statistics to try and guess when there will be a heavy load in the future. Perhaps your scheduler relies on your users alerting members of your team at any time of the night if your applications stop functioning.
This book is about these problems, about how we can move on from a world of manual processes and making guesses about the future usage of our systems. It is about harnessing the skill and experience of the humans that administer the systems to encode our operational knowledge into systems that can make decisions about your running system second by second, seamlessly responding to crashed processes, failed machines, and increased load without any human intervention.
Kubernetes chooses to model its scheduler as a control loop so that the system is constantly discovering the current state of the cluster, comparing it to a desired state, and then taking actions to reduce the difference between the desired and the actual state. This is summarized in the following diagram:
Being able to declare the state that we want the system to be in, and then have the system itself take the actions needed to manifest that desired state, is very powerful.
You may previously have used an imperative tool or a script to manage a system, or you may even have used a written playbook of the manual steps to take. This sort of approach is very much like a recipe: you take a set of actions one after another and hopefully end up in the state that you desire.
This works well when describing how to install and bootstrap a system for the first time, but when you need to run your script against a system that is already running, your logic needs to become more complicated as, for each stage in your recipe, you have to stop and check what needs to be done before you do it.
When using a declarative tool such as Kubernetes to manage your system, your configuration is simplified and becomes much easier to reason about. One important side effect of this approach is that Kubernetes will repair your configuration if an underlying failure causes it to drift away from your desired state.
By combining control loops and declarative configuration, Kubernetes allows you to tell it what to do for you, not how to do it. Kubernetes gives you, the operator, the role of the architect and Kubernetes takes the role of the builder. An architect provides a builder with detailed plans for a building, but doesn't need to explain how to build the walls with bricks and mortar. Your responsibility is to provide Kubernetes with a specification of your application and the resources it needs, but you don't need to worry about the details of exactly how and where it will run.
The basics of Kubernetes
Let's begin our look at Kubernetes by looking at some of the fundamental concepts that most of Kubernetes is built upon. Getting a clear understanding of how these core building blocks fit together will serve you well as we explore the multitude of features and tools that comprise Kubernetes.
It can be a little confusing to use Kubernetes without a clear understanding of these core building blocks so, if you don't have any experience with Kubernetes, you should take your time to understand how these pieces fit together before moving on.
The pod
Like a group of whales, or perhaps a pea pod, a Kubernetes pod is a group of linked containers. As the following diagram shows, a pod can be made up of one or more containers; often a pod might just be a single container:
Each pod that Kubernetes schedules is allocated its own unique IP address. The network namespace (and thus the pod's IP address) is shared by each container in the pod.
This means that it is convenient to deploy several containers together that closely collaborate over the network. For example, you might deploy a reverse proxy alongside a web application to add SSL or caching capabilities to an application that does not natively support them. In the following example, we achieve this by deploying a typical web application server-for example, Ruby on Rails—alongside a reverse proxy—for example, NGINX. This additional container provides further capabilities that might not be provided by the native application. This pattern of composing functionality together from smaller isolated containers means that you are able to reuse components more easily, and makes it simple to add additional functionality to existing tools. The setup is shown in the following diagram:
As well as sharing the network namespace, Kubernetes also allows very flexible sharing of volume mounts between any number of containers in a pod. This allows for a number of scenarios where several components may collaborate to perform a particular task.
In this example, we are using three containers that coordinate to serve a website built with a static-site generator using the NGINX webserver.
The first container uses Git to pull and update the source code from a remote Git repository. This repository is cloned into a volume that is shared with the second container. This second container uses the Jekyll framework to build the static files that will be served by our webserver. Jekyll watches the shared directory for changes on the filesystem and regenerates any files that need to be updated.
The directory that Jekyll writes the generated files to is shared with a container running NGINX that serves HTTP requests for our website, as shown in the following diagram:
Another use for pods that share volume mounts is to support applications that communicate using Unix sockets, as shown in the following diagram. For example, an extract transform load (ETL) system could be modeled as several independent processes that communicate with UNIX sockets. This might be beneficial if you are able to make use of third-party tools for some or all of your pipeline, or reuse tools that you may have built for internal use in a variety of situations:
In this example, a custom application designed to scrape data from webpages communicates with an instance of Fluentd over a Unix domain socket located in a shared volume. The pattern of using a third-party tool such as Fluentd to push data to a backing datastore not only simplifies the implementation of the custom tool, but also provides compatibility with any store that Fluentd chooses to support.
Kubernetes gives you some strong guarantees that the containers in your pod have a shared lifecycle. This means that when you launch a pod, you can be sure that each container will be scheduled to the same node; this is important because it means that you can depend on the fact that other containers in your pod will exist and will be local. Pods are often a convenient way to glue the functionality of several different containers together, enabling the reuse of common components. You might, for example, use a sidecar container to enhance the networking abilities of your application, or provide additional log management or monitoring facilities.
Labeling all the things
Labels are key-value pairs that are attached to resources, such as pods. They are intended to contain information that helps you to identify a particular resource.
You might add labels to your pods to identify the application that is being run, as well as other metadata, such as a version number, an environment name, or other labels that pertain to your application.
Labels are very flexible, as Kubernetes leaves it up to you to label your own resources as you see fit.
Once you begin working with Kubernetes, you will discover that you are able to add labels to almost every resource that you create.
The power of being able to add labels that reflect the architecture of your own application is that you are able to use selectors to query the resources using any combination of the labels that you have given your resources. This setup is shown in the following diagram:
You can add labels to many of the resources that you will create in Kubernetes and then query them with selectors.
Replica sets
In Kubernetes, a ReplicaSet is a resource that templates the creation of pods. The definition of a replica set contains a template definition of the pods that it creates, a desired count of replicas, and a selector to discover the pods under its management.
The ReplicaSet is used to ensure that the desired number of pods is always running. If the count of pods matching the selector drops below the desired count, then Kubernetes will schedule another.
Because the life of a pod is tied to that of the node that it is running on, a pod can be considered ephemeral. There are a number of reasons why the life of a particular pod could come to an end. Perhaps it was removed by the operator or an automated process. Kubernetes could have evicted the pod to better utilize the resources of the cluster or prepare the node for shutdown or restart. Or perhaps the underlying node failed.
A ReplicaSet allows us to manage our application by asking the cluster to ensure that the correct number of replicas is running across the cluster as a whole. This is a strategy that Kubernetes embraces across many of its APIs.
As a cluster operator, Kubernetes takes some of the complexity of running applications away from the user. When I decide that I need three instances of my application running, I no longer need to think about the underlying infrastructure: I can just tell Kubernetes to carry out my wishes. And if the worst happens and one of the underlying machines that my application is running on fails, Kubernetes will know how to self-heal my application and launch a new pod. No more pager calls and trying to recover or replace failed instances in the middle of the night.
Often, we want to update the software we run on our cluster. Because of this, we don't normally directly use ReplicaSet but, instead, manage them with a Deployment object. Deployments are used in Kubernetes to gracefully roll out new versions of a ReplicaSet. You will learn more about deployments in Chapter 4, Managing Change in Your Applications.
Services
The final basic tool that Kubernetes gives us to manage our applications is the service. Services give us a convenient way of accessing our services within our cluster, something often referred to as service discovery.
In practice, a service allows us to define a label selector to refer to a group of pods and then map that to something that our application can consume, without having to be modified to query the Kubernetes API to gather this information. Typically, a service will provide a stable IP address or DNS name that can be used to access the underlying pods that it refers to in a round robin fashion.
By using a service, our applications don't need to know that they are running on Kubernetes-we just need to configure them correctly with the DNS name or IP address of a service that they depend on.
