基于 Kubernetes 的持续部署CD方案详解

| 作者:toryzen

| 来源:http://1t.click/T9v

方案概述

本技术方案为基于 kubernetes (下文简称 K8S )为核心的持续部署(下文简称CD)方案,可以满足开发方的程序级日志查看分析,运维方的快速扩容与日常运维分析,并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升,在不降低服务可靠性的前提下降低资源使用成本。

使用场景分析

本方案适用于以 Tomcat 为容器的 JavaWeb 项目的持续部署过程,在 K8S 方案中,所有的 Node 节点均采用统一配置,根据业务环境的需求进行节点数量的控制。

技术架构与选型

  • Kubernetes:一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效, Kubernetes提供了应用部署,规划,更新,维护的一种机制。
  • Nginx:一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。
  • Harbor:Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器,通过添加一些企业必需的功能特性,例如安全、标识和管理等,扩展了开源Docker Distribution。
  • Jenkins:一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。
  • Filebeats:是一个日志文件托运工具,在你的服务器上安装客户端后,filebeat会监控日志目录或者指定的日志文件,追踪读取这些文件(追踪文件的变化,不停的读),并且转发这些信息到elasticsearch或者logstarsh中存放。
  • Elasticsearch:是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。
  • Kibana是一个开源的分析和可视化平台,设计用于和Elasticsearch一起工作来搜索,查看,并和存储在Elasticsearch索引中的数据进行交互
  • Gitlab自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目(这里的Gitlab并不涉及到开发的CI方案,主要为运维的CD方案)
  • Weave Scope Docker 和 Kubernetes 可视化监控工具。Scope 提供了至上而下的集群基础设施和应用的完整视图,用户可以轻松对分布式的容器化应用进行实时监控和问题诊断。

K8S集群部署模式:Stacked etcd topology

K8s的安装使用kubeadm安装为高可用集群,并选用Stacked etcd topology 模式

详情参考 https://kubernetes.io/docs/setup/independent/high-availability/

K8S生态技术选型:网络层面选型Weave

容器网络解决方案。weave 创建的虚拟网络可以将部署在多个主机上的容器连接起来。对容器来说,weave 就像一个巨大的以太网交换机,所有容器都被接入这个交换机,容器可以直接通信,无需 NAT 和端口映射。

原理详解:http://dockone.io/article/262

K8S生态技术选型:对外服务选型 Nodeport

K8s目前支持nodeport、loadbanlace、ingress三种对外提供服务的模式,其中loadbanlace需要云平台的支持,阿里云提供了解决方案,但腾讯云未找到,ingress技术为新出技术。

整体评估采用nodeport方式更为灵活,每个服务一个唯一的对外IP地址,并且使用Nginx进行负载均衡(采用Nginx主要为日志分析)。

介绍与使用方法:https://kubernetes.io/docs/concepts/services-networking/service/#nodeport

持续部署过程

  • Jenkins 构建时,需要传入程序版本号,构建类型(发布还是删除),程序类型(测试还是正式)。
  • CD 的全过程由位于 Jenkins 上的脚本执行
    • 开发部将对应版本的 ROOT.war 传入 Jenkins 指定目录
    • 下拉配置(包含config,hosts,dockerfile,k8syaml等等)
    • 由 dockerfile 生成 docker 容器,并将 root.war,hosts 与配置文件内置入容器中
    • 将 docker 容器打包并推送入 registry
    • 通过 kubectl 通过 k8syaml 更新/生成新的服务

各组件业务配置

K8S业务配置

命名空间

在业务上,K8S默认配置两套Namespace,分别为master存放正式环境,develop配置测试环境。

对外端口

正式环境WEB端口以32001开始,测试环境以31001开始,且一一对应。

Master数据目录

/data
└── k8s-cd-config
└── test.gyyx.cn
    ├── develop
    │   └── v1.2.0-92-3fdd00f.yaml
    ├─develop.yaml -> /data/k8s-cd-config/test.gyyx.cn/develop/v1.2.0-92-3fdd00f.yaml
    ├── master
    │   └── v1.2.0-91-746284e.yaml
    └──master.yaml->/data/k8s-cd-config/test.gyyx.cn/master/v1.2.0-91-746284e.yaml

K8s-Master 下的 data 目录下为 k8s-cd-config, k8s-cd-config 目录存放各业务的yaml 配置,二级目录为域名,三级目录划分 master (正式),develop (测试),目录下以 版本号-构建 ID-GITID.yaml 命名文件,时间最后一个即为当前线上的使用配置文件,为了运维方便,在二级目录同级内,生成一个软链连接到最新的正式与测试配置文件。注意,k8s-cd-config 仅在其中一台 Master 中存在。

Node数据目录

/data
├── filebeat
├── dockerlibs
└── nodelogs
    ├── develop
    │   ├── accesslogs
    │   │   └── test.gyyx.cn
    │   │       └── test-gyyx-cn-76d9d8d5b5-hdnql
    │   │           └── localhost_access_log.2018-12-24.txt
    │   ├── devlogs
    │   │   └── test.gyyx.cn
    │   │       └── test-gyyx-cn-76d9d8d5b5-hdnql
    │   │           └── interface.datareport.wyx.cn
    │   │               ├── error.log
    │   │               ├── info.log
    │   │               └── trace.log
    │   └── tomcatlogs
    │       └── test.gyyx.cn
    │           └── test-gyyx-cn-76d9d8d5b5-hdnql
    │               ├── catalina.2018-12-24.log
    │               ├── host-manager.2018-12-24.log
    │               ├── localhost.2018-12-24.log
    │               └── manager.2018-12-24.log
    └── master
        ├── accesslogs
        │   └── test.gyyx.cn
        │       └── test-gyyx-cn-895cc5994-sx7gk
        │           └── localhost_access_log.2018-12-24.txt
        ├── devlogs
        │   └── test.gyyx.cn
        │       └── test-gyyx-cn-895cc5994-sx7gk
        └── tomcatlogs
            └── test.gyyx.cn
                └── test-gyyx-cn-895cc5994-sx7gk
                    ├── catalina.2018-12-24.log
                    ├── host-manager.2018-12-24.log
                    ├── localhost.2018-12-24.log
                    └── manager.2018-12-24.log

节点下的/data一级目录下分 filebeat、dockerlibs、nodelogs,其中 dockerlibs 存放docker 相关数据,nodelogs 目录通过 volume 的方式挂载入 k8s的pod, nodelogs 下分 develop 与 master 目录,区分正式环境与测试环境,每个 master 与 develop 下分为 accesslogs、devlogs、tomcatlogs 分别存放访问日志,开发部日志,tomcat 日志,日志目录下为项目(域名),域名下为 POD 名称目录。

注意事项:

节点加入集群后,一定要下载手工下载 kubernetes-dashboard-amd64 镜像,防止dashboard 所在节点挂掉以后 dashboard 无法在其他节点启动。

Harbor业务配置

业务分组

Harbor 重定义其 registry 的存储路径直接使用 docker-compose 安装。template 存放基础进项,各域名分组存放业务镜像

镜像命名

分组下镜像以站点域名:版本号-类型-CDGITLAB为名称,并基于版本号确定不同的站点版本。

数据目录

Harbor数据目录统一存放在/data下。

备份策略

Harbor默认不设置备份,对于业务镜像无需进行备份,每次进行构建即可,对于模板类镜像,在Jenkins机器上均可以找到,若Harbor出现问题,则直接重建,并将Jenkins上的模板镜像进行重新push。

注意:为了业务的稳定性,Harbor由独立的服务运行(基于Docker),并不运行在K8S内。

Jenkins业务配置

数据目录

.
├── dockerlibs
├── thinbackups
└── gitlab-files
│  └── gyyx.cn
│      └── test.gyyx.cn
└── jks-cd-config
    └── test.gyyx.cn
        └── v1.2.0
            ├── develop
            │   └── 101_138a37a
            │       ├── …
            │       └── v1.2.0-101-138a37a.yaml
            ├── master
            │   └── 102_4f228a7
            │       ├── …
            │       └── v1.2.0-102-4f228a7.yaml
            └── ROOT.war

Jenkins 下的 data 目录分为 dockerlibs、thinbackups、gitlab-files 、jks-cd-config Dockerlibs 存放 docker 相关文件,thinbackups 存放每日的 Jenkins备份,gitlab-files存放构建 Gitlab 的文件(运维可以在此操作pull,push),jks-cd-config 为 jks 构建目录。

Jenkins 机使用 /data/jks-cd-config 目录存放构建内容,二级目录为域名,三级目录为版本号(以开发部版本号为准),三级目录下存放 ROOT.war,四级目录为构建 ID_GITID,目录下存放构建的原始数据。

节点每天进行 images 清理工作。

业务分组

Jenkins 的分组分为 template 与各 domain,template 存放模板,domain 以域名的形式存放正式项目:

构建参数

Jenkins 构建时,需要传递三参数,1:程序版本号,2:类型:apply与delete,3:正式环境还是测试环境,正式环境为master,测试环境为develop,对应k8s的namespace。

JenkinsAPI

curl -X POST http://jenkinsapi.com/job/域名/build \
–user admin:11b80a61d260aa41eb4a43ef0115bcbb26 \
–data-urlencode json=’{“parameter”: [{“name”:”VERSION”, “value”:”v1.2.0”}, {“name”:”TYPE”, “value”:”apply”}, {“name”:”BRANCH”, “value”:”develop”}]}’

APIDoc:https://wiki.jenkins.io/display/JENKINS/Remote+access+API Token:https://jingyan.baidu.com/article/0eb457e5dbad8003f0a9056c.html

备份策略

Jenins安装ThinBackup插件,配置每小时进行一次全局备份,且最多保留10份,备份后数据传至异地

注意:为了业务的稳定性,Jenkins由独立的服务运行,并不运行在K8S内。

GitLab 业务配置

业务分组

CD Gitlab项目下分两个组template与各domain ,template存放模板文件。例如:

Git分支

default 下以域名划分项目,每个项目划分 master 与 develop 两个分支,分别存放正式环境与测试环境CD文件

CD文件树

├── catalina.sh              #tomcat配置文件
├── config                  #程序配置文件,此文件夹会替换掉容器内的/data/conf
│   └── hello.conf
├── deployment.yaml         #k8s deploymen配置
├── dockerfile               #docker镜像生成文件
├── hosts                   #docker镜像的hosts,此文件将合并到deployment.yaml
├── service.yaml             #k8s service配置
└── tomcat                 #tomcat配置文件
    ├── Catalina
    │   └── localhost
    ├── catalina.policy
    ├── catalina.properties
    ├── context.xml
    ├── logging.properties
    ├── server.xml
    ├── tomcat-users.xml
    └── web.xml

备份策略

Gitlab使用gitlab-rake gitlab:backup:create进行每日定期备份,并传送至异地

EFK与日志管理

Elasticsearch

ES数据通过索引仅保留近10天的数据,每日通过脚本方式进行数据删除。ES的数据保存在/data/elasticsearch目录下

Filebeat

在每个Node节点启动一个Filebeat进程,用于日志的采集工作,filebeat分别监控

  • /data/nodelogs//accesslogs///
  • /data/nodelogs//devlogs///
  • /data/nodelogs//tomcatlogs///

其中,tomcatlogs日志需要进行特殊处理,进行多行合并,数据写入ES时,使用processors. Dissect进行目录名称截取,并使用域名作为ES的索引使用。

processors:
- dissect:
    tokenizer: "%{?key1}/%{?key2}/%{?key3}/%{wtype}/%{ltype}/%{domain}/%{?key7}/%{?key8}"
    field: "source"
target_prefix: "gy"

截取 gy. wtype ( master或develop) , ltype(accesslogs 、tomcatlogs、devlogs),domain(xxx.gyyx.cn)

Kibana

Kibana目前我们仅使用其discover节点,用于日志数据的查询,在配置方面 Kibana配置使用”域名-*”方式进行配置,每次新增域名,需要在此进行手工配置。

Kibana 使用 discover 查看时,默认展示一个域名下所有的日志,可以通过gy.wtype筛选选择查看测试环境还是正式环境,或者通过gy.ltype哪种日志类型。

容器资源监控

容器资源使用WeaveScope进行资源消耗监控

原文发布于微信公众号 - DevOps时代(DevOpsTimes)

原文发表时间:2019-08-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券