The scheduling of services spawned by Yaook is handled by the Kubernetes Scheduler using Affinities and Tolerations. All services come with a set of Affinities and Tolerations which allows fine-grained control over the placement of the components.
To each scheduleable component a Scheduling Key is assigned. The Key is used as
key for both tolerations and labels. If a component has the key
will tolerate both
NoSchedule taints with that key and
it will only run on nodes with that as label.
A notable exception is the Neutron Layer 2 Agent, which will schedule itself based on other criteria (see Neutron L2 Agent below).
In addition, a component may also listen to a Scheduling Group Key. In that case, it will tolerate that key and it will also run on nodes which just have a label matching that key.
This means that, on a fresh Kubernetes cluster, no services will be scheduled at all.
For details on the specific scheduling keys, please see
Neutron Metadata Agent
The metadata agent is tightly coupled to both, L3 and DHCP. It also can run on a single physical node multiple times without damage, provided proper namespacing. Hence, it is included as a sidecar container in L3 and DHCP Pods and not scheduled separately.
Neutron L2 Agent
Neutron’s Layer 2 Agent is a strict dependency of several other services, including Nova Compute. In contrast to the Metadata agent, however, it can only run at most once on each Kubernetes node, as it manages node-wide resources (network interfaces).
Thus, it will tolerate all the keys of the following services (in addition to
it will be spawned on all nodes matching any of their keys:
Neutron L3 Agent:
Neutron DHCP Agent:
The use of a ConfiguredDaemonSet ensures that there exists at most one L2 Agent Pod per Kubernetes node.