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