作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。
在Docker里面是是可以通过cgroup来限制容器的资源占用，并且是通过docker run 然后添加限制参数来实现的，但是k8s并没有直接这样的参数，它又是通过什么方式来限制呢？
在k8s的资源里面给我们添加request和limit2个配置，通过配置这个2个配置来实现资源的限制。
在 Kubernetes 配置文件中，requests 和 limits 是与资源管理相关的两个重要概念，它们都在 spec 部分的 containers 字段下定义。这两个设置用于控制 Pod 中容器可以使用的资源量，通常指的是 CPU 和内存资源。
以下是 requests 和 limits 在容器配置中的示例用法：
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi" # 请求内存：64 MiB
cpu: "250m" # 请求 CPU：250 毫核 (0.25 核)
limits:
memory: "128Mi" # 内存限制：128 MiB
cpu: "500m" # CPU 限制：500 毫核 (0.5 核)
解释
-
requests：定义了容器启动时最小的资源需求量。 -
memory: "64Mi"：此容器在创建时，至少需要 64MiB 的内存才能运行。 -
cpu: "250m"：此容器在创建时，至少需要 0.25 CPU 核心的处理能力。在 Kubernetes 中，1 CPU 等于云供应商的 1 vCPU/Core 或者物理 CPU 的 1 核心。 -
这个request实际上和资源限制的cgroup完全没有关系，它只在调度的时候有用。如果出现资源不足的情况，则会出现调度失败；如果所有节点都没有足够的资源，则pod无法调度到节点(也就是pod无法落到某一个具体的节点)。
-
limits：定义了容器运行过程中可以使用的资源上限。 -
memory: "128Mi"：此容器可以使用的内存上限是 128MiB。如果容器尝试使用超过此限制的内存，它可能会被 OOMKilled（内存不足杀掉）。 -
cpu: "500m"：此容器可以使用的 CPU 处理能力上限是 0.5 核心。如果容器尝试使用更多的 CPU，它的 CPU 使用将会被限制，在必要时会被节流（降低 CPU 使用率），但是它不会被杀死。 -
这个limit实际上就等于docker run里面的 -m 限制内存和--cpus 限制cpu。
#通过这个命令可以看才服务器可用资源 #这里显示了当前节点的总资源和可用资源 [root@master01 ~]# kubectl describe node node01 |grep Capacity -A13 Capacity: cpu: 2 ephemeral-storage: 19442Mi hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 3901352Ki pods: 110 Allocatable: cpu: 2 ephemeral-storage: 18347773103 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 3798952Ki pods: 110
运维小路
一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！
关注微信公众号《运维小路》获取更多内容。
