Pod容器分类

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

Infrastructure Container：基础容器

• 维护整个Pod网络空间

InitContainers：初始化容器

• 先于业务容器开始执行

Containers：业务容器

• 并行启动

镜像拉取策略（imagePullPolicy）

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

apiVersion: v1kind: Podmetadata:  name: foo  namespace: awesomeappsspec:  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）

参考文档：

在实际生产环境中，想要使得开发的应用程序完全没有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=akubectl label nodes 192.168.1.24 team=b

查看：

kubectl get nodes --show-labels

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

故障排查

解决：

查看日志kubectl describe TYPE/NAMEkubectl logskubectl exec -it POD

总结

1、pod三个分类

2、镜像拉取策略哪个关键字3、资源限制哪2个字段4、重启策略哪3个策略5、健康检查哪2个类型 哪3个检查方法