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。