Re: [kubernetes-users] Virtual Kubelet Working Group Proposal

[David Oppenheimer]

We're just in the process of spinning up a multitenancy working group. How would you feel about rolling virtual kubelet into that group, rather than starting a new group?

On Thu, Dec 14, 2017 at 2:35 PM, 'Ria Bhatia' via Kubernetes user discussion and Q&A <kubernet...@googlegroups.com> wrote:

Hi Everyone!  

  

I'm Ria Bhatia, a Program Manager within Microsoft Azure. I work on Azure Container Instances (ACI) but specifically I've been working on the ACI Connector. The connector allows customers to spin out container instances from their Kubernetes clusters, which gives them the benefits of per second billing and virtually unlimited compute resources. We've already seen a lot of interest from customers because they don't want to manage their worker nodes, but instead they want to focus on building and deploying their containerized applications. The possibility of eliminating the need to manage agents, not just masters, is exciting and wanted by customers.  

  

After releasing ACI we saw a shift in the cloud market, with Hyper.sh forking off our ACI Connector code, and then Amazon releasing Fargate, which is their version of container instances within the cloud. We realized there was an opportunity to help the other cloud providers connect their pods as a service, platforms, to clusters. Therefore we released a new community and pluggable version of the ACI Connector, named Virtual Kubelet and it's currently hosted here: https://github.com/virtual-kubelet/virtual-kubelet  

 

As a result, I'm proposing for the creation of a "Virtual Kubelet" working group where all relevant cloud providers and interested parties can help guide and design the future of "serverless" Kubernetes. Through Virtual Kubelet we can conform on the design for how customers will interact and create applications that directly deploy to Kubernetes without any extra thought on the underlying infrastructure.   

 

Mission statement: Design and build a consensus around how users interact with pods as the base layer of infrastructure within Kubernetes. Create an experience so all cloud providers have a consistent and innovative interface for connecting Kubernetes to their pods as a service, platforms.   

 

Thanks,  

Ria

 

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[Jessica Frazelle]

I’m not sure it fits there it might be more suited under something with apps.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzeagnjXbz47Sxn%3D9PWu079iRzvOgEYBxEBEaN7-7V1ztw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu

[David Oppenheimer]

IMO serverless containers (or pods as a service or whatever) falls into multitenancy because that is the underlying technology that is generally used to implement it. I think the discussions of multitenancy and serverless containers will become inextricably linked and we should do handle them in the same working group. For example what does a Kubernetes system where users can't see nodes look like from the user and system perspective. That question arises in high-isolation multitenant configurations even without true serverless containers (like OpenShift Online, which essentially hides nodes as part of providing a multitenant cluster), so I think we will have to address it for multitenancy anyway.

Just my opinion, happy to hear more...

On Thu, Dec 14, 2017 at 4:11 PM, Jessica Frazelle <m...@jessfraz.com> wrote:

I’m not sure it fits there it might be more suited under something with apps.

On Thu, Dec 14, 2017 at 19:02 'David Oppenheimer' via Kubernetes developer/contributor discussion <kubernetes-dev@googlegroups.com> wrote:

We're just in the process of spinning up a multitenancy working group. How would you feel about rolling virtual kubelet into that group, rather than starting a new group?

On Thu, Dec 14, 2017 at 2:35 PM, 'Ria Bhatia' via Kubernetes user discussion and Q&A <kubernetes-users@googlegroups.com> wrote:

Hi Everyone!  

  

I'm Ria Bhatia, a Program Manager within Microsoft Azure. I work on Azure Container Instances (ACI) but specifically I've been working on the ACI Connector. The connector allows customers to spin out container instances from their Kubernetes clusters, which gives them the benefits of per second billing and virtually unlimited compute resources. We've already seen a lot of interest from customers because they don't want to manage their worker nodes, but instead they want to focus on building and deploying their containerized applications. The possibility of eliminating the need to manage agents, not just masters, is exciting and wanted by customers.  

  

After releasing ACI we saw a shift in the cloud market, with Hyper.sh forking off our ACI Connector code, and then Amazon releasing Fargate, which is their version of container instances within the cloud. We realized there was an opportunity to help the other cloud providers connect their pods as a service, platforms, to clusters. Therefore we released a new community and pluggable version of the ACI Connector, named Virtual Kubelet and it's currently hosted here: https://github.com/virtual-kubelet/virtual-kubelet  

 

As a result, I'm proposing for the creation of a "Virtual Kubelet" working group where all relevant cloud providers and interested parties can help guide and design the future of "serverless" Kubernetes. Through Virtual Kubelet we can conform on the design for how customers will interact and create applications that directly deploy to Kubernetes without any extra thought on the underlying infrastructure.   

 

Mission statement: Design and build a consensus around how users interact with pods as the base layer of infrastructure within Kubernetes. Create an experience so all cloud providers have a consistent and innovative interface for connecting Kubernetes to their pods as a service, platforms.   

 

Thanks,  

Ria

 

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzeagnjXbz47Sxn%3D9PWu079iRzvOgEYBxEBEaN7-7V1ztw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[David Oppenheimer]

Multitenancy is about how mutually untrusting users and applications can securely and efficiently share a single cluster.

Multi-cluster is (to first approximation, in my mind, YMMV) about how to manage multiple clusters and applications that run on them.

On Thu, Dec 14, 2017 at 4:23 PM, Sen Han <hanse...@gmail.com> wrote:

How is the multitatency working group differ than the multi--cluster sig?

On Thu, Dec 14, 2017 at 7:11 PM, Jessica Frazelle <m...@jessfraz.com> wrote:

I’m not sure it fits there it might be more suited under something with apps.

On Thu, Dec 14, 2017 at 19:02 'David Oppenheimer' via Kubernetes developer/contributor discussion <kubernetes-dev@googlegroups.com> wrote:

We're just in the process of spinning up a multitenancy working group. How would you feel about rolling virtual kubelet into that group, rather than starting a new group?

On Thu, Dec 14, 2017 at 2:35 PM, 'Ria Bhatia' via Kubernetes user discussion and Q&A <kubernetes-users@googlegroups.com> wrote:

Hi Everyone!  

  

I'm Ria Bhatia, a Program Manager within Microsoft Azure. I work on Azure Container Instances (ACI) but specifically I've been working on the ACI Connector. The connector allows customers to spin out container instances from their Kubernetes clusters, which gives them the benefits of per second billing and virtually unlimited compute resources. We've already seen a lot of interest from customers because they don't want to manage their worker nodes, but instead they want to focus on building and deploying their containerized applications. The possibility of eliminating the need to manage agents, not just masters, is exciting and wanted by customers.  

  

After releasing ACI we saw a shift in the cloud market, with Hyper.sh forking off our ACI Connector code, and then Amazon releasing Fargate, which is their version of container instances within the cloud. We realized there was an opportunity to help the other cloud providers connect their pods as a service, platforms, to clusters. Therefore we released a new community and pluggable version of the ACI Connector, named Virtual Kubelet and it's currently hosted here: https://github.com/virtual-kubelet/virtual-kubelet  

 

As a result, I'm proposing for the creation of a "Virtual Kubelet" working group where all relevant cloud providers and interested parties can help guide and design the future of "serverless" Kubernetes. Through Virtual Kubelet we can conform on the design for how customers will interact and create applications that directly deploy to Kubernetes without any extra thought on the underlying infrastructure.   

 

Mission statement: Design and build a consensus around how users interact with pods as the base layer of infrastructure within Kubernetes. Create an experience so all cloud providers have a consistent and innovative interface for connecting Kubernetes to their pods as a service, platforms.   

 

Thanks,  

Ria

 

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzeagnjXbz47Sxn%3D9PWu079iRzvOgEYBxEBEaN7-7V1ztw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu

--

You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Brian Grant]

+SIG Node

On Thu, Dec 14, 2017 at 4:02 PM, 'David Oppenheimer' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

We're just in the process of spinning up a multitenancy working group. How would you feel about rolling virtual kubelet into that group, rather than starting a new group?

Or SIG Node. 

On Thu, Dec 14, 2017 at 2:35 PM, 'Ria Bhatia' via Kubernetes user discussion and Q&A <kubernetes-users@googlegroups.com> wrote:

Hi Everyone!  

  

I'm Ria Bhatia, a Program Manager within Microsoft Azure. I work on Azure Container Instances (ACI) but specifically I've been working on the ACI Connector. The connector allows customers to spin out container instances from their Kubernetes clusters, which gives them the benefits of per second billing and virtually unlimited compute resources. We've already seen a lot of interest from customers because they don't want to manage their worker nodes, but instead they want to focus on building and deploying their containerized applications. The possibility of eliminating the need to manage agents, not just masters, is exciting and wanted by customers.  

  

After releasing ACI we saw a shift in the cloud market, with Hyper.sh forking off our ACI Connector code, and then Amazon releasing Fargate, which is their version of container instances within the cloud. We realized there was an opportunity to help the other cloud providers connect their pods as a service, platforms, to clusters. Therefore we released a new community and pluggable version of the ACI Connector, named Virtual Kubelet and it's currently hosted here: https://github.com/virtual-kubelet/virtual-kubelet  

How much of the Pod feature set, semantics, behaviors, APIs, etc. are supported by this implementation? For example, does it support exec? Multiple containers per pod? Volumes and other resources shared across containers? Routable Pod IPs within the cluster? Core metrics?

Similar questions for the Node.

 

 

As a result, I'm proposing for the creation of a "Virtual Kubelet" working group where all relevant cloud providers and interested parties can help guide and design the future of "serverless" Kubernetes. Through Virtual Kubelet we can conform on the design for how customers will interact and create applications that directly deploy to Kubernetes without any extra thought on the underlying infrastructure.   

 

Mission statement: Design and build a consensus around how users interact with pods as the base layer of infrastructure within Kubernetes. Create an experience so all cloud providers have a consistent and innovative interface for connecting Kubernetes to their pods as a service, platforms.   

 

Thanks,  

Ria

 

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzeagnjXbz47Sxn%3D9PWu079iRzvOgEYBxEBEaN7-7V1ztw%40mail.gmail.com.

[Jessica Frazelle]

Sounds good to me. Just you could also use virtual-kubelet to do literally anything. It’s just an interface. So if someone were to make a “host or bash” one and fill in all the go interfaces for create pod etc, to do os.Exec something on the host, then it would run on the host. “Serverless” is just how it was worded so people understand it but the interface is just:

```

// Provider contains the methods required to implement a virtual-kubelet provider.
type Provider interface {
// CreatePod takes a Kubernetes Pod and deploys it within the provider.
CreatePod(pod *v1.Pod) error

// UpdatePod takes a Kubernetes Pod and updates it within the provider.
UpdatePod(pod *v1.Pod) error

// DeletePod takes a Kubernetes Pod and deletes it from the provider.
DeletePod(pod *v1.Pod) error

// GetPod retrieves a pod by name from the provider (can be cached).
GetPod(namespace, name string) (*v1.Pod, error)

// GetPodStatus retrievesthe status of a pod by name from the provider.
GetPodStatus(namespace, name string) (*v1.PodStatus, error)

// GetPods retrieves a list of all pods running on the provider (can be cached).
GetPods() ([]*v1.Pod, error)

// Capacity returns a resource list with the capacity constraints of the provider.
Capacity() v1.ResourceList

// NodeConditions returns a list of conditions (Ready, OutOfDisk, etc), which is polled periodically to update the node status
// within Kuberentes.
NodeConditions() []v1.NodeCondition

// OperatingSystem returns the operating system the provider is for.
OperatingSystem() string
}
```

So anyone could really implement anything they wanted.

[Dawn Chen]

Serverless is one of the directions for Kubernetes, and Virtual Kubelet could be one of designs / implementations underneath to help us to achieve that. Can we start with a proposal / request with sig-node first, instead of firing a new workgroup?

[Tim Pepper]

On Thursday, December 14, 2017 at 4:30:29 PM UTC-8, David Oppenheimer wrote:

Multitenancy is about how mutually untrusting users and applications can securely and efficiently share a single cluster.

While I get this rationale, it still feels unnatural to me.

This was discussed briefly earlier to day in the community meeting as the virtlet demo spawned a fair bit of side discussion in the Zoom Group Chat.

Joe Beda summed things up with: Seems like we have 3 things:

1) Running containers in VMs

2) Running VMs in containers

3) Bridging k8s to non-node based infra

Across this set there's a common move to do things beyond the simple node>pod>container tradition.  I see this ultimately as an effort to better abstract resource consuming workloads (which could be a growing list of container, vm, vm-container, function, etc.) and the associated abstraction of resource provider to be more than node-specific resources (cpu, ram, fpga, etc.), which has been happening below kubelet (CRI, CNI, CSI, CVI, etc) and now also above (virtual-kubelet).  To me this seems like it starts to overlap SIG node and scheduler and resource management wg folks more so than others.

--
Tim Pepper
Open Source Cloud Technologies Lead
VMware Open Source Technology Center

[Brian Grant]

I would like the privilege constraints of nodeless k8s to match those of multi-tenant clusters, where nodes can't be accessed by most users.

On Thu, Dec 14, 2017, 4:30 PM 'David Oppenheimer' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

Multitenancy is about how mutually untrusting users and applications can securely and efficiently share a single cluster.

Multi-cluster is (to first approximation, in my mind, YMMV) about how to manage multiple clusters and applications that run on them.

On Thu, Dec 14, 2017 at 4:23 PM, Sen Han <hanse...@gmail.com> wrote:

How is the multitatency working group differ than the multi--cluster sig?

On Thu, Dec 14, 2017 at 7:11 PM, Jessica Frazelle <m...@jessfraz.com> wrote:

I’m not sure it fits there it might be more suited under something with apps.

On Thu, Dec 14, 2017 at 19:02 'David Oppenheimer' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

We're just in the process of spinning up a multitenancy working group. How would you feel about rolling virtual kubelet into that group, rather than starting a new group?

On Thu, Dec 14, 2017 at 2:35 PM, 'Ria Bhatia' via Kubernetes user discussion and Q&A <kubernet...@googlegroups.com> wrote:

Hi Everyone!  

  

I'm Ria Bhatia, a Program Manager within Microsoft Azure. I work on Azure Container Instances (ACI) but specifically I've been working on the ACI Connector. The connector allows customers to spin out container instances from their Kubernetes clusters, which gives them the benefits of per second billing and virtually unlimited compute resources. We've already seen a lot of interest from customers because they don't want to manage their worker nodes, but instead they want to focus on building and deploying their containerized applications. The possibility of eliminating the need to manage agents, not just masters, is exciting and wanted by customers.  

  

After releasing ACI we saw a shift in the cloud market, with Hyper.sh forking off our ACI Connector code, and then Amazon releasing Fargate, which is their version of container instances within the cloud. We realized there was an opportunity to help the other cloud providers connect their pods as a service, platforms, to clusters. Therefore we released a new community and pluggable version of the ACI Connector, named Virtual Kubelet and it's currently hosted here: https://github.com/virtual-kubelet/virtual-kubelet  

 

As a result, I'm proposing for the creation of a "Virtual Kubelet" working group where all relevant cloud providers and interested parties can help guide and design the future of "serverless" Kubernetes. Through Virtual Kubelet we can conform on the design for how customers will interact and create applications that directly deploy to Kubernetes without any extra thought on the underlying infrastructure.   

 

Mission statement: Design and build a consensus around how users interact with pods as the base layer of infrastructure within Kubernetes. Create an experience so all cloud providers have a consistent and innovative interface for connecting Kubernetes to their pods as a service, platforms.   

 

Thanks,  

Ria

 

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzeagnjXbz47Sxn%3D9PWu079iRzvOgEYBxEBEaN7-7V1ztw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzfnuMEB8YTGJ7xjqXOhcn%2B%2BWtOm3spFAdLeFPyQJDcynw%40mail.gmail.com.

[Tim Hockin]

While I see the desire for a virtual interface here, I want to urge caution about force-fitting APIs that we're never designed for the particular purpose.

That said, sig-node seems like the best fit for me.  I think it is not necessary to make a working group for every such topic.  Just discuss it and hack on it.

--

You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.

To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/17321ef6-379a-4853-9d85-8b9fd9efe881%40googlegroups.com.

[Quinton Hoole]

+1 to sig-node

On Thu, Dec 14, 2017 at 5:53 PM, 'Tim Hockin' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

While I see the desire for a virtual interface here, I want to urge caution about force-fitting APIs that we're never designed for the particular purpose.

That said, sig-node seems like the best fit for me.  I think it is not necessary to make a working group for every such topic.  Just discuss it and hack on it.

On Dec 14, 2017 5:38 PM, "Tim Pepper" <tpe...@vmware.com> wrote:

On Thursday, December 14, 2017 at 4:30:29 PM UTC-8, David Oppenheimer wrote:

Multitenancy is about how mutually untrusting users and applications can securely and efficiently share a single cluster.

While I get this rationale, it still feels unnatural to me.

This was discussed briefly earlier to day in the community meeting as the virtlet demo spawned a fair bit of side discussion in the Zoom Group Chat.

Joe Beda summed things up with: Seems like we have 3 things:

1) Running containers in VMs

2) Running VMs in containers

3) Bridging k8s to non-node based infra

Across this set there's a common move to do things beyond the simple node>pod>container tradition.  I see this ultimately as an effort to better abstract resource consuming workloads (which could be a growing list of container, vm, vm-container, function, etc.) and the associated abstraction of resource provider to be more than node-specific resources (cpu, ram, fpga, etc.), which has been happening below kubelet (CRI, CNI, CSI, CVI, etc) and now also above (virtual-kubelet).  To me this seems like it starts to overlap SIG node and scheduler and resource management wg folks more so than others.

--
Tim Pepper
Open Source Cloud Technologies Lead
VMware Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/17321ef6-379a-4853-9d85-8b9fd9efe881%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewaABhnjvwzdxYdSOcCTeDUgAVSsX1s7ZFyOXJDNt3vVHg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Quinton Hoole
qui...@hoole.biz

[Michael Taufen]

+1 sig-node 

On Fri, Dec 15, 2017 at 8:56 AM, Quinton Hoole <qui...@hoole.biz> wrote:

+1 to sig-node

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewaABhnjvwzdxYdSOcCTeDUgAVSsX1s7ZFyOXJDNt3vVHg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Quinton Hoole
qui...@hoole.biz

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAL5aO5PpEG2ETwD6de8yjGgFbWQiGr1t%3DATNpAzjzh%3Dojy-yaw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael Taufen

Google SWE

[Eswar Bala]

Very interested on how this is evolving. We are determining the integration with EKS and Fargate and what the node based workflows in Kubernetes means in this world. 

On Friday, December 15, 2017 at 9:49:52 AM UTC-8, Michael Taufen wrote:

+1 sig-node 

On Fri, Dec 15, 2017 at 8:56 AM, Quinton Hoole <qui...@hoole.biz> wrote:

+1 to sig-node

On Thu, Dec 14, 2017 at 5:53 PM, 'Tim Hockin' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

While I see the desire for a virtual interface here, I want to urge caution about force-fitting APIs that we're never designed for the particular purpose.

That said, sig-node seems like the best fit for me.  I think it is not necessary to make a working group for every such topic.  Just discuss it and hack on it.

On Dec 14, 2017 5:38 PM, "Tim Pepper" <tpe...@vmware.com> wrote:

On Thursday, December 14, 2017 at 4:30:29 PM UTC-8, David Oppenheimer wrote:

Multitenancy is about how mutually untrusting users and applications can securely and efficiently share a single cluster.

While I get this rationale, it still feels unnatural to me.

This was discussed briefly earlier to day in the community meeting as the virtlet demo spawned a fair bit of side discussion in the Zoom Group Chat.

Joe Beda summed things up with: Seems like we have 3 things:

1) Running containers in VMs

2) Running VMs in containers

3) Bridging k8s to non-node based infra

Across this set there's a common move to do things beyond the simple node>pod>container tradition.  I see this ultimately as an effort to better abstract resource consuming workloads (which could be a growing list of container, vm, vm-container, function, etc.) and the associated abstraction of resource provider to be more than node-specific resources (cpu, ram, fpga, etc.), which has been happening below kubelet (CRI, CNI, CSI, CVI, etc) and now also above (virtual-kubelet).  To me this seems like it starts to overlap SIG node and scheduler and resource management wg folks more so than others.

--
Tim Pepper
Open Source Cloud Technologies Lead
VMware Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/17321ef6-379a-4853-9d85-8b9fd9efe881%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewaABhnjvwzdxYdSOcCTeDUgAVSsX1s7ZFyOXJDNt3vVHg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Quinton Hoole
qui...@hoole.biz

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAL5aO5PpEG2ETwD6de8yjGgFbWQiGr1t%3DATNpAzjzh%3Dojy-yaw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.