Deploy GitOps configurations and perform basic GitOps flow on GKE as an Azure Arc Connected Cluster

The following Jumpstart scenario will guide you on how to create GitOps configuration on a Google Kubernetes Engine (GKE) cluster which is projected as an Azure Arc connected cluster resource.

in this scenario, you will deploy & attach GitOps configuration to your cluster which will also include deploying an “Hello World” Azure Arc web application on your Kubernetes cluster. By doing so, you will be able to make real-time changes to the application and show how the GitOps flow takes effect.

NOTE: This guide assumes you already deployed a GKE cluster and connected it to Azure Arc. If you haven’t, this repository offers you a way to do so in an automated fashion using Terraform.


  • Clone the Azure Arc Jumpstart repository

    git clone
  • Fork the “Hello Arc” demo application repository.

  • (Optional) Install the “Tab Auto Refresh” extension for your browser. This will help you to show the real-time changes on the application in an automated way.

  • As mentioned, this scenario starts at the point where you already have a connected GKE cluster to Azure Arc.

    Existing Azure Arc-enabled Kubernetes cluster

    Existing Azure Arc-enabled Kubernetes cluster

  • Install or update Azure CLI to version 2.25.0 and above. Use the below command to check your current installed version.

    az --version
  • Create Azure service principal (SP)

    To be able to complete the scenario and its related automation, Azure service principal assigned with the “Contributor” role is required. To create it, login to your Azure account run the below command (this can also be done in Azure Cloud Shell).

    az login
    subscriptionId=$(az account show --query id --output tsv)
    az ad sp create-for-rbac -n "<Unique SP Name>" --role "Contributor" --scopes /subscriptions/$subscriptionId

    For example:

    az login
    subscriptionId=$(az account show --query id --output tsv)
    az ad sp create-for-rbac -n "JumpstartArcK8s" --role "Contributor" --scopes /subscriptions/$subscriptionId

    Output should look like this:

    "displayName": "JumpstartArcK8s",

    NOTE: If you create multiple subsequent role assignments on the same service principal, your client secret (password) will be destroyed and recreated each time. Therefore, make sure you grab the correct password.

    NOTE: The Jumpstart scenarios are designed with as much ease of use in-mind and adhering to security-related best practices whenever possible. It is optional but highly recommended to scope the service principal to a specific Azure subscription and resource group as well considering using a less privileged service principal account

Azure Arc Kubernetes GitOps Configuration

  • In order to keep your local environment clean and untouched, we will use Google Cloud Shell to run the az_k8sconfig_gke shell script against the GKE connected cluster.

  • Edit the environment variables in the az_k8sconfig_gke shell script to match your parameters, upload it to the Cloud Shell environment and run it using the . ./ command.

    NOTE: The extra dot is due to the script having an export function and needs to have the vars exported in the same shell session as the rest of the commands.

    Open Google Cloud Shell session and authenticate against the GKE cluster

    Open Google Cloud Shell session and authenticate against the GKE cluster

    Upload a file to Cloud Shell

    Upload a file to Cloud Shell

    Upload a file to Cloud Shell

    The script will:

    • Login to your Azure subscription using the SPN credentials

    • Retrieve the cluster credentials (KUBECONFIG)

    • Will use Helm to deploy NGINX ingress controller

    • Create the GitOps configurations and deploy the Flux operator and Memcached on the Azure Arc connected cluster

    • Deploy the “Hello Arc” application along side an Ingress rule to make it available from outside the cluster

      Disclaimer: For the purpose of this guide, notice how the “git-poll-interval 3s” is set. The 3 seconds interval is useful for demo purposes since it will make the git-poll interval to rapidly track changes on the repository but it is recommended to have longer interval in your production environment (default value is 5min)

  • Once the script will complete it’s run, you will have the GitOps configuration created all the resources deployed in your Kubernetes cluster. Note that it takes few min for the configuration change it’s Operator state status from “Pending” to Install.

    New GitOps configuration

    New GitOps configuration

The “Hello Arc” Application & Components

  • Before kicking the GitOps flow, let’s verify and zoom-in to the Kubernetes resources deployed by running few kubectl commands.

    kubectl get pods -n cluster-config - Will show the Flux operator and the Memcached pods.

    kubectl get pods -n hello-arc - Will show 3 replicas of the “Hello Arc” application and the NGINX controller.

    kubectl get svc -n hello-arc - Will show NGINX controller Kubernetes Service (Type LoadBalancer).

    kubectl get ing -n hello-arc - Will show NGINX rule which will route the traffic to the “Hello Arc” application from outside the cluster.

    kubectl get pods -n cluster-config

    kubectl get pods -n hello-arc

    kubectl get svc -n hello-arc

    kubectl get ing -n hello-arc

  • The GitOps flow works as follow:

    1. The Flux operator holds the “desired state” of the “Hello Arc” application, this are the configuration we deployed against the Azure Arc connected cluster. The operator “polls” the state of the of the “Hello Arc” application repository.

    2. Changing the application which is consider to be a new version of it, will trigger the Flux operator to kick-in the GitOps flow.

    3. A new Kubernetes pod with the new version of the application will be deployed on the cluster. Once the new pods is successfully deployed, the old one will be terminated (rolling upgrade).

  • To show the above flow, open 2 (ideally 3) side-by-side browser windows:

    • Google Cloud Shell open running the kubectl get pods -n hello-arc -w

      kubectl get pods -n hello-arc -w

    • Your clone of the “Hello Arc” application repository. Open the hello_arc.yaml file.

    • The external IP address of the Kubernetes Service seen using the kubectl get svc -n hello-arc command.

      kubectl get svc -n hello-arc

    • End result should look like that:

      Side-by-side view of terminal, “Hello Arc” GitHub repo and the application open in a web browser

  • As mentioned in the prerequisites section, it is optional but very recommended to configure the “Tab Auto Refresh” extension for your browser. If you did, in the “Hello Arc” application window, configure it to refresh every 2 seconds.

    Tab Auto Refresh

  • In the repository window showing the hello_arc.yaml file, change the text under “MESSAGE” section commit the change. Alternatively, you can open the clone repository in your IDE, make the change, commit and push it.

    Making a change to the replica count and the “MESSAGE” section

    Making a change to the replica count and the “MESSAGE” section

  • Upon committing the changes, notice how the Kubernetes Pod rolling upgrade starts. Once the Pod is up & running, the new “Hello Arc” application version window will show the new message, showing the rolling upgrade is completed and the GitOps flow is successful.

    New side-by-side view of terminal, “Hello Arc” GitHub repo and the application open in a web browser