官术网_书友最值得收藏!

Advanced services

Let's explore the IP strategy as it relates to services and communication between containers. If you recall, in the Services section of Chapter 2, Pods, Services, Replication Controllers, and Labels, you learned that Kubernetes is using kube-proxy to determine the proper pod IP address and port serving each request. Behind the scenes, kube-proxy is actually using virtual IPs and iptables to make all this magic work.

kube-proxy now has two modes—userspace and iptables. As of now, 1.2 iptables is the default mode. In both modes, kube-proxy is running on every host. Its first duty is to monitor the API from the Kubernetes master. Any updates to services will trigger an update to iptables from kube-proxy. For example, when a new service is created, a virtual IP address is chosen and a rule in iptables is set, which will direct its traffic to kube-proxy via a random port. Thus, we now have a way to capture service-destined traffic on this node. Since kube-proxy is running on all nodes, we have cluster-wide resolution for the service VIP (short for virtual IP). Additionally, DNS records can point to this VIP as well.

In the userspace mode, we have a hook created in iptables, but the proxying of traffic is still handled by kube-proxy. The iptables rule is only sending traffic to the service entry in kube-proxy at this point. Once kube-proxy receives the traffic for a particular service, it must then forward it to a pod in the service's pool of candidates. It does this using a random port that was selected during service creation.

Refer to the following diagram for an overview of the flow:

Kube-proxy communication
It is also possible to always forward traffic from the same client IP to the same backend pod/container using the sessionAffinity element in your service definition.

In the iptables mode, the pods are coded directly in the iptable rules. This removes the dependency on kube-proxy for actually proxying the traffic. The request will go straight to iptables and then on to the pod. This is faster and removes a possible point of failure. Readiness probe, as we discussed in the Health Check section of Chapter 2, Pods, Services, Replication Controllers, and Labels, is your friend here as this mode also loses the ability to retry pods.

主站蜘蛛池模板: 滦南县| 明溪县| 普格县| 鄱阳县| 米易县| 天等县| 宜兴市| 永泰县| 凉城县| 孝感市| 保定市| 应用必备| 秦安县| 玛纳斯县| 团风县| 陇南市| 清水县| 金寨县| 密云县| 田东县| 体育| 什邡市| 宁河县| 沈丘县| 衢州市| 故城县| 武义县| 鹿邑县| 武宣县| 昭觉县| 永昌县| 方正县| 理塘县| 浏阳市| 黎城县| 凤庆县| 湖北省| 凤阳县| 商洛市| 丰县| 宜州市|