1 1 00:00:02,590 --> 00:00:04,819 Now that you have your pods running, you're probably going 2 2 00:00:04,820 --> 00:00:07,749 to need to expose those to external services at some point. 3 3 00:00:08,109 --> 00:00:10,869 That means allowing them to accept connections, in some 4 4 00:00:10,870 --> 00:00:13,210 fashion, in your cluster or from outside your cluster. 5 5 00:00:13,690 --> 00:00:16,914 In Kubernetes, we use the kubectl expose 6 6 00:00:17,050 --> 00:00:19,900 command as one of the ways to create a service. 7 7 00:00:20,410 --> 00:00:23,139 We mentioned service a few times before, but let's make 8 8 00:00:23,140 --> 00:00:26,410 sure we're clear on what a service is. A service is 9 9 00:00:26,560 --> 00:00:29,679 an endpoint that is consistent so 10 10 00:00:29,680 --> 00:00:32,228 that other things inside, or outside the cluster, might be 11 11 00:00:32,229 --> 00:00:33,229 able to access it. 12 12 00:00:33,520 --> 00:00:35,774 When you create pods in Kubernetes, they don't 13 13 00:00:35,830 --> 00:00:38,829 automatically get a DNS name for external 14 14 00:00:38,830 --> 00:00:40,528 connectivity with an IP address, tight. 15 15 00:00:41,350 --> 00:00:43,898 You would want to do that with creating a service on 16 16 00:00:44,350 --> 00:00:46,350 top of that existing pod. 17 17 00:00:46,870 --> 00:00:49,840 There's various ways besides this expose command 18 18 00:00:49,870 --> 00:00:51,249 to create a service. 19 19 00:00:51,550 --> 00:00:53,259 Let's focus on what's common. 20 20 00:00:53,560 --> 00:00:55,480 The common thing in here is that core DNS. 21 21 00:00:55,481 --> 00:00:58,360 If you remember, we mentioned that earlier as one of the 22 22 00:00:58,600 --> 00:01:00,190 core features of your control plane. 23 23 00:01:00,460 --> 00:01:03,729 That service is going to be your DNS server to resolve 24 24 00:01:03,760 --> 00:01:05,319 the names for all these things. 25 25 00:01:05,680 --> 00:01:07,346 On top of that, for picking the IP 26 26 00:01:08,650 --> 00:01:10,929 and port and how it does that, how it gets traffic 27 27 00:01:10,930 --> 00:01:14,079 essentially to your service is 28 28 00:01:14,080 --> 00:01:17,170 the job of one of four different 29 29 00:01:17,260 --> 00:01:20,349 service types. Let's go through those now and then we'll go 30 30 00:01:20,350 --> 00:01:22,719 through some examples. Let's start with the service type 31 31 00:01:23,140 --> 00:01:24,670 ClusterIP, which is the default. 32 32 00:01:25,000 --> 00:01:28,239 In this case, the most important aspect is that it's only 33 33 00:01:28,240 --> 00:01:29,590 available in the cluster. 34 34 00:01:29,620 --> 00:01:31,531 This is really about one Kubernetes set 35 35 00:01:32,680 --> 00:01:34,959 of pods talking to another set of pods. 36 36 00:01:35,290 --> 00:01:37,590 This gets it's own DNS stress, right. 37 37 00:01:37,630 --> 00:01:40,689 That's going to be the DNS address in the core DNS control 38 38 00:01:40,690 --> 00:01:43,689 plane. It's going to get an IP address 39 39 00:01:43,930 --> 00:01:47,170 in that virtual IP address space inside the cluster. 40 40 00:01:47,740 --> 00:01:50,582 That allows your other pods running in the cluster to talk 41 41 00:01:50,740 --> 00:01:53,829 to this service using the port of 42 42 00:01:53,830 --> 00:01:56,525 the service. If you're running an Nginx app, and it was 43 43 00:01:56,650 --> 00:01:59,379 running on port 80 when you created the service, that 44 44 00:01:59,380 --> 00:02:01,550 service IP could also be on port 80. 45 45 00:02:01,570 --> 00:02:03,790 That keeps some sort of consistency there. 46 46 00:02:04,240 --> 00:02:07,119 If you think about it, this is very similar to the way when 47 47 00:02:07,120 --> 00:02:10,299 you create a service in Swarm, now that services 48 48 00:02:10,300 --> 00:02:11,949 are a little bit different in Swarm. They have a different 49 49 00:02:12,310 --> 00:02:13,419 idea around them. 50 50 00:02:13,600 --> 00:02:16,419 But they are consistent at least when you create a service, 51 51 00:02:16,660 --> 00:02:19,090 it gives you that internal IP on the load balancer, if you 52 52 00:02:19,100 --> 00:02:21,910 remember. It runs it on the port that the app is on. 53 53 00:02:22,210 --> 00:02:24,709 In this case, we're doing a very similar thing, but 54 54 00:02:25,180 --> 00:02:27,944 we have to create this one with an expose command 55 55 00:02:28,660 --> 00:02:30,340 or other options we'll talk about later. 56 56 00:02:30,880 --> 00:02:33,360 The next up here is NodePort, which is subtly 57 57 00:02:33,910 --> 00:02:35,931 different. It is a little bit confusing out-of-the-box. 58 58 00:02:36,610 --> 00:02:39,789 The ClusterIP is the default and it always 59 59 00:02:39,790 --> 00:02:41,529 works inside the cluster. 60 60 00:02:41,550 --> 00:02:43,329 It doesn't need anything special. It doesn't need any 61 61 00:02:43,330 --> 00:02:46,074 firewall rules outside of the cluster for traffic to get 62 62 00:02:46,300 --> 00:02:49,539 to it. But, ClusterIP is only good in the cluster. 63 63 00:02:49,690 --> 00:02:52,120 Remember that. ClusterIP, good in the cluster. 64 64 00:02:52,510 --> 00:02:54,666 A NodePort is designed for something outside 65 65 00:02:55,900 --> 00:02:58,203 the cluster to talk to your service through the 66 66 00:02:59,020 --> 00:03:01,629 IP addresses on the nodes themselves. 67 67 00:03:01,840 --> 00:03:05,049 When you create a NodePort, you're going to get a high 68 68 00:03:05,380 --> 00:03:08,350 port on each node that's assigned 69 69 00:03:08,410 --> 00:03:09,460 to this service. 70 70 00:03:09,970 --> 00:03:12,759 Once you get that, you can update other things that need to 71 71 00:03:12,760 --> 00:03:13,810 know about this port. 72 72 00:03:14,140 --> 00:03:15,634 This port is going to be a high port. 73 73 00:03:16,450 --> 00:03:19,292 You're not going to use port 80, for example, when you use 74 74 00:03:19,360 --> 00:03:22,006 this type. The key to these two is that they're always 75 75 00:03:22,360 --> 00:03:24,089 available in any Kubernetes cluster. 76 76 00:03:24,370 --> 00:03:27,219 Whether you're using a cloud vendors solution, or rolling 77 77 00:03:27,220 --> 00:03:29,817 your own Kubernetes, or deploying a packaged one like 78 78 00:03:30,310 --> 00:03:32,010 Docker Enterprise or Rancher. 79 79 00:03:32,230 --> 00:03:34,347 These are the ones that will always work out-of-the-box. 80 80 00:03:35,050 --> 00:03:37,090 Next up is the load balancer type. 81 81 00:03:37,450 --> 00:03:39,939 This is mostly used in the cloud. 82 82 00:03:40,240 --> 00:03:43,033 The idea here is that you're controlling an external load 83 83 00:03:43,240 --> 00:03:45,900 balancer through the Kubernetes command line, which 84 84 00:03:46,300 --> 00:03:47,300 is pretty cool. 85 85 00:03:47,680 --> 00:03:49,449 Essentially, this is a bunch of automation. 86 86 00:03:49,750 --> 00:03:52,029 What you're doing here is in the background, when you 87 87 00:03:52,030 --> 00:03:54,676 create this load balancer, it's going to automatically 88 88 00:03:55,780 --> 00:03:58,034 create the ClusterIP in NodePort so that those 89 89 00:03:58,780 --> 00:04:01,389 are available. Then it's going to talk to the external 90 90 00:04:01,390 --> 00:04:04,419 system. Maybe it's an AWS load balancer or some 91 91 00:04:04,420 --> 00:04:06,789 other cloud vendor. Basically, these are going to come from 92 92 00:04:06,790 --> 00:04:09,729 your infrastructure providers, and they will allow 93 93 00:04:10,040 --> 00:04:12,686 Kubernetes to talk to them through some remote API and 94 94 00:04:13,300 --> 00:04:15,809 configure them for you. So, in the case of maybe an AWS 95 95 00:04:15,850 --> 00:04:18,055 load balancer, when you create this, not only 96 96 00:04:18,820 --> 00:04:21,338 is it creating those NodePorts and ClusterIPs in the 97 97 00:04:21,339 --> 00:04:24,100 backend, but it's also telling the AWS load balancer 98 98 00:04:24,400 --> 00:04:25,638 to talk to the NodePorts. 99 99 00:04:26,290 --> 00:04:28,350 Essentially, this is just automation, right. 100 100 00:04:28,360 --> 00:04:31,000 This is helping you save a step from having to run some AWS 101 101 00:04:31,001 --> 00:04:33,353 command line, or web interface, to automatically 102 102 00:04:33,970 --> 00:04:35,200 set up that load balancer for you. 103 103 00:04:35,650 --> 00:04:38,100 The two takeaways I have for this one are to think 104 104 00:04:38,800 --> 00:04:41,397 about it as this is only for traffic coming into your 105 105 00:04:41,680 --> 00:04:43,179 cluster from an external source. 106 106 00:04:43,570 --> 00:04:46,509 It requires an infrastructure provider that gives 107 107 00:04:46,510 --> 00:04:49,479 Kubernetes the ability to talk to it remotely. 108 108 00:04:50,080 --> 00:04:51,960 The last of the four service types is ExternalName. 109 109 00:04:52,990 --> 00:04:55,489 This is used less often, and it doesn't really have 110 110 00:04:56,020 --> 00:04:58,839 anything to do with controlling inbound 111 111 00:04:59,110 --> 00:05:01,029 traffic to your services. 112 112 00:05:01,060 --> 00:05:04,309 This is more about stuff in your cluster needing to talk 113 113 00:05:04,310 --> 00:05:05,749 to outside services. 114 114 00:05:06,200 --> 00:05:08,356 You want to create DNS names in the core DNS 115 115 00:05:09,440 --> 00:05:12,740 system so that your cluster can resolve 116 116 00:05:12,770 --> 00:05:15,079 ExternalNames that you maybe don't have controlled 117 117 00:05:15,110 --> 00:05:18,110 externally. One of the reasons you might use 118 118 00:05:18,590 --> 00:05:20,746 ExternalName is when you're doing migrations 119 119 00:05:22,040 --> 00:05:25,009 of things. Think about if you have a remote application. 120 120 00:05:25,040 --> 00:05:26,501 That remote application outside of your Kubernetes cluster 121 121 00:05:27,230 --> 00:05:28,580 probably has a DNS name already, tight. 122 122 00:05:29,660 --> 00:05:32,660 If you're going to be moving say something from 123 123 00:05:32,720 --> 00:05:35,415 those external services to internal services, you might 124 124 00:05:35,990 --> 00:05:38,097 look at how you could use ExternalName as a 125 125 00:05:39,050 --> 00:05:41,860 substitute to control the DNS inside your Kubernetes 126 126 00:05:42,260 --> 00:05:45,259 workflow. You basically then could have 127 127 00:05:45,260 --> 00:05:48,102 a single command line of Kubernetes rather than saying, oh 128 128 00:05:48,380 --> 00:05:50,779 I need to change the external DNS for something so I have 129 129 00:05:50,780 --> 00:05:53,389 to run some other utility for that DNS service. 130 130 00:05:53,780 --> 00:05:56,426 Or, maybe even something that doesn't even have an API 131 131 00:05:56,630 --> 00:05:59,423 behind it. Maybe like an enterprise DNS or something like 132 132 00:05:59,450 --> 00:06:01,704 that. You can use this inside your clusters so 133 133 00:06:02,420 --> 00:06:05,570 that services inside your clusters start resolving 134 134 00:06:05,630 --> 00:06:08,869 a different endpoint than the one that they previously 135 135 00:06:08,870 --> 00:06:11,449 had that was external. I find that I really only use it 136 136 00:06:11,450 --> 00:06:13,116 when I need to change how my stuff 137 137 00:06:14,540 --> 00:06:17,600 is getting out of my cluster to some external service, but 138 138 00:06:17,630 --> 00:06:20,521 I don't have a way of controlling the DNS remotely of those 139 139 00:06:20,720 --> 00:06:22,759 other things. So, I'd rather just do it inside of 140 140 00:06:22,760 --> 00:06:25,670 Kubernetes and create some ExternalNames for my stuff. 141 141 00:06:26,000 --> 00:06:27,941 Then, when I want to change it dynamically in Kubernetes 142 142 00:06:28,460 --> 00:06:31,339 for my stuff inside my cluster, I can do that pretty easily 143 143 00:06:31,370 --> 00:06:32,749 without having to talk to anything else. 144 144 00:06:33,260 --> 00:06:35,509 All right. We're going to wrap up these four service types, 145 145 00:06:35,540 --> 00:06:38,510 but there is another way that traffic can get 146 146 00:06:38,600 --> 00:06:40,069 inside your cluster. 147 147 00:06:40,100 --> 00:06:41,329 That's through Ingress. 148 148 00:06:41,720 --> 00:06:43,220 We will talk about that later. 149 149 00:06:43,240 --> 00:06:45,949 That's specifically designed for HTTP traffic. 150 150 00:06:46,310 --> 00:06:49,103 When we get to that lecture, you'll understand why that's 151 151 00:06:49,310 --> 00:06:50,949 a little bit different than these service types.