The goals of this project/repo are the followings:
- Get hands-on with k8s CRD investigating what is needed to use CRD in a real production scenario.
- Understanding the k8s API model with a special attention to its extensibility
- Assuming you decided to use k8s as the hosting platform for your application workloads, be challenged on the idea of using k8s framework to store and share entities managed by your business application running in k8s.
According to the so called microservices approach, independent applications running within an applications ecosystem need to store their (owned) entities and share it with other applications part of the same ecosystem.
Usually to accomplish this goal each application exposes a set of (REST) API to receive entities data and persist it into a dedicated/owned storage.
Before persisting these entities, some business rules are applied to accept it and after the entities are persisted, the related data are broadcast within the ecosystem the application belongs to in case other applications are interested to these data/entities as well. A message broker part of the ecosystem is usually adopted to share these resources across the applications.
Goal of this project is to accomplish the scenario described above leveraging on the built-in k8s features in order to implement the architecture described in the following diagram
The next goal is collecting the potential issues of this approach, although technically feasible, highlighting the disadvantages and the risks related to it.
Sync one-time execution vs async loop reconciliation.
Business logic applied by the k8s controller should be delegated to a queue and executed form there. K8s provides its own queueing mechanism.
I'm currently grabbing existing code samples from multiple sources to quickly match the goal described above so prove the technical feasibility.
with plain yaml
cd kind
# create cluster
sh create-cluster.sh
# deploy workloads
sh deploy.sh k8s-as-backend y
with the operator using the e2e test framework with not clean-up
cd operator
sh run-all.sh
with a running operator
cd operator
sh deploy-with-running-operator.sh
then open an other terminal and run the following once the previous terminal is idling
cd operator
kubectl config set-context --current --namespace operator-running
kubectl apply -f deploy/crds/kab01.yaml
I'm also working on a k8s operator to deploy and monitor the described solution.
Project resources dependencies vs operator scope
- The Distributed System ToolKit: Patterns for Composite Containers
- Designing Distributed Systems
- Distributed Application Runtime
My current skills on golang are very limited. Any contribution to speed up the implementation, suggestions aimed to improve the quality of the code and the repo organization are more than welcome.