--- schema_version: "1" id: 6540b1c9c086de175671d8ebd04a93b626a1bea578f33ec121d4a69a1e90d8d6 title: Customizing Mule App Kubernetes Resources collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/runtime-fabric/2.9/customize-kubernetes-crd.md canonical_url: https://docs.mulesoft.com/runtime-fabric/2.9/customize-kubernetes-crd source_site: docs.mulesoft.com content_type: documentation content_hash: c507d22b7307fccb7b488a2f769e335bcf8eb0aa0fe62fba632c48865a6cd2c7 description: MuleSoft Documentation Site release: "2.9" latest: false --- --- product: Runtime Fabric version: 2.9 --- # Customizing Mule App Kubernetes Resources > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Runtime Fabric enables you to customize your Mule app Kubernetes resources through the custom resource `kubernetestemplates.rtf.mulesoft.com` template. Name the `kubernetestemplate` resource as `mule-application`. You can define the template in two different namespaces: - Apps namespace The template is applied to all Mule apps deployed to the given namespace. - Runtime Fabric agent namespace The template is applied to all Mule apps managed by the given Runtime Fabric agent. The `kubernetestemplate` resource applies only to new Mule app deployments after the resource creation. It does not affect existing deployments. If you redeploy a Mule app after creating or updating the `kubernetestemplate`, the template is applied. The `kubernetestemplate` resource enables you to configure the following elements of your apps pods, deployments, and services objects: - Pod - [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [Node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [Ephemeral storage limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [Topology spread constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [Service Account Token](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) Note that customization of environment variables is not supported: - [Environment Variables](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) The env supported only keywords are for [enable console logging](#enable-console-logging) and [disable service account](#disable-service-account). For the security context pod, the key to use is `containerSecurityContext`. - Deployment - Annotations - Labels - Service - Annotations - Labels Configuration elements already defined by Runtime Fabric take precedence over the ones you define in the template. To get the CRD of key elements that you can configure for the template, you can get the Kubernetes specification by running the following command: ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## Examples Configuring `labels` at `pod`, `deploy`, and `service` objects: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` Configuring the runtime default `seccompProfile` for `containerSecurityContext` under the `pod` object: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` Another example with all the keys that you can configure: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" rtf.mulesoft.com/generation: "{{ .Values.resourceContentHash }}" ``` Key elements that can not be overwritten using the CRD: - Deployment - labels - environment - organization - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - Pods - annotations - fluentbit.io/exclude - mulesoft.com/resources - labels - app - environment - am-org-id - root-org-id - organization - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - Resources - ephemeral-storage (if is not set in env.resources or cluster flavor is rtfc) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity - podAntiAffinity - Service - labels - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - annotations - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## Enable Console Logging By default, console logging is disabled if it’s detected that your Mule app logs at least one other source. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. To enable console log using the Kubernetes template, set the `ENABLE_CONSOLE_LOG` variable in the `env` section: ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ``` > [!NOTE] For clusters that forward logs using `stdout`, there is potential impact on log forwarding > functionality. Work with your Kubernetes team to adjust log forwarding configurations accordingly > and ensure continuous log monitoring and collection. If you use a side car container for Anypoint Monitoring (with AMLogFwdingAppender), console logging is also disabled. ## Disable Per Application Service Account By default, a [service account](https://kubernetes.io/docs/concepts/security/service-accounts/) is created for every Mule application deployment. You can override this default behavior using the Kubernetes template, either at the cluster level with the root Kubernetes template or at the Mule app namespace level. If disabled, the Mule application deployment uses the [default service account](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts). To disable the creation of the service account per Mule application using the Kubernetes template, set the `DISABLE_PER_APP_SA` variable in the `env` section: ```copy pod: env: DISABLE_PER_APP_SA: "true" ```