网站建设详细描述产品的是什么,制作 网站 盈利,网站首页空白 wordpress,销售网站免费模板k8s系列四——资源对象
pod概念 思考#xff1a;为什么k8s会引出pod这个概念#xff0c;容器不能解决么#xff1f; 我的理解#xff1a;一组密切相关的服务使用容器的话#xff0c;如果他们的镜像不在一个容器里的话#xff0c;那么就需要配置反向代理进行通信#xf…k8s系列四——资源对象
pod概念 思考为什么k8s会引出pod这个概念容器不能解决么 我的理解一组密切相关的服务使用容器的话如果他们的镜像不在一个容器里的话那么就需要配置反向代理进行通信没办法进行localhost实现通信 pod类型
自主式pod不是被控制器管理的Pod死亡后不会被拉起来也不会有人创建新的Pod 每个Pod里运行着一个特殊的被称为Pause容器其他容器为业务容器这些业务容器共享Pause容器的网络栈和Volume挂载卷因此他们之间通信和数据交互更为高效。
在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中同一个Pod里的容器之间仅需通过localhost就能互相通信这样也意味着同一个pod内容器的端口不能冲突。 控制器管理的Pod POD控制器类型 ReplicationController ReplicaSet Deployment ReplicationController 确保期望值少了就创建新的Pod替代多了会自动回收。(官方已抛弃) 新版本的K8S种建议使用ReplicaSet来取代ReplicationController没有本质不同但只有ReplicaSet 支持集合式的selector每个Pod有不同标签ReplicaSet 操作Pod可以按照标签条件操作 虽然ReplicaSet 可以独立但是一般还是建议使用Deployment来自动管理ReplicaSet 这样就无需担心跟其他机制不兼容问题如ReplicaSet 不支持rolling-update滚动更新但是Deployment支持Deployment并不支持Pod创建所以这俩要一起运行。 滚动更新的含义 比如有两个pod里面的镜像是V1版本现如今我们需要V2版本的那么k8s就会先启动一个V2版本的pod然后删除其中一个v1版本然后再启动一个V2版本pod在删除最后一个V1版本的 Deployment原理 创建3个pod为V1版本的镜像 滚动更新更新V1到V2新建个RS然后创建1个V2删除1个V1 从而达到滚动更新的状态此时RS停用、保留可以回滚 如果v2版本有bug还可以回滚undo即可 旧的RS启用开始回滚老版V1以此类推。 HPAHorizontalPodAutoScale HPAHorizontalPodAutoScale根据利用率平滑扩展仅适用于DaemonSet和ReplicaSet 在V1版本中支持根据Pod的利用率扩容在vlalpha版本中支持根据内存和用户自定义的metric扩缩容。 HPA基于RS定义并且监控V2Pod的资源利用率 当cpu 80 后符合条件会创建Pod 每次创建后判断条件符合后继续创建直到最大值。期间如果cpu 80 了就会停止创建。使用率小就回收直到最小值实现水平自动扩展弹性伸缩。 StatefulSet 为了解决有状态服务的问题Deployment和RS是为了解决无状态服务而设计Docker主要也是其场景包括 - 稳定的持久化存储即有个Pod死了重新调度回来以后还是能访问到相同的持久化数据数据不丢失基于PVC实现。 - 稳定的网络标识即重新调度后的PodName和HostName不变基于Headless Service即没有Cluster IP的Service来实现 - 有序部署有序扩展按照顺序进行MAN从0到N-1在下一个Pod运行前之前所有的Pod必须是running和Ready状态基于init containers来实现。 - 有序收缩有序删除即从N-1到0 Nagix Apache Mysql DaemonSet 确保全部或者一些Node上 运行一个Pod的副本。当有Node加入集群时也会为他们新增一个Pod。当有Node从集群移除时这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。除非打污点正常情况所有Node都会运行一个且只有一个Pod。 典型用法: 运行集群存储 daemon,例如在每个Node上运行glusterd、ceph在每个Node上运行日志收集daemon例如fluentd、logstash在每个Node上运行监控daemon例如Prometheus Node Exporter、Zabix Agent 都可以封装在DaemonSet中在每个Node上运行帮我们收集数据。 可以在一个node里面运行多个daemonset也可以将多个组装成一个pod运行 JobCronjob job负责批处理任务即仅执行一次的任务他保证批处理任务的一个或者多个Pod成功结束。 比如要备份数据库备份代码可以放到统一Pod里再放到Job里执行与Linux直接运行不同点是是封装好的Job可以重复利用并且脚本执行异常退出可以重复执行并且可以设置正常退出次数才算Job执行成功 Cronjob管理基于时间的Job即 在给定时间点运行一次周期性地在给定时间点运行
pod的状态
Pod的status字段是一个PodStatus的对象PodStatus中有一个phase字段。
无论是手动创建还是通过Deployment等控制器创建Pod对象总是应该处于其生命进程中以下几个相位phase之一。 挂起PendingAPI Server创建了pod资源对象已存入etcd中但它尚未被调度完成或者仍处于从仓库下载镜像的过程中。 运行中RunningPod已经被调度至某节点并且所有容器都已经被kubelet创建完成。 成功SucceededPod中的所有容器都已经成功终止并且不会被重启 失败FailedPod中的所有容器都已终止了并且至少有一个容器是因为失败终止。即容器以非0状态退出或者被系统禁止。 未知UnknownApi Server无法正常获取到Pod对象的状态信息通常是由于无法与所在工作节点的kubelet通信所致。 服务发现
Client访问service的IP和端口使用RRRound ribbon轮询等算法间接访问到Pod。 客户端访问一组podservice是通过标签来进行收集pod进行统一代理 k8s的pod与pod之间的通讯方案
网络通讯方式
网络通讯模式
Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中所有的pod都可以通过对方IP直接到达其实底层有很多转换机制这在GCEGoogle Compute Engine 里面是现成的网络模型K8S假定这个网络已存在。而在私有云搭建K8S集群就不能假定这个网络已经存在了。我们需要自己实现这个网络假设将不同节点上的Docker容器之间互相访问先打通然后再运行K8S。
同一个Pod内的多个容器间lo pause
各Pod之间的通讯 Overlay Network
Pod与Service之间的通讯各节点的Iptables规则新版本支持LVS 转发上限、效率更高
网络解决方案K8SFlannel
Flannel是CoreOS团队针对K8S设计的一个网络规划服务简单来说他他的功能是让集群中的不同节点主机创建的Docker容器具有全集群唯一的虚拟IP主机。而且它还能在这些IP之间建立一个覆盖网络Overlay Network通过这个覆盖网络将数据包原封不动地传递到目标容器内 ETCD之Flannel提供说明
存储管理Flannel可分配的IP地址段资源监控ETCD中每个Pod的实际地址并在内存中建立维护Pod节点路由表
总结
不同情况下网络通信方式 同一个 Pod 内部通讯同一个 Pod 共享同一个网络命名空间共享同一个 Linux(pod内的pause) 协议栈 Pod1 至 Pod2不同pod之间的访问 Pod1 与 Pod2 在同一台机器由 Docker0 网桥直接转发请求至 Pod2不需要经过 FlannelPod1 与 Pod2 不在同一台主机Pod的地址是与docker0在同一个网段的但docker0网段与宿主机网卡是两个完全不同的IP网段并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来通过 这个关联让Pod可以互相访问 Pod 至 Service 的网络 目前基于性能考虑全部为 iptables 维护和转发最新版转发模式可以修改为LVS模式 Pod 到外网 Pod 向外网发送请求查找路由表, 转发数据包到宿主机的网卡宿主网卡完成路由选择后iptables执 行Masquerade把源 IP 更改为宿主网卡的 IP然后向外网服务器发送请求 外网访问 PodService
组件通讯示意图 节点网络真实的物理网络
pod网络与service网络均为虚拟的私有网络
资源清单
等同于剧本里面已经写好了每一步怎么去做k8s接收到剧本之后去执行从而达到预期
资源K8s 中所有的内容都抽象为资源 资源实例化之后叫做对象
K8S 中的资源
依据资源的主要功能作为分类标准Kubernetes的API对象大体可分为五个类别如下
级别类型名称备注名称空间工作负载(Workload)Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、Cronjob ( ReplicationController 在 v1.11 版本被废弃 )名称空间负载均衡(Discovery LB)Service、Ingress、…名称空间配置和存储(ConfigStorage)Volume( 存储卷 )、CSI( 容器存储接口,可以扩展各种各样的第三方存储卷 )名称空间特殊类型的存储卷ConfigMap( 当配置中心来使用的资源类型热更新 )、Secret(保存敏感数据)、 DownwardAPI(把外部环境中的信息输出给容器)集群级资源集群(Cluster)Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding一旦经过定义以后在全集群中都能被可见以及调用元数据型资源元数据(metadata)HPA、PodTemplate、LimitRange根据某些指标进行操作
资源清单
资源清单含义
在 k8s 中一般使用 yaml 格式的文件来创建符合我们预期期望的 pod 这样的 yaml 文件我们一般 称为资源清单
简单说明
是一个可读性高用来表达数据序列的格式。YAML 的意思其实是仍是一种标记语言但为了强调这种语言以数 据做为中心而不是以标记语言为重点
基本语法
缩进时不允许使用Tab键只允许使用空格缩进的空格数目不重要只要相同层级的元素左侧对齐即可#标识注释从这个字符一直到行尾都会被解释器忽略
YAML 支持的数据结构
对象键值对的集合又称为映射mapping/ 哈希hashes / 字典dictionary数组一组按次序排列的值又称为序列sequence / 列表 list纯量scalars单个的、不可再分的值
对象类型对象的一组键值对使用冒号结构表示
name: Steve
age: 18Yaml 也允许另一种写法将所有键值对写成一个行内对象
hash: { name: Steve, age: 18 }数组类型一组连词线开头的行构成一个数组
animal:- cat- dog数组也可以采用行内表示法
animal: [Cat, Dog]复合结构对象和数组可以结合使用形成复合结构
languages:-Ruby-Perl
websites:
YAML: yaml.org
Ruby: ruby-lang.org
Perl: use.perl.org纯量纯量是最基本的、不可再分的值。以下数据类型都属于纯量
1 字符串 布尔值 整数 浮点数 Null
2 时间 日期
数值直接以字面量的形式表示
number: 12.30
布尔值用true和false表示
isSet: truenull用 ~ 表示
parent: ~时间采用 ISO8601 格式
iso8601: 2001-12-14t21:59:43.10-05:00日期采用复合 iso8601 格式的年、月、日表示
date: 1976-07-31YAML 允许使用两个感叹号强制转换数据类型
e: !!str 123
f: !!str true字符串
字符串默认不使用引号表示
str: 这是一行字符串如果字符串之中包含空格或特殊字符需要放在引号之中
str: 内容 字符串单引号和双引号都可以使用双引号不会对特殊字符转义
s1: 内容\n字符串
s2: 内容\n字符串单引号之中如果还有单引号必须连续使用两个单引号转义
str: labors day字符串可以写成多行从第二行开始必须有一个单空格缩进。换行符会被转为 空格
str: 这是一段多行字符串多行字符串可以使用|保留换行符也可以使用折叠换行
this:|FooBarthat: FooBar表示保留文字块末尾的换行- 表示删除字符串末尾的换行
s1: |Foos2: |Foos3: |-Foo常用字段的解释
必须存在的属性:
参数名字段类型说明versionstring这里是指的是K8S API的版本目前基本上是v1可以用kubectl api-versions命令查询kindstring这里指的是yaml文件定义的资源类型和角色,比如:Podmetadataobject元数据对象固定值就写metadatametadata. namestring元数据对象的名字这里由我们编写比如命名Pod的名字metadata.namespacestring元数据对象的命名空间,由我们自身定义specobject详细定义对象固定值就写Specspec.containers[]list这里是Spec对象的容器列表定义,是个列表spec.containers[]. namestring这里定义容器的名字spec.containers[]. imagestring这里定义要用到的镜像名称
主要对象
参数名字段类型说明spec.containers[].namestring定义容器的名字spec.containers[J.imagestring定义要用到的镜像名称spec.containers[]. imagePullPolicystring定义镜像拉取策略,有Always、Never、lfNotPresent三个值可选(1) Always:意思是每次都尝试重新拉取镜像(2)Never:表示仅使用本地镜像(3)IfNotPresent:如果本地有镜像就使用本地镜像没有就拉取在线镜像。上面三个值都没设置的话,默认是Always.spec.containers[].command[]List指定容器启动命令因为是数组可以指定多个不指定则使用镜像打包时使用的启动命令。spec.containers[].args[]List指定容器启动命令参数因为是数组可以指定多个。spec.containers[].workingDirstring指定容器的工作目录spec. containers[]. volumeMounts[]List指定容器内部的存储卷配置spec.containers[].volumeMounts[].nameString指定可以被容器挂载的存储卷的名称spec.containers[].volumeMounts[].mountPathString指定可以被容器挂载的存储卷的路径spec.containers[].volumeMounts[]J.readOnlyString设置存储卷路径的读写模式,ture 或者false,默认为读写模式spec.containers[].ports[]List指定容器需要用到的端口列表spec.containers[].ports[].nameString指定端口名称spec.containers[].ports[].containerPortString指定容器需要监听的端口号spec.containers[].ports[].hostPortString指定容器所在主机需要监听的端口号,默认跟上面containerPort相同,注意设置了hostPort同一台主机无法启动该容器的相同副本(因为主机的端口号不能相同这样会冲突)spec.containers[].ports[].protocolString指定端口协议,支持TCP和UDP默认值为TCPspec.containers[].env[]List指定容器运行前需设置的环境变量列表spec.containers[].env].nameString指定环境变量名称spec.containers[j.env[.valueString指定环境变量值spec.containers[J.resourcesobject指定资源限制和资源请求的值(这里开始就是设置容器的资源上限)spec.containers[].resources.limitsobject指定设置容器运行时资源的运行上限spec.containers[J. resources.limits.cpuString指定CPU的限制,单位为core数,将用于docker run --cpu-shares参数(这里前面文章Pod资源限制有讲过)spec.containers[]J.resources.limits.memoryString指定MEM内存的限制,单位为MIB、GiBspec.containers[].resources.requestsobject指定容器启动和调度时的限制设置spec.containers[].resources.requests.cpuStringCPU请求,单位为core数容器启动时初始化可用数量spec.containers[].resources.requests.memoryString内存请求单位为MIB、GiB容器启动的初始化可用数量
额外的参数项
参数名字段类型说明spec.restartPolicyString定义Pod的重启策略可选值为Always、OnFailure默认值为Always.1.Always: Pod—且终止运行则无论容器是如何终止的kubelet服务都将重启它。2.OnFailure:只有Pod以非零退出码终止时kubelet才会重启该容器。如果容器正常结束(退出码为0),则kubelet将不会重启它。3. Never: Pod终止后kubelet将退出码报告给Master不会重启该Pod。spec.nodeSelectorobject定义Node的Label过滤标签以keyvalue格式指定spec.imagePullSecretsobject定义pull镜像时使用secret名称以name:secretkey格式指定spec.hostNetworkBoolean定义是否使用主机网络模式,默认值为false。设置true表示使用宿主机网络不使用docker网桥,同时设置了true将无法在同一台宿主机上启动第二个副本。
如果想了解更详细的可以使用命令
kubectl explain pod # 结果显示
[rootk8s-master ~]# kubectl explain pods
KIND: Pod
VERSION: v1DESCRIPTION:Pod is a collection of containers that can run on a host. This resource iscreated by clients and scheduled onto hosts.FIELDS:apiVersion stringAPIVersion defines the versioned schema of this representation of anobject. Servers should convert recognized schemas to the latest internalvalue, and may reject unrecognized values. More info:https://git.k8s.io/community/contributors/devel/api-conventions.md#resourceskind stringKind is a string value representing the REST resource this objectrepresents. Servers may infer this from the endpoint the client submitsrequests to. Cannot be updated. In CamelCase. More info:https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kindsmetadata ObjectStandard objects metadata. More info:https://git.k8s.io/community/contributors/devel/api-conventions.md#metadataspec ObjectSpecification of the desired behavior of the pod. More info:https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-statusstatus ObjectMost recently observed status of the pod. This data may not be up to date.Populated by the system. Read-only. More info:https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
# 如果需要了解某一级字段表示的对象之下的二级对象字段时只需要指定其二级字段的对象名称即可三级和四级字段对象等的查看方式依次类推。例如查看Pod资源的Spec对象支持嵌套使用的二级字段:
[rootk8s-master ~]# kubectl explain pods.spec# 显示如下
RESOURCE: spec ObjectDESCRIPTION:Specification of the desired behavior of the pod. More info:https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-statusPodSpec is a description of a pod.FIELDS:activeDeadlineSeconds integerOptional duration in seconds the pod may be active on the node relative toStartTime before the system will actively try to mark it failed and killassociated containers. Value must be a positive integer.affinity ObjectIf specified, the pods scheduling constraintsautomountServiceAccountToken booleanAutomountServiceAccountToken indicates whether a service account tokenshould be automatically mounted......标签相关命令
[rootk8s-master ~]# kubectl get pods --show-labels #查看pod信息时并显示对象的标签信息
NAME READY STATUS RESTARTS AGE LABELS
pod-demo 2/2 Running 5 5h13m appmyapp,tierfrontend[rootk8s-master ~]# kubectl get pods -l app #过滤包含app标签的pod
NAME READY STATUS RESTARTS AGE
pod-demo 2/2 Running 5 5h20m[rootk8s-master ~]# kubectl get pods -l app,tier #过滤同时包含apptier标签的pod
NAME READY STATUS RESTARTS AGE
pod-demo 2/2 Running 5 5h20m[rootk8s-master ~]# kubectl get pods -L app #显示有app键的标签信息
NAME READY STATUS RESTARTS AGE APP
pod-demo 2/2 Running 5 5h21m myapp[rootk8s-master ~]# kubectl get pods -L app,tier #显示有app和tier键的标签信息
NAME READY STATUS RESTARTS AGE APP TIER
pod-demo 2/2 Running 5 5h21m myapp frontend排查问题用到得命令
kubectl describe pod mynginx-pod第二个 test容器报错了
查看test容器
kubectl log mynginx-pod -c test
kubectl logs mynginx-pod -c test80端口被占用
容器生命周期
pod创建过程 kubctl —— api —— kublet —— CRI下图为CRI内部流程
用户通过kubectl或其他API客户端提交了Pod Spec给API Server。API Server尝试着将Pod对象的相关信息存入etcd中待写入操作执行完成API Server即会返回确认信息至客户端。API Server开始反映etcd中的状态变化。所有的kubernetes组件均使用“watch”机制来跟踪检查API Server上的相关的变动。kube-scheduler调度器通过其“watcher”觉察到API Server创建了新的Pod对象但尚未绑定至任何工作节点。kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新至API Server。调度结果信息由API Server更新至etcd存储系统而且API Server也开始反映此Pod对象的调度结果Pod被调度到的目标工作节点上的kubelet尝试在当前节点上调用Docker启动容器并将容器的结果状态返回送至API Server。API Server将Pod状态信息存入etcd系统中。在etcd确认写入操作成功完成后API Server将确认信息发送至相关的kubelet事件将通过它被接受。
CRI流程 会创建一个名为PAUSE的基础容器创建一个或者多个initC容器创建完成即刻死亡此步骤可以没有创建MainC容器 在启动时候会执行一个START的脚本命令结束的时候会执行一个STOP的脚本命令在容器启动过程中会经过readiness健康就绪检查如果检查通过则可对外提供服务未通过检测的容器意味着其尚未准备就绪端点控制器如Service对象会将其IP从所有匹配到此Pod对象的Service对象的端点列表中移除检测通过之后会再将其IP添加至端点列表中在容器运行过程中一直会有一个liveiness健康存活检查用于判定容器是否处于“运行”Running状态如果不符合存活规则容器对外则不可用kubelet将杀死容器并根据重启策略restartPolicy决定是否将其重启未定义存活检测的容器的默认状态为“Success”。
pod生命周期中重要行为
Init 容器
Pod 能够具有多个容器应用运行在容器里面但是它也可能有一个或多个先于应用容器启动的 Init 容器
Init 容器与普通的容器非常像除了如下两点
Init 容器总是运行到成功完成为止每个 Init 容器都必须在下一个 Init 容器启动之前成功完成
如果 Pod 的 Init 容器失败Kubernetes 会不断地重启该 Pod直到 Init 容器成功为止。然而如果 Pod 对应的 restartPolicy 为 Never它不会重新启动
Init 容器的作用
因为 Init 容器具有与应用程序容器分离的单独镜像所以它们的启动相关代码具有如下优势 它们可以包含并运行实用工具但是出于安全考虑是不建议在应用程序容器镜像中包含这 些实用工具的 比如提前创建 mainC 所必需的文件数据 它们可以包含使用工具和定制化代码来安装但是不能出现在应用程序镜像中。例如创建 镜像没必要 FROM 另一个镜像只需要在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具 应用程序镜像可以分离出创建和部署的角色而没有必要联合它们构建一个单独的镜像。 Init 容器使用 Linux Namespace所以相对应用程序容器来说具有不同的文件系统视图。因 此它们能够具有访问 Secret 的权限而应用程序容器则不能。 比如 mainC在启动后需要运行或者调用 linux某个文件夹下的所有数据 A但A mainC没有权限访问 如果 我把A 的权限放给mainC这就会导致mainC的操作会影响到A的所有数据而mainC只需要A中的某一个文件在这种情况下我们完全可以把A的权限赋予给intC再由intC写入到mainC 它们必须在应用程序容器启动之前运行完成而应用程序容器是并行运行的所以 Init 容 器能够提供了一种简单的阻塞或延迟应用容器的启动的方法直到满足了一组先决条件。 一个pod内包含2个容器apache依赖mysql因为是并行运行的有可能apache先于mysql启动这个时候apache又访问不到mysql因为mysql没启动起来所以存活探针探测到就会一直重启 这个时候我们可以添加一个initC用来去探测mysql是否正常如果正常了就退出initC容器apache容器在启动就可以了。 init 模板
apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app: myapp
spec:containers:- name: myapp-containerimage: busyboxcommand: [sh, -c, echo The app is running! sleep 3600]initContainers:- name: init-myserviceimage: busyboxcommand: [sh, -c, until nslookup myservice; do echo waiting for myservice; sleep 2; done;]- name: init-mydbimage: busyboxcommand: [sh, -c, until nslookup mydb; do echo waiting for mydb; sleep 2; done;]上述yaml的意思为 启动一个pod这个pod内部运行一个容器 myapp在成功启动myapp之前初始化了两个initC主要为了探测myservicemydb是否存在如果都探测成功initC容器退出开始启动myapp主容器如果不成功则myapp不会启动
kind: Service
apiVersion: v1
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377特殊说明
在Pod 启动过程中Init容器会按顺序在 网络和数据卷即pause容器 初始化之后启动。每个容器必须在下一个容器启动之前成功退出如果由于运行时或失败退出将导致容器启动失败它会根据 Pod 的 restartPolicy指定的策略进行重试。然而如果 Pod 的restartPolicy设置为 AlwaysInit 容器失败时会使用RestartPolicy策略在所有的 Init容器没有成功之前Pod 将不会变成Ready状态。Init容器的端l将不会在Service 中进行聚集。正在初始化中的Pod 处于Pending 状态但应该会将Initializing 状态设置为true如果Pod重启所有Init容器必须重新执行对Init 容器spec的修改被限制在容器image字段修改其他字段都不会生效。更改 Init容器的image字段等价于重启该Pod。Init容器具有应用容器的所有字段。除了readinessProbe因为 Init容器无法定义不同于完成(completion的就绪readiness之外的其他状态。这会在验证过程中强制执行在 Pod 中的每个app 和Init容器的名称必须唯一;与任何其它容器共享同一个名称会在验证时抛出错误
容器探测
容器探测container probe是Pod对象生命周期中的一项重要的日常任务它是kubelet对容器周期性执行的健康状态诊断诊断操作由容器的处理器handler进行定义。Kubernetes支持三种处理器用于Pod探测 ExecAction在容器内执行指定命令并根据其返回的状态码进行诊断的操作称为Exec探测状态码为0表示成功否则即为不健康状态。 TCPSocketAction通过与容器的某TCP端口尝试建立连接进行诊断端口能够成功打开即为正常否则为不健康状态。 HTTPGetAction通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断响应码为2xx或3xx时即为成功否则为失败。
任何一种探测方式都可能存在三种结果“Success”成功、“Failure”失败、“Unknown”未知只有success表示成功通过检测。
容器探测分为两种类型
存活性探测livenessProbe用于判定容器是否处于“运行”Running状态一旦此类检测未通过kubelet将杀死容器并根据重启策略restartPolicy决定是否将其重启未定义存活检测的容器的默认状态为“Success”。就绪性探测readinessProbe用于判断容器是否准备就绪并可对外提供服务如果就绪探测失败端点控制器将从与 Pod 匹配的 所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容 器不提供就绪探针则默认状态为 Success。
检测探针 - 就绪检测(符合条件才READY状态) 测试
# 前提 myapp文件中只有index.html没有index1.html
apiVersion: v1
kind: Pod
metadata:name: readiness-httpget-podnamespace: default
spec:containers:- name: readiness-httpget-containerimage: wangyanglinux/myapp:v1imagePullPolicy: IfNotPresentreadinessProbe:httpGet:port: 80path: /index1.html# 容器启动后多长时间进行检测 initialDelaySeconds: 1# 重试时间periodSeconds: 3运行后的结果
[rootk8s -masterol~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
liveness-tcp-pod 1/1 Running 1 7d18h
readiness-http 0/1 Running 0 2m44s通过上面测试可以看出readinessProbe发起的测试就会失败此时我们再查看pod的状态会发现并不会将pod删除重新启动只是在READY字段可以看出当前的Pod处于未就绪状态。
如果是就绪状态则显示
[rootk8s-master ~]# kubectl get pods 查看pod状态
NAME READY STATUS RESTARTS AGE
liveness-tcp-pod 1/1 Running 1 7d18h
readiness-http 1/1 Running 0 7s存活性探测示例(设置exec探针示例)
apiVersion: v1
kind: Pod
metadata:name: liveness-exec-podnamespace: defaultlabels:test: liveness-exec
spec:containers:- name: liveness-exec-containerimage: busybox:latestimagePullPolicy: IfNotPresentcommand: [/bin/sh,-c,touch /tmp/healthy; sleep 60; rm -f /tmp/healthy; sleep 3600]livenessProbe:exec:command: [test,-e,/tmp/healthy]initialDelaySeconds: 1periodSeconds: 3[rootk8s-master ~]# kubectl create -f manfests/liveness-exec.yaml #创建pod
pod/liveness-exec-pod created
[rootk8s-master ~]# kubectl get pods #查看pod
NAME READY STATUS RESTARTS AGE
liveness-exec-pod 1/1 Running 0 6s#等待一段时间后再次查看其状态
[rootk8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-exec-pod 1/1 Running 2 2m46s上面的资源清单中定义了一个pod对象基于busybox镜像启动一个运行“touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 3600命令的容器此命令在容器启动时创建了/tmp/healthy文件并于60秒之后将其删除。存活性探针运行”test -e /tmp/healthy命令检查/tmp/healthy文件的存在性若文件存在则返回状态码0表示成功通过测试。在60秒内使用“kubectl describe pods/liveness-exec-pod”查看其详细信息其存活性探测不会出现错误。而超过60秒之后再执行该命令查看详细信息可以发现存活性探测出现了故障并且还可通过“kubectl get pods查看该pod的重启的相关信息。
存活性探测示例(设置HTTP探针示例) 基于HTTP的探测HTTPGetAction向目标容器发起一个HTTP请求根据其响应码进行结果判定响应码如2xx或3xx时表示测试通过。通过该命令”# kubectl explain pod.spec.containers.livenessProbe.httpGet“查看httpGet定义的字段 host 请求的主机地址默认为Pod IP也可以在httpHeaders中使用“Host:”来定义。 httpHeaders []Object自定义的请求报文首部。 port 请求的端口必选字段。 path 请求的HTTP资源路径即URL path。 scheme 建立连接使用的协议仅可为HTTP或HTTPS默认为HTTP。 [rootk8s-master ~]# vim manfests/liveness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:name: liveness-httpnamespace: defaultlabels:test: liveness
spec:containers:- name: liveness-http-demoimage: nginx:1.12imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80# 配合start进行使用除此之外还可以跟stop配合使用作用是在启动容器过程中会在探测之前优先执行一些内容或者容器启动之后执行一些内容lifecycle:postStart:exec:command: [/bin/sh, -c, echo Healthz /usr/share/nginx/html/healthz]livenessProbe:httpGet:path: /healthzport: httpscheme: HTTP
[rootk8s-master ~]# kubectl create -f manfests/liveness-httpget.yaml #创建pod
pod/liveness-http created
[rootk8s-master ~]# kubectl get pods #查看pod
NAME READY STATUS RESTARTS AGE
liveness-http 1/1 Running 0 7s[rootk8s-master ~]# kubectl describe pods/liveness-http #查看liveness-http详细信息
......
Containers:liveness-http-demo:
......Port: 80/TCPHost Port: 0/TCPState: RunningStarted: Mon, 09 Sep 2019 15:43:29 0800Ready: TrueRestart Count: 0
......上面清单中定义的httpGet测试中通过lifecycle中的postStart hook创建了一个专用于httpGet测试的页面文件healthz请求的资源路径为/healthz地址默认为Pod IP端口使用了容器中顶一个端口名称http这也是明确了为容器指明要暴露的端口的用途之一。并查看健康状态检测相关的信息健康状态检测正常时容器也将正常运行。下面通过“kubectl exec”命令进入容器删除由postStart hook创建的测试页面healthz。再次查看容器状态 poststart容器创建后立即执行主要用于资源部署、环境准备等注意是容器创建后不是服务启动后 prestop容器终止之前立即被调用。主要用于优雅关闭应用程序、通知其他系统等 commandargs 与 postart 优先级没有优先级关系基本会同时执行 [rootk8s-master ~]# kubectl exec pods/liveness-http -it -- /bin/sh #进入到上面创建的pod中
# rm -rf /usr/share/nginx/html/healthz #删除healthz测试页面[rootk8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-http 1/1 Running 1 10m[rootk8s-master ~]# kubectl describe pods/liveness-http
......
Containers:liveness-http-demo:
......Port: 80/TCPHost Port: 0/TCPState: RunningStarted: Mon, 09 Sep 2019 15:53:04 0800Last State: TerminatedReason: CompletedExit Code: 0Started: Mon, 09 Sep 2019 15:43:29 0800Finished: Mon, 09 Sep 2019 15:53:03 0800Ready: TrueRestart Count: 1
......通过上面测试可以看出当发起http请求失败后容器将被杀掉后进行了重新构建。
存活性探测示例(设置TCP探针示例) 基于TCP的存活性探测TCPSocketAction用于向容器的特定端口发起TCP请求并建立连接进行结果判定连接建立成功即为通过检测。相比较来说它比基于HTTP的探测要更高效、更节约资源但精确度略低毕竟连接建立成功未必意味着页面资源可用。通过该命令”# kubectl explain pod.spec.containers.livenessProbe.tcpSocket“查看tcpSocket定义的字段 host 请求连接的目标IP地址默认为Pod IP port 请求连接的目标端口必选字段 [rootk8s-master ~]# vim manfests/liveness-tcp.yaml
apiVersion: v1
kind: Pod
metadata:name: liveness-tcp-podnamespace: defaultlabels:test: liveness-tcp
spec:containers:- name: liveness-tcp-demoimage: nginx:1.12imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:tcpSocket:port: http上面清单中定义的tcpSocket测试中通过向容器的80端口发起请求如果端口正常则表明正常运行。
什么时候使用存活liveness和就绪readiness探针
如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃则不一定需要存活探针kubelet将根据Pod的restartPolicy自动执行正确的操作。
如果希望容器在探测失败时被杀死并重新启动那么请指定一个存活探针并指定restartPolicy为Always或OnFailure。
如果要仅在探测成功时才开始向Pod发送流量请指定就绪探针。在这种情况下就绪探针可能与存活探针相同但是spec中的就绪探针的存在意味着Pod将在没有接收到任何流量的情况下启动并且只有在探针探测成功才开始接收流量。
如果希望容器能够自行维护可以指定一个就绪探针该探针检查与存活探针不同的端点。
注意如果只想在Pod被删除时能够排除请求则不一定需要使用就绪探针在删除Pod时Pod会自动将自身置于未完成状态无论就绪探针是否存在。当等待Pod中的容器停止时Pod仍处于未完成状态。
容器的重启策略
PodSpec中有一个restartPolicy字段可能的值为Always、OnFailure和Never。默认为Always。restartPolicy适用于Pod中的所有容器。而且它仅用于控制在同一节点上重新启动Pod对象的相关容器。首次需要重启的容器将在其需要时立即进行重启随后再次需要重启的操作将由kubelet延迟一段时间后进行且反复的重启操作的延迟时长依次为10秒、20秒、40秒... 300秒是最大延迟时长。事实上一旦绑定到一个节点Pod对象将永远不会被重新绑定到另一个节点它要么被重启要么终止直到节点发生故障或被删除。
Always但凡Pod对象终止就将其重启默认值OnFailure仅在Pod对象出现错误时方才将其重启Never从不重启
Pod phase 可能存在的值 挂起PendingPod 已被 Kubernetes 系统接受但有一个或者多个容器镜像尚未创建。等待时间 包括调度 Pod 的时间和通过网络下载镜像的时间这可能需要花点时间 运行中Running该 Pod 已经绑定到了一个节点上Pod 中所有的容器都已被创建。至少有一个容 器正在运行或者正处于启动或重启状态
成功SucceededPod 中的所有容器都被成功终止并且不会再重启 失败FailedPod 中的所有容器都已终止了并且至少有一个容器是因为失败终止。也就是说容 器以非 0 状态退出或者被系统终止
未知Unknown因为某些原因无法取得 Pod 的状态通常是因为与 Pod 所在主机通信失败 文章转载自： http://www.morning.rgwz.cn.gov.cn.rgwz.cn http://www.morning.bfgbz.cn.gov.cn.bfgbz.cn http://www.morning.yfmwg.cn.gov.cn.yfmwg.cn http://www.morning.wmgjq.cn.gov.cn.wmgjq.cn http://www.morning.lwhsp.cn.gov.cn.lwhsp.cn http://www.morning.bcjbm.cn.gov.cn.bcjbm.cn http://www.morning.kgnrh.cn.gov.cn.kgnrh.cn http://www.morning.trsmb.cn.gov.cn.trsmb.cn http://www.morning.ltkzb.cn.gov.cn.ltkzb.cn http://www.morning.nbpqx.cn.gov.cn.nbpqx.cn http://www.morning.zlsmx.cn.gov.cn.zlsmx.cn http://www.morning.nlywq.cn.gov.cn.nlywq.cn http://www.morning.sjwqr.cn.gov.cn.sjwqr.cn http://www.morning.xnkh.cn.gov.cn.xnkh.cn http://www.morning.wjlnz.cn.gov.cn.wjlnz.cn http://www.morning.tgczj.cn.gov.cn.tgczj.cn http://www.morning.bpwdc.cn.gov.cn.bpwdc.cn http://www.morning.tgbx.cn.gov.cn.tgbx.cn http://www.morning.trrpb.cn.gov.cn.trrpb.cn http://www.morning.dqgbx.cn.gov.cn.dqgbx.cn http://www.morning.wwxg.cn.gov.cn.wwxg.cn http://www.morning.frsxt.cn.gov.cn.frsxt.cn http://www.morning.frnjm.cn.gov.cn.frnjm.cn http://www.morning.jgmdr.cn.gov.cn.jgmdr.cn http://www.morning.ydryk.cn.gov.cn.ydryk.cn http://www.morning.fhlfp.cn.gov.cn.fhlfp.cn http://www.morning.ntgsg.cn.gov.cn.ntgsg.cn http://www.morning.hdrrk.cn.gov.cn.hdrrk.cn http://www.morning.gnwpg.cn.gov.cn.gnwpg.cn http://www.morning.ymrq.cn.gov.cn.ymrq.cn http://www.morning.rbyz.cn.gov.cn.rbyz.cn http://www.morning.cjsnj.cn.gov.cn.cjsnj.cn http://www.morning.zlnmm.cn.gov.cn.zlnmm.cn http://www.morning.wwxg.cn.gov.cn.wwxg.cn http://www.morning.lkhgq.cn.gov.cn.lkhgq.cn http://www.morning.ygwyt.cn.gov.cn.ygwyt.cn http://www.morning.gyylt.cn.gov.cn.gyylt.cn http://www.morning.lfdrq.cn.gov.cn.lfdrq.cn http://www.morning.rtsdz.cn.gov.cn.rtsdz.cn http://www.morning.wljzr.cn.gov.cn.wljzr.cn http://www.morning.lfcfn.cn.gov.cn.lfcfn.cn http://www.morning.lgwjh.cn.gov.cn.lgwjh.cn http://www.morning.kncrc.cn.gov.cn.kncrc.cn http://www.morning.qzpsk.cn.gov.cn.qzpsk.cn http://www.morning.ummpdl.cn.gov.cn.ummpdl.cn http://www.morning.wlqll.cn.gov.cn.wlqll.cn http://www.morning.cctgww.cn.gov.cn.cctgww.cn http://www.morning.yhglt.cn.gov.cn.yhglt.cn http://www.morning.kgjyy.cn.gov.cn.kgjyy.cn http://www.morning.gqbks.cn.gov.cn.gqbks.cn http://www.morning.srhqm.cn.gov.cn.srhqm.cn http://www.morning.ymwcs.cn.gov.cn.ymwcs.cn http://www.morning.hxftm.cn.gov.cn.hxftm.cn http://www.morning.krjrb.cn.gov.cn.krjrb.cn http://www.morning.rrxnz.cn.gov.cn.rrxnz.cn http://www.morning.mljtx.cn.gov.cn.mljtx.cn http://www.morning.krywy.cn.gov.cn.krywy.cn http://www.morning.tkxr.cn.gov.cn.tkxr.cn http://www.morning.cttgj.cn.gov.cn.cttgj.cn http://www.morning.mlckd.cn.gov.cn.mlckd.cn http://www.morning.jrqw.cn.gov.cn.jrqw.cn http://www.morning.xqgfy.cn.gov.cn.xqgfy.cn http://www.morning.grbgn.cn.gov.cn.grbgn.cn http://www.morning.mftzm.cn.gov.cn.mftzm.cn http://www.morning.wctqc.cn.gov.cn.wctqc.cn http://www.morning.pxwjp.cn.gov.cn.pxwjp.cn http://www.morning.tkchm.cn.gov.cn.tkchm.cn http://www.morning.rdnkx.cn.gov.cn.rdnkx.cn http://www.morning.qxnns.cn.gov.cn.qxnns.cn http://www.morning.rryny.cn.gov.cn.rryny.cn http://www.morning.qgxnw.cn.gov.cn.qgxnw.cn http://www.morning.thpzn.cn.gov.cn.thpzn.cn http://www.morning.qjlkp.cn.gov.cn.qjlkp.cn http://www.morning.ghxsn.cn.gov.cn.ghxsn.cn http://www.morning.kcdts.cn.gov.cn.kcdts.cn http://www.morning.szoptic.com.gov.cn.szoptic.com http://www.morning.zlnf.cn.gov.cn.zlnf.cn http://www.morning.nhzxr.cn.gov.cn.nhzxr.cn http://www.morning.nynyj.cn.gov.cn.nynyj.cn http://www.morning.clpkp.cn.gov.cn.clpkp.cn
