Part 2: Sync from Git

What Will You Do

In this section, you will create a new GKE cluster using the UI and see that the System Sync pipeline automatically converts the cluster resource to infrastructure as code and pushes the cluster manifest to the Git repository. We will then increase the minimum node count on the cluster by updating the cluster manifest from Git and see that the cluster node count increases on the cluster.

---

Step 1: Provision Cluster

In this step, we will provision a new cluster from the UI.

• In your project, navigate to Infrastructure -> Clusters
• Click "New Cluster"
• Select "Create a New Cluster"
• Click "Continue"

• Select "Public Cloud"
• Select "GCP"
• Select "GCP GKE"
• Enter a cluster name
• Click "Continue"

• Select the previously created "Cloud Credentials"
• Enter the GCP Project ID
• Select the GCP Zone for the cluster
• Select the K8S Version for the cluster
• Select the "default-gke" blueprint
• Click "Save Changes"

• Click "Provision"

Provisioning will take approximately 25 minutes to complete. The final step in the process is the blueprint sync for the default blueprint. This can take a few minutes to complete because this requires the download of several container images and deployment of monitoring and log aggregation components.

---

Step 2: Validate GitOps

In this step, we will check that the GitOps pipeline created a cluster specification file and pushed it to the Git repository.

• In your project, navigate to GitOps -> Pipelines
• Click on the name of the previously created pipeline

You will see that a second job in the pipeline was initiated. This job was triggered by the system when the new cluster was created. This new job was the system writing the cluster specification file to the Git repo.

Now, we will check that the Git repo has the cluster spec file.

• Navigate to your GitHub repository
• In the repo, navigate to projects -> defaultproject/clusters

Note

The Git path will be different if you used a different project name.

You will see the cluster specification files for all clusters in the project.

---

Step 3: Update Cluster From Git

In this step, we will update the minimum node count in the cluster spec file on the Git repository and then witness the cluster being updated automatically in the system.

• Navigate to your Git repo -> "projects/Project Name/clusters/Cluster Name.yaml"
• Edit the file and update the text for "Size" from "Size: 3 to "Size: 2"
• Commit the changes to your Git repository

apiVersion: infra.k8smgmt.io/v3
kind: Cluster
metadata:
  name: gke-cluster-gs
  project: defaultproject
spec:
  blueprint:
    name: default-gke
    version: latest
  cloudCredentials: gke-provisioning-role
  config:
    controlPlaneVersion: "1.25"
    features:
      enableComputeEnginePersistentDiskCSIDriver: true
    gcpProject: demos-249423
    location:
      config:
        zone: us-west1-c
      type: zonal
    network:
      access:
        config:
          controlPlaneIPRange: 172.31.128.0/28
          disableSNAT: true
          enableAccessControlPlaneExternalIP: true
          enableAccessControlPlaneGlobal: true
        type: private
      enableVPCNativetraffic: true
      maxPodsPerNode: 110
      name: default
      subnetName: default
    nodePools:
    - machineConfig:
        bootDiskSize: 100
        bootDiskType: pd-standard
        imageType: COS_CONTAINERD
        machineType: e2-standard-4
      name: default-nodepool
      nodeVersion: "1.25"
      size: 2
  proxy: {}
  sharing: {}
  type: gke

The commit will trigger the GitOps pipeline and it will automatically update the cluster node pool.

• In your project, navigate to GitOps -> Pipelines
• Click on the name of the previously created pipeline

You will see that a third job in the pipeline was initiated. This job was triggered by the system when the new cluster was created. This new job was the system writing the cluster specification file to the Git repo.

After a few minutes, we can see that the number of nodes in the cluster was decreased to two.

---

Recap

In this part, you tested bidirectional syncronization between your Git repository and the system when creating and updating a GKE cluster.

---