YTread Logo
YTread Logo

Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]

Jun 02, 2021
Hello and welcome to this complete Kubernetes

course

. The

course

is a combination of lively theoretical explanations but also practical demonstrations that you can follow, so let's quickly go over the topics I will cover in this course. The first part gives you an excellent introduction. to

kubernetes

we will start with the basics of what

kubernetes

actually is what problems it solves in kubernetes architecture you will learn how you can use kubernetes by showing all the main components after learning the main concepts we will learn and install minicube for local kubernetes cluster and go over the main commands to create purge and kill pods using cubectl which is the kubernetes command line tool.
kubernetes tutorial for beginners full course in 4 hours
After knowing the main commands of cubectl, I will explain the kubernetes yaml configuration files that we will use to create and configure components and then we will continue. through a practical use case where we will deploy a simple application configuration to the Kubernetes cluster locally to get your first hands-on experience with Kubernetes and feel more confident about the tool. In the second part, we will delve into more advanced and important concepts such as organization. your components using namespaces how to make your application available from outside using kubernetes Jump in and learn about Helm which is the package manager for kubernetes, plus we will look at three components in more detail first, how to persist data in kubernetes using volumes, second, how to implement stateful applications, such as databases, that use the stateful set component, and lastly, we will look at the different types of Kubernetes services for different use cases.
kubernetes tutorial for beginners full course in 4 hours

More Interesting Facts About,

kubernetes tutorial for beginners full course in 4 hours...

If you like the course, make sure to subscribe to my channel for more videos like this and also check out the video description for more related information. courses on udemy Etc. If you have any questions during the course or after the course or if you just want to stay in touch. I'd love to connect with you on social media, so make sure you follow me there too, so in this video. I'm going to explain what Kubernetes is, we'll start with the definition to see what the official definition is and what it does, then we'll look at the kubes troubleshooting case study, basically why kubernetes appears and what problems it solves, so let's jump right in to the definition of what is kubernetes, then kubernetes is an open source container orchestration framework that was originally developed by Google, so based on it, it manages the speed of Docker containers or some other technology, which It basically means that Kubernetes helps you manage applications that are made up of hundreds or maybe thousands of containers and helps you manage them in different environments such as physical machines, virtual machines or cloud environments or even hybrid deployment environments.
kubernetes tutorial for beginners full course in 4 hours
So what problems does Kubernetes solve and what are the tasks of Actually a container orchestration tool, to look at this chronologically, the rise of microservices cost more use of container technologies because containers actually offer the host perfect for small standalone applications like microservices and the rise of containers in microservices technology has actually resulted in applications that are now made up of hundreds or sometimes even thousands of containers, now managing those container loads across multiple environments using self-built scripts and tools can be really complex and sometimes even impossible, so that specific scenario actually caused the need to have container orchestration technologies, so what?
kubernetes tutorial for beginners full course in 4 hours
Those orchestration tools like Kubernetes actually guarantee the following features: One is high availability in simple words. High availability means that the application has no downtime, so users can always access it. The second is scalability, which means that the application has high performance, loads fast and users have very high response rates from the application and the third is disaster recovery, which basically means that if an infrastructure has some problems like data loss or servers blow up or something bad happens with the service center, the infrastructure must have some kind of response. type of mechanism to collect the data and restore it to the last state so that the application does not lose any data and the containerized application can run from the last state after recovery and all these are functionalities that container orchestration technologies like . kubernetes offering, so in this video I want to give you an overview of the most basic building blocks of kubernetes, but enough so that you can start using kubernetes in practice, whether as a devops engineer or a software developer.
Now Kubernetes has tons of components, but most. Most of the time you'll be working with just a handful of them, so I'll create a case of a simple JavaScript application with a simple database and show you step by step how each Kubernetes component works. helps you deploy your application and what is the function of each of those components, so let's start with the basic configuration of a worker node or in Kubernetes terms, a node that is a simple server, a physical or virtual machine and the basic or smallest component. the kubernetes unit is a pod, so what a pod is is basically an abstraction over a container, so if you're familiar with Docker containers or container images, basically what the pod does is create this environment runtime or a layer on top of the container and the The reason is because Kubernetes wants to abstract the container runtime or container technologies so that you can replace them if you want and also because you don't have to work directly with Docker, whatever the container technology that I use in Kubernetes, so it only interacts with the Kubernetes layer, so we have an application pod that is our own application and that maybe uses a data database pod with its own container and This is also an important concept here, the pot is usually intended to run an application container inside of it that you can run. multiple containers within a pod, but it's usually only the case if you have a main application container and a helper container or some secondary service that needs to run inside that pod and as you say this is nothing special, you just have a server and two containers. running on it with an abstraction layer on top of it, so now let's see how they communicate with each other in the Kubernetes world, so Kubernetes offers a virtual network out of the box, which means that each pod gets its own IP address, not the container that gets the pod.
IP address and each pod can communicate with each other using that IP address, which is an internal IP address, obviously it is not public, so my application container can communicate with the database using the IP address; However, pod components in Kubernetes are also an important concept that they are ephemeral. meaning they can die very easily and when that happens, for example if I lose a database container because the container failed because the application failed inside it or because the server nodes I'm running them on ran out of power. resources, the Pod will die. and a new one will be created in its place and when that happens it will be assigned a new IP address, which is obviously inconvenient if you communicate with the database using the IP address because now you have to adjust it every time the pod restarts and because of that another kubernetes component called a service is used, so the service is basically a static IP address or a permanent IP address that can be attached, so to speak, to each pod, so my application will have its own service and the database pod will have its own service and the good thing here is that the life cycles of the service and the Pod are not connected, so even if the Pod dies, the service and its IP address will remain, so you will no longer have to change that endpoint, so now you will obviously want your application to be accessible through a browser and for this you would have to create an external service, so External Services is a service that opens communication from external sources, but obviously you wouldn't want your database to be open to public requests and that's why you would do it. create something called an internal service, so this is a type of service that you specify when creating one;
However, if you notice that the external service URL is not very practical, basically what you have is an HTTP protocol with a node IP address very often. The node is neither the service nor the port number of the service, which is good for testing purposes if you want to test something very quickly, but not for the final product, so you'll typically want your URL to look like this if you want to talk with your application. with a secure protocol and a domain name and for that there is another Kubernetes component called Ingress, so instead of the service, the request first goes to Ingress and then forwards to the service.
Now we looked at some of the most basic components of Kubernetes. and as you can see this is a very simple setup, we just have a server and a couple of containers running and some services, nothing really special where the advantages of Kubernetes or the actual cool features really stand out, but we'll get there step by step , so Continue, as we said, the pots communicate with each other using a service, so my application will have a database endpoint, let's say called mongodb service which it uses to communicate with the database, but where do you configure normally this url or database endpoint?
Normally I would. in the app properties file or as some kind of external environment variable, but it's usually inside the built image of the app, so for example if the service endpoint or service name in this case changed to mongodb, you'd have to adjust that url in the app, so normally you'd have to rebuild the app with a new version and push it to the repository and now you'll have to pull that new image into your pod and restart everything, which is a bit tedious for a small change like the database URL, so for that purpose Kubernetes has a component called configmap, so what it does is basically your configuration external to your application, so the config map usually it would contain configuration data like URL 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 the configuration map contains and now if you change the service name , the endpoint of the service, you just adjust the configuration map and that's it, you don't have to create a new image and have to go through this whole cycle now part of the external configuration can also be the base username and password data, which may also change in the application deployment process, but putting a password or other credentials in a configuration map in a plain text format will be insecure even though it is an external configuration, so For this purpose, Kubernetes has another component called secret, so secret is like a configuration map, but the difference is that it is used to store secret data credentials for example, and is not stored in a plain text format , of course. but in the base 64 encoded format, that secret would contain things like credentials and of course I mean the database user, you could also put it in the configuration map, but the important thing is that the passwords, the certificates, the Things you don't want other people to have access to would come in. the secret and like the config map, you just plug it into your pod so the pod can actually see that data and read it from the secret.
You can actually use configuration map data or secret inside your application pod using for example environment variables or even as a properties file, now to review, we have seen almost all the most used Kubernetes building blocks , we have seen the pod, we have seen how the services are used, what the login component is useful for and we have also seen the external configuration. using configuration map and secrets now let's look at another very important concept in general which is data storage and how it works in Kubernetes so we have this part of the database which is used by our application and it has some data it regenerates some data with this setup you see now if the database container or Pod is restarted the data will disappear and that is problematic and inconvenient obviously because you want your database data or log data to persist from long term reliable way and the way you can do it in Kubernetes is by using another Kubernetes componentcalled volumes and how it works is that you basically attach a physical storage on a hard drive to your pod and that storage could be on a local machine i.e. on the same server node where the Pod is running or it could be on the remote storage , that is, on the same server node where the Pod is running. outside the Kubernetes cluster it could be cloud storage or it could be your own local storage which is not part of the Kubernetes cluster so it only has an external reference so now when the pod or container is restarted of the database, all data persists, it is important to understand the distinction between the Kubernetes cluster and all its components and storage, regardless of whether it is local or remote storage.
Think of storage as an external hard drive connected to the Kubernetes cluster because the point is Kubernetes. clustered explicitly does not manage any data persistence, meaning that you as a Kubernetes user or administrator are responsible for backing up the data, replicating and managing it and ensuring it is maintained on suitable hardware, etc. , because it doesn't deal with Kubernetes. Now let's see that everything works perfectly and a user can access our application through a browser. Now with this setup, what happens if my app pod crashes or I have to restart the Pod because I built a new container image?
Basically, you would have downtime. where a user can access 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 depending on a single application module and a part of the database etc., we are replicating everything on multiple servers so we would have another node where a replica or clone of our application would run that will also be connected to the service, so remember that earlier we said that the service is like an address Persistent static IP with a DNS name so you don't have to constantly adjust the endpoint when a pod dies, but the service is also a load balancer, meaning the service will actually catch the request and forward it to wherever it is. busy in the list so that it has both capabilities, but to create the second replica of my application pod, you would not create a second part, but rather you would define a blueprint for a pod of my application and specify how many replicas of that pod you would like to run and that component or that blueprint is called a deployment, which is another component of Kubernetes. and in practice you wouldn't be working with pulses or you wouldn't be creating pods, you would be creating deployments because there you can specify how many replicas and you can also increase or decrease the number of part replicas that you need with the pod.
We said that part is an abstraction layer over the containers and the deployment is another abstraction over the pods, which makes it more convenient to interact with the pods, replicate them and do some other configuration, so in practice you would mainly work with implementations and not. with pots, so now if one of the replicas of your application module dies, the service will forward the requests to another one so that your application is still accessible to the user, so now you are probably wondering what happens to the database module, because if the database part of the diet, your application would also not be accessible, so we also need a replica of the database; however we cannot replicate the database using a deployment and the reason for this is because the database has a state which is its data which means if we have clones or replicas of the database they would all need to access to the same shared data store and there you would need some kind of mechanism that manages which pods are currently writing to that storage or which pods are reading from that storage to avoid data inconsistencies and that mechanism, in addition to the replication feature, is offered by another Kubernetes component called stateful set, so this component is specifically designed for applications like databases, so MySQL mongodb elasticsearch or any other stateful application or database should be built using stateful sets and not deployments, It's very important. distinction and stateful said that like the implementation it would be responsible for replicating the pots and scaling them up or down, but making sure that the database reads and writes are synchronized so that there are no inconsistencies in the database;
However, I should mention here that deploying database applications using stateful ensembles in Kubernetes cluster can be somewhat tedious, so it is definitely more difficult than working with deployments where you don't have all of these challenges. That's why it's also common practice to host database applications outside of the Kubernetes cluster and only have the deployments or applications stateless. which replicate and scale seamlessly within 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 are both load balanced, our configuration is more robust, meaning that now even if Node 1, the entire node server rebooted or crashed and nothing could run on it, we would still have a second node with application pods and databases running on it. it and the user would still be able to access the application until these two replicas are obtained. recreated so you can avoid downtime.
To summarize, we have analyzed the most used Kubernetes components. We start with the pods and services to communicate between the parties and the Ingress component that is used to route traffic to the cluster. we look at external configuration using configuration maps and secrets and data persistence using volumes and finally we look at pod planes with replication mechanisms like deployments and stateful sets where the stateful set is used specifically for stateful applications like databases and Yes, there are many more components. that Kubernetes offers, but these are really the basics, the basics, just by using these core components, you can build pretty powerful Kubernetes clusters.
Video We will talk about the basic architecture of Kubernetes, so we will see two types of nodes that Kubernetes. operates in one is master and another is slave and we are going to see what the difference is between them and what role each of them has within the cluster and we are going to review the basic concepts of how kubernetes works. what it does and how the cluster is self-managed, self-healing and automated and how you as a Kubernetes cluster operator should end up having a lot less manual effort and we'll start with this basic setup of a node with two parts of the application running on it, so one of the main components of the Kubernetes architecture is your servers or worker nodes and each node will have multiple application pods with containers running on that node and the way Kubernetes does this is by using three processes that need to be installed on each node that is used to schedule and manage those parts, so the nodes are the servers in the cluster that actually do the work, that's why they are sometimes also called worker nodes, so the first process that needs to run on each node is the runtime of the container.
In my example, I have Docker. but it could also be some other technology, because application pods have containers that run inside a container runtime that needs to be installed on each node, but the process that actually schedules those pods and the containers underneath is cubelet, which is a kubernetes process. In itself, unlike the container runtime which has an interface to both the container runtime and the machine, the node itself because at the end of the day, cubelet is responsible for taking that configuration and running a pod or start a pod with a container inside and then allocate resources from that. node to the container, such as CPU, RAM and storage resources, so usually the Kubernetes cluster is made up of multiple nodes that must also have container runtime and cubelet services installed and may have hundreds of such worker nodes that will run other pods, containers and replicas of the existing parts like my application and the database pods in this example and the way the communication between them works is through Services, which is a kind of load balancer that basically captures matches with the request directed to the party or application like the database, for example, and then forwards it. to the respective party and the third process which is responsible for forwarding the requests of the services to the pods is actually the Cube proxy which also needs to be installed on each node and the Q proxy has a smart forwarding logic inside it which ensures that Communication also works efficiently. way with little overhead, for example if an application, my application replica is creating a requested database instead of a service, it just randomly forwards the request to any replica, it will actually forward it to the replica that is running on the same node as the Pod that initiated the request.
This avoids network overload by sending the request to another machine, so to summarize two Kubernetes processes, cubelet and Cube proxy should be installed on each Kubernetes worker node along with a separate container runtime for the Kubernetes cluster to work properly but now the question is how do you interact with this cluster or decide on which node a new application or database pod should be scheduled or if a replica part dies which process actually monitors it and then reschedule it or restart it again or when we add another server How does it join the cluster to become another node and create pods and other components on it?
The answer is that all these management processes are done by the master nodes, so the master servers or the master nodes have completely different processes running inside them and these are four processes that are running. on each masternode which controls the state of the cluster and the worker nodes as well, so the first service is the API server, so when you as a user want to deploy a new application to a Kubernetes cluster you interact with the server API using some client, it could be a The UI like Kubernetes dashboard could be a command line tool like cubelet or a Kubernetes API, so the API server is like a cluster gateway that receives the initial request for any updates on the cluster or even cluster queries and also acts as a gatekeeper for authentication. to make sure that only authenticated and authorized requests reach the cluster, that means every time you want to schedule new pods, deploy new applications, create a new service or any other component, you need to talk to the API server on the master node and then with the API server. validate your request and if everything is fine it will forward your request to other processes to schedule the Pod or create this component you requested and also if you want to check the status of your deployment or cluster Health Etc then make a Request to the API server and it gives you the response, which is good for security because you only have one entry point to the cluster, another master process is a scheduler, so as I mentioned, if you send an API server a request to schedule a new pod API.
The server, after validating your request, will hand it to the scheduler to start that application module on one of the worker nodes and of course instead of just randomly assigning it to any node, the program has this whole clever way of deciding what specific worker. node, the next pod will be scheduled or the next component will be scheduled, so first it will analyze your request and see how many resources the application you want to schedule will need, how much CPU, how much RAM and then it will look and check the worker nodes and see the available resources in each of them and if it says that OneNote is the least busy or has the most resources available, it will schedule the new part in that note.
An important point here is the programmer. it simply decides which nodes a new pod will be scheduled on. The process that actually does the scheduling and actually starts that pod with a container is the cubelet, so it receives the request from the scheduler and executes the request on that note. The next component is the controller manager. which is another crucial component because what happens when pods die on any node, there must be a way to detect that the nodes died and then reschedule those pods as soon as possible, so what the controller manager does is detect the changes such as the collapse of pods, for example. so when the pods the controller manager detects that and tries to recover the stateof the cluster as soon as possible and for that it makes a request to the scheduler to reschedule those inactive parts in the same cycle that happens here where the scheduler decides based on the resource calculation which worker nodes should restart those pods again and make requests to the cubelets corresponding processes on those worker nodes to actually restart the pods and finally the last master process is etcd which is a key value store of a cluster state.
You can think of it as a cluster brain. actually meaning every change in the cluster for example when a new pod is scheduled, when a pod dies all these changes are saved or updated in this edcd key value store and the reason why atcd store is a cluster brain is because all this mechanism with scheduler controller manager etc. works because of its data, for example how does the scheduler know what resources are available on each worker node or how does the manager know driver that a cluster remains modified in some way, for example the diet of the pods or the cubelet is restarted? new pods at the request of a programmer or when you make a query request to the API server about the state of the cluster or for example the deployment status of your application, where does the API server get all this state information from so that all this information is stored in the hcd cluster. is not stored in the LCD key value store, it is the actual application data, for example if you have a database application running within a cluster, the data will be stored somewhere other than the hcd, this is just a cluster status information used for the master. processes to communicate with worker processes and vice versa, so now you probably already see that master processes are absolutely crucial for the operation of the cluster, especially the SCD store that contains some data must be stored or replicated reliably, so in practice the Kubernetes cluster is usually made up of multiple Masters where each Master node runs its Master processes where of course the API server is load balanced and its ad store forms a distributed storage between all the master nodes so now Since we saw what processes run on the worker nodes and the master nodes, let's take a look at a really practical example of a cluster configuration, so in a very small cluster you probably have two masternodes and three workers.
Notes also to keep in mind here that the hardware resources of Master and Node servers actually differ, Master processes are more important but actually have less workload so they need less resources like CPU, RAM and storage, while the worker nodes do the actual work of running those pods with containers inside them, so they need more resources and as the complexity of your application and its resource demand increases, you can add more master servers and of node for your cluster and thus forming a more powerful and robust cluster to meet the resource requirements of your application, so in an existing Kubernetes cluster you can add new master or node servers quite easily, for so if you want to add a master server, just get a new core server, install all the master processes on it and add it to the Kubernetes cluster in the same way.
If you need two worker nodes, you will get a couple of servers, install all the worker node processes such as container runtime cubelet and Q proxy, and add it to the kubernetes cluster, that's it.and this way you can infinitely increase the power and resources of your kubernetes cluster, its replication complexity and resource demand increases, so in this video I will show you what minicube and Cube CTL are and how to configure them, first of all let's see what minicube is generally in the world of Kubernetes. When you are setting up a production cluster, it will look like this, so you would have multiple Masters, at least two in a production environment, and you would have multiple worker nodes and masternodes and the worker nodes have their own separate responsibility, so As you can see in the diagram, you will now have separate physical or virtual machines, each representing a node, if you want to test something in your local environment or if you want to test something very quickly.
For example, you deploy a new application or new components and you want to test them on your local machine, obviously setting up a cluster like this will be quite difficult or even impossible if you don't have enough resources like memory and CPU etc. and exactly for the usage. In this case there is this open source tool called mini cube, so what a mini cube is is basically a cluster of nodes where the master processes and the worker processes run on one node and this node will have a time pre-installed Docker container run so you will be able to run the containers or the pods with containers on this node and the way it will run on your laptop is through a virtual box or some other hypervisor, so basically minicube will create a virtual box on your laptop and the nodes that See here that this node will run on that virtual box, so to summarize, minicube is a OneNote Kubernetes cluster that runs on a virtual box on your laptop and which you can use to test Kubernetes in your local setup, now that you have set up a cluster or a mini cluster on your laptop or PC on your local machine, you need some way to interact with a cluster, so you want to create components, configure it, etc., and that's where cubectl comes into the picture, now that you have this virtual node on your premises. machine that represents the minicube, 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 that is using cubectl which is a command line tool to the Kubernetes cluster, so let's see how. actually works, remember we said that minicube runs master and worker processes, so one of the master processes called API server is actually the main entry point to the Kubernetes cluster, so if you want to do something in Kubernetes, if you want to configure something, create it.
For any component, first you had to communicate with the API server and the way to communicate with the API server is through different clients, so you can have a UI like a dashboard, you can communicate with it using Kubernetes API or a command line tool which is Cube CTL. and cubectl is actually the most powerful of the three clients because with qcdl you can basically do anything in Kubernetes that you want and throughout these video

tutorial

s we will be using cubectl primarily so that once Cube CTL sends commands to the API. server to create components delete components etc the worker processes on the minicube node will actually make this happen so they will run the commands to create the pods to destroy the parts to create services etc so this is the mini Cube configuration and this is how Cube CTL is used to interact with the cluster.
One important thing to note here is that qctl is not just for a minicube cluster if you have a cloud cluster or a hybrid cluster whatever Cube CTL is the tool you should use to interface with any type of Kubernetes cluster . configuration, so it's important to keep that in mind here, so now that we know what minicube and Cube CTL are, let's install them to see them in practice. I'm using Mac so the installation process will probably be easier, but I'll put links to installation guides in the description so you can follow them to install it on your OS, just one thing to note here is that minicube needs a virtualization because as we mentioned it will be running on a virtual box setup or some hypervisor so you will need to install some type of hypervisor, it could be virtualbox.
I'm going to install a hyperkit, but it will also be in those step-by-step instructions, so I'll show you how to install it on a Mac. I have a Mac OS Mojave, so I'll show you how to install mini Cube on this version of Macos and I'll use Brew to install it . Such a nice update and the first thing is that I'm going to install a hyperkit hypervisor, so I'm going to stick with the hyperkit and go ahead and install it. I already had it installed, so if you're doing it for the first time, it might take you longer because it has to download all these dependencies and stuff. and now I'm going to install minicube and here is what mini Cube has Cube CTL as a dependency so when you run this it will also install cubectl so I don't need to install it separately so let's see here how to install dependencies for minicube. which is Kubernetes CLI, this is Cube CTL again because I already had it installed before, it still has a local copy of the dependencies so it's pretty fast, it may take longer if you're doing it for the first time, now that everything is installed In fact , let's check the commands so the Cube CTL command should work so I get this list of commands with cubectl so it's there and mini Cube should work too and as you can see mini Cube comes with this command line tool which is pretty simple. with one command, the entire Kubernetes cluster will appear in this OneNote setup and you can do things with it and you can just stop it or kill it, it's pretty easy, so now that we have both installed and the commands are there, let's create a kubernetes cluster mini Cube and as you can see there is a start command, let's get this straight, this is how we are going to start a kubernetes cluster.
Q mini Cube start and this is where the installed hypervisor comes into play because since midi Cube needs to run in a virtual environment, we will tell minicube which hypervisor to use to start a cluster, for that we will specify an option which is the VM driver and here I will configure the hyperkey that I installed, so I am telling minicube to use the Hyperkit hypervisor to start this mini Cube virtual cluster, so when you run this it will download some things, so again it may take a little longer if you are doing it for the first time and as I mentioned mini Cube has Docker runtime or Docker Daemon pre-installed so even if you don't have Docker on your machine it will still work so you can create containers inside it because it already contains Docker which It's pretty good if you don't have it.
Docker is already installed, so Cube CTL is now configured to use minicube, which means that the mini Cube cluster is configured and the Cube CTL command that is intended to interact with Kubernetes clusters is also connected to that mini Cube cluster , which means that if I do Cube CTL get notes which only gives me a status of the kubernetes cluster notes it will tell me that a mini Cube node is ready and as you can see it is the only node and it has to roll because obviously it has than run the master processes um and I can also get the state with minicube by running the mini cube state so I see that the host is running cubelet which is a service that actually runs the pods using the container runtime so basically everything is running and by the way if you want to look at kubernetes. architecture in more detail and to understand how the master and worker nodes actually work and what all these processes are.
I have a separate video covering the Kubernetes architecture so you can watch it at this link and we can also check which version of Kubernetes we have installed. and normally it will be the latest version so with the qctl version you actually know what the kubernetes client version is and what the kubernetes server version is and here we see that we are using 1.17 and that is the version of kubernetes that is running on minicube cluster, so if you see both client version and server version in the result, it means that minicube is installed correctly, so from now on we are going to interact with mini cube cluster using line tool of cubectl commands, so mini cube is basically just for startup and to delete the cluster, but everything else of the configuration we will do through Cube CTL and all these commands that I ran here I will put in a list in the section of comments so you can copy them to In this video I'm going to show you some basic Cube CTL commands and how to create and debug parts in minicube, so now we have a mini Cube cluster and cubectl installed and once the cluster is configured it will use cubectl to basically do anything in the cluster to create components to get the state etc so the first thing we will get is the notes state so let's see there is a node which is a set and everything will run on that node because it is a mini.
Cube, then with cubect you will get I can check the parts and I don't have any so there are no resources. I can verify the services you maintain. It will get services and I only have one default service etc. so this Cube CTL gets I can list any Kubernetes components so now since we don't have anyattributes will be specific to the type of component you are creating, so the implementation will have its own attributes that only apply to the implementation and the service will have its own things, but I said there are three parts of a configuration file and we only see metadata and the specification, so where is the third part?
So the third part will be a state, but Kubernetes will generate and add it automatically, so the way it works is that Kubernetes always compares what is the desired state and what is the actual indicated state or the component state and if the state and the desired state do not match, then Kubernetes knows that there is something to fix there, so it will try to fix it and this is the Based on the self-healing feature that Kubernetes could provide, for example, here you specify that you want two replicas of the nginx deployment, so when you apply this, when you actually create the deployment using this configuration file, that's what is applied, it means that Kubernetes will stick to the state of your deployment. and it will update that state continuously, for example if a state at any time indicates that only one replica is running, then Kubernetes will compare that state to the specification and we will know that there is a problem and another replica needs to be created.
Another interesting question here is where does Kubernetes get that state data to automatically add it here or continually update it? That information comes from etcd. Remember that the cluster brain is one of the master processes that actually stores the cluster data so that your CD at any time contains the current information. The state is from any Kubernetes component and that is where the state information comes from. As you can see, the format of the configuration files is yaml, hence the extension here, and overall it's pretty easy to understand. It's a very simple format, but yaml is very strict. the indentations, for example, if you have something incorrectly indented here, your file will be invalid, so what I do, especially if I have a configuration file that is 200 lines long, is quite long.
I usually use some online yaml validator to see where I need to fix it. but other than that it's pretty simple, another thing is where you store those configuration files. A common practice is to store these with your code because since the implementation in the service will apply to your application, it is good practice to store this configuration. files in your application code, so it will usually be part of the entire infrastructure as a code concept or you can also have your own git repository just for the configuration files, so in the previous video I showed you that deployments They manage the parts below them.
So every time you edit something in a deployment, it kind of cascades down to all the ports that it manages and every time you want to create some pods, you'll actually create a deployment and it will take care of the rest. So how does this happen or where? Is all this defined in the settings? So here in the specification part of an implementation you see a template and if I expand it you'll see that the template also has its own metadata and specifications so it's basically a configuration file within a configuration file and the reason is that this configuration is applied to a pod, so the pod should have its own configuration inside the deployments configuration file and this is how all the deployments will be defined and this will be the model for a pod, like what image should it be . depending on which port you should open what will be the container name etc. the way the connection is established is by tags and selectors, as you can see the metadata part contains the tags and the specification part contains selectors, it is quite simple in a metadata gives components like deployment or pod a key-value pair and it could be any key-value pair you can think of.
In this case we have the nginx application and that tag simply attaches to that component, so we give it pods created using this blueprint tag application engine. X and we tell the implementation to connect or match all the labels with the NGINX application to create that connection, in this way the implementation will know what pods belong to you. Now the implementation has its own X tag application engine and the service uses these two tags. selector, then in the specification of a service we define a selector that basically makes a connection between the service and the implementation or its parts because the service must know which pods are registered with it, for which pods belong to that service and that connection is made . via the tag selector and we're going to look at that in a demo, then another thing that needs to be configured on the service and the pod is the ports, so if I expand this I see that the service has its port configuration and the container inside obviously a pod is running or needs to run its import correctly, so the way this is set up is basically that the service has a port where the service itself can be accessed, so if other services send a request to the nginx service here, you should send it to port 80, but this service needs to know which pod it should forward the request to, but also what port that pod is listening on and that is the destination port, so this needs to match the container port and with that we have our basic deployment and service configurations done and to note that most of these attributes that you see here on both parts are required so this will actually be the minimum configuration for the deployment and the service, so once we have those files, let's apply them or create components using them, so let's go to the console and Here I'm going to create both the deployment and the service so that Cube CTL applies the created deployment and the nginx service.
Now if I get the pods, I see that there are two replicas running because that's how I define it here and we also have our service, which is the engine. Service We can do it using Cube CTL, describe the service and the service name and here you will see the endpoints where you have all this state information here, like the things that We define in the configuration like application selector etc., we have the destination port We define and we have the endpoints here and these should be the IP addresses and ports of the pots that the service should forward the request to, so how do we know these? are the IP addresses of the correct pods because if qctl get pod you don't get this information then the way we do it or the way we find out is using get pod and then you do Dash or that is for outputs and then we want more information , all blank and here we see more columns, so we have the name and status ready etc., but we also have the IP address, so here is the IP address endpoint specified here and this is the other , so we know that the service has correct endpoints, so now let's look at the third part of the configuration file, which is a state that Kubernetes automatically generated and the way to do it is that we can get the nginx deployment in yaml format, so when I run this command I will get the result or the updated configuration of my deployment which actually resides in the hcd because etcd stores the state of the entire cluster including all the components so if I do this I will get the yaml output in my console, but I want it in the file, so I'm going to save it to the nginx deploy result, save it there and open it in my editor next to the original, as you can see a lot of things have been added, but let's just look at the state. part, Kubernetes automatically edits and updates all of this constantly, so it says how many replicas are running, what the status of those replicas is, and some other information, so this part can also be useful when debugging, so that's the state, but also if you noticed other things.
It has also been added in the metadata and specifications part, so for example the creation timestamp of when the component was created is automatically edited by Kubernetes because it is metadata, some unique ID, etc., you don't have to worry about that and in the specifications part. it just adds some default values ​​for that component, but again, you don't need to care or understand most of these attributes, but one thing to keep in mind here is that if, for example, you want to copy an implementation that you already have using, maybe automated scripts, You'll have to delete and get rid of most of this generated stuff, so you need to clean up that deployment config file first and then you can create another deployment from that model config, so that's it with this video, so from now on we are going to be working with the configuration files, for example, if I want to delete the deployment and the service, I can do it using the configuration file and also using delete and so the deployment will disappear and I can do the same for the service.
By using cubectl apply and Cube CTL delete, you can basically work with the configuration files in this video. We are going to deploy two applications, mongodb and Express, and I chose these two because they demonstrate very well a typical simple configuration of a web application and its database. so you can apply this to any similar setup you have, so let's see how we're going to do this. First we will create a mongodb pod and to talk to that pod we will need a service and we are going to create an internal service which basically means that no requests external to the Pod are allowed, only components within the same cluster can communicate with it and that is what we want, then we will create an Express deployment, we will need a mongodb database URL so that Express can connect to it and the second is the credentials i.e. the database username and password to that can authenticate, so the way we can pass this information to the Express deployment is through its deployment configuration file through environmental variables because that's how the application is configured, so let's create a configuration map that contains the database URL and we are going to create a secret that contains the credentials and we are going to reference both within that deployment file, so once we have that configuration, we are going to need that Express is accessed through a browser to be able to do this, we are going to create an external service that will allow external requests to communicate with the Pod, so the URL will be the HTTP IP address of the node and the service port, so with this configuration the request flow will now look like this, so the request comes from the browser and goes to the external Express service which will then forward it to the Express pod which the Pod will then connect to. internal mongodb service which is basically the URL of the database here and then it will forward it to the mongodb pod where it will authenticate the request using the credentials, so now let's go and create all this configuration using the Kubernetes configuration files, let's dive into it and we believe everything. configuration, so first of all I have a mini Cube cluster running.
If I do Cube CTL, I get everything, which basically gives me all the components that are inside the cluster. I only have one default Kubernetes service, so my cluster is empty and I'm feeling it from scratch. So the first thing I said we're going to do is create a mongodb deployment. I usually create it in an editor, so I'll go to the Visual Studio code and paste a prepared deployment file for mongodb in there and that's how it goes. to make it look like this, I have a deployment type and I have some metadata. I'll just call it mongodb implementation, tags and selectors.
In the previous video I already explained the syntax of Kubernetes yaml configuration file, so if you want to know what it is all about. these attributes mean that you can watch that video and here in the template I have a definition or blueprint for the parts that this deployment will create and I'm just going to use a replica, so the container is going to be called mongodb and this is the image that I'm going to take , so let's go and check the image configuration for mongodb and I see this image here, let's open this and basically what I'm looking for is how to use that container, that is, what ports will it open and what is the external configuration that will be needed?
So the default port of the mongodb container is 27017, so I'm going to use that and we're going to use environment variables, the root username and the root password, so basically I can define the admin username on the container startup. and password, so let's go ahead and configure all of that inside the configuration file, herebelow the mongodbit image, so we'll just leave the name of the image and it will pull the last one and that's what we want, so here. I'm going to specify which port I want to expose so that the ports are the attribute name and the container port and that's the standard port, so I'm going to leave that and below I'm going to specify those two environment variables so that one is called, let's see what it is. called is any database root username and here there will be one value so we will leave it blank for now and the other one is called initroot password and we will leave it blank also just value and once we have the values ​​here we are going to have a complete implementation for mongodb this is basically all we need now note that this is a configuration file that will be checked into a repository so normally you wouldn't write the admin username and password inside the file configuration, so what we are going to do now is create a secret where we will reference the values, which means that the secret will go away in Kubernetes and no one will have access to it in a Git repository.
First of all, we're going to save this incomplete deployment file, so let's call it deployment or just yemo and save it here for syntax highlighting and now before we apply this configuration, we'll create the secret. where the username and the root password will come out, so let's create a new file and I'm going to paste the configuration of a secret which is actually quite simple, so we have a type of secret and then we have metadata which again is just the name . we will call it mongodb secret. The opaque type is actually a default type, which is the most basic key-value secret type.
Other types, for example, include TLS certificates so you can create a secret specifically with the TL certificate type and a couple of others. types, but you'll mostly use the default one and these are the actual contents, so you have the data and here you have key-value pairs which of course are the names that come to mind, so we'll specify the username or We can actually call it root username and we're going to call it root password. This is so the values ​​in these key-value pairs are not plain text, so when we create a secret, the value must be base64 encoded, just as it can. that the easiest way is to go to your terminal so here I'm going to say Echo minus a very important option don't skip it otherwise it won't work and here I'm going to put a plain text value that I want so I'm going I'm going to keep using whatever, of course, you can have something more secret here and I'm going to use base64 encoding and the value that I get here I'm going to copy it into the secret setting as a value and I'm going to do the same with the password, so again I'll use a simple password, obviously you want to have something more secure and I'll copy it as a value here and keep it secret.
Dot yeml, okay, now we've just written. configuration files we haven't created anything in the cluster yet so this is just prep work and we have to create a secret before deployment if we are going to reference the secret within this so the order of creation matters because if I'm creating an implementation that references a secret that doesn't exist yet. I'll get an error, so it won't start since we have our first component. In fact, let's go ahead and create our secret from a configuration file, so again I'm going to go to my console, let's clean this all up and I'm going to go to the folder where I'm creating all of these configuration files.
I called it Kubernetes configuration and here I have my two files, so I'm going to do. Cube CTL applies Secret and created secret, so I'm going to do Cube CTL get secret and you should see that my secret has been created. This is something created by default with a different type and this is our secret here, so now that we have our secrets, we can reference it inside our deployment configuration file, so let's go back and this is how it's referenced to the content, to the key value data specific to the secret, so instead of value we're going to say value from and then I'll make secret key reference no.
The secret key reference and the name will be the secret name, so this one here and the key will be the key in the data. I want the value of this key-value pair, so I want this part of the data, so I'm going to reference it by key so I don't have to learn it by heart, obviously, all the syntax and attribute names. The important thing here is that you know roughly how to reference it; the actual syntax you can always google or maybe in older configuration files. but yeah, that's how you reference it and we're going to do the same thing with the password, so I'm going to do it from and just copy the rest here.
Remember that yemo is very strict about indentation, here it is the same secret but a different key, so I will use a password key here and that will be it, now we have the root username and password referenced from the secret and no there are actual values ​​inside the configuration file which is good for security because you don't want your credentials in your code repository are fine so our deployment file is actually ready so let's apply that and the created deployment which means that if I get everything, I should see the Pod starting the deployment and the replica set, so let's check how the pod is working in the container. creating, so let's see, it may take some time to create if it takes a long time and if you want to see if there is a problem there, you can also have Cube CTL describe the pod and the name of the Pod so that at least we know that there is nothing wrong over there.
We see that it's just pulling the image so that's what's taking so long so let's see again that Cube CTL gets the value and as you can see it's running so we have the mongodb deployment and the replica of the Pod one on your end running now. The second step is us. We are going to create an internal service so that other components or other ports can communicate with this mongodb, so let's go ahead and create the service configuration, so let's go back to yemo and here we can create a separate emo configuration file for secret or we can also include in it, so in yaml you can put multiple documents in one file, so if I put three dashes, that's basically a syntax for separating documents in yaml, so a new document will be started, so in I'm actually going to put both the deployment and the service in a configuration file because they usually go together, so here I'll paste the service configuration and, by the way, I'll put all these configuration files in the git repository and link the repository in the description of this video, so this is a service for mongodb, let's go over some of the attributes here, so it's the type of service, just the name we'll call it mongodb service selector.
This one is important because we want this service to connect correctly to the Pod and the way to do that is to use the selector and the tag, so using this here, the tags that the deployment and the pod have service can find the parts to which is going to be attached, so we have the selector here and this is an important part where we expose the service port, so this is going to be the service port and this is going to be the container and since we exposed the container port, this address right here, these two have to match, so the destination port is the container or pod port and this is the service port and obviously these two here can be different, but I'm going to use the same port and that's basically our service, so I'm going to create the service now, this file and I'm going to go back to my and like that, and I'm going to apply the same file that I applied before to create the deployment. so let's see what happens let's look at both the deployment and the configuration of the service but you know I haven't changed the deployment that's what it means here and a service is created so if I were to edit both for example I can reapply the file and the implementation.
The service can be changed, so I think using local configuration files is a useful way to edit its components, so now let's verify that our service was created. Get the service and this is our service and it is listening on port 27017. I showed this in one of the previous videos but we can actually also validate that the service is connected to the correct pod and to do that I will describe the service and the name of the service for this. Here I have the endpoint, which is an IP address of a pod and the port where the application inside the Pod is listening to it, so let's verify that this is the correct pod.
I mean, we only have one, but still, if I get pot and I want additional output than what I get by default, one of the columns includes the IP. address which is this one here, so 172.17 06 that is the IP address of the Pod and this is the port where the application listens inside the Pod, so everything is configured perfectly, the mongodb deployment and service has been created and , by the way, if you want to see all the components for an application um, you can also show them using cubectl get all, that will show all the components and you can filter them by name so that Bongo DB and here see the service deployment replica set and the pod, so when I do all that type of component it will be the first one here, okay, that's just additional information, so now the next step we're going to create the deployment and the Express service and also an external configuration where we're going to put the Database url for mongodb, so let's go.
Go ahead and do it, I'm going to clear that up and create a new file for the Express deployment and service, so this is the Express deployment draft, same stuff here, Express, that's the name and here we have the definition of the Pod where the image name is. is Express, let's go ahead and check that image as well, we don't need it, this is Express and that is the name of the Express image and let's see the same data here, let's see the port on which the Express application starts inside the container is 8081 and these are some of the environment variables, so obviously we need three things for Express: we need to tell it which database application it should connect to, so obviously we need to tell it the address of mongodb, the address of the database it should connect to connect to the internal service and we.
We're going to need credentials so that mongodb can authenticate that connection and the environment variables to do that are going to be admin username admin password and the mongodb endpoint is going to be this one here, so we need these three environment variables, so let's go ahead and use them. First, we are going to open the container ports port again and the reason why you have multiple ports is that inside the Pod you can open multiple ports, so it will be 8081 and now we will add the environment variables for the connectivity, so the first is the username and obviously it will be the same username and password that we defined here, so what I'm going to do is just copy them because they are actually the same, so the value we are going to read from the secret that is already there, so I'll paste it here.
The second environment variable is called administrator password and I'm also going to copy it from here and the third one will be the database server. and since this is also an external configuration, we could do value here and write the mongodb server address directly here or, as I showed you in the diagram at the beginning, we can put it in a configuration map which is an external configuration so that it is centralized, so it is stored in one place and also other components can also use it, so for example if I have two applications that use mongodb database, I can reference that external configuration here and if I have to change it somewhere moment, just change it in one place and nothing else will be updated, so we will keep this incomplete deployment configuration and create the configuration map which will contain the mongodb server address, so I will create a new file.
In fact, let's save this incomplete implementation, let's call it Express yaml and we'll come back to it later, so let's save that. Now we need a configuration map here, so I'm going to copy the configuration and this is also pretty simple, like a secret. you have the type which is the configuration map, the name and the same construction, see just as you saw here, the data which is a key-value pair, it does not have a type because it is just a type of configuration map and that's it , and here you again have key-value pairs, so the database URL and the server name are actually the service name.
It's as simple as that. What do we call our service? We call it mongodb service. So I'm going to copy the service name and that will be the database. Server URL, so I'm going to copy that and we'll actually call it a configuration map to keep it consistent, save it and just like with the secret, the order of execution or creation matters, so I have to have a map ofconfiguration already in the cluster for reference. So when we're done, I have to create the configuration map first and then the deployment, so the way I can reference the configuration map within the deployment is very similar to secret, so I'm actually going to copy everything from Secret, put it here, the only difference here is that instead of secret, I'm going to say configuration map, everything is camel and obviously the name will be configuration map, that's what we call it.
I think we copied the name and again the password. is the key in the key-value pair here, so let's copy that too, now I have our Express implementation, this is just a standard thing and this is where the Pod blueprint or container configuration exists. We have exposed port 8081. This is the image with the last label. and these are the three environment variables that Express needs to connect and authenticate with mongodb so that the deployment is complete and let's go ahead and create the configuration map first and then the Express CTL deployment apply the configuration map and I will do the CDL group, apply always Express and See the pod so the container creation looks good so let's see the pod and it's running and I actually want to see the Lux so I'm going to block the Express and here you will see that the Express service has started and the database is connected so now the final step is. to access Express from a browser and to do that we will need an external service for Express, so let's go ahead and create that one too, so let's clean up this output, let's go back to the visual code and like we did last time in the same file as an implementation .
I'm going to create an express service because in practice you never really have a deployment without the service so it makes sense to keep them together and this is the external service Express and this configuration right now looks exactly the same as the service mongodb. The configuration and even the ports are the same, as here. I have exposed the service port as 8081 and the destination port is where the container port listens. So how do I make these external services by doing two things in the spec section? under the selector I'm going to put a type and a type of this external service is load balancer, which I think is a bad name for the external service because the internal service also acts as a load balancer, so I've had two pods of mongodb, the internal one.
The service would also load balance the requests coming to these parts, so I think the name of the type of load balancer was not chosen very well because it could be confusing, but what this type of load balancer basically does is accept external requests assigning the service on an external IP. address, so another thing we're going to do here to make this service external is here, we're going to provide a third port and this is going to be called node port and what it is basically is the port where this external IP address is going to be. open so this will be the port that I will have to put in the browser to access this service and this node port actually has a range and that range is between 30,000 and 32,000 so I can't give it the same port as Here, like I said, it has to be between that range, so I'm going to go with 30,000, which is the minimum in that range and that would be it, so this configuration here will create an external service, let's go ahead and do that.
I'm going to show you exactly how these ports are different from each other, so I'm going to apply Express to create the service and if I get the service, I see that the mongodb service that we created earlier has a cluster IP type and the Express service that we just created . is the load balancer, which is the type we specifically define in the internal service. We do not specify any type because the cluster IP, which is the same as in the internal service type, is the default, so we do not need to define it when creating the internal balance. service and the difference here is that the cluster IP will give the service an internal IP address, which is this one here, so this is an internal IP address of the service and the load balancer will also give the service an IP address internal, but on top of that it will also give the service an external IP address where the external requests will come from and here it says pending because we are on minicube and it works a little different in a normal Kubernetes setup.
Here you will also see a real IP address. public and this is another difference because with the internal IP address you only have one port for that IP address, with internal and external IP addresses you have ports for both and that is why we had to define the third port, which was for the external IP address . like I said pending means it doesn't have the external IP address yet so in minicube the way to do it is using the minicube service command and I will need the service name so this command will basically assign my external service. a public IP address, so I'm going to run this and the browser window will open and I'll see my Express page, so if I go back to the command line, you'll see that this command here is signed as express service, a URL with a public IP. address or with an external IP address and the port which is what we defined in the node port, so basically I can copy that command which is the same as this one here and I get the page form in Express, so now with this configuration as is What's going to work is that when I make changes here, for example, I'm going to create a new database, let's call it test DB whatever and I'm going to create a request.
What just happened in the background is that this request came to the external Express service which then forwarded it to the Express pod and the Express pod connected to the mongodb service, an everlasting service and the mongodb service then forwarded that request finally to the pod mongodb and then all the way back and we have the changes here, this is how it is deployed. a simple setup of an application in a Kubernetes cluster in this video we will go over the uses of a namespace and best practices for when and how to use a namespace first of all what is a namespace in Kubernetes in the Kubernetes cluster you can organize. resources into namespaces so you can have multiple namespaces in a cluster you can think of a namespace as a virtual cluster within a Kubernetes cluster now when you create a cluster by default Kubernetes provides you with namespaces ready to use, so on the command line if you type Cube CTL get namespaces.
I look at the list of out-of-the-box namespaces that Kubernetes offers and let's go through them one by one. The Kubernetes dashboard namespace is automatically shipped in minicube, so it is specific to the mini Cube installation. You won't have this on a standard cluster, the first being the Cube system. The Cube system namespace is not intended for use, so you basically should not create anything or modify anything in the Cube system namespace. The components that are implemented in the namespace are the system processes. from master management processes or CTL cube etc., next is Cube public and what Q public contains is basically the publicly accessible data.
It has a configuration map that contains cluster information that can be accessed even without authentication, so if I write here cubectl cluster info, this is the result I get through that information and the third one is the cubenode lease, which It's actually a recent addition to kubernetes and the purpose of that namespace is that it contains information about the heartbeats of the nodes, so each node basically gets its own object that contains the information about the availability of those nodes and the fourth namespace is the default namespace and the default namespace is the one you will use to create the resources at first if you haven't created a new namespace but of course you can add and create new namespaces and the form where you can do it is by using the command cubectl Create Namespace with namespace name so I can create my namespace and if I do Cube CTL to get namespaces I see in my list now another way to create spaces namespace is to use a namespace configuration file, which I think is a better way to create namespaces because you also have a history in your configuration file repository of the resources you created in a cluster.
Ok, now we saw what namespaces are and that you can create new ones. that kubernetes offers some of them by default, but the question is what is the need for namespaces, when should you create them and how should you use them, and the first use case of using or creating your own namespaces is as follows: imagine which only has one default namespace provided by kubernetes and you create all your resources in that default namespace if you have a complex application that has multiple deployments creating replicas of many parts and you have resources like services and Maps configuration Etc, coming soon Your default namespace will be filled with different components and it will be really difficult to get an overview of what's there, especially if we have multiple users creating things inside, so a better way to use namespaces in this case is to pool resources into namespaces so that for example you can have a database namespace where you deploy your database and all its necessary resources and you can have a monitoring namespace where you deploy the promatoes and everything you need.
You can also have an elastic stack namespace where all elasticsearch kibana ETC resources go and you can have nginx Ingress resources. just a way to logically group your resources within the cluster now, according to the official kubernetes documentation, you should not use namespaces if you have smaller projects and up to 10 users. Personally, I think it's always a good idea to group your resources into namespaces. because as I said, even if you have a small project and 10 users, you may still need some extra resources for your application, such as logging system and monitoring system, and even with minimal configuration you may already get too much to handle. just throwing everything into a default namespace another use case where you will need to use namespaces if you have multiple machines so imagine this scenario: you have two machines using the same cluster and one machine deploys an application which is called deploy of my application, that is the name of the implementation they create. and that deployment has its configuration safe now, if another team had a deployment that accidentally had the same name but a different configuration and they created the deployment or applied it, they would overwrite the first team's deployment and if they are using for example a Jenkins. or some automated way of deploying that application or creating the deployment that they wouldn't even know they overwrote or broke another team's deployment.
So to avoid those kinds of conflicts again you can use namespaces so that each machine can work in its own namespace without disrupting the other, another use case for using namespaces is to say you have a cluster and want host both the build and dev environment on the same cluster and the reason is that for example if you are using something like the nginx driver or the elastic stack used for logging for example you can deploy it to a cluster and use it for both environments that way you don't have to deploy these common resources twice on two different clusters, so now staging can use both resources as In addition to the development environment, another use case for using namespaces is when you use blue and green deployment for the application, it means that in the same cluster you want to have two different production versions, so the one that is active is in production now and the other one. that will be the next production version, the application versions in those blue and green production namespaces will be different; however, same as we saw before in staging and development, these namespaces may need to use the same resource courses like again the nginx driver or elastic stack and this way again both can use these common shared resources without having to set up a separate cluster, so one more use case for using namespaces is to limit resources and access to namespaces when working with multiple machines, so again We have a scenario in which we have two teams working on the same cluster and each of them has their own namespace so what you can do in this scenario is give the teams access to only your namespace so they can only create the Updates remove resources in their own namespace, but cannot do anything in the other namespaces.
In this way, you even restrict or even minimize the risk of one team accidentally interfering with the work of another.team, so that everyone has their own isolated and safe environment. Something additional that you can do at the namespace level is limit the resources that each namespace consumes because if you have a cluster with limited resources, you want to give each computer a share of the resources for your application, so if one computer, let's say, consumes too many resources, then other computers. eventually they will have much less and your applications may not be scheduled because the cluster will run out of resources, so what you can do is per namespace you can define resource quotas that limit the amount of CPU RAM storage resources that can use a namespace, so I hope walking through these scenarios helped you analyze what use cases and how you should use namespaces in your specific project.
There are several characteristics you should consider before deciding how to group and how to use namespaces. The first is that you can't access most resources from another namespace, for example if you have a configuration map in Project, a namespace that references the database service, you can't use that map configuration map in the Project B namespace, but you will have to create the same configuration map that also references the database service, so each namespace will define or must define its own configuration map, even if it is the same reference and the same applies to the secret, for example, if you have credentials from a shared service, you will have to create that secret in each namespace where it is located.
However, we will need it, one resource that can be shared between namespaces is the service and that is what we saw in the previous slide, so the configuration map in the Project B namespace references the service that will eventually It will be used in a pod and the way it works is like this. In a configuration map definition, the database URL, in addition to its name, which is the MySQL service, will have a namespace at the end, so using that URL you can access services from other namespaces. names, which is very convenient and that's how you can use shared. resources like elasticsearch or nginx from other namespaces and one more feature is that we saw that most of the component resources can be created within a namespace, but there are some components in kubernetes that do not have namespaces, for so to speak, they are basically left globally in the cluster and you cannot isolate them or place them in a certain namespace and examples of such resources are volume or persistent volume and node, so basically when you create the volume it will be accessible in the entire cluster because it is not in a namespace. and you can actually list the components that are not bound to a namespace using a command cubectl API resources script script namespace fake and in the same way you can also list all the resources that are bound to a namespace using space of names true, now that you have learned what namespaces are, why to use them, in what cases it makes sense to use them, in what way and also some characteristics that you should consider.
Let's see how to create components in a namespace. In the last example, we have created components using configuration. files and nowhere have we defined a namespace so what happens is that by default if you don't provide a namespace to a component it creates them in a default namespace so if I apply this component of config map and let's do it right now then Cube CD applies less F config map if I apply that and do Cube CTL gets the config map my config map was created in a default namespace and I notice that even in the command cube CTL get config map I didn't use a namespace because Cube CTL get or cube CTL commands take the default namespace as default so Coupe CTL get config map is actually the same as cube CTL gets the config map script n or the namespace and the default namespace so these are the same commands it's just a shortcut because it takes the default value as The default namespace is fine so one way to creating this config map in a specific namespace is using the cubectle apply command but adding the flag namespace and the namespace name, so this will create a config map in my namespace and this It's one way to do it. inside the config file so I can wrap this config map config file to include the information about the target namespace itself so that in the metadata I can add the namespace attribute so if I apply this config file again using cubectl apply and now if I want to get the component which I created in this specific namespace then I have to add option or flag to cubectl get command because as I said by default it will check only in space default namespace, so I recommend using the namespace attribute in a configuration file instead of providing it to the cube's CTL command because, first of all, it's better documented so you know just by looking at the configuration file where creates the component because it could be important information and secondly, if you're using an automated deployment where you're just applying the configuration files, again, this is going to be a more convenient way to do it now if, for example, we take a scenario where Since a computer gets its own namespace and has to work entirely in the namespace, it could be quite annoying to have to add this namespace tag to each cubectl command, so to make it more convenient, there is a way to change this default or active namespace which is the default namespace to whatever namespace you choose and kubernetes or cubesatel don't have any out of the box solution for that but there is a tool called Cube NS or Cubans and you have to install the tool on Mac, so I'll run Brew install X, so this will install the Cubans tool as well, so once I have Cubans installed I can run the Cuban command. and this will give me a list of all the namespaces and highlight the one that is active which is the default right now and if I want to change the active namespace I can have Cube end the space and this will change the namespace active so if I do Cube it ends now I see that the active is my namespace so now I can run Cube CTL commands without providing my namespace but obviously if you switch between namespaces a lot this won't be as convenient for your own operating system and environment. different installation process so I am going to link the Cube CTX installation guide in the description below so in this video we are going to talk about what is Ingress and how you should use it and also what are the different use cases for Ingress , so first of all, let's imagine a simple Kubernetes cluster where we have a pod of my application and its corresponding service, my application service, so the first thing you need for a front-end application is for it to be accessible through from the browser so that external requests can reach your application, so a simple way to do this is through an external service where you can basically access the application using the HTTP protocol, the node's IP address and port;
However, this is good for test cases and if you want to test something very quickly. but this is not how the final product should look like, the final product should be like this, so you have a domain name for the application and you want a secure connection using https, so the way to do it is to use the Kubernetes component called Ingress, so I can have my Ingress application and instead of an external service I would have an internal service, so it would not open your application through the IP address and port and now if the request comes from the browser it will first reach Ingress and then to Ingress. redirect it to the internal service and eventually you will end up with the Pod, so now let's take a look and see what the external service configuration looks like so that you have a practical understanding and have the service which is of type load balancer. means we open it to the public by assigning an external IP address to the service and this is the port number that the user can access the application on, so basically the IP address, the external IP address and the port number that you specify here now with Ingress of course it looks different so let's go over the syntax of Ingress, basically you have an Ingress type instead of a service and in the specification where all the configuration happens you have the so called rules or routing rules and this basically defines that the primary address or all requests to that host must be forwarded to an internal service, so this is the host that the user will enter in the browser and Ingress users.
Define a mapping, so what happens when those requests are issued to that host? It redirects you internally to a service. The route here basically means the URL route, so everything after the domain name, so sweep any routes that come after, you can define those rules here and we'll look at some different examples of the route configuration later and , as you can see here, in this configuration we have an http CP protocol, so later in this video I will show you how to configure the https connection using the Ingress component, so right now in the specification we do not have anything configured for the secure connection , it is just adhdp and one thing to note here is that this HTTP attribute here does not correspond to this one here this is a protocol to which the incoming request is forwarded to the internal service so this is actually the second step and we should not confuse it with this one and now let's see how the internal service works This is what Ingress will look like, basically the reverse is the destination where the request will be redirected, the incoming request and the service name should correspond to the internal service name like this and the port should be the port of the internal service and as you can see here, the only difference between External and Internal Services is that here in internal service I don't have the thirdports, which is the note Port that starts at 30 000.
Now we have that attribute here and the type is a default type, not a load balancer, but an internal service type which is the cluster IP, so it should be a valid domain address so you can write anything. here, first of all, it has to be valid and you must map that domain name to the IP address of the node that represents an entry point to your Kubernetes cluster, for example, if you decide that one of the nodes within the Kubernetes cluster will be the entry point, then you need to map this to the AP address of that node or and we'll see that later, if you configure a server outside of the Kubernetes cluster that will become the entry point to your Kubernetes cluster, then you need to map this name from host to the IP address of that server, so now that we saw what the Kubernetes Ingress components look like, let's see how to actually configure Ingress on the cluster, so remember this diagram that I showed you at the beginning, so basically now you have a pod service and the corresponding Ingress if you create that Ingress component alone will not be enough for Ingress routing rules to work.
What you also need is an implementation for Ingress and that implementation is called an Ingress controller, so the first step will be to install an Ingress controller which is basically another pod or another set of parts running on your node in your cluster. Kubernetes and therefore the evaluation and processing of Ingress rules, so the yaml file that I showed you with the Ingress component is basically this part here and it needs to be additionally installed on the Kubernetes cluster, so What exactly is the ingress driver? The role of the ingress controller is to evaluate all the rules that you have defined in your cluster and in this way manage all the redirects, so basically this will be the entry point into the cluster for all requests to that domain or subdomain rules that you have configured and this will evaluate all the rules because you may have 50 rules or 50 Ingress components created in your cluster, it will evaluate all the rules and decide based on that which forwarding rule applies for that specific request, so in order To install this Ingress implementation on your cluster, you must decide which of the many different third-party implementations you want to choose.
I will put a link of the

full

list in the description where you will see different types of Ingress controllers that you can choose from there is one kubernetes one which is the kubernetes nginx ingress controller but there are also others so once you install the kubernetes nginx ingress controller Ingress in your cluster, you will be ready to create Ingress rules and all the configurationwill work, so now that I've shown you how you can use Ingress in a Kubernetes cluster. I think there is one thing that is important to understand in terms of configuring the entire cluster to be able to receive external requests.
Now first of all you need to consider the environment where Your Kubernetes cluster is running if you are using any cloud service providers like Amazon Web Services, Google Cloud Leno, there are a couple more that have Kubernetes solutions outside of books or have their own virtualized load balances etc. your cluster setup would look like this. so you would have a cloud load balancer deployed specifically by that cloud provider and external requests coming from a browser will first hit the load balancer and that load balancer will then redirect the request to the Ingress controller. This is not the only way to do it.
Even in the cloud environment, you can do it in two different ways, but this is one of the most common strategies and the advantage of using a cloud provider is that you don't have to implement a load balancer yourself, so with minimal effort. probably most cloud providers will have the load balancer up and running and ready to receive those requests and then for those requests in your Kubernetes cluster, so setup is very easy now, if you're deploying your Kubernetes cluster. Kubernetes in a basic environment, then you would have to do that part yourself, so basically you would have to set up some kind of entry point to your Kubernetes cluster and there is a whole list of different ways to do that and I will put that in the description as well, but in general terms.
Inside or outside a cluster there is a separate server, you will need to provide an entry point. In one of those types there is an external proxy server which can be a software or hardware solution that will play the role of that load balancer at an entry point. your cluster, so basically what this would mean is that you will have a separate server and you would give it a public IP address and open the ports for requests to be accepted and this proxy server will act as an entry point. to your cluster, so this will be the only one accessible externally, so none of the servers in your Kubernetes cluster will have a publicly accessible IP address, which is obviously a very good security practice, so all requests will come into the proxy server and then it will redirect the request to the Ingress controller and the Ingress controller will decide which Ingress rule applies to that specific request and all the internal forwarding of the request will be done, so as I said there are different ways to configure it and configure it depending on the environment you are in and also. which approach you choose, but I think it's a very important concept to understand how the entire cluster setup works, so in my case, since I'm using a mini Cube to demonstrate all this on my laptop, the setup will be pretty easy and although this might not exactly apply to your cluster setup, you will still see in practice how all these things work, so the first thing is to install the Ingress driver on minicube and the way to do that is by running minicube plugins that enable Ingress, so what this does is automatically. automatically configures or starts the kubernetes nginx deployment of the Ingress controller, making it one of many third-party deployments that you can also safely use in production environments, not just on mini Cube, but this is what a mini Cube does it really gives you out of the box so with a simple command it will configure the Ingress controller in your cluster and if you do Cube CTL to get the pod in a cube system namespace you will see the Ingress controller pod nginx running on your cluster, so once I have the Ingress driver installed, I can now create an Ingress rule. that the controller can evaluate, so let's go to the command line where I'm going to create an ingress rule for the Kubernetes Dashboard component, so on my mini Cube cluster I have a Kubernetes Dashboard that in This moment it cannot be accessed externally, so what am I going to do?
What I need to do is, since I already have an internal service for the Kubernetes dashboard and a pod for that, I'm going to set up a login rule for the dashboard so that I can access it from a browser using some domain name, so this shows me. all the components I have in the Kubernetes Dashboard and since I already have an internal service for the Kubernetes Dashboard and the pod that is running, now I can create an Ingress rule to access the Kubernetes Dashboard using some hostname like this Let's go ahead and do it. I'm going to create an Ingress Dashboard for Kubernetes, so this is just metadata, the name will be Ingress Dashboard and the namespace will be in the same namespace as the service and the pod, so in the spec we will define the rules, so the first rule is the hostname I'm going to call.
I'm going to define panel.com and HTTP forwarding to the internal service route. Let's leave it in all the routes and this is the backend of the service, so the name of the service. will be what we saw here, so this is the name of the service and the service port is where the service listens, so it's actually 80 here and this will be the Ingress configuration to forward each request that goes to Dashboard. com to internal Kubernetes. dashboard service and we know it's internal because its type is cluster IP so there is no external IP address so obviously I just made up hostnamedashboard.com it's not registered anywhere and I also didn't configure anywhere to what IP address should resolve this hostname and this. it's something you'll always have to configure so first of all let's create that Ingress rule for Cube CTL to apply multiple Ingress yaml panels, see Ingress was created so if I have Chris in the namespace it should see my Ingress here and as you see.
The address is now empty because it takes a little while to assign the address to Ingress, so we'll have to wait for it to get the IP address that will be assigned to this host, so I'm just going to look at this and see. that address was mapped, so what I'm going to do now is take that address and in my hosts file at the end I'm going to define that mapping so that the IP address is mapped to dashboard.com And again, this works locally. If I'm going to type dashboard.com into the browser, this will be the IP address it will be assigned to, which basically means the request will hit my mini Cube cluster and be delivered to Ingress. controller and ingress controller, then we're going to go and evaluate this rule that I've defined here and we're going to forward that request to the service, so this is all the configuration that we need, so now I'm going to go and log in to dashboard.com and I'm going to see my Kubernetes dashboard here , so Ingress also has something called default backend, so if I do Cube CTL, I describe Ingress, the Ingress name and the namespace, I will get this result and here is an attribute called default backend which maps to the port of Default HTTP backend. 80.
So what this means is that whenever a request comes to the Kubernetes cluster that is not assigned to any backend, so there is no rule to assign that request to a service, then this default backend is used to handle that request, so obviously if you don't have this service created or defined in your cluster, Kubernetes will try to forward it to the service, it won't find it and you will get a default error response, for example if I entered some route that I configured, I only get page not found, so a good use for this is to define custom error messages when a page is not found when a request comes in that you can handle or the application can handle so that users still see some meaningful error message or just a custom page. where you can redirect them to your home page or something like this so all you have to do is create an internal service with the same name so the default should be backend and port number and also create a pod or application that sends that personalized air. response to the error message, so so far I have shown you what Ingress is and how you can use it.
I've also shown you a demo of how to create an Ingress rule in minicube, but we've only used a very basic Ingress Yaml setup, just a simple forward to an internal service with a route, but you can do a lot more with the setup. Ingress than just basic forwarding and in the next section we'll look at more use cases on how you can define finer granular routing for applications within Kubernetes. cluster, so the first thing is to define multiple routes of the same host, so consider the following use case. Google has one domain but it has many services that it offers, for example if you have a Google account you can use their analytics, you can use it to shop. a calendar, you have Gmail, etc. so these are all separate applications that can be accessed with the same domain, so consider that you have an application that does something similar, so it offers two separate applications that are part of the same ecosystem but that you still want to have. them in separate urls so what you can do is in the rules you can define the host which is myapp.com and in the route section you can define multiple routes so if the user wants to access your analytics app , you must enter my application. com Analytics and that will forward the request to the internal and analytics service in the Pod or if they want to access the shopping app then the URL for that would be myapp.com shopping, this way you can forward with an Ingress from the same host. for multiple apps using multiple paths, another use case is when instead of using URLs to make different apps accessible, some companies use subdomains, so instead of having analytics for myapp.com, they create a subdomain analytics .myapplication.com, so if you have your application configured that way your figure will look like this, so instead of having one host like in the previous example and multiple routes in here, you now have multiple hosts where each host represents a subdomain and inside you just have a route that again redirects that request to analytics The service is pretty simple, so now in the same request configuration you have an analytics service and a module behind it.
Now the request will look like this using the subdomain instead of the path and one last topic I mentioned that we will cover here is configuring the TLS certificate so far we have only looked at configuring Ingress for HTTP requests but it is very easy to configure forwarding https in Ingress, so all you need to do is define the attribute called TLS above the rules section with host, which is the same host as here and secret name, which is a reference to a secret you need to create in a cluster that contains that TLS certificate so the secret configuration would look like this so the name is the reference here and the actual data or content contains the TLS certificate and TLS key if you have seen my other videos where I create different components like secret, you probably notice the additional type attribute type here in Kubernetes there is a specific type of secret called TLS, so we will have to use that type when you create a TLS secret and there are three little nodes that need to be created here.
One is that the keys to this data need to be named exactly like this, the values ​​are the actual contents of the certificate file or the contents of the key and not the path or location of the file, so I have to put all the contents here, encode it in base64 and the third is that you have to create the secret in the same namespace as the Ingress component so you can use it, otherwise you can't reference a secret formula, the namespace, and these four. lines is all you need to configure the mapping of an https request to that host to the internal service.
In this video, I'm going to explain all the main concepts of Helm so you can use it in your own projects. Additionally, Helm changes a lot from version to version, so understanding the common core principles and, more importantly, its use cases, when and why we use Helm will make it easier for you to use it in practice, no matter what. version choose, so the topics I'm going to discuss This video shows Helm and Helm charts, how to use them and in what scenarios they are used and also what the helm is and what role it plays in the helm architecture.
So what is Helm? Helm has a couple of main features that are used. the first one is like a package manager for kubernetes, so you can think of it as apt, yam or Homebrew for kubernetes, so it is a convenient way to package collections of kubernetes yaml files and distribute them to public and private registries. Now these definitions may sound a bit abstract, so let's break them down with specific examples, so let's say you have deployed your application on the kubernetes cluster and you want to deploy elasticsearch additionally on yourcluster that your application will use to collect its logs to deploy the elastic stack to your kubernetes. cluster, you would need a couple of Kubernetes components, so you would need a stateful array that is for stateful applications such as databases, you will need a configuration map with external configuration, you would need a secret where some credentials and secret data are stored , you will need to create the kubernetes user with their respective permissions and also create a couple of services now if you were to create all these files manually searching for each of them separately on the internet it will be a tedious job until you have collected and tested all these yaml files and I tried it, it can take some time and since the elastic stack implementation is pretty much the standard across all clusters, other people will probably have to go through the same thing, so it made a lot of sense for someone to create these yaml files once, package them and create them. available somewhere so that other people who also use the same type of deployment can use them in their kubernetes cluster and that yemo file package is called a Helm chart, so by using Helm you can create your own Helm charts or packages of those yaml files and send them. them to some Helm repository to make them available to others or you can consume them so you can download and use existing Helm charts that other people pushed and made available in different repositories, so commonly used implementations like elasticsearch database applications mongodb MySQL or monitoring applications like Prometheus Everyone who has this kind of complex configuration has charts available in some Helm repository, so with a simple Helm install chart name command you can reuse configuration that someone else has already done without extra effort and sometimes that person is even the company that created the application and this chart sharing functionality that was widely used was actually one of the contributing factors to why Helm became so popular compared to its alternative tools, so now if you have a cluster and you need some kind of deployment you create. should be available, you can search for it using the command line so you can do a Helm search with a keyword or you can go to Helms in the public helmhub repository or the Helm chart pages or other repositories that are available and I will put All relevant links for this video in the description so you can watch them now, in addition to Public Logs for Helm charts, there are also Private Logs because when companies start creating those charts, they also started distributing them across the organization or internally within the organization.
It made a lot of sense to create Registries to share those charts within the organization and not publicly, so there are a couple of tools that are used as private Helm chart repositories and another functionality of Helm is that it is a templating engine, so, what does that do? Actually, I mean, imagine you have an application that is made up of multiple microservices and you are deploying them all in your Kubernetes cluster and the deployment and serving of each of those microservices are pretty much the same with the only difference being that the name of the app and versions are different or the docker image name and version tags are different, so without Helm you would write separate yaml file configuration files for each of those microservices, so you would have multiple deployment service files where each one has its own application name and version defined, but since the only difference between those yaml files is just a couple of lines or a couple of values ​​using Helm, what you can do is define a common model for all microservices and the values ​​that are dynamic or the values ​​that are going to change replace with placeholders and that would be a template file so the template file would look like this.
You would have a template file that is standard EML, but instead of values ​​in some places you would have the syntax, which means it is taking a value from the external configuration and that external configuration if you see the syntax here, dot values, that configuration external comes from an additional yemo file which is called values.yaml and here you can define all those values ​​that you will use in that template file so for example here those four values ​​are defined in a values ​​yml file and what point values ​​are : is an object that is created based on values ​​that are supplied through the values ​​CML file and also through the command line using script dash set scales, whichever way you define those additional values ​​that are combined and They put them together into a dot values ​​object that you can then use in those template files to get the values, so now instead of having yaml files for each microservice, you only have one and you can just replace those values ​​dynamically. and this is especially handy when you use continuous delivery continuous integration for your application because what you can do is in your build pipeline you can use those template DML files and replace the values ​​on the fly before deploying them to another use case Where you can use the helm functions of the package manager and templating engine is when you deploy the same set of applications to different Kubernetes clusters, so consider a use case where you have your microservice application that you want to deploy on development and production clusters, so instead of deploying the individual DML files separately to each cluster, you can package them to create your own application graph which will have all the necessary yaml files that that particular deployment needs and then you can use them to redeploy the same application to different Kubernetes cluster environments using one command which can also make the entire deployment process easier, so now that you know what Helm charts are used for, let's look at an example of Helm chart structure for understand better, so normally the chart is made up of such a directory structure, so you would have the top level be the name of the chart and inside the directory that would follow, so chart.yaml is basically a file that It contains all the meta information about the graph, it could be the name and version, maybe a list of dependencies etc. which I mentioned before. is where all the values ​​for the template files are set and these will actually be the default values ​​that you can override later.
The graph directory will have graph dependencies inside it, which means that if this graph depends on other graphs, those graph dependencies will be stored. here and the templates folder is basically with stored template files, so when you run the helm install command to deploy those yaml files to kubernetes, the template files from here will be populated with the values ​​from values.yaml producing a valid kubernetes manifest which can then be deployed to kubernetes and optionally you can have other files in this folder like readme or license file etc. To better understand how values ​​are injected into Helm templates consider that in values.yaml which is a default values ​​configuration has the following three values, image name, port and version and as I mentioned, the default values ​​that are defined here can be overwritten in two different ways.
One way is that when running the Helm install command, you can provide an alternative evaluation values ​​yaml file using valueflake, for example if the values ​​The yemo file will have the following three values, which are the image name, the port and version. You can define your own values ​​in the yaml file called myvalues.yaml and you can override one of those values ​​or you can even add some new attributes there and those two will be merged. will result in a DOT values ​​object that will look like this, so it will have the image name and port from value.yaml and the one you overwrote with your own values ​​file.
Alternatively, you can also provide additional individual values ​​using the set flag where you can define the values ​​directly on the command line but of course it is more organized and better manageable to have files where all those values ​​are stored instead of simply providing them on the line of command. Another feature of Helm is version management which is provided based on your configuration, but it is important. To note here the difference between Helm versions 2 and 3. In Helm version 2, the Helm installation comes in two parts: you have the Helm client and the server and the server part is called helm, so whenever you deploy Helm chart using Helm, install my chart help .
The client will send the yaml files to Tiller which actually runs or has to run on a Kubernetes cluster and Taylor will then execute this request and create components from these yemo files inside the Kubernetes cluster and exactly this architecture offers a valuable feature additional Helm, which is the release. management, so the way Helm clients' server configuration works is that every time you create or change the deployment, the peeler will store a copy of each configuration sent by the client for future reference, thus creating a history of chart runs, so that when you run the Helm update to the chart name, the changes will be applied to the existing deployment instead of deleting it and creating a new one and also in case the updates go wrong, e.g. some yaml files were fake or some configuration was wrong, you can rollback that update using Helm rollback chart name command and all this is possible because of the chart execution history that healer maintains every time you send those requests from Helm client to helm ;
However, this configuration has a big caveat, which is that helm has too much power within the Kubernetes cluster, it can create update kill components, and it has too much power. permissions and this actually makes it a big security issue and this was one of the reasons why in Helm 3 they removed the helm part and now it's just a simple Helm binary and it's important to mention it here because a lot of people have heard talk about the rudder. and when you deploy a Helm version 3, you should not be confused because Helm is no more. In this video, I'll show you how you can persist data in Kubernetes using volumes.
We will cover three components of the Kubernetes persistent storage volume. claim and storage class and see what each component does and how it is created and used for data persistence. Consider a case where you have a MySQL database part that your application uses, data is added and updated in the database, maybe create a new database with a new user. Etc., but by default, when you restart the Pod, all those changes will disappear because Kubernetes doesn't give you data persistence out of the box, that's something you need to explicitly configure for each application that needs to save data between pod restarts, so that basically you need storage that doesn't depend on the lifecycle of the Pod, so it will still be there when Paul dies and a new one is created so that the new part can pick up where the old one left off, so it reads the existing data from that storage to get updated data, however you don't know which node the new pod is restarted on, so your storage must also be available on all nodes, not just a specific one, so that when the new pod tries to read the data existing, the -Date data is on any node in the cluster and you also need highly available storage that survives even if the entire cluster fails, so these are the criteria or requirements that your storage, for example, data storage your database, you must have.
Another reliable use case for non-database persistent storage is a directory, perhaps you have an application that writes and reads files from a preconfigured directory, these could be session files for applications or configuration files etc. , and you can configure any of this type of storage using the Kubernetes component called persistent volume: Think of a persistent volume as a cluster resource like Ram or CPU that is used to store data. Persistent volume like any other component is created using Kubernetes yemo file where you can specify the type of persistent volume. and in the specifications section you have to define different parameters such as how much storage should be created for the volume, but since the persistent volume is just an abstract component, you have to take the storage from the actual physical storage such as local hard drive of the cluster nodes or their external NFS servers outside the cluster or perhaps cloud storage like AWS block storage or cloud storage.google cloud etc. so the question is where does this local or remote or cloud storage backend come from?
Who sets it up, who makes it available to the cluster, and That's the tricky part about data persistence in Kubernetes because Kubernetes doesn't care about your actual storage: it gives you a persistent volume component as an interface to the actual storage. that you as a maintainer or administrator need to take care of, so you need to decide what type of storage your cluster services or applications would need and create and manage them yourself. i.e. make backups and make sure they don't get corrupted, etc. So think of storage in Kubernetes as an external add-on to your cluster, whether it's local storage on real nodes where the cluster is running or storage remote, it doesn't matter if they are all plugins for the cluster and you can have multiple storages configured for your cluster where one application in your cluster uses local disk storage, another uses the NFS server and another uses some cloud storage or an application You can also use several of those storage types and When creating persistent volumes, you can use this actual physical storage, so in the persistent volume specification section you can define which storage backend you want to use to create that storage abstraction or resource. storage for your applications.
This is an example where we use the NFS storage backend. Basically, we define how much storage we need, some additional parameters to make the storage read, write or read-only etc., and the storage backend with its parameters. This is another example where we use Google Cloud as a storage backend again with storage. backend specified here and capacity and access modes here now, obviously depending on the storage type in the storage backend, some of the attributes in the specification will be different because they are specific to the storage type. This is another example of a local storage which is on the node itself, which has an additional node affinity attribute, now you don't have to remember and know all these attributes at once because you may not need all of them and I will also do separate videos that will cover some of the most used volumes and I will explain them. individually with examples and demonstrations, so I will explain in more detail what attributes should be used for these specific volumes and what they really mean.
In the official Kubernetes documentation you can see the

full

list of 25+ storage backends that Kubernetes supports note here that persistent volumes are namespace-less which means they are accessible to the entire cluster and unlike Other components we saw, such as pods and services, are not in any namespaces, they are now only available to the entire cluster in all namespaces. It is important to differentiate here between two categories of local and remote volumes. Each type of volume in these two categories has its own use case, otherwise they will not exist and we will look at some of these use cases later in this video.
However, local volume types violate the second and third data persistence requirement for databases that I mentioned at the beginning, which is that one is not bound to a specific node but to each node equally because you don't know where the volume will start. new pod and the second one will survive in cluster failure scenarios because of these reasons for database persistence you should almost always use remote storage so who creates these persistent volumes and when as I said persistent volumes are resources like CPU or Ram, so they must already be there in a cluster when the Pod that Depends on it or what usage is created, so a side note here is that there are two main roles in Kubernetes: there is a manager which configures the cluster and maintains it and also makes sure that the cluster has enough resources.
These are usually system administrators or developers. engineers in a company and the second role is a Kubernetes user who deploys the applications to the cluster, either directly or through the CI pipeline. These are development teams of developers who build the applications and deploy them, so in this case the Kubernetes administrator would be the one who would configure the actual storage, which means making sure the NFS server storage is there and configured or maybe create and configure a cloud storage that will be available to the cluster and secondly create persistent volume components from these storage backends based on the developer team's information of what types. of storage that your applications would need and the developers will then know that the storage is there and can be used by their applications, but for that the developers must explicitly configure the application's yaml file to use those persistent volume components; in other words, the application must claim that volume. storage and it does this using another kubernetes component called persistent volume claim persistent volume claims also PVCs are also created with the yaml configuration here is an example claim again don't worry understand each and every attribute that is defined here, but at the top level the way it works is that PVC claims a volume with a certain size or storage capacity which is defined in the persistent volume claim and some additional characteristics like the access type must be read-only or read and write or the Etc type and any persistent volumes that match this criteria or in other words, it satisfies that this claim will be used for the application, but that's not all you have to use now in configuring your pods in this way, so in the Pod spec here you have the volumes attribute that references the persistent volume claim with its name, so now the Pod and all containers within the Pod will have access to that persistent volume storage, so you have to go through those abstraction levels step by step and the parties access the storage using the claim as a volume right, so they request the volume through the claim. then it will go and try to find a persistent volume in the cluster that satisfies the claim and the volume will have a storage, the actual storage backend from which it will create that storage resource, this way the Pod will now be able to use that actual volume. storage package note here that claims must exist in the same namespace as the Pod using the claim while as I mentioned before persistent volumes do not have namespaces so once the Pod finds the matching persistent volume via the volume claim via the persistent volume claim, the volume is then mounted to the Pod like this, this is a pod level and then that volume can be mounted to the Container within the pod, which is this level right here and if you have multiple containers here in the Pod, you can decide to mount this volume on all containers or just some of them, so now the container and the application inside the container can read and write to that storage and when the Pod dies, a new one is created, it will have access to the same storage and see all the changes from the previous pod. or previous containers re-created the attributes here like volumes and volume mounts etc. and how they are used.
I'll show you more specifically and explain it in a later demo video. Now you may be wondering why so many abstractions to use the volume where you have the administrator role. To create a persistent volume and reuse the role, a claim is created on that persistent volume that is in use in the pod. Can I just use a component and set everything up fine? This actually has a benefit because as a user I mean a developer who just wants to deploy. your application on the cluster, you don't care where the actual storage is, you know you want your database to have persistence and whether the data is going to come out in a FS or AWS EBS gluster or on local storage, you don't care as long as the Data is stored safely or, if you need a storage directory for files, you don't care where the directory goes to, as long as you have enough space and it works properly and you don't want to worry about setting up these storages yourself. you just want 50 gigabytes of storage for your elastic or 10 gigabytes for your application, that's all, so you file a storage claim using PVC and assume that the cluster already has storage resources there and this makes it easier to deploy the applications to developers because they don't have to take care of things Beyond deploying the applications, now there are two types of volumes that I think should be mentioned separately because they are a little different from the rest and these are the configuration map and the secret now if you have seen my other video on Kubernetes components, then you are already familiar with both, both are local volumes, but unlike the rest, these two are not created through PV and PVC, but are components themselves and managed by Kubernetes itself .
Consider a case where you need a configuration file for your Prometheus pod or perhaps a message broker service like mosquito or consider when you need a certificate file mounted inside your application, in both cases you need a file available for your pod , so how this works is you create a config map or a secret component and you can mount it. that in your pod and in your container the same way you would mount a persistent volume claim, so instead you would have a configuration map or a secret here and I'll show you a demo of this in a video where I cover the types of local volumes to quickly To summarize what we have covered so far, we see that in essence and the volume is just a directory possibly with some data that can be accessed by the containers in a pod, how that directory is available or what storage medium actually packages it and the contents of that directory are defined by the specific volume type it uses, so to use a volume, a part specifies which volumes to provide for the pod in the specification volumes attribute and within the part, You can then decide where to mount that storage using the volume mount attribute. inside the container section and this is a path inside the container where the application can access any storage that we have mounted on the container and like I said if you have multiple containers you can decide which container should have access to that storage.
An interesting note for you is that a pod can actually use multiple volumes of different types simultaneously, let's say you have an elasticsearch application or a pod running in your cluster that needs a configuration file mounted via a map. configuration, you need a certificate, say a client certificate mounted as a secret and you need database storage. say which one is backed with AWS Elastic Block Storage, so in this case you can configure all three within your pod or deployment. This is the Pod spec that we looked at earlier and here at the volumes level it will simply list all the volumes that you want. mount on your pod so let's say you have a persistent volume claim and the background claims a persistent volume from AWS block storage and here you have the configuration map and here you have a secret and here on volume mounts you can list all those storage mounts using the names are correct so that you have the persistent storage, then you have the configuration map and the secret and each of them are mounted to a certain path inside the container.
Now we saw that to persist data in Kubernetes, administrators must configure storage for the cluster. Persistent volumes and developers can claim them using PVC, but consider a cluster with hundreds of applications where things are deployed daily and storage is needed for these applications, so developers need to ask administrators to create the persistent volumes they need for applications before deploying them and administrators afterwards. You may have to manually request storage from the cloud or storage provider and create hundreds of persistent volumes for all the applications that need storage manually and that can be time-consuming and complicated very quickly, so to make this process more efficient There is a third component. of Kubernetes persistence called storage class the storage class basically creates or provisions persistent volumes dynamically every time it is claimed by PVC and this way the creation or provisioning of volumes in a cluster can be automated.
The storage class is also created using the yaml configuration file, so this is an example file where you have the storage classstorage type storage class creates persistent volumes dynamically in the background, so remember that we defined the storage backend in the persistent volume component, now we have to define it in the storage class component and we do it using the provisioning attribute, which is the main part of storage class configuration because it tells Kubernetes which provisioner to use for a specific storage platform or cloud provider to create the persistent volume component from, so that each storage backend has its own provisioner that Kubernetes offers internally and is prefixed with Kubernetes DOT IO like this. one here and these are internal provisioners and for other or other types of storage, your external provisioners, then you have to explicitly go find them and use them in your storage class and in addition to the provisioner attribute, we configure the parameters of the storage that we want to request. our persistent volume like this is here, so the storage class is basically another level of abstraction that abstracts the underlying storage provider as well as the parameters for that storage or the characteristics of this storage, like what type of disk, etc. ., how it works or how to use the storage class. in Pod configuration, same as persistent volume, it is requested or claimed by PVC, so in PVC configuration here we add an additional attribute called storage class name which refers to the storage class that will be used to create a persistent volume that satisfies the claims of this PVC, so now when a pod claims storage via PVC, the PVC will request that storage from the Storage class, which will then provision or create a persistent volume that satisfies the needs of that claim using the actual storage backend provisioner.
This should help you understand the concepts of how data is persisted in kubernetes as a high level overview in this video we are going to talk about what stateful set is in kubernetes and what purpose it serves, so what is stateful set, the kubernetes component that is used specifically for stateful applications, so in order to understand that, you first need to understand what a stateful application is. Examples of stateful applications are all databases like MySQL elasticsearch mongodb etc. or any app that stores data to track your status on others. In words, these are apps that track status by saving that information in some storage.
Stateless applications, on the other hand, do not keep records of the previous interaction in each request or interaction is handled as a completely new isolated interaction based entirely on the information that comes with it and sometimes, stateless applications connect to the application stateful to forward those requests, so imagine a simple setup of a node.js application which is connected to mongodb database, when a request comes to the node.js application, it does not depend on any previous data to handle this request incoming, you can handle it based on the payload in the request itself. Now a typical request of this type will also need to update some data in the database or query the data, that's where mongodb comes in, so when node.js searches for words that request mongodb mongodb will update the data based on its previous state o will query data from your storage, so for each request you need to handle the data and obviously it always depends on the most up to date data or state being available, while node.js is just one step for data updates or queries and now just process the code because of this difference between stateful and stateless applications, both are implemented in different ways using different components in Kubernetes.
Stateless applications are deployed using the deployment component where the deployment is an abstraction of parts and allows you to replicate that application, which means Run 2 5 10 identical parts of the same stateless application on the cluster, so that while the Stateless applications are deployed using deployment, stateful applications in Kubernetes are deployed using stateful assembly components and just like stateful deployment makes this possible. to replicate stateful parts of the application or to run multiple replicas of it; in other words, they both manage parts that are based on an identical container specification and you can also configure storage with both equally in the same way, so if they both manage PODS replication and also the data persistence configuration In the same way, the question is what many people ask and they also often get confused about what is the difference between those two components, why do we use different ones for each type of application, so in the next section we are going to talk about the differences.
Now replicating a stateful application is more difficult and has a couple of requirements that stateless applications don't have, so let's look at this first with the example of a MySQL database. Let's say you have a part of MySQL database that you manage. requests from a Java application that is deployed using a deployment component and let's say you scale the Java application to three parts so that they can handle more client requests in parallel. Next you want to scale the MySQL application so that we can handle more Java requests and scale your The Java application here is quite simple.
Java application pod replicas will be identical and interchangeable, so you can scale them using one deployment quite easily. The deployment will create the pods in any random order. They will get random hashes at the end of the Pod name. You will get a service that balances the load on any of the replica pods for any request and also when you delete them, they are deleted in a random order or at the same time, or when you reduce them from three to two replicas, for example one. The random replica part is chosen to be removed, so there are no complications.
On the other hand, MySQL pod replicas cannot be created and deleted at the same time in any order and cannot be addressed randomly and the reason for this is that the parts of the replica are not identical, in fact each one has your own additional identity. In addition to the common model of the part from which they are created, and giving each part its own required individual identity is actually what makes the stateful assembly, different from the deployment, it maintains a fixed identity for each one. of its parts and, as I said, these parts are created from the same specification but are not interchangeable, each one has a persistent identifier that it maintains during any reprogramming, that is, when the boat dies and is replaced by a new part, maintains that identity.
The question you can ask now is why do these parts need their own identities, why can't they be interchangeable like with implementation, so why is this? This is a concept you should understand about scaling database applications in general when you get started. with a single MySQL pod it will be used to both read and write data, but when you add a second it can't act the same because if you allow two independent MySQL instances to change the same data, you will end up with consistent data. so instead there is a mechanism that decides that only one pole can write or change the data that is shared being read at the same time by multiple Parts MySQL instances from the same data is completely fine and the part that is allows updating the data is called master, the others are called slaves, so this is the first thing that differentiates these parts from each other, so not all ports are the same, but there is a mandatory module and they are the slave pods, and also There are differences between those slaves.
Parties in terms of storage, which is the next point, so the issue is that these parties do not have access to the same physical storage, although they use the same data, they are not using the same physical storage of the data, each one has its own storage replicas that each of them can access by themselves and this means that each pod replica at any time must have the same data as the others and to achieve that they have to continuously synchronize their data and as Master it is the only one one can change the data and the slaves have to take care of their own data storage, obviously the slaves have to be aware of every change so they can update their own data storage to be up to date for upcoming query requests and there is a mechanism.
In a clustered database configuration that allows continuous synchronization of data, the master changes the data and all slaves update their own data storage to stay in sync and ensure that each pod has the same state. Now let's say you have one master and two slave parts of my SQL now, what happens when a new pod replica joins the existing setup? Because now that new part also needs to create its own storage and then take care of syncing it. What happens is that it first clones the data from the previous part, not any part of in the settings, but always from the previous part and once the updated data has been cloned, it also starts continuous synchronization to listen for any updates from the Master pod and this also means and I want to point this out since it's nice.
An interesting point is that you can actually have temporary storage for a stateful application and not persist the data at all, since the data is replicated between pods, so in theory it is possible to rely only on replication of data between the pods, but this will also mean that all data will be lost when all parts die, for example if the stateful set is deleted or the cluster fails or all the nodes where these pod replicas are running fail and each part dies at the same time, the data will be gone and therefore it is still good practice to use data persistence for stateful applications if data loss will be unacceptable, as is the case in most database applications and with persistent storage, the data will survive even if all parts of the stateful set die or even if you completely delete the component from the stateful set and all parts will be erased, as well as persistent storage and the data will remain because the The life of the persistent volume is not connected or is not linked to a life cycle of other components such as the deployment or the stateful assembly and the way to do this is to configure persistent volumes for your stateful assembly and since each pod has its own data storage, meaning it is its own persistent volume that is then backed up to its own physical storage, which includes the synchronized data or the replicated database data, but also the state. of the Pod, so each pod has its own state which has information about whether it is a master pod or a slave or other individual characteristics and all of this is stored in the pot's own storage and that means that when a pot dies and is replaced , the persistent pod handles ensure that the storage volume reconnected to the replacement is a set because that storage has the state of the pod in addition to the replicated data.
I mean, you can clone the data again, there won't be any problem, but it shouldn't be lost. its state or identity state so to speak, and for this reconnection to work it is important to use a remote storage because if the Pod is rescheduled from one node to another, the old storage must also be available on the other node and cannot do it. use local volume storage because they are usually tied to a specific node and the last difference between deployment and stateful set is something I mentioned before is the pod identifier, which means that each pod has its own identifier, unlike the deployment where pods get random hashes at the end of the stateful set Parts get fixed ordered names which are made up of the stateful set name and the ordinal, it starts from zero and each additional part will get the next number, so if we create a stateful set called MySQL with three replicas, you will have pods with SQL names zero one and two, the first is the master and then come the slaves in the starting order.
An important note here is that stateful set will not create the next pod in the replica if the previous one is not already up and running. If the creation of the first pod, for example, failed or if it was pending, the next one will not be created at all. , it will simply wait and the deletion will be carried out in the same order but in reverse order, for example, if you deleted a stateful set or if I reduced it to one, for example from three, the deletion will start from the last part, so that MySQL 2 will be removed first, it will wait until that pod is removed withsuccess and then it will delete MySQL 1 and then delete my SQL zero and again.
All of these mechanisms are in place to protect the data and state that the stateful application depends on, in addition to these fixed and predictable names, each pod in a stateful array gets its own DNS endpoint from a service, so there is a service name for saveful. application as well as for deployment, for example, which will address any replica pod and furthermore there is an individual DNS name for each pod, which deployment pods do not have the individual DNS names which are made up of the pod name and the management service or government. name, which is basically a service name that you define within the stateful set, so these two features, i.e. having a predictable or fixed name, as well as your individual fixed DNS name, means that when the pod restarts , the IP address will change, but the name and endpoint will remain. the same is why you said pods get fixed identities so they stay stuck even between reboots and the fixed identity makes sure that each replica pod can retain its state and function even when it dies and is recreated and Finally, I want to mention An important point here is that you see that replicating stateful applications like databases with their persistent storage requires a complex mechanism and Kubernetes helps and supports you to set up all this but you still need to do a lot of things yourself. same where Kubernetes doesn't really help. you or not provide you with out-of-the-box solutions, for example you need to set up data cloning and synchronization within the stateful set and also make remote storage available as well as take care of managing it and backing everything up.
Of this, you have to do it yourself and the reason is that stateful applications are not a perfect candidate for containerized environments; in fact, Docker Kubernetes and containerization in general is perfectly suited for stateless applications that have no state or data dependencies and only process code to scale. and replicating them in containers is very easy in this video. First I will give you a complete overview of Kubernetes services. First I will briefly explain what service component is in Kubernetes and when we need it and then we will go over the different types of services. IP service, headless service, node port and load balancer Services.
I will explain the differences between them and when to use which one, so by the end of the video you will have a great understanding of Kubernetes services and you will be able to use them in practice, so let's start then, what is a service in Kubernetes and why do we need it? in a Kubernetes cluster? Each pod has its own internal IP address, but parts in Kubernetes are ephemeral, meaning they come and go very frequently and when the Pod is restarted or when it is old. one dies and the new one starts in its place, it gets a new IP address, so there's no point in using the pod's IP addresses directly because then you'd have to adjust that every time the Pod is recreated with the service however you had it made. a solution of a stable or static IP address that remains even when the Pod dies, basically in front of each pod we configure as a service, which represents a persistent stable IP address and access to that pod, a service also provides load balancing because When you have pod replicas for example, three replicas of your microservice application or three replicas of the MySQL application, the service will basically direct each request to that MySQL or your microservice application and then forward it to one of those pods for the Clients can call a single stable IP address instead of dialing out. each pod individually, so services are a good abstraction for loose coupling for communication within the cluster.
So, within cluster components or pods within the cluster, but also from external services, like if you have browser requests coming into the cluster or if you're talking to an external database, for example, there are several types of services in Kubernetes. The first and most common one that you will probably use most of the time is the cluster IP type. It is a default type of service, which means that when you create a service and you don't specify a type, it will automatically take the cluster IP as a type, so let's see how the cluster IP works and where it is used in the Kubernetes configuration.
Let's imagine that we have a microservice application deployed in the cluster, so we have a pod with a microservice container running inside that pod and next to that microservice container we have a companion container that collects the microservice logs and then sends them to some target database so that these two containers are running on the Pod and let's say your microservice container is running on pod 3000 and your login container, let's say, is running on port 9000. This It means that those two ports will now be open and accessible within the pod and the pod will also get an IP address from a range that is assigned to a node, so the way it works is that if you have, for example, three worker nodes in your Kubernetes cluster, each worker node will get a range of IP addresses that are internal to the cluster, so for example Pod 1 will get IP addresses from a range of 10.2.1 and up, the second worker node will get this IP range and the third worker node will get this so let's say this pod starts on node 2 so it gets an IP address that looks like this if you want to see the IP addresses of your pods in the cluster you can check them using the cubectl get pod outputwide command where you will get additional information about the pods including its IP address and here you will see the IP address that was assigned to it and as I mentioned these are from the range of IP addresses that each worker node in the cluster will get , so this is from the first worker node and these are from the second worker node, so now we can access those containers inside the Pod on this IP address on these ports if we set the replica count to 2, we are going to have another pod which is identical to the first one, which will open the same ports and get a different IP address, let's say if you start on worker node one, you will get one IP. address that looks like this now let's say this microservice can be accessed through a browser, so we have Ingress configured and the requests coming in from the browser to the microservice will be handled by Ingress.
How do I forward this incoming request from Ingress all the way? to the Pod and that happens through a service, a cluster IP or the so-called internal service, a service in kubernetes is a component like a pod, but it is not a process, it is just an abstraction layer that basically represents an IP address , so the service will get a reachable IP Address and the service will also be reachable on a certain port. Let's say we define that port as 3200 so that Ingress communicates with the service or delivers the request to the service on this IP address on this port so that this is how the service can be accessed within the cluster, so the way we How it works is that we define ingress rules that forward the request based on the request address to certain services and we define the service by its name and the DNS resolution then maps that service name to an IP address that was actually assigned to the service, like so it's like Ingress knows how to talk to the service, so once the request is delivered to the service at this address, the service will know to forward that request to one of those parties that are registered as the endpoints of the service now here are two Questions: How does the service know which pods it is managing or which pods to forward the request to? and the second is how does the service know which port to forward that request on that specific pod.
The first is defined. Using selectors, a service identifies its member pods or its endpoint pods using the selector attribute, so in the service specification in the yaml file from which we create the service we specify the selector attribute which has key-value pairs defined as a list, now these key-value pairs are basically tags that the pods should have to match that selector, so in the Pod configuration file we assign the part certain tags in the metadata section and these tags can have an arbitrary name, so we can say my application for example and give it other tags, this is Basically something we define ourselves, we can give it any name we want.
These are just key-value pairs that identify a set of containers and in the service CML file, we then define a selector to match any part that has all of these tags, this means. if we have a deployment component that creates three route replicas with a tag called app my app and writes microservice for example, and in the service selector attribute we define those two tags, then the service will match those three pod replicas and register the three. parts as your endpoints and as I said, it should match all selectors, not just one, that's how the service will know which part belongs to it, i.e. where to forward that request.
The second question was if a pod has multiple ports open where there are two different ones. applications are listening inside the Pod, how does the service know which port to forward the request to? This is defined in the Destination Port attribute, so this Destination Port attribute, let's say the Destination Port in our example is 3000, what this means is that when we create the service it will find all the parts that match the selector, so these pods will become endpoints of the service and when the service receives a request, it will choose one of those pod replicas randomly because it is a load balancer and will send the request it received to that specific pod on a port defined by the Destination Port attribute, in this case three thousand, also note that when you create a service, Kubernetes creates an endpoints object that has the same name as the service itself and Kubernetes will use this endpoints object to keep track of which pods are members of the service or as I said, which pods are the endpoints of the service and since this is dynamic, every time you create a new pod replica or pod die, the endpoints are updated, so this object will basically track that and note it here. that the service port itself is arbitrary, so you can define it yourself, while the destination port is not arbitrary, it has to match the port where the application container inside the Pod is listening.
Now let's say our microservice application received its browser requests via Ingress and Cluster Internal IP Service and now it needs to communicate with the database to handle that request for example, and in our example let's say the microservice application uses the mongodb database, so we have two mongodb replicas in the cluster that also have their own. service endpoint, so the mongodb service is also cluster IP and has its own IP address, so now the microservice application inside the Pod can communicate with the mongodb database also using the service endpoint , so the request will come from one of the parties receiving the request. from the service to the mongodb service on this IP address and the port that the service has open and then the service will again select one of those pod replicas and forward that request to the selected party on the port, the destination port defined here and this is the port where the mongodb application inside the Pod is listening now, let's assume that inside that mongodb pod there is another container running that selects the monitoring metrics for Prometheus for example, and that will be a mongodb exporter and that container, say, is running on port 9216 and this. is where the application can be accessed and in the cluster we have a Prometheus application that pulls the metrics endpoint of this mongodb exporter container from this endpoint, that means the service has to handle two different endpoint requests, which It also means that the service has two of its own Ports open to handle these two different requests, one from clients that want to talk to the mongodb database and one from clients like Prometheus that want to talk to them, the mongodb exporter application and This is an example of a multiport service and note.
Here, when you have multiple ports defined in a service, you have to name those ports. If it's just one port you can leave it to say Anonymous, you don't have to use the name attribute, it's optional, but if you have multiple ports defined. then you have to name each one of them, so these were examples of the cluster IP service type. Now let's see another type of service which is called headless service so let's see what type of headless service it is as we saw that every request to the service is forwarded to one ofthe Pod replicas that are registered as service endpoints, but imagine if a client wants to communicate with one of the pods directly and selectively or what if the Endpoint Parties need to communicate with each other directly without going through the service, obviously in This case would not be like that.
There is no point in talking to the service endpoint, which will randomly select one of the pods because we want communication with specific parties now. What would that use case be? One use case where this is necessary is when we deploy stateful applications to Kubernetes. stateful applications like MySQL databases mongodb elasticsearch etc. in applications where the pod replicas are not identical, but each has its individual state and characteristic, for example, if we are deploying a MySQL application, it would have a MySQL master instance and a worker. My SQL application and master instances are the only party allowed to write to the database and the worker pods must connect to the master to sync their data after masterpod has made changes to the database so they also get the updated data. and when a new worker pod is started, it needs to connect directly to the latest worker node to clone the data and also update itself with the state of the data, so that is the most common use case where communication is needed directly with individual pods for such a case. a client to connect to all pods individually needs to find out the IP address of each individual pod.
One option to achieve this would be to make an API call to the Kubernetes API server and it will return the list of PODS and their IP addresses, but this will make your application conform too tightly to the specific Kubernetes API and will also be inefficient because you will have to get the full list of PODS and their IP addresses every time you want to connect to one of the pods, but as a workaround, Kubernetes allows this. clients to discover pod IP addresses via DNS lookups and typically the way it works is that when a client performs a DNS lookup for a service, the DNS server returns a single IP address that belongs to the service and this will be the IP address of the service cluster that However, we saw earlier if you tell Kubernetes that you do not need a cluster IP address of the service by setting the Cluster IP field to None when creating a service, then the DNS server will return the Pod IP addresses instead of the services IP address and now the client can do a simple DNS lookup to get the IP address of the pods that are members of that service and then the client can use that IP address to connect to the specific party you want to talk to or all pods, as well as Defining a headless service in a service configuration file is basically setting the cluster IP to None.
So when we create these polls from this configuration file, Kubernetes will not assign the service a cluster IP address and we can see that in the output when I list my services, so I have a cluster IP service that I created for the microservice and a headless service and note here that when we deploy stateful applications to the cluster like mongodb for example, we have the normal service, the cluster IP service which basically handles communication with mongodb and maybe another container inside the Pod and in addition to that service we have a headless service, so we always have these two Services next to each other so that this can do the usual load balancing for this type of use cases and for use cases where the client you need to communicate with one of those parties directly like a master node directly to perform the correct commands or the pods to communicate with each other for data synchronization.
The Headless service will be used for that, when we define a service configuration, we can specify a type of the service and the type attribute can have three different values, it could be the cluster IP, which is the default, that's why we don't have to specify that we have a node port and a load balancer, so the Node Port type basically creates a service that can be accessed on a static port on each worker node in the cluster now, to compare with our previous example, The cluster IP service can only be accessed within the cluster itself, so no external traffic can be directed directly to the cluster IP service; however, the node port service makes external traffic accessible. on a static or fixed port on each worker node, so in this case, instead of Ingress, the browser request will arrive directly to the worker node on the port that defines the service specification and the port that exposes the service type The node port name is defined in the Node Port attribute. and here note that the port value note has a predefined range between 30,000 and 32,767, so you can have one of the values ​​in that range as the node port value.
Anything outside that range will not be accepted, so this means that the node port The service is accessible for external traffic, such as the browser request, for example, add the worker node IP address and the node port defined here; however, just like in the cluster IP, we have a service port, so when we create the node port service, a service cluster IP. to which the node Port service will be routed is automatically created and here as you can see if I list the services then the Port note will have the IP address of the cluster and for each IP address it will also have the open ports where the service can be accessed and also keep in mind that the service uses up all the worker nodes, so if you have three pod replicas on three different nodes, basically the service will be able to handle that request coming from any of the worker nodes and then forward it to one of those replicas of pod now with that type of service exposure is not very efficient and it is also not secure because you are basically opening the ports to talk directly to the services on each worker node.
So, the external clients basically have access to the worker nodes directly, so if we give all services this type of node port service, then we would have a bunch of open ports on the worker nodes that external clients can talk to directly, so it's not very efficient. safe way to handle that and as a better alternative there is a load balancer service type and the way it works with load balancing or service type is that the service becomes accessible externally through the balancer functionality from a cloud provider, so that each cloud provider has its own native functionality. load balancer implementation and that is created and used every time we create a type of load balancer service, Google Cloud platform, AWS Azure linode openstack, etc. all offer this functionality, so every time we create a port load balancer service node and cluster IP services are created automatically. by kubernetes to which the cloud platform's external load balancer will route traffic 2 and this is an example of how we define the load balancer service configuration, so instead of the node port type we have a balancer cargo and in the same way we have the port. of the service that belongs to the cluster IP and we have the node port which is the port that is opened on the worker node, but it cannot be directly accessed externally but only through the load balancer, so the entry point first becomes a load balancer and can then direct traffic to the node port on the worker node and the cluster IP as an internal service, so this is how the flow would work with the load balancer service burden.
In other words, the load balancer service type is an extension of the node port type, which in turn is an extension of the cluster IP type and again, if I create a load balancer service type and list all services, you can also see the differences on the screen, where for each type of service you see the IP addresses, you see the type and you see the ports that the service has opened and I should mention here that in a real Kubernetes configuration example you would probably I wouldn't use the node port for an external connection; maybe you would use it to test some service very quickly, but not for production use cases, so for example if you have an application that can be accessed through the browser, you would configure Ingress for each request of this type , so you have Internal Services, the IP services of the cluster that Ingress will route to, or you have a load balancer that uses the cloud platform's native load balancer implementation.
Congratulations. I made it to the end. I hope you have learned a lot and gained valuable knowledge from this course. If you want to learn about modern Devops tools, be sure to check out my

tutorial

s on that topic. And subscribe to my channel for more content too if you want. To stay connected you can follow me on social media or join the private Facebook group. I'd love to see you there, so thanks for watching and I'll see you in the next video.

If you have any copyright issue, please Contact