Until we port the remaining e2e tests to use exec host pods instead
of SSH, it should be possible to use bastion host when
clusters don't expose public IPs for nodes. Testers can use the
KUBE_SSH_BASTION environment variable set to a `host:port` to
specify the host that the tests will use as a jump host.
If KUBE_SSH_BASTION is specified, the test will first connect to
the bastion using SSH and the provider private key, then establish
a tunnel from the bastion to the target node by its IP. If the
node has an external IP, the external IP must be routable from the
bastion.
Support KUBE_SSH_KEY_PATH as a single environment variable that if
specified ignores the provider specific settinsg and loads the
SSH private key from the provided path. Makes it much easier to
specify a consistent signer across providers.
e2e-node tests may use custom system specs for validating nodes to
conform the specs. The functionality is switched on when the tests
are run with this command:
make SYSTEM_SPEC_NAME=gke test-e2e-node
Currently the command fails with the error:
F1228 16:12:41.568836 34514 e2e_node_suite_test.go:106] Failed to load system spec: open /home/rojkov/go/src/k8s.io/kubernetes/k8s.io/kubernetes/cmd/kubeadm/app/util/system/specs/gke.yaml: no such file or directory
Move the spec file under `test/e2e_node/system/specs` and introduce a single
public constant referring the file to use instead of multiple private constants.
Add "omitempty" to spec.dataSource like it is done for all other
optional fields too.
Serialized code creates otherwise "null" fields and some introspection
tools rely on that value to determine if a value is optional or
required.
Stop special casing KUBE_TEST_ARGS and limiting the API
group/version settings to "v1" when running the tests. This was
helpful in the past when we used to test multiple values for
KUBE_TEST_API_VERSIONS - if you were specifying KUBE_TEST_ARGS to run a
single test case, you probably didn't want to have it tested for
multiple values of KUBE_TEST_API_VERSIONS.
Now, however, KUBE_TEST_API_VERSIONS comes from
KUBE_AVAILABLE_GROUP_VERSIONS by default, which is a single list instead
of multiple, so we shouldn't need to special case KUBE_TEST_ARGS any
more. This is especially necessary because certain tests that are using
testapi break if KUBE_TEST_API_VERSIONS is just "v1".
Signed-off-by: Andy Goldstein <goldsteina@vmware.com>
Selfhosting pivoting fails when using --store-certs-in-secrets
as controller-manager fails to start because of missing front-proxy CA
certificate:
unable to load client CA file: unable to load client CA file: open
/etc/kubernetes/pki/front-proxy-ca.crt: no such file or directory
Added required certificate to fix this.
This should fixkubernetes/kubeadm#1281
Kubernetes Prow Robot