摘要:
由于现在docker官方仓库在国内基本无法访问,上面的镜像是使用本地自己搭建harbor仓库存放的镜像;有关harbor仓库的搭建可以参考本人博客[https://www.cnblogs.com/qiuhom-1874/p/13061984.html] 阅读全文
由于现在docker官方仓库在国内基本无法访问,上面的镜像是使用本地自己搭建harbor仓库存放的镜像;有关harbor仓库的搭建可以参考本人博客[https://www.cnblogs.com/qiuhom-1874/p/13061984.html] 阅读全文
posted @ 2026-07-22 22:35
Linux-1874
阅读(106)
评论(1)
推荐(2)

在较大型的web集群和微服务环境中,客户端的一次请求可能需要经过多个不同的服务模块、多个不同中间件、多台不同机器的一起相互协作才能处理完成客户端的请求,而在这一系列的请求过程之中,处理流程可能是串行执行也可能是并行执行的,那么如何确定客户端的一次请求到结束的背后究竟调用了哪些应用以及哪些模块并经过了哪些节点,且每个模块的调用先后顺序是怎样的、每个模块的处理相应性能如何?后期随着业务系统的不断增多,业务处理逻辑会越来越复杂,而分布式系统中急需一套链路追踪(Trace)系统来解决这些痛点,从而让运维人员能站在上帝视角了解整个业务系统的性能。
WVP(WEB VIDEO PLATFORM)是一个基于GB28181-2016标准实现的网络视频平台,负责实现核心信令与设备管理后台部分,支持NAT穿透,支持海康、大华、宇视等品牌的IPC、NVR、DVR接入。支持国标级联,支持rtsp/rtmp等视频流转发到国标平台,支持rtsp/rtmp等推流转发到国标平台;
Velero 是vmware开源的一个云原生的灾难恢复和迁移工具,它本身也是开源的,采用Go语言编写,可以安全的备份、恢复和迁移Kubernetes集群资源数据;官网https://velero.io/。Velero 是西班牙语意思是帆船,非常符合Kubernetes社区的命名风格,Velero的开发公司Heptio,已被VMware收购。Velero 支持标准的K8S集群,既可以是私有云平台也可以是公有云,除了灾备之外它还能做资源移转,支持把容器应用从一个集群迁移到另一个集群。Velero 的工作方式就是把kubernetes中的数据备份到对象存储以实现高可用和持久化,默认的备份保存时间为720小时,并在需要的时候进行下载和恢复。
LNMP案例之基于Nginx+PHP实现WordPress博客站点,要求Nginx+PHP运⾏在同⼀个Pod的不同容器;nginx主要作用是接入站点请求,如果请求静态资源nginx就直接响应;如果请求的是一个动态php资源,就将对应请求转发给另一个php容器进行处理;在一个pod中运行多容器,网络名称空间是共享的,所以nginx可以将对应请求转发至127.0.0.1:9000这个端口来调用php来处理对应php请求;pod中如果有数据产生,pod通过pvc/pv将对应数据存储到远端存储上;客户端访问通过防火墙,负载均衡器将请求调度到后端node上处理,如果请求所在节点没有运行对应pod,那么对应node会根据路由来转发请求,最终会将请求转发给pod所在节点进行处理;
生产者通过注册中心,将服务注册至注册中心,消费者通过注册中心找到生产者,从而实现消费者拿到生产者的实际地址,然后直接和生产者通信;管理端通过注册中心发现生产者和消费者,通过svc来管理生产者和消费者;集群外部客户端通过负载均衡器来访问集群内部服务;dubbo产生的数据可以通过pv/pvc将数据放置外部存储,如ceph,nas,nfs等;
Jenkins通过k8s上的pv/pvc来连接外部存储,通过svc的方式向外暴露服务,在集群内部通过直接访问svc就可以正常访问到jenkins,对于集群外部成员,通过外部负载均衡器来访问Jenkins;
StatefulSet本质上是Deployment的⼀种变体,在v1.9版本中已成为GA版本,它为了解决有状态服务的问题,它所管理的Pod拥有固定的Pod名称,启停顺序,在StatefulSet中,Pod名字称为⽹络标识(hostname),还必须要⽤到共享存储。在Deployment中,与之对应的服务是service,⽽在StatefulSet中与之对应的headless service,headless service,即⽆头服务,与service的区别就是它没有Cluster IP,解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。
redis是一款基于BSD协议,开源的非关系型数据库(nosql数据库),作者是意大利开发者Salvatore Sanfilippo在2009年发布,使用C语言编写;redis是基于内存存储,而且是目前比较流行的键值数据库(key-value database),它提供将内存通过网络远程共享的一种服务,提供类似功能的还有memcache,但相比 memcache,redis 还提供了易扩展、高性能、具备数据持久性等功能。主要的应用场景有session共享,常用于web集群中的tomcat或PHP中多web服务器的session共享;消息队列,ELK的日志缓存,部分业务的订阅发布系统;计数器,常用于访问排行榜,商品浏览数等和次数相关的数值统计场景;缓存,常用于数据查询、电商网站商品信息、新闻内容等;相对memcache,redis支持数据的持久化,可以将内存的数据保存在磁盘中,重启redis服务或者服务器之后可以从备份文件中恢复数据到内存继续使用;
zookeeper是一个开源的分布式协调服务,由知名互联网公司Yahoo创建,它是Chubby的开源实现;换句话讲,zookeeper是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于它实现数据的发布/订阅、负载均衡、名称服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列;
根据业务的不同,我们可以导入官方基础镜像,在官方基础镜像的基础上自定义需要用的工具和环境,然后构建成自定义出自定义基础镜像,后续再基于自定义基础镜像,来构建不同服务的基础镜像,最后基于服务的自定义基础镜像构建出对应业务镜像;最后将这些镜像上传至本地harbor仓库,然后通过k8s配置清单,将对应业务运行至k8s集群之上
容器技术除了的docker之外,还有coreOS的rkt、google的gvisor、以及docker开源的containerd、redhat的podman、阿⾥的pouch等,为了保证容器⽣态的标准性和健康可持续发展,包括Linux 基⾦会、Docker、微软、红帽、⾕歌和IBM等公司在2015年6⽉共同成⽴了⼀个叫open container(OCI)的组织,其⽬的就是制定开放的标准的容器规范,⽬前OCI⼀共发布了两个规范,分别是runtime spec和image format spec,有了这两个规范,不同的容器公司开发的容器只要兼容这两个规范,就可以保证容器的可移植性和相互可操作性。
Pause 容器,又叫 Infra 容器,是pod的基础容器,镜像体积只有几百KB左右,配置在kubelet中,主要的功能是一个pod中多个容器的网络通信。
Infra 容器被创建后会初始化 Network Namespace,之后其它容器就可以加入到 Infra 容器中共享Infra 容器的网络了,因此如果一个 Pod 中的两个容器 A 和 B,那么关系如下:
A容器和B容器能够直接使用 localhost 通信;
A容器和B容器可以可以看到网卡、IP与端口监听信息。
Pod 只有一个 IP 地址,也就是该 Pod 的 Network Namespace 对应的IP 地址(由Infra 容器初始化并创建)。
k8s环境中的每个Pod有一个独立的IP地址(前提是地址足够用),并且此IP被当前 Pod 中所有容器在内部共享使用。
pod删除后Infra 容器随机被删除,其IP被回收。
Secret 的功能类似于 ConfigMap给pod提供额外的配置信息,但是Secret是一种包含少量敏感信息例如密码、令牌或密钥的对象。Secret 的名称必须是合法的 DNS 子域名。每个Secret的大小最多为1MiB,主要是为了避免用户创建非常大的Secret进而导致API服务器和kubelet内存耗尽,不过创建很多小的Secret也可能耗尽内存,可以使用资源配额来约束每个名字空间中Secret的个数。在通过yaml文件创建secret时,可以设置data或stringData字段,data和stringData字段都是可选的,data字段中所有键值都必须是base64编码的字符串,如果不希望执行这种 base64字符串的转换操作,也可以选择设置stringData字段,其中可以使用任何非加密的字符串作为其取值。
所谓资源对象是指在k8s上创建的资源实例;即通过apiserver提供的各资源api接口(可以理解为各种资源模板),使用yaml文件或者命令行的方式向对应资源api接口传递参数赋值实例化的结果;比如我们在k8s上创建一个pod,那么我们就需要通过给apiserver交互,传递创建pod的相关参数,让apiserver拿着这些参数去实例化一个pod的相关信息存放在etcd中,然后再由调度器进行调度,由node节点的kubelet执行创建pod;简单讲资源对象就是把k8s之上的api接口进行实例化的结果;
CoreDNS是一个可扩展的DNS服务器,支持标准DNS,标准(但不广泛) 采用基于TLS的DNS和基于gRPC协议的非标准DNS。它的主要特点是插件系统,它允许您执行任何操作来响应可以在Go中编码的DNS查询。Miek Gieben在2016年编写了CoreDNS 的初始版本,在此之前他还写过SkyDNS,以及一个用Go语言编写的DNS函数库Go DNS。与它的继任者CoreDNS一样,SkyDNS的主要目的也是支持服务发现。Miek非常欣赏一个基于Go的网络服务器架构 Caddy,所以他就选用Caddy构建了CoreDNS。CoreDNS继承了Caddy的主要优点是简单的配置语法、强大的基于插件的架构以及 Go 语言。在k8s中,CoreDNS作为一个服务发现的配置中心,我们在K8s中创建的Service和Pod都会在其中自动生成相应的DNS记录。k8s服务发现的特性,使CoreDNS很适合作为企业云原生环境的DNS服务器,保障企业容器化和非容器化业务服务的稳定运行。
leader选举过程是这样的;首先candidate向集群其他候选节点(condidate角色的节点)发送投票信息(Request Vote),默认是投票给自己;各候选节点相互收到另外的节点的投票信息,会对比日志是否比自己的更新,如果比自己的更新,则将自己的选票投给目的候选人,并回复一个包含自己最新日志信息的响应消息;经过上述的投票,最终会有一个节点获取多数投票(超过集群节点数的一半),即这个节点就被当选为leader代表集群工作;即该节点会从candidate角色转换为leader;成为leader的的节点会定时发送自己的心跳信息,以此来维护自己leader的地位(默认是每100ms发送一次);其他节点收到leader发送的心跳信息后,会将自己的状态从candidate转换为follower状态,然后从leader节点同步数据到本地;
k8s高可用主要是对master节点组件高可用;其中apiserver高可用的逻辑就是通过启用多个实例来对apiserver做高可用;apiserver从某种角度讲它应该是一个有状态服务,但为了降低apiserver的复杂性,apiserver将数据存储到etcd中,从而使得apiserver从有状态服务变成了一个无状态服务;所以高可用apiserver我们只需要启用多个实例通过一个负载均衡器来反向代理多个apiserver,客户端和node的节点的kubelet通过负载均衡器来连接apiserver即可;对于controller-manager、scheduler这两个组件来说,高可用的逻辑也是启用多个实例来实现的,不同与apiserver,这两个组件由于工作逻辑的独特性,一个k8s集群中有且只有一个controller-manager和scheduler在工作,所以启动多个实例它们必须工作在主备模式,即一个active,多个backup的模式;
apiserver认证和准入控制过程,用户通过https将管理集群的请求发送给apiserver,apiserver收到对应请求后,首先会验证用户的身份信息以及合法性;这个认证主要通过用户提供的证书信息;如果用户提供的证书信息apiserver能够再etcd中完全匹配到对应信息,那么apiserver会认为该用户是一个合法的用户;除此之外,apiserver还会对用户提交的资源请求进行准入控制,所谓准入控制是指对应用户提交的资源请求做语法格式检查,如果用户提交的请求,不满足apiserver中各api的格式或语法定义,则对应请求同样会被禁止,只有通过了apiserver的认证和准入控制规则以后,对应资源请求才会通过apiserver存入etcd中或从etcd中获取,然后被其他组件通过watch机制去发现与自己相关的消息事件,从而完成用户的资源请求;
浙公网安备 33010602011771号