3

The scenario: I'm having Apache Pulsar v2.6.0 deployed in Rancher Kubernetes, together with jetstack/cert-manager:

helm install cert-manager jetstack/cert-manager --namespace cert-manager --set installCRDs=true
helm install --values ./values.yaml pulsar apache/pulsar

I also configured TLS for all Pulsar components as follows (values.yaml):


tls:
  enabled: true
  # common settings for generating certs
  common:
    keySize: 2048
  # settings for generating certs for proxy
  proxy:
    enabled: true
  # settings for generating certs for broker
  broker:
    enabled: true
  # settings for generating certs for bookies
  bookie:
    enabled: true
  # settings for generating certs for zookeeper
  zookeeper:
    enabled: true

However, cert-manager generates the secrets names with a hash suffix, so when creating e.g. a Zookeeper pod, Kubernetes complains that it cannot find the tls secret and fails with the event 'MountVolume.SetUp failed for volume "zookeeper-certs" : secret "pulsar-tls-zookeeper" not found'.

Any idea how to handle this scenario?

user14321182
  • 51
  • 5

2 Answers2

2

I found the answer here: https://github.com/jetstack/cert-manager/issues/3283

The secrets that were generated (including the hash suffix) are used as next private keys for key rotation. The correct secrets containing both the current key and the certificate (which the others do not contain) would be generated next. However, due to a an error during ca cert generation for the issuer, this does not happen.

user14321182
  • 51
  • 5
0

You could disable the hash suffix for the secrets so the names are more predictable:

generatorOptions:
  disableNameSuffixHash: true
Rob Evans
  • 2,822
  • 1
  • 9
  • 15
  • This answer only makes sense for resources applied with Kustomize. It has nothing to do with the question, which is asking about secrets created by cert-manager in response to Certificate requests. – Fully Buzzword Compliant Nov 22 '22 at 16:43