* proxy: v2.246.0
Release notes: https://github.com/linkerd/linkerd2-proxy/releases/tag/release/v2.246.0
Signed-off-by: l5d-bot <l5d-bot@users.noreply.github.com>
* pin max k3s to known working version in integration tests
Signed-off-by: Alex Leong <alex@buoyant.io>
---------
Signed-off-by: l5d-bot <l5d-bot@users.noreply.github.com>
Signed-off-by: Alex Leong <alex@buoyant.io>
Co-authored-by: l5d-bot <l5d-bot@users.noreply.github.com>
Co-authored-by: Alex Leong <alex@buoyant.io>
* IPv6 integration tests
This adds a new test `TestDualStack` to the deep suite that ensures requests to a dual stack service are always routed the the IPv6 endpoint.
It also amends other tests in the suite for them to work in IPv6-only clusters:
- skipports: replaced the booksapp with emojivoto, given the servers in the former don't bind to IPv6 addresses
- endpoints: amended the regexes to include IPv6 addresses
- localhost: bumped nginx for it to bind to the IPv6 loopback as well
Note the `TestDualStack` test is disabled by default because Github runners don't support IPv6. To run it locally, first deploy a dual-stack cluster via:
```
kind create cluster --config test/integration/deep/kind-dualstack.yml
```
(for testing IPv6-only clusters, use the `kind-ipv6.yml` config)
Then load the images and trigger the test with:
```
bin/tests --name deep-dual-stack --skip-cluster-create $PWD/target/cli/linux-amd64/linkerd
```
We use the `kube_codegen.sh` script from the kubernetes/code-generator
repo to generate Go bindings for CRDs defined in this repo. The
arguments and flags for that script changed in Kubernetes 1.30, which
broke our usage of that script when this repo's Kubernetes dependencies
were updated in #12463.
In this change, I'm updating `bin/update-codegen.sh` to work with the
latest version of the `kube_codegen.sh` script.
To validate, check out this branch and run `bin/update-codegen.sh`. The
script should exit cleanly, and there should be no changes to the
previously-generated Go bindings.
Signed-off-by: Kevin Ingelman <ki@buoyant.io>
Added the test `deep-native-sidecar` which runs the `deep` test with the
new flag `--native-sidecar`.
Also replaced the final `WaitRollout` call in `install_test.go` with a
`linkerd check` call, to also allow us verifying that command is working
as intended.
This removes the `upgrade-stable` integration test and refactors the
`helm-upgrade` one to upgrade from the last published edge helm charts
instead of the last stable.
We previously relied on knowing the tag structure, but this is brittle if we
change anything in the proxy repo. Instead, we now use the GitHub API to
list all releases, and we match the version by name.
In the sync-proxy workflow, we can use the github CLI directly to inspect the
API. This changes the commit message to include a link to the release notes
instead of replicating them in the commit message
* Automate edge releases
Followup to #12132
Now one only needs to tag in order to trigger the release. Please see the updated `RELEASE.md` file for the new instructions.
The last action in the release workflow, `helm-publish`, now runs:
- `bin/helm-bump-edge`: This has been modified to calculate the new edge version by inspecting https://run.linkerd.io/install-edge and bumping the version found there, using a new scheme `YYYY.M.N` (also droppping the `-edge` suffix) shared across all the charts (except for `partials`, `patch` and `linkerd-multicluster-link` which remain static). The `version` entry in the Chart.yaml files no longer needs to be manually updated, and its value is not used for the new version computation, so it was changed to `0.0.0-undefined`. Also note this script validates that the current git tag matches the expected new version.
- `bin/helm-docs`: Called just to update the charts READMEs with the new version. We also still call it in the `helm.yml` workflow to check the values.yaml entries are in sync. So after any change to those values, we still need to manually run `bin/helm-docs`.
- `bin/helm-build package`: As the previous two steps mutate the local checked out source, this no longer validates that there are no uncommited changes.
---------
Co-authored-by: Oliver Gould <ver@buoyant.io>
Whenever we make changes to CRDs we need to update our Go bindings. Part
of the process (i.e. generating informers, listers, clientsets) is
automated through a utility script provided by a Kubernetes upstream
library.
We have a wrapper (`bin/update-codegen`) around the script. The wrapper
will call into the generator by using a path relative to `$GOPATH`. When
unset, the script will fail. Some environments may have an unbound
GOPATH, we simplify our wrapper script by cloning the repo in the root
of the project instead of relying on GOPATH.
Signed-off-by: Matei David <matei@buoyant.io>
* build: Update fetch-proxy to support alternate repos
In some build and test scenarios, it's desirable to fetch alternate proxy
releases during the build process.
This change updates the proxy container image build tooling to support the
LINKERD2_PROXY_REPO and LINKERD2_PROXY_GITHUB_TOKEN environment variables. These
may be set to the desired repository and a GitHub personal access token,
respectively.
When these are unset, the default behavior is unchanged.
GitHub can automatically generate release notes from commit messages. This saves
us from having to manually update the `CHANGES.md` file every week.
In preparation for the next edge release, this change updates the release
workflow to stop relying on the CHANGES file. The CHANGES file is updated with a
pointer to the releases page.
The ExternalWorkload resource we introduced has a minor naming
inconsistency; `Tls` in `meshTls` is not capitalised. Other resources
that we have (e.g. authentication resources) capitalise TLS (and so does
Go, it follows a similar naming convention).
We fix this in the workload resource by changing the field's name and
bumping the version to `v1beta1`.
Upgrading the control plane version will continue to work without
downtime. However, if an existing resource exists, the policy controller
will not completely initialise. It will not enter a crashloop backoff,
but it will also not become ready until the resource is edited or
deleted.
Signed-off-by: Matei David <matei@buoyant.io>
We introduced an ExternalWorkload CRD for mesh expansion. This change
follows up by adding bindings for Rust and Go code.
For Go code:
* We add a new schema and ExternalWorkload types
* We also update the code-gen script to generate informers
* We add a new informer type to our abstractions built on-top of
client-go, including a function to check if a client has access to the
resource.
For Rust code:
* We add ExternalWorkload bindings to the policy controller.
---------
Signed-off-by: Matei David <matei@buoyant.io>
Recent versions of the code-generator package have replaced the `generate-groups.sh` script that we use to generate client-go bindings for custom resource types with a new script called `kube_codegen.sh`. This PR updates our `update-codgen.sh` script to use `kube_codegen.sh` instead of `generate-groups.sh`.
Signed-off-by: Alex Leong <alex@buoyant.io>
New versions of the k8s-openapi crate drop support for Kubernetes 1.21.
Kubernetes v1.22 has been considered EOL by the upstream project since
2022-07-08. Major cloud providers have EOL'd it as well (GKE's current
MSKV is 1.24).
This change updates the MSKV to v1.22. It also updates the max version
in _test-helpers.sh to v1.28.
* Reenable cni-calico-deep integration test
Fixes#11567
The trick is to run the test under k8s `v1.27.6-k3s1` as the following
versions break Calico in k3s (see k3d-io/k3d#1375).
Also removed the `continue-on-error: true` directive in the integration
workflow because it was hiding this problem.
* Clean up ./cni-plugin directory
Closes#11568
It's been a while since we moved the linkerd-cni plugin code, tests and
build scripts into the linkerd2-proxy-init repo. The cni-plugin
directory can be safely removed.
Docker introduced a `gha` cache type, removing the need to manage our
own Docker cache in CI.
Modify the `docker-build` action to set required `ACTIONS_CACHE_URL` and
`ACTIONS_RUNTIME_TOKEN` environment variables, consumed by
`docker buildx` commands. Additionally, removed `docker-cache-prune`
and `DOCKER_BUILDKIT_CACHE`.
Cached Docker build times reduced to 15s ~ 1m45s.
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
PR #11528 changed the `rust-toolchain` file to use the TOML format
rather than the plaintext format. Unfortunately, this broke the
`test-policy` CI job, which `cat`s the contents of the `rust-toolchain`
file to determine which Rust version to install, and that file now no
longer exists (since it's now in `rust-toolchain.toml`). See:
https://github.com/linkerd/linkerd2/actions/runs/6649430068/job/18068192854?pr=11535
This branch fixes that by changing the CI job to use a regex to extract
the Rust toolchain version instead.
171985d updated the bin/docker-build script to output metadata files
into to root directory of the repo. This dirties the git status and is
generally inconcistent with the way our tooling works.
This change updates the location of the files to be under the
`./target/` directory, along with all of our other build outputs.
Add go client codegen for HttpRoute v1beta3. This will be necessary for any of the go controllers (i.e. metrics-api) or go CLI commands to interact with HttpRoute v1beta3 resources in kubernetes.
Signed-off-by: Kevin Ingelman <ki@buoyant.io>
This adds the ability to pass in a docker builder option to docker. This makes building multi-arch images super simple by using our k8s infrastructure.
It also makes building multi-arch images very fast since they can be built in parallel and on native hardware.
DCO Sign off
I agree to the DCO for all the commits in this PR.
Co-authored-by: Alejandro Pedraza <alejandro.pedraza@gmail.com>
We have a number of tests in the `test/integration/install` directory which exercise basic functionality such as injecting pods and sending traffic. These test are not currently run at all.
We update a number of tests which were previously just installing Linkerd to also run these basic tests.
Signed-off-by: Matei David <matei@buoyant.io>
Signed-off-by: Alex Leong <alex@buoyant.io>
Co-authored-by: Matei David <matei@buoyant.io>
The policy controller is currently built by cross-building, however, the
process is not very robust. In order to cross-build, we have to build
each image on the host platform (typically amd64), install a target
architecture compiler, and use a distroless runtime image tied to the
target arch. Furthermore, arm targets also have to compile using rustls
instead of openssl. The result is that we have three different
dockerfiles that build the image: each one specialized for a target
arch. At the end, the manifests are combined to provide a multi-arch
image.
By using a different base layer for the builder (dev container), we can
cross compile more efficiently. First, instead of dynamically linking
the TLS library, we statically link openssl. This is done by vendoring
the dependency and feature gating it (available as a default feature but
can be turned off to compile with rustls). This is all abstracted away
by using a `just` script present on the base image; the recipe sets up
the environment. Second, since all binaries are compiled using static
linking, we can use an architecture agnostic `scratch` runtime layer.
This greatly simplifies the process. We only need to maintain one docker
file. Details about the compilation (which compiler to use) are
abstracted away in the `just` file. The image includes dependencies to
build for all three target architectures supported by Linkerd: amd64,
arm and arm64 (clang, libssl). All targets are now using openssl.
Signed-off-by: Matei David <matei@buoyant.io>
Co-authored-by: Oliver Gould <ver@buoyant.io>
wind the new linkerd-cni build through the build. refactor image, version, and pullPolicy into an Image object.
Signed-off-by: Steve Jenson <stevej@buoyant.io>
* build(deps): bump sigs.k8s.io/gateway-api from 0.5.1 to 0.6.0
Bumps [sigs.k8s.io/gateway-api](https://github.com/kubernetes-sigs/gateway-api) from 0.5.1 to 0.6.0.
- [Release notes](https://github.com/kubernetes-sigs/gateway-api/releases)
- [Changelog](https://github.com/kubernetes-sigs/gateway-api/blob/main/CHANGELOG.md)
- [Commits](https://github.com/kubernetes-sigs/gateway-api/compare/v0.5.1...v0.6.0)
---
updated-dependencies:
- dependency-name: sigs.k8s.io/gateway-api
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
* Account for possible errors returned from `AddEventHandler`
In v0.26.0 client-go's `AddEventHandler` method for informers started
returning a registration handle (that we ignore) and an error that we
now surface up.
* client-go v0.26.0 removed the openstack plugin
* Temporary changes to trigger tests in k8s 1.21
- Adds an innocuous change to integration.yml so that all tests get
triggered
- Hard-code k8s version in `k3d cluster create` invocation to v1.21
* Revert "Temporary changes to trigger tests in k8s 1.21"
This reverts commit 3e1fdd0e5e.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Alejandro Pedraza <alejandro@buoyant.io>
Supersedes #9856, now that the `linkerd check` logic in the integrations tests got cleaned up via #9989.
The helm-upgrade test had been commented-out when we jumped to the new 2.12 helm charts. It can be used again to test upgrades from 2.12.x.
- Some of the logic in `test/integration/install/install_test.go` still hadn't considered the need to upgrade both the `linkerd-crds` and `linkerd-control-plane` charts, so that got fixed.
- Removed references to the now-deprecated `linkerd2` chart.
- Improved the `helm_cleanup()` function by uninstalling the charts in reverse order (extensions first, core last). We delete the namespaces afterwards because helm sometimes doesn't remove them, and so we shouldn't fail if we attempt to delete one that is already gone. Also removed unneeded `kubectl wait`s because `kubect delete ns` should be blocking.
`bin/linkerd` may use an outdated cached binary. There's no mechanism to
invalidate this cache except to manually delete the file. This is
cumbersome, and a common source of developer confusion.
This change removes this caching logic so that the binary is always
rebuilt. This is relatively quick (<2s) when nothing has changed.
* Use self-hosted runner for ARM64 integration tests
This refactors the "ARM64 integration tests" job in `relase.yaml` to
use an ARM self-hosted runner tagged with `[self-hosted, Linux, ARM64]`,
tied to the linkerd github org.
We no longer use a local (linux/x86_64) linkerd CLI that connects to an
existing k3s instance in the host. Instead, we run the CLI ARM64 binary
in the host itself, after creating the cluster with k3d (which gets
always torn down at the end of the tests regardless of their success).
Please check the "ARM CI host at Equinix Metal" doc in Notion for the
host setup.
## Other Changes
- The cni test was removed.
- Replaced `"$bindir"/docker` with just `docker` in `bin/image-load` as
we do elsewhere.
- Properly detect k3d arch in `bin/k3d`
The controller's k8s client was using `admissionregistration/v1beta1`
for its MWC shared informer. `v1beta1` was removed in k8s 1.22, and `v1`
was introduced in k8s 1.16:
https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22
Modify the controller's k8s client to use `admissionregistration/v1` for
its MWC shared informer.
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
https://github.com/linkerd/dev is a new repo that contains our
devcontainer tooling and includes git submodules for all repositories
that use this tooling (to ease validating dev changes).
This change removes the devcontainer (and devcontainer-specific tooling)
from the linkerd2 repo in favor of using this new repo.
Signed-off-by: Oliver Gould <ver@buoyant.io>
Depends on #9195
Currently, `linkerd inject --default-inbound-policy` does not set the
`config.linkerd.io/default-inbound-policy` annotation on the injected
resource(s).
The `inject` command does _try_ to set that annotation if it's set in
the `Values` generated by `proxyFlagSet`:
14d1dbb3b7/cli/cmd/inject.go (L485-L487)
...but, the flag in the proxy `FlagSet` doesn't set
`Values.Proxy.DefaultInboundPolicy`, it sets
`Values.PolicyController.DefaultAllowPolicy`:
7c5e3aaf40/cli/cmd/options.go (L375-L379)
This is because the flag set is shared across `linkerd inject` and
`linkerd install` subcommands, and in `linkerd install`, we want to set
the default policy for the whole cluster by configuring the policy
controller. In `linkerd inject`, though, we want to add the annotation
to the injected pods only.
This branch fixes this issue by changing the flag so that it sets the
`Values.Proxy.DefaultInboundPolicy` instead of the
`Values.PolicyController.DefaultAllowPolicy` value. In `linkerd
install`, we then set `Values.PolicyController.DefaultAllowPolicy` based
on the value of `Values.Proxy.DefaultInboundPolicy`, while in `inject`,
we will now actually add the annotation.
This branch is based on PR #9195, which adds validation to reject
invalid values for `--default-inbound-policy`, rather than on `main`.
This is because the validation code added in that PR had to be moved
around a bit, since it now needs to validate the
`Values.Proxy.DefaultInboundPolicy` value rather than the
`Values.PolicyController.DefaultAllowPolicy` value. I thought using
#9195 as a base branch was better than basing this on `main` and then
having to resolve merge conflicts later. When that PR merges, this can
be rebased onto `main`.
Fixes#9168
Each of our repos now has variations of a script to check that all
github workflows/actions use the same version of the devcontainer as
that specified in devcontainer.json. Some versions of this have had
small problems (mostly with regard to `yq` syntax).
This change extracts a reusable script, `bin/action-dev-check`, that is
now bundled in v28 of the devcontainer. This will enable other
repositories to use the same validation logic.
```
:; just action-dev-check
bin/action-dev-check
.github/workflows/actions.yml:16: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/actions.yml:24: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/go.yml:19: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/go.yml:27: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/go.yml:35: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/helm.yml:18: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/proto.yml:18: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/rust.yml:45: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/rust.yml:53: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/rust.yml:63: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/rust.yml:73: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
.github/workflows/shell.yml:18: Expected image 'ghcr.io/linkerd/dev:v28'; found 'ghcr.io/linkerd/dev:v27'
```
Signed-off-by: Oliver Gould <ver@buoyant.io>
Signed-off-by: Oliver Gould <ver@buoyant.io>
It can be difficult to understand why a given module is a part of our Go
dependencies. This change adds utility scripts--inspired by Rust's
`cargo tree`--that use `go mod graph` to inspect Go dependencies.
* `go-mod-tree` -- like `cargo tree`, prints all dependencies from an
optional root module.
* `go-mod-versions` -- enumerates all versions of a module in the Go
dependency graph
* `go-mod-why` -- like `cargo tree -i`, prints the tree of modules that
depend on a given module.
Signed-off-by: Oliver Gould <ver@buoyant.io>
* Allows RSA signed trust anchors on linkerd cli (#7771)
Linkerd currently forces using an ECDSA P-256
issuer certificate along with a ECDSA trust
anchor. Still, it's still cryptographically valid
to have an ECDSA P-256 issuer certificate issued
by an RSA signed CA.
CheckCertAlgoRequirements checks if CA cert uses
ECDSA or RSA 2048/4096 signing algorithm.
Fixes#7771
Signed-off-by: Baeyens, Daniel <daniel.baeyens@gmail.com>
Co-authored-by: Alejandro Pedraza <alejandro@buoyant.io>
l5d-bot