¶Digital Reform
There was a vary circumstances from digital governance, industry, manufacture and medicine, and the booming of
new business models has stimulated enterprises to accelerate digital transformation for better company management
and customer service, which further promotes the upgrading and optimization of the Chinese digital economy.
¶Solution - Cloud Native
What’s internet essentially?
移动互联网络应该是
一个异步的由事件流驱动的巨大的状态机
There are many reason that we are migrating business service into Cloud Native. One of most important reason is that we
need to reduce our costs. Furthermore, as our productivity increases, we will have a vision on the IoT service.
the digital reform indicate that in the future, the connected things shall be self-diagnosis, reliable, lower-bandwidth,
low-carbon, more intelligent, and have a better version management.
¶Why Pekko if you have kubernetes?
Kubernetes is not the application layer.
As we know, K8S is covering the cluster orchestration, supporting auto-scaling and resilience on the nodes or the pods
level.
How the auto-scaling and self-healing will be handled within the application instances or node?
Kubernetes will not be able to help with that, another layer such as Pekko need to look after the application
communication, remoting, concurrency & parallel processing, responding to application failure, implementing resilience
design patterns such as bulk-heading and circuit-breakers on the application node level.
Non-function design in Kubernetes is stupid, such like GEO-Red, distributed-lock for business, transactions, entity-id
tracing, overload protect, data desensitization, Monitoring… etc.
In short, Kubernetes is looking after elasticity, auto-scaling and resilience outside the nodes while Pekko and other
reactive application tools are looking after those within the application layer and the nodes.
After all, Kubernetes will not be able to fix a poorly designed application that is prone to failure and lacking
resilience and elasticity.
We need a REAL reactive manifesto application, and below Lightbend diagrams
help with understanding the concept:
So, how to build stateful, resilient and responsive applications in the Cloud?
¶Sharding your X
¶Pekko roles as Kubernetes resource mapping
We use both Kubernetes Statefulset and Deployment. As we can use Statefulset for the seed nodes, mark as role seed
,
and Deployment for scaling out worker nodes, marks role worker
. In this way, we can maintaion stable and ordered DNS
names for the seed nodes, while retain the ability to start multiple Pekko nodes in parallel when scale with
Deployment.
1 | { |
We will setup env from Kubernetes and deliver into application.conf
1 | cluster { |
¶Statefulset for entry -> seeds
especially, mTLS in istio. We will map it for traffic entries as a headless service. And the seed
-ed service won’t
do anything. The resource definition looks like a regular service, but clusterIP set to None:
1 | apiVersion: v1 |
Every Pekko seed node instance in the Statefulset can be addressed via DNS as ${SEED_NODE_NAME}.pekko-seed
.
Then, create Statefulset of seed nodes:
1 | apiVersion: apps/v1beta1 |
First of all, every seed node will have a stable name (e.g. pekko-seed-0, pekko-ssed-1). This name is known as the
Kubernetes pod name. And then use it to construct the addressable DNS name, such as pekko-seed-0.pekko-seed
.
Once deployment the Pekko seed nodes:
1 | kubectl apply -f pekko-seeds.yaml |
We will seed the seeds that were created sequentially:
1 | kubectl get pods |
As mentioned before, the seed nodes won’t do anything, below diagram show it just play the role for traffic transform,
cluster communication and cluster init.
This part is very-very important!! for vary business service, such like coap, diameter protocol based on udp that
Kubernetes doesn’t provide a full-stack support for loadbalancer.
¶Deployment for loadbancer -> workers
Next, deploy the worker nodes using Deployment. It use the Downward API to assign the Pod IP address as te Pekko node’s
hostname.
1 | apiVersion: apps/v1 |
Once deloyed, you can validate that all nodes are up and running:
1 | kubectl get pods |
You can validate that the nodes have joined the cluster by inspecting the logs of any of the Pekko nodes. For
example, to tail the first seed node’s log:
1 | kubect logs -f pekko-seed-0 |
Also, you can simply attach Kubernetes HPA:
1 | apiVersion: autoscaling/v1 |
¶Health check
Pekko already implementation cluster health check management:
1 | management |
¶Summary
Please check my own repo in GitHub, if you need more investigate.