# Plan Log Retention and Deployment Constraints Plan pod log retention and review which configurations can’t change after deployment with Confluent for Kubernetes. ## Confluent Platform cluster log retention When you deploy Confluent Platform through Confluent for Kubernetes (CFK), plan log retention management early in the planning phase, and have a working log retention solution in your production environment. When a Kubernetes pod restarts, whether due to a crash or manual restart, the pod doesn’t automatically retain the logs that it generated during its previous lifecycle. The pods erase the logs because pods are ephemeral. They lose their data stored when they restart or get deleted. The historical Confluent Platform pod logs are crucial for troubleshooting purposes. You can follow several [common approaches](https://kubernetes.io/docs/concepts/cluster-administration/logging/#cluster-level-logging-architectures) for Kubernetes pod log retention, such as node-level logging, sidecar containers, or centralized logging solutions. Centralized logging is one of the solutions that forward the Confluent Platform pod logs to a centralized logging system, such as Elasticsearch, Logstash, and Kibana (ELK), or to a log management tool, such as Grafana or Loki. These third-party log management tools are not integrated with Confluent, but as a best practice, set up a Confluent Platform pod log retention solution in the production environment. ## Configurations that can’t change after deployment CFK provides a declarative API and configuration automation for running Confluent Platform on Kubernetes. You can update configurations and upgrade versions for an existing deployment by applying the updated declarative specifications in custom resource files. However, the following configuration scenarios cannot be enabled or changed for an existing deployment: * Confluent RBAC You can’t turn off Confluent RBAC on an existing cluster set up with RBAC. As a workaround, you can grant the `ClusterAdmin` role to a root group containing all users. * TLS certificates mechanism You can’t change the mechanism that provides TLS certificates between auto-generated certificates and user-provided certificates. * TLS encryption You can’t enable TLS encryption on a TLS-disabled cluster. You can’t enable TLS encryption on a TLS-disabled Apache Kafka® REST API server (`kafka.spec.services.kafkaRest.tls`). * Kafka listener authentication You can’t enable the authentication mechanism on existing Kafka and KRaft controller listeners. Also, you can’t change the authentication mechanism used for existing Kafka and KRaft controller listeners. * Kafka metrics TLS and authentication configurations * External network access mechanism for Kafka brokers * You can’t change the external network access mechanism for Kafka brokers among load balancer, node ports, and static ingress controller-based routing. * When you change the configuration of the external access mechanism, such as the domain or port, you might need to restart the Kafka cluster for the configuration to take effect. For more details, refer to the specific external access configuration guide. * Storage class for persistent storage You can’t change the storage class used to create persistent volume claims for Confluent components. * Configuration secrets mechanism You can’t change the configuration secrets mechanism between using Kubernetes secrets and using the directory in path containers feature.