Kubernetes Automation is currently in Preview release and only accessible to selected customers. If you would like to share feedback or ideas, join the preview by signing up via this form or contacting your Customer Success Manager.
For more information, see
After you join the preview program for Kubernetes Automation, we'll provide Hub subscription details. With those subscription details, you can activate the capability by following these steps.
This guide provides detailed steps for provisioning EdgeConnect for Kubernetes Automation. After executing the steps, you have deployed permissions as well as EdgeConnect in your Kubernetes cluster so that EdgeConnect can route the API requests executed by the Kubernetes workflow actions to the Kubernetes API.
All requests from the Kubernetes Automation workflow actions are sent via EdgeConnect to the Kubernetes API server. You can use Kubernetes Role-based access control (RBAC) to control what actions are allowed in the workflow.
This guide explains how to set up the permissions by deploying a dedicated ServiceAccount
used by the EdgeConnect pods, a Role
/ClusterRole
and a RoleBinding
/ClusterRoleBinding
to control what actions are allowed in the workflow. Ensure that the permissions of the Role
/ClusterRole
are sufficient for the tasks your workflows need to accomplish. For example, if you need a list of pods in your workflow, the Role
must provide the permissions to make those API calls.
The EdgeConnect pods require a Kubernetes service account to authenticate to the Kubernetes API server.
Create a ServiceAccount
object with a definition similar to this example.
apiVersion: v1kind: ServiceAccountmetadata:name: edgeconnect-deployment-rollout-restarternamespace: dynatrace
Apply the ServiceAccount
.
kubectl apply -f edgeconnect-serviceaccount.yaml
To grant permissions to the ServiceAccount
, you need to define a Role
or ClusterRole
.
Create a Role
or a ClusterRole
. For example, if you would like to implement the use case for restarting a deployment in a workflow, the Role
needs the following permissions.
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: edgeconnect-deployment-rollout-restartnamespace: myservicerules:- apiGroups: ["apps"]resources: ["deployments"]verbs: ["get", "list", "patch"]
Apply the Role
.
kubectl apply -f edgeconnect-role.yaml
We recommend applying the least privilege when defining the Role
, adding only the necessary permissions.
To grant the permissions defined in the Role
/ClusterRole
to the ServiceAccount
, you need to specify a RoleBinding
/ClusterRoleBinding
.
Create a RoleBinding
or ClusterRoleBinding
. For example, if you want to grant permission to the previously defined Role
to the ServiceAccount
, specify a RoleBinding
similar to this.
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: edgeconnect-deployment-rollout-restartnamespace: myserviceroleRef:kind: Rolename: edgeconnect-deployment-rollout-restartapiGroup: rbac.authorization.k8s.iosubjects:- kind: ServiceAccountname: edgeconnect-deployment-rollout-restarternamespace: dynatrace
Apply the RoleBinding
.
kubectl apply -f edgeconnect-rolebinding.yaml
Roles
and RoleBindings
must exist in the same namespace. Roles
and RoleBindings
can exist in separate namespaces from ServiceAccounts
. This allows you to deploy your Role
and RoleBinding
in the namespace in which your Dynatrace Workflows should operate. The ServiceAccount
and EdgeConnect
deployments can be deployed in a different namespace, for example, dynatrace
.
There are two approaches for deploying EdgeConnect in your Kubernetes cluster
Follow one of the approaches to deploy EdgeConnect.