Showing results for 
Search instead for 
Did you mean: 

InfoScale Availability Support for Kubernetes

Level 2

InfoScale Availability will support containers in Kubernetes with the InfoScale 7.4.3 release. This feature is intended to simplify support for making applications running in containers highly available and incorporates support for InfoScale features that enable businesses to build highly resilient and performance applications.

InfoScale works with Kubernetes to ensure your containerized applications are highly available by providing an interface for Kubernetes Liveness Probes. I’ll start by introducing two concepts integral to this solution, Veritas Cluster Server (VCS) for Containers and Kubernetes High Availability and how they work together. Next, I’ll discuss VCS Sidecar and monitoring within the application container and why this solution provides value.

Veritas Cluster Server for Containers

Veritas Cluster Server (VCS) monitors and orchestrates high availability for mission-critical enterprise applications. VCS does this by monitoring the application and its resources, orchestrating a failover (and failback) when a fault is detected. You can read more about VCS functionality here.

VCS for containers running on Kubernetes can be deployed in two ways.

  • VCS can be deployed as a sidecar container as part of the Pod containing the application container and other containers.
  • VCS can be deployed within the application container itself.

Using VCS to monitor the application and the required resources, you can ensure that their integrity is maintained, preventing unnecessary outages. This model also provides a familiar look and feel and operation to application owners responsible for making their applications highly available.

Kubernetes High Availability

Kubernetes worker nodes run the Kubelet service, responsible for checking to see if containers are running (amongst many other tasks). The Kubelet checks on each container to see if they are running, with a Liveness Probe at set time intervals. If the container has stopped running or responding, the container may be restarted.

VCS works in co-operation with Kubernetes by returning Liveness Probe requests. In other words, to make your container highly available, Kubernetes Liveness Probes are used to query VCS agents to find out if the application and its resources are running normally.

To help you understand why this model is beneficial, I need to discuss the two ways that we implement InfoScale Availability in containers on Kubernetes. 

VCS Sidecar Container Implementation

A Sidecar container is simply an extra container deployed with a Pod containing an application that you wish to make highly available with InfoScale Availability. The implementation of the sidecar container typically includes the following VCS agents

  • Application monitoring agent – Used for monitoring the application.
  • Mount agent –  Detects the presence of a required Persistent Volume claim.
  • Network agent – Ensures that a required network resource is available.

When the Application Pod is deployed, the Application container and InfoScale Sidecar container are simultaneously launched with the same Kubernetes Process Namespace. The shared Process Namespace enables the InfoScale Sidecar container to monitor the application by PID.

Figure 1 High Availability implementation with InfoScale Sidecar containerFigure 1 High Availability implementation with InfoScale Sidecar containerFigure 1 is a block diagram showing the implementation of a Sidecar based HA container solution.

The Kubernetes Liveness Probe is initiated by the Kubelet and queries the VCS Agent(s) in the InfoScale Sidecar container for the Application Container status. If the Liveness Probe fails to return the desired result, the Kubelet can kill and restart the Application Container.

VCS deployed within an Application Container

Deploying VCS directly within the Application Container involves creating the container and installing VCS in it in the usual way with a regular server.

Figure 2 In-application VCS implementationFigure 2 In-application VCS implementation

High availability is achieved in the same way as with the InfoScale Sidecar implementation except that VCS is installed directly inside the Application Container. Thus, the Kubelet still conducts Liveness Probes on the VCS Agent and will kill and restart the Application Container if required. 

What’s the difference?

Below are the benefits of each implementation.

VCS Sidecar Benefits

-        Pre-configured for applications (MySQL upon 7.4.3 launch).

-        Don’t have to configure storage and network resources as they are automatically configured through configmaps.

-        Vendor provided application containers won’t require modification.

VCS In-Application Benefits

-        Supports all existing VCS Agents.

-        Supports custom applications.




For more information about InfoScale, please take a look at our technical library.

KubeCon 2020

Want to see a demo of InfoScale 7.4.3 with CSI and VCS? Or do you have questions for our InfoScale Experts? Join me at KubeCon on November 17-20, 2020. Register for the event happening now, and search for Veritas in the sponsor directory to find our virtual booth: