k8s-Pod

1、Pod概述

Pod 是 k8s 系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在 k8s 上运行容器化应用的资源对象，其他的资源对象都是用来支 撑或者扩展 Pod 对象功能的，比如控制器对象是用来管控 Pod 对象的，Service 或者 Ingress 资源对象是用来暴露 Pod 引用对象的，PersistentVolume 资源对象是用来为 Pod 提供存储等等，k8s 不会直接处理容器，而是 Pod，Pod 是由一个或多个 container组成

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

• （1）最小部署单元
• （2）包含多个容器（一组容器的集合）
• （3）一个pod中容器共享网络命名空间
• （4）pod是短暂的

2、Pod存在的意义

• （1）创建容器使用docker，一个docker对应一个容器，一个容器有进程，一个容器运行一个应用程序
• （2）pod是多进程设计，可以运行多个应用程序（一个pod有多个容器，一个容器里面运行一个应用程序）
• （3）pod存在为了亲密性应用（两个应用之间进行交互、网络之间调用、两个应用需要频繁进行调用）

3、Pod实现机制

共享网络

容器本身之间相互隔离

前提条件：容器在同一个namespace下

通过pod创建容器，首先默认创建一个根容器(Pause容器)，然后才创建业务容器，通过pause容器将其他业务容器全部放入info容器，所有都是在同一个命名空间下，只有一个ip、mac地址、port

共享存储

pod持久化数据 -日志数据、-业务数据

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: write
      image: centos
      command：["bash","-c","for i in (1..100);do echo $i >> /data/hello;sleep 1;done"]
      volumeMounts:
      - name: data
        mountPath: /data
    - name: red
      image: centos
      command：["bash","-c","tail -f  /data/hello"]
      volumeMounts:
      - name: data
        mountPath: /data
        
    volumes:
    - name: data
      emptyDir: {}

引入数据卷概念volumes,使用数据卷进行持久化存储

4、Pod镜像拉取策略

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: nginx
      image: nginx:1.14
      imagePullPolicy：Always

• IfNotPresent： 默认值，镜像在宿主机上不存在时才拉取
• Always：每次创建pod都会重新拉取一次镜像
• Never：pod永远不会主动拉取这个镜像

5、Pod资源限制

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: db
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: "password"
      resource:
        limits:
          cpu: "1"
          memory: 1Gi
        requests:
          cpu: 20m
          memory: 1Gi

• requests 调度大小
• limits 最大

6、Pod重启策略

apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
    - name: busybox
      image: busybox:1.2.2
      args:
      - /bin/sh
      - -c
      - sleep 36000
    restartPolicy: Never

• Always：当容器终止退出后，总是重启容器，默认策略
• OnFailure：当容器异常退出(退出状态码非0)时，才重启
• Never：当容器终止退出，从不重启容器

7、Pod健康检查

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
    - name: liveness
      image: busybox:1.2.2
      args:
      - /bin/sh
      - -c
      - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy
      livenessProbe:
        exec:
          command:
          - cat
          - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5

（1）k8s集群中通过容器检查来检查状态

• java堆内存溢出是检查不了的

（2）应用层面健康检查

livenessProbe(存活检查)

• 如果检查失败，将杀死容器，根据Pod的restartPolicy来操作

readnessProbe(就绪检查)

• 如果检查失败，k8s会把Pod从service endpoints中剔除

probe支持以下三种方法检查：

• httpGet
  -发送http请求，返回200-400状态码为成功
• exec
  -执行shell命令返回状态码是0为成功
• tcpSocket
  -发起TCP Socket建立成功

8、Pod调度策略

kubectl get pods

kubectl get pods -o wide

调度过程：

master节点

• （1）create pod – apiserver – etcd
• （2）scheduler – apiserver – etcd – 调度算法，把pod调度到某个node节点上

node节点

kubelet – apiserver – 读取etcd拿到分配给当前node节点的pod – docker创建容器

影响Pod调度的属性：

1、Pod资源限制影响Pod调度

根据request找到足够node节点进行调度

2、节点选择器标签影响Pod调度

apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  nodeSelector:
    env_role:dev
  containers:
    - name: busybox
      image: busybox:1.5


     
//首先给node节点创建标签
kubectl label node1 env_role=dev

//查看给node打的标签
kubectl get node1 --show-labels

3、节点亲和性影响Pod调度

节点亲和性nodeAffinity和之前nodeSelector基本一样，根据节点上的标签约束来决定Pod调度到哪些节点上

apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringException:
        nodeSelectorTerms:
        - matchExpressions:
          -key: enc_role
            operator: In
            values:
            - dev
            - test
      requiredDuringSchedulingIgnoredDuringException:
      - weight: 1
        preference:
          matchExpressions:
          - key: group
            operator: In
            values:
            - otherprod
  containers:
  -name: webdemo
    image: nginx


//第一个requiredDuringSchedulingIgnoredDuringException 表示硬亲和性
- 当前约束条件必须满足


//第二个requiredDuringSchedulingIgnoredDuringException 表示软亲和性
- 尝试满足，不保证

//operator操作符
- In                在
- NotIn             不在
- Exists            存在
- DoesNotExists    不存在
- Gt                大于
- Lt                小于


//反亲和性

4、污点和污点容忍影响Pod调度

（1）基本介绍

nodeAffinity和nodeSelector： Pod根据里边配置调度到某些node节点上，这俩都是Pod里边的属性，调度时实现

Taint污点：节点不做普通分配调度，不是Pod中的属性，是node节点的属性

（2）场景

• 专用节点
• 配置特定硬件节点
• 基于Taint驱逐

（3）具体演示

//1.查看当前节点污点的情况

kubectl describe node 节点名称 | grep Taint 

污点值有三个：
NoSchedule: 一定不被调度
PreferNoSchedule: 尽量不被调度
NoExecute: 不会调度，并且还会驱逐node已存在的pod


//2.为节点添加污点

kubectl taint node <node-name> <key>=<value>:<effect>
kubectl taint node node2 node-type=production:NoShedule #举例


#创建deployment类型的pod，名称为web1，镜像为nginx及其5个副本
kubectl create deployment web1 --image=nginx
kubectl scale deployment web1 --replicas=5


//3.删除污点
kubectl taint node <node-name> <key>=<value>:<effect>
kubectl taint node node2 node-type=production:NoSchedule #举例

（4）污点容忍

apiVersion: v1
kind: Pod
metadata:
  name: node-taint
spec:
  tolerations:
  - key: "<key>"
    operator:"Equal"    #判断条件为 Equal 
    value:"<value>" 
    effect:"NoExecute
  containers:
  - name: webdemo
    image: nginx