cloudnative-pg / charts

CloudNativePG Helm Charts
Apache License 2.0
174 stars 82 forks source link

Setting up cloudnative-pg with istio mtls #327

Closed kndoni closed 1 month ago

kndoni commented 3 months ago

Hello I am trying to set up the latest version of cloudnative-pg in a kubernetes cluster. Istio is being used for handling traffic in the cluster and for some reasons it seems to not work when the helm chart is set up. In the service I can see that the service does not have an endpoint and also the pod is stuck on crashbackloop Any advices?

itay-grudev commented 2 months ago

Can you provide more information about the issue if you're still having it. Your description is quite vague.

kndoni commented 2 months ago

Hey @itay-grudev,

In the cluster I am trying to set cloudnative-pg I had to use an older version because in the newest version seccomprofile is enforced and in my cluster we are using kyverno and seccomprofile is not allowed. Right now I am using version 0.14.0 of the chart. I also have istio mtls in the cluster, so in order for cnpg operator to work I have to include the following annotations to the chart:

  annotations:
    proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
    traffic.sidecar.istio.io/excludeInboundPorts: "9443"
    traffic.sidecar.istio.io/excludeInboundPorts: "443"
    sidecar.istio.io/inject: "false"

After this annotations the operator works just fine. Then I try to depoy the cluster chart. Here is when I have the issue now. Since I have disabled istio on operator it has to be disabled on cluster as well. At first a job initdb is ran which spins up a pod and it seems that there is no way to add this annotations to the job that spins up the cluster. And therefore the pod of the job is stuck in crashbackloop state.

Any ideas on how can I solve this?

itay-grudev commented 1 month ago

Providing the following to the cluster chart will expose them to the cluster object:

cluster:
  additionalLabels: {}
  annotations: {}

According to the documentation here, they should be propagated to all the corresponding pods and jobs. If that's not the case I'd suggest raising a ticket on the Operator repository.