上篇文章给搭建搭建了企业私有服务,本篇文章给大家介绍下k8s中的 资源清单 本篇文章大部分全都是理论。耐心看完将会刷新你对k8s的认知。
一、 k8s中的资源
1.1 什么是资源?
K8s中所有的内容都抽象为资源,资源实例化之后,叫做对象
1.2 K8S中存在哪些资源
- 工作负载型资源(workload): Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob(ReplicationController在v1.11版本被废弃)
- 服务发现及负载均衡型资源(ServiceDiscoveryLoadBalance): Service、Ingress、…
- 配置与存储型资源: Volume(存储卷)、CSI(容器存储接口,可以扩展各种各样的第三方存储卷)
- 特殊类型的存储卷: ConfigMap(当配置中心来使用的资源类型)、Secret(保存敏感数据)、DownwardAPI(把外部环境中的信息输出给容器)
- 集群级资源: Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding
- 元数据型资源: HPA、PodTemplate、LimitRange
二、资源清单
在k8s中,一般使用yaml格式的文件来创建符合我们预期期望的pod
,这样的yaml文件我们一般称为资源清单
三、常用的字段解释
3.1 必须存在的字段
注意: 如果写不全是不让运行pod的
参数名 | 字段类型 | 说明 |
---|---|---|
version | String | 这里是指的k8s API 的版本,目前基本是v1,可以 用kubectl api-version命令查询 |
kind | String | 这里指的是yam文件定义的资源类型和角色,比如:Pod |
metadata | Object | 元数据对象,固定值就写 metadata |
metadata.name | String | 元数据对象的名字,这里由我们编写,比如如名POd的名字 |
metadata namespace | String | 元数据对象的命名空间,由我们自身定义 |
spec | Object | 详细定义对象,固定值就写Spec |
spec containers[] | list | 这里是Spec对象的容器列表定义,是个列表 |
spec containers[].name | String | 这里定义容器的名字 |
spec containers[]. image | String | 这里定义要用到的镜像名称 |
定义一个pod进行运行测试
- 编写一个yaml文件
- 使用kubectl进行创建
- 使用 get pod 查看
1、创建 pod.yaml文件
[root@k8s-master01 ~]# vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
version: v1
spec:
containers:
- name: app
image: hub.dashujulaoge.com/library/myapp:v1
2、创建pod
[root@k8s-master01 ~]# kubectl create -f pod.yam
3、 使用get pod 查看状态(成功运行)
3.2 主要对象
主要: 一下内容可以有可以没有,如果没有写系统会添加默认值
参数名 | 字段类型 | 说明 |
---|---|---|
spec containers[]. name | String | 定义容器的名字 |
spec containers[]. image | String | 定义要用到的镜像名称 |
spec containers[]. imagePullPolicy | String | 走义镜像拉取策路,有 Always、 Never IfNotPresent三个值可选(1) Always:意思是 每次都芸试重新拉取镜像(2) Never:表示仅 使用本地镜像(3) IfNotPresent:如果本地有 镜像就使用本地镜像,没有就拉取在线镜像。 上面三个值都没设置的话,默认是 Always。 |
spec containers[]. command[] | list | 指走容器启动命令,因为是数组可以指定多 个,不指定则使用镜像打包时使用的启动命 令。 |
spec containers[]. args[] | list | 指定容器启动命令参数,因为是数组可以指定多个。 |
spec containers[]. workingDir | String | 指定容器的工作目录 |
spec containers[]. volumeMounts[] | list | 指定容器内部的存储卷配置 |
spec containers[]. volumeMounts[].name | String | 指定可以被容器挂载的存储卷的名称 |
spec containers[]. volumeMounts[].mountrPath | String | 指定可以被容挂载的存储芢的路径 |
spec containers[]. volumeMounts[].readOnly | String | 设置存储卷路径的读写模式,ture或者 false, 认为读写模式 |
spec containers[]. ports[] | list | 指走容器需要用到的满口列表 |
spec containers[].ports[]. name | String | 指定端口名称 |
spec containers[].ports[]. containerPort | String | 指定容器需要监听的端口号 |
spec containers[]. ports[]. hostPort | String | 首定容器所在主机需要监听的端口号,默认跟 上面 containerPort相同,注意设置了 hostPort 同一台主机无法启动该容器的相同副本(因为 主机的端口号不能相同,这样会冲突) |
spec containers[]. ports[]. protocol | String | 指定端口协议,支持TCP和UDP,认值为TCP |
spec containers[]. env[] | list | 指定容器运行前需设置的环境变量列表 |
spec containers[].env[]. name | String | 指定环境变量名称 |
spec containers[].env[] value | String | 指走环境变量值 |
spec containers[]. resources | Object | 指定资源限制和源请求的值(这里开始就是 设置容器的资源上限) |
spec containers[]. resources.limits | Object | 指定设置容器运行时资源的运行上限 |
spec containers[]. resources.limits. cpu | String | 指定CPU的限制,单位为core数,将用于 docker run-cpu- shares参数(这里前面文章 Pod资源限制有讲过) |
spec containers[].resources.limits. memory | String | 指定MEM内存的限制,单位为MIB、GiB |
spec containers[]. resources. requests | Object | 指定容器启动和调度时的限制设置 |
spec containers[]. resources. requests. cpu | String | CPU请求,单位为core数,容器启动时初始化 可用数量 |
spec containers[]. resources. requests memory | String | 内存请求,单位为MIB、GiB,容器启动的初始 化可用数量 |
3.3 额外的参数项
参数名 | 字段类型 | 说明 |
---|---|---|
spec. restartPolicy | String | 定义Pod的重启策路,可选值为 Alays、 Onfailure,默认值为 Always。 1 Always:Pod-且终止运行,则无论容器是如何终止的, kubelet服务都将重启它。 2. failure:只有Pod以非零退出码终止时, kubeletオ会重启该容 器。如果容器正常结束(退出码为0),则 kubelet将不会重启它 3. Never:Pod终止后, kubelet将退出码报告给 Master,不会重启该 Pod |
spec. nodeSelector | Object | 定义Node的Labe过滤标签,以 key: value格式指定 |
spec. imagePullSecrets | Object | 定义pu像时便用 secrets名称,以 name secretkey格式指定 |
spec.hostNetwork | Boolean | 定义是否使用主机网络模式,默认值为 false。设置true表示使用宿主 机网络,不使用 docker网桥,同时设置了tue将无法在同一台宿主机 上启动第二个副本。 |
四、容器生命周期
4.1 Pod生命周期架构图
4.2 Init 容器
Pod能够具有多个容器,应用运行在容器里面,但是它也可能有一个或多个先于应用容器启动的Init容器
Init容器与普通的容器非常像,除了如下两点:
✮ Init容器总是运行到成功完成为止
✮ 每个Init容器都必须在下一个Init容器启动之前成功完成
如果Pod的Init容器失败,Kubernetes会不断地重启该Pod,直到Init容器成功为止。然而,如果Pod对应的restartPolicy为Never,它不会重新启动
4.3 Init容器的作用
因为Init容器具有与应用程序容器分离的单独镜像,所以它们的启动相关代码具有如下优势:
✮ 它们可以包含并运行实用工具,但是出于安全考虑,是不建议在应用程序容器镜像中包含这些实用工具的
✮ 它们可以包含使用工具和定制化代码来安装,但是不能出现在应用程序镜像中。例如,创建镜像没必要FROM另一个镜像,只需要在安装过程中使用类似sed、awk、python或dig这样的工具。
✮ 应用程序镜像可以分离出创建和部署的角色,而没有必要联合它们构建一个单独的镜像。
✮ Init容器使用LinuxNamespace,所以相对应用程序容器来说具有不同的文件系统视图。因此,它们能够具有访问Secret的权限,而应用程序容器则不能。
✮ 它们必须在应用程序容器启动之前运行完成,而应用程序容器是并行运行的,所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法,直到满足了一组先决条件。
4.4 Init特殊说明
❉ 在Pod启动过程中,Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。
❉ 如果由于运行时或失败退出,将导致容器启动失败,它会根据Pod的restartPolicy指定的策略进行重试。然而,如果Pod的restartPolicy设置为Always,Init容器失败时会使用RestartPolicy策略。
❉ 在所有的Init容器没有成功之前,Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态,但应该会将Initializing状态设置为true。
❉ 如果Pod重启,所有Init容器必须重新执行。。
❉ #对Init容器spec的修改被限制在容器image字段,修改其他字段都不会生效。更改Init容器的image字段,等价于重启该Pod。
❉ Init容器具有应用容器的所有字段。除了readinessProbe,因为Init容器无法定义不同于完成(completion)的就绪(readiness)之外的其他状态。这会在验证过程中强制执行。
❉ 在Pod中的每个app和Init容器的名称必须唯一;与任何其它容器共享同一个名称,会在验证时抛出错误。
4.5 容器探针
探针是由kubelet对容器执行的定期诊断。要执行诊断,kubelet调用由容器实现的Handler。有三种类型的处理程序:
- ExecAction:在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
- TCPSocketAction:对指定端口上的容器的IP地址进行TCP检查。如果端口打开,则诊断被认为是成功的。
- HTTPGetAction:对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400,则诊断被认为是成功的。
每次探测都将获得以下三种结果之一:
- 成功:容器通过了诊断。
- 失败:容器未通过诊断。
- 未知:诊断失败,因此不会采取任何行动
4.6 探测方式
livenessProbe:指示容器是否正在运行。如果存活探测失败,则kubelet会杀死容器,并且容器将受到其重启策略的影响。如果容器不提供存活探针,则默认状态为Success
readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败,端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针,则默认状态为Success
4.7 PodHook
Podhook(钩子)是由Kubernetes管理的kubelet发起的,当容器中的进程启动前或者容器中的进程终止之前运行,这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hook
Hook的类型包括两种:
- exec:执行一段命令
- HTTP:发送HTTP请求
4.8 重启策略
PodSpec中有一个restartPolicy字段,可能的值为Always、OnFailure和Never。默认为Always。restartPolicy适用于Pod中的所有容器。restartPolicy仅指通过同一节点上的kubelet重新启动容器。失败的容器由kubelet以五分钟为上限的指数退避延迟(10秒,20秒,40秒…)重新启动,并在成功执行十分钟后重置。如Pod文档中所述,一旦绑定到一个节点,Pod将永远不会重新绑定到另一个节点。
4.9 PodHase可能存在的值
-
挂起(Pending):Pod已被Kubernetes系统接受,但有一个或者多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间,这可能需要花点时间
-
运行中(Running):该Pod已经绑定到了一个节点上,Pod中所有的容器都已被创建。至少有一个容器正在运行,或者正处于启动或重启状态
-
成功(Succeeded):Pod中的所有容器都被成功终止,并且不会再重启
-
失败(Failed):Pod中的所有容器都已终止了,并且至少有一个容器是因为失败终止。也就是说,容器以非0状态退出或者被系统终止
-
未知(Unknown):因为某些原因无法取得Pod的状态,通常是因为与Pod所在主机通信失败
五、粉丝福利及软件获取
有的小伙伴刚开始学习k8s的没有目标,不知道该怎么学,以及k8s有哪些内容该怎么学。我在这里为大家准备了一个学习流程图感兴趣的小伙伴可以进行获取 微信搜索【大数据老哥】回复【k8s学习流程图】 即可获取。
软件获取
小伙伴们在安装的是后可能会需要很多镜像文件下载是非常的漫长,大数据老哥在这里为你们准备了, 微信搜索公众号【大数据老哥】 回复【k8s软件包】即可获取
其他福利
微信公众号搜索【大数据老哥】可以获取 200个为你定制的简历模板、大数据面试题、企业面试题…等等。