The book “Mastering Kubernetes. Orchestration of container architectures "/ Blog of the publishing house" Peter "

Hi, habrozhiteli! We recently published a book on Kubernetes version 1.10. The post covers the passage “Networking Solutions for Kubernetes.”

Networking is an extensive topic. There are many ways to configure a network with devices, hearths, and containers. Kubernetes does not limit you to this. All that this platform prescribes is a high-level network model with a flat address space for hearths. Within this space, you can implement many good solutions with different capabilities and for different environments. In this section, we will look at some of them and try to understand how they fit into the Kubernetes network model.

Creating bridges in hardware clusters

The simplest environment is a bare metal cluster, which is a regular L2-level physical network. To connect containers to such a network, you can use the standard Linux bridge. This is a rather painstaking procedure, requiring experience with low-level Linux network commands, such as brctl, ip addr, ip route, ip link, nsenter, etc. You can start implementing this solution with the following guide: blog.oddbit.com/
2014/08/11 / four-ways-to-connect-a-docker / (look for the With Linux Bridge devices section).

Contiv

Contiv is a general-purpose network add-on. It is designed to connect containers via CNI and can be used with Docker (directly), Mesos, Docker Swarm and, naturally, Kubernetes. Contiv deals with network policies and partially duplicates a similar object in Kubernetes. The following are some of the features of this network add-on:

• support for CNM in libnetwork and the CNI specification;
• A feature-rich policy engine that provides security and predictable application deployment.
• best-in-class container performance;
• multi-tenancy, isolation, and overlapping subnets;
• IPAM integration and service discovery;
• a wide selection of physical topologies:
  
  a) layer 2 protocols (VLAN);
  b) layer 3 protocols (BGP);
  c) overlay networks;
  d) Cisco SDN (ACI);
• IPv6 support;
• scalable policy and route allocation;
• Integration with application templates, including the following:
  
  a) Docker-compose;
  b) Kubernetes deployment manager;
  c) load balancing on services, built into the balancer of microservices of the "east - west" type (east - west);
  d) traffic isolation during storage, access control (for example, etcd / consul), network transmission and management.

Contiv has many features. This tool implements a wide range of tasks and supports various platforms, so I'm not sure if it will be the best choice for Kubernetes.

Open vswitch

Open vSwitch is a mature virtual switch (software) switch solution supported by many major market players. The Open Virtualization Network (OVN) system allows you to build various virtual network topologies. She has a special add-on for Kubernetes, but it’s very difficult to configure (see github.com/openvswitch/ovn-kubernetes manual ). The Linen CNI add-on has fewer features, but its configuration is much easier: github.com/John-Lin/linen-cni . The Linen CNI structure is shown in Fig. 10.6.


Open vSwitch can integrate physical servers, VMs, and pods / containers into a single logical network. This system supports both overlay and physical modes.

Here are some of its key features:

• Standard 802.1Q VLAN with trunk and public ports
• NIC binding with or without LACP for a higher level switch
• NetFlow, sFlow® and mirroring for enhanced visibility;
• QoS configuration (Quality of Service) plus policies;
• tunneling through Geneve, GRE, VXLAN, STT and LISP;
• break control in 802.1ag;
• OpenFlow 1.0 plus numerous add-ons;
• transactional database for storing configuration with bindings for C and Python;
• high-performance redirection using Linux kernel modules.

Nuage Networks VCS

Virtualized Cloud Services (VCS) is a product from Nuage, which is a well-scalable, policy-based platform for building software-defined networks (Software-Defined Networking, SDN). This is an enterprise level solution, which is based on the open system Open vSwitch (for data redirection) and a multifunctional SDN controller based on open standards.

The Nuage platform combines Kubernetes pods and third-party environments (virtual and hardware) into transparent overlay networks and allows you to describe detailed policies for different applications. Its real-time analysis engine enables you to monitor the visibility and security of Kubernetes applications.

In addition, all VCS components can be installed as containers. There are no specific hardware requirements.

Canal

Canal is a mixture of two open source projects: Calico and Flannel. Hence the name. The Flannel project, developed by the CoreOS team, deals with the networking capabilities of containers, while Calico is responsible for network policies. Initially, they were developed separately from each other, but users wanted to use them together. The Canal open source project is now a deployment template for installing Calico and Flannel as separate CNI add-ons. Created by Calico's founders, Tigera has been supporting both projects and even planned tighter integration, but since releasing its own solution for secure networking between applications in Kubernetes, priority has shifted towards simplifying the configuration and integration of Flannel and Calico instead of developing a unified solution. In fig. 10.


Note that when integrating with Kubernetes, Canal does not access etcd directly, but the Kubernetes API server.

Flannel

Flannel is a virtual network that provides each node with a virtual network for working with container runtimes. On each node, the flaneld agent is launched, raising the subnet based on the reserved address space stored in the etcd cluster. Packet exchange between containers and, by and large, the node is made by one of several servers. Most often, the server uses UDP over the TUN device, which by default tunnels traffic through port 8285 (do not forget to open it in your firewall).

In fig. 10.8 describes in detail the various components of the Flannel network, the virtual network devices it creates, and how they communicate with the host and the hearth via the docker0 bridge. Here you can also see the process of encapsulating UDP packets and their movement between nodes.


Other network technologies are supported:

• vxlan - encapsulates packets using VXLAN inside the kernel;
• host-gw - creates IP routes to subnets through the IP addresses of the remote server. It is worth noting that this requires a direct connection at the second network layer between the servers running Flannel;
• aws-vpc - Create IP routes in the Amazon VPC routing table
• gce - creates IP routes in the Google Compute Engine network
• alloc - performs only the selection of the subnet, but not the redirection of packets;
• ali-vpc - Creates IP routes in the Alicloud VPC routing table.

Calico Project

Calico is a complete solution for networking between containers and network security. It can be integrated with all major orchestration platforms and runtimes:

• Kubernetes (add-on for CNI);
• Mesos (add-on for CNI);
• Docker (add-on for libnework);
• OpenStack (add-on for Neutron).

Calico can also be deployed locally or in a public cloud while preserving all the features. The application of network policies can depend on the load, which provides clear traffic control and ensures that packets always reach the desired destinations. Calico can automatically import network policies from orchestration platforms. In fact, he is responsible for implementing network policies at Kubernetes.

Romana

Romana is a modern solution for networking between containers. It was originally designed for use in the cloud and operates at the third network layer, relying on standard methods for managing IP addresses. Romana allows you to isolate entire networks by creating gateways and routes for them using Linux-based servers. Work at the third network layer does not require encapsulation. Network policy is applied to all endpoints and services as a distributed firewall. Romana facilitates on-premises and hybrid deployments between different cloud platforms, as you no longer need to configure virtual overlay networks.

Recently appeared in Romana virtual IP addresses allow local users to open access to their services in local networks of the second level, using external addresses and specifications of services.

Romana developers claim that their approach significantly improves performance. In fig. Figure 10.9 shows how, together with avoiding VXLAN encapsulation, you can get rid of a lot of overhead.

Weave net

The main features of the Weave Net project are ease of use and lack of configuration. It uses VXLAN encapsulation and installs micro-DNS on each node. As a developer, you will be dealing with a high level of abstraction. After you name your containers, Weave Net will allow you to connect to standard ports and enable the appropriate services. This helps in migrating existing applications to microservice and containerization platforms. Weave Net provides a CNI add-on for working with Kubernetes and Mesos. Starting with Kubernetes 1.4, integration with Weave Net can be accomplished with a single command that deploys DaemonSet:

kubectl apply -f https://git.io/weave-kube

The Weave Net pods hosted on each node are responsible for connecting any other pod instances to the Weave network. Weave Net supports APIs with network policies, providing a complete and easy to configure solution.

Effective use of network policies

Kubernetes network policy is designed to control traffic that is directed to specific pods and namespaces. When managing hundreds of deployed microservices (as is often the case with Kubernetes), networking between the hearths comes to the fore. It is important to understand that this mechanism is only indirectly related to security. If an attacker is able to penetrate the internal network, he will most likely be able to create his own instance of the hearth that will comply with the network policy and allow free communication with other hearths. In the previous section, we looked at various networking solutions in Kubernetes, focusing on network interfaces. Here we will focus on the network policy implemented on top of these solutions, although both components are closely interconnected.

Network Policy Architecture in Kubernetes

Network policy determines how subsets of hearths can interact with each other and with other network endpoints. The NetworkPolicy resource uses labels to select hearths and defines a list of permission rules that allow traffic to be directed to selected hearth instances (in addition to what is already allowed by the isolation policy in the given namespace).

»More information about the book can be found on the publisher’s website
» Contents
» Excerpt

For Khabrozhiteley 20% discount on coupon - Kubernetes

Upon payment of the paper version of the book, an electronic version of the book is sent by e-mail.

PS: 7% of the cost of the book will go to the translation of new computer books, the list of books handed over to the printing house is here .