Custom sidecars

Sidecars allow you to enhance your SaaS product's functionality without changing its core service. Think of them as add-on containers that run alongside your main application container. You can:

1. Add new features or capabilities by attaching sidecar containers
2. Use existing open-source implementations as sidecars
3. Deploy your own custom implementations as sidecars
4. Run multiple sidecars with each resource instance

The 'SIDECARS' resource capability makes this process simple, letting you expand your service's features in a modular way while maintaining isolation from the main application.

For example, you might add a sidecar to handle custom logging, or monitoring, while your main service container focuses on core business logic

Most basic configuration requires only an image with a version to be provided. Here is an example using compose spec:

x-omnistrate-capabilities:
  sidecars:
    tooling:
      imageNameWithTag: "busybox:stable"

With this configuration, your additional sidecar will inherit environment variables, config maps, and security context from your main resource.

Note

Pod volumes (including logs) will be automatically mounted to make them accessible for each sidecar container.

Overriding security context

In some cases, sidecar might require a specific user and/or group to execute. If that is your case, you can specify them within the configuration in the spec file as follows:

x-omnistrate-capabilities:
  sidecars:
    tooling:
      imageNameWithTag: "busybox:stable"
      securityContext:
        runAsUser: 10
        runAsGroup: 99
        runAsNonRoot: true

Providing custom limits

Omnistrate will set default resource limits for each sidecar. If you find default limits inappropriate, you can provide custom limits in spec configuration:

x-omnistrate-capabilities:
  sidecars:
    tooling:
      imageNameWithTag: "busybox:stable"
      resourceLimits:
        cpu: "250m"
        memory: "256Mi"

For more information about resource limits, see Kubernetes CPU limits documentation, or Kubernetes memory limits documentation.

Specifying an entry point

Not all containers come with an entry point preconfigured. When configuring the custom sidecar you might need to provide the command and arguments that ensure the sidecar performs its intended task and remains running continuously. Here is an example of a command, whose only purpose is to keep the container running:

x-omnistrate-capabilities:
  sidecars:
    tooling:
      imageNameWithTag: "busybox:stable"
      command:
        - "/bin/sh"
        - "-c"
        - "while true; do echo hello; sleep 10; done" 

Extra arguments can be passed by providing values to the "args" property:

x-omnistrate-capabilities:
  sidecars:
    my-sidecar:
      imageNameWithTag: "private/my-image:2.1.3"
      command:
        - "/bin/init-command"
      args:
        - "setup"
        - "{{ $sys.id }}"

API

All of the above configurations may be performed using API method EnableResourceCapability. The sidecar capability identifier is "SIDECARS" and configuration needs to be provided in the analogical form to spec configuration.