In this video, we will discuss Kubernetes objects. Kubernetes objects are persistent entities in Kubernetes. "Persistent" means that when you create an object, Kubernetes continually works to ensure that that object exists in the system, until and unless you modify or remove that object. In this way, Kubernetes objects define the state of your cluster. By creating an object, you tell Kubernetes that you expect that object to exist. The system is then responsible for ensuring that that object does in fact exist. Some examples of Kubernetes objects are Pods, namespaces, Deployments, ConfigMaps, and volumes, which we will discuss in this course. To work with these objects—that is, to create, update, or delete them—you use the Kubernetes API. The most common way to perform these actions is to use the "kubectl" command-line interface. The CLI makes the necessary Kubernetes API calls on your behalf. You can also use the API directly by using one of the many client libraries provided by Kubernetes. Kubernetes objects consist of two main fields. The first is the object "spec," which is provided by the user. The spec dictates the desired state for this object. The second field is the "status," which is provided by Kubernetes. The status describes the current state of the object—its actual state as opposed to its desired state. The status is updated if at any time the status of the object changes. The goal, of course, is for the desired state to match the current state, and Kubernetes continually works toward that end. Before we talk about a few specific object types, let’s look at some characteristics of objects that will help set the stage. Namespaces provide a convenient way to virtualize a physical cluster. With namespaces, you can make one cluster appear to be several distinct clusters. This is useful when several teams want to share a cluster, such as for cost-saving purposes, or when a team maintains multiple projects and wants to keep these projects segregated. However, namespaces are most useful when there's a large number of cluster users. A cluster will automatically have several namespaces created that are used to house elements of the Kubernetes architecture, which we spoke about in a previous video. For instance, the kube-system namespace is present to hold some of these components. Since this namespace is intended for the Kubernetes system, users should not put applications into the namespace. Instead, there might be a default namespace, which can be used to hold the users’ applications. In some circumstances, this situation can be suitable for a user. Perhaps they only have one team using a cluster, and that team only has one project that it deploys into this cluster. In this case, further division might not be necessary. If, however, there are many teams or many projects, or perhaps a lot of users who have different needs, additional namespaces can be created to keep things separate. A team can have its own namespace, or a project can have its own. Administrators can divvy up a cluster with namespaces at their own discretion. These are just a few common patterns, but the key point is that namespaces can be used to provide logical separation of a cluster into virtual clusters. One final point about namespaces: they provide a scope for the names of objects [prod team: note the additional bullet on the left side on this slide]. Each object has a name, and that name must be unique for that resource type within that namespace. For example, if you have a Pod that is named "myPod" in the default namespace, then no other Pod in the default namespace can use that name. However, a Pod in another namespace can use the same name, since that namespace provides a new scope for that name, and a Deployment in the same namespace can use the same name, since the resource type is different. If we refer to our cluster with several namespaces, we can deploy named objects into these namespaces. [Show the first round of objects in the namespaces]. In this diagram, the top row displays the object type and the bottom row, the object name. So here we have two different object types deployed, Type A and Type B. In both namespaces, the names of the Type A and Type B objects are the same. That’s okay because the object types are different. Since "team" is a separate namespace, we can also create a Type-A object with the same name as the one in the default namespace. There is no collision here because the names only have to be unique within a namespace. However, if in the project namespace we try to deploy another Type A object with the same name as the one already deployed there, it will fail because we cannot have two objects of the same type with the same name in the same namespace. Names obviously provide a level of uniqueness within a namespace. But if you want to provide attributes to an object without specifying any uniqueness, labels are a great place to start. Labels are key/value pairs that can be attached to objects in order to identify those objects. However, a label does not uniquely identify a single object. Many objects carry the same labels, which enables those objects to be grouped and organized. This is where selectors come into play. Label selectors are the core grouping primitive in Kubernetes. They enable you to identify a set of objects. We’ll see later that these are used by Kubernetes controllers to determine which set of objects ought to be controlled. In this diagram, we have three objects of Type A deployed into the default namespace. All have different names for uniqueness, but we also have a third row that indicates the label name. In this case, all the objects are labeled "app." This label now serves to group these three objects together, which is useful for a variety of Kubernetes constructs. You should now be familiar with the basics of Kubernetes objects. Specifically, you should understand how namespaces can be used to virtualize a cluster, as well as how to avoid naming collisions for objects in one or many namespaces. You should also understand how labels can be applied to Kubernetes objects, that they do not provide uniqueness, and that they are used by selectors to group objects together. In the next video, we’ll begin to learn about some of the basic objects available in Kubernetes.