Table of contents
No headings in the article.
▶What is Kubernetes Networking?
It has been designed to ensure that the different entity types within Kubernetes can communicate. The layout of a Kubernetes infrastructure has, by design, a lot of separation. Namespaces, containers, and Pods are meant to keep components distinct from one another, so a highly structured plan for communication is important.
Kubernetes has its own set of rules, and if you're dealing with containers and the cloud, it helps to understand how Kubernetes networking works.
The Kubernetes Network Model has a few general rules to keep in mind:
>> Every Pod gets its IP address: There should be no need to create links between Pods and map container ports to host ports.
>> NAT is not required: Pods on a node should be able to communicate with all Pods on all nodes without NAT.
>> Agents get all-access passes: Agents on a node (system daemons, Kubelet) can communicate with all the Pods in that node.
>> Shared namespaces: Containers within a Pod share a network namespace (IP and MAC address), so they can communicate with each other using the loopback address.
Here, there are some types of Kubernetes Networking:
▶Container-to-Container Networking
This networking happens through the Pod network namespace. Network namespaces allow you to have separate network interfaces and routing tables that are isolated from the rest of the system and operate independently. Every Pod has its network namespace, and containers inside it share the same IP address and ports. All communication between these containers happens through localhost, as they are all part of the same namespace (green line on the diagram below).
▶Pod-to-Pod networking
Pod-to-Pod communication happens using real IPs, whether you deploy the Pod on the same node or a different node in the cluster.
The diagram below shows that for Pods to communicate with each other, the traffic must flow between the Pod network namespace and the Root network namespace.
From Pod 1 to Pod 2, the flow of events is:
▶Pod-to-Service networking
Pods are very dynamic. They scale up or down based on demand. They are created again in case of an application crash or a node failure.
Kubernetes fixes this problem by using the Service function, which does the following:
\>> Assigns a static virtual IP address in the frontend to connect any backend Pods associated with the Service.
\>> Load-balances any traffic addressed to this virtual IP to the set of backend Pods.
\>> Keeps track of the IP address of a Pod, such that even if the Pod IP address changes, the clients don't have any trouble connecting to the Pod because they only directly connect with the static virtual IP address of the Service itself.
▶Internet-to-Service networking
It is possible to expose an application to an external network in two different ways.
>> Egress: You can use this when you want to route traffic from your Kubernetes Service out to the Internet.
>> Ingress: Incoming traffic from the external world to Services. Ingress also allows and blocks particular communications with Services using rules for connections. Typically, there are two ingress solutions that function on different network stack regions: the service load balancer and the ingress controller.
▶ServiceTypes for publishing Services:
Kubernetes Services provide you with a way of accessing a group of Pods, usually defined by using a label selector. This could be applications trying to access other applications within the cluster, or it could allow you to expose an application running in the cluster to the external world. Kubernetes ServiceTypes enable you to specify what kind of Service you want.
The different ServiceTypes are:
>> ClusterIP: This is the default ServiceType. It makes the Service only reachable from within the cluster and allows applications within the cluster to communicate with each other. There is no external access.
>> LoadBalancer: This ServiceType exposes the Services externally using the cloud provider's load balancer. Traffic from the external load balancer is directed to the backend Pods. The cloud provider decides how it is load-balanced.
>> NodePort: This allows the external traffic to access the Service by opening a specific port on all the nodes. Any traffic sent to this Port is then forwarded to the Service.
>> ExternalName: This type of Service maps a Service to a DNS name by using the contents of the externalName field by returning a CNAME record with its value. No proxying of any kind is set up.
This was a simple nutshell for Kubernetes Networking Fundamentals.