- Okay, in this final demonstration, I'm going to update the cluster state manually by scaling up the front end deployment from one to four replicas. Now, by doing this, the cluster state will be out of sync with the state as hold and declared within the Cloud Academy GitOps Demo Repo. When flux detects this configuration drift, it should reappear by re-syncing the cluster state back to the state described in the Git Repo. Okay, lets begin. First, I'll run the command "kubectl get pods -n cloudacademy". 

To examine the currently running set of pods, in here you can see we have a single pod consisting of the engine x proxy container in the "flaskapp" container. Next, I'll run the command "kubectl scale deployment/frontend --replicas=4 -n cloudacademy". Which will scale up the front end deployment replicas from one to four. This will cause configuration drift to occur. 

After this, I'll rerun the previous kubectl get pods command but with added flag, "--watch". To watch any pod events that happen. Here, we should expect a number of pod termination events to take place. Since flux will trigger the cluster to re sync itself with the state currently held and described in the Git Repo. Remembering that this can take up to five minutes before the re syncing occurs. Excellent. You can see the termination events happening now. I'll rerun the same command but this time without the "--watch" flag. And, as expected, the number of running pods has returned to one. As per the declared state currently held in the Git Repo. 

Rerunning the same command again you can see that this view has now filtered down to the just one running pod. Next, I'll scan through the flux logs and search for the occurrences where the re syncing takes place. By running the command "kubectl -n flux logs deployment/flux | grep configured". Here you can see that flux is internally using the "kubectl apply -f" command. To reapply the declared cluster configuration, currently held within Git. And that in this case the config met was unchanged, and that the front end deployment was changed. This addressing the configuration drift that we manually applied. 

Finally, I'll jump back into my browser and examine the current front end deployment cluster config held in Git. As you can see, the deployment is currently set to have one replica and it is this particular city that has caused our manual scaling to be reset from four back to one. And all thanks to the flux operator kicking in and doing its job automatically. 

Okay that completes the end to end GitOps demonstration. You've seen not only how to install GitOps using flux, but also how to work with it in terms of making changes and observing how those changes are automatically applied and synchronized in the cluster.