Good day!
What I am doing:
I am deploying Couchbase clusters using the CAO 2.6 on a newly stood up Openshift 4.14
What is not working:
I deploy both the operator and admission pods into the same namespace as well as the cluster, the test cluster that I deploy gets stuck on Ready 0/1, the port does not listen and returns a connection refused, as if the service is not starting and 8091 is not binding to the address
What does work :
something very interesting, this all works perfectly if I use the default namespace, the moment I move everything to a namespace, the cluster does not build, gets stuck on the very first pod and throws an error in the event that the liveness probe failed, the operator and admission pod do build and work, I did also notice that the liveness probe also failed on operator pod, could be that it was still coming up ? but the pod does complete fine.
What have a I tried
- All posts within this forum on the same topic as this was already asked before and not willing to hijack an older post
- I tried the multi tenant network policy as recommended in a previous post
- I have tried the Couchbase Cluster on Kubernetes failing readiness probe post whereby a oc add policy is applied
- I am using kubeadmin user
- I have followed the Autonomous Operator 2.6 guide to the tee, I have also tried to append --namespace= to the bin/cao command when creating the pods, the crds are applied and the create-user-role is also applied.
- I am using Red Hat’s image from their repository as mentioned in the setup guide
There aren’t any logs besides from the “Member creation failed” log in operator and the dial tcp : connection refused, I also noticed that using the default namespace, the cluster fqdn is node.cluster.default.svc, which would point to the default namespace I am assuming with the default part, now this should change to the actual namespace then ? but the service does not start in order for me to actually verify this, I originally thought the fqdn was not being changed hence why its not starting.
The exact same error that I have is from Couchbase Cluster on Kubernetes failing readiness probe…
I guess this is something related to permissions, or a configuration done on default that’s not on the new namespaces - any advise would be appreciated.