‫For your first cluster, maybe even possibly your first few
‫clusters, you won't have to worry too much about this
‫concept of namespaces and contexts.
‫But, it is something you need to be aware of that it exists
‫in case you need to use it.
‫Namespaces is essentially virtual clusters,
‫or virtual views, inside a single cluster.
‫It filters not just the view of the command so
‫that you only see certain things when you type commands,
‫but it also, with the right network policy plugins,
‫can control the networking.
‫This is a little bit different than Swarm where Swarm,
‫out-of-the-box, you would create different overlay networks
‫and everything was essentially private.
‫In Kubernetes, networking and control of
‫apps and their privacy, and what they can see and access,
‫and what's physically controlled there is really dependent
‫on your network plugin.
‫Namespaces itself is not related
‫to Docker namespaces, which you may have heard of, which is
‫really a part of the Linux subsystem, and that's kind of
‫how containers work. This isn't anything to do with that.
‫This is simply Kubernetes saying, hey you might
‫have a whole lot of stuff going on in your cluster, and I'm
‫giving you the opportunity to make little mini clusters
‫where you'd set the namespace with a context and that's
‫your view is by changing your context.
‫You can change what you see.
‫Then the namespace is different segments
‫for filtering the commands, as well as potentially
‫the networking. On my system here on my desktop,
‫I simply see kubectl get namespaces and
‫that command shows me 4. That's kind of, out-of-the-box,
‫the standard you're going to see.
‫Default is what you've been working with so far.
‫That's made for the default namespace
‫of your apps. The only thing it really shows you when you
‫did a kubectl get all is the
‫Kubernetes API endpoint itself, right.
‫Until we start adding apps, we didn't really see anything
‫there. There's technically all this stuff running in the
‫background, right. That's what the kubectl get all
‫--all namespaces.
‫You can see all the API containers
‫and whatnot running inside Kubernetes itself
‫with that command. If I look at all the namespaces at once,
‫I get everything including system stuff.
‫This is a view of what it would look like on minikube
‫which puts everything into their own pods for running the
‫cluster itself.
‫There's a lot going on there.
‫The realization is that when you're normally
‫using Kubernetes, the command line focuses on the default
‫namespace, by default.
‫You're only going to see your apps there really, other
‫than the API endpoint.
‫That's a good thing, right. It hides the complexity of
‫what's going on in the background from your everyday
‫command, because you don't really need to see that stuff
‫unless you need to upgrade it, or change it, or if you have
‫a problem. Context comes into play for setting
‫your view for when you're running commands.
‫The kubectl does lots of things, right.
‫It can connect to different clusters.
‫It can change the authentication, or the user, that
‫you're using to talk to the cluster, which we haven't
‫talked about, or the namespace.
‫So, there's these three parts, really, of a context.
‫That is cluster, the authentication, or the user,
‫and then the namespace that you want to see.
‫All that's defined, by default,
‫in a file inside the .kube directory
‫of your home directory.
‫There's a file in there called config, and it will
‫basically be a YAML file of all, three of those parts.
‫You can have multiple entries in there, and you can
‫edit it however you'd like.
‫You could have a bunch of different clusters and as long as
‫you have the certificates to talk to them, the right
‫authentication, you can put all that stuff in that file,
‫and it's something you want to keep secret. It's not
‫something you really want to share because it typically has
‫your authentication keys for talking
‫to a cluster. If you use the kubectl config
‫command with the sub command of get contexts,
‫that's plural, you can see basically the
‫output of that file. Instead of dumping it raw, you
‫can actually see a little nice list of
‫what it's got inside it.
‫In my case, I've got my standard Docker Desktop on my local
‫machine. That entry is in there twice for the last few
‫editions of Docker Desktop because they've changed the name
‫so they're kind of keeping both in there for compatibility.
‫Then I have a local minikube and
‫a remote instance of micro K8s running
‫on an Ubuntu server.
‫So, you can imagine that if I was managing a lot of other
‫servers, I don't necessarily always want to ssh into those
‫machines. I really just want to sit on my local machine
‫and talk to that remote API.
‫You can use the kubectl config command with
‫any of the set options. You definitely want to check out
‫the help there. But, there's set options for setting
‫the defaults for each one of these, so you could
‫potentially change the user to have a different
‫authentication. So, maybe you have God rights instead of
‫just a subset of the commands that Kubernetes is
‫could run. Or, maybe you're going to change the cluster
‫you're talking to.
‫There's even command line plugins if you look around on
‫Google for allowing you to see in your
‫shell which of the context you're using.
‫That's kind of handy when you end up managing a whole bunch
‫different clusters. You want to know, hey which one am I
‫talking to right now? You can actually set that up, kind of
‫like how the get prompts will tell you what branch you're
‫in. These will tell you, in your prompt, what
‫context you have.