The existing Zones interface was mainly created for the kubelet
to interface with a local metadata server to fetch a node's zone
and region. With external cloud providers, it makes more sense for
the zone/region logic to be coupled to the Instances interface.
This commit adds zone/region information to the recently added
InstanceMetadata type we're using as part of the new InstancesV2
interface in the cloud provider.
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
- Changed kubectl top to sort first at the pod level and then at the container level when --sort-by and --containers are used together.
- Refactored printSinglePodMetrics into two separate functions instead of passing in bool to change behavior.
- Refactored MetricsSorters to simplify code.
- Added unit tests to test container sorting.
- Fixed pod sorting unit tests which were not working because it was checking for --sort-by command line flag which was never true.
- Test that client-side apply users don't encounter a conflict with
server-side apply for objects that previously didn't track managedFields
- Test that we stop tracking managed fields with `managedFields: []`
- Test that we stop tracking managed fields when the feature is disabled
This code can be called not only when a container is dead and restarted,
but when is started for the first time too. For example, any pod with
initContainer and containers will exhibit this behaviour. The reason is
that in that case, the "if createPodSandbox" path will return the
initContainers only and on the next call to this function this code is
executed to start the containers for the fist time.
In that case, it is wrong to log that the container is dead and will be
restarted, as it was never started. In fact, the restart count will not
be increased.
This commit just changes this to say that the container is not in the
desired state and should be started. In the end, the kubelet is a state
machine and that is all we really care about.
No tests are added, as the behaviour was correct and tests don't check
logs messages.
Signed-off-by: Rodrigo Campos <rodrigo@kinvolk.io>
As of now, the kubelet is passing the security context to container runtime even
if the security context has invalid options for a particular OS. As a result,
the pod fails to come up on the node. This error is particularly pronounced on
the Windows nodes where kubelet is allowing Linux specific options like SELinux,
RunAsUser etc where as in [documentation](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-container),
we clearly state they are not supported. This PR ensures that the kubelet strips
the security contexts of the pod, if they don't make sense on the Windows OS.
The KEP specifies that the controller will "mirror all labels from the
Endpoints resource and all endpoints and ports from the corresponding subset".
I'd missed that in my initial implementation, this should fix that.
A cloud provider should have the option to only implement the new
InstanceV2 interface. Currently the cloud nodelifecycle controller only
makes instancev1 calls when it should prefer instancev2 if supported and
fallback to the existing instancev1 otherwise.
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
