You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you install MetalLB operator from the instructions given at OperatorHub.io it will install into the operators namespace.
If you happen to have also installed https://operatorhub.io/operator/intel-device-plugins-operator this doesn't work out very well because both operators Service selectors are exactly the same, and both of their pods have the same port (9443) and so kubernetes will end up routing things wrong.
Error from server (InternalError): error when creating "metallb.yaml": Internal error occurred: failed calling webhook "metallbvalidationwebhook.metallb.io": failed to call webhook: Post "https://metallb-operator-controller-manager-service.operators.svc:443/validate-metallb-io-v1beta1-metallb?timeout=10s": tls: failed to verify certificate: x509: certificate is valid for inteldeviceplugins-controller-manager-service.operators, inteldeviceplugins-controller-manager-service.operators.svc, not metallb-operator-controller-manager-service.operators.svc
I was briefly confused why the metallb-operator-controller-manager-service was using the wrong cert, but on further inspection I found it wasn't, the request had actually gone to to the intel-device-plugins-operator pods
This is because both services yaml look identical aside from the name:
If you install MetalLB operator from the instructions given at OperatorHub.io it will install into the
operators
namespace.If you happen to have also installed https://operatorhub.io/operator/intel-device-plugins-operator this doesn't work out very well because both operators
Service
selectors are exactly the same, and both of their pods have the same port (9443) and so kubernetes will end up routing things wrong.I was briefly confused why the metallb-operator-controller-manager-service was using the wrong cert, but on further inspection I found it wasn't, the request had actually gone to to the intel-device-plugins-operator pods
This is because both services yaml look identical aside from the name:
I think adding a label to the pods and selector of the service something like
app: metallb
would solve this.The text was updated successfully, but these errors were encountered: