-
Notifications
You must be signed in to change notification settings - Fork 39.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pod lifecycle checkpointing #3949
Comments
Fixing the hostname seems like an obvious change. We should consider where I don't know if we will ever really get to pervasive live migration, but I On Thu, Jan 29, 2015 at 1:53 PM, Brian Grant notifications@github.com
|
I'd make the requirement that anything using the Kubernetes API to introspect or manage their own pods would need to be migration-aware. They could use the post-migration hook to get the pod's new name. Why would someone want the uid? What issue is that? (Other than #386.) |
They want the uid as a unique instance identifier. We could give them anything, but self registration into an external system is one way (I'm pod foo, serving X, here's my unique identifier) |
Hi, I'm interested in pod live migration. Is there any progress? Docker has built-in C/R operations in experimental mode, could we develop a feature based on that? |
We have not done any real work in this area. It is somewhat counter to
Kubernetes designs, and would be a little tricky to manage with regards to
life cycle in our API
…On Apr 19, 2017 5:48 AM, "Ce Gao" ***@***.***> wrote:
Hi, I'm interested in pod live migration.
Is there any progress? Docker has built-in C/R operations in experimental
mode, could we develop a feature based on that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3949 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVDgyLFMOD9GGp4yQxyfUxZCV89Lvks5rxeZcgaJpZM4DZNIC>
.
|
pod live migration? I think it's not necessary to do this. |
@warmchang Live migration would let one reduce downtime for services that don't support failover and have a long startup time. You can run them under a single-instance StatefulSet (not under RC, as they do not guarantee stopping the old instance), but then you'll see those slow restarts (potentially multiple ones) on a rolling cluster reboot. |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
For evaluation I've implemented a migration controller and a MigratingPod kind, which allows to migrate pods on deletion. Here's a small demo gif showing the migration of a simple pod with a "stateful container". This is implemented with a finalizer that's also respected by kubelet, so the Pod doesn't get terminated immediately. |
|
/close |
@wgahnagl: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen This has been raised recently at SIG Node meetings with some demos. kubernetes/enhancements#1990 is not yet implementable but reopening to keep this on backlog. (closed due to confusion about title/first comment) |
@ehashman: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/triage accepted |
/remove-triage accepted Sorry for the confusion. It seems that sig-node has not yet decided to accept this. |
@bgrant0607: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/retitle Pod lifecycle checkpointing |
/remove-priority awaiting-more-evidence |
Filing this issue for discussion and tracking, since it has come up a number of times.
Starting with background:
Pods are scheduled, started, and eventually terminate. They are replaced with new pods by replication controller (or some other controller, once we add more controllers). That's both reality and the model. Today pods are replaced reactively, but eventually it will replace pods proactively for planned moves. We currently do not preempt pods in order to schedule other pods, and likely won't for some time.
Currently, new pods have no obvious relationship to the pods they replace. They have different names, different uids, different IP addresses, different hostnames (since we set the pod hostname to pod name), and newly initialized volumes.
Replication controllers themselves are not durable objects. They are tied to deployments. New deployments create new replication controllers. This simplifies sophisticated deployment and rollout strategies without making simple scenarios complex. Both rollout tools/components and auto-scaling will deal with groups of replication controllers.
Naming/discovery is addressed using services, DNS, and the Endpoints API. The evolution of these mechanisms is being discussed in #2585.
This is a flexible model that facilitates transparency, simplifies handling of inevitable distributed-systems scenarios, facilitates high availability, and facilitates dynamic deployment and scaling.
But the model is not without issues. The main ones are:
Data durability is being discussed in the persistent storage proposal #3318. We will also need to address it for local storage, but local storage is less relevant to "migration", anyway, since it's not feasible to migrate. For remote storage, it will be possible to detach and reattach the devices to new pods/hosts.
Self-discovery: Pods know their IP addresses, but currently do not know the names nor IPs of services targeting them. This will be solved by the service redesign #2585 and downward API #386.
Work/role assignment: We encourage dynamic role assignment: master election, fine-grain locking, sharding, task queues, pubsub, etc. That said, some servers are "pet-like", particularly those requiring large amounts of persistent storage. Many of these are replicated and/or sharded, with application-specific clustering implementations that tie together names/addresses and persistent data. We've discussed a concept tentatively called "nominal services" #260 to stably assign names and IP addresses to individual pods, and we aim to address that in the service redesign #2585.
So, do we need "pod migration", and, if so, what should it mean? I think it minimally should mean that the replacement pod has the same hostname, IP address, and storage.
We should aim to minimize disruption for high-availability servers. We could we do, besides the things planned above?
With respect to Kubernetes objects, the "migrated" pod would still be a new pod with a new name and uid. The orchestration of the migration would be performed by a controller -- possibly an enhanced replication controller, perhaps in collaboration with a network controller to move the address, similar to the separation of concerns in the persistent storage proposal. During the migration process, the old and new pods would coexist, and that coexistence would be visible to clients of the Kubernetes API, but the application being migrated and its clients would not need to be aware of the migration.
/cc @smarterclayton @thockin @alex-mohr
The text was updated successfully, but these errors were encountered: