Object management
1. Object management
Let's finish up this section of the course by exploring Kubernetes object management. It's important to know that all Kubernetes objects are identified by a unique name and a unique identifier. Recall the earlier example where you wanted the three nginx Web servers to run all the time. The simplest way to achieve this is by declaring three Pod objects and specifying their state. For each, a Pod must be created and an nginx container image must be used. Let's see how to make this declaration. You define the objects you want Kubernetes to create and maintain with manifest files. These are ordinary text files that can be written in YAML or JSON. You'll see YAML used in this course. This manifest file defines a desired state for a Pod: its name and a specific container image for it to run. Required fields include: apiVersion, which states the Kubernetes API version used to create the object, kind, which states the object you want (in this case, a Pod), and metadata, which identifies the object name, unique ID, and an optional namespace. If several objects are related, it's a best practice to define them all in the same YAML file. This makes things easier to manage. We strongly recommend saving YAML files in version-control repositories so it's easier to track and manage changes and to undo those changes when necessary. It's also helpful when recreating or restoring a cluster. Cloud Source Repositories is a popular service for this purpose. Let's look at the details of an object. First, all objects are identified by a name. Names must consist of a unique string under 253 characters. Numbers, letters, hyphens, and periods are allowed. Only one object can have a particular name at the same time in the same Kubernetes namespace. After an object is deleted, however, the name can be reused. Second, every object created throughout the life of a cluster has a unique identifier, or UID, generated by Kubernetes. And third, there are labels. Labels are key-value pairs to tag objects during or after their creation. Labels help identify and organize objects. A way to select Kubernetes resources by label is through the kubectl command. For example, this command can select all the Pods that contain a label called "app" with a value of "nginx." Label selectors can be used to ask for all the resources that have a certain value for a label, all those that don't have a certain value, or even all those with a value in a set you supply. Now let's go back to our example. One way to create three nginx web servers is by declaring three Pod objects, each with its own section of YAML. In Kubernetes, a workload is spread evenly across available nodes by default. So how do you tell Kubernetes to maintain the desired state of three nginx containers? To maintain an application's high availability, you need a better way to manage it in Kubernetes than specifying individual Pods. One option is to declare a controller object. A controller object's job is to manage the state of the Pods. Because Pods are designed to be ephemeral and disposable, they don't heal or repair themselves and are not meant to run forever. Examples include Deployments, StatefulSets, DaemonSets, and Jobs. Deployments are a great choice for long-lived software components like web servers, especially when you want to manage them as a group. In our example, the practical effect of the Deployment controller is to monitor and maintain the three nginx Pods. When the kube-scheduler schedules Pods for a Deployment, it notifies the kube-APIserver. The Deployment controller creates a child object, a ReplicaSet, to launch the desired Pods. If one of these Pods fails, the ReplicaSet controller will recognize the difference between the current state and the desired state and will try to fix it by launching a new Pod. So, this means that instead of using multiple YAML manifests or files for each Pod, you used a single Deployment YAML to launch three replicas of the same container. Within a Deployment object spec, the number of replica Pods, which containers should run the Pods, and which volumes should be mounted the following elements are defined. Based on these templates, controllers maintain the Pod's desired state within a cluster.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.