提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
1、HC:公有云,物料是华为的,客户买华为服务,数据在华为,华为在线安装,升级、运维,数据控制者;
2、HCSO(HCS Online):混合云,物料是客户的(也会买华为的硬件),客户买华为服务,数据在客户,华为在线安装,升级、运维(从客户机房拉线)
3、HCS:混合云,物料是客户的(也会买华为的硬件),客户买华为的服务,数据在客户,华为现场安装,升级、运维,设备供应者。
HCIP学习笔记-华为云运维方案-9:https://blog.csdn.net/GoNewWay/article/details/131528217?
HCIP:https://blog.csdn.net/gonewway/category_12320829.html
告警术语
故障:云服务的意外中断或华为云公有云服务质量的下降,面向用户提供的服务发生不可用及用户体验有损的场景定义为故障
隐患:现网云服务发生故障的潜在风险点,如不提前处理可能会引发现网故障
事件型告警:在某一时刻突然触发的错误性告警,例如:某一刻虚拟机蓝屏故障、某接口调用失败
指标型告警:在特定网站,多某个监控指标设置阈值,持续达到阈值时触发的动作,比如:CPU利用率过高,磁盘使用率过高
告警工单:通过告警规则生成的工单,由告警处理人按照规范进行处理,告警平台统一处理承载
告警氛围三个等级:Critical(紧急)、Major(重要)、Info(提示)
Deployment不是直接控制pod的,Deployment是通过一种名为ReplicaSet的控制器控制pod,通过kubectl get rs可以查看ReplicaSet
回滚也称回退,即发现升级出现问题时,让应用回到老的版本,Deployment可以非常方便的回滚到老版本,Deployment之所以能够如此容易的做到回滚,是因为Deployment通过ReplicaSet控制pod的,升级后之前ReplicaSet都一直存在,Deployment回滚做的就是使用之前的ReplicaSet再次把pod创建出来,Deployment中保存ReplicaSet的数量可以使用revisionHistoryLimit参数限制,默认值是10.
Job和CronJob
Job和CronJob是负责批量处理短暂的一次性任务(short lived one-off tasks),即仅执行一次任务,它保证批处理任务的一个或多个pod成功结束
Job:是Kubernetes用来控制批处理型任务的资源对象,批处理业务与长期伺服业务(Deployment、Statefulset)的主要区别是批处理业务的运行有头有尾,而长期伺服业务在用户不停止的情况下永远运行。Job管理的pod根据用户的设置把任务成功完成就自动退出(pod自动删除)
CronJob:是基于时间的Job,类似于Linux的crontab文件中的一行,在指定的时间周期运行指定的Job
任务负载的这种用完即停止的特性特别适合一次性任务,比如持续集成
docker和containerd调用链区别
docker(Kubernetes 1.23及以下版本)
kubelet–>docker shim (在kubelet进程中)–>docker–>containerd
docker(Kubernetes 1.24及以上版本社区方案)
kubelet–>cri-dockerd(在kubelet使用cri接口对接cri-dockerd)–>docker–>containerd
containerd
kubelet–>cri plugin(在containerd进程中)–>containerd
其中docker虽增加了swarm cluster、docker build、docker API等功能,但也会引入一些bug,并且与containerd相比,多了一层调用,因此containerd被认为更加节省资源且安全
devops持续交付场景
开发者–>提交代码–代码库–>源码到镜像–>SWR–>CCE(测试环境、预发环境、生产环境)
云容器引擎与其他服务的关系图:
Kubernetes本身并不负责网络通信,但提供了容器网络接口CNI(Container Network Interface),具体的网络通信交由CNI插件来实现。开源的CNI插件非常多,像Flannel、Calico等。针对Kubernetes网络,CCE也定制了相应的CNI插件(Canal和Yangtse),用于负责集群内网络通信。
Kubernetes虽然不负责搭建网络模型,但要求集群网络满足以下要求:
同一个节点中的Pod通信
Pod通过虚拟Ethernet接口对(Veth Pair)与外部通信,Veth Pair像一根网线,一端在Pod内部,一端在Pod外部。同一个节点上的Pod通过网桥(Linux Bridge)通信,如下图所示。
在同一节点上的Pod会通过Veth设备将一端连接到网桥,且它们的IP地址是通过网桥动态获取的,和网桥IP属于同一网段。此外,同一节点上的所有Pod默认路由都指向网桥,网桥会负责将所有非本地地址的流量进行转发。因此,同一节点上的Pod可以直接通信。
不同节点上的Pod通信
Kubernetes要求集群Pod的地址唯一,因此集群中的每个节点都会分配一个子网,以保证Pod的IP地址在整个集群内部不会重复。在不同节点上运行的Pod通过IP地址互相访问,该过程需要通过集群网络插件实现,按照底层依赖大致可分为Overlay模式、路由模式、Underlay模式三类。
Overlay模式是在节点网络基础上通过隧道封装构建的独立网络,拥有自己独立的IP地址空间、交换或者路由的实现。VXLAN协议是目前最流行的Overlay网络隧道协议之一。
路由模式采用VPC路由表的方式与底层网络相结合,能够更加便捷地连接容器和主机,在性能上会优于Overlay的隧道封装。
Underlay模式是借助驱动程序将节点的底层网络接口直接暴露给容器使用的一种网络构建技术,享有较高的性能,较为常见的解决方案有IP VLAN等。