《三》深刻理解Pod对象

Pod容器分类

1. 最小部署单元
2. 一组容器的集合
3. 一个Pod中的容器共享网络命名空间
4. Pod是短暂的

Infrastructure Container：基础容器
• 维护整个Pod网络空间
InitContainers：初始化容器
• 先于业务容器开始执行
Containers：业务容器
• 并行启动

镜像拉取策略（imagePullPolicy）

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

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
      imagePullPolicy: IfNotPresent

资源限制

默认状况下pod运行没有任何CPU和内存的限制。这意味着系统中的pod能够尽量多的消耗CPU和内存在pod执行的节点。
基于多种缘由用户可能但愿对系统中的单个pod的资源使用量进行限制。

requests：容器运行是，最低资源需求，也就是说最少须要多少资源容器才能正常运行
limits：总的资源的限制，也就是说一个pod里的容器最多使用多少资源

说明：
一、如下有2个容器（db、wp）
二、cpu：‘250m’ ：表示使用了1核的百分之25；500m 就是使用1核的50%
三、cpu: 0.1 ：表示0.1=100m

查看限制的属性：
查出分配的节点的IP
[root@docker demo]# kubectl describe pods frontend

查看限制的属性：
kubectl describe nodes 192.168.1.23

总结：
一、设置最大的limit 的配置
二、设置1核的cpu就是 cpu：1；cpu最大限制2核

重启策略（restartPolicy）

• Always：当容器终止退出后，老是重启容器，默认策略。好比 web服务器，持久性的服务
• OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
• Never:：当容器异常终止退出，从不重启容器。

验证：

查看：

健康检查（Probe）

参考文档：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

在实际生产环境中，想要使得开发的应用程序彻底没有bug，在任什么时候候都运行正常，几乎 是不可能的任务。所以，咱们须要一套管理系统，来对用户的应用程序执行周期性的健康检查和修复操做。这套管理系统必须运行在应用程序以外，这一点很是重要一一若是它是应用程序的一部分，极有可能会和应用程序一块儿崩溃。所以，在Kubernetes中，系统和应用程序的健康检查是由Kubelet来完成的。

一、进程级健康检查
最简单的健康检查是进程级的健康检查，即检验容器进程是否存活。这类健康检查的监控粒 度是在Kubernetes集群中运行的单一容器。Kubelet会按期经过Docker Daemon获取全部Docker进程的运行状况，若是发现某个Docker容器未正常运行，则从新启动该容器进程。目前，进程级的健康检查都是默认启用的。

2．业务级健康检查
在不少实际场景下，仅仅使用进程级健康检查还远远不够。有时，从Docker的角度来看，容器进程依旧在运行；可是若是从应用程序的角度来看，代码处于死锁状态，即容器永远都没法正常响应用户的业务

为了解决以上问题，Kubernetes引人了一个在容器内执行的活性探针（liveness probe）的概念，以支持用户本身实现应用业务级的健康检查。这些检查项由Kubelet代为执行，以确保用户的应用程序正确运转，至于什么样的状态才算“正确”，则由用户本身定义。Kubernetes支持3种类型的应用健康检查动做，分别为HTTP Get、Container Exec和TCP Socket。我的感受exec的方式仍是最通用的，由于不是每一个服务都有http服务，但每一个服务均可以在本身内部定义健康检查的job，按期执行，而后将检查结果保存到一个特定的文件中，外部探针就不断的查看这个健康文件就OK了。

Probe有如下两种类型
livenessProbe
若是检查失败，将杀死容器，根据Pod的restartPolicy来操做。

readinessProbe
若是检查失败，Kubernetes会把Pod从service endpoints中剔除。

Probe支持如下三种检查方

httpGet
发送HTTP请求，返回200-400范围状态码为成功，好比200成功，400不成功。

exec
执行Shell命令返回状态码是0为成功。

tcpSocket
发起TCP Socket创建成功。

initialDelaySeconds
initialDelaySeconds: 5
第一次使用probe时，须要等待5秒

periodSeconds
periodSeconds: 5
每隔5秒执行一个活性探针

2.1 Container Exec
当/tmp/healthy 这个被删除了，再次 cat /tmp/healthy 不存在，状态码非0，就执行livenessProbe 这个规则

2.2 Container HTTP

说明：大于或等于200且小于400的任何代码表示成功。任何其余代码都指示失败。

2.3 Container TCP
经过此配置，kubelet将尝试打开指定端口上的容器的套接字。若是能够创建链接，则认为容器是健康的，若是不能，则认为它是失败的。

调度约束

说明

用户建立一个pod，apiServer收到请求后，会将这个状态（pod属性）写入到etcd中，apiServer经过watch 将新的pod 通知给Scheduler（调度器），Scheduler根据自身的调度算法将pod分配到哪一个node上，这些的配置信息会存在etcd中，node上的kubelet 经过watch 绑定pod，并启动docker,再更新pod状态（运行，仍是中止）etcd中，因此kubelet 展现给用户

apiServer：至关于管家
etcd:至关于帐本

nodeName用于将Pod调度到指定的Node名称上
nodeSelector用于将Pod调度到匹配Label的Node上

新建label标签
kubectl label nodes 192.168.1.23 team=a
kubectl label nodes 192.168.1.24 team=b

查看：
kubectl get nodes --show-labels

经过 kubectl describe pods pod-example 查看调度器到哪一个节点上

故障排查

解决：
查看日志
kubectl describe TYPE/NAME
kubectl logs
kubectl exec -it POD

总结

一、pod三个分类二、镜像拉取策略哪一个关键字三、资源限制哪2个字段四、重启策略哪3个策略五、健康检查哪2个类型 哪3个检查方法