Take you to the third step of advanced Kubernetes practice: Resource Management Foundation-Alibaba Cloud Developer Community

Click here to view Chapter 1: Kubernetes quick start Click here to view Chapter 2: resource management basics

chapter 3: Resource Management basis

the Kubernetes of API Server system receives and responds to client operation requests based on HTTP/HTTPS. It provides a "resource-based" RESTful-style programming interface, the components of the cluster are abstracted into standard REST resources, such as nodes, Namespace, and pods, and support resource management using JSON as the data serialization solution through standard HTTP methods. This topic describes how to manage Kubernetes resources.

3.1 resource objects and API groups

REST is the abbreviation of Representational State Transfer, which means "representing State transition". It is a program architecture style and its basic elements are resource, representation and action. A resource is an object. A resource usually means an object with attached types and associated data, supported Operation methods, and relationships with other objects. It is a state-holding object, S(State) in REST. REST components capture the current or expected state of resources by using representations and transmit the representations between components to perform operations on resources. A representation is a byte sequence consisting of data, metadata describing the data, and metadata occasionally describing the metadata (usually used to verify the integrity of the message). There are other commonly used but inaccurate names in the representation, such as documents, files, and HTTP message entities. The data format is called media type. JSON or XML is commonly used. API clients cannot directly access resources. They need to perform "actions" to change the status of resources. As a result, the status of resources changes from a form of "Transfer". Is another form. Resources can be grouped into collections. Each collection contains only a single type of resources, and the resources are disordered. Of course, resources may not belong to any set. They are called monomer resources. In fact, a collection itself is also a resource. It can be deployed at the global level, at the top of an API, or included in a resource. It is represented as a "sub-collection". The relationship among sets, resources, sub-sets and sub-resources is shown in Figure 3-1.

Figure 3-1 collection, resources, and sub-Resources

Kubernetes system abstracts everything into API resources, organizes and manages these resources and their objects in the REST architecture style, and supports standard HTTP methods (POST, PUT, PATCH, DELETE and GET) manage resources such as adding, deleting, modifying, and checking. However, in the context of Kubernetes system, "resource" is used to represent a collection of "objects". For example, Pod resources can be used to describe all Pod- type objects, however, this book will use resources, objects, and resource objects without distinction, and understand them as instance-objects generated by resource types.

3.1.1 Kubernetes resource objects

based on the main functions of resources, Kubernetes API objects can be classified into Workload (Workload), Discovery and load balancing (Discovery & LB), configuration and storage (Conf? ig & Storage, Cluster (Cluster), and Metadata (Metadata). They are basically designed around a core purpose: how to better run and enrich Pod resources, thus providing more flexible and perfect operation and management components for containerized applications, as shown in Figure 3-2.

Figure 3-2 common resource objects Kubernetes

workloads are used to ensure that Pod resource objects can run containerized applications better. Pod objects with the same load must serve each request in a load balancing manner, however, various containerized applications need to "discover" each other to complete work collaboration. Pod resources have a lifecycle. Storage resources can provide a persistent data storage mechanism for reconstructed Pod objects. Shared Pod resources with the same configuration can obtain configuration change information from configuration resources, as a configuration center, these resources provide an extremely convenient management mechanism for managing configuration files of containerized applications. Cluster Resources provide configuration interfaces for managing the working characteristics of a cluster, while metadata resources are used to configure the behavior of other resources within the cluster. (1) a workload-based resource Pod is a basic resource of a workload-based resource. It runs containers and resolves environmental dependencies. For example, inject shared or persistent volumes, configuration information, and key data into the container. However, pods may be terminated due to resource overruns or node failures. These abnormal Pod resources need to be rebuilt. However, this kind of work will be done by the workload controller, they are also called pod controllers. Applications are divided into stateless and stateful types, which have very different environment dependencies and working characteristics. Therefore, they are managed by two different types of Pod controllers, ReplicationController, replicaSet and Deployment manage stateless applications StatefulSet manage stateful applications. ReplicationController is the controller of the previous generation. Its functions are realized by ReplicaSet and Deployment, so it is almost abandoned. Some applications are unique. They need to run a single Pod resource on each node in the cluster to collect logs or run system services, the management of these Pod resources belongs to the DaemonSet controller. In addition, some containerized applications need to continue running to provide services for the daemon process, while others need to exit after normal completion, the Job controller is responsible for the control of these containerized applications that should be exited after normal completion. The following is a more detailed description of each Pod controller. ReplicationController: it is used to ensure that each Pod replica can meet the target number at any time. In other words, it is used to ensure that each container or container group is always running and accessible; it is a stateless Pod application controller of the previous generation. We recommend that you use a new controller Deployment and ReplicaSet to replace it. ReplicaSet: The only difference between a new generation of ReplicationController and ReplicationController is that it supports different tag selectors. ReplicationController only supports equivalent selectors, while ReplicaSet also supports set-based selectors. Deployment: used to manage stateless persistent applications, such as HTTP servers. It is used to provide declarative updates for pods and ReplicaSet. It is a more advanced controller built on ReplicaSet. StatefulSet: used to manage stateful persistent applications, such as database service programs. The difference between them and Deployment is that StatefulSet creates a unique persistent identifier for each Pod, and ensures the order between pods. DaemonSet: indicates that each node runs a copy of a Pod. New nodes are added to the Pod. When the node is removed, the Pod is recycled; daemonSet are often used to run cluster storage daemons, such as glusterd and ceph, and log collection processes, such as f? luentd and logstash, and monitoring processes such as Prometheus Node Exporter, collectd, Datadog agent, and Ganglia gmond. Job: used to manage applications that can be terminated after running, such as batch Job tasks. In other words, a Job creates one or more pods and ensures that they meet the target number, until the Pod ends normally. (2) discovery and load balancing Pod resources may be reconstructed due to any unexpected failure, so it needs a fixed "discovery" method. In addition, Pod resources are visible only in the cluster, and its client may also be other Pod resources in the cluster. To allow access from users in the external network, you need to expose it to the outside of the cluster in advance and balance the access traffic of the same workload. Kubernetes use standard resource objects to solve such problems. They are Service and Endpoint resources used to add discovery mechanisms and load balancing functions to workloads, you can also use layer -7 proxies to Ingress resources for traffic load balancing requests. (3) configuration and storage Docker container layer-by-layer joint mounting method determines that it is not appropriate to store data that requires persistence inside the container, so it solves such problems by introducing the method of mounting external storage volumes, kubernetes designed a Volume resource for this purpose, which supports many types of storage devices or storage systems, such as GlusterFS, CEPH RBD, and Flocker. In addition, the new version of Kubernetes supports unified Storage interfaces through standard CSI( Container Storage Interface) and extended support for more types of Storage systems. In addition, when building container applications based on images, the configuration information is baked during image production, which makes it difficult t o customize configurations for different environments. Docker uses environment variables as a solution. However, the value must be passed in when the container is started and cannot be modified at runtime. ConfigMap resources can be connected to pods in the form of environment variables or volumes, and can be shared and referenced by pods of the same type. This allows you to modify resources at one time and take effect at multiple locations ". However, this method is not suitable for storing sensitive data, such as private keys and passwords. It is another resource type Secret function. (4) cluster- level resource Pod, Deployment, Service, and Conf? Resources such as igMap belong to the namespace level and can be managed by the corresponding project administrator. However, there are still some cluster- level resources in the Kubernetes that define the configuration information of the cluster itself. They should only be operated by the cluster administrator. Cluster-level resources include the following types. Namespace: the scope of resource object names. Most objects belong to a Namespace. By default, they belong to default ". Node: the worker Node of the Kubernetes cluster. The identifier must be unique in the current cluster. Role: a namespace- level permission set consisting of rules, which can be referenced by RoleBinding. ClusterRole:Cluster-level permission set consisting of rules, which can be referenced by RoleBinding and ClusterRole Binding. RoleBinding: bind the permission in a Role to one or a group of users. The permission belongs to and can only be applied to one namespace. When binding, you can reference roles in the same namespace, you can also reference ClusterRole in a global namespace. ClusterRoleBinding: bind the permission defined in the ClusterRole to one or a group of users. It can reference ClusterRole in the global namespace and add relevant information through Subject. (5) metadata resource this kind of resource object is used to configure its behavior or characteristics for other resources within the cluster, such as the scale of HorizontalPodAutoscaler resource object that can be used to automatically scale workloads, pod template resources can be used to create prefabricated templates for pod resources, while LimitRange can set limits on the number of system resources such as CPU and memory for namespace resources. An application usually needs to be supported by multiple resources, such as using Deployment resources to manage application instances (pods) and using Conf? igMap resources Store application configurations, use Service or Ingress resources to expose services, and use Volume resources to provide external storage. The main part of this book will introduce these resource types, which are important tool components for hosting containerized applications in Kubernetes clusters.

3.1.2 resources and their organizational forms in APIs

in Kubernetes, resource objects represent persistent class entities on the system. Kubernetes use these persistent class entities to express the status of the cluster, including the nodes on which containerized applications are running, what resources are available for each application and their own behavior policies, such as restart, upgrade, and fault tolerance policies. An object may contain multiple resources. You can add, delete, modify, and query these resources. Kubernetes usually use standard RESTful terms to describe API concepts. resource type refers to the name used in the URL, such as Pod, Namespace, and Service. The URL format is GROUP/VERSION/RESOURCE ", for example, apps/v1/deployment. All resource types have a JSON representation format called "kind". The client must submit the configuration information of the object in JSON when creating the object. A list of objects belonging to the same resource type is called collection, such as PodList. A type of single instance is called "resource" or "object", such as a pod object named Pod-demo. kind indicates the type of a resource object, such as Namespace, Deployment, Service, and Pod. These resource types can be divided into three categories. Object: an Object is a persistent entity Kubernetes the system. An Object may contain multiple resources. The client can use it to perform multiple operations. Namespace, Deployment, Service, and pods belong to this category. List: A List is a collection of resources of the same type, such as PodLists and NodeLists. Simple (Simple) class: It is often used to perform special operations on objects or manage non-persistent entities, such as/binding or/status. Kubernetes, most API resource types are "objects", which represent instances of a concept in a cluster. A small number of API resource types are virtual, which are used to express an operation. All object-type resources have a unique name identifier for idempotent creation and acquisition. However, you can also use a dedicated identifier when you do not need to obtain or depend on idempotence for virtual resources. Some resource types belong to clusters, such as Namespace and PersistentVolume, while most resource types are limited by namespaces, such as pods, Deployment, and Service. The URL path of a namespace-level resource contains the name of the space to which it belongs. These resource objects are deleted when the namespace is deleted, access to these resource objects is also subject to authorization review at the namespace level to which they belong.

Kubernetes divides APIs into multiple logical combinations called API groups. They can be enabled or disabled separately and can be decomposed again. API Server supports different versions in different groups, allowing different groups to evolve at different speeds. It also supports different versions in the same group, such as apps/v1, apps/v1beta2 and apps/v1beta1 can also use resource types with the same name in different groups, therefore, the same resource type can be used simultaneously in stable version groups and new experimental groups with different characteristics. The API of group management makes it easier to expand. You can run the kubectl api- versions command to obtain information about the API Server of the current system. Many API groups shown in the command results will be used in the following sections to configure the resource list:

[root@master ~]# kubectl api-versionsadmissionregistration.k8s.io/v1beta1apiextensions.k8s.io/v1beta1apiregistration.k8s.io/v1apiregistration.k8s.io/v1beta1apps/v1apps/v1beta1apps/v1beta2authentication.k8s.io/v1authentication.k8s.io/v1beta1authorization.k8s.io/v1authorization.k8s.io/v1beta1autoscaling/v1autoscaling/v2beta1batch/v1batch/v1beta1certificates.k8s.io/v1beta1events.k8s.io/v1beta1extensions/v1beta1networking.k8s.io/v1policy/v1beta1rbac.authorization.k8s.io/v1rbac.authorization.k8s.io/v1beta1scheduling.k8s.io/v1beta1storage.k8s.io/v1storage.k8s.io/v1beta1v1

Kubernetes apis are organized in a hierarchical structure. Each API Group is a REST path with/apis as the root path, however, the core group core has a dedicated simplified path "/api/v1". Currently, common API groups can be classified into the following two types. core group: the REST path is/api/v1. You can specify only the version, such as apiVersion: v1, without specifying the path in the resource configuration apiVersion field ". named group: the REST path is/apis/$GROUP_NAME/$VERSION, for example,/apis/apps/v1. The format referenced in the apiVersion field is apiVersion:

$GROUP_NAME/$VERSION”，如“apiVersion: apps/v1”

. To sum up, the URL representation of each resource type at the namespace level in the API can be simply abstracted as a path like "/apis /// namespaces, for example, if the path of the Deployment type in the default namespace is/apis/apps/v1/namespaces/default/deployments, you can obtain the list of all Deployment objects in the default namespace through this path:

~]$ kubectl get --raw /apis/apps/v1/namespaces/default/deployments | jq .{  "kind": "DeploymentList",  "apiVersion": "apps/v1",  ……  "items": [……]}

in addition, Kubernetes also supports user-defined resource types. Currently, there are three commonly used methods: one is to modify Kubernetes source code custom types; The other is to create a custom API Server, and aggregate them into the cluster; The third is to use Custom resources (Custom Resource Def? inition,CRD).

3.1.3 access Kubernetes REST API

accessing Kubernetes REST API in programming mode helps you understand its streaming cluster management mechanism, A common method is to use curl as an HTTP client to directly operate resource objects on the cluster through API Server to simulate the process of requests and responses. However, Kubernetes clusters deployed by kubeadm only support HTTPS APIs by default, which requires a series of authentication checks, fortunately, you can also use the kubectl proxy command to start a proxy gateway for API Server on the local host, which supports HTTP communication. The working logic is shown in Figure 3-3. For example, start a API Server proxy gateway on port 8080 of the local port 127.0.0.1:

~]$ kubectl proxy --port=8080Starting to serve on 127.0.0.1:8080

then, you can use a client tool such as curl to initiate an access request to this socket address on another terminal. For example, the request Kubernetes NamespaceList resource objects in the cluster, that is, to list all Namespace objects in the cluster:

~]$  curl localhost:8080/api/v1/namespaces/{  "kind": "NamespaceList",  "apiVersion": "v1",  ……}

alternatively, use the JSON command line processor jq command to filter the content of the response JSON data stream. For example, the following command is only used to display member objects in the relevant NamespaceList object:

~]$ curl -s localhost:8080/api/v1/namespaces/ | jq .items[].metadata.name"default""kube-public""kube-system"

if you specify the name of a Namespace resource object, you can obtain the corresponding resource information. Take the kube- system Namespace as an example:

~]$ curl -s localhost:8080/api/v1/namespaces/kube-system{  "kind": "Namespace",  "apiVersion": "v1",  "metadata": {

"name": "kube-system",
"selfLink": "/api/v1/namespaces/kube-system",
"uid": "eb6bf659-9d0e-11e8-bf0d-000c29ab0f5b",
"resourceVersion": "33",
"creationTimestamp": "2018-08-11T02:33:23Z"

}, "spec ": {

"finalizers": [
  "kubernetes"
]

}, "status ": {

"phase": "Active"

}

the preceding command response shows the resource configuration format of most resource objects in the Kubernetes. It is a JSON-serialized data structure that includes kind, apiVersion, metadata, spec and status are five level -1 Fields. The meaning and functions of each field are described in section 3.2.

3.2 object resource format

Kubernetes API only accepts and responds to JSON-formatted data (JSON objects), and allows users to provide YAML-formatted POST objects for ease of use, however, API Server need to convert it to JSON format before submitting it. All JSON objects received and returned by the API Server follow the same pattern. They all have the kind and apiVersion fields, which are used to identify the resource type, API Group, and related versions to which the object belongs. Further, most objects or list-type resources need to have three nested fields: metadata, spec, and status. The metadata field provides metadata information for resources, such as the name, namespace, and tag. spec defines the desired state, the significance of the statuses varies. For example, the core function of Pod resources is to run containers, while status records the current status information of the active object, which is maintained by the Kubernetes system, A read-only field. Each resource usually only accepts and returns a single type of data, and one type can be accepted or returned by multiple resources that reflect a specific use case. For example, for Pod resources, you can create, update, or delete Pod objects. However, the metadata of each Pod object, the values of the spec and status fields are independent object data. They can be operated separately, especially the status object, which is automatically updated by the Kubernetes system, you cannot manually operate it.

3.2.1 resource configuration list

in section 3.1, the curl command was used to request the status information of the API Server active object kube-system on the Namespace through a proxy. In fact, you can also use the kubectl get TYPE/NAME -o yaml command to obtain the YAML configuration list of any object, you can also use the kubectl get TYPE/NAME -o json command to obtain the configuration list in JSON format. For example, you can run the following command to obtain the status of kube-system:

~]$ kubectl get namespace kube-system -o yamlapiVersion: v1kind: Namespacemetadata:  creationTimestamp: 2018-08-11T02:33:23Z  name: kube-system  resourceVersion: "33"  selfLink: /api/v1/namespaces/kube-system  uid: eb6bf659-9d0e-11e8-bf0d-000c29ab0f5bspec:  finalizers:

• kubernetesstatus:

phase: in addition to a very small number of Active resources, most of the resources on the Kubernetes system are created by their users. When creating a resource, you need to define the configuration data of the resource in the YAML or JSON serialization scheme in a similar way as the preceding output, that is, the desired target state, then, the underlying component of the Kubernetes ensures that the runtime status of the active object is infinitely close to the status defined in the configuration list provided by the user. Therefore, the resource is created based on the resource configuration list provided by the user. The format is similar to the YAML or JSON output obtained by The kubectl get command. However, the status field is read-only and is automatically maintained by Kubernetes cluster. For example, the following is an example of a resource configuration list provided when you create a Namespace resource. It provides only a few Required fields:

apiVersion: v1kind: Namespacemetadata:  name: devspec:  finalizers:

• kubernetes saves the content in the configuration list as described above in a FILE. You can use the kubectl create -f /PATH/TO/FILE command TO create it into a cluster. After the creation is completed, view the output results in the YAML or JSON format. You can see that the Kubernetes completes most of its fields and provides the corresponding data. In fact, most of the resources Kubernetes can be created and viewed in a similar way, and almost all of them follow a similar organizational structure, the following command shows the status of the Deployment resource object myapp created by using the kubectl run command in Chapter 2:

~]$ kubectl get deployment myapp -o yamlapiVersion: extensions/v1beta1kind: Deploymentmetadata:……  name: myappspec:  replicas: 3  selector:

matchLabels:
  run: myapp

...... status: ……

to save space, the output above saves most of the content and only retains its main structure. As can be seen from the command results, it also follows Kubernetes API standard resource organization format and consists of five core fields: apiVersion, kind, metadata, spec, and status, however, the nested content in the spec field is almost completely different from Namespace resources. In fact, for almost all resources, the functions of the apiVersion, kind, and metadata fields are basically the same, but spec is used for the desired state of resources, the difference in resource types lies in the significant difference in their nested attributes, which are defined and maintained by users. The status field is used to record the current status of the active object. It must be the same as the expected status defined in the spec or is in the process of converting to the same status.

3.2.2 metadata nested fields

the metadata field is used to describe the attributes of an object. Multiple fields are embedded in it to define the metadata of a resource, such as name and labels. These fields can be divided into two categories: required fields and optional fields. The following table lists the required fields for namespace-level resources. namespace: specifies the namespace to which the current object belongs. default value: default. name: specifies the name of the current object, which must be unique in the same type of namespace to which it belongs. uid: the unique identifier of the current object. The uniqueness only occurs in a specific time period and namespace; this identifier is mainly used to distinguish objects with the same name as deleted and recreated objects. Optional fields are usually maintained and set by the Kubernetes system, or have default values, or allow null values. The following are common types of fields: labels: specifies the tag and key-value data used to identify the current object, which is often used as a selection condition. annotations: non-identity key-value data, used as a selection condition to supplement labels. resourceVersion: the internal version identifier of the current object. It allows the client to determine whether the object changes. generation: The generation used to identify the target status of the current object. creationTimestamp: the timestamp of the creation date of the current object. deletionTimestamp: the timestamp of the date when the object is deleted. In addition, when you create resources from the configuration list, you usually only need to specify required fields. Optional fields can be specified as needed. For nested fields that are not explicitly defined by the user, A series of f? The inalizer component is automatically filled in. You need to forcibly verify the target resource object created by the resource, or use the initializer component to complete the modification. For example, you need to add a Sidecar container for each Pod object to be created. Different resource types also have some specific nested fields, such as Conf? igMap resources also support clusterName.

3.2.3 spec and status fields

Kubernetes use spec to describe the desired status of an object, and use the status field to record the current status of an object on the system. Therefore, the status field is only meaningful for the active object. Both fields belong to nested fields. When defining a resource configuration list, spec is a field that must be defined. It is used to describe the target state of an object, that is, the characteristics that users expect the object to show. The status field records the current or actual status of an object. The value of this field is filled or updated by the Kubernetes system and cannot be defined manually. The controller-manager of the Master dynamically manages the corresponding controller components and ensures that the actual state of the object matches the desired state. It is a reconciliation configuration system. For example, Deployment is an object used to describe applications running in a cluster. Therefore, when creating an object of the Deployment type, you need to set the spec for Deployment target object, specify the number of Pod replicas that you want to run, the tag selector used, and the Pod template. Kubernetes the system to read the spec of the Deployment object to be created and the current status of the corresponding active object on the system. If necessary, update the object to ensure that the status field matches the desired status in the spec field. If any of these instances has a problem (the value of the status field has changed), the Kubernetes system needs to respond to the differences between the spec and status fields in a timely manner, for example, the number of missing Pod replicas. The nested fields of spec fields are different for different object types. For more information, see the instructions in Kubernetes API reference manual, the common configuration fields of core resource objects will be described later in this book.

3.2.4 resource configuration list format document

when defining a resource configuration list, although apiVersion, kind, and metadata have rules to follow, the spec field varies greatly for different resources, therefore, you need to refer to Kubernetes API reference documents to learn about various available attribute fields. Fortunately, Kubernetes have built related documents in the system. You can use the kubectl explain command to obtain relevant instructions, it displays the relevant next-level document based on the given object type or corresponding nested fields. For example, to understand the level -1 fields of a Pod resource, you can use a command similar to the following. The Command results output the supported fields and their descriptions:

~]$ kubectl explain pods

To understand the second- level object fields under an object represented by a level -1 field, you only need to specify the object name of the level -1 field. You can view the level -3 and level -4 field objects in the same way. For example, the Spec object of the Pod resource supports nested secondary fields. You can run the following command:

~]$ kubectl explain pods.specRESOURCE: spec 

the spec Field Document contains RESOURCE, DESCRIPTION, and FIELDS. The FIELDS section provides nested FIELDS, data types, and function descriptions. For example, the data type of the containers field in the FIELDS shown in the preceding command is an Object list ([]Object) and is a required field. Any field whose value is object type data is nested with one or more next- level fields. For example, each container in a Pod object is also object type data, which also contains nested fields, however, containers cannot be created separately, but must be included in the context of Pod objects. The detailed information can be obtained through three-level Fields. The Command and its results are as follows:

~]$ kubectl explain pods.spec.containersRESOURCE: containers <[]Object>

DESCRIPTION:

 List of containers belonging to the pod. Containers cannot currently be added

or removed. There must be at least one container in a Pod. Cannot be updated.

 A single application container that you want to run within a pod.

FIELDS: args <[]string>

 Arguments to the entrypoint. The docker image's CMD is used if this is not 
     provided. ……

command <[]string>

 Entrypoint array. Not executed within a shell. The docker image's
 ENTRYPOINT is used if this is not provided. ……

env <[]Object>

 List of environment variables to set in the container. Cannot be updated.

......

The built-in document greatly reduces the difficulty for users to manually create resource configuration lists. When trying to use a resource type, explain is indeed one of the common commands for users. After being familiar with the functions of common fields, you can use the list of existing active objects of the same TYPE as the template to generate the configuration file of the target resource. The command format is "kubectl get TYPE NAME -o yaml -- export", the -- export option is used to omit the output information generated by the system. For example, to generate the deploy- demo.yaml file based on the current Deployment resource object myapp, you can run the following command:

~]$ kubectl get deployment myapp -o yaml --export > deploy-demo.yaml

managing resource objects through resource inventory files has many advantages over directly operating on command lines, including that command line operation only supports some attributes of some resource objects, the resource list allows you to configure all attribute fields of resources, and use the configuration list file to perform advanced functions such as version tracing and review. Most of the resource management operations in subsequent chapters of this book are performed with the help of resource configuration files.

3.2.5 resource object management

the Kubernetes of the API Server is designed according to the declarative programming paradigm. It focuses on building the program logic without the need for users to describe its implementation process. Users only need to set the desired state, the system can determine the operations that need to be performed to ensure that the desired state is met. For example, if you expect a Deployment controller to manage three Pod resource objects, but the current number observed by the system is two, therefore, the system will know that a new Pod resource needs to be created to meet this expectation. The self-healing, autonomy and other functions of Kubernetes depend on their declarative mechanisms. Another corresponding paradigm is called imperative programming. The Code focuses on creating a statement that tells the computer how to perform operations to change the program state, it is closely related to the way the hardware works. Generally, the code uses control structures such as conditional statements, loops, and class inheritance. To make it easy for users to use, Kubernetes API Server also supports declarative paradigms. It directly manages objects through commands and their options, commands such as delete and get belong to this category. You need to tell the system what to do during execution. For example, you can use the run command to create a Deployment object with three Pod object replicas, you can also use the delete command to delete a Service object named myapp. Kubernetes, most API objects in the system have two fields, spec and status. spec allows users to define the desired status and the system reads the relevant definitions from it; the status is the current status that the system observes and writes, from which users can obtain relevant information. The Kubernetes system monitors the system object through the controller, which is responsible for making the current state of the system infinitely close to the desired state of the user. kubectl commands can be divided into three types: imperative command and imperative object conf? iguration) and declarative object conf? iguration). The first method is the previously used run, expose, delete, get, and other commands, which directly act on the active objects on the Kubernetes system. It is easy to use, but does not support code reuse, modify review and audit logs. The use of these functions usually depends on resource configuration files, which are also called resource lists. In this mode, users can access the complete mode of each object, but users need to learn more about Kubernetes API. As described in section 3.2.4, the resource list is essentially a JSON or YAML text file that consists of the configuration information of the resource object and supports version control using Git. Users can manage resource objects in declarative or declarative form on the Kubernetes system based on the resource list, as shown in Figure 3-4.

Figure 3-4 manage objects based on resource configuration list

statement-based management includes create, delete, get, and replace commands. The difference between Statement-based management and statement-based management is that it reads the target resource objects to be managed through the resource configuration list. The management operation of declarative object configuration is directly applied to the active object. Even if only a very small part of the configuration list is modified, the object update by using the replace command will cause the entire object to be replaced. Further, when you use a mixed statement command to make out-of-band modifications to the inventory file, the current status of the active object will inevitably be lost. Declarative object configuration does not directly indicate the object management operations to be performed, but provides the configuration list file to the Kubernetes system and entrusts the system to track the status changes of the active object. You can create, delete, and modify resource objects by using the unique apply command. The configuration information provided to the command is saved in the annotation information of the object (kubectl.kubernetes.io/last-applied-conf? iguration), and compare and check the current status of the active object, the configuration information in the annotation, and the configuration information in the resource list to merge changes, so as to implement the advanced patch mechanism of modifying only the change fields. Compared with declarative object configuration, declarative object configuration has the disadvantage that configuration files in the same directory must perform the same operation at the same time, for example, both create and update, the updates of other users must also be reflected in the configuration file, otherwise the updates will be overwritten in the next update. Therefore, declarative object configuration is a management mechanism recommended to users first. However, for beginners, the configuration method of declarative commands is the easiest to use, and it is easy to switch to use declarative object configuration management method after knowing the system. Therefore, if recommended to advanced users, we recommend that you use declarative configuration. We also recommend that you use versioning to store the desired status and cross-object historical information, and enable the change review mechanism. In addition, we recommend that you use projects such as kube-applier to implement automated declarative configuration. You can push the configuration to the Git repository and use such tools to automatically synchronize it to Kubernetes cluster.

3.3 kubectl commands and resource management

API Server is a gateway Kubernetes a cluster. Users, administrators, and other clients can only interact with the cluster through this gateway interface. API is a programmer-oriented access interface. Currently, it supports Golang and Python programming languages. Of course, the common command line tool kubectl is more commonly used by end users. Before accessing a cluster, all clients must know the cluster location and have the credentials to access the cluster. When you use kubeadm to initialize a cluster, is the/etc/kubernetes/admin.conf file automatically generated by kubeadm init the kubeconf file used by the client to connect to the current cluster? The ig file, which has built-in user accounts and related authentication credentials that are used to access the Kubernetes cluster with the highest administrative permissions, and can be directly used by kubectl.

3.3.1 resource management operation overview

resource management operations can be divided into four types: add, delete, modify, and check. kubectl provides a series of subcommands for executing such tasks, such as create, delete, patch, apply, replace, edit, get, and so on. Some commands must be run based on the resource list, such as the apply and replace commands. Some commands can be run based on the inventory file, it can also be applied to active resources in real time, such as create, get, patch, and delete. The kubectl command can read any file suffixed with. yaml,. yml, or. json (it can be called a configuration list or configuration file, which will be used in the following article without distinction). In practice, users can either use a dedicated inventory file for each resource or use multiple related resources (for example, belonging to the same application or microservice) the organization is in the same inventory file. However, if the inventory file is in the YAML format, multiple resources need to use the "---" symbol to separate resources. In this way, multiple resources are called by subcommands such as create and apply in the order defined in the inventory file. Most subcommands of kubectl support using the "-f" option to specify the path or URL of the inventory file, or the directory where the inventory file is stored. In addition, this option can be reused multiple times in the same command. If the specified directory path exists in a subdirectory, you can use the-R option as needed to recursively obtain the configuration list in the subdirectory. Furthermore, the support for the use of tags and annotations is a feature of the Kubernetes system. It adds a lot to the resource management mechanism, and commands such as delete and get can select target objects based on tags, some resources, such as Service and Pod controller Deployment, must depend on tags for normal use and operation. The subcommand label is used to manage resource labels, while the subcommand to manage resource annotations is to annotate. Local Update (modification) Existing resources are also a common operation. The apply command performs an update operation by comparing the version of a resource in the inventory file with the previous version. It does not have additional effects on undefined attributes. The edit command is equivalent to using the get command to obtain the resource configuration, modify it through the interactive editor, and then use the apply command to apply it automatically. The patch command updates resources locally based on JSON patches, JSON merge patches, and policy merge patches. To take advantage of the apply command, you should always use the apply command or create -- save-conf? Use the ig command to create a resource.

3.3.2 Basic usage of kubectl

kubectl is one of the most commonly used client tools. It provides a simple way to access Kubernetes API based on command lines and can meet most of the operation requirements for Kubernetes. For example, when you want to create a resource object, kubectl submits the JSON-formatted list content to the API Server as a POST. This topic describes the basic features of kubectl. If you want to deploy kubectl separately, Kubernetes also provides a separate distribution package, or packages that are applicable to program managers of various platforms, such as rpm packages or deb packages, you can obtain the matching version based on the platform type and complete the installation. The procedure is similar to the previous installation method, so the specific procedure is not described here. kubectl is a command-line client tool for Kubernetes. It has rich features and powerful functions, and is the most commonly used cluster management tool for Kubernetes administrators. The most basic syntax is kubectl [command] [TYPE] [NAME] [f? ...] ", the brief description of each part is as follows. (1)command: subcommands that perform corresponding operations on resources, such as get, create, delete, and run. Common Core subcommands are shown in Table 3-1. (2)TYPE: the TYPE of the resource object to be operated, such as pods and services. The TYPE name is case-sensitive, but can be abbreviated. (3)NAME: The object NAME, which is case-sensitive. If it is omitted, it indicates all resource objects of the specified TYPE. In addition, you can also use TYPE/NAME to represent resource objects. 4)f? **: command line options, such as"-s "or" -- server ". In addition, commands such as get also have a common flag"-o "to specify the output format, as shown in Table 3-1.

Table 3-1 list of kubectl subcommands

command Category description basic command create (primary) use files or standard input to expose resources based on rc, service, deployment or pod create Service resources run by creating Deployment cluster running in the specified mirror set settings of the specified resource specific property get Base Command (intermediate) display one or more resources explain print resource document edit edit resource delete based on file name, stdin, resource or name, and resources and selectors delete resources rollout Deployment commands manage rolling updates of resources rolling-update performs rolling upgrades on ReplicationController scale scale scaling Deployment, ReplicaSet, RC, or Job scale autoscale on Deployment, replicaSet or RC auto scaling certif? icate cluster management command configure digital certificate resource cluster- info print cluster information top print resource (CPU/Memory/Storage) usage cordon set the specified node to unschedulable the uncordon state sets the specified node to schedulable state to drain the load of the specified node to enter the maintenance mode taint. Declare taints and standard behaviors for nodes describe troubleshooting and debugging commands display details of specified resources or resource groups logs display logs of a container in a Pod attach the attached terminal to a running container exec run the specified command port-forward in the container to forward one or more local ports to the specified Pod proxy create a proxy cp that can access the Kubernetes API Server copy files or directories between containers auth print authorization information apply advanced command apply configuration to resource patch based on file or stdin use policy merge patch update resource field replace replace a resource based on file or stdin convert to different API versions change configuration file label settings command update the specified resource label annotate update resources annotation completion output specified shell (such as bash) other commands to print the full code version Kubernetes the version information of the server and client api-versions print the API version information conf supported by the server in the format of group/version? Configure kubeconf for ig? The content plugin of the ig file run the command line plugin help Print Help information for any command

kubectl commands also contain a variety of output formats (as shown in Table 3-2), which provide users with a very flexible custom output mechanism, such as YAML or JSON format output.

Table 3-2 common output formats of kubectl get commands

output Format Description-o wide displays additional information about resources- o name only prints the name of the resource-o yaml YAML format output API object information-o json JSON format output API object information- o go-template to customize go template formatting output API object information-o custom-columns customize the fields to be output

In addition, the kubectl command has many common options, which can be obtained by using the kubectl options command. The following are some common commands. -s or -- server: specify the address and port of the API Server. --kubeconf? ig: the kubeconf used? The path of the ig file. Default value: ~/.kube/conf? ig. -- namespace: The target namespace for command execution. Part of kubectl commands have been mentioned many times in chapter 2. Most of the remaining commands will be used in subsequent chapters, their instructions will also be explained when they are first used.

3.4 manage namespace resources

namespaces (Namespace) are Kubernetes cluster-level resources. They are used to separate clusters into multiple isolated logical partitions to be configured for different users, tenants, environments, or projects. For example, you can create namespaces for development, qa, and production environments. The vast majority of Kubernetes resources belong to the namespace level (the other is global or cluster level). Namespace resources provide isolated scopes for such resource names, the names of resources of the same type in the same namespace must be unique. However, this restriction is not applicable when cross-Namespaces exist. However, Kubernetes, some resources belong to cluster-level resources, such as Node, Namespace, and PersistentVolume. They do not belong to any namespaces, so the names of resource objects must be globally unique. Kubernetes namespace resources are different from Linux namespaces. They are independent concepts. In addition, Kubernetes namespace cannot isolate the communication between pods. It is only used to limit the scope of resource object names.

3.4.1 view namespaces and their resource objects

by default, Kubernetes cluster provides several namespaces for specific purposes. For example, kube-system is mainly used to run system-level resources, while default provides a default value for resource operations that do not specify namespaces, most of the resource management operations in the previous section are performed in the default namespace. The kubectl get namespaces command allows you to view namespaces resources:

~]$ kubectl get namespacesNAME          STATUS    AGEdefault       Active    6dkube-public   Active    6dkube-system   Active    6d

you can also use the kubectl describe namespaces command to view the details of a specific namespace, for example:

~]$ kubectl describe namespaces default

in most cases, the kubectl resource viewing command should be performed for a specific namespace. Use the "-n" or "-- namespace" option for the kubectl resource viewing command. For example, view all Pod resources in kube-system:

~]$ kubectl get pods -n kube-systemNAME                                 READY    STATUS     RESTARTS    AGEetcd-master.ikubernetes.io           1/1      Running    1           6dkube-apiserver-master.ikubernetes.io 1/1      Running    1           6d……

the command results show that the Pod resource objects in the kube-system and default namespaces are different, which is the embodiment of the Namespace resource name isolation function. With Namespace objects, users no longer need to carefully arrange resource names or worry about misoperation of other users' resources.

3.4.2 management Namespace resources

Namespace is one of the Kubernetes API standard resource types. As described in section 3.2.1, its configuration mainly consists of one-level fields such as kind, apiVersion, metadata, and spec. Save the namespace configuration list in section 3.2.1 in the configuration file, and use the statement object configuration command create or statement object configuration command apply to complete the creation:

~]$ kubectl apply -f namespace-example.yamlnamespace/dev created

namespace resource attributes are few (usually you only need to specify a name). For simplicity, kubectl provides a dedicated encapsulated statement command "kubectl create namespace". The name of the Namespace resource can only contain letters, digits, hyphens, and underscores (_). For example, the following command can be used to create a Namespace object named qa:

~]$ kubectl create namespace qanamespace/qa created

the name of a namespace resource can only contain letters, digits, hyphens, and underscores (_). In practice, we recommend that you do not mix different types of management methods. Considering the powerful functions of the declarative object configuration management mechanism, we strongly recommend that you use commands such as apply and patch to manage resources such as resource creation and modification. When you use kubectl to manage resources, if the namespace option is provided, the management operation is only performed for the specified namespace, if you delete Namespace resource, all other resource objects contained in the resource are deleted. Table 3-3 shows several common command formats.

Table 3-3 delete commands used with namespaces

command format function kubectl delete TYPE RESOURCE -n NS delete a specified RESOURCE kubectl delete TYPE in a specified namespace -- all -n NS delete all resources of the specified TYPE in a specified namespace kubectl delete all -n NS delete all resources of the specified namespace resource kubectl delete all -- all delete all resources in all namespaces

it should be noted again that Namespace object is only used to isolate resource object names. It cannot isolate cross-Namespace Pod communication, which is a function of network policy resources. 3.5 basic management of Pod resources Pod is the core resource type in Kubernetes API. It can be defined in the resource list in JSON or YAML format and managed by resource management commands in declarative or declarative form. During creation, you can use the create or apply command to submit the request to the API Server and save it to the etcd of the cluster status storage system. Then, the scheduler schedules the request to the optimal target node, the kubelet of the corresponding node is created and started by the container engine. This kind of Pod object is also called autonomous Pod.

3.5.1 configuration management methods of declarative objects

the declarative object configuration management mechanism is a management method in which users specify the target resource objects to be managed through the configuration file, and then users directly specify the management operations to be performed by the Kubernetes system by using commands, common commands include create, delete, replace, get, and describe. 1. Create a Pod resource a Pod is a standard Kubernetes API resource. It is defined in the configuration list by using the kind, apiVersion, metadata, and spec Fields. The status field is maintained by the system after the object is created. The core function of a Pod object is to run containerized applications. The required field nested in the spec field is containers, whose value is a list of container objects, supports nested creation of one or more containers. The following is a Pod resource list sample file. The expected state defined in spec is to run a container named myapp in the Pod object based on the ikubernetes/myapp: v1 image:

apiVersion: v1kind: Podmetadata:  name: pod-examplespec:  containers:

• name: myapp image: ikubernetes/myapp:v1

  把上面的内容保存于配置文件中，使用“kubectl [COMMAND] -f /PATH/TO/YAML_FILE”命令以陈述式对象配置进行资源对象的创建，下面是相应的命令及响应结果：

~]$ kubectl create -f pod-example.yamlpod/pod-example created

if you are familiar with JSON, you can define the list file as JSON format. The list file in YAML format is also converted to JSON format by API Server before application. The message returned by the command indicates that the Pod- example object of the Target pod is successfully created. In fact, the-f option in the create Command also supports directory path or URL, and when the target path is a directory, the-R option can be used for subdirectory recursion. In addition, the -- record option can record the command itself as the annotation information of the target object kubernetes.io/change-cause, while the -- save-conf? ig can save the resource object configuration information provided to the command in the annotation information of the object kubectl.kubernetes.io/last-applied-conf? In iguration, the function of the latter command is similar to that of the declarative object configuration command apply. 2. View Pod status by default, the get command displays the most critical status information of the resource object, while commands such as describe can print the detailed status of the Kubernetes resource object. However, although the resource list file provided during creation is simple, the kubectl get command can either use the-o yaml or- o json options to output the configuration data and status of the resource object, you can also use the -- custom- columns option to customize the fields to be displayed:

~]$ kubectl get -f pod-example.yamlNAME          READY     STATUS    RESTARTS    AGEpod-example   1/1       Running   0           1m~]$ kubectl get -f pod-example.yaml -o custom-columns=NAME:metadata.name,STATUS:status.phaseNAME          STATUSpod-example   Running

when the-o yaml or-o json option is used, the get command can return the metadata, expected status, and current status of the resource object, and print the details of the active object, you need to use the describe command, which can filter and output information of qualified resource objects based on the resource list, resource name, or volume label. The command format is kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | - l label] | TYPE/NAME) ". For example, to display the pod-example details, run the following command: ~]$ kubectl describe -f pod-example.yaml for a Pod resource object, it can return the metadata of the active object, current Status, container list, container details, volume object list, QoS category, events, and related information, these details are essential for understanding the status of the target resource object or troubleshooting operations. 3. Update Pod resources not every property value of an active object can be modified. For example, the metadata.name field of a Pod resource object cannot be modified unless it is deleted and recreated. For those attributes that support modification, such as the image field of the container, you can export the complete configuration list to the configuration file and update the corresponding configuration data, then, use the replace command to update the resource object based on the management mechanism of declarative object configuration. For example, change the image value in the resource list used to create pod-example to ikubernetes/myapp: v2, and then perform the following operations:

~]$ kubectl get pods pod-example -o yaml > pod-example-update.yaml~]$ sed -i 's@(image:).*@ikubernetes/myapp:v2@' pod-example-update.yaml~]$ kubectl replace -f pod-example-update.yamlpod/pod-example replaced

when updating the configuration of an active object, the replace command reconstructs the entire resource object. Therefore, it must be based on the complete configuration information to completely replace the active object. To replace an object based on the previous configuration file, you must use the -- force option to delete the previous active object and then create the object. Otherwise, the command returns an error message. For example, change the image in the configuration list in the create Pod resource step to ikubernetes/myapp: v2 and then forcibly replace it. Run the following command:

~]$ kubectl replace -f pod-example.yaml --forcepod "pod-example" deletedpod/pod-example replaced

4. You can use the-f option to specify a configuration list for the delete Pod resource statement object configuration management method. For example, delete the Pod resource object defined in the pod- example.yaml file:

~]$ kubectl delete -f pod-example.yamlpod "pod-example" deleted

then, print the resource objects defined in the relevant configuration list again to verify the deletion result, for example:

~]$ kubectl get -f pod-example.yamlNo resources found.Error from server (NotFound): pods "pod-example" not found

3.5.2 declarative object configuration management

in the declarative object configuration management mechanism, multiple resources specified at the same time must perform the same operation, and the replace command is to update resources by completely replacing existing active objects, this is not an ideal choice for the production environment. The declarative object configuration operation saves the configuration information in the annotation of the target object when managing the resource object, and compares the current configuration of the active object, the configuration saved in the annotation during the previous management operation and the configuration provided by the current command generate update patches to complete the patch update operation of the active object. Common commands for such management operations include apply and patch. For example, to create a Pod resource object that uses the ikubernetes/myapp: v1 image as the primary container defined in Section 3.5.1, run the following command:

~]$ kubectl apply -f pod-example.yamlpod/pod-example created

To update an object, you can directly modify the original resource list file and run the apply command again. For example, you can modify the image file in the Pod resource list to ikubernetes/myapp: run the apply command again after v2:

~]$ kubectl apply -f pod-example.yamlpod/pod-example configured

the command result shows that the resource has been reconfigured and has taken effect. In fact, this type of operation can also use the patch command to directly perform patch operations. You can still use the apply command to delete resource objects, but use the -- prune option at the same time. The command format is kubectl apply -f -- prune -l ". Note that this command is extremely dangerous because it filters out all eligible objects based on the tag selector, and check whether a configuration file has defined the corresponding resource objects in the directory specified by-f. Those resource objects that do not exist will be deleted. Therefore, we recommend that you use the kubectl delete command in the declarative object configuration mode to delete resource objects. This command format has clear objectives and is not prone to deviation.

3.6 Summary of this Chapter

this topic describes the resource object types and their management methods that are commonly used in Kubernetes systems. After explaining the basic usage of kubectl command line tools, the usage of Namespace resource objects is briefly described as follows. Kubernetes provides a RESTful-style API that abstracts various components as "resources" and instantiates them through attribute assignment. Kubernetes API supports many resource types, including Node, Namespace, Pod, Service, Deployment, and Conf? Hundreds of types, such as igMap. Most of the resource configurations in the standard format are composed of one-level attribute fields, such as kind, apiVersion, metadata, spec, and status. spec is a user-defined desired state, the status is the current status maintained by the system. Kubernetes API mainly provides declarative object configuration interfaces, but it also supports declarative commands and declarative object configuration management methods. kubectl has many functions. It uses subcommands to complete different tasks, such as create, delete, edit, replace, and apply. Namespace and Pod are the basic resource types of the Kubernetes system.