Added kernel upgrade workflow documentation #5211
Conversation
|
@ddysher PTAL |
|
Depends on #4585 |
| @@ -31,3 +31,25 @@ You can use the kube-version-change utility to convert config files between diff | |||
| $ hack/build-go.sh cmd/kube-version-change | |||
| $ _output/go/bin/kube-version-change -i myPod.v1beta1.yaml -o myPod.v1beta3.yaml | |||
| ``` | |||
|
|
|||
| ### Upgrading the kernel on a node | |||
There was a problem hiding this comment.
What does this have to do with upgrading a kernel? (Yes it's a good example, but updating libc would have the same issues)
This is about preparing a node for cluster removal, either temporary or permanent... I'll try to think of a better title, but saying this is only about kernel isn't good...
There was a problem hiding this comment.
+1. Upgrading docker daemon requires downtime, and all running containers are killed today too.
There was a problem hiding this comment.
The containers have their own libc's, so, in principle, you could upgrade the node libc, restart all the node daemons, and not affect any running containers, and not have any open file handles on the old libc.
There was a problem hiding this comment.
Does docker daemon use libc? It seems we cant avoid downtime in the libc case.
How about Maintenance event on a node?
There was a problem hiding this comment.
Called it "Upgrading the system software on a Node"
There was a problem hiding this comment.
Okay, called it "Maintenance on a Node"
| 1. for pods which are not replicated, bring up a new copy of the pod, and redirect clients to it. | ||
| 1. Work on the node | ||
| 1. Make the node schedulable again: | ||
| `kubectl update nodes $NODENAME --patch='{"apiVersion": "v1beta1", "unschedulable": false}'. |
|
PTAL |
erictune
force-pushed
the
upgrade_sketch
branch
from
456ff44 to
a30f2f6
Compare
ddysher
added
the
lgtm
Added kernel upgrade workflow documentation
No description provided.