multus-cni
multus-cni copied to clipboard
pass through the pod annotations when multus receives them
See https://github.com/kubernetes/kubernetes/issues/69882#issuecomment-1509077177 and https://github.com/k8snetworkplumbingwg/multus-cni/pull/1116
Passing the annotations seems not to be a standardized behaviour, but it is very useful nontheless.
I'm not clear that io.kubernetes.cri.pod-annotations
comes from and use-case yet. Could you please clarify that, including why the annotation, io.kubernetes.cri.pod-annotations
, should be default (to all platform).
This comment is a good summary.
My use case is that a custom CNI plugin needs some extra information to configure the networking of a Pod that I would like to pass as an annotation on the Pod; containerd can already be configured to pass this annotation to CNI plugins, this patch enables multus to receive it.
Tomo's looking into the possibility of checking this out with capability args in the meanwhile, and we'll circle back to it to make sure it's necessary.
Tomo's looking into the possibility of checking this out with capability args in the meanwhile, and we'll circle back to it to make sure it's necessary.
@dougbtv @s1061123 I think that this refers to the fact that you don't have to go to the apiserver to fetch the labels and the annotations of the pod if you set this option in containerd and crio https://github.com/kubernetes/kubernetes/issues/69882#issuecomment-1701125419, as those values will be available in the CNI ADD request @mikezappa87
Basically you can save this API call and get it from the capabilities
https://github.com/k8snetworkplumbingwg/multus-cni/blob/53a68c35ffc9dbdf61960b85309714ebc381613d/pkg/k8sclient/k8sclient.go#L407-L421
This would be a useful feature for my own use-case -- to pass node affinity/taint information concerning particular network attachments onto pods that use them.
Hi, this feature would help our CNI to get some pod annotations directly and avoid implementing token management for it to access api-server...