We looked at POD and how the POD lifecycle works in the previous post. In this post, let's discuss about Kubernetes ReplicaSets.
ReplicaSet's are Kubernetes Controller that are used to maintain a stable set of replica PODs running at any give time. It is often used to ensure the availability of a certain number of identical Pods. It uses labels(fields) to select pods that it should be managing. For the ReplicaSet to be able to acquire a pod, it must be tagged with a label that corresponds to the ReplicaSet selector and not already be owned by another controller.
A ReplicaSet is linked to its Pods via the metadata.ownerReferences field of the Pods, which specifies which resource the current object owns. All Pods acquired by a ReplicaSet have their owning ReplicaSet's identifying information within their ownerReferences field. The ReplicaSet learns about the state of the Pods it is maintaining through this link and plans accordingly.
The Structure of a ReplicaSet Manifest
Before digging deeper into ReplicaSet use cases and best practices for working with them, it's important to understand how they function. The first thing to note is that they behave similar to any other resource in Kubernetes, in that you must specify the apiVersion, kind, metadata, and spec.
Above is an example of what a ReplicaSet manifest looks like. Saving this manifest into frontend.yaml and submitting it to a Kubernetes cluster will create the defined ReplicaSet and the Pods that it manages. It will then create a scenario where you have 3 pods in your environment, all running a frontend demo application.
Let's look at the first section more closely:
The first two fields are simple and static, and will always be the same. The apiVersion and kind simply tell Kubernetes what it has to work with, and they should never be different. Moving further, you specify the name and labels in the metadata definition. This will allow you to keep a better overview of the resources available in your environment.
Moving to spec field -
The replicas field is set to 3 in this example, but you can change it to whatever works best for your application. There is no official limit to how high this can be set, but keep in mind the underlying resources of your Kubernetes cluster.
The selector field comes next in the manifest. This is where you tell the ReplicaSet how to identify the pods it needs to control. It should match any pods with the label tier: frontend in this case.
Finally, you must define the pods' actual template.
This is similar to defining any other pod. First, you specify the metadata field, which is labelled tier: frontend in this case. As you can see, we specified that the ReplicaSet would look for this when determining which pods it needed to own. So double-check that it corresponds to what you wrote earlier in the manifest.
Finally, you specify the container(s) that will be contained within the pod. In this example, we're going to use a simple demo frontend created by Google.
Scaling ReplicaSets -
You can set the ReplicaSet to autoscale based on the amount of CPU load on the node. The number of replicas (pods) that the ReplicaSet should keep is easily controllable via the command line or by directly editing the ReplicaSet configuration on the fly.
Isolating Pods from a ReplicaSet -
Pods can be isolated from a ReplicaSet by simply changing their labels so that they no longer match the ReplicaSet’s selector. ReplicaSets can be removed with or without the removal of their dependent pods.
Alternatives to ReplicaSet
1. Deployment -
ReplicaSets should not be used for tasks where other resources are available. Kubernetes also has a deployment resource, which is similar to a ReplicaSet in that you can specify the number of replicas to be maintained. The main major difference between the two resources is that deployments handle pod upgrades. Meaning, you should use ReplicaSets if you do not want any automatic pod upgrading or if you want to implement your own custom upgrading logic.
2. Job
ReplicaSets are also used to execute batch jobs that require multiple nodes to complete the same task. However, because the resource has been specifically designed for this purpose, best practice suggests that you use a job instead to create batch workloads.
3. DaemonSets
Another main alternative to ReplicaSets are DaemonSets. DaemonSets are a feature that allows pods to run on each node and have access to machine-level functions. When you need a specific pod to run on each node in your cluster, use a DaemonSet. That scenario can be configured with a ReplicaSet, but DaemonSets are designed for it.
4. Bare Pods
Unlike when a user creates Pods directly, a ReplicaSet replaces Pods that are deleted or terminated for any reason, such as node failure or disruptive node maintenance, such as a kernel upgrade. As a result, even if your application only requires a single Pod, it is recommended that you use a ReplicaSet. Consider it similar to a process supervisor, but instead of individual processes on a single node, it supervises multiple Pods across multiple nodes. A ReplicaSet delegated local container restarts to a node agent such as Kubelet.
5. ReplicationController
ReplicaSets are the ReplicationControllers' successors. Except that a ReplicationController does not support set-based selector requirements, the two serve the same purpose and behave similarly. As a result, ReplicaSets are advisable to ReplicationControllers.
A ReplicaSet is an excellent way to quickly get a predefined number of pods up and running in your environment. It is not difficult to set up. However, you should always consider whether a ReplicaSet is the best option for you. Now that you understand the capabilities of a ReplicaSet, you can decide whether it is required in your environment.
That's all for this post; in the next one, we'll talk about Deployments.
I hope this was helpful.
Thank you for reading!
*** Explore | Share | Grow ***
コメント