The cancellation of the context happened after the cleanup of the apiserver, so
clients using that context were kept running. That wasn't the intent and causes
a slow shutdown because the apiserver delays its shutdown when it has active
clients.
The fix is to create a new cancellation context and to use that for the
clients. The automatic cancellation of it then happens before the apiserver
cleanup.
For case of SendInitialEvents, a buffer of objects is created. That
process takes a significant amount of memory and CPU when the resource
is of a large volume. Many objects may be not relevant when key is provided.
This commit applies key when composing the buffer for SendInitialEvents.
Signed-off-by: Eric Lin <exlin@google.com>
- Switch to using the ProxyWatcher to validate the dance between
closing the stop channel and closing the result channel.
- Use the new clientfeaturestesting.SetFeatureDuringTest to test with
the WatchListClient enabled and disabled. These should result in
almost the exact same output events from the informer
(list ordering not garenteed), but with different input events
recieved from the apiserver.
If we're following a file, that file will remain open, and we continue
to read data from it when new data becomes available.
On Windows, this can be an issue if the container logs needs to be rotated.
Log rotation is done by renaming the file, but this action may fail if
the file is already opened.
Setting the FILE_SHARE_DELETE flag when opening the file will prevent this
issue, as documented: "Delete access allows both delete and rename operations" [1].
In golang, there's no way to set this flag [2], the sharemode is always set to:
sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE)
Thus, we need to open the file ourselves with the right flags.
[1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea?redirectedfrom=MSDN
[2] https://cs.opensource.google/go/go/+/refs/tags/go1.22.2:src/syscall/syscall_windows.go;l=366
The internal informer populates the RV as soon as it conducts
The first successful sync with the underlying store.
The cache must wait until this first sync is completed to be deemed ready.
Since we cannot send a bookmark when the lastProcessedResourceVersion is 0,
we poll aggressively for the first list RV before entering the dispatch loop.
When using GOTOOLCHAIN with make verify the build results copied out of
the dockerized environment contains a go toolchain folder that is
write protected. In order to prevent failures during the cleanup step
opt-out of copying $GOPATH to the host.
When doing a kubelet health check on init/join, do not
hardcode the "localhost" address. Instead, use the
KubeletConfiguration HealthzBindAddress and HealthzPort
fields.
