Technical documentation

Here are the relevant details:

Polygon Node Deployment Configuration

This Kubernetes Deployment is designed to deploy Polygon node, a critical component of our blockchain ecosystem. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: polygon-sentry-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: Polygon-Sentry
  template:
    metadata:
      labels:
        app: Polygon-Sentry
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: environment
                operator: In
                values:
                - sentry
      containers:
        - name: heimdall
          image: 0xpolygon/heimdall:1.0.0-beta
          command:
            - heimdalld
            - start
          args:
            - --chain=mumbai
            - --rest-server
            - --home=/var/lib/heimdall
          ports:
            - containerPort: 26656
          volumeMounts:
            - name: heimdall-config-volume
              mountPath: /var/lib/heimdall
        - name: bor
          image: 0xpolygon/bor:1.0.0-beta
          command:
            - bor
            - server
            - --config=/var/lib/bor/config.toml
          ports:
            - containerPort: 30303
          volumeMounts:
            - name: bor-config-volume
              mountPath: /var/lib/bor
        - name: rabbitmq
          image: rabbitmq:3.8
          ports:
            - containerPort: 5672
            - containerPort: 15672
      volumes:
        - name: heimdall-config-volume
          persistentVolumeClaim:
            claimName: heimdall-pvc-sentry
        - name: bor-config-volume
          persistentVolumeClaim:
            claimName: bor-pvc-sentry

Polygon node consists of three main containers:

heimdall Container

The heimdall container is responsible for running the Heimdall node on the Polygon network. Its specific configurations include:

  • Docker Image: 0xpolygon/heimdall:1.0.0-beta

  • Command: Initiates the Heimdall process.

  • Arguments: Specifies various configuration options for Heimdall, such as the chain to connect to (--chain=mumbai), enabling the REST server (--rest-server), and the Heimdall data directory (--home=/var/lib/heimdall).

  • Ports: Exposes port 26656 to establish connections with other nodes for peer-to-peer communication.

  • Volume: Mounts a volume named heimdall-config-volume to store persistent Heimdall data.

Heimdall is critical for transaction validation on the Polygon network, ensuring the security and integrity of the blockchain.

bor Container

The bor container is responsible for running the Bor node on the Polygon network. Its specific configurations include:

  • Docker Image: 0xpolygon/bor:1.0.0-beta

  • Command: Starts the Bor server.

  • Arguments: Specifies the path to the Bor configuration file (--config=/var/lib/bor/config.toml).

  • Volume: Mounts a volume named bor-config-volume to store persistent Bor configuration data.

Bor plays a crucial role in the Polygon network, handling the consensus layer and transaction validation.

rabbitmq Container

The rabbitmq container uses the official RabbitMQ image and is responsible for providing a messaging infrastructure for internal system communication. Its specific configurations include:

  • Docker Image: rabbitmq:3.8

  • Ports: Exposes ports 5672 and 15672 for communication with services that require messaging.

RabbitMQ is a fundamental part of our system, enabling asynchronous communication between components for coordination and information exchange.

This Deployment is part of a broader infrastructure that supports the secure and efficient operation of our Polygon network.

Persistent Volumes (PVs) e Persistent Volume Claims (PVCs)

These PVs and PVCs play a crucial role in ensuring data persistence and storage management for these components within the Kubernetes cluster. 

# PV e PVC para Heimdall
apiVersion: v1
kind: PersistentVolume
metadata:
  name: heimdall-pv-sentry
  labels:
    app: Polygon-Sentry
spec:
  capacity:
    storage: 150Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /var/lib/heimdall

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: heimdall-pvc-sentry
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 150Gi
  storageClassName: standard
  selector:
    matchLabels:
      app: Polygon-Sentry

---
# PV e PVC para Bor
apiVersion: v1
kind: PersistentVolume
metadata:
  name: bor-pv-sentry
  labels:
    app: Polygon-Sentry
spec:
  capacity:
    storage: 600Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /var/lib/bor

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bor-pvc-sentry
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 600Gi
  storageClassName: standard
  selector:
    matchLabels:
      app: Polygon-Sentry

Let's break down their purposes and significance:

PV and PVC for Heimdall

heimdall-pv-sentry Persistent Volume (PV):

  • Purpose: This PV is intended to provide a persistent storage solution for the Heimdall component of Polygon node.

  • Configuration Highlights:

    • Capacity: 150 gigabytes of storage (storage: 150Gi).

    • Access Mode: ReadWriteOnce, allowing read and write access by a single node at a time.

    • Reclaim Policy: Retain, which means that even after the PVC is deleted, the data in the PV will be retained.

    • Storage Class: Uses the standard storage class.

    • Host Path: Maps to the host machine's /var/lib/heimdall directory, ensuring data persistence.

heimdall-pvc-sentry Persistent Volume Claim (PVC):

  • Purpose: The PVC is a request for storage resources that will be bound to the heimdall-pv-sentry PV. It allows Heimdall to access and use the specified storage capacity.

  • Configuration Highlights:

    • Access Mode: ReadWriteOnce, ensuring that only one node can use the storage at a time.

    • Requested Storage: Requests 150 gigabytes of storage (storage: 150Gi).

    • Storage Class: Uses the standard storage class.

    • Selector: Matches labels with the app: Polygon-Sentry label to associate this PVC with the Polygon node application.

PV and PVC for Bor

bor-pv-sentry Persistent Volume (PV):

  • Purpose: This PV is designed to offer persistent storage for the Bor component of Polygon node.

  • Configuration Highlights:

    • Capacity: 600 gigabytes of storage (storage: 600Gi).

    • Access Mode: ReadWriteOnce, allowing a single node to read and write data.

    • Reclaim Policy: Retain, ensuring data retention even after PVC deletion.

    • Storage Class: Utilizes the standard storage class.

    • Host Path: Mapped to the host machine's /var/lib/bor directory to maintain data persistence.

bor-pvc-sentry Persistent Volume Claim (PVC):

  • Purpose: The PVC represents a request for storage resources bound to the bor-pv-sentry PV. It facilitates Bor's access to the specified storage capacity.

  • Configuration Highlights:

    • Access Mode: ReadWriteOnce, allowing exclusive access by one node.

    • Requested Storage: Requests 600 gigabytes of storage (storage: 600Gi).

    • Storage Class: Utilizes the standard storage class.

    • Selector: Matches labels with the app: Polygon-Sentry label to associate this PVC with the Polygon node application.

In summary, these PVs and PVCs are essential for Polygon node's data storage needs. They ensure that Heimdall and Bor have access to the required storage capacity while maintaining data integrity and persistence, which are crucial for the reliable operation of our blockchain ecosystem.

PreviousKubernetesNextcontrol pane cluster

Last updated