Kubernetes下pod控制组管理解析

在 Kubernetes 里面，将资源分成不同的 QoS 类别，并且通过 pod 里面的资源定义来区分 pod 对于平台提供的资源保障的 SLA 等级：

针对不同的优先级的业务，在资源紧张或者超出的时候会有不同的处理策略。

同时，针对 CPU 和内存两类不同类型的资源，一种是可压缩的，一种是不可压缩的，所以资源的分配和调控策略也会有很大区别。

CPU 资源紧缺时，如果节点处于超卖状态，则会根据各自的 requests 配置，按比例分配 CPU 时间片，而内存资源紧缺时需要内核的 oom killer 进行管控，

Kubernetes 负责为 OOM killer 提供管控依据：

OOM 得分主要根据 QoS 类和容器的 requests 内存占机器总内存比来计算：

OOM 得分越高，该进程的优先级越低，越容易被终止；根据公式， Burstable 优先级的 pod 中， requests 内存申请越多，越容易在 OOM 的时候被终止。

首先我们先看下 pod 的控制组层级

其中 kubepods-besteffortslice 存放 besteffort 类型 pod 控制组配置， kubepods-burstableslice 存放 burstable 类型 pod 控制组配置。

kubepods-pod934b0aa2_1d1b_4a81_bfcf_89c4beef899eslice 、 kubepods-podca849e84_aa86_4402_bf31_e7e73faa77feslice 则为 Guaranteed 类型 pod

为了更好的解释说明，我们创建一个新的 Guaranteed 类型的 pod 用于测试:

kubepods-podf56bf66f_3efb_4c80_8818_37de69ee5b72slice 这个名称是怎么命名的呢？

命名格式为： kubepods-pod<pod uid>slice ，并且会将 uid 中 - 转换为 _

我们发现怎么有两个容器呢？（ docker-08974ffd61043b34e4cd5710d5446eb423c6371afb4c9d106e608f08cc1182a3scope 、 docker-d33dc12340fd32b35148293c21f84dab14f2274046056bbeef9e9666d1d0dc2ascope ）

其实是业务容器 + infra 沙箱容器，并且命名格式遵循： docker-<container id>scope

我们可根据以下命令获取业务容器 id ：

我们上述对 pod 配额的定义为:

其实等同于以以下方式启动 docker 容器:

我们可以看下 docker 容器的配额：

HostConfigCpuShares 对应控制内的 cpushares 文件内容

HostConfigCpuPeriod 对应控制内的 cpucpucfs_period_us 文件内容

HostConfigCpuQuota 对应控制内的 cpucfs_quota_us 文件内容

并且我们发现 k8s 基于 pod 管理控制组（同一 pod 内的容器所属同一控制组）

我们可以得出记录： k8s 通过控制组的 cpushares 、 cpucpucfs_period_us 、 cpucfs_quota_us 配置，达到限制 CPU 的目的。

那么这三个文件是用来干嘛的？

当系统中有两个 cgroup ，分别是 A 和 B ， A 的 shares 值是 1024 ，B 的 shares 值是 512 ，

那么 A 将获得 1024/(1024+512)=66% 的 CPU 资源，而 B 将获得 33% 的 CPU 资源。 shares 有两个特点：

从上面两个特点可以看出：

在闲的时候， shares 基本上不起作用，只有在 CPU 忙的时候起作用，这是一个优点。

由于 shares 是一个绝对值，需要和其它 cgroup 的值进行比较才能得到自己的相对限额，而在一个部署很多容器的机器上， cgroup 的数量是变化的，所以这个限额也是变化的，自己设置了一个高的值，但别人可能设置了一个更高的值，所以这个功能没法精确的控制 CPU 使用率。

值对应关系为： resourcesrequestscpu 1024 = cpushares

如： resourcesrequestscpu 为3的时候， cpushares 值为 3072 ； resourcesrequestscpu 为 100m 的时候， cpushares 值为 102

并且 k8s 下容器控制组的 cpucpucfs_period_us 值固定为 100000 ，实际只设置 cpucfs_quota_us 值

例如：

cpucpucfs_period_us 为 100000 （单位微妙，即01秒）， cpucfs_quota_us 为 500000 （单位微妙，即 05 秒）时， resourceslimitscpu 为5，即5个 cpu 核心。

cpucpucfs_period_us 为 100000 （单位微妙，即01秒）， cpucfs_quota_us 为 10000 （单位微妙，即 001 秒）时， resourceslimitscpu 为01（或100m），即01个 cpu 核心。

与 cpu 不同， k8s 里 pod 容器的 requestsmemory 在控制组内没有对应的属性，未起到限制作用，只是协助 k8s 调度计算。

而 pod 容器的 limitsmemory 对应控制组里的 memorylimit_in_bytes 值。

我们已经知道kubernetes的常用术语和一些思想，要想进行二次开发，或者简单的说跑起来，运行一个小实例，那就要求我们需要对ta的常用 *** 作相当的熟悉。入手了解kubectl是非常快速的一个方式，下面，我们就来看看kubectl的命令行 *** 作的常用方式。

1kubectl用法详解

1 kubectl语法

kubectl [command] [Type] [NAME] [flags]

command: 子命令，用于 *** 作kubernetes集群资源对象的命令，例如：create, delete, describe, get, apply等等

TYPE: 资源对象的类型，区分大小写，能以单数，复数或者简写形式表示。例如以下3中TYPE是等价的。

kubectl get pod pod1kubectl get pods pod1kubectl get po pod1

NAME：资源对象的名称，区分大小写。如果不指定名称，系统则将返回属于TYPE的全部对象的列表，例如：kubectl get pods 将返回所有pod的列表

flags: kubectl 子命令的可选参数，例如使用 -s 指定api server的url地址而不用默认值。

kubectl可 *** 作的资源对象类型以及缩写：

在一个命令行中也可以同时对多个资源对象进行 *** 作，以多个TYPE和NAME的组合表示，示例如下：

获取多个pod的信息：

kubectlgetpods pod1 pod2

获取多种对象的信息：

kubectlgetpod/pod1  rc/rc1

同时应用多个YAML文件，以多个-f file参数表示：

kubectlgetpod-fpod1yaml-fpod2yamlkubectlcreate-fpod1yaml-frc1yaml-fservice1yaml

2kubectl 子命令详解

kebectl的子命令非常丰富，涵盖了对kubernetes集群的主要 *** 作，包括资源对象的创建、删除、查看、修改、配置、运行等，详细的子命令如表210所示：

3kubectl参数列表

Kubectl命令行的公共启动参数如下所示：

4Kubectl 输出格式

kubectl命令可以用多种格式对结果进行显示，输出的格式通过-o参数指定：

5kubectl *** 作示例

1、根据yaml配置文件一次性创建service和rc

kubectlcreate-fmy-serviceyaml-fmy-rcyaml

2、根据目录下所有yaml、yml、json文件的定义进行创建 *** 作

kubectlcreate-f

3、查看所有Pod列表

kubectlgetpods

4、查看rc和service列表

kubectlgetrc,service

5、显示Node的详细信息

kubectldescribenodes

6、显示Pod的详细信息

kubectldescribepods/

7、显示由RC管理的Pod信息

kubectldescribepods

8、删除基于podyaml文件定义的Pod

kubectldelete-f podyaml

9、删除所有包含某个label的Pod和Service

kubectldeletepods,services -lname=

10、删除所有Pod

kubectldeletepods--all

11、在Pod的容器里执行date命令，默认使用Pod中的第1个容器执行

kubectlexec date

12、指定Pod中某个容器执行date命令

kubectl exec-cdate

13、以bash方式登陆到Pod中的某个容器里

kubectl exec -it-c/bin/bash

14、查看容器输出到stdout的日志

kubectl logs

15、跟踪查看容器的日志，相当于tail -f命令的结果

kubectl logs -f-c

以上就是本次分享的全部内容，现在想要学习的小伙伴欢迎关注六星社区，获取更多技能与教程。

openstack 的软路由，虚拟机port已经在用internal port来接入ovs bridge，而且在性能上确实比veth-pair有提升

ovs-internal-port 111-114Gb/s (1 process) 129-133Gb/s (4 process)

veth-pair-device 108-110Gb/s (1 process) 118-122Gb/s (4 process)

但是k8s获取pod ip的方式就是通过 eth0来获取的，这是一个硬编码。

这样就要求pod内部必须要有一个eth0网卡。

为了使用internal port，

可以先创建port，接入到br-int，（不同pod使用不同的port 名）

然后将该port设备，放入pod ns内部，并进行重命名。

那么问题来了，当创建新的port的时候，或者重启openvswitch。

已经配置好的port就会从pod ns内部移出。 这样就会导致网络问题。

如果不这样做，就需要采用两个网卡的方案，用原生port名直接放进去，配置好ip，然后弄一个dummy eth0网卡，也配上ip。

但是这个逻辑又过于复杂，pod内部多网卡也不够简洁。

结论： ovs 对internal 网卡的重命名支持的不够好。

>

以上就是关于Kubernetes下pod控制组管理解析全部的内容，包括:Kubernetes下pod控制组管理解析、K8s kubectl 常用命令总结，建议收藏！、关于k8s使用ovs internal port的一些问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！