Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes: The Future of Deployment

bashton.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Kubernetes: The Future of Deployment

#71

Post by jacques_chester »

NotOscarWilde wrote: post #6

A slightly off-topic comment, but being an early-stage PhD in theoretical CS with my thesis topic on approximation algorithms for scheduling, I would like to know whether there are some theoretical problems related to these VM schedulers used in practice. If there is somebody knowledgeable about what is theoretically open (unknown tight approximation ratio, for instance) AND very useful to people building Kubernetes…

Lattice[1] "cheats" by turning the bin packing problem into an auction. Execution agents perform a simple local calculation and send in their bids. Then jobs are placed according to those bids.

This is because while you can try to produce an optimal distribution, it's a fool's errand in a distributed system. A perfect solver, given imperfect data, produces nonsense. GIGO, as they used to say.

Amit Gupta wrote some notes last year about it[2].

Disclaimer: I work for Pivotal.

[1] http://lattice.cf/

[2] http://blog.pivotal.io/pivotal-cloud-foundry/products/app-pl...

Re: Kubernetes: The Future of Deployment

#72

Post by NateDad »

saryant wrote: post #60
NateDad wrote: post #7

Wow, you could totally s/kubernetes/juju/ in this article and still be 100% correct. ( https://jujucharms.com for those not aware of juju)

Not cool. At least disclose that you're one of the devs behind Juju.

Sorry, I didn't think of it. I've mentioned it multiple times on HN, but you're right, I should have added a disclosure.

Seriously didn't mean to be pushing Juju, I was just surprised at how similar it was to Juju. I had always sort of assumed it was Google cloud only, and/or containers only, etc.

Re: Kubernetes: The Future of Deployment

#73

Post by cbeacock »

vyshane wrote: post #58
shykes wrote: post #48

Earlier quoted context omitted.

In case you're interested, the next version of Docker (1.7) supports multi-host networking and dynamic service discovery out of the box. The whole thing is pluggable and can use various distributed state backends (etcd, zookeeper etc) or IP connectivity backends (veth, macvlan, vxlan, openvpn etc) without changing your application. Service discovery uses DNS so you don't need to modify your application to take advant…

Hi Solomon, do you have an ETA for Docker 1.7? I see that it's currently in RC1. How soon will we be able to take advantage of libnetwork via Compose? Is there any documentation yet on how it will be done in Compose? Is there currently an easy way to try it via Boot2Docker? Sorry about the barrage of questions. As you can probably guess, I'm very interested in trying this out.

As far as an ETA goes, it looks like they're shooting for 06/16/2015, as found on their project page here: https://github.com/docker/distribution/wiki/docker-1.7-Proje...

Re: Kubernetes: The Future of Deployment

#74

Post by presspot »

peteridah wrote: post #70
cmcluck wrote: post #39

Earlier quoted context omitted.

(disclaimer: i work at Google and was one of the founders of the project) when we were looking at building k8s our mission was to help the world move forwards to a more cloud native approach to development. by cloud native i mean container packaged, dynamically scheduled, micro-services oriented. we figured that in the end our data centers are going to be well suited to run cloud native apps, since they were designed…

Thanks for this, it cleared up some confusion in my mind. A blogpost capturing these thoughts would be great.

"Adding k8s on mesos you get the next-generation cloud native scheduler and the ability to run existing workloads. by running k8s by itself you get a lightweight cluster environment for running next gen cloud native apps." @cmcluck

More references:

[1] https://mesosphere.com/blog/2015/04/22/making-kubernetes-a-f...

[2] http://blog.kubernetes.io/2015/04/kubernetes-and-mesosphere-...

[3] http://thenewstack.io/mesosphere-now-includes-kubernetes-for...

Re: Kubernetes: The Future of Deployment

#75

Post by scprodigy »

takeda wrote: post #67
jganetsk wrote: post #61

Earlier quoted context omitted.

How does that prove it's a VM? How do you know it's not cgroup isolation with a chroot jail? Also known as containers?

Because you're the one setting them up. Basically you run Amazon provided agent on an EC2 instance and ECS will see it as a host for ECS. Also Amazon bills you for that EC2 instance as any other instance. Personally I have hard time understanding the benefits of running docker in public cloud, you still run a VM you still pay for that VM. It just one extra abstraction layer which increases complexity of your infrastr…

People use Docker in a public cloud (VM), primarily to simplify the deployment pipeline, not for LXC.

Given this, it actually makes sense to combine VM with Docker, check out www.hyper.sh

Re: Kubernetes: The Future of Deployment

#76

Post by scprodigy »

takeda wrote: post #67
jganetsk wrote: post #61

Earlier quoted context omitted.

How does that prove it's a VM? How do you know it's not cgroup isolation with a chroot jail? Also known as containers?

Because you're the one setting them up. Basically you run Amazon provided agent on an EC2 instance and ECS will see it as a host for ECS. Also Amazon bills you for that EC2 instance as any other instance. Personally I have hard time understanding the benefits of running docker in public cloud, you still run a VM you still pay for that VM. It just one extra abstraction layer which increases complexity of your infrastr…

People use Docker in a public cloud (VM), primarily to simplify the deployment pipeline, not for LXC.

Given this, it actually makes sense to combine VM with Docker, check out www.hyper.sh

Re: Kubernetes: The Future of Deployment

#77

Post by takeda »

scprodigy wrote: post #75
takeda wrote: post #67

Earlier quoted context omitted.

Because you're the one setting them up. Basically you run Amazon provided agent on an EC2 instance and ECS will see it as a host for ECS. Also Amazon bills you for that EC2 instance as any other instance. Personally I have hard time understanding the benefits of running docker in public cloud, you still run a VM you still pay for that VM. It just one extra abstraction layer which increases complexity of your infrastr…

People use Docker in a public cloud (VM), primarily to simplify the deployment pipeline, not for LXC. Given this, it actually makes sense to combine VM with Docker, check out www.hyper.sh

My problem is that I don't believe you can use docker without using containers. And if you want to simplify pipeline, why not just use rpm-maven-plugin[1] you can easily deploy including dependencies, it is fast, you can easily upgrade or downgrade. And no need to trying to figure complexities imposed due to involving LXC.

[1] http://mojo.codehaus.org/rpm-maven-plugin/ (the website does not seem to be available at this moment due to recent CodeHaus shutdown)

Re: Kubernetes: The Future of Deployment

#79

Post by crb »

wyc wrote: post #25
falcolas wrote: post #23

Worth remembering, Kubernetes was built to Google's needs, and Google runs with a shared network space on any given VM and assigns an entire /24 to the VM running docker. Each container gets one of those addresses. [1] This probably won't work for everyone - be sure to read into the fine grained details before drinking the koolade. They're also at least two build versions behind Docker.[2] [1] https://github.com/Goog…

Agreed. I have more specifics of Google-centralism in my comment here: https://news.ycombinator.com/item?id=9330049

In that post, you asked "Do you see any other providers here? https://github.com/GoogleCloudPlatform/kubernetes/tree/maste...

Your implication was, at the time, there was only a GCE Persistent Disk provider.

Today, there's that, plus AWS EBS volume, git repo, GlusterFS, NFS, Ceph block device, iSCSI, as well as host path and empty directory.

Sounds like the product has evolved with a broad spectrum of support to me!

Re: Kubernetes: The Future of Deployment

#80

Post by wyc »

crb wrote: post #79
wyc wrote: post #25

Earlier quoted context omitted.

Agreed. I have more specifics of Google-centralism in my comment here: https://news.ycombinator.com/item?id=9330049

In that post, you asked "Do you see any other providers here? https://github.com/GoogleCloudPlatform/kubernetes/tree/maste... Your implication was, at the time, there was only a GCE Persistent Disk provider. Today, there's that, plus AWS EBS volume, git repo, GlusterFS, NFS, Ceph block device, iSCSI, as well as host path and empty directory. Sounds like the product has evolved with a broad spectrum of support to me!

Yes, it has! Again, I don't think the design decisions were made to lock out other vendors. It's very reasonable to me that the first platform to be supported by Google engineers is Google's platform.

Side note: I should be a better citizen and link to specific commits next time.

Post reply on HN