Simply an Octelium Cluster is a distributed system that operates on top of k8s. It can work on top of a single-node k8s cluster/k3s which can fit in a small VM/VPS and it can also operate on top of a multi-node "production" k8s cluster. Octelium isn't just some simple abstraction over k8s, Octelium is a complete platform on its own that uses k8s as an infrastructure for itself. It uses its nodes as gateways and hosts for Octelium Services, each Service, represented by an identity-aware proxy that's deployed as a k8s service on the underlying k8s cluster, has a stable private dual-stack IP address(es) depending on the scaling and is basically acting as the endpoint of the other side of the WireGuard/QUIC tunnel.
You can now see that Octelium does with identity-aware proxies similarly to what Kubernetes itself does with containers, building a control plane around a scalable data-plane to automatically manage and deploy identity-aware proxies instead of just offloading the work manually to the Cluster administrators which is, I believe the case, in many ZTAs (e.g. Teleport, Pomerium, etc...) which makes the entire system very hard to manage since there is a lot of manual work to do by the administrators of the system. With Octelium, you can simply create and delete Services declaratively via `octeliumctl apply` or directly via the gRPC APIs and forget about managing, deploying and cleaning them up yourself. Actually Octelium resources started as CRDs many years ago, but the amount of resources in the Cluster (e.g. Users, Sessions, Services, Namespaces which are not related to k8s namespaces, Policies, Devices, Credentials, etc...) made it impossible to rely on a the etcd backend, it was simply unreliable for frequently updated resources and resources with large info. So a separate Postgres backend was introduced later.