CoreOS Fest 2017 Overview

I attended CoreOS Fest 2017 held at the beautiful Pier 27 in San Francisco from May 31– June 2. This was my first time attending as well as presenting and the caliber of engineering talent was impressive. The conference started with a keynote from CoreOS CEO Alex Polvi where he introduced the theme and main technology focus of the conference — Kubernetes with a emphasis on Tectonic. The main point he made, building stuff is fun but it is a lot of hard work! I tend to agree with this to a point; as technologists we love to build, but we always need to ask the question: “Is what I am building setting my company apart?” sometimes not having to build is great but other times the use case is so specific that building provides the greatest value and is the only option.

Customer Panel (Starbucks, Concur and Ticketmaster)

I really enjoy conferences where customers come on stage especially if they give context to the issues and battles they had to get a technology deployed. “The truth is out there!” Starbucks, Concur and Ticketmaster did a great job of representing their independent companies. They all talked about deploying Kubernetes in the business and the adoption of container technologies that was the driving force behind what drove the need for a orchastrator. An interesting question to the panel “Mesos vs. Kubernetes” came up and as I have heard before the size of community behind Kubernetes is what drove most of the choice in this realm. One thing that was disappointing and what I was hoping to get more information on was the size of deployments done with Tectonic\Kubernetes. What I got from most of the customers is that they are running POC, Test, Dev and very small production clusters, I would love to hear “We are running a 4000 node cluster in production and here are the issues, problems and wins we had.”


In a nutshell Tectonic is packaged version of Kubernetes with some benefits.

Tectonic provides the most current release of Kubernetes with an installer, a UI, Operators, LDAP Auth., Monitoring and Support. I quickly checked out the Console and it looks polished with a great amount of help to get things going and do day to day operations.

 There are a number of Installers available today, split between graphical and Terraform. Terraform seems like a very good choice for what CoreOS is trying to do here, support multiple cloud deployment including OpenStack. My only concern with Terraform up to now is feature parity, something that probably warrants another post. Both AWS and bare metal installers are supported, the Azure installer is in alpha, and the OpenStack installer is in pre-alpha. If you are interested in playing around with these installers, more information can be found here:

 A Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks, current Operators are etcd Operator and the Prometheus Operator)

LDAP Auth.
 Tectonic Identity is an authentication service for both Tectonic Console and kubectl. It facilitates communication to the API server on the end user's behalf. All Tectonic clusters enable Role Based Access Control (RBAC). Tectonic Identity can be mapped to an LDAP service ensuring RBAC role bindings for groups and users map to your exiting LDAP system. Doing some research around the topic of LDAP and Kubernetes I found another project from Apprenda that includes LDAP authentication both looks interesting and perhaps worth testing.

 Tectonic uses Prometheus monitoring for Tectonic. CoreOS is adding to the Prometheus codebase and will provide enhancements to Kubernetes integration as well as work toward establishing best practices and standards for monitoring and metrics formats.

 CoreOS provides the following support for Tectonic:

Support Levels
 Business Day or 24/7 Support
 Bare Metal, AWS

I am sure we will see more support levels come for Azure and OpenStack as the installers move to GA.


Another technology that caught my attention at the conference is Matchbox. An early level provisioning system it PXE boots machines and applies a profile. Once the machine boots Ignition data can be applied to fully configure the machine. What I really like about these “light IaaS” systems is that they are the start to enable true immutable infrastructure. I am interested to see where this project goes; we have been doing work in a similar project called RackHD ( that adds some lower level functionality like firmware management and the ability to create workflows, a tool that handles these lower level functions well becomes a key piece in building an effective private cloud.


Draft has been making waves at a couple of conferences I attended this year, and I can understand why. Draft enables developers to develop code without the need to worry about containerizing and deploying said code to an orchestrator. Draft builds upon Kubernetes Helm and the Kubernetes Chart format, making it easy to construct CI pipelines from Draft-enabled applications.The idea here is a three step process:

  1. draft create to containerize your application based on Draft packs
  2. draft up to deploy your application to a Kubernetes dev sandbox, accessible via a public URL
  3. Use a local editor to modify the application, with changes deployed to Kubernetes in seconds

Once you feel good about your code commit at which point CI/CD takes over. For those who are wondering, Draft Packs allows a user to bootstrap an application from a defined starter pack and consist of a Dockerfile and a Helm Chart ( something I discuss more when I cover Helm) that demonstrates best practices for an application of a given language pack. Here is an example:

Draft is an open source project build by the Microsoft Azure team.


I got to play with Helm a little bit after a Kubernetes hackathon we did with our Romanian team. This is a tool I would like to work with a lot more since I feel it will become a fundamental cornerstone of Kubernetes and the way we deploy applications to the orchestrator. In short Helm manages Kubernetes Charts, Charts are packages of pre-configured Kubernetes resources. This becomes a repo of sorts of apps you can deploy on Kubernetes. You can find popular applications that have been defined in Helm ( or you can create your own. Charts are written in YAML.

A example can be seen here:

Helm consists of two parts, a client (helm) and a server component (tiller) that runs on the Kubernetes cluster. The quick start guide on Helm can be found here:


As I mentioned I had the great privilege of presenting at CoreOS Fest this year. It is always amazing to realize how many talented people come to these conferences and when they take their time to listen to me I am indeed humbled. My talk can be viewed here:

Final Thoughts

I always enjoy going to smaller conferences, it just feels like the level on interaction with people that are truly passionate about their work is higher. Hopefully I will be able to make it back next year but for now more exploration into the wonderful world of Kubernetes.