github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-23 11:50:44 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #98282 from pjh/README-updates

Browse Source 
Improve the Windows GCE README
This commit is contained in:
Kubernetes Prow Robot 2021-01-21 17:49:29 -08:00 committed by GitHub
commit 1bbe5599ff
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 47 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
cluster/gce/windows/README-GCE-Windows-kube-up.md
View File

@ -20,11 +20,6 @@ Then, optionally clean/prepare your environment using these commands:
# Remove files that interfere with get-kube / kube-up: # Remove files that interfere with get-kube / kube-up:
rm -rf ./kubernetes/; rm -f kubernetes.tar.gz; rm -f ~/.kube/config rm -rf ./kubernetes/; rm -f kubernetes.tar.gz; rm -f ~/.kube/config
# Set the default gcloud project for this shell. This is optional but convenient
# if you're working with multiple projects and don't want to repeatedly switch
# between gcloud config configurations.
export CLOUDSDK_CORE_PROJECT=<your_project_name>
# To run e2e test locally, make sure "Application Default Credentials" is set in any of the places: # To run e2e test locally, make sure "Application Default Credentials" is set in any of the places:
# References: https://cloud.google.com/sdk/docs/authorizing#authorizing_with_a_service_account # References: https://cloud.google.com/sdk/docs/authorizing#authorizing_with_a_service_account
# https://cloud.google.com/sdk/gcloud/reference/auth/application-default/ # https://cloud.google.com/sdk/gcloud/reference/auth/application-default/
@ -37,8 +32,8 @@ export GOOGLE_APPLICATION_CREDENTIAL=[path_to_the_json_file]
### 1. Build Kubernetes ### 1. Build Kubernetes
NOTE: this step is only needed if you want to test local changes you made to NOTE: this step is only needed if you want to test local changes you made to the
the codebase. codebase.
The most straightforward approach to build those binaries is to run `make The most straightforward approach to build those binaries is to run `make
release`. However, that builds binaries for all supported platforms, and can be release`. However, that builds binaries for all supported platforms, and can be
@ -54,7 +49,12 @@ KUBE_BUILD_PLATFORMS="linux/amd64 windows/amd64" make quick-release
You can create a regular Kubernetes cluster or an end-to-end test cluster. You can create a regular Kubernetes cluster or an end-to-end test cluster.
Only end-to-end test clusters support running the Kubernetes e2e tests (as both [e2e cluster creation](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/e2e-internal/e2e-up.sh#L24) and [e2e test scripts](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/ginkgo-e2e.sh#L42) are setup based on `cluster/gce/config-test.sh`), also enables some debugging features such as SSH access on the Windows nodes. Only end-to-end test clusters support running the Kubernetes e2e tests (as both
[e2e cluster creation](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/e2e-internal/e2e-up.sh#L24)
and
[e2e test scripts](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/ginkgo-e2e.sh#L42)
are setup based on `cluster/gce/config-test.sh`), also enables some debugging
features such as SSH access on the Windows nodes.
Please make sure you set the environment variables properly following the Please make sure you set the environment variables properly following the
instructions in the previous section. instructions in the previous section.
@ -78,38 +78,56 @@ Now bring up a cluster using one of the following two methods:
#### 2a. Create a regular Kubernetes cluster #### 2a. Create a regular Kubernetes cluster
Ensure your GCP authentication is current:
```bash ```bash
# Invoke kube-up.sh with these environment variables: gcloud auth application-default login
# PROJECT: text name of your GCP project. gcloud auth login
# WINDOWS_NODE_OS_DISTRIBUTION: the Windows version you want your nodes to
# run, e.g. win2019 or win1909.
# KUBE_UP_AUTOMATIC_CLEANUP (optional): cleans up existing cluster without
# prompting.
PROJECT=${CLOUDSDK_CORE_PROJECT} WINDOWS_NODE_OS_DISTRIBUTION=win2019 \
KUBE_UP_AUTOMATIC_CLEANUP=true ./cluster/kube-up.sh
``` ```
Invoke kube-up.sh with these environment variables:
```bash
# WINDOWS_NODE_OS_DISTRIBUTION: the Windows version you want your nodes to
# run, e.g. win2019 or win1909.
# KUBE_UP_AUTOMATIC_CLEANUP (optional): cleans up existing cluster without
# prompting.
WINDOWS_NODE_OS_DISTRIBUTION=win2019 KUBE_UP_AUTOMATIC_CLEANUP=true ./cluster/kube-up.sh
```
If your GCP project is configured with two-factor authentication, you may need
to tap your security key shortly after running `kube-up`.
To teardown the cluster run: To teardown the cluster run:
```bash ```bash
PROJECT=${CLOUDSDK_CORE_PROJECT} ./cluster/kube-down.sh ./cluster/kube-down.sh
``` ```
If you want to run more than one cluster simultaneously, you can use two
separate GCP projects and:
1. Use a separate shell for each project / cluster.
1. Set the `CLOUDSDK_CORE_PROJECT` environment variable to the GCP project you
want to use in each shell. This variable will override your current gcloud
config.
1. Prefix your `kube-up.sh` and `kube-down.sh` commands with
`PROJECT=${CLOUDSDK_CORE_PROJECT}`
#### 2b. Create a Kubernetes end-to-end (E2E) test cluster #### 2b. Create a Kubernetes end-to-end (E2E) test cluster
If you have built your own release binaries following step 1, run the following If you have built your own release binaries following step 1, run the following
command: command:
```bash ```bash
PROJECT=${CLOUDSDK_CORE_PROJECT} WINDOWS_NODE_OS_DISTRIBUTION=win2019 \ WINDOWS_NODE_OS_DISTRIBUTION=win2019 ./hack/e2e-internal/e2e-up.sh
./hack/e2e-internal/e2e-up.sh
``` ```
If any e2e cluster exists already, this command will prompt you to tear down and If any e2e cluster exists already, this command will prompt you to tear down and
create a new one. To teardown existing e2e cluster only, run the command: create a new one. To teardown existing e2e cluster only, run the command:
```bash ```bash
PROJECT=${CLOUDSDK_CORE_PROJECT} ./hack/e2e-internal/e2e-down.sh ./hack/e2e-internal/e2e-down.sh
``` ```
No matter what type of cluster you chose to create, the result should be a No matter what type of cluster you chose to create, the result should be a
@ -135,14 +153,14 @@ If you brought up an end-to-end test cluster using the steps above then you can
use the steps below to run K8s e2e tests. These steps are based on use the steps below to run K8s e2e tests. These steps are based on
[kubernetes-sigs/windows-testing](https://github.com/kubernetes-sigs/windows-testing). [kubernetes-sigs/windows-testing](https://github.com/kubernetes-sigs/windows-testing).
* Build the necessary test binaries. This must be done after every change to * Build the necessary test binaries. This must be done after every change to
test code. test code.
```bash ```bash
make WHAT=test/e2e/e2e.test make WHAT=test/e2e/e2e.test
``` ```
* Set necessary environment variables and fetch the `run-e2e.sh` script: * Set necessary environment variables and fetch the `run-e2e.sh` script:
```bash ```bash
export KUBECONFIG=~/.kube/config export KUBECONFIG=~/.kube/config
@ -158,9 +176,9 @@ use the steps below to run K8s e2e tests. These steps are based on
NOTE: `run-e2e.sh` begins with a 5 minute sleep to wait for container images NOTE: `run-e2e.sh` begins with a 5 minute sleep to wait for container images
to be pre-pulled. You'll probably want to edit the script and remove this. to be pre-pulled. You'll probably want to edit the script and remove this.
* The canonical arguments for running all Windows e2e tests against a cluster * The canonical arguments for running all Windows e2e tests against a cluster
on GCE can be seen by searching for `--test-cmd-args` in the [test on GCE can be seen by searching for `--test-cmd-args` in the
configuration](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-windows/windows-gce.yaml#L78) [test configuration](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-windows/windows-gce.yaml#L78)
for the `ci-kubernetes-e2e-windows-gce` continuous test job. These arguments for the `ci-kubernetes-e2e-windows-gce` continuous test job. These arguments
should be passed to the `run-e2e` script; escape the ginkgo arguments by should be passed to the `run-e2e` script; escape the ginkgo arguments by
adding quotes around them. For example: adding quotes around them. For example:
@ -171,7 +189,7 @@ use the steps below to run K8s e2e tests. These steps are based on
--ginkgo.skip="\[LinuxOnly\]|\[Serial\]|\[Feature:.+\]" --minStartupPods=8 --ginkgo.skip="\[LinuxOnly\]|\[Serial\]|\[Feature:.+\]" --minStartupPods=8
``` ```
* Run a single test by setting the ginkgo focus to match your test name; for * Run a single test by setting the ginkgo focus to match your test name; for
example, the "DNS should provide DNS for the cluster" test can be run using: example, the "DNS should provide DNS for the cluster" test can be run using:
```bash ```bash
@ -187,6 +205,6 @@ directory.
## E2E Testing ## E2E Testing
Once you've created a pull request you can comment, Once you've created a pull request you can comment, `/test
`/test pull-kubernetes-e2e-windows-gce` to run the integration tests that cover pull-kubernetes-e2e-windows-gce` to run the integration tests that cover the
the changes in this directory. changes in this directory.