Hello,I am following the installation guide for Submariner via Helm. I have two on-prem OpenShift 4.6 clusters I am looking to link with Submariner. These two clusters are located on the same subnet, and they do not have overlapping IPs.I have not configured GlobalNet since the cluster IPs do not overlap, and I also disabled NAT, as I do not think there would be NAT'ing between the gateways.
After the installation of the Broker and Submariner Operator on Cluster A, I noticed that there were errors in the events related to the Lighthouse service account. Lighthouse Agent and Lighthouse CoreDNS required the "submariner-lighthouse" service account to run. To move past this for temporarily, I created this service account manually and provided it with permissions, and Lighthouse Agent and Lighthouse CoreDNS started coming up.
After this, I observed that Lighthouse Agent was encountering issues talking to the API server on startup for the serviceimports and restarting. Looking at the logs, it is showing an error trusting the certificate for the API server. I will attach the logs.
From this, I have a couple questions:(1) Is there anything in the guide steps for Helm installation related to the service accounts to be created that I may have misconfigured?
(2) To resolve the certificate issue, is there anything I can provide to the deployment? If we needed to work around the issue temporarily, is there any way to disable certificate verification in Lighthouse Agent?
x509: certificate is valid for 172.30.0.1, not 10.5.57.171
which seems to be the IP of the internal endpoint of the API, that is weird.
Thank you very much for your time.
Regards,Joe--
You received this message because you are subscribed to the Google Groups "submariner-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to submariner-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/submariner-users/ff462625-6f14-40a7-aaac-714992733d69n%40googlegroups.com.
Hey Joe!Sorry for the delay in our response, I was supposed to respond but I got distracted by our 0.9 items.On Mon, Mar 22, 2021 at 11:16 PM Joe Grap <grap....@gmail.com> wrote:Hello,I am following the installation guide for Submariner via Helm. I have two on-prem OpenShift 4.6 clusters I am looking to link with Submariner. These two clusters are located on the same subnet, and they do not have overlapping IPs.I have not configured GlobalNet since the cluster IPs do not overlap, and I also disabled NAT, as I do not think there would be NAT'ing between the gateways.Ok, that makes sense. We are adding automatic nat/no-nat between endpoints in 0.9, hopefully that setting will go away at some point for now it will be the fall-back if the best configuration can't be determined.After the installation of the Broker and Submariner Operator on Cluster A, I noticed that there were errors in the events related to the Lighthouse service account. Lighthouse Agent and Lighthouse CoreDNS required the "submariner-lighthouse" service account to run. To move past this for temporarily, I created this service account manually and provided it with permissions, and Lighthouse Agent and Lighthouse CoreDNS started coming up.oh, that sounds like there is a problem with the service-account definition in helm. +Steve Mattar can you have an eye on that ^let's open a bug to track it in the charts repo.
To view this discussion on the web visit https://groups.google.com/d/msgid/submariner-users/CAC3B9fnH6_tb5SMX%2Bce1X7a_-BgPijjCV-gdN2UU93X6OgAaZA%40mail.gmail.com.
Hmm, and the submariner-gateway is ok?The CA & Token is passed down from the operator config, can check viakubectl get Submariner submariner -n submariner-operator -o yamlIf the contents of the CA & Token parameters make sense?I've seen also miss configuration sometimes in openshift, where the the kubeconfig has skipInsecureCertificates (or similar setting) so the FQDN of the api endpoints will not be checked on the certificate, but ... we don't have a setting for insecure certificates in submariner
oc get daemonsets -n submariner-operator
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
submariner-gateway 0 0 0 0 0 submariner.io/gateway=true 134m
submariner-globalnet 0 0 0 0 0 submariner.io/gateway=true 134m
submariner-routeagent 0 0 0 0 0 <none> 134m
There is not yet, I'm afraid, but we are considering adding it, can you help me by opening a bug on the submariner-operator?, we can propagate that setting down from there to submariner-gateway & lighthouse.
Did you have the opportunity to check with subctl? I wonder if it's any different for your specific openshift deployment in terms of the certificates.
Do you have a version of the Helm charts with PR #125 (merged about two weeks ago)? I think that should have fixed the Lighthouse SA issue (which is why Helm CI is passing).