Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2019 (San Diego), 22 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Cloud Provider Intro - Fabio Rapposelli, VMware & Nick Turner, Amazon

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

SIG Cloud Provider Intro - Fabio Rapposelli, VMware & Nick Turner, Amazon

The long-term goal of SIG Cloud Provider is to promote a vendor-neutral ecosystem for our community. New vendors providing support for Kubernetes should feel equally empowered to do so as any of today’s existing cloud providers. More importantly, SIG Cloud Provider is focused on ensuring a consistent and high-quality user experience across providers. The SIG acts as a central group for developing the Kubernetes project in a way that ensures all providers share common privileges and responsibilities. This intro session will begin with an introduction to the SIG activities in representing the collective interests of all participating cloud providers in the Kubernetes ecosystem, and help guide participants in how to become involved with SIG and to transition from specific cloud SIGs to Cloud Provider Working Groups.

https://sched.co/Uaht

A

Welcome everybody- this is say: club provider intro session and today we're gonna. Give you like an overview of. What's the club provider does and we're gonna be our lovely host for today, so my name is fabio riposte le or for vmware. They work in kubernetes for the past, I, don't know four or five years working mostly upstream, so you probably saw some so my PRS on vSphere. If you use vSphere, there's a pretty good chance that I wrote some of the code and we me there's Nick Turner from Amazon. You want to introduce yourself Nick.

B

My name is Nick Turner I work at AWS on eks and before that I worked at a couple of startups in Seattle and where are you? It was a user of kubernetes and now I'm a cloud provider. I guess.

A

Awesome, so the agenda for today is we're gonna. We just we want to make this as interactive as possible. So please feel free to like ask questions as if you get any questions you want to ask us just. Do it right away, don't wait until the end.

A

We have some slides we're going to go over so we're gonna talk about you know some logistics. First, we're gonna introduce the cig. We got going over one of the main projects that we have currently in the cig, which is the lot extraction and migration project and, at the very end, we're gonna offer some topics for a discussion. So if people have you know, question they haven't thought about just look at the slide. We're gonna give some. You know food for thought there, but again feel free to ask any questions.

A

Any time we'll be walking around with a microphone to give you a chance to ask your question to the microphone. So please raise your hand. Let me know if you have anything you want to ask us some rules of engagement. Please you know just be respectful, be kind we're here just to collaborate. No, you know no hard feelings with anybody, so just you know just be kind. That's really the only thing to keep in mind right now, and this is the Charter for siccola providers.

A

So if you never be exposed to sick cloud provider before this is what sick, liberal, sick club provider is all about, so sick law provider and it's going to the Charter right now, cyclop providers mission is to simplify, develop and maintain club or Club provider integrations as extensions or add-ons to kubernetes clusters. So what does that mean? So it means that we have. You know some of the things in the kubernetes ecosystem that we want to make sure our you know, working in concert with everything else happening in kubernetes course.

A

So, ideally, what we want to do is we want, to, you know, be able to leverage class, specific components and services with kubernetes. So if your cloud platform has some services that can be beneficial to kubernetes, we want to make sure you have all the integration points, all the api's. You need to use them effectively.

A

So we want to make sure that you know you have all the right abstractions, all the right api's to do the lifecycle management of those resources, so think of it you know, has you know a way to provisional balancers or you know, use your I. Don't know encryption keys from your cloud provider. We want to make sure you have the right abstraction, the right api's to use them and, last but not least, there's actually a very important part of the Sickler providers to ensure Ventor neutrality in the project.

A

There have been a lot of tensions before when all the effort with club providers was focused on kubernetes core. You know lots of tensions. Since you know, vendors have different agendas. Sometimes- and this you know the creation of Saqqara ensure that there's vendor neutrality in the kubernetes ecosystem itself. So we want to have make sure that we have a testing framework, a testing environment that is able to maintain that vendor neutrality across the board. So this is a very big focus of siccola provided these days.

A

So again, what is the Cygnus possible for common interfaces? All the things that we do in cyclop provider are meant to create this. You know this bays underlying interface for cloud providers to integrate with we also work with utter SIG's to you know, get to disco. Think of it, as you know, a way to integrate, for example, with state cluster life cycle. So cluster life cycle has projects around lifecycle of clusters, so we work with them to make sure that all the interfaces are. You know working in concert together so think of cluster API.

A

For example. That's one, a big! You know point of contact that we have with them. We want to make sure that you know clock controlling manager, which is a you know, curious core component is you know, work in and all the core controllers are managed. This is under the responsibility of the sig and we also kind of we're also the umbrella sig for all the projects that don't have that our club provider specifics and they don't have a specific six sponsoring them. So one big example that I could give you here is CSI.

A

So CSI is the storage, the common storage interface, the CSI spec itself is sponsored by six storage. So six storage is looking after the the spec of CSI itself, but not of the specific club provider. Implementations of it. So give an example. You know the AWS CSI implementation, it's not under six storage, because six storage doesn't want to have, you know, doesn't want to sponsor those efforts, so they are under state law provided right now and right now. The only counter example I can give.

A

You is cluster API, so cluster API has providers for specific platforms, ABS vSphere and others, and those are under six life cycle. So, depending on the governance of the sig itself, it can be either under that or if not, it will be collected under state cloud provider, and these are some of the sub projects we currently have under state law providers. So there's, as you can see, there's a bunch of you know: providers listed there with the name of the product itself, so this is a kind of an interesting distinction.

A

So you'll see that there's some names here, but you probably know that there are auto club providers that offer kubernetes integration, but they're not listed here. Why is that? So? These are the providers that decided to upstream their work.

A

So all these providers are listed under the six sub project list because they are part of the kubernetes six goetaborg, so basically they're under the CN CF umbrella, under the kubernetes umbrella, they're, not tied to their own vendor, vendor or goetaborg they're, basically just part of the upstream community and if you're a if you're a vendor if you're a club provider- and you want to move your code under that- please reach out to to us during one of the sig cloud provider meetings we'll be happy to accommodate.

A

We actually had a few of those top of my mind will be Alibaba that you know recently got moved under the urban age six org. We also have utter pride of that participate in the sig. But they're not you know comfortable to move those could their code for the club provider under the sick because of other reasons so either way just be engaged with us. Even if you don't want to move your code under other kubernetes on the club provider sick.

A

But it's important to have you on the same page, with what we're doing as part of the broader sig and now we're going to talk about the club provider. Section migration project and I'm gonna hand it off to Nick yeah.

B

So a little bit of background when, obviously when kubernetes began all of the cloud provider specific code was embedded in core and people quickly realized that this was a little bit untenable. We had all these cloud provider SDKs directly imported into the project and that caused started to cause significant code.

B

Bloat has more and more providers added themselves in so we're currently in the product process of removing that code from the kubernetes core codebase, but it's a very long process, so we were working on it last year, we're continuing to work on it next year, and so some of the benefits of this it's going to be easier to support new providers because they don't have to actually go through the process to be merged in entry providers can release whenever they want. They don't have to follow the kubernetes code releases and then I think the third.

B

The third benefit is just reduced bloat in core the the SDK is actually significantly bloat, some of the binaries like cubelet so and you can take a look at the removing entry providers kept for a little bit more information on that.

B

So one big piece of this extraction: migration is the cloud controller manager. So, as you might know, a lot of the loops in the cube controller manager right now have cloud provider specific code in them. So part of this extraction is breaking those out into a separate binary which would be the cloud controller manager, and so there is actually a kept which is in the process.

B

I think it's I'm, not sure I, don't think it's implementable yet, but we're getting there so we're trying to get there by the end of this year and basically the process that we will follow or the proposed process is so right now cube. Controller manager has a leader election lock. So if you have multiple cube controller managers running only one of them is the leader and actually acting on anything.

B

But when you break a number of controllers out of that binary, and then you try to perform an upgrade, you can imagine that as a new node comes up with this broken out binary. Those controllers that have been broken out. The cloud specific controllers aren't gonna, listen to the lock right, they're, just going to try to do they're just going to start acting on whatever resources they act on. So the the way around this is to introduce a new migration lock, which the broken out controllers will sort of obey. So you can see here.

B

The cute controller manager has two sets of controllers in it. It has the core controllers, which are continuing to watch the cube controller manager lock, and it has the broken out cloud. Controller managers still within the same binary and those guys are looking at the migration lock and then the next step of that migration would be to actually move the cloud.

B

The cloud controllers over to the cloud controller manager binary, and so when a new node comes up with those controllers, they will be looking at the migration lock as well, so that allows the process to happen without any conflict. There.

B

Questions on that.

A

If you have like any questions, just raise your hand, I'll gonna, walk over. You get a microphone. Yes,.

B

So you said yes.

A

About right now is the documentation project, so the idea is right now to get started with any club provider. You have to go and find your documentation right. You have to go search the internet, for you know how do I. You start up. You know my cluster or well how about operating my cluster on you know vSphere or anybody else or whatever else, whatever other providers. So right now we're trying to get in sync with sig Docs to make sure we have.

A

You know the right, Assad, the right side, lock the right set of expectations for provider that are listed under state cloud provider in terms of documentation. Have that standardized. So you know the benefit of being part of that your org be part of that be part of secure provider as a project is to leverage those. You know, synergies between all the various projects right and be part of the upstream community.

A

But you know if you feel like you're, you know you're you're, okay, with having your own documentation, your own repo, your own issues, your own, you know way of governance for your cloud provider. That's that's! Absolutely fine! That the kind of benefit you get from participating in the community is standardization, basically.

B

Extraction work so 2019 encompassed beginning with began. The migration out of tree and cloud providers were moved into the legacy cloud providers, repo and staging.

B

Towards the end of 2019, we're still working on the strategy, the migration strategy for a cloud controller manager and then 2020 should see the migration strategy become a little bit more battle tested and TBD. When cloud providers actually make the cut over, I will see- hopefully 2020 but maybe 2021 anything else. I.

A

Just want to add one thing: if you experience the KK repo.

B

We built it in tree. It was part of KCM, so now, with the AWS cloud provider, we just import the legacy cloud provider into our external binary and because legacy is sort of under kind of us, I would say soft code freeze and ideally we're just trying to accept bug fixes there. So that's our incentive to get it out to migrate that code out completely as soon as possible.

B

So maybe a little bit an opportunity for some discussion here.

B

What is a reasonable time line to fully remove entry providers is the first question and so also what is the state of existing cloud providers and they're out of tree providers if anybody wants to share or has any thoughts on that I.

A

Want to ask another question: I mean how many of you are using out of tree providers either be.

A

The current organization- so we talked about this before so how do you? How do you discover? How do you find out? You know what the providers are the documentation? How do you actually get this thing? You know off the ground.

A

So we previously had six specific sick, claw provider, specific SIG's like cig VMs, tikka, WS, cig, OpenStack and so on. So some of some of the people kind of, like you, know, I'm running, you know my cluster on VMware, so just go to cig VMware get all the information that I get identity for them.

A

We're gonna like briefly touch on that after, but you know, all these seats are now folded into siccola providers, so there's no longer a sick, VM or a ciggy ws meeting. We only have you know, provider specific means for that. So wonder if interview either as end users or you know, integrators or even vendors find this discoverability of information around how to run kubernetes on a specific law provider, find it difficult or it's hard to figure out how to understand hard to Google. Even yes,.

B

Is successful so we're gonna try to help with that as much as possible, but that's what every cluster operator is going to have to go through the.

C

Other thing is even for managed: kubernetes. There are a couple of subtle places: you're going to see changes so as an example.

C

Moved PV type for a gcep D on CSI, and so the olden old one will work, but you will now see this new option and there'll be a bunch of guidance about you know where possible. Please use the new type, not the old type.

A

Today, you this presentation, and tomorrow you want to get started. You know contributing to this first thing. First step join the meetings. We have a biweekly meeting on Wednesday right Wednesday and you know that is the best place to start. We do have obvious. Obviously we have open issues, so people can just look at them, but more importantly, is like to get on. We were what the what the worst stream is right, claw destruction of migration. It's it's a big topic right now.

A

It's probably where we need the most help at this very moment and it's gonna, be it's gonna, be huge impact on kubernetes as a whole. So it's actually a very interesting problem to solve, also a very complex problem to solve. So there's a lot of work there. That needs to be done and there's also separate meeting for that. You know, besides the main six o'clock provider meeting, there's also a cloud extraction and migration meeting specific for that. So that would be a very good.

A

You know starting point if you want to contribute to to the work here, there's also a lot of work in the cloud providers themselves. So every single cloud provider has a lot of work to do. It can be on the CCM itself. It can be on CSI, it can be on any other provider. So if you care a lot about one specific club provider or one specific part of a club provider, say storage on vSphere or storage at NWS or encryption provider, there's a lot of work to be done there too.

A

So plenty work needs to be done.