Skip to content

Containers

Overview

Workload created using the "workload wizard" can have multiple containers and each container can have its own unique configuration.


Container Configuration

Service Name

  • Provide a service name for your container. Note that the name has to be unique within a given workload.

Container Image

  • Provide the Image and the Tag for the container image.
  • These will pulled from the customer's Container Registry

Advanced

Users can optionally configure "commands" and "args" to dynamically change the behavior of their container.

Type

The workload wizard currently supports "Deployments" and "Stateful Sets" types.

Containers

Ports and Protocol

  • Specify the ports and protocols that you would like to allow clients to connect to the container. Both TCP and UDP protocols are supported within the cluster.

Sizing

The Rafay platform provides a standard set of container sizes by default. In addition, application owners can also create custom container sizes if needed.

Type CPU Memory Storage
Nano 0.125 0.5 GB 1 GB
Micro 0.25 1 GB 2 GB
Small 0.5 2 GB 10 GB
Medium 1.0 4 GB 20 GB
Large 2.0 8 GB 40 GB
X Large 4.0 16 GB 80 GB

In addition to this, when additional capacity needs to be allocated for a workload, the default capacity for the Org Namespace can be updated in the Ops Console.

Containers


Initial Replica Count

Certain containers in the workload may be heavily utilized and there may be a need to operate multiple replicas to handle the baseline load.

For example, a user facing container may have to handle 1000s of concurrent connections. It may make sense for this container to start life by running >1 replicas.

Customers can review container utilization trends in the dashboard and determine the most appropriate number of initial replicas.


Auto Scaling

A typical application will have periods of low and high utilization. For example, a business productivity application is likely to have very high utilization from 9am to 5pm business hours and very low utilization on weekends. In contrast, an entertainment application may have high utilization in the evenings and extremely high utilization on weekends.

Containers

It makes significant economic sense for application operators like Design Capacity for a Baseline and leverage Auto Scaling for the peaks.

Containers

Customers can configure thresholds for metrics (CPU and Memory utilization) for auto scaling is triggered. When triggered, replicas are added to ensure that utilization is brought below the configured thresholds. Containers can be configured to autoscale to a specified upper limit (so as to not blow away the budget).

Scale down is performed automatically after a cool down period (5 minutes) to ensure that the system does not land up trashing.

Containers


Log Aggregation

If a logs endpoint is configured for the workload, and logs aggregation is enabled for the container, then the Rafay managed "Fluentd" will automatically scrape logs emitted by the container to stdout and directly stream the logs to the configured endpoint.

Anything emitted to stdout is collected and aggregated. The logs are streamed directly from the "managed cluster" to the configured aggregation endpoint.

Containers


Volumes

If the container need a local storage volume, it needs to be declared explicitly. Customers need to give it a name, specify a size, configure the mount path and configure if it needs to be persist across container restarts. A container can be configured with multiple storage volumes if it requires it.

For example, if the container is a database, it makes sense for the storage volume to be persistent to ensure there is no data loss. In contrast, for stateless containers, there is little value in persistent storage.

Containers


Startup Configuration

A container may require access to a number of configuration information when it starts up.

Environment Variables

Containers may need access to specific ENV variables during startup. If these contain sensitive data, customers should enable the "secure" option to ensure that they are secured both in transit and at rest on the cluster and only accessible to the configured container.

The default security setting is "secure" to protect against inadvertent configuration errors.

Files

Containers may need access to a file with configuration information etc during startup. For example, a webserver container may need a specific config file for it to startup properly. The file is made available to the container at a configured mount point.

If the file contains sensitive data, customers should enable the "secure" option to ensure that they are secured both in transit and at rest on the cluster and only accessible to the configured container.

The default security setting is "secure" to protect against inadvertent configuration errors.

Certificates and Private Keys

If the container needs to act as a TLS server or a client, it will require access to certificates and private keys. The Rafay platform can make this available to the container at a configured mount point.

Private keys are extremely sensitive credentials. As a result, they are distributed to the required clusters in a secure manner (encrypted).

Containers


Health Checks

Rafay strongly recommends that customers leverage health check capabilities to ensure availability of their applications. The Rafay platform can be configured to perform two types of health checks on containers.

Readiness

Readiness checks are performed when a container starts. The Rafay platform can use the result of the readiness tests to determine if the container is healthy and ready to serve users.

Liveness

Liveness checks are performed on an ongoing basis during the lifetime of a container. The Rafay platform can use the result of liveness tests to determine if the container is still healthy. If not, it will stop sending it traffic and take remediation action.

Only one probe each can be configured for readiness and liveness respectively. However, the same probe can used for both readiness and liveness tests.

Containers

Types of Probes

Rafay allows customers to create probes based on EXEC, HTTP, HTTPS and TCP.

  • Probe Interval: The frequency (in seconds) at which the platform will probe the container. The default probe interval is 10 seconds.

  • Timeout: Number of seconds the platform will wait before the unresponsive container is deemed unavailable.

  • Success Threshold: Number of probes before the container is deemed as available.

  • Failure Threshold: Number of probes before the container is deemed as unavailable.