rancher
/
fleet-docs
mirror of https://github.com/rancher/fleet-docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fixup! Add a table comparing agent vs manager initiated registration

This commit is contained in:
Mario Manno 2025-10-20 16:55:40 +02:00
parent d9eb9f4276
commit 6176f32dbb
No known key found for this signature in database
GPG Key ID: 374B465F5AD95072
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/cluster-registration.md
View File

@ -47,7 +47,7 @@ or [Rancher](https://github.com/rancher/rancher).
| **Data Synchronization (Pull)** | The agent pulls configuration bundles and agent updates from the Fleet Controller (part of the two-stage pull model). | The agent pulls configuration bundles and agent updates from the Fleet Controller. |
| **Agent Management (Push/Redeploy)** | The upstream controller typically **lacks** the direct network access/credentials required for proactive management actions (PUSH) on the agent deployment. | The initial deployment mechanism grants the Manager explicit access. This infrastructure can be used for administrative management actions (e.g., triggering deployment using the kubeconfig). |
| **Agent Redeployment Control Field** | The `redeployAgentGeneration` field (on `ClusterSpec`) is **not used** by the upstream controller to trigger redeployment, as the manager lacks the API access necessary to directly manipulate the downstream agent deployment. | The `redeployAgentGeneration` field on the `ClusterSpec` **can be incremented to force redeployment** of the agent by the Fleet Controller. |
| **Agent Adoption Post-Registration** | After initial registration using the token, the agent is adopted into the standard management lifecycle via bundles created by the `manageagent` controller (as noted in conversation history). | Once the agent is deployed, the `manageagent` controller explicitly creates a bundle to **adopt the existing deployment**, ensuring management continues through the Fleet system (this flow is clearly defined in internal documents). |
| **Agent Adoption Post-Registration** | After initial registration using the token, the agent is adopted into the standard management lifecycle via bundles created by the `manageagent` controller. |
| **Rancher Context** | This method is **not commonly used** when registering clusters through the Rancher dashboard. | This method **is used** when adding a cluster via the Rancher dashboard (often via a Rancher agent proxying the downstream kubeconfig upstream). |
| **Post-Registration Token Status** | The agent forgets the registration token after success; a new token must be generated for re-registration. | N/A; registration token/kubeconfig management is handled internally by the Fleet Manager. |