【K8S运维知识汇总】第4天9:实战交付dubbo服务到K8S集群、开场
现在把nginx的流量调度恢复
4层的也进行恢复
两台nginx上跑了一个keepalive,把另外一台也配置上
把配置黏贴过来
这样nginx也都好了
完全是用traefik-ingress控制器来对流量进行分发,也就是ingress的资源就是一个可视化的nginx
把容器删了,自己会钻到21上了
dashboard现在就一个副本,想要2个
就会给你起来一个,这样就很方便对容器横向扩容
小人输入dashboard.od.com,流量是从笔记本浏览器经过dns解析到vip 10.4.7.10上(也就是10.4.7.11/12),进入到11节点上的7层负载均衡nginx里,nginx看到你请求的域名是dashboard.od.com,于是匹配到了自定义的dashboard.od.com,rewrite 443,卸载到了证书,然后帮你抛到了ingress上,ingress监听在了每个宿主机运算节点的81端口,把dashboard.od.com抛到了ingress,ingress控制器就会根据你的ingress资源配置找到host:dashboard.od.com,路径 /给你抛到dashboard的service上,相当于kubelet 把service和pod链接起来了,帮你找到了pod,pod在不同的节点,由kube-proxy的轮询算法,ipvs
这里就是dashboard,kube-proxy找到了192.168.40.188:443,用永不排队的NQ,lvs的轮询算法,轮询到172.7.21.5:8443,让两个dashboard能够交替给你服务。
跨宿主机能够通信,是因为装了CNI网络插件
Dubbo是一个阿里开源的微服务框架,基于java开发
Dubbo的架构,最主要的组件是registry(注册中心,服务发现就依赖这个注册中心,不管是消费者还是提供者都需要去链接注册中心,提供者provider到注册中心是注册地过程,消费者consumer到registry是订阅subscribe)
consumer 调用invoke provider提供者,是通过rpc协议去调用的,也就是远程过程调用,就好像在调用本地方法一样
这样就可以一些服务拆开了,consumer是web工程(各种页面调用的方法是后台不同的provider)
consumer是web工程(各种页面调用的方法是后台不同的provider),以前是调用本地方法,消耗本地资源 ,服务器就需要升级,不利于横向扩容,调用这些服务的时候,都可以让他们独立的一个个写成单独的服务,web服务区调用服务的时候,就好像在调用本地方法一样,实际上是资源不重叠的
真正交付Dubbo,要交付registry,provider,然后monitor和consumer
实验架构图,右上角是注册中心,Dubbo微服务的注册中心是依赖于zookeeper来做的,中间段是k8s集群,有DUbbo微服务提供者集群和Dubbo微服务消费者集群,都是封装pod,交付到k8s里,把能够动态扩容的服务都放到k8s里,把微服务的消费者和提供者交付到k8s集群里,同时把Dubbo-monitor交付到k8s集群里。
开发会把代码放到版本控制中心,运维使用恰当工具持续集成部署
编译代码,打包成docker镜像,放到harbor仓库里,ops服务器就是hdss7-200,做一个k8s的资源配置清单,应用到k8s里,就把代码变成了pod
用户访问找ingress,ingress配置好规则daemon.od.com,然后到消费者集群,消费者集群是一个web服务
这里需要把zk放在k8s外面,原因是zk是典型的有状态服务,不适宜放到k8s里进行管理
k8s具有很强的动态性,pod是可以漂移的,所以pod管理的一定是不能有状态的,无状态的意思就是这个容器死了就死了,无所谓,随便扩容,随便死。
有状态服务,是要有数据持久化下来,很不适合放在k8s里管理,k8s也有专门管理有状态服务的,叫是StatefulSet,这个pod控制器来管理有状态服务
ES MYSQL,ZK这种有状态服务,最好放到k8s外面去