4 ms·

We're really excited to broaden customer choice and let people decide what container technology makes sense for their workloads. The CoreOS team has been amazin

We're really excited to broaden customer choice and let people decide what container technology makes sense for their workloads. The CoreOS team has been amazing in helping to ensure Kubernetes is flexible enough to support alternate runtimes starting with not just rkt, but a full scale implementation of all of Kubernetes (running on rkt). Thank you so much! Disclosure: I work at Google on Kubernetes.

zwischenzug 10y ago
I am interested in Google's plans for Kubernetes - is the plan to include unikernels in the aegis of Kubernetes' control?
- TheIronYuppie 10y ago
  Well, two things really: 1) It's definitely not a Google project. CoreOS just gave a great example of that (Redhat, Samsung, Huawei, IBM, Cisco, etc etc etc) 2) We plan on fully supporting OCI and any container technology that supports that interface should run without issue. So, to the extent that a unikernel runtime supported that, then you're good. There are, of course, many items to be sorted out (how do you provide underlying scheduling, how do you handle the functions that kubelet currently provides, how do you provide effective debugging, etc), but I'll leave that to smarter folks than I to work out :) Disclosure: I work at Google on Kubernetes
  - fh973 10y ago
    While CoreOS is not Google you should mention that Google Ventures is the leading investor in CoreOS.
    - TheIronYuppie 10y ago
      That's true, but it is totally and completely separate. While I know Google Venture folks, they do not share anything about investments (performance/strategy/etc) to the main product org.
gagdad 10y ago
What about LXC? Is there just no community interest for this feature?
- colemickens 10y ago
  I would hope/expect to see systemd-nspawn support before LXC directly.
- themgt 10y ago
  If you've ever looked at the underlying code of "LXC" it's basically a bunch of spaghetti scripts that utilize cgroups. It was awesome for its time, but it's really not something worth supporting in 2016 vs. the new container runtimes.
  - throw2016 10y ago
    This is extremely misinformed. When did you last look at it? Can you post some examples of the spagetti scripts mentioned? What features do the 'new 2016 container run times' have that the LXC project did not provide initially and does not have? Really? It's sad to see this level of dimissive reductive fud being used against the LXC project liberally and consistently especially here on HN to promote other container solutions. A quick visit to linuxcontainers.org or the LXC github repo will quickly and dramatically dispel such notions. The LXC project is written in C and has been in development since 2009 along with cgroup and namespace support in the kernel. It's mature, robust and easy to use. It provides advanced container networking options from veth to macvlan and supports aufs, overlayfs, btrfs, LVM thin, ZFS for snapshots and clones, since at least 2011. It was also the first to support unprivileged containers with its 1.0 release in 2013. It's this work that Docker was based on and its unfortunate the ecosystem far from highlighting the benefits they got many choose to downplay and misrepresent the LXC project leading to comments like the above. LXC is now on 2.0 with multiple improvements from proper display of cgroup controls and container resource usage inside containers with the lxcfs project to initial support for live migration. It is also significantly easier to use than single app containers especially for multiple processes and networking without needing to create custom process managers, run apps in specific ways or network workarounds. LXC runs the container OS's init in the container, Docker and others do not. There are reasons for both approaches. Hope for better informed discussions on Linux containers here.
otterley 10y ago
Does this mean k8s will be able to run pods directly via systemd-nspawn? I'm not completely sure what rkt buys us -- please fill me in.
- robszumski 10y ago
  rkt utilizes systemd-nspawn under the hood, but you need some additional features around that as well. The usage is explained pretty well in the architecture guide: https://coreos.com/rkt/docs/latest/devel/architecture.html https://coreos.com/rkt/docs/latest/devel/architecture.html

zwischenzug 10y ago

I am interested in Google's plans for Kubernetes - is the plan to include unikernels in the aegis of Kubernetes' control?

TheIronYuppie 10y ago
Well, two things really: 1) It's definitely not a Google project. CoreOS just gave a great example of that (Redhat, Samsung, Huawei, IBM, Cisco, etc etc etc) 2) We plan on fully supporting OCI and any container technology that supports that interface should run without issue. So, to the extent that a unikernel runtime supported that, then you're good. There are, of course, many items to be sorted out (how do you provide underlying scheduling, how do you handle the functions that kubelet currently provides, how do you provide effective debugging, etc), but I'll leave that to smarter folks than I to work out :) Disclosure: I work at Google on Kubernetes
- fh973 10y ago
  While CoreOS is not Google you should mention that Google Ventures is the leading investor in CoreOS.
  - TheIronYuppie 10y ago
    That's true, but it is totally and completely separate. While I know Google Venture folks, they do not share anything about investments (performance/strategy/etc) to the main product org.

gagdad 10y ago

What about LXC? Is there just no community interest for this feature?

colemickens 10y ago
I would hope/expect to see systemd-nspawn support before LXC directly.
themgt 10y ago
If you've ever looked at the underlying code of "LXC" it's basically a bunch of spaghetti scripts that utilize cgroups. It was awesome for its time, but it's really not something worth supporting in 2016 vs. the new container runtimes.
- throw2016 10y ago
  This is extremely misinformed. When did you last look at it? Can you post some examples of the spagetti scripts mentioned? What features do the 'new 2016 container run times' have that the LXC project did not provide initially and does not have? Really? It's sad to see this level of dimissive reductive fud being used against the LXC project liberally and consistently especially here on HN to promote other container solutions. A quick visit to linuxcontainers.org or the LXC github repo will quickly and dramatically dispel such notions. The LXC project is written in C and has been in development since 2009 along with cgroup and namespace support in the kernel. It's mature, robust and easy to use. It provides advanced container networking options from veth to macvlan and supports aufs, overlayfs, btrfs, LVM thin, ZFS for snapshots and clones, since at least 2011. It was also the first to support unprivileged containers with its 1.0 release in 2013. It's this work that Docker was based on and its unfortunate the ecosystem far from highlighting the benefits they got many choose to downplay and misrepresent the LXC project leading to comments like the above. LXC is now on 2.0 with multiple improvements from proper display of cgroup controls and container resource usage inside containers with the lxcfs project to initial support for live migration. It is also significantly easier to use than single app containers especially for multiple processes and networking without needing to create custom process managers, run apps in specific ways or network workarounds. LXC runs the container OS's init in the container, Docker and others do not. There are reasons for both approaches. Hope for better informed discussions on Linux containers here.

otterley 10y ago

Does this mean k8s will be able to run pods directly via systemd-nspawn? I'm not completely sure what rkt buys us -- please fill me in.

robszumski 10y ago
rkt utilizes systemd-nspawn under the hood, but you need some additional features around that as well. The usage is explained pretty well in the architecture guide: https://coreos.com/rkt/docs/latest/devel/architecture.html https://coreos.com/rkt/docs/latest/devel/architecture.html