Goodbye minikube!

I’ve been using minikube as my local cluster since I started to learn Kubernetes. But I’ve decided to let it go in favor of kind. Here’s the story.

A couple of weeks ago, I gave my talk on Zero Downtime on Kubernetes. A demo is included in the talk, as with most of my presentations. While rehearsing in the morning, the demo worked, albeit slowly. Two days before that, I had another demo that also uses Kubernetes and it was already slow. But I didn’t take the hint.

During the demo, everything was slow: the of scheduling pods, of course, but also the running and the deletion of pods. The demo failed miserably. I didn’t even manage to stop minikube cleanly and I had to stop the VM.

To say I was disappointed is quite an understatement. That was my first shot at this demo. I hate when demos go wrong; I hate it, even more, when it works during rehearsal and it fails in front of the audience. I apologized profusely and decided that I wouldn’t repeat the same experience.

After the talk, I deleted the cluster and created it from scratch again. As for the deleted cluster, I used the virtualbox driver. I also used the same configuration as before: 4 cores and 16Gb. And yet, scheduling was slow… again.

I already had some interest in alternatives to minikube. This failure gave me the right incentive. I chose kind because some of the comments mention it in good terms.

Coming from minikube, there are a couple of differences worth mentioning. The most important one is that kind runs in Docker. Its name is actually an acronym for ‘kubernetes in docker.’ Hence, Docker must be running prior to any kind-related operation.

As a consequence, there’s no dedicated cluster IP, everything is directly on localhost. However, the cluster needs to be configured explicitly to map ports.

#devops #kubernetes #minikube #kind

What is GEEK

Buddha Community

Goodbye minikube!

I’ve been using minikube as my local cluster since I started to learn Kubernetes. But I’ve decided to let it go in favor of kind. Here’s the story.

A couple of weeks ago, I gave my talk on Zero Downtime on Kubernetes. A demo is included in the talk, as with most of my presentations. While rehearsing in the morning, the demo worked, albeit slowly. Two days before that, I had another demo that also uses Kubernetes and it was already slow. But I didn’t take the hint.

During the demo, everything was slow: the of scheduling pods, of course, but also the running and the deletion of pods. The demo failed miserably. I didn’t even manage to stop minikube cleanly and I had to stop the VM.

To say I was disappointed is quite an understatement. That was my first shot at this demo. I hate when demos go wrong; I hate it, even more, when it works during rehearsal and it fails in front of the audience. I apologized profusely and decided that I wouldn’t repeat the same experience.

After the talk, I deleted the cluster and created it from scratch again. As for the deleted cluster, I used the virtualbox driver. I also used the same configuration as before: 4 cores and 16Gb. And yet, scheduling was slow… again.

I already had some interest in alternatives to minikube. This failure gave me the right incentive. I chose kind because some of the comments mention it in good terms.

Coming from minikube, there are a couple of differences worth mentioning. The most important one is that kind runs in Docker. Its name is actually an acronym for ‘kubernetes in docker.’ Hence, Docker must be running prior to any kind-related operation.

As a consequence, there’s no dedicated cluster IP, everything is directly on localhost. However, the cluster needs to be configured explicitly to map ports.

#devops #kubernetes #minikube #kind

Minikube: Run Kubernetes Locally

Minikube

minikube implements a local Kubernetes cluster on macOS, Linux, and Windows. minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit.

Features

minikube runs the latest stable release of Kubernetes, with support for standard Kubernetes features like:

• LoadBalancer - using minikube tunnel
• Multi-cluster - using minikube start -p <name>
• NodePorts - using minikube service
• Persistent Volumes
• Ingress
• Dashboard - minikube dashboard
• Container runtimes - minikube start --container-runtime
• Configure apiserver and kubelet options via command-line flags
• Supports common CI environments

As well as developer-friendly features:

• Addons - a marketplace for developers to share configurations for running services on minikube
• NVIDIA GPU support - for machine learning
• Filesystem mounts

For more information, see the official minikube website

Installation

See the Getting Started Guide

:mega: Please fill out our fast 5-question survey so that we can learn how & why you use minikube, and what improvements we should make. Thank you! :dancers:

Documentation

See https://minikube.sigs.k8s.io/docs/

More Examples

See minikube in action here

Community

minikube is a Kubernetes #sig-cluster-lifecycle project.

#minikube on Kubernetes Slack - Live chat with minikube developers!

minikube-users mailing list

minikube-dev mailing list

Contributing

Development Roadmap

Join our meetings:

• Bi-weekly office hours, Mondays @ 11am PST
• Triage Party

Download Details:

Author: Kubernetes
Source Code: https://github.com/kubernetes/minikube 
License: Apache-2.0 license

#go #golang #kubernetes #contains #cluster 

Minions in Minikube - A Kubernetes Intro for Java Developers

We want our microservices to be replicable, replaceable workers that we can easily upgrade or downgrade without any downtime and minimal management. We might say we want them to be our minions. In this article we’ll walk through a simple example to see what Kubernetes can do for us by creating and orchestrating an army of minions. You can code along with this article or clone the project from here.

Prerequisites

We will need to containerize our microservices to run them in Kubernetes—we’ll use Docker for this. Rather than using a cloud-hosted Kubernetes we’ll use Minikube so that we can sandbox locally.

The Aim

Our minion army will be Java microservices. We want different types of minions in our army so that we see what Kubernetes can do for us. So we’ll aim for each microservice to respond to a simple http request with a response like:

We’ll use ASCII art to represent the minion types.

Building a Java Minion Service

We can kickstart our microservice as a Spring Boot Web app using the Spring Initializr with the Web starter dependency:

In the project we’ll create a Controller annoted with @RestController to handle requests. We’ll use an @RequestMapping(method=GET) to provide a response body. So to start with we can do something like:

@RequestMapping( method=GET)
@ResponseBody
public String minion() throws UnknownHostException {
​
   StringBuilder stringBuilder = new StringBuilder();
   stringBuilder.append("Host: ").append(InetAddress.getLocalHost().getHostName()).append("<br/>");
   return stringBuilder.toString();
​
}

But this won’t quite give us what we want. We could output the ASCII art here but which minion type do we choose? For this we can use a trick. We’ll create one app that can take the form of any minion type we choose. To do that we’ll need it to contain a library of ASCII art minions. So we create a class called MinionsLibrary that we annotate with @Component and inside we create a map that we initialise with some minions from this blog :

@Component
public class MinionsLibrary {
​
    private Map<String,String> map = new HashMap<>();
​
    public MinionsLibrary(){
​
      map.put("one-eyed-minion",<COPY-PASTE MINION ASCII ART HERE>);
      map.put("two-eyed-minion",<COPY-PASTE MINION ASCII ART HERE>);
      map.put("sad-minion",<COPY-PASTE MINION ASCII ART HERE>);
      map.put("happy-minion",<COPY-PASTE MINION ASCII ART HERE>);
​
    }
}

#java #devops #microservices #docker #spring boot #kubernetes #introduction #spring boot 2 #minikube #spring boot microservices

Access Minikube Using Kubectl From Remote Machine

Installing Minikube

If you do not have a minikube setup just use the below link to setup.

https://kubernetes.io/docs/setup/learning-environment/minikube/

Install Kubectl

It will help you connect to the minikube API server and schedule deployments.

curl -LO "https://storage.googleapis.com/kubernetes-release/release/

$(curl -s https://storage.googleapis.com/kubernetes-release/release/

stable.txt)/bin/linux/amd64/kubectl"

Apply Port Forwarding in Network Settings

Once the setup is done open the network setting of minikube in VirtualBox and adds port forwarding to 8443. Port 51928 is mapped to 8443 of minikube in network settings below.

#kubernetes #minikube #kubectl #remote machine

How to experiment locally on Kubernetes with minikube and your local Dockerfiles

Introduction

In this entry-level article, I present a simple way to build, expose and test your dockerized application in local development environment with Minikube, essentially Kubernetes on your computer. Sometimes the developers struggle with handling the experimental images, because for every image change, they push it to the registry and then pull it on the test K8s cluster. Below, we will use only local environment — this is going to work even if you don’t have a network connection.

We will gather necessary tools, install Minikube and build and test our own sample application.

#dockerfiles #kubernetes #minikube #docker