In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)05/31 Report--
This article will explain in detail the example analysis of capacity expansion and reliability in Kubernetes. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.
RC: elastic expansion and management of micro-services
If pods is a unit and deployment and services are abstraction layers, who is going to track the health of pods?
So RC came out like this.
After pods is deployed, they need to be expanded and tracked. The RC definition file has a baseline configuration for the number of pods, which are available at any given point. Kubernetes ensures that the required configuration options are always maintained by tracking the number of pods. It kills some pods, or creates some to satisfy the baseline configuration.
RC can track the health of pods. If a pod becomes hard to get, it will be killed and some new pod will be created. Because a RC essentially inherits the definition of pod, the YAML or JSON list may contain attributes for restart policies, container surveys, and health check endpoints.
Kubernetes supports automatic elastic expansion of pod based on CPU utilization, which is similar to automatic expansion of EC2 or GCE. At run time, RC can be operated to automatically expand the capacity of pods, based on a specific CPU utilization threshold. The maximum and minimum values of the number of pods can also be specified under the same command.
Flat Network: secret weapon
Network is also one of the complex challenges in the containerization process. The only way to expose a container to the outside world is to forward it through the host's port. But it gets complicated when you expand the container. Instead of leaving network configuration and integration to administrators, Kubernetes comes with a network model that is very easy to use.
Each node, service,pod, and container has an IP address. The IP address of the node is assigned by the physical router; combined with the assigned port, it becomes an endpoint to access the service orientation. Although it is not routable, Kubernetes services can also obtain IP addresses. All communication is generated on the basis of no NAT layer, which makes the network flat and transparent.
This model will bring some benefits:
All containers can communicate with each other without NAT
All nodes do not need NAT to communicate with all pods and containers in the cluster.
Each container sees the same IP address as any other container
The best thing about expanding pods through RS is that port mapping is handled by Kubernetes. All pods belonging to service are exposed to each node through the same port. Even if no pod is scheduled on a specific node, the request is automatically forwarded to the appropriate node.
This amazing function is realized through the combination of kube-proxy,iptables and etcd network agents. The current state of the cluster is maintained using etcd, which means querying through kube-proxy at run time. Bounce the request to the correct destination by operating the iptables,kube-proxy on each node.
Kube-proxy also handles the basic load balancing of services. Service endpoints are also managed using Docker links through environment variables. These variables are decomposed into ports, which are exposed through service. Kubernetes1.1 includes an option to use local iptables, which causes an 80% delay. This design eliminates CPU overhead, thus improving efficiency and scalability.
Persistence: bringing state to the container
The container is short-lived. When they move from one host to another, they do not contain status. Persistence is a must for product load. Any useful application has a database behind it.
By default, pods is also temporary. Every time they come back to life, they start in a blank state. It is also possible to set the data volumes shared by containers running in the same pod. Confirmed by emptyDir monilker, this is somewhat similar to the Docker data volume, where the host file system is exposed as a directory in the container. EmptyDir data volumes track the life cycle of pods. When the pod is deleted, the data volume is also deleted. Because these volumes only match the host, they are not available on other nodes.
In order to bring persistent data on pods, Kubernetes supports PV and PVC requests no matter which node they are scheduled on. PVC and PV share the relationship, just like pod and nodes. When a pod is created, it can contact a specific data volume through claim. PV can be based on a variety of plug-ins, such as GCE persistent hard disk, Amazon Elastic Fast Storage (EBS), Network File system (NFS), small computer system Interface (ISCSI), GlusterFS and RBD.
The workflow for setting up persistence includes configuring the underlying file system or cloud data volume, creating persistent data volumes, and finally, creating a claim to associate pod with data volumes. This decoupling method can completely separate pod from data volumes, or pod does not need to know the exact file system or the persistence engine that supports it. Some file systems, such as GlusterFS, can also be containerized, making configuration easier and easier.
Conclusion
Containers are no longer a new concept. Google has run most of its network-sized workloads in containers for decades. They learn lessons in this process, and integrate these lessons into the construction of Kubernetes, these lessons can also be transplanted to other choreography platforms, can also be transplanted to other orchestration tools. Kubernetes solved the problems faced by Google SRE a decade ago, which are affecting the way forward for container orchestration tools.
Most importantly, Kubernetes is already a focus in the container ecosystem, and it exists as if it were a valuable open source platform for other related services. Understanding the current role and role of Kubernetes is necessary to orchestrate the tool market.
This is the end of the article on "sample Analysis of expansion and Reliability in Kubernetes". 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, please 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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.