Create a doc to describe the deployment process. #1159
Conversation
docs_dev/kubeflow_deployment.md
Outdated
|
|
||
| 1. We provide simple, platform deployment scripts like this [one for GKE](https://github.com/kubeflow/kubeflow/blob/master/docs/gke/configs/deploy.sh) | ||
|
|
||
| 1. A corresponding platform specific getting started page ([see here]](https://github.com/kubeflow/website/tree/master/content/docs/started) provides platform specific instructions |
docs_dev/kubeflow_deployment.md
Outdated
|
|
||
| 1. We provide simple, platform deployment scripts like this [one for GKE](https://github.com/kubeflow/kubeflow/blob/master/scripts/gke/deploy.sh) | ||
|
|
||
| 1. A corresponding platform specific getting started page ([see here]](https://github.com/kubeflow/website/tree/master/content/docs/started) provides platform specific instructions |
There was a problem hiding this comment.
Replace [see here]] with [see here]
|
/retest |
|
|
||
| The scaffolding/prototype for this (bootstrapper) is still in place and we haven't | ||
| rejected this idea completely. So contributions pursuing this idea further would | ||
| be welcome. |
There was a problem hiding this comment.
@jlewi I liked the design of the bootstrapper running in the 'kubeflow' namespace with elevated privileges. It did seem to have a limitation of only creating/deploying one kubeflow instance/namespace with no specific rbac mapping to users in that namespace. i wonder if this design might be continued with a local command communicating with the bootstrapper for create, delete, list, add <user/group>, and other subcommands. The bootstrapper would leverage the application as a bundling construct for different types of applications that have different users, cloud-providers and components.
There was a problem hiding this comment.
See #1151 The bootstrapper is turning into a wrapper around ksonnet to support click to deploy. And moves it into the direction of being an app manager. (I hope providing a REST server in front of ks will eventually be officially part of ksonnet).
This is needed to support click to deploy which uses a javascript client side web app. So we can't run ks in that case.
We can also avoid providing elevated permissions via a service account and instead use a bearer token containing user credentials in the request. Ideally that credential could be scoped (e.g. in GCP don't want to pass a GCP credential with access to other resources).
I think we should avoid duplicating the functions provided by existing tools e.g. ks and kubectl.
I think the next piece of functionality that will go into it will be monitoring functionality see #1106.
|
|
||
| Here are some **guidelines (not requirements)** for creating the above scripts and instructions | ||
|
|
||
| * Platform scripts should assume users are starting from scratch |
There was a problem hiding this comment.
IMO platform scripts which create the cluster and its node pools (eg deployment manager) should be separate from scripts which create/deploy a kubeflow instance which should also be separate from scripts which create the user/group/PV/PVCs.
There was a problem hiding this comment.
See comment below about the scripts being linear. My thinking is that providing a single script optimizes for getting started "one command". If the scripts are linear it should be pretty straightforward.
If we can have a module approach where the scripts are split up into separate scripts that can then be called from a single uber script that might be nice too. That would probably help with code reuse as well. But I also don't want to make our scripts super complicated.
| opening more. | ||
|
|
||
| The current thinking is to follow the guidance of sig-apps and use an [application resource](https://github.com/kubernetes-sigs/application) | ||
| to represent Kubeflow and attach events, status, and other metrics to that application as appropriate. |
There was a problem hiding this comment.
In addition to the application crd noted above - could the SecurityProfile also be leveraged?
There was a problem hiding this comment.
Assuming you mean for security purposes (as opposed to monitoring) then I think so. It looks like SecurityProfile is still very early though and not even supported by sig-apps yet.
There was a problem hiding this comment.
yes. It is early but it seems like it could be combined with application resource - where a UI could allow different components and security profiles to be bundled and deployed.
Is the bootstrapper assuming that only one kubeflow instance would be deployed or many? EG:
- kubeflow-admin
above privileged namespace could deploy kubeflow 'instances' like below and have different directories (that could include gitops) for each deployment - kubeflow-teamX
- kubeflow-datascientistY
- kubeflow-pytorch-gpu-1
There was a problem hiding this comment.
bootstrapper is becoming a server around ksonnet see #1151. So in this case the server can be used with manager different ksonnet applications and not just deploying kubeflow. Its primary function will be as a templating microservice e.g.
paramaters, ksonnetapp -> YAML manifests.
|
/assign @kunmingg Can you LGTM this? Would be good to get it committed. |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jlewi 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:
Approvers can indicate their approval by writing |
|
/retest |
1 similar comment
|
/retest |
|
Rebase'd to pick up improvements to the tests. |
|
/lgtm |
|
/retest |
* This is not a proposal but a description of the current state.
|
/lgtm |
* This is not a proposal but a description of the current state.
/assign @ankushagarwal
/assign @kunmingg
This change is