Using Multiple Host Networks
This page is about using multiple host networks with Charmed Kubernetes. For information on using multiple container networks, please refer to the Multus page instead.
Using network spaces and bindings in Juju, it’s possible to deploy Charmed Kubernetes in an environment with multiple networks and assign traffic to different networks explicitly.
Currently, multiple networks are only supported in Juju on MAAS.
The rest of this document assumes you’re familiar with the basics of MAAS and Juju. If you’re not, you can familiarise yourself with them by reading the MAAS documentation and Juju documentation.
Configure MAAS
Preconditions:
- You have MAAS nodes that are attached to multiple logical networks (separate physical networks or VLANs).
- You have commissioned the nodes in MAAS.
Create spaces in MAAS
In the ‘Subnets’ tab of the MAAS GUI, click Add -> Space
to create spaces as
needed. To add subnets to a space, enter the subnet’s VLAN configuration page
(click in the ‘VLAN’ column on the main Subnets page) and assign it to the space.
Enable network interfaces on nodes
By default, only the first network interface is enabled on each node. You need to manually enable the rest.
Go to the ‘Nodes’ tab, click on a node, and click the ‘Interfaces’ tab. Set
each interface’s IP mode to Auto assign
.
Configure Juju
If you’ve already bootstrapped a Juju controller, use juju reload-spaces
to
pick up the changes from MAAS. Otherwise, bootstrap a new Juju controller and
the new controller should pick up the spaces automatically.
Run juju spaces
and make sure you see the network spaces and subnet
assignments that you’re expecting to see.
Use bindings to direct network traffic
Using bindings, you can direct specific kinds of network traffic in your Charmed Kubernetes cluster to go through specific networks.
The easiest way to do this is by using an overlay file when you deploy Charmed
Kubernetes. The following is an example overlay that defaults all bindings to
send traffic through a network space named control
, with the exception of the
flannel cni binding, which will send its traffic through a network space named
workload
instead:
applications:
easyrsa:
bindings:
"": control
etcd:
bindings:
"": control
kubeapi-load-balancer:
bindings:
"": control
kubernetes-control-plane:
bindings:
"": control
kubernetes-worker:
bindings:
"": control
containerd:
bindings:
"": control
flannel:
bindings:
"": control
cni: workload
Once you have an overlay file created, use it to deploy Charmed Kubernetes with your bindings:
juju deploy charmed-kubernetes --overlay my-overlay.yaml
The following endpoints are available for use in bindings:
Charm | Endpoint | Description of traffic |
---|---|---|
etcd | cluster | ETCD internal (peer) |
etcd | db | ETCD external (client) |
flannel | cni | Flannel traffic (pod to pod communication) |
canal | cni | Flannel traffic (pod to pod communication) |
calico | cni | Calico traffic (pod to pod communication) |
kubernetes-control-plane | kube-api-endpoint | Main traffic to kube-apiserver, from kubeapi-load-balancer |
kubernetes-control-plane | kube-control | Secondary traffic to kube-apiserver, from pods |
kubeapi-load-balancer | website | Traffic to kubeapi-load-balancer, from kubectl, kubelet and kube-proxy |
kubernetes-worker | kube-control | Traffic to kubelet, from kube-apiserver (health checks) |
You can read more about bindings in the Juju documentation here: Binding endpoints within a bundle
See the guide to contributing or discuss these docs in our public Mattermost channel.