Kubernetes Architecture: Four Approaches to Container Solutions

If you write source code and test applications, you likely think of the application code as separate from the server that it runs on. The code is checked into version control, the build executes, and then an automated process combines the two and creates a virtual environment. (Otherwise, you have to copy the application code by hand, then stop the server, and restart it, forcing the application into memory.)

Challenges of traditional programming vs. cloud-native

Moving between environments and reproducing production issues can cause serious programming delays. Programmers want easy pushes to production with limited downtime. Traditional programming approaches involve a single build written in one programming stack if the process is manual. This usually means changes only occur at night or over the weekend, which, in turn, means someone has to work the weekend and monitor in case something goes wrong with the rollout.

With a single large deploy, problems with one subsystem can influence another. Companies often want to check the entire system for problems, leading to regression testing of the entire system before release.

The cloud-native approach provides separate, thin slices of the application that can be built using any technology, interact using internet protocols, and can be deployed separately.

How Kubernetes can help

A container combines the core pieces of an operating system with all the dependencies and the code itself into one image. That image is a single file that is small enough to store as an artifact, pull out, and run. Kubernetes manages a large number of containers, doing the work to allocate disk, CPU, and memory so you don’t have to. Here are a few of the benefits of developing in this way:

• No-configuration debugging: The same image runs in test and production.
• Promoting the container is easy: All the code runs in a container plus shared resources (like a shared file system) called a pod. Creating a running a pod is a simple command-line command or two.
• Blue/green deploys are easy: Because Kubernetes controls traffic for an entire cluster, it is possible to create a series of new servers, sending traffic only after the server exists. That means no downtime and makes rollback as easy as switching the load balancer to the old server.
• Applications can be composed: Programmers can build individual pieces of functionality in separate images using whatever technologies they select.

For a deeper dive into what how programmers use Kubernetes clusters, see the blog post “Kubernetes Clusters: Architecture for Rapid, Controlled Cloud App Delivery.”

The title might be SysOps, Operations, or perhaps IT Administration. Whatever the name being used, the role is less about monitoring and supporting machines and more about setting up the machines, running them, and installing the applications that run on them.

The responsibilities include making sure there is enough CPU, disk, memory, and storage. In a data center environment, this might involve buying physical machines or the rack capacity to add to a private cloud. More likely, it means balancing several virtual machines on a limited number of servers while trying to keep server response times fast enough and making periodic backups.

Challenges for the administrator

Administrators walk a fine line when provisioning a private cloud—limited resources will lead to performance problems, while excessive resources add unnecessary cost. An administrator also focuses on deployment, setting up the technology so the programmers can roll out new versions easily. This role requires understanding setup, capacity planning, measurement, and deployment.

How Kubernetes can help

The Kubernetes cluster is a collection of pods, where each pod can be an application. Pods have one or more containers. As we’ve discussed, deploying containers (entire operating system images) and directing traffic can expedite deploys. Here are a few more ways container management with a tool like Kubernetes aids the administrator:

• Move seamlessly from private to public clouds: A Kubernetes cluster in a private environment looks, acts, and can be figured just the same as a cluster in a public cloud.
• Built-in scaling: The autoscale features of Kubernetes mean the servers can scale up and down to match demand, eliminating disk, CPU, and memory waste.
• Built-in load balancing: Kubernetes includes a proxy, which routes traffic to the load-balanced servers in the cluster. This load balancing is critical to keeping the cluster performing.
• Built-in labelling and naming: The Domain Name System (DNS link resides outside ibm.com) provides naming and discovery for the services in the cluster, making it possible to name and discover microservices.
• Deployment controllers track versioning: Administrators create a deployment that interacts with a deployment controller using the kubectl command; the deployment can create pods or ReplicaSets that represent a deployed application. The deployment can also track the version of the application that is running to roll forward changes or roll back in the event of a significant bug.
• Easily support CI/CD: Once applications are running on the cluster, most administrators will want to step back and stop running Kubernetes itself by hand through the kubectl. Instead, they’d like to have those commands run on files generated by a build/deploy pipeline. That pipeline will include a source code system like GitHub, a build automation tool such as Travis/Jenkins, and container image repositories like DockerHub. As Kubernetes continues to mature, new tools and support continue to emerge.

Once the server is running, someone needs to keep it running. Operators—also called software reliability engineers (SREs) or production application support experts—focus on observing system performance through graphs and logs and taking corrective action when systems do down or get slow.

Challenges for operations

The sheer number of servers, systems, routers, and other tools is expanding rapidly, and thanks to the Internet of Things, everything needs internet bandwidth. Unfortunately, bandwidth isn’t free.

At the same time, in data centers, all of the hosted applications need different versions of operating systems. Running them on one big server with virtual machines saves time, but those virtual machines then compete for resources. A simple list of every system is difficult to create and challenging to maintain, especially as systems increase in complexity. Operators also need notifications when something is going wrong and ways to observe and manage a complex environment.

How Kubernetes can help

Once the servers are in containers, running them in one cluster is easy. Operators can apply the “filename” command, where the filename has the rules to start up the container. If the container is running in the cluster, Kubernetes itself gives commands to observe the performance and resources of every system, along with tools to instrument and monitor at a higher level through the dashboard.

The sheer number of moving parts involved in a cluster can make isolating and debugging problems challenging. The Kubernetes UI (link resides outside ibm.com) tool does provide some dashboards for monitoring and logging deployment. Tools like Istio extend that monitoring to include traffic between all of the running pods within a cluster and provide new, cutting-edge capabilities to support workloads running across multiple clusters. Istio can also provide call-stack tracking of messages and track traffic accessing external endpoints—which can lead to important error notifications.

For a closer look at Istio, see our video “What is Istio?”:

The operator’s main entrance into Kubernetes is likely the dashboard (link resides outside ibm.com) (see example below). Using that dashboard, an operator performs tasks around monitoring, scaling, jobs, and deployments.

Management tasks security with hardening, protecting, auditing, and setting policies to reduce risk. Security professionals want to find and eliminate back doors that allow unintended access to the software.

One common anti-feature, for example, is the ability to inject malicious code. For the security analyst, the elements of the software exposed to the public internet are not necessarily good—they are more like the “attack surface.”

Security analysts may perform threat modeling (who could want or get what information from the system), hardening of systems, penetration testing, and auditing. Auditing can include authentication and authorization.

Challenges for the security analyst

Security challenges sound similar to the operator’s, at least at first. However, where the operator wants to monitor and fix the systems, security cares about controlling and locking them down. This “hardening” of systems prevents back doors and unanticipated power use, such as our malicious code example.

The goal is to limit the information paths, to know what the logins are on the systems, what operating systems they run on, and how to deploy policies to all of the systems at the same time. While you might have virus scanners running on laptops, the proliferation of open source code means that viruses can easily infiltrate a programmer’s codebase.

How Kubernetes can help

With Kubernetes, it’s possible to build a “base container” that all applications run on. That base container can be in a known good state. If a change needs to be deployed to all the servers, the kubectl command gives the analyst the capability to change all of them.

Kubectl provides the analyst with the tools to audit (link resides outside ibm.com) the changes, when they happened, who made them, from where the change was initiated, and more. Kube-apiserver performs audits while audit backends (link resides outside ibm.com) persist them to external storage.

That leaves the “open source virus” problem. Security scanning tools solve this by scanning each new container. That scans the entire operating system image, the code, the libraries, and all the dependencies.

Kubernetes architecture is flexible and can fit the needs and challenges of individuals across an entire IT department. For programmers, it helps control the code in each pod. Administrators get help setting up the cluster. Operators get help keeping the cluster running. Security analysts get help protecting the system.

A managed container service can help meet the needs of each of these perspectives. IBM Cloud Kubernetes Service allows for customization around configuration and cluster management while offering tools to consistently scale, service and monitor deployment.

Want to get some free, hands-on experience with Kubernetes? Take advantage of interactive, no-cost Kubernetes tutorials by checking out IBM CloudLabs.

Sign up for an IBMid and create your IBM Cloud account.