Is there a specification of what Kubernetes is the implementation of?

p.theml · August 25, 2021, 5:53pm

Hello,
I was wondering: Is there a specification of what Kubernetes is the implementation of?

The API to low-level container runtimes is specified by the OCI. An implementation for this also comes from the OCI, runc. There are also other implementations that follow the specification. Another example is crun. This means that the API specifies what low-level container runtimes must be able to do. But the implementation is separate from the specification that runc follows.
The API to high-level container runtimes is specified with the CRI. For example, containerd and CRI-O implement this specification and therefore it is also given what the high-level container runtimes must be able to do if they want to follow the CRI specification. Again, the specification is developed separately from the implementation.

Is there also a “product-independent” specification for Kubernetes?
I found the OpenAPI spec, but that is part of the application and not a “product independent” specification. (kubernetes/api/openapi-spec at master · kubernetes/kubernetes · GitHub)
I also found the Conformance Tests, but this is not a formal document as it is a specification. (GitHub - cncf/k8s-conformance: 🧪CNCF K8s Conformance Working Group)

I didn’t find a “product independent” specification, which suggests that Kubernetes proclaims itself as an industry standard and equates its documentation to a specification.

To me, the difference between specification and implementation is the place of definition of the thing. If a thing defines itself it is not a specification. Then it is a way of solving a problem that is accepted by all. If there is a generic definition of the behaviour and different approaches to a solution can arise from it, it is a specification.

I hope someone can help me with my question.
With kind regards
Pascal Theml

devkulkarni · August 26, 2021, 3:52pm

For what reason are you looking for a specification? Are you planning to run model checkers against it? Given the very broad and evolving API surface in Kubernetes, I don’t think there has been any conscious efforts to define a formal specification for various K8s abstractions. There are design documents that capture the APIs and different approaches for implementation. These are part of Kubernetes Enhancement Proposals (KEPs). You can find the KEPs in this repo: enhancements/keps at master · kubernetes/enhancements · GitHub
You can look through that to understand the level of details that are usually captured when adding a new API/abstraction to K8s. In case you want to define formal specification in some kind of language (Z, VDM), you can start with one of the well-known abstractions (say, Deployment), go through its KEP and try to model the behavior outlined in the KEP.

p.theml · September 2, 2021, 7:04am

I am currently writing my bachelor thesis. In researching containers, I found specifications and also implementations that follow these specifications. OCI → runc, CNI → Refernce Plugins, … but what about Kubernetes?
I am looking for a formal specification for Kubernetes.

Thanks for your link to the KEPs, I didn’t know them yet. But I don’t think that’s a formal specification. Do you have another approach to find a specification or can you explain to me if KEPs could serve as a specification after all.

protosam · September 2, 2021, 1:00pm

Pretty much this. As far as I’m aware there is no agreed upon formal definition for what Kubernetes is like you have with it’s lower level components.

Kubernetes is the application that is subject to change. Similar to the Linux kernel.

charlieok · September 2, 2021, 3:49pm

I think you’ll find the general pattern is that early implementations in some area come first. Then, people start wanting standardization, so they form working groups to write specifications. To use one of your examples, Docker broke new ground, then people wanted standards for containers, and the Open Container Initiative formed.

Hopefully this makes some intuitive sense. It’s difficult to write standards for some new thing that is still in flux and is not yet widely understood (though it is attempted all the time!).

All that said, it seems worth mentioning the Kubernetes Resource Model as an example of adding some definition to just what it is that Kubernetes is implementing at its core.

github.com

kubernetes/community/blob/master/contributors/design-proposals/architecture/resource-management.md

# The Kubernetes Resource Model (KRM)

> This article was authored by Brian Grant (bgrant0607) on 2/20/2018. The original Google Doc can be found [here](https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRfGejw-qlKQIuLKQWlwzs/edit#).

Kubernetes is not just API-driven, but is *API-centric*.

At the center of the Kubernetes control plane is the [apiserver](https://kubernetes.io/docs/admin/kube-apiserver/), which implements common functionality for all of the system’s APIs. Both user clients and components implementing the business logic of Kubernetes, called controllers, interact with the same APIs. The APIs are REST-like, supporting primarily CRUD operations on (mostly) persistent resources. All persistent cluster state is stored in one or more instances of the [etcd](https://github.com/coreos/etcd) key-value store.

![apiserver](./images/apiserver.png)

With the growth in functionality over the past four years, the number of built-in APIs grown by more than an order of magnitude. Moreover, Kubernetes now supports multiple API extension mechanisms that are not only used to add new functionality to Kubernetes itself, but provide frameworks for constructing an ecosystem of components, such as [Operators](https://coreos.com/operators/), for managing applications, platforms, infrastructure, and other things beyond the scope of Kubernetes itself. In addition to providing an overview of the common behaviors of built-in Kubernetes API resources, this document attempts to explain the assumptions, expectations, principles, conventions, and goals of the **Kubernetes Resource Model (KRM)** so as to foster consistency and interoperability within that ecosystem as the uses of its API mechanisms and patterns expand. Any API using the same mechanisms and patterns will automatically work with any libraries and tools (e.g., CLIs, UIs, configuration, deployment, workflow) that have already integrated support for the model, which means that integrating support for N APIs implemented using the model in M tools is merely O(M) work rather than O(NM) work.

## Declarative control

In Kubernetes, declarative abstractions are primary, rather than layered on top of the system. The Kubernetes control plane is analogous to cloud-provider declarative resource-management systems (NOTE:  Kubernetes also doesn’t bake-in templating, for reasons discussed in the last section.), but presents higher-level (e.g., containerized workloads and services), portable abstractions. Imperative operations and flowchart-like workflow orchestration can be built on top of its declarative model, however.

Kubernetes supports declarative control by recording user intent as the desired state in its API resources. This enables a single API schema for each resource to serve as a declarative data model, as both a source and a target for automated components (e.g., autoscalers), and even as an intermediate representation for resource transformations prior to instantiation.

The intent is carried out by asynchronous [controllers](/contributors/devel/sig-api-machinery/controllers.md), which interact through the Kubernetes API. Controllers don’t access the state store, etcd, directly, and don’t communicate via private direct APIs. Kubernetes itself does expose some features similar to key-value stores such as etcd and [Zookeeper](https://zookeeper.apache.org/), however, in order to facilitate centralized [state and configuration management and distribution](https://sysgears.com/articles/managing-configuration-of-distributed-system-with-apache-zookeeper/) to decentralized components.

This file has been truncated. show original

Topic		Replies	Views
Why runc is vendored in k8s? General Discussions	0	461	September 12, 2021
Kubernetes.io Blog: Kubernetes v1.12: Introducing RuntimeClass General Discussions	0	647	October 13, 2018
Multiple container runtimes in a single Kubernetes cluster General Discussions	3	4126	July 21, 2021
Kubernetes.io Blog: Future of CRDs: Structural Schemas General Discussions k8s-blog	0	2014	June 20, 2019
Migrating to kubernetes version with containerd instead of docker as a container runtime General Discussions	2	841	June 17, 2021

Is there a specification of what Kubernetes is the implementation of?

Related topics