Kubernetes复习总结（一）：Kubernetes内置资源、Device Plugin机制

原创

已于 2024-01-20 15:27:22 修改 · 1.7k 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#Kubernetes #Pod #Deployment #Service #Device Plugin

于 2024-01-06 16:23:58 首次发布

本文详细介绍了Kubernetes内置资源，包括Pod、Deployment、DaemonSet等，阐述了Pod的概念、生命周期、容器探测等，Deployment通过管理ReplicaSet间接管理Pod。还介绍了Service的聚合功能、工作模式和类型，Ingress的反向代理原理。此外，讲解了Kubernetes Device Plugin机制，包括资源上报和Pod分配GPU的流程。

1、Kubernetes内置资源

1）、Pod

Pod是Kubernetes进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中

Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器

1）Pod=进程组

在Kubernetes里面，Pod实际上正是Kubernetes抽象出来的一个可以类比为进程组的概念

由四个进程共同组成的一个应用Helloworld，在Kubernetes里面，实际上会被定义为一个拥有四个容器的Pod

就是说现在有四个职责不同、相互协作的进程，需要放在容器里去运行，在Kubernetes里面并不会把它们放到一个容器里，Kubernetes会把四个独立的进程分别用四个独立的容器启动起来，然后把它们定义在一个Pod里面

所以当Kubernetes把Helloworld给拉起来的时候，实际上会看到四个容器，它们共享了某些资源，这些资源都属于Pod，所以我们说Pod在Kubernetes里面只是一个逻辑单位，没有一个真实的东西对应说这个就是Pod。真正起来在物理上存在的东西，就是四个容器。这四个容器或者说是多个容器的组合就叫做Pod

Pod是Kubernetes分配资源的一个单位，因为里面的容器要共享某些资源，所以Pod也是Kubernetes的原子调度单位

2）为什么Pod必须是原子调度单位？

假如现在有两个容器，它们是紧密协作的，所以它们应该被部署在一个Pod里面。具体来说，第一个容器叫做App，就是业务容器，它会写日志文件；第二个容器叫做LogCollector，它会把刚刚App容器写的日志文件转发到后端的ElasticSearch中

两个容器的资源需求是这样的：App容器需要1G内存，LogCollector需要0.5G内存，而当前集群环境的可用内存是这样一个情况：Node_A：1.25G内存、Node_B：2G内存

假如说现在没有Pod概念，就只有两个容器，这两个容器要紧密协作、运行在一台机器上。可是，如果调度器先把App调度到了Node_A上面，接下来会怎么样呢？这时会发现：LogCollector实际上是没办法调度到Node_A上的，因为资源不够。其实此时整个应用本身就已经出问题了，调度已经失败了，必须去重新调度

在Kubernetes里，就直接通过Pod这样一个概念去解决了。因为在Kubernetes里，这样的一个App容器和LogCollector容器一定是属于一个Pod的，它们在调度时必然是以一个Pod为单位进行调度，所以这个问题是根本不存在的

3）Pod里面的容器是超亲密关系

Pod里面的容器是超亲密关系，大概分为以下几类：

比如说两个进程之间会发生文件交换，比如一个写日志，一个读日志
两个进程之间需要通过localhost或者说是本地的Socket去进行通信，这种本地通信也是超亲密关系
这两个容器或者是微服务之间，需要发生非常频繁的RPC调用，出于性能的考虑，也希望它们是超亲密关系
两个容器或者是应用，它们需要共享某些Linux Namespace。最简单常见的一个例子，就是我有一个容器需要加入另一个容器的Network Namespace。这样我就能看到另一个容器的网络设备，和它的网络信息

4）Infra container（也叫Pause容器）

每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：

业务容器（用户程序所在的容器）：数量可多可少
Infra container：每个Pod都会有的一个根容器

共享网络：

如上图所示，这个Pod里有两个用户容器A和B，还有一个Infra container。Infra container是一个非常小的镜像，大概100~200KB左右，是一个汇编语言写的、永远处于暂停状态的容器

整个Pod里Infra container第一个启动，在Infra container Hold住Network Namespace后，用户容器就可以加入到Infra container的Network Namespace当中了

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

这也就意味着，对于Pod里的容器A和容器B来说：

它们可以直接使用localhost进行通信
它们看到的网络设备跟Infra container看到的完全一样
一个Pod只有一个IP地址，也就是这个Pod的Network Namespace对应的IP地址
其他的所有网络资源，都是一个Pod一份，并且被该Pod中的所有容器共享
Pod的生命周期只跟Infra container一致，而与容器A和B无关

而对于同一个Pod里面的所有用户容器来说，它们的进出流量，也可以认为都是通过Infra container完成的

共享存储：

有了Infra container这个设计之后，共享Volume就简单多了：Kubernetes只要把所有Volume的定义都设计在Pod层级即可

这样，一个Volume对应的宿主机目录对于Pod来说就只有一个，Pod里的容器只要声明挂载这个Volume，就一定可以共享这个Volume对应的宿主机目录。比如下面这个例子：

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:
  restartPolicy: Never
  volumes:
  - name: shared-data
    hostPath:      
      path: /data
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

在这个例子中，debian-container和nginx-container都声明挂载了shared-data这个Volume。而shared-data是hostPath类型。所以，它对应在宿主机上的目录就是：/data。而这个目录，其实就被同时绑定挂载进了上述两个容器当中

这就是nginx-container可以从它的/usr/share/nginx/html目录中，读取到debian-container生成的index.html文件的原因

Infra container的作用：

整个Pod的生命周期就等同于Infra container的生命周期，可以以它为依据评估整个Pod的健康状态
Pod里的多个业务容器共享Infra container的IP，共享Infra container挂载的Volume，既简化了密切关联的业务容器之间的通讯问题，也很好地解决了它们之间的文件共享问题

5）Pod生命周期

我们一般将Pod对象从创建至终的这段时间范围称为Pod的生命周期，它主要包含下面的过程：

Pod创建过程
运行初始化容器（init container）过程
运行主容器（main container）
- 容器启动后钩子（post start）、容器终止前钩子（pre stop）
- 容器的存活性（liveness probes）、就绪（readiness probes）、启动（startup probes）探针
Pod终止过程

在这里插入图片描述

6）容器探测

Kubernetes提供了三种探针来实现容器探测，分别是：

liveness probes：存活性探针，用于判定是否需要重启容器，通常情况下主要用于检查容器是否无响应、死锁等，从而通过重启来提高应用的可用性
readiness probes：就绪性探针，用来判定容器是否准备就绪，是否可以接受流量。当Pod内所有容器均就绪，则Pod将被认为已ready，如果没有，那么将从Service的Loader Blance中剔除该Pod
startup probes：启动探针，Kubernetes v.1.18后支持，用于判定应用程序容器什么时候启动了，而启用这个探针主要目的是希望容器在启动成功后再进行存活性和就绪检查，确保这些存活、就绪探测器不会影响应用程序的启动。这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉

启动探针案例：

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080
livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10
startupProbe:
  httpGet: