"Kubernetes Crash Course for Absolute Beginners [NEW]" - Transcript | YTScribe

hello and welcome to the kubernetes crash course where i will teach you everything you need to know to get started with kubernetes in one hour i am nana and i have taught hundreds of thousands of people how to advance their devops skills through my youtube channel online courses and the devops educational program if you're new here be sure to subscribe because i upload new videos all the time now let's look at an overview of what you will learn first of all we'll see what is kubernetes and why do we need it and why did it

become so popular second we will go through the kubernetes architecture and you will see how kubernetes actually works in the background after that we will cover main kubernetes components that you need to learn to work efficiently with kubernetes and finally we will do a hands-on demo project to get your first practical experience with kubernetes now kubernetes is a very popular but also a very complex technology so this crash course will help you get your first experience to get started with kubernetes but if by the end of the video you decide to deepen your knowledge in

kubernetes and are thinking about a career as a kubernetes administrator my new complete kubernetes administrator course will be a great resource for you where you will learn how to build configure and manage kubernetes clusters from scratch the course is also dedicated to help you pass the cka exam from linux foundation to become a certified kubernetes administrator now we have a lot to cover in this video so let's jump right into it so let's jump in right into the definition what is kubernetes so kubernetes is an open source container orchestration framework which was originally developed by

google so on the foundation it manages containers be docker containers or from some other technology which basically means that kubernetes helps you manage applications that are made up of hundreds or maybe thousands of containers and it helps you manage them in different environments like physical machines virtual machines or cloud environments or even hybrid deployment environments so what problems does kubernetes solve and what are the tasks of a container orchestration tool actually so to go through this chronologically the rise of microservices caused increased usage of container technologies because the containers actually offer the perfect host for

small independent applications like microservices and the rise of containers and the micro service technology actually resulted in applications they're now comprised of hundreds or sometimes maybe even thousands of containers managing those loads of containers across multiple environments using scripts and self-made tools can be really complex and sometimes even impossible so that specific scenario actually caused the need for having container orchestration technologies so what those orchestration tools like kubernetes do is actually guarantee following features one is high availability in simple words high availability means that the application has no downtime so it's always accessible by the

users a second one is scalability which means you can scale your applications fast when you have more load on it and more users are trying to access it and the same way you can easily scale it down when the load goes down so it makes your application more flexible to adjust to the increasing or decreasing load and the third one is disaster recovery which basically means that if an infrastructure has some problems like data is lost or the servers explode or something bad happens with the service center the infrastructure has to have some kind of

mechanism to back up the data and to restore it to the latest state so that application doesn't actually lose any data and the containerized application can run from the latest state after the recovery and all of these are functionalities that container orchestration technologies like kubernetes offer so how does the kubernetes basic architecture actually look like the kubernetes cluster is made up with at least one master node and then connected to it you have a couple of worker nodes where each node has a cubelet process running on it and cubelet is actually a kubernetes process that

makes it possible for the cluster to talk to each other to communicate to each other and actually execute some tasks on those nodes like running application processes each worker node has containers of different applications deployed on it so depending on how the workload is distributed you would have different number of docker containers running on worker nodes and worker nodes are where the actual work is happening so here is where your applications are running so the question is what is running on masternode masternode actually runs several kubernetes processes that are absolutely necessary to run and manage

the cluster properly one of such processes is an api server which also is a container an api server is actually the entry point to the kubernetes cluster so this is the process which the different kubernetes clients will talk to like ui if you're using kubernetes dashboard an api if you're using some scripts and automating technologies and a command line tool so all of these will talk to the api server another process that is running on master node is a controller manager which basically keeps an overview of what's happening in the cluster whether something needs to

be repaired or maybe if a container died and it needs to be restarted etc and another one is scheduler which is basically responsible for scheduling containers on different nodes based on the workload and the available server resources on each node so it's an intelligent process that decides on which worker node the next container should be scheduled on based on the available resources on those worker nodes and the load that that container needs and another very important component of the whole cluster is actually an etcd key value storage which basically holds at any time the current

state of the kubernetes cluster so it has all the configuration data inside and all the status data of each node and each container inside of that node and the backup and restore that we mentioned previously is actually made from these etcd snapshots because you can recover the whole cluster state using that etcd snapshot and last but not least also a very important component of kubernetes which enables those nodes worker nodes masternodes talk to each other is the virtual network that spans all the nodes that are part of the cluster and in simple words virtual network

actually turns all the nodes inside of a cluster into one powerful machine that has the sum of all the resources of individual nodes one thing to be noted here is that worker knows because they actually have most load because they are running the applications on inside of it usually are much bigger and have more resources because they will be running hundreds of containers inside of them whereas master node will be running just a handful of master processes like we see in this diagram so it doesn't need that many resources however as you can imagine masternode

is much more important than the individual worker nodes because if for example you lose a masternode access you will not be able to access the cluster anymore and that means that you absolutely have to have a backup of your master at any time so in production environments usually you would have at least two masters inside of your kubernetes cluster but in more cases of course you're going to have multiple musters where if one muster node is down the cluster continues to function smoothly because you have other masters available in this video we're going to learn

about the main kubernetes components that we as kubernetes administrators or users will be working with most of the time to make it easier to understand all these components i'm gonna build a simple use case of a web application with a simple database and i'm gonna show you step by step how each component in kubernetes helps you deploy such an application setup and what is the role of each of these components so let's start with the basic setup of a worker node or in kubernetes terms a node which is a simple server a physical or virtual

machine and the basic component or the smallest unit of kubernetes is a pod so what pod is is basically an abstraction over a container so if you're familiar with docker containers or container images so basically what pod does is it creates this running environment or a layer on top of the container and the reason is because kubernetes wants to abstract away the container runtime or container technologies so that you can replace them if you want to and also because you don't have to directly work with docker or whatever container technology you use in a kubernetes

so you only interact with the kubernetes layer so we have an application pod which is our own application and that will maybe use a database pod with its own container and this is also an important concept here pod is usually meant to run one application container inside of it you can run multiple containers inside one pod but usually it's only the case if you have one main application container and the helper container or some side service that has to run inside of that pod and as you see this is nothing special you just have one

server and two containers running on it with a abstraction layer on top of it so now let's see how they communicate with each other in kubernetes world so kubernetes offers out of the box a virtual network which means that each pod gets its own ip address not the container the pod gets the ip address and each pod can communicate with each other using that ip address which is an internal ip address obviously it's not the public one so my application container can communicate with database using the ip address however pod components in kubernetes also an

important concept are ephemeral which means that they can die very easily and when that happens for example if i lose a database container because the container crashed because the application crashed inside or because the nodes the server that i'm running them on ran out resources the pod will die and a new one will get created in its place and when that happens it will get assigned a new ip address which obviously is inconvenient if you are communicating with the database using the ip address because now you have to adjust it every time pod restarts and

because of that another component of kubernetes called service is used so service is basically a static ip address or permanent ip address that can be attached so to say to each pod so my app will have its own service and database pod will have its own service and the good thing here is that the life cycles of service and the pod are not connected so even if the pod dies the service and its ip address will stay so you don't have to change that endpoint anymore so now obviously you would want your application to be

accessible through a browser right and for this you would have to create an external service so external services a service that opens the communication from external sources but obviously you wouldn't want your database to be open to the public requests and for that you would create something called an internal service so this is a type of a service that you specify when creating one however if you notice the url of the external service is not very practical so basically what you have is an http protocol with a node ip address so of the node not

the service and the port number of the service which is good for test purposes if you want to test something very fast but not for the end product so usually you would want your url to look like this if you want to talk to your application with a secure protocol and a domain name and for that there is another component of kubernetes called ingress so instead of service the request goes first to ingress and it does the forwarding then to the service so now we saw some of the very basic components of kubernetes and as

you see this is a very simple setup we just have a one server and a couple of containers running and some services nothing really special where kubernetes advantages or the actual cool features really come forward but we're gonna get there step by step so let's continue so as we said pods communicate with each other using a service so my application will have a database endpoint let's say called mongodb service that it uses to communicate with the database but whether you configure usually this database url or endpoint usually you would do it in application properties file

or as some kind of external environmental variable but usually it's inside of the built image of the application so for example if the endpoint of the service or service name in this case changed to mongodb you would have to adjust that url in the application so usually you'd have to rebuild the application with a new version and you have to push it to the repository and now you'll have to pull that new image in your pod and restart the whole thing so a little bit tedious for a small change like database url so for that

purpose kubernetes has a component called config map so what it does is it's basically your external configuration to your application so config map would usually contain configuration data like urls of a database or some other services that you use and in kubernetes you just connect it to the pod so that pod actually gets the data that config map contains and now if you change the name of the service the endpoint of the service you just adjust the config map and that's it you don't have to build a new image and have to go through this

whole cycle now part of the external configuration can also be database username and password right which may also change in the application deployment process but putting a password or other credentials in a config map in a plain text format would be insecure even though it's an external configuration so for this purpose kubernetes has another component called secret so secret is just like config map but the difference is that it's used to store secret data credentials for example and it's stored not in a plain text format but in base 64 in encoded format but of course

basics before encoding a secret doesn't make it automatically secure the secret components are meant to be encrypted using third-party tools in kubernetes because kubernetes doesn't encrypt them out of the box and there are tools for that from cloud providers or separate third-party tools that you can deploy on kubernetes to encrypt your secrets and that will make secrets secure so secret would contain things like credentials and of course i mean database user you could also put in config map but what's important is the passwords certificates things that you don't want other people to have access to

would go in the secret and just like config map you just connect it to your pod so that pod can actually see those data and read from the secret you can actually use the data from configmap or secret inside of your application pod using for example environmental variables or even as a properties file so now let's see another very important concept generally which is data storage and how it works in kubernetes so we have this database pod that our application uses and it has some data or it generates some data with this setup that you

see now if the database container or the pod gets restarted the data would be gone and that's problematic and inconvenient obviously because you want your database data or log data to be persisted reliably long term and the way you can do it in kubernetes is using another component of kubernetes called volumes and how it works is that it basically attaches a physical storage on a hard drive to your pod and that storage could be either on a local machine meaning on the same server node where the pod is running or it could be on a

remote storage meaning outside of the kubernetes cluster it could be a cloud storage or it could be your own premise storage which is not part of the kubernetes cluster so you just have an external reference on it so now when the database pod or container gets restarted all the data will be there persisted it's important to understand the distinction between the kubernetes cluster and all of its components and the storage regardless of whether it's a local or remote storage think of a storage as an external hard drive plugged in into the kubernetes cluster because the

point is kubernetes cluster explicitly doesn't manage any data persistence which means that you as a kubernetes user or an administrator are responsible for backing up the data replicating and managing it and making sure that it's kept on a proper hardware etc because it's not taking care of kubernetes so now let's see everything is running perfectly and a user can access our application through a browser now with this setup what happens if my application pod dies right crashes or i have to restart the pod because i built a new container image basically i would have a

downtime where a user can reach my application which is obviously a very bad thing if it happens in production and this is exactly the advantage of distributed systems and containers so instead of relying on just one application part and one database part etc we are replicating everything on multiple servers so we would have another node where a replica or clone of our application would run which will also be connected to the service so remember previously we said the service is like a persistent static ip address with a dns name so that you don't have to

constantly adjust the end point when a pod dies but service is also a load balancer which means that the service will actually catch the request and forward it to whichever part is least busy so it has both of these functionalities but in order to create the the second replica of the my application pod you wouldn't create a second part but instead you will define a blueprint for a my application pod and specify how many replicas of that pod you would like to run and that component or that blueprint is called deployment which is another component

of kubernetes and in practice you would not be working with pods or you would not be creating pods you would be creating deployments because there you can specify how many replicas and you can also scale up or scale down the number of replicas of pots that you need so with pot we said that pot is a layer of abstraction on top of containers and deployment is another abstraction on top of pots which makes it more convenient to interact with the pods replicate them and do some other configuration so in practice you would mostly work with

deployments and not with pods so now if one of the replicas of your application pod would die the service will forward the requests to another one so your application would still be accessible for the user so now you're probably wondering what about the database pod because if the database part died your application also wouldn't be accessible so we need a database replica as well however we can't replicate database using a deployment and the reason for that is because database has a state which is its data meaning that if we have clones or replicas of the

database they would all need to access the same shared data storage and there you would need some kind of mechanism that manages which parts are currently writing to that storage or which pods are reading from the storage in order to avoid data inconsistencies and that mechanism in addition to replicating feature is offered by another kubernetes component called statefulset so this component is meant specifically for applications like databases so mysql mongodb elasticsearch or any other stateful applications or databases should be created using stateful sets and not deployments it's a very important distinction and stateful said just

like deployment would take care of replicating the pots and scaling them up or scaling them down but making sure the database reads and writes are synchronized so that no database inconsistencies are offered however i must mention here that deploying database applications using stateful sets in kubernetes cluster can be somewhat tedious so it's definitely more difficult than working with deployments where you don't have all these challenges that's why it's also a common practice to host database applications outside of the kubernetes cluster and just have the deployments or stateless applications that replicate and scale with no problem

inside of the kubernetes cluster and communicate with the external database so now that we have two replicas of my application pod and two replicas of the database and they're both load balanced our setup is more robust which means that now even if node one the whole node server was actually rebooted or crashed and nothing could run on it we would still have a second node with application and database pods running on it and the application would still be accessible by the user until these two replicas get recreated so you can avoid downtime so to summarize

we have looked at the most used kubernetes components we start with the pods and the services in order to communicate between the parts and the ingress component which is used to route traffic into the cluster we've also looked at external configuration using config maps and secrets and data persistence using volumes and finally we've looked at pod blueprints with replicating mechanisms like deployments and stateful sets where stateful set is used specifically for stateful applications like databases just using these core components you can actually build pretty powerful kubernetes clusters before moving on i want to give a

shout out to castin who made this video possible kessen's k10 is the data management platform for kubernetes k10 basically takes off most of the load of doing backup and restore in kubernetes from the cluster administrators it has a very simple ui so it's super easy to work with and has an intelligent logic which does all the heavy lifting for you and with my link you can download k10 for free and get 10 nodes free forever to do your kubernetes backups so make sure to check out the link in the video description and now let's continue

so now that we have seen the basic concepts of kubernetes how do we actually create those components like pods and services to configure the kubernetes cluster all the configuration in kubernetes cluster actually goes through a master node with the process called api server which we mentioned briefly earlier so kubernetes clients which could be a ui a kubernetes dashboard for example or an api which could be a script or a curl command or a command line tool like cubectl they all talk to the api server and they send their configuration requests to the api server which

is the main entry point or the only entry point into the cluster and these requests have to be either in yaml format or json format and this is how example configuration in yaml format actually looks like so with this we are sending a request to kubernetes to configure a component called deployment which is basically a template or a blueprint for creating pods and in this specific configuration example we tell kubernetes to create two replica pods for us called my app with each pod replica having a container based on my image running inside in addition to

that we configure what the environment variables and the port configuration of this container inside of the pod should be and as you see the configuration requests in kubernetes are declarative form so we declare what is our desired outcome from kubernetes and kubernetes tries to meet those requirements meaning for example since we declare we want two replica parts of my app deployment to be running in the cluster and one of those parts dies the controller manager will see that the ease and shoot states now are different the actual state is one part our desired state is

2 so it goes to work to make sure that this desired state is recovered automatically restarting the second replica of that pod so here i have examples of a deployment and service configuration files side by side so the first thing is that every configuration file in kubernetes has three parts the first part is where the metadata of that component that you're creating resides and one of the metadata is obviously name of the component itself the second part in the configuration file is specification so each component's configuration file will have a specification where you basically put

every kind of configuration that you want to apply for that component the first two lines here as you see is just declaring what you want to create here we are creating deployment and here we're creating a service and this is basically you have to look up for each component there's a different api version so now inside of the specification part obviously the attributes will be specific to the kind of a component that you're creating so deployment will have its own attributes that only apply for deployment and the service will have its own stuff but i

said there are three parts of a configuration file and we just see metadata and the specification so where's the third part so the third part will be a status but it's going to be automatically generated and edit by kubernetes so the way it works is that kubernetes will always compare what is the desired state and what is the actual state or the status of that component and if the status and desired state do not match then kubernetes knows there's something to be fixed there so it's gonna try to fix it and this is the basis

of the self-healing feature that kubernetes provides for example here you specify you want two replicas of nginx deployment so when you apply this when you actually create the deployment using this configuration file that's what apply means kubernetes will add here the status of your deployment and it will update that state continuously so for example if a status at some point will say just one replica is running then kubernetes will compare that status with the specification and we'll know there is a problem there another replica needs to be created sap now another interesting question here is

where does kubernetes actually get the status data to automatically add here or update continuously that information comes from the icd remember the cluster brain one of the master processes that actually stores the cluster data so it cd holds at any time the current status of any kubernetes component and that's where the status information comes from so as you see the format of the configuration files is yemel that's why the extension here and generally it's pretty straightforward to understand it's a very simple format but yaml is very strict about the indentations so for example if you

have something wrongly indented here your file will be invalid but other than that it's pretty simple another thing is where do you actually store those configuration files a usual practice is to store them with your code because since the deployment and service is going to be applied to your application it's a good practice to store these configuration files in your application code so usually it will be part of the whole infrastructure as a code concept or you can also have its own git repository just for the configuration files so in this video i'm going to

show you what mini cube and cube ctl are and how to set them up so first of all let's see what is mini cube usually in kubernetes world when you are setting up a production cluster it will look something like this so you would have multiple masters at least two in a production setting and you would have multiple worker nodes and master nodes and the worker nodes have their own separate responsibility so as you see on the diagram you would have actual separate virtual or physical machines that each represent a note now if you want

to test something on your local environment or if you want to try something out very quickly for example deploying new application or new components and you want to test it on your local machine obviously setting up a cluster like this will be pretty difficult or maybe even impossible if you don't have enough resources like memory and cpu etc and exactly for the use case there's this open source tool that is called a mini cube so what a mini cube is is basically one node cluster where the master processes and the worker processes both run on

one node and this node will have a docker container runtime pre-installed so you will be able to run the containers or the pods with containers on this node so now that you have this virtual node on your local machine that represents mini cube you need some way to interact with that cluster so you need a way to create pods and other kubernetes components on the node and the way to do it is using cubectl which is a command line tool for kubernetes cluster so let's see how it actually works remember we said that minicube runs

both master and work processes so one of the master processes called api server is actually the main entry point into the kubernetes cluster so if you want to do anything in the kubernetes if you want to configure anything create any component you first have to talk to the api server and the way to talk to the api server is through different clients so you can have a ui like a dashboard you can talk to it using kubernetes api or a command line tool which is cubectl and cubectl is actually the most powerful of all the

three clients because with cube cdl you can basically do anything in the kubernetes that you want and throughout this video tutorials we're going to be using cube ctl mostly so once the cube ctl submits commands to the api server to create components delete components etc the work processes on minicube node will actually make it happen so they will be actually executing the commands to create the parts to destroy the parts to create services etc so this is the mini cube setup and this is how cubectl is used to interact with the cluster an important thing

to note here is that kipctl isn't just for minikube cluster if you have a cloud cluster or a hybrid cluster whatever cube ctl is the tool to use to interact with any type of kubernetes cluster setup so that's important to note here so now that we know what mini cube and cube ctl are let's actually install them to see them in practice now let's see how to install and run mini cube there are many different ways depending on your operating system and its architecture so the best way is to reference the official documentation and here

as you see minicube can run either as a container or a virtual machine and these are the resource requirements to run minicube on your machine so make sure you have enough resources for installation you just select the correct data for your machine in my case it's going to be mac os with a home homebrew installation and with one simple brew installed mini cube command i can basically install mini cube like this and as you see the latest mini cube version has been installed once minicube is installed we want to actually start or create a mini

cube cluster which is also super easy as you see we simply execute a mini cube start command however as i mentioned minicube must start either as a container or a virtual machine so we need either a container or a virtual machine tool installed on our laptop to run mini cube and this is going to be the driver for mini cube and opening the drivers page you see the list of supported drivers for linux mac os and windows and you see that docker is actually the preferred driver for running mini cube on all operating systems now

this may be a little bit confusing because as you know inside the kubernetes cluster we run docker containers and it's important to note here that mini cube insulation actually comes with docker already installed to run those containers but docker as a driver from minicube means that we are hosting minicube on our local machine as a docker container itself so we have two layers of docker mini cube running is a docker container and inside mini cube we have docker packaged in minikube to run our application containers and for hosting minicube on our machine we can use

docker so if you have docker already installed on your machine you're all set up to start a mini cube cluster if not also not a problem you can easily install it from here so clicking on install docker link this will take me to docker hub where i have docker desktop installation for windows and mac so i'm simply going to click in in my case docker desktop for mac and i'm gonna download and install docker and once downloaded just install it drag and drop into the applications folder and now we can start the docker daemon from

the applications and as you see docker is starting up so the download and installation may take some time but once docker is installed and running we can switch back to the terminal and start the mini cube cluster using mini cube start command passing docker as a driver option using the driver flag with docker value and let's execute and this may also take a while when you're running it first time because it needs to actually create the cluster and download all the necessary images and components so the next time you do mini cube start it should

actually go faster and as you see this command created a local kubernetes cluster on our machine with the latest kubernetes version 1.22 and now we can check the status of the cluster using minicube status command and we see that all the components inside are running and everything is configured and now start to actually interact with our cluster using command line tool and cubectl actually gets installed as a dependency when we install minicube which you see right here installing dependencies for minicube and kubernetes cli is actually cube ctl and that means we already have that available

we don't have to install it so now i can do cube ctl get node and this will display all the nodes in the cluster in our case we just have one node which is control plane and the worker node at the same time and we see information for each node like the status the kubernetes version that it's running as well as when it was added to the cluster so with this we now have an actual kubernetes cluster running locally on our machine and we can start deploying applications in it so from this point on we

are going to be interacting with the mini cube cluster using cubectl command line tool so minicube is basically just for the startup and for deleting the cluster but everything else configuring we're going to be doing through cubectl now we have enough knowledge to deploy a very simple but realistic application setup in a kubernetes cluster we will deploy a mongodb database and a web application which will connect to the mongodb database using external configuration data from config map and the secret and finally we will make our web application accessible externally from the browser so let's get

right in so i have two resources here we're going to reference the kubernetes documentation to create our components which is a realistic way of working with kubernetes and also a docker hub where i have the web application image that i created which is publicly accessible so you can also pull it directly from the docker hub in your kubernetes cluster so first let's go ahead and create all the kubernetes configuration files that we need for deploying our application setup and for that i'm going to go to visual studio code where i have a kubernetes demo folder

open and in this folder we're going to create four kubernetes configuration files that we need we're going to create a config map with mongodb database endpoint we're going to create a secret with username and password for mongodb and then we're going to create a configuration file for deploying a mongodb application and its service and then we're going to create kubernetes configuration file for deploying our simple demo app application with its service so the first file will be called config.yml and creating a config map in kubernetes is super simple for the syntax we can reference kubernetes

documentation so i'm going to copy the first part here paste it in and that's basically the main syntax we're starting from let's call our config map config so we have the metadata and then we have the actual contents of this config map within the data attribute we have all the key value pairs that we define as external configuration within this config map in our case we just have one which we're going to call url as a key and of course we need a value for the mongodb url and the value will be the service that

we're going to create for mongodb application and we're going to call that service service and in a couple of minutes you're going to see how to create this service and that will be basically all the configuration we need for creating config map so that one is done let's now go ahead and create secret dot yaml which will hold the username and password for mongodb application again to reference documentation i'm going to take this one and let's actually copy the whole thing so we have the secret kind instead of config map let's call this secret we

have type opaque which is the generic type for defining secret data basically and we have the same data attribute here and let's actually create our own values let's call this [Music] user and password and as you already learned the values in secret are base64 encoded so we can just set the values plain text we have to encode them first and encoding values is super easy we're just gonna do echo and let's call it user and base 64. encode it and the same way let's do password and paste those values and this will be our secret

configuration and now when we create deployments for our applications we can reference any of the values defined in the secret or config map so let's see how that works again let's create a new file and let's call this dot yaml this is going to be a configuration file where we're going to create deployment and service for mongodb you can have separate files for them but it's a very common thing to put them together because all the deployments need services so you have them grouped in one yaml file and again let's reference the documentation for the

deployment example syntax and we can then adjust the values as we need and as you see deployment configuration file looks a little bit more complex than configmap or a secret so let's go through the configuration and understand all these attributes so we have the metadata section and the specification and these are basically deployment specific configuration that we have in the specification section and let's start with the main part of the deployment which defines the blueprint for the pots and that blueprint is defined as a template so template basically is a configuration of the part within

the configuration of deployment and you see that template section has its own metadata and own spec or specification just like deployment has its metadata and specification right so this part actually configures the pod within a deployment and in the specification of the pod we have the definition of containers so this is a list of containers as you learned you can have multiple containers in a pot but mostly one main application per pot and this is where we define which image will be used to create this pod in our case this is going to be a

mongodb image and if we search for in docker hub that's basically the image name and you can find all the text in the text section and we're going to use the tag 5.0 so one go 5.0 that's where we define the image of the container within the pot we can name this mongodb this is just the name of the container and we also have the port where the container will listen and let's check our image and as you see mongodb starts at this port so we can just copy it and paste it in here so

this basically just configures our deployment to create pods with a mongodb image version 5.0 so that's the core of a deployment now let's see what is all this other stuff here first of all we have this labels attribute in the metadata section and then we also have match labels attribute so what is this about in kubernetes you can give any component a key value pair labels so you can label anything from pod to deployment to configmap etc and labels basically are additional identifiers of the components in addition to the name for example so you can

identify and address specific components using their labels now why do we need them first of all when we have multiple replicas of the same part each part will get a unique name however they can share the same label so we can identify all the part replicas of the same application using a specific label that all of them share and that's why in the metadata of the pod we always have this label so for pods labels is a required field for other components like deployment configmap etc labels is optional but it is a good practice to

set them now when we create pod replicas how does deployment know which parts actually belong to it or how does kubernetes know which pods belong to which deployments and that is defined using this part right here so selector match labels is in the specification of the deployment as you see and this defines that all the parts that match this label belong to this deployment so that's why we have match labels here so this selector will match the pods created with this configuration because they have label app engine x now are these labels given or can

you select any key value pairs well these are totally up to you you can call it whatever you want you can call it my key my value it doesn't really matter however the standard and a common practice in kubernetes is to use app key in the labels when labeling your applications and the value will obviously be whatever application you have so let's actually change and set the values to instead of nginx because that's our application and of course we want to match label app and let's also change this one right here to deployment and finally

last attribute we have here is replicas which is super simple and straightforward this just defines how many pods you want to create using this blueprint in our case let's do just one replica because it's a database and as you learned if you want to scale databases in kubernetes you should use stateful set and not a deployment to keep everything simple we're going to stick to one replica and that basically configures our mongodb deployment and the pod blueprint now let's add a service configuration because every application needs a service in kubernetes and that's going to be

a separate yaml unit or yaml section and we're going to separate it using three dashes which is basic yaml syntax nothing specific to kubernetes and again let's grab a service example and adjust it as we need now service configuration is much easier than the deployment as you see first let's change the name let's call it service and remember this is the end point which we will use to access and that's what we defined right here so this is the name of the service and in the specification we have service specific attributes first of all we

have the selector attribute which you already know from here now why do we need a selector in service because as you know service needs to forward the request that it gets to its endpoint pods how does service know which pods belong to it and which ones it should forward the requests to well using the same label selector as we saw on deployment so this should match the label of the pods that will belong to the service which is and that's how service and pods will find each other and then we have the ports configuration which

is also super simple service is accessible within the cluster using its own ip address and the port and we define its port right here and this can be any port that we decide on this could be 80 8080 doesn't really matter and we have the target port which is the port of the pods that belong to the service and logically enough the target port should always be the same as the container port because that's where the application in the pod is accessible that's where the service should forward the request to so again very important port

attribute sets the port of the service and target port tells service to which port it should forward the request to the pods and this should be same as the container port port and target port values can be different or again it's a common standard to select the same port for the service as well just to keep things simple so let's save this and that's our configuration for mongodb deployment and service now i'm going to copy this whole thing and create a deployment in service for web application for our kubernetes demo application and let's call this

webapp dot yaml paste everything in and we can just adjust all these values in the service and deployment all the labels and label selectors of course and right here we of course need the correct image of our web application going back to our docker hub this is the name of my image and again this is publicly accessible so you can use it as well and the tag is v 1.0 and there you go so this is a very simple node.js application which starts on port 3000 so that's why we need to define container port on

3000 and container port is same as target port on the service and we can set the service port to the same value and this will configure deployment and service for our web application so this is the basic configuration for deployment and service for any application in kubernetes cluster but we have one more thing to configure in our deployment components for both and web app which is we need to pass the data defined in the config and secret components first of all when starting a mongodb application we need to set user name and password so when

mongodb application starts it will automatically generate username and password for mongodb and we can then use that to access it in our cluster now how do we know how username and password can be configured in a mongodb on startup well we go to the image documentation and right here we see the environment variable names for username and password and these are actually required fields in most of the databases we have to set them otherwise we won't be able to access them so the next question is how do we configure environment variables in a container configuration

so how do we pass environment variables to this application running inside the container well that's also very easy we have n attribute for that which is a list of environment variables with names and values that's it so very simple so name is the environment variable name and value is the environment variable value so let's copy the name so this is the environment variable name that mongodb expects and we have to set a value whatever we want the username to be now we can directly set the username right here like this or in our case we're

going to reference them from secret and config components how do we do that also pretty simple we do value from and we want to reference it from the secret so we do secret key ref and under that we have the name of the secret which we called secret and the key which is user so kubernetes will basically find a secret with this name and get the value set for this key and substitute it as a value for this environment variable and the same way we're gonna configure a password so let's take the password that's the

name of the environment variable same secrets component this time with a different key and that's it so our mongodb configuration file is complete and when it starts a user with these credentials will be created when our web application starts it will need to connect to the database so we need to give this web application information about the database endpoint where can it access the database and which username and password to use to authenticate with the database and i have already configured this application inside to expect all these values as environment variables with specific names so

we're going to pass these three pieces of data as environment variables to the web app application so let's do that again the name of the environment variable the first one i actually called username and we can actually copy the same configuration and paste it here and you already see an advantage of using configuration from secret or config because if you need the same information in 10 different applications you create it once and reference it 10 times the second environment variable is for password and i called this one user pwd and finally our application needs the

database endpoint which will be db url and this value is not in the secret but in configmap and how do we access value from config map very similar as the secret so we have the same value from and instead of secret key ref we have config map kirev or key reference and then we have name which we called config and key which is the name of the key and that's it so we don't have any of the configuration values hard coded in our kubernetes configuration files we only have references which makes our configuration way cleaner

so if something changes or the values change here we don't have to adjust anything in our deployments so connectivity with the database is configured and there is one last thing missing in our web application configuration before we deploy all this which is making it accessible from the browser we want to be able to type in some url and access our web application from the browser right and as you learned we have external services for that so we will need to adjust the service configuration a little bit right now these service configurations both of them are

internal services so to make it external all we need to do is set a type which is by default cluster ip so that's the default type if we don't specify the type but we're going to set it to node port so node port is an external service type and it requires a third port which is called a node port so what is a node port port this is a port which will open on the kubernetes nodes on which the application will be accessible so on the node ip address in node port combination we will be

able to access this service which will then access the pods behind it and node port range is actually defined in kubernetes so we can't just type anything we want here like this it has to be within the range of thirty thousand and thirty two thousand seven hundred sixty seven so anything within this range is fine as a value so we can do 30 000 or 30 100 doesn't really matter so let's set this as a value and this completes the web app configuration file now we have a very simple but also pretty realistic configuration for

deploying an application with its database with external configuration in the cluster so as a final step we're just gonna create all these components one by one in kubernetes so i'm gonna open a terminal and we already have a mini cube cluster running but there are no components inside so first we need to create the external configurations because they need to be there when we create mongodb and web application deployments because they reference those configurations so let's create config and secret first to do that we have cube ctl apply command with minus f which stands for

file which takes a kubernetes configuration file as an input like this and creates whatever is defined inside and as you see config was created now let's create longer secret next we're gonna create a database because our web application depends on it so it should start first and again let's do cube ctl apply with mongo.yaml as an input and as you see deployment and service were created and finally let's deploy our web application and there you go so everything seems fine but of course we want to check all the parts and all the components that were

created in the cluster so for that i'm going to actually switch to command line so that we can see it better and first we're going to do cube ctl get all which gives you all the components created in the cluster which includes deployments the pods behind the deployment and all the services and as you see we have deployment and web app deployment parts each one with one replica running and we have the services for mongodb and web app and web app service is of node port type which means we can access it externally however we

don't see configmap and secret here we can get them using kubectl get config map and cubectl get secret commands so as you see displaying any component is pretty easy using cube ctl you just do kubectl get and the name of the component like pod and you get a list of those components with some additional data and cubesatl is actually a very powerful tool and it has a bunch of sub-commands so as a natural documentation for cubectl to basically have an overview and see what you can do with it you can always use cubectl help as

a documentation which lists all the sub-commands you can use with it one of them which we already used get and for each sub-command like cube ctl get you can also get some help and basically see all the examples plus all the available options so you can navigate all the options you have here so cube ctl get is obviously the most common command you're going to use to list all the components if you want to see more details about a certain component you can use cube ctl describe command for it a name of the component like

a service for example and the actual instance of that component like web app service and this will give you more detailed output about that specific component same way you can also do cube ctl describe pod and then name of the pod like this one and this will give you details about your pot including the status of how the pod was scheduled the container configuration labels etc and finally of course when you have applications running in your cluster you want to check the logs to troubleshoot debug or just make sure that everything is fine within the

pod and you can do that very easily using kubectl locks command and just specifying name of the pot like this this gives you logs of the container inside and you can even stream the logs using minus f option so the final step we want to validate that our application is also accessible from the browser and for that we actually configured the service and we can actually get the service using service or svc comment so how do we access this service from the browser because this is the port we're going to use to access it but

which ip address is it accessible at well the node port service is always accessible at the ip address of the cluster node so all the work nodes that the cluster has in our case we just have one which is the mini cube so we need the ip address of the mini cube to get that we just do mini cube ip or using kubernetes we can also get get node which gives you mini cube and a white output or a longer output than what you see here which will give you the ip address of the node

which is the same as this one right here and by the way you can use the all white option for any other get command for services pods etc to get some additional information like this so let's grab the mini cube ip address and access the application at this port which is 30 100 and there you go this is our web application which is connected to mongodb and we can also validate that by editing something and saving because this request goes to database and if we refresh the changes should still be there awesome so we deployed

an application with its database in kubernetes which is a blueprint configuration for most common application setups you're gonna have plus you also learn a couple of cubesitl commands as well as how to reference the kubernetes official documentation to help you configure and create all the components i hope i helped you learn a lot about kubernetes with this crash course and you feel much more confident with kubernetes now if you're serious about learning kubernetes in depth i actually have two more resources for you as i mentioned at the beginning if you want to really become an

expert in kubernetes and learn how to build and administer a cluster from scratch then my complete kubernetes administrator course will be a perfect resource for you but if your goal is rather to become a devops engineer then our complete devops educational program will be the best fit for you where during a six-month program you learn all the necessary concepts and technologies including kubernetes which you need to get started in devops or cloud engineering if you're interested you can find the links in the video description below and with that thank you for watching and see you

in the next video