Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Kotal is an open source alternative to centralized API gateway, Node as a service, and Staking service providers. Like Infura in Ethereum ecosystem, Onfinality in Polkadot ecosystem, and Hiro in Stacks ecosystem.
Kotal is multi-client, protocol-agnostic, and cloud-agnostic Blockchain Kubernetes Operator that makes it easy to deploy highly-available self-managing self-healing blockchain infrastructure on any cloud.
Kotal has been tested on Amazon Web Service, Google Cloud Platform, Microsoft Azure, DigitalOcean, Alibab Cloud, Tencent cloud 🤯.
Deploy nodes across 10 Blockchain protocols (Aptos, Bitcoin, Chainkstack, Ethereum, Filecoin, IPFS, NEAR, Polkadot, Stacks)
Upgrade and Downgrade node client software
Load validator keys and start producing blocks
Manage storage and resources (CPU & Memory) allocated to the node
Manage Secrets (private keys, passwords, tokens, certificates)
Monitor resources utilization
Fetch real time logs
Create TLS-secure API endpoints
View API endpoints usage
Create workspaces of nodes and resources
Invite members to workspaces and assign roles
Kubernetes cluster
Cert Manager
For development and testing purposes we recommend using kind (Kubernetes in Docker), it's an easy way to create and tear down kubernetes clusters in seconds. For staging and production purposes you can use any public cloud kubernetes as a service like Amazon EKS, Azure AKS or Google GKE.
kind installation guide can be found here.
Cert Manager is a native Kubernetes certificate management controller. It can help with issuing certificates from a variety of sources, such as Let’s Encrypt, HashiCorp Vault, a simple signing key pair, or self-signed. It will ensure certificates are valid and up to date, and attempt to renew certificates at a configured time before expiry.
Kotal webhook component uses cert-manager for issuing certificates to default and validate your Blockchain resources such as nodes, beacon nodes, ipfs peers ... etc.
cert-manager installation guide can be found here.
The latest version of Kotal operator v0.3.0 can be installed into your Kubernetes cluster simply by:
Create rinkeby.yaml manifest that describes an Ethereum node which uses go-ethereum client, connecting to rinkeby network, and enabling JSON-RPC server:
Deploy the node using kubectl:
Within a couple of seconds, the node will be up and running. You can get the node using:
It will return an output similar to the following:
Kotal will create all the necessary pods, volumes, services for the node. Get the pods by:
It will return an output similar to the following:
Finally delete the node by:
Congratulations!
You can support us by donating Eth or any token to our ENS address farghaly.eth or directly to the following Ethereum address:
Thank you!
We've extended Kubernetes with Node custom resource which can be used to deploy Bitcoin nodes from the given spec.
Node is Bitcoin node using Bitcoin Core client, connecting to and syncing a specific chain.
For all the fields associated with the Node API resource:
Full Bitcoin node reference is documented here.
Bitcoin nodes that enable JSON-RPC server are required to use basic authentication while calling JSON-RPC methods.
Apply rpc-user-password.yaml to create the password secret:
Apply bitcoin.yaml manifest:
Kotal operator will notice your bitcoin-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed Bitcoin Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
It will return node logs similar to the following:
By default, Bitcoin node JSON-RPC server port is 8332, which can be changed using rpcPort.
Forward localhost:8332 calls to the node pod:
In another terminal window call getblockhash JSON-RPC method to get the genesis block hash:
You will get JSON result similar to the following:
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Bitcoin Node controller.
The following manifest describes a Bitcoin node that syncs Bitcoin mainnet network: mainnet, enables HTTP JSON-RPC server rpc: true, defines JSON-RPC user credentials rpcUsers: ... and uses client:
Rinkeby is a Proof of Authority public Ethereum test network, used by developers to test their dApps.
The following manifest describes an Ethereum node that joins rinkeby network network: rinkeby, and uses Hyperledger Besu client client: besu:
Apply rinkeby.yaml manifest:
Kotal operator will notice your rinkeby-besu-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed Ethereum Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
Let's update our node by enabling JSON-RPC HTTP server:
Apply the new version of rinkeby.yaml:
Forward localhost:8545 calls to the node pod:
In another terminal window call eth_syncing JSON-RPC method
You will get JSON result similar to the following:
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Ethereum Node controller.
In this tutorial we will use the following private keys and their corresponding addresses.
DON'T use these keys in production.
0xbAa5f05af4A67A467cEcA89085f162aFb4206Aaa
fb5411342ae51291447515c89bcf6a057e3dbd0b51e060c45cb73406c38f851d
0xc1381ED43B327e3C7A1ADb21285f1e9cB82Bc00d
153b174f5e9948ae4678baed54f88244cc9c39d56b9f17ecef93d7ede633f56b
0x7DE985E2f878c83C4e91b6B1312c0f63A56C844a
89b03c4de62d61be16d22e09c8a48929a9bccd11fa6b37809cfef290292bcba3
Let's describe an Ethereum Node that uses a custom genesis block to join a private Proof of Authority network using Clique consensus configuration in the genesis block.
In this node, we're using Hyperledger besu client client: besu, enabling JSON-RPC server rpc: true so we can query number of peers later in this tutorial, and we're loading the node private key from Kubernetes secretd called besu-clique-nodekey.
The node private key will give the node a unique identity and node URL, and will allow the node to generate blocks, because the address 0xbAa5f05af4A67A467cEcA89085f162aFb4206Aaa that's corresponding to the node private key is in the initial block signers.
We're defining a genesis block that uses the value 4444 as network and chain identifier, and we start the chain with 3 signers as defined by spec.genesis.clique.signers.
This node private key secret can be created by:
Let's deploy the node:
Kotal operator will notice your besu-clique-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
Let's deploy another go-ethereum node, and connect it to the previous node in our private proof of authority network.
In this node, we're using go-ethereum client client: geth, starting the PoA consensus engine miner: true, setting the second address in the genesis signers list spec.genesis.clique.signers as the coinbase coinbase: "0xc1381ED43B327e3C7A1ADb21285f1e9cB82Bc00d", and loading the signer account private key and password from kubernetes secrets privateKeySecretName: ... and passwordSecretName: .... We're connecting to the first node using staticNodes option which accepts Node name or enode url.
You can create the private key and password secrets using:
Deploy the second node using:
Kotal operator will notice your second geth-clique-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum Nodes using:
It will return an output similar to the following:
net_peerCountGet the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Forward localhost:8545 calls to the node pod:
In another terminal window call net_peerCount JSON-RPC method
You will get JSON result similar to the following:
Deploy a third node that uses Nethermind client, and signing blocks using the third key in the signers list spec.genesis.clique.signers. Nethermind client is similar to geth, you will import signer account private key and password from kubernetes secrets, and use the same genesis as the other nodes.
Finally you can delete all the nodes by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Ethereum Node controller.
We've extended Kubernetes with Node custom resource which can be used to deploy Ethereum nodes from the given spec.
Using Ethereum Node custom resource, you can describe any public or private network node you want, and Kotal will create all the necessary Kubernetes resources like pods, persistent volumes, services, configmaps, and secrets for you.
If you want to get all the deployted ethereum Node(s):
Which will report node name, client, network, and consensus.
If you want to get all the fields associated with ethereum Node:
Kotal supports the following Ethereum 1 clients:
For a comprehensive reference on Ethereum Node, check our
Support for OpenEthereum (parity) client has been deprecated. OpenEthereum team is working with Erigon on a smooth transition path for users. More information can be found
In this tutorial we will use the following private keys and their corresponding addresses.
DON'T use these keys in production.
0xbAa5f05af4A67A467cEcA89085f162aFb4206Aaa
fb5411342ae51291447515c89bcf6a057e3dbd0b51e060c45cb73406c38f851d
0xc1381ED43B327e3C7A1ADb21285f1e9cB82Bc00d
153b174f5e9948ae4678baed54f88244cc9c39d56b9f17ecef93d7ede633f56b
0x7DE985E2f878c83C4e91b6B1312c0f63A56C844a
89b03c4de62d61be16d22e09c8a48929a9bccd11fa6b37809cfef290292bcba3
Let's describe an Ethereum Node that uses a custom genesis block to join a private Proof of Work network using Ethash consensus configuration in the genesis block.
In this node, we're using Hyperledger besu client client: besu, enabling JSON-RPC server rpc: true so we can query number of peers later in this tutorial, turning on Proof of Work mining miner: true, setting the address that will collect block reward using coinbase, and we're loading the node private key from Kubernetes secretd called besu-ethash-nodekey, this is the private from which the coinbase address is derived.
We're defining a genesis block that uses the value 4444 as network and chain identifier, and used ethash proof of work consensus engine.
This node private key secret can be created by:
Let's deploy the node:
Kotal operator will notice your besu-ethash-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
Let's deploy another go-ethereum node, and connect it to the previous node in our private proof of work network.
In this node, we're using go-ethereum client client: geth, turning on Proof of Work mining miner: true, setting the address that will collect block reward using coinbase, and loading the miner account private key and password from kubernetes secrets privateKeySecretName: ... and passwordSecretName: .... We're connecting to the first node using staticNodes option which accepts Node name or enode url.
You can create the private key and password secrets using:
Deploy the second node using:
Kotal operator will notice your second geth-ethash-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum Nodes using:
It will return an output similar to the following:
net_peerCountGet the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Forward localhost:8545 calls to the node pod:
In another terminal window call net_peerCount JSON-RPC method
You will get JSON result similar to the following:
Deploy a third node that uses Nethermind client, and use the third private key and address from the table above. Nethermind client is similar to geth, you will import signer account private key and password from kubernetes secrets, and use the same genesis as the other nodes.
Finally you can delete all the nodes by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Ethereum Node controller.
We've extended Kubernetes with BeaconNode and Validator custom resources which can be used to deploy Ethereum 2.0 beacon nodes and validator clients from the given spec.
BeaconNode is Ethereum 2.0 beacon node -optionally- connecting to Ethereum 1 endpoint and syncing the beacon chain.
Here's an example of ConsenSys Teku beacon node BeaconNode syncing mainnet beacon chain, connecting to Ethereum 1 JSON RPC endpoint, enabling REST API server which is listening at port 8888:
For all the fields associated with the BeaconNode API resource:
Validator is Ethereum 2.0 validator client connecting to beacon node endpoint and validating blocks using the loaded keystores.
Here's an example of ConsenSys Teku validator client connecting to beacon node endpoint, validating pyrmont blocks using 1 loaded validator keystore from its secret:
For all the fields associated with the Validator API resource:
Kotal supports the following Ethereum 2.0 beacon node and validator clients:
Setting validator or beacon node client is as simple as changing the spec.client to the desired client.
We've extended Kubernetes with Node custom resource which can be used to deploy Chainlink nodes from the given spec.
Using Chainlink Node custom resource, you can describe any chainlink node, connect to EVM chain node, add jobs and satisfy requests, and Kotal will create all the necessary Kubernetes resources like pods, persistent volumes, services, configmaps, and secrets for you.
If you want to get all the deployted chainlink Node(s):
Which will report node name, client, Ethereum chain ID, and Link contract address.
If you want to get all the fields associated with chainlink Node:
Let's deploy the beacon node:
Kotal operator will notice your teku-beacon-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum 2.0 BeaconNode using:
It will return an output similar to the following:
Get the pods created for the beacon node:
It will return an output similar to the following:
Get the logs of the running beacon node:
/eth/v1/beacon/genesis REST APIGet the service created for the beacon node:
It will return an output similar to the following:
Forward the localhost:8888 calls to the beacon node
In another terminal window, send REST API call to get chain genesis details:
You'll get a result similar to the following:
Finally delete the beacon node:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Ethereum 2.0 BeaconNode controller.
Full beacon node reference is documented .
Full validator client reference is documented .
by ConsenSys.
by Sigma Prime.
by Prysmatic Labs.
by Status.im.
For a comprehensive reference on Chainlink Node, check our
The Beacon Chain is the coordination mechanism of the new network, responsible for creating new blocks, making sure those new blocks are valid, and rewarding validators with ETH for keeping the network secure.
In this beacon node, we're using ConsenSys Teku Ethereum 2.0 client client: teku, and syncing the pyrmont network beacon chain network: pyrmont. We also enable REST API server rest: true at port 8888 restPort: 8888. We're connecting to Ethereum 1 endpoint eth1Endpoints: .... Check Ethereum on how to deploy an Ethereum node.
In this tutorial we will use the following private keys and their corresponding addresses.
DON'T use these keys in production.
0xbAa5f05af4A67A467cEcA89085f162aFb4206Aaa
fb5411342ae51291447515c89bcf6a057e3dbd0b51e060c45cb73406c38f851d
0xc1381ED43B327e3C7A1ADb21285f1e9cB82Bc00d
153b174f5e9948ae4678baed54f88244cc9c39d56b9f17ecef93d7ede633f56b
0x7DE985E2f878c83C4e91b6B1312c0f63A56C844a
89b03c4de62d61be16d22e09c8a48929a9bccd11fa6b37809cfef290292bcba3
Let's describe an Ethereum Node that uses a custom genesis block to join a private Proof of Authority network using ibft2 consensus configuration in the genesis block.
In this node, we're using Hyperledger besu client client: besu, enabling JSON-RPC server rpc: true so we can query number of peers later in this tutorial, and we're loading the node private key from Kubernetes secretd called besu-ibft2-nodekey.
The node private key will give the node a unique identity and node URL, and will allow the node to generate blocks, because the address 0xbAa5f05af4A67A467cEcA89085f162aFb4206Aaa that's corresponding to the node private key is in the initial block validators.
We're defining a genesis block that uses the value 4444 as network and chain identifier, and we start the chain with 3 validators as defined by spec.genesis.ibft2.validators.
This node private key secret can be created by:
Let's deploy the node:
Kotal operator will notice your besu-ibft2-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
Let's deploy another go-ethereum node, and connect it to the previous node in our private proof of authority network.
In this node, we're using go-ethereum client client: geth, starting the PoA consensus engine miner: true, setting the second address in the genesis validators list spec.genesis.ibft2.validators as the coinbase coinbase: "0xc1381ED43B327e3C7A1ADb21285f1e9cB82Bc00d", and loading the validator account private key and password from kubernetes secrets privateKeySecretName: ... and passwordSecretName: .... We're connecting to the first node using staticNodes option which accepts Node name or enode url.
You can create the private key and password secrets using:
Deploy the second node using:
Kotal operator will notice your second geth-ibft2-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum Nodes using:
It will return an output similar to the following:
net_peerCountGet the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Forward localhost:8545 calls to the node pod:
In another terminal window call net_peerCount JSON-RPC method
You will get JSON result similar to the following:
Deploy a third node that uses Nethermind client, and signing blocks using the third key in the validators list spec.genesis.ibft2.validators. Nethermind client is similar to geth, you will import validator account private key and password from kubernetes secrets, and use the same genesis as the other nodes.
Finally you can delete all the nodes by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Ethereum Node controller.
Node is NEAR node using client, connecting to and syncing a specific chain, and optionally validating blocks.
Full NEAR node reference is documented .
The following manifest describes a NEAR node that syncs NEAR mainnet network: mainnet, enables HTTP JSON-RPC server rpc: true and uses NEAR Core client:
Apply near.yaml manifest:
Kotal operator will notice your near-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed NEAR Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
It will return node logs similar to the following:
By default, NEAR node JSON-RPC server port is 3030, which can be changed using rpcPort.
Forward localhost:3030 calls to the node pod:
In another terminal window call status JSON-RPC method to get the general status of our node (sync status, nearcore node version, protocol version) and the current set of validators:
You will get JSON result similar to the following:
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal NEAR Node controller.
Staking is the act of depositing 32 ETH to activate validator software. As a validator you’ll be responsible for storing data, processing transactions, and adding new blocks to the blockchain. This will keep Ethereum secure for everyone and earn you new ETH in the process. This process, known as proof-of-stake, is being introduced by the Beacon Chain. source
In this validator client, we're using ConsenSys Teku Ethereum 2.0 client client: teku, validating pyrmont network blockchain network: pyrmont, connecting to beacon node endpoint using beaconEndpoints: ..., setting the graffiti text to include in the propsed blocks graffiti: validated by Kotal, and loading a validator keystore using keystores: ... from a kubernetes secret called my-validator.
The keystores loaded using spec.keystores[].secretName from kubernetes secret, must contain two data keys:
keystore key hodling the BLS12-381 keystore JSON file
password key holding the encryption key of the keystore.
Let's deploy the validator client:
Kotal operator will notice your teku-validator and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed Ethereum 2.0 Validator using:
It will return an output similar to the following:
Get the pods created for the validator client:
It will return an output similar to the following:
Get the logs of the running validator pod:
You'll get an output similar to the following:
Finally delete the validator client:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Ethereum 2.0 Validator controller.
Polkadot is a sharded protocol that enables blockchain networks to operate together seamlessly. Polkadot is a 100% open-source project created to enable a decentralized web and better society.
We've extended Kubernetes with Node custom resource which can be used to Polkadot, Kusama, Rococo, and substrate-based chains from the given spec.
Node is Polkadot node using parity polkadot client, connecting to and syncing a specific chain, and optionally validating blocks.
For all the fields associated with the Node API resource:
Full polkadot node reference is documented here.
In this tutorial, we will learn how to deploy a NEAR validator node, and load a validator key into it.
Generate validator account using NEAR CLI tool. Which can be installed using:
Validator account must have the name validator.
An ed25519 private key will be generated and saved in current user home directory under .near-credentials/testnet
It will return an output similar to the following
Change private_key field to secret_key.
Create a Kubernetes secret from the generated private key in the previous step:
The following manifest describes a NEAR node that syncs NEAR testnet network: testnet, enables HTTP JSON-RPC server rpc: true, loads validator key from the Kubernetes secret that we've created in the previous step, and uses NEAR Core client:
Apply near.yaml manifest:
Kotal operator will notice your near-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed NEAR Node using:
It will return an output similar to the following:
Note that validator is true in the prevous output 😇
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
It will return node logs similar to the following:
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal NEAR Node controller.
Chainlink node requires access to an EVM chain node with WebSocket server enabled. Here's how to deploy a simple Ethereum Rinkeby node with WebSocket server enabled:
After deploying this node, it can be accessed in-cluster using ws://besu-rinkeby-node:8546 🔥. Read Ethereum guide for more details on how to deploy public and private network nodes.
Chainlink requires access to PostgreSQL database instance.
You can use a hosted database a service to obtain PostgreSQL database:
You can also deploy your own PostgreSQL database instance from official PostgreSQL docker image.
Chainlink node requires a strong password for securing access to keystore (wallet) and API. We will store this password in Kubernetes secret my-password:
Chainlink optionally requires TLS certificate to secure access to the node API. Using cert-manager we can issue a simple self-signed certificate and store it in a Kubernetes secret:
With access to Ethereum Rinkeby node, PostgreSQL database, tls certificate and a strong password. We're ready to deploy our Chainlink node to create jobs and satisfy requests:
In this manifest, we're describing Chainlink node that connects to Ethereum Rinkeby node using ethereumWsEndpoint, setting ethereum chain ID using ethereumChainId, setting link contract address using linkContractAddress, connecting to postgress database instance using databaseURL, setting wallet password using keystorePasswordSecretName which accepts a name of k8s secret, setting tls configuration using certSecretName which accepts k8s secret name that holds tls.key and tls.crt, and finally setting API credentials using apiCredentials.
Apply chainlink.yaml manifest:
Kotal operator will notice your chainlink-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed Chainlink Node using:
It will return an output similar to the following:
If you added -o wide it will return more info like link contract address
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
Chainlink node comes with a user interface for managing the node, and it's being served by default on port 6688.
Forward localhost:6688 calls to the node pod:
Open https://localhost:6688 and it will take you to Chainlink node UI. It will ask you for API credentials. Enter the email address in your node's .spec.apiCredentials.email, and in the password field, enter fE2xXKDnR3ns489X.
🔥🔥🔥
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Chainlink Node controller.
IPFS is a distributed system for storing and accessing files, websites, applications, and data.
We've extended Kubernetes with Peer and ClusterPeer custom resources which can be used to deploy IPFS peers, swarms, and clusters from the given spec.
Peer is an ipfs peer running go-ipfs client and connecting to the public ipfs swarm or a private swarm secured by swarm key. Here's an example of a very basic ipfs peer connecting to the public ipfs swarm.
For all the fields associated with the Peer API resource:
Full ipfs peer reference is documented here.
ClusterPeer is an ipfs cluster peer running ipfs-cluster-service client, connecting to ipfs peer and optional bootstrap cluster peer(s). ClusterPeers provide data orchestration across a swarm of IPFS daemons by allocating, replicating and tracking a global pinset distributed among multiple peers. Here's an example of cluster peer connecting to ipfs peer.
For all the fields associated with the ClusterPeer API resource:
Full ipfs cluster peer reference is documented here.
The following manifest describes Kusama node that syncs Kusama relay chain network: kusama, in archive mode pruning: false, and uses Parity Polkadot client:
Apply kusama.yaml manifest:
Kotal operator will notice your kusama-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed Polkadot Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
It will return node logs similar to the following:
Once the node is fully synced, enable validator by updating the node with validator: true:
Apply the updated kusama.yaml Node manifest:
Fetch the deployed Polkadot Node using:
It will return an output similar to the following:
Note that validator has changed from false to true.
The remainig steps in setting up a validator are:
Bonding KSM
Generating Session Keys
Setting Session Keys by signing and submitting an extrinsic
Relax 🏝️
These steps are documented in Polkadot Wiki.
We will cover next how to generate a session key.
Validator nodes can't enable external HTTP or WS JSON-RPC servers.
Session key can be generated by calling author_rotateKeys JSON-RPC method.
Forward localhost:9933 calls to the node pod because rpcPort: 9933:
In another terminal window call author_rotateKeys JSON-RPC method to get a new session key:
You will get JSON result similar to the following:
You can set the sesison key as documented in Polkadot Wiki.
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Polkadot Node controller.
This is a simple ipfs peer that joins the public ipfs swarm, and will starts with the all default settings that's similar to running ipfs init then ipfs daemon on your machine.
Let's deploy the peer:
Kotal operator will notice your simple-peer and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
It will return an output similar to the following:
Get the pods created for the peer:
It will return an output similar to the following:
Check the logs of the running peer:
You'll get output similar to the following:
Your peer is up and running and ready to receive api calls.
Let's forward localhost:5001 calls to simple-peer:5001
In another terminal window, send http api call using cURL:
You'll get the following output:
You can also view ipfs webui by visiting http://0.0.0.0:5001/webui
Finally, delete the ipfs peer:
Kubernetes garbage collector will delete all the resources that has been created by Kotal IPFS Peer controller.
Make sure Bitcoin node is fully synced before deploying your Stacks node.
Let's store Stacks Foundation Bitcoin node JSON-RPC password in a Kubernetes secret to be used by our node:
Apply bitcoin-node-rpc-password.yaml to create the password secret:
The following manifest describes a Stacks node that syncs Stacks mainnet network: mainnet, and connects to the bitcoin node using configurations in bitcoinNode: ... for Proof of Transfer:
Apply stacks.yaml manifest:
Kotal operator will notice your stacks-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed Stacks Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
It will return node logs similar to the following:
By default, Stacks node JSON-RPC server port is 20443, which can be changed using rpcPort.
Forward localhost:20443 calls to the node pod:
HTTP server will start after Bitcoin headers sync, till then you will get the following error if you tried to send JSON-RPC calls:
In another terminal window call info JSON-RPC method to retrieve information about the Core API including the server version:
You will get JSON result similar to the following:
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Stacks Node controller.
Stacks node requires a Bitcoin node to connect to on the back-end for . You can deploy a Bitcoin node using Kotal operator like we did in this . In this tutorial, we will be using Bitcoin node hosted by Stacks Foundation.
We've extended Kubernetes with Node custom resource which can be used to create Filecoin nodes across different filecoin networks like Mainnet or calibration using lotus client from a given spec.
Here's an example of a Filecoin node that syncs calibration chain:
For all the fields associated with the Node API resource:
Full filecoin node reference is documented here.
This is a simple filecoin Node that joins calibration test network.
Let's deploy the node:
Kotal operator will notice your calibration-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
It will return an output similar to the following:
Get the pods created for the node:
It will return an output similar to the following:
Check the logs of the running node:
Finally you can delete the filecoin node and all its resources by
and kubernetes garbage collector will delete all resources created by the node controller.
We've extended Kubernetes with Node custom resource which can be used to deploy Stacks rpc and miner nodes from the given spec.
Node is Stacks node using Stacks Blockchain Node client, connecting to and syncing a specific chain, optionally mining or exposing JSON-RPC server to be used by clients.
For all the fields associated with the Node API resource:
Full Stacks node reference is documented here.
IPFS Cluster provides data orchestration across a swarm of IPFS daemons by allocating, replicating and tracking a global pinset distributed among multiple peers. Source
Before we start, you need to:
Deploy an ipfs peer Peer because it's required by ClusterPeer. Check our Deploy IPFS Peer tutorial.
Create a cluster secret which secures access to the cluster:
Cluster secret must be 32-byte hex-encoded (64 characters) without the leading 0x. It must be hold in data field called secret in the Kubernetes secret.
Create cluster peer ID and private key using ipfs-key
It will return an output similar to the following:
create Kubernetes secret from the generated private key in step(3) above.
Now we're ready to deploy the cluster peer and connect it to the peer we've deployed in step(1)
Let's deploy cluster peer manifest file:
Kotal operator will notice your cluster-peer and will create all the necessary pods, persistent volumes, services, configmaps, and secrets.
You can fetch the deployed IPFS ClusterPeer using:
It will return an output similar to the following:
Get the pods created for our cluster peer:
It will return an output similar to the following:
Check the logs of the running cluster peer:
It will return an output similar to the following:
As you can see from the logs that our cluster peer is up and running as indicated by the healthy logs IPFS Cluster is READY.
Let's add some content to the pinset by executing commands inside cluster peer container:
Let's fetch the pinset of the ipfs peer by executing commands inside peer -created in step(1)- container:
As you can see, content pinned by the cluster peer, has been added to the pinset of the ipfs peer and available in its local storage.
The only prerequisite to the second cluster peer is to:
Deploy an ipfs peer Peer, and name it peer-sample-two. Check our Deploy IPFS Peer tutorial.
We will reuse cluster secret that was generated in step(2) during deploying first cluster peer above.
Deploying this cluster manifest will deploy a cluster peer that connects to the first cluster peer and will connect to its own ipfs peer peer-sample-two instance.
You can fetch the deployed cluster peers by:
It will return an output similar to the following:
Get the pods created by our cluster peer:
It will return an output similar to the following:
Check the logs of cluster peer two:
It will return an output similar to the following:
As you can see cluster peer two is up and running as indicated by the healthy logs and IPFS Cluster is READY.
Cluster peer two has joined the first cluster peer as indicated by the highlighted log line joined 12D...uiq's cluster
Finally, delete all peers and cluster peers:
Kubernetes garbage collector will delete all the resources that has been created by Kotal IPFS Peer and ClusterPeer controllers.
Stacks node requires a Bitcoin node to connect to on the back-end for Proof of Transfer. You can deploy a Bitcoin node using Kotal operator like we did in this guide. In this tutorial, we will be using Bitcoin node hosted by Stacks Foundation.
Make sure Bitcoin node is fully synced before deploying your Stacks node.
Don't use the following Miner private key in production!
Generate Key chain using Stacks CLI tool. Stacks CLI can be installed using:
Generate key chain using:
It will return an output similar to the following
Store privateKey from the output above into a Kubernetes secret in data field called key:
Let's store Stacks Foundation Bitcoin node JSON-RPC password in a Kubernetes secret to be used by our node:
Apply bitcoin-node-rpc-password.yaml to create the password secret:
The following manifest describes a Stacks node that syncs Stacks mainnet network: mainnet, and connects to the bitcoin node using configurations in bitcoinNode: ... for Proof of Transfer, and loading miner private key using seedPrivateKeySecretName:
Apply stacks.yaml manifest:
Kotal operator will notice your stacks-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed Stacks Node using:
It will return an output similar to the following:
Note Miner is true in the previous output 🔥
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
It will return node logs similar to the following:
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Stacks Node controller.
network is Bitcoin network to join and sync. Possible values are mainnet and testnet.
network is immutable, can't be changed after node is created.
p2pPort is p2p communications port.
p2pHost is p2p communications host.
rpc enables JSON-RPC server.
rpcPort is JSON-RPC server port.
rpcHost is JSON-RPC server host.
rpcUsers is a list of JSON-RPC users credentials:
wallet loads local wallet and enables wallet RPC calls.
txIndex maintains a full transaction index.
resources allocates compute and storage resources to the node.
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1), 1500m, 2, and 4.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
Apply polkadot.yaml manifest:
Kotal operator will notice your polkadot-node and will create all the necessary pods, persistent volumes, services, configmaps, and secrets neccessary.
You can fetch the deployed Polkadot Node using:
It will return an output similar to the following:
Get the pods that has been created by Kotal for the node:
It will return an output similar to the following:
Get the logs of the running node:
It will return node logs similar to the following:
Forward localhost:8888 calls to the node pod because rpcPort: 8888:
In another terminal window call eth_getBlock JSON-RPC method to get the latest synced block:
You will get JSON result similar to the following:
Finally you can delete the node by:
Kubernetes garbage collector will delete all the resources that has been created by Kotal Polkadot Node controller.
The following manifest describes a Polkadot node that syncs Polkadot relay chain network: polkadot, enables HTTP JSON-RPC server rpc: true on custom port rpcPort: 8888, and uses client:
network required
string
Bitcoin network to join and sync
number
p2p communications port
8333 for mainnet, 18333 for testnet
string
p2p communication host
0.0.0.0
boolean
Enables JSON-RPC server
false
number
JSON-RPC server port
8332 for mainnet, 18332 for testnet
string
JSON-RPC server host
0.0.0.0
array
JSON-RPC users credentials
boolean
Load local wallet and enables wallet RPC calls
false
boolean
Maintains a full transaction index
false
object
node compute and storage resources to alloacte
username
string
JSON-RPC user name
passwordSecretName
string
Kubernetes secret name holding JSON-RPC user password
cpu
string
number of cpu cores this node requires
2
cpuLimit
string
number of cpu cores this node is limited to
4
memory
string
memory this node requires
4Gi
memoryLimit
string
memory this node is limited to
8Gi
storage
string
disk space this node requires
100Gi
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
string
Polkadot node client image
last stable and tested client
array
Extra arguments to pass down to the node client
number
number of replicas
1
string
polkadot network/chain to join and sync
string
p2p protocol tcp port
30333
string
Kubernetes secret name holding node Ed25519 private key
boolean
enables validator
false
string
blockchain synchronization mode
full
boolean
whether to keep only recent or all blocks
false
number
number of blocks to keep state for
256
string
database backend
auto
string
logging verboisty level
info
boolean
enables connecting to telemetry server
false
string
telemetry service URL
wss://telemetry.polkadot.io/submit/ 0
string
exposes prometheus exporter endpoint
false
number
prometheus exporter port
9615
boolean
enables JSON-RPC server
false
number
JSON-RPC server port
9933
boolean
enables Websocket server
false
number
Websocket server port
9944
array
browser origins allowed to access the JSON-RPC HTTP and WS servers
all
object
node compute and storage resources to alloacte
image is polkadot node client image. Kotal dashboard uses image information published here.
extraArgs are extra arguments to pass down to the node client. This can be useful if kotal doesn't support something you're inttersted in.
replicas is number of replicas. Accepted values are 0 and 1 only.
network is the polkadot network/chain to join and sync. Possible values are polkadot, kusama, rococo, westend and other chains supported by Parity Polkadot client.
p2pPort is p2p protocol tcp port.
nodePrivateKeySecretName is Kubernetes secret name holding node Ed25519 private key in data field called key.
Node private can be generated using subkey tool from Parity Substrate.
Create node private key secret:
polkadot-node-key secret can be used in your polkadot Node by updating .spec with nodePrivateKeySecretName: polkadot-node-key.
validator enables validator.
Node must sync blocks in archive mode pruning: false if validator is enabled.
syncMode is blockchain synchronization mode. Available values are fast and full.
pruning controls whether to keep only recent or all blocks. Setting pruning to false runs the node in archive mode.
retainedBlocks is the number of blocks to keep state for. It's only considered if .spec.pruning is set to true.
database is database backend. Possible values are auto, paritydb or rocksdb.
logging is logging verboisty level. Available logging levels are error, warn, info, debug, and trace.
telemetry enables connecting to telemetry server.
telemetryURL is telemetry service URL. It's only considered if .spec.telemetry is set to true.
prometheus exposes prometheus exporter endpoint.
prometheusPort is prometheus exporter port
rpc enables JSON-RPC server.
rpcPort is JSON-RPC server port.
ws enables Websocket server.
wsPort is Websocket server port.
corsDomains is browser origins allowed to access the JSON-RPC HTTP and WS servers.
resources allocates compute and storage resources to the node.
cpu
string
number of cpu cores this node requires
4
cpuLimit
string
number of cpu cores this node is limited to
8
memory
string
memory this node requires
4Gi
memoryLimit
string
memory this node is limited to
8Gi
storage
string
disk space this node requires
80Gi
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1), 1500m, 2, and 4.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
number
Ethereum chain id
string
Link contract address
string
Ethereum node WebSocket server endpoint
array
Ethereum HTTP endpoints
string
Postgres database connection URL
string
k8s secret name that holds keystore password
object
API credentials
array
Domains from which to accept cross origin requests
*
string
k8s secret name that holds tls.key and tls.crt
number
Port used for node API and GUI
6688
number
Port used for HTTPS connections
6689
number
Port used for p2p communcations
30303
boolean
Enable secure cookies for authentication
false
string
Logging verbosity level
info
object
node compute and storage resources to alloacte
ethereumChainId is ethereum chain id.
linkContractAddress is Link contract address.
ethereumWsEndpoint is Ethereum node's WebSocket server endpoint.
ethereumHttpEndpoints is array of Ethereum HTTP endpoints used for heavy requests and as fallback in case of Ethereum node bug or failure.
databaseURL is Postgres database connection URL.
keystorePasswordSecretName is k8s secret name that holds keystore (wallet) password in data field called password.
apiCredentials is the credetials used to access Chainlink node UI:
string
User email
passwordSecretName
string
k8s secret name that holds password in data field called password
corsDomains is a list of domains from which to accept cross origin requests.
certSecretName is k8s secret name that holds TLS private key in tls.key data field and TLS certificate in tls.crt data field.
apiPort is the port used for node API and GUI.
tlsPort is the port used for HTTPS connections.
p2pPort is the port used for p2p communcations.
secureCookies enables secure cookies for authentication.
logging is logging verbosity level. Possible values are debug, info, warn, error, and panic.
resources allocates compute and storage resources to the node.
cpu
string
number of cpu cores this node requires
2
cpuLimit
string
number of cpu cores this node is limited to
4
memory
string
memory this node requires
2Gi
memoryLimit
string
memory this node is limited to
4Gi
storage
string
disk space this node requires
20Gi
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1), 1500m, 2, and 4.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
string
Network to join
string
Ethereum 2.0 client to use
array
Ethereum 1 JSON RPC endpoints
array
hostnames to whitelist for RPC access
*
array
domains from which to accept cross origin requests
*
bool
Enable REST API server
false
string
REST API server host
0.0.0.0
number
REST API server port
5051
bool
Enables JSON RPC server
false
string
JSON RPC server host
0.0.0.0
number
JSON RPC server port
4000
bool
GRPC gateway server
false
string
GRPC gateway server host
0.0.0.0
number
GRPC gateway server port
3500
number
p2p and discovery port
9000
string
k8s secret name that holds tls.key and tls.crt
string
logging verbosity level
info
object
Node compute and storage resources
network is Ethereum 2.0 network to join and sync its beacon chain.
client is the Ethereum 2.0 client to use.
client possible values are teku,prysm,lighthouse, and nimbus.
eth1Endpoints is array of Ethereum 1 JSON RPC endpoints.
hosts is a list of host names to whitelist for RPC access (server enforced).
corsDomains is a list of domains from which to accept cross-origin requests (browser enforced).
rest enables REST API server.
restHost is the REST API server host.
restPort is the REST API server port.
rpc enables JSON RPC server.
rpcHost is the JSON RPC server host.
rpcPort is the JSON RPC server port.
grpc enables GRPC gateway server.
grpcHost is the GRPC gateway server host.
grpcPort is the GRPC gateway server port.
p2pPort is the p2p and discovery port.
certSecretName is k8s secret name that holds TLS private key in data field called tls.key and TLS certificate in data field called tls.crt.
certSecretName is supported only by prysm client.
logging is logging verbosity level.
Different levels are supported by different Ethereum 2.0 beacon node clients.
off
✔️
❌
❌
❌
fatal
✔️
❌
✔️
✔️
none
❌
❌
❌
✔️
notice
❌
❌
❌
✔️
error
✔️
✔️
✔️
✔️
warn
✔️
✔️
✔️
✔️
info
✔️
✔️
✔️
✔️
debug
✔️
✔️
✔️
✔️
trace
✔️
❌
✔️
✔️
all
✔️
❌
❌
❌
critical
❌
✔️
❌
❌
panic
❌
❌
✔️
❌
resources allocates compute and storage resources to the node.
resources object has the following fields:
cpu
string
number of cpu cores this node requires
4
cpuLimit
string
number of cpu cores this node is limited to
8
memory
string
memory this node requires
8Gi
memoryLimit
string
memory this node is limited to
16Gi
storage
string
disk space this node requires
200Gi
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1 core), 1500m which is 1.5 core, 2 cores, and 4 cores.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
string
Network to validate blocks for
string
Ethereum 2.0 client to use
array
List of beacon node endpoints
string
k8s secret name that holds tls.crt
string
Text to include in proposed blocks
Powered by Kotal
string
Wallet password kubernetes secret
array
Validator keystores
string
logging verbosity level
info
object
Validator compute and storage resources
network is the Network to validate blocks for.
client is the Ethereum 2.0 client to use.
beaconEndpoints is a list of beacon node endpoints.
certSecretName is k8s secret name that holds TLS certificate in data field called tls.crt.
certSecretName is supported only by prysm client.
graffiti is the text to include in proposed blocks.
walletPasswordSecretName is prysm wallet password kubernetes secret.
Wallet password secret must be deployed before deploying the validator.
Wallet password secret must contain the password in key named password.
keystores is array of keystore objects.
secretName
string
kubernetes secret name holding keystore and password
publicKey
string
Validator public key in hexadecimal
Keystore secret must be deployed before deploying the validator.
Keystore secret must contain the BLS12-381 keystore JSON file in data field key called keystore key, and password in password key.
logging is logging verbosity level.
Different levels are supported by different Ethereum 2.0 beacon node clients.
Teku validator client doesn't support logging. Verbosity level will be ignored 🙈
off
❌
❌
❌
fatal
❌
✔️
✔️
none
❌
❌
✔️
notice
❌
❌
✔️
error
✔️
✔️
✔️
warn
✔️
✔️
✔️
info
✔️
✔️
✔️
debug
✔️
✔️
✔️
trace
❌
✔️
✔️
all
❌
❌
❌
critical
✔️
❌
❌
panic
❌
✔️
❌
resources allocates compute and storage resources to the node.
resources object has the following fields:
cpu
string
number of cpu cores this node requires
4
cpuLimit
string
number of cpu cores this node is limited to
8
memory
string
memory this node requires
8Gi
memoryLimit
string
memory this node is limited to
16Gi
storage
string
disk space this node requires
200Gi
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1 core), 1500m which is 1.5 core, 2 cores, and 4 cores.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
string
NEAR network to join and sync
string
Kubernetes secret name holding node Ed25519 private key
string
Kubernetes secret name holding node Ed25519 validator key
number
Minimum number of peers to start syncing/producing blocks
5
boolean
Keeps old blocks in the storage
false
number
p2p protocol tcp port
24567
string
p2p host
0.0.0.0
boolean
Enables JSON-RPC server
false
number
JSON-RPC server listening port
3030
string
JSON-RPC server listening host
0.0.0.0
number
Prometheus exporter port
9615
string
Prometheus exporter host
0.0.0.0
string
Telemetry service URL
array
Boot nodes to bootstrap network from
object
node compute and storage resources to alloacte
network is NEAR network to join and sync. Possible values are mainnet, testnet, and betanet.
network is immutable, it can't be changed after node is created.
nodePrivateKeySecretName is Kubernetes secret name holding node Ed25519 private key in data field key, from which node public key is generated, and p2p messages are signed.
validatorSecretName is Kubernetes secret name holding node Ed25519 validator key in data field key.
minPeers is the minimum number of peers to start syncing/producing blocks.
archive keeps old blocks in the storage.
p2pPort is p2p protocol tcp port.
p2pHost is p2p host address.
rpc enables JSON-RPC server.
rpcPort is JSON-RPC server listening port.
rpcHost is JSON-RPC server listening host address.
prometheusPort is Prometheus exporter port.
prometheusHost is Prometheus exporter host address.
telemetryURL is Telemetry service URL.
bootnodes is a list of boot nodes to bootstrap network from
resources allocates compute and storage resources to the node.
cpu
string
number of cpu cores this node requires
4
cpuLimit
string
number of cpu cores this node is limited to
8
memory
string
memory this node requires
4Gi
memoryLimit
string
memory this node is limited to
8Gi
storage
string
disk space this node requires
250Gi for non archival node, 4Ti for archive node
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1), 1500m, 2, and 4.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
network is Stacks network to join and sync. Possible values are mainnet and testnet.
network is immutable, can't be changed after node is created.
rpcPort is JSON-RPC server port.
rpcHost is JSON-RPC server host.
p2pPort is p2p bind port.
p2pHost is p2p bind host.
bitcoinNode is Bitcoin node details for Stacks node to connect and query:
miner enables mining.
seedPrivateKeySecretName is Kubernetes secret name holding seed private key used for mining.
mineMicroblocks enables mining Stacks micro blocks.
nodePrivateKeySecretName is Kubernetes secret name holding node private key.
resources allocates compute and storage resources to the node.
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1), 1500m, 2, and 4.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
network is the public network name to join, like rinkeby.
network can't be provided in private networks, where .spec.genesis is not null.
network can't be updated (immutable).
highlyAvailable controls if Ethereum nodes will be scheduled on different Kubernetes nodes.
topologyKey is Kubernetes node label key used to distribute ethereum nodes pods on different kubernetes nodes.
bootnodes is ethereum node URLs for p2p network discovery and bootstraping.
bootnodes accepts ethereum node URL enodeURL or a reference to kotal Node in the form of name.namespace where namespace is optional if referenced node is in the same namespace.
Ethereum clients have hardcoded bootnodes for public main and test networks. bootnodes will override these bootnodes.
client is the Ethereum client name powering the node.
client possible values are besu, geth, nethermind.
Only besu client can be used if network consensus is ibft2.
Only besu can be used in fixed difficulty proof of work networks, where spec.genesis.ethash.fixedDifficulty is not null.
coinbase is ethereum account to which mining rewards are paid.
coinbase is required if the node is mining miner: true.
corsDomains is a list of domains from which to accept cross-origin requests (browser enforced).
Default value * will be used if HTTP RPC server is enabled rpc: true or web socket server is enabled ws: true or graphQL server is enabled graphql: true.
graphql enables the GraphQL server.
Nethermind client doesn't support GraphQL.
graphqlPort GraphQL server listening port.
The default value 8547 will be used if the graphQL server is enabled graphql: true.
hosts is a list of host names to whitelist for RPC access (server enforced).
import is the ethereum account to import. Only for nodes running with geth or nethermind.
During account creation, it will be encrypted with the password, and during import it will be unlocked using the same password.
Nodes that import accounts can't enable HTTP RPC server, web socket server, or GraphQL server to prevent funds drainage if exposed to the internet.
Account must be imported if the node is running with geth or nethermind clients wants to be a signer or miner.
logging is Ethereum node logging verbosity level.
logging possible values are off, fatal, error, warn, debug, info, trace and all.
Different clients support different logging vrbosity levels as shown in the following table:
miner enables node mining or signing blocks.
nodePrivateKeySecretName is the node private key.
nodePrivateKeySecretName is required if the node is a boot node bootnode: true, or if besu node with client: besu is a signer in proof of authority clique network or validator in ibft2 network.
p2pPort is node p2p port for communication (TCP) and discovery (UDP).
resources allocates compute and storage resources to the node.
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1), 1500m, 2, and 4.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
rpc enables the HTTP RPC server.
rpcPort is the HTTP RPC server listening port.
Default value 8545 will be used if the HTTP RPC server is enabled with rpc: true.
rpcAPI is a list of RPC services to enable.
Default value ["web3", "eth", "net] will be used if HTTP RPC server is enabeld with rpc: true.
staticNodes is a set of trusted ethereum nodes to maintain connection to.
staticNodes accepts ethereum node URL enodeURL or a reference to kotal Node in the form of name.namespace where namespace is optional if referenced node is in the same namespace.
syncMode is Blockchain synchronization mode.
syncMode possible values are light, full, snap or fast.
light and snap sync modes are only supported by go-ethereum client.
ws enables the web socket server.
wsPort is the web socket server listening port.
The default value 8546 is used if the web socket server is enabled with ws: true.
wsAPI is a list of rpc services to enable.
the default value ["web3", "eth", "net] will be used if the web socket server is enabeld with ws: true.
genesis is the genesis block configuration.
Genesis block configuration genesis is required in private networks.
chainId is required.
chainId can't reuse existing public network chain id to avoid transaction replay.
id is the network id used for p2p communications between network nodes in private networks.
id is required in private networks.
id can't be provided while joining a public network.
id can't be updated (immutable).
coinbase is the beneficiary (ethereum address) of mining reward.
coinbase is optional.
difficulty is the difficulty of the genesis block.
difficulty is optional.
mixHash is combined with the nonce to prove the effort spent to create a block.
mixHash is optional.
gasLimit is the total gas limit for all transactions in a block.
gasLimit is optional.
nonce is a random number used in block computation.
nonce is optional.
timestamp is block creation date.
timestamp is optional.
forks is an object, where the key is fork name and the value is the block number at which to activate this fork.
forks is optional.
if forks is missing, all forks will be activated at block 0 (genesis block) except DAO.
Later forks like muirglacier can't be activated before earlier forks like homestead. They must be ordered as in the following table:
accounts is an array of accounts to fund or store code.
accounts is optional.
accounts is recommended for networks where signers or validators are not rewarded with eth.
a single account has no defaults.
ethash is Proof of Work consensus engine configuration.
ethash is optional.
ethash can be set only in proof of work private networks.
ethash.fixedDifficulty has no default value.
ethash.fixedDifficulty is only supported by Hyperledger Besu Client client: besu
clique is Proof of Authority clique consensus engine configuration.
clique is optional.
clique can be set only in proof of authority clique private networks.
At least one signer in clique.signers is required.
ibft2 is IBFT2 engine configuration.
ibft2 is optional.
ibft2 can be set only in IBFT2 private networks.
At least one validator in ibft2.validators is required.
initProfiles is al list of initial ipfs configuration profile.
initialProfiles available values are server, randomports, default-datastore, local-discovery, test, default-networking, flatfs, badgerds, and lowpower.
initProfiles can't be updated (immutable).
profiles is the list of configuration profiles to apply after peer initialization.
profiles available values are server, randomports, default-datastore, local-discovery, test, default-networking, flatfs, badgerds, and lowpower.
apiHost is API server host.
apiPort is API server port.
gatewayHost is local ipfs gateway host.
gatewayPort is API server port.
routing is the content routing mechanism.
routing available values are none, dht, dhtclient, dhtserver.
swarmKeySecretName is the kubernetes secret name that's holding the swarm key in a key called secret.
resources allocates compute and storage resources to the peer.
resources object has the following fields:
Memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1 core), 1500m which is 1.5 core, 2 cores, and 4 cores.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
id is cluster peer id derived from private key.
id is required if privateKeySecretName is provided.
It will return an output similar to the following:
privateKeySecretName is the name of the k8s secret holding base64 cluster peer privatekey in a key called key.
privateKeySecretName is required if id is provided.
It will return an output similar to the following:
trustedPeers is a list of peer IDs that can manage the cluster pinset in crdt consensus clusters.
trustedPeers is ignored in raft consensus clusters.
trustedPeers default value is * which is trust all peers.
bootstrapPeers is a list of peers to connect to on startup.
bootstrapPeers will be trusted peers in crdt clusters.
consensus is the cluster consensus algorithm.
peerEndpoint id ipfs peer http API endpoint.
peerEndpoint is required for the cluster peer to function correctly.
clusterSecretName is the k8s secret name holding 32-bit hex-encoded (without 0x) cluster secret in a key called secret.
clusterSecretName can be generated using openssl tool:
resources allocates compute and storage resources to the peer.
resources object has the following fields:
Memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1 core), 1500m which is 1.5 core, 2 cores, and 4 cores.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
network is the network this node should join and sync its blockchain data.
network possible values are mainnet, and calibration.
butterfly and nerpa networks have been deprecated 🥺
api enables API server.
apiPort is API server listening port.
apiHost is API server host.
apiRequestTimeout is API request timeout in seconds.
disableMetadataLog disables metadata logging.
p2pPort is p2p port.
p2pHost is p2p host.
ipfsPeerEndpoint ipfs peer endpoint.
ipfsOnlineMode sets sets ipfs online mode.
ipfsForRetrieval uses ipfs for retrieval.
resources allocates compute and storage resources to the node.
memory and storage requests and limits must use the pattern ^[1-9][0-9]*[KMGTPE]i$ for example 1500Mi, 30Gi, and 1Ti.
cpu requests and limits must use the pattern ^[1-9][0-9]*m?$ for example 1000m (which is equal to 1), 1500m, 2, and 4.
cpuLimit can't be less than cpu.
memoryLimit can't be less than or equal to memory.
storageClass field is immutable, it cannot be changed after creation.
required
required
Support for OpenEthereum (parity) client has been deprecated. OpenEthereum team is working with Erigon on a smooth transition path for users. More information can be found
Geth (Go-Ethereum) GraphQL server can be used only if RPC is enabled as of geth
Nethermind client which was activated by syncMode: light.
chainId is the chain id value used in transaction signature to prevent transactions reply
id can be generated using tool.
privateKeySecretName can be generated using tool.
network required
string
Stacks network to join and sync
number
JSON-RPC server port
20443
string
JSON-RPC server host
0.0.0.0
number
p2p bind port
20444
string
p2p bind host
0.0.0.0
object
Bitcoin node details
boolean
Enables mining
false
string
Kubernetes secret name holding seed private key used for mining
boolean
Mines Stacks micro blocks
false
string
Kubernetes secret name holding node private key
object
node compute and storage resources to alloacte
endpoint
string
Stacks network to join and sync
p2pPort
number
p2p bind port
rpcPort
number
JSON-RPC server host
rpcUsername
string
Bitcoin node JSON-RPC username
rpcPasswordSecretName
string
Kubernetes secret name holding bitcoin node JSON-RPC password
cpu
string
number of cpu cores this node requires
2
cpuLimit
string
number of cpu cores this node is limited to
4
memory
string
memory this node requires
4Gi
memoryLimit
string
memory this node is limited to
8Gi
storage
string
disk space this node requires
100Gi
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
string
Public network name to join, like mainnet, rinkeby, and goerli
boolean
Ethereum nodes will be scheduled on different kubernetes nodes
false
string
kubernetes node label key used to distribute ethereum nodes
topology.kubernetes.io/zone
object
Genesis block configuration
array
ethereum node URLs for p2p discovery bootstrap
string
ethereum client powering the node
string
ethereum account to which mining rewards are paid
array
domains from which to accept cross origin requests (browser enforced)
*
boolean
enable GraphQL server
false
number
GraphQL server listening port
8547
array
hostnames to whitelist for RPC access (server enforced)
*
object
ethereum account to import for geth node
string
node logging verbosity level
info
boolean
node is mining or signing blocks ?
false
string
name of kubernetes secret holding node private key
string
node p2p port
30303
object
node compute and storage resources to alloacte
boolean
enable HTTP RPC server
false
number
HTTP RPC server listening port
8545
array
services to enable
web3, eth, and net
array
set of trusted ethereum nodes to maintain connection to
string
blockchain synchronization mode
fast in public, full in private
boolean
enable web socket server
false
number
web socket server listening port
8546
array
services to enable
web3, eth, and net
privateKeySecretName
string
name of the k8s secret holding account private key in hexadecimal (without 0x) in data field called key
passwordSecretName
string
name of the k8s secret holding encryption secret in data field called password
off
✔️
✔️
❌
fatal
✔️
❌
❌
error
✔️
✔️
✔️
warn
✔️
✔️
✔️
debug
✔️
✔️
✔️
info
✔️
✔️
✔️
trace
✔️
❌
✔️
all
✔️
✔️
❌
cpu
string
number of cpu cores this node requires
2 in private, 4 in public
cpuLimit
string
number of cpu cores this node is limited to
3 in private, 6 in public
memory
string
memory this node requires
4Gi in private, 8Gi in public
memoryLimit
string
memory this node is limited to
8Gi in private, 16Gi in public
storage
string
disk space this node requires
100Gi in private, 6Ti in mainnet with full sync, 750Gi in mainnet wit fast sync, 25Gi in public test networks
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
number
used in transaction signature to prevent transactions reply eip155
number
used in network p2p communications
string
benefeciary (ethereum address) of mining reward
address(0)
string
difficulty (hexadecimal number) of the genesis block
0x1
string
hash (hexadecimal) combined with nonce to prove effort spent to create block
0x00..00
string
total gas limit (hexadecimal number) for all transactions in a block
0x47b760
string
random hexadecimal number used in block computation
0x0
string
genesis block creation date (hexadecimal)
0x0
Array
array of accounts to prefund and store code
object
supported forks and corresponding block number
object
Proof of Work consensus configuration
object
Proof of Authority consensus configuration
object
IBFT2 consensus configuration
mainnet
1
ropsten
3
rinkeby
4
goerli
5
kotti
6
ethereum classic
61
Mordor
63
development
2018
homestead
number
Homestead fork activation block number
dao
number
DAO fork activation block number
eip150
number
eip150 fork activation block number
eip155
number
eip155 fork activation block number
eip158
number
eip158 fork activation block number
byzantium
number
Byzantium fork activation block number
constantinople
number
Constantipole fork activation block number
petersburg
number
Petersburg fork activation block number
istanbul
number
Istanbul fork activation block number
muirglacier
number
Muir Glacier fork activation block number
berlin
number
Berlin fork activation block number
london
number
London fork activation block number
arrowGlacier
number
Arrow Glacier fork activation block number
address
string
ethereum address
balance
string
account balance in hexadecimal
code
string
bytecode in hexadecimal
storage
map
key is the storage location in hexadecimal, and value in hexadecimal is the storage value
fixedDifficulty
number
fixed difficulty used in block computation
blockPeriod
number
block time in seconds
15
epochLength
number
number of blocks after which to reset all votes
1000
signers
Array
array of ethereum addresses
blockPeriod
number
block time in seconds
15
epochLength
number
number of blocks after which to reset all votes
1000
validators
array
array of ethereum addresses
requestTimeout
number
timeout for each consensus round in seconds
10
messageQueueLimit
number
message queue limit
1000
duplicateMessageLimit
number
duplicate messages limit
100
futureMessagesLimit
number
future messages buffer limit
1000
futureMessagesMaxDistance
number
maximum height from current chain height for buffering future messages
10
Array
List of initial configuration profiles
default-datastore
Array
List of configuration profiles to apply after peer initialization
string
API server host
0.0.0.0
number
API server port
5001
string
Local ipfs gateway host
0.0.0.0
number
Local ipfs gateway port
8080
string
Content routing mechanism
dht
string
Name of the k8s secret holding swarm secret key
object
Compute and storage resources
cpu
string
number of cpu cores this peer requires
1
cpuLimit
string
number of cpu cores this peer is limited to
2
memory
string
memory this peer requires
2Gi
memoryLimit
string
memory this peer is limited to
4Gi
storage
string
disk space this peer requires
10Gi
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider
string
Cluster peer ID
string
Name of the k8s secret holding cluster peer privatekey
* if consensus is crdt
array
Peer IDs that can manage the pinset in crdt consensus
array
Peers to connect to on startup
string
Cluster consensus algorithm
crdt
peerEndpoint required
string
ipfs peer http API endpoint
clusterSecretName required
string
Name of the k8s secret holding cluster secret
object
Compute and storage resources
cpu
string
number of cpu cores this peer requires
1
cpuLimit
string
number of cpu cores this peer is limited to
2
memory
string
memory this peer requires
2Gi
memoryLimit
string
memory this peer is limited to
4Gi
storage
string
disk space this peer requires
10Gi
string
network to join and sync
boolean
enables API server
false
number
API server listening port
1234
string
API server host
0.0.0.0
number
API request timeout in seconds
30
boolean
disables metadata logging
false
string
p2p port
4444
string
p2p host
0.0.0.0
string
ipfs peer endpoint
boolean
ipfs online mode
false
boolean
use ipfs for retrieval
false
object
node compute and storage resources to alloacte
cpu
string
number of cpu cores this node requires
4 in nerpa, 8 in other networks
cpuLimit
string
number of cpu cores this node is limited to
8 in nerpa, 16 in other networks
memory
string
memory this node requires
8Gi in nerpa, 16Gi in other networks
memoryLimit
string
memory this node is limited to
16Gi in nerpa, 32Gi in other networks
storage
string
disk space this node requires
100Gi in nerpa, 200Gi in other networks
storageClass
string
Node volume storage class
Cluster's default storage class will be used as defined by cluster admin or cloud provider