Currently, whenever agnhost/VERSION is bumped, the version in
agnhost/agnhost.go has to be bumped as well. This is also verified
on presubmit (build/dependencies.yaml).
This means that whenever we need to bump the agnhost image version,
someone has to approve the build/dependencies.yaml, which is not as
easy.
This commit removes the need for this check by automatically setting
the Version inside agnhost.go at build time, simplifying the process.
This change allows the `TAG` value in the pause Makefile to be
overridden from the environment. Defaults to existing hard-coded value
in `build/pause/Makefile`
When building inside a docker container, we fail to pass along enough
information for KUBE_CGO_OVERRIDES. The original PR was geared towards
building the binary from the command line
- dca376a03e
- e4ded2b3ec
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
As described in #100596 this can surprise newcomers.
This adds a paragraph which explains where are the build
artifacts are and how to use the docker images produced
by the build system.
For manifest lists containing Windows images, it is important to also have the "os.version"
annotation set, as it is needed by the Windows nodes, so they can pull the appropriate image
from the list.
Previously, the docker manifest CLI did not have the capability to set it, so, we had to set
it outselves in the manifest list's image JSON file. This is no longer necessary since
docker 20.10.0, which includes docker manifest annotate --os-version.
The docker installed in the image gcr.io/k8s-testimages/gcb-docker-gcloud:v20210622-762366a
satisfies this version requirement.
We can indirectly retrieve the kube-cross version from the
`build/build-image/cross/VERSION` for the sample-apiserver. This allows
us to simplify the handling in `build/dependencies.yaml` as well as
the required approval (via `OWNERS`) if the kube-cross version changes.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Update dependencies and the test images to use pause 3.5. We also
provide a changelog entry for the new container image version.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
docker buildx CLI plugin is not default enable most functionality which we
comsumed during build releases. Means `docker buildx build` will work, but
flags like `--load` or `--platform` is not supported. Which is still true
statement with most up-to-date docker version. That means for new join
member who plan to build by themself, will need to notice if buildx is
properly installed. And not getting confused by build script when docker
complant about unknown flag `--load`, `--platoform`. Hance, add buildx
instruction to note.
- Cleans up some of the image registry handling by
initializing values in a more consistent and clear
manner.
- Adds the Docker library registry to the list of
values that is override-able.
- Adds a few branches to logic to ensure each registry
is handled the same.
The conformance test for ServiceAccountIssuerDiscovery is currently
configured with --in-cluster-discovery, which only supports token
validation against in-cluster endpoints. Many cloud providers provide
their own, external endpoints for OIDC discovery, and because the iss
claim in tokens will point to these endpoints, but the client in this
test only trusts the Cluster CA, it will fail to connect to the external
discovery endpoints when validating the token.
To ensure that the conformance test at least supports scenario where
both the discovery doc endpoint and JWKS endpoint are cluster-local and
the scenario where both endpoints are cluster-external, this PR has the
test try both and requires at least one to pass.
Caveat: The test still won't support a configuration where one
endpoint is cluster-local and the other is external. We don't yet have
evidence that this is a configuration that is used in practice, so this
initial hotfix will at least fix the conformance test for the "both
external" configuration we know providers already use. Note that if one
endpoint is cluster-local, and the other is cluster-external, tokens can
still only be validated in-cluster, because both endpoints must be
accessible to Relying Parties that validate tokens.
kube-cross:v1.16.3-1 contains x86_64-w64-mingw32, which will allow us to
build Windows binaries. With this, we won't have to rely on the dockerhub
image dockcross/windows-static-x64.
This enables building the conformance image when running `make
cross-in-a-container`, which is being used by the release engineering
tooling.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
We now build the pause image to use a pseudo user and group 65535:65535.
This increases the security aspect of the container image, if a
vulnerability would directly affect the pause container.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
This is to consume the changes for binding the udp listeners of netexec
to specific addresses.
Signed-off-by: Federico Paolinelli <fpaoline@redhat.com>
Not all instances of docker run has the --rm argument, which means that they'll
persist after they've finished. This can cause storage to remain occupied needlessly.
Dan and Sascha are senior Release Managers, SIG Release leadership, and
have already been giving thoughtful reviews of the content in this
directory.
Adding them as reviewers to spread the load of SIG Release eyes on
content.
Signed-off-by: Stephen Augustus <foo@auggie.dev>
The `-q` flag is not implemented by `docker buildx`, which results in an
output:
```
WARN[0000] quiet currently not implemented.
```
In the same way, the build output is not logged to `stdout` (but
`stderr`). This means we now dump the whole build process to a file and
if the `docker buildx` command fails, then we output those logs by
printing the contents of that file. This will also reduce the overall
verbosity and aligns to the original `docker build` behavior.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
In order to use buildx with docker versions prior to v20.10 experimental
features must be enabled. Setting at build time ensures that they are
in case they have not already been at the environment scope.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
Both images are now sane multi-architecture images and should fix the
kube-proxy container image in the same way.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
We cannot have any RUN commands in the Windows stage when using docker buildx,
which is why we were using the busybox-helper image. The purpose of the image
was to contain a few things that we would obtain by running a few commands:
- symlinks for the busybox binary
- run vcredist_x64.exe which would also give us the vcruntime140.dll which is
necessary for dig or httpd.
There are alternatives to the commands above that can be achieved in a Linux stage
as well:
- we can create the symlinks in a Linux stage with ln -s. Copying them over to
Windows will allow them to work just as well as if they were being copied over
from a Windows image. The 'Files\' prefix issue to the symlink target still persists.
- we can download the vcruntime140.dll directly, allowing us to skip the vcredist_x64.exe
installation.
The alternative to this would be to special-case code-generator. Since
it legit wants codegen, it seems wrong to make it be _examples (which tools
should ignore).
Make examples an "internal module" so the main go.mod for
k8s.io/code-generator does not get too polluted.
Because this comment is in a `define` which is later evaluated, the
syntactical `$(eval)` is treated like a variable exapansion. Just
change the comment.
Driving towards `make --warn-undefined-variables`.
The ``.container-$OS-$ARCH`` make subaction is creating files with the same name, and ``clean`` is meant to delete them. However, the ``clean``'s rm regex is not quite correct.
In d9cfd77149 and
d70d04f92b we added support for
reproducible builds for individual binaries (like kube-apiserver),
however we need to thread this support when we build binaries with
docker as well (say during "make quick-release").
Essentially, if GOLDFLAGS is set explicitly by someone either to a valid
value they would like to use or empty ("") then we pick that up. If it
is not set we should avoid setting GOLDFLAGS to empty. This ensures that
we support the same functionality documented here:
https://github.com/kubernetes/kubernetes/blob/master/build/root/Makefile#L82-L85
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
A new Windows image has been released in the second half of 2020 with the tag 20H2.
We are going to need a pause image for it as well.
The image tag can be found here: https://hub.docker.com/_/microsoft-windows-nanoserver
It has been observed that the DiagTrack service in the pause
image is consuming a non-trivial amount of CPU. We don't need
this service in the pause image, so we should disable it.
We can disable the service by running chntpw in a docker buildx Linux stage
and then copy the SYSTEM file back to the final Windows image.
Co-Authored-By: Mark Rossetti <marosset@microsoft.com>
Co-Authored-By: Davanum Srinivas <davanum@gmail.com>
As per #96015 and other reports, conversion-gen does the wrong thing if
dependent packages are not ALSO being re-generated. It creates new
versions of generated files that have missing conversions.
This change passes all packages as "extras" which will be parsed but not
regenerated (default already does exactly this).
Provides a response that includes a body and a method. This response
will enable a client (e2e test) to confirm that a proxy did not alter
the http method.
Adds Windows support for most of the images.
Adds a README explaining the image building process, including the
Windows Container image building process.
Some distributions have no default write-access to this file, which
means that it's not possible to update the file and rebuild the project
if not write-able. This patch fixes this by adding an additional
`chmod`.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
We can use docker buildx in order to build and push Windows images from the same Linux
node, as long as the Dockerfile does not have any RUN commands in the Windows step.
We also need to create a non-default builder instance in order to be able to
build and push Windows images.
The Windows images have to be built and pushed directly to the registry. Because of
this, the make target "push" has been removed (the target "all" will build and push
the images).
We need wincat for a few kubectl proxy scenarios.
For Windows containers without Hyper-V isolation, the host OS Version and the
Container OS Version need to match, which is why we added multiple Windows OS Versions
to the building process.
Adds support for Windows OS Versions: 1809, 1903, 1909, 2004.
Bumps pause image version to 3.4.
Co-Authored-By: Claudiu Belu <cbelu@cloudbasesolutions.com>
Co-Authored-By: Ben Moss <bmoss@pivotal.io>
Signed-off-by: Leah Hanson <lhanson@pivotal.io>
'agnhost' image uses hardcoded 'cluster.local' value for DNS domain.
It leads to failure of a bunch of HPA tests when test cluster is
configured to use custom DNS domain and there is no alias for
default 'cluster.local' one.
So, fix it by reusing it's own function for reading DNS domain suffixes.
Signed-off-by: Valerii Ponomarov <kiparis.kh@gmail.com>
Using Windows nanoserver container images as a base instead of the current
Windows servercore image will reduce the image size by about ~10x.
However, the nanoserver image lacks several things we need:
- netapi32.dll
- powershell
- certain powershell commands
- chocolatey cannot be used
When building the nanoserver images, we are going to use a Windows servercore helper,
in which we are going to install the necessary dependencies, and then copy them over
to our nanoserver image, including necessary DLLs.
Other notable changes include:
- switch from wget to curl (wget was a powershell alias).
- implement in code getting the DNS suffix list and DNS server list.
- reimplement getting file permissions for mounttest.
And same for go_test_conditional_pure.
Instead of aliasing. Aliases are annoying in a number of ways. This is
specifically bugging me now because they make the action graph harder to
analyze programmatically. By using aliases here, we would need to handle
potentially aliased go_binary targets and dereference to the effective
target.
The comment references an issue with `pure = select(...)` which appears
to be resolved considering this now builds.
When we switched to go-runner for building the apiserver,
controller-manager, and scheduler server components, we no longer
reference the individual architectures in the image names, specifically
in the 'FROM' directive of the server image Dockerfiles.
As a result, server images for non-amd64 images copy in the go-runner
amd64 binary instead of the go-runner that matches that architecture.
This commit explicitly sets the '--platform=linux/${arch}' to ensure
we're pulling the correct go-runner arch from the manifest list.
Before:
FROM ${base_image}
After:
FROM --platform=linux/${arch} ${base_image}
Signed-off-by: Stephen Augustus <saugustus@vmware.com>
debian-base is no longer used for building core Kubernetes server
components, so we remove the unnecessary local variable referencing it
from kube::build::get_docker_wrapped_binaries().
Signed-off-by: Stephen Augustus <saugustus@vmware.com>
This allows the execution of the Makefiles from distributions which do
have `bash` in a different path.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
