0x01 Pod概述
Pod 是k8s 系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在 k8s 上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展 Pod 对象功能的，比如控制器对象是用来管控 Pod 对象的，Service 或者Ingress 资源对象是用来暴露 Pod 引用对象的，PersistentVolume 资源对象是用来为 Pod提供存储等等，k8s 不会直接处理容器，而是Pod，Pod 是由一个或多个 container 组成。
Pod是Kubernetes的最重要概念，每一个Pod都有一个特殊的被称为”根容器“的Pause容器。Pause 容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。
0x02 Pod存在的意义
（1）创建容器使用docker，一个docker对应市一个容器，一个容器有进程，一个容器运行一个应用程序。
（2）Pod是多进程设计，运行多个应用程序。
-
一个Pod有多个容器，一个容器里面运行一个应用程序
（3）Pod存在为了亲密性应用。
-
两个应用之间进行交互
-
两个应用之间调用
-
两个应用直接需要频繁调用
0x03 Pod实现机制
（1）共享网络
-
通过Pause容器，把其他业务容器加入到Pause容器里面，让所有业务容器在同一个名称空间中，可以实现网络共享。
（2）共享存储
-
引入数据卷根念volume.使用数据卷进行持久化存储。
0x04 Pod镜像拉取策略
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: nginx
image: nginx:1.14
imagePullPolicy: Alway
IfNotpresent：默认值，镜像在宿主机上不存在时才拉取。
Always：每欧创建 Pod 都会重新拉取一次镜像Pod。
Never：永远不会主动拉取这个镜像。
0x05 Pod资源限制
requests：调度大小
limits：最大大小
apiVersion: v1
kind: Pod
metadata:
name: frontendSpeci
spec:
containers:
- name: db
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Pod和Container的资源请求和限制：
-
spec.containers[].resources.limits.cpu
-
spec.containers[].resources.limits.memory
-
spec.containers[].resources.requests.cpu
-
spec.containers[].resources.requests.memory
0x06 Pod重启机制
restartPolicy: Never
Always：当容器终止退出后，总是重启容器，默认策略。
OnFailure：当容器异常退出（退出状态码非0时），才重启容器。
Never：当容器终止退出，从不重启容器。
0x07 Pod健康检查
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
两种检查机制：
（1）livenessProbe（存活检查）：如果检查失败，将乐死容器，根据Pod的restartPolicy来操作。
（2）readinessProbe（就绪检查）：如果检查失败，Kubernetes会把Pod从service endpoints中剔除。
三种检查方法：
（1）httpget：发送HTTP请求，返回200-400范围状态码为成功。
（2）exec：执行she11命令返回状态码是0为成功。
（3）tcpsocket：发起TCP Socket建立成功。
0x08 Pod调度策略
创建pod流程图：
影响pod调度的属性：
（1）资源限制
根据request找到足够性能的node节点进行调度。
（2）节点选择器
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
nodeSelector:
env_role: dev #选择env_role标签为dev的
containers:
- name: nginx
image: nginx:1.15
给node1节点打上标签
kubectl label node node1 env_role dev
查看node1节点标签
kubectl get nodes node1 --show-labels
（3）节点亲和性
节点亲和性（ nodeAffinity）和之前节点选择器（nodeSelector）基本一样，根据节点上标签约束来决定Pod调度到哪些节点上。
亲和性分为两种：硬亲和性（约束必须满足），软亲和性（尝试满足）。
常用的操作符为 In：在里面，NotIn：不在里面，Exists ：存在，DoesNotExists：不存在，Gt ：大于，Lt：小于。
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
containers:
- name: webdemo
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和性
nodeSelectorTerms:
- matchExpressions:
- key: eny role
operator: In
values:
- dey
preferredDuringSchedulingIgnoredDuringExecution: # 软亲和性
- weight: 1
preference:
matchExpressions:
- key: group
operator: In
values:
- otherprod
0x09 Pod污点与容忍
Taint污点：节点不做普通分配调度，是节点属性。
（1）添加污点
# kubectl taint node [nodeName] key=value:污点值
[root@master ~] kubectl taint node 172.16.10.20 node-role.kubernetes.io/master=true:NoSchedule
# 污点值有三个
# NoSchedule：一定不被调度
# PreferNoSchedule：尽量不被调度
# NoExecute：不会调度，并且还会驱逐Node已有Pod
（2）删除污点
# kubectl taint node [nodeName] key=value:污点值
[root@master ~] kubectl taint node 172.16.10.20 node-role.kubernetes.io/master=true:NoSchedule-
（3）查看污点情况
[root@master ~] kubectl describe node 172.16.10.20 | grep Taint
Taints: node-role.kubernetes.io/master=true:NoSchedule
（4）污点容忍
设置污点容忍后，就算节点是NoSchedule也可以会被调度到。在yaml Deployment 中设置。
#这里的key跟value跟添加污点时候的key value值要一样
spec:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule
发表评论