chrisegner
commented
2 years ago I'm also experiencing this in the context of RH ServiceMesh 2.0 on OpenShift 4.7. As @ntxt mentioned, this used to work. We noticed certificates are expired and not renewing. I see the same stanza with the exposer route not admitted due to HostAlreadyClaimed. In my case, the offending route is the one that gets created by RHSM (istio) Gateway.
(Note: RHSM copies annotations from the Gateway to the Openshift Route object. Details https://docs.openshift.com/container-platform/4.7/service_mesh/v2x/ossm-traffic-manage.html#ossm-auto-route-annotations_routing-traffic)
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: api-gateway
annotations:
kubernetes.io/tls-acme: "true"
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
httpsRedirect: true
hosts:
- api-foo-dev.example.com
- api-bar-dev.example.com
- api-baz-dev.example.com
- api-qixx-dev.example.com
- api-quxx-dev.example.comThat causes the main route to get created in the service mesh's namespace in addition to the exposer route. These two routes conflict. If I remove the annotation, only the main route exists.
$ oc get route -n develop-istio-system
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
api-gateway-1b49626edxx api-foo-dev.example.com istio-ingressgateway https passthrough/Redirect None
api-gateway-25ac42f2exx api-bar-dev.example.com istio-ingressgateway https passthrough/Redirect None
api-gateway-2e7f2c82bxx api-baz-dev.example.com istio-ingressgateway https passthrough/Redirect None
api-gateway-7142b43bcxx api-qixx-dev.example.com istio-ingressgateway https passthrough/Redirect None
api-gateway-ba7b8c932xx api-quxx-dev.example.com istio-ingressgateway https passthrough/Redirect None
exposer-4dc3fbdoncopqm03ssi4khkxx HostAlreadyClaimed /.well-known/acme-challenge/wnq3LxaXxxxx exposer-4dc3fbdoncopqm03ssi4khkxx <all> edge/Allow None
exposer-bo90lih5l4fnd336d163ur0xx HostAlreadyClaimed /.well-known/acme-challenge/2tvd6HrLxxxx exposer-bo90lih5l4fnd336d163ur0xx <all> edge/Allow None
exposer-osfb5gnj37o8rr68g24a8eqxx HostAlreadyClaimed /.well-known/acme-challenge/_pUV-Af0xxxx exposer-osfb5gnj37o8rr68g24a8eqxx <all> edge/Allow None
exposer-ota457irmli2gpdaetqbkbfxx HostAlreadyClaimed /.well-known/acme-challenge/51CLcTDyxxxx exposer-ota457irmli2gpdaetqbkbfxx <all> edge/Allow None
exposer-pjqm1ebiea7nn5p41tcptt6xx HostAlreadyClaimed /.well-known/acme-challenge/TFXPfY8Bxxxx exposer-pjqm1ebiea7nn5p41tcptt6xx <all> edge/Allow NoneAny advice on a workaround is appreciated.
What happened: I have run the following script with a resource file below, the deployment and a passthrough route got created with the annotation pointing to a TLS secret. The secret gets created but the cert and key values are not populated, which makes the "docker-registry" fail looking for them (the secret is mounted to the container). The exposer route gets rejected with "HostAlreadyClaimed". What you expected to happen: The secret should get populated with the key and cert values, "docker-registry" should see and use them to secure the requests passed through by the route. How to reproduce it (as minimally and precisely as possible):
openshift-acme logs:
Anything else we need to know?: I had this setup working for a few days (passthrough route + TLS secret mounted into a pod) but after recreating it in another namespace both stopped to work. No duplicate routes are present in any namespaces, double checked. Environment:
@tnozicka