docker 部署微服务:一台宿主机一个 docker 容器开着吗?那么性能会不会有限制?类似 vm 那种?

今天在听架构课程时候,听到了多台机器,我们使用docker来进行部署服务,使用K8S集群管理。

那么本人就突然有疑问,多台主机,一个主机一个docker吗?性能如何分配?比如cpu 内存 磁盘空间等。

答案是:一台电脑,一个docker执行。
具体参考如下。
如果你对我的观点有疑问,可以联系我。

docker注意点

大家需要注意,Docker本身并不是容器,它是创建容器的工具,是应用容器引擎。

想要搞懂Docker,其实看它的两句口号就行。

第一句,是“Build, Ship and Run”。

k8s 注意点

就在Docker容器技术被炒得热火朝天之时,大家发现,如果想要将Docker应用于具体的业务实现,是存在困难的——编排、管理和调度等各个方面,都不容易。于是,人们迫切需要一套管理系统,对Docker及容器进行更高级更灵活的管理。

就在这个时候,K8S出现了。

K8S,就是基于容器的集群管理平台,它的全称,是kubernetes。
Kubernetes 这个单词来自于希腊语,含义是舵手或领航员。K8S是它的缩写,用“8”字替代了“ubernete”这8个字符。

Docker容器CPU、memory资源限制

背景

在使用 docker 运行容器时,默认的情况下,docker没有对容器进行硬件资源的限制,当一台主机上运行几百个容器,这些容器虽然互相隔离,但是底层却使用着相同的 CPU、内存和磁盘资源。如果不对容器使用的资源进行限制,那么容器之间会互相影响,小的来说会导致容器资源使用不公平;大的来说,可能会导致主机和集群资源耗尽,服务完全不可用。

docker 作为容器的管理者,自然提供了控制容器资源的功能。正如使用内核的 namespace 来做容器之间的隔离,docker 也是通过内核的 cgroups 来做容器的资源限制;包括CPU、内存、磁盘三大方面,基本覆盖了常见的资源配额和使用量控制。

Docker内存控制OOME在linxu系统上,如果内核探测到当前宿主机已经没有可用内存使用,那么会抛出一个OOME(Out Of Memory Exception:内存异常 ),并且会开启killing去杀掉一些进程。

一旦发生OOME,任何进程都有可能被杀死,包括docker daemon在内,为此,docker特地调整了docker daemon的OOM_Odj优先级,以免他被杀掉,但容器的优先级并未被调整。经过系统内部复制的计算后,每个系统进程都会有一个OOM_Score得分,OOM_Odj越高,得分越高,(在docker run的时候可以调整OOM_Odj)得分最高的优先被kill掉,当然,也可以指定一些特定的重要的容器禁止被OMM杀掉,在启动容器时使用 –oom-kill-disable=true指定。

cgroup简介

cgroup是Control Groups的缩写,是Linux 内核提供的一种可以限制、记录、隔离进程组所使用的物理资源(如 cpu、memory、磁盘IO等等) 的机制,被LXC、docker等很多项目用于实现进程资源控制。cgroup将任意进程进行分组化管理的 Linux 内核功能。cgroup本身是提供将进程进行分组化管理的功能和接口的基础结构,I/O 或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。这些具体的资源管理功能称为cgroup子系统,有以下几大子系统实现:

  1. blkio:设置限制每个块设备的输入输出控制。例如:磁盘,光盘以及usb等等。
  2. cpu:使用调度程序为cgroup任务提供cpu的访问。 cpuacct:产生cgroup任务的cpu资源报告。
  3. cpuset:如果是多核心的cpu,这个子系统会为cgroup任务分配单独的cpu和内存。
  4. devices:允许或拒绝cgroup任务对设备的访问。
  5. freezer:暂停和恢复cgroup任务。
  6. memory:设置每个cgroup的内存限制以及产生内存资源报告。
  7. net_cls:标记每个网络包以供cgroup方便使用。
  8. ns:命名空间子系统。
  9. perf_event:增加了对每group的监测跟踪的能力,即可以监测属于某个特定的group的所有线程以及运行在特定CPU上的线程。

目前docker只是用了其中一部分子系统,实现对资源配额和使用的控制。

内存限制

Docker 提供的内存限制功能有以下几点:

容器能使用的内存和交换分区大小。
容器的核心内存大小。
容器虚拟内存的交换行为。
容器内存的软性限制。
是否杀死占用过多内存的容器。
容器被杀死的优先级
一般情况下,达到内存限制的容器过段时间后就会被系统杀死。

详细的省略了

CPU 限制

概述
Docker 的资源限制和隔离完全基于 Linux cgroups。对 CPU 资源的限制方式也和 cgroups 相同。Docker 提供的 CPU 资源限制选项可以在多核系统上限制容器能利用哪些 vCPU。而对容器最多能使用的 CPU 时间有两种限制方式:一是有多个 CPU 密集型的容器竞争 CPU 时,设置各个容器能使用的 CPU 时间相对比例。二是以绝对的方式设置容器在每个调度周期内最多能使用的 CPU 时间。

磁盘IO配额控制

相对于CPU和内存的配额控制,docker对磁盘IO的控制相对不成熟,大多数都必须在有宿主机设备的情况下使用。主要包括以下参数:

  1. –device-read-bps:限制此设备上的读速度(bytes per second),单位可以是kb、mb或者gb。
  2. –device-read-iops:通过每秒读IO次数来限制指定设备的读速度。
  3. –device-write-bps :限制此设备上的写速度(bytes per second),单位可以是kb、mb或者gb。
  4. –device-write-iops:通过每秒写IO次数来限制指定设备的写速度。
  5. –blkio-weight:容器默认磁盘IO的加权值,有效值范围为10-100。
  6. –blkio-weight-device: 针对特定设备的IO加权控制。其格式为DEVICE_NAME:WEIGHT

存储配额控制的相关参数,可以参考Red Hat文档中blkio这一章,了解它们的详细作用。

容器空间大小限制

在docker使用devicemapper作为存储驱动时,默认每个容器和镜像的最大大小为10G。如果需要调整,可以在daemon启动参数中,使用dm.basesize来指定,但需要注意的是,修改这个值,不仅仅需要重启docker daemon服务,还会导致宿主机上的所有本地镜像和容器都被清理掉。

使用aufs或者overlay等其他存储驱动时,没有这个限制。

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!