Now that you have your pods running, you're probably going 2 2
to need to expose those to external services at some point. 3 3
That means allowing them to accept connections, in some 4 4
fashion, in your cluster or from outside your cluster. 5 5
In Kubernetes, we use the kubectl expose 6 6
command as one of the ways to create a service. 7 7
We mentioned service a few times before, but let's make 8 8
sure we're clear on what a service is. A service is 9 9
an endpoint that is consistent so 10 10
that other things inside, or outside the cluster, might be 11 11
able to access it. 12 12
When you create pods in Kubernetes, they don't 13 13
automatically get a DNS name for external 14 14
connectivity with an IP address, tight. 15 15
You would want to do that with creating a service on 16 16
top of that existing pod. 17 17
There's various ways besides this expose command 18 18
to create a service. 19 19
Let's focus on what's common. 20 20
The common thing in here is that core DNS. 21 21
If you remember, we mentioned that earlier as one of the 22 22
core features of your control plane. 23 23
That service is going to be your DNS server to resolve 24 24
the names for all these things. 25 25
On top of that, for picking the IP 26 26
and port and how it does that, how it gets traffic 27 27
essentially to your service is 28 28
the job of one of four different 29 29
service types. Let's go through those now and then we'll go 30 30
through some examples. Let's start with the service type 31 31
ClusterIP, which is the default. 32 32
In this case, the most important aspect is that it's only 33 33
available in the cluster. 34 34
This is really about one Kubernetes set 35 35
of pods talking to another set of pods. 36 36
This gets it's own DNS stress, right. 37 37
That's going to be the DNS address in the core DNS control 38 38
plane. It's going to get an IP address 39 39
in that virtual IP address space inside the cluster. 40 40
That allows your other pods running in the cluster to talk 41 41
to this service using the port of 42 42
the service. If you're running an Nginx app, and it was 43 43
running on port 80 when you created the service, that 44 44
service IP could also be on port 80. 45 45
That keeps some sort of consistency there. 46 46
If you think about it, this is very similar to the way when 47 47
you create a service in Swarm, now that services 48 48
are a little bit different in Swarm. They have a different 49 49
idea around them. 50 50
But they are consistent at least when you create a service, 51 51
it gives you that internal IP on the load balancer, if you 52 52
remember. It runs it on the port that the app is on. 53 53
In this case, we're doing a very similar thing, but 54 54
we have to create this one with an expose command 55 55
or other options we'll talk about later. 56 56
The next up here is NodePort, which is subtly 57 57
different. It is a little bit confusing out-of-the-box. 58 58
The ClusterIP is the default and it always 59 59
works inside the cluster. 60 60
It doesn't need anything special. It doesn't need any 61 61
firewall rules outside of the cluster for traffic to get 62 62
to it. But, ClusterIP is only good in the cluster. 63 63
Remember that. ClusterIP, good in the cluster. 64 64
A NodePort is designed for something outside 65 65
the cluster to talk to your service through the 66 66
IP addresses on the nodes themselves. 67 67
When you create a NodePort, you're going to get a high 68 68
port on each node that's assigned 69 69
to this service. 70 70
Once you get that, you can update other things that need to 71 71
know about this port. 72 72
This port is going to be a high port. 73 73
You're not going to use port 80, for example, when you use 74 74
this type. The key to these two is that they're always 75 75
available in any Kubernetes cluster. 76 76
Whether you're using a cloud vendors solution, or rolling 77 77
your own Kubernetes, or deploying a packaged one like 78 78
Docker Enterprise or Rancher. 79 79
These are the ones that will always work out-of-the-box. 80 80
Next up is the load balancer type. 81 81
This is mostly used in the cloud. 82 82
The idea here is that you're controlling an external load 83 83
balancer through the Kubernetes command line, which 84 84
is pretty cool. 85 85
Essentially, this is a bunch of automation. 86 86
What you're doing here is in the background, when you 87 87
create this load balancer, it's going to automatically 88 88
create the ClusterIP in NodePort so that those 89 89
are available. Then it's going to talk to the external 90 90
system. Maybe it's an AWS load balancer or some 91 91
other cloud vendor. Basically, these are going to come from 92 92
your infrastructure providers, and they will allow 93 93
Kubernetes to talk to them through some remote API and 94 94
configure them for you. So, in the case of maybe an AWS 95 95
load balancer, when you create this, not only 96 96
is it creating those NodePorts and ClusterIPs in the 97 97
backend, but it's also telling the AWS load balancer 98 98
to talk to the NodePorts. 99 99
Essentially, this is just automation, right. 100 100
This is helping you save a step from having to run some AWS 101 101
command line, or web interface, to automatically 102 102
set up that load balancer for you. 103 103
The two takeaways I have for this one are to think 104 104
about it as this is only for traffic coming into your 105 105
cluster from an external source. 106 106
It requires an infrastructure provider that gives 107 107
Kubernetes the ability to talk to it remotely. 108 108
The last of the four service types is ExternalName. 109 109
This is used less often, and it doesn't really have 110 110
anything to do with controlling inbound 111 111
traffic to your services. 112 112
This is more about stuff in your cluster needing to talk 113 113
to outside services. 114 114
You want to create DNS names in the core DNS 115 115
system so that your cluster can resolve 116 116
ExternalNames that you maybe don't have controlled 117 117
externally. One of the reasons you might use 118 118
ExternalName is when you're doing migrations 119 119
of things. Think about if you have a remote application. 120 120
That remote application outside of your Kubernetes cluster 121 121
probably has a DNS name already, tight. 122 122
If you're going to be moving say something from 123 123
those external services to internal services, you might 124 124
look at how you could use ExternalName as a 125 125
substitute to control the DNS inside your Kubernetes 126 126
workflow. You basically then could have 127 127
a single command line of Kubernetes rather than saying, oh 128 128
I need to change the external DNS for something so I have 129 129
to run some other utility for that DNS service. 130 130
Or, maybe even something that doesn't even have an API 131 131
behind it. Maybe like an enterprise DNS or something like 132 132
that. You can use this inside your clusters so 133 133
that services inside your clusters start resolving 134 134
a different endpoint than the one that they previously 135 135
had that was external. I find that I really only use it 136 136
when I need to change how my stuff 137 137
is getting out of my cluster to some external service, but 138 138
I don't have a way of controlling the DNS remotely of those 139 139
other things. So, I'd rather just do it inside of 140 140
Kubernetes and create some ExternalNames for my stuff. 141 141
Then, when I want to change it dynamically in Kubernetes 142 142
for my stuff inside my cluster, I can do that pretty easily 143 143
without having to talk to anything else. 144 144
All right. We're going to wrap up these four service types, 145 145
but there is another way that traffic can get 146 146
inside your cluster. 147 147
That's through Ingress. 148 148
We will talk about that later. 149 149
That's specifically designed for HTTP traffic. 150 150
When we get to that lecture, you'll understand why that's 151 151
a little bit different than these service types.