Customizing Mule App Kubernetes Resources

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:

Note that customization of environment variables is not supported:

Environment Variables

The env supported only keywords are for enable console logging and 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:

kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml

Examples

Configuring labels at pod, deploy, and service objects:

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:

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:

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 }}"

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:

pod:
   env:
       ENABLE_CONSOLE_LOG: "true"

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 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.

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:

pod:
   env:
       DISABLE_PER_APP_SA: "true"