‫I want to take a quick minute to talk about DNS and
‫Kubernetes. Sometimes we take it for granted in Docker,
‫and Swarm, and Kubernetes, DNS just kind of works.
‫I want to give you some details real quick on what's going
‫on in the background before we keep moving forward.
‫What you've experienced so far is if you're in a container,
‫and you cURL or ping a service name,
‫you get back the response.
‫So, clearly there's a DNS server in there
‫doing something to match services to
‫DNS names. Believe it or not, DNS is optional
‫as a service, or an add on, inside your Kubernetes cluster.
‫But, everyone puts one in there.
‫In fact, when you install it, whether it's kubeadm, or
‫Docker Desktop, or whatever you're using, there's going to
‫be a DNS server in there.
‫Starting with 1.11 Release, CoreDNS
‫is the default. It's sort of the standard.
‫There's a prior one called KubeDNS, which is deprecated at
‫this point, and we should all be using CoreDNS now.
‫What this is known as is DNS-based service discovery.
‫You had it in Docker. You had it in Swarm.
‫Basically, it works the same way in Kubernetes where when
‫you create a service, you get the hostname that matches
‫the service. But, that hostname is part of a larger
‫name, the fully qualified domain name.
‫We didn't get that in Docker or Swarm.
‫They were really just focused on hostnames.
‫With Kubernetes, we get more options, right.
‫So, out-of-the-box, you're just going to be talking
‫from one service to another using the hostname.
‫If you start using namespaces, and we
‫will go through that a little bit later.
‫Think of names spaces as a way to
‫section off all the different parts of different apps
‫into these areas inside the same cluster, that won't
‫really clash with each other.
‫You can't technically create the same pod, or the same
‫service, or the same Deployment, with the same
‫names, in the same namespace.
‫If you create other namespaces, which you
‫may do as you get more advanced, you can then have the
‫same things named in different namespaces and they won't
‫clash. That includes DNS.
‫In fact, when you look at the fully qualified domain name
‫standard here, you'll see that it has the hostname,
‫which we've been using so far.
‫Then the namespace name.
‫If you were to type out this full name, you would have to
‫specify the namespace.
‫By default, you've been working in default.
‫That's the default namespace for apps.
‫If you do a quick command at the command line
‫of kubectl get
‫namespaces, you'll see a list here.
‫I'm on Docker Desktop, so I get an extra one there
‫that says Docker, so that'll be just a part of your
‫Docker Desktop that runs some special Docker services that
‫do some of the magic that Docker provides in a Kubernetes
‫cluster. The default is the one you're dumped into on
‫a basic cluster. Then the other ones are standard that come
‫out-of-the-box with Kubernetes.
‫The system one, obviously, is running the control plane.
‫That's the system there.
‫The public, we don't really use much.
‫It's only got a couple of things in it.
‫Then node-lease is a new one in newer Kubernetes
‫environments.
‫These are really advanced topics that you won't really need
‫getting started. You could quite possibly run
‫your clusters without ever really messing a lot with those
‫namespaces. Usually, what you're going to be dealing with
‫is the default namespace and as you get larger, you
‫will possibly make multiple namespaces
‫for different applications that possibly had the same name.
‫Or maybe you want to deploy the same thing multiple times,
‫with the same service names, pod names,
‫deployment names, and you wouldn't want them to clash, so
‫you would create different namespaces for those.
‫It's a little bit similar to Swarm stacks,
‫but there's so much difference between the way namespaces
‫work and stacks work that I really don't want you
‫to get thinking that they're the exact same.
‫Namespaces is really just an organizational parameter,
‫and it doesn't, out-of-the-box, control networking
‫segmentation or anything like that.
‫That gets more advanced. You can worry about that stuff
‫later. Let's get back to this fully qualified domain name
‫there. Now that you know the hostname and the namespace
‫part, then it's .svc for service because
‫that's what we're looking up here.
‫That cluster.local you see on the end is the default
‫service DNS name given to your cluster when
‫you create it or spin it up.
‫If you're using something like kubeadm to build your
‫cluster out, you can change that name before you
‫build your cluster. This is the one, by default.
‫You'll know if you need to change it based on maybe
‫creating multiple Kubernetes clusters, or if
‫you've got some sort of external requirements for how your
‫apps find each other. Again, all this DNS is
‫inside your cluster only.
‫It's not some DNS service that outside services are going
‫to be able to see, or use, unless they're talking to
‫the Kubernetes API remotely.