Patrick Ohly 23362e001c build: support -race in binaries ... 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 ...		2025-09-02 16:32:09 +02:00
..
release.sh	build: support -race in binaries	2025-09-02 16:32:09 +02:00