Orchestrating Resilient Blockchain on Kubernetes

One of the newfound fascination within the tech domain for me is Blockchain. Blockchain has become one of the emerging (and disruptive) technology within the recent past. Even at this emerging stage, blockchain provides us with numerous benefits such as immutability, distributed trust, decentralized network, and data security. And because of these properties, the term “Cloud 2.0” has been coined for Blockchain.

Why Kubernetes?

Apart from the advantages blockchains possess; blockchains on traditional infrastructure arise several concerns. One of the major concerns is resiliency, scalability, monitoring and managing the underlying resources of blockchain. The majority of these concerns can be addressed by orchestrating blockchain on Kubernetes. The diagram below depicts blockchain specific features, Kubernetes specific features as well as addons Kubernetes can bring to blockchain infrastructure.

What are we doing here?

In re: Invent 2019, AWS extended AWS Fargate support to Elastic Kubernetes Service (EKS), which undoubtedly can address a major concern i.e. management of underlying machinein a blockchain.

“AWS Fargate removes the need for you to interact with or think about servers or clusters”

However, we will take it step-by-step with the basics here and hence above will be covered in my next article of this series. For this article we will target the following:

  1. Viability of Kubernetes as an orchestrating engine for Blockchain. We will deploy this simple blockchain code on a local running cluster based on minikube.
  2. Exploiting monitoring tools that can help us monitor our blockchain resources as well as identify the issue. For this purpose, we will be using Kubernetes dashboard via Heapster. Heaspter (although deprecated) provides basic metrics that can be integrated with Kubernetes dashboard providing us an overview of resources. For an in-depth analysis of our resources, Grafana will be used which will take us down to the Pod level.

But basics first!

Before we start, we need to know that blockchain infrastructure handles numerous underlying operations. The figure below depicts the most common basic operations using which this simple blockchain code has been developed. In addition to these operations, The code also provides us a basic API in-order to interact with our blockchain.

Let’s get started!

For requirements and deployment steps, simply follow the README of the blockchain source code. Once working on your machine, Postman can help you execute some requests for example:

  1. GET /chain: Returns full blockchain.
  2. POST /chain/new: Creates new transaction. An example request body is as follows:
    {
    "sender": "sender-address",
    "recipient": "recipient-address",
    "amount":"amount-to-be-sent"
    }
  3. GET/chain/mine: Mines and adds the new block to the chain.
  4. GET/nodes/: List the nodes within the blockchain network.
  5. POST /nodes/register: Register new node within the blockchain network. Request body should look like:
    {
    "nodes": ["list-of-nodes-to-register"]
    }
  6. GET /nodes/resolve: Resolve conflicts between the nodes through a simple Consensus algorithm.

At this point, our single Blockchain on Kubernetes works just fine. We can visualize that in Kubernetes dashboard by deploying on our minikube

$> kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml

Once deployed we can see how our cluster is doing. To get more performance metrics and visualization, we will now enable Heapster and Grafana. For sake of simplicity we’ll use the minikube addon:

$ minikube addons enable heapster
# output should be "heapster was successfully enabled"

Below you can see how our cluster is performing at the moment with basic blockchain running along with several kube-system and monitoring services.

Now, let’s create Chaos!

The above graph shows us how stable our current system is. Indeed it looks so beautiful (and indeed, boring!).

Whenever we talk about large-scale, distributed applications like Blockchain; High availability, Scalability, and Resiliency are the points where these platforms get questioned. Even when all the distributed applications are functioning properly in normal circumstances, a simple disruption like failure to handle requests in peak hours or hardware failure can identify weaknesses within the system. This is what we are going to do with this simple setup we have built just now! We will create disruption, identify and evaluate. Addressing it would be part of my next article!

For this article, we can simulate a case of handling load. Using Postman we will send a number for requests and after some time, we get the see that something fails in the below graph:

Finally a disruption! What happened?

This is what we will try to find out in this section. From the Kubernetes dashboard we can find out below that the CPU usage started increasing around 23:26 (yes, an unusual time to get hit!).

To find out more details, we will go to the Grafana dashboard to find out more details about it. Simply execute the command below to get the running services on Kubernetes.

$> kubeclt get svc -A

The list will tell you that Grafana is running on NodePort(a static port) 30002. Access your Grafana default dashboard on http://{MINIKUBE-IP}:30002. Graphs below start telling me some more details of the events that happened around 23:26. Not just our cluster resource usage increased, but our node-level resources also seem to get disrupted.

Now let’s look at the pods level. We are seeing that our blockchain pod is running and it started to get network traffic around 23:28 (almost the same time when we started sending a load of requests).

And after some time, around 23:45 our resources got clogged. Kubernetes Core DNS service stopped responding to our requests.

What is the point of this Chaos?

Resiliency: With this chaos, we stretched our current system to the limits and with the help of Kubernetes the failed running services recovered in almost no time. However, scalability remains the issue since minikube is based on a static resource where already several services and pods are running. This issue will be addressed in my next blog.

Conclusion:

In this article, I took you through a case of orchestrating one of the most disrupting technologies, Blockchain. With the help of simple blockchain source code, we went through the deployment, REST APIs to interact with the blockchain and some monitoring tools. In the end, we disrupted the blockchain by inducing innumerable requests and saw some downtime. Kubernetes recovered the failed services within blockchain; hence increasing the resiliency for the blockchain infrastructure.

Published by backdoorcodr

Passionate about Cloud, Data; and everything that revolves around them!

One thought on “Orchestrating Resilient Blockchain on Kubernetes

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: