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

This article mainly explains "detailed introduction of Kubernetes". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the detailed introduction of Kubernetes.

11 parts of Kubernetes 1. Pod

Pod is the smallest interactive unit in Kubernetes. A Pod can consist of multiple containers that are deployed together on a single node to form a unit. An Pod has an IP, and the IP is shared between its containers.

In the microservice world, an Pod can be a single instance of a microservice that performs background work or service requests.

2. Node (node)

Node is a machine. They are the "bare metal" (or virtual machines) that Kubernetes uses to deploy Pod. Node provides Kubernetes with available cluster resources to maintain data, run jobs, maintain workloads, create network routes, and so on.

3. Label (label) and Annotation (Note)

Label is the way that Kubernetes and its end users are used to filter similar resources in the system, and it is also the glue that resources and resources "access" or associate with each other. For example, the Service that opens the port for Deployment. Whether it's monitoring, logging, debugging, or testing, any Kubernetes resource should be tagged for subsequent inspection. For example, label all Worker Pod in the system: app=worker, and then select them in the kubectl or Kubernetes API using the-- selector field.

Annotation is very similar to Label, but is often used to save metadata for different objects in free string form, such as "reason for change: security patch upgrade."

4. Service Discovery (service discovery)

As an orchestration system, Kubernetes controls many resources for different workloads and is responsible for managing the network of Pod, jobs, and all physical resources that require communication. To do this, Kubernetes uses ETCD.

ETCD is the "internal" database of Kubernetes, which is used by Master to get the location of all resources. Kubernetes also provides actual "service discovery" for services-all Pod uses a custom DNS server that parses the names of other services to obtain their IP addresses and ports. It is "out of the box" in the Kubernetes cluster and does not need to be set up.

5. ReplicaSet (replica set)

Although Pod is a physical running task, it is usually not enough to use a single instance. In order to be redundant and handle the load, Pod needs to be copied for some reason (such as "scaling"). To implement the layer responsible for extension and replication, Kubernetes uses ReplicaSet. This layer represents the desired state of the system in terms of the number of copies and maintains the current state of the system at any given time.

This is also where auto-scaling is configured to create additional copies when the system is under high load and to scale down when these resources are no longer needed to support the running workload.

6. DaemonSet (daemon set)

Sometimes, no more than one instance is required per node of the application. Log collectors such as FileBeat are a good example. In order to collect logs from each node, its agent needs to run on all nodes, but only one instance is needed for each node. Kubernetes's DaemonSet can be used to create such workloads.

7. StatefulSet (stateful set)

Although most microservices involve immutable stateless applications, there are exceptions. Stateful workloads depend on the reliable support of disk volumes. Although the application container itself can be immutable and can be replaced with newer versions or healthier instances, all copies still require data persistence. StatefulSet is used for the deployment of such applications that need to use the same node throughout the lifecycle.

It also retains its "name": the hostname in the container and the name of the service discovery in the entire cluster. The StatefulSet composed of three ZooKeeper can be named zk-1, zk-2 and zk-3, and can also be extended to more members zk-4, zk-5, etc. StatefulSets is also responsible for managing PersistentVolumeClaim (disks attached to the Pod).

8. Job (Task)

The Kubernetes core team considered most applications that use the orchestration system. Although most applications require continuous running to process server requests (such as Web servers) at the same time, it is sometimes necessary to generate a batch of jobs and clean them up after they are completed. For example, a mini serverless environment.

To do this in Kubernetes, you can use Job resources. As the name suggests, the job of Job is to generate a container to do a specific job and destroy it when it completes successfully. For example, a set of Worker reads jobs from a queue of data to be processed and stored. Once the queue is empty, the Worker is no longer needed until the next batch is ready.

9. ConfigMap (configuration mapping) and Secret (secret configuration)

If you are not familiar with the application list of twelve elements, please understand it first. A key concept of modern applications is that there is no environment and can be configured with injected environment variables. The application should be completely independent of its location. To implement this important concept in Kubernetes, you have ConfigMap. This is actually a list of key values of environment variables that are passed to the running workload to determine different runtime behaviors. In the same category, Secret is similar to normal configuration entries, except that it is encrypted to prevent the disclosure of sensitive information such as keys, passwords, certificates, and so on.

Personally, I think Hashicorp's Vault is the best way to use a secret configuration. Be sure to read the article I wrote last year about why Vault is part of the production environment, as well as another more technical article by one of my colleagues.

10. Deployment (deployment)

Everything looks good, Pod works fine, and if there is a ReplicaSet on the upper layer, it can scale according to the load. However, people are flocking to quickly replace applications with the new version. We want to build, test, and release on a small scale to shorten the feedback cycle. Using Deployments to deploy new software sustainably, this is a set of metadata that describes the new requirements of a particular running workload. For example, release new versions, bug fixes, and even rollbacks (another internal option for Kubernetes).

There are 2 main strategies for deploying software in Kubernetes:

Replacement-as the name suggests, replacing all loads with new requirements will naturally force downtime. This is helpful for quickly replacing resources in non-production environments.

Rolling upgrade-slowly replace the container with a new one by listening on two specific configurations:

A. MaxAvailable-- sets the percentage (or specific number) of workloads available when deploying the new version, 100% means "I have 2 containers, and I want to keep 2 alive to service requests when deploying"

B. MaxSurge-- sets the percentage (or number) of workloads deployed based on the current surviving containers, which means "I have X containers, deploy another X containers, and then start scrolling to remove the old containers."

11. Storage (Storage)

Kubernetes adds a layer of abstraction to the storage. Workloads can request specific storage for different tasks and even manage persistence beyond the Pod lifecycle. For brevity, read the author's previously published article on Kubernetes storage, focusing in particular on why it doesn't fully address data persistence requirements such as database deployment.

Conceptual understanding

Kubernetes is (and still is) designed and developed according to a number of guidelines, and every function, concept, and idea built into the system takes into account community factors. In addition, end users will be guided to use the system in some way, but this is not mandatory; best practices are also public, but as an open source free system, you can operate according to your own needs.

Each part of the API---oriented system is built with excellent documents and operable API to achieve interactivity. Core developers ensure that end users can make changes, queries, and updates so as not to block them or have unwanted filters.

Welcome wrappers-as a derivative of the previous point, Kubernetes welcomes tools and wrappers built on top of its API. As an original platform, Kubernetes was built in a very customizable way for others to use and further develop tools for different use cases. Some tools have become very famous and widely used, such as Spinnaker, Istio, and so on.

Declarative state-users are encouraged to use declarative descriptions rather than imperative descriptions in the system. This means that the state and components of the system are best described as code managed in some version control, such as Git, to avoid the hassle of manual modifications. As a result, Kubernetes reduces the difficulty of disaster recovery and makes it easier to share and transfer responsibilities between teams.

At this point, I believe that you have a deeper understanding of the "detailed introduction of Kubernetes", you might as well come to the actual operation! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.