<commit_before>---
title: Kubernetes 上的 TiDB 集群环境需求
category: how-to
aliases: ['/docs-cn/v3.0/how-to/deploy/tidb-in-kubernetes/prerequisites/']
---

# Kubernetes 上的 TiDB 集群环境需求

本文介绍在 Kubernetes 上部署 TiDB 集群的软硬件环境需求。

## 软件版本要求

| 软件名称 | 版本 |
| :--- | :--- |
| Docker | Docker CE 18.09.6 |
| Kubernetes | v1.12.5+ |
| CentOS | CentOS 7.6，内核要求为 3.10.0-957 或之后版本 |

## 内核参数设置

| 配置项 | 设置值 |
| :--- | :--- |
| net.core.somaxconn | 32768 |
| vm.swappiness | 0 |
| net.ipv4.tcp_syncookies | 0 |
| net.ipv4.ip_forward | 1 |
| fs.file-max | 1000000 |
| fs.inotify.max_user_watches | 1048576 |
| fs.inotify.max_user_instances | 1024 |
| net.ipv4.conf.all.rp_filter | 1 |
| net.ipv4.neigh.default.gc_thresh1 | 80000 |
| net.ipv4.neigh.default.gc_thresh2 | 90000 |
| net.ipv4.neigh.default.gc_thresh3 | 100000 |
| net.bridge.bridge-nf-call-iptables | 1 |
| net.bridge.bridge-nf-call-arptables | 1 |
| net.bridge.bridge-nf-call-ip6tables | 1 |

在设置 `net.bridge.bridge-nf-call-*` 这几项参数时，如果选项报错，则可通过如下命令检查是否已经加载该模块：

{{< copyable "shell-regular" >}}

```shell
lsmod|grep br_netfilter
```

如果没有加载，则执行如下命令加载：

{{< copyable "shell-regular" >}}

```shell
modprobe br_netfilter
```

同时还需要关闭每个部署 Kubernetes 节点的 swap，执行如下命令：

{{< copyable "shell-regular" >}}

```shell
swapoff -a
```

执行如下命令检查 swap 是否已经关闭：

{{< copyable "shell-regular" >}}

```shell
free -m
```

如果执行命令后输出显示 swap 一列全是 0，则表明 swap 已经关闭。

此外，为了永久性地关闭 swap，还需要将 `/etc/fstab` 中 swap 相关的条目全部删除。

在上述内容都设置完成后，还需要检查是否给机器配置了[SMP IRQ Affinity](https://cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt)，也就是将各个设备对应的中断号分别绑定到不同的 cpu 上，防止所有中断请求都落在一个 cpu 上而引发性能瓶颈。对于 tidb 集群来说网卡处理包的速度对集群的吞吐率影响很大，因此这里我们主要说一下怎么将网卡中断绑定到特定的 cpu 上，充分利用多核的优势提高集群的吞吐率，首先我们可以通过如下命令查看网卡对应的中断号：

{{< copyable "shell-regular" >}}

```shell
cat /proc/interrupts|grep <iface-name>|awk '{print $1,$NF}'
```

上面命令输出的第一列是中断号，第二列是设备名称，如果是多队列网卡上面的命令会显示有多行信息，网卡的每个队列对应一个中断号。通过如下的命令可以得知此中断号被绑定到具体哪个 cpu 上。

```shell
## 这个值展示的是对应的 cpu 序号的十六进制，不是很直观，具体计算方法见上面给出的官方文档 SMP IRQ Affinity
cat /proc/irq/<ir_num>/smp_affinity

## 下面这个值展示的是 cpu 序号对应的十进制数字，比较直观
cat /proc/irq/<ir_num>/smp_affinity_list
```

如果多队列网卡对应的所有中断号都被绑定到不同的 cpu 上，那么这个配置就是没问题的。如果都落在一个 cpu 上那需要调整，调整的方式有两种，一种是通过开启 irqbalance 服务来达到目的。还有一种方式是禁掉 irqbalance，自定义中断号和 cpu 的绑定关系，详情参见脚本 [set_irq_affinity.sh](https://gist.githubusercontent.com/SaveTheRbtz/8875474/raw/0c6e500e81e161505d9111ac77115a2367180d12/set_irq_affinity.sh)

上面说的是处理多队列网卡和多核心的情形，如果是单队列网卡和多核的情况则有所不同。对于这个情况我们可以使用 [RPS/RFS](https://www.kernel.org/doc/Documentation/networking/scaling.txt) 在软件层面模拟实现硬件的网卡多队列功能(RSS)，这种情况下不能使用 irqbalance 来达到目的，可以通过使用上面贴出的脚本来设置 RPS，至于 RFS 的配置可以参考网上的配置即可。

## 硬件和部署要求

与使用 binary 方式部署 TiDB 集群一致，要求选用 Intel x86-64 架构的 64 位通用硬件服务器，使用万兆网卡。关于 TiDB 集群在物理机上的具体部署需求，参考[这里](/v3.0/how-to/deploy/hardware-recommendations.md)。

对于服务器 disk、memory、CPU 的选择要根据对集群的容量规划以及部署拓扑来定。线上 Kubernetes 集群部署为了保证高可用，一般需要部署三个 master 节点、三个 etcd 节点以及若干个 worker 节点。同时，为了充分利用机器资源，master 节点一般也充当 worker 节点（也就是 master 节点上也可以调度负载）。通过 kubelet 设置[预留资源](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/)来保证机器上的系统进程以及 Kubernetes 的核心进程在工作负载很高的情况下仍然有足够的资源来运行，从而保证整个系统的稳定。

下面按 3 Kubernetes master + 3 etcd + 若干 worker 节点部署方案进行分析。Kubernetes 的多 master 节点高可用部署可参考[官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/)。

## Kubernetes 系统资源要求

- 每台机器需要一块比较大的 SAS 盘（至少 1T），这块盘用来存 Docker 和 kubelet 的数据目录。Docker 的数据主要包括镜像和容器日志数据，kubelet 主要占盘的数据是 [emptyDir](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) 所使用的数据。

- 如果需要部署 Kubernetes 集群的监控系统, 且监控数据需要落盘，则也需要考虑为 Prometheus 准备一块 SAS 盘，后面日志监控系统也需要大的 SAS 盘，同时考虑到机器采购最好是同构的这一因素，因此每台机器最好有两块大的 SAS 盘。

    > **注意：**
    >
    > 生产环境建议给这两种类型的盘做 RAID5，至于使用多少块来做 RAID5 可自己决定。

- etcd 的分布建议是和 Kubernetes master 节点保持一致，即有多少个 master 节点就部署多少个 etcd 节点。etcd 数据建议使用 SSD 盘存放。

## TiDB 集群资源需求

TiDB 集群由 PD、TiKV、TiDB 三个组件组成，在做容量规划的时候一般按照可以支持多少套 TiDB 集群来算。这里按照标准的 TiDB 集群（3 个 PD + 3 个 TiKV + 2 个 TiDB）来算，下面是对每个组件规划的一种建议：

- PD 组件：PD 占用资源较少，这种集群规模下分配 2C 4GB 即可，占用少量本地盘。

    为了便于管理，可以将所有集群的 PD 都放在 master 节点，比如需要支持 5 套 TiDB 集群，则可以规划 3 个 master 节点，每个节点支持部署 5 个 PD 实例，5 个 PD 实例使用同一块 SSD 盘即可（两三百 GB 的盘即可）。通过 bind mount 的方式在这块 SSD 上创建 5 个目录作为挂载点，操作方式见[文档](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/docs/operations.md#sharing-a-disk-filesystem-by-multiple-filesystem-pvs)。<commit_msg>address comment<commit_after>---
title: Kubernetes 上的 TiDB 集群环境需求
category: how-to
aliases: ['/docs-cn/v3.0/how-to/deploy/tidb-in-kubernetes/prerequisites/']
---

# Kubernetes 上的 TiDB 集群环境需求

本文介绍在 Kubernetes 上部署 TiDB 集群的软硬件环境需求。

## 软件版本要求

| 软件名称 | 版本 |
| :--- | :--- |
| Docker | Docker CE 18.09.6 |
| Kubernetes | v1.12.5+ |
| CentOS | CentOS 7.6，内核要求为 3.10.0-957 或之后版本 |

## 内核参数设置

| 配置项 | 设置值 |
| :--- | :--- |
| net.core.somaxconn | 32768 |
| vm.swappiness | 0 |
| net.ipv4.tcp_syncookies | 0 |
| net.ipv4.ip_forward | 1 |
| fs.file-max | 1000000 |
| fs.inotify.max_user_watches | 1048576 |
| fs.inotify.max_user_instances | 1024 |
| net.ipv4.conf.all.rp_filter | 1 |
| net.ipv4.neigh.default.gc_thresh1 | 80000 |
| net.ipv4.neigh.default.gc_thresh2 | 90000 |
| net.ipv4.neigh.default.gc_thresh3 | 100000 |
| net.bridge.bridge-nf-call-iptables | 1 |
| net.bridge.bridge-nf-call-arptables | 1 |
| net.bridge.bridge-nf-call-ip6tables | 1 |

在设置 `net.bridge.bridge-nf-call-*` 这几项参数时，如果选项报错，则可通过如下命令检查是否已经加载该模块：

{{< copyable "shell-regular" >}}

```shell
lsmod|grep br_netfilter
```

如果没有加载，则执行如下命令加载：

{{< copyable "shell-regular" >}}

```shell
modprobe br_netfilter
```

同时还需要关闭每个部署 Kubernetes 节点的 swap，执行如下命令：

{{< copyable "shell-regular" >}}

```shell
swapoff -a
```

执行如下命令检查 swap 是否已经关闭：

{{< copyable "shell-regular" >}}

```shell
free -m
```

如果执行命令后输出显示 swap 一列全是 0，则表明 swap 已经关闭。

此外，为了永久性地关闭 swap，还需要将 `/etc/fstab` 中 swap 相关的条目全部删除。

在上述内容都设置完成后，还需要检查是否给机器配置了[SMP IRQ Affinity](https://cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt)，也就是将各个设备对应的中断号分别绑定到不同的 cpu 上，防止所有中断请求都落在一个 cpu 上而引发性能瓶颈。对于 tidb 集群来说网卡处理包的速度对集群的吞吐率影响很大，因此这里我们主要说一下怎么将网卡中断绑定到特定的 cpu 上，充分利用多核的优势提高集群的吞吐率，首先我们可以通过如下命令查看网卡对应的中断号：

{{< copyable "shell-regular" >}}

```shell
cat /proc/interrupts|grep <iface-name>|awk '{print $1,$NF}'
```

上面命令输出的第一列是中断号，第二列是设备名称，如果是多队列网卡上面的命令会显示有多行信息，网卡的每个队列对应一个中断号。通过如下的命令可以得知此中断号被绑定到具体哪个 cpu 上。

{{< copyable "shell-regular" >}}

```shell
## 这个值展示的是对应的 cpu 序号的十六进制，不是很直观，具体计算方法见上面给出的官方文档 SMP IRQ Affinity
cat /proc/irq/<ir_num>/smp_affinity

## 下面这个值展示的是 cpu 序号对应的十进制数字，比较直观
cat /proc/irq/<ir_num>/smp_affinity_list
```

如果多队列网卡对应的所有中断号都被绑定到不同的 cpu 上，那么这个配置就是没问题的。如果都落在一个 cpu 上那需要调整，调整的方式有两种，一种是通过开启 [irqbalance](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-tool_reference-irqbalance) 服务来达到目的。在 centos7 上开启命令如下:

{{< copyable "shell-regular" >}}

```shell
systemctl start irqbalance
```

还有一种方式是禁掉 irqbalance，自定义中断号和 cpu 的绑定关系，详情参见脚本 [set_irq_affinity.sh](https://gist.githubusercontent.com/SaveTheRbtz/8875474/raw/0c6e500e81e161505d9111ac77115a2367180d12/set_irq_affinity.sh)

上面说的是处理多队列网卡和多核心的情形，如果是单队列网卡和多核的情况则有所不同。对于这个情况我们可以使用 [RPS/RFS](https://www.kernel.org/doc/Documentation/networking/scaling.txt) 在软件层面模拟实现硬件的网卡多队列功能(RSS)，这种情况下不能使用 irqbalance 来达到目的，可以通过使用上面贴出的脚本来设置 RPS，至于 RFS 的配置可以参考网上的配置即可。

## 硬件和部署要求

与使用 binary 方式部署 TiDB 集群一致，要求选用 Intel x86-64 架构的 64 位通用硬件服务器，使用万兆网卡。关于 TiDB 集群在物理机上的具体部署需求，参考[这里](/v3.0/how-to/deploy/hardware-recommendations.md)。

对于服务器 disk、memory、CPU 的选择要根据对集群的容量规划以及部署拓扑来定。线上 Kubernetes 集群部署为了保证高可用，一般需要部署三个 master 节点、三个 etcd 节点以及若干个 worker 节点。同时，为了充分利用机器资源，master 节点一般也充当 worker 节点（也就是 master 节点上也可以调度负载）。通过 kubelet 设置[预留资源](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/)来保证机器上的系统进程以及 Kubernetes 的核心进程在工作负载很高的情况下仍然有足够的资源来运行，从而保证整个系统的稳定。

下面按 3 Kubernetes master + 3 etcd + 若干 worker 节点部署方案进行分析。Kubernetes 的多 master 节点高可用部署可参考[官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/)。

## Kubernetes 系统资源要求

- 每台机器需要一块比较大的 SAS 盘（至少 1T），这块盘用来存 Docker 和 kubelet 的数据目录。Docker 的数据主要包括镜像和容器日志数据，kubelet 主要占盘的数据是 [emptyDir](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) 所使用的数据。

- 如果需要部署 Kubernetes 集群的监控系统, 且监控数据需要落盘，则也需要考虑为 Prometheus 准备一块 SAS 盘，后面日志监控系统也需要大的 SAS 盘，同时考虑到机器采购最好是同构的这一因素，因此每台机器最好有两块大的 SAS 盘。

    > **注意：**
    >
    > 生产环境建议给这两种类型的盘做 RAID5，至于使用多少块来做 RAID5 可自己决定。

- etcd 的分布建议是和 Kubernetes master 节点保持一致，即有多少个 master 节点就部署多少个 etcd 节点。etcd 数据建议使用 SSD 盘存放。

## TiDB 集群资源需求

TiDB 集群由 PD、TiKV、TiDB 三个组件组成，在做容量规划的时候一般按照可以支持多少套 TiDB 集群来算。这里按照标准的 TiDB 集群（3 个 PD + 3 个 TiKV + 2 个 TiDB）来算，下面是对每个组件规划的一种建议：

- PD 组件：PD 占用资源较少，这种集群规模下分配 2C 4GB 即可，占用少量本地盘。

    为了便于管理，可以将所有集群的 PD 都放在 master 节点，比如需要支持 5 套 TiDB 集群，则可以规划 3 个 master 节点，每个节点支持部署 5 个 PD 实例，5 个 PD 实例使用同一块 SSD 盘即可（两三百 GB 的盘即可）。通过 bind mount 的方式在这块 SSD 上创建 5 个目录作为挂载点，操作方式见[文档](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/docs/operations.md#sharing-a-disk-filesystem-by-multiple-filesystem-pvs)。
{'fraction_non_alphanumeric': 0.12825072238275173, 'fraction_numerical': 0.03111802622805068, 'mean_word_length': 5.530478955007257, 'pattern_counts': {'":': 0, '<': 21, '<?xml version=': 0, '>': 27, 'https://': 15, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '127233', 'n_tokens_mistral': 5714, 'n_tokens_neox': 6147, 'n_words': 621}