{"slug": "agents-on-every-cloud", "title": "Agents on Every Cloud", "summary": "Solo.io has published open source distributions of kagent and agentgateway on AWS Marketplace, Microsoft Azure Marketplace, and Google Cloud Marketplace, both free to deploy and installable via each cloud's native flow. kagent, a CNCF project, is a Kubernetes-native framework for building and running AI agents, while agentgateway, part of the Linux Foundation, is an AI-native data plane built on the Kubernetes Gateway API that supports MCP and A2A protocols with LLM routing, failover, prompt guards, and observability. The combined deployment enables agents to be exposed, secured, and observed as production services across all three clouds.", "body_md": "Solo.io has published the open source distributions of [kagent](https://kagent.dev/) and [agentgateway](https://agentgateway.dev/) on all three major cloud marketplaces: AWS Marketplace, Microsoft Azure Marketplace, and Google Cloud Marketplace. Both are free to deploy, and both install into your cluster the same way you already consume other cloud services: subscribe, pick a cluster, done. No Helm repo setup, no copying manifests from a README, and the deployment shows up in your cloud account alongside everything else you run there.\n\nA quick word on the projects themselves. Both started at Solo.io and both were donated to open foundations: kagent is a CNCF project, and agentgateway is part of the Linux Foundation. kagent is a Kubernetes-native framework for building and running AI agents. You declare agents, model configurations, and MCP tools as Kubernetes resources, and the kagent controller runs them, with a web UI on top and pluggable LLM providers (OpenAI, Anthropic, Azure OpenAI, Gemini, Ollama). agentgateway is an AI-native data plane built on the [Kubernetes Gateway API](https://kubernetes.io/docs/concepts/services-networking/gateway/). It speaks the protocols agents actually use, MCP and A2A, and adds LLM routing and failover, prompt guards, and observability for agent traffic.\n\nEach one is useful on its own. Together, one extends the other: kagent gives you agents running in your cluster, and agentgateway extends them with a real network edge, so agents and tools stop being cluster-internal experiments and become services you can expose, secure, and observe like anything else in production. In the walkthrough below we deploy both from the marketplace and connect them.\n\nHere is where you can find the listings today:\n\n| kagent | agentgateway | |\n|---|---|---|\n| AWS Marketplace |\n|\n\nThe exact install flow differs per cloud (EKS add-on or Helm on AWS, a Kubernetes application on Azure, click-to-deploy on Google Cloud), and each one has a dedicated walkthrough:\n\nThe rest of this post is the part that is the same everywhere: what you get after the marketplace install, and how the two products work together. Everything below was run on real marketplace installs across the three clouds with both products installed.\n\nYou need a Kubernetes cluster, kubectl access to it, and an LLM provider API key (we use OpenAI here). kagent does not run any agents until a provider is configured, so the key is the one real prerequisite.\n\nagentgateway builds on the upstream Kubernetes Gateway API, so its only prerequisite is the standard CRDs:\n\n```\nkubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.0/standard-install.yaml\n```\n\nInstall both products from your cloud’s marketplace (steps in the per-cloud posts above). agentgateway lands in the `agentgateway-system`\n\nnamespace and kagent in the `kagent`\n\nnamespace. Whichever cloud you used, the result looks the same:\n\n``` bash\n$ kubectl get pods -n agentgateway-system\nNAME READY STATUS RESTARTS AGE\nagentgateway-cdd8744df-4rb7k 1/1 Running 0 2m\n\n$ kubectl get pods -n kagent\nNAME READY STATUS RESTARTS AGE\nkagent-controller-7974bb886-ch8v7 1/1 Running 0 5m\nkagent-kmcp-controller-manager-bc49969c4-crhjv 1/1 Running 0 5m\nkagent-postgresql-85d75cbd57-knpqf 1/1 Running 0 5m\nkagent-tools-6cb4449d6b-hzfsr 1/1 Running 0 5m\nkagent-ui-75f8449979-96km2 1/1 Running 0 5m\n```\n\nThat is the whole platform: the kagent controller and UI, kmcp for serving MCP tools, a bundled PostgreSQL for state, and the agentgateway control plane watching for Gateway API resources. (Exact resource names vary a little per platform: on AKS, for example, they carry the extension instance name you chose at install, so `kagent-controller`\n\nbecomes `<extension-name>-controller`\n\n.) kagent also registers a set of CRDs that make agents ordinary Kubernetes resources:\n\n``` bash\n$ kubectl get crd | grep kagent.dev\nagentharnesses.kagent.dev\nagents.kagent.dev\nmcpservers.kagent.dev\nmemories.kagent.dev\nmodelconfigs.kagent.dev\nmodelproviderconfigs.kagent.dev\nremotemcpservers.kagent.dev\nsandboxagents.kagent.dev\ntoolservers.kagent.dev\n```\n\nDeployed on Google Cloud? Skip this section: the deploy form already collected your provider choice and created the `ModelConfig`\n\n(and secret, if the provider uses a key), so jump straight to creating an agent.\n\nOn AWS and Azure, give kagent an LLM to talk to. Create a secret with your API key and a `ModelConfig`\n\nthat references it:\n\n```\nkubectl create secret generic kagent-openai -n kagent \\\n --from-literal=OPENAI_API_KEY=$OPENAI_API_KEY\nkubectl apply -f - <<EOF\napiVersion: kagent.dev/v1alpha2\nkind: ModelConfig\nmetadata:\n name: default-model-config\n namespace: kagent\nspec:\n model: gpt-4o-mini\n provider: OpenAI\n apiKeySecret: kagent-openai\n apiKeySecretKey: OPENAI_API_KEY\nEOF\n```\n\nNote: Other providers (Anthropic, Azure OpenAI, Gemini, Ollama) work the same way; see the [kagent provider docs](https://kagent.dev/docs/getting-started/configuring-providers).\n\nAn agent is a resource like any other. The declarative type means the whole agent, model, instructions, and tools, is described by the resource and runs on kagent’s built-in runtime. The `tools`\n\nreference attaches the MCP tool server that ships with kagent, so the agent can actually inspect the cluster it lives in (the name follows the install, like the controller service; check with `kubectl get remotemcpservers -n kagent`\n\n):\n\n```\nkubectl apply -f - <<EOF\napiVersion: kagent.dev/v1alpha2\nkind: Agent\nmetadata:\n name: k8s-helper\n namespace: kagent\nspec:\n description: Answers questions about workloads in this cluster\n type: Declarative\n declarative:\n modelConfig: default-model-config\n systemMessage: |\n You are a Kubernetes assistant. Answer questions about the\n workloads running in this cluster using the tools available to you.\n tools:\n - type: McpServer\n mcpServer:\n apiGroup: kagent.dev\n kind: RemoteMCPServer\n name: kagent-tool-server\nEOF\n```\n\nThe controller spins up a pod for the agent and reports readiness on the resource:\n\n``` bash\n$ kubectl get agents -n kagent\nNAME TYPE RUNTIME READY ACCEPTED\nk8s-helper Declarative python True True\n```\n\nFor a look around, port-forward the UI at `kubectl -n kagent port-forward svc/kagent-ui 8080:8080`\n\n(use `kagentaks-ui`\n\nin Azure) and open `http://localhost:8080`\n\n(hit Skip Wizard on the bottom for this demo). Now you can chat with the agent there, and kagent ships prebuilt agents and MCP tools for Kubernetes, Helm, Istio, and more.\n\nSo far the agent lives inside the cluster, reachable through a port-forward. That is fine for a demo and not fine for anything real: other teams, other agents, and external callers need a governed way in, and you need to see and control that traffic. This is where agentgateway extends kagent.\n\nkagent exposes every agent over A2A (Agent2Agent), the open protocol for agent-to-agent communication, served by the kagent controller at `/api/a2a/<namespace>/<agent-name>`\n\n. agentgateway understands A2A natively, so exposing the agent is a plain Gateway API exercise:\n\n```\nkubectl apply -f - <<EOF\napiVersion: gateway.networking.k8s.io/v1\nkind: Gateway\nmetadata:\n name: kagent-gateway\n namespace: kagent\nspec:\n gatewayClassName: agentgateway\n listeners:\n - name: http\n port: 8080\n protocol: HTTP\n allowedRoutes:\n namespaces:\n from: Same\n---\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: k8s-helper-a2a\n namespace: kagent\nspec:\n parentRefs:\n - name: kagent-gateway\n rules:\n - backendRefs:\n - name: kagent-controller # in AKS use kagentaks-controller\n port: 8083\nEOF\n```\n\nThe backendRef points at the kagent controller service on port 8083; check the service name in your cluster with `kubectl get svc -n kagent`\n\n(it follows the install name, for example `kagentaks-controller`\n\non AKS).\n\nThe agentgateway controller picks up the Gateway, deploys a proxy for it, and (on a cloud cluster) provisions a load balancer. Within a minute the Gateway is programmed and has an address:\n\n``` bash\n$ kubectl get gateway,httproute -n kagent\nNAME CLASS ADDRESS PROGRAMMED AGE\ngateway.gateway.networking.k8s.io/kagent-gateway agentgateway aacf335c...elb.amazonaws.com True 60s\n\nNAME HOSTNAMES AGE\nhttproute.gateway.networking.k8s.io/k8s-helper-a2a 60s\n```\n\nNow the agent has an address outside the cluster. Grab it and fetch the agent card, the A2A discovery document that tells other agents what this one can do:\n\n```\nGW=$(kubectl get gateway kagent-gateway -n kagent \\\n -o jsonpath='{.status.addresses[0].value}')\n\ncurl -s http://$GW:8080/api/a2a/kagent/k8s-helper/.well-known/agent-card.json | jq .\n{\n \"name\": \"k8s_helper\",\n \"description\": \"Answers questions about workloads in this cluster\",\n \"capabilities\": { \"streaming\": true },\n \"preferredTransport\": \"JSONRPC\",\n \"protocolVersion\": \"0.3\",\n ...\n}\n```\n\nAnd talk to it. A2A is JSON-RPC over HTTP, so a plain curl works; any A2A client library works the same way:\n\n```\ncurl -s http://$GW:8080/api/a2a/kagent/k8s-helper/ \\\n -H 'Content-Type: application/json' \\\n -d '{\"jsonrpc\":\"2.0\",\"id\":\"1\",\"method\":\"message/send\",\"params\":{\"message\":{\"kind\":\"message\",\"messageId\":\"demo-1\",\"role\":\"user\",\"parts\":[{\"kind\":\"text\",\"text\":\"In one sentence: what do you do?\"}]}}}' \\\n | jq -r '.result.artifacts[0].parts[0].text'\nI provide information and answers regarding the workloads running in the Kubernetes cluster.\n```\n\nThat request went from the internet, through the agentgateway proxy, to the agent’s A2A endpoint. And because the data plane understands what it is routing, you get structured visibility into agent traffic for free:\n\n``` bash\n$ kubectl logs -n kagent deploy/kagent-gateway --tail 1\n2026-08-11T20:34:26.791178Z info request gateway=kagent/kagent-gateway listener=http\n route=kagent/k8s-helper-a2a endpoint=10.48.0.7:8083 src.addr=10.48.1.1:22687 http.method=POST\n http.host=136.115.154.87 http.path=/api/a2a/kagent/k8s-helper/ http.version=HTTP/1.1\n http.status=200 protocol=http duration=1008ms\n```\n\nFrom here the interesting part starts. Because the traffic flows through agentgateway, you get the things you would expect from a gateway, applied to agent protocols: per-route policies, authn/z in front of agents, rate limits, and metrics and traces for every agent and tool call (the chart ships Prometheus endpoints and a Grafana dashboard out of the box). The same gateway can also front MCP tool servers and route LLM traffic with failover between providers, so as your agent footprint grows, the governance model does not change.\n\nThe extension works in the other direction too: agents you build in kagent become A2A services other teams can consume through the gateway, and tools you put behind agentgateway become available to any MCP-capable agent, not just kagent’s.\n\nTwo open source projects, three marketplaces, one deployment model: pick your cloud, subscribe, and you have an agent runtime and an agent-aware gateway running in your cluster. The per-cloud posts cover the marketplace specifics:\n\nDocs and source, if you want to go deeper: [kagent.dev](https://kagent.dev/) ([GitHub](https://github.com/kagent-dev/kagent)) and [agentgateway.dev](https://agentgateway.dev/) ([GitHub](https://github.com/agentgateway/agentgateway)).", "url": "https://wpnews.pro/news/agents-on-every-cloud", "canonical_source": "/blog/2026-08-27-agents-on-every-cloud/", "published_at": "2026-08-27 00:00:00+00:00", "updated_at": "2026-08-27 22:19:13.087065+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Solo.io", "kagent", "agentgateway", "AWS Marketplace", "Microsoft Azure Marketplace", "Google Cloud Marketplace", "CNCF", "Linux Foundation"], "alternates": {"html": "https://wpnews.pro/news/agents-on-every-cloud", "markdown": "https://wpnews.pro/news/agents-on-every-cloud.md", "text": "https://wpnews.pro/news/agents-on-every-cloud.txt", "jsonld": "https://wpnews.pro/news/agents-on-every-cloud.jsonld"}}