Kubernetes is universally lauded for its ability to seamlessly orchestrate the deployment of containers in almost any environment. It eliminates the majority of the complexity for configuring, spinning up, and performing run-time operations for containers at enterprise scale to make them the de facto mode of managing these logical units.
When it comes to assuring organizations of high availability and business continuity, however, this platform has traditionally had its fair share of issues, particularly at the application level for databases and other mission critical deployments.
Although it offers some failover capabilities in this context, according to DH2i CEO Don Boxley, “Because of the statefulness of the application database, if the failover didn’t happen perfectly, I would’ve lost data. The second thing is the failover really takes a long time: customers are seeing an average of two to 10 minutes for a new pod to come back up and get itself settled.”
When handling rapid e-commerce transactions during pivotal time periods such as Cyber Monday, for example, that much downtime can result in the loss of hundreds of thousands of dollars—if not more.
Nonetheless, such concerns have now been alleviated by the newfound capacity to support SQL Server availability groups in Kubernetes. With this option organizations can specify ahead of time which nodes they’d like to failover to (across clouds, datacenters, and settings) to instantly transition between them in the event of failure.
Applying this approach to additional applications makes Kubernetes truly enterprise worthy in terms of high availability, which significantly reduces the risk of using this popular method for managing containers.
The Kubernetes Approach
Kubernetes has a distinct method of enforcing its somewhat limited high availability capabilities for applications. Although it doesn’t involve previously defined, end user approved availability groups, conceptually it’s centered on “a bunch of nodes it’s got under management,” Boxley explained. “A node goes down; it’s responsible for bringing up a replacement node for that somewhere.” From a more granular perspective, Kubernetes arranges its management of containers with the following triad:
- Nodes: Nodes are the fundamental building block of computing instances. As Boxley’s previous quote indicates, what Kubernetes essentially does is manage those nodes (and orchestrates them for customers to abstract the complexity of doing so). In this context, nodes are what containers run on.
- Pods: Boxley specified that pods are “a logical grouping of nodes, what we would call a VM, for example. But, it obviously doesn’t have to necessarily be a VM. It could be a bare metal machine. It’s kind of like a cluster inside a cluster.”
- Clusters: Clusters are a set of pods with the nodes the latter contain. Within Kubernetes clusters users can have “a pod completely go away for some reason, and Kubernetes would fire up another pod to compensate for that,” Boxley revealed. “Within a pod you can have a node go away and it would fire up another node to compensate for that specific node going away. So, it’s failing over from one node to another node.”
The Availability Group Approach
The problem with this method is the performance issues Boxley outlined—specifically, considerable latency and the issue of state in which containers replete with application data are termed “stateful”. With crucial database applications like SQL Server, for example, data loss can result in all sorts of complications, not the least of which are cost and regulatory repercussions. Availability groups remediate this situation so that there’s “that comfort that if a node goes down I’ve got my secondaries all ready, and SQL Server will takeover the failover responsible for it, and I don’t really care what Kubernetes is doing because I’ll have two nodes already running,” Boxley commented.
Availability groups are a mainstay of SQL Server and are its primary form of ensuring high availability. Until recently, however, they weren’t available for containers via platforms like Kubernetes. Their implementation in Kubernetes solidifies much needed resiliency for running containers with this platform. SQL Server availability groups are responsible for “high availability of the application,” Boxley mentioned. However, in the event of failure, Kubernetes will still continue with its own failovers to “bring that primary [node] back someplace else, that’s fine, but [customers] don’t have to be held hostage to that process,” Boxley indicated. “They can keep going.”
And Going, and Going…
The ability to perpetuate the useful lifespan of applications and the data they contain is the end goal of high availability. SQL Server availability groups for the containers Kubernetes manages fulfills this objective, without which container deployments—and by extension, the myriad cloud use cases they support—are somewhat tenuous. But with this approach, they become much more reliable so organizations can continue to work under even trying circumstances.