Dynatrace Operator release notes version 1.2.0
Release date: Jun 24, 2024
If you're running Dynatrace Operator v1.2.0 or v1.2.1, we recommend upgrading to version v1.2.2 to get the latest important patches.
New features and enhancements
-
A new DynaKube API version v1beta2 has been introduced
-
We advise you to update the current DynaKube files to the new version. Versions currently deployed in the Kubernetes cluster will be automatically updated to the new API version by the Dynatrace Webhook.
-
The following feature flags have been removed and replaced by fields in the new DynaKube API version:
feature.dynatrace.com/dynatrace-api-request-threshold
replaced byspec.dynatraceApiRequestThreshold
feature.dynatrace.com/oneagent-seccomp-profile
replaced byspec.oneagent.<monitoringmode>.secCompProfile
feature.dynatrace.com/metadata-enrichment
replaced byspec.metadataEnrichment
-
The following fields were added to the DynaKube:
spec.dynatraceApiRequestThreshold
: The minimum time in minutes between requests from the Dynatrace Operator, which was previously hard coded to 15 minutes in order to reduce network load. The specified interval is counted independently for each of these request.spec.metadataEnrichment
: Dedicated section to configure metadata enrichment. (See Standalone metadata enrichment)spec.oneagent.<monitoringmode>.namespaceSelector
: Applicable only forapplicationMonitoring
orcloudNativeFullStack
. The namespaces where you want OneAgent (codeModules) to be injected.spec.oneagent.<monitoringmode>.secCompProfile
: Enables or disables the adding of a default seccomp-profile to the Dynatrace init-container. The seccomp (secure computing mode) profile determines the system calls that a process in the initContainer can make. By default, the seccomp profile is not set. If enabled theRuntime/default
seccomp profile added, see Enable seccomp profile for Dynatrace init containers.
-
-
Standalone metadata enrichment:
-
Kubernetes and Dynatrace metadata are used to enrich observability signals (for example, traces, metrics, and logs) before ingesting them into the Dynatrace platform. To achieve this, the Dynatrace Operator creates and injects metadata files into pods that match the
namespaceSelector
specified inspec.metadataEnrichment
-
Starting with this Operator version, metadata enrichment can be configured independently of the OneAgent.
-
No action is needed if you want to continue using metadata enrichment coupled with
applicationMonitoring
orcloudNativeFullStack
. The webhook will automatically convert your DynaKube custom resource from v1beta1 to v1beta2. If you want to configure metadata enrichment independently, adjust your DynaKube to v1beta2 and use themetadataEnrichment
section in your DynaKube. Note: If you useclassicFullStack
, metadata enrichment is automatically turned off for converted DynaKubes. You can enable it by editing your v1beta2 DynaKube custom resource. -
Configuration example:
spec:metadataEnrichment:enabled: truenamespaceSelector:matchLabels:app: otel-demoFor DynaKube samples, see the GitHub page.
-
- The Operator image is now built and released for the s390x architecture.
- For OneAgents in version 1.288+ the
readOnlyRootFileSystem
field in the SecurityContext is now always set to true.
- The
tenantUUID
is no longer parsed from theapiUrl
, but retrieved directly from the environment.
- Added shortnames
dk
anddks
for DynaKube to improve kubectl command usability.
Resolved issues
- Fixed an issue with metadataEnrichment, where
k8s.workload.kind
andk8s.workload.name
were set tounknown
incorrectly if the last parent of the object was an unknown workload. They are now set to the last known workload type in the hierarchy. E.gCustomResource
->Deployment
->ReplicaSet
->Pod
. The owner in this case would be theDeployment
, as it is the last well-known object in the hierarchy.
- Fixed an issue in which the support archive was corrupted by a rogue log line when created using the
--stdout
command line switch.