Howdy!
This is 100% possible, however this does require that multiple dynakubes are used and there are some additional parameters which need to be set to deploy successfully. You will need 1 dynakube CRD for each node pool.
Referentially, i've built out the below on a GKE cluster with two node pools: "default-pool" and "super-cool-nodepool":
kubectl describe nodes | grep nodepool
cloud.google.com/gke-nodepool=super-cool-nodepool
cloud.google.com/gke-nodepool=super-cool-nodepool
cloud.google.com/gke-nodepool=super-cool-nodepool
cloud.google.com/gke-nodepool=default-pool
cloud.google.com/gke-nodepool=default-pool
cloud.google.com/gke-nodepool=default-pool
To get this deployed in Cloud Native Full Stack, I'd recommend the below yaml as a template:
---
apiVersion: dynatrace.com/v1beta2
kind: DynaKube
metadata:
name: default-pool
namespace: dynatrace
spec:
apiUrl: https://{environmentid}.live.dynatrace.com/api
tokens: "my-token"
skipCertCheck: false
oneAgent:
hostGroup: default-pool
cloudNativeFullStack:
namespaceSelector:
matchLabels:
monitor: default
nodeSelector:
cloud.google.com/gke-nodepool: default-pool
Some notes on the "whys" here:
- "name:" needs to be unique to the dynakube CRD as each nodepool requires a different configuration
- "token:" you can reuse the same token/ secret in the same cluster, but it must be called out via this parameter. if it is not the CRD will look for a token with the same value set in "name:" In my example i am using one token for both CRDS, but you could use a unique token for each CRD/ node pool.
- "hostGroup:" This is the recommended yaml syntax over "args" as called out by @chrismuellner
- "nameSpaceSelector:" Setting some unique form of APM injection in each dynakube CRD is required when leveraging multiple dynakubes in Cloud Native Full Stack or Application Only Mode. These two modes use our CSI drivers by default to perform APM injection, if there are injection rules which overlap or conflict the dynatrace operator will reject the dynakube. please note that my example would look for namespaces with the "default" label, not the "Default" namespace.
Depending on your use case for deploying into a single cluster with multiple CNFS dynakubes, it may be in best practices to deploy with dedicated Activegates per node pool. Note that you'll also want to add node selectors to those as well. For a six node cluster with two node pools you could use a single yaml file, but they are still separate dynakubes. Note in my yaml below i am also generating a token, which both dynakube crds are using:
apiVersion: v1
data:
apiToken: <REDACTED>
dataIngestToken: <REDACTED>
kind: Secret
metadata:
name: my-token
namespace: dynatrace
type: Opaque
---
apiVersion: dynatrace.com/v1beta2
kind: DynaKube
metadata:
name: default-pool
namespace: dynatrace
spec:
apiUrl: https://{environmentid}.live.dynatrace.com/api
tokens: "my-token"
skipCertCheck: false
oneAgent:
hostGroup: default-pool
cloudNativeFullStack:
namespaceSelector:
matchLabels:
monitor: default
nodeSelector:
cloud.google.com/gke-nodepool: default-pool
# Configuration for ActiveGate instances.
activeGate:
capabilities:
- routing
- kubernetes-monitoring
- dynatrace-api
replicas: 1
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: 1000m
memory: 1.5Gi
nodeSelector:
cloud.google.com/gke-nodepool: default-pool
---
apiVersion: dynatrace.com/v1beta2
kind: DynaKube
metadata:
name: super-cool-nodepool
namespace: dynatrace
spec:
apiUrl: https://{environmentid}.live.dynatrace.com/api
tokens: "my-token"
skipCertCheck: false
oneAgent:
hostGroup: super-cool-nodepool
cloudNativeFullStack:
namespaceSelector:
matchLabels:
monitor: super-cool-namespace
nodeSelector:
cloud.google.com/gke-nodepool: super-cool-nodepool
# Configuration for ActiveGate instances.
activeGate:
capabilities:
- routing
- kubernetes-monitoring
- dynatrace-api
replicas: 1
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: 1000m
memory: 1.5Gi
nodeSelector:
cloud.google.com/gke-nodepool: super-cool-nodepool
Which results in the below resources being deployed to the cluster
edit: One last note. I removed tolerations as it's not likely all your node pools are part of the control plane, but they may be relevant to your needs. The tolerations in your previously shared yaml are correct.
Featured Posts
