Kubernetes

Kubernetes Pod 创建过程

我们知道 Kubernetes 由很多不同组件构成

第一种情况，如果直接创建pod

apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: lizhe
spec:
  containers:
  - name: demo-ctr
    image: nginx

• kubectl 发送创建pod的请求到 api server
• api server 生成 pod 创建信息
• api server 存储 创建信息 到 etcd
• scheduler 查询 pod.spec.Node==null 确认此pod没有被分配
• scheduler 分配node pod.spec.Node=node1，保存到etcd
• kubelet 查询etcd，在节点上操作

第二种情况，通过deploy（replicaset）创建pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx


 

• kubectl 发送创建dep的请求到 api server
• api server 生成 dep 创建信息
• api server 存储 创建信息 到 etcd
• controller manager 中的 replicaset controller 从etcd中得到 replicaset 信息
• controller manager 发送创建 3个 pod 的请求到 api server

• api server 生成 pod 创建信息
• api server 存储 创建信息 到 etcd
• scheduler 查询 pod.spec.Node==null 确认此pod没有被分配
• scheduler 分配node pod.spec.Node=node1，保存到etcd
• kubelet 查询etcd，在节点上操作

实际上，只有上面一部分步骤是多出来的

不需要使用Scheduler的情况

Scheduler 主要任务是 调度 Pod

具体过程请参考 Kubernetes Pod 创建过程

有几种情况，Kubernetes可以绕过 调度器 直接创建pod

• 创建pod的时候，指定了 nodeName
• 由守护进程集 daemonset 创建的pod （daemonset会指定nodeName，所以和第一条一样）
• 静态pod

进一步解释

	由守护进程集创建的Pod可以在调度器启动之前运行
	由守护进程集创建的Pod可以不遵守节点的Unschedulable
	由守护进程集创建的Pod优先级更高，解调度器会避免驱逐它，自动缩放器也会单独管理它们

	静态 Pod 和 守护进程集 类似，Kubelet 除了可以与 Kubernetes API 服务器通信并获取 Pod 描述文件之外，还可以从本地目录获取资源定义。以这种方式定义的 Pod，只能由 Kubelet 管理，而且只能在一个节点上运行。
	API 服务不会监视这些 Pod ，而且它们也没有控制器，也不会针对它们执行 健康检查，Kubelet 会监视这些 Pod，并在崩溃时重启。
	Kubelet 还会定期扫描配置目录，以查找 Pod 定义的改动，并相应的添加 或 删除 Pod
	

初始化容器

通过初始化容器，也可以方便的做一些类似 postStart 的工作

但是需要明确区分的是，初始化容器的作用目标是 Pod本身，而 postStart 的作用目标则是 container

大多数情况下，这两种方式可以互换

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
  labels:
    app: init
spec:
  initContainers:
    - name: init
      image: busybox
      command:
      - wget
      - "-O"
      - "/tmp/index.html"
      - https://studyk8s.com
      volumeMounts:
        - name: initdir
          mountPath: "/tmp"

  containers:
    - name: nginx
      image: nginx
      ports:
      - containerPort: 80
      volumeMounts:
        - name: initdir
          mountPath: /usr/share/nginx/html
  volumes:
    - name: initdir
      emptyDir: {}

Init容器与普通容器非常像，除了以下两点:

• Init容器总是运行到完成 (例如执行wget、curl、ping等命令)
• 如果有多个Init容器的情况下都必须要在下一个启动之前结束运行

如果Pod中的Init容器启动失败，Kubernetes会不断重启该Pod，指导Init容器成功为止，如果Pod对应的restartPolicy值为Never(只要退出就不再重启)，则它不会重新启动。

PreStop 钩子

Prestop 的语义也很简单，在停止之前调用

但是在什么停止之前呢？容器停止之前？Pod销毁之前？

Prestop的准确调用时间是，在Kubernetes发出 SIGTERM信号之前调用

需要注意的是，SIGTERM信号是发送给Pod的，preStop钩子是容器的

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        lifecycle:
          preStop:
            exec:
              command:
              - sh
              - -c
              - sleep 30
      - name: u1
        command:
        - sleep
        - infinity
        image: ubuntu
        lifecycle:
          preStop:
            exec:
              command:
              - sh
              - -c
              - date "+%Y-%m-%d %H:%M:%S" >> /datetmp.txt && sleep 5
      - name: u2
        command:
        - sleep
        - infinity
        image: ubuntu
        lifecycle:
          preStop:
            exec:
              command:
              - sh
              - -c
              - date "+%Y-%m-%d %H:%M:%S" >> /datetmp.txt && sleep 10

脚本中 Nginx 阻塞30秒，最后应该是被 kill的

两个ubuntu容器阻塞时间有 5秒 的差值，

观察到的结果是，他们都是在最后30秒一起结束的，而preStop脚本则异步同时启动

控制信号

在开始讨论 Kubernetes 如何使用 控制信号 控制容器之前，

也许您有必要回顾一下 Docker的控制信号部分 容器的启动和停止

当 Kubernetes 决定关闭一个容器时，

无论是 Pod 需要关闭 还是 存活探针 失败 造成的 容器重启，

Kubernetes 都会给容器发送一个 SIGTERM 信号。

容器有义务尽快响应 SIGTERM信号，迅速终止，例如 关闭已经打开的数据库连接，清理临时文件等等

Kubernetes会提供 默认30秒 的宽限期，如果容器在30秒之后没有关闭，它将发送 SIGKILL信号来杀死容器

这个默认30秒可以通过 Pod 的下列属性修改

.spec.terminationGracePeriodSeconds 

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
spec:
  containers:
  - name: nginx
    image: nginx
  terminationGracePeriodSeconds: 30

注意这个属性是作用在 Pod 上的，不是 container

PostStart 钩子

顾名思义，这个钩子允许你在容器 启动后 ，执行一些逻辑

有三点需要重点解释

1. postStart 和 容器的主线程 是 异步执行的，并不是 在主线程启动之后，它们是 同时启动的
2. postStart 运行结束以前，容器会处于pending状态
3. 钩子的语义中含有 “至少执行一次” 的意思，所以如果 重复 执行钩子会对系统造成影响，需要慎重考虑

对于第一个问题

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        lifecycle:
          postStart:
            exec:
              command:
              - sh
              - -c
              - date "+%Y-%m-%d %H:%M:%S" > /datetmp.txt && sleep 30
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30

可以看到 postStart的启动时间和容器的启动时间是相同的

因为我当前系统时间是 utc+8，所以 datetmp 中是 9点23，Nginx控制台日志中是 17点23，但是它们确实同一时间启动，而不是等到主线程之后启动

对于第二个问题

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        lifecycle:
          postStart:
            exec:
              command:
              - sh
              - -c
              - echo "postStart postStart postStart" && sleep infinity
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30

PostStart 钩子 的 等待状态 和 就绪探针的区别在于

它并不承认 容器已经 启动

注意启动状态 started 是 false ， 而就绪探针的 started 状态是 true

单Pod装在3个container的情况下，这3个container的PostStart钩子和容器的3个主线，6个脚本，会同时启动

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        lifecycle:
          postStart:
            exec:
              command:
              - sh
              - -c
              - echo "postStart postStart postStart" && sleep 30
      - name: u1
        command:
        - sleep
        - infinity
        image: ubuntu
        lifecycle:
          postStart:
            exec:
              command:
              - sh
              - -c
              - date "+%Y-%m-%d %H:%M:%S" >> /datetmp.txt
      - name: u2
        command:
        - sleep
        - infinity
        image: ubuntu
        lifecycle:
          postStart:
            exec:
              command:
              - sh
              - -c
              - date "+%Y-%m-%d %H:%M:%S" >> /datetmp.txt

这里 ubuntu 容器阻塞30秒，但是Nginx阻塞永远，结果是这个Pod上的3个容器，同时，都无法成功启动

所以说，postStart钩子虽然是作用在容器上的，但是它会影响到所在pod上的其他容器

将Nginx阻塞改为30秒，ubuntu改为5秒

可以看到在5秒过后，10秒左右的时候，三个容器仍为starting状态

还可以看到，2个ubuntu上，postStart钩子是异步，同时启动的

健康检查

Kubernetes自带的探针分为两种

存活探针 和 就绪探针

存活探针通过以下3种方式检查容器是否健康

1. 通过 HTTP GET 请求，期望返回的response code 200-399
2. TCP 套接字连接成功
3. Exec 调用命令，退出代码 为 0

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 30

未通过 存活探针 检查的容器，会被重启，也只会被重启

就绪探针的检查方式相同 HTTP、命令、TCP ， 但是就绪探针不会重启容器，而是避免这个容器接收请求

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /
            port: 801
            scheme: HTTP
          initialDelaySeconds: 30

Limits 可能导致OOM

乍一看这是一句废话，你限制了内存最大值，超出的时候当然要OOM

其实不然，很多常见的应用程序使用的内存最大值，并不能简单的通过 Limits 来限制

在Docker容器中，容器无法感知到自己处在一种 被限制的，资源隔离 的环境中，它会认为自己像正常的非容器应用一样，可以使用全部的宿主机资源

Linux 环境中

即使 -c 分配了 1000 个微核，200M 内存，但是容器仍然认为自己在使用宿主机 的 6个内核 和 8GB 内存

docker run -i -t --name ubuntu -c 1000 -m 200M ubuntu /bin/bash

这种情况会对传统程序，比如Java造成一定的困扰

内存方面

如果不设置 -Xms ，java默认会使用 （它认为的）物理内存的 1/64 作为堆容量的最小值。

如果不设置 -Xmx，java默认会使用（它认为的）物理内存的 1/4 作为堆容量的最大值。

 initial heap size
 Larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum. Before Java SE 5.0, the default initial heap size was a reasonable minimum, which varies by platform. You can override this default using the -Xms command-line option.
 maximum heap size
 Smaller of 1/4th of the physical memory or 1GB. Before Java SE 5.0, the default maximum heap size was 64MB. You can override this default using the -Xmx command-line option.
 Note: The boundaries and fractions given for the heap size are correct for Java SE 5.0. They are likely to be different in subsequent releases as computers get more powerful.
 

因为 获取了错误的 资源信息，容器内应用有可能分配超出自己 能够使用的 资源范围，触发 OOM 异常

那么，仅仅是简单的设置-Xmx 为 200M 就可以避免这个问题么？并不是

容器 -m 参数会限制整个容器的内存使用上限，但是 -Xms 和 -Xmx 限制的仅仅是堆的大小，一个完整的Java程序实际会使用

1. java程序的堆内存，最大就是 -Xmx设置的这个值
2. Garbage collection在垃圾回收的时候使用的内存
3. JIT optimization使用的内存
4. java程序的Off-heap所使用的内存
5. java程序的Metaspace所使用的内存
6. JNI Code所占用的内存
7. jvm启动的时候所占用的内存。

这还不包括Ubuntu 容器本身可能消耗的一些资源（虽然小到可以忽略不计），所以，将 -Xmx 设置为 -m 的 80% 到 90% 可能会是一个稳妥的选择

具体数值需要根据具体项目实际测试

CPU 方面，因为 cpu 可以超卖，所以不会出现 OOM 的情况，

但是，容器内程序认为自己可以使用宿主机的全部 6个内核，真的没有问题么？

docker run --name cputest -it --rm -c 512 progrium/stress --cpu 1

由于 -c 只是标注了容器的 cpu 竞争分配，最多 512 个微核，所以这里它仍然使用了 100% 的cpu， –cpu 强制锁住它在一个内核上，所以，它使用了全部内核的 1个内核

docker run --name cputest -it --rm -c 512 progrium/stress --cpu 6

这次使用了全部的宿主机 cpu

实际上 -c 参数并不会影响程序使用足够的cpu资源，即使是 -c 512，也不会影响线程在多个内核上的调度（不会局限在一个内核的 0.5 上），

Docker 上 -c 只限制竞争

Kubernetes 上 requests 限制竞争，limits 限制 cpu 获得的 cpu片段时间，所以它们都不会影响cpu调度

不会出现6个内核，120个线程被过度频繁调度的情况

为Kubelet预留资源

在kubernetes集群运行过程中，kubelet需要定时向 API Server 发送心跳，报告运行状态

此处实际上存在很大的安全隐患

因为在节点上， Kubelet 和 节点上运行的Pods 需要共享 CPU 和 RAM 资源，这就导致在极端情况下，Kubelet 可能无法得到足够的资源来运行自己

也就是说 Pods 很可能 消耗掉全部的节点物理资源，导致 节点心跳停止 或 报告不及时，API Server 可能会错误的认为，这个节点已经离线

理想主义的状态下，部署到这个节点上的所有Pod，不应该消耗100%的物理资源

例如

100m cpu * 9 ，这样理论上 会剩余 100m

但是由于集群环境极为复杂，而且无法保证调度器会为每个节点预留资源，而且更无法保证每个有权限的操作人员都会留意到这个问题

所以经常会有资源超载的情况，导致kubelet心跳停止

解决办法非常的简单粗暴

部署一个 “占位” 应用，并且分配它的 requests cpu 资源为 100m

这个占位应用（比如Nginx）因为没有具体应用，所以不会真的消耗cpu

这里requests属于好控制的

1000m的 单核可以支持

100m * 9 的正常应用，100m * 1 的占位Nginx，

不过requests只影响 容器调度 和 cpu竞争，无法保证 cpu 资源不被耗尽

把limits也设置成

100m * 9 应用，100m * 1 占位Nginx，这回好了，不过limits是可以超卖的，所以也无法保证所有管理员都给你留出那 100m

结论，

最好是只使用 limits，这样可以保证 requests 默认和 limits保持一致

因为requests无法超卖，所以有Nginx 占位 100m的情况下，那 9 个 只写了limits的正常应用，就不能超过900m了

以上是一种偏方来处理这个问题，那kubernetes原生应用有处理这个问题么

答案是 有，但是麻烦

• --kube-reserved,用于配置为kube组件（kubelet,kube-proxy,dockerd等）预留的资源量，比如--kube-reserved=cpu=1000m,memory=8Gi，ephemeral-storage=16Gi。
• --kube-reserved-cgroup，如果你设置了--kube-reserved，那么一定要设置对应的cgroup，并且该cgroup目录要事先创建好，否则kubelet将不会自动创建导致kubelet启动失败。比如设置为kube-reserved-cgroup=/kubelet.service 。如果不设置此项，上面的--kube-reserved也不会生效。
• --system-reserved，用于配置为System进程预留的资源量，比如--system-reserved=cpu=500m,memory=4Gi,ephemeral-storage=4Gi。
• --system-reserved-cgroup，如果你设置了--system-reserved，那么一定要设置对应的cgroup，并且该cgroup目录要事先创建好，否则kubelet将不会自动创建导致kubelet启动失败。比如设置为system-reserved-cgroup=/system.slice。如果不设置此项的话，上面的--system-reserved也不会生效。

[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=docker.service
Requires=docker.service

[Service]
WorkingDirectory=/var/lib/kubelet
ExecStartPre=-/bin/mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service /sys/fs/cgroup/hugetlb/system.slice/kubelet.service
ExecStart=/opt/kubernetes/bin/kubelet \
  --eviction-hard=memory.available<1024Mi,nodefs.available<10%,nodefs.inodesFree<5% \
  --system-reserved=cpu=0.5,memory=1G \
  --kube-reserved=cpu=0.5,memory=1G \
  --kube-reserved-cgroup=/system.slice/kubelet.service \
  --system-reserved-cgroup=/system.slice \
  --enforce-node-allocatable=pods,kube-reserved,system-reserved \
  --address=192.168.0.101 \
  --hostname-override=192.168.0.101 \
  --cgroup-driver=cgroupfs \
  --pod-infra-container-image=hub.breezey.top/kubernetes/pause-amd64:3.0 \
  --experimental-bootstrap-kubeconfig=/opt/kubernetes/cfg/bootstrap.kubeconfig \
  --kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig \
  --cert-dir=/opt/kubernetes/ssl \
  --cluster-dns=192.168.0.200 \
  --cluster-domain=k8s.breezey.top. \
  --hairpin-mode=promiscuous-bridge \
  --allow-privileged=true \
  --fail-swap-on=false \
  --serialize-image-pulls=false \
  --max-pods=60 \
  --logtostderr=true \
  --v=2 
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

而且很遗憾，在rke安装的kubernetes集群中

并没有使用这种方式

默认是没有kubelet.service的

需要手动添加

再通过参数指定

rke默认情况下安装的kubernetes

kubelet 进程使用的 cgroup 是这样的

6:cpu,cpuacct:/docker/4b28805380958bf3efb5c0d0a9c93ba42fab4d36e1be9036f3b9c4b01ef3bd62

就是这货

Kubernetes CPU 资源控制

控制 cpu 资源，需要使用 requests 和 limits 属性

简而言之

Requests 表现出来的是 Cgroups 中的进程在 CFS 调度器上的 cpu.shares，而 Limit 则是 CFS 上的带宽限制

requests 和 limits 实际上使用的是不同的算法来控制 cpu 资源

先说 requests

在 docker run 中 使用 –cpu-shares 可以按照比例来分配 cpu 资源

例如 两个容器

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 只能提供 按照一定比例的 竞争关系，所以当只有一个容器时，该容器仍然可以获得全部的cpu资源

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

在kubernetes上

使用 agileek/cpuset-test 镜像来进行压测，在 节点 slave2 上一共有6个内核16G内存

当只存在一个 requests 100m 的 s1 ，且 只有一个 replica 的时候，因为没有竞争，它仍然可以吃掉 100%的cpu

    name: s1
    resources:
      requests:
        cpu: 100m

可惜的是这个镜像好像对多核cpu支持的不是特别号，我在这个节点上有6个内核，这里我需要把 replica 调整到6，才能将这个节点上的6个内核都吃光

我们加入一个竞争者，克隆 s1 到 s2 ，在s2上调整 requests 到50m

最终在 slave2 节点上有

s1 （100m）* 6
s2 （50m） * 6

可以看到 s1 和 s2 的 cpu 占用比逐渐向 4:2 靠近

Limits 表现出来的是 cpu.cfs_period_us和cpu.cfs_quota_us属性

cpu.cfs_period_us： 设定时间周期（单位为微秒（μs））， 必须与 cfs_quota_us 配合使用。
cpu.cfs_quota_us ： 设定周期内最多可使用的时间（单位为微秒（μs））。 这里的配置指 task对单个 cpu 的使用上限。

例如要设置成限制为 50%

将 cpu.cfs_quota_us 设为 50000，相对于 cpu.cfs_period_us 的 100000 是 50%

设置

s1 requests 100m limits 100m

s2 requests 50m limits 50m

会得到

这种情况下总cpu使用率直接下降到 6%，内核应用曲线几乎都降到了0