Php K8S Laravel Package

Product Decisions This Supports

• Kubernetes-adjacent feature work in PHP estates: If the roadmap includes operational tooling — deploy previews, namespace provisioning, tenant isolation, job runner orchestration, config/secret sync, or cluster introspection dashboards — this package is the direct dependency that unblocks those epics without introducing a second language runtime into the stack.
• Build vs. buy on the “control plane glue” layer: The core work here (auth, watches/streaming, resource models, API surface coverage) is commodity plumbing. Adopting the package converts weeks of bespoke cURL-against-the-API-server engineering into maintenance, so the decision is really “do we staff a K8s client we own, or do we consume this and contribute upstream?”
• Roadmap scoping signal for 3.9.0: Two decisions land here. (1) The maintainer has removed the Laravel integration, so any roadmap item assuming first-party Laravel ergonomics (service provider, config publishing, facade, Eloquent-style resource management) must now be re-scoped as in-house glue. (2) PHP 8.2 and Laravel support both drop, so the platform baseline for the affected service moves forward. Treat this as a forcing function to confirm the product’s supported-runtime matrix before committing dates.
• Use cases that are now cleanly in scope: long-lived watch/exec sessions over WebSockets (the ratchet/pawl bump matters for streaming reliability), cluster orchestration helpers with named arguments (readability and forward-compatibility in our own wrapper code), and resource lifecycle/age surfaced in UIs via the newly exposed creation timestamp — that last one is a small but genuine end-user-visible feature for any “what’s running and how old is it” view.
• Vendor-risk tracking: The package is now framework-agnostic and community-maintained, with a small PR pipeline (three PRs in this release). That is either a healthy sign of an independent library or an early signal of thinning Laravel-ecosystem investment — a PM should decide which reading applies and record it as a dependency risk on the roadmap.

When to Consider This Package

Consider it when:

• The product genuinely needs to talk to Kubernetes from PHP: provisioning namespaces per customer, driving CI/CD preview environments, listing/annotating resources, watching for state changes, or executing into pods for support tooling.
• You are on PHP 8.3+ and have already migrated — or deliberately plan to migrate — off PHP 8.2. 3.9.0 removes 8.2, so this is a hard gate, not a soft preference.
• You are not relying on Laravel-specific integration. The Laravel support removal means the package no longer ships the framework conveniences; if your application is Laravel-based you will own the service container wiring, configuration, and any facade-style ergonomics yourself. Budget for that or use the framework-agnostic client directly in a dedicated service.
• Your team is comfortable owning the sharp edges: this is a low-level API client, not an operator or a declarative reconciler. Expect to write retry, backoff, watch-restart, and error-classification logic above it.
• You want to contribute upstream rather than fork — the active PR flow suggests patches are accepted.

Look elsewhere when:

• What you actually need is deployment (building images, rolling out manifests, GitOps reconciliation). That is Helm/Argo/Flux territory; this package does not replace them, and reaching for it to do so is a common and expensive misread.
• You are pinned to PHP 8.2, or you are on a Laravel version whose support policy you cannot diverge from for this dependency.
• Your Kubernetes interaction is trivial and one-directional — a handful of kubectl-equivalent calls at deploy time. Shelling out or using a thin HTTP wrapper may cost less than the dependency.
• You need a hard SLA, a vendor to escalate to, or a guarantee of continued Laravel-ecosystem alignment. The 3.9.0 direction is explicitly away from framework coupling.
• Your cluster policy forbids in-cluster credentials held by application code — in which case the architectural problem is upstream of the library choice.

Migration note for existing adopters: the removal of Laravel support and PHP 8.2 are breaking changes; despite the minor version number, plan this as a coordinated upgrade with a platform-baseline bump and a re-validation of any in-house Laravel glue you built on top of the previous integration.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a PHP library that lets our product drive Kubernetes directly instead of us building that integration from scratch. The new 3.9.0 release is a scope and risk event, not a feature release: the maintainer has deliberately removed the Laravel integration and dropped PHP 8.2, while fixing PHP 8.4 compatibility and improving streaming reliability. The practical consequence is that we can still get the core capability — but any convenience we were implicitly counting on from the Laravel side is now our own engineering cost, and our supported PHP baseline moves forward. The recommendation is to adopt the framework-agnostic library where we have a concrete need, explicitly budget roughly the glue work, and treat PHP 8.2 retirement as a scheduled item rather than an incident. The upside: real operational features on the roadmap (per-customer environments, cluster visibility, resource lifecycle in the UI) become deliverable in PHP rather than requiring a separate service in another language.

To engineering (the short version): 3.9.0 fixes PHP 8.4 deprecations, removes Laravel support, drops PHP 8.2, exposes resource creation timestamps, allows named arguments in KubernetesCluster methods, and bumps ratchet/pawl. Treat it as breaking on the platform axis even though it is a minor version. Action items: (1) confirm our PHP floor is 8.3+ and schedule the bump; (2) inventory and own any code that depended on the old Laravel service provider/facade integration — that contract is gone; (3) re-run the WebSocket/watch integration tests against the new ratchet/pawl; (4) use the creation-timestamp exposure to retire whatever workaround our resource-age UI currently uses; (5) adopt named arguments in our cluster-orchestration call sites so minor signature changes stop breaking us. We remain a thin layer over this client — our retry, watch-restart, and error-handling logic stays ours and must be tested against the new release.