OpenKruise Sidecar set for data locality

https://github.com/openkruise/kruise/blob/master/docs/tutorial/sidecarset.md

In previous posts, I have talked about "data" components that could be co-located with compute resources.   This would decouple data from compute and allow each to be more focused on their respective jobs while depending on the other to perform their part of the interface contract.

This is like spring bean injection, but at the container level.   Realizing this pathway to seeing a part of a new level of code that is now possible.   It's not inside the JVM but inside Kubernetes.  You co-locate containers in Pods to collaborate on problems and get the benefits of data and network locality.  

OpenKruise has a SideCarSet that can make management of this type of configuration easier.  In a recent post, I talked about Gloo and Virtual Services.  Now the picture is coming into focus:

Pod Level

Gloo Virtual Service

Kubernetes Service

OpenKruise Advanced Stateful Set

OpenKruise SideCarSet

Node Level:  

Local DB DaemonSet

With these pieces you can start to think about containers as "beans" and use OO techniques like composition.  Now the Pod becomes your local "application context" and Kubernetes becomes a "parent application context"

The documentation for the AdvancedStatefulSet says that it functions mostly the same as the original StatefulSet but will allow in place replacement of container images.

The Kubernetes StatefulSet supports multiple containers in the spec ( see this example:  https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/)

Hopefully the AdvancedStatefulSet supports changing all the containers in Pod.  This would make the pods truly dynamic.  I had blogged about phase changes during the processing of a series of steps.  If the AdvancedStatefulSet could handle the image changes, this could be the way to do that.  More experimentation is needed.

There are two levels of data sharing here.  Node level - not the same as pod level but close.  Pod level has special properties (see below), but both are options:

https://www.mirantis.com/blog/multi-container-pods-and-container-communication-in-kubernetes/

Note: containers can keep their own in process cache also.