Design Principles

Design Concepts and Distributed Systems

Breaking down and understanding the design principles behind Kubernetes allows us to delve deeper into the Kubernetes system. It supports better usage management of cloud-native applications deployed in a distributed way. On the other hand, it can lead us to learn from their experience in the design of distributed systems.

API Design Principles

For cloud computing systems, the system API actually assumes the role of system design. For each new feature supported by the Kubernetes cluster system, or each new technology introduced, a corresponding API object will be introduced to manage the feature's operation. Understanding these APIs is like grabbing hold of the key aspects of the K8s system. The design of Kubernetes system API follows these principles:

1. All APIs should be declarative. Declarative operations, compared to the imperative ones, have a steady effect on repeated operations, which is essential in a distributed environment where data loss or duplication is common. Moreover, declarative operations are easier for users to use. They allow the system to hide implementation details from the user while retaining the system's potential for continuous optimization. Also, the declarative API implies that all API objects are nouns like Service, Volume. These descriptive words represent the target object that the user expects to achieve.

2. API objects should be complementary and combinable. This encourages API objects to adhere to object-oriented design principles, achieving "high cohesion, loose coupling", breaking down business-related concepts appropriately and increasing the reusability of the decomposed objects.

3. High-level APIs are built on operational intentions. Good API design parallels good application system design using object-oriented methods; high-level design should be business-driven, not technological implementation driven. Therefore, the design of Kubernetes' high-level APIs is based on the operation and management of system scheduling containers.

4. Low-level APIs are designed according to the control needs of high-level APIs. The aim of designing and implementing low-level APIs is their use by high-level APIs. The design of low-level APIs should be based on demand, and be able to resist the temptation of technical execution.

5. Avoid simple encapsulation and do not rely on internal hidden mechanisms unknowable through the external API. Simple encapsulation does not necessarily provide new functionality but increases the dependability of the encapsulated API. Internal hidden mechanisms are detrimental to system maintenance. For instance, StatefulSet and ReplicaSet, which are two sets of Pods, are defined by Kubernetes using different API objects, not by distinguishing different types of ReplicaSet with a special internal algorithm.

6. API operation complexity should be proportional to the number of objects. This point is mainly considered from the system performance - to ensure that as the system size expands, the performance doesn't slow down rapidly. A minimum constraint is that an API's operational complexity should not exceed O(N), where N is the number of objects; otherwise, the system will not be scalable.

7. The status of an API object should not depend on the network connection status. It is well known that in a distributed environment, network disconnections are frequently occurring. Therefore, to ensure that the API object's state can accommodate network instability, the object's state must not rely on network connection status.