Pod networking
1. Pod networking
The Kubernetes networking model relies heavily on IP addresses, because services, Pods, containers, and nodes all communicate using IP addresses and ports. And Kubernetes provides different types of load balancing to direct traffic to the correct Pods. Let’s review some of the basics of Pod networking. A Pod is a group of containers that shares storage and networking. This is based on the “IP-per-pod” model of Kubernetes, where each Pod is assigned a single IP address, and the containers within a Pod share the same network namespace, including that IP address. In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster. For example, let’s say a legacy application uses nginx as a reverse-proxy for client access. If the nginx container runs on TCP port 80, and the legacy application runs on TCP port 8000, the two containers appear as though they’re installed on the same machine because both containers share the same networking namespace. The nginx container will contact the legacy application by establishing a connection to “localhost” on TCP port 8000. This works well for a single Pod, but workloads can run in multiple Pods and can be composed of many different applications that need to talk to each other. So, how do Pods talk to other Pods? Each Pod has a unique IP address, just like a host on the network. On a node, Pods are connected to each other through the node's root network namespace, which ensures that Pods can find and reach each other on that virtual machine. The root network namespace is connected to the Node's primary NIC, network interface card. Using the node’s VM NIC, the root network namespace is able to forward traffic out of the node. This means that the IP addresses on the Pods must be routable on the network that the node is connected to. In GKE, nodes get their Pod IP addresses from address ranges assigned to the Virtual Private Cloud, or VPC, being used. VPCs are logically isolated networks that provide connectivity for resources deployed within Google Cloud, such as Kubernetes Clusters, and Compute Engine instances. A VPC can be composed of many different IP subnets in regions around the world. When you deploy a GKE cluster, you can select a VPC along with a region or zone. By default, a VPC has an IP subnet pre-allocated for each Google Cloud region in the world. The IP addresses in this subnet are then allocated to the compute instances that you deploy in the region. Then there are GKE cluster nodes, which are compute instances that GKE customizes and manages for you. These machines are assigned IP addresses from the VPC subnet that they reside in. Google Cloud offers something called an alias IP, which can configure additional secondary IP addresses or IP ranges on Compute Engine VM instances. VPC-Native GKE clusters automatically create an alias IP range to reserve approximately 4,000 IP addresses for cluster-wide services that you might want to create later. VPC-Native GKE clusters also create a separate alias IP range for your Pods. You’ll recall that each Pod must have a unique address, so this address space will be large. By default the address range uses a /14 block, which contains over 250,000 IP addresses. Google Cloud quota limits will prevent you from running 250,000 Pods in a single cluster, but the large IP address range allows GKE to divide the IP space among the nodes. Using this large Pod IP range, GKE allocates a much smaller /24 block to each node, which contains about 250 IP addresses. This allows for 1000 nodes, with over running 100 pods each, by default. This functionality allows you to configure both the number of nodes you expect to use and a maximum number of Pods per node. The nodes allocate a unique IP address from their assigned range to each Pod as it starts. Because the Pods' IP addresses are a part of the alias IP, GKE automatically configures your VPC to recognize this range of IP addresses as an authorized secondary subnet of IP addresses. This ensures the Pod’s traffic is permitted to pass the anti-spoofing filters on the network. Each node maintains a separate IP address space for its Pods, which means the nodes don’t need to perform network address translation on the Pod IP addresses. Pods can directly connect to each other by using their native IP addresses. Pod IP addresses are natively routable within the cluster's VPC network and other VPC networks connected to it by VPC Network Peering. The traffic from clusters is routed or peered inside Google Cloud but becomes NAT translated at the node IP address if it has to exit Google Cloud.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.