The subpath could be passed a powershell subexpression which would be executed by kubelet with privilege. Switching to pass the arguments via environment variables means the subexpression won't be evaluated.
Signed-off-by: James Sturtevant <jstur@microsoft.com>
PVC and containers shared the same ResourceRequirements struct to define their
API. When resource claims were added, that struct got extended, which
accidentally also changed the PVC API. To avoid such a mistake from happening
again, PVC now uses its own VolumeResourceRequirements struct.
The `Claims` field gets removed because risk of breaking someone is low:
theoretically, YAML files which have a claims field for volumes now
get rejected when validating against the OpenAPI. Such files
have never made sense and should be fixed.
Code that uses the struct definitions needs to be updated.
The fact that the .status.loadBalancer field can be set while .spec.type
is not "LoadBalancer" is a flub. Any spec update will already clear
.status.ingress, so it's hard to really rely on this. After this
change, updates which try to set this combination will fail validation.
Existing cases of this will not be broken. Any spec/metadata update
will clear it (no error) and this is the only stanza of status.
New gate "AllowServiceLBStatusOnNonLB" is off by default, but can be
enabled if this change actually breaks someone, which seems exceeedingly
unlikely.
using wait.PollUntilContextTimeout instead of deprecated wait.Poll for test/integration/scheduler
using wait.PollUntilContextTimeout instead of deprecated wait.Poll for test/e2e/scheduling
using wait.ConditionWithContextFunc for PodScheduled/PodIsGettingEvicted/PodScheduledIn/PodUnschedulable/PodSchedulingError
The "set" list type was chosen because it seemed appropriate (no duplicates!)
but that made tracking of managed fields more expensive (each entry in the list
is tracked, not the entire field) and for no good reason (one client is
responsible for the entire list).
Therefore the type gets changed to "atomic". Server-side-apply has not been
used in the past and PodSchedulingContext objects are short-lived and still in
alpha, so the any potential compatibility issues should be minor.
The scheduling throughput in scheduler_perf increases:
name old SchedulingThroughput/Average new SchedulingThroughput/Average
PerfScheduling/SchedulingWithResourceClaimTemplate/2000pods_100nodes-36 18.8 ± 8% 24.0 ±37%
PerfScheduling/SchedulingWithMultipleResourceClaims/2000pods_100nodes-36 13.7 ±81% 18.5 ±40%
