.. _co-env-sizing:

=======================
Sizing recommendations
=======================

Review the following sizing guidelines and recommendations before creating your
Kubernetes cluster.

Node number and size recommendations
-------------------------------------

The number of nodes required in your cluster depends on whether you are
deploying a development testing cluster or a production-ready cluster.

.. _co-bin-packing:

* **Test Cluster:** Each node should typically have a minimum of 2 or 4 CPUs and 7 to 16 GB RAM. If you are testing a deployment of |co| and all |cp| components, you can create a 10-node cluster with six nodes for |zk-full| and |ak-tm| pods (three replicas each) and four nodes for all other components pods.

  .. note::
     
     Confluent recommends running |zk| and |ak| on individual pods on individual
     Kubernetes nodes. You don't have to do this, but we've found that this is
     the best way to run |zk| and |ak| clusters.

  .. tip::
  
    Confluent recommends running |zk| and |ak| on individual pods on individual
    nodes. You can *bin pack* other components. Bin packing places component
    tasks on nodes in the cluster that have the least remaining CPU and memory
    capacity. Bin packing maximizes node utilization and can reduce the number
    of nodes required. Each |cp| component YAML file has the default entry
    ``disableHostPort: false``. You can enable bin packing by adding this
    parameter to the component section in the ``<provider.yaml>`` file and
    setting it to ``true``. Bin packing components is **not recommended** for
    production deployments. Also, note that when set to ``false``, the default
    port used is **28130**. 

* **Production Cluster:** Review the default :ref:`capacity values <co-yaml-parameters>` in the ``helm/providers/<provider>.yaml`` file. Determine how these values affect your production application and build out your nodes accordingly. You can also use the on-premises :ref:`System Requirements <system-requirements>` to determine what is required for your public or private cloud production environment. Note that the on-premises storage information provided is not applicable for cloud environments.

  .. note::
   
    Your Confluent Sales Engineer can help you determine the number of nodes
    required for your application. To get additional information, you can also
    contact `Confluent Support <http://support.confluent.io/>`_ .

.. _co-yaml-pod-resources:

Pod resource parameters
------------------------
   
The default parameters in the provider YAML file specifies pod resources needed.
If you are testing |co-long| and |cp|, your resource requirements may not be as
great as the default values shown. However, |zk| and |ak| must be installed on
individual pods on individual nodes.

.. important:: 
   
   At least three |ak| brokers are required for a fully functioning |cp|
   deployment. A one- or two-broker configuration is not supported and should
   not be used for development testing or production.

|co-long| can define pod resource limits for all |cp| components it deploys. You
can define these settings using the ``requests`` and ``limits`` tags for each
component in their ``values.yaml`` file. The following example shows the default
pod resource parameters in a provider YAML file snippet for |ak|. See `Managing Compute Resources for Containers <https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/>`__ for more details.

.. note::
   
   The ``limits`` property is shown in the following example. The default for
   ``limits`` is empty and not shown in the default ``provider.yaml`` files. It's only shown here so you know where it goes in the .yaml file. See `Managing Compute Resources for Containers <https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/>`__ for more details.

::

   ## Kafka Cluster
   ##
   kafka:
     name: kafka
     replicas: 3
     resources:
       ## It is recommended to set both resource requests and limits.
       ## If not configured, kubernetes will set cpu/memory defaults.
       ## Reference: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
       requests:
         cpu: 200m
         memory: 1Gi
       limits: {}
     loadBalancer:
       enabled: false
       domain: ""
     tls:
       enabled: false
       fullchain: |-
       privkey: |-
       cacerts: |-

.. _co-yaml-parameters:

During installation, |co-long| and |cp| components are created based on
parameters stored in multiple Helm Chart ``values.yaml`` files (one for |co| and
one for each |cp| component) and the ``<provider>.yaml`` where you are
installing your |cp| cluster.

.. important::
   
   Do not modify parameters in the individual component ``values.yaml`` files.
   If you need to adjust capacity, add a parameter, or change a parameter for a
   component, you modify the component section in the ``<provider>.yaml`` file.
   You can also adjust configuration parameters after installation using
   :ref:`helm upgrade <co-configuration-modification>`.

The ``<provider>.yaml`` file is layered over the ``values.yaml`` files at
installation and contains values that are specific to provider environments and
that can be modified by you prior to installation.

After you download the Helm bundle you'll see that:

* The ``values.yaml`` file for each |cp| component is stored in ``helm/confluent-operator/charts/<component>/``. 
* The ``values.yaml`` file for |co-long| is stored in ``helm/confluent-operator/``. 
* The ``<provider>.yaml`` file for each provider is stored in ``helm/providers/``.

At installation, Helm reads the YAML files in the following layered order:

#. The ``values.yaml`` for the |cp| component is read.
#. The ``values.yaml`` for |co| is read.
#. The ``providers.yaml`` is read.

.. include:: includes/cli-updates-at-install.rst