Pod容器分类
- 最小部署单元
- 一组容器的集合
- 一个Pod中的容器共享网络命名空间
- 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
[[email protected] 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/
在实际生产环境中，想要使得开发的应用程序完全没有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
总结
1、pod三个分类
2、镜像拉取策略哪个关键字
3、资源限制哪2个字段
4、重启策略哪3个策略
5、健康检查哪2个类型 哪3个检查方法
原文地址：http://blog.51cto.com/jacksoner/2328999