Learn Kubernetes- It’s Easier Than You Think

By: Tracy Ragan

It is time to learn Kubernetes. Once again the IT community is facing a massive evolution. Some would believe that evolution happens slowly over time, but there are current day evolutionists that suggest something different. Instead of evolving over years, we evolve in sprints. This theory accurately describes IT evolution. Get ready because we are going through one of the sprints.

If we think back over the last thirty years of IT, there are three big sprints. First, moving from a mainframe architecture to a fully distributed ‘open’ architecture. This move introduced us to OS/2, Windows and most importantly Linux. The second evolutionary sprint was to the cloud and virtual environment. The second sprint’s goal in part was to correct the problem with our first sprint. Getting rid of all those physical machines became essential. Now we are on our third big sprint; modern architecture. Modern architecture took the idea of virtual machines to the next level, one that delivers auto scaling and fault tolerance. Yes, we are evolving quickly.

Transforming to Modern Architecture

Every evolution has required us to change the way in which we develop and deliver software. This sprint is no different. In a modern architecture we will be required to transform the way we write software, deliver binaries and manage production infrastructure. While some tools may stay in place, most practices and tooling will be upgraded or completely replaced. This is why the time is now to learn Kubernetes.

The shift to containers and Kubernetes will impact writing code, our CI/CD pipeline and data center management. In other words, just about everything. Let’s look at each:

1. Code will go from thousands of lines long to a few hundred lines long and version control with branching and merging becomes less critical
2. Configuration Management will shift from the developers build (compile/link) process to managing runtime APIs3) Performance monitoring, security and deployments will shift from a monolithic application to small reusable functions

Don’t fret. Much of what we are getting rid of needs to go. But the problem is moving from this monolithic approach to a microservice-based architecture. This is a complex environment. New solutions are entering the market to make this easier.

Human Transformation

Like all the evolutionary sprints, this current modern architecture sprint requires a shift in culture. In order to learn Kubernetes, Dev and Ops professionals will need to open their minds, be willing to learn new skills and shift thinking from monolithic practices to microservices. While this sounds daunting at first, it’s important to remember “the more things change, the more things stay the same.” This shift, like any other, does not change the core of software. We write code and we deliver it. While the infrastructure is shifting, the core of software development is not.

Learn Kubernetes from the Beginning

Getting started in this new modern architecture requires learning some new terms and concepts. The best place to start is with containers:

Containers — A container provides an isolated context in which an application, together with its environment can run. Its problems include:

• Containers need to be managed
• Container networking is hard
• Containers must be scheduled, distributed and load balanced· Data must persist somewhere

Containers led to the birth of Kubernetes which performs container orchestration.

Kubernetes — Kubernetes ensures that the cluster running containers continues to serve users no matter how its environment is altered, with minimal intervention from operations teams. Kubernetes is ‘self-healing’ which mean its:

• Finds and restarts failed containers;
• Finds and reschedules failed nodes;
• Destroys unresponsive containers;

To learn Kubernetes, we need some definitions of the parts and pieces of Kubernetes.

Navigating Kubernetes — The absolute best way to learn Kubernetes is to read some highly technical books. Two of the best are ”The Illustrated Children’s Guide to Kubernetes” and “Phippy Goes to the Zoo–A Kubernetes Story” by Matt Butcher & Karen Chu, Illustrated by Bailey Beougher, Renee French. These illustrated children’s books were created on behalf of the Cloud Native Computing foundation. They provide a simple explanation of Kubernetes. You can read them to the kids making sure they are prepared to create the next evolution in IT architecture.

Here is Kubernetes according to Phippy:

Nodes and Pods — A Node is a simple virtual Image. Pods live in Nodes. According to Phippy, “Pods run your containers. There is at least one container for every Pod. The Pod controls the execution of that container. When the container exits, the pod dies too.”

In your Kubernetes cluster, you will have multiple Nodes running Pods that house containers.

Replica Sets — “ReplicaSet ensures that a set of identically configured Pods are running at the desired replica count. If a Pod drops off, the ReplicaSet brings a new one online as a replacement.”

Deployments — “Deployments controls deploying and maintaining a set of Pods. It uses a ReplicaSet to keep Pods running, but offers sophisticated logic for deploying, updating, and scaling a set of Pods within a cluster.”

Daemon Sets — “DaemonSets provide a way to ensure that a copy of a Pod is running on every node in a cluster. As a cluster grows and shrinks, the DaemonSets spreads these specially labeled Pods across all of the nodes.”

Ingress — “Ingresses provide a way to declare that traffic ought to be channeled from the outside of the cluster into destination points within the cluster. One single external Ingress point can accept traffic destined to many different internal services.”

Custom Resource Definitions — “CRDs provide an extension mechanism that cluster operators and developers can use to create their own resource types.”

Labels — “Kubernetes uses labels as “nametags” to identify things. Labels are open-ended. You can use them to indicate roles, stability, or other important attributes.”

Namespace — “A namespace functions as a grouping mechanism inside of Kubernetes. Services, pods, replication controllers, and volumes can easily cooperate within a namespace, but the namespace provides a degree of isolation from the other parts of the cluster.”

Service — “A service tells the rest of the Kubernetes environment (including other pods and replication controllers) what services your application provides. While pods come and go, the service IP addresses and ports remain the same. And other applications can find your service through Kubernetes service discovery.”

If you Learn Kubernetes — Microservices is next

Now that you have the basics down around Kubernetes, it’s time to understand microservices. According to Wikipedia, “Microservices are a software development technique — a variant of the service-oriented architecture architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight.”

When you think microservices, think functions. Instead of building a single .jar or .ear file you will instead have hundreds (if not thousands) of microservices that are linked at runtime via APIs. A collection of microservice versions create an application version. Unlike our monolithic days of compiling and linking a binary that is itself the software application, microservices are loosely coupled. A core foundation of microservices is that they are independently deployed and should be written in a way to not impact its clients when a new version is made available. Microservices are immutable, meaning they are never changed. You always release a new version and, in many cases,, the old version will remain running in your cluster until it can be safely deprecated.

From Data Center to Death Star

When you start building out a cluster of microservices, it begins to look very much like a Deathstar. Microservices are released and shared across multiple applications and teams. Microservices require a strong Domain Driven Design and careful management. It will not be uncommon for Death Stars to include 3,000 to 5,000 microservices. Take a look at the Amazon Death Star:

New DevOps tools are entering the market to provide visibility into your Death Star. New solutions will include configuration management, new Kubernetes CD pipelines, security and monitoring. Sound familiar? It is, just in a new format.

Conclusion

The time is now to learn Kubernetes and to understand the shift that microservices create in our software development practice. It would be wrong to believe that Kubernetes is just a passing phase. It is here to stay and critical for Machine Learning (ML) and Artificial Intelligence (AI) where the ability to scale up processors to perform massive computing and pattern matching is essential. We could not have self-driving cars, or Netflix without it. Learning is easy — read ”The Illustrated Children’s Guide to Kubernetes” and “Phippy Goes to the Zoo–A Kubernetes Story” to get started. You will be surprised how quickly your mind will begin to shift to this new fault tolerant, auto-scaling way of thinking where the ability to compute is endless. I for one am super charged by the possibilities Kubernetes creates. I hope you will be too.

REGISTER FOR THE ENTERPRISE KUBERNETES VIRTUAL SKILUP DAY HERE

DevOps Institute is dedicated to advancing the human elements of DevOps success through the SKIL Framework: Skills, Knowledge, Ideas, and Learning. Learn more.

This blog was originally posted on DevOpsInstitute.com.