通过jenkins交付微服务到kubernetes

随着Kubernetes的遍地开花，Kubernetes的优势可以说是深入人心，很多企业也是利用Kubernetes，来实现更高效的交付和更好地提高我们的资源使用率，推动标准化，适应云原生。

随着Kubernetes和云原生加速企业产品落地，现在总结以下几点

1）更快的应用开发与交付
2）天然适合微服务，是微服务和Devops的桥梁
3）可移植性，支持公有云，私有云，裸机，虚拟机
4）标准化的应用开发与发布：声明式API和Operator
5）自动化运维：弹性伸缩（HPA），故障自愈，负载均衡，配置管理等

另外就是交付spring cloud到k8s之前说一下微服务的概念

什么是微服务？

早在2011年的5月份在威尼斯的一个架构研讨会上微服务的概念就被人提起了，当时的参会者对它的描述只是一种通用的软件并没给出明确的定义是什么，之后随着技术的不断发展，在2014年詹姆斯里维斯以及它的伙伴马丁福勒在它的微博中发表了一篇有关于微服务特点的文章，对微服务进行了全面的阐述，之后微服务就走进了我们的视野
https://martinfowler.com/articles/microservices.html
这是关于网站的描述
在这个文章中并给出微服务一个明确的定义，微服务其实是一种软件的架构风格，是一种将单体架构
拆分为小的服务进行去开发，每个服务都运行在自己的进程中，采用的是轻量级的restful或者http进行通信，并且都是独立开发独立部署和测试的，可以使用多种语言进行开发

对于微服务有一个关键点叫化整为零，把一个大的应用却成一个小的不同的应用
比如嘀嘀打车，早期在一个互联网应用上基本上都是单体架构，不是分布式的
单体情况下把很多程序都写一个程序中，然后一台服务器对所有服务进行运行，但是随着并发的提高，这种单体架构显然承受不了了，这样的话就需要我们对我们软件的指责进行慢慢的划分，将其剥离出来，形成一个一个的微服务，也就是多个微服务的模块形成一个完整的应用，这些都是独立部署独立运行的，一个微服务也会运行在一个虚拟机里面。

spring cloud微服务体系的组成

服务发现 （Eureka，Cousul，zookeeper）
也就是注册中心最为微服务必不可少的中央管理者，服务发现的主要职责就是将其它的微服务模块进行登记与管理，这就相当于生活中来了一家公司，去工商局进行登记一样的道理，在服务发现中它主包含了三个子模块，分别是eureka，cousul，zookeeper，这些spring cloud底层都支持的注册中心，一般常用的是eureka和consul，那么微服务构建好了之后，那么微服务与微服务直接怎么进行服务直接的通信，或者微服务遇到了故障无法达到请求的话（hystrix/ribbon/openfeign）
另外就是路由与过滤主要是针对对外接口的暴露的，这里主要涉及zuul，spring cloud gateway，这两个组件主要为外部的调用者比如其他的系统和我们的微服务进行通信的时候，由外到内是怎么彼此进行访问的，那么这些就是由这两个组件进行完成的
配置中心就是存放我们应用程序配置的地方，可能我们有上百个应用程序，那么每个应用程序都是一个微服务，那么就会产生一个很严重的问题，就是这些配置文件放在什么地方比如每个服务下都放一个xml，或者yml，维护起来是非常不方便的，因为改一个参数，就要对所有的应用进行调整，为了解决这个问题配置中心就出现了，相当于又提供了一个微服务把我们应用中所有的配置文件，都放在了配置中心中，那么其他应用都是通过配置中心来获取到这些配置文件的而不是我们要这个这个配置文件放到每个程序中，这样的好处就是可以将我们的配置文件进行集中的管理，只需要改一个地方所有地方都能生效

spring cloud微服务组成

消息总线，spring cloud stream或者spring cloud bus就跟我们的消息mq差不多就是我们发布一个信息，到我们队列里面由其他的微服务或者其他的应用进行获取提供了系统与系统之间或者微服务与微服务之间的消息传递过程，这个中间增加了一个额外的东西叫做消息总线，具体的消息总线可以是mq或者是Redis，不同的厂商实现了不同的实现
安全控制是针对我们安全的管理，在我们传统网站开发的时候，应用的访问控制有授权的可以使用这个功能，没有授权的就无法进行访问，安全控制在spring cloud中也是存在的提供了AUTH2.0方案的支持，链路监控就是对我们消息传递的过程要进行统筹和监控，比如系统中有10个微服务，而这10个微服务是彼此依赖的，第一个微服务它是底层最基础的用户管理而第二个微服务是基于用户管理开发一个权限管理，在往上是应用管理，应用系统的扩展，每一个微服务之间彼此之间进行依赖在顶层我们进行调用的时候会安装微服务的调用顺序一级一级消息往下传递，这样做有一个问题来了，如果中间有个环节出现了问题，没有响应服务我们在使用的角度当前我们的请求失败了，但是具体的环节不知道是在那一块出现问题，那么链路监控就是让我们快递定位消息传递过程哪个阶段进行出错，有助于我们问题的排查
spring cloud cli命令行工具，来实现我们开发来实现的一些功能，spring cloud cluster是对我们集群管理的一个辅助工具

现在去交付微服务到k8s中举个demo仅供参考

一、发布流程设计
二、准备基础环境
三、在Kubernetes中部署jenkins
四、jenkins pipeline及参数化构建
五、jenkins在k8s中动态创建代理
六、自定义构建jenkins-slave镜像
七、基于kubernetes构建jenkins ci系统
八、pipeline集成helm发布spring cloud微服务

一、传统的发布流程是怎么样的？
现在的这个发布流程设计还是要和自己的项目中去考量，布置一个大体的拓扑图，那么比如没有这样的场景jenkins去发布微服务，它是一个怎么样的流程，作为运维来讲首先要去拉代码，开发已经将这个项目开发好了，并推送到git仓库中或者部署的私有的gitlab代码仓库中，第一步做的就是将这个代码拉下来，拉完代码，一般代码都是Java应用，会设计到一个编译，编译出来一个可部署的包，一般微服务是jar包，或者直接启动的应用程序，然后就开始去封装这个服务了，一般就是将这个jar包或者应用程序，通过dockerfile去达成一个可部署的镜像，这个镜像一般会自己制作jdk环境，或者就是jre环境，就是基础镜像能够运行这个镜像的底包，最后一步就是部署到k8s中，这里就会写一些yaml文件了去把这个镜像部署到k8s中，也就是容器的编排，另外还要考虑怎么将这个应用暴露出去，让用户访问到。

使用jenkins自动话发布的流程是这么样的？
显然这种方式发布多个微服务很不高效，所以就需要ci/cd，这么一说，那么有jenkins了，怎么将这种方式自动化起来，减少人工的干预。
上面那张图，首先是这样的，开发将代码推送到git仓库中，通过commit提交上去，然后再到jenkins了，它负责的任务就是checkout代码的拉取，code compile代码的编译，docker build &push ，镜像的构建与推送到harbor仓库中，然后deploy，将应用部署到k8s中，这里呢由于可能是很多的微服务，那么我们就需要模版的代替，去发布微服务，这里我们就会需要用到它原生的helm微服务发布工具来到k8s当中去deploy，发布到测试环境中去，然后通过slb提供一个统一的出口，发布出去，中间产生的镜像也都会存放到harbor仓库中，当QA测试没有问题，这个镜像也就可以去发布生产环境中。

为什么需要jenkins slave架构
另外这里还提到了一个jenkins，slave的一个架构，主要的是可以动态的可以完成这些任务，动态的去调度一个机器和一个pod来完成这几步的任务，因为当任务很多时，也就是都在jenkins master去做，显然任务多了负载就高了，所以就需要引入这个slave去解决这个问题。

二、准备基础环境，所需的组件来完成我们流程的发布

1、k8s——（ingress controller、coredns、pv自动供给）
2、harbor,并启用chart存储功能，将我们的helm打成chart并存放到harbor中
3、helm-v3 工具，主要来实现模版化，动态的将应用渲染安装与卸载，更好的去管理微服务
4、gitlab代码仓库，docker-compose实现
5、MySQL，微服务数据库
6、在k8s中部署eureka（注册中心）

1、检查k8s基础组件的环境是否安装：
1、默认我的这个基础的组件都是安装好的，ingress 和coredns

[root@k8s-master1 ~]# kubectl get pod -A
NAMESPACE              NAME                                         READY   STATUS    RESTARTS   AGE
ingress-nginx          nginx-ingress-controller-2vs56               1/1     Running   0          5h3m
ingress-nginx          nginx-ingress-controller-586gw               1/1     Running   0          167m
ingress-nginx          nginx-ingress-controller-pxztr               1/1     Running   0          5h3m
ingress-nginx          nginx-ingress-controller-qp266               1/1     Running   0          5h6m
kube-system            coredns-59fb8d54d6-vjn62                     1/1     Running   0          5h7m
kube-system            kube-flannel-ds-amd64-2hnkf                  1/1     Running   0          5h7m
kube-system            kube-flannel-ds-amd64-2smpl                  1/1     Running   0          5h7m
kube-system            kube-flannel-ds-amd64-jbrv4                  1/1     Running   0          167m
kube-system            kube-flannel-ds-amd64-jsxdf                  1/1     Running   0          5h7m
kubernetes-dashboard   dashboard-metrics-scraper-566cddb686-mddlb   1/1     Running   0          5h7m
kubernetes-dashboard   kubernetes-dashboard-c4bc5bd44-wpgc7         1/1     Running   0          5h7m

1.2、k8s pv的自动供给，这里当然也可以使用Ceph持久化存储，由于我的测试环境配置不够，先拿NFS对有状态的应用实现自动的PV供给。
先准备一台NFS服务器为K8S提供存储支持

[root@k8s-node3 ~]# yum -y install nfs-utils
创建共享的目录
[root@k8s-node3 ~]# mkdir /ifi/kubernetes -p
[root@k8s-node3 ~]# cat /etc/exports
/ifi/kubernetes 10.4.7.0/24(rw,no_root_squash)
[root@k8s-node3 kubernetes]# systemctl start nfs
[root@k8s-node3 ~]# systemctl enable nfs

并且要在每个Node上安装nfs-utils包，用于mount挂载时用。
[root@k8s-master1 ~]# mount -t nfs 10.4.7.22:/ifi/kubernetes /mnt
由于K8S不支持NFS动态供给，还需要先安装nfs-client-provisioner插件
修改nfs的服务端地址和挂载的目录，这是我nfs-client的地址，如果借鉴的需要将id_rsa.pub给我
git clone [email protected]:zhaocheng172/nfs-client.git
[root@k8s-master1 nfs-client]# kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
busybox                                   1/1     Running   0          35m
nfs-client-provisioner-86dff449dd-68ngn   1/1     Running   0          106s

2、镜像仓库Harbor
2.1安装docker与docker-compose

# wget http://mirrors.aliyun.com/docker-ce/linux/CentOS/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo
# yum install docker-ce -y
# systemctl start docker
# systemctl enable docker

docker-compose的下载地址：https://docs.docker.com/compose/install/
curl -L https://github.com/docker/compose/releases/download/1.25.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

2.2 解压离线包部署
下载地址：https://github.com/goharbor/harbor

# tar zxvf harbor-offline-installer-v1.10.1.tgz
# cd harbor
# vi harbor.yml
hostname: harbor.zhaocheng.com
# ./prepare
# ./install.sh --with-chartmuseum
# docker-compose ps 

--with-chartmuseum 参数表示启用Charts存储功能。
进行访问：
http://harbor.zhaocheng.com
这个已经启动chart功能

2.3 配置Docker可信任
由于habor未配置https，还需要在node节点上的docker配置可信任。

# cat /etc/docker/daemon.json 
{
  "registry-mirrors": ["https://38vve9ja.mirror.aliyuncs.com"],
  "insecure-registries": ["harbor.zhaocheng.com"]
}
# systemctl restart docker

3、helm-v3 工具
3.1安装helm工具

[root@k8s-master1 helm]# wget  https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gz
[root@k8s-master1 helm]# tar xf helm-v3.0.0-linux-amd64.tar.gz 
[root@k8s-master1 helm]# mv linux-amd64/helm /usr/bin/
[root@k8s-master1 helm]# helm  --help

3.2 安装push插件

# git clone https://gitee.com/zhaocheng172/helm-push.git
# tar zxvf helm-push_0.7.1_linux_amd64.tar.gz
# mkdir -p /root/.local/share/helm/plugins/helm-push
# chmod +x bin/*
# mv bin plugin.yaml /root/.local/share/helm/plugins/helm-push

3.3 添加repo
# helm repo add  --username admin --password Harbor12345 myrepo http://192.168.30.27/chartrepo/library

3.4 推送与安装Chart
helm安装好有默认的模版，那么我们先使用它的进行生成一个chart包，用于我们测试推送到我们的Harbor仓库中，这个Chart是当我们部署完之后，官方默认自带的模版，小的demo,install之后是一个Nginx的应用

[root@k8s-master ~]# mkdir chart-test
[root@k8s-master ~]# cd chart-test/
[root@k8s-master chart-test]# helm create test
[root@k8s-master chart-test]# helm install test01 test
NAME: test01
LAST DEPLOYED: Sat Mar 14 17:10:20 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=test,app.kubernetes.io/instance=test01" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:80

这里是直接使用他们自己写的模版创建的pod
查看这个pod已经正常运行，而这个test01是我们自己起的名字，这个部署的时候一般是我们的微服务的名称
要是去加个--dry-run的话就是预先执行，一般看看这个模版有没有都执行成功，有没有问题

[root@k8s-master chart-test]# helm install test02 --dry-run test/

[root@k8s-master chart-test]# kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-564dddddd6-dgv26   1/1     Running   8          26h
test01-f7f8c5759-zv8kf                    1/1     Running   0          31s

没什么问题的话我们就需要将这个chart达成一个包，以便下次的时候再用
[root@k8s-master chart-test]# helm package test/
Successfully packaged chart and saved it to: /root/chart-test/test-0.1.0.tgz
[root@k8s-master chart-test]# ls
test  test-0.1.0.tgz

推送到我们的镜像harbor仓库中
[root@k8s-master chart-test]# helm push test-0.1.0.tgz --username=admin --password=Harbor12345 http://192.168.30.27/chartrepo/library
Pushing test-0.1.0.tgz to http://192.168.30.27/chartrepo/library...
Done.

tgz包安装helm ，一般用于之前制作的包，比如我们之前制作的模版，如果想使用了，那么直接就可以再使用

[root@k8s-master ~]# helm install test02 test-0.1.0.tgz 
NAME: test02
LAST DEPLOYED: Sat Mar 14 17:49:00 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1

4、部署gitlab，这里分别我整理了两个方法来部署gitlab，第一个是英文版页面，第二个是中文版页面
4.1#安装gitlab，建议2c2g+

yum -y install policycoreutils openssh-server openssh-clients postfix
#修改postfix
sed -i 's/inet_interfaces = localhost/inet_interfaces = all/g' /etc/postfix/main.cf
sed -i 's/inet_protocols = all/inet_protocols = ipv