Shulou(Shulou.com)06/03 Report--

1. Pod

Kubernetes assigns a unique IP address to each Pod, called Pod IP, and multiple containers in a Pod share Pod IP addresses. Kubernetes requires the underlying network to support direct TCP/IP communication between any two Pod in the cluster, which is usually realized by virtual layer 2 network technology, such as Flannel, Open vSwitch and so on. Therefore, in Kubernetes, a container in one Pod can communicate directly with a Pod container on another host.

There are two types of Pod: normal Pod and static Pod (Static Pod). Static Pod is not stored in etcd storage, but in a specific file on a specific Node, and only starts running on this Node. Once a normal Pod is created, it is stored in etcd, and then dispatched by Kubernetes Master to a specific Node and Binding, the kubelet process on that Node instantiates it into a set of related Docker containers and starts it. When a container in the Pod stops, Kubernetes automatically detects the problem and restarts the Pod (restart all containers in the Pod); if the Node where the Pod is located is down, all Pod on this Node will be rescheduled to run on other nodes.

The relationship between Pod, container and Node is shown below:

All resource objects in Kubernetes can be defined or described in yaml or JSON format. Here is a simple Pod resource definition file:

ApiVersion: v1kind: Podmetadata: name: myweb labels: name: mywebspec: containers:-name: myweb image: kubeguide/tomcat-app: V1 ports:-containerPort: 8080 env:-name: MYSQL_SERVICE_HOST value: 'mysql'-name: MYSQL_SERVICE_PORT value:' 3306'

Kind indicates that this is a definition of Pod for pod, the name attribute in metadata is the name of Pod, and the Label of resource objects can also be defined in metadata. It is stated here that myweb has a name=myweb tag (Label). The definition of the container group contained in Pod is declared in the spec section, where a container named myweb and mirrored as kubeguide/tomcat-app: v1 is defined, which injects environment variables named MYSQL_SERVICE_HOST='mysql' and MYSQL_SERVICE_PORT='3306' (env keyword) and starts the container process on port 8080 (containerPort). Pod's IP plus the container port here forms a new concept-Endpoint, which represents the external communication address of a service process in this Pod. There are also cases where a Pod has multiple Endpoint. For example, when we define a Tomcat as a Pod, we can expose the management port and the service port.

Volume in Docker also has a corresponding concept in Kubernetes-Pod Volume,Pod Volume has some extensions, such as GlusterFS, a distributed file system, to implement back-end storage; Pod Volume is defined on top of Pod and then mounted to its own file system by each container. We will talk about the definition of Pod Volume later.

Incidentally, I would like to mention the concept of Event. Event is a record of an event, recording the earliest occurrence time, the last recurrence time, the number of repetitions, the initiator, the type, and the cause of the event. Event is usually associated with a specific resource object and is an important reference for troubleshooting. When we find that a Pod cannot be created for a long time, we can use kubectl describe pod xxx to view its description information and locate the cause of the problem.

Each Pod can set a limit on the computing resources on the server it can use. Currently, there are two kinds of computing resources that can be set a limit: CPU and Memory. The resource unit of CPU is the number of CPU (Core), which is an absolute value.

A CPU quota is already a fairly large resource quota for a container, so in Kubernetes, the minimum CPU quota of 1/1000 is usually represented by m. Typically, the CPU quota for a container is defined as 100m-300m, that is, it takes up 0.1m-0.3m CPU. Similar to the CPU quota, the Memory quota is an absolute value in bytes of memory.

You need to set the following two parameters to limit the quota of computing resources:

Requests: the minimum number of requests for this resource, the system must meet the requirements. Limits: the maximum allowed amount of this resource cannot exceed this limit. When the container tries to use more than this amount of resource, it may be restarted by Kubernetes Kill.

In general, we should set Requests to a small value to meet the resource requirements of the container under normal workload, while Limits should be set to the maximum amount of resources under peak load. Here is a simple definition of a resource quota:

Spec: containers:-name: db image: mysql resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

A minimum of 0.25 CPU and 64MB memory, a maximum of 0.5 CPU and 128MB memory.

II. Label (label)

Label is equivalent to the familiar "tag". Defining a Label to a resource object is tantamount to tagging it, and then you can query and filter resource objects with some Label through Label Selector (tag selector). In this way, Kubernetes implements a simple and general object query mechanism similar to SQL.

Label Selector is equivalent to a where query condition in a SQL statement. For example, when the Label Selector of name=redis-slave acts on Pod, it is equivalent to a statement such as select * from pod where pod's name= 'redis-slave'. There are two kinds of Label Selector expressions: equality-based (Equality-based) and set-based (Set-based). The following is an example of an equation-based match.

Name=redis-slave: matches all resource objects labeled name=redis-slave.

Env! = production: matches all resource objects whose label env is not equal to production.

The following is an example of a set-based match

Name in (redis-master, redis-slave): matches all resource objects labeled name=redis-master or name=redis-slave. Name not in (php-frontend): matches all resource objects whose label name is not equal to php-frontend.

Complex condition selection can also be achieved through the combination of multiple Label Selector expressions, which can be separated by ",". The relationship between several conditions is "AND", that is, multiple conditions are satisfied at the same time, for example:

Name=redis-slave, envailing products not in (php-frontend), envailing production

Take Pod as an example, Label is defined in metadata:

ApiVersion: v1kind: Podmetadata: name: myweb labels: app: myweb

RC and Service define Selector in spec to associate with Pod:

ApiVersion: v1kind: ReplicationControllermetadata: name: mywebspec: replicas: 1 selector: app: myweb template:.

Deployment, ReplicaSet, DaemonSet, and Job can use set-based filters in Selector:

Selector: matchLabels: app: myweb matchExpressions:-{key: tier, operator: In, values: [frontend]}-{key: environment, operator: NotIn, values: [dev]}

MatchLabels is used to define a set of Label, which is the same as writing directly in Selector; matchExpressions is used to define a set of set-based filters, and the available conditional operators are: In, NotIn, Exists, and DoesNotExist.

If both matchLabels and matchExpressions are set, the two sets of conditions are "AND" relations, that is, all conditions need to be met at the same time to complete Selector filtering.

The important usage scenarios of Label Selector in Kubernetes are as follows:

The Kube-controller process filters the number of Pod replicas to be monitored through the Label Selector defined on the resource object RC, so that the number of Pod replicas always conforms to the expected fully automatic control flow. The Kube-proxy process selects the corresponding Pod through the Label Selector of Service, and automatically establishes the request forwarding routing table of each Service to the corresponding Pod, thus realizing the intelligent load balancing mechanism of Service. By defining a specific Label for some Node and using the tag scheduling strategy of NodeSelector in the Pod definition file, the kube-scheduler process can implement the Pod "directed scheduling" feature.

To take a more complex example, suppose we define three Label:release, env, and role for Pod, and different Pod defines different Label. As shown in the following figure, if we set Label Selector for "role=frontend", we will select Pod on Node 1 and Node 2.

If we set the Label Selector for "release=beta", we will select the Pod on Node 2 and Node 3, as shown in the following figure.

Conclusion: multiple groups of tags can be created for objects using Label. Label and Label Selector together constitute the core application model of Kubernetes system, which enables the managed objects to be managed in fine groups and realizes the high availability of the whole cluster.

III. Replication Controller

The role of RC is to declare that the number of copies of Pod meets a certain expected value at any time, so the definition of RC includes the following parts.

Number of copies expected by Pod (replicas). The Label Selector used to filter the target Pod. The Pod template (template) used to create a new Pod when the number of copies of the Pod is less than expected.

Here is an example of a complete RC definition, ensuring that the Pod that has the tier=frontend tag (running the Tomcat container) always has three copies throughout the Kubernetes cluster:

ApiVersion: v1kind: ReplicationControllermetadata: name: frontendspec: replicas: 3 selector: tier: frontend template: metadata: labels: app: app-demo tier: frontendspec: containers:-name: tomcat-demo image: tomcat imagePullPolicy: IfNotPresent env:-name: GET_HOSTS_FROM value: dns ports:-containerPort: 80

When we define a RC and submit it to the Kubernetes cluster, the Controller Manager component on the Master node is notified to periodically patrol the target Pod currently alive in the system and ensure that the number of target Pod instances is exactly equal to the expected value of this RC. If there are too many copies of Pod running, the system will stop the extra Pod;. If there are fewer copies of Pod running than expected, that is, if a Pod dies, the system will automatically create a new Pod to ensure that the number is equal to the expected value.

Through RC,Kubernetes to achieve high availability of user application clusters, and greatly reduce a lot of manual operation and maintenance work that operators need to complete in the traditional IT environment (such as host monitoring scripts, application monitoring scripts, fault recovery scripts, etc.).

Let's take a look at how Kubernetes automatically controls the number of Pod replicas through RC. If we have three Node nodes and define redis-slave in RC, the Pod needs to keep two replicas, and the system will create replicas on two of them, as shown in the following figure.

If the Pod2 on Node2 terminates unexpectedly, a new Pod will be created and started automatically according to the number of replicas defined by RC. This ensures that there are always two redis-slave Pod running in the entire cluster.

The system may choose Node1 or Node3 to create a new Pod, as shown in the following figure.

By modifying the number of copies of RC, you can achieve the dynamic scaling (Scaling) function of Pod.

Kubectl scale rc redis-slave-replicas=3

At this point, Kubernetes will select one of the three Node to create and run a new Pod3, so that the number of redis-slave Pod copies is always maintained at 3.

IV. Replica Set

Since Replication Controller has the same name as the module Replication Controller in Kubernetes code, and the word does not accurately express its meaning, it has been upgraded to another new object-Replica Set, officially interpreted as "the next generation RC" since Kubernetes v1.2. The only difference that currently exists between Replica Set and RC is that Replica Set supports set-based Label selector (Set-based selector), while RC only supports equation-based Label selector (equality-based selector), so Replica Set is more powerful. Here is an example of the definition of Replica Set (omitting the Pod template section):

ApiVersion: extensions/v1beta1kind: ReplicaSetmetadata: name: frontendspec: selector: matchLabels: tier: frontend matchExpressions:-{key: tier, operator: In, values: [frontend]} template:.

Replica Set is rarely used alone, and it is mainly used by Deployment, a higher-level resource object, thus forming a set of choreography mechanisms for Pod creation, deletion, and update.

The characteristics and functions of RC and RS are as follows:

In most cases, we define a RC to achieve automatic control of the Pod creation process and the number of copies. The complete Pod definition template is included in RC. RC realizes the automatic control of Pod copy through Label Selector mechanism. By changing the number of Pod copies in RC, you can expand or reduce the capacity of Pod. By changing the mirror version of the Pod template in RC, you can achieve the rolling upgrade function of Pod. 5. Deployment

The biggest difference between Deployment and RC is that we can always know the progress of the current Pod "deployment". The complete process of creating, scheduling, binding nodes of a Pod and launching the corresponding container on the target Node takes some time, so we expect the system to launch the target state of N Pod copies, which is actually the final state caused by a continuously changing "deployment process".

Typical usage scenarios for Deployment are as follows:

Create a Deployment object to generate the corresponding Replica Set and complete the process of creating a copy of Pod. Check the status of the Deployment to see if the deployment action is complete (whether the number of Pod copies reaches the expected value). Update the Deployment to create a new Pod (such as a mirror upgrade). If the current Deployment is unstable, roll back to an earlier version of Deployment. Pause Deployment in order to modify multiple Pod Template Spec configuration items at once, and then resume Deployment for a new release. Extend Deployment to cope with high loads. Check the status of the Deployment as an indicator of the success of the publication. Clean up older versions of ReplicaSet that are no longer needed.

The definition of Deployment is similar to that of Replica Set, except that the API declaration is different from the Kind type.

ApiVersion: extensions/v1beta1kind: Deploymentmetadata: name: nginx-deploymentapiVersion: v1kind: ReplicaSetmetadata: name: nginx-repset

Here is a complete example of a Deployment definition:

ApiVersion: extensions/v1beta1kind: Deploymentmetadata: name: frontendspec: replicas: 1 selector: matchLabels: tier: frontend matchExpressions:-{key: tier, operator: In, values: [frontend]} template: metadata: labels: app: app-demo tier: frontendspec: containers:-name: tomcat-demo image: tomcat imagePullPolicy: IfNotPresent ports:-containerPort: 8080

You can view the information of Deployment by using the command kubectl get deployment, and several of the parameters are explained as follows:

The expected value of the number of DESIRED::Pod copies, that is, the Replica defined in Deployment. CURRENT: the current value of Replica, if it is less than the expected value of DESIRED, creates a new Pod until DESIRED is reached. UP-TO-DATE: the number of copies of the latest version of Pod, indicating how many copies of Pod have been successfully upgraded during a rolling upgrade. AVAILABLE: the number of Pod replicas available in the current cluster, that is, the number of Pod currently alive in the cluster.

Pod management objects, in addition to RC, ReplicaSet, Deployment, but also DaemonSet, StatefulSet, Job and so on, are used in different application scenarios.

VI. Horizontal Pod Autoscaler

Like RC and Deployment, HPA is also a Kubernetes resource object. By tracking and analyzing the load changes of all target Pod controlled by RC or RS, determine whether it is necessary to adjust the number of copies of the target Pod.

HPA can be used as a measure of Pod load in two ways:

CPUUtilizationPercentage application customized metrics, such as the corresponding number of requests per second (TPS or QPS) for the service.

CPUUtilizationPercentage is an arithmetic average, that is, the average of the CPU utilization that comes with all copies of the target Pod. The CPU utilization of a Pod is the current CPU usage of the Pod divided by its Pod Request. For example, if we define a Pod with a Pod Request of 0.4 and the current Pod of CPU usage of 0.2, its CPU utilization is 50%. In this way, we can calculate the arithmetic average of CPU utilization of all Pod copies controlled by RC or RS. If the value of CPUUtilizationPercentage exceeds 80% at a certain time, it means that the current number of Pod replicas may not be enough to support more requests, and dynamic expansion is needed. When the peak period of requests passes, the CPU utilization of Pod will drop again, and the corresponding number of Pod replicas should be automatically reduced to a reasonable level.

Here is a concrete example of a HPA definition:

ApiVersion: autoscaling/v1kind: HorizontalPodAutoscalermetadata: name: php-apache namespace: defaultspec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: kind: Deployment name: php-apache targetCPUUtilizationPercentage: 90

Control Pod replicas of php-apache through HPA. When the CPUUtilizationPercentage value of Pod replicas exceeds 90%, the number of Pod replicas will be automatically increased, and the number of Pod replicas should be between 2 and 10 during capacity expansion or reduction.

In addition to defining HPA objects through yaml files, you can also create them as commands:

Kubectl autoscale deployment php-apache-cpu-percent=90-min=1-max=10

7. StatefulSet

Pod's management objects RC, Deployment, DaemonSet and Job are all stateless services, but in practice, many services are stateful, such as Mysql cluster, MongoDB cluster, ZooKeeper cluster and so on. StatefulSet can be used to manage stateful services.

StatefulSet has the following features:

Each Pod in StatefulSet has a stable, unique network identity that can be used to discover other members of the cluster. Suppose the name of StatefulSet is kafka, then the first Pod is kafka-0, the second is kafka-1, and so on. The start-stop order of the Pod copy controlled by StatefulSet is controlled, and when the nth Pod is operated, the first Pod is already running and ready. Pod in StatefulSet uses stable persistent storage volumes, which is realized through PV/PVC. When deleting Pod, StatefulSet-related storage volumes are not deleted by default (to ensure data security).

In addition to being bundled with PV volumes to store Pod state data, StatefulSet is also used with Headless Service, that is, which Headless Service it belongs to is declared in the definition of each StatefulSet. Headless Service differs from a normal Service in that it does not have a Cluster IP. If the DNS domain name of a Headless Service is resolved, the Endpoint list of all Pod corresponding to that Service is returned. In addition to Headless Service, StatefulSet creates a DNS domain name for each Pod instance controlled by StatefulSet. The format of this domain name is:

$(podname). $(headless service name)

For example, for a 3-node kafka StatefulSet cluster, if the name of the corresponding Headless Service is kafka,StatefulSet and the name is kafka, then the DNS names of the three Pod in the StatefulSet are kafka-0.kafka, kafka-1.kafka and kafka-3.kafka, respectively. These DNS names can be fixed directly in the configuration file of the cluster.

8. Service (service)

1. Overview

In fact, Service is a "micro-service" in the micro-service architecture that we often talk about, and resource objects such as Pod and RC are actually "married" for it. The logical relationship between Pod, RC, or RS and Service is shown in the following figure.

From the figure above, we can see that the Service of Kubernetes defines an access entry address for the service. The front-end application (Pod) accesses a group of cluster instances composed of Pod replicas behind it through this entry address, and the "seamless docking" between Service and its back-end Pod replica cluster is achieved through Label Selector. In fact, the function of RC is to ensure that the service capability and quality of Service are always in the expected standard.

By analyzing, identifying and modeling all the services in the system as micro-services-Kubernetes Service, our system is finally composed of several micro-service units that provide different business capabilities but are independent of each other. The services communicate with each other through TCP/IP, thus forming a powerful and flexible elastic cluster with strong distributed ability, flexible expansion ability and fault tolerance. As a result, our system architecture has become much simpler and more intuitive.

Since each Pod is assigned a separate IP address, and each Pod provides a separate Endpoint (Pod IP+ContainerPort) to be accessed by the client, and multiple Pod replicas form a cluster to provide services, how can the client access them? The general practice is to deploy a load balancer (software or hardware), but this undoubtedly increases the workload of operations and maintenance. Service (service) is used in the Kubernetes cluster, which provides a virtual IP address (Cluster IP) and port number. Any service in the Kubernetes cluster can access this service through the Cluster IP+ port, and the kube-proxy running on each Node is responsible for which Pod the access request will eventually be forwarded to. The kube-proxy process is actually an intelligent software load balancer, which is responsible for forwarding the request for Service to a Pod instance at the back end, and internally implementing the load balancing and session persistence mechanism of the service.

Here is a simple definition of Service:

ApiVersion: v1kind: Servicemetadata: name: tomcat-servicespec: ports:-port: 8080 selector: tier: frontend

The above defines a Service named "tomcat-service", which has a service port of 8080 and has all Pod instances of the Label "tier=frontend".

Many services have the problem of multiple ports, usually one port provides business services, and the other port provides management services, such as Mycat, Codis and other common middleware. Kubernetes Service supports multiple Endpoint, and each Endpoint is required to define a name to distinguish. The following is a sample Service definition of tomcat multi-port.

ApiVersion: v1kind: Servicemetadata: name: tomcat-servicespec: ports:-port: 8080 name: service-port-port: 8005 name: shutdown-port selector: tier: frontend

Why do multiple ports need to be named for each port? This involves the service discovery mechanism of Kubernetes.

Service Discovery Mechanism of 2.Kubernetes

The Service in each Kubernetes has a unique Cluster IP and a unique name, and the name is defined by ourselves, so can we access it through the name of Service?

In the earliest days, Kubernetes adopted the way of Linux environment variables, that is, each Service generated some corresponding Linux environment variables (ENV), and when each Pod container started, these environment variables were automatically injected to achieve the purpose of establishing a connection through the name of Service.

Considering that it is still not convenient and intuitive to obtain the IP and port of Service through environment variables, Kubernetes later introduced the DNS system through the way of Add-On value-added package, using the service name as the DNS domain name, so that the program can directly use the service name to establish a connection.

With regard to the deployment of DNS, I will explain the follow-up blog posts separately. Interested friends can follow my blog.

3. The problem of external system accessing Service

There are three IP addresses in the Kubernetes cluster, which are as follows:

The IP address of the Node IP:Node node, which is the IP address of the physical Nic. The IP address of the Pod IP:Pod, that is, the IP address of the docker container, which is the virtual IP address. The IP address of the Cluster IP:Service, which is the virtual IP address.

External access to a node or service in a Kubernetes cluster must communicate through Node IP.

Pod IP is a virtual layer 2 network IP address assigned by Docker Engine according to the IP address segment of the docker0 bridge. The access between Pod and Pod communicates through this virtual layer 2 network, while the real TCP/IP traffic flows out through the physical network card where the Node IP is located.

Service's Cluster IP has the following characteristics:

Cluster IP only acts on the object Service, and Kubernetes manages and assigns IP addresses. Cluster IP is a virtual address and cannot be ping. Cluster IP can only combine Service Port to form a specific communication port for internal access of Kubernetes cluster. Cluster IP alone does not have the basis of TCP/IP communication, and some additional work needs to be done if external access to this communication port is required. The communication among Node IP, Pod IP and Cluster IP adopts a special routing rule designed by Kubernetes itself, which is very different from the IP routing that we are familiar with.

If our application wants external access, the most common way is to use NodePort.

ApiVersion: v1kind: Servicemetadata: name: tomcat-servicespec: type: NodePort ports:-port: 8080 nodePort: 31002 selector: tier: frontend

NodePort is implemented by opening a corresponding TCP listening port for the Service that needs external access on each Node in the Kubernetes cluster. The external system only needs to use the IP address of any Node + the specific NodePort port number to access the service.

NodePort has not completely solved all the problems of external access to Service, such as load balancing, and it is common practice to deploy a load balancer outside the Kubernetes cluster.

The Load balancer component is independent of the Kubernetes cluster and can be a hardware load balancer or a software implementation, such as HAProxy or Nginx. This way undoubtedly increases the workload of operation and maintenance and the probability of error.

So Kubernetes provides an automated solution. If we use Google's GCE public cloud, we only need to change type: NodePort to type: LoadBalancer, and Kubernetes will automatically create a corresponding Load balancer instance and return its IP address for external clients to use. Other public cloud providers can do the same as long as they implement drivers that support this feature.

9. Volume (storage volume)

Volume is a shared directory in Pod that can be accessed by multiple containers. Volume is defined on Pod and is mounted to a specific file directory by multiple containers in a Pod. When the container is terminated or restarted, the data in Volume will not be lost. Kubernetes supports many types of Volume, such as GlusterFS, Ceph and other distributed file systems.

In addition to allowing multiple containers in a Pod to share files, write container data to host disk or write files to network storage, Kubernetes also provides centralized definition and management of container configuration files through ConfigMap objects.

Kubernetes supports a variety of Volume types, which we will introduce one by one.

1.emptyDir

EmptyDir is created when Pod is assigned to Node. Its initial content is empty, and there is no need to specify the corresponding directory file on the host. It is a directory automatically assigned by Kubernetes. When Pod is removed from Node, the data in emptyDir will be permanently deleted.

The uses of emptyDir are as follows:

Temporary space, such as a temporary directory for some applications to run, and does not need to be saved permanently. A temporary save directory for the intermediate process CheckPoint of a long task. A container needs a directory (a multi-container shared directory) to get data from another container.

EmptyDir is defined as follows:

Template: metadata: labels: app: app-demo tier: frontend spec: volumes:-name: datavol emptyDir: {} containers:-name: tomcat-demo image: tomcat volumeMounts:-mountPath: / mydata-data name: datavol imagePullPolicy: IfNotPresent

2.hostPath

Use hostPath to mount files or directories on the host, which is mainly used in the following aspects:

When the log files generated by the container application need to be saved permanently, you can use the host's file system storage. When you need to access the internal data of the Docker engine on the host, you can define the host directory of hostPath as the data storage directory of docker, so that the internal applications of the container can directly access the data files of docker.

When using hostPath, you need to be aware of the following:

The Pod on different Node mounts the directory of the local host. If you want different Node to mount the same directory, you can use network storage or distributed file storage. If resource quota management is used, Kubernetes cannot manage the resources it uses on the host.

HostPath is defined as follows:

Volumes:- name: "persistent-storage" hostPath: path: "/ data"

3.gcePersistentDisk

Using this type of Volume means using the permanent disk (PersistentDisk, PD) provided by Google Public Cloud to store data. There are some restrictions on using gcePersistentDisk:

Node needs to be a Google GCE CVM. These CVMs need to exist in the same GCE project and Zone as PD.

Create a PD with the gcloud command:

Gcloud compute disks create-size=500GB-zone=us-centrall-a my-data-disk

An example of a Volume that defines a gcePersistentDisk type is as follows:

Volumes:- name: test-volume gcPersistentDisk: pdName: my-data-disk fsType: ext4

4.awsElasticBlockStore

Similar to GCE, this type of Volume uses EBS Volume provided by Amazon public cloud to store data, and you need to create an EBS Volume before you can use awsElasticBlockStore.

Some of the restrictions on using awsElasticBlockStore are as follows:

Node needs to be an instance of AWS EC2. These AWS EC2 instances need to exist in the same region and availability-zone as EBS volume. EBS only supports a single EC2 instance mount and one volume.

Create an EBS volume with the aws ec2 create-volume command:

Aws ec2 create-volume-availability-zone eu-west-la-size 10-volume-type gp2

An example of a Volume that defines an awsElasticBlockStore type is as follows:

Volumes:- name: test-volume awsElasticBlockStore: volumeID: aws:/// fsType: ext4

5.NFS

When using the shared directory provided by the NFS network file system to store data, we need to deploy a NFS Server in the system.

An example of a Volume that defines a NFS type is as follows:

Volumes:- name: nfs-volume nfs: server: nfs-server.localhost path: "/"

6. Other types of Volume

Iscsi: Mount to Pod using the directory on the iSCSI storage device. Flocker: use Flocker to manage storage volumes. Glusterfs: Mount to Pod using the directory of the GlusterFS network file system. Rbd: Mount to Pod using Ceph block device shared storage (Rados Block Device). GitRepo: by mounting an empty directory and clone a git repository from the GIT library for Pod to use. Secret: a secret volume is used to provide encrypted information for Pod. The secret defined in Kubernetes can be mounted directly as a file for Pod to access. Secret volume is implemented through tmfs (memory file system), so this type of volume is not persisted. 10. Persistent Volume

The Volume mentioned above is defined on Pod and is part of "computing resource". In fact, "network storage" is a kind of physical resource that exists relatively independent of "computing resource". For example, in the case of using a CVM, we usually create a network storage first, then draw a "network disk" from it and mount it to the CVM. Persistent Volume (PV for short) and the associated Persistent Volume Claim (PVC for short) achieve similar functions.

The differences between PV and Volume are as follows:

PV can only be network storage, does not belong to any Node, but can be accessed on each Node. PV is not defined on Pod, but is defined independently of Pod.

The following is the yaml definition of NFS type PV, which declares that 5G of storage space is required:

ApiVersion: v1kind: PersistentVolumemetadata: name: pv003spec: capacity: storage: 5Gi accessModes:-ReadWriteOnce nfs: path: / somepath server: 172.17.0.2

The accessModes attribute of PV has the following types:

ReadWriteOnce: read and write permissions, and can only be mounted by a single Node. ReadOnlyMany: read-only permission, allowed to be mounted by multiple Node. ReadWriteMany: read and write permissions, allowed to be mounted by multiple Node.

If Pod wants to apply for PV resources, you first need to define a PersistentVolumeClaim (PVC) object:

ApiVersion: v1kind: PersistentVolumeClaimmetadata: name: myclaimspec: accessModes:-ReadWriteOnce resources: requests: storage: 5Gi

Then refer to the above PVC in the volume definition of Pod

Volumes:-name: mypd persistentVolumeClaim: claimName: myclaim

A PV is a stateful object that has the following states:

Available: idle state. Bound: has been bound to a PVC. Released: the corresponding PVC has been deleted, but the resources have not been reclaimed by the cluster. Failed:PV automatic recycling failed. Namespace (Namespace)

By "allocating" the resource objects within the Kubernetes cluster to different Namespace, different projects, groups or user groups are logically grouped, so that different groups can be managed separately while sharing the resources of the whole cluster.

After the Kubernetes cluster starts, it creates a Namespace called "default", which can be seen through kubectl:

Kubectl get namespaces

If Namespace is not specifically specified, user-created Pod, RC, RS, and Service are all created by the system into this default Namespace named default.

The following is an example of the definition of Namespace:

ApiVersion: v1kind: Namespacemetadata: name: development

Define a Pod and specify which Namespace it belongs to:

ApiVersion: v1kind: Podmetadata: name: busybox namespace: developmentspec: containers:-image: busybox command:-sleep-"3600" name: busybox

When you use the kubectl get command to view Pod status information, you need to add the-- namespace parameter to specify the resource object under which namespace to view. Without this parameter, the resource object under default will be viewed by default.

Kubectl get pods-namespace=development

When we create a Namespace for each tenant to achieve multi-tenant resource isolation, we can also combine the resource quota management of Kubernetes to limit the resources that different tenants can occupy, such as CPU usage, memory usage, and so on.

12. Annotation (Notes)

Annotation, like Label, is defined in the form of key/value key-value pairs. The difference is that Label has a strict naming convention, which defines the metadata (Metadata) of Kubernetes objects and is used for Label Selector. Annotation, on the other hand, is "additional" information arbitrarily defined by the user so that it can be found by external tools. Usually, the module of Kubernetes will mark some special information of the resource object by Annotation.

The information recorded using Annotation is as follows:

Build information, release information, Docker image information, such as timestamp, release id number, PR number, image bash value, docker registry address, etc. Address information of log library, monitoring library, analysis library and other resource libraries. Program debugging tool information, such as tool name, version number, etc. Contact information of the team, such as phone number, name of the person in charge, web address, etc.

Note: the content of this article is extracted from "Kubernetes authoritative Guide: full contact from Docker to Kubernetes practice (Commemorative Edition"), and some of the contents have been reduced, and some of the contents have been adjusted accordingly, which can help you deepen your understanding and definition of various resource objects of Kubernetes, follow my blog, and start a learning trip of K8s with me.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.