Some applications, such as KFServing, require that cert-manager be exposed on the default service endpoint, https://cert-manager-webhook.cert-manager.svc.
However, in Konvoy, cert manager uses a non-default name in order to prevent collisions with app instances set up in the default userspace. As a result, it is exposed at https://cert-manager-kubeaddons-webhook.cert-manager.svc.
To work around this, you can expose the cert-manager-kubeaddons-webhook at a secondary service endpoint with this command:
You can verify that the service was created by running:
This will make it so that the cert-manager-kubeaddons-webhook will be accessible via https://cert-manager-webhook.cert-manager.svc and https://cert-manager-kubeaddons-webhook.cert-manager.svc, so applications will be able to access it either way.
However, in Konvoy, cert manager uses a non-default name in order to prevent collisions with app instances set up in the default userspace. As a result, it is exposed at https://cert-manager-kubeaddons-webhook.cert-manager.svc.
To work around this, you can expose the cert-manager-kubeaddons-webhook at a secondary service endpoint with this command:
kubectl expose deployment -n cert-manager cert-manager-kubeaddons-webhook --type=ClusterIP --name=cert-manager-webhook --port=443 --target-port=10250
You can verify that the service was created by running:
kubectl get service -n cert-manager | grep cert-manager-webhook
This will make it so that the cert-manager-kubeaddons-webhook will be accessible via https://cert-manager-webhook.cert-manager.svc and https://cert-manager-kubeaddons-webhook.cert-manager.svc, so applications will be able to access it either way.