‫The advantage of you learning Docker, then Compose,
‫and then Swarm is that you have so much of the basic
‫knowledge here that I don't have to start from scratch when
‫I'm teaching you Kubernetes.
‫Some of the terminologies, especially when we talk about
‫the objects inside of Kubernetes that you control and use,
‫the terms can be a little bit confusing because some are
‫conflicting and some are just new.
‫By far the number one thing you're going to keep hearing,
‫if you've ever looked up anything in Kubernetesland, is the
‫pod. The pod is the basic unit of deployment.
‫We don't technically deploy containers directly
‫inside of Kubernetes.
‫We only deploy pods, and we use things
‫on top of that known as controllers
‫to control those pods.
‫Technically, you can deploy a pod directly,
‫but you're not really going to want to do that.
‫Almost always you'll create a controller that
‫is an object that continually sits there and
‫validates whether or not what's going on inside
‫of Kubernetes is what you've asked it to do.
‫It's a differencing engine that has different types.
‫You start out with Deployments and ReplicaSets which you'll
‫be using almost exclusively.
‫Deployments are very similar to the way we did services in
‫Swarm and that controls your pods
‫at lower levels. Then, you can change up and do
‫different types of controllers, even third-party types of
‫controllers including StatefulSets, and DaemonSets,
‫and Jobs, and CronJobs and so much more.
‫That's part of the flexibility of Kubernetes
‫is that it gives us this basic unit of pods and then allows
‫us to control that with controllers in different ways,
‫and allows us to get really creative with how we deploy our
‫systems.
‫The service is a little bit different in Kubernetes than
‫you were used to in Swarm.
‫The service really doesn't have anything to do with
‫deploying applications like you would in Swarm.
‫The services, specifically the endpoint that you give
‫to a set of pods, often when you use
‫a controller like a deployment controller to deploy
‫out a set of replica pods, you would
‫then set a service on that.
‫The service just means you're giving it a persistent
‫endpoint in the cluster so
‫that everything else can access that set of pods at
‫a specific DNS name and port.
‫Next up, real quick, is a namespace.
‫We won't really use namespaces much in Docker
‫Mastery itself because it's an optional, advanced feature,
‫but you will hear it mentioned if you're looking in
‫documentation or reading blogs and whatnot.
‫The namespace is really just a filter
‫on your view at the command line.
‫That's really all it is. It's not a security feature.
‫If you're familiar with some of the internals of Docker,
‫you hear about namespaces in Docker.
‫This is in no way the same thing.
‫This is simply a way for you to
‫filter your views when you're using the kubectrl command
‫line so that you only see the things you care about at the
‫moment. A good example might be when using Docker Desktop,
‫it defaults to the default
‫namespace and filters out all of the system containers
‫running Kubernetes in the background.
‫Because normally, you don't want to see those when you're
‫running the kubectrl command lines.
‫Then you can change the namespace to see those
‫if you want to see the different views.
‫Just think of it as a filter, not a security feature.
‫Of course, there's so much more to Kubernetes that will get
‫into eventually. There's Secrets.
‫There's ConfigMaps. There's a bunch of third-party stuff.
‫But enough with the concepts. Let's type commands and see
‫results at the command line and then we're going to
‫visualize it on the drawing board.