Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve the Windows GCE README #98282

Merged
merged 1 commit into from Jan 22, 2021
Merged

Improve the Windows GCE README #98282

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
76 changes: 47 additions & 29 deletions cluster/gce/windows/README-GCE-Windows-kube-up.md
View file
Open in desktop
Expand Up @@ -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/
Expand All @@ -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
Expand All @@ -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.
Expand All @@ -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
gcloud auth application-default login
gcloud auth login
```

Invoke kube-up.sh with these environment variables:

```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
# 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
Expand All @@ -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
Expand All @@ -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:
Expand All @@ -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
Expand All @@ -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.