This page provides brief definitions of terms that are commonly used in Anthos Config Management. The glossary is written with the assumption that you are already familiar with basic Kubernetes terms.
- Blueprint: A blueprint is a package of deployable, reusable configuration and policies that implement and document a specific solution. Blueprints enable you to design infrastructure, platforms, and application services by composing and connecting cloud resources with a declarative configuration. To learn more, see the Blueprints overview.
ClusterSelector: A ClusterSelector is a special type of config that uses Kubernetes labelSelectors. You can use a ClusterSelector to limit which clusters a particular config applies to, based on the cluster's labels. You can also use ClusterSelectors to limit which clusters instantiate a namespace-scoped object. To learn more see, Using ClusterSelectors.
Config: A config is a Kubernetes configuration declaration written in YAML or JSON. Config Sync reads and applies the config to one or more clusters to create or configure a Kubernetes object or resource in those clusters, or to provide information needed by Config Sync itself. A config can contain any configuration detail you could apply to a Kubernetes cluster using
kubectl apply. Configs must be stored in a repository. To learn more, see Using configs in Git repositories.
Config Controller: Config Controller is a hosted service to provision and orchestrate Anthos and Google Cloud resources. It offers an API endpoint that can provision, actuate, and orchestrate Google Cloud resources. To learn more, see Config Controller overview.
Config Sync: Config Sync lets cluster operators and platform administrators deploy consistent configurations and policies. You can deploy these configurations and policies to individual Kubernetes clusters, multiple clusters that can span hybrid and multi-cloud environments, and multiple namespaces within clusters. To learn more, see Config Sync overview.
Constraint: A constraint is a set of rules and parameters that govern interaction with a Kubernetes cluster. By defining one or more constraints, Policy Controller lets you enforce policy for a Kubernetes cluster. After a constraint is installed, requests to the API server are checked against the constraint and are rejected if they do not comply. To learn more, see Creating constraints.
Constraint template: A constraint template defines the schema and logic of the constraint. Constraint templates can be sourced from Google and third parties, or you can write your own. For more information about creating templates, see Writing a constraint template.
Constraint template library: The constraint template library is a collection of pre-built policies included with Anthos Policy Controller for common security and compliance controls. To learn more, see Constraint template library.
- Fleet: Fleets (formerly known as environs) are a Google Cloud concept for logically organizing clusters and other resources, letting you use and manage multi-cluster capabilities and apply consistent policies across your systems. Fleets form a crucial part of how enterprise multi-cluster functionality works in Google Cloud. To learn more, see Introducing fleets.
- Hierarchical repo: A hierarchical repo, also known as a structured repo, is a repository that separates configs into distinct categories. There are categories for system configuration, cluster metadata, cluster-level configuration, and namespace configuration. You can also use the unstructured repo format (which is the recommended format for most users). For more information, see Hierarchical repo overview.
- Landing zones: Google Cloud landing zones provide you with a set of configuration templates (blueprints) representing common enterprise best practices. By adopting these landing zone blueprints, you can configure an enterprise cloud "landing zone" where you can safely deploy your workloads. For more information, see Deploy a Landing Zone blueprint.
Namespace repo: Namespace repositories are unstructured repos that can be set up so that non-administrative users can control them. These repositories contain namespace-scoped configs synced to a particular namespace across clusters. For more information, see Configuring syncing from namespace repositories.
NamespaceSelector: NamespaceSelectors are used to limit which namespace-scoped objects can inherit a config. The behavior is slightly different for hierarchical and unstructured repos. For more information, see Limiting which namespaces a config affects.
nomosis a command-line tool for checking the syntax of configs before you commit them to your repo, and for debugging problems in Config Sync, your cluster, or your repo. To learn more, see Using the nomos command.
- Policy Controller: Policy Controller enables the enforcement of fully programmable policies for your clusters. These policies act as "guardrails" and prevent any changes to the configuration of the Kubernetes API from violating security, operational, or compliance controls. To learn more, see Policy Controller overview.
- Structured repo: See Hierarchical repo.
Reconciler: A reconciler is a Pod that is deployed as a Deployment. It syncs manifests from a Git repository to a cluster.
Referential constraints: A referential constraint is a type of constraint that references another object in its definition. For example, "do not allow two services to have the same hostname". To learn more, see Writing referential constraint templates.
Registered cluster: A cluster registered to a fleet. To learn more, see Registering a cluster.
RepoSync: A RepoSync object syncs your namespace repository to the cluster. To learn more, see RootSync and RepoSync fields.
ResourceGroup: A ResourceGroup is a resource that aggregates the reconciliation status of all resources for each Git repository synced to the cluster. Config Sync automatically generates the ResourceGroup custom resource (CR). To learn more, see ResourceGroup fields.
root-reconciler: When you create a RootSync object, Config Sync creates a reconciler called root-reconciler.
Root repo: This repository lets you sync cluster-scoped and namespace-scoped configs. The root repository uses admin-level credentials to enforce policies on application namespaces and override local changes that drift from the state that you declared in your configs. Each cluster can only have one root repository, and a central administrator typically governs this repository.
RootSync: A RootSync object syncs your root repository to the cluster. When you configure syncing from your root repository, using the Google Cloud Console or the
gcloudcommand-line tool, Config Sync automatically creates a RootSync object. If you use
kubectl, you need to create a RootSync object.
- Unstructured repo: The unstructured source repository format lets you organize the configs in your repository in whatever way is most convenient. This format can be especially useful if you are organizing or generating configs using a tool such as Kustomize, Kpt, or Helm. Unstructured is the recommended format for most users. The alternative repository format is a hierarchical repo. For more information, see Using an unstructured repo.