副本机制和其他控制器

副本机制和其他控制器: 部署托管的pod

保持pod健康

只要pod调度到某个节点, 该节点上的Kubelet就会运行pod的容器, 从此只要该pod存在, 就会保持运行. 如果容器的主进程崩溃, Kubelet将重启容器.

程序可以能因为无限循环或死锁而停止响应, 为确保应用程序在这种情况下可以重新启动, 必须从外部检查应用程序的运行状态, 而不是依赖于应用的内部检测.

介绍存活探针

Kubernetes可以通过存活探针(liveness probe)检查容器是否还在运行. 可以为pod中每个容器单独指定存活探针, 如果检测失败, Kubernetes将定期执行探针并重启容器.

Kubernetes有以下三种检测容器的机制:

HTTP GET探针对容器的IP地址(你指定的端口和路径)执行HTTP GET请求. 如果探测器收到响应, 并且响应码不代表错误, 则认为探测成功. 如果服务器返回错误响应码或者根本没有响应, 那么特测被认为是失败的, 容器将被重新启动.

TCP套接字探针尝试与容器指定端口建立TCP连接. 如果连接成功建立, 则探测成功. 否则, 容器重新启动.

Exec探针在容器内执行任意命令, 并检查命令的退出状态码. 如果状态码是0, 则探测成功. 所有其他状态码都认为失败.

创建基于HTTP的存活探针

liveness:
	httpGet:
		path: /
		port: 8080

该pod的描述文件定义了一个httpGet探针, 该探针告诉Kubernetes定期在端口8080路径上执行HTTP GET请求, 以确定容器是否健康.

使用存活探针

获取崩溃容器的应用日志

如果容器重启, Kubectl logs命令将显示当前容器的日志. 当你想知道前一个容器为什么终止时. 可以通过添加--previous选项.

容器被强行终止时, 会创建一个全新的容器--而不是重启原来的容器.

配置存活探针的附加属性

除了明确指定的存活探针选项, 还可以看到其他属性, 例如delay, timeout, period等.

请务必记得设置一个初始延时来说明应用程序的启动时间.

创建有效的存活探针

对于在生产中运行的pod, 一定要定义一个存活探针. 没有探针的话, Kubernetes无法知道你的应用是否还活着. 只要进程还存在, Kubernetes会认为容器是健康的.

了解ReplicationController

ReplicationController是一种Kubernetes资源, 可确保它的pod始终保持运行状态.

ReplicationController的操作

RelicationController会持续监控正在运行的pod列表, 并保证相应”类型”的pod的数目与期望的相符.

介绍控制器的协调流程

ReplicationController的工作是确保pod的数量始终与其标签选择器匹配. 如果不匹配, 则ReplicationController将根据所需, 采取适当地操作来协调pod的数量.

使用DaemonSet在每个节点上运行一个pod

运行执行单个任务的pod

介绍Job资源

在发生节点故障时, 该节点上由Job管理的pod将按照ReplicaSet的pod的方式, 重新安排到其他节点. 如果进程本身异常退出(进程返回错误退出代码时), 可以将Job配置为重新启动容器.

安排Job定期运行或在将来运行一次

Job资源在创建时会立即运行pod. 但是许多批处理任务需要在特定时间运行, 或者在指定的时间间隔內重复运行. 在Linux和类UNIX操作系统中, 这些任务通常被称为cron任务.

了解计划任务的运行方式

在正常情况下, CronJob总是计划为配置中的每个执行创建一个Job, 但是可能会同时创建两个Job, 或者根本没有创建. 为了解决第一个问题, 你的任务应该是幂等的. 对于第二个问题, 请确保下一个任务完成本应该由上一次的(错过的)运行完成的工作.