pod进阶版(1)

pod的相关知识

k8s的pad重启策略:

Always deployment的yaml文件只能是Always pod的yaml三种模式都可以。
Onfailure:只有异常退出状态码非0才会重启。正常退出不重启。
Never：非正常退出和非正常退出都不重启。
容器的退出了pod才会重启。
pod可以有多个容器，只要有一个容器退出，整个pod都会重启，pod内的所有容器都会重启。

docekr的重启策略：

docker的默认策略是Never。
on-failure：非正常退出，才会重启容器。
always：只要容器退出都会重启。
unless-stopped：只要退出就会重启，docker守护进程时已经停止的容器，不会重启。

单机部署：docker就够用了
集群化部署：k8s部署

yaml模板文件快速生成的三种方式

可以生成pod、service、deployment等yaml文件

1、手写

2、对已有资源进行导出

kubectl get deployments.apps nginx -o yaml > /opt/lyw.yaml

3、通过api的组件，使对象不执行命令生成文件

kubectl create deployment nginx1 --image=nginx:1.22 --dry-run=client -o yaml >  /opt/test1.yaml
--dry-run=client 只是调用api的对象不执行命令

pod的状态：

pod状态	简述说明	说明
pending	挂起状态	pod已被创建，但是尚未被分配到运行的node节点（原因：节点资源不够或等待其他pod节点调度）
running	运行中	pod已经被分配到了node节点，pod内部的所有容器都已经启动，运行状态正常，稳定。
completed	成功运行完毕并退出	容器内部的进程运行完毕，正常退出，没有发生错误。
successded	成功运行完毕并退出	容器内部的进程运行完毕，正常退出，没有发生错误。
faild	运行错误并退出	pod中的容器非正常退出，发生了错误。需要通过查看详细和日志来定位问题。
Unkown	未知	由于某些原因，k8s集群无法获取pod的状态。 APIserver出了问题
terminating	在终止中	这个pod正在被删除，里面的容器正在终止。终止过程中，资源回收、垃圾清理、以及终止过程中需要执行的命令。
crashloopbackoff	pod当中的容器退出，kubelet正在重启
imagepullbackoff	正在重试拉取镜像
errimagepull	镜像拉取出错（1、网速太慢 2、镜像名字写错了 3、镜像仓库挂了）
Evicte	pod被驱赶（node节点的资源不足部署pod，或者是资源不足，kubelet自动选择一个pod驱逐。）

pod内的容器使用节点资源的限制：

1、request：需要的资源
2、limit 最高占用系统多少资源
limit需要多少，最多也只能占用这么多

两个限制(cpu、内存):

cpu ：
   cpu的个数限制：
   1 2 0.5 0.2 0.3 1：可以占用1个cpu 0.1是最小单位（要么整数，要么就是小数点后只能跟一位）
cpu时间分片原理：
       cpu时间分片: 通过周期性的轮流分配cpu时间给各个进程。多个进程可以在cpu上交替，在k8s中就是占用cpu的比率，单位：m（millicores）100m是最小单位（等于0.1）
内存：Ki 字节 Mi-mb Gi-gb Ti-tb

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: centosname: centos
spec:replicas: 1selector:matchLabels:app: centostemplate:metadata:labels:app: centosspec:containers:- image: centos:7name: centosimagePullPolicy: Nevercommand: ["/bin/bash","-c","sleep 3600"]resources:requests:memory: "256Mi"cpu: "0.5"limits:memory: "1Gi"cpu: "1"
#在创建pod时，一定要给容器做资源限制。

如果超出范围

ready status

0/1 crashloopbackoff

超过资源限制，进程会被立即杀死

k8s怎么设置拉取镜像的策略：

镜像默认策略：
IfnotPresent: 如果本地镜像有，就不拉取，本地没有才会去镜像仓库拉取。默认策略
Always: 不论镜像是否存在，创建时(重启) 都会重新拉取镜像
Never: 仅仅使用本地镜像，不进行拉取镜像

如果涉及到外部部署，默认策略 (事前要把docker的镜像导入到目标主机)
Always：一般不用

pod探针

pod的容器健康检查------探针

探针probe、k8s对容器的定期检查，诊断。

探针的三种规则：

存活探针

livenessProbe 探测容器是否正常运行，如果发现探测失败，会杀容器，容器会根据重启策略来决定是否重启，不是杀掉pod。livenessProbe 杀死容器重启。

所有的探针策略伴随整个pod的生命周期。

就绪探针

探测容器是否进入ready状态，并做好接受请求的准备。探测失败 READY 0/1 没有进入ready状态。

service会把这个资源对象的端点从当中踢出，service也不会把请求转发到这个pod。

启动探针

只是在容器的启动后进行检测，容器内的应用是否启动成功，在启动探测成功之前，所有的探针都处于禁用状态，但是，一旦启动探针结束，后续的操作不再收启动探针影响。

在一个容器当中的可以有多个探针。启动探针:只在容器启动时探测。

Probe的检查方法：

1、exec探针: 在容器内部执行命令,如果命令的返回码是0，表示成功。
适用于需要在容器内部自定义命令来检查容器的健康情况。

2、httpGet：对指定ip+端口的容器发送一个httpget的请求。响应状态码大于等于200,小于400都是成功。
适用于检查容器是否能响应http的请求，web容器（nginx，tomcat）

3、tcpSocket：端口，对指定端口上的容器的ip地址进行tcp检查（三次握手），端口打开，认为探测成功。
检查特定端口的监听状态。
类似于 telnet 192.168.10.10:80

诊断结果：
1、成功容器通过了，正常运行
2、失败存活探针将会重启
3、未知状态

exec探针

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: centosname: centos
spec:replicas: 1selector:matchLabels:app: centostemplate:metadata:labels:app: centosspec:containers:- image: centos:7name: centosimagePullPolicy: Nevercommand: ["/bin/bash","-c","touch /opt/123.txt; sleep 3600"]livenessProbe:exec:command: ["/usr/bin/test","-e","/opt/123.txt"]initialDelaySeconds: 3
#核心指标;表示容器启动之后多少秒来进行探测，时间不要设置的太短，可能会导致无效的探测periodSeconds: 2
#核心指标;表示探针探测的间隔时间。每隔多少秒进行检查。根据应用的延迟敏感度,这个应用非常重要，是核心组件。failureThreshold: 2
#核心指标;表示如果探测失败，失败几次之后，把容器标记为不健康。successThreshold: 1
#表示只要成功一次就标记为就绪，标记为健康，ready。只能为1timeoutSeconds: 1
#表示每次探测的超时时间，就是探测这个过程耗时，小于间隔时间，在这个秒数没必须完成探测。

httpGet探针

apiVersion: v1
kind: Pod
metadata:labels:run: nginx1name: nginx1
spec:containers:- image: nginx:1.22name: nginx1livenessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 4periodSeconds: 2

正常示范

错误示范1

错误示范2

tcpSocket探针

apiVersion: v1
kind: Pod
metadata:labels:run: nginx1name: nginx1
spec:containers:- image: nginx:1.22name: nginx1livenessProbe:tcpSocket:port: 81initialDelaySeconds: 4periodSeconds: 2