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

51–60 of 80 posts

Re: Kubernetes: The Future of Deployment

#51

Post by rantanplan »

thebeardisred wrote: post #16
dchuk wrote: post #3

What's the deal with the name "Kubernetes"? Does it mean anything, or have some tech significance, or is it really just because it basically means "ruler" in Greek?

It means "Helmsman" in ancient Greek. Similarly it's related to the word "Governor" e.g: "kubernan" in ancient greek means to steer "kubernetes" is helmsman "gubernare" means to steer or to govern in Latin "gubernator" is "governor" in Latin Which then leads into the modern word "Gubernatorial", et al.

Um... in modern Greek too, not just ancient Greek :)

Re: Kubernetes: The Future of Deployment

#52

Post by dcosson »

Does anyone have resources about security/isolation best practices for running multiple applications on Kubernetes (or Mesos or similar)?

For instance in a non cloud-native app that runs in VM's, you might have one app per VM and have firewalls between different VM's that don't need to talk to each other. Then if a non-critical app got compromised and an attacker got remote execution or SQL injection or something they can't get to your other app servers or databases.

If all your apps are in a cluster, the non-critical compromised app might be running on the same host as a critical app, in which case the only thing keeping the attacker from your database credentials or other secrets is the docker container isolation which if I understand correctly is not assumed to be secure the way VM isolation is.

What are people doing to address this? Or are my assumptions wrong and it's not actually a problem to worry about? My initial impression with mesos was that you'd only use it if you're at big enough scale that you're running a huge number of instances of the same app or you're running a lot of different data processing tasks that all access the same data so no isolation is needed between them. Now I feel like I see Kubernetes being discussed frequently as a great way to run all your different microservices at any scale (e.g. "The Future of Deployment"), but I've never seen this aspect of security discussed.

Re: Kubernetes: The Future of Deployment

#53

Post by jacques_chester »

dcosson wrote: post #52

Does anyone have resources about security/isolation best practices for running multiple applications on Kubernetes (or Mesos or similar)? For instance in a non cloud-native app that runs in VM's, you might have one app per VM and have firewalls between different VM's that don't need to talk to each other. Then if a non-critical app got compromised and an attacker got remote execution or SQL injection or something the…

You might prefer Cloud Foundry, which is switching its underlying container scheduling fabric to Lattice[1].

In particular, Cloud Foundry has more advanced security groups features, because it's mostly being marketed to enterprise customers.

Disclaimer: I have worked on CF and I work for a company which is a major contributor to CF.

[1] http://lattice.cf/

Re: Kubernetes: The Future of Deployment

#54

Post by jacques_chester »

SEJeff wrote: post #5
lobster_johnson wrote: post #2

I'd love for someone to explain how Kubernetes compares to Mesos. Every article I find on the subject says they are mutually beneficial, not competitors — that you would typically run Kubernetes as a Mesos framework — yet Kubernetes also seems like it duplicates much of Mesos' functionality on its own.

Kubernetes (k8s) makes for an amazing developer story. Mesos is much more bare metal, but the scheduler scales a loooot better than the still relatively immature k8s scheduling component. One of the original authors of mesos wrote a paper on scheduling: https://www.cs.berkeley.edu/~alig/papers/drf.pdf . Mesos is one of the first "two level" schedulers. I very highly recommend that you also read this article for an id…

> (your own heroku with not a ton of work)

I've worked on Cloud Foundry, which is ostensibly a Heroku competitor.

The idea that you can replicate Heroku's full functionality "easily" is just silly.

Full-feature PaaSes do a lot of things, including a whole bunch of tedious nitty-gritty details.

We're well into the days of early maturity on PaaS products. You can install Cloud Foundry or OpenShift, or host on Heroku. Writing your own PaaS at this point is a bit like writing a custom operating system circa 1995. Unless you have a compelling reason to do so, you'd be utterly crazy to.

Re: Kubernetes: The Future of Deployment

#55

Post by menage »

cmcluck wrote: post #36
DannoHung wrote: post #18

Earlier quoted context omitted.

Pretty sure it's due to it meaning in a literal sense, "Helmsman".

(disclosure: i work at Google and picked the name) comments above are right -- we wanted to stick to the nautical theme that was emerging in containers and 'kubernetes' (or helmsmen is greek) seemed about right. the fact that the word has strong roots in modern control theory was nice also. fun fact: we actually wanted to call it 'seven' after seven-of-nine (a more attractive borg) but for obvious reasons that didn't…

The GFS cell used back in 2004 for staging Borg binaries to production was /gfs/seven/, for the same reason :-)

Re: Kubernetes: The Future of Deployment

#56

Post by dcosson »

jacques_chester wrote: post #53
dcosson wrote: post #52

Does anyone have resources about security/isolation best practices for running multiple applications on Kubernetes (or Mesos or similar)? For instance in a non cloud-native app that runs in VM's, you might have one app per VM and have firewalls between different VM's that don't need to talk to each other. Then if a non-critical app got compromised and an attacker got remote execution or SQL injection or something the…

You might prefer Cloud Foundry, which is switching its underlying container scheduling fabric to Lattice[1]. In particular, Cloud Foundry has more advanced security groups features, because it's mostly being marketed to enterprise customers. Disclaimer: I have worked on CF and I work for a company which is a major contributor to CF. [1] http://lattice.cf/

Lattice looks interesting, looking forward to checking it out more

Re: Kubernetes: The Future of Deployment

#57

Post by thockingoog »

shykes wrote: post #48
iyn wrote: post #46

Earlier quoted context omitted.

Honest answer: I don't. In short: most of the things have fixed config that is loaded into etcd cluster and different services in Docker containers use it to communicate with other containers/services (something like {rabbitmq_host: "host address"}. In the project I'm working on right now I have just 10 boxes which will probably grow to 20-30 in the coming months. It's nothing, I know, and as you can tell from the ha…

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…

I haven't seen any examples of apps that broke because of the kubernetes network model - can you point me at them? I want to understand.

Re: Kubernetes: The Future of Deployment

#58

Post by vyshane »

shykes wrote: post #48
iyn wrote: post #46

Earlier quoted context omitted.

Honest answer: I don't. In short: most of the things have fixed config that is loaded into etcd cluster and different services in Docker containers use it to communicate with other containers/services (something like {rabbitmq_host: "host address"}. In the project I'm working on right now I have just 10 boxes which will probably grow to 20-30 in the coming months. It's nothing, I know, and as you can tell from the ha…

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.

Re: Kubernetes: The Future of Deployment

#59

Post by saryant »

Hortinstein wrote: post #41
iyn wrote: post #9

Earlier quoted context omitted.

Can you suggest best resources (text/video) for learning about Kubernetes & Mesos? I use Docker & CoreOS all the time (love it) and I'm always trying to improve/learn something new. Can you tell how do you use Apache Aurora? What other interesting projects are worth learning about?

how do you currently do service discovery w/ Docker and CoreOS without MESOS or Kubernetes?

(Not the same person)

On a past project I did service discovery with Docker and CoreOS using SkyDNS with etcd. Services would register their network location in etcd and SkyDNS would translate those entries into DNS records. SkyDNS ran on every host and the app-level containers linked to the SkyDNS container.

If a container was moved across hosts, the etcd entry would be updated automatically and eventually the updated DNS entry for that service would propagate across the cluster.

Post reply on HN