Chapter 11. Extending Kubernetes with OCP, CoreOS, and Tectonic

The first half of this chapter will cover how open standards encourage a diverse ecosystem of container implementations. We'll look at the Open Container Initiative (OCI) and its mission to provide an open container specification as well. The second half of this chapter will cover CoreOS and its advantages as a host OS, including performance and support for various container implementations. Also, we'll take a brief look at the Tectonic enterprise offering from CoreOS.

This chapter will discuss the following topics:

• Why standards matter?
• The Open Container Initiative and Cloud Native Computing Foundation
• Container specifications versus implementations
• CoreOS and its advantages
• Tectonic

The importance of standards

Over the past two years, containerization technology has had a tremendous growth in popularity. While Docker has been at the center of this ecosystem, there is an increased number of players in the container space. There is already a number of alternatives to the containerization and Docker implementation itself (rkt, Garden, and so on). In addition, there is a rich ecosystem of third-party tools that enhance and compliment your container infrastructure. Kubernetes lands squarely on the orchestration side of this ecosystem, but the bottom line is that all these tools form the basis to build cloud-native applications.

As we mentioned at the very beginning of the book, one of the most attractive things about containers is their ability to package our application for deployment across various environment tiers (that is, development, testing, and production) and various infrastructure providers (GCP, AWS, On-premise, and so on).

To truly support this type of deployment...

The Open Container Initiative

One of the first initiatives to gain widespread industry engagement is the OCI. Among the 36 industry collaborators are Docker, Red Hat, VMware, IBM, Google, and AWS, and they are listed on the OCI website at:

https://www.opencontainers.org/.

The purpose of the OCI is to split implementations, such as Docker and rkt, from a standard specification for the format and runtime of containerized workloads. By their own terms, the goal of the OCI specification has three basic tenets(you can refer to more details about this in point 1 in the References section at the end of the chapter):

• Creating a formal specification for container image formats and runtime, which will allow a compliant container to be portable across all major, compliant operating systems and platforms without artificial technical barriers.

• Accepting, maintaining, and advancing the projects associated with these standards (the Projects). It will look to agree on a standard set of container actions (start...

Cloud Native Computing Foundation

A second initiative that also has a widespread industry acceptance is the Cloud Native Computing Foundation (CNCF). While still focused on containerized workloads, the CNCF operates a bit higher up the stack at an application design level. The purpose is to provide a standard set of tools and technologies to build, operate, and orchestrate cloud-native application stacks. Cloud has given us access to a variety of new technologies and practices that can improve and evolve our classic software designs. This is also particularly focused at the new paradigm of microservice-oriented development.

As a founding participant in CNCF, Google has donated the Kubernetes open-source project as the first step. The goal will be to increase interoperability in the ecosystem and support better integration with projects. CNCF is already hosting a variety of projects in orchestration, logging, monitoring, tracing, and application resiliency.

Note

For more information on CNCF...

Standard container specification

A core result of the OCI effort is the creation and development of the overarching container specification. The specification has five core principles for all containers to follow, which I will briefly paraphrase (you can refer to more details about this in point 2 in the References section at the end of the chapter):

• The container must have standard operations to create, start, and stop containers across all implementations.
• The container must be content-agnostic, which means that type of application inside the container does not alter the standard operations or publishing of the container itself.
• The container must be infrastructure-agnostic as well. Portability is paramount; therefore, the containers must be able to operate just as easily in GCE as in your company's datacenter or on a developer's laptop.
• A container must also be designed for automation, which allows us to automate across the build, updating, and deployment pipelines. While this rule is a bit...

CoreOS

While the specifications provide us a common ground, there are also some trends evolving around the choice of OS for our containers. There are several tailor-fit OSes that are being developed specifically to run container workloads. Although implementations vary, they all have similar characteristics. Focus on a slim installation base, atomic OS updating, and signed applications for efficient and secure operations.

One OS that is gaining popularity is CoreOS. CoreOS offers major benefits for both security and resource utilization. It provides resource utilization by removing package dependencies completely from the picture. Instead, CoreOS runs all applications and services in containers. By providing only a small set of services required to support running containers and bypassing the need of hypervisor usage, CoreOS lets us use a larger portion of the resource pool to run our containerized applications. This allows users to gain a higher performance from their infrastructure and...

Kubernetes with CoreOS

Now that we understand the benefits, let's take a look at a Kubernetes cluster using CoreOS. The documentation supports a number of platforms, but one of the easiest to spin up is AWS with the CoreOS CloudFormation and CLI scripts.

Note

If you are interested in running Kubernetes with CoreOS on other platforms, you can find more details in the CoreOS documentation athttps://coreos.com/kubernetes/docs/latest/.https://coreos.com/kubernetes/docs/latest/We can find the latest instructions for AWS at https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html.

You can follow the instructions mentioned earlier to spin-up Kubernetes on CoreOS. You'll need to create a key pair on AWS and also specify a region, cluster name, cluster size, and DNS to proceed.

In addition, we will need to create a DNS entry and will require a service such as Route53 or a production DNS service. When following the instructions, you'll want to set the DNS to a domain or sub-domain, where you have...

Tectonic

Running Kubernetes on CoreOS is a great start, but you may find that you want a higher level of support. Enter Tectonic, the CoreOS enterprise offering for running Kubernetes with CoreOS. Tectonic uses many of the components we already discussed. CoreOS is the OS and both Docker and rkt runtimes are supported. In addition, Kubernetes, etcd, and flannel are packaged together to give a full stack of cluster orchestration. We discussed flannel briefly in Chapter 3, Networking, Load Balancers, and Ingress. It is an overlay network that uses a model similar to the native Kubernetes model, and it uses etcd as a backend.

Offering a support package similar to Red Hat, CoreOS also provides 24x7 support for the open-source software that Tectonic is built on. Tectonic also provides regular cluster updates and a nice dashboard with views for all the components of Kubernetes. CoreUpdate allows users to have more control of the automatic updates. In addition, it ships with modules for monitoring...

Summary

In this chapter, we looked at the emerging standards bodies in the container community and how they are shaping the technology for the better with open specifications. We also took a closer look at CoreOS, a key player in both the container and the Kubernetes community. We explored the technology they are developing to enhance and compliment container orchestration and saw first-hand how to use some of it with Kubernetes. Finally, we looked at the supported enterprise offering of Tectonic and some of the features that are available now.

In the next chapter, which is the last one, we will explore the broader Kubernetes ecosystem and the tools available to move your cluster from development and testing into full blown production.

References

1. https://www.opencontainers.org/faq/ (Under How broad is the mission of the OCI?)
2. https://github.com/opencontainers/specs/blob/master/principles.md