 Hello all and welcome to this We're actually doing this live from Poop Con here in London and Andy is back east in the United States and he's Andy Goldstein is our principal software engineer. He's been working on OpenShift for a number of years So I'm gonna let him Introduce the subject of services, linkings and catalogs We've got a number of folks here sitting with me from Protobahn So I will let them talk through my microphone and the Q&A session starts What we're going to try and do here today is let Andy take the first 20 minutes or so to present The state of services, linkings and catalogs and how to get involved in it And how to help where the Trello cards are where the stuff is and GitHub and all of that And then we'll have Q&A via the chat room and if you just type it into chat We'll read back the question and if you happen to be in the room with me here You can actually talk live. So I'm gonna mute myself for now and let Andy take it away So thanks Andy for joining us today. All right. Thank you Diane. So my name is Andy Goldstein I am a principal software engineer with Red Hat. I'm the team lead for our cluster infrastructure team Which focuses on Kubernetes? so Within OpenShift are a big part of the foundation is Kubernetes. So today's talk will be covering Services linking and catalogs as they relate to both Kubernetes and OpenShift So here's what I'm going to talk about today services linking and catalogs. So for starters If you're deploying something into Kubernetes or OpenShift whether it's a series of microservices or a large Java application for example those things are going to be deployed using pods and a pod is just a collection of containers and pods come and go so You probably need some way to consistently reference Database or a web service or a memory cache that your microservices or your application need to talk to So that brings us to services. What is a service? It is an abstraction that allows us to not have to worry about pods that are transient and it instead gives us a consistent way to to reference Your database or your cache or whatever you're trying to talk to So a service inside of Kubernetes and OpenShift is something that sits in front of pods via a label selector and I'll have an example where you can see Some labels and how the service is able to select which pods it is going to communicate with The service has a static IP address, which is extremely useful for consistent Communications Additionally, we have DNS integration if you have that enabled in Kubernetes and it's also out of the box with OpenShift So rather than having to remember an IP address you can use DNS to communicate with your services and The service acts as a load balancer in front of the pods that it is it's sitting in front of and requests that go to that service are Delivered most of the time round Robin among the pods that sit behind it There are there is another use for services within the cluster as well You can use a service that instead of talking to pods or sitting in front of pods is used to Provide a link to an external or off cluster destination So an example would be let's say your IT department has an existing Oracle database or an existing web service that has been around since before you deployed OpenShift and You want to be able to Reference that service in the same manner that you would use if you were referencing a series of pods that are Fronted by a service and so in this case as a user or an administrator You would manually manage the end points that that service is Is sitting in front of instead of having a label selector that? Takes care of that for you automatically So here's an example service. I have a service here It lives in the namespace Andy It has a name of DB because it's a database service and then I have a selector That is going to match on two labels The first one is DB name and it wants to find pods with a DB name value of postgres And the second one is for the environment and we're looking for a production Pod and in addition to specifying a selector you specify at least one port and This makes sure that the service is listening on port 5 4 3 2 and it is targeting Port 5 4 3 2 inside of the containers or inside of the pods that it's it's sitting in front of So here's a graphical representation of what that might look like you'd have your DB service that gets a cluster IP address I picked one at random here 10 dot 0 dot 0 dot 15 and You'll see three pods two of them pods one and two have matching DB names and environment labels for postgres and prod and you can see each pod has a unique IP address The third pod has a different value for the environment label So in this particular example, the DB service is going to communicate with pods one and two but not pod three and To the right of the DB service I have listed what the DNS entry would look like by default for this particular service It's the name of the service DB followed by the name of the namespace or project Which in my example is Andy and then dot svc dot cluster dot local So how can you talk to a service there's two ways you can do it. I just mentioned DNS and There's one other mechanism, which is environment variables and Kubernetes and OpenShift will automatically create environment variables for you that allow you to To look up the host and the port of your service and these environment variables are Automatically created and automatically injected into your pods when they are created and started now There is an ordering issue. You do have to make sure that your service exists before The pod is created Otherwise the you won't have these environment variables accessible in the pod and that's why DNS has an advantage Because DNS is going to work anytime regardless of if you create the service first or if you create the pod first So how do we find services You can definitely run OC get services or cube control get services and this will list all the services in a single project Not super easy to make this work across projects. You can have it list services in every project, but that's going to give you everything and it's going to be hard to To filter out the weeds. It's not a curated list it's just literally every single service that you have access to will show up when you run that command across projects and Similarly where it's not a curated list if I did want to To expose one of my services so that other users could find it effectively if I wanted to publish it There's no command for doing that right now, which is why I have some question marks after OC there You could grant users read-only access to a project But even then the default policy for the viewer role I don't believe gives you access to to things like secrets if you needed them to to to communicate with a service for credentials and And doing this granting is it's pretty broad if I give somebody read-only access to my project they get to see pretty much everything in there and I would probably much prefer it to be more restrictive where I could explicitly say I have an etcd service that I want to share with other people But I have a postgres service that I want to keep to myself within my project So what's missing in services They only have the IP and the port or ports specified for communicating with them and there's no way to easily associate any sort of configuration details or credentials that you would need to use when communicating with a service and Case in point is username password that sort of thing You you don't have any environment variables or files or anything that represent those credentials unless you take the appropriate steps to get those into your pods Via secrets or however you plan to do it, but there's no way to associate that with a service right now So one thing that we're proposing is being able to link configuration details and secrets to a service and the proposed command that we have is OC link and So I have two examples here where I'm saying I would like to link a DB cred secrets to my DB service And I would like to link a DB config map to my DB service And what this will do is add a new annotation that contains a list of the The referenced items and this is just a proposal for right now It's it's a lot easier to prototype with the annotation than it is to modify the API and maybe one day assuming this is accepted We would get this to evolve to an actual field on the service itself So here's an example secret and config map item You've got the DB cred secret with the username and password and you've got the DB config map with some arbitrary data in there. I just happened to pick color of green What does it look like after I run OC link? You'll see that this is my service. That's the same Andy namespace and DB name But I've got some new annotations now. So after I run OC link, you would see these kubernetes.io References annotations and by itself. This doesn't doesn't really do much, but what we can do is service linking So I mentioned before that environment variables are automatically injected for all of the services that exist at the time that the pot is created And that's something that We are probably going to deprecate so that you have to be more explicit in which services a given pod depends on And so what we'd like to do with service linking is provide the ability to link Configuration credentials and services to basically anything that has a pod or a pod template So pods replication controllers deployment configs and open shift deployments from kubernetes Jobs demon sets and anything else that might come along as we grow So let's take an example deployment config this one's pretty basic I've stripped out some items that aren't relevant to this example, but I have a deployment config called front end it has To replicas I have a selector defined and I have a single container That's running the andy slash front end image whatever that happens to be and it exposes one port on 8080 So what would it look like to do linking here? I'd like to reuse the proposed link command and The example is OC link service slash DB DC slash front end and this would link the service and any references So that would be the config map and secret that I had in the example I'd like to bring those along with me so that when the service is linked to the deployment config we get that information automatically added without having to do any extra work and This linking could happen as environment variables or volumes and files I'm going to demonstrate just environment variables in this example So here's what the deployment config would look like after we run the linking with Some of the other irrelevant pieces removed You'll see that there's a new ENV section under my container and I've got five environment variables here I've got DB underscore host and DB underscore port which come from the service And then I've got the DB underscore username and password which come from the secret and DB underscore color which comes from the config map and so all of this just happens as a result of running OC link and now when the deployment config is Deployed and we have an actual pod or set of pods that come from it The code running in those pods can make use of these environment variables Just because it's a convention that we're attempting to establish So there's still a lot of things left to be done when it comes to thinking about service linking One big one is we'd like to find a way to do linking inside of templates So a template inside of OpenShift and hopefully eventually Kubernetes is a list of items Which could include things like services image streams build configs deployment configs individual pods, etc and right now there's no easy way to define a service in a template and define a pod or deployment config in the same template and Have a way to designate that the service should be linked to the pod And so that that's one item where we could use some help another one is Finalizing the environment variable and volume conventions and just what the user experience looks like around that a Couple more outstanding questions are should we do the server side? Should we do a client side if we do it client side? It is fairly easy to get the moving parts going But it means that every client would have to implement the same or similar logic Versus if we do it on the server then it's implemented in one place and all the clients can take advantage of it and then finally unlinking is Something like that needed and if so, what does it actually mean? Do we remove the environment variables in the files or or what? So definitely some items still to figure out there Which moves I'm going to move on to service catalogs now so what we're proposing is a curated list of Services and you can have one or more catalogs inside your cluster users or administrators would be able to Pick which services they want to publish to a catalog The catalogs would be able to display services across multiple namespaces or projects And so this solves the problem I highlighted before where if you run OC get services and you only see Either services in your namespace or services across multiple namespaces This solves that problem and the fact that users are publishing them means it is a curated list We want to provide the ability to list and search and then finally What good would a catalog be if we couldn't actually consume the services in that catalog? So what are we proposing for publishing a service to a catalog? OC create catalog entry give it a name in this case Andy DB I'm saying that I want the entry to reference the SVC slash DB service from my namespace I want to put it in the default catalog And I'm going to give it a description of Andy's DB service and this will create a catalog entry for that service and Here's a sample of what that might look like so you can see that the The name is filled in is Andy DB. The catalog is default It's got my description and then I have a reference field in here that references What namespace the service lives in what kind of resource it is in this case of service and the name of that particular resource which is DB and Similarly if I wanted to take a look at what service catalogs existed I could run OC get service catalogs and in this example you can see default finance and IT And then if I wanted to see what individual entries existed in a given catalog I could run OC get service catalog entries Default and then I would see Andy DB Which was the one that we just looked at and then I've got some other examples here for say Redis memcached and etc So how do you use a catalog entry? Well, because the Services or whatever is in the catalog can come from multiple namespaces and you may not have access to To get those resources from a given namespace We're doing something similar to persistent volume claims where we're having a service claim and the service claim is Resource that you would create that indicates your desire to use an entry from the catalog But it doesn't exactly give you The immediate ability to just reach into someone else's project and and get access to their data So here's my example OC create service claim My DB being the name and then I specify that I want it to come from the default catalog And I'd like to use the Andy DB entry So what happens when you create a claim? We will have some code running in a controller that processes the claim and The first thing that would happen is that claim would be evaluated to determine if it should be admitted or rejected and That could go a few different ways It could be an automated decision where you've got a policy of some sort that determines who's allowed to Who's allowed to create claims who's allowed to consume Catalog entry items from particular catalogs or it could be custom It could go through some sort of workflow process where you need to have some manual intervention Where a manager needs to approve a claim for example and finally once a claim is admitted It will be fulfilled in whatever manner is necessary based on the type of the entry that's in the catalog So here's an example Let's say I've got my catalog entry that we were looking at before for Andy DB and on the left I've got an Andy project that has the three resources that we've been discussing today so far the DB service the DB cred secret and the DB could big map and John here wants to create a service claim to use this particular entry from the catalog and so John creates that service claim and Once it is admitted the controller would go and create Something that looks just like what's in Andy's project. You'll have a my DB service a DB cred secret and a DB config map and these items represent basically copies of the data that is in Andy's project at that point in time and the The service itself would most likely be configured to point to Andy service so if you if you attempted to connect to the my DB service it would Just redirect or potentially be a C name over to the Andy service or to the DB service in the Andy project So I mentioned that there's different types of catalog entries Her entry references One of them could be service and that's the example that we just looked at where you would or the controller Would copy the service and any associated configuration and secrets It'll copy that information into new resources in the destination project. So that's where John's project got new resources with the data copied from Andy's project another type of reference could be a template so this would be a way to Publish a template. So let's say that I have a template that creates an etcd cluster for example and As I mentioned before if I don't want to necessarily give every user access to all of my templates I could pick this etcd template publish it to the catalog and then they would be able to Create a claim against that template and the system would provision that template for them in their project And then another type that we're considering is a service broker type and this is similar to what other cloud vendors provide where you can basically inject a set of Catalog entries into the catalog and then all of the provisioning and linking and unlinking and deprovisioning is handled by an external service broker So there are still a lot of to-dos and this is where we are really looking for community help and community input I'm going to be starting some design and prototyping and would definitely appreciate any help if anyone's interested in providing some assistance We are looking for feedback on the user experience So all of the examples that I presented in this presentation so far are not set in stone So we want to make sure that we get the best user experience both from the command line perspective and from the the web console Perspective, which I didn't even haven't even discussed yet. So any feedback on user experience would be extremely helpful Feedback on the service broker API we need help defining that so that we can make sure that that has a good user experience other things we need to figure out are TLS support so for example if you've got a an external service for or even an internal one And I and I create a claim and I get a new service for my project If I try to make a TLS connection to that service, it's probably going to have the wrong Hostname so there'll be a mismatch because I'm trying to talk to my service in my project when it's really The certificate is valid for a different project. So we need to figure that out Security is a big one figuring out who's allowed to publish to a catalog Who's allowed to consume various items or entries is something that we definitely need help with Multitenant networking if that is enabled then just Creating a C name for example from my new service to the original service is not going to work because most likely the The network won't allow those connections to go through so we need to figure out how to poke those holes appropriately and then finally just keeping data in sync if I have a config map or a secret and I go ahead and do a claim against that and then the original data changes say the password changes I'm not going to be made aware of that unless we figure out some way to handle that so These are a series of to-dos. I'm sure there's probably a lot more and we definitely will appreciate any community help we can get so in closing I want to thank everybody for listening and The first link I have on the page here is the Trello card that we have for the Proposal that exists upstream in the Kubernetes repository The second link is to our open shipped origin code base and the third link is to Kubernetes and I want to thank everybody again for listening and I will Turn it over to questions at this point All right. Thank you Andy There's one question right off the bat from rich carpenter around the security stuff And he says in the example of the DB service claim would the project claim making the claim need to get their own Credentials seems it may be a security risk to have any other projects making the claim have access to the same credentials as the creator of the service right, so we definitely appreciate that and what we are thinking is that there will probably be multiple phases and For starters we most likely would just have the credentials credentials be shared but We are definitely interested whether it's with template provisioning or the service broker model or Another one that we've yet to come up with We do want to to provide the ability to Generate per whether it's it's per pod or per project or what the appropriate scope is We want to be able to generate a unique credentials so that not everybody is sharing the same single set And since I'm wondering Andy if you could pull up the Trello card that you mentioned and just show that on the screen because maybe not everybody is aware of our Process from the community point of view of how to comment on Trello cards Sure, give me just a second to pull that up here Yes, hi, Andy. This is Christian with him or none from for one so I would like to know when When would be a by level the? Service worker support What was the question when will we have service burger support? Yes, I Don't have an ETA on that at this point we need to define the API and then I There are still several moving pieces to figure out For starters, there is no code for any of this right now. It's all theoretical. So I am planning to start prototyping very soon and Like I said, we will definitely appreciate any input and collaboration on any part of this including the service broker Sure Hello, Andy. This is Julian Fernandez from from Islam and I want to know It's a question about security. How can you manage your own service in a public service catalog? For example, if I want to change something in something in a sacred or in a conflict data How can I change that and reference in every everyone who is claiming that service? Right. So that was one of the the bullets I had on my next to last slide with the items that we have to still figure out So keeping all of that data in sync We don't have a Pathforward yet or a solution yet, but it is definitely an item that we are aware of and we will be working to to address Okay, another question within your proposal. I miss some information about the security policies of One service in a service catalogue for example If I upload my service to a service for example the default service catalogue Everyone can change and can update that service. Oh, you know, I suppose that not so maybe we we need some security config to We need to add add some security config to that service Yes, I definitely agree. I if you're looking at the screen now I have the proposal that I've submitted to Kubernetes and highlighted is security and figuring out what to do there. I agree 100% with what you said and I think what's probably going to happen is there will be an initial round of prototyping just to make sure that what's in the proposal is feasible and and that probably won't include security to start off with but we obviously Wouldn't want to really ship anything without security built-in. So I will be planning to have discussions with with other members of our teams who specialize in security especially around access control and Kubernetes and OpenShift and It is something we need to solve All right, let me just check and see it looks like there's a couple other questions popping into the chat Let's see from Leak Helcott It's curious as to whether there is a vision for a federated service catalogue wherein Services are shared across the OpenShift deployments So I guess I need some clarification on that is that Question about if you have multiple OpenShift clusters, would you are you asking for a way to Have entries in one catalogue in one cluster Be made available to another cluster He's saying yes. Okay That wasn't something that I had been thinking about but if that's something that you are interested in It would definitely appreciate some more details on that use case We'll see if he pipes in with a little bit more Mike and that certainly can be Submitted as feedback to the Trello card that I have on the screen right now It could be submitted as feedback to the proposal that's inside That the Trello card links to so either of those would be a valid way to To get that feedback to us He's now saying sure he's built the Cisco inter-cloud service catalogue and he'll he'll do his worst to help you out Thanks, Lee There's another question from Mike Can there be a service or a similar object that is referenced by other projects instead of copied? So you could create an object as a DB dev DB connection or a prod D DB And publish it and other projects could reference it in their project And it's a very long-winded one, so I'm gonna keep going. Yeah, I'm reading it And I'm gonna find Mike and take him off mute Let's see Mike if you unmute yourself you can talk and add Some context to that question So I think that that question might probably needs a little bit more context of what you're trying to accomplish I can I can understand the question. So I don't have an answer right now I I think the goal here is just to avoid having lots and lots of copies of services in individual namespaces that all point back to an original service so that if the credentials change or they can take changes you don't have to To refresh that sort of thing I Think that's I Like that We just need to figure out if you do have the multi-tenant networking plug-in enabled a way to be able to To poke those holes appropriately and also from the the If you're writing an application or a microservice and you're deploying it to a project You obviously can can talk to whatever your firewall allows you to talk to but it's certainly easy to say I just want to go to the service or DNS name called DB and Don't have any it's not a fully qualified name and because of the way that DNS resolution works in the containers DB would be resolved to DB dot whatever your project is dot service dot cluster dot local Which obviously would require that you have a local service, but you can also Reference services by DNS name that don't belong to your project And the only issue or potential issue there would be if the multi-tenant networking plug-in doesn't allow you to make that cross project top So it's definitely something that's worth thinking about but I will say that you are not going to be allowed to Get access to secrets in another namespace or another project. So We you probably are still going to need to have a have to have a copy of that in your project locally right then I'm not seeing any other questions in the chat Looking around the room So Andy from your perspective, what's the best way? You mentioned Trello before of adding in use cases and comments on Trello Is that really the best way for people to contribute at this juncture? That is certainly a good way to do it I Like that just because it's it's not an email that's just sent to me that potentially gets missed And it allows all the members of the community to see what people are interested in and collaborate on it So either the Trello card or the the Kubernetes pull request would work for me Perfect. So if you could throw that last slide up again, just so we'll end on having those those links there for everybody to share Give me just a second And I I think I saw on that Trello page that this was a proposal that was in the works for 3.3 Yeah, so we are hoping to get something in for 3.3 and We are trying to figure out in addition to doing the prototyping We're trying to figure out where this code is ultimately going to live We would like to have it be something that users could run on Kubernetes as well as OpenShift but it It's probably not the service catalog portion of it is probably not something that would be considered a core Kubernetes feature edition and whereas linking I think is probably Has a better chance of getting into the core project So we just need to figure out the best way to deploy this and get it integrated into the cluster Whether that's Kubernetes or OpenShift and that's going to be part of the prototyping that's going on Awesome, well, thank you very much for taking the time to do this presentation today I think it's opened a lot of eyes. It's also an awful lot of interest in getting this work done sooner than later So I'm sure you'll get some comments back on that Trello card and a few volunteers to help you in your prototyping efforts and Once we've got a prototype up. I'd love to have you back to show it off on the As another Commons briefing in the not too distance future Definitely, I'd be happy to do that Let's see there may have been one more question that pops in Well, I think that's what we've got so thanks very much for coming today and Please reach out if you have more questions and join us on our weekly community meetups there Thursdays 10 to 11 on IRC channel for OpenShift-dev So that's that'll be tomorrow depending on where you are in the world. All right. Thanks again, and we'll talk to you all next week