Cloud native application challenges: installing the walking skeleton

Editor’s note: This article is an excerpt from Chapter 1 of the Manning book, Platform Engineering on Kubernetes. This excerpt focuses on managing YAML-defined Kubernetes resources — deployments, services, Ingress, and ConfigMaps/secrets — at scale. To learn the latest Kubernetes best practices and the open source solutions, straight from the Kubernetes community, download the book in its entirety.

In the previous section [which can be read by downloading the entire book], I shared a hands-on approach to experimenting with cloud native applications by deploying a sample microservices app on a local Kubernetes cluster using Kubernetes in Docker. Now, it’s time to deploy our walking skeleton. 

To run containerized applications on top of Kubernetes, you will need to have each of the services packaged as a container image, plus you will need to define how these containers will be configured to run in your Kubernetes cluster.

Defining Services and Resources in Kubernetes with YAML

To do so, Kubernetes allows you to define different kinds of resources (using YAML format) to configure how your containers will run and communicate with each other. The most common kinds of resources are: 

• Deployments: Declaratively define how many replicas of your container need to be up for your application to work correctly. Deployments also allow us to choose which container (or containers) we want to run and how these containers must be configured (using environment variables). Running our cloud-native applications.
• Services: Declaratively define a high-level abstraction to route traffic to the containers created by your deployments. It also acts as a load balancer between the replicas inside your deployments. Services enable other services and applications inside the cluster to use the service name instead of the physical IP address of the containers to communicate, providing what is known as service discovery.
• Ingress: Declaratively define a route for routing traffic from outside the cluster to services inside the cluster. Using Ingress definitions, we can expose the services that are required by client applications running outside the cluster. 
• ConfigMap/secrets: Declaratively define and store configuration objects to set up our service instances. Secrets are considered sensitive information that should have protected access.

Why YAML alone becomes hard to manage

These YAML files will be complex and hard to manage if you have large applications with tens or hundreds of services. Keeping track of the changes and deploying applications by applying these files using kubectl becomes a complex job. It is beyond the scope of this series to cover a detailed view of these resources, and other resources are available such as the official Kubernetes documentation page. 

In this book [which can be downloaded here], we will concentrate on how to deal with these resources for large applications and the tools that can help us with that task. The following section provides an overview of the tools to package and install components into your Kubernetes cluster.

Packaging and installing Kubernetes applications

There are different tools to package and manage your Kubernetes applications. Most of the time, we can separate these tools into two main categories: templating engines and package managers. You will probably need both kinds of tools for real-life scenarios to get things done.

What are templating engines in Kubernetes?

Let’s discuss these two kinds of tools: why would you need a templating engine? What kind of packages do you want to manage? A templating engine allows you to reuse the same resource definitions in different environments where applications might require slightly different parameters. 

The textbook example of the need to template your resources is database URLs. If your service needs to connect to different database instances in different environments, such as the testing database in the testing environment and the production database in the production environment, you want to avoid maintaining two copies of the same YAML file but with different URLs. 

The figure below shows how you can now add variables to the YAML files, and the engine will then find and replace these variables with different values depending on where you want to use the final (rendered) resource. 

“Using a templating engine can save you a lot of time maintaining different copies of the same file, because when files start to pile up, maintaining them becomes a fulltime job.”

Using a templating engine can save you a lot of time maintaining different copies of the same file, because when files start to pile up, maintaining them becomes a fulltime job. There are several tools in the community to deal with templating Kubernetes files. Some tools just deal with YAML files, and some other tools are more targeted to Kubernetes resources specifically. Some projects that you should check out are:

• Kustomize: https://kustomize.io/

• Carvel YTT
• Helm Templates

What are package managers for Kubernetes?

Now, what do you do with all these files? 

It is quite a natural urge to organize these files in logical packages. If you are building an application that is composed of different services, it might make sense to group all the resources related to a service inside the same directory or even in the same repository that contains the source code for that service. 

You also want to make sure that you can distribute these files to the teams deploying these services to different environments, and you quickly realize that you need to version these files in some way. This versioning might be related to the version of your service itself or with a high-level logical aggregation that makes sense for your application. 

“When we talk about grouping, versioning, and distributing these resources, we are describing the responsibility of a package manager.”

When we talk about grouping, versioning, and distributing these resources, we are describing the responsibility of a package manager. Developers and operations teams are already used to working with package managers no matter the technology stack they use. Maven/Gradle for Java, NPM for NodeJS, APT-GET for Linux/Debian/ Ubuntu packages, and more recently, containers and container registries for cloudnative applications.

Core responsibilities of a Kubernetes package manager

So, what does a package manager for YAML files look like? What are the package manager’s main responsibilities? As a user, a package manager allows you to browse available packages and their metadata to decide which package you want to install. Once you have decided which package you want to use, you should be able to download it and then install it. 

Once the package is installed, you would expect, as a user, to be able to upgrade to a newer version of the package when it becomes available. Upgrading/updating a package requires manual intervention, meaning that as a user, you will explicitly tell the package manager to upgrade the installation of a certain package to a newer (or latest) version. 

From a package provider’s point of view, a package manager should offer a convention and structure to create packages and a tool to package the files you want to distribute. Package managers deal with versions and dependencies, meaning that if you create a package, you must associate a version number with it. 

Some package managers use the semver (semantic versioning) approach, which uses three numbers to describe the package maturity (1.0.1, where these numbers represent the major, minor, and patch versions). 

A package manager doesn’t need to provide a centralized package repository, but they often do. This package repository is in charge of hosting packages for users to consume. 

Central repositories are useful because they provide access to developers with thousands of packages ready to be used. Some examples of these central repositories are Maven Central, NPM, Docker Hub, GitHub Container Registry, etc. These repositories are in charge of indexing the package’s metadata (which can include versions, labels, dependencies and short descriptions) to make them searchable by users. 

These repositories also deal with access control to have public and private packages, but at the end of the day, the main responsibility of the package repository is to allow package producers to upload packages and package consumers to download packages from them (see below).

Popular Kubernetes tools: Helm, Imgpkg, Kapp, Terraform

When we talk about Kubernetes, Helm is a very popular tool that provides both a package manager and a templating engine. But there are others worth looking into, such as: 

• Imgpkg , which uses Container registries to store the packages. 
• Kapp , which provides higher-level abstractions to group resources as applications.
• Tools like Terraform and Pulumi that allow you to manage infrastructure as code. 

In the following section, we will look at using Helm to install the Conference application into our Kubernetes cluster. Download the entire book to keep reading.

Frequently asked questions

1. What is a walking skeleton in cloud native applications?

A walking skeleton is a minimal deployment that demonstrates basic architecture and connectivity between microservices. It serves as a foundation for testing your deployment pipeline and Kubernetes configuration before building full functionality.

2. Why do you need templating engines for Kubernetes YAML files?

Templating engines solve the problem of maintaining multiple YAML copies across different environments. They let you use variables that get replaced with environment-specific values like database URLs, saving time when managing complex applications.

3. What’s the difference between templating engines and package managers for Kubernetes?

Templating engines handle configuration management by replacing variables for different environments. Package managers focus on grouping, versioning, and distributing collections of Kubernetes resources as logical packages.

4. How do you manage Kubernetes applications with multiple services at scale?

Use the four core Kubernetes resources (Deployments, Services, Ingress, ConfigMaps/Secrets) combined with both templating engines and package managers. Tools like Helm provide both capabilities to avoid manually managing hundreds of YAML files.