Open phoracek opened 5 years ago
Thanks for opening this issue.
I am not sure what is the best approach to take care of this, I was able to think on one that is to run on namespaces like kube-system
and openshift-*
and add them the kubemacpool/ignoreAdmission
label.
I wasn't able to find a pre configured label on this namespaces
kubectl get ns kube-system -o yaml
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: 2019-07-22T14:44:27Z
name: kube-system
resourceVersion: "9"
selfLink: /api/v1/namespaces/kube-system
uid: 34c2dc75-ac8f-11e9-ae51-525500d15501
spec:
finalizers:
- kubernetes
status:
phase: Active
Yeah, the missing label is a problem. And labelling those ourselves sounds little unclean. But maybe it's better than just blocking the whole system.
Could you at least check openshift, does it have any labels on its kube-system?
@phoracek on openshift we only have annotations
apiVersion: v1
kind: Namespace
metadata:
annotations:
openshift.io/sa.scc.mcs: s0:c17,c4
openshift.io/sa.scc.supplemental-groups: 1000280000/10000
openshift.io/sa.scc.uid-range: 1000280000/10000
creationTimestamp: "2019-07-22T07:49:18Z"
name: kube-system
resourceVersion: "9333"
selfLink: /api/v1/namespaces/kube-system
uid: 35aec22e-ac55-11e9-ab52-664f163f5f0f
spec:
but again not labels.
you think it's a good solution to add labels by the operator I am really not sure?
Maybe we can follow the opposite way. Administrator has to create NetworkAttachmentDefinitions
per each namespace to make them available for users. If the admin wants to enable KubeMacPool, they have label the namespace appropriately. This will need further discussion, but I think it would be fair. Also it would give us an easy way to disable it in case something goes wrong.
There are some namespaces we should ignore during the admission. Especially system namespaces should not rely on KubeMacPool stability.