Relevance of HA architecture for Kubernetes service

Introduction

Laymen explanation

If you worked on solution deployment, you must be agreeing that HA is important to provide interruption free service of software. At the same time, you might be agreed that HA technology comes with its own cost - pricing, upgrade, deployment and scale related challenges.

Does Kubernetes environment has any say about HA? Does K8s environment has any say about session persistence on failure(connection failover).

Technical explanation

• Traditionally, North-south traffic(end user facing) needs connection failover for HA.

• Micro-services brought two-tier architecture concept (North-South and East-West) where east-west traffic plays significant role.

• East-west traffic is related to communication between apps. This tier(East-west) can live with less stringent flavour of HA.

Cost of connection failover based HA

I am here not talking about money alone. Rather there are other challenges mentioned below.

• • Pricing

  • Upgrade challenge

  • Compute overhead related to connection state sync

  • Deployment complexity

  • Scale challenge. Note that in HA, state sharing happens. This must be designed to match infinite scale claim of Kubernetes. This architecture needs rethink and might be quite challenging to implement while migrating monolith to micro-services

Can HA be avoided?

• HA can't be avoided, but its requirement can be relaxed.

• For East-west traffic, session persistence on failover is mostly not needed. Client App can retry as fresh.

• For north-south traffic, session persistence on failover might be needed for better user experience. Here human being is a user and initiator.

• A long-lived doesn't always imply that it needs session persistence on failure.

  • For optimisation, few system keeps long-lived connection. For example, database connection is long-lived. However, database system also allow reconnect as fresh. It means that session persistence on failover should not be needed.

  • For cases like downloading big files might have significant penalty on restart. In this case, persistence on failover is desirable.

Architectural condition to live with relaxed HA

K8s service by default supports HA. You simply need to enable more than one replicas of a service POD. So life is simpler. Additional requirements are

• • Client should be able to reconnect immediately on failure. In K8s it is easy to do by maintaining multiple POD based service. East-west Apps are mostly designed this way.

  • Client must be able to continue seamlessly on reconnect. If stateless, then it is pretty simple. For stateful, idempotent request is desirable. An Idempotent request results same response if called twice

  • Client should not keep residue of broken connection. This is mostly related to cleanup.

  • It is preferred that connections are short-lived. A long lived connection has higher overhead of retry (cleanup cost, retry cost etc).

Connection failover for North-South traffic

• • Load balancer can persist connection if server app fails. This is done by maintaining session info in the load balancer (so behaving as proxy)

Reference

https://learnk8s.io/kubernetes-long-lived-connections

https://docs.citrix.com/en-us/netscaler/12/load-balancing/load-balancing-protect-configuration/connection-failover.html

https://blog.jetstack.io/blog/k8s-getting-started-part3/