OpsLevel Agent

The OpsLevel agent is a multi-facet application that runs in your cloud and connects with OpsLevel to support multiple functionalities for OpsLevel. The current functionalities are:

• Kubernetes Service Detection (Aliases)

https://github.com/OpsLevel/opslevel-agent

Primer

To see the agent in action you can watch this primer video
https://opslevel.zoom.us/clips/share/A2F3MRZiQkhwOTJDRVJ0ZUYtMnNtMnJUMzBRAQ

Prerequisites

• Make sure you have the OpsLevel Helm chart repository added.
• Make sure you have the "kubernetes integration" installed in your opslevel account

Values.yaml

The bare minimum values file look like this

secret:
  data:
    OPSLEVEL_API_TOKEN: "XXXXX"

helm install opslevel-agent opslevel/opslevel-agent -f values.yaml

Multiple Clusters

If you intend to deploy the agent to multiple clusters you may want to create a unique
integration tile in your OpsLevel account for each cluster so that you know which cluster the recommendations are coming from.
If you do this you'll need to specify the integration's alias in the values file you'll want the agent to submit for like this:

agent:
  integration: "prod-cluster"

Resource Targeting

By default the agent will target the following resources:

• v1/Service
• apps/v1/Deployment
• apps/v1/StatefulSet
• apps/v1/DaemonSet
• batch/v1/CronJob

but if you want other resource types to make suggestions you can add configuration so long as the
resource types show up when you use kubectl api-resources --verbs="get,list".

The following restricts the agent to only syncronize Service and APIService resources:

configmap:
  data:
    config.yaml: |
      selectors:
      - apiVersion: "v1"
        kind: Service
      - apiVersion: "apiregistration.k8s.io/v1"
        kind: APIService

Migration from Legacy Integration

Prior to the opslevel-agent the way to integrate OpsLevel with Kubernetes was using the kubectl-opslevel tool. In the interim while we progress to make the opslevel-agent have similar functionality you can run both tools at the same time using the same Kubenetes integration and API token. The key change you'll want to make to your kubectl-opslevel deployment is to turn on the flag --disable-service-create so that it will only "update" services with alias matches.

By doing this you can effectively "gate" which Kubernetes services are synchronized with kubectl-opslevel by first having them show up as "suggestions" in OpsLevel and then only after you accept those suggestions the next time kubectl-opslevel synchronizes it will find the service with that alias and perform a reconciliatory update.

This is only an interim state while opslevel-agent does not have 100% component field parity.