The advertisement operator is the module that receives Advertisement CRs and creates the virtual nodes with the announced resources. Doing so, the remote clusters (emulated by the virtual nodes) are taken into account by the scheduler, which can offload the jobs it receives on them.
The operator dynamically watches the
ClusterConfig CR to know the maximum number of Advertisements that can be accepted and the acceptance policy.
Check cluster configuration to get more details about
If the configured policy is
AutoAcceptMax, the behavior is the following:
MaxAcceptableAdvertisementsincreases, check if there are refused Advertisements: if so, they are accepted until the new maximum is reached.
Implement manual acceptance of Advertisement: at the moment the
ManualAccept policy is not implemented.
Implement more complex policies, for example blacklist/whitelist some foreign clusters.
Gracefully delete the virtual-kubelet when the Advertisement is deleted.
The Virtual-Kubelet has an ownerReference to the Advertisement, so when this is deleted, the Virtual-Kubelet is deleted as well. However, the deletion order is: Advertisement deleted -> Virtual-Kubelet deleted -> Virtual node deleted. The desired deletion order is the opposite: in fact, by first deleting the virtual node, the Virtual-Kubelet will reflect the deletion of all offloaded resources on the foreign cluster, leaving a clean namespace in it.
Recreate the Virtual-Kubelet if it is unexpectedly deleted.
If an Accepted Advertisement exists in the cluster, the linked Virtual-Kubelet should exist as well. If the Deployment of the Virtual-Kubelet is deleted in some way, it should be recreated by the Advertisement Operator.
Advertisementis created by the foreign cluster.
ClusterConfigCR to accept/refuse the
Advertisementis accepted, wait for the network modules to set a possible PodCIDR remapping.
Secret, created by the foreign cluster, with the permissions to create resources on it.