Cloud Native DevOps with Kubernetes

[paul nisset]

Hi,
I recently got about halfway through a similar book with 'Cloud Native' in the title that used Minikube for it's examples. The concepts were simple but I gave up on the book because they were all based on Minikube and Minikube crashed on multiple machines with the same simple examples from the book. It was extremely frustrating to invest the time in setting everything up only to have the technology fail under a really light workload  .

After crashing, it  would give you the message to delete and recreate the container. Just a huge time waster.
I came to the conclusion that Minikube is a joke and completely unusable for trying out this technology .

How is your book different? Is there a reliable way to try out any examples that you have ?

Thanks,
Paul

[Tim Holloway]

I've never crashed MiniKube. MiniKube runs as a self-launching VM and it may be simply that your system isn't properly set up for that kind of thing. Could be insufficient RAM or disk, might even be that you don't have a VM-friendly CPU.

[paul nisset]

"Could be insufficient RAM or disk, might even be that you don't have a VM-friendly CPU.
"


That's why I tried it on three separate machines.


Windows 10 desktop with 32GB Ram
Windows10 laptop with 8GB RAM , and Apple laptop with 8GB .


I don't think it is the hardware.

The book example has 4 pods .
1) MySQL light, 2) a service for a table 3) a service for  a second table  4) a service that links the two tables.
The tables only have 3 or 4 records in them each.  

I tried it with Virtual Box and the Windows hypervisor.

The 32GB machine has other VirtualBox machines that run on  it fine.

The issue is that the  Minikube API crashes . Sometimes immediately sometimes after  period of time. ie a service will work then I'll wait a while try it again and the service will crash.
Minikube probably did work at some point in the past.
I'm not sure how to get an older version of Minikube as their site pretty much forces you to use the latest version. It ended up being that I was trying to debug technology I didn't know about that was supposed to "just work" .

Just to learn how a technology works and to see it working became way too much of a time vacuum .

[Tim Holloway]

Hmmm. I'm supposed to be the one who tries something unfamiliar right when a broken release comes out.

For what it's worth, last time I ran Minikube I think it was VirtualBox under Fedora 30.

Among the places where I'd look for trouble are:

A) VirtualBox console. In case the whole VM crashed or hung/suspended.

B) Minikube dashboard. Check to see what resources are running and look at their logs

C) If the dashboard isn't responding, go to the console (command window) using kubectl and see if it responds.

D) If kubectl won't open a console, ssh into the VM. Should be some credentials published somewhere, if I'm not mistaken.

E) From ssh, see whether the kerberos processes are running, stopped, waiting, or zombie using the "ps" system command and/or "top" (which will cue you to anything that's using excessive CPU/virtual memory).

At point E) things may get a little murky unless you have been reading the docs about Kerberos' innards, but it's worth a try.

[paul nisset]

Thanks Tim.

I was running it from the console.  From looking at kubectl status I was able to see what was happening  with the pods . I also was able to see their logs.

I would see 2 or 3 of the pods up and running and occasionally get them to do things and return data but usually 1 or more  pods would not be running. From what recall , it had to do with the API server. It never crashed the VM .Just  the pods would stop working or not start up and it would be different pods each run.

I was kind of surprised at how resource intensive  the desktop version of the software was . The 2 machines with 8GB  of RAM were stretched but that wasn't the issue with the pods crashing.

What I was doing should definitely have worked on the 32GB machine.

I decided to shelve it for the time being as it is not something I need to use currently and there are other fish to fry.  

[Justin Domingus]

That sounds frustrating paul

I had some issues with minikube early on when I mostly used a Mac and ended up having better luck with Docker For Mac's Kubernetes add-on when they released it. Lately I've been running Linux on my workstations and minikube has been much better. I have also been impressed with microk8s on Ubuntu. I haven't had to use Windows as my main workstations much but i sounds like maybe the user experience with minikube on Windows is less than ideal right now

I also pretty regularly find myself spinning up a GKE cluster to test something complicated, or to try out something with Ingress on GCP, and then tear it down when I'm done. I'm lucky that we have some budget for those sorts of quick tests where I work. AWS, GCP, and Azure all add free credits on new account sign up so you could always spin up a new throwaway account on one of those platforms if you wanted to try something out short-term.

[paul nisset]

Thanks for the input and suggestions Justin.
You're right about Windows as a workstation often being less than ideal. You end up jumping though extra hoops.

[John Arundel]

paul nisset wrote:Hi,

I came to the conclusion that Minikube is a joke and completely unusable for trying out this technology .

Our experience was rather similar. We started out using Minikube as the primary tool for walking the reader through running her first Kubernetes deployment, but every other week or so we'd find an update to either Kubernetes or Minikube meant the examples no longer worked. After a couple of months of this we got pretty fed up with Minikube and switched to Docker Desktop, which we've found has been completely reliable.

It's hard enough building examples for beginners to use that work across all platforms and won't break with every Kubernetes minor release. We didn't need the extra headache of an unreliable container orchestrator.