This quickstart shows you how to get started with Anthos Config Management on a new cluster, using the foo-corp example repo to bootstrap a cluster with a set of configs. In this quickstart, you do not need write access to the repo. Imagine that a compliance team in your organization is responsible for creating the configs, and that each cluster is required to sync to the repo.
After you complete this quickstart, you can follow an advanced quickstart about writing, testing, and syncing configs.
Before you begin
-
Sign in to your Google Account.
If you don't already have one, sign up for a new account.
-
In the Google Cloud Console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Cloud project. Learn how to confirm that billing is enabled for your project.
- Enable the Anthos API.
- Install and initialize the Cloud SDK.
Requirements
Anthos Config Management requires an active Anthos entitlement. For more information, see Pricing for Anthos.
Cluster setup
GKE users
Set up the
kubectl
command to authenticate to the cluster and create a RoleBinding to make yourself a cluster administrator, using the following commands. Use your cluster name where you see[MY-CLUSTER]
, and use your Cloud Billing account's email address where you see [USER-ACCOUNT]. Depending on how you configured thegcloud
command on your local system, you may need to add the--project
and--zone
fields.gcloud container clusters get-credentials [MY-CLUSTER] kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin --user [USER_ACCOUNT]
Anthos clusters on VMware users
Anthos Config Management installation
Install the
nomos
command onto your local system.If you are installing manually, install the Config Management Operator onto the cluster you just created.
Register your cluster to an Anthos environ using Connect.
Configure your cluster
You can configure your cluster using kubectl
or the Google Cloud Console.
kubectl
Create a file config-management.yaml
and copy the below YAML file into it.
Because the repo is world-readable, secretType
is set to none
. For an
explanation of the fields, see
Configuration for the Git repository.
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
name: config-management
spec:
# clusterName is required and must be unique among all managed clusters
clusterName: my-cluster
git:
syncRepo: https://github.com/GoogleCloudPlatform/csp-config-management/
syncBranch: 1.0.0
secretType: none
policyDir: "foo-corp"
Apply the configuration to your cluster:
kubectl apply -f config-management.yaml
If the command succeeds, Kubernetes updates the Config Management Operator on your
cluster to begin syncing your cluster's configuration from the repository.
To verify that the Config Management Operator is running, list all Pods running in the
config-management-system
namespace:
kubectl get pods -n config-management-system
Output:
NAME READY STATUS RESTARTS AGE
git-importer-5f8bdb59bd-7nn5m 2/2 Running 0 2m
monitor-58c48fbc66-ggrmd 1/1 Running 0 2m
syncer-7bbfd7686b-dxb45 1/1 Running 0 2m
Console
To configure the Operator on the Google Cloud Console, complete the following steps:
Visit the Anthos Config Management menu in Google Cloud Console.
Select your registered cluster and click Configure.
In the Git Repository Authentication for ACM section, complete the following:
- For the Secret type, select None, as the repo in this example is world-readable.
- Click Continue.
In the ACM Settings for your clusters section, complete the following:
- In the URL field, add
https://github.com/GoogleCloudPlatform/csp-config-management/
- In the Branch field, add
1.0.0
- Click Show advanced options.
- In the Policy directory field, add
foo-corp
- In the URL field, add
Click Done. You are taken back to the Anthos Config Management menu. After a few minutes, refresh the page. You should see
Synced
in the status column next to the cluster you configured.
Examine your cluster and repo
The foo-corp
repo includes configs in the cluster/
and namespaces/
directories. These configs are applied as soon as the Config Management Operator is
configured to read from the repo.
All objects managed by Anthos Config Management have the
app.kubernetes.io/managed-by
label set to configmanagement.gke.io
.
List namespaces managed by Anthos Config Management:
kubectl get ns -l app.kubernetes.io/managed-by=configmanagement.gke.io
Output:
NAME STATUS AGE
audit Active 4m
shipping-dev Active 4m
shipping-prod Active 4m
shipping-staging Active 4m
Examine the configs that caused these namespaces to be created, such
as namespaces/audit/namespace.yaml
and
namespaces/online/shipping-app-backend/shipping-dev/namespace.yaml
.
List ClusterRoles managed by Anthos Config Management:
kubectl get clusterroles -l app.kubernetes.io/managed-by=configmanagement.gke.io
Output:
NAME AGE
namespace-reader 6m52s
pod-creator 6m52s
Examine the ClusterRole configs declaring:
cluster/namespace-reader-clusterrole.yaml
cluster/pod-creator-clusterrole.yaml
You can examine other objects, such as Roles and PodSecurityPolicies, in the same way.
Attempt to manually modify a managed object
If you manually modify a Kubernetes object that is managed by
Anthos Config Management, that object's configuration is automatically updated
to match the object's config in your repo. To test this, delete the
shipping-dev
namespace.
kubectl delete namespace shipping-dev
If you check immediately, the namespace may be missing, but within a few seconds, it exists again. For example:
kubectl get ns shipping-dev
Output:
Error from server (NotFound): namespaces "shipping-dev" not found
Seconds later:
kubectl get ns shipping-dev
Output:
NAME STATUS AGE
shipping-dev Active 3s
Cleaning up
After you finish the exercises in this topic, you can clean up by deleting the cluster you used for testing.
What's next
- Work through the advanced quickstart about writing, testing, and syncing configs.
- Learn more about writing configs.
- Learn about validating configs.