Kubernetes Network

In Chapter 3, Getting Started with Kubernetes, we learned how to deploy containers with different resources and also looked at how to use volumes to persist data, dynamic provisioning, different storage classes, and advanced administration in Kubernetes. In this chapter, we'll learn how Kubernetes routes traffic to make all of this possible. Networking always plays an important role in the software world. We'll learn about Kubernetes networking step by step, looking at the communication between containers on a single host, multiple hosts, and inside a cluster.

The following are the topics we'll cover in this chapter:

• Kubernetes networking
• Docker networking
• Ingress
• Network policy
• Service mesh

Kubernetes networking

There are plenty of options when it comes to implementing networking in Kubernetes. Kubernetes itself doesn't care about how you implement it, but you must meet its three fundamental requirements:

• All containers should be accessible to each other without NAT, regardless of which nodes they are on
• All nodes should communicate with all containers
• The IP container should see itself in the same way as others see it

Before getting any further into this, we'll first examine how default container networking works.

Docker networking

Let's now review how docker networking works before getting into Kubernetes networking. For container networking, there are different modes: bridge, none, overlay...

Ingress

Pods and services in Kubernetes have their own IPs. However, this is normally not the interface you'd provide to the external internet. Though there is a service with a node IP configured, the port in the node IP can't be duplicated among the services. It is cumbersome to decide which port to manage with which service. Furthermore, the node comes and goes; it wouldn't be clever to provide a static node IP to an external service.

Ingress defines a set of rules that allows the inbound connection to access Kubernetes cluster services. This brings the traffic into the cluster at L7, and allocates and forwards a port on each VM to the service port. This is shown in the following diagram. We define a set of rules and post them as source type ingress to the API server. When the traffic comes in, the ingress controller will then fulfill and route the ingress according...

Network policy

The network policy works as a software firewall to the pods. By default, every pod can communicate with each other without any boundaries. The network policy is one of the isolations you could apply to these pods. This defines who can access which pods in which port by namespace selector and pod selector. The network policy in a namespace is additive, and once a pod enables the network policy, it denies any other ingress (also known as deny all).

Currently, there are multiple network providers that support the network policy, such as Calico (https://www.projectcalico.org/calico-network-policy-comes-to-kubernetes/), Romana (https://github.com/romana/romana), Weave Net (https://www.weave.works/docs/net/latest/kube-addon/#npc), Contiv (http://contiv.github.io/documents/networking/policies.html), and Trireme (https://github.com/aporeto-inc/trireme-kubernetes). Users...

Service mesh

A service mesh is an infrastructure layer for handling service-to-service communication. Especially in the microservice world, the application at hand might contain hundreds of thousands of services. The network topology can be very complicated here. A service mesh can provide the following:

• Traffic management (such as A/B testing and canary deployment)
• Security (such as TLS and key management)
• Observability (such as providing traffic visibility. This is easy to integrate with monitoring systems such as Prometheus (https://prometheus.io/), tracing systems such as Jaeger (https://www.jaegertracing.io) or Zipkin (https://github.com/openzipkin/zipkin), and logging systems)

There are two major service mesh implementations on the market—Istio (https://istio.io) and Linkerd (https://linkerd.io). Both of these deploy network proxy containers alongside the application...

Summary

In this chapter, we learned how containers communicate with each other. We also introduced how pod-to-pod communication works. A service is an abstraction that routes traffic to any of the pods underneath it if the label selectors match. We also learned how a service works with a pod using iptables. We also familiarized ourselves with how packet routes from external services to a pod using DNAT and un-DAT packets. In addition to this, we looked at new API objects such as ingress, which allows us to use the URL path to route to different services in the backend. In the end, another NetworkPolicy object was introduced. This provides a second layer of security, and acts as a software firewall rule. With the network policy, we can make certain pods communicate with certain other pods. For example, only data retrieval services can talk to the database container. In the last...