Restructure the Ubuntu Getting Started Section.
- This supercedes PR #1770 - This breaks up the section from one huge installation page into: - A new index page. - New support grid with commercial and community support options. - Move to lifecycle-based pages based on operational tasks. - Add support for local deployments via LXD. - Added screenshots to images/docs/ubuntu - Add backup page. - Add decommissioning page. - Add a glossary of terms page. - Rewritten installation page. - Add logging page. - Add monitoring page. - Add networking page, flannel only for now, calico in progress. - Add a scaling page. - Add a security page. - Add a storage page. - Add a troubleshooting page. - Add an upgrade page. - Add a cluster validation page. - Add new ubuntu content to the index page. - Add Ubuntu to _data TOC. - Add warning about choosing ipv6 with LXD, thanks Ed Baluf. - Template-ize all the pages per jaredb's review.
This commit is contained in:
Jorge O. Castro
@@ -0,0 +1,161 @@
|
||||
---
|
||||
title: Validation
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
This page will outline how to ensure that a Juju deployed Kubernetes cluster has stood up correctly and is ready to accept workloads.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
This page assumes you have a working Juju deployed cluster.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
# Validation
|
||||
|
||||
## End to End Testing
|
||||
|
||||
End-to-end (e2e) tests for Kubernetes provide a mechanism to test end-to-end
|
||||
behavior of the system, and is the last signal to ensure end user operations
|
||||
match developer specifications. Although unit and integration tests provide a
|
||||
good signal, in a distributed system like Kubernetes it is not uncommon that a
|
||||
minor change may pass all unit and integration tests, but cause unforeseen
|
||||
changes at the system level.
|
||||
|
||||
The primary objectives of the e2e tests are to ensure a consistent and reliable
|
||||
behavior of the kubernetes code base, and to catch hard-to-test bugs before
|
||||
users do, when unit and integration tests are insufficient.
|
||||
|
||||
### Usage
|
||||
|
||||
To deploy the end-to-end test suite, you need to relate the `kubernetes-e2e` charm to your existing kubernetes-master nodes and easyrsa:
|
||||
|
||||
```
|
||||
juju deploy kubernetes-e2e
|
||||
juju add-relation kubernetes-e2e kubernetes-master
|
||||
juju add-relation kubernetes-e2e easyrsa
|
||||
```
|
||||
|
||||
Once the relations have settled, you can do `juju status` until the workload status results in
|
||||
`Ready to test.` - you may then kick off an end to end validation test.
|
||||
|
||||
### Running the e2e test
|
||||
|
||||
The e2e test is encapsulated as an action to ensure consistent runs of the
|
||||
end to end test. The defaults are sensible for most deployments.
|
||||
|
||||
juju run-action kubernetes-e2e/0 test
|
||||
|
||||
|
||||
### Tuning the e2e test
|
||||
|
||||
The e2e test is configurable. By default it will focus on or skip the declared
|
||||
conformance tests in a cloud agnostic way. Default behaviors are configurable.
|
||||
This allows the operator to test only a subset of the conformance tests, or to
|
||||
test more behaviors not enabled by default. You can see all tunable options on
|
||||
the charm by inspecting the schema output of the actions:
|
||||
|
||||
juju actions kubernetes-e2e --format=yaml --schema
|
||||
|
||||
Output:
|
||||
|
||||
```
|
||||
test:
|
||||
description: Run end-to-end validation test suite
|
||||
properties:
|
||||
focus:
|
||||
default: \[Conformance\]
|
||||
description: Regex focus for executing the test
|
||||
type: string
|
||||
skip:
|
||||
default: \[Flaky\]
|
||||
description: Regex of tests to skip
|
||||
type: string
|
||||
timeout:
|
||||
default: 30000
|
||||
description: Timeout in nanoseconds
|
||||
type: integer
|
||||
title: test
|
||||
type: object
|
||||
```
|
||||
|
||||
As an example, you can run a more limited set of tests for rapid validation of
|
||||
a deployed cluster. The following example will skip the `Flaky`, `Slow`, and
|
||||
`Feature` labeled tests:
|
||||
|
||||
juju run-action kubernetes-e2e/0 skip='\[(Flaky|Slow|Feature:.*)\]'
|
||||
|
||||
> Note: the escaping of the regex due to how bash handles brackets.
|
||||
|
||||
To see the different types of tests the Kubernetes end-to-end charm has access
|
||||
to, we encourage you to see the upstream documentation on the different types
|
||||
of tests, and to strongly understand what subsets of the tests you are running.
|
||||
|
||||
[Kinds of tests](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/e2e-tests.md#kinds-of-tests)
|
||||
|
||||
### More information on end-to-end testing
|
||||
|
||||
Along with the above descriptions, end-to-end testing is a much larger subject
|
||||
than this readme can encapsulate. There is far more information in the
|
||||
[end-to-end testing guide](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/e2e-tests.md).
|
||||
|
||||
### Evaluating end-to-end results
|
||||
|
||||
It is not enough to just simply run the test. Result output is stored in two
|
||||
places. The raw output of the e2e run is available in the `juju show-action-output`
|
||||
command, as well as a flat file on disk on the `kubernetes-e2e` unit that
|
||||
executed the test.
|
||||
|
||||
> Note: The results will only be available once the action has
|
||||
completed the test run. End-to-end testing can be quite time intensive. Often
|
||||
times taking **greater than 1 hour**, depending on configuration.
|
||||
|
||||
##### Flat file
|
||||
|
||||
Here's how to copy the output out as a file:
|
||||
|
||||
juju run-action kubernetes-e2e/0 test
|
||||
|
||||
Output:
|
||||
|
||||
Action queued with id: 4ceed33a-d96d-465a-8f31-20d63442e51b
|
||||
|
||||
Copy output to your local machine
|
||||
|
||||
juju scp kubernetes-e2e/0:4ceed33a-d96d-465a-8f31-20d63442e51b.log .
|
||||
|
||||
##### Action result output
|
||||
|
||||
Or you can just show the output inline::
|
||||
|
||||
juju run-action kubernetes-e2e/0 test
|
||||
|
||||
Output:
|
||||
|
||||
Action queued with id: 4ceed33a-d96d-465a-8f31-20d63442e51b
|
||||
|
||||
Show the results in your terminal:
|
||||
|
||||
juju show-action-output 4ceed33a-d96d-465a-8f31-20d63442e51b
|
||||
|
||||
|
||||
### Known issues
|
||||
|
||||
The e2e test suite assumes egress network access. It will pull container
|
||||
images from `gcr.io`. You will need to have this registry unblocked in your
|
||||
firewall to successfully run e2e test results. Or you may use the exposed
|
||||
proxy settings [properly configured](https://github.com/juju-solutions/bundle-canonical-kubernetes#proxy-configuration)
|
||||
on the kubernetes-worker units.
|
||||
|
||||
## Upgrading the e2e tests
|
||||
|
||||
The e2e tests are always expanding, you can see if there's an upgrade available by running `juju status kubernetes-e2e`.
|
||||
|
||||
When an upgrade is available, upgrade your deployment:
|
||||
|
||||
juju upgrade-charm kubernetes-e2e
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
Reference in New Issue
Block a user