《三》深入理解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里的容器最多使用多少资源

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

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

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

总结：
1、设置最大的limit 的配置
2、设置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/

扫描二维码关注公众号，回复： 4463184 查看本文章

 在实际生产环境中，想要使得开发的应用程序完全没有bug，在任何时候都运行正常，几乎 是不可能的任务。因此，我们需要一套管理系统，来对用户的应用程序执行周期性的健康检查和修复操作。这套管理系统必须运行在应用程序之外，这一点非常重要一一如果它是应用程序的一部分，极有可能会和应用程序一起崩溃。因此，在Kubernetes中，系统和应用程序的健康检查是由Kubelet来完成的。

1、进程级健康检查
最简单的健康检查是进程级的健康检查，即检验容器进程是否存活。这类健康检查的监控粒 度是在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