本快速入门使用 foo-corp 示例代码库向您展示如何在新集群上开始使用 Anthos Config Management。在开始编写自己的配置之前，学习快速入门将有助于您了解 Anthos Config Management 的工作原理。

准备工作

GKE On-Prem 用户：创建用户集群。然后，设置 kubectl 命令以向集群验证身份，然后使用以下命令创建 RoleBinding，将您自己设置为集群管理员。在显示 [MY-CLUSTER] 的位置使用您的集群名称，并在显示 [USER-ACCOUNT] 的位置使用您的 Google Cloud Platform 电子邮件地址。根据您配置本地系统的方式，您可能需要添加 --project 和 --zone 字段。

 gcloud container clusters get-credentials [MY-CLUSTER]

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin --user [USER_ACCOUNT]

Google Kubernetes Engine 用户：创建集群
安装 Config Management Operator
安装 nomos 命令
如果您没有 GitHub 帐号，请创建一个
安装 jq 命令，该命令将在本指南的部分内容中使用

配置集群

创建代码库

本快速入门通过创建 foo-corp 代码库的分支来创建您的代码库，然后创建其本地克隆作为您的工作副本。

1、在浏览器中，转到 foo-corp 代码库，然后点击 Fork 按钮。

2、您的分支会在浏览器中打开。复制其网址，同时省略所有参数（? 字符后面的任何内容以及 ? 字符本身）。

3、在本地系统上，克隆您的分支。将 [GIT-FORK-URL] 替换为分支的网址。

 git clone [GIT-FORK-URL]

创建 nomos vet 预提交钩子

您可以安装预提交钩子，以便 nomos vet 命令在您将更改提交到本地代码库之前，检查您的更改是否存在语法错误或其他修改问题。

注意：预提交钩子不会提交到代码库，并且必须在克隆代码库的每个系统上配置。您可以将这些文件提交到代码库中的其他位置，并要求用户将其复制到本地系统上的正确位置。

1、在终端中，转到您克隆了代码库的目录。

2、修改 .git/hooks/pre-commit 文件。请注意 .git/ 目录中的 . 字符。

3、将以下内容添加到该文件中，将 [/path/to/] 替换为安装了 nomos 命令的完全限定路径。

nomos vet --path=/path/to/repo

保存该文件。

4、确保 .git/hooks/pre-commit 文件是可执行文件：

chmod +x .git/hooks/pre-commit

创建 git-creds Secret

按照安装 Anthos Config Management 中的说明创建 git-creds Secret，Config Management Operator 可使用该对象读取代码库的内容。将该部署密钥添加到 GitHub 时，请勿授予写入权限。

注意：创建 Secret 后删除私钥或妥善保护。

配置 Config Management Operator

将此 YAML 清单复制到名为 config-management.yaml 的文件中。将 spec.clusterName 的值更改为您的集群的名称。将 spec.syncRepo 的值更改为 GitHub 中代码库的网址，同时省略该部分。请勿更改字符串的 git@github.com 部分。

apiVersion: addons.sigs.k8s.io/v1alpha1
 kind: ConfigManagement
 metadata:
   name: config-management
 spec:
   # The name of your cluster. If omitted, this cluster cannot be selected by
   # a ClusterSelector.
   clusterName: my-gke-cluster
   git:
     syncRepo: git@github.com:my-git-username/foo-corp-example.git
     syncBranch: 0.1.0
     secretType: ssh

policyDir: “foo-corp”

使用 kubectl apply 将配置应用于您的集群：

kubectl apply -f config-management.yaml

如果命令成功，则 Config Management Operator 会部署到集群中，而且会读取代码库的内容，并将集群的配置与代码库中的现有配置同步。如需验证 Config Management Operator 是否正在运行，列出 config-management-system Namespace 中运行的所有 Pod：

Pod 名称中的字母数字后缀是唯一的，因此您的输出与上面的示例类似但不完全相同。

检查您的集群和代码库

foo-corp 代码库包含 cluster/ 和 namespaces/ 目录中的配置。Config Management Operator 配置为从代码库中读取内容后，系统会立即应用这些配置。

由 Anthos Config Management 管理的所有对象都将注释 configmanagement.gke.io/managed 设置为 enabled。

本部分的命令使用 jq 命令根据注释过滤资源，因为 kubectl 命令不支持按注释过滤。

列出由 Anthos Config Management 管理的 Namespace：

kubectl get namespaces -o json | jq -cr '.items[] | select( .metadata.annotations."configmanagement.gke.io/managed" == "enabled" ) | .metadata.name'

audit
shipping-dev
shipping-prod
shipping-staging

检查引发系统创建这些 Namespace 的配置，例如 namespaces/audit/namespace.yaml 和 namespaces/online/shipping-app-backend/shipping-dev/namespace.yaml。

列出由 Anthos Config Management 管理的 ClusterRole：

kubectl get clusterroles -o json | jq -cr '.items[] | select( .metadata.annotations."configmanagement.gke.io/managed" == "enabled" ) | .metadata.name'

namespace-reader
pod-creator

检查代码库中的 cluster/namespace-reader-clusterrole.yaml 和 cluster/pod-creator-clusterrole.yaml 文件，这些文件引发系统创建这些 ClusterRole。

列出由 Anthos Config Management 管理的角色：

kubectl get rolebinding -n backend -o json | jq -cr '.items[] | select(.metadata.annotations."configmanagement.gke.io/managed" == "enabled" ) | [.metadata.name,.metadata.namespace] | @tsv'

shipping-dev   job-creator

检查 namespaces/online/shipping-app-backend/shipping-dev/job-creator-role.yaml 配置，该配置引发此角色的创建。

列出由 Anthos Config Management 管理的 PodSecurityPolicies：

kubectl get psp -o json | jq -cr '.items[] | select( .metadata.annotations."configmanagement.gke.io/managed" == "enabled" ) | .metadata.name'

psp

检查 cluster/pod-security-policy.yaml 配置，该配置引发系统创建此 PodSecurityPolicy。

尝试手动修改托管对象

如果手动修改由 Anthos Config Management 管理的 Kubernetes 对象，系统会自动更新该对象的配置以与代码库中对象的配置匹配。要对此进行测试，请删除 shipping-dev Namespace。

kubectl delete namespace shipping-dev

注意：如果 shipping-dev Namespace 包含任何并非由 Anthos Config Management 管理的对象，那么这些 Namespace 也会被删除。本示例假设所有对象都由 Anthos Config Management 管理，但删除 Namespace 是针对活跃集群的破坏性操作。

如果您立即检查，Namespace 可能会缺失，但在几秒钟内，它会重新出现：

kubectl get namespaces -o json | jq -r '.items[] | select( .metadata.annotations."configmanagement.gke.io/managed" == "enabled" ) | .metadata.name'

audit
shipping-prod
shipping-staging

# Wait a few seconds

kubectl get namespaces -o json | jq -r '.items[] | select( .metadata.annotations."configmanagement.gke.io/managed" == "enabled" ) | .metadata.name'

audit
shipping-dev
shipping-prod

shipping-staging

同样，如果您手动更新由 Anthos Config Management 管理的 Kubernetes 对象，您的更改会快速更新以与代码库中的配置匹配。要对此进行测试，请更新 namespace-reader ClusterRole 以移除 watch 动词。

检查 ClusterRole：

kubectl get ClusterRole namespace-reader -oyaml

注意 verbs 的值。

在一个终端中，监控 namespace-reader 对象是否发生变化。此命令会一直运行，监控与该对象相关的事件，直到您将其终止：

kubectl get clusterrole namespace-reader -o yaml --watch

在另一个终端中，使用 kubectl edit 命令修改 ClusterRole。kubectl edit 会在默认编辑器（通常是 vi）中打开，并在保存文件时应用您的更改。

kubectl edit clusterrole namespace-reader

注意：此示例使用 kubectl edit（而不是 kubectl apply）处理 YAML 清单。如果使用 kubectl apply，则必须修改 YAML 清单以手动添加 configmanagement.gke.io/managed: enabled 注释并将其设置为 enabled。否则，Anthos Config Management 将停止管理此对象。

删除包含 -watch 内容的一整行并保存文件。返回正在监控 ClusterRole 的终端。请注意，watch 动词已移除，但这个更改将在几秒钟内还原。

按 Control+C 停止监控此对象。

此练习显示，即使有人进行手动更改，Anthos Config Management 也会使对象与您代码库中的配置保持同步。

更新代码库中的配置

当您通过将 Git 提交推送到代码库来更新代码库中的配置时，Anthos Config Management 会检测到相应的更改并将新配置应用于相关的 Kubernetes 对象。

在此示例中，您将用户 jane@foo-corp.com 添加到 namespace-readers ClusterRoleBinding。

打开终端，发出以下命令以监控 namespace-readers ClusterRoleBinding 是否发生变化：

kubectl get clusterrolebindings namespace-readers -o yaml --watch

打开另一个终端，转到您代码库的本地克隆。修改 cluster/namespace-reader-clusterrolebinding.yaml 文件，以将 jane@foo-corp.com 添加到 subjects 字段。修改完之后，该文件将包含以下内容：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
   name: namespace-readers
subjects:
-kind: User 
 name: cheryl@foo-corp.com 
 apiGroup: rbac.authorization.k8s.io
-kind: User 
 name: jane@foo-corp.com 
 apiGroup: rbac.authorization.k8s.io 
roleRef: 
 kind: ClusterRole 
 name: namespace-reader 
 apiGroup: rbac.authorization.k8s.io

保存该文件。创建一个提交命令，并将更改推送到您的代码库。

git add cluster/namespace-reader-clusterrolebinding.yaml
git commit -m "Add Jane to namespace-reader"
git push origin master

返回正在监控 namespace-reader 对象的终端。几秒钟后，更改即会生效。

还原更改也很容易。返回用于 Git 的终端。使用 git log 命令查找哈希值（在此示例中是最上面的条目），并将其还原。在以下命令中，在显示 [HASH] 的位置使用提交命令的哈希值。

git revert [HASH]
git push origin master

返回您正在监控 namespace-reader 对象的终端，您会发现 jane@foo-corp.com 不再列在 ClusterRole 的主题中。

按 Control+C 可停止监控 namespace-reader 对象。

此练习显示，当您向代码库提交更改时，Anthos Config Management 会使对象与代码库中的配置保持同步。

清理

完成本主题中的练习后，请执行以下操作以进行清理：

删除 foo-corp 代码库的分支。您添加到分支的部署密钥也会被删除。
删除分支的本地克隆。
删除用于测试的集群。

原文链接

创作场景

Anthos Config Management 快速入门