Example of a Klever Validator in a Kubernetes Cluster

This article is part of phase #2 of the Klever Validators Program, which comprises a series of challenges in preparation for the upcoming mainnet, giving everyone the opportunity to learn about Klever and earn tokens in the process. Each phase of the testnet will be testing a different aspect of validating and securing the Klever blockchain.

Why Klever?

Klever promises a range of interesting features.

• Full Privacy — No personal information is required, there is no login or sign up
• The all-in-one wallet mobile app for blockchain and cryptocurrency
• No fees — sending and receiving tokens are free
• The user remains in control of his keys instead of having them managed by a centralized authority
• Cross-chain trading with Bitcoin and other popular cryptos

Validator Setup

Running a validator is a long-term commitment and requires a great deal of planning and maintenance. On the one hand, being a validator comes with social responsibilities, like participating in governance and being transparent. On the other hand, validating is highly technical. One must not only ensure high availability for optimal uptime and the highest standards of security when handling keys, but also stay on top of things identifying performance bottlenecks, tweaking configuration parameters and sharing knowledge with other validators.

Kubernetes is one of many ways to simplify the deployment process and the configuration management of a validator node. In the following section, we will be giving you a high-level overview of how such a setup could look like.

First Things First

As described in the official docs “How to run a node”, we need to run the validator in an isolated environment — a docker container. For this, we first need a docker image, a persistent storage for the “node” folder and a monitoring endpoint. Luckily, all of the above is very easy to set up. The code snippet below defines the StatefulSet of a Klever testnet validator.

# Source: klever/templates/statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: klever
  labels:
    helm.sh/chart: klever-1.0.0
    app.kubernetes.io/name: klever
    app.kubernetes.io/instance: klever
    app.kubernetes.io/version: "0.0.5"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: klever
      app.kubernetes.io/instance: klever
  serviceName: klever
  template:
    metadata:
      annotations:
        prometheus.io/path: /node/metrics
        prometheus.io/port: "8080"
        prometheus.io/scrape: "true"
      labels:
        app.kubernetes.io/name: klever
        app.kubernetes.io/instance: klever
        blcs-chain: klever
        blcs-component: validator
    spec:
      serviceAccountName: klever
      securityContext:
        {}
      containers:
        - name: klever
          securityContext:
            {}
          image: "kleverapp/klever-go-testnet:latest"
          imagePullPolicy: Always
          args: [ "--port=10230", "--rest-api-interface=0.0.0.0:8080", "--use-log-view" ]
          volumeMounts:
          - name: data
            subPath: config
            mountPath: /opt/klever-blockchain/config/node
          - name: data
            subPath: db
            mountPath: /opt/klever-blockchain/db
          - name: data
            subPath: logs
            mountPath: /opt/klever-blockchain/logs
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          resources:
            limits:
              cpu: 4
              memory: 8Gi
            requests:
              cpu: 500m
              memory: 512Mi
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: klever

The YAML above can either be deployed in your Kubernetes cluster or tried out locally using minikube. This is, of course, only scratching the surface of the entire setup process as you’ll also need to define the PersistentVolumeClaim, a Service, a ServiceAccount, a VirtualService and a Gateway. Please check out the Istio documentation for more information.

Furthermore, we use helm to simplify the deployment of our software stack, removing the need to deploy every single YAML file individually with kubectl.

Rancher is a great orchestration tool for Kubernetes environments, so you’ll want to check that out too!

Rancher UI of Klever Validator

For monitoring, we recommend Grafana and Prometheus for receiving notifications/alerts. Here’s an example of what it could look like for a validator.

Grafana Klever Testnet Validator Dashboard Example

If you need to manage multiple validators, especially for different chains, Kubernetes is great for scaling and optimizing your resource usage.

To setup a Klever Testnet Validator on a single instance only you should be fine with the docker setup.

We realize that this is by no means a complete guide on how to set up a validator in a Kubernetes environment. With this article, we merely want to give anyone out there who wants to become a validator a little encouragement to learn more about containerized environments and point out some of the benefits. We hope we succeeded in that and you had fun reading it!