Application Adoption with Red Hat Advanced Cluster Management for Kubernetes and GitOps

[Red Hat]

In this blog, we will show you how to take an existing application and adopt it for management by Red Hat Advanced Cluster Management. Red Hat Advanced Cluster Management v2.1 brings us four pillars of management that cover what you need to manage enterprise OpenShift clusters at scale: cluster lifecycle; application lifecycle; governance, risk & compliance; and observability.

One piece of the puzzle when importing existing clusters is the currently deployed workloads on those clusters. With our replace capabilities, an applications manifest can be stored in Git, and then the application is adopted by the Advanced Cluster Management application lifecycle. You can then begin to manage your applications through GitOps and the application console.

In this example, we will use a sample application that you will deploy with the kubectl apply command, and then adopt into the application console.

Prerequisites

• You need a managed OpenShift cluster.
• You need a Red Hat Advanced Cluster Management hub cluster.
• Ensure you have an application that runs on Kubernetes.
• You also need GitHub access.

Apply an application

Applying the application manually is easy. See the procedure:

1. Log into the managed OpenShift cluster.
2. Fork the following demonstration repository: Demo GitOps.
3. Clone that repo to the system where you are connecting to the managed OpenShift cluster.
4. Create the namespace oc new-project nginx.
5. Apply the basic application with oc apply -k placement/nginx.

Now we have an application manifest applied manually to the managed cluster. This application consists of a deployment with a replica set, a service, and a route.

We adopt the application with Red Hat Advanced Cluster Management application lifecycle capabilities. Subscriptions are used for delivering and maintaining applications. To accomplish the adoption, you must build a copy of the application manifest in Git. If the application did not originate from a repository, using the Kubernetes CLI, extract the manifest information for each resource in the application. In our example, we use the following commands:

• kubectl get deploy nginx-placement -o yaml > deployment.yaml
• kubectl get route nginx -o yaml > route.yaml
• kubectl get service placement-nginx-service > service.yaml

If you’d like to use kustomize, create the following kustomization.yaml file:

resources:
  deployment.yaml
  service.yaml
  route.yaml

This all exists in the fork for this exercise, but if you are adopting a new application, you would then commit the resource YAML files to your Git repository.

With the artifacts in place in Git, we will initialize the application subscription for our managed cluster, which will adopt management of the application into Red Hat Advanced Cluster Management.

Adopting an application

By default, a subscription cannot apply resources from the source repository to the existing resources on the cluster if the resources are not created by the subscription.

In this exercise, we are going to apply the application artifacts from the Git repository to the cluster where the application artifacts already exist by using a subscription. In order to alter the default subscription behavior to overwrite existing resources, you need to log into Red Hat Advanced Cluster Management as a subscription administrator. See the following procedure to set up that role:

1. Log into the hub cluster using CLI.
2. Run oc edit clusterrolebinding open-cluster-management:subscription-admin and add a user or a group subject. See the following example:

subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: kube:admin

3. Save changes.
4. Log in to the Red Hat Advanced Cluster Management console as the subscription administrator.

Now you are ready to create:

1. Navigate to the Application overview page.
2. Select Create application.
3. Give your application a Name and choose or create a Namespace that matches where your existing application is deployed.
4. Select the Git Repository type.
5. Choose or enter your URL for the repository (forked repository URL for this exercise).
6. Choose the appropriate Branch and enter the path placement/nginx.
7. Check the Merge updates box, and flip the YAML: On switch at the top of the page.
8. On the right pane, in the Application YAML editor, modify the line: apps.open-cluster-management.io/reconcile-option: merge and change merge to replace.
9. Select clusters to deploy to by providing a Label and Value that match the managed cluster where you previously deployed the application. Example: Label name Value my-cluster-name
10. Click Save and you will be taken to the Topology.

The Topology shows the way Red Hat Advanced Cluster Management sees your manifest defined in Git. The nodes will show the states of each resource as they are adopted by the remote cluster. If you watch the resources, you will see that annotations are added to all the resources defined on the managed cluster, which is how Red Hat Advanced Cluster Management identifies the application resources under management.

Once all the nodes move to a successful states (green check mark), the application is under Red Hat Advanced Cluster Management control. Any new changes to the manifest in Git will result in the application being modified accordingly by the Advanced Cluster Management subscription.

You can validate this by modifying the image version found in the deployment.yaml from 1.14.1 to 1.16.1. This will trigger the nginx app to be upgraded, and the console will display the new version.

This opens exciting possibilities when using Red Hat Advanced Cluster Management. Bringing existing Kubernetes applications onboard from your imported clusters allows you to create a central management strategy and provides a single pane of glass to view all your applications. This adoption capability allows integration of Red Hat Advanced Cluster Management into your existing Kubernetes infrastructure, allowing the evolution to a GitOps style of application management.

If your interested in more GitOps demonstrations, take a look at the other folders in the Demo GitOps and visit our community here.

View the full article