-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change wordings on CNI,CSI and CRI related pages to really mean k0s s… #3598
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(A personal note on formatting: Hard wrapping text in Markdown files allows for more accurate review comments, as you don't have to comment on two or three sentences at once. (And I think it's generally nicer to look at.))
docs/cloud-providers.md
Outdated
|
||
Use the built-in [manifest deployer](manifests.md) built into k0s to deploy your cloud provider as a k0s-managed stack. Next, just drop all required manifests into the `/var/lib/k0s/manifests/aws/` directory, and k0s will handle the deployment. | ||
You can use any means to deploy your cloud controller inito the cluster. Most providers support [Helm charts](helm-charts.md) to deploy them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use any means to deploy your cloud controller inito the cluster. Most providers support [Helm charts](helm-charts.md) to deploy them. | |
You can use any means to deploy your cloud controller into the cluster. Most providers support [Helm charts](helm-charts.md) to deploy them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be awesome if we could add links to the two or three most important cloud provider helm charts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The inito
typo is still there.
docs/cloud-providers.md
Outdated
@@ -1,10 +1,8 @@ | |||
# Cloud providers | |||
|
|||
k0s builds Kubernetes components in *providerless* mode, meaning that cloud providers are not built into k0s-managed Kubernetes components. As such, you must externally configure the cloud providers to enable their support in your k0s cluster (for more information on running Kubernetes with cloud providers, refer to the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/). | |||
k0s supports all Kubernetes cloud providers that implement the [CCM specification](https://kubernetes.io/docs/concepts/architecture/cloud-controller/). In the case of k0s, all cloud controllers must be installed as cluster add-ons as k0s builds Kubernetes components in *providerless* mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I struggle a bit with the term "CCM specification". The link to the Kubernetes docs is not really pointing to a specification, is it?
Also about "... that implement the CCM specification": Are there any Kubernetes cloud providers out there that don't implement the "specification"? Isn't that the deciding factor for being a Kubernetes cloud provider in the first place?
Kubernetes calls those components cloud controllers. Maybe we should do the same? What about sth. like this:
K0s supports all [Kubernetes cloud controllers]. However, those must be installed as separate cluster add-ons since k0s builds Kubernetes components in *providerless* mode.
[Kubernetes cloud controllers]: https://kubernetes.io/docs/concepts/architecture/cloud-controller/
1778f31
to
bd25c0b
Compare
@twz123 fixed all the things, PTAL again |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's still one small typo left.
docs/cloud-providers.md
Outdated
|
||
Use the built-in [manifest deployer](manifests.md) built into k0s to deploy your cloud provider as a k0s-managed stack. Next, just drop all required manifests into the `/var/lib/k0s/manifests/aws/` directory, and k0s will handle the deployment. | ||
You can use any means to deploy your cloud controller inito the cluster. Most providers support [Helm charts](helm-charts.md) to deploy them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The inito
typo is still there.
k0s comes with some helper commands to create kubeconfig with client certificates for users. There are few caveats that one needs to take into consideration when using client certificates: | ||
|
||
* Client certificates have long expiration time, they're valid for one year | ||
* Client certificates cannot be revoked (general Kubernetes challenge) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…upports ANY standard providers for these The current working might make some users think k0s supports and works with only with the things we bundle in when actually k0s works with any standard Kubernetes component. Signed-off-by: Jussi Nummelin <jnummelin@mirantis.com>
bd25c0b
to
44555ce
Compare
Successfully created backport PR for |
…upports ANY standard providers for these
The current wording might make some users think k0s supports and works with only with the things we bundle in when actually k0s works with any standard Kubernetes component.
Description
Fixes # (issue)
Type of change
How Has This Been Tested?
Checklist: