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