概述

Pod是K8s系统中可以创建和管理的最小单位。

Pod是资源对象模型中由用户创建或部署的最小资源对象模型，也是K8s上运行容器应用的资源对象，

其他的资源对象都是用来支撑或扩展Pod对象的功能

比如
控制器对象是用来管控Pod对象

service或ingress资源对象是用来暴露Pod引用对象

PersistentVolume资源对象是为Pod提供存储的

k8s 不会直接处理容器，而是Pod。Pod由一个或多个container组成

Pod是K8s的最重要的概念，每一个Pod都有一个特殊的被称之为根容器的Pause容器。Pause容器对应的镜像属于K8s的一部分。除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器

基本概念

1. 最小部署单位
2. 包含多个容器(一组容器的集合)
3. 同一个Pod容器共享网络命名空间(同一个Pod，共享网络)
4. Pod短暂存在

Pod存在的意义

1. 创建容器使用Docker，一个Docker对应的是”一个”容器。一个容器有进程，一个容器运行一个应用程序
2. Pod是“多进程”设计，运行多个应用程序
3. Pod的存在，为了亲密性
   • 两个应用需要进行交互
   • 网络外部隔离，内部互通

Pod共享实现机制

共享网络

容器本身之间相互隔离

使用namespace、group进行隔离而存在

实现原理

首先创建Pause根容器，其中会创建info容器

Pause容器中拥有同一个Ip，Mac地址，port

之间使用socket实现网络互通

后创建业务容器1，将业务容器1加入到info容器中

同时创建业务容器2，将业务容器2加入到info容器中

使用中介的概念实现互相相连

通过Pause容器，把其他业务容器加入到Pause容器里面，让所有的业务容器在同一个名称空间中，从而实现网络共享

共享存储

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  containers:
  - name: myapp
    image: centos
    # imagePullPolicy: Always
    # imagePullPolicy: IfNotPresent
    # imagePullPolicy: Never
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    command: ["bash", "-c", "for i in (1..100);done echo $i >> /data/demo;sleep 1;done"]
    volumeMounts:            # 挂载数据卷
      - mountPath: /data
        name: data

  - name: myapp
    image: centos
    command: ["bash", "-c", "tail -f /data/demo"]
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    volumeMounts:        # 挂载数据卷
      - mountPath: /data
        name: data

  volumes:        # 定义数据卷
    - name: data

Pod实现持久化存储机制

• 日志数据
• 业务数据

引入一个数据卷Volume的概念，使用数据进行持久化存储

镜像拉取策略

# imagePullPolicy: Always        # 每次创建都会拉取新的镜像

# imagePullPolicy: IfNotPresent    #  默认值，镜像不在宿主机上时拉取

# imagePullPolicy: Never        # 从不主动拉取，需手动拉取

Pod资源限制

  - name: myapp
    image: centos
    command: ["bash", "-c", "tail -f /data/demo"]
    resources:
      limits:        # 需要的“最大”配置
        memory: "128Mi"
        cpu: "500m"
      requests:    # 需要的‘最低’配置
        memory: "64Mi"
        cpu: "250m"
    volumeMounts:
      - mountPath: /data
        name: data

此配置由docker完成，并非Pod

Pod重启机制

# restartPolicy: Never # 从不
# restartPolicy: Alway    # 当容器退出的时候，总是重启容器，默认策略
# restartPolicy: onFailure    当状态码非0的时候，才重启

建议使用onFailure, 如果不会关的话，alway机制会使小白的我关不掉。

Pod健康检查

容器检查并不能检查到全部，例如出现java的堆内存溢出造成java部分并不能提供正常服务，此时的pod还是Running状态

健康检查的两种机制

• livenessProbe(存活检查)
  • 如果检查容器的状态为失败，则会根据Pod中restartPolicy来操作
• readnessProbe(就绪检查)
  • 如果检查容器的状态为失败，则会把Pod从service endpoints中剔除

livenessProbe(存活检查)，杀掉此容器，restartPolicy重启

readnessProbe，杀掉此服务，由其他节点提供 实现重启

livenessProbe健康检查的方式

HttpGet

发送Http请求，返回200-400范围内状态码表示成功

exec

执行Shell命令返回状态码为0则成功

tcpsocket

发起Tcp， socket建立连接则成功

livenessProbe:
      exec:    # 检查方式
        command:
        - cat
        - ??
      initialDelaySeconds: 5    # 检查的时间间隔
      periodSecond: 5        #

Pod创建流程

1. create Pod → Api service  存储至 ectd
2. Scheduler → api service — 读取etcd  → 使用调度算法，把Pod 调度至某个Node中去
3. kubelc  — api service — 读取 etcd拿到， 分配至当前节点—Docker创建容器

Pod调度

标签选择器

#  kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ...
# 更新标签名
kubectl label node node1 env_rold=dev
# 查看标签名
kubectl get nodes NAME --show-labels

查看标签名

节点亲和性

支持的常用操作符号

• In
• NoIn
• Exists
• Gt (大于)
• Lt(小于)
• DoesNotExists

影响Pod调度

# 查看污点kubectl describe nodes NodeName | grep Taint
kubectl describe nodes docker-desktop | grep Taint# 为节点添加污点kubectl taint node NodeNAME key=value:污点中三个值
kubectl taint node NodeNAME env_role=yes:NoSchedule    # 此时的Nodename不会被调度# 删除污点kubectl taint node NodeNAME env_role:NoSchedule-

污点中的值

NoSchedule：一定不被调度

PreferNoSchedule： 尽量不调度

NoExecute： 不会被调度，并且驱逐Node已有Pod

污点容忍