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.
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.
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.
--- applications: - name: mywordpress memory: 128M path: . buildpack: https://github.com/cloudfoundry/php-buildpack host: wordpress-on services: - mysql-db env: SSH_HOST: [email protected] 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
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.
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
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
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.