docs/modules/traits/pages/pod.adoc

= Pod Trait

// Start of autogenerated code - DO NOT EDIT! (description)
The pod trait allows the customization of the Integration pods.
It applies the `PodSpecTemplate` struct contained in the Integration `.spec.podTemplate` field,
into the Integration deployment Pods template, using strategic merge patch.

This can be used to customize the container where Camel routes execute,
by using the `integration` container name.


This trait is available in the following profiles: **Kubernetes, Knative, OpenShift**.

// End of autogenerated code - DO NOT EDIT! (description)

*Note 1*: In the current implementation, template options override the configuration options defined via CLI, for example in:

[source,console]
----
$ kamel run integration.groovy --pod-template template.yaml --env TEST_VARIABLE=will_be_overriden --env ANOTHER_VARIABLE=Im_There
----

The value from the template overwrites the `TEST_VARIABLE` environment variable, while `ANOTHER_VARIABLE` stays unchanged.

*Note 2:* Changes to the `integration` container entrypoint aren't applied due to current trait execution order.

// Start of autogenerated code - DO NOT EDIT! (configuration)
== Configuration

Trait properties can be specified when running any integration with the CLI:
[source,console]
----
$ kamel run --trait pod.[key]=[value] integration.groovy
----
The following configuration options are available:

[cols="2m,1m,5a"]
|===
|Property | Type | Description

| pod.enabled
| bool
| Can be used to enable or disable a trait. All traits share this common property.

|===

// End of autogenerated code - DO NOT EDIT! (configuration)

== Sidecar containers

With the following Integration, that reads files from a directory:

.integration.groovy
[source,groovy]
----
from('file:///var/log')
 .convertBodyTo(String.class)
 .setBody().simple('${body}:  {{TEST_VARIABLE}} ')
 .log('${body}')

----

Plus the following Pod template, that adds a sidecar container to the Integration Pod, generating some data into the directory, and mounts it into the `integration` container:

.template.yaml
[source,yaml]
----
containers:
  - name: integration
    env:
      - name: TEST_VARIABLE
        value: "hello from the template"
    volumeMounts:
      - name: var-logs
        mountPath: /var/log
  - name: sidecar
    image: busybox
    command: [ "/bin/sh" , "-c", "while true; do echo $(date -u) 'Content from the sidecar container' > /var/log/file.txt; sleep 1;done" ]
    volumeMounts:
      - name: var-logs
        mountPath: /var/log
volumes:
  - name: var-logs
    emptyDir: { }
----

The Integration route logs the content of the file generated by the sidecar container, e.g.:

[source,console]
----
$ kamel run integration.groovy --pod-template template.yaml
...
Condition "Ready" is "True" for Integration integration
[1] 2021-04-30 07:40:03,136 INFO  [route1] (Camel (camel-1) thread #0 - file:///var/log) Fri Apr 30 07:40:02 UTC 2021 Content from the sidecar container
[1] :  hello from the template
[1] 2021-04-30 07:40:04,140 INFO  [route1] (Camel (camel-1) thread #0 - file:///var/log) Fri Apr 30 07:40:03 UTC 2021 Content from the sidecar container
[1] :  hello from the template
[1] 2021-04-30 07:40:05,142 INFO  [route1] (Camel (camel-1) thread #0 - file:///var/log) Fri Apr 30 07:40:04 UTC 2021 Content from the sidecar container
[1] :  hello from the template
----

== Init containers

With this trait you will be also able to run `initContainers`. There is a little caveat though, as you will need to include at least one container in the template spec, you will need to provide the configuration for the default container, which is `integration`. Here a simple example:

.template.yaml
[source,yaml]
----
containers:
  - name: integration
initContainers:
  - name: init
    image: busybox
    command: [ "/bin/sh" , "-c", "echo 'hello'!" ]
----

The `integration` container will be overwritten by the container running the route, and the `initContainer` will run before the route as expected.