In this Cloud Native Short Take, RX-M Managing Partner Randy Abernethy taks us through part 2 of the RX-M Kubernetes Services Module where he covers the nature of Kubernetes services, discussing Service selector behavior and blue-green deployments.
Video Transcript
Hey everybody, welcome back to another edition of the Cloud Native Short Takes and today we’re going to take another 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’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 backend pods that match the Service selector. Now let’s actually see if there are any back-end pods that match the Service selector and this shows us our selector. We can see that these guys sync up so our testweb Service should match up with our labels. Now I’m going to show how you can scale this Service. Now if i’d had a Deployment i could have just said kubectl scale --replicas=10 or something like that but i’m going to do something a little bit more tricky. I’m going to do a kubectl run and I’m going to run another web type guy but this time I’m going to use an Apache web server and I’m going to call this web 2.
So let’s go ahead and take a look at this guy. Now if I do a kubectl get endpoints–this is a tricky way to see what endpoints your Services have discovered. So you can see that my Service has only found one pod and the reason for this is that my pod that I just created does not have a run=web label. It has a run=web2 label. So let’s go ahead and take a look at the pods that we’ve got here. You can see this guy–you know of course he was called web2 so that’s the label he gets. We can add labels to pods too though; so i’m going to kubectl label pod web2 with the label run=web. Oops! i tried to change the label that already exists. You’re normally not allowed to do that unless you use the --overwrite flag.
All right, now let’s go back and look at our pods and look at their labels. You can see that now the run key has been set to web for both of these guys. If we then go and take a look at the endpoints you can see that, voila, without any extra work the Service has automatically picked up that second pod. If we curl the Service IP you can see that this time we got the Apache web server the second time we got the Nginx web server and so on.
So the Service not only gives you the ability to provide a stable network identity for all of these pods but the pods can actually be incongruent. You could do a blue-green style deployment like I’ve just done. You could have your Python code running under Nginx and your Python code running under Apache and as long as the API is the same the client doesn’t care which web server is providing the interface. This gives you the ability to have diversity and all sorts of other interesting things in your application. So the abstraction of a Service is really a superpower in Kubernetes and gives us a lot of flexibility and a lot of control.
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!