With the introduction of later Dynatrace operator versions (such as Operator 0.14.0 and 0.15.0), the operator now performs more checks to ensure your deployment does not crash or see errors when deploying your dynakube.yaml custom resource. One of these checks is to reach out to the image repository where the operator is to reach out and pull the necessary images from and confirm the version of the image is correct. In doing so, it checks the certificate authority of the image repository to ensure it can trust the connection. If you are using a custom Certificate Authority (CA) certificate in your network, are using a custom CA certificate for a managed cluster, or you are using an image repository that has it's own CA certificate, you will likely receive the following error shown in your Dynatrace Operator pod:
{"level":"info","ts":"2024-02-26T21:06:49.315Z","logger":"dynakube-version","msg":"updating image version info for tenant registry image","image":"[DNS]/linux/activegate:latest","oldImageID":"","oldVersion":""}
{"level":"info","ts":"2024-02-26T21:06:49.379Z","logger":"dynakube-version","msg":"failed to determine image version"}
{"level":"info","ts":"2024-02-26T21:06:49.379Z","logger":"dynakube","msg":"could not reconcile component versions"}
getting reference \"[DNS]/linux/activegate:latest\"","ts":"2024-02-26T21:06:46.721Z"}{"error":"getting reference \"[DNS]/linux/activegate:latest\": Get \"https://[DNS]/v2/\": tls: failed to verify certificate: x509: certificate signed by unknown authority"
...
Please note that "[DNS]" is the DNS of the image repository or Dynatrace cluster where the image is stored. This error is created because the Dynatrace operator does not have a CA certificate who's name matches an expected CA certificate. This is typically because the CA certificates do not match. To resolve this, you will need to provide the trusted CA certificate of the URL it is attempting to reach out to, to the Dynatrace operator. This can be done by using the following dynakube parameter trustedCAs. This parameter is documented here: DynaKube parameters for Dynatrace Operator.
The value for the trustedCAs parameter should be the name of the config map in the same namespace as the Dynatrace Operator. The contents of the config map should be as follows:
data:
certs: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Please note the following:
- The key of the config map is named "certs"
- If you need multiple CA certificates, they can be appended together.
Additionally, if you have the CA certificate file on the same system, you could use the following Kubernetes command to create the config map:
kubectl create configmap ca.crt --from-file=/path/to/certificate/ca.crt -n dynatrace
From here, you would need to add the name of the CA certificate to the dynakube. The following is an example snippet of your dynakube:
apiVersion: dynatrace.com/v1beta1
kind: DynaKube
metadata:
name: dynakube
namespace: dynatrace
spec:
apiUrl: https://[URL]/api
trustedCAs: ca.crt
Finally, please note this issue is separate from an already known common issue defined here: https://community.dynatrace.com/t5/Troubleshooting/Internal-error-occurred-failed-calling-webhook-x5....
