Kubernetes

How to make pod monopolize CPU kernel

When using docker, you can bind the container to a CPU kernel through the parameter cpuset

In this case, the number of context switches between CPUs by the operating system is greatly reduced, so the performance of applications in the container will be greatly improved.
In fact, cpuset is a common way to deploy online application type pods in production environment

To use functions similar to docker cpuset on kubernetes, the following two conditions need to be met
The QoS of the pod is guaranteed

Set requests and limits to the same value, such as 2

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "200Mi"
        cpu: "2"

In this way, the above pod will be bound to two exclusive CPU cores

Kubernetes CPU resource control

To control CPU resources, you need to use the requests and limits attributes

In short
Requests shows the CPU of the process in cgroups on the CFS scheduler Shares, and limit is the bandwidth limit on CFS
Requests and limits actually use different algorithms to control CPU resources

Let’s start with requests
Use – CPU shares in docker run to allocate CPU resources in proportion
For example, two containers

docker run --name c1 -itd --rm -c 1024 progrium/stress --cpu 6
docker run --name c2 -itd --rm -c 2048 progrium/stress --cpu 6

–cpu-shares shares can only provide a certain proportion of competition, so when there is only one container, the container can still obtain all CPU resources

docker run --name c1 -itd --rm -c 1024 progrium/stress --cpu 6

On kubernetes
The agileek / cpuset test image is used for pressure test. There are six cores with 16g of memory on node slave2
When there is only one S1 with 100m requests and only one replica, it can still eat 100% of the CPU because there is no competition

    name: s1
    resources:
      requests:
        cpu: 100m

Unfortunately, this image does not seem to support a special number for multi-core CPUs. I have six cores on this node. Here, I need to adjust replica to 6 to eat up all six cores on this node

We join a competitor, clone S1 to S2, and adjust requests to 50m on S2
Finally, on the slave2 node
s1 （100m）* 6
s2 （50m） * 6
It can be seen that the CPU occupancy ratio of S1 and S2 is gradually approaching 4:2

Limits shows the CPU cfs_ period_ Us and CPU cfs_ quota_ Us attribute
cpu. cfs_ period_ Us: set the time period (in microseconds)（ μ s) ) must be the same as CFS_ quota_ Use with us.
cpu. cfs_ quota_ Us: set the maximum time (in microseconds) that can be used in the cycle（ μ s））。 The configuration here refers to the maximum usage of a single CPU by a task.
For example, set the limit to 50%
Set CPU cfs_ quota_ Us is set to 50000, relative to CPU cfs_ period_ 100000 US is 50%
set up
s1 requests 100m limits 100m
s2 requests 50m limits 50m
Will get

In this case, the total CPU utilization directly drops to 6%, and the kernel application curve almost drops to 0

Kubernetes Pod QoS

The basic concept and use of QoS will not be repeated here

https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/

This is mainly to explain a problem

QoS acts on the pod, but the resources that determine QoS act on the container. Then, when there is only one container on a pod, this problem becomes very simple

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: lizhe
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: lizhe
spec:
  containers:
  - name: qos-demo-ctr1
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"
  - name: qos-demo-ctr2
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "300Mi"
        cpu: "800m"
      requests:
        memory: "300Mi"
        cpu: "800m"

If the requests and limits of container2 are inconsistent, the QoS should be burstable for container2 and guaranteed for container1

container1

requests 200,700 limits 200,700

container2

requests 200,700 limits 300,800

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: lizhe
spec:
  containers:
  - name: qos-demo-ctr1
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"
  - name: qos-demo-ctr2
    image: busybox
    command:
    - sleep
    - infinity
    resources:
      limits:
        memory: "300Mi"
        cpu: "800m"
      requests:
        memory: "200Mi"
        cpu: "700m"

conclusion
QoS really works on pod
The QoS is determined by the resources of the container

All container requests and limits are consistent == guaranteed
There are inconsistencies == burstable
No configuration == best effort

Introduction to kubernetes

The word kubernetes itself means helmsman and aviator in Greek.
It was opened source by Google in 2014

Now that you have seen this article, I believe you must understand how valuable it is to master and learn it.
There is a saying that software is eating the world and containers are eating software. This is why I have written a lot of content about docker at the same time.

Kubernetes is becoming an operating system for container and cloud environments.
Before 2017, kubernetes was in competition with mesosphere and docker swarm. It was not until 2017 that kubernetes gradually became the de facto standard of container arrangement.
At present, mainstream cloud manufacturers provide kubernetes services.