We need to define some terms that will have specific meaning for this guide.
This guide is divided into three layers, which are distinct from the broader layers of Bitcoin and web1/2/3/etc:
Layer 1: Hosts These are the physical machines, OSs, users, and other basic low-level, groundwork, or foundational architecture.
Layer 2: K3s Can be thought of as the HAB node operating system. It is the interim layer between Bitcoin and the physical machines.
Layer 3: Bitcoin This is the final layer of the node. It is the app running on the Operating System (k8s), running on the Hardware.
At the moment, this guide does not incorporate Lightning or other Bitcoin reliant L2 systems, so this is where the guide stops (hopefully to be expanded in the future!). The entire project is organized around these three layers, and they correspond to the file structure of the repo where you will be executing code, and the guide itself.
For the purposes of this guide, a
standup takes a machine in a lower state and
elevates it to the desired state. A
teardown take a machine from its current
state and demotes it to a lower state. Grammatically there may be a bit of
confusion here, as subject in one is a future state and in the other it is the
current state. However, this methodology is useful because it is linear: we
cannot tear down a host which has not been first stood up.
teardown live hostmeans taking a live host and moving it to a vanilla state.
standup live hostmeans taking a vanilla host and elevating it to a live host.
Raw : a raw describer indicates either fresh out of the box, or newly repurposed, and not ready to use. If it's a host, it hasn't even been turned on or correctly imaged, or if it has, it is certainly not in any assured state of being ready to receive Kubernetes.
Raw is almost exclusively used for devices: be it computers, hard drives, or
other hardware. We neither
standup a raw device nor
teardown a raw device. A
raw device is at the entry point to the ecosystem. Instead, we may add a new raw
device to inventory, prep a raw device, and then
standup a vanilla device.
Vanilla : a vanilla describer indicates uniform, minimal, basic characteristics that allow for something to be eligible as generically useful.
standup a vanilla device we take it from a known or unknown raw state,
to a known, uniform, usable preliminary state. We generally have no need for
teardown of a vanilla host and returning it to the raw state, because that
would mean returning something to an unknown state. However, we do have need to
teardown higher vanilla layers, like a vanilla app in the cluster to shut the
We should also note that hosts in the vanilla state are to be assumed insecure: they are vanilla, they have nothing to defend.
Live : a live describer indicates active participation at the top of class.
standup a live host we are putting it in the cluster, where the host
can now support layers that reside above it. When we
teardown a live host we
are returning it to the vanilla state. This may be useful when redesigning the
cluster topology. Say, if we need to distribute or service a device.
A host in the live state should have security assurances locked down.
A 'node' vs a 'node'
Kubernetes internally labels each host a 'node', and by putting a bitcoin node
on a k8s node, there is a conflict between what a node is: is it a software
bitcoin node or a k8s hardware node? In this guide, we will use Node (node) to
mean the entire cluster acting as a bitcoin node. For individual bitcoin nodes
within the cluster we will endeavor to refer to them as a bitcoin instances,
bitcoind instance. We will use Host (host) to mean Kubernetes/physical
computer as much as possible. This is convenient because Ansible uses hosts to
mean, essentially, the same thing as k8s nodes. Though of course, as you will
see, this will get violated (mostly unintentionally), so do pay attention to the
context with which the term is being mentioned.