Skip to content

Getting Started

Huanyu He edited this page Apr 13, 2022 · 3 revisions

What's "hybridnet"

Normally, for some applications(e.g., batch jobs), we don't care whether it will be accessed outside the cluster or it needs to run on a high performance network, but just need a separated network environment (a network namespace) for each of job while they can communicate with each other. Overlay network is always recommended for these cases.

But for the long running jobs, the throughput and methods of accessing always need to be considered, which maybe required a kind of container network that has a higher performance and is able to work with underlying interconnect fabric. This kind of network is also called "underlay" normally.

Hybrinet provides a network that overlay and underlay containers can run on the same node and have cluster-wide bidirectional network connectivity. Which means a hybridnet cluster can be freely transformed between "underlay", "overlay" and "overlay/underlay hybrid", providing a full flexibility to change the form of cluster networking according the applications.

The trick is, the traffic between an overlay container and an underlay container will always be handled as "overlay", just like traffic happens between two overlay containers. But when it comes to the traffic between underlay Pods(or underlay pods to Nodes and addresses outside the cluster), it will still be handled as underlay traffic.

It can be explained in a more interested way. Assuming that there are two parallel universes called "overlay" and "underlay". Creatures live in different universes could not see each other, as we all know. Now a god called "Hybridnet" wants the two universes to have a talk. So he builds a projection in the "overlay" universe for every "underlay" creature and makes "underlay" creatures share the same appearance and mind with their "overlay" projections. So the creatures in both universes can have a communication through the projections.

Every ip address of underlay container can be considered as two: an overlay ip address and an underlay ip address, which have the same value. An underlay container uses its overlay ip address to communicate with an overlay container, and uses its underlay ip address in other situations.

Since this, obviously, all the Subnet cannot be overlapped whether it is underlay or overlay.

Install

Use these commands to build a simplest hybridnet network environment:

To install hybridnet in an exist Kubernetes (version > 1.16) cluster, you need a Kubernetes Services Proxy implementation first, e.g., iptables/ipvs mode Kube-proxy, Cilium with bpf.hostRouting enabled. Because hybridnet does not implement Kubernetes Services Proxy itself.

# Get Repo Info
helm repo add hybridnet https://alibaba.github.io/hybridnet/
helm repo update

# Install Chart
helm install hybridnet hybridnet/hybridnet -n kube-system

Observation

Using kubectl commands along with Network/Subnet/IPInstance CR objects, you can get the condition of network resources easily:

[root@network-test00002 ~]# kubectl get network
NAME                NETID   SWITCHID
overlay-network     4       virtual-switch
underlay-network1   0       physical-switch1
[root@network-test00002 ~]#
[root@network-test00002 ~]#
[root@network-test00002 ~]# kubectl get subnet
NAME                      VERSION   CIDR              START          END   GATEWAY        TOTAL   USED   AVAILABLE   NETID   NETWORK
overlay-subnet-conflict   4         10.14.130.0/24                         10.14.130.1    253     0      253                 overlay-network
overlay-subnet1           4         10.14.100.0/24                         10.14.100.1    253     2      251                 overlay-network
underlay-subnet1          4         192.168.56.0/24   192.168.56.8         192.168.56.1   247     6      241         0       underlay-network1
[root@network-test00002 ~]#
[root@network-test00002 ~]#
[root@network-test00002 ~]# kubectl get ipinstance -n default
NAME            IP                 GATEWAY        PODNAME                                      NODE                SUBNET             NETWORK
192-168-56-16   192.168.56.16/24   192.168.56.1   nginx-deployment-fb7b8d877-97k5m             network-test00003   underlay-subnet1   underlay-network1
192-168-56-17   192.168.56.17/24   192.168.56.1   nginx-deployment-fb7b8d877-m8srv             network-test00003   underlay-subnet1   underlay-network1
192-168-56-18   192.168.56.18/24   192.168.56.1   nginx-deployment-fb7b8d877-49t5n             network-test00003   underlay-subnet1   underlay-network1
192-168-56-19   192.168.56.19/24   192.168.56.1   nginx-deployment-underlay-5598684bd5-7cx7q   network-test00003   underlay-subnet1   underlay-network1
192-168-56-20   192.168.56.20/24   192.168.56.1   nginx-deployment-underlay-5598684bd5-z7zkj   network-test00003   underlay-subnet1   underlay-network1
192-168-56-21   192.168.56.21/24   192.168.56.1   nginx-deployment-underlay-5598684bd5-qfvd5   network-test00003   underlay-subnet1   underlay-network1