Alternatives to minikube logo

Alternatives to minikube

Kubernetes, Docker Compose, Docker, Rancher, and Docker Swarm are the most popular alternatives and competitors to minikube.
20
9
+ 1
0

What is minikube and what are its top alternatives?

It implements a local Kubernetes cluster on macOS, Linux, and Windows. Its goal is to be the tool for local Kubernetes application development and to support all Kubernetes features that fit.
minikube is a tool in the Container Tools category of a tech stack.
minikube is an open source tool with 17.2K GitHub stars and 2.7K GitHub forks. Here’s a link to minikube's open source repository on GitHub

minikube alternatives & related posts

related Kubernetes posts

Yshay Yaacobi
Yshay Yaacobi
Software Engineer · | 29 upvotes · 504.2K views
atSolutoSoluto
Docker Swarm
Docker Swarm
.NET
.NET
F#
F#
C#
C#
JavaScript
JavaScript
TypeScript
TypeScript
Go
Go
Visual Studio Code
Visual Studio Code
Kubernetes
Kubernetes

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

See more
Conor Myhrvold
Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 20 upvotes · 1M views
atUber TechnologiesUber Technologies
Jaeger
Jaeger
Python
Python
Java
Java
Node.js
Node.js
Go
Go
C++
C++
Kubernetes
Kubernetes
JavaScript
JavaScript
OpenShift
OpenShift
C#
C#
Apache Spark
Apache Spark

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

See more

related Docker Compose posts

Docker
Docker
Docker Compose
Docker Compose
Jenkins
Jenkins
Kubernetes
Kubernetes
Amazon EC2
Amazon EC2
Heroku
Heroku
FeathersJS
FeathersJS
Node.js
Node.js
ExpressJS
ExpressJS
PostgreSQL
PostgreSQL
React
React
Redux
Redux
Semantic UI React
Semantic UI React
AVA
AVA
ESLint
ESLint
nginx
nginx
GitHub
GitHub
#Containerized
#Containers
#Backend
#Stack
#Frontend

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

See more
Zach Holman
Zach Holman
at Zach Holman · | 14 upvotes · 88K views
Home Assistant
Home Assistant
Docker
Docker
Docker Compose
Docker Compose

I've been recently getting really into home automation- you know, making my house Smart™, which basically means half the time my lights don't turn on and the other half of the time apparently my kitchen faucet needs a static IP address.

But it's been a blast! It's a fun way to write code for yourself, outside of work, to have an impact in the real world. It's a nice way of falling in love with a different side of programming again.

I've used Apple's HomeKit for awhile, since we're pretty all-in in Apple devices at home, but the rough edges have been grating at me more and more. HomeKit is so opaque- you can't see what's wrong, why a device is unresponsive, and most importantly: the compatibility isn't there. HomeKit has a limited selection of — more expensive — accessories, and as you go beyond just simple LED lights, you want a bit more power. Also, we're programmers, dammit, gimme all the things.

Anyway, I've switched to Home Assistant the last few months, and I'm kicking myself I didn't make the switch earlier. As a programmer, it's great: you get the most capability than pretty much any other smart home platform (integrations have been written for most devices and technologies out there today), it's easier to debug, and when you want to go bigger than just simple lights on/off, HA has some really powerful stuff behind it.

I use Home Assistant in conjunction with Docker and Docker Compose; since the config is extracted out, upgrades are usually as easy as a pull of the latest version. I've just started digging into writing integrations for a lesser-used device that I have at home, and HA makes it pretty straightforward to just magically add it to the home network.

It plays well with others, too- we require a VPN connection in to the home network to access our Home Assistant install, and HA has a few tricks to help with that (ignoring the VPN route if you're on a local network, etc). Nice client support for iOS and Android, too.

Anyway, big fan of Home Assistant if you want to go beyond simple home automations and setup. Wish I would have done it a lot earlier. Also, big fan of jumping into all this if you have the time and interest to do so- it's been tickling a different part of my code brain than I've had access to in awhile, and that's been fun in and of itself.

See more

related Docker posts

Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly · | 20 upvotes · 387K views
atChecklyHQChecklyHQ
Heroku
Heroku
Docker
Docker
GitHub
GitHub
Node.js
Node.js
hapi
hapi
Vue.js
Vue.js
AWS Lambda
AWS Lambda
Amazon S3
Amazon S3
PostgreSQL
PostgreSQL
Knex.js
Knex.js
vuex
vuex

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

See more
Tymoteusz Paul
Tymoteusz Paul
Devops guy at X20X Development LTD · | 17 upvotes · 593.9K views
Vagrant
Vagrant
VirtualBox
VirtualBox
Ansible
Ansible
Elasticsearch
Elasticsearch
Kibana
Kibana
Logstash
Logstash
TeamCity
TeamCity
Jenkins
Jenkins
Slack
Slack
Apache Maven
Apache Maven
Vault
Vault
Git
Git
Docker
Docker
CircleCI
CircleCI
LXC
LXC
Amazon EC2
Amazon EC2

Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

See more

related Docker Swarm posts

Yshay Yaacobi
Yshay Yaacobi
Software Engineer · | 29 upvotes · 504.2K views
atSolutoSoluto
Docker Swarm
Docker Swarm
.NET
.NET
F#
F#
C#
C#
JavaScript
JavaScript
TypeScript
TypeScript
Go
Go
Visual Studio Code
Visual Studio Code
Kubernetes
Kubernetes

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

See more
Docker Machine logo

Docker Machine

368
373
13
368
373
+ 1
13
Machine management for a container-centric world
Docker Machine logo
Docker Machine
VS
minikube logo
minikube
Helm logo

Helm

366
196
4
366
196
+ 1
4
The Kubernetes Package Manager
Helm logo
Helm
VS
minikube logo
minikube

related Helm posts

Emanuel Evans
Emanuel Evans
Senior Architect at Rainforest QA · | 12 upvotes · 205.7K views
atRainforest QARainforest QA
Heroku
Heroku
Kubernetes
Kubernetes
Google Kubernetes Engine
Google Kubernetes Engine
Google Cloud SQL for PostgreSQL
Google Cloud SQL for PostgreSQL
PostgreSQL
PostgreSQL
Google Cloud Memorystore
Google Cloud Memorystore
Redis
Redis
CircleCI
CircleCI
Google Cloud Build
Google Cloud Build
Helm
Helm
Terraform
Terraform

We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).

We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .

Read the blog post to go more in depth.

See more
Ido Shamun
Ido Shamun
at The Elegant Monkeys · | 6 upvotes · 96.6K views
atDailyDaily
Kubernetes
Kubernetes
GitHub
GitHub
CircleCI
CircleCI
Docker
Docker
Helm
Helm

Kubernetes powers our #backend services as it is very easy in terms of #devops (the managed version). We deploy everything using @helm charts as it provides us to manage deployments the same way we manage our code on GitHub . On every commit a CircleCI job is triggered to run the tests, build Docker images and deploy them to the registry. Finally on every master commit CircleCI also deploys the relevant service using Helm chart to our Kubernetes cluster

See more
Spring Cloud logo

Spring Cloud

281
252
0
281
252
+ 1
0
Spring helps development teams everywhere build simple, portable,fast and flexible JVM-based systems and applications.
    Be the first to leave a pro
    Spring Cloud logo
    Spring Cloud
    VS
    minikube logo
    minikube

    related Spring Cloud posts

    Spring Boot
    Spring Boot
    Spring Cloud
    Spring Cloud
    Elasticsearch
    Elasticsearch
    MySQL
    MySQL
    Redis
    Redis
    RabbitMQ
    RabbitMQ
    Kafka
    Kafka
    MongoDB
    MongoDB
    GitHub
    GitHub
    Linux
    Linux
    IntelliJ IDEA
    IntelliJ IDEA

    Spring-Boot Spring Cloud Elasticsearch MySQL Redis RabbitMQ Kafka MongoDB GitHub Linux IntelliJ IDEA

    See more

    related Portainer posts

    Wallace Alves
    Wallace Alves
    Cyber Security Analyst · | 1 upvotes · 71.9K views
    Docker
    Docker
    Docker Compose
    Docker Compose
    Portainer
    Portainer
    ELK
    ELK
    Elasticsearch
    Elasticsearch
    Kibana
    Kibana
    Logstash
    Logstash
    nginx
    nginx

    Docker Docker Compose Portainer ELK Elasticsearch Kibana Logstash nginx

    See more
    Google Cloud Container Builder logo

    Google Cloud Container Builder

    154
    164
    0
    154
    164
    + 1
    0
    Stand-alone tool for building container images regardless of deployment environment
      Be the first to leave a pro
      Google Cloud Container Builder logo
      Google Cloud Container Builder
      VS
      minikube logo
      minikube
      Docker Hub logo

      Docker Hub

      81
      44
      0
      81
      44
      + 1
      0
      Build and Ship any Application Anywhere
        Be the first to leave a pro
        Docker Hub logo
        Docker Hub
        VS
        minikube logo
        minikube
        Marathon logo

        Marathon

        74
        53
        5
        74
        53
        + 1
        5
        Deploy and manage containers (including Docker) on top of Apache Mesos at scale