Hacker News new | past | comments | ask | show | jobs | submit login
Try Kubernetes with Vagrant (lollyrock.com)
85 points by mariomarin on July 11, 2015 | hide | past | favorite | 26 comments



The author of this post is using v0.17 but the latest Kubernetes version is v0.21 and soon v1.0 will be out. Beware that some of the commands he uses have already been renamed (run-container to run and resize to scale). Also a tip, some resources have abbreviations, eg. you can pass rc instead of replicationControllers in the cli

  kubectl get rc -l name=www-nginx


Thanks for the tip. Yet another thing I will file under "see if it's still around in a few years" before I bother with it too much.


Trust me, it will be.

RedHat, Microsoft and Google are backing it. The chances of it disappearing are minimal.


Wasn't OpenStack a thing like that too? Big company backing doesn't really mean as much as people think.


It's still not a thing??

https://wiki.openstack.org/wiki/Contributors/Corporate

Looks to me like a pretty big list.


It's a thing in that it exists, can be deployed, has industry backing and a lot of hype around it. And enough mindshare that no direct (open) competitor has a chance.

But the difference between what it claims to be able to do and what you want to actually use without hiring a bunch of developers (if possible, those that build the feature you are interested in) is also a thing. Anything going above a basic feature set is quite tricky, and many components are of bad quality. Or have undocumented specialties and the only way to get support that can help is to track down the original developers on IRC. Or 3 components share a concept, but all do it in slightly different ways.

To many cooks and all that... Many developers have recognized that, but cleaning up takes time & there are new bits and features added all the time.

Which also means that if someone doesn't need the full feature set OpenStack promises a competitor (like using containers & Kubernetes maybe) can easily beat it.

(I don't have that much experience using it myself, but I've heard the above from many developers, vendors and people trying to use it on conferences and online)


I'm well aware of all you have state, difficulties, to many cooks... [I'm one of the top 3 contributors to openstack right now]; but what u have just described IMHO is applicable to all projects that gain momentum (I mean look at what happened to node.js and io.js and the split or whatever that happened there), linux itself has lots of similarities (or so I have heard) so I am thinking this is just the nature of the game...

TLDR; software takes time to mature, software that is subject to hype probably takes a little more time to mature (due to more people/cooks and more hype).


thing is, you can deploy node.js or io.js, and they largely work according to the description or the documentation. Having seen 4 sequential openstack deployment failures and rollbacks, I wouldn't wish it on my worst enemy.


Out of curiosity where did these 4 sequential openstack deployment failures and rollbacks happen? Would whoever this is be willing to share 'their story' (because if they do they can help, the software matures and get better, if they don't share it, then well nobody can fix problems that won't be talked about/shared); at yahoo we've had 4+ deployments and have not had a issue (but we also have engineers and operators who know openstack in & out).


OpenStack and Kubernetes solve different problems. OpenStack is aimed at IaaS, a la AWS without the more recent additions.

Kubernetes is the central component for a PaaS, which is why OpenShift 3 is built on top of it.


I would put it differently: OpenStack is how you do IaaS with long-lived, mutable server instances ("pets").

Kubernetes is how you do IaaS with immutable, disposable application instances ("cattle").

I've used both. OpenStack is indeed complex and brittle (but if you get it working and leave it alone, it works well). I'm excited about k8s but it's too new to pass much judgement on yet.


Interesting way to look at it. I've worked on Cloud Foundry, so I'm used to seeing things from the PaaS POV.


This openstack project makes that boundary a little more fuzzy: https://wiki.openstack.org/wiki/Magnum


OpenStack also has PaaS/SaaS components.

And in the end the problem they solve is "running applications", and for some applications that don't strictly require IaaS they are competitors. (e.g. if someone is migrating web apps off AWS, moving to a private OpenStack instance might seem like an obvious solution (like AWS, but on your own hardware), but maybe moving to a PaaS solution is the better choice, even if it requires changes to the apps)



Large companies have collectively backed all sorts of things that faded into obscurity. Tell me about the last CORBA system you worked on.

What matters in the end is developer momentum. That's what will keep Kubernetes alive.


"The author of this post is using v0.17 but the latest Kubernetes version is v0.21 and soon v1.0 will be out"

Thanks for the heads-up. I was trying to keep up with Kubernetes development a few months ago and then lost track. Looks like 1.0 will be released on July 21 http://www.kuberneteslaunch.com/ Looking forward to this.


  git clone https://github.com/GoogleCloudPlatform/kubernetes.git
  export KUBERNETES_PROVIDER=vagrant
  cd kubernetes
  ./cluster/kube-up.sh
will not work. you need to build kubernetes first. you can either run `make quick-release` before kube-up (but you need build deps) or you can download a release version. Instead try running:

  export KUBERNETES_PROVIDER=vagrant && curl -sS https://get.k8s.io | bash
You don't even need to clone the repo.


Seems Kubernetes 1.0 is also out: https://github.com/GoogleCloudPlatform/kubernetes/pull/11103 Why do they do that on weekends? ;)


I believe they're doing the real launch at OSCON which is in a week or two.


There's an explosion in the container/VM space or competing and complimenting products that I can barely keep a handle on. One thing I've noticed is that they've all seemingly failed at actually abstracting anything and are really just adding another level of obstuse syntax on top of already obscure linux commands. Why can't list out my software stack as a list of dependencies and versions (like npm package.json or a maven POM file)?


The short answer is that systems grow at the edges from a given starting position.

Existing package systems like Maven, Rubygems, NPM etc basically evolved to wire together a monolith at build time.

Placement systems like Kubernetes, Mesos and (I have a dog in this fight) Diego/Lattice solve a different problem -- efficiently locating and wiring up distributed systems composed of standalone services at runtime.

If you squint and turn your head sideways, the problem that they solve rhymes. You don't see it that way yet because you assume that there is a monolith-style solution to the problem of assembling a distributed system at build time.

There are people trying, but it's not really going to work as well. Distributed systems are simply harder to build and compose than monoliths.

The only reason you're seeing this now is because PaaSes make it trivial to stage a single app or API server, so suddenly it has become attractive to break the monolith apart. Until now, running a fleet of microservices was basically too hard for 90% of development shops.

Disclaimer: I was seconded to the Cloud Foundry buildpacks team for ~7 months and I work for Pivotal.


Can that be done by combining different images?


Those wanting an alternative might like to try Lattice[0], which is extracted from the next-gen Cloud Foundry core components (Diego scheduler, Gorouter and Loggregator).

Disclaimer: I work for Pivotal, which donates the majority of engineering to the Cloud Foundry Foundation.

[0] http://lattice.cf/


I've been running Rancher (http://rancher.com) for a week now trying out multiple configurations, and that significantly took the shine off Kubernetes for me until someone comes up with a decent web front-end.

Setup was _way_ easier, too. (Kubernetes 1.0 better come with updated docs, two months ago they didn't match the then current release).

It's going to be interesting watching what happens in the container orchestration space - the good thing is that you can (nearly) always move your stuff across without much hassle.

(Didn't know about Lattice.cf, going to take a look at that too.)


somtimes HN titles are just simple sentences with strange random substantives to me...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: