You can examine the routing rules at the gateway that connects all the nodes and you won’t find any routes for this network. You can ifconfig to your heart’s delight and you will not find any devices configured with addresses on this network. Now look at the service network 10.3.240.0/20. Those are the virtual ethernet interfaces for each pod and the bridges that connect them to each other and the outside world. If you go looking on the hosts that make up the nodes in your cluster, listing bridges and interfaces you’re going to see actual devices configured with addresses on this network.
Consider the pod network address range 10.0.0.0/14. Like the pod network the service network is virtual, but it differs from the pod network in some interesting ways. $ kubectl describe services service-test Name: service-test Namespace: default Labels: Selector: app=service_test_pod Type: ClusterIP IP: 10.3.241.152 Port: http 80/TCP Endpoints: 10.0.1.2:8080,10.0.2.2:8080 Session Affinity: None Events: There are other types of services, and I’ll talk about a couple of them in the next post on ingress, but ClusterIP is the default and it means “the service will be assigned an IP address reachable from any pod in the cluster.” You can see the type of a service by running the kubectl describe services command with the service name. The network specified by this address space is called the “service network.” Every service that is of type “ClusterIP” will be assigned an IP address on this network. If you’re running in Google Container Engine you can do this: $ gcloud container clusters describe test | grep servicesIpv4Cidr servicesIpv4Cidr: 10.3.240.0/20 The same is true of the service network address range. In the first post I noted that the pod network address range is not exposed via kubectl and so you need to use a provider-specific command to retrieve this cluster property. It’s also not the same as the private network the nodes are on, which will become clearer below. The IP that the test service was assigned represents an address on a network, and you might have noted that the network is not the same as the one the pods are on. If your goal is to understand how this actually works then a good place to start is with that IP address that our service was assigned. You can continue to run the client pod and you’ll see responses from both server pods with each getting approximately 50% of the requests. $ kubectl logs service-test-client2 HTTP/1.0 200 OK Hello from service-test-6ffd9ddbbf-kf4j2 The kubernetes designers solved this problem in an elegant way that builds on the basic capabilities of the platform to deliver on all three of those requirements, and it starts with a resource type called a service.Īfter this pod runs to completion the output shows that the service forwarded the request to one of the server pods. This implies a few requirements for the proxy: it must itself be durable and resistant to failure it must have a list of servers it can forward to and it must have some way of knowing if a particular server is healthy and able to respond to requests. Clients connect to the proxy and the proxy is responsible for maintaining a list of healthy servers to forward requests to. You will probably have recognized this as an old problem, and it has a standard solution: run the traffic through a reverse-proxy/load balancer. You can use a pod IP address as an endpoint but there is no guarantee that the address won’t change the next time the pod is recreated, which might happen for any number of reasons. That’s because pods in kubernetes are ephemeral. Pod networking in a cluster is neat stuff, but by itself it is insufficient to enable the creation of durable systems. If you aren’t already familiar with how pods communicate then it’s worth a read before continuing.
#WHAT IS KUBERNETES NETWORKING SERIES#
In the first post of this series I looked at how kubernetes employs a combination of virtual network devices and routing rules to allow a pod running on one cluster node to communicate with a pod running on another, as long as the sender knows the receiver’s pod network IP address. Understanding kubernetes networking: services
0 kommentar(er)
