From edd9f47033a5ae4137b27a9cfa279fa644beeb0c Mon Sep 17 00:00:00 2001 From: Billy Tat Date: Mon, 22 Apr 2024 15:00:30 -0700 Subject: [PATCH 1/3] Add cattle cluster agent cpu and mem request recommendation --- .../rancher-managed-clusters/tips-to-set-up-containers.md | 7 +++++++ .../rancher-managed-clusters/tips-to-set-up-containers.md | 7 ++++++- .../rancher-managed-clusters/tips-to-set-up-containers.md | 7 ++++++- 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md b/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md index 0cec0a91864..343cb9fd151 100644 --- a/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md +++ b/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md @@ -21,6 +21,7 @@ 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. @@ -28,9 +29,11 @@ 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. @@ -40,6 +43,7 @@ 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 @@ -50,7 +54,10 @@ 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/) diff --git a/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md b/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md index 0cec0a91864..98dfae1ffaa 100644 --- a/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md +++ b/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md @@ -21,6 +21,7 @@ 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. @@ -28,9 +29,11 @@ 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. @@ -40,6 +43,7 @@ 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 @@ -48,9 +52,10 @@ 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. +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. ### 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/) diff --git a/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md b/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md index 0cec0a91864..98dfae1ffaa 100644 --- a/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md +++ b/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md @@ -21,6 +21,7 @@ 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. @@ -28,9 +29,11 @@ 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. @@ -40,6 +43,7 @@ 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 @@ -48,9 +52,10 @@ 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. +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. ### 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/) From 6a52c6b462cd9a3d240cac6208f7ffa4e0275e6b Mon Sep 17 00:00:00 2001 From: Billy Tat Date: Mon, 29 Apr 2024 16:48:22 -0700 Subject: [PATCH 2/3] Move cattle agent cpu and mem rec to cluster agent specific page. Revert additions to incorrect pages --- .../about-rancher-agents.md | 55 ++++++++++++++++++- .../tips-to-set-up-containers.md | 7 --- .../about-rancher-agents.md | 55 ++++++++++++++++++- .../tips-to-set-up-containers.md | 7 +-- .../about-rancher-agents.md | 55 ++++++++++++++++++- .../tips-to-set-up-containers.md | 7 +-- 6 files changed, 161 insertions(+), 25 deletions(-) diff --git a/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md b/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md index 2d98149dae2..57d3611f5b1 100644 --- a/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md +++ b/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md @@ -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: + + + + +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. + + + + +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. + + + + +If you prefer to configure via YAML, add the following snippet to your configuration file: + + + + +```yaml +cluster_agent_deployment_customization: + override_resource_requirements: + requests: + cpu: 50m + memory: 100Mi +``` + + + + +```yaml +spec: + clusterAgentDeploymentCustomization: + overrideResourceRequirements: + requests: + cpu: 50m + memory: 100Mi +``` + + + + ### 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 | | ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ | diff --git a/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md b/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md index 343cb9fd151..0cec0a91864 100644 --- a/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md +++ b/docs/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md @@ -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/) diff --git a/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md b/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md index 2d98149dae2..57d3611f5b1 100644 --- a/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md +++ b/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md @@ -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: + + + + +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. + + + + +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. + + + + +If you prefer to configure via YAML, add the following snippet to your configuration file: + + + + +```yaml +cluster_agent_deployment_customization: + override_resource_requirements: + requests: + cpu: 50m + memory: 100Mi +``` + + + + +```yaml +spec: + clusterAgentDeploymentCustomization: + overrideResourceRequirements: + requests: + cpu: 50m + memory: 100Mi +``` + + + + ### 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 | | ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ | diff --git a/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md b/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md index 98dfae1ffaa..0cec0a91864 100644 --- a/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md +++ b/versioned_docs/version-2.7/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md @@ -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/) diff --git a/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md b/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md index 2d98149dae2..57d3611f5b1 100644 --- a/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md +++ b/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md @@ -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: + + + + +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. + + + + +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. + + + + +If you prefer to configure via YAML, add the following snippet to your configuration file: + + + + +```yaml +cluster_agent_deployment_customization: + override_resource_requirements: + requests: + cpu: 50m + memory: 100Mi +``` + + + + +```yaml +spec: + clusterAgentDeploymentCustomization: + overrideResourceRequirements: + requests: + cpu: 50m + memory: 100Mi +``` + + + + ### 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 | | ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ | diff --git a/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md b/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md index 98dfae1ffaa..0cec0a91864 100644 --- a/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md +++ b/versioned_docs/version-2.8/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers.md @@ -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/) From 8b71096b32e125601735361546d2781c552d0d28 Mon Sep 17 00:00:00 2001 From: Billy Tat Date: Tue, 30 Apr 2024 11:04:41 -0700 Subject: [PATCH 3/3] Apply feedback --- .../launch-kubernetes-with-rancher/about-rancher-agents.md | 6 +++--- .../launch-kubernetes-with-rancher/about-rancher-agents.md | 6 +++--- .../launch-kubernetes-with-rancher/about-rancher-agents.md | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md b/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md index 57d3611f5b1..375397eb513 100644 --- a/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md +++ b/docs/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md @@ -23,21 +23,21 @@ The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Ku ### 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. +The `cattle-cluster-agent` pod does not define the 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 assess your use case appropriately and that you allocate the correct resources to your cluster for your needs. To configure request values through the UI: -1. When you create or edit an existing cluster, go to the **Cluster Options** section. +1. When you [create](./launch-kubernetes-with-rancher.md) 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. -1. When you create or edit an existing cluster, go to the **Cluster Configuration**. +1. When you [create](./launch-kubernetes-with-rancher.md) 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. diff --git a/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md b/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md index 57d3611f5b1..375397eb513 100644 --- a/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md +++ b/versioned_docs/version-2.7/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md @@ -23,21 +23,21 @@ The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Ku ### 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. +The `cattle-cluster-agent` pod does not define the 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 assess your use case appropriately and that you allocate the correct resources to your cluster for your needs. To configure request values through the UI: -1. When you create or edit an existing cluster, go to the **Cluster Options** section. +1. When you [create](./launch-kubernetes-with-rancher.md) 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. -1. When you create or edit an existing cluster, go to the **Cluster Configuration**. +1. When you [create](./launch-kubernetes-with-rancher.md) 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. diff --git a/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md b/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md index 57d3611f5b1..375397eb513 100644 --- a/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md +++ b/versioned_docs/version-2.8/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md @@ -23,21 +23,21 @@ The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Ku ### 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. +The `cattle-cluster-agent` pod does not define the 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 assess your use case appropriately and that you allocate the correct resources to your cluster for your needs. To configure request values through the UI: -1. When you create or edit an existing cluster, go to the **Cluster Options** section. +1. When you [create](./launch-kubernetes-with-rancher.md) 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. -1. When you create or edit an existing cluster, go to the **Cluster Configuration**. +1. When you [create](./launch-kubernetes-with-rancher.md) 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.