In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-29 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)05/31 Report--
This article will explain in detail how the Service in Kubernetes works. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.
Service is an abstract resource of Kubernetes access layer, which provides us with a fixed and unified access interface address and load balancing capability. at this time, we may think that when we used docker-compose, there was no concept of Service, didn't it also run? Yes, Pod ip is also interconnected within the Kubernetes cluster, but the ip of Pod often leads to client access errors due to expansion and reconstruction. Pod access cannot provide load balancer capability, while Service can directly access Pod by selecting a group of label of Pod, and can use a domain name that remains unchanged for thousands of years, so it chooses Service.
1. How does Service come into being and how does it exist within the cluster?
In kubernetes, the so-called Service is the kube-proxy generation iptables or ipvs rule, which produces a set of virtual addresses that are valid in a clustered environment. The Service cannot go directly to the inside of the Pod, and there is an interval between EndPoints, which is a combination of ip and port. The default type is ClusterIP, which can only receive access requests from pod client programs in the cluster. This is also the most commonly used type, as well as NodePort, LoadBalancer, and ExternalName.
2. Iptables or ipvs, is it iptables or ipvs? A Service object is some iptables or ipvs rules on the worker node that are used to forward traffic dispatching to the IP address of the Service object to the IP address and port pointed to by the corresponding Endpoints object. We often see this sentence, how to understand it?
Kubernetes1.1 was previously implemented based on userspace. Under this model, each request traffic first reaches the kernel space, is forwarded to kube-proxy through a socket, and then sent back to the kernel space, and then dispatched to the backend pod. It can be seen that requests are forwarded back and forth in user space and kernel space, which is bound to be inefficient. But when the pod does not respond, it can be automatically redirected to another pod.
Iptables rules were introduced in the Kubernetes1.1 version, and Kubernetes1.2 began to become the default type. That is, when a Service resource is created, the kube-proxy of each node on the cluster is notified and an iptables rule is created for traffic forwarded to this Service ClusterIP. Working TCP/IP transport layer, efficient and stable.
However, this approach has the following disadvantages: 1. When the pod selected in the iptables proxy model is unresponsive, it cannot be automatically redirected to other pod resource objects within the cluster.
2. Kube-proxy handles the interaction between Service and pod through iptables. Every time a computing node or a large number of pod is generated, it is necessary to generate a large number of iptables rules. It is not difficult to imagine that each time these iptables rules need to be refreshed to ensure correctness, they need to take up a lot of CPU resources, so the implementation of Service based on iptables has become a bottleneck restricting Kubernetes to carry more pod.
The ipvs model is used by default at the beginning of Kubernetes1.11. Under this model, kube-proxy will track the changes of Service and endpoints objects on APIServer, call netlink to create ipvs rules, and the request scheduling function is implemented by ipvs. The hook function runs on netfilter, which has the characteristics of fast traffic forwarding and good synchronization of rule performance. It supports many scheduling algorithms, and the rest is still completed by iptables. At this point, we can roughly understand the role and relationship between iptables and ipvs.
3. Kubernetes's service discovery is implemented through dns, so why are there four types of service exposure? When it comes to Service, we have to introduce kubernetes network model and communication mode.
A complete Kubernetes cluster should contain three layers of networks. The first layer is the network between mater and node nodes, which needs to be configured before deploying the kubernetes cluster. The second layer network is pod's network implemented through kubelet or cni plug-ins for communication between or within pod. All pod in the cluster are in the same network plane space and can communicate directly. The layer 3 network is the network of Service resources, which is a virtual network that is used to configure the IP address for the Kubernetes cluster, but this address is not configured on the network interface of any host or container, but is configured as an iptables rule through kubeproxy to schedule all traffic destined for this address to the back-end pod.
There are four ways to communicate:
Internal communication of the same pod
Pod communicate with each other
Communication between pod and service
Traffic from outside the cluster to service.
Therefore, in order to satisfy these communication methods, Service has the following types: ClusterIP: service for exposing ip addresses within the cluster, which is accessible only within the cluster, but not accessible by external ip. The default Service type is
NodePort: this type is based on clusterIp and serves the IP address of a node. External nodes can be accessed directly through NodeIP:NodePort.
LoadBalancer: this type is built on top of NodePort and can be associated with a load balancing device outside the cluster. Kubernetes does not provide LoadBalancer support for privatized clusters. A self-built load balancer is required if you use it in a privatized cluster
ExternalName: it exposes the service by mapping Service to the hostname specified by the contents of the externalName field, which needs to be resolved by the DNS service to a record of type CNAME. How do you understand this sentence?
For example, all your services are within the cluster, but you have a database that is mongodb, which is not containerized, let alone deployed inside Kubernetes. Of course, you can access this external service by adding configuration in ConfigMap, but when your environment changes, such as different data addresses from development environment and production environment, you need to modify and rebuild ConfigMap. At this point, you can use the Kubernetes ExternalName built-in service discovery mechanism to apply services running outside the cluster, using external services just like those in the cluster! In this way, you can achieve the same functionality in both the development environment and the production environment, and if you eventually move the service into the cluster, you do not need to change any code or configuration.
Kind: ServiceapiVersion: v1metadata: name: mongospec: type: ExternalName externalName: mango123456.com you only need to visit: mongodb://:@mongo: to automatically access external services.
4. Service itself has ports, Pod has ports, and containers have ports. What is the relationship between them?
ContainerPort: an informational data that provides a way for the cluster to quickly learn about the relevant pod access ports, and explicitly specify the container port, whether you specify it or not does not affect the client pod on other nodes to access it.
Port: service provider port for service access within the kubernetes cluster
TargetPort:pod target port. If the default port port is not set, the data of port and nodePort will enter into the Pod through this port, and the port of containers in Pod will be mapped to this port to provide services.
Access port for users outside the nodePort:Kubernetes cluster; this is all about how Service in Kubernetes works. I hope the above content can be helpful to you and learn more. 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.
Views: 283
*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.