GraphOS Router Support Tool
OverviewGetting Started
Modes

Local Mode

GuideReference

Job Mode

GuideReferenceSupport Bundle Storage and Retrieval
Data CollectedCollecting Metrics
Products
Apollo GraphOS PlatformManage, observe, and scale your graph.GraphOS Agent ServicesPreviewGovern how agents access your graph.Apollo ConnectorsConnect REST APIs to your graph declaratively.Apollo FederationFederate multiple subgraphs into a single supergraph.Rover CLIInteract with your graph from the command line.Apollo RouterRun and configure your graph gateway.Apollo OperatorDeploy and manage Apollo Router on Kubernetes.
Open source
Apollo Client (Web)Simplify GraphQL data management in web apps.Apollo iOSSwift-first GraphQL client for iOS.Apollo KotlinKotlin-first GraphQL client for Android and JVM.Apollo ServerBuild GraphQL servers with Node.js.Apollo MCP ServerExpose GraphQL tools to AI agents with MCP.IDE SupportEnhance your development workflow with IDE support.GraphOS Router Support ToolDiagnose and troubleshoot your GraphOS Router.
Resources

Apollo Docs

nodeMetrics needs three separate grants to reach /api/v1/nodes/<node>/proxy/stats/summary:

  • nodes (list): To resolve node names when neither nodeNames nor selector is set. An ordinary, low-risk read of node objects—this is what surfaces node pressure conditions (MemoryPressure, DiskPressure).

  • nodes/proxy (get): Required unconditionally by the API server for any request matching the /nodes/{name}/proxy/{path} URL pattern. This is a broad grant: Kubernetes' own RBAC good-practices documentation states it "provides access to privileged kubelet APIs that can retrieve container logs or execute and attach to pod processes... bypasses audit logging and admission control," and is explicitly "not a read-only permission." What this tool does with it is read-only, but the grant itself authorizes more than that one use, and it can't be scoped to just the router's nodes.

  • nodes/stats (get): Required separately by the kubelet's own authorization check, layered on top of nodes/proxy, not a substitute for it.

Declining nodes/proxy/nodes/stats still leaves nodes access (node pressure conditions) and everything clusterResources provides: OOM kill occurrences and last state, restart counts, configured limits. What's lost is container memory/CPU trajectory over time, but nodeMetrics is a fallback for that signal, not the preferred path. For the full breakdown of each grant, go to Data Collected.

nodes/proxy and nodes/stats are only useful together. Declining either one loses the same capability, so there's no reason to grant one without the other. The chart currently only supports declining all three together, via job.collectNodeMetrics: false at install time. Doing that skips creating the ClusterRole/ClusterRoleBinding entirely, so the nodeMetrics collector itself then comes back empty rather than the install failing.