Kubernetes Configuration and Infrastructure as Code Taxonomy

Sitemap## ITNEXT

Image generated by Gemini

I’ve used quite a few terms in my posts about Kubernetes Configuration and Infrastructure as Code (IaC), and we introduced some additional jargon when we announced ConfigHub recently. I also use some uncommon terms and some common terms in unexpected ways. For example, some people interpreted “configuration” as referring to just application configuration (definition below). And someone recently mentioned they learned a new term from one of my posts. It was suggested to me that providing a glossary of the terminology would be helpful.

Tool Categories

I mentioned many tools in my posts on Kubernetes Configuration and the Infrastructure as Code landscape, and also wrote a number of follow-up posts about specific categories. What are they?

• Declarative Configuration: I discussed Declarative Configuration in my first post in my blog series on IaC. Declarative configuration expresses the desired or goal state of a system, as opposed to the steps and/or actions required to achieve it. This is a fairly broad category of tools that encompasses or overlaps with many of the others.
• Infrastructure as Code: Infrastructure as Code (IaC) generally has two main aspects that are usually conflated:
  1. Infrastructure configuration should be represented as code or a code-like format.
  2. Configuration should be managed using the same tools and practices as code, namely text files in source control.
  Popular IaC tools generate declarative configuration, which is then applied to systems under management in an orchestrated fashion.
  Note that under this definition, Kubernetes configuration tools such as Helm count as IaC, which is fitting because Kubernetes was designed to have an infrastructure-like API.
• Infrastructure as Data: The common meaning appears to be tools driven by serialized data formats. Ansible and Kubernetes, which both consume YAML, have been described this way. Their configurations are often generated from templates, which are implemented and managed as Infrastructure as Code.
• Infrastructure Provisioning: Tools that create infrastructure (and potentially other) resources (see below) in systems, such as cloud service providers, typically by calling APIs. The earliest mention of this term that I have seen was in Mitchell Hashimoto’s description of CloudFormation. He considered Terraform to be in this category as well. Initially CloudFormation apparently only supported resource creation, so the term provisioning, providing something for use, fit. It looks like CloudFormation added support for updates the following year, and IaC tools in this category now do generally support updates, which are significantly more challenging to implement than creation.
• KRM-based Provisioning: Using the Kubernetes Resource Model to provision resources in other systems by implementing a one-to-one correspondence between custom resources in Kubernetes and resources in the systems under management. These tools, such as Config Connector and Crossplane, are also Infrastructure as Data tools.
• Infrastructure from Code: Infrastructure from Code tools generate, or select, and/or invoke Infrastructure as Code templates / modules / packages based on elements in application source code. Some tools are directed by source-code annotations, others via code libraries, a couple use new languages, and, more recently, use AI.
• GitOps: GitOps is a design pattern for continuous reconciliation of desired state and live state using version control to manage declarative specification of the desired state and automation to make that desire a reality. See also the GitOps principles.
• Configuration Management: Configuration Management is a process for managing the operational state of systems over time. It’s frequently used to describe automated reconciliation processes, such as those performed by tools like Puppet and Chef, which are also Infrastructure as Code tools. I also consider GitOps tools to be Configuration Management tools. The overlap with Infrastructure Provisioning is blurry, perhaps most blurry with Ansible, which can provision infrastructure and does not run continuously, but is generally considered a Configuration Management tool because it perform similar management tasks as Chef and Puppet. One could also write a Terraform provider plugin to ssh into a machine and apply a declarative description of the filesystem and OS state similar to the Postgres provider, which connects to Postgres to configure it. Kubernetes Operators, such as SchemaHero, have similar capabilities.
• Application Configuration: Operator-oriented settings (as opposed to user settings or preferences) consumed by an application to control its behavior.
• Feature Flags: Application configuration that can be changed dynamically, or at least without redeploying, to enable/disable/control application features, often for a subset of servers, clients, or users.
• Secrets: Keys for accessing some systems and/or data.
• Policy as Code: Policies and/or rules serialized in a machine-readable form, often declarative, sometimes serialized as data.
• Asset Management: Cloud Asset Management tools inventory cloud resources, analogous to IT Asset Management systems for physical IT assets, and support resource discovery, auditing, queries, and analysis.

Patterns and Processes

• Variant: A distinct configuration derived from another configuration that varies in some ways from the original.
• Exclusive Actuation: Ensuring that all changes are made through a single mechanism and process, sometimes enforced through constrained permissions for individuals. This approach is often implemented or desired with IaC, especially template catalogs (see below).
• DRY: Don’t Repeat Yourself. The principle that one should minimize duplication of code, which in the case of IaC implies duplication of configuration elements, such as resources (see below) and their attributes. Generally this is achieved through parameterization and logic to generate configuration variants for every use case.
• WET: Write Every Time or Write Everything Twice. The opposite of DRY. Fully concrete, unparameterized configuration, with a distinct, explicit copy for every variant.
• Rendered Manifest Pattern: The approach of generating WET configuration from DRY configuration before applying it to the systems under management, particularly for Kubernetes configuration. The term “manifest” was borrowed (and semantically drifted) from the container agent that was released prior to Kubernetes.
• Hydration==: The process of generating WET configuration from DRY configuration, as a pun on DRY and WET. A synonym for “rendering” and “configuration generation”.==
• Claim Model: The use of claims to provision resources indirectly. The claim represents the resource request, including the minimum requirements, which is typically a partial expression of the desired state rather that the full desired state. That claim can be fulfilled by a resource (or resources) that satisfies the requirements. A claim is essentially a future. The pattern is used in Kubernetes.
• Cargo Culting: In the context of declarative configuration and IaC, copying configuration without fully understanding its contents.
• Promotion: I mentioned promotion and rollout (see below) in my post that discussed deployment using GitOps. A summary produced by AI (which I tried because I didn’t remember seeing a good definition anywhere) was actually pretty good: the process of moving a validated and tested release artifact from one environment (see below), or release/deployment stage, to another, archetypically, from development to staging or staging to production. This process is frequently gated by human approvals and, at least when deploying to production, a number of policies.
• Rollout: This AI-generated definition was also pretty good: the process of gradually updating an application or service (release artifacts and/or application configuration / feature flags), ensuring minimal downtime and allowing for controlled risk management during the transition to a new version. Rollout may imply more automation than promotion, and can utilize patterns such as blue/green, canary, and/or progressive deployment. A rollout is the deployment process used to implement a promotion, at least in production, which typically involve updating multiple instances of the application or service needed due to availability, scalability, regional isolation, etc.
• Mass Change: Changing many copies of similar configurations, often variants of the same original configuration.
• Configuration Authoring: The process of creating and editing a configuration artifact from scratch (i.e., not from a template or by cargo culting) prior to initial deployment, whether manually or using a LLM.

Elements

• Configuration Data: WET configuration serializable as structured data. It is typically represented in a serialized data format, such as JSON, YAML, or CSV, without code-like constructs such as variables, expressions, conditionals, loops, etc. It may be generated and used on the fly, stored in files in version control, an object store, or in a container registry, or stored in a SQL or NoSQL database. Applications and Infrastructure as Data tools consume configuration data directly.
• Resource: In APIs generally, and in Kubernetes and cloud services specifically, a resource is a specific object that can be accessed and manipulated through the API, often identified by a unique URI (Uniform Resource Identifier). Kubernetes configuration tools like Helm, KRM-based provisioning tools like Crossplane, and IaC tools like Terraform and Pulumi mainly create, update, and/or delete resources.
• Package: A reusable configuration artifact, frequently serving as a unit of discovery, storage, deployment, and abstraction. Abstractions generally consist of input parameters and, sometimes, output parameters. They often contain templates (see below). Examples of packages include Terraform modules and .
• Template: In the narrow sense, a configuration template is a text-based configuration format marked up with substitution syntax, similar to, and sometimes using the same tools as, web page templates, such as Jinja and Go templates within YAML. In the broad sense, I include configuration generators expressed in configuration DSLs and even in general-purpose languages, when written similarly to templates with configuration data intermingled with code to produce configuration variants, as templates also.
• Template Catalog: A directory, index, or registry of configuration templates (in the broad sense), usually published as packages, for copying and/or deploying the configuration artifacts on demand.
• Override: Individual or partial sets of configuration settings taking precedence over other configuration values specified for those settings elsewhere in a configuration, often to customize the configuration without modifying the original source.
• Overlay: A configuration override expressed in the same representation as the full configuration, but without repeating settings that are not being overridden. Kustomize supports overlays.
• State-based Policy Constraints: Policies expressed as constraints on the desired state.
• Environment: A deployment environment is a collection of resources (especially infrastructure, like networks and Kubernetes clusters) used to run applications and services at a specific stage of deployment. What often distinguishes production from pre-production environments like development and staging, is the posture towards operational concerns such as security, privacy, cost, scalability, availability, reliability, observability, and regional isolation. An ephemeral environment is provisioned on demand and destroyed when no longer in use.
• Control Plane: A control plane is an API-driven system, typically running continuously, that manages, manipulates, and provides access to resources.
• State: In the context of declarative configuration and IaC tools, state is persistent data stored by the tool in addition to the configuration input read and acted upon by the tool.
• Backing Service: A service consumed over the network by an application during its normal operation. The term comes from the 12-factor App.

Challenges

• Configuration Drift: The divergence of the actual system state from the desired state, such as that specified using IaC.
• Blast Radius: The scope of resources and applications potentially impacted by a single action performed using a tool.
• Configuration Sprawl: Sprawl refers to a collection of something that has spread out in a haphazard way. With configuration, sprawl refers to the number of files and the number of locations (e.g., repositories) and systems (e.g., version control systems, secret managers, object stores, artifact repositories) where those files are stored.
• Factory Model: The multi-step, unidirectional process by which configuration is changed, approved, rendered by IaC tools, and deployed, often through deployment pipelines.
• Artisanal Automation: Automation tools, such as Infrastructure as Code tools, that are configured manually and that require significant expertise and time to produce a quality outcome.
• Toil: Manual, repetitive work, such as making changes to IaC through git.

Whew, that was a lot of terms. If I missed some important terms or you disagree with my definitions, let me know! There are some important terms I haven’t used in my posts yet, so I’ll define those terms when I cover those topics.

GitLab also has a good glossary focused more on applications than infrastructure that is worth checking out.

Feel free to reply here, or send me a message on LinkedIn, X/Twitter, or Bluesky, where I plan to crosspost this.

If you found this interesting, you may be interested in other posts in my Infrastructure as Code and Declarative Configuration series.

CTO of ConfigHub. Original lead architect of Kubernetes and its declarative model. Former Tech Lead of Google Cloud's API standards, SDK, CLI, and IaC.

More from Brian Grant and ITNEXT

Recommended from Medium

[

See more recommendations

](https://medium.com/?source=post_page---read_next_recirc--62ab4dd7e82f---------------------------------------)