4、pod运维replicationCtroller、replicaSet、DeamonSet、Job、Cronjob

时间:2024-03-07 11:57:25

1、kubenetes 会自动重新运行失败的pod应用

pod运行失败,会自动重启,但是节点失败,pod会被移除,
除非配置了relicationController来管理资源

2、保持pod的健康存活

配置探针,发送http请求

3、查看前一个pod的运行日志

kubectl logs <pod_name> --previous

4、查看容器重启的运行状态

kubectl describe po <pod_name>

delay(延迟)、timeout(超时)、period(周期)等。delay=0s部分显
⽰在容器启动后⽴即开始探测。timeout仅设置为1秒,因此容器必须在
1秒内进⾏响应,不然这次探测记作失败。每10秒探测⼀次容器
(period=10s),并在探测连续三次失败(#failure=3)后重启容器。

退出代码
为137,这有特殊的含义 —— 表⽰该进程由外部信号终⽌。数字137是
两个数字的总和:128+x,其中x是终⽌进程的信号编号。在这个例⼦
中,x等于9,这是SIGKILL的信号编号,意味着这个进程被强⾏终
⽌

5、pod 探针配置探测延迟

如果没有设置初始延迟,探针将在启动时⽴即开始探测容器,这
通常会导致探测失败,因为应⽤程序还没准备好开始接收请求。如果
失败次数超过阈值,在应⽤程序能正确响应请求之前,容器就会重
启。

6、replicationController的作用

ReplicationController是⼀种Kubernetes资源,可确保它的pod始终保
持运⾏状态。如果pod因任何原因消失(例如节点从集群中消失或由于
该pod已从节点中逐出),则ReplicationController会注意到缺少了pod并
创建替代pod

7、replicationController 创建

# 查看rc列表
kubectl  get rc

# 查看现有rc的yaml文件
kubectl get rc <rc_name> -o yaml

# 创建一个rc的yaml
kubectl create -f kubectl-rc.yaml

创建成功就会执行
⼀个ReplicationController有三个主要部分:
label selector(标签选择器),⽤于确定ReplicationController作⽤
域中有哪些pod
replica count(副本个数),指定应运⾏的pod数量
pod template(pod模板),⽤于创建新的pod副本

spec containers ,容器相关

8、查看rc的状态

kubectl describe rc <rc_name>

9、pod 删除rc流程

10、kubernetes进入node节点

#创建节点
gcloud container clusters create <node_name> --num-nodes <node_num>

#获取节点列表
kubectl get nodes

#查看node详细信息
kubectl describe node <node_name>

#进入node节点
gcloud compute ssh <node_name> 

#节点重置
gcloud compute instances reset <node_name>

11、replicationController 中的pod移动和删除(原pod需要手动删除,才行)

#更新pod中一个标签
kubectl label pod kubia app=foo --overwrite

# 展示所有标签
kubectl get pods --show-lables

# 展示特定标签
kubectl get pods -L app

当 你 更 改 pod 的 标 签 , 使 得 它 们 不 再 与
ReplicationController的pod选择器匹配时,发⽣的事情。可以看到三个
pod和ReplicationController。在将pod的标签从app=kubia更改为app=foo
之后,ReplicationController就不管这个pod了。由于控制器的副本个数
设 置 为 3 , 并 且 只 有 两 个 pod 与 标 签 选 择 器 匹 配 , 所 以
ReplicationController 启 动 kubia-2qneh pod , 使 总 数 回 到 了 三 。
kubiadmdck pod现在是完全独⽴的,并且会⼀直运⾏直到你⼿动删除它

12、修改pod 模板

更改pod的标签和更改replicationController的选择器标签,都会重新创建新的pod,
rc就不会管理对应的pod,但是新创建的pod,还是原来的模板pod,如果想要pod的模板
更新,就需要配置replicationController的模板,要修改旧的pod,你需要删除它们,
并让ReplicationController根据新模板将其替换为新的pod。

配置kubectl edit使⽤不同的⽂本编辑器
可以通过设置KUBE_EDITOR环境变量来告诉kubectl使⽤你期望的
⽂本编辑器。例如,如果你想使⽤nano编辑Kubernetes资源,请执⾏以
下命令(或将其放⼊~/.bashrc或等效⽂件中):
export KUBE_EDITOR="usr/bin/nano"

# 查看rc列表
kubectl get rc

# 修改pod模板
kubectl edit rc <rc_name>

13、pod的扩容缩放(修改保存后,会立即生效)

# 副本数改为10
kubectl scale rc <rc_name> --replicas=10

# 编辑yaml文件
kubectl edit rc <rc_name>

14、删除一个rc

删除rc rc下管理的pod将不被管理

kubectl delete rc <rc_name> --cascade=false

15、relicaSet与replicationController的区别

ReplicationController是⽤于复制和在异常时重新调度节点的
唯⼀Kubernetes组件,后来又引⼊了⼀个名为ReplicaSet的类似资源。它
是 新 ⼀ 代 的 ReplicationController , 并 且 将 其 完 全 替 换 掉
(ReplicationController最终将被弃⽤)。
ReplicaSet的⾏为与ReplicationController完全相同,但pod选择器的
表达能⼒更强。虽然ReplicationController的标签选择器只允许包含某个
标签的匹配pod,但ReplicaSet的选择器还允许匹配缺少某个标签的
pod,或包含特定标签名的pod,不管其值如何。
另外,举个例⼦,单个ReplicationController⽆法将pod与标签
env=production和env=devel同时匹配。它只能匹配带有env=devel标签的
pod或带有env=devel标签的pod。但是⼀个ReplicaSet可以匹配两组pod
并将它们视为⼀个⼤组。
同样,⽆论ReplicationController的值如何,ReplicationController都
⽆法仅基于标签名的存在来匹配pod,⽽ReplicaSet则可以。例如,
ReplicaSet可匹配所有包含名为env的标签的pod,⽆论ReplicaSet的实际
值是什么(可以理解为env=*)。

16、replicaSet相关操作

# 查看replicaSet列表
kubectl get rs


replicaSet的所有操作和replicationController操作一致

17、使用replicaSet的标签

In:Label的值必须与其中⼀个指定的values匹配。
NotIn:Label的值与任何指定的values不匹配。
Exists:pod必须包含⼀个指定名称的标签(值不重要)。使⽤此运
算符时,不应指定values字段。
DoesNotExist:pod不得包含有指定名称的标签。values属性不得指
定。
如果你指定了多个表达式,则所有这些表达式都必须为true才能使
选择器与pod匹配。如果同时指定matchLabels和matchExpressions,则所
有标签都必须匹配,并且所有表达式必须计算为true以使该pod与选择
器匹配。

18、deamonSet (确保⼀个pod匹配它的选择器并在每个节点上运⾏

Replicationcontroller和ReplicaSet都⽤于在Kubernetes集群上运⾏部
署特定数量的pod。但是,当你希望pod在集群中的每个节点上运⾏时
希望在每个节点上运⾏⽇志收集器和资源监控器。另⼀个典型的例⼦
是Kubernetes⾃⼰的kube-proxy进程,它需要运⾏在所有节点上才能使
服务⼯作

19、replicaSet和DeamonSet的区别

20、创建一个deamonSet

创建⼀个DaemonSet,它在标
记为具有SSD的所有节点上运⾏这个守护进程。集群管理员已经向所有
此类节点添加了disk=ssd的标签,因此你将使⽤节点选择器创建
DaemonSet

# 查看ds列表
kubectl get ds

# 创建ds
kubectl create -f ds.yaml

# 查询node列表
kubectl get node

# 给node添加disk=ssd标签

kubectl label mode <node_name> disk=ssd

21、移除deamonSet中的pod(立即生效,会删除node下对应节点,不需要手动在删除)

# 修改node标签
kubectl label node <node_name> disk=hdd --overwrite

21、Job维护pod(只执行一次,临时任务)

运⾏⼀种pod,该pod在内部进程成功
结束时,不重启容器。⼀旦任务完成,pod就被认为处于完成状态。
在发⽣节点故障时,该节点上由Job管理的pod将按照ReplicaSet的
pod的⽅式,重新安排到其他节点。如果进程本⾝异常退出(进程返回
错误退出代码时),可以将Job配置为重新启动容器。

22、创建一个Job

# 查看job列表
kubectl get jobs

# 查询job的yaml
kubectl get po <po_name> -o yaml


在⼀个pod的定义中,可以指定在容器中运⾏的进程结束时,
Kubernetes会做什么。这是通过pod配置的属性restartPolicy完成的,默
认为Always。Job pod不能使⽤默认策略,因为它们不是要⽆限期地运
⾏。因此,需要明确地将重启策略设置为OnFailure或Never。

23、设置job的运行次数及并行数量

Job将⼀个接⼀个地运⾏五个pod。它最初创建⼀个pod,当pod的
容器运⾏完成时,它创建第⼆个pod,以此类推,直到五个pod成功完
成。如果其中⼀个pod发⽣故障,⼯作会创建⼀个新的pod,所以Job总
共可以创建五个以上的pod

24、Job 的扩容缩放

kubectl scale job <job_name> --replicas 3

25、设置Job的运行过期时间

通过在pod配置中设置activeDeadlineSeconds属性,可以限制pod的
时间。如果pod运⾏时间超过此时间,系统将尝试终⽌pod,并将Job标
记为失败。
注意 通过指定Job manifest中的spec.backoffLimit字段,可以配置
Job在被标记为失败之前可以重试的次数。如果你没有明确指定它,则
默认为6

26、cronJob(定时执行、或将来运行一次pod)

可能发⽣Job或pod创建并运⾏得相对较晚的情况。你可能对这项
⼯作有很⾼的要求,任务开始不能落后于预定的时间过多。在这种情
况下,可以通过指定CronJob规范中的startingDeadlineSeconds字段来指
定截⽌⽇期
⼯作运⾏的时间应该是10:30:00。如果
因为任何原因10:30:15不启动,任务将不会运⾏,并将显⽰为Failed。