// Module included in the following assemblies:
//
// deploying/assembly_deploy-kafka-cluster.adoc

[id='deploying-kafka-cluster-{context}']
= Deploying the Kafka cluster

This procedure shows how to deploy a Kafka cluster to your Kubernetes using the Cluster Operator.

The deployment uses a YAML file to provide the specification to create a `Kafka` resource.

Strimzi provides example YAMLs files for deployment in `examples/kafka/`:

`kafka-persistent.yaml`:: Deploys a persistent cluster with three ZooKeeper and three Kafka nodes.
`kafka-jbod.yaml`:: Deploys a persistent cluster with three ZooKeeper and three Kafka nodes (each using multiple persistent volumes).
`kafka-persistent-single.yaml`:: Deploys a persistent cluster with a single ZooKeeper node and a single Kafka node.
`kafka-ephemeral.yaml`:: Deploys an ephemeral cluster with three ZooKeeper and three Kafka nodes.
`kafka-ephemeral-single.yaml`:: Deploys an ephemeral cluster with three ZooKeeper nodes and a single Kafka node.

In this procedure, we use the examples for an _ephemeral_ and _persistent_ Kafka cluster deployment:

Ephemeral cluster:: In general, an ephemeral (or temporary) Kafka cluster is suitable for development and testing purposes, not for production. This deployment uses `emptyDir` volumes for storing broker information (for ZooKeeper) and topics or partitions (for Kafka). Using an `emptyDir` volume means that its content is strictly related to the pod life cycle and is deleted when the pod goes down.
Persistent cluster:: A persistent Kafka cluster uses `PersistentVolumes` to store ZooKeeper and Kafka data. The `PersistentVolume` is
acquired using a `PersistentVolumeClaim` to make it independent of the actual type of the `PersistentVolume`. For example, it can use
ifdef::Kubernetes[HostPath volumes on Minikube or]
Amazon EBS volumes in Amazon AWS deployments without any changes in the YAML files. The `PersistentVolumeClaim` can use a `StorageClass` to trigger automatic volume provisioning.

The example YAML files specify the latest supported Kafka version, and configuration for its supported log message format version and inter-broker protocol version.
Updates to these properties are required when xref:assembly-upgrading-kafka-versions-str[upgrading Kafka].

The example clusters are named `my-cluster` by default.
The cluster name is defined by the name of the resource and cannot be changed after the cluster has been deployed.
To change the cluster name before you deploy the cluster, edit the `Kafka.metadata.name` property of the `Kafka` resource in the relevant YAML file.

.Default cluster name and specified Kafka versions
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    version: {DefaultKafkaVersion}
    #...
    config:
      #...
      log.message.format.version: {LogMsgVersHigher}
      inter.broker.protocol.version: {LogMsgVersHigher}
  # ...
----

For more information about configuring the `Kafka` resource, see link:{BookURLUsing}#assembly-config-kafka-str[Kafka cluster configuration^] in the _Using Strimzi_ guide.

.Prerequisites

* xref:deploying-cluster-operator-str[The Cluster Operator must be deployed.]

.Procedure

. Create and deploy an _ephemeral_ or _persistent_ cluster.
+
For development or testing, you might prefer to use an ephemeral cluster.
You can use a persistent cluster in any situation.

** To create and deploy an _ephemeral_ cluster:
+
[source,shell,subs="attributes+"]
kubectl apply -f examples/kafka/kafka-ephemeral.yaml

** To create and deploy a _persistent_ cluster:
+
[source,shell,subs="attributes+"]
kubectl apply -f examples/kafka/kafka-persistent.yaml

. Verify that the Kafka cluster was successfully deployed:
+
[source,shell,subs="attributes+"]
----
kubectl get deployments
----
