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
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).
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.
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)
"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:
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.
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.
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.)