1 00:00:00,001 --> 00:00:02,734 [No Audio] 2 00:00:02,734 --> 00:00:07,101 All right, huge disclaimer. Since all of you have 3 00:00:07,101 --> 00:00:10,367 already studied Docker Swarm, Service will be a 4 00:00:10,367 --> 00:00:14,234 term which you are already familiar with. But both 5 00:00:14,234 --> 00:00:18,534 of these Services are different. In case of Swarm, 6 00:00:18,534 --> 00:00:21,434 Service acted like a deployment, where you can 7 00:00:21,434 --> 00:00:24,201 declare all of the desired objects and manager 8 00:00:24,201 --> 00:00:26,134 will convert them into tasks. 9 00:00:26,901 --> 00:00:30,967 But here in Kubernetes, Services are merely networking objects 10 00:00:30,967 --> 00:00:33,934 for Pods. Since both of the forms chose to have 11 00:00:33,934 --> 00:00:36,234 different interpretation for the same term, 12 00:00:36,234 --> 00:00:40,001 it becomes our job not to get confused around it. 13 00:00:41,134 --> 00:00:43,701 With that out of the way, let's dig deep into 14 00:00:43,701 --> 00:00:47,601 Kubernetes Services. Firstly, Services are also 15 00:00:47,601 --> 00:00:50,434 objects just like Pods or Controllers, but they 16 00:00:50,434 --> 00:00:53,001 fall under the category of connectivity. 17 00:00:53,534 --> 00:00:57,301 To understand how Services work, let's take two dummy Pods 18 00:00:57,301 --> 00:00:59,801 Blue Dark and Pink Dark. 19 00:01:01,067 --> 00:01:05,634 We want these Pods to be able to talk, talk to external world 20 00:01:05,634 --> 00:01:09,901 or simply to each other. Then Services are 21 00:01:09,901 --> 00:01:12,934 connectivity objects, which serve as a stack of 22 00:01:12,934 --> 00:01:15,867 network configurations, which can allow Pods to 23 00:01:15,867 --> 00:01:18,767 be able to communicate. Just like deployments or 24 00:01:18,767 --> 00:01:22,067 ReplicaSets, Services also use labels and 25 00:01:22,067 --> 00:01:26,067 selectors to determine which pods will be connected to them. 26 00:01:27,034 --> 00:01:30,901 Our pods have label DB and DP. 27 00:01:30,901 --> 00:01:34,834 Whereas our Service has a selector looking for DB. 28 00:01:34,834 --> 00:01:38,467 So Dark Pink won't affiliate with the Service. 29 00:01:38,801 --> 00:01:41,734 Dark Blue's connectivity will now be handled by 30 00:01:41,734 --> 00:01:44,234 this Service, and it can potentially talk to the 31 00:01:44,234 --> 00:01:47,934 outside world as well. Remember the word, 32 00:01:48,201 --> 00:01:51,834 potentially talk, not necessarily. Let's brief up 33 00:01:51,834 --> 00:01:54,434 the Services. First two points are already 34 00:01:54,434 --> 00:01:57,634 familiar to you, but they are important to list out. 35 00:01:57,634 --> 00:02:00,534 You might be surprised that Kubernetes itself 36 00:02:00,534 --> 00:02:04,034 uses these Services to perform all sorts of in-cluster 37 00:02:04,034 --> 00:02:06,534 and global communications. Services 38 00:02:06,534 --> 00:02:09,467 generally provide cluster IP to each Pod, which 39 00:02:09,467 --> 00:02:13,501 allows it to talk within cluster. But if we choose 40 00:02:13,501 --> 00:02:16,467 to abstain from such a practice, we can create a 41 00:02:16,467 --> 00:02:20,401 headless Service. And finally, Kubernetes also 42 00:02:20,434 --> 00:02:23,367 provides native support for multi-port Services 43 00:02:23,367 --> 00:02:26,967 and cloud load balancers. We recently mentioned 44 00:02:26,967 --> 00:02:29,434 that Services can make Pods potentially talk to 45 00:02:29,434 --> 00:02:33,934 outside world. But why potentially? Well, because 46 00:02:33,934 --> 00:02:39,034 Services also have types. First of them is ClusterIP, 47 00:02:39,034 --> 00:02:43,201 which only exposes the Service within the cluster. 48 00:02:43,201 --> 00:02:47,267 It means that outside world can't access it, 49 00:02:47,267 --> 00:02:49,634 but Pods within the cluster connected to this 50 00:02:49,634 --> 00:02:53,234 Service can talk to each other. Second type is 51 00:02:53,234 --> 00:02:56,667 NodePort, which exposes the Service on the 52 00:02:56,701 --> 00:03:00,434 external IPs of all of the nodes of the cluster, 53 00:03:00,434 --> 00:03:04,234 including Master. This will by default also create 54 00:03:04,234 --> 00:03:07,101 a Cluster IP, where the NodePort will be routed 55 00:03:07,101 --> 00:03:10,267 eventually. If we have defined a cloud provided 56 00:03:10,267 --> 00:03:12,967 LoadBalancer, we can use LoadBalancer type 57 00:03:12,967 --> 00:03:16,067 Service, which doesn't only expose it to all 58 00:03:16,067 --> 00:03:20,001 nodes, but also provides dedicated external IPs to 59 00:03:20,001 --> 00:03:23,367 the Pods connected to the Service. And finally, 60 00:03:23,401 --> 00:03:27,534 we have ExternalName, which allows us to use DNS 61 00:03:27,534 --> 00:03:30,534 address to communicate to ports connected to the Service. 62 00:03:30,534 --> 00:03:33,001 In next lecture, we will take a look at 63 00:03:33,001 --> 00:03:35,334 ClusterIP and NodePort Services. 64 00:03:35,334 --> 00:03:37,701 Whereas we will visit Load Balancers 65 00:03:37,701 --> 00:03:40,567 when we run Kubernetes on a managed cloud provision.