github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-24 04:06:03 +00:00
Code Issues Projects Releases Wiki Activity

Improve the Windows GCE README

Browse Source
This commit is contained in:
Peter Hornyack 2021-01-14 16:09:58 -08:00
parent 661eae7c7c
commit 313ac4751c
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:
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:
# References: https://cloud.google.com/sdk/docs/authorizing#authorizing_with_a_service_account
# 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
NOTE: this step is only needed if you want to test local changes you made to
the codebase.
NOTE: this step is only needed if you want to test local changes you made to the
codebase.
The most straightforward approach to build those binaries is to run `make
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.
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
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
Ensure your GCP authentication is current:
```bash
# Invoke kube-up.sh with these environment variables:
# PROJECT: text name of your GCP project.
# 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
gcloud auth application-default login
gcloud auth login
```
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:
```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
If you have built your own release binaries following step 1, run the following
command:
```bash
PROJECT=${CLOUDSDK_CORE_PROJECT} WINDOWS_NODE_OS_DISTRIBUTION=win2019 \
./hack/e2e-internal/e2e-up.sh
WINDOWS_NODE_OS_DISTRIBUTION=win2019 ./hack/e2e-internal/e2e-up.sh
```
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:
```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
@ -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
[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.
```bash
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
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
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
on GCE can be seen by searching for `--test-cmd-args` in the [test
configuration](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-windows/windows-gce.yaml#L78)
* 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 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
should be passed to the `run-e2e` script; escape the ginkgo arguments by
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
```
* 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:
```bash
@ -187,6 +205,6 @@ directory.
## E2E Testing
Once you've created a pull request you can comment,
`/test pull-kubernetes-e2e-windows-gce` to run the integration tests that cover
the changes in this directory.
Once you've created a pull request you can comment, `/test
pull-kubernetes-e2e-windows-gce` to run the integration tests that cover the
changes in this directory.