kubernetes / kubeadm

Aggregator for issues filed against kubeadm

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Follow-up selfhosting improvements

luxas opened this issue · comments

kubernetes/kubernetes#40075 is now lgtm'd and we don't want to put more complexity in the PR, it's big enough already and has been waiting for quite a long time.

It now works, and that's great.

OLD: Here we should track the fixup work (20th Jan):

  • Be able to deploy 2 schedulers and cms
  • Specify rollingupdate parameters to the deployments: kubernetes/kubernetes#40075 (comment)
  • Use server-side DaemonSet upgrades - depends on kubernetes/kubernetes#41116
  • General fixup of the code/make it more efficient
  • Add tests
  • Refactor the API type behind it so we can specify more options (like 2 or more schedulers)
  • Make secrets of the needed certs and mount them in the Pod
  • Use the more generic --controlplane or --controlplane-type flag
  • Make constants of commonly used string values
  • Adopt the Pod checkpointer #131
    ...and probably more.

EDIT: New list as of 19th June

  • Make self-hosting work, split out to phase, use DaemonSets: kubernetes/kubernetes#47435
  • Upload certificates to the API using Secrets: kubernetes/kubernetes#42548
  • Propose a create-first-then-delete DaemonSetUpdateStrategy and consume for the controller-manager and scheduler
  • Write a kubelet checkpointing proposal and opt-into that for kubeadm

@pires @mikedanese @Kargakis @lukemarsden

commented

Use the more generic --controlplane or --controlplane-type flag

I strongly disagree with this one. There are only two types of deployments right now, self-hosted or non-self-hosted. And I don't see that changing in the future. --self-hosted is clear about its intents.

I strongly disagree with this one. There are only two types of deployments right now, self-hosted or non-self-hosted. And I don't see that changing in the future. --self-hosted is clear about its intents.

I see it from the perspective that we don't know what happens in the future; we should be future-proof and I also assume here that we will enable self-hosting by default. So if we have self-hosting enabled by default, --self-hosted=false feels like an awkward way of using static pods for those who prefer that.
WDYT @pires?

Also forgot to add to the list:

  • Push a version of the Pod Checkpointer to a gcr.io repo from kubernetes/kubeadm and deploy it in self-hosted mode
commented

For now, --self-hosted seems to suffice for people wanting to try self-hosted mode, which is still a rough take, and I'm expecting feedback, like this PR, to shape future changes. So, renaming flags doesn't make much sense to me here. I think we must come up with API objects that cover the features we're planning for ASAP.

I think we must come up with API objects that cover the features we're planning for ASAP.

That's exactly what I'm doing

Do we still need checkpointing, server restart and disaster recovery?

EDIT: New list as of 19th June

  • Make self-hosting work, split out to phase, use DaemonSets: kubernetes/kubernetes#47435
  • Upload certificates to the API using Secrets: kubernetes/kubernetes#42548
  • Propose a create-first-then-delete DaemonSetUpdateStrategy and consume for the controller-manager and scheduler
  • Write a kubelet checkpointing proposal and opt-into that for kubeadm

cc @roberthbailey @timothysc @aaronlevy @roberthbailey Did I miss something ^?

Why is this closed...? Those last two items still need to be done.

No idea @timothysc, Github links ftw I guess?

@timothysc requested an update on this issue, here we go:

Sounds good?

cc @diegs for the "Add-then-kill" DaemonSet UpdateStrategy implementation, please link here when you have the PR up

@timothysc @diegs Moving the rest of these items to v1.9

The add-then-kill feature is not relevant anymore and the checkpointing issue is separate (#131) so closing this as it doesn't have any action items