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

This article shares with you the content of a sample analysis of Kubernetes resource types. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Kubernetes is an open source container management platform for deploying and managing containerized workloads. When you run containers in a production environment, you will have dozens or even thousands of containers.

These containers need to be deployed, managed, and connected, which is difficult to do manually. That's what Kubernetes does. Think of it as a container scheduler.

Kubernetes is designed to work with Docker, a containerized platform that packages applications and all dependencies into one container.

For example: Docker is used to isolate, package, and transport applications as containers. Kubernetes is a container scheduler for deploying and extending applications.

With regard to Kubernetes, we can:

Deploy services and launch new versions without downtime

Run on private or public cloud

Place and scale a copy of the service on the most appropriate server

Verify the health of the service

Mount volumes for stateful applications

Now that we have reviewed Kubernetes, let's skip to some of its resources and discuss when to use them. Start with pods.

What is Pods?

Pod is the lowest or more atomic unit of an application in Kubernetes. It should be noted that in the Docker world, pod is not equal to a container. A pod can consist of multiple containers. If you have a pure Docker background, this can be difficult to understand.

Think of it as an Kubernetes abstraction, which represents a set of containers and their shared resources. For example, a Pod can include a container with a Node.js application and another container that provides data to the web server.

Pod is a way to represent processes that are running in a cluster.

If a pod can have multiple containers, how does it work? We need to pay attention to some restrictions. Pod has the following contents:

Single IP address

Shared host

Shared IPC space

Shared network port range

Shared Volum

Containers in pod communicate with each other through local hosts, while pod-to-pod communicates through services. As you can see from the figure, containers in pod share an IP address.

Pod is a good way to deploy an application, but there are some limitations to the pod resource type. Pod is a single entity, and if it fails, it cannot restart itself. This is not suitable for most use cases because we want the application to have high availability.

But Kubernetes has solved this problem, and we will take a closer look at how to deal with high availability in this article.

In Kubernetes, pod always runs on the node. You can think of a node as a working machine managed by the primary server. A node can have multiple pods, and the master node automatically arranges these pods on one node.

Pods principle

Pods is designed as a cohesive unit that runs multiple processes. These processes are packaged in containers. All the containers that make up the pod run on the same machine and cannot be split across multiple nodes.

All processes (or containers) in Pod share the same resource (such as storage), and they can communicate with each other through the local host. A volume is like a directory with shareable data. All containers can access them and share the same data.

Replication controller

We just learned that pods is going to die. If they die, that's how they end up. But what if you want to run three pod of the same version for high availability? That's what replication controller does.

The primary responsibility of replication controller is to prevent failure. It is on top of the pod resource type and controls it.

This feature addresses this problem with pods. However, it is important to note that replication controller does not deal with everything related to pods, that is, the lifecycle.

Suppose we want to upgrade pod without downtime. Replication controller will not be responsible for this operation.

Now that we know about pods, let's move on to the next Kubernetes resource: services.

What is Services?

If we want to connect to pods, we need to create a Service. In Kubernetes, Service is a set of network abstractions on pods. Think of it as a set of pods running on a cluster. Kubernetes services are typically used to support micro-service architectures.

Kubernetes provides a group of pods with their own IP address and a single DNS name, and can achieve load balancing between them. They provide the features of standardized clusters, such as:

Load balancing

Deployment with zero downtime

Service discovery between applications

It allows for load balancing of traffic in the event of a failure. A service allows Kubernetes to set up a single DNS record for pods. As mentioned earlier, each pod has a separate IP address. For service resource types, you usually define a selector like the following example:

In addition, kube-proxy creates a virtual IP in the cluster to access the service. The virtual IP is then routed to pod IP. If pod ip changes or deploys a new pods,service resource type, the changes are tracked and internal routes are updated on your behalf.

What is deployments?

Now it's the last part of the puzzle: deployments. The deployments resource type is on top of a replica set (ReplicaSet) and can be manipulated. In other words, deployments provides updates for the pods replica set.

To do this, you need to describe the desired state in deployments, and then the deployment controller will change to the desired state at a controllable speed. This allows you to run stateless applications. If you need to upgrade, you need to replace the replica set. This action will cause the application to shut down.

One of the main advantages of Kubernetes is high availability. Deployment enables us to upgrade without downtime. Specify the number of pods to run, as you did in the replication set.

Once the update is triggered, deployment performs a rolling upgrade of the pods, ensuring that each pod upgrade is successful, and then moves on to the next one.

Let's look at an example of deployment and see how they are created.

The output of the latter command is shown below.

So, what happens if we launch a new version of the application and something goes wrong? deployment also has a workaround, and we can easily roll back the deployment.

Here is a warning: if you are using pvc (persistent volume declaration) and write something in the declaration. This will not be reversed.

Deployment controls ReplicaSet, while ReplicaSet controls Pods. Therefore, when using the Deployment resource type, you still need a Service to access it.

Thank you for reading! This is the end of this article on "sample Analysis of Kubernetes Resource types". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.