By default, cmd is used to execute commands in Windows containers, but it
has some issues executing the command (no output):
echo 'hostName' | nc -w 1 -u <targetIP> <targetPort>
But it has no issues running (output is correct):
echo hostName | nc -w 1 -u <targetIP> <targetPort>
This causes the test "should function for node-pod communication: udp" to
fail when using Windows Containers.
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.
Some tests which utilized SSH to run commands on nodes would
first look for external IPs but fall back to internal IPs
since those could be reachable by the testing program.
This change adds that same fallback logic to another method
used to find the appropriate SSH address for each node.
Fixes#68747
Tests might want to use there own options for specifying a file path,
while still using the abstract file access API. For example,
framework.CreateFromManifests might be used to create a mixture of
files under the repo root and from elsewhere. To support this,
absolute paths can now be given to the testfiles package and they will
be read directly.
While debugging issues I found myself having to change the constant in the code
for a cluster > 20 nodes, and then on a very small cluster I found myself passing
0 to avoid the mostly useless output (it's useful in specific scenarios but generates
a *lot* of output that doesn't help debugging the rest of the time).
Some mounttest related tests are checking the file permissions set on the
container files, but the default file permissions on Windows is 775 instead of
644, causing some tests to fail.
Keep in mind that file permissions work differently on Windows, and setting file
permissions via Kubernetes is not currently supported on Windows.
Attempting to retrieve logs for a container that hasn't started yet
may have been the reason for the "the server does not allow this
method on the requested resource" error that showed up on the GCE CI
test cluster (issue #70888).
If we wait with retrieving logs until the pod is running or has
terminated, then we might be able to avoid that error. It's the right
thing to do either way and not complicated to implement.
