Cluster Controller Should Update Cluster APIEndpoints

[jessicaochen]

Currently it is the responsibility of the deployer to update cluster APIEndpoints after the control plane is provisioned. This should really live in the cluster controller so that the logic works across updates and is consistent.

[dlipovetsky]

I'm curious--how will the cluster controller know that APIEndpoints should be updated? Will it watch Machine objects?

[jessicaochen]

For now, the controller can probably watch for the appearance of a master machine and use the IP.

More long term, the cluster controller (or some controller at the same level) should have a concept of control plane and create the appropriate machines to back said control plane. Since said controller created the needed stuff for the control plane, it should also be able to fetch the IP for the control plane.

Just my thinking on this. How exactly to do this is up to implementer.

[dlipovetsky]

Is there consensus on what the cluster controller is responsible for? (I have not seen a design for it, so my own impression is that there is no consensus.)

I thought it could be responsible for the infrastructure (other than compute) required by the cluster, e.g., networks, security groups, etc, and that other controllers (e.g. MachineDeployment) would be responsible for compute infrastructure + software provisioning.

(I agree that the cluster controller would have to watch for master machines in order to update the APIEndpoints.)

[detiber]

In the case of a HA cluster I would expect the cluster controller to manage the api server load balancer, which should probably be the advertised endpoint used. At least until there is better client tooling that allows for the use of multiple endpoints and endpoint discovery.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[vincepri]

/remove-lifecycle rotten

[vincepri]

This has been fixed on master, v1alpha2 as part of #143

/close

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

This has been fixed on master, v1alpha2 as part of #143

/close

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.