‫Now that you have your pods running, you're probably going
‫to need to expose those to external services at some point.
‫That means allowing them to accept connections, in some
‫fashion, in your cluster or from outside your cluster.
‫In Kubernetes, we use the kubectl expose
‫command as one of the ways to create a service.
‫We mentioned service a few times before, but let's make
‫sure we're clear on what a service is. A service is
‫an endpoint that is consistent so
‫that other things inside, or outside the cluster, might be
‫able to access it.
‫When you create pods in Kubernetes, they don't
‫automatically get a DNS name for external
‫connectivity with an IP address, tight.
‫You would want to do that with creating a service on
‫top of that existing pod.
‫There's various ways besides this expose command
‫to create a service.
‫Let's focus on what's common.
‫The common thing in here is that core DNS.
‫If you remember, we mentioned that earlier as one of the
‫core features of your control plane.
‫That service is going to be your DNS server to resolve
‫the names for all these things.
‫On top of that, for picking the IP
‫and port and how it does that, how it gets traffic
‫essentially to your service is
‫the job of one of four different
‫service types. Let's go through those now and then we'll go
‫through some examples. Let's start with the service type
‫ClusterIP, which is the default.
‫In this case, the most important aspect is that it's only
‫available in the cluster.
‫This is really about one Kubernetes set
‫of pods talking to another set of pods.
‫This gets it's own DNS stress, right.
‫That's going to be the DNS address in the core DNS control
‫plane. It's going to get an IP address
‫in that virtual IP address space inside the cluster.
‫That allows your other pods running in the cluster to talk
‫to this service using the port of
‫the service. If you're running an Nginx app, and it was
‫running on port 80 when you created the service, that
‫service IP could also be on port 80.
‫That keeps some sort of consistency there.
‫If you think about it, this is very similar to the way when
‫you create a service in Swarm, now that services
‫are a little bit different in Swarm. They have a different
‫idea around them.
‫But they are consistent at least when you create a service,
‫it gives you that internal IP on the load balancer, if you
‫remember. It runs it on the port that the app is on.
‫In this case, we're doing a very similar thing, but
‫we have to create this one with an expose command
‫or other options we'll talk about later.
‫The next up here is NodePort, which is subtly
‫different. It is a little bit confusing out-of-the-box.
‫The ClusterIP is the default and it always
‫works inside the cluster.
‫It doesn't need anything special. It doesn't need any
‫firewall rules outside of the cluster for traffic to get
‫to it. But, ClusterIP is only good in the cluster.
‫Remember that. ClusterIP, good in the cluster.
‫A NodePort is designed for something outside
‫the cluster to talk to your service through the
‫IP addresses on the nodes themselves.
‫When you create a NodePort, you're going to get a high
‫port on each node that's assigned
‫to this service.
‫Once you get that, you can update other things that need to
‫know about this port.
‫This port is going to be a high port.
‫You're not going to use port 80, for example, when you use
‫this type. The key to these two is that they're always
‫available in any Kubernetes cluster.
‫Whether you're using a cloud vendors solution, or rolling
‫your own Kubernetes, or deploying a packaged one like
‫Docker Enterprise or Rancher.
‫These are the ones that will always work out-of-the-box.
‫Next up is the load balancer type.
‫This is mostly used in the cloud.
‫The idea here is that you're controlling an external load
‫balancer through the Kubernetes command line, which
‫is pretty cool.
‫Essentially, this is a bunch of automation.
‫What you're doing here is in the background, when you
‫create this load balancer, it's going to automatically
‫create the ClusterIP in NodePort so that those
‫are available. Then it's going to talk to the external
‫system. Maybe it's an AWS load balancer or some
‫other cloud vendor. Basically, these are going to come from
‫your infrastructure providers, and they will allow
‫Kubernetes to talk to them through some remote API and
‫configure them for you. So, in the case of maybe an AWS
‫load balancer, when you create this, not only
‫is it creating those NodePorts and ClusterIPs in the
‫backend, but it's also telling the AWS load balancer
‫to talk to the NodePorts.
‫Essentially, this is just automation, right.
‫This is helping you save a step from having to run some AWS
‫command line, or web interface, to automatically
‫set up that load balancer for you.
‫The two takeaways I have for this one are to think
‫about it as this is only for traffic coming into your
‫cluster from an external source.
‫It requires an infrastructure provider that gives
‫Kubernetes the ability to talk to it remotely.
‫The last of the four service types is ExternalName.
‫This is used less often, and it doesn't really have
‫anything to do with controlling inbound
‫traffic to your services.
‫This is more about stuff in your cluster needing to talk
‫to outside services.
‫You want to create DNS names in the core DNS
‫system so that your cluster can resolve
‫ExternalNames that you maybe don't have controlled
‫externally. One of the reasons you might use
‫ExternalName is when you're doing migrations
‫of things. Think about if you have a remote application.
‫That remote application outside of your Kubernetes cluster
‫probably has a DNS name already, tight.
‫If you're going to be moving say something from
‫those external services to internal services, you might
‫look at how you could use ExternalName as a
‫substitute to control the DNS inside your Kubernetes
‫workflow. You basically then could have
‫a single command line of Kubernetes rather than saying, oh
‫I need to change the external DNS for something so I have
‫to run some other utility for that DNS service.
‫Or, maybe even something that doesn't even have an API
‫behind it. Maybe like an enterprise DNS or something like
‫that. You can use this inside your clusters so
‫that services inside your clusters start resolving
‫a different endpoint than the one that they previously
‫had that was external. I find that I really only use it
‫when I need to change how my stuff
‫is getting out of my cluster to some external service, but
‫I don't have a way of controlling the DNS remotely of those
‫other things. So, I'd rather just do it inside of
‫Kubernetes and create some ExternalNames for my stuff.
‫Then, when I want to change it dynamically in Kubernetes
‫for my stuff inside my cluster, I can do that pretty easily
‫without having to talk to anything else.
‫All right. We're going to wrap up these four service types,
‫but there is another way that traffic can get
‫inside your cluster.
‫That's through Ingress.
‫We will talk about that later.
‫That's specifically designed for HTTP traffic.
‫When we get to that lecture, you'll understand why that's
‫a little bit different than these service types.