Kubernetes basics. Talking about services, labels, and selectors. All right, so a service is assigned to a fixed IP to your pod and then it replicates and allows other pods and other services to communicate with them. Services really act like a way of communication between the pods, okay? Number one, the cluster has an IP, an internal IP, and the port nodes also have awareness of that access to that IP. It also uses a load balancer as a bounds for that browsing that traffic that comes into the nodes themselves. You're going to have multiple services with different configurations and features running. Usually, the frontend is either a web server, application server, some kind of server, backends are usually the nodes and maybe a database server. They run with usually a load balancer, Google Cloud load balancer, which will let you detailed what GCP API you use. Again, a definition in YAML file will tell you the resources, the pods you'll be using, and then the pod selector, and then the type of load balancer you'll be applying to this. Labels are metadata that you can assign to any API object and represent an identity. They are used for grouping, mechanisms, searching, but not only that, they're using for filtering, finding something. Pods could contain a lot of entities and containers that could be in many, many containers in your environment. By labeling them logically, you'll be able to quickly find them and not only that, per mechanisms inside the pods to quickly identify them. In this example, you have four pods and three labels, so my application, my application, my application, my application, but notice the labels, one is prod, one is test, there's another for tests, there's another prod, and then you have different roles underneath each. That way, not only is it a way of segregating for reporting, but it's also a way of mechanizing and orchestrating the container environment itself. You could query, you could find labels, like I said, when you need to find something in 9,000 containers, it's going to be very handy to have a label. And you could also use it to map the entire application to that label itself. So, app label equals all my applications. So an easy way to again group all your applications. Or narrow your search, like I said. Trying to find a needle in the haystack of a thousand containers could be very challenging. With tags and labels, it could be made very, very easy. You'll be able to similarly apply labels for your backend services also. This is my BE server, this is my backend server, my database, whatever. Or, your applications test phase. Call it test. Here you go. Both of them are test, you could group them together, and you could have a red and blue or green, yellow application. We'll talk about those later on. But it's a way again of testing your application in an environment without disrupting anything in production again. And then on your production release, like I said, make the same changes. You could label these, and understand that labeling is just an example right here that we're showing you, but it's really an example and it's really a logical way of managing Kubernetes. Kubernetes also checks whether your pod is alive or healthy. If it gets a negative response, or no reply, it's unhealthy. In other words, if I'm knocking on your door and you don't open that door, I'm going to call the police, have them come on in and probably maybe rescue, because I know there's something wrong. Kubernetes has that unhealthy environment already built in. I call it, a.k.a. Doctor in a can. Kubernetes then automatically restarts the pod if it needs restarts to see that, if everything comes up bright. And if everything is good, it goes back into a healthy state. Doctors not needed any longer, pod is up and running.
