Kubernetes configuration files are long and verbose. When defining an application you may regularly define a deployment, service, ingress controller, DNS, and configuration. Within those configuration files there will be a fair amount of boilerplate and numerous repeated values.

It may come as no surprise that numerous projects are popping up to simplify the configuration for an application. Kedge, PsyKube, and Helm are just a few of the options being used.

At the crux of this is application developer and application operator user experience. To understand why these projects are popping up let’s take a look at the people, expectations, and what they are doing.

Simple Expectations

Application developers have been spoiled with simple experiences. Heroku, Cloud Foundry, and others have set an example of how you one can describe their application in a simple form and deploy it to a platform.

To understand this it’s worth looking at the Cloud Foundry manifest.yaml file. Here’s a simple example for a Wordpress site:

---
applications:
- name: mywordpress
  memory: 128M 
  path: .
  buildpack: https://github.com/cloudfoundry/php-buildpack
  host: wordpress-on
  services:
  - mysql-db
  env:
    SSH_HOST: user@your-ssh-server
    SSH_PATH: /full/or/relative/path/on/ssh/server
    SSH_KEY_NAME: sshfs_rsa
    SSH_OPTS: '["cache=yes", "kernel_cache", "compression=no", "large_read"]'

To create this same thing for Kubernetes you would typically have hundreds of lines of YAML.

The Difference Between PaaS and IaaS

It’s worth noting that Kubernetes is different from a Platform as a Service (PaaS). Kubernetes is closer to an Infrastructure as a Service (IaaS). A PaaS does a fair amount of work for developers to transform their applications into something that can run and then operates them.

What we’re talking about here is not what they do but rather how people interact with the systems.

It’s About User Experience

Jakob Nielsen noted that,

Useful = usability + utility

Both a PaaS and an IaaS have utility. To be useful, especially to the masses, usability needs to be part of the equation.

Nielson also noted,

Usability is defined by 5 quality components:

• Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
• Efficiency: Once users have learned the design, how quickly can they perform tasks?
• Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
• Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
• Satisfaction: How pleasant is it to use the design?

Kedge, PsyKube, and Helm are examples of projects working to improve the usability of Kubernetes for the masses.

A Helm Example

Recently a number of people ran into some trouble installing the Wordpress community stable chart for Helm with working TLS. Michael Venezia, my cohort on the Samsung CNCT, recently came up with a solution that easily works for TLS, non-TLS, and is simple.

In the values.yaml file you can put the following in:

ingress:
  enabled: true
  hosts:
  - name: wordpress.local
    tls: true
    tlsSecret: wordpress.local-tls

This configuration can handle multiple host names and the case of no TLS (just remove the tls and tlsSecret lines). The secret can be set outside of the Chart and application. But, you can optionally set the secret with the following in the values.yaml file:

  secrets:
  - name: wordpress.local-tls
    key: -----BEGIN RSA PRIVATE KEY----- ...
    certificate: -----BEGIN CERTIFICATE----- ...

This simple configuration is turned into the appropriate Kubernertes configuration. Kubernetes complexity is turned into simplicity.

Helm and Charts aren’t the only projects working on simplicity. It’s currently a common theme in the community.