Isolated SessionsDelivering

Every Session in a space of its own, up to cluster admin

Every Session runs in a container of its own. On top of that, each workshop chooses how much of Kubernetes its Sessions get, from none at all to a namespace with quotas and RBAC, a virtual cluster with cluster admin, or a virtual machine. One Session cannot see another's namespace, and what a workshop creates for a Session is deleted with it.

What you can do with it

  • A Session's pods in a namespace of its own, the rest of the cluster forbidden to it, and admin access in its namespace but none to create namespaces.

    A namespace for each Session

    Each Session gets a Kubernetes namespace of its own, with admin access to it by default, or edit or view when the workshop needs less. A workshop can add more namespaces per Session when it needs them.

  • The resource quota and the container limits that a Session's namespace gets from the workshop's budget.

    Quotas sized to the workshop

    Pick a budget, from small, at 1 CPU and 1 GiB of memory, to xxx-large, at 8 CPUs and 16 GiB, and each Session's namespace gets the matching quota and container defaults. Or choose custom and write your own.

  • A Session's virtual cluster: its nodes and namespaces listed, everything allowed, and a namespace and a custom resource definition created in it.

    Cluster admin in a virtual cluster

    Turn on a virtual cluster, and each Session gets what looks like a cluster of its own, with cluster admin, to install operators and do what a namespace does not allow, without a real cluster for each person.

  • A workshop definition in the editor that creates a KubeVirt virtual machine for each Session.

    A virtual machine when a container is not enough

    Create a VM on the cluster's nodes with KubeVirt, or a remote one through an operator such as Crossplane, alone or beside a namespace, for a complete Linux environment with administrator access.

  • A Session with no Kubernetes access: Python and its tools in the first terminal, and kubectl with no cluster to reach in the second.

    No Kubernetes at all

    For a workshop about a programming language or a command line tool, block access to the cluster, and the Session is its container and nothing more.

How you use it

A namespace for each Session is the default, with no quota. A resource budget in the workshop definition gives it one:

resources/workshop.yaml
spec:
session:
namespaces:
budget: small

Access to the namespace is admin unless role, beside the budget, sets edit or view.

For cluster admin, the workshop turns on a virtual cluster instead:

resources/workshop.yaml
spec:
session:
applications:
vcluster:
enabled: true

The Session's kubeconfig then points at the virtual cluster, where the person working in it is cluster admin, with no access to the cluster underneath. The budget, if any, applies to the virtual cluster as a whole.

A virtual machine is a KubeVirt VirtualMachine among the resources the workshop creates for each Session, which the docs show in full.

Limits

What it does not do, and what it needs from you, so you can judge it before you build on it.

Where it is used

Use cases that rely on it

Deploy it from the Hub

The Hub is a catalog of workshops you deploy on your own Educates, each with one command. These ones show this Feature at work.

Explore the Hub

Try it yourself, or talk to us

Get started runs Educates on your laptop with a first workshop in a few commands. Get help is where you ask the community, and where you can hire the people who build Educates.