With #5835 adding `linkerd-await` in most Dockerfiles we require
`TARGETARCH` to be set by the system, which is only available in the
BuildKit backend. Thus we drop support for plain vanilla docker and
remove all references to `DOCKER_BUILDKIT`. The developer docs are being
updated accordingly in #5869
This release fixes several stability issues identified in pre-release
testing:
* linkerd/linkerd2#5871 reported that the outbound proxy would not tear
down client connections when communicating with a defunct endpoint
(especially when communicating with headless services).
Now, dispatch timeouts trigger serverside connection teardown so that
clients have an opportunity to re-resolve the destination.
* The ingress-mode outbound proxy did not properly share load balancers
for connections targeting multiple endpoints in the same logical
service. Now, when the l5d-dst-override header is set, the
ingress-mode proxy correctly reuses load balancers independently of
the original destination address.
* The proxy's server could panic when `accept(2)` returned an error.
This case is now handled gracefully and logged as a warning.
* The inbound proxy included a redundant cache that has been removed.
* Diagnostic logging has been improved, especially for TCP forwarding.
---
* ingress: Instrument outbound TCP metrics (linkerd/linkerd2-proxy#933)
* inbound: Remove unnecessary connection stack cache (linkerd/linkerd2-proxy#934)
* outbound: Simplify Endpoint type (linkerd/linkerd2-proxy#935)
* outbound: Use the OrigDstAddr type in stack targets (linkerd/linkerd2-proxy#936)
* outbound: Decouple the resolver from concrete target types (linkerd/linkerd2-proxy#938)
* errors: always teardown connections on errors (linkerd/linkerd2-proxy#939)
* http: Parameterize header module (linkerd/linkerd2-proxy#941)
* duplex: include src/dst peer in logs (linkerd/linkerd2-proxy#937)
* Make stack trace initialization lazy (linkerd/linkerd2-proxy#940)
* outbound: Mock the original destination address in ingress-mode (linkerd/linkerd2-proxy#942)
* Prevent server errors from panicking the proxy (linkerd/linkerd2-proxy#943)
@dadjeibaah [pointed
out](https://github.com/linkerd/website/pull/972#discussion_r588584786)
while reviewing the [Enabling Tap
access](https://linkerd.io/2/tasks/securing-your-cluster/#enabling-tap-access)
doc that granting the `linkerd-linkerd-viz-tap` ClusterRole to a user
is no longer enough for tapping, as namespace listing is now also
required:
```console
$ linkerd viz tap -n linkerd deploy/linkerd-controller --as $(whoami)
Cannot connect to Linkerd Viz: namespaces is forbidden: User "dennis" cannot list resource "namespaces" in API group "" at the cluster scope
Validate the install with: linkerd viz check
```
Adding the Namespace List privilege to that CR solves the issue.
Reenabled the `upgrade-test` and `cni-calico-deep` tracing integration tests. The former was disabled because in edge-21.2.4 the viz install wasn't waiting for the core components to be ready, and the latter was disabled because the `jaeger-webhook` image couldn't be loaded.
The reason simply was disk pressure, as evidenced by the k8s events. The fix consisted on adding a `--cleanup-docker` option to `bin/tests` which deletes the `image-archives` dir and the docker cache after the images have been loaded into k3d. That option is enacted only in the `integration_tests.yml` workflow in the deep tests, which are the ones pulling the most images.
The `release.yml` workflow doesn't require it since it pulls the images directly from the public registry.
This PR updates hint anchors to the correct fields matching
with the anchors in `linkerd2/troubleshooting`.
The plan is to keep this PR update with the changes being
done in https://github.com/linkerd/website/pull/947
and merge only after that PR is merged.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
* tests: Add TestOverridesSecret integration test
Fixes#5670
This PR adds a new test under install tests called
`TestOverridesSecret` which reads the overrides secret
stored in the cluster and then checks if the relevant overrides
that are passed through helm override flags and CLi flags
are present or not.
Currently, Helm overrides flags are only available with the
edge releases and hence these flags are gated based on the version
in the install logic.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
Co-authored-by: Alejandro Pedraza <alejandro@buoyant.io>
This change fixes an issue where the `linkerd-sp-validator` does not set
the `request.UID` for an `admissionResponse`. This causes an issue that
prevents service profiles from being added or updated.
Fixes#5862
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
* edge-21.3.1 change notes
## edge-21.3.1
This edge release is another release candidate, bringing us closer to
`stable-2.10.0`! It fixes the Helm install/upgrade procedure and ships some new
CLI commands, among other improvements.
* Fixed Helm install/upgrade, which was failing when not explicitly setting
`proxy.image.version`
* Added a warning in the dashboard when viewing tap streams from resources that
don't have tap enabled
* Added the command `linkerd viz list` to list meshed pods and indicate which can
be tapped, which need to be restarted before they can be tapped, and which
have tap disabled
* Similarly, added the command `linkerd jaeger list` to list meshed pods and
indicate which will participate in tracing
* Added the `--opaque-ports` flag to `linkerd inject` to specify the list of
opaque ports when injecting pods (and services)
* Simplified the output of `linkerd jaeger check`, combining the checks for the
status of each component into a single check
* Changed the destination component to receive the list of default opaque ports
set during install so that it's properly reflected during discovery
* Moved the level of the proxy server's I/O-related "Connection closed" messages
from info to debug, which were not providing actionable information
Co-authored-by: Oliver Gould <ver@buoyant.io>
Co-authored-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Warn users about missing tap configuration
This change modifies the dashboard so that it stops displaying an error
message when viewing tap streams from resources that don't have tap
enabled and instead, shows a warning and also guides the user on what to
do to fix it.
This change also includes updating the `<ExpansionPanel>` component
since we were getting deprecation warnings from Material-UI. The
component has been renamed to an accordion.
Fixes#5831
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
- Get rid of all the custom settings passed through `--set` during `helm install`, and instead let the defaults mechanisms in the templates to kick-in
- Before installing `linkerd-viz` through Helm, wait on _all_ the core components to be ready (this is what might have been causing the restarts seen in CI)
- Show full output when `linkerd jaeger check` fails, and do some cleanup before triggering the tracing tests. But then I decided to temporarily disable that test till we figure out what's the deal.
Continuation of https://github.com/linkerd/linkerd2/pull/5721/
The `config.linkerd.io/opaque-ports` annotation can now be set using the `--opaque-ports` flag on `inject`
Example
```bash
$ linkerd inject /path/to/manifest.yaml --opaque-ports 3000,5000-6000,mysql
```
This annotation is the only one which is applied to services.
Signed-off-by: Alex Leong <alex@buoyant.io>
Co-authored-by: Mayank Shah <mayankshah1614@gmail.com>
The proxy would log 'Connection closed' messages at the INFO level in
benign/innocuous situations where these logs create more concern than
they provide actionable information.
This release updates the proxy server to log I/O errors at the DEBUG
level. Other errors, like TLS detetion timeouts, continue to be logged
at INFO.
---
* server: Log connection closed messages at DEBUG (linkerd/linkerd2-proxy#931)
* server: Log non-i/o errors at INFO (linkerd/linkerd2-proxy#932)
This PR combines the induvidual checks that check for each deployment
in running into a single check which checks for `running` status
for all the known deployments in the jaeger extension namespace.
This follows the same pattern as other extensions.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
* Move CP check after the readiness check
Moved the `can initialize client` and `can query the control plane API`
checks from the `linkerd-existence` section to the `linkerd-api` because
they required the `linkerd-controller` pod to not just be "Running" but
actually be ready.
This was causing `linkerd check` to show some port-forwarding warnings
when ran right after install.
This also allowed getting rid of the `CheckPublicAPIClientOrExit` function
and directly use `CheckPublicAPIClientOrRetryOrExit` (better naming
punted for later) which was refactored so it always runs the
`linkerd-api` checks before retrieving the client.
Other changes:
- Temporarily disabled `upgrade-edge` test because the latest edge has this readiness check issue
- Have the upgrade tests do proper pruning (stolen for @Pothulapati's #5673😉 )
- Added missing label to tap SA (fixes#5850)
- Complete tap-injector Service selector
Pods can only participate in tracing if they have been injected by the jaeger-injector. Similarly, pods may only be tapped if they have been injected by the tap-injector. Since pods which were already running when the injector starts will not be injected until those pods are restarted, it can be difficult to know which pods in your cluster will participate in tracing or be valid tap targets.
We add the command `linkerd viz list` to list meshed pods and indicate which can be tapped, which need to be restarted before they can be tapped, and which have tap disabled.
```console
> linkerd viz list -A
Pods with tap enabled:
* collector-7f585dc68-z8vc8.linkerd-jaeger
* jaeger-69fc767648-mxtc4.linkerd-jaeger
* jaeger-injector-67fbccc487-sjh4c.linkerd-jaeger
* grafana-84c9b569b9-27qsj.linkerd-viz
* metrics-api-6c956b4b58-5xvz8.linkerd-viz
* prometheus-7fdb866467-s4q5m.linkerd-viz
* tap-768b5ddc6c-hdfb2.linkerd-viz
* tap-injector-ff446c479-4wtsm.linkerd-viz
* web-5f79854c4f-lpv5l.linkerd-viz
Pods missing tap configuration (restart these pods to enable tap):
* linkerd-gateway-777b7cb9bf-7fr2n.linkerd-multicluster
* linkerd-controller-6864cf5f8c-bxp7l.linkerd
* linkerd-destination-67499b8df7-fqqb9.linkerd
* linkerd-identity-7c577f7454-c2v7r.linkerd
* linkerd-proxy-injector-c7844b9f6-hwbsm.linkerd
* linkerd-sp-validator-f4c8cc6d6-658tb.linkerd
```
Similarly, we add the command `linkerd jaeger list` to list meshed pods and indicate which will participate in tracing.
```console
> linkerd jaeger list -A
Pods with tracing enabled:
* grafana-84c9b569b9-27qsj.linkerd-viz
* metrics-api-6c956b4b58-5xvz8.linkerd-viz
* prometheus-7fdb866467-s4q5m.linkerd-viz
* tap-768b5ddc6c-hdfb2.linkerd-viz
* tap-injector-ff446c479-4wtsm.linkerd-viz
* web-5f79854c4f-lpv5l.linkerd-viz
Pods missing tracing configuration (restart these pods to enable tracing):
* collector-7f585dc68-z8vc8.linkerd-jaeger
* jaeger-69fc767648-mxtc4.linkerd-jaeger
* jaeger-injector-67fbccc487-sjh4c.linkerd-jaeger
* linkerd-gateway-777b7cb9bf-7fr2n.linkerd-multicluster
* linkerd-controller-6864cf5f8c-bxp7l.linkerd
* linkerd-destination-67499b8df7-fqqb9.linkerd
* linkerd-identity-7c577f7454-c2v7r.linkerd
* linkerd-proxy-injector-c7844b9f6-hwbsm.linkerd
* linkerd-sp-validator-f4c8cc6d6-658tb.linkerd
```
This commands list pods in the context's default namespcae by default, but can be configured with the usual `-n` and `-A` flags.
This replaces the jaeger extension's data plane check which gave a warning if there were pods with tracing. That check has been removed here.
Signed-off-by: Alex Leong <alex@buoyant.io>
In #5694 we set many Helm values to empty (like version tags), and then the
templates became responsible to filling out to proper default values. We missed
doing that for the `linkerd.io/proxy-version` annotation built in the
`_metadata.tpl` template. This fixes that, and also stops setting
`proxy.image.version` in `helm install|upgrade` in the Helm integration tests,
which is what avoided catching this error .
* destination: pass opaque-ports through cmd flag
Fixes#5817
Currently, Default opaque ports are stored at two places i.e
`Values.yaml` and also at `opaqueports/defaults.go`. As these
ports are used only in destination, We can instead pass these
values as a cmd flag for destination component from Values.yaml
and remove defaultPorts in `defaults.go`.
This means that users if they override `Values.yaml`'s opauePorts
field, That change is propogated both for injection and also
discovery like expected.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
When introducing the `linkerd-await` helper, we provided a default value
for `TARGETARCH`. This appears to interfere with multi-arch image
builds, causing ARM builds to fetch amd64 binaries.
Unsetting this default appears to fix this issue.
## edge 21.2.4
This edge is a release candidate for `stable-2.10.0`! It wraps up the functional
changes planned for the upcoming stable release. We hope you can help us test
this in your staging clusters so that we can address anything unexpected before
an official stable.
This release introduces support for CLI extensions. The Linkerd `check` command
will now invoke each extension's `check` command so that users can check the
health of their Linkerd installation and extensions with one command. Additional
documentation will follow for developers interested in creating extensions.
Additionally, there is no longer a default list of ports skipped by the proxy.
These ports have been moved to opaque ports, meaning protocols like MySQL will
be encrypted by default and without user input.
* Cleaned up entries in `values.yaml` by removing `do not edit` entries; they
are now hardcoded in the templates
* Added the count of service profiles installed in a cluster to the Heartbeat
metrics
* Fixed CLI commands which would unnecessarily print usage instructions after
encountering API errors (thanks @piyushsingariya!)
* Fixed the `install` command so that it errors after detecting there is an
existing Linkerd installation in the cluster
* Changed the identity controller to receive the trust anchor via environment
variable instead of by flag; this allows the certificate to be loaded from a
config map or secret (thanks @mgoltzsche!)
* Updated the proxy to use TLS version 1.3; support for TLS 1.2 remains enabled
for compatibility with prior proxy versions
* The opaque ports annotation is now supported on services and enables users to
use this annotation on mirrored services in multicluster installations
* Reverted the renaming of the `mirror.linkerd.io` label
* Ports `25,443,587,3306,5432,11211` have been removed from the default skip
ports; all traffic through those ports is now proxied and handled opaquely by
default
* Errors configuring the firewall in CNI are propagated so that they can be
handled by the user
* Removed Viz extension warnings from the `check --proxy` command when tap is
not configured for pods; this is now handled by the `viz tap` command
* Added support for CLI extensions as well as ensuring their `check` commands
are invoked by Linkerd's `check` command
* Moved the `metrics`, `endpoints`, and `install-sp` commands into subcommands
under the `diagnostics` command.
* Removed the `linkerd-` prefix from non-cluster scoped resources in the Viz and
Jaeger extensions
* Added the linkerd-await helper to all Linkerd containers so that the proxy can
initialize before the components start making outbound connections
* Removed the `tcp_connection_duration_ms` histogram from the metrics export to
fix high cardinality issues that surfaced through high memory usage
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
This change removes the `tcp_connection_duration_ms` histogram from
metrics export. This metric can end up being extremely high-cardinality
without providing much value.
Furthermore, an issue was fixed that prevented some modules from being
able to update their log level dynamically.
---
* trace: set `log` global max level when reloading (linkerd/linkerd2-proxy#928)
* detect: Surface timeouts to inner stack (linkerd/linkerd2-proxy#929)
* Remove the tcp_connection_duration_ms histogram (linkerd/linkerd2-proxy#930)
When a container starts up, we generally want to wait for the proxy to
initialize before starting the controller (which may initiate outbound
connections, especially to the Kubernetes API). This is true for all
pods except the identity controller, which must start before its proxy.
This change adds the linkerd-await helper to all of our container
images. Its use is explicitly disabled in the identity controller, due
to startup ordering constraints, and the heartbeat controller, because
it does not run a proxy currently.
Fixes#5819
Update day of the week in which community meetings take place
Community meeting was indicating Wednesdays on the repository while the
meetings are actually taking place on Thursdays.
Signed-off-by: Rodrigo Broggi <ro_broggi@hotmail.com>
* Remove linkerd prefix from extension resources
This change removes the `linkerd-` prefix on all non-cluster resources
in the jaeger and viz linkerd extensions. Removing the prefix makes all
linkerd extensions consistent in their naming.
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
* cli: reorganise diagnostics subcommand
Fixes#5192, #5193
This PR moves `metrics`, `diagnostics`(which prints out metrics of
control-plane components), `endpoints` and `install-sp` into a new `diagnostics`
subcommand.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
As described in https://github.com/linkerd/linkerd2/pull/5692, this PR adds support for CLI extensions.
Calling `linkerd foo` (if `foo` is not an existing Linkerd command) will now search the current PATH for an executable named `linkerd-foo` and invoke it with the current arguments.
* All arguments and flags will be passed to the extension command
* The Linkerd command itself will not process any flags
* To simplify parsing, flags are not allowed before the extension name
e.g. with an executable called `linkerd-foo` on my PATH:
```console
> linkerd foo install
Welcome to Linkerd foo!
Got: install
> linkerd foo --context=prod install
Welcome to Linkerd foo!
Got: --context=prod install
> linkerd --context=prod foo install
Cannot accept flags before Linkerd extension name
> linkerd bar install
Error: unknown command "bar" for "linkerd"
Run 'linkerd --help' for usage.
```
We also update `linkerd check` to invoke `linkerd <extension> check` for each extension found installed on the current cluster. A check warning is emitted if the extension command is not found on the path.
e.g. with both `linkerd.io/extension=foo` and `linkerd.io/extension=bar` extensions installed on the cluster:
```console
> linkerd check
[...]
Linkerd extensions checks
=========================
Welcome to Linkerd foo!
Got: check --as-group=[] --cni-namespace=linkerd-cni --help=false --linkerd-cni-enabled=false --linkerd-namespace=linkerd --output=table --pre=false --proxy=false --verbose=false --wait=5m0s
linkerd-bar
-----------
‼ Linkerd extension command linkerd-bar exists
Status check results are ‼
```
Signed-off-by: Alex Leong <alex@buoyant.io>
This change removes the default ignored inbound and outbound ports from the
proxy init configuration.
These ports have been moved to the the `proxy.opaquePorts` configuration so that
by default, installations will proxy all traffic on these ports opaquely.
Closes#5571Closes#5595
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
Fixes https://github.com/linkerd/linkerd2/discussions/5777
When a user runs `linkerd viz check --proxy`, it will print a warning if there are any proxies which cannot be tapped. This is a normal state of affairs after freshly installing the linkerd-viz extensions because any existing pods will need to be restarted before they can be tapped. The check warning may lead users to falsely believe that something has gone wrong with their installation.
We remove this specific check from `linkerd viz check --proxy`. To replace it, we improve the error output when attempting to tap a resource which is not tappable. This gives the user actionable feedback when the tap command fails.
Old:
```console
> linkerd viz tap -n emojivoto deploy/vote-bot
no pods to tap for deployment/vote-bot
```
New:
```console
> linkerd viz tap -n emojivoto deploy/vote-bot
no pods to tap for deployment/vote-bot
1 pods found with tap not enabled:
* vote-bot-64dd87cb87-7mcv4
restart these pods to enable tap and make them valid tap targets
```
Signed-off-by: Alex Leong <alex@buoyant.io>
This change adds error propagation for the CNI's ADD command so that any failures in the `ConfigureFirewall` function to configure the Pod's iptables can be bubbled up to be logged and handled.
Fixes#5809
Signed-off-by: Frank Gu <frank@voiceflow.com>
This changes the destination service to always use a default set of opaque ports
for pods and services. This is so that after Linkerd is installed onto a
cluster, users can benefit from common opaque ports without having to annotate
the workloads that serve the applications.
After #5810 merges, the proxy containers will be have the default opaque ports
`25,443,587,3306,5432,11211`. This value on the proxy container does not affect
traffic though; it only configures the proxy.
In order for clients and servers to detect opaque protocols and determine opaque
transports, the pods and services need to have these annotations.
The ports `25,443,587,3306,5432,11211` are now handled opaquely when a pod or
service does not have the opaque ports annotation. If the annotation is present
with a different value, this is used instead of the default. If the annotation
is present but is an empty string, there are no opaque ports for the workload.
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
This reverts commit f9ab867cbc which renamed the
multicluster label name from `mirror.linkerd.io` to `multicluster.linkerd.io`.
While this change was made to follow similar namings in other extensions, it
complicates the multicluster upgrade process due to the secret creation.
`mirror.linkerd.io` is not that important of a label to change and this will
allow a smoother upgrade process for `stable-2.10.x`
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
This change introduces an opaque ports annotation watcher that will send
destination profile updates when a service has its opaque ports annotation
change.
The user facing change introduced by this is that the opaque ports annotation is
now required on services when using the multicluster extension. This is because
the service mirror will create mirrored services in the source cluster, and
destination lookups in the source cluster need to discover that the workloads in
the target cluster are opaque protocols.
### Why
Closes#5650
### How
The destination server now has a new opaque ports annotation watcher. When a
client subscribes to updates for a service name or cluster IP, the `GetProfile`
method creates a profile translator stack that passes updates through resource
adaptors such as: traffic split adaptor, service profile adaptor, and now opaque
ports adaptor.
When the annotation on a service changes, the update is passed through to the
client where the `opaque_protocol` field will either be set to true or false.
A few scenarios to consider are:
- If the annotation is removed from the service, the client should receive
an update with no opaque ports set.
- If the service is deleted, the stream stays open so the client should
receive an update with no opaque ports set.
- If the service has the annotation added, the client should receive that
update.
### Testing
Unit test have been added to the watcher as well as the destination server.
An integration test has been added that tests the opaque port annotation on a
service.
For manual testing, using the destination server scripts is easiest:
```
# install Linkerd
# start the destination server
$ go run controller/cmd/main.go destination -kubeconfig ~/.kube/config
# Create a service or namespace with the annotation and inject it
# get the destination profile for that service and observe the opaque protocol field
$ go run controller/script/destination-client/main.go -method getProfile -path test-svc.default.svc.cluster.local:8080
INFO[0000] fully_qualified_name:"terminus-svc.default.svc.cluster.local" opaque_protocol:true retry_budget:{retry_ratio:0.2 min_retries_per_second:10 ttl:{seconds:10}} dst_overrides:{authority:"terminus-svc.default.svc.cluster.local.:8080" weight:10000}
INFO[0000]
INFO[0000] fully_qualified_name:"terminus-svc.default.svc.cluster.local" opaque_protocol:true retry_budget:{retry_ratio:0.2 min_retries_per_second:10 ttl:{seconds:10}} dst_overrides:{authority:"terminus-svc.default.svc.cluster.local.:8080" weight:10000}
INFO[0000]
```
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
This release updates the proxy to use TLS version 1.3 for proxy-to-proxy
communication. Support for TLS 1.2 remains enabled for compatibility
with prior proxy versions.
This release also includes an update to the `tracing-subscriber`
dependency that may reduce latency and CPU usage.
---
* make proxy builds work on windows (linkerd/linkerd2-proxy#925)
* Add support for TLS v1.3 (linkerd/linkerd2-proxy#926)
* deps: Update `tracing-subscriber` to 0.2.16 (linkerd/linkerd2-proxy#927)
This PR enables the temporarily disabled external-prometheus-deep
integration test. This also fixes the clean up issue by essentially
moving the external-prometheus resources into `external-prometheus`
which has the relevant annotation required to be deleted by
`bin/test-cleanup`
This PR also updates the test resource label to be `test.linkerd.io/is-test-data-plane` from
`linkerd.io/is-test-data-plane` to prevent `linkerd inject` from removing it.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
The CLI binaries are never used inside a cluster so there's no need to
load the cli-bin image.
Also, I always have `LINKERD_LOCAL_BUILD_CLI=1` in my environment to avoid
building that image to begin with (takes more than 80s in my machine
with warm docker dependencies), which caused `bin/image-load` to fail
when it attempted to load it.
Currently the identity controller is the only component that receives the CA certificate / trust anchors as option `-identity-trust-anchors-pem` instead of an env var.
This stops one from letting it read the trust anchors from a Secret that is managed by e.g. cert-manager.
This PR uses an env var instead of the option to provide the trust anchors. For most helm chart users this doesn't change anything. However using kustomize the helm output manifest can now be adjusted (again) so that the certificate is loaded from a ConfigMap or Secret like in [this example](https://github.com/mgoltzsche/khelm/tree/master/example/kpt/linkerd) which aims to produce a static manifest to make the installation/update more declarative and support GitOps workflows.
This PR does not provide chart options/values to specify Secrets upfront - it would introduce dependencies to other operators.
Relates to #3843, see https://github.com/linkerd/linkerd2/issues/3843#issuecomment-775516217Fixes#3321
Signed-off-by: Max Goltzsche <max.goltzsche@gmail.com>
Fixes#5782
`linkerd install` was checking for the existence of the
`linkerd-config-overrides` secret which hasn't been available till
recent versions. Changed this to check for the usual `linkerd-config`
ConfigMap. Uses a straight k8s API call for simplicity.
When running `bin/tests`, if there were linkerd resources already in the cluster an error was thrown, but the offending resources weren't shown.
Before:
```console
$ bin/tests --skip-cluster-create ~/.linkerd2/bin/linkerd
==================RUNNING ALL TESTS==================
Note: cluster-domain, cni-calico-deep and multicluster require a specific cluster configuration and are skipped by default
Checking the linkerd binary...[ok]
Checking if there is a Kubernetes cluster available...[ok]
Checking if Linkerd resources exist on cluster...
Linkerd resources exist on cluster:
/home/alpeb/.linkerd2/bin/linkerd
Help:
Run: [/test-cleanup]
```
After:
```console
$ KUBECONFIG=~/tmp/kubeconfig bin/tests --images skip --skip-cluster-create ~/.linkerd2/bin/linkerd
==================RUNNING ALL TESTS==================
Note: cluster-domain, cni-calico-deep and multicluster require a specific cluster configuration and are skipped by default
Checking the linkerd binary...[ok]
Checking if there is a Kubernetes cluster available...[ok]
Checking if Linkerd resources exist on cluster...
Linkerd resources exist on cluster:
pod/linkerd-identity-6fc8449776-t2vmj
pod/linkerd-proxy-injector-fb4b5ffb7-xdqxh
pod/linkerd-controller-7b9f9d458b-fbhz2
service/linkerd-proxy-injector
service/linkerd-sp-validator
deployment.apps/linkerd-identity
deployment.apps/linkerd-proxy-injector
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-controller
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-destination
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity
validatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-sp-validator-webhook-config
podsecuritypolicy.policy/linkerd-linkerd-control-plane
customresourcedefinition.apiextensions.k8s.io/serviceprofiles.linkerd.io
Help:
Run: [/home/alpeb/.linkerd2/bin/linkerd/test-cleanup]
```
Problem: CLI prints command usage for multiple commands in-case of API errors
Solution: Print the error and the exit using os.Exit(1) to avoid Cobra printing usage
Closes#5058
Signed-off-by: Piyush Singariya piyushsingariya@gmail.com
This change counts the number of service profiles installed in a cluster
and adds that info to the heartbeat HTTP request.
Fixes#5474
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
Fixes#5574 and supersedes #5660
- Removed from all the `values.yaml` files all those "do not edit" entries for annotation/label names, hard-coding them in the templates instead.
- The `values.go` files got simplified as a result.
- The `created-by` annotation was also refactored into a reusable partial. This means we had to add a `partials` dependency to multicluster.
The ARM integration tests are too fragile, given our test
infrastructure. This flakiness is blocking a release.
This change comments out the ARM tests from our release workflow. We
should enable it when we can actually rely on these tests to provide a
meaningful signal.
This release wraps up most of the functional changes planned for the upcoming
`stable-2.10.0` release. Try this edge release in your staging cluster and
let us know if you see anything unexpected!
* **Breaking change**: Changed the multicluster `Service`-export annotation
from `mirror.linkerd.io/exported` to `multicluster.linkerd.io/export`
* Updated the proxy-injector to to set the `config.linkerd.io/opaque-ports`
annotation on newly-created `Service` objects when the annotation is set on
its parent `Namespace`
* Updated the proxy-injector to ignore pods that have disabled
`automountServiceAccountToken` (thanks @jimil749)
* Updated the proxy to log warnings when control plane components are
unresolveable
* Updated the Destination controller to cache node topology metadata (thanks
@fpetkovski)
* Updated the CLI to handle API errors without printing the CLI usage (thanks
@piyushsingariya)
* Updated the Web UI to only display the "Gateway" sidebar link when the
multicluster extension is active
* Fixed the Web UI on Chrome v88 (thanks @kellycampbell)
* Improved `install` and `uninstall` behavior for extensions to prevent
control-plane components from being left in a broken state
* Docker images are now hosted on the `cr.l5d.io` registry
* Updated base docker images to buster-20210208-slim
* Updated the Go version to 1.14.15
* Updated the proxy to prevent outbound connections to localhost to protect
against traffic loops
This renames the multicluster annotation prefix from `mirror.linkerd.io` to
`multicluster.linkerd.io` in order to reflect other extension naming patterns.
Additionally, it moves labels only used in the Multicluster extension into their
own labels file—again to reflect other extensions.
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
This release changes the outbound proxy to fail all connections
to the loopback interface. Such connections should never be proxied in
normal operation. This helps to prevent against traffic loops.
Additionally, the proxy's core dependencies have been updated and
proxy-specific implementations of general features have been replaced by
those in the `tower` crate.
---
* outbound: Prevent connections on the loopback interface (linkerd/linkerd-proxy#924)
* buffer: replace `linkerd-buffer` with `tower::buffer` from upstream (linkerd/linkerd-proxy#922)
* transport: Introduce a Keepalive type (linkerd/linkerd-proxy#923)
* transport: Introduce address new-types (linkerd/linkerd-proxy#921)
* update tracing-futures, rm old pin-project (linkerd/linkerd-proxy#920)
* Move proxy stack initialization into modules (linkerd/linkerd-proxy#915)
* Update dependencies (linkerd/linkerd-proxy#918)
* transport: Replace async-stream with tokio-stream (linkerd/linkerd-proxy#914)
* Re-export stack::Param as svc::Param (linkerd/linkerd-proxy#917)
* Log warnings when controller components do not resolve (linkerd/linkerd-proxy#913)
* channel: use `tokio-util`'s `PollSemaphore` (linkerd/linkerd-proxy#912)
* update Tower to v0.4.5 (linkerd/linkerd-proxy#911)
* Parameterize resolution targets (linkerd/linkerd-proxy#908)
Alejandro Pedraza
Oliver Gould
Kevin Leimkuhler
Tarun Pothulapati
Dennis Adjei-Baah
Alex Leong
Rodrigo Broggi
(Frank) Yu Cheng Gu
Max Goltzsche
Piyush Singariya