Kubernetes is a completely resource-centric container orchestration platform, which is evident from the design of the REST API exposed by kube-apiserver, and the ecosystem of Kubernetes revolves around the control and maintenance of many component resources, so it can be considered as a “resource control system” in essence.

Group / Version / Resource

For the concept of resource, if in a large and complex container orchestration platform designed only such a simple “resource” semantics is obviously a bit thin, or expression is too weak, so for such a concept of resources, in Kubernetes and grouped and versioned words, so there are some terms we usually see in operations and development: Group / Version / Resource / Kind, respectively: Resource Group / Resource Version / Resource / Resource Type.

The relationship between them is as follows.

  • The Kubernetes system supports multiple Groups (Resource Groups).
  • Each Group supports multiple Resource versions (Versions).
  • Each resource version in turn supports multiple resources (Resource), some of which also have their own subresources.
  • Kind and Resource belong to the same level concept, and Kind is used to describe the kind of Resource.

The complete form of locating a resource is as follows.

1

<GROUP>/<VERSION>/<RESOURCE>[/<SUBSOURCE>]

Deployment for example: apps/v1/deployments/status

In Kubernetes, there is another concept of describing resources called “Resource Object”, which is described as follows.

1

<GROUP>/<VERSION>, Kind=<RESOURCE_NAME>

Take Deployment as an example: apps/v1, Kind=Deployment

Some basic features of the resource concept:

  • Each resource has a certain number of operation methods, called Verbs, such as create / delete / update / get / list / watch … (8 types).
  • Each resource has at least two Versions, including an external version for user requests, and an internal version for use within the api-server.
  • Kubernetes resources as a whole are divided into Built-In Resources and Custom Resources, where CR is implemented through CRD Custom Resource Definition.

Group

Resource groups, also known as APIGroups in Kubenetes API Server, have the following characteristics.

  • Resource groups are divided based on the functionality of resources.
  • Support for having different resource versions in different resource groups, thus facilitating the iterative upgrade of resources within the group.
  • Support for Resource with the same name Kind in different Groups.
  • Support for extending custom resources via CRD.
  • Ability to use kubectl commands for resource interaction without specifying a Group.

Group with group name and Group without group name

There is also a difference in the way HTTP requests are made between Groups with group names and Core Groups without group names (e.g. v1/pods).

1
2

Have group name Group resources: .../apis/<GROUP>/<VERSION>/<RESOURCE>
No group name Group resources: .../api/<VERSION>/<RESOURCE>

Version

Kubernetes uses semantic version numbers for resource versions. The version number starts with v and is followed by the test phase of the version (Alpha -> Beta -> Stable), e.g. v1alpha1, v1beta1, v2stable1.

The status of each testing phase of the version is as follows.

  • Alpha stage: internal test version, there are many defects and bugs, the version is extremely unstable, the official may give up supporting this version at any time, only for developers’ test use, the features in the Alpha version will be disabled by default. Common naming schemes such as v1alpha1.
  • Beta stage: relatively stable version, tested by the official and community, the version will change slightly when iterating, but will not be as unstable as the Alpha version, the features under the Beta stage are enabled by default. Common naming schemes such as v2beta1.
  • Stable stage: official release version, stable version of the function, basically formed a product, all features are turned on by default, naming method generally does not add stable, directly v1, v2 such.

Resource

Resource is a core concept in Kubernetes, and the essence of Kubernetes is to manage, schedule, and maintain the various Resources under it.

  • A Resource instantiated as a Resource Object.
  • All Resource Objects in Kubernetes are called Entity.
  • A Resource Object can be manipulated through the Kubenetes API Server.

Kubernetes currently classifies Entities into two main categories.

  • Persistent Entity: i.e. Resource Object persists after creation, the vast majority are PEs, e.g. Deployment / Service.
  • Ephemeral Entity: transient entities, where the Resource Object is unstable after creation and is not rebuilt after a failure / scheduling failure, e.g. Pods.

Resource manipulation methods

Although at the Etcd level, operations on resources are eventually converted to basic operations such as add, delete, change, and watch, Kubernetes abstracts to the resource level and gives resources more operation methods, which are called “Verbs” as mentioned before, namely create / delete / deletecollection / patch / update / get / list / watch. update / get / list / watch, we can still put them into four categories: add, delete, change, and check.

  • add
    • create: Resource Object creation
  • delete
    • delete: single Resource Object delete
    • deletecollection: multiple Resource Objects deleted
  • change
    • patch: Resource Object partial field update
    • update: Resource Object overall update
  • check
    • get: Single Resource Object get
    • list: Multiple Resource Objects get
    • watch: Resource Objects monitoring

Resource and Namespace

Kubernetes also supports the concept of Namespace, which addresses the complexity of managing too many Resource Objects.

Namespaces have several features.

  • Each Namespace can be treated as a “virtual cluster”, meaning that isolation can be achieved between different Namespaces.
  • Cross-Namespace communication between different Namespaces is possible.
  • Access rights to different Namespaces can be configured for different users.

So we know that Namespace can achieve resource isolation and cross Namespace communication at the same time, which is a very flexible concept that can play an important role in many scenarios, such as multi-tenancy implementation, isolation of production/test/development environments, etc.

Resource Manifest File Resource Object Description File

Whether it is a built-in resource in Kubernetes or a Custom Resource defined through CRD, the creation of a Resource Object is done through a Resource Object Description File.

Manifest File in Kubernetes can be defined in two formats: YAML and JSON.

Regardless of the format, the fields of the Manifest File have a fixed meaning.

  • apiVersion: Note that APIVersion here actually refers to APIGroup/APIVersion, such as Deployment can be written as apps/v1, while for Pod, since it belongs to Core Group, i.e. no-name Group, so omit Group and write as v1 that is.
  • kind: the kind of Resource Object.
  • metadata: metadata information of the Resource Object, commonly used include name / namespace / labels.
  • spec: Desired status of the Resource Object (Desired Status)
  • status: the actual status of the Resource Object (Actual Status)