Issues with running Solace Helm chart with Redundancy and TLS enabled.

Trying to figure out what reason this would not work. I am able to use the solace helm chart (https://github.com/SolaceProducts/pubsubplus-kubernetes-quickstart) to run solace in my GKE kubernetes cluster with tls enabled using my cert secret, however when I enable redundancy, 2 of the pods will not become ready. I was able to confirm that if I run redundancy on with tls disabled, all 3 pods startup correctly. The pods themselves dont seem to give too much in the way of an error message, Readiness probe failed: Fri Feb 4 20:12:11 UTC 2022 INFO: readiness_check.sh-Waiting for valid server status response, got:

As well as: startup-broker.sh-Waited 110 seconds, Management API not yet accessible

<returnInfo><errorInfo>management host is not responding</errorInfo></returnInfo>

from the container logs.

There's a number of warnings in my container logs but nothing that stands out.


Curious if anyone has had this issue before if there is additional setup that is needed to use HA mode with TLS.

Answers

  • pkondrat
    pkondrat Member, Employee Posts: 27 Solace Employee

    Hi bcalitag,

    This issue should be fixed in the latest version of the chart (v3.0.0).

    Best Regards,

    Paul

  • bcalitag
    bcalitag Member Posts: 3

    Thanks Paul, this got me a bit closer but I'm still having a few issues. It looks like the startup-broker.sh is failing in the tls block when trying to curl the SEMP api to set the tlsServerCertContent. I got into the pod and tried to make the call myself and it is telling me my cert is invalid:


      "meta":{

        "error":{

          "code":2,

          "description":"Problem with tlsServerCertContent: The certificate in .sempV2/cert.pem is invalid.",

          "status":"FAIL"

        },

        "request":{

          "method":"PATCH",

                "uri":"https://localhost:1943/SEMP/v2/config/"

        },

        "responseCode":400

      }

    I did verify on my own machine that the cert file is valid, and has been tested with other services so I'm unsure why there would be issues. Do you have any insights?

  • pkondrat
    pkondrat Member, Employee Posts: 27 Solace Employee

    Just a wild guess but, that cert needs to have a private key in the same file. Is it possible that your .pem file does not contain the private key?

  • bcalitag
    bcalitag Member Posts: 3

    I'm using an kubernetes tls secret with both a crt and key file. I did verify they were both on disk before it cats the files and tries to update the semp config

  • pkondrat
    pkondrat Member, Employee Posts: 27 Solace Employee

    Without more to go on, I'd recommend to start over with a new test deployment from scratch, possibly even with a new key/certificate. Maybe the failing deployment is trying to reuse an old PVC or some other pre-condition.