Kubernetes Client Laravel Package

Product Decisions This Supports

Build vs. buy for cluster operations from PHP. If your product's job includes creating namespaces, applying manifests, reading pod/deployment status, or driving Custom Resources on behalf of tenants, this library removes a chunk of undifferentiated work: kubeconfig loading (including inline PEM certs and tokens), TLS/timeout options, HTTP adapter discovery, resource models, repositories, and typed collections. That is roughly the "write it ourselves over cURL" scope you would otherwise spend 2–4 weeks on plus ongoing maintenance.

Roadmap: self-service and per-tenant infrastructure. The repository/collection pattern (e.g. $client->pods(), $client->deployments()) maps cleanly onto product features that need a Kubernetes object graph in application code: spinning up a sandbox environment per trial account, provisioning a dedicated worker per customer, or tearing down resources on downgrade. PatchMergeTrait and PatchType mean CRD-driven workflows are in scope, which matters if your roadmap includes operators or platform CRDs.

Roadmap: operational visibility inside the product. Because the models are addressable via Model/Attribute/Explorer.php and collections extend Illuminate collections, you can build admin dashboards ("your workers are running / degraded") without a separate metrics stack or a second language runtime in the deploy pipeline. Streaming parser contracts also make log-tail and watch-style features plausible rather than aspirational.

Feature scoping and delivery estimates. The presence of a full test story — PHPUnit plus Behat scenarios against an in-memory fake API server that asserts method, URI, headers and body actually sent — is a genuine schedule input. It signals integration behaviour is verified without a live cluster, so CI cost and "works on my cluster" risk are lower than the star count implies.

Architecture decision: PHP as a first-class cluster operator. Adopting this is a vote that your PHP service, not a Go sidecar or a kubectl shell-out, owns cluster mutations. That reduces the number of deployables and languages your team must staff, and it keeps transactional intent (DB write + cluster apply) in one process where you can reason about it.

Risk and due-diligence input. 3 stars, 0 dependents, and an opportunity score of ~35 are the decision-relevant facts here, not the feature list. Treat this as a "buy with a fork budget" candidate — the PM decision is not whether the API fits (it does) but whether your team is willing to own a low-traffic dependency. Budget an explicit owner and a fork contingency before it enters a critical path.

When to Consider This Package

Adopt when all of the following hold:

• Your runtime is genuinely PHP 8.4+. This is the hardest gate in the whole evaluation — it is a modern, aggressive floor and will likely force a platform upgrade before you can even install it. If you are on 8.1–8.3, this package is a roadmap dependency, not a today dependency.
• You are on, or willing to be on, Laravel/Symfony with an Illuminate-leaning stack. Collections extend Illuminate collections, so a non-Laravel codebase inherits that dependency. That is usually fine, occasionally a governance objection.
• You need read/write access to a modest set of core resources plus CRDs — not high-throughput or watch-heavy workloads. The design is a request/response client with a streaming parser contract; it is not a controller-runtime or informer framework.
• Your cluster surface is small and your blast radius is understood: one or a few clusters, credentials in kubeconfig or env, and a team that can read the source when docs run out.
• You accept ownership. With zero dependents there is no ecosystem signal of production hardening. Require a named internal owner, a vendored fork or pinned commit strategy, and a review of the exception hierarchy (note: both Exception/ and Exceptions/ exist — a smell that warrants a compatibility read before you build error handling on top).

Look elsewhere or build thin wrappers when:

• You need a mature, widely deployed client. The better-known PHP Kubernetes clients have orders of magnitude more production exposure; for a critical path, "popular and boring" is a legitimate criterion.
• You need controller/informer semantics, watch streams as a primary primitive, leader election, or admission webhooks. Wrong tool.
• Your team would rather shell out to kubectl for a handful of apply/delete operations. Honestly evaluate this first: if you have under ~5 cluster operations and no CRDs, a subprocess wrapper is less dependency risk than a library.
• You are polyglot and already run Go for platform work. The official Go client is the ecosystem default; adding a PHP cluster client splits ownership of cluster mutations across two runtimes.
• License policy is strict. BSD-3-Clause is permissive and commercially safe; this is a pass, not a blocker — but confirm your attribution obligations are captured in whatever notice file your legal process requires.

Diligence checklist before adoption: check release cadence and last-commit recency, confirm the PHPUnit/Behat suites pass on your PHP version, verify the HTTP adapter you already ship (cURL, Guzzle 7, Symfony HttpClient, socket) is covered, read the changelog for public-API breaks, and confirm Client::setTmpDir() semantics for temporary certificate handling fit your container's writable-filesystem policy — ephemeral temp files are a real failure mode in read-only root filesystems.

How to Pitch It (Stakeholders)

To executives (one paragraph): We are evaluating a small open-source PHP library that lets our application talk to Kubernetes directly — creating and inspecting the resources our customers' environments run on — instead of us building that plumbing ourselves. It is well-engineered for its size: modern PHP, strict static analysis, two test suites including a simulated cluster that verifies the exact requests sent. The trade-off is adoption: it has a handful of stars and no downstream dependents, so it has not been battle-tested by a community. My recommendation is to treat it as a build accelerator with an ownership cost, not a vendor dependency — worth adopting for non-critical-path cluster automation if we assign an owner and can run PHP 8.4, and worth deferring if either is untrue.

To engineering (the honest version): The API is the right shape — client entry point with kubeconfig and TLS handling, HTTP adapter discovery across cURL/Guzzle/Symfony/socket, a repository registry, models, and Illuminate-based collections, plus patch strategies for CRDs. Test discipline is above average for a package this size (PHPUnit plus Behat against a fake API server that asserts the real wire request, PHPStan at max level, PSR-12). Three concerns: (1) PHP 8.4+ floor is a platform prerequisite, not a footnote; (2) zero dependents means no external evidence of production use — we should pin it, or fork it, and name an owner; (3) the duplicated Exception/ and Exceptions/ directories suggest churn in the error model, so design our error handling defensively. If we proceed, keep it behind an internal interface so replacing it is a contained change rather than a refactor.

To the platform/security reviewer (the questions they will ask): Credentials come from kubeconfig including inline PEM content, which the client writes to private temporary files it owns and cleans up on release — confirm that behaviour against our read-only-filesystem and secret-handling standards, and verify setTmpDir() is set explicitly in our deployments. Confirm the RBAC footprint we grant this service is scoped per-namespace rather than cluster-wide, since a library this small is not a substitute for least-privilege. BSD-3-Clause clears legal with attribution.