Smart Assistant

Distributors such as Red Hat and SUSE have been working to turn their large enterprise distributions into container runtime environments to outsource much of the hassle of package maintenance to the vendors of programs. In this and many other places, the motto "Kubernetes first" applies. Infrastructure as Code and continuous integration/continuous deployment (CI/CD) pipelines with all kinds of automatisms, including implicit error correction, are attractive factors simply missing in conventional deployment models.

For some admins, however, getting used to the world of containers and fleet managers quickly becomes a nightmare. Kubernetes and the container lobby promise that they will make everything far simpler and easier to manage. However, if you are setting up Kubernetes (K8s) for the first time and need a configuration that is not provided in the default settings of the respective K8s distribution, you will find yourself at a complete loss (Figure 1).

Figure 1: Kubernetes is powerful, but it is also massively complex. The sum of different technologies and functions that have formed around K8s in particular leaves newcomers perplexed. © CNCF

The same is true for rolling out apps in Kubernetes itself: Anyone who has had the pleasure of dealing with custom resource definitions (CRDs), third-party operators, and Kubernetes' various storage and networking methods is likely to lose faith in the service really making anything easier – especially when the format in which Kubernetes accepts resource definitions with kubectl is not particularly intuitive or easy to penetrate. Instead of being enthusiastic about containers, many administrators feel frustrated after their first attempts at using K8s.

Enter Acorn, a tool that acts as a layer between Kubernetes and the user, replacing much of the complexity of Kubernetes with sensible defaults. The idea is that administrators will have a sense of achievement within a very short time, such as being able to run an NGINX instance that takes less than a minute to start. For this purpose, Acorn comes with a kind of internal build system and supports special containers and integration with external tools. Of course, the developers of the solution also make liberal use of typical buzz phrases like "secure by design," which begs the question: Is Acorn really the philosopher's stone when it comes to Kubernetes usability, or does the marketing material for the product promise more than the software itself delivers? In this article, I introduce Acorn in detail and take a closer look at the solution.

Packaging and Deployment

Francis Bacon postulated that to really know something is to know its causes, and in the context of Acorn, this insight proves true once again because to understand Acorn, you should block out the blah-blah from the marketing departments and first look at what Acorn seeks to be. In this way, you can see what end users and administrators can and cannot expect from the software. In its own documentation, Acorn describes itself as a tool for packaging and deploying applications that aims to ease significantly the task of running apps on K8s. A look behind the scenes shows how this is supposed to work.

Acorn is doing something that, at first glance, seems diametrically opposed to the goals of the tool: It adds an extra layer of abstraction (i.e., more complexity). However, it is precisely this layer that contains the secret ingredients of the solution. Acorn is inventing a kind of new declaration language that claims to be far more intuitive to use than that of Kubernetes itself. An example can help you understand.

Listing 1 contains an Acornfile (think Dockerfile) that starts an Nginx container with a simple index.html. The resulting container is named web in Kubernetes and can be accessed on port 80. It contains a modified file in /usr/share/ and defines its content as My First Acorn!. If you then navigate to the IP address of the container on port 80, the welcome message is waiting for you there.

containers: {
 web: {
  image: "nginx"
  ports: publish: "80/http"
  files: {
   // Simple index.html file
   "/usr/share/nginx/html/index.html": "<h1>My First Acorn!</h1>"
  }
 }
}

To start the container as described, you just need to have the Acornfile in a folder and call

acorn build .

The rest happens automatically in the background. Of course, this also means that virtual infrastructure definitions in Acorn can be managed excellently in Git. The solution also enables Infrastructure as Code with a relatively easy implementation.

Preparation Is Essential

At this point, practiced Kubernetes users may be wondering how Acorn even knows to which Kubernetes cluster to talk and where it gets the login credentials. You need to complete a separate step before the first build command: acorn install. For the command to work, the user executing it must have Kubernetes administrator privileges in Kubernetes' role-based access control (RBAC). These rights must also be available via the environment variable in the current command-line session. Basically, the same precautions should be taken for calling acorn as for calling kubectl at the same location. If this condition is met, Acorn creates the resources it needs in K8s after the install command is called and can then be used as described.

However, this assumes that the Kubernetes cluster meets two conditions. First, the implementation of persistent storage in Acorn is decidedly rudimentary. The program relies on Kubernetes to provide it with persistent volumes when it requests them. For this to work, however, a default storage class must be defined in Kubernetes, because otherwise an Acorn request would come to nothing. Most off-the-shelf Kubernetes distributions define a default storage class, so you should have no issues here. However, if an acorn build fails because of a storage error, the probability is high that it is because of the missing default class for volumes.

The second condition is that for Acorn as an endpoint to expose services directly to the outside world through the Kubernetes API, you must have specified at least one ingress controller that Acorn can use to define the service accordingly. Moreover, this ingress controller must meet all the requirements for creating resources of the LoadBalancer type for non-HTTP endpoints. This condition is not quite as strict as the first, because even without it, an Acorn container can theoretically be run in Kubernetes. Practically, however, the services published in Acorn would not then be accessible from the outside.

What sounds rather clumsy in theory is not typically a problem in practice. Again, almost all Kubernetes distributions established on the market have the necessary prerequisites. In their documentation, the Acorn developers list various Kubernetes distributions and provide guidance on how to modify the factory configuration to make Acorn run smoothly [1].

TLS Support Out of the Box

The example with the simple HTML file shown previously is admittedly not a very practical example for workloads as usually run in Kubernetes. Even this simple example already exposes a problem that should have been noticed immediately by the people responsible for security: It opens up HTTP port 80 and delivers pages without encryption, which is absolutely mandatory for the vast majority of web-based services.

Encryption is not so easy to include in Kubernetes. Either you store the SSL keys and certificates in the version control system and then battle with storage solutions for passwords and secrets and somehow integrate them into the CI/CD process, or you opt for the Let's Encrypt solution, which is now favored in many places. The correct implementation in Kubernetes might not be an obstacle for a professional, but if you are not totally familiar with the processes and service types in Kubernetes, you might start to despair at this point.

Acorn offers its first real demonstration of power now. If you enter the command

# acorn install \
  --lets-encrypt enabled \
  --lets-encrypt-tos-agree=true \
  --lets-encrypt-email <address>

Acorn installs all the services required for Let's Encrypt in the target cluster. If you roll out an application with Acorn afterward, you just need to change the endpoint of the application to 443/https in the Acornfile. During deployment, Acorn then not only generates a dynamic hostname according to the domain preset in the cluster, but also the matching SSL certificate, which Acorn also stores directly in the load balancer for the ingress driver (Figure 2). All told, this is likely to make Acorn a solution that offers the fastest path for developers to create a technically correct, dynamically encrypted endpoint in Kubernetes.

Figure 2: Acorn combines simple and complex Kubernetes functions and has some hugely impressive features under its belt, including completely automatic integration of Let's Encrypt.