Php K8S Laravel Package

Technical Evaluation

Architecture fit

• php-k8s is a Kubernetes API client, not an application framework component. The Laravel binding that previously shipped with it (service provider + facade + config/k8s.php publishing) was a thin convenience layer over the core client.
• Removing Laravel support makes the package framework-agnostic. That is a reasonable architectural direction for a control-plane client and improves its fit for CLI tools, queue workers, and non-Laravel PHP services in the estate.
• Cost: for a Laravel-first estate we lose container binding, config-driven client construction, and the facade. Those become application-owned code. This is a real, if small, architectural regression for Laravel consumers and must be budgeted as such.

Integration feasibility

• Still feasible and low-effort. Manual construction of the client and a hand-written service provider are on the order of tens of lines. No protocol or auth changes are implied by the notes.
• The ratchet/pawl bump is the only change that touches runtime behavior of long-lived connections (exec, attach, port-forward, log streaming). Treat it as a behavioral change to validate, not a routine dependency refresh.

Technical risk

• Semver violation is the headline risk. "Remove Laravel support" and "Remove PHP 8.2 support" are breaking changes published in a minor release (3.9.0). Any service on ^3.0 will pull this on the next composer update and can fail at bootstrap with a missing provider/facade class. Pin to 3.8.* immediately, before anything else in this assessment is actioned.
• Dropping PHP 8.2 raises the floor (presumably to 8.3). Any service or CI image still on 8.2 cannot take this release at all. Verify the actual composer.json require.php constraint rather than inferring it.
• The ratchet/pawl update is transitive and may pull newer react/* versions, which can conflict with other WebSocket consumers in the same application and can change reconnect/backoff and error-surfacing behavior.
• "Support named parameters in KubernetesCluster functions" implies signature work. If parameter names changed rather than merely becoming addressable, callers using named arguments break. Positional callers are likely safe. Audit actual call sites.
• Resource creation timestamp is additive and low risk, but confirm nullability — older API servers and some resource kinds may not populate it, and naive ->diffForHumans() on null will fatal.
• PHP 8.4 deprecation fixes are low risk but are the kind of change that occasionally alters edge-case behavior (implicit nullable, dynamic properties). Worth a smoke test, not a design review.

Key questions

1. Is a 4.0.0 planned to formally mark the Laravel/PHP 8.2 removal, and will 3.8.x receive security fixes in the meantime?
2. Was illuminate/support removed from require, or only the provider class? The former reduces dependency-conflict surface; the latter leaves dead weight.
3. What is the supported PHP and Laravel matrix for 3.9.x, and is there a stated support window?
4. Does the project intend to publish a documented "bring your own container binding" recipe, or are we entirely on our own for Laravel integration?
5. Which pawl/react versions are now pinned, and do they conflict with our existing WebSocket or queue-worker dependencies?
6. Is the maintainer's narrowing of scope (dropping Laravel) a signal of reduced investment overall? Single-maintainer projects warrant an explicit exit plan.

Integration Approach

Stack fit

• For Laravel services on PHP 8.3+: core client fits, binding layer does not. We supply the binding.
• For PHP 8.2 services: not compatible. Either upgrade PHP or remain on 3.8.x.
• For non-Laravel PHP services and CLI tooling: fit improves — one fewer framework assumption to carry.

Migration path

1. Freeze first. Add "krymo/php-k8s": "3.8.*" (or "^3.8 <3.9") to every affected composer.json and land it before any other work. This is the only urgent step.
2. Inventory. Grep for the facade alias, the provider class name in config/app.php, published config/k8s.php, and any KubernetesCluster calls using named arguments. Produce a per-service list.
3. Decide build-vs-adopt. Options, in preference order: (a) upgrade to 3.9 and maintain a thin in-house service provider + config in a shared internal package; (b) stay on 3.8.x long-term with a documented freeze; (c) fork the Laravel binding; (d) migrate to an alternative client. Recommend (a) — smallest permanent surface and keeps us on the maintained line.
4. Upgrade PHP where required, separately and ahead of the package bump, so failures are attributable.
5. Move to 3.9.x service by service, removing facade/provider references and wiring the internal binding, with the WebSocket/exec paths explicitly exercised.
6. Document the internal adapter as the supported entry point so new code does not reintroduce direct facade usage.

Compatibility

• Verify no other package in the estate depends on php-k8s transitively with a ^3 constraint — those will float to 3.9 independently of our pins.
• Check pawl/react resolution against any existing WebSocket or event-loop usage in the same application.
• Confirm the Laravel versions in use are unaffected by whatever remains in the package's require block.

Sequencing Pin → inventory → PHP floor upgrade → build internal adapter with tests → pilot on one low-risk service → roll out → remove facade references → publish internal docs and a version-watch runbook. Do not bundle the PHP upgrade and the package bump in a single change; the semver surprise already makes attribution harder than it should be.

Operational Impact

Maintenance

• We permanently acquire a small piece of Laravel glue that was previously upstream's. It is bounded (provider, config, maybe a facade) but it is ours to test against each Laravel major.
• A breaking change shipped in a minor version means automated dependency updates are unsafe for this package. Exclude it from Renovate/Dependabot auto-merge and route it to manual review with a changelog read.
• Single-maintainer dependency. Mitigate with the pin, an internal adapter that isolates the client surface, and a documented fallback client.

Support

• No vendor support path; reliance on GitHub issues and the maintainer's availability. Nominate an internal owner for the adapter and for version-watch.
• The scope reduction (dropping Laravel) is a supportability signal worth recording. It suggests Laravel-specific issues will not be prioritized upstream.

Scaling

• Package-level scaling concerns are control-plane, not application: API server QPS and watch-connection counts. Unchanged by this release.
• Long-lived exec/port-forward sessions via pawl hold event-loop resources; the dependency bump may shift memory or reconnect behavior under many concurrent sessions. Load-test if we run these at volume.

Failure modes

• Silent break on composer update — missing provider/facade class at boot. Highest-probability failure; mitigated by pinning.
• Config not loading — published config orphaned once the provider is gone; client constructed with defaults and fails at first API call rather than at boot.
• PHP floor mismatch in CI or a container image, surfacing as a resolver error at deploy rather than in review.
• WebSocket regression from the pawl/react bump — exec and log streaming degrade or reconnect-loop in production.
• Null timestamp dereference on resources or API server versions that omit creation timestamps.
• Named-argument mismatch in KubernetesCluster calls if parameter names were altered alongside the named-parameter support.

Ramp-up

• Low for existing developers — the API surface they use is unchanged; only the wiring moves. The main learning is "where does the client come from now," which the internal adapter answers.
• New hires lose the discoverability of a published Laravel integration; the internal adapter package needs real README coverage or the knowledge concentrates in one or two people.
• Rough sizing: adapter plus tests ~1–2 days; per-service migration ~half a day each once the adapter exists; PHP 8.2→8.3+ upgrades are the dominant cost and should be estimated from the PHP upgrade workstream, not from this package.