You can optionally spin up a Tezos blockchain indexer that makes querying for information very quick. An indexer puts the chain contents in a database for efficient indexing. Most dapps need it. You can read more about indexers here.
You must spin up an archive node in your cluster if you want to your indexer to index it. You would do so by configuring a new node's history_mode to be archive.
You can also spin up a lone indexer without any Tezos nodes in your cluster, but make sure to point the rpc_url field to an accessible Tezos archive node's rpc endpoint.
+
+
+
+
\ No newline at end of file
diff --git a/Prerequisites/index.html b/Prerequisites/index.html
new file mode 100644
index 000000000..6c397b5cb
--- /dev/null
+++ b/Prerequisites/index.html
@@ -0,0 +1,20 @@
+
+
+
+
+
+
+Prerequisites | Tezos K8s
+
+
+
+
+
Start Docker Desktop and follow the setup instructions. Note: You may quit Docker after it has finished setting up. It is not required that Docker Desktop is running for you to run a Tezos chain.
If in the next step minikube does not start correctly, you may need to configure a different driver for it. Please see the minikube docs here for more information.
We recommend using a very nice GUI for your k8s Tezos chain infrastructure called Lens. This allows you to easily see all of the k8s resources that have been spun up as well as to view the logs for your Tezos nodes. Checkout a similar tool called k9s that works in the CLI.
Check out Oxheadalpha's Typescript node module tezos-pulumi to deploy tezos-k8s in AWS EKS.
Under API Access Tokens > New Token, give a name to your access token and generate it by clicking on the "generate" button. Save the generated access token, e.g. yEflQt726fjXuSUyQ73WqXvAFoijXkLt on your computer.
Create a new network by clicking on the "Create a Network"
+button. Save the 16 character generated network
+id, e.g. 1c33c1ced02a5eee on your computer.
Set Zerotier environment variables in order to access the network id and access token values with later commands:
mkchain is a python script that generates Helm values, which Helm then uses to create your Tezos chain on k8s.
Follow just the Install mkchain step in ./mkchain/README.md. See there for more info on how you can customize your chain.
Set as an environment variable the name you would like to give to your chain:
exportCHAIN_NAME=my-chain
NOTE: k8s will throw an error when deploying if your chain name format does not match certain requirements. From k8s: DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
You can spin up a number of regular peer nodes that don't bake in your cluster by passing --number-of-nodes N to mkchain. Pass this along with your previously used flags (--zerotier-network and --zerotier-token). You can use this to both scale up and down.
Or if you previously spun up the chain using mkchain, you may adjust
+your setup to an arbitrary number of nodes by updating the "nodes"
+section in the values yaml file.
nodes is a dictionary where each key value pair defines a statefulset
+and a number of instances thereof. The name (key) defines the name of
+the statefulset and will be the base of the pod names. The name must be
+DNS compliant or you will get odd errors. The instances are defined as a
+list because their names are simply -N appended to the statefulsetname.
+Said names are traditionally kebab case.
At the statefulset level, the following parameters are allowed:
storage_size: the size of the PV
runs: a list of containers to run, e.g. "baker", "accuser"
instances: a list of nodes to fire up, each is a dictionary
+defining:
bake_using_account: The name of the account that should be used
+for baking.
is_bootstrap_node: Is this node a bootstrap peer.
config: The config property should mimic the structure
+of a node's config.json.
+Run tezos-node config --help for more info.
At this point additional nodes will be added in a full mesh
+topology.
Congratulations! You now have a multi-node Tezos based permissioned chain.
On each computer, run this command to check that the nodes have matching heads by comparing their hashes (it may take a minute for the nodes to sync up):
kubectl get pod -n oxheadalpha -l appType=octez-node -o name | whileread line; do kubectl -n oxheadalpha exec$line -c octez-node -- /usr/local/bin/octez-client rpc get /chains/main/blocks/head/hash; done
Although spinning up a mainnet baker is possible, we do not recommend running a mainnet baker at this point in time. Secret keys should be handled via an HSM that should remain online, and the keys should be passed through a k8s secret to k8s. This functionality still needs to be implemented.
You should be aware of minikube VM's allocated memory. Especially if you use minikube for other applications. It may run out of virtual memory say due to having large docker images. Being that snapshots are relatively large and increasing in size as the blockchain grows, when downloading one, you can potentially run out of disk space. The snapshot is deleted after import. According to minikube start --help, default allocated space is 20000mb. You can modify this via the --disk-size flag. To view the memory usage of the VM, you can ssh into minikube.
The accounts object of values.yaml defines Tezos accounts used in the chart.
+By default no account is configured:
accounts: {}
accounts is a map where keys are account aliases and values are maps of
+fields key, is_bootstrap_baker_account, bootstrap_balance, signer_url
+protocols and operations_pool.
The key field can be set to a public or private key. For a bootstrap baker,
+it must be set to a private key. The key type will be recognized automatically,
+and the pod will fail if the key type is unexpected.
The protocols fields overrides the top-level protocols field described
+below and has the same syntax. This allows to set specific per-block votes per
+baker.
The operations_pool field instructs the baker to target a url for external
+mempool queries when baking a block. This is useful to run a Flashbake-capable baker.
+The entry is passed to baker binaries using the --operations-pool flag.
Public chains: Accounts do not get is_bootstrap_baker_account and
+bootstrap_balance fields.
Non-public chains: If you don't specify accounts needed by nodes, they can
+be created deterministically via the above setting. If specifying, accounts
+can be given a bootstrap balance and can also be configured to be bootstrap
+baker accounts. Accounts with balances set to "0" will be imported by the
+node but they will not be bootstrap accounts. If you don't set a bootstrap
+balance, it will default to the bootstrap_mutez field above.
A public key account can contain a signer_url to a remote signer
+that signs with the corresponding secret key. You don't need to
+set this if you're deploying a tezos-k8s signer into the same
+namespace of its baker. See octezSigners and tacoinfraSigners
+fields in values.yaml to define remote signers. (You shouldn't add things
+to the URL path such as the public key hash. It will be added automatically.)
An account being signed for by a Tacoinfra AWS KMS signer requires a
+key_id field. This should be a valid id of the AWS KMS key.
+The key's corresponding public key must be provided here as well.
When running bakers for a public net, you must provide your own secret keys.
+For non public networks you can change the
+should_generate_unsafe_deterministic_data setting to true, and deterministic
+keys will be generated for your nodes automatically. This is helpful to spin up
+local testnets.
should_generate_unsafe_deterministic_data: false
+
+
+
+
\ No newline at end of file
diff --git a/Tezos-Nodes/index.html b/Tezos-Nodes/index.html
new file mode 100644
index 000000000..bc24dd541
--- /dev/null
+++ b/Tezos-Nodes/index.html
@@ -0,0 +1,64 @@
+
+
+
+
+
+
+Nodes | Tezos K8s
+
+
+
+
+
Use nodes to configure the Tezos nodes running in your chart.
nodes is a dictionary where each key/value pair defines a statefulset and a
+number of instances thereof. The name (key) defines the name of the
+statefulset and will be the base of the pod names. The instances are defined
+as a list because their names are simply -N appended to the statefulsetname.
+Said names are typically kebab case.
Params at the statefulset level:
config: The "config" property should mimic the structure of a node's
+config.json. Run octez-node config --help for more info.
+If present at the statefulset level, it overrides it in
+node_globals.
env: A dictionary of containers mapped to a dictionary of env
+vars. The container name "all" will apply the env vars to
+all containers. The most specific wins. Find the names of
+the containers by examining an installed environment, or by
+looking at charts/tezos/templates/nodes.yaml. Please note
+that we truncate the protocol from the container name for
+bakers and accusers, so "baker-011-pthangz2" is configured
+using just "baker".
images: Optional specification of images to use for the tezos node and
+baker. Options are "octez" with a tezos/tezos image.
+If no images are provided, the containers will default to the images
+defined in the "images" field up above.
runs: A list of containers to run.
+Options being octez_node, accuser, baker, logger and vdf.
local_storage: Use local storage instead of a volume. The storage will be
+wiped when the node restarts for any reason. Useful when
+faster IO is desired. Defaults to false.
local_storage_pv_size: The size of the persistent volume to store identity.json
+and peers.json when local_storage is enabled. Some cloud
+providers have minimum pv size requirements for which this
+value can be used. Default value is 1Gi.
node_selector: Specify a kubernetes node selector in key: value format
+for your tezos nodes.
readiness_probe: Attach a probe to the node. The probe checks whether
+the most recent block is recent enough. If not, the
+services will be unreachable. Defaults to True.
+True is good for RPC nodes, private nodes, and
+self-contained private chains.
+Recommended to set to False when bootstrapping a new
+chain with external bakers, such as a new test chain.
+Otherwise, the chain may become unreachable externally
+while waiting for other nodes to come online.
instances: A list of nodes to fire up, each is a dictionary defining:
bake_using_account: Account name that should be used for baking.
+Don't also set bake_using_accounts.
bake_using_accounts: List of account names that should be used for baking.
+Don't also set bake_using_account.
config: Same as the outer statefulset level config. It overrides the
+statefulset level.
is_bootstrap_node: Boolean for is this node a bootstrap peer.
identity: An optional map containing a pre-generated Tezos node
+identity. This is useful for local storage nodes which would
+need to generate an identity at every boot. The identity file
+will be created at /var/tezos/node/data/identity.json.
+Required fields are peer_id, public_key, secret_key,
+and proof_of_work_timestamp.
Defaults are filled in for most of the above values. You can also provide
+global defaults for all nodes via a node_globals section which is also
+a dictionary. Currently, two keys are defined: config and env. These
+operate in the same way as the section in nodes going by the same name.
Example config:
node_globals: config: shell: history_mode: full env: baker: TEZOS_LOG: "* -> debug" nodes: rolling-baking-node: config: shell: history_mode: rolling env: all: TEZOS_CLIENT_UNSAFE_DISABLE_DISCLAIMER: "Y" snapshot-downloader: HTTP_PROXY: http://my-proxy.my-company.com:3128/ labels: # Example labels you might use to specify certain attributes of your nodes. peer_node: "true" # Forward P2P traffic to this node types instances rpc_node: "true" # Forward RPC traffic to this node types instances node_selector: nodeSelectorKey: nodeSelectorValue storage_size: 15Gi images: # (optional field) octez: tezos/tezos:v... local_storage: false runs: - octez_node - baker resources: requests: memory: 16192Mi limits: memory: 16192Mi instances: - bake_using_account: baker0 is_bootstrap_node: true # Note the following config section overrides the above one even # if we make them the same in this example. config: shell: history_mode: rolling identity: peer_id: id... public_key: ... secret_key: ... proof_of_work_stamp: ... rolling-node: labels: # Example labels you might use to specify certain attributes of your nodes. peer_node: "true" rpc_node: "true" images: # (optional field) octez: tezos/tezos:v... runs: ["octez_node"] instances: - {} - {}
Define remote signers. Bakers automatically use signers in their namespace
+that are configured to sign for the accounts they are baking for.
+By default no signer is configured.
tezos-proto-cruncher: a chart to deploy a daemonset in your cluster to find vanity hashes for protocols in parallel
+
+
+
+
\ No newline at end of file
diff --git a/sitemap.xml b/sitemap.xml
new file mode 100644
index 000000000..dde6cb077
--- /dev/null
+++ b/sitemap.xml
@@ -0,0 +1 @@
+https://tezos-k8s.xyz/weekly0.5https://tezos-k8s.xyz/weekly0.5https://tezos-k8s.xyz/helm-chartweekly0.5https://tezos-k8s.xyz/Indexersweekly0.5https://tezos-k8s.xyz/other-helm-chartsweekly0.5https://tezos-k8s.xyz/Prerequisitesweekly0.5https://tezos-k8s.xyz/Private-Chainweekly0.5https://tezos-k8s.xyz/Public-Nodeweekly0.5https://tezos-k8s.xyz/RPC-Authweekly0.5https://tezos-k8s.xyz/Tezos-Accountsweekly0.5https://tezos-k8s.xyz/Tezos-Nodesweekly0.5https://tezos-k8s.xyz/Tezos-Signersweekly0.5
\ No newline at end of file