Kubernetes – 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 increasing number of players in the container space. There are 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 complement your container infrastructure. While Kubernetes is designed to manage the state of a container and the orchestration, scheduling, and networking side of this ecosystem, the bottom line is that all of these tools form the basis to build cloud-native applications.

As we mentioned at the very beginning of this 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-premises, and so on).

To truly support this type of deployment agility, we need not only the containers themselves to have a common platform, but also the underlying specifications to follow a common set of ground rules. This will allow for implementations that are both flexible and highly specialized. For example, some workloads may need to be run on a highly secure implementation. To provide this, the implementation will have to make more intentional decisions about some aspects of the implementation. In either case, we will have more agility and freedom if our containers are built on some common structures that all implementations agree on and support.

In the following pages, we’ll explore the building blocks of the many competing standards in the Kubernetes ecosystem. We’ll explain how they’re changing and developing and what part they may play in the future.

One of the examples that we’ll explore more deeply in this third edition is the CRI-O project, which came to be after the creation of the OCI Charter. Let’s make sure we understand the importance of that mission.

The OCI Charter

The mission of the OCI Charter is to ensure that the open source community has a stable platform from which industry participants can contribute the portable, open, and vendor-neutral runtimes required to build container-powered applications. The Linux Foundation is the holder of the charter, which is a sister organization to the CNCF. We’ll look more into the implications of a foundation in Chapter 11, Kubernetes SIGs, Incubation Projects, and the CNCF.

If you’d like to read more about these foundations, you can check out their websites here: https://www.linuxfoundation.org/ and https://www.cncf.io/.

While the OCI Charter tries to standardize the building blocks of the ecosystem, it does not attempt to define the system at the macroscopic level, nor does it market a particular pathway or solution. There’s also a process defined that helps technology mature in a responsible way through these foundations, to ensure that the best possible technology is reaching the end user. These are defined as the following stages:

  1. Sandbox
  2. Incubating
  3. Graduated

For the specifics of this chapter as regards the OCI, let’s look at what else they’re trying to accomplish. Firstly, we’re attempting to create a format specification. This specification will call out a few important dimensions in order to create a consensus:

  • Provide a format: In order to ensure a specification that can be used across multiple runtimes, you need a standard container format and runtime specification. The container format is represented by the root filesystem that sits on the disk, with the necessary additional configuration that allows a given container to be run on the system. There is a push to categorize the standardization into the following layers: base, optional, and out of scope.
  • Provide a runtime: This is more straightforward, as it’s designed to provide an executable that can directly run a container via consumption of the aforementioned container format and runtime specification.

The Charter also incentivizes a number of projects, the first two of which are the runc projects, and the third of which involves the definition of its own specifications in the OCI Specification project. New projects are added by members through a review process that needs two-thirds approval from the current Technical Oversight Board (TOB). If we look deeper into the principles that govern the OCI, the website names six guiding principles:

  • Technology leadership
  • Influence through contribution
  • Limited scope, limited politics
  • Minimalist structure
  • Representative leadership
  • Adherence to anti-trust regulations

These items are a blend of philosophical and logical frameworks that encourage competition, collaboration, meritocracy, and the continuous improvement cycles that many Agile and DevOps practitioners have long utilized.

Let’s dig more into the initiative itself now.

Comments are closed.