We currently build all of our CLI binaries serially, but if we have a
docker stage for each platform, we can parellize builds for each
platform, reducing build times significantly.
This change renames `cli/Dockerfile-bin` to `cli/Dockerfile` (so
that we get syntax highlighting in editors, etc) and restructures the
Dockerfile to have a docker stage for each platform. Then, there are
two final stages: 'basic' and 'multi-arch'. The `bin/docker-build-cli-bin`
utility typically only builds the `basic` target; when
`DOCKER_MULTIARCH` is set, it also builds the target that includes
arm binaries.
Variable references are only expanded to previously defined
environment variables as per https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#envvar-v1-core
which means for `LINKERD2_PROXY_POLICY_WORKLOAD` to work correctly, the
`_pod_ns` `_pod_name` should be present before they are used.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
Fixes#6688
This PR adds the new `LINKERD2_PROXY_POLICY_SVC_ADDR` and
`LINKERD2_PROXY_POLICY_SVC_NAME` env variables which are used to specify
the address and the identity (which is `linkerd-destination`) of the
policy server respectively.
This also adds the new `LINKERD2_PROXY_POLICY_WORKLOAD` in the format
of `$ns:$pod` which is used to specify the identity of the workload itself.
A new `_pod_name` env variable has been added to get the name of the pod
through the Downward API.
These variables are only set if the `proxy.component` is not
`linkerd-identity`.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
`svc/linkerd-policy` selects pods on
`linkerd.io/control-plane-component: policy`; but this doesn't actually
select any controller pods.
This change ensures all `control-plane-component` labels use
`destination` instead of `policy`.
https://github.com/linkerd/linkerd2/pull/5567 introduced behavior where we consider the owner references of a pod to be authoritative about which resources contain that pod. This is in contrast to relying on the label selectors which can be ambiguous when, for example, deployments have overlapping label selectors.
This distinction is non-obvious. To prevent regressions in this behavior, we add tests to codify this requirement.
Signed-off-by: Alex Leong <alex@buoyant.io>
We've implemented a new controller--in Rust!--that implements discovery
APIs for inbound server policies. This change imports this code from
linkerd/polixy@25af9b5e.
This policy controller watches nodes, pods, and the recently-introduced
`policy.linkerd.io` CRD resources. It indexes these resources and serves
a gRPC API that will be used by proxies to configure the inbound proxy
for policy enforcement.
This change introduces a new policy-controller container image and adds a
container to the `Linkerd-destination` pod along with a `linkerd-policy` service
to be used by proxies.
This change adds a `policyController` object to the Helm `values.yaml` that
supports configuring the policy controller at runtime.
Proxies are not currently configured to use the policy controller at runtime. This
will change in an upcoming proxy release.
Fixes https://github.com/linkerd/linkerd2/issues/3706
The implementation of the `linkerd viz edges` command works by gathering http and tcp metrics in both the inbound and outbound directions and combining this data in dubious ways.
We make the implementation simpler and more correct by instead doing the following:
* Gather tcp metrics only
* (this drops support for very old proxy versions which do not expose the `tcp_open_connections` metric)
* Gather outbound metrics only
* (all meshed edges will have a src in the mesh and will be present in the outbound metrics)
* Outbound metrics do not have a `client_id` label, so we fill in this missing data by inspecting the source pod via the k8s api and reconstruct that pod's TLS identity based on it's service account name and namespace.
Signed-off-by: Alex Leong <alex@buoyant.io>
We've implemented new CRDs to support configuration and discovery of
inbound policies. This change imports these CRDs from
linkerd/polixy@25af9b5 and adds them to the default Linkerd installation:
- `servers.policy.linkerd.io`
- `serverauthorizations.policy.linkerd.io`
When running `linkerd upgrade`, we check to make sure that the trust anchors in each data plane pod will validate the issuer certificate. However, the control plane pods no longer have the trust anchors embedded directly; they are now mounted from the linkerd-trust-anchors configmap. Thus we should skip this check specifically for the control plane pods.
Signed-off-by: Alex Leong <alex@buoyant.io>
* Do not install PSP resources by default
Fixes#6549
PodSecurityPolicy is deprecated as of k8s v1.21 and will be unavailable starting k8s v1.25. This was causing warnings to be displayed in `linkerd install/upgrade` and `linkerd check`.
By default, do not include the linkerd PSP resource along with its Role and RoleBinding. If the user wants that, they can by setting `enablePSP: true`, a new config introduced for this purpose.
This was done in the linkerd, linkerd-cni, linkerd-viz, multicluster and jaeger charts.
The associated checks were also removed, including the NET_ADMIN+NET_RAW capabilities check, which rely on the PSP API.
Fixes#6452
We add a `linkerd-identity-trust-roots` ConfigMap which contains the configured trust root bundle. The proxy template partial is modified so that core control plane components load this bundle from the configmap through the downward API.
The identity controller is updated to mount this new configmap as a volume read the trust root bundle at startup.
Similarly, the proxy-injector also mounts this new configmap. For each pod it injects, it reads the trust root bundle file and sets it on the injected pod.
Signed-off-by: Alex Leong <alex@buoyant.io>
Increase container security by making the root file system of the cni
install plugin read-only.
Change the temporary directory used in the cni install script, add a
writable EmptyDir volume and enable readOnlyFileSystem securityContext
in cni plugin helm chart.
Tested this by building the container image of the cni plugin and
installed the chart onto a cluster. Logs looked the same as before this
change.
Fixes#6468
Signed-off-by: Gerald Pape <gerald@giantswarm.io>
Fixes#5589
The core control plane has a dependency on the viz package in order to use the `BuildResource` function. This "backwards" dependency means that the viz source code needs to be included in core docker-builds and is bad for code hygiene.
We move the `BuildResource` function into the viz package. In `cli/cmd/metrics.go` we replace a call to `BuildResource` with a call directly to `CanonicalResourceNameFromFriendlyName`.
Signed-off-by: Alex Leong <alex@buoyant.io>
* Set `LINKERD2_PROXY_INBOUND_PORTS` during injection
Fixes#6267
The `LINKERD2_PROXY_INBOUND_PORTS` env var will be set during injection,
containing a comma-separated list of the ports in the non-proxy containers in
the pod. For the identity, destination and injector pods, the var is set
manually in their Helm templates.
Since the proxy-injector isn't reinvoked, containers injected by a mutating
webhook after the injector has run won't be detected. As an escape hatch, the
`config.linkerd.io/pod-inbound-ports` annotation has been added to explicit
overrides.
Other changes:
- Removed
`controller/proxy-injector/fake/data/inject-sidecar-container-spec.yaml` which
is no longer used. - Fixed bad indentation in some fixture files under
`controller/proxy-injector/fake/data`.
Default Linkerd skip and opaque port configuration
Missing default ports based on docs
Addressed: Add Redis to default list of Opaque ports #6132
Once merged, the default install values will match the recommendations in Linkerd's TCP ports guide.
Fixes#6132
Signed-off-by: jasonmorgan <jmorgan@f9vs.com>
Co-authored-by: Alejandro Pedraza <alejandro.pedraza@gmail.com>
If kubernetes system is not up, we were displaying usage after the error, masking the actual issue in the logs.
I agree to the DCO for all the commits in this PR
Signed-off-by: dileep <dileepreddyr@gmail.com>
* Add missing ignoreInboundports to CNI config and also fixed ignoreOutboundports to support passing just one port
This change fixes an issue where tap does not work when running Linkerd
through Linkerd CNI installed via helm charts. This issue was caused by
the CNI chart's value not including tap control and admin ports in the
config. This caused tap request traffic to go to the inbound side of the
proxy as opposed to the respective tap control port.
Fixes#6224
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
List of changes:
- Include more output in the `simulate` mode (thanks @liuerfire!")
- Log to `stdout` instead of `stderr` (thanks @mo4islona!)
Non user-facing changes:
- Added `dependabot.yml` to receive automated dependencies upgrades PRs (both for go and github actions). As a result, also upgraded a bunch of dependencies.
Closes#6177
This change adds an additional check to the data plane category which will warn users when the `opaque-ports` annotation is misconfigured on services and pods.
As an example, the output looks like this:
```
$ linkerd check --proxy
...
× opaque ports are properly annotated
* service/emoji-svc has the annotation config.linkerd.io/opaque-ports but pod/emoji-696d9d8f95-8p94s doesn't
* pod/voting-67bb58c44c-dgt46 and service/voting-svc have the annotation config.linkerd.io/opaque-ports but values don't match
see https://linkerd.io/2/checks/#linkerd-opaque-ports-definition for hints
```
Signed-off-by: Miguel Ángel Pastor Olivar <migue@github.com>
Because extension label values have been changed, an older install of an extension will fail to be uninstalled with a more recent CLI version. This is because the uninstall command checks the new label value which doesn't match older installs.
This small change fixes that by checking both -- the new, non-prefixed version and the old prefixed one. The bug should have a relatively small impact since there are only a few edge releases that contain the prefixed label value (an exception being stable-2.10.0 which used the prefixed version still).
Signed-off-by: Matei David <matei@buoyant.io>
This PR corrects misspellings identified by the [check-spelling action](https://github.com/marketplace/actions/check-spelling).
The misspellings have been reported at 0d56327e6f (commitcomment-51603624)
The action reports that the changes in this PR would make it happy: 03a9c310aa
Note: this PR does not include the action. If you're interested in running a spell check on every PR and push, that can be offered separately.
Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
Because of changes in control-plane and extensions, the current
serviceprofiles in `install-sp` are no longer relevant. Most of the
current ones should be moved over into the viz extension.
This leaves the core cp with just the `linkerd-dst` serviceprofile.
Fixes#6084
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
Go 1.16.4 includes a fix for a denial-of-service in net/http: golang/go#45710
Go's error file-line formatting changed in 1.16.3, so this change
updates tests to only do suffix matching on these error strings.
* Skip configuring firewall if rules exists
This change fixes an issue where the `proxy-init` will fail if
`PROXY_INIT_*` chains already exist in the pod's iptables. This then
causes the pod to never start because proxy-init never finishes running
with a non-zero exit code.
In this change, we capture the output of the `iptables-save` command and
then check to see if the output contains the `PROXY_INIT_*` chains. If
they do, exist and log a warning stating that the chains already
exist.
Fixes#5786
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
Linkerd's CLI offers basic shell suggestions on most of its subcommands.
These suggestions are based on hardcoded suggestion lists, for example such
`viz stat` auto suggests a list of all resources types supported by that
command located in `k8s.go`. Although this provides basic suggestions
for k8s manifest resources, prior to this change, there currently is no
way to get auto suggested resources from the k8s cluster linkerd is
installed in.
This change adds a new `CommandCompletion` module that reads arguments
and a substring, and queries the k8s API to determine what suggestions
to provide to the user. The current implementation makes the module
generic enough to query most Kubernetes resourcesand can be used for all
subcommands in the CLI.
This change only applies this behavior to the `stat` command as first
step. Adding auto completion for other commands will be done in a number
of follow up PRs.
To test out the change on this branch:
- Build the CLI binaries on this branch
- install the completion scripts for your shell environment. Running
`linkerd completion -h` should give you more info on how to do that.
- If not installed already, install `linkerd viz`
```
linkerd viz install | k apply -f -
```
- test out completion by typing
```
linkerd viz stat [tab][tab]
```
Part of #5981
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
Supersedes #5885
We've recently refactored the linkerd docs in the website to host separate sections for each major 2.x version. The [Troubleshooting page](https://linkerd.io/2.10/tasks/troubleshooting/) section is also versioned, but currently the hint URLs output by `linkerd check` commands point to `https://linkerd.io/checks` which redirects to `https://linkerd.io/2.10/tasks/troubleshooting`.
This PR changes the base of those hint URL so that instead it points to `https://linkerd.io/{version}/checks` where `{version}` is the CLI's major version. If the CLI is not in a stable version (edge or local dev version) then `{version}` will be `2` which the site will redirect to the latest stable version.
This change is coupled with linkerd/website#5885 that takes care of the website-side of things.
* Support Traffic Splitting through `ServiceProfile.dstOverrides`
This commit
- updates the destination logic to prevent the override of `ServiceProfiles.dstOverrides` when a `TS` is absent and no `dstOverrides` set. This means that any `serviceprofiles.dstOverrides` set by the user are correctly propagated to the proxy and thus making Traffic Splitting through service profiles work.
- This also updates the `profile_translator.toDstOverrides` to use the port from `GetProfiles` when there is no port in `dstOverrides.authority`
After these changes, The following `ServiceProfile` to perform
traffic splitting should work.
```yaml
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
name: backend-svc.linkerd-trafficsplit-test-sp.svc.cluster.local
spec:
dstOverrides:
- authority: "backend-svc.linkerd-trafficsplit-test-sp.svc.cluster.local.:8080"
weight: 500m
- authority: "failing-svc.linkerd-trafficsplit-test-sp.svc.cluster.local.:8080"
weight: 500m
```
This PR also adds an integration test i.e `TestTrafficSplitCliWithSP` which checks for
Traffic Splitting through Service Profiles. This integration test follows the same pattern
of other traffic split integration tests but Instead, we perform `linkerd viz stat` on the
client and check if there are expected server objects to be there as `linkerd viz stat ts`
does not _yet_ work with Service Profiles.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
The `check` command is useful in verifying if a cluster is ready for
linkerd to be install or if a linkerd installation was successful. In
most cases, all check results are green and all checks results are
displayed to the user, however, this output can be verbose especially
when copying and pasting it around for other users to see.
This change introduces a `--short` flag for the `check` command where it
only shows errors or warnings encountered when `check` is run. It then
show the regular overall `Status check results are...` message once
complete. If all checks pass, we only show the check results message.
This change also includes a code reorg refactor for the `check.go` file
by moving all output format related code into `healthcheck.go`. It also
includes some code to output a new header for core checks in the `'basic'`
format.
```bash
Linkerd core checks
===================
Status check results are √
```
Some outstanding questions:
- Feedback on the current formatting of the `--short` is welcome. I did
not change the wording but rather just omitted successful checks.
- This change does not include the short flag for extension specific
checks. My thinking was that those checks are not as verbose as the
parent linkerd check and do not need the flag.
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
* checks: add proxy checks for core cp and extension pods
Fixes#5623
This PR adds proxy checks for control-plane and extension pods
when the respective checks are ran. This can make sure proxies
are working correctly and are able to communicate.
Currently, The following checks are added:
- proxy status checks
- proxy certificate checks
- proxy version checks
These are the same data-plane proxy checks that were already
present.
As these checks result in errors in most cases under integration
tests as there are latest versions online. This is fixed by templating
the check golden files and checking for the known error.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
Co-authored-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
### What
This change adds the `config.linkerd.io/proxy-await` annotation which when set will delay application container start until the proxy is ready. This allows users to force application containers to wait for the proxy container to be ready without modifying the application's Docker image. This is different from the current use-case of [linkerd-await](https://github.com/olix0r/linkerd-await) which does require modifying the image.
---
To support this, Linkerd is using the fact that containers are started in the order that they appear in `spec.containers`. If `linkerd-proxy` is the first container, then it will be started first.
Kubernetes will start each container without waiting on the result of the previous container. However, if a container has a hook that is executed immediately after container creation, then Kubernetes will wait on the result of that hook before creating the next container. Using a `PostStart` hook in the `linkerd-proxy` container, the `linkerd-await` binary can be run and force Kubernetes to pause container creation until the proxy is ready. Once `linkerd-await` completes, the container hook completes and the application container is created.
Adding the `config.linkerd.io/await-proxy` annotation to a pod's metadata results in the `linkerd-proxy` container being the first container, as well as having the container hook:
```yaml
postStart:
exec:
command:
- /usr/lib/linkerd/linkerd-await
```
---
### Update after draft
There has been some additional discussion both off GitHub as well as on this PR (specifically with @electrical).
First, we decided that this feature should be enabled by default. The reason for this is more often than not, this feature will prevent start-up ordering issues from occurring without having any negative effects on the application. Additionally, this will be a part of edges up until the 2.11 (the next stable release) and having it enabled by default will allow us to check that it does not conflict often with applications. Once we are closer to 2.11, we'll be able to determine if this should be disabled by default because it causes more issues than it prevents.
Second, this feature will remain configurable; if disabled, then upon injection the proxy container will not be made the first container in the pod manifest. This is important for the reasons discussed with @electrical about tools that make assumptions about app containers being the first container. For example, Rancher defaults to showing overview pages for the `0` index container, and if the proxy container was always `0` then this would defeat the purpose of the overview page.
### Testing
To test this I used the `sleep.sh` script and changed `Dockerfile-proxy` to use it as it's `ENTRYPOINT`. This forces the container to sleep for 20 seconds before starting the proxy.
---
`sleep.sh`:
```bash
#!/bin/bash
echo "sleeping..."
sleep 20
/usr/bin/linkerd2-proxy-run
```
`Dockerfile-proxy`:
```textile
...
COPY sleep.sh /sleep.sh
RUN ["chmod", "+x", "/sleep.sh"]
ENTRYPOINT ["/sleep.sh"]
```
---
```bash
# Build and install with the above changes
$ bin/docker-build
...
$ bin/image-load --k3d
...
$ bin/linkerd install |kubectl apply -f -
```
Annotate the `emoji` deployment so that it's the only workload that should wait for it's proxy to be ready and inject it:
```bash
cat emojivoto.yaml |bin/linkerd inject - |kubectl apply -f -
```
You can then see that the `emoji` deployment is not starting its application container until the proxy is ready:
```bash
$ kubectl get -n emojivoto pods
NAME READY STATUS RESTARTS AGE
voting-ff4c54b8d-sjlnz 1/2 Running 0 9s
emoji-f985459b4-7mkzt 0/2 PodInitializing 0 9s
web-5f86686c4d-djzrz 1/2 Running 0 9s
vote-bot-6d7677bb68-mv452 1/2 Running 0 9s
```
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Remove the `linkerd-controller` pod
Now that we got rid of the `Version` API (#6000) and the destination API forwarding business in `linkerd-controller` (#5993), we can get rid of the `linkerd-controller` pod.
## Removals
- Deleted everything under `/controller/api/public` and `/controller/cmd/public-api`.
- Moved `/controller/api/public/test_helper.go` to `/controller/api/destination/test_helper.go` because those are really utils for destination testing. I also extracted from there the prometheus mock structs and put that under `/pkg/prometheus/test_helper.go`, which is now by both the `linkerd diagnostics endpoints` and the `metrics-api` tests, removing some duplication.
- Deleted the `controller.yaml` and `controller-rbac.yaml` helm templates along with the `publicAPIResources` and `publicAPIProxyResources` helm values.
## Health checks
- Removed the `can initialize the client` check given such client is no longer needed. The `linkerd-api` section was left with only the check `control pods are ready`, so I moved that under the `linkerd-existence` section and got rid of the `linkerd-api` section altogether.
- In that same `linkerd-existence` section, got rid of the `controller pod is running` check.
## Other changes
- Fixed the Control Plane section of the dashboard, taking account the disappearance of `linkerd-controller` and previously, of `linkerd-sp-validator`.
* Removed `Version` API from the public-api
This is a sibling PR to #5993, and it's the second step towards removing the `linkerd-controller` pod.
This one deals with a replacement for the `Version` API, fetching instead the `linkerd-config` CM and retrieving the `LinkerdVersion` value.
## Changes to the public-api
- Removal of the `publicPb.ApiClient` entry from the `Client` interface
- Removal of the `publicPb.ApiServer` entry from the `Server` interface
- Removal of the `Version` and related methods from `client.go`, `grpc_server.go` and `http_server.go`
## Changes to `linkerd version`
- Removal of all references to the public API.
- Call `healthcheck.GetServerVersion` to retrieve the version
## Changes to `linkerd check`
- Removal of the "can query the control API" check from the "linkerd-api" section
- Addition of a new "can retrieve the control plane version" check under the "control-plane-version" section
## Changes to `linkerd-web`
- The version is now retrieved from the `linkerd-config` CM instead of a public-API call.
- Removal of all references to the public API.
- Removal of the `data-go-version` global attribute on the dashboard, which wasn't being used.
## Other changes
- Added `ValuesFromConfigMap` function in `values.go` to convert the `linkerd-config` CM into a `*Values` struct instance
- Removal of the `public` protobuf
- Refactor 'linkerd repair' to use the refactored 'healthcheck.GetServerVersion()' function
* Removed Destination's `Get` API from the public-api
This is the first step towards removing the `linkerd-controller` pod. It deals with removing the Destination `Get` http and gRPC endpoint it exposes, that only the `linkerd diagnostics endpoints` is consuming.
Removed all references to Destination in the public-api, including all the gRPC-to-http-to-gRPC forwardings:
- Removed the `Get` method from the public-api gRPC server that forwarded the connection from the controller pod to the destination pod. Clients should now connect directly to the destination service via gRPC.
- Likewise, removed the destination boilerplate in the public-api http server (and its `main.go`) that served the `Get` destination endpoint and forwarded it into the gRPC server.
- Finally, removed the destination boilerplate from the public-api's `client.go` that created a client connecting to the http API.
* Move `sp-validator` into the `destination` pod
Fixes#5195
The webhook secrets remain the same, as do the `profileValidator` settings in `values.yaml`, so this doesn't pose any upgrading challenges.
Fixes#5994
When running an uninstall command for Linkerd or a Linkerd extension and there are no resources to delete the command silently exits and prints no output. This can be confusing.
We update the uninstall commands to print an error message to stderr if there are no resources to delete. Since this message is printed to stderr instead of stdout, it does not interfere with piping the output to kubectl.
```console
> linkerd viz uninstall | kubectl delete -f -
No resources found to uninstall
No resources found
```
Signed-off-by: Alex Leong <alex@buoyant.io>
Failing core checks weren't appropriately showing the hint anchor:
```console
control-plane-version
---------------------
‼ control plane is up-to-date
is running version 21.3.4 but the latest edge version is 21.4.3
see l5d-version-control for hints
```
This change replaces all the manually-created healthcheck categories and
instead uses the `NewCategory()` constructor that correctly sets the
hint anchor default. This constructor returns a reference instead of a
value, so other places had to be updated accordingly.
* trafficsplit: Support v1alpha2 version
This PR updates the TrafficSplit CRD to add the `v1alpha2` version
which changes the `weight` field from `resource.Quantity` into
integer.
Our Initial approach to fixing this, was to switch all the types in
the code repo to be `v1alpha2`. This was complex because switching
from resource.Quantity to integer means that a conversion webhook
would be needed to support existing users and not break stuff in
clusters.
Instead of changing all golang TrafficSplit types to `v1alpha2`, This
PR tries to do it differently i.e Keep using `storage` version and
all the types in destination as `v1alpha1` and make k8s convert `v1alpha2`
resources into `v1alpha1`. This works because `v1alpha1`'s `weight` field
is `resource.Quantity` which also covers normal integers
(which is in v1alpha2). By keeping all the internal types to still use
`v1lapha1`, we can essentially support both types without having to write
conversion webhooks. The obv trade-off here is that we are essentially
not moving away from `v1alpha1` in the code repository.
Because with TrafficSplit, The proportions matter more than the exact digits
we are not loosing any type of precision when converting from a `integer`
into `resource.Quantity`. So, With this change, The following TrafficSplit
resource should work.
```yaml
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: reviews-rollout
spec:
service: reviews
backends:
- service: reviews-v2
weight: 50
- service: reviews-v3
weight: 50
```
This PR also updates the trafficsplit integration test to do the same
for both v1alpha1 and v1alpha2.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
Currently, We do not support `matches` field in the TrafficSplit
CRD. This seems to be mistakenly added when OpenAPIV3 Validation
support was added.
This PR updates the TrafficSplit CRD to remove that field, while
also updating the golden test files.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
* cli: restrict repair cmd with the same server version
Fixes#5917
Currently, When a repair cmd is ran with a CLI that is different
from the server version. This means it is possible for the cmd
to fail as the `Values` struct changes between versions.
This PR updates the cmd to restrict it to the version that the
server is on, but as the repair cmd is available only on `2.9.4`
- we fall back to an upgrade suggestion for all versions <= 2.8.1
- Suggest to use `2.9.4` for all `2.9.*` versions
- Suggest the same version for everything else
We also support `--force` flag when users want to skip this
restriction.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
* cli: make inject add the right annotation with `--ingress`
Currently, When `--ingress` flag is used with inject. The
CLI is not setting `linkerd.io/inject: ingress`. Instead,
we get a `linkerd.io/inject: enabled`.
This is because we are setting the annotation to `ingress` in
`getOverrideAnnotations` which is being overridden to `enabled`
later in the inject pipeline at `transform`. This PR updates
the `transform` to only add the `enabled` annotation if its
not ingress mode injection.
After this change:
```bash
./bin/go-run cli inject 005f4facb3/shell.yaml --ingress --proxy-cpu-limit 50m
github.com/linkerd/linkerd2/cli/cmd
github.com/linkerd/linkerd2/cli
apiVersion: v1
kind: Pod
metadata:
annotations:
config.linkerd.io/proxy-cpu-limit: 50m
linkerd.io/inject: ingress
name: shell-demo
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: shared-data
dnsPolicy: Default
volumes:
- emptyDir: {}
name: shared-data
---
pod "shell-demo" injected
```
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
* Schedule heartbeat 10 mins after install
... for the Helm installation method, thus aligning it with the CLI
installation method, to reduce the midnight peak on the receiving end.
The logic added into the chart is now reused by the CLI as well.
Also, set `concurrencyPolicy=Replace` so that when a job fails and it's
retried, the retries get canceled when the next scheduled job is triggered.
Finally, the go client only failed when the connection failed;
successful connections with a non 200 response status were considered
successful and thus the job wasn't retried. Fixed that as well.
### What
When a namespace has the opaque ports annotation, pods and services should
inherit it if they do not have one themselves. Currently, services do this but
pods do not. This can lead to surprising behavior where services are correctly
marked as opaque, but pods are not.
This changes the proxy-injector so that it now passes down the opaque ports
annotation to pods from their namespace if they do not have their own annotation
set. Closes#5736.
### How
The proxy-injector webhook receives admission requests for pods and services.
Regardless of the resource kind, it now checks if the resource should inherit
the opaque ports annotation from its namespace. It should inherit it if the
namespace has the annotation but the resource does not.
If the resource should inherit the annotation, the webhook creates an annotation
patch which is only responsible for adding the opaque ports annotation.
After generating the annotation patch, it checks if the resource is injectable.
From here there are a few scenarios:
1. If no annotation patch was created and the resource is not injectable, then
admit the request with no changes. Examples of this are services with no OP
annotation and inject-disabled pods with no OP annotation.
2. If the resource is a pod and it is injectable, create a patch that includes
the proxy and proxy-init containers—as well as any other annotations and
labels.
3. The above two scenarios lead to a patch being generated at this point, so no
matter the resource the patch is returned.
### UI changes
Resources are now reported to either be "injected", "skipped", or "annotated".
The first pass at this PR worked around the fact that injection reports consider
services and namespaces injectable. This is not accurate because they don't have
pod templates that could be injected; they can however be annotated.
To fix this, an injection report now considers resources "annotatable" and uses
this to clean up some logic in the `inject` command, as well as avoid a more
complex proxy-injector webhook.
What's cool about this is it fixes some `inject` command output that would label
resources as "injected" when they were not even mutated. For example, namespaces
were always reported as being injected even if annotations were not added. Now,
it will properly report that a namespace has been "annotated" or "skipped".
### Tests
For testing, unit tests and integration tests have been added. Manual testing
can be done by installing linkerd with `debug` controller log levels, and
tailing the proxy-injector's app container when creating pods or services.
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* checks: make hintBaseURL configurable
Fixes#5740
Currently, When external binaries use the `healthcheck` pkg, They
can't really override the `hintBaseURL` variable which is used
to set the baseURL of the troubleshooting doc (in which hintAnchor
is used as a anchor).
This PR updates that by adding a new `hintBaseURL` field to
`healthcheck.Category`. This field has been added to `Category`
instead of `Checker` so as to reduce unecessary redundancy as
the chances of setting a different baseURL for checkers under
the same category is very low.
This PR also updates the `runChecks` logic to automatically fallback
onto the linkerd troubleshooting doc as the baseURL so that all
the current checks don't have to set this field. This can be done
otherwise (i.e removing the fallback logic and make all categories
specify the URL) if there is a problem.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
Oliver Gould
Tarun Pothulapati
Alex Leong
LiuDui
Alejandro Pedraza
Gerald Pape
Jason Morgan
rdileep13
Dennis Adjei-Baah
dependabot[bot]
Miguel Ángel Pastor Olivar
Matei David
Josh Soref
Dominik Münch
Kevin Leimkuhler