快速部署应用到阿里云Kubernetes
文章目录
今天给大家介绍下如何快速部署应用到阿里云Kubernetes
(托管版),以下简称k8s
k8s
是个复杂的产品我相信大部分企业在应用的时候并不会关系太深层次的问题,所以我个人比较推荐的k8s
使用方式是直接部署各大云平台的托管版
(Azure
云平台只提供了托管版
)。托管版
有如下优势:
- 部署简单,因为云平台解决了
master
节点管理,所以我们只需一键部署node
节点 - 运维简单,因为只管理
node
节点,所以我们并不需要担心集群可靠性问题。并且云平台一般会在安装的k8s
版本中嵌入云平台自己的网络和存储解决方案。网络方面可能体会不太明显,但至少我们可以直接在k8s
中管理云磁盘Disk
- 成本低,大部分中小公司如果要运作
k8s
是需要招聘独立的运维人员的,如果使用托管版
我相信一般的运维人员或开发人员是可以替代的,因为运维并不需要花太多功夫
所以今天的主题中k8s
的托管版
是我们强调快
的其中一个因素。
另一个因素就是Coderun
,它是一个CI/CD
平台,你可以将它与Jenkins
、drone
、Travis
或Codefresh
等进行比较,他们是类似的平台,其实准确说Coderun
和Codefresh
是比较类似的,与其他平台的差异是集成了镜像仓库
和Helm Charts
,以及集成了一些相关的云平台资源,所以它是另一个快
的因素。
阿里云Kubernetes
阿里云k8s
部署这里不进行介绍,详见:阿里云ACK
- 自部署,阿里云仅提供一键部署但不提供管理和后续维护.要求用户水平较高
- 托管模式,阿里云提供一键部署,并负责管理
Master
节点.这种模式用户仅需要管理Node
节点,基本不需要担心节点挂了,并且可以自行确定Node
节点要求的性能.后续升级也可以交给阿里云负责 - serverless,终极模式,啥都不需要管理,只需要把镜像提交上去,并确定资源需求即可.不需要维护任何服务器.
如上所述我比较推荐托管版
获取KubeConfig
不管哪种集群创建后都可以在控制台获取到KubeConfig
配置,在阿里云控制台点击某个集群后可以看到下图KubeConfig
:
我们需要三个信息:
server
,集群地址,阿里云为每个Kubernetes集群都分配了一个外部地址(如果是自部署模式好像需要自己配置)client-certificate-data
,集群的访问证书client-key-data
,相当于证书的秘钥
如果你为k8s
开启了RBAC
模式,那么我们需要创建Service Account
并绑定Role
后参考Token
模式配置:K8s Token
Coderun
Coderun
的地址是:https://g.coderun.top/,我们需要先进行注册,当然它的注册很方便,直接使用Github
、Gitlab
、Gitee
或Coding
账号都可以直接登录(注册并登录),所以如果你的代码仓库是使用云平台那最好直接使用可以访问你代码仓库的账号进行登录,这样就可以直接使用相关的代码仓库。
下面演示的例子: coderun-demo,因为我是直接使用Github
账号登录,所以默认会自动添加了Github
的配置,如果你要构建的仓库不在你的当前账号下需要自己再配置Git
账号,参考官方文档:Git配置
配置Kubernetes集群
现在我们需要将k8s
的集群连接配置到Coderun
中,在控制台的整合
->Kubernetes
,点击右边的添加
按钮选择证书
模式(如果你使用Token
请选择Token
模式),如图:
- 其中上图中的
名称
是你可以自行定义的名称,这个名称可以方便后续在Pipeline
中使用,所以最好取一个好记的名称(这里使用myk8s
). - 证书:填写
KubeConfig
中的client-certificate-data
的内容 - Key:填写
KubeConfig
中的client-key-data
的内容
完毕后保存,对于Pipeline
就有一个可用的myk8s
的集群,这个集群连接到我们在阿里云上的k8s
集群,后续的所有部署只需要部署到myk8s
即可。
配置Pipeline
添加仓库
在Coderun
控制台的Repo|仓库
,点击添加仓库
.在右侧选择代码仓库,(如果不是当前用户的Git
仓库,参见Git配置),如下图:
点击下一步后,选择Build
类型
三种类型分别是:
coderun.yml
,使用代码仓库中的coderun.yml
文件进行构建Dockerfile
,使用代码仓库中的Dockerfile
作为镜像的构建- 模板,和上述的
Dockerfile
类似,只是使用Coderun
内置的各语言Dockerfile
模板
因为我们在代码仓库中已经有Dockerfile
,所以直接使用Dockerfile
创建,我们可以看到添加好的仓库:
Pipeline
配置
点击添加好的仓库hellwen/coderun-demo
,我们可以看到Pipeline
页面,如图:
Pipeline
配置如下:
|
|
默认coderun
会将Dockerfile
解析出来,这样的好处是在Coderun
上可以随意修改Pipeline
并重新部署而无需重新提交代码仓库,因为我更想使用代码仓库中的Dockerfile
所以更简洁的配置:
|
|
上述配置会默认使用当前代码仓库下的Dockerfile
文件,注意:如果是使用代码仓库中的文件是和Build
的代码分支有关(使用对应分支下的Dockerfile
)
几个比较重要的配置:
docker
: 这个关键字可以任意定义,用于给每个step
取一个名称,后面会显示在Build
日志中image
: 指定了用于step
的基础镜像,这里默认使用官方的docker
镜像处理Dockerfile
registry_name
: 这个参数是指定代码仓库的配置,相关的配置在整合
中,每个用户coderun
会自动创建一个同名的镜像仓库,所以这里可以直接使用repo_name
: 镜像名称,默认为代码仓库名称,可以执行修改但要注意不要和其他仓库镜像同名tags
: 指定build
后镜像的tag
分支名称
详细的配置说明详见文档:crun/docker
如果你想使用脚本自己构建Dockerfile
,可以把crun/docker
替换成docker
配置好我们就可以进行下测试了,选择分支
页面,如图:
点击Build
后可以看到当前的Build
进度,第一次Build
一般会因为上传镜像所以稍微有点慢
Build
完成后如下右上角有绿色确定图标指示成功:
crun/docker
会自动上传镜像到对应的仓库中,所以观察日志可以看到上传后的镜像地址是:r.crun.top/hellwen/hellwen/coderun-demo:latest
,其中hellwen/hellwen
并不是Bug
第一个hellwen
是Coderun
账号,第二个hellwen
是Github
账号(我们添加的仓库的前缀)
我们到镜像
页面可以看到我们刚刚上传的镜像:
Kubernetes部署
前面步骤我们只是完成了镜像
的构建,有了镜像后我们就可以进行部署。
配置镜像仓库到k8s
如果要让k8s
访问你的Coderun
私有镜像仓库需要配置Secret
,操作如下:
Coderun
不支持账号密码,因此我们需要一个Token
,可通过整合
->Token
获取:
点击生成Token
,任何输入一个名称,点击生成
,如下:
复制上图的Token
备用:bj8pikhk57kg00fn9vd0
(要使用kubectl
访问k8s
集群请自行配置KubeConfig
,参考:阿里云上的进群KubeConfig
页面)
|
|
其中docker-password
为上面生成的Token
,docker-username
修改成你自己的账号
|
|
Pipeline
增加deploy
在原有Pipeline
配置上增加一个step
: deploy
|
|
- 其中
crun/kube
是官方提供的插件,用于部署到k8s
,它可以执行任何k8s
对象 cluster_name
这里指定的是前面步骤配置的k8s
集群,我们命名为:myk8s
namespace
指定k8s
集群的默认命名空间template
指定k8s
能有效识别的yaml
配置(可以包含:service
和deployment
等)
详细的配置说明详见文档:crun/kube
其中deployment.yml
如下(内容有点多,不好意思,如果你不了解k8s
请自行学习):
|
|
重要参数:
image
中我们使用了一个变量{{CR_IMAGE}}
这个变量会自动从crun/docker
获取到build
后的完整镜像地址Ingress
中的host
配置为空是为了让集群的根目录可以访问到
其中ingress
需要nginx-ingress
控制器的支持(如果没有安装你没法访问到部署后的页面,但部署依然正常的)。
helm
的安装这里不介绍了,自行Google
,如果要安装ingress
控制器可以使用下列命令:
|
|
在执行一次Build
,如下:
上图的左边列表我们可以看到多了一个deploy
,右边的日志显示我们部署了Deployment
,Service
和Ingress
部署效果
部署后的k8s
状态(要使用kubectl
访问k8s
集群请自行配置KubeConfig
):
|
|
|
|
上面的镜像地址我们可以看到使用{{CR_IMAGE}}
会自动被替换成r.crun.top/hellwen/hellwen/coderun-demo:latest
,也就是crun/docker
上传的地址,是不是特别方便了:)
访问应用
如果有ingress
控制器,直接使用ingress
的地址47.110.164.15
进行访问:
下次你如果往代码仓库中提交代码,Coderun
就会自动触发并自动部署,完全自动哦。
总结
到这里我们的部署就完成了.比起自己搭建Jenkins
是不是方便不少
Jenkins
应该是用得做广泛的CI/CD
工具了,但是Jenkins
并不诞生在Docker
和Kubernetes
的年代,所以难免有些设计比较落后。最明显的问题就是配置的雪花问题,现在的运维架构很讲究IaC,从Iac
的角度来讲雪花会带来后续大量运维和管理难点。
目前新的CI/CD
一般都采用一个一代码仓库统一进行管理的配置
文件方式来进行部署,这样就可以避免雪花问题。Coderun
更是如此,相较于其他产品我觉得Coderun
的好处有几点:
- 国内的平台,速度和服务有保障
coderun.yml
解决雪花问题,支持嵌入式和文件方式配置- 整合常见的Git平台:
Github
、Gitee
、Coding
、Gitlab
(其中Gitee
和Coding
国内有不少用户,国外产品不太会支持这两个代码仓库) - 自带
镜像
仓库和Helm Charts
仓库,更方便维护和Pipeline
的使用 - 基于
docker
镜像作为step
,用户可以自定义自己的镜像,进行无限扩容
文章作者 今何安
上次更新 2019-05-07