Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what are the reasons for choosing Kubernetes as a Docker orchestration tool". In daily operation, I believe many people have doubts about the reasons for choosing Kubernetes as a Docker orchestration tool. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "what are the reasons for choosing Kubernetes as a Docker orchestration tool?" Next, please follow the editor to study!

Deployments

In the default settings in K8S1.1, Deployments is the alpha version. In 1. 2, when you start a new cluster, the Deployments feature opens the beta version and is considered stable and working.

Why deploying programs in K8S1.1 is so tedious (click here to read more: https://engineering.nanit.com/real-world-deployments-on-kubernetes-68fa81396dad#.rw2succxq), I won't go into the details here, the main points here are:

1. You have to calculate the unique value for each deployment yourself and put it in the Replication-Controller definition file.

two。 To create and update an existing Replication-Controller for the first time, you have to have a different process.

3. After you can configure a new version through scrolling updates, you have to find an existing Replication-Controller in the system.

Deployments began to gradually replace the Replication-Controller/ Rolling-Update program. Deployments is declarative, which is powerful: you don't have to tell the cluster what to do, you just declare what functionality you want, and the cluster dispatches everything it needs to make itself ideal. You don't have to calculate the unique value yourself, and you no longer need to find the existing configuration when you want to update it.

The official introduction guide uses kubectl create to create deployments and kubectl apply to update deployments. But from my personal experience, you can apply it in the above two cases, which means that you no longer need different programs to create and update.

The last great deployment feature is to support rollback. The rollback feature in K8S1.1 has been done by redeploying the old Replication-Controller. In K8S1.2, you can use recording Flag when you create a configuration. In this way, you will be allowed to roll back a configuration to the current version whenever you need it.

Support for multiple availability zones

Before the K8S1.2 version, one of the biggest drawbacks of K8S was its lack of support for extenders on different AZs. This means that your cluster only lives on a single AZ, and if something goes wrong with that AZ, you will lose your entire cluster. The only way to handle these failures is to manage multiple clusters, but the cost of doing so is unaffordable.

K8S1.2 brings the full support of Multi-AZ. You can easily generate nodes in any AZ, and the scheduler is fully aware that different nodes schedule your pods.

Although this is a significant improvement in this area, Multi-AZ support does not apply to K8S and its components. Your cluster still exists in an AZ, and if the AZ goes down, you will fall into a strange state: the cluster is fully functional but the cluster won't, which means you can't handle deploy operations, and so on.

K8S1.2 brings full support for Multi-AZ. You can easily resurrect on any AZ, and the scheduler knows this when dispatching your pods to different nodes.

This is a great improvement in this area, because support for Multi-AZ applies not only to K8S master and its components. Your Master also runs on a single AZ, and if the AZ fails, you will fall into a bad state: the cluster will all work, but the master will not, which means you can't handle the operation if you want to configure it.

ConfigMaps & secrets as an environmental variable

K8S1.1 has a built-in option to configure through Secrets storage. However, it is still recommended to use Secrets to store sensitive data, and ConfigMap allows us to store insensitive data configurations in a more direct and convenient way.

One of the great adjustments in K8S1.2 is that Secrets and ConfigMap can be used not only as data volumes (the only option in K8S1.1), but also as environment variables for your definition files. It is more convenient than loading data volumes and reading files on the application, just to get a simple configuration project.

Daemon-Sets

Having a K8S cluster sometimes makes us forget that we have nodes in the cluster. We create containers, but most of the time we don't even know which node they are running on.

Although there are times when we need to deal with some node-related tasks when we know. An example is an application that collects statements from a node and then transfers them to some measurement server. Another example is to collect all logs from all containers running on the node and send them to our login system. In these examples, we need a single container running each node.

K8S1.1 simply provides us with static pods to do this. In order to define a static pod, we may have to define it with pod under a specific folder on each node. This is obviously inconvenient because:

1. If we want to add static pods, we have to warn every node running on the cluster.

2. Static pods is managed locally by kubelet, so we cannot query API or do anything else with them.

K8S1.2 introduces Daemon-Sets, which gives us a more convenient way to run a pod on each node. The pods in Daemon-Sets is visible, just like any other pod in the system. You can delete a Daemon-Set and create the Daemon-Sets you want through API. There is no need to change the file on the node.

Cluster size and performance

Cluster size is a very important issue for a company, which has the right to determine the core infrastructure. We will never know how big we will be a year from now, but we need to be 100% sure that the tools we choose now will not limit us in the future.

The official version 1.2 supports 1000 nodes per cluster and 30000 pod running at the same time.

However, these numbers can be good or bad (depending on your subjective will), and it's encouraging to see what process the team is running. 1.2 has an X10 zoom improvement over the 1.1 release.

Look forward to seeing a higher number on 1.3.

Jobs

Jobs allows you to run pods and successfully complete a certain number of pods. In K8S1.1, we can create naked pods (without Replication-Controller), but these pods are not guaranteed to be completed at all. For example, if a node running pod is restarted during execution, pod will not be restarted on another node. By verifying the job we completed, we confirm that the above situation will not happen.

Although this is not a world-changing feature, it is definitely a useful feature!

Project process

In addition to the features and improvements described above, it is easy to notice the great progress since version 1.1. Each issue is a matter of hours and is prioritized by the owner. The long-awaited function is about to be realized. More and more contributors are joining the big party to help improve the project, expand and discuss these issue by submitting code. This is probably one of my favorite OSS projects.

At this point, the study on "what are the reasons for choosing Kubernetes as a Docker orchestration tool" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.