kubernetes: enable bpf masqurade and tunnel based routing for tenant clusters - #144

* upd kubernetes (#134)

* Allow root login without password

* add ephemeral volumes for containerd and kubelet

* update kubernetes application

* etcd: Add quota-backend-bytes calculations (#133)

* Prepare release v0.6.0 (#135)

* etcd: enable autocompact and defrag (#137)

Signed-off-by: Andrei Kvapil <[email protected]>

* switched place -maxdepth im Makefiles (#140)

* postgres: fix users and roles (#138)

Signed-off-by: Andrei Kvapil <[email protected]>

* kubernetes: enable bpf masqurade and tunnel routing (#144)

* Unhardcode cluster.local domain (#142)

Allow using other domains for the cluster

Signed-off-by: Andrei Kvapil <[email protected]>

* kamaji: unhardcode cluster.local domain (#145)

Signed-off-by: Andrei Kvapil <[email protected]>

* kubernetes: specify correct dns address (#147)

---------

Signed-off-by: Andrei Kvapil <[email protected]>
Co-authored-by: Andrei Kvapil <[email protected]>

…3045)

## What this PR does

**Problem**

On a loaded install the `monitoring-agents` fluent-bit DaemonSet
crash-loops and its HelmRelease times out (`timeout waiting for:
[DaemonSet/.../monitoring-agents-fluent-bit status: 'InProgress']`),
cascading into velero → backupstrategy-controller `DependencyNotReady`
and failing the whole install.

Root cause: fluent-bit's HTTP server on `:2020` (the liveness/readiness
target) binds only AFTER the `filter:kubernetes` "testing connectivity
with API server" step. During a concurrent install the kube-API can be
unreachable for ~10s (observed `connection #144 timeout after 10 seconds
to: kubernetes.default.svc:443`), which delays the `:2020` bind. The
vendored subchart's default probes (`initialDelaySeconds 0,
timeoutSeconds 1, failureThreshold 3`) fire into a connection-refused
port immediately, and the single-threaded HTTP server can't always meet
a 1s timeout while the engine is busy — so liveness SIGTERMs fluent-bit
(exitCode 0, not OOM) into a restart loop.

**Fix**

Relax both probes in the first-party umbrella `values.yaml`
`fluent-bit:` block: `initialDelaySeconds 15, periodSeconds 10,
timeoutSeconds 5, failureThreshold 6` (~75s tolerance from container
start, ~60s steady-state). The `httpGet` target is unchanged — path `/`
on port `http` (`:2020`). The change is values-only; the vendored
subchart is not touched.

**Why load-triggered (not always-broken)**

A steady-state cluster runs the identical probe config with the
DaemonSet 3/3 Ready, 0 restarts, 26 days. The probe only fails when the
`:2020` bind is delayed by API unreachability under install-time load.
Steady-state-stable + flaky-only-under-load = probe-too-aggressive, not
a target or config error.

**Test**

Added a helm-unittest (`tests/fluent-bit_probes_test.yaml`) pinning both
the relaxed timing and the preserved `:2020` httpGet target (path `/`,
port `http`) on the rendered DaemonSet, so a future change that
re-tightens the probes or breaks the path/port is caught.

### Screenshots

N/A — no UI changes.

### Release note

```release-note
fix(monitoring-agents): relax fluent-bit liveness/readiness probes so the DaemonSet no longer crash-loops on a loaded install when its :2020 HTTP server binds late behind a busy kube-API
```


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Adjusted Fluent Bit health probes to use more relaxed timing, reducing
the chance of restart loops on busy installations.
* Kept the readiness check pointed at the expected HTTP path and port
while making probe behavior more stable.
* **Tests**
* Added test coverage to verify the generated probe configuration stays
consistent.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->