服务交付架构

Dubbo是基于java开发的，是一个分布式微服务框架（服务调用），如果没有分布式需求，是不需要Dubbo的。

• Registry：不管是消费者还是提供者，都需要联系注册中心，只是提供者是注册，而消费者是订阅；
• Consumer：通过RPC调用Provider提供的方法（如下图的invoke），就像调用本地方法一样；
• Monitor：监控消费者和提供者的信息；

• 开发会把代码托管到Git上，进行代码托管，以及版本管理；
• 运维会通过工具（这里是Jenkins）从Git上拉代码，并编译代码打包成Docker镜像，上传到Harbor数据库中；
• 运维再通过k8s的资源配置清单，应用到K8s集群中，把服务生成Pod并提供服务；
• Pod利用Dubbo微服务自动去注册中心注册（ZK，ZooKeeper，类似ETCD），这里的ZK同ETCD一样，不会部署在K8s内，因为是有状态服务；
• Dubbo微服务的提供者集群和消费者集群部署在K8s中，方便利用K8s的机制并根据实际情况进行灵活的扩容/缩容；
• 用户通过Ingress规则，找到相应消费者集群，完成服务互动；

这里只介绍如何部署Dashboard，至于使用方法，会在之前的文章：K8s – Core Resource Management Method GUI部分进行总结；

安装部署Dashboard

上传Dashboard的Image

root@f0-15:~# docker pull docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
v1.8.3: Pulling from k8scn/kubernetes-dashboard-amd64
a4026007c47e: Pull complete 
Digest: sha256:ebc993303f8a42c301592639770bd1944d80c88be8036e2d4d0aa116148264ff
Status: Downloaded newer image for k8scn/kubernetes-dashboard-amd64:v1.8.3
docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
root@f0-15:~# docker images |grep dashboard
k8scn/kubernetes-dashboard-amd64   v1.8.3                     fcac9aa03fd6   4 years ago   102MB
root@f0-15:~# docker tag fcac9aa03fd6 harbor.frank.com/public/dashboard:v1.8.3
root@f0-15:~# docker push harbor.frank.com/public/dashboard:v1.8.3

由于安全原因，实验环境必须跳板机（现有的是Win Server，开启了多账户），从实验环境拷贝东西回来，也需要特定的接口，此时还没有GUI，每次手动调用接口很麻烦，所以就写了一个简单的批处理文件，可以执行如下功能：

• 拖拽需要上传的文件到这个批处理文件上，可以自动读出该文件的实际路径；
• 自动读取当前用户名；
• 执行完后不自动退出，显示输出结果；

下载Curl Win版本

这个必须科学上网才能下载，我直接附在这里，方便下载：

coreDNS实现了服务在集群内被自动发现，那么如何实现服务在集群外被自动发现呢？这里有两种方法，这里只关注Ingress资源：

• 使用nodeport service，在这种方法中，kube-proxy只能使用iptables模型，不能使用ipvs模型；
• 使用Ingress资源，只能调度并暴露7层应用，特质http或https；

常用的Ingress控制器主要有以下几种，这里使用traefik：

• Ingress-nginx
• HAProxy
• Traefik

注意：ingress资源和ingress控制器不是一个东西（具体可以看最下面的流程图）：

• ingress资源：专用于暴露7层应用（http/https）到k8s集群外的一种核心资源；

• ingress控制器：简化版本的nginx（调度流量）+go脚本（动态识别yaml，主要用于监控ingress配置清单的变化以做出应对），traefik就是其中之一；

安装部署Traefik

上传Traefik的Image

服务发现

服务之间互相定位的过程，以适应如下服务特点：

• 动态性强；
• 更新发布频繁；
• 支持自动伸缩；

在k8s集群里，pod ip是不断变化的，如何找到对应的pods？首先集群网络抽象了集群IP，Service资源绑定Cluster IP并暴露这个资源，Service本身根据标签选择器，来锁定一组pods，并通过ipvs算法分配这组pods的资源。也可以参考上一篇的总结：管理Service资源。

那么新的问题来了，虽然可以通过Service找到pod，但如果有很多不同的Services，很难把所有Services与Customer IP的关系记下来，这个是不是很像DNS被创造出来的初衷^_^~？那我们是否可以通过类似DNS的机制，绑定Service和Cluster IP呢？答案是肯定的：

• Kube-dns，k8s v1.10之前默认使用；
• Coredns，k8s v1.11以后默认使用；

安装部署CoreDNS