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

Kubernetes V1 Released

googlecloudplatform.blogspot.com

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Kubernetes V1 Released

#31

Post by nickstinemates »

nickbauman wrote: post #16
puja108 wrote: post #9

Earlier quoted context omitted.

ManagedVMs don't use k8s under the covers afaik. However there's GKE (Google Container Engine), which goes on top of (at least 3) MVMs and that one does use k8s. While it is true that going with a PaaS(-like) solution like AppEngine or Heroku is easy in the beginning it can get pretty expensive pretty fast and it limits you in the choice of languages, frameworks, and data stores you can use. This can in some instance…

I've found Heroku to be about 10x the cost of AppEngine for the same kinds of apps and users. I don't even want to imagine what it would cost to create my own ec2 sprawl to do what AppEngine can do out of the box. As far as languages go, I've gone to production with AppEngine apps written in Python and Clojure. I've diddled with Go. Unless what you want is something like Node.js, which has its own limitations, I don'…

FWIW, Amazon has something similar in Elastic Beanstalk. Haven't used either personally, but they are comparable services.

Re: Kubernetes V1 Released

#32

Post by eepyaich »

amouat wrote: post #29
throwaway1979 wrote: post #22

Earlier quoted context omitted.

I've been playing with Swarm and like what I've seen so far. WRT Kubernetes, on a platform other than GCE, is Flannel required for networking?

I think you just need to provide a flat networking infrastructure where all nodes get their own IP and can reach each other. So you can swap flannel for project calico or your own setup if you like.

Yep - see http://www.projectcalico.org/calico-networking-for-kubernete....

[Disclosure - I'm part of the Project Calico team.]

Re: Kubernetes V1 Released

#33

Post by dward »

amouat wrote: post #29
throwaway1979 wrote: post #22

Earlier quoted context omitted.

I've been playing with Swarm and like what I've seen so far. WRT Kubernetes, on a platform other than GCE, is Flannel required for networking?

I think you just need to provide a flat networking infrastructure where all nodes get their own IP and can reach each other. So you can swap flannel for project calico or your own setup if you like.

Weave and Openvswitch are two other options. Many IaaS (gcp, aws) provide the required nobs and dials to configure this "natively" using their API so no extra SDN required if you are already running on a compatible cloud provider.

Re: Kubernetes V1 Released

#34

Post by matthewrudy »

rjusher wrote: post #30
TheIronYuppie wrote: post #27

Earlier quoted context omitted.

Docker and Kubernetes works hand in hand. That is to say, if you choose Docker as your container format, Kubernetes runs Docker on every node to run your container. Kubernetes focuses on _what_ Docker should run, and how to move those container workloads around. Docker also has Docker Swarm, which can be thought of as a competitor in some ways. But Google will be a heavy supporter of their container format for a long…

So Kubernetes compliments Docker, but how it complements it. I had tested Docker just for fun, thinking that maybe I could implement it in the way I work, and sure it is a super tool for developing (far better than Virtual Machines), but deploying was kind of nightmerish, for what I understood Docker wasn't at the time ready for being a deployment tool. Does Kubernetes fixes or extends Docker in this way

I have a docker image I want to run "myapp". So I tell Kubernetes "run me 5 instances of the image 'myapp', and expose port 8080"

Kubernetes jobs is to start, monitor, and load balance those docker containers.

Docker's job is to run each container.

Re: Kubernetes V1 Released

#35

Post by bkeroack »

rjusher wrote: post #30
TheIronYuppie wrote: post #27

Earlier quoted context omitted.

Docker and Kubernetes works hand in hand. That is to say, if you choose Docker as your container format, Kubernetes runs Docker on every node to run your container. Kubernetes focuses on _what_ Docker should run, and how to move those container workloads around. Docker also has Docker Swarm, which can be thought of as a competitor in some ways. But Google will be a heavy supporter of their container format for a long…

So Kubernetes compliments Docker, but how it complements it. I had tested Docker just for fun, thinking that maybe I could implement it in the way I work, and sure it is a super tool for developing (far better than Virtual Machines), but deploying was kind of nightmerish, for what I understood Docker wasn't at the time ready for being a deployment tool. Does Kubernetes fixes or extends Docker in this way

Think of them as different layers. If you're a front end web dev, it's sort of like SASS vs CSS: the former is a layer on top of the latter that makes it more powerful/convenient/easier to use.

At the bottom of the stack (most low level) is the Docker runtime. It knows how to run containers on the local machine. It can link them together, manage volumes, etc but at the core it is a single machine system. (That's probably why Docker, Inc has developed their proprietary orchestration tools like swarm).

Layered on top of that are container-native OSes like CoreOS. CoreOS provides facilities for running distributed containers on multiple physical nodes. It handles things like replication and restarting failed containers (actually fleet "units"). This is a huge improvement over vanilla Docker, but it's still pretty low level. If you want to run a real production application with dependencies it can be tedious. For example, linking together containers that run on different nodes. How does container A find container B (which may be running on any one of N nodes)? To solve this you have to do things like the Ambassador Pattern[1]. Any complex application deployment involves essentially building discovery and dependency management from scratch.

Layered on top of this is Kubernetes (it runs on CoreOS but also Ubuntu and others). As said elsewhere in this post, k8s provides an opinionated workflow that allows you to build distributed application deployments without the pain of implementing things like low-level discovery. You describe your application in terms of containers, ports, and services and k8s takes care of spawning them, managing replica count (restarting/migrating if necessary) and discovery (via DNS or environment variables).

One of the very convenient things about k8s (unlike vanilla Docker) is that all containers within a pod can find each other via localhost, so you don't have to maintain tedious webs of container links. In general it takes the world of containerization from "Cool technology, but good luck migrating production over" to "I think we could do this!".

1. https://coreos.com/blog/docker-dynamic-ambassador-powered-by...

Re: Kubernetes V1 Released

#36

Post by justincormack »

jacques_chester wrote: post #28

Interesting to see IBM placing a bet each way by joining the new foundation, seeing as they're already in the Cloud Foundry Foundation. Edit: and I see the Cloud Foundry Foundation logo on the Cloud Native Foundation homepage. It's Foundations all the way down. (Disclaimer: I work for another CFF member, Pivotal).

Its pretty orthogonal to cloud foundry, which is a composite infrastructure, while these are lower level products that can be used to build PaaS.

Re: Kubernetes V1 Released

#37

Post by arianvanp »

TheIronYuppie wrote: post #26
arianvanp wrote: post #10

I'm hoping for ACI support soon so that I can use rkt instead of docker. :-)

I have good news for you :) https://blog.kismatic.com/running-rkt-on-kubernetes/ Full Disclosure: I work at Google on Kubernetes

Yes you can use rkt for docker images, but I want to be able to use ACI's. which doesn't seem possible yet[0].

But awesome that there's at least some support! :D

[0] - https://github.com/GoogleCloudPlatform/kubernetes/issues/720...

Re: Kubernetes V1 Released

#39

Post by bkeroack »

StevePerkins wrote: post #3

Can anyone recommend a good "Consultant's", "Solutions Architect's", or "Top-Right Quadrant on a Silly Gardner Chart" overview of how Kubernetes competes or cooperates with Mesos? It feels like there's quite a bit of dense conceptual reading you have to plow through before you can even start to talk about what these things do.

To add to the others, in a nutshell:

- Mesos is a generalized, low level framework for distributing workloads over multiple nodes. It provides mechanism not policy. Therefore it requires quite a bit of up-front work to build something usable for any given application.

- Kubernetes is an opinionated cluster execution tool. It provides tools and a curated workflow for running distributed containerized applications. It's generally pretty quick and easy to get running.

- Mesos has a rich, resource-aware task scheduler. You can specify that your application requires X CPU units and Y RAM units and it will find the optimum node to run the task on.

- By contrast, the Kubernetes scheduler currently is rather dumb[1]. There's no way to specify the expected resource utilization for pods, and the scheduler simply tries to spread out replicas as much as possible throughout the available nodes.

People are (rightly) excited about things like Mesosphere which could allow the best of both worlds: the ease and API of Kubernetes with a powerful Mesos resource scheduler, not to mention nice-to-haves like a Web UI with pretty visualizations.

You can now cut me a check for 50% of the consulting revenue you get from this information. :)

1. The scheduler is intentionally simple and pluggable, to allow improvements easily in the future. My statements only apply to the current state of Kubernetes as deployed today.

Re: Kubernetes V1 Released

#40

Post by throwaway1979 »

amouat wrote: post #29
throwaway1979 wrote: post #22

Earlier quoted context omitted.

I've been playing with Swarm and like what I've seen so far. WRT Kubernetes, on a platform other than GCE, is Flannel required for networking?

I think you just need to provide a flat networking infrastructure where all nodes get their own IP and can reach each other. So you can swap flannel for project calico or your own setup if you like.

I thought each host needs an entire /24 subnet, and the pods that run on the host get individual IP addresses. Am I mistaken?
Post reply on HN