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.
On Thu, Dec 14, 2017 at 19:20 David Oppenheimer <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected].
>>>> To post to this group, send email to [email protected].
>>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/kubernetes-dev/CAOU1bzeagnjXbz47Sxn%3D9PWu079iRzvOgEYBxEBEaN7-
>>> 7V1ztw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzeagnjXbz47Sxn%3D9PWu079iRzvOgEYBxEBEaN7-7V1ztw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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
>> <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>
>>
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
