# 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](_glossary.md). 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](co-api.md#cfk-api). 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](co-manage-topics.md#co-manage-topics)) or a rolebinding (see [Configure RBAC for Confluent Platform Using Confluent for Kubernetes](co-rbac.md#co-rbac)), 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](co-concepts-cfk.md#co-concepts-cfk). - For testing, follow the [Get Started with Confluent for Kubernetes](co-quickstart.md#co-quickstart) to deploy Confluent Platform right away.