concept iptable in category kubernetes
This is an excerpt from Manning's book Core Kubernetes MEAP V02.
Kube-proxy handles the creation of ClusterIp and NodePort services on every Node. ClusterIP is a Kubernetes service, which automatically loads-balances Kubernetes Pods. NodePort is an open port on a Kubernetes Node that load balances multiple Pods. This proxy may or may not be installed, as some installers replace it with there own network component that handles service management. Kubernetes permits multiple Pods of the same type to be proxied by a service. For this to work, every Node in a cluster has to be aware of every Service and every Pod. The kube-proxy facilitates and manages each Service on each Node as defined for a specific cluster. The kube-proxy supports TCP, UDP, and STCP network protocols as well as forwarding and load balancing. Each Node needs to know how to proxy from a Service to the Pods associated with that Service, and the kube-proxy uses iptables rules on the host to maintain the forwarding rules.
Iptables has been referred to as the “caulk of distributed systems and networks,” mainly because it is used almost ubiquitously in production Linux environments. For the longest time, most people thought of it as a necessary security step, but they rarely saw that it is a bold tool. Iptables enables all manners of creativity when designing armies of servers that can host complicated network applications. In the post-Kubernetes era, iptables is more a tool for liberating your applications than one that limits your productivity. Keep an open mind about how you can leverage the tool. Even if you never have to touch it again, it is key to appreciating why the complexity of Kubernetes is a necessary as you move to a microservices environment for your applications.
You can think of iptables as a combination of a router and firewall, both living right inside your OS for convenient last-minute networking tasks. It configures the Linux kernel’s networking userspace to drop, accept, and route packets. The previous statement is a gross oversimplification, but for Kubernetes, it’s a reasonable abstraction to keep you moving along.
Alternatively, you may have needed to think through iptables and turn a rule on or off. If you haven’t done it firsthand, you may have seen someone do so. Regardless of your background, our discussion of networking concepts should be supplemented by your independent study to fill any holes in your knowledge base. Networking concepts are often very abstract, and they’re hard to teach because very few people ever have to do networking: the day-to-day job of a software engineer in an enterprise usually involves building on top of TCP networks, which perform well for most scenarios.
Figure 5.2. Tables in iptables
Iptables provides five different types of tables.
This is an excerpt from Manning's book Kubernetes in Action.
The initial implementation of the kube-proxy was the userspace proxy. It used an actual server process to accept connections and proxy them to the pods. To intercept connections destined to the service IPs, the proxy configured iptables rules (iptables is the tool for managing the Linux kernel’s packet filtering features) to redirect the connections to the proxy server. A rough diagram of the userspace proxy mode is shown in figure 11.9.
The kube-proxy got its name because it was an actual proxy, but the current, much better performing implementation only uses iptables rules to redirect packets to a randomly selected backend pod without passing them through an actual proxy server. This mode is called the iptables proxy mode and is shown in figure 11.10.
When a service is created in the API server, the virtual IP address is assigned to it immediately. Soon afterward, the API server notifies all kube-proxy agents running on the worker nodes that a new Service has been created. Then, each kube-proxy makes that service addressable on the node it’s running on. It does this by setting up a few iptables rules, which make sure each packet destined for the service IP/port pair is intercepted and its destination address modified, so the packet is redirected to one of the pods backing the service.