feat(tools): Add script to deploy local CCM with kops #877
Conversation
This commit introduces a new bash script, `deploy-kops-gcp.sh`, to automate the deployment of a Kubernetes cluster on GCP using kops, specifically configured to run a locally built version of the cloud-controller-manager. This script streamlines the development and testing workflow by handling the entire process: - Building the cloud-controller-manager Docker image. - Pushing the image to the user's Google Container Registry (GCR). - Copying the default CCM manifest and using `sed` to replace the image with the newly built version. - Creating and updating a kops cluster with the `ClusterAddons` feature flag, injecting the custom manifest. The script requires the `GCP_PROJECT` environment variable to be set. It includes a cleanup function to automatically delete the cluster upon completion, which can be disabled by setting `DELETE_CLUSTER=false`. This provides developers with a quick and repeatable way to test their changes on a real cluster.
k8s-ci-robot
added
the
cncf-cla: no
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: cowsking The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
needs-triage
|
This issue is currently awaiting triage. If the repository mantainers determine this is a relevant issue, they will accept it by applying the The 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-sigs/prow repository. |
|
Welcome @cowsking! |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @cowsking. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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-sigs/prow repository. |
k8s-ci-robot
added
the
size/L
| if [[ -z "${CLUSTER_NAME:-}" ]]; then | ||
| CLUSTER_NAME="${SCRIPT_NAME}.k8s.local" | ||
| fi | ||
| echo "CLUSTER_NAME=${CLUSTER_NAME}" |
There was a problem hiding this comment.
Personally I would rather we just required the cluster name rather than defaulting to the script name. Willing to be over ruled on this though.
tools/kops_local_ccm.sh
Outdated
|
|
||
| if [[ -z "${GCP_PROJECT:-}" ]]; then | ||
| echo "GCP_PROJECT must be set" | ||
| exit 1 |
There was a problem hiding this comment.
Can we move the requirements checks closer to the beginning? Seems like we should do this first, then start taking actions.
|
/ok-to-test |
k8s-ci-robot
added
ok-to-test
|
just FYI there is already a job that test this ccm with kops https://github.com/kubernetes/cloud-provider-gcp/blob/master/e2e/scenarios/kops-simple cc: @justinsb |
refactor: Move requirement checks to beginning of process
You're right that e2e/scenarios/kops-simple handles the automated testing. This script serves a different purpose as a direct response to developer requests for a simpler, kubetest2-free way to quickly stand up a kops cluster for local manual testing and debugging. Let me know how you think @cheftako @aojea @justinsb |
k8s-ci-robot
added
cncf-cla: yes
This commit introduces a new bash script,
deploy-kops-gcp.sh, to automate the deployment of a Kubernetes cluster on GCP using kops, specifically configured to run a locally built version of the cloud-controller-manager.This script streamlines the development and testing workflow by handling the entire process:
sedto replace the image with the newly built version.ClusterAddonsfeature flag, injecting the custom manifest.The script requires the
GCP_PROJECTenvironment variable to be set. It includes a cleanup function to automatically delete the cluster upon completion, which can be disabled by settingDELETE_CLUSTER=false. This provides developers with a quick and repeatable way to test their changes on a real cluster.