Actions54
- Namespace Actions
- Deployment Actions
- Service Actions
- Pod Actions
- StatefulSet Actions
- ConfigMap Actions
- Secret Actions
- Job Actions
- CronJob Actions
- Node Actions
- Workload Actions
Overview
The "Redeploy" operation for the Workload resource in this Rancher node allows users to trigger a redeployment of a workload within a Kubernetes cluster managed by Rancher. This operation is useful when you want to restart or refresh a workload without changing its configuration, for example, to apply updated container images that use the same tag, or to recover from transient errors.
Common scenarios include:
- Redeploying an application after updating environment variables or secrets externally.
- Restarting pods managed by a workload to pick up new configurations or fix issues.
- Triggering a rolling update without modifying the workload spec.
Practical example: You have a deployment running a web application and want to force all pods to restart to clear cached data or reload configuration files. Using the "Redeploy" operation on the workload will initiate this process seamlessly.
Properties
| Name | Meaning |
|---|---|
| Cluster Name or ID | Select the target Kubernetes cluster by name or ID where the workload resides. |
| Project Name or ID | (Optional) Select the project within the cluster to scope the workload. |
| Namespace Name or ID | (Optional) Select the namespace within the project where the workload is deployed. |
These properties allow precise targeting of the workload to be redeployed by specifying its location in the Rancher/Kubernetes hierarchy.
Output
The output of the "Redeploy" operation is a JSON object representing the response from the Rancher/Kubernetes API regarding the redeployment action. It typically includes status information about the workload, such as whether the redeployment was successfully initiated, current state, and metadata.
If the node supports binary data output, it would represent any associated binary payloads related to the workload, but this operation primarily deals with JSON responses.
Dependencies
- Requires an active connection to a Rancher-managed Kubernetes cluster via an API key credential configured in n8n.
- The node depends on Rancher's API endpoints to manage workloads.
- Proper permissions are needed on the Rancher API token to perform workload redeployments.
- The node uses dynamic option loading methods to fetch clusters, projects, and namespaces for user selection.
Troubleshooting
Common Issues:
- Incorrect or missing cluster/project/namespace identifiers can cause failures in locating the workload.
- Insufficient API permissions may result in authorization errors.
- Network connectivity problems between n8n and the Rancher server can cause timeouts or connection errors.
Error Messages:
- "Workload not found": Verify that the specified cluster, project, namespace, and workload exist and are correctly referenced.
- "Unauthorized" or "Forbidden": Check that the API key has the necessary permissions to redeploy workloads.
- Timeout or network errors: Ensure that the Rancher API endpoint is reachable from the n8n instance.
Resolving these usually involves verifying input parameters, checking credentials, and ensuring network access.
Links and References
- Rancher Official Documentation
- Kubernetes Workloads Overview
- n8n Expressions Documentation (for using expressions in property fields)