Support for passing additional args to API server, controller manager, and scheduler

[ahmedwaleedmalik]

What this PR does / why we need it:
This PR adds support in KubeOne to configure additional flags and feature gates for the following components:

1. API server
2. Controller Manager
3. Scheduler

KubeOne also configures flags and crucial feature gates that are essential for the working of the underlying Kubernetes cluster. Due to this these flags and feature gates are always merged with what KubeOne configures. Since it's easy to misconfigure feature gates, we have prohibited users from specifying them with flags and instead created a dedicated featureGates field.

Which issue(s) this PR fixes:

Fixes #2275 #2431
xref #3143

What type of PR is this?

/kind feature

Special notes for your reviewer:
Resurrection of #3074

Does this PR introduce a user-facing change? Then add your Release Note here:

Support for passing additional args to the API server, controller manager, and scheduler

Documentation:

TBD

/assign @kron4eg

[ahmedwaleedmalik]

/cc @kron4eg
/assign

[cnvergence]

/assign cnvergence

[cnvergence]

I am not sure how I feel about allowing all of them while enabling support in these components seems to be non-breaking, fiddling with configuration files, for instance providing the wrong path for TLS cert, is breaking cluster with manual cluster repair required, if you try to rollback it with KubeOne.

[cnvergence]

I have tested it with the AWS cluster, this configuration seems like it covers most of the options and they are being applied properly.

[ahmedwaleedmalik]

I am not sure how I feel about allowing all of them while enabling support in these components seems to be non-breaking, fiddling with configuration files, for instance providing the wrong path for TLS cert, breaking cluster with manual cluster repair required, if you try to rollback it with KubeOne.

Hey @cnvergence, this has been quite thoroughly discussed internally. We are aware of the risks, as mentioned in the documentation of the structs/fields. However, we don't want to block users from overriding these values since sometimes it's essential for their workflows.

cc @xmudrii @moadqassem

[cnvergence]

Understood, for that extensibility I am all for it, as it is a strong feature request
Just would love to have this process well explained and easier to mitigate

[xmudrii]

This looks good in majority, I left some comments, I'll take a look at them later today and try to get this PR merged.

[xmudrii]

/lgtm
/approve

[kubermatic-bot]

LGTM label has been added.

Git tree hash: 28c6bd50f771ee79f92ef47d4d200c2a1fad9665

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: xmudrii

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [xmudrii]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment