 Hi there, I I'm glad to be home in Chicago I want to talk today about service service is one of the oldest APIs in all of Kubernetes in fact it was in the very first public commit in Kubernetes it existed as an API at that time in 2014 so almost 10 years Service is also one of the most widely used APIs in Kubernetes anybody here ever not used a service now Pretty much anybody who deploys workloads in kubernetes ends up using services. Why it does a lot of things Let me give you some examples. It does in cluster virtual service addressing With IP allocation It does out of cluster load balancer allocations including a bunch of affordances for a variant a number of variant Implementation it includes node port allocations and DNS names and service discovery and Name aliases for things that have nothing to do with kubernetes It also does health checking for load balancers in case your load balancer wants it or if it doesn't It also does back-end routing policies in topology It also does finding and grouping of endpoints automatically But if you don't like it automatically you can do it yourself It also does things like session affinity with a whole bunch of configuration And it has a bunch of configuration hints for on node implementation details. It also does port mappings Oh and simple firewalling. This is not an exhaustive list, but I'm running out of time so Service was designed to be simple We have this this congruent or not congruent a circled model that We designed to build for the way Kubernetes the services work, but you know what they say about good intentions So as Kubernetes is expanded 10 years now, we have accumulated a lot of functionality We have all sorts of stuff that has grown and more knobs and more sophistication. That's code for complexity The API that we've laid out almost 10 years ago is starting to limit how we can evolve but Kubernetes the project we have a strong commitment to compatibility and so That includes things like under specified semantics. Now, what do I mean by under specified semantics? Any developers in here should now be cringing Under specified semantics is session affinity per service or per port? Well, we never specified that so now we have multiple implementations which choose different interpretations of that And we can no longer define it because we would break somebody Our implementations required to consider port protocol or just port number when routing well We didn't write that down. I feel like we maybe shouldn't have had to but we didn't write it down And so variant implementations have made different decisions about this Is a service actually immutable like we say it is or can it be updated? We we say that the cluster IP is immutable But then we allow you to mutate it The service API it simply it just does too many things for too many people We have and we do things different from everything else in Kubernetes For example, we do synchronous allocation instead of doing it in a controller like everybody else We also have a pseudo transaction system built in we also until last year didn't even support finalizers properly The result is a very complex API that is really just a tangle of fields that have complicated Interrelationships between each other it makes implementation and testing really hard. It makes validation hard It makes comprehension hard and often we miss subtle interactions whenever we're trying to make changes to the service API It also cuts off avenues for growth There are a bunch of things that services probably should do but can't because we've locked ourselves in with API decisions For example, we can't forward a whole IP address only specific ports because we've defined the API that way So what can we do about this? I can't just delete it as much as I would like to But I can stop adding to it and we can offer maybe a replacement that works better. I think we can So meet my good friend Gateway API if you haven't heard about Gateway API yet. It just went GA like last week Really awesome project a lot of development time went into this. I hear you. You're saying wait a second Isn't Gateway like the L7 load balancer thing? Yes well kind of Gateway is an API that describes how to get traffic into pods. I wanted to call it the goes into API, but nobody would let me Let's take a quick look at the Gateway API model So there are three categories of API resource for up to three different personas up to The infrastructure provider the cluster operator and the application operator Somebody defines a gateway this requests an ingress point to be created the gateway class references the the gateway references the gateway class This is a implementation details The app operator specifies some routes which control how traffic is processed and routes those traffic to services I don't think cluster IPs are all that different In fact a cluster IP is really just a gateway into a set of pods traffic goes out of the client and into the gateway So a load balancer is also a gateway into a set of pods Not every service wants a load balancer and not every load balancer service wants a cluster IP These things are really different from each other Because gateway is a pure API the implementations can choose what they need And the upside of this is that users can compose what they really need from different implementations of the same API Downside it's a little bit more complicated Now maybe we can relegate a service into just being a group of pods and maybe we need a new API I don't we'll figure that out either way. We still need to interoperate with services So we can decompose the service API into a bunch of smaller things and giving us a constellation of concepts that lets us build a Composable service final word. This is not a commitment This is a bunch of ideas that I've thrown out and had people grown at me We're gonna see what we can do with this. We're looking for feedback if you love it if you hate it Let us know thanks