0:00 In this lecture, let's go ahead and continue building out our Helm chart 0:03 for our 0:03 microservices. 0:05 Specifically, I want to now create Kubernetes services 0:09 to 0:09 expose actual network traffic to our underlying 0:13 deployments. Now, as we've seen already in our Helm chart, 0:17 the use of Kubernetes services allows us to expose the 0:21 underlying pod or a deployment in this case to 0:25 an actual request, so we can actually make a request to 0:28 that pod. 0:29 Well, pods in Kubernetes are ephemeral. 0:32 They will be deleted and recreated, so we can't simply 0:35 communicate by pod IP address. Instead, we use 0:39 Kubernetes services as we've already seen. 0:42 So if we say get service in Pulsar, for example, we 0:46 know we're already using this Kubernetes service name to communicate to the 0:49 broker. Well, if we actually look at this 0:53 broker by running get service, output YAML 0:57 in the Pulsar namespace, we can see what this actually does. 1:01 So we define the ports that it will accept traffic 1:05 on, and then we specify the target port on the 1:08 given container that we're going to send traffic to, and we do that through the 1:13 use of a selector. So the selector field will allow us to 1:16 supply attributes, or in this case labels, that we want to 1:20 send the traffic to, and these labels will be applied to the 1:24 given 1:24 Pulsar broker component, so the component broker here. 1:28 That label will exist on the deployment, and that's where this service will send 1:31 the traffic to. 1:33 Now, these Kubernetes service names act as the 1:36 host name itself, which 1:37 means it's static and doesn't change even 1:40 when our underlying pods do. 1:42 We have the expected port here that we'll send traffic to on the 1:45 underlying 1:46 service. And so let's go ahead and create this same kind of service
The rest of the transcript is for members.
Sign in 