Network and Security

We've learned how to deploy containers with different resources in Kubernetes in Chapter 3, Getting Started with Kubernetes, and know how to use volume to persist the data, dynamic provisioning, and different storage classes. Next, we'll learn how Kubernetes routes the traffic to make all of this possible. Networking always plays an important role in the software world. We'll describe the networking from containers on a single host, multiple hosts and finally to Kubernetes.

• Docker networking
• Kubernetes networking
• Ingress
• Network policy

Kubernetes networking

There are plenty of choices you can use to implement networking in Kubernetes. Kubernetes itself doesn't care 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 the same way as the others see it

Before getting into anything further, we'll first review how does the default container networking works. That's the pillar of the network to make all of this possible.

Docker networking

Let's review how Docker networking works before getting into Kubernetes networking. In Chapter 2...

Ingress

Pods and services in Kubernetes have their own IP; however, it is normally not the interface you'd provide to the external internet. Though there is service with 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 external service.

Ingress defines a set of rules that allows the inbound connection to access Kubernetes cluster services. It brings the traffic into the cluster at L7, allocates and forwards a port on each VM to the service port. This is shown in the following figure. 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 by the ingress rules...

Network policy

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

Currently, there are multiple network providers that support 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 are free to choose any...

Summary

In this chapter, we have learned how containers communicate with each other as it is essential, and we introduced how pod-to-pod communication works. Service is an abstraction to route the traffic to any of the pods underneath, if label selectors match. We learned how service works with pod by iptables magic. We got to know how packet routes from external to a pod and the DNAT, un-DAT tricks. We also learned new API objects such as ingress, which allow us to use the URL path to route to different services in the backend. In the end, another object NetworkPolicy was introduced. It provides a second layer of security, acting as a software firewall rule. With network policy, we can make certain pods communicate only with certain pods. For example, only data retrieval service can talk to the database container. All of these things make Kubernetes more flexible, secure, and...