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

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

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

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

• Why organizations care about the cloud
• What the cloud did for engineers
• How abstraction can help us learn from our mistakes
• How the cloud doesn’t exactly do what people think it does

Let’s take a closer look.

Why organizations care about the cloud

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

Figure 1.1 – Data center web app architecture

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

• Servers
• Network equipment
• Connections between servers
• Ethernet cables and power cables

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

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

• RDS (Amazon’s database service)
• Load balancers
• CDNs
• S3 buckets (cloud storage in AWS)
• Route 53 (AWS DNS)

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

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

Figure 1.2 – Cloud web app architecture

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

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

• Load balancers
• Virtual machines (or bare-metal servers)
• Network equipment (virtual or physical)
• Subnets, private IPs, public IPs, and gateways
• Security for multiple pieces of virtualized hardware and services

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

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

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

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

What the cloud did for engineers

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

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

• Autoscaling the servers
• Doing multiple checks to ensure that there’s enough hard disk, CPU, and RAM space on the physical/bare-metal server that’s being used
• Networking setup
• Lots of automation

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

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

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

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

• Deploying your containerized application
• Scaling your application
• Ensuring that your application is highly available
• Giving you the ability to secure your application and the users accessing the application

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

Kubernetes in the cloud

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

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

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

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

Why Kubernetes?

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

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

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

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

Kubernetes as a data center

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

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

• Servers
• Network equipment (firewalls, load balancers, routers, switches, gateways, and so on)
• Outbound and inbound connectivity
• Security
• The ability to run software and virtualization on the servers

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

Kubernetes fills every piece of the data center puzzle:

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

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

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

When thinking about creating any type of application, automation code, or piece of software, there always needs to be some sort of standard. The thing is, there are many standards and there isn’t a one-size-fits-all solution. Sure, there are (what should be) mandatory standards for writing code such as storing the code in source control and running certain types of tests, but the workflows for each organization will be drastically different.

When it comes to cloud-native applications and applications running on Kubernetes, the thought process of workflows is the same as any other application, but there are true, standard processes that are automatically implemented for you. This includes things such as the following:

• Easy autoscaling
• Self-healing
• Networking out of the box
• And a lot more

In the upcoming section, we’ll build on what you learned previously and dive into what cloud-native apps do for organizations.

What cloud-native apps do for organizations

By definition, a cloud-native application gives you the ability to do the following:

• Easily scale
• Make highly available almost out of the box
• Deploy more efficiently
• Continuously make changes in a much easier fashion versus outside of Kubernetes in a bare-metal/data center environment

When thinking about cloud-native applications and the preceding list, microservices typically come to mind. The idea behind microservices, which is a big piece of the idea behind cloud-native, is the ability to make changes faster and more efficiently. When you’re dealing with a monolithic application, the application has many dependencies and is essentially tied together. You can’t update one piece of the application without bringing down the rest of the application. Blue/green and canary deployments are far more complicated because of the tightly coupled monolithic application. Self-healing and scalability mean scaling the entire application, not just the pieces that need to be scaled, which means more resources (RAM, CPU, and so on) are typically consumed than what’s needed.

Cloud-native and the microservice mindset aim to fix this problem. With microservices running inside Kubernetes, there are some extreme benefits. You can manage how many replicas (copies) of the application are running. That way, you can scale them out or scale them back when needed. Self-healing of Pods is far more efficient since if a piece of the application that’s running inside of a Pod goes down, it’s not a huge deal because it’ll come right back up automatically. The applications running inside of Pods, which have one or more containers running inside of the Pods, are loosely coupled, so updating/upgrading versions of the application in a blue/green or canary scenario utilizing a rolling update is far less likely to fail.

When it comes to teams, as in, individual engineers, microservices help a ton. With a monolithic application, there is a fair amount of coordination that has to happen between the team when changing anything in the code base. Although teamwork and communication are crucial, there shouldn’t be a reason to let everyone know about a code change in the development environment that you’re making to test a piece of functionality without breaking everyone else’s code. With how fast organizations want to move in today’s world, this process slows engineering teams down to a grinding halt. Not to mention, if an engineer wants to test how the functionality will work with the rest of the application, they shouldn’t have to worry about every piece of the application breaking. That’s really where microservices shine.

When the Kubernetes architecture was built, it was thought about in the same way as cloud-native applications – a loosely coupled architecture that is easily scalable and doesn’t have a ton of dependencies (hence, the microservice movement). Can you run monolithic applications on Kubernetes? Absolutely. Will they still self-heal and autoscale? Absolutely. The idea behind a cloud-native application environment and cloud-native Kubernetes is to use a microservice-style architecture, but you shouldn’t let that stop you from jumping into Kubernetes. The primary goal is to have independent services that can be accessed via an Application Programming Interface (API).

The final piece of the puzzle is containerized applications. Before even running an application inside Kubernetes, it must be containerized. When the idea of containers was thought about way before Docker was around, the idea was to have the ability to split an entire application into tiny micro-sized pieces. When containers are built, they’re built with the same mindset as the following aspects:

• Self-contained execution environments
• Virtualized OSes
• Microservice architecture with the ability to split up pieces of an entire application and consolidate it into a single container for the ability to easily scale, update, and swap out

The world is cloud-based

One of the worst things that an organization can do in today’s world, from an engineering perspective, is to get left behind. The last thing an organization wants is to realize 10 years later that the systems and dependencies that they have in place are so old that no organization or software company is even supporting them anymore. The golden rule before 2015/2016 was to ensure that the architecture and the people/engineers running the architecture were up to date every 5 to 10 years. Now, with how fast technology is moving, it’s more like every 2 to 5 years.

When looking at organizations such as Microsoft, Google, and AWS, they’re releasing huge changes and updates all the time. When attending a conference such as Microsoft Build or the AWS Summit, the keynotes are filled with game-changing technology with tons of new services coming to the cloud platforms all the time. The reality is that if organizations don’t want to be left behind, they can’t wait more than 5 years to start thinking about the newest technology.

With that being said, many organizations can’t simply upgrade systems every 6 months or every year because they’re too large and they don’t have enough people to make those migrations and updates. However, technology leaders need to start thinking about what this will look like because the future of the company will be on the line. For example, let’s look at the change in Windows Server over the past few years. Microsoft used to constantly talk about new Windows Server versions and features at every conference. Now, it’s all about Azure. The technology world is changing drastically.

Where Kubernetes fits in here is that it helps you make cloud-native and fast-moving decisions almost automatically. For example, let’s say (in a crazy world) Kubernetes goes away in 3 years. You still have your containerized applications and your code base that’s in source control and loosely coupled, which means you can run it anywhere else, such as in a serverless service or even a virtual machine if it comes down to it. With the way that the world is going, it’s not necessarily about always using Kubernetes to prevent an organization from going down. It’s about what Kubernetes does for engineers, which is that it allows you to manage infrastructure and applications at the API level.

Engineering talent is toward the cloud

One last small piece we will talk about is the future of engineers themselves. New technology professionals are all about learning the latest and greatest. Why? Because they want the ability to stay competitive and get jobs. They want to stay up to date so they can have a long and healthy career. What this means is that they aren’t interested in learning about how to run a data center, because the tech world is telling everyone to learn about the cloud.

As time goes on, it’s going to become increasingly difficult for organizations to find individuals that can manage and maintain legacy systems. With that being said, there’s no end in sight for legacy systems going away. That’s why organizations such as banks are still looking for COBOL developers. The thing is, no engineer wants to bet their career in their 20s on learning legacy pieces.

One of the biggest buzzwords in the technology space today is abstraction. Abstraction, at its highest level, involves removing certain pieces of work from you that you specifically need to do to get the job done. For example, if a developer needs to run code, they need to run code. They don’t need to build virtual machines or deploy networks. They simply need to run an application. Removing the need for a virtual machine or a network is abstracting away what the developer doesn’t need to spend time and focus on.

What abstraction does

Let’s take a look at what abstraction does from two sides – Dev and Ops.

From a Dev perspective, the goal of a developer is to plan out pieces of an application, write the code to make those pieces work, and deploy them to see how the pieces work together. However, to deploy the code, you used to need a server, an OS, and other components. With platforms such as Kubernetes, developers don’t need that anymore. Instead of having to worry about deploying virtual machines, developers simply have to write a Kubernetes manifest that contains a container image with the application inside of it. No more having to worry about day-one operations.

From an Ops perspective, infrastructure engineers or cloud engineers no longer have to worry about having to stop what they’re doing to order servers, deploy virtual machines, and fight to make an OS work as expected. Instead, they can write out a Kubernetes manifest and other API-driven techniques (such as IaC) to ensure that a Kubernetes cluster is up and running, operational, and ready to host developer code/container images.

What abstraction doesn’t do

One primary thing that abstraction doesn’t do is remove the need to think logically and from an architectural perspective for engineering-related work. Abstraction removes what’s now considered the low-hanging fruit of an environment. For example, a virtual machine with the need to deploy an OS and manage all the components can now be considered low-hanging fruit when the other option is to deploy a Kubernetes cluster and manage the infrastructure at the API level.

The important piece to remember is that engineers and developers still need to think. Abstraction isn’t about having a solution where you press a button or two and poof, your application is up and running with scaling and plenty of high availability. Abstraction at this level still requires solid architecture, planning, and repeatable processes.

The final part of this chapter will involve mapping out how you can start slow but, at the same time, go fast when implementing Kubernetes. The idea is that you want to understand what’s happening inside of your organization so that you truly know the need for Kubernetes. Once you know that, you can start implementing it as fast as possible without taking on technical debt and management worries. When thinking about how to start slow and go fast, the premise is to understand the why behind the conversation around Kubernetes and then once you know that, start iterating.

Understanding the engineering need for Kubernetes

Every good engineer has a lot of goals, but a few of the primary ones are as follows:

• Make my life easier
• Remove the work that isn’t important
• Conduct value-driven work for an organization

When it comes to putting out fires, waking up at 2:00 A.M. and rushing around to try to get a server up and running for a developer isn’t the most fun part of an engineer’s day. Instead, they want to focus on providing value to an organization. Abstraction helps a ton with removing what isn’t needed, as does removing toil.

The same goes for developers. They don’t want to worry about waiting days or weeks (or longer) to get a server up and running to host an application. They want a quick, efficient, and scalable way to host applications without having to sit around and wait.

The goal is for an engineer to understand the need for Kubernetes. It’s easy to look at the latest and greatest technology so that it can be implemented. That’s typically the fun part for many engineers, both on the Ops and Dev sides. However, the most important piece is understanding that Kubernetes removes the low-hanging fruit for setting up environments and instead allows you to focus on value-driven work.

Understanding the business need for Kubernetes

There are always two sides to a tech plan in any organization – the technical/engineering side and the business side. On the business side, the primary important pieces are as follows:

• Will Kubernetes help us go faster?
• Will Kubernetes make us more efficient?
• Will Kubernetes help us get to market faster?
• Will Kubernetes help us reduce downtime and engineering overhead?

The answers to those questions are yes and no, and as an engineer, you have to be prepared to answer them. The golden rule is that Kubernetes removes the incredible complexity of racking and stacking a data center, much like the cloud. When talking about Kubernetes to the business, it isn’t a conversation around implementing this Kubernetes thing and all our problems go away. The conversation is more around this Kubernetes thing will make our lives easier.

Planning is the hard part

As engineers, both on the Dev and Ops sides, playing with new technology is fun. Learning new tricks, new platforms, and beefing up your resume to stay competitive in the market is what a lot of individuals think about. Although that’s great, you also must think about the why behind implementing Kubernetes.

Before moving on to the next chapter, think about these three things:

• Why do I feel like Kubernetes is important?
• How can Kubernetes help my environment progress?
• How can Kubernetes make deploying software easier?

Now, let’s summarize what we’ve learned in this chapter.

Before you can even think about implementing Kubernetes, you need to learn about what the cloud is doing for engineers, what cloud-native applications are doing for engineers, and why organizations need to start thinking about Kubernetes. This is always the first step in any engineering-related decision since it impacts not only you but the organization as a whole. Because of the way that the tech world is changing, understanding the need for implementing cloud-based solutions and how to move fast but start slow is how organizations have successful Kubernetes deployments and a smooth on-ramp from traditional monolithic applications to implementing microservices.

Now that you know the why behind implementing cloud-native technologies such as Kubernetes and what cloud-native applications do for organizations, it’s time to start learning about how to get started with Kubernetes. We will start the next chapter by understanding how to implement a Kubernetes service in the top three clouds.

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• Architecting Cloud Computing Solutions, by Kevin L. Jackson and Scott Goessling: https://www.packtpub.com/cloud-networking/cloud-computing
• vSphere Virtual Machine Management, by Rebecca Fitzhugh: https://www.packtpub.com/product/vsphere-virtual-machine-management/9781782172185
• Cloud Native Architectures, by Tom Laszewski, Kamal Arora, Erik Farr, and Piyum Zonooz: https://www.packtpub.com/product/cloud-native-architectures/9781787280540