Kubernetes vs Oracle VM VirtualBox

• Cost-effectiveness, Kubernetes is free and open source.
• Scalability, Kubernetes works regardless of how many pods it's managing; be it ten or a thousand.
• Low overhead, Kubernetes adds very little performance cost per developer per machine. The benefits of having a managed system vastly outweigh the minor performance cost.
• Large market share, Kubernetes is one of the top container orchestration tools used by developers today. This has been immensely helpful when finding new talent who are familiar with Kubernetes.

Read full review

• It is simple to install - there is no advanced knowledge required to begin building virtual computers
• It is easy to use - adding new virtual machines is simple with wizard-based deployment
• It enables easy portability - moving virtual machines from one host to another is straight-forward and simple
• It is free

Read full review

• Speed of error detection - many times, in attempting to fix a problem, I found that kubernetes just had a delay in handling an automated fix. By changing the system, I was playing a cat and mouse game with kubernetes' attempts to auto-fix the error.
• Sensible logging - many of the logs are difficult to decipher and too verbose to be useful.
• The learning curve is high - it took many months of working with Google, in which both I and Google Support Engineers learned a lot about how Kubernetes works. The learning curve is not for people looking for quick and easy out of the box.

Read full review

• I have had issues in the past when it has come to resizing VM disk storage. The issue is entirely detailed here: https://www.virtualbox.org/ticket/9103 -- the problem was caused because of having existing snapshots (which error message output was not detailing). I haven't had to deal with the issue due to my dynamic disk sizes not being small from the start anymore (this is mostly an issue for my Windows VMs where the base disk may need significant size for the OS). It looks like, for a resize, that a merge of all snapshots has to occur first -- one user on that list details a workaround to maintain snapshots by cloning the VM. (Note: 5.2 was just released a few weeks ago, and looks like it should prevent the problem happening in the future by properly informing users that it isn't possible with snapshots).
• Certain scenarios, like resizing disks, required dropping into a terminal as there were no options to previously do so via the GUI. According to some recent posts, I've seen that v5.2 has added disk management stuff like that to the GUI (or will be adding it). I'm comfortable with dropping into the terminal, but in a teaching scenario or when evaluating the learnability of the tools, it complicates things.

Read full review

• We switched from Chef, so we got a HUGE amount of ROI by switching our microservices over to Kubernetes 8. A lot less code, a lot easier to test, and immutable images means we have just one build and that artifact goes through all the environments.
• Automated deploys are SUPER easy with Kubernetes 8. We just have simple scripts listening on a GitHub repo for changes that applies/creates all the Kubernetes 8 pieces we need. Everyone has the power to deploy to any of the clusters through code and code reviews.
• Shrunk our devops need dramatically, everything just works.

Read full review

• Minimal-to-no support needed from the DevOps team.
• Provides a direct and an easy way to access multiple VMs inside the same machines which enables performing various testing and QA tasks without the need to switch hardware.
• Automatic provisioning using tools (esp. Vagrant) which enables developing a base image once, and allows for exporting/importing anywhere across the developers team.
• Very cost-effective (no fees or monthly subscriptions).

Read full review