Does Kubernetes have any strategy of picking which older version pods to be deleted during rolling update? I didn't find any existing documents describing this.
Pods are supposed to be ephemeral and disposable, and thus if you do care about their ordering, you'd want to use a StatefulSet with podManagementPolicy: which allows you to control the order they are created and then destroyed.
Related
This question already has answers here:
k8s - Why we need ReplicaSet when we have Deployments
(2 answers)
Kubernetes: what's the difference between Deployment and Replica set?
(4 answers)
Closed last month.
I know that deployment uses replicaset underneath it, has revision control, creates another replicaset during rolling upgrade/downgrade.
I want to know what is the scenario in which only replicaset can be used and deployment can't be used.
ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time and it checks how many pods need to maintain bases on which it creates or deletes the pods. ReplicaSet then fulfills its purpose by creating and deleting Pods as needed to reach the desired number. ReplicaSets can be used independently. With ReplicaSet you define the number of replicas you want to run for a particular service. You would have those many replicas running.
Whereas Deployment is the advancement of replica sets. When you use Deployments you don't have to worry about managing the ReplicaSets that they create. Deployments own and manage their ReplicaSets. As such, it is recommended to use Deployments when you want ReplicaSets. As a replica looks only on creating and deleting the pods. Deployment is recommended for application services and
With deployment you should be able to do rolling upgrades or rollbacks. You can update images from v1 to v2.
Refer to this SO1 , SO2 and official documentation of Replicasets and Deployment.
what is the scenario in which only replicaset can be used and deployment can't be used.
There is no such common scenario. ReplicaSets are a lower level abstraction for maintaining stateless pods of the same image / config version. You typically creating new ReplicaSets when you want to change image or pod configuration, it is recommended to use Deployment for such changes.
By its own, it is not very useful to use ReplicaSet directly, it is more a lower level abstraction to maintain the number of replicas with the same configuration.
When updating my deployment to use a new version of my application, a new ReplicaSet is created and the previous ReplicaSet is scaled down as the new one scales up. What is the separation of concerns between the Deployment and the two ReplicaSets during this process?
Am I correct in assuming that it's the Deployment that's gradually changing the number of desired replicas for the two ReplicaSets as the update progresses?
A ReplicaSet ensures that a number of Pods is created in a cluster. The pods are called replicas and are the mechanism of availability in Kubernetes. But changing the ReplicaSet will not take effect on existing Pods, so it is not possible to easily change, for example, the image version.
A deployment is a higher abstraction that manages one or more ReplicaSets to provide controlled rollout of a new version. When the image version is changed in the Deployment, a new ReplicaSet for this version will be created with initially zero replicas. Then it will be scaled to one replica, after that is running, the old ReplicaSet will be scaled down. (The number of newly created pods, the step size so to speak, can be tuned.)
Below explains about the division of responsibilities between Deployments and ReplicaSets in a rolling update?
Deployment resources makes it easier for updating your pods to a newer version.
As per question lets assume, ReplicaSet-A for controlling your pods, then You wish to update your pods to a newer version, now you should create Replicaset-B, scale down ReplicaSet-A and scale up ReplicaSet-B by one step repeatedly (This process is known as rolling update). Although this does the job, it's not a good practice and it's better to let K8S do the job.
A Deployment resource does this automatically without any human interaction and increases the abstraction by one level.
Note: Deployment doesn't interact with pods directly, it just does rolling update using ReplicaSets
Refer this Replica set doc and Deployment doc
The Kubernetes StatefulSet RollingUpdate strategy deletes and recreates each Pod in order. I am interested in updating a StatefulSet by recreating a pod and then deleting the old Pod (note the reversal), one-by-one.
This is interesting to me because:
There is no reduction in the number of Ready Pods. I understand this is how a normal Deployment update works too (i.e. a Pod is only deleted after the new Pod replacing it is Ready).
More importantly, it allows me to perform application-specific live migration during my StatefulSet upgrade. I would like to "migrate" data from (old) pod-i to (new) pod-i before (old) pod-i is terminated (I would implement this in (new) pod-i readiness logic).
Is such an update strategy possible?
This is inherently possible with Deployments, but not StatefulSets. StatefulSets are used when you care strongly about an exact number of replicas with well known names. Deployments are used for more elastic workloads.
You may be able to accomplish your goal by using multiple StatefulSets- e.g. instead of a StatefulSet of 3 replicas, use 3 StatefulSets of 1 replica each. Then deploy an additional StatefulSet for your data migration before removing one of the previous ones.
Alternatively, this may be a use case for an Operator to manage the application.
No, because pods have specific names based on their ordinal (-0, -1, etc) and there can only be one pod at a time with a given name. Deployments and DaemonSets can burst for updates because their names are randomized so it doesn't matter what order you do things in.
Is there a way in Kubernetes to upgrade a given type of pod first when we have a deployment or stateful set with two or more replicas ( where one pod is master and others are not)?
My requirement to be specific is to ensure when calling upgrade on deployment/statefull set is to upgrade master as the last pod under a given number of replicas..
The only thing that's built into Kubernetes is the automatic sequential naming of StatefulSet pods.
If you have a StatefulSet, one of its pods is guaranteed to be named statefulsetname-0. That pod can declare itself the "master" for whatever purposes this is required. A pod can easily determine (by looking at its hostname(1)) whether it is the "master", and if it isn't, it can also easily determine what pod is. Updates happen by default in numerically reverse order, so statefulsetname-0 will be upgraded last, which matches your requirement.
StatefulSets have other properties, which you may or may not want. It's impossible for another pod to take over as the master if the first one fails; startup and shutdown happens in a fairly rigid order; if any part of your infrastructure is unstable then you may not be able to reliably scale the StatefulSet.
If you don't want a StatefulSet, you can implement your own leader election in a couple of ways (use a service like ZooKeeper or etcd that can help you maintain this state across the cluster; bring in a library for a leader-election algorithm like Raft). Kubernetes doesn't provide this on its own. The cluster will also be unaware of the "must upgrade the leader last" requirement, but if the current leader is terminated, another pod can take over the leadership.
The easiest way is probably having master in one deployment/statefulset, while followers in another deployment/statefulset. This approach ensure update is persist and can make use of update strategy in k8s.
The fact that k8s does not differentiate pod by containers nor any role specific to user application architecture ('master'); it is better to manage your own deployment when you have specific sequence that is outside of deployment/statefulset control. You can patch but change will not persist rollout restart.
"How to permanently delete pods inside "default" namespace? As when I delete pods, they are coming back because of "replication controller".
As this is in a Default namespace, I am sure that we can delete it permanently. Any idea how to do it ?
I'd like to add some update to what was already said in previous answer.
Basically in kubernetes you have several abstraction layers. As you can read in the documentation:
A Pod is the basic execution unit of a Kubernetes application–the
smallest and simplest unit in the Kubernetes object model that you
create or deploy. A Pod represents processes running on your Cluster .
It is rarely deployed as separate entity. In most cases it is a part of higher level object such as Deployment or ReplicationController. I would advise you to familiarize with general concept of controllers, especially Deployments, as they are currently the recommended way of setting up replication [source]:
Note: A Deployment that configures a ReplicaSet is now the recommended
way to set up replication.
As you can read further:
A ReplicationController ensures that a specified number of pod
replicas are running at any one time. In other words, a
ReplicationController makes sure that a pod or a homogeneous set of
pods is always up and available.
It applies also to situation when certain pods are deleted by user. Replication controller doesn't care why the pods were deleted. Its role is just to make sure they are always up and running. Its very simple concept. When you don't want certain pods to exist any more, you must get rid of the higher level object that manages them and ensures they are always available.
Read about Replication Controllers, then delete the ReplicationController.
It can't "ensure that a specified number of pod replicas are running" when it's dead.
kubectl delete replicationcontroller <name>