Bump linkerd-cni to v1.5.2 (linkerd#13198)

This release fixes the issue that when the node had hit the inotify limit, deploying the linkerd-cni daemonset would silently fail. Now the problem is caught and the pod enters a crash loop until the limit is no longer surpassed.

proxy: v2.257.0 (linkerd#13158)

Release notes: https://github.com/linkerd/linkerd2-proxy/releases/tag/release/v2.257.0

Signed-off-by: l5d-bot <l5d-bot@users.noreply.github.com>
Co-authored-by: l5d-bot <l5d-bot@users.noreply.github.com>

Implement providing configuration for TCP_USER_TIMEOUT to linkerd-pro…

…xy (linkerd#13024)

Default values for 30s will be enough to linux TCP-stack completes about 7 packages retransmissions, after about 7 retransmissions RTO (retransmission timeout) will rapidly grows and does not make much sense to wait for too long.

Setting TCP_USER_TIMEOUT between linkerd-proxy and wild world is enough, since connections to containers in same pod are more stable and reliable

Fixes linkerd#13023

Signed-off-by: UsingCoding <extendedmoment@outlook.com>

build(deps): bump actions/checkout from 4.1.7 to 4.2.0 (linkerd#13104)

Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.7 to 4.2.0.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@692973e...d632683)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

proxy: v2.253.0 (linkerd#13060)

Release notes: https://github.com/linkerd/linkerd2-proxy/releases/tag/release/v2.253.0

Signed-off-by: l5d-bot <l5d-bot@users.noreply.github.com>
Co-authored-by: l5d-bot <l5d-bot@users.noreply.github.com>

Allow configuring externalTrafficPolicy (linkerd#13016)

The linkerd-multicluster helm chart does not allow changing the externalTrafficPolicy of the linkerd-gateway Service

Add serviceExternalTrafficPolicy to allow changing the value in the deployed service if needed.

Deploying the linkerd-multicluster chart with "serviceExternalTrafficPolicy: Local" will make the Service to be deployed with `externalTrafficPolicy: Local`

Fixes linkerd#13015

Signed-off-by: Lauri Kuittinen <lauriku@gmail.com>

build(deps): bump mio from 1.0.1 to 1.0.2 (linkerd#13001)

Bumps [mio](https://github.com/tokio-rs/mio) from 1.0.1 to 1.0.2.
- [Release notes](https://github.com/tokio-rs/mio/releases)
- [Changelog](https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md)
- [Commits](tokio-rs/mio@v1.0.1...v1.0.2)

---
updated-dependencies:
- dependency-name: mio
  dependency-type: indirect
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Only bind to IPv6 addresses when disableIPv6=false (linkerd#12938)

## Problem

When the IPv6 stack in Linux is disabled, the proxy will crash at startup.

## Repro

In a Linux machine, disable IPv6 networking through the `net.ipv6.conf.*` sysctl kernel tunables, and restart the system:

- In /etc/sysctl.conf add:
```
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
```

- In /etc/default/grub set:
```
GRUB_CMDLINE_LINUX="ipv6.disable=1"
```

- Don't forget to update grub before rebooting:
```
sudo update-grub
```

In a default k3d cluster, install Linkerd. You should see the following error in any proxy log:

```
thread 'main' panicked at /__w/linkerd2-proxy/linkerd2-proxy/linkerd/app/src/lib.rs:245:14:
Failed to bind inbound listener: Os { code: 97, kind: Uncategorized, message: "Address family not supported by protocol" }
```

## Cause

Even if a k8s cluster didn't support IPv6, we were counting on the nodes having an IPv6 stack, which allowed us to bind to the inbound proxy to [::] (although not to [::1] for the outbound proxy, as seen in GKE). This was the case in the major cloud providers we tested, but it turns out there are folks running nodes with IPv6 disabled and so we have to cater that case as well.

## Fix

The current change undoes some of the changes from 7cbe2f5 (for the proxy config), 7cbe2f5 (for the policy controller) and 6603409 (for linkerd-cni), binding back again to 0.0.0.0 unless `disableIPv6` is false.

Only bind to IPv6 addresses when disableIPv6=false (linkerd#12938)

## Problem

When the IPv6 stack in Linux is disabled, the proxy will crash at startup.

## Repro

In a Linux machine, disable IPv6 networking through the `net.ipv6.conf.*` sysctl kernel tunables, and restart the system:

- In /etc/sysctl.conf add:
```
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
```

- In /etc/default/grub set:
```
GRUB_CMDLINE_LINUX="ipv6.disable=1"
```

- Don't forget to update grub before rebooting:
```
sudo update-grub
```

In a default k3d cluster, install Linkerd. You should see the following error in any proxy log:

```
thread 'main' panicked at /__w/linkerd2-proxy/linkerd2-proxy/linkerd/app/src/lib.rs:245:14:
Failed to bind inbound listener: Os { code: 97, kind: Uncategorized, message: "Address family not supported by protocol" }
```

## Cause

Even if a k8s cluster didn't support IPv6, we were counting on the nodes having an IPv6 stack, which allowed us to bind to the inbound proxy to [::] (although not to [::1] for the outbound proxy, as seen in GKE). This was the case in the major cloud providers we tested, but it turns out there are folks running nodes with IPv6 disabled and so we have to cater that case as well.

## Fix

The current change undoes some of the changes from 7cbe2f5 (for the proxy config), 7cbe2f5 (for the policy controller) and 6603409 (for linkerd-cni), binding back again to 0.0.0.0 unless `disableIPv6` is false.

add status message when attempting to attach to headless service (lin…

…kerd#12918)

If the `parent_ref` of an HTTPRoute resource is set to a headless service, the policy controller gives the HTTPRoute a status of NoMatchingParent:

```
  - conditions:
    - lastTransitionTime: "2024-07-30T22:52:24Z"
      message: ""
      reason: NoMatchingParent
      status: "False"
      type: Accepted
```

However, this can be misleading because the parent does exist, but is not a valid parent because it does not have a cluster IP.

We make this error easier to understand by adding a message to the status condition in this case:

```
    - lastTransitionTime: "2024-07-30T22:51:29Z"
      message: parent service must have a ClusterIP
      reason: NoMatchingParent
      status: "False"
      type: Accepted
```

Signed-off-by: Alex Leong <alex@buoyant.io>