public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-25 04:28:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

Move cattle agent cpu and mem rec to cluster agent specific page. Revert additions to incorrect pages

Browse Source
This commit is contained in:
Billy Tat
2024-04-29 17:03:13 -07:00
parent edd9f47033
commit 6a52c6b462
6 changed files with 161 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md
+53 -2
View File
@@ -21,11 +21,62 @@ The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher
The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters when `cattle-cluster-agent` is unavailable.
### Requests
The `cattle-cluster-agent` pod does not define default CPU and memory request values. As a baseline, we recommend setting the CPU request at `50m` and memory request at `100Mi`. However, it is important that you ensure your cluster has the correct resources available and the use case has been assessed appropriately before doing so.
To configure request values through the UI:
<Tabs groupId="k8s-distro">
<TabItem value="RKE">
1. When you create or edit an existing cluster, go to the **Cluster Options** section.
1. Expand the **Cluster Configuration** subsection.
1. Configure your request values using the **CPU Requests** and **Memory Requests** fields as needed.
</TabItem>
<TabItem value="RKE2/K3s">
1. When you create or edit an existing cluster, go to the **Cluster Configuration**.
1. Select the **Cluster Agent** subsection.
1. Configure your request values using the **CPU Reservation** and **Memory Reservation** fields as needed.
</TabItem>
</Tabs>
If you prefer to configure via YAML, add the following snippet to your configuration file:
<Tabs groupId="k8s-distro">
<TabItem value="RKE">
```yaml
cluster_agent_deployment_customization:
override_resource_requirements:
requests:
cpu: 50m
memory: 100Mi
```
</TabItem>
<TabItem value="RKE2/K3s">
```yaml
spec:
clusterAgentDeploymentCustomization:
overrideResourceRequirements:
requests:
cpu: 50m
memory: 100Mi
```
</TabItem>
</Tabs>
### Scheduling rules
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
| Component | nodeAffinity nodeSelectorTerms | nodeSelector | Tolerations |
| ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md
-7
View File
@@ -21,7 +21,6 @@ Smaller distributions such as Alpine and BusyBox reduce container image size and
Popular distributions such as Ubuntu, Fedora, and CentOS are more field-tested and offer more functionality.
### Start with a FROM scratch container
If your microservice is a standalone static binary, you should use a FROM scratch container.
The FROM scratch container is an [official Docker image](https://hub.docker.com/_/scratch) that is empty so that you can use it to design minimal images.
@@ -29,11 +28,9 @@ The FROM scratch container is an [official Docker image](https://hub.docker.com/
This will have the smallest attack surface and smallest image size.
### Run Container Processes as Unprivileged
When possible, use a non-privileged user when running processes within your container. While container runtimes provide isolation, vulnerabilities and attacks are still possible. Inadvertent or accidental host mounts can also be impacted if the container is running as root. For details on configuring a security context for a pod or container, refer to the [Kubernetes docs](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
### Define Resource Limits
Apply CPU and memory limits to your pods. This can help manage the resources on your worker nodes and avoid a malfunctioning microservice from impacting other microservices.
In standard Kubernetes, you can set resource limits on the namespace level. In Rancher, you can set resource limits on the project level and they will propagate to all the namespaces within the project. For details, refer to the Rancher docs.
@@ -43,7 +40,6 @@ When setting resource quotas, if you set anything related to CPU or Memory (i.e.
The Kubernetes docs have more information on how resource limits can be set at the [container level](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) and the namespace level.
### Define Resource Requirements
You should apply CPU and memory requirements to your pods. This is crucial for informing the scheduler which type of compute node your pod needs to be placed on, and ensuring it does not over-provision that node. In Kubernetes, you can set a resource requirement by defining `resources.requests` in the resource requests field in a pod's container spec. For details, refer to the [Kubernetes docs](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).
:::note
@@ -54,10 +50,7 @@ If you set a resource limit for the namespace that the pod is deployed in, and t
It is recommended to define resource requirements on the container level because otherwise, the scheduler makes assumptions that will likely not be helpful to your application when the cluster experiences load.
TODO we recommend to set your CPU request at 50m and memory request at 100Mi, however this is a base recommendation and customers should choose based on resources available in their environment and their use case on how they use Rancher.
### Liveness and Readiness Probes
Set up liveness and readiness probes for your container. Unless your container completely crashes, Kubernetes will not know it's unhealthy unless you create an endpoint or mechanism that can report container status. Alternatively, make sure your container halts and crashes if unhealthy.
The Kubernetes docs show how to [configure liveness and readiness probes for containers.](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md
+53 -2
View File
@@ -21,11 +21,62 @@ The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher
The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters when `cattle-cluster-agent` is unavailable.
### Requests
The `cattle-cluster-agent` pod does not define default CPU and memory request values. As a baseline, we recommend setting the CPU request at `50m` and memory request at `100Mi`. However, it is important that you ensure your cluster has the correct resources available and the use case has been assessed appropriately before doing so.
To configure request values through the UI:
<Tabs groupId="k8s-distro">
<TabItem value="RKE">
1. When you create or edit an existing cluster, go to the **Cluster Options** section.
1. Expand the **Cluster Configuration** subsection.
1. Configure your request values using the **CPU Requests** and **Memory Requests** fields as needed.
</TabItem>
<TabItem value="RKE2/K3s">
1. When you create or edit an existing cluster, go to the **Cluster Configuration**.
1. Select the **Cluster Agent** subsection.
1. Configure your request values using the **CPU Reservation** and **Memory Reservation** fields as needed.
</TabItem>
</Tabs>
If you prefer to configure via YAML, add the following snippet to your configuration file:
<Tabs groupId="k8s-distro">
<TabItem value="RKE">
```yaml
cluster_agent_deployment_customization:
override_resource_requirements:
requests:
cpu: 50m
memory: 100Mi
```
</TabItem>
<TabItem value="RKE2/K3s">
```yaml
spec:
clusterAgentDeploymentCustomization:
overrideResourceRequirements:
requests:
cpu: 50m
memory: 100Mi
```
</TabItem>
</Tabs>
### Scheduling rules
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
| Component | nodeAffinity nodeSelectorTerms | nodeSelector | Tolerations |
| ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md
+1 -6
View File
@@ -21,7 +21,6 @@ Smaller distributions such as Alpine and BusyBox reduce container image size and
Popular distributions such as Ubuntu, Fedora, and CentOS are more field-tested and offer more functionality.
### Start with a FROM scratch container
If your microservice is a standalone static binary, you should use a FROM scratch container.
The FROM scratch container is an [official Docker image](https://hub.docker.com/_/scratch) that is empty so that you can use it to design minimal images.
@@ -29,11 +28,9 @@ The FROM scratch container is an [official Docker image](https://hub.docker.com/
This will have the smallest attack surface and smallest image size.
### Run Container Processes as Unprivileged
When possible, use a non-privileged user when running processes within your container. While container runtimes provide isolation, vulnerabilities and attacks are still possible. Inadvertent or accidental host mounts can also be impacted if the container is running as root. For details on configuring a security context for a pod or container, refer to the [Kubernetes docs](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
### Define Resource Limits
Apply CPU and memory limits to your pods. This can help manage the resources on your worker nodes and avoid a malfunctioning microservice from impacting other microservices.
In standard Kubernetes, you can set resource limits on the namespace level. In Rancher, you can set resource limits on the project level and they will propagate to all the namespaces within the project. For details, refer to the Rancher docs.
@@ -43,7 +40,6 @@ When setting resource quotas, if you set anything related to CPU or Memory (i.e.
The Kubernetes docs have more information on how resource limits can be set at the [container level](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) and the namespace level.
### Define Resource Requirements
You should apply CPU and memory requirements to your pods. This is crucial for informing the scheduler which type of compute node your pod needs to be placed on, and ensuring it does not over-provision that node. In Kubernetes, you can set a resource requirement by defining `resources.requests` in the resource requests field in a pod's container spec. For details, refer to the [Kubernetes docs](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).
:::note
@@ -52,10 +48,9 @@ If you set a resource limit for the namespace that the pod is deployed in, and t
:::
As a starting point, we recommend setting your CPU request at 50m and memory request at 100Mi. You should choose your limits based on the resources available in your environment and your use case with Rancher. It is recommended to define resource requirements on the container level because otherwise, the scheduler makes assumptions that will likely not be helpful to your application when the cluster experiences load.
It is recommended to define resource requirements on the container level because otherwise, the scheduler makes assumptions that will likely not be helpful to your application when the cluster experiences load.
### Liveness and Readiness Probes
Set up liveness and readiness probes for your container. Unless your container completely crashes, Kubernetes will not know it's unhealthy unless you create an endpoint or mechanism that can report container status. Alternatively, make sure your container halts and crashes if unhealthy.
The Kubernetes docs show how to [configure liveness and readiness probes for containers.](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md
+53 -2
View File
@@ -21,11 +21,62 @@ The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher
The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters when `cattle-cluster-agent` is unavailable.
### Requests
The `cattle-cluster-agent` pod does not define default CPU and memory request values. As a baseline, we recommend setting the CPU request at `50m` and memory request at `100Mi`. However, it is important that you ensure your cluster has the correct resources available and the use case has been assessed appropriately before doing so.
To configure request values through the UI:
<Tabs groupId="k8s-distro">
<TabItem value="RKE">
1. When you create or edit an existing cluster, go to the **Cluster Options** section.
1. Expand the **Cluster Configuration** subsection.
1. Configure your request values using the **CPU Requests** and **Memory Requests** fields as needed.
</TabItem>
<TabItem value="RKE2/K3s">
1. When you create or edit an existing cluster, go to the **Cluster Configuration**.
1. Select the **Cluster Agent** subsection.
1. Configure your request values using the **CPU Reservation** and **Memory Reservation** fields as needed.
</TabItem>
</Tabs>
If you prefer to configure via YAML, add the following snippet to your configuration file:
<Tabs groupId="k8s-distro">
<TabItem value="RKE">
```yaml
cluster_agent_deployment_customization:
override_resource_requirements:
requests:
cpu: 50m
memory: 100Mi
```
</TabItem>
<TabItem value="RKE2/K3s">
```yaml
spec:
clusterAgentDeploymentCustomization:
overrideResourceRequirements:
requests:
cpu: 50m
memory: 100Mi
```
</TabItem>
</Tabs>
### Scheduling rules
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
| Component | nodeAffinity nodeSelectorTerms | nodeSelector | Tolerations |
| ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md
+1 -6
View File
@@ -21,7 +21,6 @@ Smaller distributions such as Alpine and BusyBox reduce container image size and
Popular distributions such as Ubuntu, Fedora, and CentOS are more field-tested and offer more functionality.
### Start with a FROM scratch container
If your microservice is a standalone static binary, you should use a FROM scratch container.
The FROM scratch container is an [official Docker image](https://hub.docker.com/_/scratch) that is empty so that you can use it to design minimal images.
@@ -29,11 +28,9 @@ The FROM scratch container is an [official Docker image](https://hub.docker.com/
This will have the smallest attack surface and smallest image size.
### Run Container Processes as Unprivileged
When possible, use a non-privileged user when running processes within your container. While container runtimes provide isolation, vulnerabilities and attacks are still possible. Inadvertent or accidental host mounts can also be impacted if the container is running as root. For details on configuring a security context for a pod or container, refer to the [Kubernetes docs](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
### Define Resource Limits
Apply CPU and memory limits to your pods. This can help manage the resources on your worker nodes and avoid a malfunctioning microservice from impacting other microservices.
In standard Kubernetes, you can set resource limits on the namespace level. In Rancher, you can set resource limits on the project level and they will propagate to all the namespaces within the project. For details, refer to the Rancher docs.
@@ -43,7 +40,6 @@ When setting resource quotas, if you set anything related to CPU or Memory (i.e.
The Kubernetes docs have more information on how resource limits can be set at the [container level](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) and the namespace level.
### Define Resource Requirements
You should apply CPU and memory requirements to your pods. This is crucial for informing the scheduler which type of compute node your pod needs to be placed on, and ensuring it does not over-provision that node. In Kubernetes, you can set a resource requirement by defining `resources.requests` in the resource requests field in a pod's container spec. For details, refer to the [Kubernetes docs](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).
:::note
@@ -52,10 +48,9 @@ If you set a resource limit for the namespace that the pod is deployed in, and t
:::
As a starting point, we recommend setting your CPU request at 50m and memory request at 100Mi. You should choose your limits based on the resources available in your environment and your use case with Rancher. It is recommended to define resource requirements on the container level because otherwise, the scheduler makes assumptions that will likely not be helpful to your application when the cluster experiences load.
It is recommended to define resource requirements on the container level because otherwise, the scheduler makes assumptions that will likely not be helpful to your application when the cluster experiences load.
### Liveness and Readiness Probes
Set up liveness and readiness probes for your container. Unless your container completely crashes, Kubernetes will not know it's unhealthy unless you create an endpoint or mechanism that can report container status. Alternatively, make sure your container halts and crashes if unhealthy.
The Kubernetes docs show how to [configure liveness and readiness probes for containers.](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)