Deploy and Manage Confluent Platform Using Confluent for Kubernetes Blueprints

Deploy Confluent Platform

When you deploy Confluent Platform from the Control Plane cluster with a Blueprint, CFK Blueprints creates the Confluent Platform pods and application resources in the target Kubernetes cluster.

From the Control Plane, you can perform the following on all your Confluent cluster deployments:

  • Provision a deployment
  • Monitor the status of a deployment
  • Update a deployment
  • Upgrade a deployment
  • Delete a deployment

A deployment allows you to override the configuration settings in the Blueprint, such as:

  • Certificates
  • External Access domains
  • Credentials
  • Replicas
  • Metadata labels

For clarify, the Control Plane and Data Plane are specified in this document. However, for the single-cluster deployments, the Control Plane and Data Plane refer to the same Kubernetes cluster.

To deploy a Confluent Platform cluster:

  1. Edit the CRs for the Confluent component clusters:

    Kind:                  —-- [1]
    metadata:
      name:                —-- [2]
    spec:
      resourceMetadata:    —-- [3]
        overrideName:
        overrideNamespace:
        annotations:
        labels:
      blueprintRef:
        name:              —-- [4]
        namespace:         —-- [5]
      k8sClusterRef:
        name:              —-- [6]
        namespace:         —-- [7]
      replicas:            —-- [8]
      dataVolumeCapacity:  —-- [9]
      externalAccess:      —-- [10]
      dependencies:
        metricsReporter:   --- [11]
    
  • [1] Confluent Platform component cluster type. Specify one of the following:

    • ZookeeperCluster
    • KafkaCluster
    • SchemaRegistryCluster
    • ControlCenterCluster
    • ConnectCluster
    • KafkaRestProxyCluster
    • KsqlDBCluster
  • [2] Name of this CR.

  • [3] Overrides for the Confluent Platform cluster in the remote target k8sClusterRef. This setting is ignored in single-cluster deployments.

    Set resourceMetadata.overrideName and resourceMetadata.overrideNamespace for the cluster name and namespace on the remote cluster. If omitted, metadata.name and metadata.namespace are used.

  • [4] Required. The name of the Blueprint to be used.

  • [5] The namespace of the Blueprint CR.

  • [6] Required. The Kubernetes cluster where the Confluent Platform component cluster is to be deployed.

  • [7] The namespace where the CR is to be deployed.

  • [8] Defaults to the replicas from the Blueprint.

  • [9] Defaults to the dataVolumeCapacity from the Blueprint.

  • [10] Defaults to the externalAccess and listeners from the Blueprint.

  • [11] Default metrics to send to Health+.

  1. In the Data Plane, create the namespace for the Confluent CRs (<data-plane-cp-namespace>).

  2. Deploy the Confluent Platform clusters:

    kubectl apply -f <Confluent component cluster CR yaml file> \
       -namespace <control-plane-cp-namespace>
    
  3. In the Data Plane, check when the Confluent components pods are up and running:

    kubectl get pods -namespace <data-plane-cp-namespace>
    

Monitor Confluent Platform

As a platform administrator, from your Control Plane, you can see which deployment provisioning is in progress and can track the state of the deployments:

kubectl get cpc -n <control-plane-cp-namespace>
kubectl get kafkaclusters -n <control-plane-cp-namespace>

Delete Confluent Platform

From your Control Plane, delete the Confluent CR to unistall a Confluent component from the Data Plane:

kubectl delete -f <Confluent component cluster CR yaml file> \
  -namespace <control-plane=cp-namespace>