问题描述

nginx容器化时,有一个普遍会遇到的问题:如何自动设置nginx worker process的数量?

nginx官方容器镜像的nginx.conf配置文件中,会有一条worker process配置:

worker_processes  1;

它会配置nginx仅启动1个worker。这在nginx容器为1核时,可以良好的工作。

当我们希望nginx给更高的配置,例如4c或者16c,我们需要确保nginx也能启动响应个数的worker process。有两个办法:

  1. 修改nginx.conf,将worker_processes的个数调整为对应的cpu核数。
  2. 修改nginx.conf,将worker_processes修改为auto。

第一个方法可行,但是需要修改配置文件,nginx需要reload。实际部署时,必须将nginx.conf作为配置文件挂载,对一些不太熟悉nginx的用来说,心智负担会比较重。

第二个方法,在Kubernetes上会遇到一些问题。通过在容器中观察可以发现,nginx启动的worker process,并没有遵循我们给Pod设置的limit,而是与Pod所在node的cpu核数保持一致。

这在宿主机的cpu核数比较多,而Pod的cpu配置较小时,会因为每个worker分配的时间片比较少,带来明显的响应慢的问题。

问题原因

我们知道,在Kubernetes为容器配置cpu的limits为2时,容器其实并不是真正的“分配了”2个cpu,而是通过cgroup进行了限制。

        resources:
          limits:
            cpu: 500m
            memory: 256Mi
          requests:
            cpu: 500m
            memory: 256Mi

我们到这个Pod所在宿主机上去查看相关信息。

# docker inspect 17f5f35c3500|grep -i cgroup
            "Cgroup": "",
            "CgroupParent": "/kubepods/burstable/podb008ccda-9396-11ea-bc20-ecf4bbd63ee8",
            "DeviceCgroupRules": null,
# cd /sys/fs/cgroup/cpu/kubepods/burstable/podb008ccda-9396-11ea-bc20-ecf4bbd63ee8
# cat cpu.cfs_quota_us
200000
# cat cpu.cfs_period_us
100000

可以看到,实际是通过 cpu.cfs_quota_us/cpu.cfs_period_us 来限制该Pod能使用的cpu核数的。

但是nginx的worker_processes,是通过 sysconf(_SC_NPROCESSORS_ONLN) 来查询宿主机上的cpu个数的(getconf _NPROCESSORS_ONLN),我们通过strace来观察下这个过程。

# strace getconf _NPROCESSORS_ONLN
execve("/bin/getconf", ["getconf", "_NPROCESSORS_ONLN"], [/* 23 vars */]) = 0
brk(0)                                  = 0x606000
...
open("/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3
read(3, "0-31\n", 8192)                 = 5
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a922a0000
write(1, "32\n", 332

可见,getconf _NPROCESSORS_ONLN实际是通过读取文件/sys/devices/system/cpu/online来获取cpu个数的。

默认Kubernetes上,/sys/devices/system/cpu/online文件实际就是宿主机的,因此,nginx启动的worker process个数,与宿主机cpu个数一致,也就不奇怪了。

解决方案

解决方案实际也不难想到,修改容器中的/sys/devices/system/cpu/online就行了。

社区的lxcfs已经解决了这个问题。

lxcfs

LXCFS是一个小型的FUSE文件系统,其目的是让Linux容器感觉更像一个虚拟机。LXCFS会关注的procfs中的关键文件:

/proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime
/sys/devices/system/cpu/online

可以看到,我们需要的/sys/devices/system/cpu/online文件,也在lxcfs关注列表中。

lxcfs的使用方法也比较简单,只要将宿主机的/var/lib/lxc/lxcfs/proc/online挂载到容器的/sys/devices/system/cpu/online就可以了。

      containers:
      - args:
        - infinity
        command:
        - sleep
        volumeMounts:
        - mountPath: /sys/devices/system/cpu/online
          name: lxcfs-2
          readOnly: true
      volumes:
      - hostPath:
          path: /var/lib/lxc/lxcfs/proc/online
          type: ""
        name: lxcfs-2

当我们在容器中读取/sys/devices/system/cpu/online文件时,由于kubelet将该文件绑定了/var/lib/lxc/lxcfs/proc/online,该read请求会交给lxcfs daemon来处理。

lxcfs实际处理的函数如下。

int max_cpu_count(const char *cg)
{
	__do_free char *cpuset = NULL;
	int rv, nprocs;
	int64_t cfs_quota, cfs_period;
	int nr_cpus_in_cpuset = 0;

	read_cpu_cfs_param(cg, "quota", &cfs_quota);
	read_cpu_cfs_param(cg, "period", &cfs_period);

	cpuset = get_cpuset(cg);
	if (cpuset)
		nr_cpus_in_cpuset = cpu_number_in_cpuset(cpuset);

	if (cfs_quota <= 0 || cfs_period <= 0){
		if (nr_cpus_in_cpuset > 0)
			return nr_cpus_in_cpuset;

		return 0;
	}

	rv = cfs_quota / cfs_period;

	/* In case quota/period does not yield a whole number, add one CPU for
	 * the remainder.
	 */
	if ((cfs_quota % cfs_period) > 0)
		rv += 1;

	nprocs = get_nprocs();
	if (rv > nprocs)
		rv = nprocs;

	/* use min value in cpu quota and cpuset */
	if (nr_cpus_in_cpuset > 0 && nr_cpus_in_cpuset < rv)
		rv = nr_cpus_in_cpuset;

	return rv;
}

根据前面的信息,可以看到最终返回的值为 200000/100000 = 2。

结论

因此,当有lxcfs的加持时,nginx可以放心的将worker_processes配置为auto,不需要担心启动了过多的worker processes。