So welcome to the final chapter in this course. And so far in this course, what we have been doing is, we try to be very hands on, we try to take a look at our code and deploy our code. And really take a look at OpenShift and try to learn OpenShift by doing. And I want to do in this video is, I want to step back just a little bit and try to take a look at the architecture of Kubernetes and OpenShift and I want to see the components that OpenShift consists of, right? I want to take a look at some of the, some of the resources that kubernetes as well as OpenShift provides, right. And this is quite useful for us so that when we talk about OpenShift and kubernetes we know what these two offer to us. And when we deploy and develop applications in the future, we have a general overview of the landscape of kubernetes and OpenShift, right? So when we talk about kubernetes and OpenShift, it is quite useful to know some very, very basic terminology, right? So kubernetes as well as OpenShift uses the term note to mean simply a server that is a part of the kubernetes cluster and a note can form a function, right? It can be either a control plane or a compute node, right? A control plane note is basically a note that serves as, that runs the workload that pertains to the cluster, right? So, think something like the DNS resolution service, right? This is a workload that is critical for the operational capability of the cluster, right? And so, this is something that the control plane will host, on the other hand, compute note is a note such that it executes workloads for the user, right? So for example, the application pods that I want to schedule will run on a compute node, right? And so, we then have the term resource and I have used this term, this term resource throughout this course, right? And this is any kind of a resource that we can deploy or spawn on kubernetes or OpenShift, right, this can be a pod, this can be a deployment resource, any similar service, right? Etc. A controller is very important concept within kubernetes as well as OpenShift and our controller is basically a manager, right? A controller or a manager, these are kind of synonymous terms. It's basically a program, it's a program that operates on a watch loop, right? And it watches a state, right? And whenever there's a change in that state, this controller contains logic that tries to move the state towards the desired state. And so this sounds all incredibly complicated, but for example, a deployment or replication controller is a controller, right? So, an example of that is that we specify that, we want to have three ports of our application, right? We deploy our application and we want to have three ports, and then one of our port dies, right? One of our ports gets destroyed for whatever reason, and suddenly we only have two ports running, right? Well, this is a change of a state and then the controller reacts to this change of a state by spawning a new port, right? So this is a, this is a controller that responds to the state change on a watch loop, right? We then have labels, labels are incredibly useful within kubernetes. We have used actually labels quite extensively for our cleanup, right? So whenever we have done OC delete dash, dash selector, right? We have used labels. So app equals something was a label. Label is a key value pair, that can be assigned to any resource and it's simply marks, marks a resource as something, right? And these labels can be used by a number of things, be it for example, like we have used just to signal that a pair, a number of resources, a set of resources belong to one application, right? For example, and the name space is simply a group of resources, right, that are bounded together. So there is essentially a set of boundaries within which we can instantiate a set of resources. If you have been using, if you have been using the OpenShift within the cloud, the cloud environment, right, then you have the dash def name space and dash stage name space. And in fact these are projects as we will see in a in a little bit. And if you create your own kubernetes cluster, you can create as many name spaces as you need for basically the limiting a set of resources, right? Then we have our own OpenShift terminology, we can have our infrastructure node or infra node and this is node, a server within the OpenShift cluster, right? That contains some infrastructure services like monitoring, logging, routing etc, right? We then have our console, right, which is the web UI that we have been using a lot in this course. And of course because we have been using it a lot, this web UI has to live somewhere, right? There is an application like any other, this application is hosted somewhere within the open cluster and so this is a pot or set of pots like any other. And project is like I said, an extension of the kubernetes name space and it adds just very few niceties to the name space. But for our understanding at this at this stage, you can think of them as somewhat similar, right? So this is just very, very basic terminology of OpenShift and kubernetes. So let's take a look. At some components that openshift uses in order to operate, in order for us to use Red Hat openshift. We have a number of components and especially if you use openshift in the cloud, you don't see a lot of the underlying components. But you can also deploy openshift onto your computer, in your environment at work, at school, right? And if you do, then you have to maintain a lot of the underlying hardware. And then you come into contact with something like the Red Hat CoreOS, and this is the underlying operating system on which we deploy Red Hat openshift. And Red Hat CoreOS is an immutable container-based operating system, that enables us to deploy and manage openshift. Or rather it enables us to integrate openshift with the operating system, right? So where the operating system uses containers as a first class citizens, right? So the Red Hat CoreOS is the operating system on which we can deploy Red Hat openshift. Of course the operating system has to have some kind of container runtime. And so we know that within Red Hat openshift as well as Kubernetes, we can spawn pods, right? And pods are basically our applications, one pod contains one or more containers, right? And so we need to have a way to spawn our containers. Previously, in previous versions of openshift as well as Kubernetes, we used Docker as our container runtime. This has been deprecated, and right now we use CRI-O as our container runtime, right? So, we have our CRI-O that is deployed and installed on top of our operating system. And this is by the way, this is just a single node that we are talking about. This Red Hat openshift consists of multiple nodes, of course, right? And so this CRI-O container engine enables us to spawn containers that openshift manages for us, right? So, when I tell openshift to create a application for me within a pod, the CRI-O is responsible at a low level for spawning that application container, right? One very interesting component that I definitely want to mention is Etcd, right? Now, recall that when we talked about scaling and scalability, I paused at databases, and I posed the question, right? What will happen when we scale up something like postgres database to two pods, or multiple pods, without any further configuration? And the answer by default is that you will have two databases that do not talk to each other, right? Well, Etcd is actually a distributed database, right? It is a cloud native database, which is one of the core components of Kubernetes as well as Red Hat openshift, right? Etcd is a key-value store database, which stores all of the configuration and state of your openshift. And only the control plane can talk to it via the API, right? So Etcd, if you want to take a look at it, I would definitely encourage you to deploy it. You can spin it up as a separate application, right? It's a very interesting piece of technology, very highly scalable, very interesting piece of technology to just play around with and take a look at, right? Core piece of technology within Red Hat openshift as well as Kubernetes. If you ever managed Kubernetes just by itself, and it crashed or there was some kind of catastrophic failure, you might have had to do some backup or restore of the Etcd database maybe. So, this is the Etcd, very basic component, very crucial component of every Kubernetes as well as openshift cluster, right? Then we actually have Kubernetes, right? And Kubernetes is a part of openshift, it is the engine, it is the container orchestration and management engine of openshift, right? Openshift uses Kubernetes and add more, right? Openshift is Kubernetes and more, right? So this is why openshift can be fully compatible with kubectl, right? Because openshift is Kubernetes, kubectl communicates with Kubernetes, or openshift is Kubernetes. The thing is that openshift adds more things on top of Kubernetes, such as s2i which we have been using in this course, that kubectl knows nothing about, right? And so kubectl does not know anything about s2i because it's not part of Kubernetes, and so you can't use s2i within kubectl. And so for that you need oc as we have been using within this course. Well, what other pods are parts of openshift? Well, then we have our operators, right? We have our CRDs, and operators in CRDs, these are our managers. I have mentioned some operators in the scalability sections as a way to scale some databases, right? This is essentially a manager, it's a part of the same watch loop as I described previously, that you can coat up and deploy yourself, right? So this is kind of an advanced topic but openshift provides a number of operators by default. And openshift actually provides a number of operators that it uses for itself, right? So these are operators that keep openshift running. Openshift also provides a number of runtimes and something as a service, right? So this is something like the s2i for Java, Ruby, Node.js, etc. So these are the developer niceties that we have been using throughout this course this, right? So thanks to the work that Red Hat has done to enable developers to just sit down and spawn an application, right? And to bring these runtimes to openshift. We can simply, our experience of developing an openshift is much, much faster and easier, than what we have been doing in the pure Kubernetes way, right? Part of open shift is also containerized services, right, and most notably for example. There is the image registry, an internal image registry which you might have seen also in the S do I and at the top most. There is some other death tools and user experience, such as the web console. That we have been using, very extensively throughout this course, right. So these are some of the components, some of the main components that open shift consists of, right. And one of the things that I definitely wanted to highlight is that kubernetes kubernetes is part of open shift, right. It is the engine that powers open shift, right, so this was our are open shift components stack. Let's take a look at the very basic architecture, so this is what our cluster might look like, right. We have our control plane over here, which runs the API or authentication service. We have our data store, which is the cd, for example, right, we have our scheduler or management replication. And these are all workloads that pertain to the cluster, right to the open cluster without which the cluster could not run. And that is why, these workloads run on the control plane nodes, right. This does not mean that there is only one control plane node, but for simplicity. We only show, for example one control plane node, if there is some storage needed. Which of course there will be some persistent storage needed, there can be multiple persistent storage providers. Right, gloucester probably not anymore, but seth right, seth is definitely used nowadays. And there is also some other vendors, that can provide persistent storage right. For our cluster, for example, at the top of my mind, like something like AWS can also provide persistent storage to our cluster. Right, then we have some infrastructure node that runs our infrastructure. So for example, this could run our console, right, some are console and then we have our node, this is our regular node. Right, which could run our applications such as our, contacts application. Right, and so this ball consists, this is all our open shift application or are open shift cluster. Right, we can have multiple of our nodes and our infrastructure nodes. And our control plane nodes, and all of these nodes can be in the cloud, they can be local right. They can be in AWS in google cloud, in the IBM cloud, wherever you want them to be, they can be in your local cloud, right. You can have your own cloud with the red hat open stack for example, they can be on your bare metal machines, right. You can have your own data center, you can have your own machines. You can deploy right at open shift there, and in fact you can have them in both of these clouds at the same time, right. You can have some of the nodes in your local environment and some of them in AWS for example. And these nodes will communicate quite well, and you have your developer user. Which uses some tools like git, right, and some cicd continuous integration. Continuous deployment, to talk to our cluster and uses the, uses our cluster to do what needs to be done. And we might have some traffic via the routing layer, which might route our external requests to our actual parts, right. So this is just a very basic architecture of kubernetes, so new features in red hat open shift four. Well, when red hat opens shift four came out, so if you have been using the cloud environment. Within this course, you have been using red hat open shift four, red hat shift four has been with us for quite some time at this point. Red hat open shift three is still supported, within so far right, but will be deprecated within 2022 I believe so. Red hat open shift four, is huge step within the red hat open shift and kubernetes space. Right, but at this point we have been with the red hat open shift four for so long that it is not as relevant as it used to be. One thing that I would definitely point out is the operator SDK, right, so if you want to look at something that are interesting. Operators and trying to deploy, and write your own operator is quite, is a little bit of an advanced subject. But it's definitely something that will give you a lot of knowledge into how operation it works, right. And sadly you can deploy your operators into the cloud cluster that we, that I have been using throughout the course. But if you spawn your own kubernetes or open shift cluster, then you can deploy your own operators. Into your small cluster and you can test the operator SDK and package your applications as operator, right. So, we don't have our resource types, right, and throughout this course we have been using a lot of resources already. We have gotten very, we got our hands dirty with a lot of resources, and so this is just a formalization. Of a lot of knowledge that we already have, right, and of what we already used, right. So we have our parts right, and a part is a basic unit of work, within kubernetes part consists of one or more containers, right. And each part is given a unique I be address, right, within a kubernetes cluster, each part should be reachable to any other part. Right. So if each part should be reachable to any other part, where do we need services? Right. So a service is a concept where basically it is a resource that gives a single I P and pod right? Which leads to a set of pods. Well the reason why you use services is that pods are ephemeral, right? Pods often get destroyed and recreated. And services leads to a set of pods which can be dynamic. And so we don't want to keep remembering or keep trying to discover new pod I P addresses. We just want to discover one single I P address of a service. Right? Or even better get the DNS name for a service and use that instead of using ever changing I P addresses of pods. Right? We have our replication controllers and replication controllers. We have not used replication controllers throughout the course. But the truth of the matter is that we have used replication controls indirectly. And the reason for that is that replication controllers are used in scaling the pods up and down. Right. A replication controller is a controller which manages the number of pods. So when you say that you want a pods, you want an application to have for example three pods. It is a job of a replication controller to keep the number of pods to for example three pods. Right. Now, you might say that we have not used replication controllers but we have used a deployment or a deployment config and that is absolutely true. And my response to that would be that deployment and deployment controllers use replication controllers. Okay. So then we have our are persistent volumes and persistent volume claims. Now this can be confusing to especially to new users. Persistent volumes, our storage or storage that is defined by an administrator. Right? So for example an administrator provision storage within AWS and configures it for kubernetes. And a developer claims some of that storage by using persistent volume claims and uses it in their application. Right. So these are kind of two sides of the same coin. However, persistent volume is used by an administrator and persistent volume claim is used by a developer. Right. And then we have our ConfligMaps and secrets. Now we have used both in our previous videos and in our previous credit exercises. And so I will not spend a lot of time on that. So we then have our OpenShift Resource Types. Right. And the main OpenShift Resource Type that is specific to OpenShift or one of the main resource types is the deployment config. Right. And so it's interesting that when you create, for example, if you notice when you create a postgres database. I believe that still to this day, it spawns with a deployment config rather than deployment. So both deployments and deployment config. Our controller type resources. Right, which managed the pods for the applications? And as I said, both of these resources used replication controllers underneath. Right. And deployment config is specific to OpenShift and there are some niceties that deployment config provides to you, that deployment does not right? So for example, the lifecycle hooks are definitely nice for the deployment config object. Right. And deployment object does not support the lifecycle hooks. Now, if you are not sure for example what the lifecycle hooks are right. Then my advice would be to use deployment because that means your application is compatible with upstream kubernetes. And you might move your application between kubernetes as well as OpenShift. However, it might be interesting to research exactly what the lifecycle hooks are, especially for something like a database. Right? And see whether it might help your use case. And in that case you might want to use the deployment config in case that you might need it. Right. Another resource is the build conflig, we have used it extensively. Right. This is also specific to OpenShift of course because it uses the S2 I feature. And yeah, we have used it extensively throughout this course, so I'm going to spend a lot of time on it. And the route is also specific to redhead OpenShift. The upstream kubernetes has a similar resource called ingress. Right? But with an OpenShift we have ingress as well as a route and a route we have used throughout the course as well. It gives us a DNS host, right? DNS host name. And basically what this means is that it gives us a resolvable address, right? A ural that we can that we can access from our browser so that our application is accessible to us. Right? And so OpenShift comes with something like openly discuss comes with a router. This router is h a proxy I believe and this route the routes the requests to the pods. Right? Then we have the last section within this high level overview is networking. Networking is a huge subject within the kubernetes and OpenShip community. Right. The main thing that I wanted to point out here is that, there are many pieces within the cluster that need to communicate together. What I wanted to talk about when it came to networking is that we have several pieces of architecture, right? We have one type of node. Right? We have a different type of note. We have a third type of node and all of these types of nods must be able to communicate with each other. Right? So for example, All of the workload nodes, right? Must be able to communicate with each other, right? Because there can be multiple of these nodes, right? There can be multiple of infrastructure nodes, right? And there can be multiple of control plane nodes. So all of these notes must be reachable, right, to each other. But all of these nodes must be reachable between each other as well, right? But what's more, all of the parts has to be reachable to each other across these nodes, right? So not only that part one from a single node be reachable to part two from a single node. Our application must be able to reach the API authentication if need be, right? And so this becomes extremely complicated when we start to have hundreds and hundreds of ports with hundreds of nodes. And each of these nodes has hundreds of ports and we have hundreds of services, right? This image does not even have any services that connect each of these nodes, right? And this image does not even have routes that route to each of these parts externally, right? And so when we talk about networking, what we do with an open shift is we deploy something called software defined networking or SDN. Which essentially enables us to create complex networking rules and routes. And this enables us to solve these complex routing rules and even at some point for example create rules such that some applications might not be able to talk to other applications for security reasons, right? So networking is a very broad topic, a huge topic within the Kubernetes community. And if that interests you then there is a lot of reading to be done, right, and it is a huge rabbit hole. But for our purposes so far, it is enough to understand that there are many different IP routes, right? And many different routes, many different ways into which we need to connect within our open shift cluster. And the way we saw that issue is via software defined networking layer. Okay, so this does it for our lecture and I'll see you in the next video.
