Kubernetes学习记录之Pod

Pod

概念

Pod就是一组共享了某些资源的容器
Pod的设计是为了亲密性应用可以共享存储和网络而设计

共享网络

容器实现了namesapce隔离，那么pod是怎么打破这种隔离的？
实际上，在k8s中，pod的实现需要一个中间容器，这个容器叫做Infra容器
在一个pod中，Infra容器永远都是第一个被创建的容器，用户定义的其它容器则通过JoinNetworkNamespace的方式与Infra关联在一起
我们可以在node节点中找到这个容器，就是pause容器
在一个pod中共享网络，这意味着对于pod中的两个容器来说：

• 它们可以使用localhost进行通信 它们看到的网络设备和Infra容器看到的完全一样

• 一个pod只有一个IP地址，也就是这个pod的Network Namespace对应的地址

• Pod的生命周期和Infra容器一致，而与其他业务容器无关

共享存储

pod使用数据卷的方式实现数据共享，k8s只需要把所有的volume定义在pod层级即可

这样，一个volume对应的宿主机目录对于pod来说就只有一个，pod内容器只需要声明挂载这个volume，就可以实现数据共享

Pod的状态

• Pending

这个状态意味着Pod的YAML文件已经提交给了k8s，API对象已经被创建并保存到etcd中

但是，这个Pod里有些容器可能因为某种原因不能够被顺序创建，比如无法调度

• Running

这个状态下，Pod已经被调度成功，跟一个具体节点绑定

它包含的容器都已经被创建，并且至少有一个在正在运行

• Succeeded

Pod里所有的容器都运行完毕，并且成功退出，常见于一次性任务

• Failed

Pod里至少有一个容器以不正常的状态退出，遇到这个状态需要查看events

• Unknown

异常状态，意味着kubelet不能上报情况，可能是master和node之间的通信出问题

拉取策略

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

资源限制

• spec.containers[].resources.limits.cpu：实际使用最大CPU配额
• spec.containers[].resources.limits.memory：实际使用最大内存配额
• spec.containers[].resources.requests.cpu：调度时请求的CPU配额参考
• spec.containers[].resources.requests.memory：调度时请求的内存配额参考

重启策略

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

健康检查

• livenessProbe（存活检查）：如果检查失败，将杀死容器，根据重启策略来决定是否重启
• readinessProbe（就绪检查）：如果检查失败，k8s会将Pod从service endpoints中删除

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

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

标签选择器

为node设置标签，让pod调度到指定标签的node上

kubectl label nodes [node] key=value #添加
kubectl label nodes [node] key- #删除

节点亲和性

节点亲和性用于替换节点标签选择器，有两种亲和性表达：

• RequiredDuringSchedulingIgnoredDuringExecution：硬限制，必须满足条件
• PreferrefDuringSchedulingIgnoredDuringExecution：软限制，可以按权重优先

apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity
spec:
  affinity:
    nodeAffinity:
     # requiredDuringSchedulingIgnoredDuringExecution:
     #   nodeSelectorTerms:
     #   - matchExpressions:
     #     - key: disktype
     #       operator: In
     #       values:
     #       - ssd
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype 
            operator: In
            values:
            - ssd
  containers:
  - name: web
    image: nginx

简单总结就是这个就是说会调度到有这个标签的Node上

污点和污点容忍

首先区分一下污点是node的污点，污点容忍是pod对node上污点的容忍程度

关于污点，常见的污点应用场景为节点独占或者有特殊硬件的节点

给一个node设置污点：

kubectl taint node [node] key=valie[effect]

删除污点

kubectl taint node [node] key:[effect]-

其中[effect]可取值：

• NoSchedule：不可能被调度，比如master节点在初始化时已经被打上不可调度标签
• PreferNoSchedule：尽量不要被调度
• NoExecute：不仅不会被调度，还会驱逐Node上已有的Pod

污点容忍是在构建Pod时，YAML文件中的一个字段

比如下面这个Pod，它可以忍受NoSchedule污点的node

apiVersion: v1
kind: Pod
metadata:
  name: taint04
spec:
  containers:
  - name: web
    image: nginx
  tolerations: 
  - key: "disktype"
    operator: "Equal"
    value: "ssd1"
    effect: "NoSchedule"

简单点总结就是 打个比方

给Node打个标签 这屋的人不洗脚，这个Pod看到有这个污点，就不来这屋了
给Pod加上一个容忍度，可以容忍不洗脚，那么Pod就可以来这个Node

指定Node

指定Node就不经过调度器了 ，直接调度

apiVersion: v1
kind: Pod
metadata:
  name: nodename02
spec:
  nodeName: k8s-node01
  containers:
  - name: web
    image: nginx