[RFE] Managing zones in k8s
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
I was following the instructions discussed in: https:/
Using juju 2.9.45 + single-node microk8s 1.27/stable for this test.
However, affinity / anti-affinity does not give the same AZ capabilities we have in the VM world.
AZs means I have a list of groups of no common servers. That means an operator can deploy knowing its workloads will land on different nodes, networks, storage, etc.
I believe we can get a very close UX as VMs in k8s by using:
1) using nodeAffinity to select the zones set in constraints [2]
2) setting topology spread [1]
With these two features enabled, one could set the following:
$ juju deploy postgresql-k8s -n3 --constraints=
That would result in a deployment where:
1) nodeAffinity only allows to select nodes in z1 or z2 and topologyKey is set in tags
2) to spread pods across nodes, respecting the topologyKey and maxSkew of 1
-------
I also noticed that "topologyKey" is not being respected, where command:
$ juju deploy postgresql-k8s --channel=14/edge -n3 --constraints=
Results in: https:/
Where "topology-key" is not set.
In any case, I don't believe that will provide the same UX as described above. We should have both options (pod/anti-pod syntax + zones and topologyKeys)
-------
[1] https:/
[2] https:/
We can look to utilise the now standard node labels
topology. kubernetes. io/zone kubernetes. io/region
topology.
to provide out of the box support for zone constraints and spreading workload units across AZ in the same way as we do for machine clouds. This would be done using affinity under the covers but the UX is generic, ie --constraints= "zones= z1,z2" and the spread across AZ is done automatically. Juju doesn't have an option for controlling skew as far as I can recall - if we were to add it it would be modelled to work across all clouds.
We have the k8s specific syntax for bespoke node/pod (anti-)affinity based on node tags, and this syntax is supposed to expose topology key also. I am not sure why that isn't doing what's expected.