> For the complete documentation index, see [llms.txt](https://platform9.com/kb/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://platform9.com/kb/pmk/solutions/ability-to-define-specific-cpus-cores-for-etcd-container.md).

# Ability to Define Specific CPUs/Cores for ETCD container

## Problem

In production environments it is required to have the ability to define the specific CPUs or cores for the ETCD container, so as to ensure it does not impact other applications using guaranteed CPUs as defined via kubelet’s cpu manager policy.

## Environment

* Platform9 Edge Cloud - v5.3.
* Kuberneted version-1.20.

## Cause

Since ETCD runs as Docker container and is not managed by Kubelet, it doesn't inherit the kubelet cpu manager policy and by default has usage of all available cpus in the system.

## Workaround

{% hint style="warning" %}
**Warning**

The below change will not persist across cluster upgrade
{% endhint %}

Please find the steps below to set specific CPUs for ETCD container. Note that the same will have to be done on each master node part of the cluster, one node at a time to ensure quorum is maintained

1. Stop the Stack and set required permission:

{% tabs %}
{% tab title="Master node" %}

```javascript
$ sudo systemctl stop pf9-hostagent pf9-nodeletd
$ sudo /opt/pf9/nodelet/nodeletd phases stop
$ sudo chmod 644 /opt/pf9/pf9-kube/master_utils.sh
```

{% endtab %}
{% endtabs %}

2. Edit the file `/opt/pf9/pf9-kube/master_utils.sh` to add `cpuset-cpus` argument:

{% tabs %}
{% tab title="Master node" %}

```javascript
$ sudo vi /opt/pf9/pf9-kube/master_utils.sh
...
function ensure_etcd_running()
{
    local node_endpoint=$1

    mkdir -p "$ETCD_DATA_DIR"
    chmod 0700 "$ETCD_DATA_DIR"

    local etcd_log_level="info"
    if [[ "${DEBUG}" == 'true' ]]; then
        etcd_log_level="debug"
    fi

    # ETCD_LOG_LEVEL: --debug flag and ETCD_DEBUG to be deprecated in v3.5
    # ETCD_LOGGER: default logger capnslog to be deprecated in v3.5, using zap
    # ETCD_ENABLE_V2: Need this for flannel's compatibility with etcd v3.4.14
    local run_opts="--net=host \
        --detach=true \
        --cpuset-cpus=0-3 \        <----- Adding required argument "cpuset-cpus"
        --volume /etc/ssl:/etc/ssl \
        --volume /etc/pki:/etc/pki \
        --volume /etc/pf9/kube.d/certs/etcd:/certs/etcd \
        --volume /etc/pf9/kube.d/certs/apiserver:/certs/apiserver \
        --volume ${ETCD_DATA_DIR}:/var/etcd/data \
        -e ETCD_LOG_LEVEL=${etcd_log_level} \
        -e ETCD_LOGGER=zap \
        -e ETCD_ENABLE_V2=true \
        -e ETCD_PEER_CLIENT_CERT_AUTH=true"


$ sudo cat /opt/pf9/pf9-kube/master_utils.sh | grep cpuset
        --cpuset-cpus=0-3 \
```

{% endtab %}
{% endtabs %}

{% hint style="info" %}
**Info**

Reference: <https://docs.docker.com/config/containers/resource_constraints/#configure-the-default-cfs-scheduler>.
{% endhint %}

3. Start the stack

{% tabs %}
{% tab title="Master node" %}

```javascript
$ sudo systemctl start pf9-hostagent
```

{% endtab %}
{% endtabs %}

4. Validation post stack startup:

{% tabs %}
{% tab title="Javascript" %}

```javascript
$ sudo docker inspect etcd | grep CpusetCpus
            "CpusetCpus": "0-3",

$ taskset -pc 12815
pid 12815's current affinity list: 0-3
```

{% endtab %}
{% endtabs %}

## Resolution

To persist the changes across upgrades the internal configurations will be reconfigured in the SMCP-5.11 release.

## Additional Information

The ETA for the release SMCP-5.11 is not confirmed, you can track the progress by opening a support request mentioning the jira id- AIR-659.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://platform9.com/kb/pmk/solutions/ability-to-define-specific-cpus-cores-for-etcd-container.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
