Managed Containers - Octelium Docs

In addition to serving internal and private resources behind NAT from anywhere as well as serving protected public resources such as SaaS APIs and databases, Octelium Clusters enable you to seamlessly deploy, manage and scale your containerized applications and serve them as Services by reusing the underlying Kubernetes infrastructure that runs the Octelium Cluster and deploying your Dockerized images on top of it. Here is a simple example of running an nginx image as an Octelium Service:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: nginx:latest

NOTE

Managed containers are automatically scheduled over data-plane nodes (read more here).

Environment Variables

You can also add your environment variables as follows:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: nginx:latest
11        env:
12        - name: KEY1
13          value: VALUE1
14        - name: KEY2
15          value: VALUE2

Command and Arguments

You can override the container's "entrypoint" command via the command array as follows:

1kind: Service
2metadata:
3  name: my-api
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: my-api:latest
11        command:
12        - /bin/another-binary

You can also add any command-line arguments via the args array as follows:

1kind: Service
2metadata:
3  name: my-api
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: my-api:latest
11        args:
12        - --arg1=value1
13        - --arg2=value2
14        - --arg3
15        - val3

Scaling

You can easily scale up/down your upstream containerized application by controlling the number of replicas as follows:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: nginx:latest
11        replicas: 4

Private Registry

You can deploy Docker images from private container registries. In such case, all you have to do is add the registry credentials as follows:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: ghcr.io/org/image:tag
11        credentials:
12          usernamePassword:
13            username: username
14            password:
15              fromSecret: secret-1

NOTE

You can read more about Secret management here.

Resource Limits

You can restrict how much memory and CPU your application can consume by forcing resource limits. Here is an example:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: nginx:latest
11        resourceLimit:
12          cpu:
13            millicores: 1500
14          memory:
15            megabytes: 512

Extended Resources

You can also set an extended resource limit to request custom resource that can be recognized by your Kubernetes cluster. For example this can be useful to request and schedule a GPU for your managed container (read more here). Here is an example:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: nginx:latest
11        resourceLimit:
12          cpu:
13            millicores: 1500
14          memory:
15            megabytes: 512
16          ext:
17            nvidia.com/gpu: "1"

Security Context

You can also set a few security related configurations for your managed container such as enforcing a read-only root filesystem and setting the user ID. Here is an example:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  config:
7    upstream:
8      container:
9        port: 80
10        image: nginx:latest
11        securityContext:
12          readOnlyRootFilesystem: true
13          runAsUser: 1000

Dynamic Configuration

You can also simultaneously deploy more than one container and dynamically route among them depending on identity as well as context (read more in detail about dynamic configuration here). Here is an example:

1kind: Service
2metadata:
3  name: nginx
4spec:
5  mode: HTTP
6  dynamicConfig:
7    configs:
8    - name: c1
9      upstream:
10        container:
11          port: 80
12          image: ghcr.io/org/image:v1
13    - name: c2
14      upstream:
15        container:
16          port: 80
17          image: ghcr.io/org/image:v2
18    rules:
19    - condition:
20        match: ctx.request.http.path.startsWith("/v1")
21      configName: c1
22    - condition:
23        match: ctx.request.http.path.startsWith("/v2")
24      configName: c2