Split/Refactor gcp manifests into separate kpt packages #93
Labels
Comments
|
Issue-Label Bot is automatically applying the labels:
Please mark this comment with 👍 or 👎 to give our bot feedback! |
jlewi
pushed a commit
to jlewi/manifests
that referenced
this issue
Jul 29, 2020
* The management blueprint should have its own KptFile
* Prior to this PR there was only a KptFile at gcp/
* This doesn't work because for the management cluster we
only pull the package gcp/v2/management
* Related to GoogleCloudPlatform/kubeflow-distribution#102
* Related to GoogleCloudPlatform/kubeflow-distribution#93
* For CNRM Switch to workload identity and stop using namespace mode for CNRM; GoogleCloudPlatform/kubeflow-distribution#13
* Using namespace mode is just extra complexity because we have to install
a separate copy of the CNRM controller for every project.
* The only reason to do really do that is if you want to use different
GCP service accounts to manage different projects. Typically that's
not what we do.
* With workload identity we have 1 namespace per project but they
all use the same GCP SA so the GCP sa can just be authorized to
access multiple projects or a folder as needed.
* Update the resources to the v1beta1 spec for use with AnthosCLI
* It looks like anthoscli requires a NodePool resource
* With the v1beta1 specs we need to add the annotation gke.cluster.io = "bootstrap://" so that anthoscli is able to probably group the resources.
* Move cnrm-install iam and services into kustomize packages
* This way we can hydrate them like we do other manifests
* Fix the setters and substitutions for CNRM to make them unique per name
* This way we could potentially have multiple management clusters per project
which if nothing else will be useful for testing.
k8s-ci-robot
pushed a commit
to kubeflow/manifests
that referenced
this issue
Jul 30, 2020
…RM. (#1432) * Fix management blueprint kptfile and stop using namespace mode for CNRM. * The management blueprint should have its own KptFile * Prior to this PR there was only a KptFile at gcp/ * This doesn't work because for the management cluster we only pull the package gcp/v2/management * Related to GoogleCloudPlatform/kubeflow-distribution#102 * Related to GoogleCloudPlatform/kubeflow-distribution#93 * For CNRM Switch to workload identity and stop using namespace mode for CNRM; GoogleCloudPlatform/kubeflow-distribution#13 * Using namespace mode is just extra complexity because we have to install a separate copy of the CNRM controller for every project. * The only reason to do really do that is if you want to use different GCP service accounts to manage different projects. Typically that's not what we do. * With workload identity we have 1 namespace per project but they all use the same GCP SA so the GCP sa can just be authorized to access multiple projects or a folder as needed. * Update the resources to the v1beta1 spec for use with AnthosCLI * It looks like anthoscli requires a NodePool resource * With the v1beta1 specs we need to add the annotation gke.cluster.io = "bootstrap://" so that anthoscli is able to probably group the resources. * Move cnrm-install iam and services into kustomize packages * This way we can hydrate them like we do other manifests * Fix the setters and substitutions for CNRM to make them unique per name * This way we could potentially have multiple management clusters per project which if nothing else will be useful for testing. * Add workload identity pool to the management cluster. * Management nodepool should set workloadMetadataConfig so that we run the workload identity servers. * Fix.
jlewi
pushed a commit
to jlewi/manifests
that referenced
this issue
Jul 31, 2020
* The management blueprint should have its own KptFile
* Prior to this PR there was only a KptFile at gcp/
* This doesn't work because for the management cluster we
only pull the package gcp/v2/management
* Related to GoogleCloudPlatform/kubeflow-distribution#102
* Related to GoogleCloudPlatform/kubeflow-distribution#93
* For CNRM Switch to workload identity and stop using namespace mode for CNRM; GoogleCloudPlatform/kubeflow-distribution#13
* Using namespace mode is just extra complexity because we have to install
a separate copy of the CNRM controller for every project.
* The only reason to do really do that is if you want to use different
GCP service accounts to manage different projects. Typically that's
not what we do.
* With workload identity we have 1 namespace per project but they
all use the same GCP SA so the GCP sa can just be authorized to
access multiple projects or a folder as needed.
* Update the resources to the v1beta1 spec for use with AnthosCLI
* It looks like anthoscli requires a NodePool resource
* With the v1beta1 specs we need to add the annotation gke.cluster.io = "bootstrap://" so that anthoscli is able to probably group the resources.
* Move cnrm-install iam and services into kustomize packages
* This way we can hydrate them like we do other manifests
* Fix the setters and substitutions for CNRM to make them unique per name
* This way we could potentially have multiple management clusters per project
which if nothing else will be useful for testing.
k8s-ci-robot
pushed a commit
to kubeflow/manifests
that referenced
this issue
Jul 31, 2020
…stop using namespace #1437: Fix cloudresourcemanager service; missing ApiVersion. Cherry pick of #1432 #1437 on v1.1-branch. #1432: Fix management blueprint kptfile and stop using namespace #1437: Fix cloudresourcemanager service; missing ApiVersion. (#1439) * Fix management blueprint kptfile and stop using namespace mode for CNRM. * The management blueprint should have its own KptFile * Prior to this PR there was only a KptFile at gcp/ * This doesn't work because for the management cluster we only pull the package gcp/v2/management * Related to GoogleCloudPlatform/kubeflow-distribution#102 * Related to GoogleCloudPlatform/kubeflow-distribution#93 * For CNRM Switch to workload identity and stop using namespace mode for CNRM; GoogleCloudPlatform/kubeflow-distribution#13 * Using namespace mode is just extra complexity because we have to install a separate copy of the CNRM controller for every project. * The only reason to do really do that is if you want to use different GCP service accounts to manage different projects. Typically that's not what we do. * With workload identity we have 1 namespace per project but they all use the same GCP SA so the GCP sa can just be authorized to access multiple projects or a folder as needed. * Update the resources to the v1beta1 spec for use with AnthosCLI * It looks like anthoscli requires a NodePool resource * With the v1beta1 specs we need to add the annotation gke.cluster.io = "bootstrap://" so that anthoscli is able to probably group the resources. * Move cnrm-install iam and services into kustomize packages * This way we can hydrate them like we do other manifests * Fix the setters and substitutions for CNRM to make them unique per name * This way we could potentially have multiple management clusters per project which if nothing else will be useful for testing. * Add workload identity pool to the management cluster. * Management nodepool should set workloadMetadataConfig so that we run the workload identity servers. * Fix. * Fix cloudresourcemanager service; missing ApiVersion. Related to: GoogleCloudPlatform/kubeflow-distribution#102
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now we have one giant kpt package for the management and instance packages
https://github.com/kubeflow/manifests/tree/master/gcp/v2/management
https://github.com/kubeflow/manifests/tree/master/gcp/v2/cnrm
We should probably split these into separate kpt packages (e.g each one should have their own kpt file)
The text was updated successfully, but these errors were encountered: