Container no-brainer? Tectonic combines CoreOS stack & Kubernetes for the enterprise

Enterprises interested in leveraging Google-esque infrastructure with containers may be interested in Tectonic, “the commercial Kubernetes platform” that combines the CoreOS open-source stack with Kubernetes so that the enterprise can run containers much the same way that Google does. “Based on some of our experiences working there, we can define Google’s infrastructure and we know that you have to have an OS that looks like the one we ship, which is designed for containers,” says Kelsey Hightower, Product Manager / Chief Advocate, CoreOS.

How Tectonic Works

Instead of using configuration managers such as Chef or Puppet to deploy applications to specific machines, Tectonic uses Kubernetes to deploy applications across server clusters in a distributed fashion. Enterprises connect to Kubernetes via APIs to use it as their global cluster scheduler for application deployment, says Hightower.

To store cluster data, CoreOS designed and built an open-source database technology called etcd, which is a lot like Google’s database, Chubby, which the search titan uses internally. Kubernetes interacts with etcd for cluster data storage and retrieval. “When Google set out to do Kubernetes, they selected etcd because it is similar to Chubby and it was already on the market as an open-source tool,” says Hightower. Rather than having the purpose of maintaining large amounts of data, etcd intends to store data in an extremely consistent fashion so that Kubernetes can quickly and easily work with cluster configuration data.

Enterprises also need their container technology to communicate among and between the servers in a cluster even as the cluster scales up or down in size. To make this possible, CoreOS designed and built Flannel, which is a tool that enables the enterprise to add an overlay network capability for this purpose. This is basically an SDN that the enterprise can configure in order to add and remove machines and then reprogram the resulting network of machines dynamically.

So that enterprises can keep the containers that their developers create behind the corporate firewall, CoreOS has the CoreOS Enterprise Registry, which is an on-premise version of the hosted solution, “Enterprise Registry allows the enterprise to hook into its mature enterprise authentication backends such as Active Directory and LDAP,” says Hightower. Now the enterprise can control container access and give access only to those who should have it, to move containers around inside the secure haven of the enterprise perimeter.

The next piece is the Tectonic console / user interface / dashboard to Kubernetes. The enterprise enters through this console to create and monitor their applications and to address application trouble issues. “An enterprise uses the Techtonic console to track events, partition workloads, and perform other management duties without having to log in to specific machines,” says Hightower.

To stay current, Tectonic makes it possible to perform automated upgrades and updates to all its software components. “Just as our CoreOS operating system can update itself in a manner similar to how the Google Chrome web browser updates itself, so also Tectonic can automatically update its components and the cluster,” says Hightower.

CoreOs does this by repurposing its existing updating technology. Enterprises can for example roll out new versions of Kubernetes to each computer in the cluster, in the background, machine-by-machine, to negate the downtime that can come with typical upgrade procedures.

The CoreOS component of Tectonic includes CoreOS Linux. “It’s a Linux distro with the caveat that we do a rolling release model and it can upgrade itself,” says Hightower. The next component that relates to Tectonic is Rocket, the CoreOS container runtime environment. “Rocket is compatible with all Docker images and enables the user to sign and verify images as well,” says Hightower.

The appc Spec

CoreOS supports the appc open specification so that the industry can construct images regardless of the tool / runtime and have a single, documented image format that everyone can agree on. The intention is in part to provide a common definition of what a container is and of how it is secured. This enables container developers, distributors, and enterprises to sign and verify containers so that ultimately everyone who wants to create or use a secure container can do so.

David Geer

David Geer’s work has appeared in ScientificAmerican, The Economist Technology Quarterly, CSO & CSOonline, FierceMarkets, TechTarget, InformationWeek, Computerworld,,, IEEE Computer Society’s Computer magazine, IEEE Distributed Systems Online, Government Security News, Laptop, Smart Computing, Technical Support, The Hosting Standard (Canada), (UK), SIGnature, Processor, and the Engineering News-Record. David served as a technician at CoreComm in Cleveland, OH prior venturing into writing.

David Geer has 24 posts and counting. See all posts by David Geer