The Priority is determined as follows:
P0: ClusterCIDR with higher number of matching labels has highest
priority.
P1: ClusterCIDR having cidrSet with fewer allocatable Pod CIDRs has
higher priority.
P2: ClusterCIDR with a PerNodeMaskSize having fewer IPs has higher
priority.
P3: ClusterCIDR having label with lower alphanumeric value has higher
priority.
P4: ClusterCIDR with a cidrSet having a smaller IP address value has
higher priority.
Add a new cidrset named `multicidrset` which extends the current
cidrset mechanism to track allocatable Pod and Service CIDRs.
multicidrset stores the info about allocated CIDRs in a Map as opposed
to the current cidrset implementation where it is stored in a bitmap.
Introduce networking/v1alpha1 api group.
Add `ClusterCIDR` type to networking/v1alpha1 api group, this type
will enable the NodeIPAM controller to support multiple ClusterCIDRs.
Updates predicate to check for a length >=2 to avoid
the index out of bounds panic.
Signed-off-by: Edwin Xie <exie@vmware.com>
Co-authored-by: Tyler Schultz <tschultz@vmware.com>
After the userns PR got merged:
https://github.com/kubernetes/kubernetes/pull/111090
gnufied decided it might be safer if we feature gate this part of the
code, due to the kubelet volume host type assertion.
That is a great catch and this patch just moves the code inside the
feature gate if.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
github.com/opencontainers/selinux/go-selinux needs OS that supports SELinux
and SELinux enabled in it to return useful data, therefore add an interface
in front of it, so we can mock its behavior in unit tests.
In theory the check is not necessary, but for sake of robustness and
completenes, let's check SELinuxMountReadWriteOncePod feature gate before
assuming anything about SELinux labels.
Add a new call to VolumePlugin interface and change all its
implementations.
Kubelet's VolumeManager will be interested whether a volume supports
mounting with -o conext=XYZ or not to hanle SetUp() / MountDevice()
accordingly.
Let volume plugins decide if they want to mount volumes with "-o
context=XYZ" or let the container runtime relabel the volume on container
startup.
Using NewMounter, as it's the call where a volume plugin gets the other MountOptions.