Welcome back to another edition of Cloud Native Short Takes! In this episode, Managing Partner Randy Abernethy explores the nature of Kubernetes Services.
Video Transcript
Hey everybody, welcome back to another edition of the Cloud Native Short Takes and today we’re going to take a look at Kubernetes Services. The RX-M Services module covers exploring the nature of Kubernetes Services, helps us understand the difference between ClusterIP, NodePort, and LoadBalancer Service types. Then it digs under the covers a little bit to make sure that we can choose the right Service for the right task, debug them, and effectively understand how they wire into the Kubernetes DNS system and all that sort of good stuff.
So we’re going to start off with a few simple looks at Services. When you set up a plain vanilla cluster you’re going to be interacting with the default namespace and there is a Service, the Kubernetes Service, that is created for you. This Service gives you the ability to talk to the API Server so if you’re building something that’s Kubernetes aware that Service is there for you to use. But what if we’re building something really simple? You know, a microservice, something webby, or what have you–and we want to scale it. Well, one of the things that we’re going to need to do is to make it easy for clients to get to that set of pods because remember, Kubernetes is a really dynamic environment. We need a way to simplify access to the pods that we create for the Services that are making use of them.
So let’s go ahead and take a look at a simple example. I’m going to do a kubectl run and we’ll go ahead and run a simple image like nginx and then we’re going to call this web. Okay so this stands up a single standalone pod and if we do a kubectl get pod --show-labels this pod has an automatic label applied to it: run=web. Let’s say for example we want to provide a stable network identity for this pod and if we’re going to scale this pod–we’re going to create 15 copies of this pod–they can all have that same label. We want to be able to load balance traffic across those pods and that’s exactly what Services do.
So in the RX-M Services module we learn all about Services. I’m just going to grab an example from one of the elements of the lab here and I’m going to create this Service for us to use on this machine. So dropping that in–this Service was generated so it’s got some extra stuff in it that we could leave in there–it wouldn’t hurt anything–but the creationTimestamp is going to be created by Kubernetes when we create the Service. I’m going to give this port that we’re going to forward in our Service a name and so we’ll call this web. Then, this is the most interesting part the selector; the selector allows us to specify what label we’d like to use in order to connect our Service to the various pods that we might want to forward traffic to. So we saw that our pod had the label run=web; we’ll use that as the selector key-value pair–so this selector is going to match that label.
Now we’re going to create a simple ClusterIP Service and that IP address is going to be resolvable by the hostname that is the same as the Service name. Every time you create a Service you not only get the sort of load balancing and routing to the backend pods that match your selector but you also get DNS resolution for the name of your Service to that ClusterIP that the Service is assigned. So this makes it really easy to use dynamic pods that are moving around in a cluster exactly like you would use a traditional static piece of software running on a virtual machine. The Service is that abstraction layer that makes transparent to the user that pods are coming and going and that pods–there might be 50 of them or one of them–we just really don’t care when we use a Service. So we’ve got a Service called testweb, it has a ClusterIP and as we can see it’s going to allow traffic coming in on port 80 to go out to the back end pods that match the Service selector.
Now let’s actually see if there are any back-end pods that match the Service selector. One of the things that we could do is we could do a kubectl get service -o wide and this shows us our selector. We can see that these guys sync up. So our testweb Service should match up with our labels so let’s give it a try! I’m going to curl the ClusterIP, the Service IP of our Service. We went through that ClusterIP and we reached the pod on the back end. Now let’s try it one more way; I’m going to go ahead and stand up a little pod inside the cluster that will give us a more accurate approximation of what a client would see trying to access the pod behind this Service. Here I’m going to use wget and I’m going to look for testweb; I’m not going to use the IP. There we go! That name of that Service is DNS resolvable in the cluster because it’s not the ClusterIP we’re depending on, it’s the name of the Service which should be pretty darn stable in a given application. So Services are really bringing a lot to the table as you can see here.
This has been a look at the Kubernetes Services module. This is one of the many modules available in the custom courseware builder where you can tailor and design your own specific classes for you or your teams that meet the exact needs of the folks that are interested in learning more about Kubernetes.
All right take care everybody and we’ll see you next time on a future Cloud Native Short Take!