Since a few releases, Go supports `go build -race` and then produces
binaries which do data race detection when invoked. Some changes are needed to
enable using this in a kind cluster:
- `-race` must be passed when building dynamically linked binaries.
Only those support -race because CGO is required.
To avoid adding yet another env variables, the existing KUBE_RACE
gets used to convey the intent.
- KUBE_RACE must be passed into the dockerized build.
- Logging the base image of a release image makes it easier
to figure out whether the binary has a chance to run.
The base image is important because dynamically linked binaries need a base
image with libc. By default, control plane components are linked statically,
so users need to explicitly override the defaults:
KUBE_RACE=-race KUBE_CGO_OVERRIDES="kube-apiserver kube-controller-manager kube-scheduler" KUBE_GORUNNER_IMAGE=gcr.io/k8s-staging-test-infra/kubekins-e2e:v20250815-171060767f-master kind build node-image ...
KUBE_GORUNNER_IMAGE changes the base image for kube-apiserver,
kube-controller-manager and kube-scheduler. The kubekins image was picked for
this example because a Prow job definition already uses it. Reusing
it in a job avoids the need to maintain another image definition.
Running conformance tests against such a cluster with alpha+beta features
enabled revealed one new data race:
$ kubectl logs -n kube-system kube-controller-manager-kind-control-plane
...
WARNING: DATA RACE
Write at 0x00c00019a730 by goroutine 216:
k8s.io/client-go/tools/leaderelection.(*LeaderElector).setObservedRecord()
k8s.io/client-go/tools/leaderelection/leaderelection.go:529 +0x179
k8s.io/client-go/tools/leaderelection.(*LeaderElector).tryCoordinatedRenew()
k8s.io/client-go/tools/leaderelection/leaderelection.go:367 +0x5ca
...
Cleanup the available scripts to remove unused code paths after all
gogo references have been migrated to native protobuf.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
set -x/+x wraps setting relevant configuration variables to debug how and where
they get sets. The final gotestsum invocation gets logged in addition to being
run.
If someone really wants to do golang diagnostics:
https://go.dev/doc/diagnostics#tracing
then they will only be able to do that in debug builds (`DBG`).
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Run "gimme master" and use the newly built binaries. Adjust
GOROOT_BOOTSTRAP so we can use the golang that is already
on disk to build the new commit from golang.
To enable this, edit `.go-version` and set the version to
```
devel
```
and then run `make quick-release` (for example)
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This is in preparation for revamping the resource.k8s.io completely. Because
there will be no support for transitioning from v1alpha2 to v1alpha3, the
roundtrip test data for that API in 1.29 and 1.30 gets removed.
Repeating the version in the import name of the API packages is not really
required. It was done for a while to support simpler grepping for usage of
alpha APIs, but there are better ways for that now. So during this transition,
"resourceapi" gets used instead of "resourcev1alpha3" and the version gets
dropped from informer and lister imports. The advantage is that the next bump
to v1beta1 will affect fewer source code lines.
Only source code where the version really matters (like API registration)
retains the versioned import.
Adds the KUBE_BUILD_WINDOWS option to make release-images and quick-release-images,
which will allow it to build the a Windows kube-proxy image as well. That image can
then be used with Windows Host Process Containers to start the kube-proxy
service on Windows nodes.
