Our offerings
From vSphere to Kubernetes: what carries over
A short session, open to anyone
Which parts of your vSphere knowledge map straight across to Kubernetes, which do not, and where your VMs can go: onto Kubernetes itself with KubeVirt, or onto another hypervisor beside it.
- Recording coming soon
- Live on request
- Nothing to install
Modular training for your team
Four one-day modules, each sold on its own
Foundations and Resilience for any team running Kubernetes, and Operations and Migration for teams moving their VMs onto it. Each is a full, hands-on day, so a team can start with the one it needs most and come back for the others.
- One day per module
- On site or remote
- Our sandbox or your systems
VMware Kubernetes Migration pilot
Three weeks, with one of your own workloads
Once the team is trained, we move a pilot application from your estate onto Kubernetes with KubeVirt, alongside your engineers, and finish with a recommendation on whether to go further.
- 3 weeks
- Your own workload
- A decision on full migration
The free session in detail
From vSphere to Kubernetes: what carries over
What maps across, what does not, and what the day-to-day looks like.
- Format
- Recording coming soon, live on request
- Level
- Beginner to intermediate
- Your systems
- No
- Price
- Free
For a lot of VMware teams, the question of what comes after vSphere now hangs over every renewal, whether or not anyone has put a date on it yet, and for many vSphere engineers the answer being put forward is Kubernetes. This session is where to start. We work through a vSphere estate piece by piece, from vCenter and datastores to vMotion and HA, and show what each part becomes on Kubernetes. Most of it maps across. Some of it does not, such as Fault Tolerance, or HA restarting a VM on its own, which on Kubernetes depends on fencing being in place first; we cover those plainly, so nobody finds out during an outage. We also cover where the VMs themselves go. Some teams move them onto another hypervisor and run Kubernetes beside it for their applications, while others run them on Kubernetes itself with KubeVirt, so there is one platform to look after instead of two; neither route has to leave your own data centre. For teams taking KubeVirt, there is still the choice between assembling it yourself and buying it packaged, and we cover what each kind of platform leaves to your team. Staying on VMware and using its own Kubernetes layer is covered too, along with why it does not answer the licensing which is pushing most teams to look elsewhere. A talk-through rather than a workshop, with demos shown as videos, open to managers as well as engineers.
You will be able to
Translate each part of your vSphere estate into its Kubernetes equivalent, for applications and for VMs
Name the vSphere features with no direct equivalent, and what teams do instead
Explain what managing workloads by desired state changes about day-to-day operations
Weigh moving your VMs to another hypervisor beside Kubernetes against running them on Kubernetes with KubeVirt
Know what to test on your own workloads before committing to a move
Setting it up
Nothing at all, not even an install
The free session, coming soon
Tell us where to send it and we will email it to you as soon as it is ready. If you would rather have the session given live, to your team or at your event, then let us know and we will arrange a date.
The modules in detail
| Module | Length | Where | Your systems | Who it is for | Price |
|---|---|---|---|---|---|
Foundations Kubernetes for vSphere Engineers | 1 day | On site / remote | Optional | vSphere engineers new to Kubernetes | On request |
Operations Running VMs on Kubernetes | 1 day | On site / remote | Optional | Engineers who will run VMs on Kubernetes day to day | On request |
Migration Migrating VMs off vSphere | 1 day | On site / remote | Yes | Teams moving VMs onto Kubernetes | On request |
Resilience Protecting Workloads on Kubernetes | 1 day | On site / remote | Optional | Teams putting Kubernetes into production | On request |
The free session is the starting point, and assumes no Kubernetes experience at all. Foundations and Resilience are for any team that will run Kubernetes, whichever platform its VMs end up on; Resilience assumes Foundations, or equivalent experience, and teams running VMs on Kubernetes take it after Operations. Operations and Migration, in that order, are for teams moving their VMs onto Kubernetes. Teams ready to move a production workload onto KubeVirt go on to our three-week pilot.
Kubernetes for vSphere Engineers
The platform underneath, explained in terms you already use.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 4 hrs
- Level
- Beginner
- Your systems
- Optional
- Price
- On request
Whether your VMs move onto Kubernetes or onto another hypervisor beside it, the engineers who will run the cluster are often the ones on the team with the least Kubernetes experience. This day closes that gap. The hardest adjustment is the operating model. In vSphere, you make a change and it stays made; in Kubernetes, you describe the state you want, and a controller keeps putting it back. Once that clicks, most of the rest follows. It can run on our sandbox cluster, so there is nothing to set up and nothing to get approved, or on the platform your team has chosen.
You will be able to
Read, change, and apply Kubernetes manifests with kubectl
Explain why a change made by hand gets reverted, and where that change should have gone
Set up namespaces, quotas, and RBAC in place of folders, resource pools, and vCenter roles
Provide storage through storage classes and persistent volume claims, the counterparts of datastores and VMDKs
Work out why something is not running, from events, logs, and resource status
Setting it up
Our sandbox cluster, or the platform your team has chosen, agreed when you book
Running VMs on Kubernetes
Day-two operations, from golden images to node failure.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 5 hrs
- Level
- Intermediate
- Your systems
- Optional
- Price
- On request
For teams running VMs on Kubernetes, this is the day most vSphere engineers are waiting for: creating, networking, moving, and protecting VMs on Kubernetes, and knowing where the behaviour differs from what they are used to. Some of it is close to a direct swap, such as live migration standing in for vMotion. Other parts behave differently in ways that matter most at 03:00. A VM on a failed node is not restarted until the cluster is sure that node is down, so fencing has to be in place before it is needed. Every exercise runs against VMs on a live cluster, and at one point we take a node away, so the team sees its first node failure in a lab as opposed to in production.
You will be able to
Build VMs from golden images, with instance types, preferences, and cloud-init in place of templates and customisation specs
Put VMs on your existing VLANs with Multus and a Linux bridge
Live-migrate and resize running VMs, keep VMs apart with anti-affinity rules, and know what draining a node does to them, the way you would enter maintenance mode
Snapshot, clone, and restore a VM, and know what a snapshot leaves out
Predict what happens to each VM when a node fails, and know what fencing it needs to restart elsewhere
Reach a VM's console and guest agent when its network is down
Setting it up
Our sandbox cluster, or the platform your team has chosen, agreed when you book
Migrating VMs off vSphere
Forklift, and the failures that look like success.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 4 hrs
- Level
- Advanced
- Your systems
- Yes
- Price
- On request
Forklift, the upstream project behind the migration tooling in several KubeVirt distributions, makes moving a VM look simple, and for a lot of VMs it is. The trouble sits in the minority. In our own migration testing, we saw migrations report success over a multi-disk VM whose conversion picked the wrong operating system disk, over Windows drivers which had only partly installed, and over DNS settings which never arrived. We also saw VMs with independent disks hang indefinitely, with no error at all, and Forklift's plan validation only warns about such VMs before letting them run. This day teaches the tool, or the one your platform ships with instead, and then the checks which catch what the status does not.
You will be able to
Sort your own estate into VMs that can move as they are, need preparing first, or should stay put, and pick the candidates for a pilot migration
Run cold and warm migrations with Forklift, and know why warm does not always mean less downtime
Check that a migrated guest is healthy, as opposed to trusting a green status
Prepare Windows guests for conversion, covering drivers, static IP addresses, and DNS
Spot the VMs that will hang or convert the wrong disk before a migration starts
Plan migration waves, with a rollback for each
Setting it up
A non-production vCenter, with two or three test VMs you are happy for us to copy
A non-production Kubernetes cluster which can reach that vCenter, or we can help you set one up beforehand
Protecting Workloads on Kubernetes
Backups, monitoring, and upgrades, which vSphere did without being asked.
- Length
- 1 day
- Format
- On site / remote
- Hands-on
- 4 hrs
- Level
- Intermediate
- Your systems
- Optional
- Price
- On request
A vSphere estate is protected by things nobody has to think about from one day to the next. The backup product reads changed blocks through vSphere's own APIs, vCenter draws a performance chart and raises alarms for every VM, and Lifecycle Manager upgrades hosts one at a time while vMotion keeps the VMs running. On Kubernetes, each of those is a separate piece which the team chooses and runs, and until it does, a workload can look protected without being so. This day works through each of them on our sandbox cluster or your own platform, with containerised applications, and with VMs on KubeVirt for teams that run them. We back workloads up off the cluster and restore them after deleting the originals, then check the application rather than the status. We build the views and alerts a vSphere team expects from vCenter, with a runbook behind each alert. Then we upgrade the cluster underneath running workloads, and find the one it could not move.
You will be able to
Back up workloads and their persistent volumes to object storage, and restore them onto the same storage or different storage
Explain why a snapshot is not a backup, and what quiescing the application, or freezing a VM's guest, adds to a backup
Read a workload's performance from the cluster and from inside it, in place of vCenter's performance charts
Turn the alerts which ship with Kubernetes and KubeVirt, and your own, into alarms with a runbook behind each
Upgrade the cluster under running workloads, and find the ones the upgrade leaves behind
Plan the order and cadence of upgrades across Kubernetes, its add-ons such as KubeVirt, and the nodes
Setting it up
Our sandbox cluster, or the platform your team has chosen, agreed when you book
Where VMware teams are now
Broadcom's licensing changes have put a date on a lot of VMware estates, and the engineers asked to move them have spent years building their expertise in vSphere. Leaving VMware need not mean going to public cloud, since Kubernetes runs on the hardware you already own. Some teams move their VMs to another hypervisor and their applications onto Kubernetes beside it; others run the VMs on Kubernetes too, with KubeVirt, so VMs and containers share one platform. Either way, the people who run the estate end up running Kubernetes, and they are the harder part of the move. An estate is only as safe as the incident response behind it, and years of vSphere instinct do not transfer by themselves.
How we teach it
We start from what your engineers already know. Each module opens with the vSphere feature and works towards its Kubernetes equivalent, including the places where the behaviour differs, so the team leaves with an accurate picture of the new platform instead of a set of look-alikes. The labs include the failures, too: a node going away, a migration that reports success over a broken guest, and a change reverted by a controller.
We meet your team on the platform it has chosen. If you will run OpenShift, SUSE, or another Kubernetes distribution, we teach the modules on it, with its own console and tooling. If you have not chosen yet, we teach upstream Kubernetes and KubeVirt, which carry over to whichever platform you pick.
Our engineers have run Kubernetes on VMware on premises for years, including the multi-cloud platform we designed and supported for Siemens, which grew to 200+ clusters across AWS, Azure, and VMware. We have run Kubernetes training for engineering teams at companies including Maersk, JCDecaux, AJ Bell, Vonage, and Numatic.
Does this sound like your team?
vSphere teams with a move date
The estate is going to Kubernetes, or to another hypervisor with Kubernetes beside it, and the people who will run it have not used Kubernetes yet
Teams running two platforms at once
Partway through a migration, with VMs on both sides and runbooks written for only one of them
Platform teams inheriting VMs
Comfortable with Kubernetes, and now responsible for workloads that were never going to be containers
vSphere teams already running Kubernetes
Running Kubernetes on VMware's own Kubernetes layer, and now moving VMs onto Kubernetes too. Operations is the place to start
Infrastructure leads planning the exit
Need to know what the team has to learn, and how long it will take, before committing to a date
How the modules run
Six to ten engineers per module, so everybody works at their own keyboard
Your own laptop, with a browser. Migration also needs a terminal, as it runs on your systems
Working vSphere experience; Foundations assumes no Kubernetes at all
Start with the free session if you are still deciding where the estate should go
Talk to a specialist
Interested in running vSphere to Kubernetes Skills Transfer with your team? Book a quick chat with one of our team to find out more.
Talk to a specialist