Getting Started with Kubernetes | Kubernetes Network and Policy Control

1) Basic Network Model of Kubernetes

This article introduces some underlying fundamentals for the Kubernetes network model. Kubernetes does not restrict network implementation solutions, and therefore no existing ideal reference cases are available. Kubernetes defines a container network model to determine restrictions on a container network. Generally, this is summarized into three requirements and four goals.

Three Requirements

The three requirements are as follows:

  • 2) Nodes and pods may communicate with each other, without explicit address translation.
  • 3) The IP address displayed for a pod is the same as that for others, without any intermediate transitions.

Four Goals

The four goals specify how to connect an external system to applications in a container in a Kubernetes system.

  • How do these services communicate with backend pods?
  • How do pods invoke each other?
  • How do containers in a pod communicate with each other?

Basic Constraint

The development of container networks is complex because it depends on the host network. From this perspective, container networks are divided into two categories: underlay and overlay.

  • By contrast, an overlay network does not need to apply for an IP address from the IPM management component on the host network. Generally, any IP address not conflicting with that of the host network is assigned to the overlay network.

2) Network Namespace


This section describes the kernel foundation that is implemented by the network in the network namespace. In a narrow sense, the runC container technology is executed based on its kernel without relying on any hardware. The kernel representative process is a task. If isolation is not required, the host space (namespace) without a special space isolation data structure (nsproxy-namespace proxy) is used.

Relationships Between Pods and Network Namespaces

3) Overview of Mainstream Network Solutions

Typical Implementation Solutions for Container Networks

This section briefly introduces typical implementation solutions for container networks. Container networks are implemented in Kubernetes in various ways. The container network is complex as it involves coordination with the underlying IaaS network and a trade-off between performance and the flexibility of IP address allocation. Therefore, various solutions may be used.

  • Calico uses policy-based routing, with BGP used among nodes to synchronize routes. It features rich functions and better support for network points. Calico requires a direct connection to the underlying network by using the MAC address, not across the L2 network.
  • Some community members combine the advantages of Flannel and Calico into a grafted innovative project named Cilium.
  • To encrypt data, use WeaveNet whose dynamic solutions achieve better encryption.

Flannel Solution

  • The second is VxLAN for the kernel mode. Both backends are overlay-network solutions. VxLAN offers better performance but requires kernels that support VxLAN features.
  • If clusters are not large and reside on the same L2 network, use host-gw. In this mode, the backend is started by a broadcast routing rule, with higher performance.

4) Use of the Network Policy

The Concept Behind Network Policy

Let’s understand the concept behind network policy.

Configuration Example

  • The stream direction also needs to be determined, which might be inbound, outbound, or both.
  • Most importantly, describe the permitted or denied streams based on specified stream direction and control object. For example, for the stream feature, use some selectors to determine the peer end (which is actually selecting an object), use the IPBlock mechanism to determine the allowed IP addresses, and determine the protocols and ports. Combine the stream features into a quintuple that selects specific acceptable streams.


This section briefly summarizes this article.

  • For network solutions, topology is the key that influences the container network performance. It’s significant to understand how the source and destination ends of the package are interconnected, how the package is sent from the container to the host from the container, whether the package needs to be encapsulated or decapsulated after being sent, whether the package is sent through policy-based routing, and how the package is parsed out when it reaches the peer end.
  • Select the container network and design. Assume that there’s no information about the external network or the need for a universally adaptable solution. In such a case, if you were not sure whether the MAC address supported direct connection or whether you could control the routing table of the external router, choose the Flannel solution and use VxLAN as a backend solution. If you are sure that the network is dual-layer and directly connected, use Calico or Flannel-Hostgw as a backend solution.
  • A network policy is a powerful tool that accurately controls inbound and outbound streams during O&M and use. Select an implementation method based on the desired control objects and streams.

5) Thinking

Here are some questions for you:

Original Source:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store