RosettaCloud™ Kubernetes
Clusters and containers
Clusters that arrive
ready to run something.
Scaling, ingress, monitoring and storage drivers are installed and version-tracked from the moment the cluster exists, on AWS, Azure or Google Cloud, through the same operations on each. You get to the part you actually wanted to do.
The week after the cluster,
already done
Installed for you and version-tracked, so you can see what is running rather than infer it. Bring your own instead wherever you would rather.
Autoscaler
Node counts follow the workload instead of the guess someone made when the cluster was created.
Ingress
An ingress controller in place, so getting traffic to a service is not the first afternoon of work.
Monitoring
Metrics collection installed and running from the start rather than added after the first incident.
Dashboard
A cluster dashboard for the people who would rather look than remember the command.
File storage driver
Shared file systems mounted into pods, for workloads that expect a POSIX path.
Block storage driver
Persistent volumes backed by the cloud’s own block storage.
Object storage driver
Buckets reachable from inside the cluster without an access key in a manifest.
High-performance file driver
The fast parallel file system, for the workloads that actually need one.
Nodes, versions and who may reach it
Node groups you shape
Separate groups for separate work, so a GPU pool and a general pool are different node groups on one cluster rather than two clusters.
A kubeconfig, not a credential
Access is issued as a time-limited session. There is no long-lived key that has to be rotated or that outlives the person who needed it.
Shared like anything else
Give a colleague, a group or an organisation access to the cluster. They get their own session, and it ends when the share does.
Pick the tools.
Not the setup.
A cluster reachable only over a terminal is a cluster only some of your people can use. Choose the applications you want when you describe the cluster, and they are running on it the moment it exists.
Notebooks and a desktop
Jupyter, RStudio, a terminal or a full graphical desktop, opened in a browser against the cluster rather than over a connection somebody has to set up first.
Several of them at once
You are not picking one. Choose the set the work needs and move between them, all against the same cluster.
Two people in one session
A collaborative RStudio session takes more than one person, so working through a failing job becomes a conversation rather than an exchange of screenshots.
Your own tools alongside them
Your container images, startup scripts and environment, so an in-house tool arrives with the standard ones instead of being installed afterwards.
Nothing is installed by hand, and nothing has to be installed again when the cluster is replaced next month.
It comes up connected
Most of the time between having a cluster and using one goes on the work between the pieces. That part is done for you, identically on every cloud.
Storage is already mounted
Attach the storage a cluster needs and it is there at its path when the cluster comes up. Nobody edits a mount table, copies data in, or explains to the next person where the files went.
There are no keys to hand out
Cloud keys are held by the platform, not by the people using it. Nobody is emailed a private key, nobody stores one on a laptop, and there is nothing to rotate or to leak.
Certificates are issued and attached
A service that should be reachable over HTTPS comes up that way, without a certificate request, a renewal reminder, or an expiry nobody noticed until it broke.
It has a name, not an address
DNS records are created on the domains you have mapped, so people reach the cluster by a name that means something and keeps working when the machine behind it changes.
And you can share it while it is running
A live cluster is shared with a colleague, a group or a whole organisation the way a document is. They get access to the thing itself, not a copy of it and not a rebuild of it, and that access ends when the share does.
See how sharing works →What runs on it
Images and registries,
managed across clouds
A cluster is only half the problem. The other half is where the images live and who is allowed to pull them.
Repositories on demand
Create a registry repository, choose whether tags can be overwritten, and replicate to the additional regions you serve.
Scanned and encrypted
Scanning on push, and encryption at rest, decided per repository rather than hoped for centrally.
Shared by role
Repository access follows people, groups and roles, so a joiner can pull because of who they are rather than because someone edited a policy.
Under the same budget
as everything else
A cluster that would take an account over budget is refused at the cloud’s own API. An idle one is found alongside idle machines, volumes and databases. Cost is attributed to the person and the project that created it, in your own account, on your own bill.
What counts as waste →Common questions
What do I get beyond a bare managed cluster?
The pieces every cluster needs before it is useful, installed and version-tracked for you: the autoscaler, a dashboard, ingress, monitoring, and storage drivers for file, block and object storage. You can leave that to us or bring your own, and either way you can see which version of each is running.
How do I get kubectl access to a cluster?
A kubeconfig is issued for you, backed by a time-limited session rather than a long-lived credential. Sharing a cluster with a colleague issues them their own, and stopping the share stops the access.
Can I run clusters on more than one cloud the same way?
Yes. Creating a cluster, adding a node group, wiring in storage, issuing credentials and sharing it are the same operations on AWS, Azure and Google Cloud, so a second cloud does not mean a second way of working. The clusters themselves remain each provider’s own managed service.
Does cluster cost fall under the same budgets?
Yes. A cluster is created inside the same budget and quota checks as anything else, so one that would take an account over is refused at the cloud API. An idle cluster is one of the twenty eight kinds of waste that get detected.