Use a GitOps approach to run Turbonomic actions on Red Hat OpenShift and Kubernetes

GitOps is becoming a de facto approach to manage workloads on Red Hat OpenShift (and Kubernetes). GitOps is based on the “single source of truth” principle, where the desired state of the system is stored. A continuous delivery (CD) tool or pipeline always syncs this desired state into a target cluster.

IBM Turbonomic manages these clusters at scale by recommending appropriate actions on the cluster resources, to drive an optimized state. These actions generally are the changes to resource specifications. Turbonomic also has capability to apply these changes to the resources in Red Hat OpenShift (and Kubernetes) so as to maintain the desired optimal state. But, with a CD tool and GitOps approach in place, Turbonomic cannot directly execute actions on the cluster resources.

However, with GitOps integration, Turbonomic understands the source of truth details. Hence, it applies changes required for desired state directly back to the source of truth as a direct commit or via a Pull Request/Merge Request back into the resource yaml stored in the source of truth.

This tutorial explains how Turbonomic can integrate with GitOps tools, taking ArgoCD as example, to seamlessly manage Red Hat OpenShift or Kubernetes clusters.

In this tutorial you will:

• Create a secret for GitHub token in Red Hat Openshift cluster.
• Deploy kubeturbo on a Red Hat OpenShift cluster, with GitOps integration.
• Deploy a sample ArgoCD application on the Red Hat OpenShift cluster.
• Review the recommended actions for the application in Turbonomic and run those actions.
• Review the changes that were made by Turbonomic in single source of truth (a GitHub repository).

Prerequisites

Users should have experience working with Turbonomic (read more in this article, "Understanding Application Resource Management using Turbonomic”), Red Hat OpenShift (learn more in this getting started guide), and Argo CD (learn more in this getting started guide in the docs).

1. Access to Turbonomic ARM platform or SaaS instance.
2. Red Hat OpenShift cluster with cluster-admin access.
3. Red Hat OpenShift GitOps Operator installed in Red Hat Openshift cluster. Red Hat OpenShift GitOps implements Argo CD as a controller.
4. GitHub account.
5. The OpenShift (oc) and kubectl CLI tools on the machine where you are completing the tutorial.

Turbonomic and GitOps Deployment Architecture

The overall architecture of the scenario is shown in the following figure.

In a Red Hat OpenShift cluster, we have the openshift-gitops operator is deployed. Red Hat OpenShift GitOps implements Argo CD as a controller. An application is deployed and managed by Argo CD, which syncs the desired state of the application from application yamls stored in a GitHub repository to target resource specs in the OpenShift cluster. The Turbonomic server monitors and manages this Red Hat OpenShift cluster using the Kubeturbo deployment along with GitOps integration. When action recommendations for the Argo CD application are run, Turbonomic changes the application yaml and performs a commit to the GitHub repository, which is then synced by the Argo CD operator in the cluster.

Steps

Step 1: Create a secret for a GitHub token in the Red Hat Openshift cluster

You need to create this secret for your GitHub personal access token, such that you can deploy the kubeturbo custom resource with GitOps integration (which you do in the next step).

To generate GitHub personal access tokens, read the GitHub docs.

1. In the OpenShift web console, Go to Workloads > Secrets and set the scope to default project.

2. Click Create > Key/value secret. Specify "github-secret" as the secret name and specify "token" as the key. Then, for the value, specify your own GitHub personal access token.

   

Step 2: Deploy the kubeturbo operator on the Openshift

1. For Turbonomic to provide visibility and control for assuring performance of workloads running in an OpenShift cluster, you need to install the kubeturbo operator following the kubeturbo documentation.

2. Edit the custom resource yaml file, deploy/crds/charts_v1alpha1_kubeturbo_cr.yaml. (For more information on the custom resource yaml file, see the kubeturbo documentation.)

   For the serverMeta section, specify these values:

    version: <Turbonomic Server version>
    turboServer: <Turbonomic Server URL>
   

   For the restAPIConfig section, specify these values:

    opsManagerUserName: <User to log into Turbonomic >
    opsManagerPassword: <Password to log into Turbonomic >
   

   For the targetConfig section, specify these values:

    targetName: <Unique identification name for Kubernetes clusters >
   

   For the args section, specify these values:

    gitEmail: "<Email id associated with GitHub account>"
    gitUsername: "<GitHub Username>"
    gitSecretName: "github-secret"
    gitSecretNamespace: "default"
    gitCommitMode: "direct"
   

   For the image section, specify these values:

    repository:  operatorhub.io/operator/kubeturbo
    tag: <Turbonomic server version>
   

   The following screen capture shows a sample customer resource yaml file.

   

3. Deploy kubeturbo by creating a "kubeturbo" custom resource. The operator will create the kubeturbo product deployment and related resources.

    kubectl apply -f deploy/crds/charts_v1alpha1_kubeturbo_cr.yaml -n turbo
   

Step 3: Deploy a sample Argo CD application on the Red Hat OpenShift cluster

In this step, an Argo CD application is deployed to demonstrate the GitOps integration feature. We will create an Argo CD sample application to deploy a Kubernetes application in a Red Hat OpenShift cluster. You need to create Kubernetes application yamls in the GitHub repository.

1. Create a repository in your GitHub account. In this repository, create a directory with the name gitops-multifile. Create three yamls in the gitops-multifile directory of this repository: beekman-one-more.yaml, beekman-orig.yaml, and service.yaml.

   beekman-one-more.yaml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      annotations: null
      labels:
        app: bee
      name: beekman-one-more
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: bee
      template:
        metadata:
          labels:
            app: bee
        spec:
          containers:
          - env:
            - name: RUN_TYPE
              value: cpu
            - name: CPU_PERCENT
              value: "95"
            image: quay.io/ecotz/sampleapp:latest
            imagePullPolicy: Always
            name: beekman-1
            resources:
              limits:
                cpu: 11m
                memory: 28Mi
              requests:
                cpu: 10m
                memory: 10Mi
            terminationMessagePath: /dev/termination-log
            terminationMessagePolicy: File
          dnsPolicy: ClusterFirst
          imagePullSecrets:
          - name: docker-credentials
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext: {}
          terminationGracePeriodSeconds: 30
   

   beekman-orig.yaml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: bee
      name: beekman-change-reconciler
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: bee
      template:
        metadata:
          labels:
            app: bee
        spec:
          containers:
          - env:
            - name: RUN_TYPE
              value: cpu
            - name: CPU_PERCENT
              value: "95"
            image: quay.io/ecotz/sampleapp:latest
            imagePullPolicy: Always
            name: beekman-1
            resources:
              limits:
                cpu: 11m
                memory: 28Mi
              requests:
                cpu: 10m
                memory: 10Mi
            terminationMessagePath: /dev/termination-log
            terminationMessagePolicy: File
          - env:
            - name: RUN_TYPE
              value: cpu
            - name: CPU_PERCENT
              value: "95"
            image: quay.io/ecotz/sampleapp:latest
            imagePullPolicy: Always
            name: beekman-2
            resources:
              limits:
                cpu: 11m
                memory: 28Mi
              requests:
                cpu: 10m
                memory: 10Mi
            terminationMessagePath: /dev/termination-log
            terminationMessagePolicy: File
          dnsPolicy: ClusterFirst
          imagePullSecrets:
           - name: docker-credentials
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext: {}
          terminationGracePeriodSeconds: 30
   

   service.yaml

    apiVersion: v1
    kind: Service
    metadata:
      name: bee
      labels:
        app: bee
    spec:
      ports:
      - port: 80
        name: web
      selector:
        app: bee
   

2. In the terminal, log in to the OpenShift cluster by using the oc login command.

    oc login --token=<login-token> --server=<OpenShift API Server:Port>
   

3. Copy the following content in to the gitops-cluster-role-binding.yaml file on your local machine.

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: argocd-application-controller-cluster-admin
    subjects:
      - kind: ServiceAccount
        name: openshift-gitops-argocd-application-controller
        namespace: openshift-gitops
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-admin
   

4. Run the following command to create the cluster-admin role binding for the openshift-gitops-argocd-application-controller service account.

    oc create -f gitops-cluster-role-binding.yaml
   

   This step is required for Argo CD to perform required changes to target configurations across all namespaces in the Kubernetes cluster. If the Argo CD controller service account has this role assigned already, you can skip this step.

5. Run the following command to create a namespace argocd-test. This namespace is for deploying sample application yamls.

    oc create namespace argocd-test
   

6. (Optional) Create a secret named docker-credentials by running the following command. By creating this secret creation you can avoid the "docker-rate-limit exceeded" error which might occur at times due to access image pulls from Quay container registry without authentication. Replace <docker-acct-username>, <docker-acct-password> and <email-id> with your quay.io account username, password, and email respectively.

    oc create secret docker-registry docker-credentials --docker-server=quay.io --docker-username=<docker-acct-username> --docker-password=<docker-acct-password>  --docker-email=<email-id> -n argocd-test
   

7. Copy the following contents into the gitops-multifile.yaml file on your local machine.

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: gitops-multifile
      namespace: openshift-gitops
    spec:
      destination:
        namespace: argocd-test
        server: https://kubernetes.default.svc
      project: default
      source:
        path: gitops-multifile
        repoURL: <your_github _repo_url>
        targetRevision: HEAD
      syncPolicy:
        syncOptions:
        - PruneLast=true
        - RespectIgnoreDifferences=true
        - CreateNamespace=true
        - ApplyOutOfSyncOnly=true
   

   Replace <your_github _repo_url> value in the file with the URL of the GitHub repository you forked in the beginning of this step.

8. Create the Argo CD application by running following command:

    oc create -f gitops-multifile.yaml
   

   This Argo CD application deploys sample application yamls present in the gitops-multifile directory of the GitHub repository into the argocd-test namespace of the cluster when the synchronization completes.

9. Log in to Argo CD instance in the browser, using its admin account. Follow these instructions in the Red Hat OpenShift documentation.

   You will see the tile for Argo CD application that the gitops-multifile created in the previous step. Click the Sync button.

   

10. In the side window, click the SYNCHRONIZE button.

    

    When the Argo CD application completes the synchronization, we can see the following screen that depicts application resources created in the target cluster as per the resource specs that exist in the single-source-of-truth, the GitHub repository.

    

Step 4: Review and run the recommended actions for the application

In this step, you review the recommendations provided by Turbononmic for performance assurance or optimization.

1. Log in to the Turbonomic console. On the home page, under “Top Business Applications” section, we can now see the Argo CD application listed as a Turbonomic business application, openshift-gitops/gitops-multifile.

   

   The action recommendations for the Argo CD application will be generated over a period of time when Turbonomic monitors the application and detects performance issues.

2. Click that application, to scope the view to the Argo CD app. In the application page, review the details of application supply chain, and then click the SHOW ALL link in the Pending Actions section to navigate to the Action Center.

   

3. In the Action Center, select Workload controllers in the left nav to view resize actions recommendations that Turbonomic provided due to the performance issues. Click the Details button for the first action to view the details.

   

   The Action Details page provides the details of performance issue and recommendation to resize virtual CPU limit from 11m cores to 200m cores.

4. After reviewing the details click the EXECUTE ACTION button at the bottom of the page.

   

   The action is executed by Turbonomic and completes the required changes. In this example, code is changed and committed to the GitHub repository, which is the single-source-of-truth. When action execution has completed, a green check mark appears next to the action.

   

Step 5: Review the changes made by Turbonomic in single source of truth

In this step, you will review the changes made by Turbonomic in GitHub repository as a result of action execution done in previous step. These are the changes to resource specifications as per recommendations provided by Turbonomic.

1. Open the GitHub repository and navigate to the gitops-multifile directory where application yamls are stored.

2. Open the beekman-orig.yaml file, and view the changes that were made by Turbonomic as part of action execution.

   

3. As the Argo CD application synchronization policy is not set to “Auto-Sync”, open the Argo CD instance and notice that application is now out of sync.

   

4. Click the Sync button, and then on the bottom of the next page click the Synchronize button, so that Argo CD can sync changes from the GitHub repository into the cluster resources, which completes the Turbonomic action execution with GitOps integration.

   The Argo CD application can be enabled to perform Auto-Sync, in which case Argo CD keeps polling the single source of truth and automatically syncs the changes to maintain the desired state.

Summary and next steps

In this tutorial, you learned how to deploy kubeturbo to enable GitOps integration in Turbonomic. With this integration in place, Turbonomic understands the single source of truth details and performs action execution by committing the changes required to the GitHub repository. These changes will then be deployed to the target cluster by a CD tool like Argo CD as per a GitOps approach.

Ready to try Turbonomic for yourself to improve the performance of your applications? Register for a free Turbonomic trial account.