## Symptom
With `KUBECTL_CONTEXT` set in `.ate-dev-env.sh`, `./hack/install-ate.sh
--deploy-ate-system` aborts mid-deploy at the first `ko resolve`:
Error: unknown command "--context=..." for "ko resolve"
CRDs, the ate-system namespace, and podcertificate-controller have
already been applied by then, leaving the cluster half-installed.
## Cause
`run_ko` unconditionally appends `-- --context=$KUBECTL_CONTEXT` to
every ko invocation. Only `ko apply`, `ko create`, `ko delete`, `ko run`
have a kubectl phase that consumes args after `--`. Other subcommands
(`resolve`, `build`, `deps`, `login`, ...) parse it as a flag and reject
it.
## Fix
Only forward `--context` for the ko subcommands that actually delegate
to kubectl. `run_kubectl` already passes the context to direct kubectl
invocations, so the chained `ko resolve | run_kubectl apply -f -` flow
still targets the right cluster.
Adds golangci-lint v2.12.2 using the per-tool-module pattern under
hack/tools/golangci-lint/. The verifier at hack/verify/golangci-lint.sh
is auto-discovered by hack/verify-all.sh, so the existing CI verify
step picks it up with no workflow YAML change.
Ships .golangci.yaml with the standard linter set, a make lint
target, and a verify wrapper that pins GOOS=linux so ateom-gvisor's
netlink references typecheck on macOS the same way they do on CI.
Adjustments to keep the first run clean: two dead-code deletions
((*runsc).cmdList, MemoryPullCache.gcsClient), two SA9003 empty
branches replaced with slog.Error / t.Logf, one S1008 return-bool
simplification, and inline //nolint for one intentional best-effort
ReleaseLock plus four audit-tracked SA1019 deprecations.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This commit was automatically generated by the tools/reorg tool.
```
go run ./tools/reorg
go generate ./...
bash benchmarking/locust/generate_protos.sh
```
We are just using tools modules (plural) to manage installing go
binaries with binned versions easily.
We are NOT trying to patch transitive dependencies in those tools,
versus just updating those tools themselves.
Add a helper script to update them as intended, and add and AGENTS.md to
tell agents to use the script.
- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR
`install-ate-kind.sh --deploy-ate-system` installs the kind overlay
(rustfs and the `otel-system` namespace) via a kustomize build of
`manifests/ate-install/kind`, but the matching teardown only removed
`kind/rustfs.yaml`, and only when `ATE_INSTALL_RUSTFS=true` was set in
the environment.
Teardown now deletes the same kustomize set whenever
`ATE_INSTALL_KIND=true` (already exported by `install-ate-kind.sh`). The
GKE path is unchanged; `ATE_INSTALL_RUSTFS` is unused after this change.
Fixes #<issue_number_goes_here>
> It's a good idea to open an issue first for discussion.
- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
We've already been managing other go binaries with tools modules.
Doing this limits the number of setup steps needed, and allows our
scripts to make assumptions about the kind version.
`kind` has minimal dependencies and should compile very quickly.
Label the registry as created by our script, so we know if we should
delete it.
- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR
We're planning to add these later, noticed this failing on @dims's PR.
> It's a good idea to open an issue first for discussion.
- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR
Kubernetes 1.36 stopped putting the subject key in spec.pkixPublicKey
for PodCertificateRequest and now sends a stub PKCS#10 request instead.
The old controller parsed the deprecated field unconditionally, so new
PCRs had pkixPublicKey=null and failed with an ASN.1 'sequence
truncated' error before any certificate could be issued.
Add a shared helper that extracts the public key from
spec.stubPKCS10Request first and falls back to spec.pkixPublicKey for
older clusters. Both pod identity and service DNS signers use that path,
so their behavior stays consistent across Kubernetes versions. Bump the
Kubernetes dependencies to expose the new field and update
controller-runtime to the matching generation.
Without this, the `ate-system` pod all fail to start due to missing
certificates.
- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR
- Add a trivial /readyz handler (which will only be served once we
finish initializing)
- We use the metrics handler because we already expose an HTTP port
there and there should be no conflict
- Add a readiness probe to the install manifest
- Update install script to wait for readiness on core components
Improves reliability for the demo flow, including the test flake seen in
#2
> It's a good idea to open an issue first for discussion.
- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR
This is the initial release of the Agent Substrate.
Agent substrate is a system built on top of Kubernetes which manages agent-like
workloads to achieve higher scale and efficiency than Kubernetes alone can
offer, with lower latency. It builds on top of Kubernetes features like
Pods and Pod autoscaling, but takes the Kubernetes control-plane out of the
critical path to achieve lower latency.
It can run on any Kubernetes cluster and does not inhibit “regular” use of
Kubernetes in any way. Kubernetes provides the infrastructure provisioning and
management for all types of workloads, while Agent Substrate provides
agent-specific scheduling and control.
At its core, Agent Substrate maps a larger set of “actors” (applications such
as agents) onto a smaller set of ready “workers” (Kubernetes Pods), relying on
the fact that agent-like applications tend to be idle most of the time to
achieve heavy multiplexing. It provides functionality to manage an actor’s
lifecycle (e.g. create/destroy, suspend/resume), to assign actors to workers in real
time, and to route incoming traffic to them.
Agent Substrate is intended to be a low-opinion system. The workloads it
manages don't have to be literal AI agents, but those are the best example of
the kind of applications it is designed for. It is not an SDK for building
agents, but rather a system for running them at scale.
Agent Substrate is currently in VERY early development. It is not ready for
production use, and the APIs are almost guaranteed to change. We are not
making any guarantees about backward compatibility at this stage, and
everything in this project may be changed.
Co-authored-by: Alex Bulankou <alexbu@google.com>
Co-authored-by: Benjamin Elder <bentheelder@google.com>
Co-authored-by: Bowei Du <bowei@google.com>
Co-authored-by: Dmitry Berkovich <dberkov@google.com>
Co-authored-by: Fabricio Voznika <fvoznika@google.com>
Co-authored-by: Francisco Cabrera <fclieutier@google.com>
Co-authored-by: Haven Xia <haoyuxia@google.com>
Co-authored-by: Julian Gutierrez Oschmann <juliangut@google.com>
Co-authored-by: Kevin Steuer <ksteuer@google.com>
Co-authored-by: Max Smythe <smythe@google.com>
Co-authored-by: Maya Wang <mymaya@google.com>
Co-authored-by: Michael Taufen <mtaufen@google.com>
Co-authored-by: Shruti Nair <shrutinair@google.com>
Co-authored-by: Taahir Ahmed <taahm@google.com>
Co-authored-by: Tim Hockin <thockin@google.com>
Co-authored-by: Zoe Zhao <zoezhao@google.com>
Tim Hockin