This quickstart shows you how to use Config Sync to implement a GitOps approachfor managing your Google Kubernetes Engine clusters. With a GitOpsworkflow, you use a Git repository as the single source of truth for yourcluster configurations.

By using Config Sync, you get the following benefits:

• Enforce consistency: helps to ensure that all your clusters have the sameconfiguration, reducing the risk of configuration drift.
• Improve security: centrally manage and audit your clusterconfigurations, making it easier to enforce security policies.
• Increase velocity: automate the rollout of configuration changes,letting you to deploy changes faster and more reliably.

In this tutorial, you create a GKE cluster and configure Config Sync tosync configuration files from a sample repository. This tutorial helps you understand howConfig Sync works and gives you experienceusing Config Sync to manage your clusters in a consistent and automated way.

Before you begin

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.create permission.Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.create permission.Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. Make sure that you have the following role or roles on the project: Kubernetes Engine Admin

   Check for the roles

   1. In the Google Cloud console, go to theIAM page.

      Go to IAM
   2. Select the project.

   3. In thePrincipal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

   4. For all rows that specify or include you, check theRole column to see whether the list of roles includes the required roles.

   Grant the roles

   1. In the Google Cloud console, go to theIAM page.

      Go to IAM
   2. Select the project.
   3. Clickperson_addGrant access.

   4. In theNew principals field, enter your user identifier. This is typically the email address for a Google Account.

   5. In theSelect a role list, select a role.
   6. To grant additional roles, clickaddAdd another role and add each additional role.
   7. ClickSave.

Create a cluster

In this section, you create a cluster that you can use in this tutorial.Although in a real-world scenario you would likely manage multipleclusters, to simplify this tutorial you only create and manage one cluster.

To create a cluster, complete the following steps:

1. Enable the Google Kubernetes Engine API.

   Go to GKE

2. In the Google Cloud console, go to theKubernetes Engine page.

   Go to Google Kubernetes Engine

3. Clickadd_boxCreate.

4. In theAutopilot section, selectConfigure.

5. In theCluster basics section, entercs-cluster in theNamefield. Leave all other fields with their recommended defaults.

6. ClickCreate. You are taken to theKubernetes clusters page. Ittakes several minutes for your cluster to be created. When you see a greencheck mark in theStatus column next to your cluster, it's ready.

Configure your cluster

Now that you have a cluster, you can configure Config Sync to syncconfiguration files from a Git repository.

To configure Config Sync in the Google Cloud console, complete the followingsteps:

1. In the Google Cloud console, go to theConfig page under theFeatures section.

   Go to Config

2. ClickaddInstall Config Sync.
3. Select the Config Sync version that you want to use.
4. UnderInstallation options, selectInstall Config Sync on individual clusters.
5. In theAvailable clusters table, selectcs-cluster and clickInstall Config Sync.In theSettings tab, you should see the status for thecs-clusterasEnabled after a few minutes.
6. On theConfig Sync dashboard, clickDeploy cluster package.
7. In theSelect clusters for package deployment table, selectcs-clusterand then clickContinue.
8. LeavePackage hosted on Git selected and then clickContinue.
9. In thePackage name field, entersample-repository.
10. In theRepository URL field, enterhttps://github.com/GoogleCloudPlatform/anthos-config-management-samples.
11. In thePath field, enterconfig-sync-quickstart/multirepo/root.
12. Leave all other fields with their default values.

13. ClickDeploy Package.

    After a few minutes, you should seeSynced in theSync statuscolumn forcs-cluster.

Now that Config Sync is synced to a repository, it continuously reconcilesthe state of your clusters with the configs in the repository.

View package details

To view the objects managed by Config Sync, go to thePackages tab andclickcs-cluster. The package details page provides an overview of all syncedresources, including the resource type and which namespace the resource issynced to.

(Optional) Explore the sample repository

The configurations applied to your cluster are defined in the/config-sync-quickstart/multirepo/repository. This sample demonstrates a multi-repository setup wherecluster-admin-level configurations, represented by theroot repository, areseparated from namespace-level configurations, represented by thenamespacesrepository. In this example, these configurations are split into differentfolders. In a real-world scenario, you could store configurations in two differentrepositories with different access permissions.

At a high level, cluster-level or root repositories are typically managed by acentral administrator and contain cluster-wide resources, namespaceconfigurations, and policies. Namespace-level repositories typically containconfigurations specific to individual namespaces and are often managed byapplication teams.

Some of the key types of files that you might store in a root repository includethe following:

• Namespace creation: files likenamespace-gamestore.yaml create thenamespaces themselves.
• Cluster-scoped resources: files that affect the entire cluster includeresources likeClusterRole objects which add cluster-wide roles that grantpermissions.
• Connecting namespace repositories: the key file in this multi-repositorysetup is thereposync-gamestore.yaml file. ThisRepoSync object tellsConfig Sync to sync configurations for thegamestore namespace from adifferent path. In this example, theRepoSync object points to theconfig-sync-quickstart/multirepo/ namespaces/gamestore directory withinthe same repository, but in a real-world scenario, you could point to adifferent Git repository.

The namespace repository contains application-specific configurations for thegamestore namespace. For example, theconfigmap-inventory.yaml file containsinventory data for thegamestore application. This type of GitOps setuplets application teams have more autonomy over their own deployments andnamespace-scoped resources without needing to modify the central rootrepository.

Clean up

1. Go to the GKE menu in Google Cloud console.

   Go to GKE

2. Next to thecs-cluster, clickmore_vertActions, then clickdeleteDelete.

3. When prompted to confirm, clickDelete again.

What's next

• Learn aboutvalidating configs.