Ability to separate control plane components on dedicated nodes about kubespray HOT 8 OPEN

Well, kubespray build on top of kubeadm, so that would be a separate part to maintain.

Support for kube-apiserver for dedicated node for enhance and obtain high performance.

Do you mean separating control plane components on different nodes ?
Aka for instance

[kube_api_server]
control_plane_1
control_plane_2
control_plane_3
[kube_controller_and_scheduler]
control_plane_4
control_plane_5
control_plane_6

I'm not sure if that's possible with kubeadm... 🤔 . Even if it is, it would be a big amount of work on kubespray, I think.

The openAI stuff isn't really relevant. As written in their articles, they have very specific workloads and a quite particular model.

from kubespray.

from kubespray.

from kubespray.

It shouldn't be a problem to allocate master nodes from normal operation, e.g. via taint:
Taints: dedicated=master:NoSchedule

from kubespray.

@hufhend Yeah, you can disable scheduling the pods to control plane with that taints.

By the way, What I want to describe is seperating the kube-apiserver from static pods that created with kubeadm then use it as systemd service in other dedicated machine.

I think it may not be necessary for many use cases..

from kubespray.

@VannTen

Do you mean separating control plane components on different nodes ?
Aka for instance

Yes, I meant like that, additionally [kube_api_server] hosts could be not kubernetes control plane node just node for hosting kube-apiserver with systemd service.

[kube_api_server]
not_control_plane_1
not_control_plane_2
not_control_plane_3

[kube_controller_and_scheduler]
control_plane_1
control_plane_2
control_plane_3

Because kube-apiserver can be run with binary or container,
and kube-apiserver just need right x509 certificate for communicating with etcd and kubelet and other control plane components to work properly. (Some of the information about kube-apiserver I know can be wrong)

I think that it would be a tricky job for supporting it on kubespray. And it may not be used frequently in common use cases.

"If" this works really needed then some control plane should be provisioned wtih $ kubeadm init phase control-plane controller-manager and kubeadm init phase control-plane scheduler (https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane)

And missed kube-apiserver should be run in other nodes as systemd service or container.

I tested this concept with my local vm clusters and it can be worked, but applying this with kubespray might be tricky as you mentioned. :)

The openAI stuff isn't really relevant. As written in their articles, they have very specific workloads and a quite particular model.

I agree with you they have specific workloads and particular model so it might not be needed in most common cases!

I think this issue can be closed without any works :)

from kubespray.

I don't think whether the api-server runs on top of kubelet as a container or directly as a systemd service is particularly impactful (and systemd can run service exactly like containers, in fact) on performance.

@VannTen Yeah, It does not affect performance whether that server runs on systemd or container whatever.

But the point what I think isdedicated node for kube-apiserver that dedicated node just have kube-apiserver and doesn't have any other workloads except kube-apiserver.

I think this title and description might be confusing about what I want to say :)

For now on, this feature is usually not needed.

Can you suggest which title is suitable for this?

Thank you for your interest :)

from kubespray.

Yeah I get it. But whether you run with systemd or kubelet is orthogonal to using dedicated nodes.

I get it what you intended right now.

As you said, using a dedicated node is one thing, separating and running the API server is another(systemd or container / static pods , whatever)

I will change this issue title based on your opinion :)
Thank you!👍

from kubespray.