Kubernetes is a very complex platform, with a lot of online documentation, but a lot of clutter. Kubernetes. IO above there is an official document, but many students will be confused when they see the official document, because the document content is much, and the density is very large, it is difficult to grasp the key concept, but only to understand the core concept of Kubernetes, And in the brain to establish the concept of the Kubernetes platform model, in order to use the Kubernetes.
To this end, I put this Kubernetes most basic core concept to comb out, the following in turn to explain to you.
The first core concept of Kubernetes is called Cluster. The cluster consists of many nodes, and more nodes can be added as needed. The nodes can be physical machines or virtual machines, and each node has a certain amount of this CPU and memory capacity.
The entire Kubernetes cluster can be abstracted as a supercomputer whose CPU and memory capacity is the sum of the CPU and memory capacity of all nodes. And more CPU and memory can be added to the supercomputer as needed.
Container Kubernetes is a Container scheduling platform, so containers are a basic concept of Kubernetes platform. It’s not hard to understand containers, but there are two key points, one is packaging mechanism, and behind it is container Image, Image mechanism. The other is isolation, which is implemented by Linux Namespace and CGroups mechanisms.
Containers are often translated into the metaphor of this container, which is figuratively used to pack and transport goods, and can be isolated from each other.
In my mind, I always associate this container with the goods at home. The goods cabinet can hold all kinds of things, and they are separated from each other. Software containers are used to package and run applications, which can run applications in various language stacks, separated by a lightweight mechanism known as Linux Namespace and CGroups.
From the perspective of the host operating system, containers are actually processes. So from the container’s internal perspective, it feels like a complete operating system, with its own file system, network, CPU, Memory and other resources, and the container is an instance of a mirrored runtime.
Mirror it is the OS file system, plus the application files, plus a package of dependencies. An image can be thought of as a template for a container, which is the second conceptual container.
POD Let’s look at the third concept POD. Kubernetes does not dispatch containers directly, but encapsulates a concept called POD. A POD can run in one or more containers. They share the file system and network of the POD. Each POD has its own IP address. Containers in pods share this IP and port space and can access each other through this localhost.
In most cases, there is only one application container inside a POD. Kubernetes does not schedule the Docker container directly, but adds the POD package. One reason is to consider scenarios that require auxiliary containers. Let’s say there are some scenarios that require this sidecar. Another reason is to consider using different container technologies instead.
ReplicaSet so let’s look at another concept called replicas. When an application is released, it will not ship only one POD instance, but many POD instances to achieve this high availability. Replicaset is a concept that corresponds to aset of pods for an application.
It can use a template, usually a YAML or JSON file specification template, to specify the container’s image, port, replica number, ignition and health check mechanism, environment variables, volume mount, and so on for an application.
While running, ReplicaSet monitors and maintains the number of pods. If it has too many, it takes some offline, and if it has too few, it starts more.
It is worth mentioning that Kubernetes had a similar concept called ReplicationController before, but this concept has been gradually abandoned and replaced by This Rebeccaset. This is the replica set.
The concept of POD is ephemeral in Kubernetes, which means that it is not fixed, The POD may hang or restart at any time, either unexpectedly or unexpectedly.
The corresponding IP address will change along with it. If the IP address of a service instance is not fixed, it may change at any time. So how does the consumer of the service address it? Kubernetes addresses this problem by introducing this Service abstraction.
To put it simply, Service is to mask the details of IP addressing and load balancing of the application. Consumers can access the target Service with no name. The underlying mechanism of Kubernetes Service does the addressing and load balancing. Even if the POD IP of the application changes, the Service will be shielded from such changes, so that the consumer is unaware of the Service. Order is a very important concept in Kubernetes.
Publishing collections of Deplment replicas can be considered a basic publishing mechanism. From this ReplicaSet set, basic application publishing can be implemented, as well as advanced publishing functions such as canary, blue and green, and scroll publishing. But using this ReplicaSet to do these advanced functions can be cumbersome. In order to simplify these advanced distributions, Kubernetes introduces the concept of Deployment on the basis of ReplicaSet.
In a nutshell, Deployment manages the ReplicaSet and implements advanced publishing mechanisms such as blue-green and scroll. The following figure shows an example of rolling publishing through Deployment scheduling.
Assume that a green version of the application has been released, and the corresponding ReplicaSet is V1.0. We can then upgrade to release the V1.1 version of the application through this Deployment. Deployment will then create ReplicaSet V1.1, and Deployment will schedule it in turn, pulling the blue version in and the green version out, until all blue pods are online and all green pods are offline. In this process, the Service abstraction will mask the application address change, so that the consumer Client is unaware. If there is a problem with the blue POD during the rollout process. If the ignition health check is not passed, the Deployment will automatically terminate and the release will be rolled back. Even if the release is successfully completed, the release personnel can still use this Deployment to fall back to a previous release if necessary. So Deployment is a more flexible release mechanism.
In particular, Deployment and Service fit the two most important concepts related to application release. These are two concepts that are often used during the release process.
When we publish the application, the Deployment and Service specifications are mainly in the release description file we write. So these two concepts have to be understood completely.
Let me summarize these two important concepts. Deployment is a concept based on ReplicaSet, which is created by Deployment when an application is published. ReplicaSet creates POD instances of the application according to the specification and maintains and ensures the number of instances. When upgrading, Deployment creates a new ReplicaSe and schedules rolling releases, which can also roll back these functions.
The figure above shows the Deployment of two applications A and B, managed and controlled by two Deployment and ReplicaSe groups respectively. Service is the concept of mutual routing and addressing between services. First, the enterprise Client inside Kubernetes cluster indirectly accesses the target application POD through Service. Second, Kubernetes cluster external clients, if the cluster application POD access, also indirectly through the Service.
ConfigMap VS Secret
When the micro service goes online, it is often necessary to set some variable configurations. These configurations may have different values for different environments. Some of these configurations are configured once at startup, such as the database connection string, and some of these configurations can be dynamically adjusted at runtime, such as the expiration TTL value of the cache, the sales limit of the business promotion, and so on.
Therefore, microserver needs the support of configuration center to achieve this flexible dynamic configuration for different environments. The Kubernetes platform has built-in support for microserver configuration, a concept called ConfigMap. The developer writes the configuration to this ConfigMap. Kubernetes supports injecting the configuration from the ConfigMap into the POD in the form of environment variables. This allows POD applications to access these configurations in the form of environment variables.
ConfigMap also supports the ability to mount a Volume to a POD so that POD applications can access configuration files that are sensitive to sensitive data, such as user names, passwords, and security certificates. Kubernetes supports the configuration of sensitive data through the concept of Secret. Secret can be thought of as a special kind of Config that provides a more secure configuration storage and access mechanism.
DaemonSet
One of the most common scenarios in incognito is to have a daemon on each node. For example, in monitoring scenarios, a Fluentd log collection process or Prometheus’s exporter process needs to be deployed on each machine. For this scenario, Kubernetes supports a publishing concept called DaemonSet. It is possible to deploy a daemon POD on each Woker node and ensure that there is only one POD on each node. This is introduced by DaemonSet.
So these are the most basic and important concepts in Kubernetes. If you master the concepts above, then the basic application of Kubernetes should be said to be no problem, basically can cover most of the application scenarios of Kubernetes. In addition to the above core concepts, Kubernetes has some other concepts for reference, and I have listed them together.
The Volume storage Volume can be used as disk file storage. It can be used as local or remote file storage on a node. After being mounted to a Mount, the Volume becomes part of the POD. However, the storage behind the Volume support can still exist.
PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume PersistentVolume A persistent volume, short for PV, is an advanced storage resource abstraction. It can connect to various cloud storage devices and is generally configured by a cluster administrator. If you think of the Kubernetes cluster as a supercomputer, then PV can be thought of as a superdisk that can be plugged into the supercomputer. If the Volume is mounted using PV, the data on the Volume will continue to exist even after the POD is restarted.
PersistentVolumeClaims is the specification that needs to be filled out when applying for a PV, including disk size and type. Ah, PVC for short. The application applies for the PV resource through the PVC. Then mount it to the POD as a Volume. The introduction of PV further decouples the Volume from the physical storage.
StatefulSet, as its name suggests, is a publishing mechanism that supports stateful applications. Such as MySQL database or Redis cache distribution. It’s the opposite of ReplicaSet, where StatefulSet is a stateful publication, and ReplicaSet is a publication that supports stateless applications.
Job is simple, it supports a one-run finish task.
A CronJob is a task that supports periodic running.
Summary Cluster Cluster, simple can be understood as a large computer abstract by the node composition.
Container Container applications live and run in containers.
POD is the basic scheduling unit of Kubernetes.
ReplicaSet creates and manages PODS and supports the distribution of stateless applications.
Service is the application POD access point, IP address blocking and load balancing.
Deployment Management ReplicaSet supports rolling these advanced publishing mechanisms.
Secrets ConfigMap is a common configuration, and Secrets is a sensitive data configuration.
DaemonSet, which ensures that there is only one such POD on each node, often used for monitoring.
StatefulSet is similar to ReplicaSet, but supports stateful applications.
Job Indicates a task that ends after running once.
CronJob Indicates the periodic running task.
Volume Indicates the disk file storage that can be loaded. PrsistentVolume/PersistentVolumeClaims large disk storage of an abstract, and the corresponding distribution mechanism.