EdgeConnect for Kubernetes Automation

Preview release

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.

Prerequisites

Role-based Access Control Setup for EdgeConnect

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.

Define service account

The EdgeConnect pods require a Kubernetes service account to authenticate to the Kubernetes API server.

  1. Create a ServiceAccount object with a definition similar to this example.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: edgeconnect-deployment-rollout-restarter
      namespace: dynatrace

  2. Apply the ServiceAccount.

    kubectl apply -f edgeconnect-serviceaccount.yaml

Define Role/ClusterRole

To grant permissions to the ServiceAccount, you need to define a Role or ClusterRole.

  1. 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/v1
    kind: Role
    metadata:
      name: edgeconnect-deployment-rollout-restart
      namespace: myservice
    rules:
      - apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["get", "list", "patch"]

  2. Apply the Role.

    kubectl apply -f edgeconnect-role.yaml

We recommend applying the least privilege when defining the Role, adding only the necessary permissions.

Define RoleBinding/ClusterRoleBinding

To grant the permissions defined in the Role/ClusterRole to the ServiceAccount, you need to specify a RoleBinding/ClusterRoleBinding.

  1. 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/v1
    kind: RoleBinding
    metadata:
      name: edgeconnect-deployment-rollout-restart
      namespace: myservice
    roleRef:
      kind: Role
      name: edgeconnect-deployment-rollout-restart
      apiGroup: rbac.authorization.k8s.io
    subjects:
    - kind: ServiceAccount
      name: edgeconnect-deployment-rollout-restarter
      namespace: dynatrace

  2. 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.

Deploy EdgeConnect in Kubernetes

There are two approaches for deploying EdgeConnect in your Kubernetes cluster

Follow one of the approaches to deploy EdgeConnect.

Related topics