Confluent for Kubernetes Terminology
The following are the key terms you encounter when working with Confluent for Kubernetes (CFK). For a broader set of Apache Kafka® and Confluent terms, see the Glossary.
- Confluent for Kubernetes (CFK)
A cloud-native control plane for deploying and managing Confluent Platform in private Kubernetes environments through a declarative API.
- Control plane
The CFK process that runs in your Kubernetes cluster. It watches your Confluent custom resources and acts to keep Confluent Platform in its desired state. Also referred to as the operator.
- Declarative API
An API model in which you declare the desired state of Confluent Platform in YAML. CFK determines how to achieve that state, rather than requiring imperative commands.
- Desired state
The configuration you declare in a custom resource (a Kubernetes object that configures a Confluent Platform component). CFK works to make the actual state of the cluster match this desired state.
- Reconciliation
The continuous process in which CFK compares the desired state with the actual state and resolves any differences, for example after a configuration change or a pod failure.
- Custom resource (CR)
A Kubernetes object you create to configure and manage a Confluent Platform component or an application resource (a Confluent object, such as a topic or rolebinding, that runs on top of a component). For example, a Kafka CR defines a Kafka cluster.
- Custom Resource Definition (CRD)
The schema that defines a custom resource type. CFK includes a CRD for each Confluent Platform component and application resource it manages. For the full schema, see Confluent for Kubernetes API Reference.
- Confluent component
A Confluent Platform service that CFK deploys and manages. Examples include:
Apache Kafka®
Connect
Schema Registry
ksqlDB
Confluent Control Center
Confluent REST Proxy
- Application resource
A Confluent object that runs on top of a Confluent Platform component, such as a topic (see Manage Kafka Topics for Confluent Platform Using Confluent for Kubernetes) or a rolebinding (see Configure RBAC for Confluent Platform Using Confluent for Kubernetes), that you also manage declaratively through CFK.
- Helm
The Kubernetes package manager used to install and upgrade CFK itself. After CFK is up and running, you manage Confluent Platform through custom resources.
Next steps
To see how these concepts fit together, see How Confluent for Kubernetes Works.
For testing, follow the Get Started with Confluent for Kubernetes to deploy Confluent Platform right away.