Kubernetes 高级调度（一）

一. 初始化容器 Initcontainer

首先来看初始化容器，顾名思义，初始化容器是用来进行初始化操作的。很多情况下，程序的启动需要依赖各类配置、资源。但是又不能继承在原有的启动命令或者镜像当中，因为程序的镜像可能并没有加载配置命令，此时 Initcontainer 就起了很大的作用

1. Initcontainer 的基本概念

Initcontainer 是 Kubernetes 的初始化容器(也可称之为 Init 容器)，它是一种特殊的容器，在Pod 内的应用容器启动之前运行，可以包括一些应用镜像中不存在的使用工具和安装脚本，用以在程序启动时进行初始化，比如创建文件、修改内核参数、等待依赖程序启动等

每个 Pod 中可以包含多个容器,同时 Pod 也可以有一个或多个先于应用程序启动的 Init 容器,在 Pod定义中和 container 同级,按顺序逐个执行,当所有的 Init 容器运行完成时,Kubernetes 才会启动 Pod内的普通容器

Tnit 容器与普通的容器非常像，除了如下几点：

• 他们总是运行到完成
• 上一个运行完成才会运行下一个
• 如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止，但是如果 Pod 对应的 restartPolicy 值为 Never，Kubernetes 则不会重新启动 Pod

为Pod 设置 Init 容器需要在 Pod的 spec 中添加 initcontainer 字段,该字段和应用的 containers禹组同级相邻，配置方式和 containers 中的普通容器差不多，Init 容器支持应用容器的全部字段和特生，包括资源限制、数据卷和安全设置。但是 Init 容器对资源请求和限制的处理稍有不同，Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe，因为他们必须在 Pod 就绪之前运行完成

备注：
lifecycle 主要指的是容器在其运行环境中经历的不同阶段，以及 Kubernetes 如何管理和响应这些阶段的能力。Kubernetes 提供了容器生命周期钩子(container Lifecycle Hooks)，这是一种允许用户指定在容器生命周期的特定点上运行代码片段或命令的功能
容器生命周期钩子主要包括以下两个部分：
Poststart：这个钩子在容器被创建之后立即调用，但需要注意的是，在钩子执行的时候容器内的主进程尚未启动。这可以用于执行一些初始化任务，比如建立文件系统的缓存目录或其他类型的准备动作
Prestop：这个钩子在发送信号给容器内的主进程之前调用，这意味着这是在容器被终止之前可以执行一些清理工作的最后机会。它常被用来做一些资源释放的工作，比如关闭已经打开的数据库连接或网络连接等

在生产环境中，为了应用的安全和优化镜像的体积，业务镜像一般不会安装高危工具和并不常用的运维工具，比如 cur1、sed、awk、python 或 dig 等，同时建议使用非 root 用户去启动容器。但是某些应用启动之前可能需要检查依赖的服务有没有成功运行，或者需要更高的权限去修改一些系统级的配置，而这些检测或配置更改都是一次性的，所以在制作业务镜像时没有必要为了一次配置的变更去安装一个配置工具，更没有必要因为使用一次高权限而把整个镜像改成以 root 身份运行

考虑到上述问题和需求，Kubernetes 引入了初始化容器的概念，Init 容器具有与应用容器分离的单
独镜像，其启动相关代码具有如下优势:

• Init 容器可以包含安装过程中应用容器中不存在的实用工具或个性化代码
• Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低
• Init 容器可以以 root 身份运行，执行一些高权限命令
• Init 容器相关操作执行完成后就会退出，不会给业务容器带来安全隐患

由于 Init 容器必须在应用容器启动之前运行完成，因此, Init 容器提供了一种机制来阳塞或延迟应用容器的启动，直到满足一组先决条件，Pod内的所有应用容器才会并行启动

2. 示例一：延迟指定时间后启动

（1）编写 initcontainers 的 yaml 文件

[root@k8s-master ~]# vim init01.yml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: initc01
  name: initc01
spec:
  terminationGracePeriodSeconds: 0
  containers:
  - image: nginx:1.7.9
    imagePullPolicy: IfNotPresent
    name: n1
    resources: {}
  initContainers:
  - name: initc01
    image: nginx:1.7.9
    imagePullPolicy: IfNotPresent
    command: ["sh","-c","sleep 15"]
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

（2）创建 Pod

[root@k8s-master ~]# ku create -f init01.yml

（3）查看创建结果

不断地査看 Pod 启动状态，15 秒后会发现 Pod 开始启动

[root@k8s-master ~]# ku get pod

3. 示例二：更用初始化容器修改内核参数

在容器里修改内核参数，实际上修改的就是物理机的内核参数，为了安全性，一般不允许在容器里修改内核参数，Seccomp 代表安全计算(Secure computing)模式，seccomp 控制了容器能做哪些操作，添加 securitycontext 参数之后就可以修改内核参数了

创建一个 pod，initcontainers 初始化容器里的 securitycontext:privileged:true 表示该容器具有特权，可以执行命令"sh",“-c”,”/sbin/sysctl -w vm.swappiness=0"，vm.swappiness 设置为0表示尽量少使用 swap 内存

（1）编写 initcontainers 的 yaml 文件

[root@k8s-master ~]# vim init02.yml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: initc02
  name: initc02
spec:
  terminationGracePeriodSeconds: 0
  containers:
  - image: nginx:1.7.9
    imagePullPolicy: IfNotPresent
    name: n1
    resources: {}
  initContainers:
  - name: initc02
    image: alpine
    imagePullPolicy: IfNotPresent
    command: ["sh","-c","/sbin/sysctl -w vm.swappiness=0"]
    securityContext:
      privileged: true
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

（2）创建 Pod

[root@k8s-master ~]# ku create -f init02.yml

（3）查看创建结果

查看 Pod 中的容器

[root@k8s-master ~]# ku get pod -o wide

查看 k8s-node02 机器上的 swappiness 值是否为 0

[root@k8s-node02 ~]# cat /proc/sys/vm/swappiness

4. 示例三：等待依赖服务启动

有时某些服务需要依赖其他组件才能启动，比如后端应用需要数据库启动之后，应用才能正常启动,此时需要检测数据库实例是否正常，等待数据库可以正常使用时，在启动后端应用，此时可以使用初始化容器进行控制

①：创建第一个 Pod

（1）编写 yaml 文件

[root@k8s-master ~]# vim myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80
  initContainers:
    - name: init-redis
      image: busybox:1.28
      command: ['sh', '-c', 'until nslookup redis-service; do echo waiting for nginx01; sleep 2; done;']
    - name: init-mysql
      image: busybox:1.28
      command: ['sh', '-c', 'until nslookup mysql-service; do echo waiting for nginx02; sleep 2; done;']

（2）创建 Pod

[root@k8s-master ~]# ku create -f myapp.yaml

（3）查看创建结果

[root@k8s-master ~]# ku get pod -o wide

②：创建第一个被依赖的 service

（1）编写 yaml 文件

[root@k8s-master ~]# vim redis-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: redis
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        - image: redis:5.0
          imagePullPolicy: IfNotPresent
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: redis
  name: redis-service
spec:
  ports:
    - port: 6379
      protocol: TCP
      targetPort: 6379
  selector:
    app: redis
  type: NodePort

（2）创建 Pod

[root@k8s-master ~]# ku create -f redis-deployment.yaml

（3）查看创建结果

[root@k8s-master ~]# ku get pod
[root@k8s-master ~]# ku get svc

③：创建第二个被依赖的 service

（1）编写 yaml 文件

[root@k8s-master ~]# vim mysql-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: mysql
  name: mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - env:
            - name: MYSQL_ROOT_PASSWORD
              value: 'moonfdd'
          image: 'mysql:8.0'
          imagePullPolicy: IfNotPresent
          name: mysql
          volumeMounts:
            - mountPath: /var/lib/mysql
              name: volv
      volumes:
        - hostPath:
            path: /root/k8s/moonfdd/mysql/var/lib/mysql
            type: DirectoryOrCreate
          name: volv
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: mysql
  name: mysql-service
spec:
  ports:
    - port: 3306
      protocol: TCP
      targetPort: 3306
  selector:
    app: mysql
  type: NodePort

（2）创建 Pod

[root@k8s-master ~]# ku create -f mysql-deployment.yaml

（3）查看创建结果

[root@k8s-master ~]# ku get pod
[root@k8s-master ~]# ku get svc

到这里可以发现，当把 redis-service 和 mysql-service 两个服务创建出来后，nginx 的 Pod 就正常运行了

5. pause 容器

在 Kubernetes 中，pause 容器并不是指暂停容器的执行，而是指一个特殊的辅助容器，它被用于每个Pod 以帮助实现网络命名空间。pause 容器是 Kubernetes 中每个 Pod 的第一个容器,它的主要作用是作为 Pod 内所有其他容器共享网络命名空间的基础

每个 Kubernetes Pod 都有一个 pause 容器，它是 Pod 的第一个容器，也是唯一必须运行的容器。即使 Pod 中的其他容器都停止了，只要 pause 容器还在运行，Pod 就不会被 Kubernetes 认为是完全停止的

（1）pause 容器的作用

作用	说明
网络命名空间	pause 容器为 Pod 内的所有容器提供了一个共享的网络命名空间。这意味着 Pod 内的所有容器都共享同一个 IP 地址和端口空间，从而使得它们可以直接通过 1ocalhost 或者其他指定方式相互通信
网络接口	pause 容器负责设置 Pod 的网络接口,使得 Pod 内的容器能够通过这个接口访问外部网络
稳定性	如果 Pod 中的所有声明的容器都被删除或停止，pause 容器将保持运行，从而保证 Pod 的网络命名空间不会丢失。这也意味着 Pod 的网络配置仍然保留，直到整个 Pod 被删除
生命周期管理	pause 容器是一个非常简单的容器，其镜像只包含一个命令/pause，该命令实际上是个无限循环，保持容器处于运行状态。它不执行任何业务逻辑，仅仅是作为 Pod 网络基础设施的一部分

（2）pause 容器的好处

• 简化了 Pod 内的网络配置
• 提高了 Pod 网络的一致性
• 减少了管理 Pod 网络复杂性的开销

总的来说，pause 容器对于实现 Kubernetes Pod 的网络功能至关重要，它是 Kubernetes 网络模型的一个核心组成部分

（3）pause 容器的实现

Pod 里的多个容器怎么去共享网络?下面是个例子：

比如说现在有一个 Pod，其中包含了一个容器 A和一个容器 B，它们两个就要共享 NetworkNamespace。在 Kubernetes 里的解法是这样的:它会在每个 Pod 里，额外起一个 Infra(基础)container 小容器来共享整个Pod 的 Network Namespace

Infra container,是一个非常小的容器，大概 700KB 左右，是一个’ 语言写的、永远处于“暂停"状态的容器。由于有了这样一个 Infra container之后，其他所有容器都会通过 Join Namespace的方式加入到 Infra container 的Network Namespace 中

所以说一个 Pod 里面的所有容器，它们看到的网络视图是完全一样的。即:它们看到的网络设备!P 地址、Mac 地址等等，跟网络相关的信息。其实全是一份，这一份都来自于 Pod 第一次创建的这个|nfra container。这就是 Pod 解决网络共享的一个解法

在 Pod 里面，一定有一个!P地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个infra container 的 IP 地址，所以大家看到的都是同一份，而其他所有网络资源，都是一个 Pod份，并且被 Pod 中的所有容器共享。这就是Pod 的网络实现方式

由于需要有一个相当于中间的容器存在，所以整个 Pod 里面，必然是 lnfa container 第一个启动。并日整个 Pod 的牛命周期是等同于 Infracontainer 的生命周期的，与容器 A和 B是无关的。这也是为什么在 Kubemnetes 里面，它是允许去单独更新 Pod 里的某一个镜像的，即:做这个操作，整个 Pod 不会重建，也不会重启，这是非常重要的一个设计

①：査看 nginx 的 Pod 运行在的主机

[root@k8s-master ~]# ku get pod -o wide

②：在 k8s-node01 主机上査看 Pod 中的 pause 容器

[root@k8s-node01 ~]# docker ps | grep pause

二. 临时容器 Ephemeral containers

1. 临时容器的概念

临时容器与其他容器的不同之处在于，临时容器是被临时添加到 Pod 上，用于在线调试应用的，他永远不会自动重启，因此不适用与构建应用程序，临时容器的声明和普通容器类似，但是临时容器没有端口配置，因此不能使用像 ports、livenessprobe、readnessProbe、resources 这样的字段，当然，临时容器只是用来调试程序的，它的状态不会影响其他正常容器，所以它并不需要这些字段配置

临时容器使用 API 中一种特殊的 Ephemeral containers 处理器进行创建，而不是直接添加到pod.spec 字段，因此无法使用 kubectl edit 来添加临时容器，与常规容器一样，将临时容器添加到 Pod后，将不能更改或删除临时容器，但是 当添加了临时容器的 Pod 重启后，临时容器就会被销毁

因为临时容器是为了调试程序而设计的，所以在添加临时容器时，最好使用一个包含所有常用工具的镜像进行创建。当业务容器崩溃或容器镜像不包含调试工县而导致kubectl exec不可用时，临时容器对于交互故障排査和在线 Debug 很有用。尤其是在使用像不包含任何 shel1 和其他工具的 destroless 镜像作为基础镜像时，虽然可以减少攻击面和漏洞，但对于问题的排査会变得尤为棘手，此时临时容器就可以发挥很大的作用，带来诸多便利性

2. 临时容器的使用

（1）编写 yaml 文件

[root@k8s-master ~]# vim pod-tomcat.yaml
apiVersion: v1
kind: Pod
metadata:
  name: tomcat-test
  namespace: default
  labels:
    app:  tomcat
spec:
  containers:
  - name:  tomcat-java
    ports:
    - containerPort: 80
    image: nginx:1.7.9
    imagePullPolicy: IfNotPresent

（2）创建 Pod

[root@k8s-master ~]# ku create -f pod-tomcat.yaml

（3）查看创建结果

[root@k8s-master ~]# ku get pod

（4）为 tomcat 的 pod 创建临时容器

[root@k8s-master ~]# ku debug -it tomcat-test --image=busybox:1.28 --target=tomcat-java

备注：

命令字	含义
tomcat-test	pod 的名字
–target=tomcat-java	pod 中源容器的名称
–image=busybox:1.28	该 pod 中临时容器使用的镜像

（5）查看 tomcat-test 这个 pod 是否已经有临时容器

[root@k8s-master ~]# ku describe pods tomcat-test

三. 自动扩缩容 HPA

在集群安装的过程中，我们可以安装一个叫 Metrics Server 的组件，该组件在集群中负责采集 Pod和 Node 的度量值指标,比如 Pod 的 CPU、内存使用率和节点的内存、CPU 使用率,而且安装的 Dashboard可以展示 CPU、内存信息也是依靠 Metrics Server 的。当然，该组件不仅仅是用来展示数据的，还可以使用 Metrics Server 提供的数据结合 Kubernetes 的 HPA 功能实现 Pod 的自动扩缩容

1. 什么是 HPA

HPA(Horizontal Pod Autoscaler,水平 Pod 自动伸缩器)可以根据观察到的 CPU、内存使用率或自定义度量标准来自动扩展或缩容Pod的数量.注意 HPA 不适用于无法缩放的对象比如：Daemonset

HPA 控制器会定期调整 RC或 Deployment 的副本数，以使观察到的平均 CPU 利用率与用户指定的目标相匹配

HPA 需要 Metrics server 获取度量指标,如果已经部署了 Metrics Server，本节的实践部就分无须再次安装Metrics Server。如果没有安装 Metrics Server，可以参考其他实验文档自行部署

2. HPA 的工作原理

（1）HPA 根据观察到的 CPU、内存使用率或自定义度量标准来自动扩展或缩容 Pod 的数量

（2）HPA 控制器会定期调整 RC(Replication controller)或 Deployment 的副本数，以使观察到的平均 CPU 利用率(或其他度量标准)与用户指定的目标相匹配

（3）HPA 需要 Metrics Server 获取度量指标，Metrics Server 负责采集 Pod 和 Node 的度量值指标，如 CPU、内存使用率等

3. HPA 的工作流程

（1）配置 HPA： 使用 kubectl autoscale 命令为Deployment、Replicaset 或Statefulset 等资源创建 HPA 对象，并指定目标 CPU 利用率、最小副本数和最大副本数

（2）度量指标采集： Metrics Server 定期采集 Pod 和 Node 的度量值指标，并将这些数据提供给 HPA控制器

（3）伸缩决策： HPA控制器根据当前 Pod 的度量指标和目标利用率进行比较，如果当前利用率高于目标利用率，则增加 Pod 副本数;如果当前利用率低于目标利用率，则减少 Pod 副本数(在最小副本数和最大副本数之间调整)

（4）Pod 伸缩： Kubernetes 根据 HPA 控制器的决策自动调整 Pod 的副本数，以实现自动扩缩容

4. HPA 的应用场景

（1）应对流量波动： 在 web 服务中，流量可能会随时间变化而波动。HPA可以根据流量变化自**动调整Pod 副本数，以确保服务的稳定性和响应速度

（2）资源优化： 通过自动扩缩容，HPA 可以在保证服务质量的同时最大化资源利用率，降低运营成本

5. HPA 实践——实现 web 服务器的自动伸缩特性

在生产环境中，总会有一些意想不到的事情发生，比如公司网站流量突然升高，此时之前创建的 Pod已不足以支撑所有的访问，而运维人员也不可能 24 小时守着业务服务，这时就可以通过配置 HPA，实现负载过高的情况下自动扩容 Pod 副本数以分摊高并发的流量，当流量恢复正常后，HPA 会自动缩减 Pod 的数量

（1）编写 yaml 文件

[root@k8s-master ~]# vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-server
  labels:
    name: nginx-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          resources:
            requests:
              cpu: 10m
          image: nginx:1.7.9
          ports:
            - name: nginx
              containerPort: 80

（2）创建 Pod

[root@k8s-master ~]# ku create -f nginx-deployment.yaml

（3）查看创建结果

[root@k8s-master ~]# ku get pod

（4）配置 nginx-server 的 service

[root@k8s-master ~]# ku expose deployment nginx-server --port=80

（5）使用 kubectl autoscale 命令创建 HPA

[root@k8s-master ~]# ku autoscale deployment nginx-server --cpu-percent=10 --min=1 --max=10

此 HPA 将根据 CPU的使用率自动增加和减少副本数量，上述设置的是 CPU 使用率超过 10%(–cpu-percent 参数指定)就会增加 Pod 的数量，以保持所有 Pod 的平均 CPU 利用率为 18%,允许最大的 Pod 数量为 10(–max),最少的 Pod 数为1(–min)

（6）查看当前 HPA 的状态

因为未对其发送任何请求，所以当前 CPU 使用率为 0%

[root@k8s-master ~]# ku get hpa

备注：

如果看不到 TARGET 的 CPU 利用率，可以多等十几秒

（7）查看当前 Ngmx 的 service 地址

[root@k8s-master ~]# ku get svc

（8）压力测试(打开一个新的终端)

[root@k8s-node02 ~]# while true;do wget -q -O- http://10.107.208.141 >/dev/null;done

（9）查看 HPA 状态

等待一分钟左右，再次查看 HPA，可以看到 Pod 的 CPU 已经升高

（10）再次查看 Pod，可以看到已经扩容(Pod 副本增加到了 10 个)

[root@k8s-master ~]# ku get pod

（11）停止压力测试

Ctrl+C 终止终端的测试，等待一分钟左右，再次查看HPA 状态

（12）查看 pod 的副本数

[root@k8s-master ~]# ku get pod