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

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Service Catalog Deep-Dive - Jonathan Berkhahn, IBM & Mateusz Szostok, SAP

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 Service Catalog Deep-Dive - Jonathan Berkhahn, IBM & Mateusz Szostok, SAP

Join us for a deep dive into how Kubernetes Service Catalog works behind the scenes. Starting with a quick overview of the architecture of Service Catalog, we'll also cover the operation of the Open Service Broker API that underpins Service Catalog. We'll cover some of the challenges we faced while bridging the different processing models between Kubernetes and the Open Service Broker API, and we will then look at more advanced scenarios and new features from the perspective of cluster operators, application developers and helm chart authors. You’ll come away with a solid understanding of how Service Catalog works and recommended workflows and practices for using it. Finally, if you're interested in contributing or using Service Catalog, come meet the maintainers and learn how!

https://sched.co/UagL

A

So hello, everybody nice to be here, I'm Otto, shows talk as Sonia software engineer at is AP labs, Poland on daily basis, I'm Kumar maintainer, but I'm also maintainer and culture of six Service Catalog. This is a deep dive session about Service Catalog. Yesterday we have intro session where Jonathan explain what Service Catalog is and why you would want one. During this session you will learn what is open service book API specification.

A

Next I will present the current status of Shirdi implementation. I want to also say a few words about our release process because we change it a little bit so I want to say how it affects you. Additionally, we briefly show you which new sub projects were added under the 6/3 color control.

A

Then we jump into proposal for service instance deletion and last but not least, we introduce you to our plan for upcoming code to auto 3 release. So, let's start, and let's start with open service block API specification, so this specification defines the REST API, which allows cloud in our case, kubernetes interact with service brokers. Service broker is a server somewhere on the internet that offers catalog of services. Service Catalog is a client implementation where you can register your broker.

A

As a result, you will have a one place which is unified and where you can find all of your services and what is service so service can be pretty much anything. A classical example is database. How do I get one? Do you remember the old approach where you were creating a ticket to infra team and waiting either it's resolved and then get your credentials back. It's not a way to go with cloud native work. We want to have something managed, but also automated and in ecosystem.

A

We have a DCP broker that broker you can register in service card. As a result, you will see gcp or fairing in your cluster, so you can say: hey create me a mysql database on the CP side and then get me back the credentials and you, as a user, don't care how its managed or maintained you can focus on writing your business application and it could be also extend to other use cases like subscribing to some api's, for example, as your broker allows you to subscribe to text analytics service, which is also cool.

A

You can create also your own broker. For example, in Kemah we created a broker which allows you to expose api's and events from some monoliths application into your cluster.

A

So, as I said, this specification is about the REST API s, so we communicated between service, catalog and brokers using rest calls. We have catalog endpoint. We have output to provision the service. We have am going to create a binding unbinding the provision and delete that and update that instance. So, as you can see, it's simple and awesome concept, but when you want to extend kubernetes, you should in a native way. Of course, you should add a new kinds and a controller manager which is watching those kinds and based on that execute some actions.

A

So in service catalog we added eight kinds. First of all, we created cluster service broker. When you want to register a broker in your platform, you need to create cluster service broker. In case of that kind, you will see services from given broker in the whole cluster, but what you can do also is to create a service broker. As a result, you will see services from that broker only in a given night space. As a side note, you can also define cluster restriction, so you can filter out some service classes from a given broker.

A

Ok, so when you register broker, then service catalogue, fetches services from from a given broker and represent them as their service classes and service plants in your cluster and service class, can be like MySQL and each service clan plan. Each service class has at least one plan and plan is like free, tier or Enterprise Edition, where you can adjust your database size right after that.

A

You can create a service instance for a given class, so service instance is like a physical MySQL installation and after that, you creating service binding to get your credential to that instance. So, as I said, surgical log extends kubernetes by adding new kinds, but how to answer that question I need to say that this project was started by Google guys almost three years ago. At that time we are able to extend kubernetes only using aggregate api server and who knows what it is. Okay, so I will briefly describe it.

A

Basically, if you are operating on the core resources, you are going for the main API server and your manifests are stored in the main etcd storage.

A

When it comes to extend that with aggregate API server, you need to deploy your server and have etcd storage, where your manifest will be stored, and it sounds ok, but we had a few problems when it comes to maintaining and developing Service Catalog. First of all, as I said, you need to write API server from scratch, so basically to write strategy for each of your kind and also DB connection you own a lot of code, and the problem is that this code is not directly connected with your business. Application.

A

Second thing is that if you only hold API logic, then you also own some core concepts like incrementing generation field, simply you duplicate CoreLogic, which is leads to some bugs and it's hard to follow best practices. The last thing I want to talk about is that in this approach you need to have etcd connection, so you need to have your HT cluster and maintain backups with and so on so forth.

A

So we have a new kid on the block sear these sear. These are right now in GA stage, so how hard could could be we've sear. This is like a child's play. You define name and version and, as a result, your card is registered in the main API server.

A

So anyone who crowd your kind and then this call goes directly through the main EPA server and your manifest are stored in the main API etcd storage. So it allows you to benefit from the implementation improvement of the general API server, which is really cool. So in the new Service Catalog version we get rid of the API server and it CD storage and replace that with this year the approach we also added webhook server, which allows us to intercept crud requests, so we can set some defaults or validate, manifests before storing them in etcd.

A

So right now we know the building blocks of new architecture, and now I need to answer how it did. How did we move our features? So at the beginning we collected all aggregate API server features on the slide. You see only the five, my most important ones and the whole story took us around five pounds. So it was hard to squeeze five months of work into 30 minute talk, so I will focus only how we substituted field selector in this year. The approach why?

A

Because, in my opinion, was the most problematic part and also it affects you as a user. So as introduction for those who don't know field selector allows you to fetch resources with the same field value. We strongly rely on such queries in our project. Unfortunately, you are not able to query theories using field selector. We need to find out some alternatives. Of course, there are some other options that we considered, but I will describe only that one that was finally implemented and you work with kubernetes.

A

So you know that we can query resources using label selector. So what we did, we simply copied those fields under labels. Entry and similar approach is also implemented in prowl, and what you need to know is that there are some restriction about labels values, so first off is limited to 63 characters and has strict rules about characters that are allowed at the beginning.

A

We forget about that, but now we are, they fixed that just by doing this shaft from given value as a result, we have always fixed number of characters and we are escaping not allowed characters by default. So previously we had a field selector run right now we have a label selector when you need to specify the label name and also label value. So if you are wearing resources from service catalog using field selector, please replace that with label selector, as I said, we don't have enough time to go through all of our migration scenarios.

A

But here you will find a recording from these years, cognitive conference, where talk about our migration approach in details and I, encourage you to watch that recording and now, let's go back to what we have already achieved. So exactly on the 3rd of October, we cut off the first beta release.

A

The purpose of the beta release is to get the feedback from the community as well as give you a chance to test Service Catalog in stage environments before the audit tree is officially released, and now we have the third battle release where a lot of things were already fixed and I need to say that we create a new one, because we need to fix the cleaner job.

A

Basically, right now we are not working on kubernetes 1.16, because in 1.16, duplicate API is where we moved from kubernetes and need to update our clients. So let's say a few words how those affect you. First of all, the old implementation is still available on odo to branch, and we support that implementation until July 2020. We provide back and security fixes for that implementation because we are supporting to version. At the same time, we had to adjust our pipeline just a little bit. Their release process from the master branch looks exactly as previously so.

A

Calm is from master I have two tags Connery and specific name for the comet. In case of the release. We are also pushing hand chart to registry using the catalog name, be aware that we also supporting the release from all the two branch, but here the release will duplicated duplicated.

A

Api server has the older two suffix, so it also applies to chart that is pushed to our registry and same thing applies to advocate binaries here here you have hand commands that can be used to install service catalog in given version, so from master is exactly as same as previously and in case of the old approach. We need to specify the order suffix, so we have already new implemented and we also created the migration job, which takes care of migrating your resources from a great API server to see the approach.

A

We integrated that job into our hand chart, so you can simply execute her maverick command and, as a result, you will have new service catalog on your server, but we also created the ducati documentation how to execute our migration binary manually. So in case you didn't install service catalog, using charts, be aware that you need to execute a sanity check before doing the migration. You cannot have any ongoing passing operation and also you cannot have any resources which are failed during the deletion process.

A

If you have sorry sources in your caster, you may run into some corner cases during the migration process. Nevertheless, I really encourage you to test the new silica lock and share the feedback with us. I can say that Kumar project already uses service Kellogg will share the implementation on the production environments.

A

Next topic, new sub projects under service catalog, so sometimes I go. We move to projects under our control. First one is mini broker. We are using it in official civic about the work for documentation and basically that broker is really nice for local development and testing scenarios. Second thing is: go client for service brokers. We are using. We use the client in our service, color controllers, and it's also right now under the kubernetes 6 organization. The last thing is that we finally migrated from duplicated kubernetes organ is a incubated organization to kubernetes 6.

A

So do not forget to update your 4th locate for projects location on your local machines. Now now it's time to jump into design issue. So as an introduction- and you say that, for example, you have a service instance and after that you created some service bindings that service instance after some time you decide. Ok, I, don't need that instance. So what I need to do simply delete that service instance, but the provision process will fail, because you still have some Associated service bindings to that service instance.

A

The problem is that the service instance is already marked for deletion and we cannot revert that state. As a result, you are not able to update a service instance or create a new service binding, so the current Buffay behavior is so-so, so there was already a lot of discussion about that problem. So around one month ago, we created a new proposal.

A

We describe the current problems that we have and gather all options that were previously discussed and show the accepted solution and the accepted solution is to add Cascade deletion, because we get a feedback from the most of our users. That users expect that deleting kubernetes resource results in total deletion of resources associated with with it. So, for example, you have deployment and when you delete deployment, then also underlying pods are also deleted. It's not exactly the same in Service Catalog, but we still decide to go with that approach.

A

So right now you have an option to specify flag during this fiscal log, installation and then Control Manager. We always perform the Cascade deletion. For your service instance is there any alternative. Other options is to deal with.

A

This issue is to implement the proper validation webhook, so we can reject the deletion request before reaching the main api server and if you use the service catalog and have some thoughts about it, just picture them with us under the issue about cascade deletion and almost the last point on my presentation- and I want to talk right now about our plans for audit to my stop. So, first of all, we want to work on our documentation enhancement. I want to be compliant with official guidelines.

A

We also want to clean up our structure, add more examples and also the our main with me, because it's a little bit outdated. Let me- and we want to show new things that were added during the developing process- yeah very important thing. We also want to be compliant with new, open service book API specification, CI, pipeline's cleanup and that's true. You already did a lot of work, a lot of things regarding CI pipelines, we added end-to-end and migration tests. We adjusted our body building pipelines on prowl and retina right now.

A

We are thinking about moving our release Python from Travis to prowl. So thanks to w, have more control over that process and, of course, add documentation about our our continuous integration flows, which will be really helpful for our new contributors.

A

Next thing: migrate, Service, Catalog resources under our control. Currently, our web website is controlled by one of our maintainer and we simply want to move it to something that is really connected with six. So under this six domain last thing, last being really important for us is also to have a final decision about the pod presses functionality. So, right now, when you are creating a service binding, we are fetching with credentials from broker and storing them in kubernetes secret. After that, you need to manually inject those secrets into your business application.

A

What we want to do is to do that in automated way. To do so, we need to we wanted to reuse pod present functionality, but read right now. Pod process are still in alpha state in kubernetes, so into sync, with syncope machinery and sick architecture about the future of those resources, and maybe we just simply move those in functionality under the sixth color control. But all of this custom is to be done before doing the find before announcing the final decision.

A

So as you can see a lot of things going on and if you, if you want to become the contributor, then just join our weekly cig meetings, it takes it takes place each Monday at 9:00 a.m. Pacific time, so it's 6 p.m. for Central, Europe, and here you have also some useful links for our homepage for github repo and links for our communication channels. The presentation is available on the coop concise, so you can download it from there and thank you for your time and now I'm open for your questions.

A

So the question was in which direction the cloud providers are going so if they want to invest time to support some dedicated brokers or if they want to go with dedicated operators right? Okay, so we still don't have the final decision about that and I need to say that we still have GCP brokers, other brokers, AWS brokers, present in ecosystem and they are still developed.

A

We have some contacts with DCP guys which are still developing that thing, because the main reason is that if you are developing some controllers, like operators, you can run them only in kubernetes ecosystem with service brokers is really agnostic, so you can have you can simply implement it only once and your offering will be available in the kubernetes on Cloud, Foundry and right now, even in SA P. There is something like service manager with which exposed services from s AP directly to Cloud, Foundry and also kubernetes.

A

So the main reason to invest time in service brokers is to be agnostic between your platform and currently we are just working Service Catalog. We are not so close to service brokers, but from my experience as a kheema developer, I can say that right now we still using a lot of brokers from a co system and they are still active.

A

Yeah get your point so basically, sir, this does not solve those problems. See. Are these solve problems with it? Is it with that you require that we required at the beginning its city connections, so you need to maintain some in C cluster in case of manage kubernetes platform and about your problem.

A

What you can do right now is to create a dedicated need space per user. That will provision some instance, because what you can do right now, you can create a service broker which is nice base code, and then you can also filter out some services that you don't want to expose to the end-user, and that's the that's the current thing that you can implement. But right now we didn't solve the Arabic issue.

B

A

But right now stealing kubernetes ecosystems, yeah. These are really promoted and you need to really have a specific case to use the aggregate epi server right. Basically, you will not.

A

You will generate additional load on your main API server, but, to be honest, it's not so big to have a problems with that and if you want to go with a great API, server is good for some corner connect some respects, if accused cases, when you want to change the some CoreLogic right and to adjust it a little bit or you want to still support the field. Selector queries or you want to have some additional generic sub resources. You sear this. You can only support status, scale and and I think that's it.

A

So only two sub resources on your card, but basically, if you will try the kubernetes recommendation, mostly it's good to go with sheer this approach because, as I said, it allows you to benefit from the main improvements in the general API server. Instead of doing a lot of work in the directly in your project,.

B

B

Yeah, that's true yeah! That's the sauce.

A

Yeah, that's also true to Tony for provisioning and mining actions and and still in the aggregate EPA's a very also going through the main API server. So you also generating some loss on the many PI server.

B

That's wrong: the other okay.

A

Okay, so basically mmm you know what opposites is are okay, so simply right now in a human project, we have something like so depending usage and our idea behind that is to say during the binding action you can already specify in which deployment functions or whatever those bindings will be, so those secrets will be are automatically injected.

A

So, as a result, you don't need to take care of somehow adjusting your deployments to have additional environments variable and you need to change it because your deployments stay at it as it as they are, and secrets are automatically available in your deployment. So right now we just using put press set to say: hey just injects those secrets from communities directly into your pot. As a result, you have environment variables from a given broker directly in your business application.

A

There is one problem with that approach that you need to know the name of the secret that still you need to know the exact name of the secret, so, for example, it will be host or user name password. We don't have any contract between our services. So if you provision service MySQL service from other and then you will replace that with demise Square from Google, those credentials may be different, but probably may be correct me if I'm wrong. There also opens but also open service book API, we'll work on that.

B

A

Any other questions.

A

Okay, so the yes, so first of all service catalog is still in like better fizz right. So we are, we don't have a fisheries wonderdog and right now we are doing the my songs and right now we currently we are implementing all the three license and what we did right now.

A

We use the subversion option to somehow say to our user: hey it's still beta, but right now in that beta, we have like an alpha version that say that current here the approach needs to be tested on your stage environments before we officially release all the three simple, only auto 3 release, which means that it's a bit about the stable beta that you can use on production clusters, but yeah, but these are two steps and you can read more about it using on some versioning site.

A

So you know that if we are adding additional topics better, then your inform user that do not use that implementation directly on your production servers, but still try it out on your some stage, environments and report, some issues and and I'm not quite sure I- don't want to do any promise, but yeah. We are working to get to underdo.

A

Few things needs to be adjusted, for example, still the pod press that needs to be defined. How we want to work on that or not, and also our documentation needs to be clean up before going to all the one.

A

Okay, so no more questions. Thank you very much for your time and see on the next cue. Come.