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

Add instructions about how to bring up e2e test cluster #85836

Merged
merged 2 commits into from
Jan 2, 2020
Merged

Add instructions about how to bring up e2e test cluster #85836

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b4f5238
Add instructions about how to use kubetest to bring up e2e test cluster
YangLu1031 Dec 3, 2019
b88788b
update to use e2e-up.sh instead of kubetest
YangLu1031 Dec 20, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 20 additions & 5 deletions cluster/gce/windows/README-GCE-Windows-kube-up.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,9 +56,8 @@ make quick-release

### 2. Create a Kubernetes cluster

You can create a regular Kubernetes cluster or an end-to-end test cluster.
End-to-end test clusters support running the Kubernetes e2e tests and enable
some debugging features such as SSH access on the Windows nodes.
You can create a regular Kubernetes cluster or an end-to-end test cluster.<br />
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,9 +77,9 @@ export KUBERNETES_NODE_PLATFORM=windows
export LOGGING_STACKDRIVER_RESOURCE_TYPES=new
```

Now bring up a cluster using kube-up script:
Now bring up a cluster using one of the following two methods:

#### 2. Create a regular Kubernetes cluster
#### 2a. Create a regular Kubernetes cluster

```
# Invoke kube-up.sh with these environment variables:
Expand All @@ -95,6 +94,22 @@ To teardown the cluster run:
PROJECT=${CLOUDSDK_CORE_PROJECT} KUBERNETES_SKIP_CONFIRM=y ./cluster/kube-down.sh
```

#### 2b. Create a Kubernetes end-to-end (E2E) test cluster
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that these headings are accurate:

#### 2a. Create a regular Kubernetes cluster
#### 2b. Create a Kubernetes end-to-end (E2E) test cluster

Is there any difference in the resulting clusters? Can e2e tests be run against clusters brought up using the 2a steps?

I'm wondering if this should instead be:

#### 2. Create a Kubernetes cluster
...explain that there are two ways that work, and explain what the difference between them is...
##### Using kube-up
##### Using kubetest

What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, did some experiments, the main differences are

  1. Both e2e test clusters and e2e test scripts are setup using the config cluster/gce/config-test.sh, so the test scripts look for the e2e cluster only and run tests.
  2. Only e2e test clusters enables SSH on windows nodes. Regular clusters are not. So couldn't dump logs thru scp on regular cluster windows node.

Added explanations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the differences between kubetest --up & ./hack/e2e-internal/e2e-up.sh is that kubetest has extra step at the end: ./cluster/kubectl.sh --match-server-version=false version which seems just update the kubectl binary. And the kubectl.sh will be deprecated soon from the file descriptions.

If you have built your own release binaries following step 1, run the following
command:
```
PROJECT=${CLOUDSDK_CORE_PROJECT} ./hack/e2e-internal/e2e-up.sh
```

If any e2e cluster exists already, this command will prompt you whether tears down and creates a new one. To teardown existing e2e cluster only, run the command:
```
PROJECT=${CLOUDSDK_CORE_PROJECT} ./hack/e2e-internal/e2e-down.sh
```

No matter what type of cluster you chose to create, the result should be a
Kubernetes cluster with one Linux master node, `NUM_NODES` Linux worker nodes
and `NUM_WINDOWS_NODES` Windows worker nodes.

## Validating the cluster

Invoke this script to run a smoke test that verifies that the cluster has been
Expand Down