There are a number of samples that can be found in the samples/docker/applications directory of your Apama installation. The Simple sample has already been referenced in Quick start to using Apama in Kubernetes. The other samples in the above directory cover more complex use cases. These samples build upon the base image and demonstrate how to use an Apama correlator in a Kubernetes environment to build your own applications.

The README.txt files that are provided in the samples/docker/applications directory and in each of the individual sample subdirectories guide you through the process of building and running. The samples demonstrate various ways in which Kubernetes can be used to deploy Apama and related Software AG products. They also demonstrate interactions between containers and normal applications such as dashboards.

This sample deploys Apama's Weather demo. It demonstrates the use of separate pods and connecting services to allow communication between them. A correlator pod and a dashboard server pod connect just as in the non-Docker Weather sample. The engine and weather services expose the required ports allowing connections to be made.

This sample starts an IAF pod which connects to a correlator pod connected by a service. The IAF is running the File transport. An EPL application is deployed into the correlator, which requests the contents of a file inputFile.txt from the File adapter, and then directs it to write those contents back out to another file outputFile.txt.

The configuration for the correlator pod defines a readinessProbe that checks that the correlator is running before the pod is marked ready. In a similar way, the IAF pod configuration defines an initContainer to make sure the service it uses to connect to the correlator is present before continuing.

See also Deploying an Apama application using Kubernetes which refers to this sample.

For containers to share dynamic data, they need a live view on that data. This is provided by a Kubernetes feature called volumes, which allows containers to share parts of their file system with each other. We use the Kubernetes PersistentVolume, PersistantVolumeClaim and Deployment objects to implement the sample.

This sample contains a toy application MemoryStoreCounter.mon that makes use of the MemoryStore to lay down persistent state on disk in the form of a number that increments each time the monitor is loaded. While the correlator container is the one reading and writing to the MemoryStore, the persistent file is on a volume which is persisted between container restarts.

Kubernetes volumes give you the ability to manage data that has a different lifecycle to the container that uses it. In an application like this, you can replace the other containers with equivalents that are based on a newer version of Apama. After bringing them up again, the correlator will still have access to the MemoryStore data that it wrote in a previous iteration, as this data is owned by the volume.

This sample demonstrates two Apama correlators communicating with each other via a Universal Messaging realm server. Therefore, Universal Messaging must be installed to run. A service is created that allows the correlators to communicate with the Universal Messaging pod, and the correlator pod uses an initContainer element in the Kubernetes configuration to ensure that the Universal Messaging service exists before continuing.

This sample introduces the StatefulSet as a method to allow scaling correlators using a common resource. The structure of the sample is meant to represent a real world scenario in which persistent data is accessed by multiple correlators. Kubernetes Services, StatefulSets and pods are used to set up and initialize the running system. The StatefulSet starts up a number of correlator pods that process events. A Terracotta pod provides the store for the running correlators to share. There are headless services binding the correlators and Terracotta, allowing the resultant pods to have allocated hostnames that are used in the configuration.

When the sample is started, it starts up several correlators, where each correlator connects with the Terracotta store. One pod uses the engine_send tool to send events to one of the correlators. The event processing is then handled by that correlator. The processing updates the stored state, making it available to all other correlator pods.

This sample demonstrates how to use Kubernetes secrets to set variables in correlator configuration files. These can then be loaded at runtime into a correlator.