Rainbond V5.2.0-release 发布,拥抱生态,灵活接入Kubernetes集群

好雨云阅读(2640)评论(0)

导读:Rainbond V5.2版本经过4个月的开发迭代,V5.2.0-release 终于发布啦。新版本推出了Rainbond Operator全新的安装模式和运行模式,拥抱Kubernetes生态;不再内置安装Kubernetes,Rainbond应用管理和Kubernetes层完全解耦合,支持接入任何安装方式的1.14版本以上Kubernetes集群;基于生态模式支持接入更多的存储类型、组件类型,使Rainbond扩展能力显著增强;推出企业视图模式控制台,使企业应用开发、管理更加便捷。同时,我们推出 Rainbond Cloud 服务,借助阿里云等已有的公有云资源,帮助企业快速搭建多云应用开发、交付、运维平台。

Rainbond 开源已经经历了30个月,3个大版本迭代,成为3000余企业的选择,落地到交通、能源、高校、民航、军队、政府等数十个行业。Rainbond希望带给大家,面向应用的管理体验,而不是停留在虚拟机和容器资源管理层面的体验,Rainbond砥砺前行。

下面言归正传,让我们来看一下 V5.2.0 有哪些变化?

主要改动说明

V5.2.0版本相对于V5.1.X版本做了大量的功能、架构变更,性能、稳定性优化。为了方便大家阅读,这里仅罗列关键的变更点,细节可以参考Release 记录

1. 引入 Rainbond-operator,对接已有Kubernetes集群

Operator是Kubernetes体系中对于复杂应用管理的扩展模式,关于Operator的理解可以阅读文章 Kubernetes Operator 技术下沉,体验上浮。同样的Rainbond整个架构也可以认为是一套应用,因此我们定义了Rainbond-operator来将Rainbond可以安装到Kubernetes集群中,使用Kubernetes来管理Rainbond系统组件,同时Rainbond又可以反过来管理调度Kubernetes资源。在过去的版本中我们提供了一套Ansible脚本来完成Kubernetes的安装和Rainbond的安装,取得了不错的安装体验。然而缺陷就是限制了Kubernetes版本用户无法自由选择,同时Rainbond还不得不做自身组件的运维工作,重复的造了轮子。Rainbond-operator 的出现完整的解决了这两个缺陷。

Operator 将在Rainbond后续的版本中出现更多,Rainbond目前仅支持几种默认的组件类型,将来将通过Operator的方式定义更多的组件类型,从而更加灵活的支持组件类型扩展。比如基于etcd-operator定义etcd组件类型,更精细化的支持部署etcd集群。比如基于rds operator类型,直接支持快捷创建RDS组件实例接入Rainbond平台。

Rainbond-operator支持两种安装模式,默认版本中提供一套UI辅助用户配置参数和观察集群初始化进度。在Rainbond Cloud中支持从控制台基础操作即可完成将已有的Kubernetes集群初始化完成成为Rainbond集群。

安装过程

2. 企业共享组件库,助力构建企业中台

共享组件库是企业内部复用模块、应用、解决方案的核心。Rainbond定义了一种应用模型规范(RAM),同时支持任意部署到Rainbond的组件一键发布成应用模型,并支持版本管理、分类管理、交付管理等。以共享组件库企业可以开发环境快速复制,测试环境快速安装,生产环境标准交付,优秀方案企业共享。共享组件库包括应用的组装发布、应用版本存储、离线导出和导入、云端同步共享等特性。

谈到应用模版,这里必须得提Helm,Helm是一个优秀的Kubernetes应用打包工具,支持厂商多从而形成了Helm应用生态。然而遗憾的是helm打包的应用没有规范(Kubernetes用法各样),这也是为什么Rainbond一直不支持Helm应用的直接安装的原因。对于广大软件生产企业来说,定义Helm应用模版也是一件复杂的事情。Rainbond在应用发布、应用共享、应用安装方面提供全流程管理,缺陷的就是RAM不是被社区公认的规范,这条路已经有了解决方案。OAM应用规范应运而生,Rainbond将在后续的版本中逐步将RAM替换为OAM规范,从而实现Rainbond生产的应用可以交付到各类云环境。

共享组件库

3. 存储体系重构

Rainbond组件存储在V5.1及以前版本中支持类型较为单一,仅支持全局共享存储类型。这是一种基于NAS/NFS为基础的文件系统共享存储模式。这样一方面不能很好的匹配Kubernetes已有的存储生态,二来在性能要求较高的场景中支持不足。在V5.2版本中Rainbond全面接入Kubernetes存储生态,基于Kubernetes Storage Class资源扩充更多的Rainbond存储类型,同时重新实现原有的全局共享存储类型,不再依赖宿主机提前挂载NFS,使得Rainbond在存储扩充上不再依赖对集群宿主机的操作。用户可以根据自身环境已有资源合理选择存储类型接入。

存储选择

Rainbond Cloud 服务试运行上线

Rainbond Cloud 是Rainbond产品SaaS化在线服务平台,由好雨科技运营。Rainbond Cloud可以认为是Rainbond集群的托管服务,依托于IaaS厂商的计算资源,比如用户购买阿里云的托管Kubernetes集群,通过API对接到Rainbond Cloud,由Rainbond Cloud来管理用户的Kubernetes集群,并提供给用户多云应用管理体验。Rainbond Cloud有如下优势:

  • 完整的Rainbond功能,持续产品迭代和升级,需求不等待;

  • 多云资源管理,阿里云、AWS、华为云等IaaS厂商的资源,统一托管到Rainbond Cloud,你只需要管应用,应用可以透明在多云上备份和迁移,不被IaaS厂商绑定;

  • 便捷的云资源对接,仅需30分钟即可完成集群从计划到投产;

  • 服务安全可靠,用户所有代码、应用、数据、流量都由用户自己掌控。Rainbond Cloud只是管理和调度服务,即使Rainbond Cloud故障不影响用户业务;

  • 帮助用户实现云原生DevOps、企业中台、企业应用交付等流程和体验;

  • SLA保障;

现在注册,免费使用 快速前往

下一步计划

  • 完善企业应用交付流程。

  • 支持更多IaaS资源对接,让用户更方便的利用公有云资源。

  • 引入OAM规范,支持更多的应用类型。

常见 FAQ

  • Rainbond是什么项目

    Rainbond 是以企业云原生应用开发、架构、运维、共享、交付为核心的Kubernetes多云赋能平台, 向下结合Kubernetes云原生资源管理模式,对接管理各类基础设施,通过多维度的软件定义屏蔽了底层资源的差异,甚至包括CPU架构差异和操作系统差异,从而对上层提供以应用为中心的基础设施; 向上定义了标准应用模型(RAM,OAM),内置ServiceMesh微服务架构框架, 提供用户基于源码/已有镜像构建服务组件的能力,编排服务组件的能力,发布共享完整应用模型的能力,交付运维业务应用的能力。

  • Rainbond与Rancher项目有什么不同?

    Rancher,Kubernetes生态中成功的开源项目,其定位“Run Kubernetes Everywhere”,Rancher可以帮助我们快速搭建Kubernetes集群并提供集群资源很好的管理体系。Rainbond定位“企业应用全生命周期管理“,可以这么认为Rainbond在Rancher之上的维度,用Rancher更好的管理Kubernetes,用Rainbond更好、更方便的使用Kubernets。因此Rainbond与Rancher甚至可以并存,各司其职。

  • Rainbond的发展方向是?

    Rainbond的目标是建立一套完整的应用管理生态体系,未来Kubernetes就像现在的虚拟机一样成为基础设施的单元,从数据中心到云端到边缘,Rainbond帮助企业完成应用开发和交付到任意区域,不用再关心Kubernetes基础设施。

  • Rainbond 有在线托管服务版本吗?

    从现在开始,有了,伴随着5.2版本发布,Rainbond Cloud服务试运行上线,这可能是你最快体验Rainbond的方式。

GigaOm市场报告全球第一的K8S存储平台Portworx发布Essentials免费版本

Portworx阅读(3061)评论(0)

GigaOm市场报告全球第一的K8S存储平台Portworx发布Essentials免费版本!

GigaOm最新发布了Kubernetes数据存储平台的市场报告:Portworx被评为全球第一的数据存储平台。

报告链接:

https://ask.portworx.com/portworx-number-one-data-storage-platform-kubernetes-report/?utm_medium=website&utm_source=blog&utm_campaign=2020%20GigaOm%20Radar%20Report

Portworx近期发布了最新的产品版本Portworx Essentials,Essentials版本为K8S存储平台的用户提供了更多的选择。

Portworx Essentials版本覆盖了在K8S生产系统上运行有状态应用(如数据库)的所有必要功能。Portworx的所有功能都是为了K8S的生产系统服务的。但在用户环境中,并不是所有的K8S系统都需要100甚至1000个节点,至少现阶段不是这样。这也是Portworx Essentials版本推出的原因。

如果用户需要企业级、关键性应用的平台,且能够同时支撑多个应用,具备强有力的安全和数据保护机制,用户可以选择使用Portworx Enterprise版本。

如果用户正在部署一个小型的应用生产环境,Portworx Essential版本则是能够快速开始部署,并为后续的扩容打好基础的最佳选择。为了让用户快速的在Kubernetes环境里使用Portworx,Portworx Essentials向用户免费提供。用户可以快速注册并创建第一个集群。

Portworx Essentials完整的功能列表请访问:https://ask.portworx.com/essentials/?utm_medium=website&utm_source=blog&utm_campaign=Essentials

打造企业级pipeline服务的18个疑问

JFrog捷蛙阅读(3015)评论(0)

Jenkins已经成为大量公司最常用的一种持续集成工具了,但是目前pipeline的普及程度可能依然低于30%,大量的团队依然使用自由风格这种笨重的方式,给统一构建过程、构建集中管理带来极大的不便。笔者通过下面的18个问题来讲解一下为什么企业级持续集成服务需要使用pipeline的构建方式。

一、Jenkins2.0的最大改变是什么?

很多人认为jenkins2.0的最大改变是增加了pipeline,实际上pipeline在Jenkins1.0中已经有了这个概念,而jenkins2.0中最大的改变应该是pipeline as code,即以代码的方式描述pipeline。

二、Pipeline由谁来编写,由谁维护?pipeline统一管理的优势?

由于pipeline编写需要代码能力 ,并且pipeline的中执行步骤直接影响了最后构建产物的质量,所以建议pipeline需要由持续集成服务部门统一编写、统一管理。此持续集成服务部门可以由工程效能团队、测试团队、ci团队等兼任。编写好的pipeline需要标记模版的使用方法和作用,需要相关的文档或者json串记录模版的这些属性,那么业务部门就可以自助的使用这些模版 ,并在无形之间执行了我们在模版中设置的一些质量扫描测试的工作,并收集回了整个软件生命周期的元数据,用于我们对业务的质量进行评判。

三、Pipeline最佳管理方式?

由统一的持续集成服务部门编写pipeline的模版和所需的类库,将这些模版和类库存放到gitlab等源码仓库中统一进行版本控制管理。并将源码地址配置到jenkins的Share Library的功能中,业务开发人员如需Jenkins进行构建,只需传递自己所需的参数,调用持续集成服务部门已经写好的library,就可以自行设置构建任务了。

Git仓库保存流水线模版:

Pipeline中引用模版:

四、脚本式pipeline和声明式pipeline如何选择?

声明式pipeline比较简单,也是Blue Ocean支持的语法格式,但此种pipeline在jenkins2.5之后才支持,成熟度有待发展,是官方推荐的方式。

Jenkins2.0最早支持 的pipeline,如果对Groovy语法很熟悉,可选择脚本式pipeline,可以实现更复杂的逻辑。

五、不会pipeline的语法怎么办?

Jenkins2.0中提供了流水线语法查询的功能,可以自动生成流水线代码片断,直接拷贝粘贴就可以

六、Pipeline中要涉及的基础工具链包括哪些?

Pipeline一般的应用是来做集成构建的,也就是把源码打包成制品,所以pipeline中涉及的最基础的工具一定是源码仓库和制品仓库,以及构建过程中使用的每种语言的打包工具。

源码仓库:用于管理源代码,常用gitlab、github、svn等

制品仓库:用于管理制品,常用Artifactory。

打包工具:如mvn、go、npm、docker等

七、Pipeline中涉及到的进阶工具链?

Jira:关联需求信息

Sonarqube:代码静态扫描

Xray:制品漏洞扫描

JMeter:性能测试

Junit:单元测试

JaCoCo:代码覆盖率

Ansible,saltstack:发布

八、Pipeline中需要设置的质量关卡包括什么?

质量关卡,即构建过程中的质量门,为确保每一个版本都能高质量发布,建议将以下指标与部署包关联,作为整个pipeline构建过程的质量关卡,如果有未达到的情况,记录并处理。关卡包括:

代码静态扫描的issue数量

80%以上的单元测试覆盖率

漏洞扫描的结果

开源许可证扫描

不同环境是否具备不可变基础设施

集成测试是否通过

性能测试结果

较高的接口测试覆盖率

九、什么是一次构建,多次部署?如何在pipeline中实践?

DevOps成熟度标准中建议做到一次构建,多次部署。目的是为了在测试环境测过的包可以在不改变任何环境和依赖的情况下发布到生产线上。发布时重新打包往往会因为源码版本变更、基础环境变更等因素导致发布事故。

最佳实践是使用制品提升仓库级别的方案,使用Artifactory可以用起promotion的属性进行制品提级。

十、如何在pipeline中设置构建参数?

Jenkins支持参数化构建,包括凭据参数、字符参数、密码参数、布尔值参数、文件参数、文本参数、运行时参数、选项参数等。在pipeline中设置方法可以直接在片断生成器中生成。(语法获取可以使用片段生成器,搜properties)

十一、如何在pipeline中进行并行构建任务?

Jenkins pipeline支持并行构建任务,解决多个环境进行构建,或多个环境进行发布的场景。使用串行十分影响效率,采用并行方式,通常是将命令下发给不同的agent,节省构建时间。(语法获取可以使用片段生成器,搜parallel)

十二、如何在pipeline中优雅的使用密文?

Pipeline中经常涉及到这样一种场景,需要调用其他系统的api,难免会使用到一些key或者密码 ,但是这些信息直接明文写到pipeline中非常不优雅,并且存在很大的安全隐患,所以在我们不希望展示这些key的场景下,可以使用Jenkins的凭证特性,解决这种问题 。(语法获取可以使用片段生成器,搜withCredentials)

十三、如何在pipeline中设置定时启动job?

某些特定场景下,如每天凌晨需要对项目进行一次clean的全量构建,占用的时间和资源较多,我们可以使用Jenkins的构建触发器功能触发定时任务进行构建。(语法获取可以使用片段生成器,搜properties)

十四、如何在pipeline中设置通过轮询代码仓库启动job?

此触发方式使用的较少,最佳实践以webhook的方式触发构建更方便,但是在少量特殊场景,如每天需要构建,但是版本不发生变化时不构建可以应用此触发器

十五、如何在pipeline中设置通过其他job完成触发启动job?

在集成测试的时候需要大量的此类操作,公共组件构建了最新的版本要同时触发所有依赖他的构建项目进行构建,确保此版本能正常被业务应用使用。

十六、如何在pipeline中设置通过git的webhook触发启动job?

通过Git的钩子(webhook)功能触发Jenkins构建任务,这种构建模式比较常见,DevOps成熟度标准中也把这一条当作三级评估的准则,是否每一次提交代码都能触发完整的构建过程,决定了我们持续集成的速度和效率。

十七、如何将pipeline与流程审批系统对接?

为实现需要人工校验是否继续进行后续流程,对接审批流程等操作,Jenkins支持了构建等待的功能,可以在构建过程中暂停任务,等待下一步信号。(语法获取可以使用片段生成器,搜input)

十八、什么情况下需要使用多分支pipeline?

在实际的项目中,往往需要多分支同时进行开发,如果每一个分支都创建一个jenkins项目 ,管理起来非常不方便。这种场景下需要使用多分支pipeline。常使用when参数来判断分支。

更多精彩内容可以专注我们的在线课堂

微信搜索公众号:jfrogchina 获取课程通知

Prometheus扩展遇到的挑战

yuangeqingtian阅读(4498)评论(0)

本文将会涵盖使用Prometheus扩展中遇到的大部分问题。

Prometheus是云原生环境的支柱之一,创建了名为Prometheus监控之后,成为了实际的K8S环境的可视化标准。Prometheus和K8S关联紧密,经历了各个开发阶段,一路走来,从理念到生产环境一路相辅相成。

Prometheus第一阶段

通常,在开发阶段Prometheus就和第一个K8S集群一起合作了。部署了一些app之后,你可能发现你需要监控集群内部的信息,但是老的基于宿主机的工具不能工作。精疲力尽地调查之后,你发现了Prometheus。

部署了K8S集群之后,Prometheus和Grafana,再加上一些基础的导出工具,你需要的数据就到手了,可以开始构建仪表盘和告警了。

随着你对Prometheus的了解深入之后,它出色的特性也随之出现:

 

Service discovery机制让配置工作更简单

开源社区提供的数以百计的数据导出工具

仪表盘相关的library可以自定义应用的监控指标

背靠云原生基金会的大树,继K8S之后,第二个毕业的项目,而且是OSS

K8S已经仪表盘化了而且把Prometheus的参数暴漏给它的服务了

 

目前的阶段,一切顺利。K8S是你最好的朋友,你的应用顺利扩展,在fashion的仪表盘上,你可以查看大量信息。让我们开启下一步的工作吧!

让我们转移到生产环境

你的第二个K8S集群构建好了,你遵循相同的流程,部署Prometheus,导出工具,grafana。Staging阶段的集群通常比开发环境的要更大,但是Prometheus可以轻松应对。现在K8S集群上的应用并不多,仪表盘和用户的数量也不多,迁移工作相对简单。

第一个问题出现了,现在部署了两套不同的Grafana,观察开发环境和staging环境的参数需要在两套grafana中切换。目前的阶段,只是小问题,开发者并不会太担心。所有的东西都检查完毕,准备投放到生产环境了。

 

 

 

现在,遵循相同的流程,部署Prometheus,导出工具,Grafana,迁移dashboard和用户,你的第三套集群创建完毕。用户虽然并不很满意同时有三套监控网站,但是这并不能阻止你前进的步伐。

 

迁移应用到K8S的反馈很好,公司决定前期更多的应用到K8S。新的用户,配置,dashboard和告警需要一个一个地添加到每个集群中。管理配置文件开始需要更多地精力和时间。

应用快速增长带来了新的需求,不同应用需要更多地集群来服务不同区域增加可用性。每个集群使用不同的Prometheus和Grafana实例,环境太复杂,DevOps和开发小组开始抱怨。

保持全局的可见性

分布式的模型带来了不同的挑战:

 

并不支持全局的可视性,一些生产集群会把它当成新的需求

操作会很笨重而且花费大量时间

模型会复杂化管理和监督工作

 

为了访问不同的K8S集群,中心化的可视化工具可以在一个dashboard里观看并且关联跨越多个集群的服务信息。

乍一看,这可能很简单,我部署一个中心化的Grafana,添加不同集群上的Prometheus作为数据源。

 

但是,这里有隐藏的挑战

Prometheus并不提供安全的特性。如果Prometheus和Grafana通信在集群内部还好说,如果Grafana在集群之外,你需要在Prometheus上限制连接和访问数据。应对此问题有很多解决方案,但是管理证书,创建ingress controller,Grafana配置安全信息等等工作,需要花费更多的时间和精力。

如果集群是动态变化的,那么在部署Prometheus到集群的时候,最好实现自动化添加数

据源到Grafana的功能。

一个dashboard可以提供不同的数据源用于展示,但是我们还是不能跨越不同集群来检索服务。

数据访问的控制更重要了,RBAC的系统可能会需要。大概率会需要集成身份验证系统来

保持用户信息实时更新。

所有的这些问题都有解决方案,但是需要付出架构设计,开发,实施的努力。这一套架的维护也需要花费大量资源。

 

Prometheus水平扩展

努力工作之后,你现在有一个很好的中心化的系统,一切都很美好。开发者认识到自定义监控参数的好处,编写代码来获得。你的组织开始扩张,K8S里的服务数量增加,参数用途扩大。集群开始扩容,服务有了更多的复制品。

与此同时,你的Prometheus服务器开始死亡,troubleshooting之后,你发现问题在内存上。Prometheus上的内存使用和存储数据的时间段直接相关,随着存储数据时间段不断增加,内存开始溢出。提高资源配额不能永久解决问题,总会到达节点机器的内存顶点。百万参数的Prometheus可以占用超过100G的内存资源,可能会影响K8S集群。你必须要扩容来增加资源,但是Prometheus并不是设计来水平扩展地。一旦垂直扩展的上限达到,万事休矣。

 

对此问题,有一些解决方案,比如对不同地数据记录在几台Prometheus服务器上做分区,但是这比较复杂,实施和troubleshooting起来都很困难。

 

让我们尝试长期存储解决方案

许多人都曾面对这个问题。Prometheus声称它并不是一个数据记录存储,那么有些人最终为Prometheus指标创建了长期存储方案。

目前有一些开源社区地项目提供长期存储:Cortex, Thanos,M3 .

这些服务也很复杂,而且:

 

架构复杂,需要大量精力部署,优化,维护监控自启动服务

操作成本高,你可以使用DynamoDB等数据库,但是依然需要扩展其他的监控服务,而且数据吞 吐量会很高。

这些项目还在早期地开发阶段,即使有专职小组来负责,生产环境中运行仍然有风险。

 

What’s  Next?

Prometheus是云原生地应用监控领域地变革者,一如K8S对于容器编排。然而,即使是大型科技公司在Prometheus扩展上大费脑筋。每一个全职维护Prometheus地开发者都是业务部门地损失。

探索新的领域确实让人兴奋,但是有时候可以付费来直接购买好的服务。

为了解决消费者遇到地问题,Sysdig公司一直在提升自己的服务,我们希望兼容所有的Prometheus同时提升我们地扩展能力来保持百万级别地时间段数据。使用Sysdig产品,你可以体验安全可扩展地Prometheus解决方案.

kubernetes-Prometheus基于邮件告警

Daniel_Ji阅读(8937)评论(0)

1、告警逻辑框架

Prometheus的告警逻辑框架:

1)指标获取:Prometheus从监控目标中获取指标数据;

2)设置规则:运维人员根据运维管理需要,设置告警规则(rule_files);

3)推送告警:在Pometheus中指定指定告警规则,并设置告警服务器(prometheus.yml),当发生符合告警的规则时,Prometheus就会将告警信息发送给设置的告警服务器;

4)发送告警:在告警服务器中,设置告警路由和告警接收,告警服务器将会根据告警管理配置将告警信息发送给告警接收器(email等);

5)处理告警:运维人员接收到告警信息后,对告警信息进行处理,保证被监控对象的正常运行。

2、指定告警服务和规则文件

告诉Promentheus,将告警信息发送给那个告警管理服务,以及使用那个告警规则文件。这里的告警服务在Kubernetes中部署,对外提供的服务名称为alertmanager,端口为9093。告警规则文件为“/etc/prometheus/rules/”目录下的所有规则文件

global:
 scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
 evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
 # scrape_timeout is set to the global default (10s).

# 指定告警服务器
alerting:
 alertmanagers:
 - static_configs:
 - targets:
 - alertmanager:9093

# 指定告警规则文件
rule_files:
 - "/etc/prometheus/rules/*.yml"
 # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
 # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
 - job_name: 'prometheus'

# metrics_path defaults to '/metrics'
 # scheme defaults to 'http'.

static_configs:
 - targets: ['localhost:9090']
 - job_name: 'redis'
 static_configs:
 - targets: ['redis-exporter-np:9121']
 - job_name: 'node'
 static_configs:
 - targets: ['prometheus-prometheus-node-exporter:9100']
 - job_name: 'windows-node-001'
 static_configs:
 - targets: ['10.0.32.148:9182']
 - job_name: 'windows-node-002'
 static_configs:
 - targets: ['10.0.34.4:9182']
 - job_name: 'rabbit'
 static_configs:
 - targets: ['prom-rabbit-prometheus-rabbitmq-exporter:9419']

3、设置告警规则

设置告警的规则,Prometheus基于此告警规则,将告警信息发送给告警服务。这将未启动的实例信息发送给告警服务,告知哪些实例没有正常启动。

#rules
groups:
 - name: node-rules
 rules:
 - alert: InstanceDown # 告警名称
   expr: up == 0 # 告警判定条件
   for: 3s # 持续多久后,才发送
   labels: # 标签
    team: k8s
   annotations: # 警报信息
    summary: "{{$labels.instance}}: has been down"
    description: "{{$labels.instance}}: job {{$labels.job}} has been down "

4、设置告警信息路由和接受器

这里设置通过邮件接收告警信息,当告警服务接收到告警信息后,会通过邮件将告警信息发送给被告知者。

global:
 resolve_timeout: 5m
 smtp_smarthost: 'smtp.163.com:25' # 发送信息邮箱的smtp服务器代理
 smtp_from: 'xxx@163.com' # 发送信息的邮箱名称
 smtp_auth_username: 'xxx' # 邮箱的用户名
 smtp_auth_password: 'SYNUNQBZMIWUQXGZ' # 邮箱的密码或授权码

route:
 group_by: ['alertname']
 group_wait: 10s
 group_interval: 10s
 repeat_interval: 1h
 receiver: 'email'
receivers:
 - name: 'email'
 email_configs:
 - to: 'xxxxxx@aliyun.com' # 接收告警的邮箱
 headers: { Subject: "[WARN] 报警邮件"} # 接收邮件的标题

inhibit_rules:
 - source_match:
 severity: 'critical'
 target_match:
 severity: 'warning'
 equal: ['alertname', 'dev', 'instance']

5、验证

在方案中Prometheus所监控的实例中,redis和windows-node-002没有正常启动,因此根据上述的告警规则,应该会将这些信息发送给被告警者的邮箱。

在被告警者的邮箱中,接收的告警信息如下。

 

作者简介:

本文版权归(微博:ik8s)拥有者所有。

咨询合作微博:ik8s

工欲善其事,必先利其器——DevOps中如何管理工具包

JFrog捷蛙阅读(2621)评论(0)

一、背景

作为DevOps交付流水线的开发者,为支持CI/CD中各项任务的自动化,都需要依赖多种包管理工具来下载各种相关的工具,比如针对产生最终交付件的构建过程,就需要在构建流程的第一步,自动地把相关工具,如Curl、wget、Maven、Gradle、npm等等,下载到CI服务器。这些工具的下载,通常都需要依靠对应的公网服务器和包管理工具来支持。而这样通过公网来下载工具,有时会遇到稳定性的问题,也就是所谓的环境问题,导致工具下载失败,进而导致构建任务的失败。因此,我们需要引入新的技术来克服这些问题,保证工具包下载的稳定和可靠。

二、工具包管理的痛点——缺乏稳定性

通常,我们会使用各种各样的包管理工具来帮助我们下载和管理这些工具包,如Windows上的Chocolatey,Mac/Linux上的Homebrew,还有npm、Yum、Debian、Docker等等。可是,有时我们通过这些包管理工具来下载工具包时,会碰到意外的5xx服务器错误。而更多的时候,通过这些包管理工具来下载会非常的慢。这些问题在我们使用自动化构建工具(如Travis CI、Jenkins、Gitlab CI,等等)来实现持续集成CI的时候,会被成千上百倍地放大。一种解决办法就是在碰到这些环境问题时,通过手动运行构建的方式进行补救,当然,这只是指标不治本。同时,在网络访问有限制的时候,如很多金融企业都会采用的网络隔离,根本不可能去下载这些公网服务器上的工具包。

三、解决方案——使用JFrog Artifactory的远程仓库

JFrog Artifactory作为全语言制品仓库,其远程仓库可以作为公网服务器的本地代理和缓存。当我们通过其远程仓库来下载所需的工具包时,Artifactory首先检查在本地的缓存中是否已经存在。如果有,直接返回该工具包;如果没有,Artifactory将会代理到公网服务器去下载相应的工具包,并缓存到本地,以供后续的下载使用。
利用Artifactory的远程仓库作为下载前述工具包的代理和缓存,能够使得DevOps流程中的各个环节,如前面描述的持续集成流程,更加的迅速和稳定。在有网络隔离要求的环境中,如金融企业的研发/生产环境,Artifactory可以帮助技术人员建立自己的企业级单一可信源。
下面,我们将通过示例为大家一一展示,Artifactory的远程仓库是如何为不同种类的工具包提供服务的。

四、示例一——Chocolatey

当使用Choco为Windows系统下载Gradle的时候,我们经常会碰到类似下面这样的503错误,从而导致构建失败:
 
解决的方法:我们在Artifactory里定义一个Nuget类型的远程仓库,利用它作为通过Choco包管理工具下载的来源。
第一步:配置Artifactory远程仓库
在Artifactory里创建一个Nuget类型的远程仓库,其主要参数如下:
· 仓库名:choco
第二步:安装Choco包
· 用匿名安装的命令
choco install <package-name> -s <artifactory-url>/api/nuget/choco
· 使用带用户认证的方式
choco install <package-name> -s <artifactory-url>/api/nuget/choco
-u <artifactory-user> -p <artifactory-password>

五、示例二——Homebrew

和Chocolatey类似,也可以用Artifactory来支持Brew的下载:
第一步:配置Artifactory远程仓库
在Artifactory里创建通用(Generic)类型的远程仓库:
· 仓库名:homebrew
第二步:设置“HOMEBREW_ARTIFACT_DOMAIN”环境变量
· 匿名访问:
set HOMEBREW_ARTIFACT_DOMAIN=<artifactory-url>/homebrew
· 带用户认证的访问:
set HOMEBREW_ARTIFACT_DOMAIN=<artifactory-user>:<artifactory-password>@<artifactory-url>/homebrew
第三步:安装
之后再通过 brew install命令安装,就会访问Artifactory的本地缓存了。

六、示例三——Yum

本节将介绍如何利用Artifactory的远程仓库来使用Yum下载RPM包。
第一步:配置Artifactory远程仓库
在Artifactory里创建一个RPM类型的远程仓库:
· 仓库名:yum
· Url:http://mirror.centos.org/centos/<version>/os/<architecture>
o 例如:http://mirror.centos.org/centos/7.6.1810/os/x86_64
第二步:创建yum的配置
创建下述文件:/etc/yum.repos.d/artifactory
· 匿名访问时,文件内容为:
[artifactory]HERE name=artifactory
baseurl=https://<artifactory-url>/yum
enabled=1 gpgcheck=0
· 带用户认证时,文件内容为:
[artifactory] name=artifactory
baseurl=https://<artifactory-user:<artifactory-password>@<artifactory-url>/yum
enabled=1 gpgcheck=0
之后正常使用yum命令就可以从Artifactory的本地缓存下载RPM包了。

七、示例四——Docker

本节将介绍如何利用Docker命令从Artifactory的远程仓库来下载Docker镜像。
第一步:配置Artifactory远程仓库
在Artifactory里创建Docker类型的远程仓库:
· 仓库名:docker
第二步:登录
用下述命令登录Artifactory的Docker仓库:
Docker login <your docker domain>
其中<your docker domain>的写法可以参考Artifactory中docker仓库对应的”Set Me Up”显示的设置。
第三步,拉取镜像
执行下述命令,从Artifactory的缓存拉取Docker镜像:
docker pull <your docker domain>/<docker image>:<docker tag>
当然,针对Docker应用,你可以使用JFrog提供的免费版镜像中心——JCR(JFrog Container Registry,https://jfrog.com/container-registry/),来管理自己的Docker镜像。

八、总结

在DevOps流程当中,我们需要下载很多工具包,来支持整个流程的自动化运转。然而。直接从外网下载这些工具包,经常会碰到环境问题,进而影响整个DevOps流程的效率和可靠性。
Artifactory通过其远程仓库的设置和全语言制品支持的能力,能够帮助我们建立各种工具包的本地源,从而使得DevOps的流程更加迅速和稳定。本文还列出了几种典型类型工具包的配置方法。
更多精彩内容可以专注我们的在线课堂
微信搜索公众号:jfrogchina 获取课程通知

kubernetes-基于Prometheus和Grafana监控rabbitmq(rabbitmq-exporter)

Daniel_Ji阅读(12094)评论(0)

1、安装和配置rabbitmq-exporter

1.1 使用helm安装rabbitmq-exporter

这里的rabbitmq-exporter通过helm在Kubernetes中进行安装,这里需要通过rabbitmq.url,rabbitmq.user和rabbitmq.password,设置正确的rabbitmq的url地址和用户/密码。

$ helm install prom-rabbit stable/prometheus-rabbitmq-exporter --set "rabbitmq.url=http://rabbit-service:15672" 
/ --set "rabbitmq.user=user" --s set "rabbitmq.password=bitnami" --namespace=kube-public

rabbitmq-exporter具体配置信息请参考下表:

Parameter Description Default
replicaCount desired number of prometheus-rabbitmq-exporter pods 1
image.repository prometheus-rabbitmq-exporter image repository kbudde/rabbitmq-exporter
image.tag prometheus-rabbitmq-exporter image tag v0.29.0
image.pullPolicy image pull policy IfNotPresent
service.type desired service type ClusterIP
service.internalport service listening port 9419
service.externalPort public service port 9419
resources cpu/memory resource requests/limits {}
loglevel exporter log level {}
rabbitmq.url rabbitmq management url http://myrabbit:15672
rabbitmq.user rabbitmq user login guest
rabbitmq.password rabbitmq password login guest
rabbitmq.existingPasswordSecret existing secret name containing password key ~
rabbitmq.capabilities comma-separated list of capabilities supported by the RabbitMQ server bert,no_sort
rabbitmq.include_queues regex queue filter. just matching names are exported .*
rabbitmq.skip_queues regex, matching queue names are not exported ^$
rabbitmq.include_vhost regex vhost filter. Only queues in matching vhosts are exported .*
rabbitmq.skip_vhost regex, matching vhost names are not exported. First performs include_vhost, then skip_vhost ^$
rabbitmq.skip_verify true/0 will ignore certificate errors of the management plugin false
rabbitmq.exporters List of enabled modules. Just “connections” is not enabled by default exchange,node,overview,queue
rabbitmq.output_format Log ouput format. TTY and JSON are suported TTY
rabbitmq.timeout timeout in seconds for retrieving data from management plugin 30
rabbitmq.max_queues max number of queues before we drop metrics (disabled if set to 0) 0
annotations pod annotations for easier discovery {}
prometheus.monitor.enabled Set this to true to create ServiceMonitor for Prometheus operator false
prometheus.monitor.additionalLabels Additional labels that can be used so ServiceMonitor will be discovered by Prometheus {}
prometheus.monitor.interval Interval at which Prometheus Operator scrapes exporter 15s
prometheus.monitor.namespace Selector to select which namespaces the Endpoints objects are discovered from. []

1.2 查看rabbitmq指标数据

在浏览器中访问rabbitmq-exporter,能够看到所要监控的指标。

 

2、Prometheus监控

2.1 配置Prometheus

在Prometheus的配置文件(Prometheus.yaml)中,添加红色字体部分的内容。

global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
alertmanagers:
– static_configs:
– targets:
# – alertmanager:9093

# Load rules once and periodically evaluate them according to the global ‘evaluation_interval’.
rule_files:
# – “first_rules.yml”
# – “second_rules.yml”

# A scrape configuration containing exactly one endpoint to scrape:
# Here it’s Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
– job_name: ‘prometheus’

# metrics_path defaults to ‘/metrics’
# scheme defaults to ‘http’.

static_configs:
– targets: [‘localhost:9090’]

# 配置从redis-exporter中获取数据,目标地址为:10.0.32.148:9182

 – job_name: ‘rabbit’
static_configs:
– targets: [‘prom-rabbit-prometheus-rabbitmq-exporter:9419’]

2.2 配置验证

在浏览器的地址栏访问http://{prometheus}/targets,将会看到新配置的rabbitmq。

 

3 Grafana监控

3.1 配置Windows监控dashboard

下载rabbitmq-exporter的dashboard(rabbitmq-monitoring_rev4.json),下载地址:https://grafana.com/grafana/dashboards/4279

 

在grafana中导入dashboard:rabbitmq-monitoring_rev4.json。

 

导入后,通过此dashborad,管理员就可以监控rabbitmq的运行状态、内存、磁盘空间、消息队列和消息状态等指标。

 

作者简介:

季向远,北京神舟航天软件技术有限公司。本文版权归原作者所有。微博:ik8s

通过Portworx在AWS上运行高可用SQL Server容器

Portworx阅读(2123)评论(0)

通过Portworx云原生存储,在Amazon EKS里运行高可用SQL Server容器

在本文我们将分析,如何使用Amazon Elastic Container Service for Kubernetes (Amazon EKS, https://amazonaws-china.com/eks/),来在容器中部署Microsoft SQL Server。文中讨论的方式和与原理,也适用于其他需要高可用和持久性、并符合可复用的DevOps方式的有状态应用。例如运行MongoDB、Apache Cassandra、MySQL、或者大数据处理等。

首先能够被支持在容器中运行的是SQL Server 2017版本。我们可以在Linux容器中,使用Kubernetes (https://amazonaws-china.com/kubernetes/)来运行SQL Server生产负载。

Microsoft SQL Server是被广泛使用的数据库。SQL Server提供一系列很不错的功能,也有很不错的开发者社区。但是它需要比较多的运维,也比开源的或者云端的数据库成本要更高。很多为了降低成本的用户会转向开源方案来降低软件授权的成本。另一些用户会迁移工作负载到关系数据库管理系统(RDBMS)服务里,比如Amazon RDS for Microsoft SQL Server或者Amazon Aurora。

但也有许多情况,用户无法离开SQL Server。这有很多可能的原因,比如需要重新部署和开发的成本,以及需要配置具备相关技能的开发工程师和运维工程师资源的成本等。用户可能无法使用云服务,可能是软件授权和支持的问题,或者一些技术问题。

在这样的情况下,可以通过把SQL Server数据库部署到Amazon Elastic Compute Cloud (Amazon EC2, https://amazonaws-china.com/ec2/)实例上,来使用云服务。这种方式保持了需要满足特定需要的灵活性,也提供了云的各种好处。这些好处包括对于物理硬件层的抽象,以及按需付费的模式,以及其他的云端服务能力。虽然这种方式比本地部署SQL Server要更有优势,但管理额外的数据库实例的管理成本仍然有可提升的空间。

使用Kubernetes来运行SQL Server会有更多优势:

  • 简化:在容器中部署和运维SQL Server会很简单和快捷,比起传统的部署模式会大幅降低工作量。这是因为部署不需要安装,而是通过上载新的镜像来完成。容器提供了一个可以任何环境运行的抽象层。
  • 更优化的资源使用:容器化的SQL Server提供了高密度,允许内部负载共享一个通用的资源池(内存、CPU、存储)。因此减少了闲置的资源,增加了基础架构资源的利用率。
  • 降低软件授权的成本:在容器中运行SQL Server的一些场景,不论是高密度还是低密度,都会降低软件授权的成本。我们会在本文后面详细介绍软件授权的成本。
容器服务

目前,AWS里有四种容器服务:

  • Amazon      Elastic Container Service (Amazon ECS,https://amazonaws-china.com/ecs/):一个高度可扩展的,高性能的调度服务,与AWS的多项服务原生集成。
  • Amazon Elastic Container Service for Kubernetes (Amazon EKS):一个AWS提供的管理服务,可以方便的使用Kubernetes部署、管理和扩展容器应用。
  • AWS      Fargate (https://amazonaws-china.com/fargate/):一个Amazon ECS的计算引擎,可以帮助用户在不需要管理服务器/集群的情况下,来运行容器。
  • Amazon Elastic Container Registry (Amazon ECR,https://amazonaws-china.com/ecr/):一个完整的被管理的Docker容器注册表,便于用户来存储、管理和部署Docker容器镜像。

在AWS上作架构的一个重要原则是 Multi-AZ部署,来产生高可用的和高性能的负载。你可以直接使用Amazon Elastic Block Storage (Amazon EBS, https://amazonaws-china.com/ebs/) 卷作为SQL Server容器的存储解决方案,但这会限制这些容器只能在单一的可用区域内。Portworx可以用来解决这个问题。

Portworx是AWS全球的合作伙伴,也是微软的高可用和容灾方案合作伙伴。Portworx使得SQL Server能够以高可用的方式,跨多个AWS可用区域,作为EKS集群来运行。Portworx也可以配置成跨越AWS Auto Scaling Groups的高可用。当使用SQL Server实例的存储层的时候,这些功能确保了存储的可用性。存储的可用性是保证容器化SQL Sever实例高可用性所必须的。

这篇文章介绍了,如何使用Amazon EKS和Portworx云原生存储(基于Amazon EBS 卷)来在生产环境中运行SQL Server负载。我们也提供了一份样例脚本( https://github.com/awslabs/aws-eks-portworx-sql)  ,来自动地在几分钟内完成SQL Server实例的部署过程。

在容器中运行SQL Server的好处

使用容器最大的好处是简单和有效。不需要安装SQL Server或者配置容错集群。使用简单的命令就可以部署SQL Server容器,然后Kubernetes会提供SQL Server部署的高可用。在一些情况下,Kubernetes中部署的SQL Server的容器实例,可用性甚至高于那些部署在容错集群上的。后面“高可用性”部分我们会介绍更多细节。

在容器中运行SQL Server的主要好处来自于高密度部署和资源共享。容器和虚拟机(VMs)的根本性的不同是:在运行过程中,与虚拟机不同,容器并不是被限定到一系列固定的资源上的。一个共享的资源池经常被一组容器在同一个主机上共享来使用。这使得容器可以随时调整使用更多或者更少的资源。只要资源的总消耗不高于总资源池的资源容量,所有的容器都能有足够的资源来运行。

如图中所示,一个按照自身配置满负荷资源运行的VM,无法在使用主机上闲余的资源。在这个例子中,资源池有两台物理主机,包括8个CPU核。尽管有3个CPU核仍然闲余未被使用,VM4和VM7仍然在自身满资源的状态下运行,而无法扩展使用闲余的资源。

让我们来看一下能够更有效利用资源的另一种方式。假设存在一种情况,你不需要担心物理主机资源的数量。你只需部署一个满资源的VM来运行一组应用,比如一些SQL Server实例。假设你可以让你的应用共享所有资源,并且确保互相之间没有冲突。图右侧的部分就是这样的解决方案:使用Amazon EC2实例上的容器服务。

使用这种解决方案。没有容器存在资源限制,总体的CPU核资源从8个减少到了6个。对于内存资源来说也是一样的。容器化,可以增加底层架构的使用效率和有效性。这对于运行SQL Server这样的有峰值使用量的应用来说尤其合适。

另一个在容器中运行SQL Server的好处是可以减少软件授权的成本。SQL Server是一个商业产品,使用授权的限制会影响我们从技术角度的决策,或者可能大幅推高我们的商业成本。微软授权SQL Server在容器中使用的方式,会很大程度上缓解这些问题。在后续“SQL Server容器软件授权”部分有更多的细节。

Amazon EKS架构上的SQL Server

Kubernetes是一个开源软件,可以用来部署和管理可扩展的容器化应用。它是一个中心化管理的分布式系统,用来运行和调度容器。

当你手边已经有一个Kubernetes集群,使用和部署应用还是比较直接的。但是部署和运维一个Kubernetes集群本身还是比较复杂的。

Amazon EKS把复杂的Kubernetes集群的进行抽象。它提供一个完整的受管理的Kubernetes,用户可以调用AWS API进行部署和管理。作为响应,用户会收到一个上游Kubernetes api-server端点,这个端点允许用户连接到新的Kubernetes集群并使用。

SQL Server在每一个Pod (一组总是一起运行的容器)中,被部署为一个单独的容器。多个SQL Server的实例可以被部署为多个Pods。Kubernetes调度这些位于集群的节点上的Pods,确保有足够的资源来运行它们。

为了在Kubernetes上运行SQL Server,你需要创建一个Kubernetes部署。这个部署创建了一个属于该部署且可以被管理的复制集(ReplicaSet)。这个ReplicaSet确保包含一个单独SQL Server容器的一个单独的Pod,可以在集群上运行。当然,你也可以在同一个集群上部署SQL Server的多个实例来达到高密度。

存储的使用也进行了抽象化。对Kubernetes来说,持久卷(PV)是一个封装了存储解决方案实施细节的对象。这可能是Amazon EBS卷,一个网络五年间系统(NFS)共享,或者其他解决方案。PV的生命周期跟使用它的Pod的生命周期互相独立不相干。

要使用PV,另一个对象 – 持久卷声明(PVC, Persistent Volume Claim)需要被创建。PVC是一个使用请求,用来请求使用定义了大小和访问模式(读/写)的存储。一个PVC也可以定义存储类(Storage Class)的值。存储类是另一类抽象,允许用户定义存储解决方案的一些参数,比如延迟(latency)和IOPS。

管理员需要定义一个存储类,例如AWS标准目的GP2 EBS卷,或者Portworx高(中) I/O卷。管理员然后可以基于这个存储类来创建PV,或者允许用户基于PVCs来动态的创建PV。而后应用可以Include一个PVC,把PV分配给某个特定的pod。为了让这个过程更加简单,你可以定义一个默认的存储类。例如,假设一个Amazon EBS标准目的SSD (gp2)卷,被定义成Kubernetes集群上的默认存储类,即使一个PVC没有Include某一个特定的存储类注解,Kubernetes将会自动注解它到AWS GP2 EBS存储类上。

存储的选择

存储是SQL Server部署中的一个关键部分。在AWS上部署SQL Server最常用的存储方式是使用EBS卷。在Kubernetes集群中有两种存储类可以直接用来使用EBS卷。

  • Aws-gp2 (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) 提供了一个平衡成本和性能的解决方案。
  • Aws-io1 (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html),适用于需要稳定的IOPS和通道速度的生产环境负载。

你可以直接在EBS卷上存储SQL Server文件。然而,在许多情况下,一个单独的EBS卷并不能满足要求。例如,你也许需要在Multi – AZ架构下的高可用性,需要超出单独EBS卷限制的存储容量,或者需要单独卷无法达到的IOPS和通道速度。你可以尝试使用SQL Server Always On可用性组来解决高可用性问题,但是它无法解决存储容量、IOPS、和通道速度问题。同时针对SQL Server容器的Always On可用性组功能,目前也仅在SQL Server 2019是Preview发布。

你可以满足所有这些要求,包括高可用性、IOPS和通道速度,通过把几个EBS卷合并成存储池,在每一个EC2实例里Striping卷,并且把存储池延展到不同可用性区域的多个实例里。你可以部署一个独立的存储集群,并且通过NFS存储类在Kubernetes集群中使用该存储集群。但这些操作会增加一些管理复杂度。

Portworx云原生存储

Portworx是一个存储集群解决方案,可以在Kubernetes集群中服务应用和部署。Portworx是部署在Kubernetes之上的。Portworx使用Kubernetes来抽象化所有复杂的管理存储集群的操作。Portworx提供一个简单的存储类,可以被Kubernetes集群里的所有的有状态应用来使用。

在AWS里,Portworx通过对附加在Kubernetes集群(EC2实例)上的Worker Node上的EBS卷进行声明,来提供存储类。Portworx会把所有卷放进一个抽象的存储池里,然后从存储池里创建逻辑卷。当SQL Server的应用创建一个包括Portworx存储类的PVC,并且限定卷大小,一个包括具体大小的Portworx PV就被分配给了应用。

Portworx可以创建快照,称为3DSnaps。通过这个功能,你可以在SQL Server不停机的情况下,或者把SQL Server调成 read-only模式的情况下,来创建SQL Server卷的连续快照。Portworx的另一个功能是可以导入已有的EBS卷到Portworx逻辑集群卷里。这使得负载的迁移变得很容易。通过Portworx,集群可以变得密度很高,意味着你可以在一个主机上运行更多的容器。针对Kubernetes的一般性建议是每个VM/100个Pods。Portworx有一些客户甚至可以在每个主机上运行200~300个Pod (https://portworx.com/architects-corner-aurea-beyond-limits-amazon-ebs-run-200-kubernetes-stateful-pods-per-host/)。

Portworx在EBS卷之上,使用自己最佳颗粒度的快照层。

Portworx快照的创建和存储都是实时的。这是因为Portworx的快照是re-direct-on-write快照,实际上,Portworx可以通过书签方式(bookmark)即时地创建一个卷的实时快照。因为实际上的存储块并没有被copy,不论作多少次快照,都没有由于写入带来的资源使用。你可以创建一个每15分钟一次的快照组,而不影响到任何使用性能。快照可以跨多个EBS卷,集群,并且以应用一致持续的状态。

Portworx也支持重新定义虚拟卷的尺寸。你可以使用这个功能,结合EBS弹性卷,动态的来扩大或者缩小存储,来避免由于过度部署带来的额外成本损失。Portworx快照并不消耗额外的空间,这是因为存储方式是redirect-on-write,包括一个B-tree–based的文件系统,这样Portworx可以保持追踪同一个块的不同版本的数据。因此,这些快照非常节省空间。

你可以使用Portworx云快照策略来自动上载所有的快照到Amazon Simple Storage Service (S3, https://amazonaws-china.com/s3/),并且删除本地的快照。这个功能帮助防止本地不断增加的快照来消耗EBS卷空间。Portworx也有一个本地快照保留策略,来帮助在本地保存一些特定的快照。这个策略可以基于每个卷,也可以在卷被创建或者卷被更新的时候动态的来配置。Amazon S3是一个对象存储服务,提供99.999999999百分比的可用性。被上载到S3的Portworx快照,包括实际的存储块,而不仅仅是书签。因此它提供了预防数据丢失的另一个保护层。

对本地的快照来说,恢复操作也是即时的,对于cloudsnaps (https://docs.portworx.com/cloud/backups.html) 来说,恢复操作也几乎是即时的,因为Portworx仅仅在Amazon S3中存储快照的不同部分。

关于性能和延迟,Portworx逻辑卷被每个Pod在本地访问。在后台,Portworx把block复制到其他可用性区域的其他worker node上。这样,当pod意外恢复到其他可用性区域后,可以快速的重新访问本地数据,继续运行。

Portworx有客户运行大规模数据库比如Cassandra和Elasticsearch (https://portworx.com/ge-mesosphere-dcos-portworx/),在AWS上成功运行上百T的数据。这些客户认可在EBS上运行Portworx带来的成本节省收益。需要了解更多Portworx的功能,可以访问Portworx的网站 (https://portworx.com/products/features/)。

以上我们解释了,你可以结合使用Amazon EKS和Portworx存储,作为一个运行SQL Server的可靠的并且灵活的解决方案。接下来,我们将描述把SQL Server部署到Amazon EKS上的具体步骤。你可以按照下面的说明,在自己的环境里快速部署并验证解决方案。

一些前置条件

本文描述的解决方案基于PowerShell脚本。可以是Windows PowerShell或者PowerShell Core。如果你希望在Windows 10或者Windows Server 2016来运行脚本,你可以使用自带的Windows PowerShell。你也可以在MacBook或者Linux机器上来运行这些脚本。首先你需要在你的目标设备上安装PowerShell Core (https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell?view=powershell-6)。另一种选择,Mac的用户可以使用ReadMe文件里的说明来部署一个本地的Docker容器,来包括所有这些前置条件。

这个脚本会调用在AWS Tools for PowerShell ( https://amazonaws-china.com/powershell/) 里的PowerShell cmdlets 。确保你的机器上安装了最新版本的 AWS Tools for Windows PowerShell (https://www.powershellgallery.com/packages/AWSPowerShell/3.3.343.0),或者AWS Tools for PowerShell Core (https://www.powershellgallery.com/packages/AWSPowerShell.NetCore/3.3.343.0)

这些脚本有时候需要AWS 命令行界面(AWS CLI)工具来调用Amazon EKS APIs。确保你安装了最新版本的AWS CLI (https://docs.aws.amazon.com/cli/latest/userguide/installing.html)。

最后,你需要必须的AWS账户的权限来运行脚本。这包括运行AWS CloudFormation模板、创建虚拟私有云(VPCs)、子网、安全组、以及EC2实例,并且部署和访问EKS集群。你可以使用一个IAM用户(在你的计算机上保存一对可长期使用的Keys)。这种情况下,你需要允许AWS在PowerShell 和 AWS CLI上使用这些Keys。

另一种方式,你可以使用IAM角色,它具有被分配给EC2实例的所有必须的权限,可以用来运行脚本。这个方式,不需要额外的配置,AWS PowerSheel Tool和AWS CLI会从EC2实例的元数据那里自动获得临时的身份信息。

作为可选,这个包里面包括一个Docker文件,它会直接创建脚本,以及直接创建以上所有的必须的部分(AWS CLI、AWS cmdlets这些)到microsoft/powershell Docker镜像里。这样你就可以直接使用docker run来setup环境,不论是在MacOS、Linux或者Windows上,只要你安装了Docker。

在Amazon EKS上部署SQL Server

你可以通过运行被include的脚本,传递必须的参数,来部署SQL Server。脚本包括许多参数,最重要的一些参数已经有默认的值,来帮助不熟悉的用户。反复运行同样参数的脚本也是安全的,它会检查底层的资源是不是已经存在,如果已经存在,会复用它们。

以下是脚本运行的所有步骤:

1.   首先,它为Amazon EKS创建一个IAM服务角色。这个角色会允许AWS来创建必要的资源。

2.   你需要一个VPC来运行你的集群。脚本会接收一个AWS CloudFormation VPC Stack的名称作为一个参数。如果Stack已经存在,它就会复用这个Stack,否则,它就通过AWS提供的模板创建一个新的Stack。Stack包括VPC、子网和安全组,这些必须的内容来运行集群。

3.   你使用一个客户端工具kubectl来配置和与Kubernetes交互。脚本会下载AWS版本的Kubectl,并且安装到你的本地计算机。

4.   当你使用Kubectl来查询Amazon EKS,你正在使用的AWS PowerShell工具的身份信息也会被传递给Amazon EKS。这个任务是被另一个工具aws-iam-authenticator来完成的,这个工具也会被脚本下载并安装。

5.   它创建了一个新的EKS集群。这个EKS集群包括被管理的一组3个 Master节点,分布在3个AWS可用区域上。

6.   它配置Kubectl来连接到上面步骤创建的EKS集群上。

7.   它创建了新的EC2实例,并且配置它们加入到EKS集群和Worker nodes上。

8.   它创建了一个Etcd集群,让Portworx与之通信。

9.   它然后下载一个DaemonSet规格参数,并且应用到EKS集群上。这就自动安装了Portworx云原生存储 – 含有GP2和IO1 EBS卷,供用户选择其中一种或者全部。

10.  它为Portworx卷创建了一个存储类,其中EKS集群内的复制因子数值为3。这样你就可以在主机发生错误的时候,维持SQL Server集群的高可用。甚至Kubernetes可以把你的SQL Server Pod调度到另一个可用性区域。

11.  它在EKS集群内,为gp2 EBS卷创建了一个存储类。

12.  它在EKS集群内创建了一个新的Persistent Volume声明(PVC)。PVC允许Portworx来部署由Amazon EBS卷支持的持久卷(PV)。

13.  它提示你输入SQL Server SA用户的密码。输入符合SQL Server密码要求的强度较高的密码。脚本会把密码作为Secret保存到EKS集群里。

14.  然后它会创建SQL Server的部署。部署包括一个复制集,它会按顺序创建Kubernetes的Pods。Pod是由一个运行SQL Server的单独容器组成。PVC卷被Mount到了这个容器里。SA的密码也被使用。

15.  最后,它输出端点的名称,在连接字符串里使用来连接到SQL Server实例里。

运行脚本会部署EKS集群,以及一个单独的SQL Server实例。你也可以在同一个EKS集群上部署另一个SQL Server实例,只需要再次运行同一个脚本即可。然后为appName参数传递一个不同的名称。

高可用性

脚本部署SQL Server使用Multi-AZ Kubernetes集群,和一个有Portworx卷支持的存储类(Storage Class)。由于Portworx在SQL Server容器里保护和复制数据,部署针对下列情况具备高可用:

  • 容器错误
  • Pod错误
  • EC2实例错误
  • EC2主机错误
  • EBS磁盘错误
  • EC2网络分区
  • AWS有效性区域错误

如果一个容器或者Pod错误,Kubernetes会立即调度另一个容器或者Pod。甚至Kubernetes把Pod调度到了另一个可用性区域。你也不会有数据损失,因为Portworx自动的在可用性区域之间复制数据。

在前面的部分,我们注意到Portworx复制因子的数值被设定成了3。这意味着除了我们的主PV之外,Portworx会在集群上的其他地方一直保持两个额外的PV副本。因为Amazon EBS卷只在一个单独的可用性区域保持高可用性,默认情况下,Portworx把这些复制扩展到多个可用性区域里。相对于本地部署时:通常一个SQL Server错误恢复集群实例(FCI)是部署在同一个数据中心里的,很大的进步就是Kubernetes和Portworx集群是分布在多个可用性区域里的。因此,可用性更高。

在Portworx存储集群上的Kubernetes里运行SQL Server容器,类似在跨多个可用性区域的Storage Spaces Direct 集群(https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview)上运行SQL Server Always On FCI。这样Recovery Point Objective (RPO)是零,而且Recovery Time Objective (RTO,https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container-ha-overview?view=sqlallproducts-allversions) 小于10分钟,这样可以应对可能出现的可用性区域的错误,达到极高的可用性。区别是在EKS里运行容器,比起在Windows Server容错恢复集群上配置和维护SQL Server要更加容易。

如果你运行SQL Server标准版,你也可以通过使用容器和Amazon EKS获得相比于传统Windows部署的更高的可用性。这是因为SQL Server标准版FCI只能授权最多两个节点的使用。(一个第二节点)。然而,容器可以被部署到含有任何数量节点的集群上。SQL Server Always On FCI的企业版可以超过两个节点。取决于你的软件授权协议,你可能要为每个额外的实例购买新的授权。这不是容器的使用方式。你可以只支付一个容器的费用,不论你在集群上有多少standby的实例。

也可以把SQL Server容器和Always On可用性组(SQL Server 2019 preview版本)一起部署。这样的配置类似部署Always On可用性组(每个节点自己就是一个Always On FCI集群)。这样,容器就会摆脱一些Always On可用性组和FCI的限制。例如,这些限制包括从一个可用性组的节点自动容错恢复到另一个节点,和为每一个节点设置FCI的复杂操作。

SQL Server容器软件授权

基于SQL Server 2017软件授权说明:“SQL Server 2017使用授权给虚拟机和容器,为客户的部署提供灵活性。有两种可选的给虚拟机和容器的授权方式,为每个虚拟机和容器授权,以及为高度虚拟化或高密度容器环境的最大密度授权(每物理主机授权)”。

有机会通过把SQL Server负载容器化来降低软件授权成本。你可以基于不同的实际场景,使用每容器授权的模式,或者使用每物理主机授权的模式(高密度),来降低软件授权的数量。

如果你有一些应用在EC2实例上运行,并且希望在同一个主机上运行应用的同时,也运行SQL Server,你可以使用每容器授权的模式。如果没有容器,是在虚拟机上直接运行SQL Server,包括EC2实例,你就需要为VM包括的所有vCPU购买授权,不论SQL Server到底使用了多少vCPU资源。然而,如果你是在VM之上的容器里运行SQL Server,你只需要为容器访问到的vCPU数量购买授权。你可以仅仅为能访问到的核数量购买授权,这样你最小的情况可以只够买4核的授权,或者6核,8核这样,视情况而定。

如果你的SQL Server实例存在突发峰值的使用情况,你可以在高密度环境的容器内运行它们。这种情况下,你可以选择每物理机授权的模式。只要所有的物理核资源得到了正确的授权,就会允许你运行物理核资源之上的不限数量的容器,以及不限数量的vCPU。

在上面的图里,有12个vCPU核和20个容器。但因为这些容器都运行在一个6核的物理机器上,只需要为这6个物理机的核授权。这对那些已经在本地物理环境里过度部署了SQL Server虚拟机的情况非常有用。EC2实例有一个固定的hyperthreading比例:2vCPU对应一个物理主机核。这样迁移过度部署的负载(3:1,4:1,5:1或者更高)到EC2实例里会带来更高的成本问题。容器化解决成本问题,相应也会带来更好的收益。

Portworx授权

Portworx支持高密度容器环境的授权模式。Kubernetes本身推荐一个节点最多不要超过100个pod(https://kubernetes.io/docs/setup/cluster-large/)。这样理论上,你可以在每个EC2实例里运行不超过100个SQL Server Pods,这样可以大量节省SQL Server授权。Portworx针对每个EC2实例只需要一个授权,不论运行多少容器,或者消耗多少存储。这样对于集群,你并不是简单的用一个授权来换另外一个,实际上,每个主机运行的SQL Server数量越多,你的平均授权成本越低。Portworx支持每个集群数千节点,以及支持每个节点数百个有状态容器(https://portworx.com/architects-corner-aurea-beyond-limits-amazon-ebs-run-200-kubernetes-stateful-pods-per-host/)。

什么情况下不适合使用SQL Server容器

在现有版本的功能上,并不是所有的SQL Server都能够被容器化。目前仅仅只有SQL Server2017支持容器。2017之前的版本都不能支持容器。但SQL Server本身是兼容SQL Server 2008之后的版本的,这意味着你可以导入从SQL Server 2008(或之后版本)中创建的数据库到SQL Server2017实例里(包括在容器里运行的SQL Server 2017里),用兼容模式来运行即可。

虽然SQL Server on Linux支持与Microsoft Active Directory的集成,SQL Server容器目前不支持Active Directory集成。

SQL Server一个经常使用的功能是horizontal read-scaling,它在Always on可用性组里。这个功能对容器目前只是Preview版本,不能用在生产环境。

另一个云带来的可能的好处是License Included services模式。对于许多商业来说,管理已购买的授权和实际软件授权使用是非常复杂的工作。经常会不一致,导致客户要么为未使用的软件授权多花钱,要么合规地软件授权不足。SQL Server容器支持Bring Your Own License (BYOL)模式,因此在决策前好好考虑下授权的问题。

也有其他一些功能目前还不能使用,比如Distributed Transaction Coordinator (DTC)和custom CLR user types。如果你的SQL Server负载是一个比较静态平稳的资源消耗模式,也许传统的部署模式更加适用。

结论

在本篇文章中,我们讨论了为什么要考虑在容器中使用SQL Server和Portworx,并且讨论了需要考虑的各个方面。

这样的方式有下面的好处:

  • 简单,而且会帮助你降低一些管理的复杂度。
  • 可以通过释放闲置的资源给需要的负载,来增加应用的性能。
  • 可以增加数据保护,以及部署的容灾恢复。
  • 可以减少基础架构的成本。
  • 可以减少SQL Server软件授权的成本。

这篇文章演示了在Amazon EKS上与Portworx一起部署SQL Server是比较简单的。你可以部署基础架构和EKS集群,并且通过使用一个简单的脚本来调用AWS API,从而来运行SQL Server容器。基于你的情况,你可以使用两种存储方案:

  • 使用单独的EBS卷作为一个PVC,在一个单一的高可用区域里提供高可用性,最少的存储成本。
  • 使用一个集群化的存储解决方案Portworx来跨多个可用性区域,提供支持可用性区域错误恢复级别的高可用。

kubernetes-基于Prometheus和Grafana监控Windows操作系统(wmi-exporter)

Daniel_Ji阅读(8683)评论(0)

1、安装和配置wmi-exporter

1.1 使用helm安装redis-exporter

通过下面的连接:https://github.com/martinlindhe/wmi_exporter/releases/download/v0.10.2/wmi_exporter-0.10.2-amd64.exe

下载wmi_exporter-0.10.2-amd64.exe,并将名称改为wmi_exporter.exe。在本文中,将wmi_exporter.exe放置在”d:\”目录下,通过执行下面的命名将wmi_exporter.exe注册成windows系统服务。

sc create wmi_exporter binpath= "d:\wmi_exporter.exe" start= auto

1.2 查看Windows操作系统的指标数据

在浏览器中访问:http://{ip}:9182,能够看到所要监控的指标。

2、Prometheus监控

2.1 配置Prometheus

在Prometheus的配置文件(Prometheus.yaml)中,添加红色字体部分的内容。

global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
alertmanagers:
– static_configs:
– targets:
# – alertmanager:9093

# Load rules once and periodically evaluate them according to the global ‘evaluation_interval’.
rule_files:
# – “first_rules.yml”
# – “second_rules.yml”

# A scrape configuration containing exactly one endpoint to scrape:
# Here it’s Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
– job_name: ‘prometheus’

# metrics_path defaults to ‘/metrics’
# scheme defaults to ‘http’.

static_configs:
– targets: [‘localhost:9090’]

# 配置从redis-exporter中获取数据,目标地址为:10.0.32.148:9182

– job_name: ‘windows-node-001’
static_configs:
– targets: [‘10.0.32.148:9182’]

2.2 配置验证

在浏览器的地址栏访问http://{prometheus}/targets,将会看到新配置的redis。

3 Grafana监控

3.1 配置Windows监控dashboard

下载wmi-exporter的dashboard(windows-host-metrics_rev1.json),下载地址:https://grafana.com/api/dashboards/10171/revisions/1/download/

在grafana中导入dashboard:windows-host-metrics_rev1.json。

导入后,通过此dashborad,管理员就可以监控Windows操作系统的CPU、内存、磁盘空间、网络等性能指标。

 

作者简介:

季向远,北京神舟航天软件技术有限公司。本文版权归原作者所有。微博:ik8s

Kubernetes 1.18GA,15个稳定11个beta,引入kubectl debug命令

王延飞阅读(51941)评论(1)

我们很高兴宣布Kubernetes 1.18的交付,这是我们2020年的第一版!Kubernetes 1.18包含38个增强功能:其中15个功能已趋于稳定,beta版本中有11个,alpha版本中有12个。

Kubernetes 1.18是一个“完美”的版本。为了改善用户体验,我们在beta和 stable 功能改进方面进行了大量工作:增加新的开发和新功能。对alpha,beta和 stable 版进行几乎一样多的增强是一项伟大的成就。这说明,社区在提高Kubernetes的可靠性以及继续扩展其现有功能方面所做的巨大努力。

Kubernetes 1.18主要更新内容

Kubernetes拓扑管理器(Topology Manager ) 升级到Beta版 !

拓扑管理器功能 是1.18版中Kubernetes的beta版本功能,它可以使CPU和设备(如SR-IOV VFs)实现NUMA,这将使你的工作负载在针对低延迟而优化的环境中运行。在引入拓扑管理器之前,CPU和设备管理器会做出彼此独立的资源分配决策,那么可能会导致在多套接字( multi-socket )系统上分配不良,从而导致关键型应用程序的性能下降。

Serverside Apply引入Beta 2版本

Server-side Apply 在1.16中被升级为Beta,在1.18中引入Beta 2版本。这个新版本将跟踪和管理所有新Kubernetes对象的字段更改,从而使你知道更改了什么资源以及何时更改的。

使用IngressClass扩展Ingress,并用IngressClass替换不推荐使用的注释

在Kubernetes 1.18中,Ingress有两个重要的补充:一个新pathType字段和一个新IngressClass资源。该pathType字段允许指定路径应如何匹配。除了默认ImplementationSpecific类型外,还有new Exact和Prefixpath类型。

该IngressClass资源用于描述Kubernetes集群中的Ingress类型。入口可以通过ingressClassName在入口上使用新字段来指定与它们关联的类。这个新资源和字段替换了不建议使用的kubernetes.io/ingress.class注释。

SIG-CLI引入kubectl debug命令

SIG-CLI一直在争论是否需要调试实用程序。随着临时容器(ephemeral containers)的发展,开发人员越来越需要更多类似kubectl exec的命令。该kubectl debug命令的添加(它是Alpha版本,但欢迎你提供反馈),使开发人员可以轻松地在集群中调试其Pod。我们认为这种增加是无价的。此命令允许创建一个临时容器,该容器在要检查的Pod旁边运行,并且还附加到控制台以进行交互式故障排除。

Alpha版本引入Windows CSI

随着Kubernetes 1.18的发布,用于Windows的CSI代理的Alpha版本也已发布。CSI代理使非特权(预先批准)的容器能够在Windows上执行特权存储操作。现在,可以利用CSI代理在Windows中支持CSI驱动程序。

Kubernetes 1.18其他更新

稳定特性💯

主要变化

发行说明

在我们的发行说明中查看Kubernetes 1.18发行版的完整详细信息。

可用性

Kubernetes 1.18可以在GitHub上下载。如果要开始使用Kubernetes,可以看看这些互动式教学或使用 kind.运行本地Kubernetes集群。你还可以使用kubeadm轻松安装1.18 。

发布团队

通过数百名贡献了技术和非技术内容的个人的努力,使此发行成为可能。特别感谢Searchable AI网站可靠性工程师Jorge Alarcon Ochoa领导的发布团队。34位发布团队成员协调了发布的许多方面,从文档到测试,验证和功能完整性。

随着Kubernetes社区的发展,我们的发布过程很好地展示了开源软件开发中的协作。Kubernetes继续快速地获得新用户。这种增长创造了一个积极的反馈周期,其中有更多的贡献者提交了代码,从而创建了更加活跃的生态系统。到目前为止,Kubernetes已有超过40,000个人贡献者,活跃社区有3,000多人。

发布徽标

为什么选择大型强子对撞机?

LHC是世界上最大,功能最强大的粒子加速器。这是来自世界各地成千上万科学家合作的结果,所有这些都是为了促进科学的发展。以类似的方式,Kubernetes已经成为一个项目,它聚集了来自数百个组织的数千名贡献者–所有人都朝着在各个方面改善云计算的相同目标努力!发行名称“ A Quarky”的意思是提醒我们,非常规的想法可以带来巨大的变化,对开放性保持开放态度将有助于我们进行创新。

关于设计师

Maru Lango是目前居住在墨西哥城的设计师。尽管她的专长是产品设计,但她还喜欢使用CSS + JS进行品牌,插图和视觉实验,并为技术和设计社区的多样性做出了贡献。你可能会在大多数社交媒体上以@marulango的身份找到她,或查看她的网站: https://www.marulango.com/

Kubernetes 用户实践亮点

  • 爱立信正在使用Kubernetes和其他云原生技术来交付高要求的5G网络,从而节省多达90%的CI / CD。
  • Zendesk正在使用Kubernetes 运行约70%的现有应用程序。它还构建了所有也可以在Kubernetes上运行的新应用程序,这节省了时间,提高了灵活性并提高了其应用程序开发的速度。
  • 由于改用Kubernetes,LifeMiles已将基础设施支出减少了50%。它还使他们可以将其可用资源容量增加一倍。

生态系统更新

  • CNCF公布了其年度调查的结果,该结果表明Kubernetes在生产中的使用量正在猛增。调查发现,有78%的受访者在生产中使用Kubernetes,而去年这一比例为58%。
  • CNCF举办的“ Kubernetes简介”课程已超过100,000个注册

项目速度

CNCF继续完善DevStats,这是一个雄心勃勃的项目,旨在可视化项目中的大量贡献。K8s DevStats展示了主要公司贡献者的贡献细目,以及一系列令人印象深刻的预配置报告,包括从各个贡献者到请求生命周期时间的所有内容。

在过去的一个季度中,有641家不同的公司和6,409多名个人为Kubernetes做出了贡献。查看DevStats,以了解有关Kubernetes项目和社区整体速度的更多信息。

活动更新

Kubecon + CloudNativeCon EU 2020推迟发布-有关最新信息,请查看Novel Coronavirus更新页面

Kubernetes 1.18即将举行的在线讲座

将于2020年4月23日举行在线讲座,以了解Kubernetes 1.18版本的主要功能,包括 kubectl debug ,Topology Manager,Ingress to V1 graduation 和 client-go 。在此处注册: https://www.cncf.io/webinars/kubernetes-1-18/

欢迎你参与其中

参与Kubernetes的最简单方法是加入符合你的兴趣的众多特殊兴趣小组(SIG)之一。你有什么想向Kubernetes社区广播的内容吗?在我们的每周社区会议上以及通过以下渠道分享你的声音。感谢你一直以来的反馈和支持。

k8s高可用部署后续:SLB

Young阅读(17418)评论(3)

前一段时间写了使用keepalived+haproxy部署k8s高可用集群,核心思想是利用keepalived生成vip实现主备容灾,以及haproxy负载k8s-apiserver流量。k8s高可用部署:keepalived + haproxy

这种方式是自己实现了负载均衡。本文将探讨在用户已有SLB的场景下如何实现k8s高可用

SLB概念

阿里云文档中SLB(Server Load Balancer)介绍如下:

负载均衡基础架构是采用集群部署,提供四层(TCP协议和UDP协议)和七层(HTTP和HTTPS协议)的负载均衡,可实现会话同步,以消除服务器单点故障,提升冗余,保证服务的稳定性。

负载均衡作为流量转发服务,将来自客户端的请求通过负载均衡集群转发至后端服务器,后端服务器再将响应通过内网返回给负载均衡。

本文还涉及到SLB的一个关键技术限制:

在 4 层(TCP 协议)服务中,不支持添加进后端的服务器既作为 Real Server,又作为客户端向所在的 SLB 实例发送请求。因为,返回的数据包只在服务器内部转发,不经过负载均衡,所以通过配置在 SLB 后端的 服务器去访问其 VIP 是不通的。

另外对于SLB的健康检查、调度算法等最佳实践不做探讨,请查阅相关文档。文本探讨的范围仅限于架构可行性验证。

架构

1 keepalived+haproxy

 

由于4层SLB不支持后端服务访问其VIP,根据kubeadm官方安装文档:

 

 

 

 

 

 

指定vip会发生如下超时错误:

[etcd] Creating static Pod manifest for local etcd in “/etc/kubernetes/manifests”

[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory “/etc/kubernetes/manifests”. This can take up to 4m0s

[kubelet-check] Initial timeout of 40s passed.

查看kubele日志:

# sudo journalctl -u kubelet.service

k8s.io/kubernetes/pkg/kubelet/kubelet.go:442: Failed to list *v1.Service: Get https://172.16.105.26:9443/api/v1/services?limit=500&resourceVersion=0: dial tcp 172.16.105.26:9443: connect: connection refused

还记得之前说的4层负载的技术限制吗?

基于此我们出了一个比较”脏”的方案:keepalived+haproxy。安装步骤与上一篇文章一样,只是结果不同:

  •  这种方式还是先启用keepalived绑定vip,此时对vip的请求属于本地访问,不会转发出去,因此不会出现访问不通的情况。
  • 三台keepalived都必须是leader, 否则只有一台能绑定vip,其他两台还是加入不了
  • 如何使三台都是keepalived leader? 两种方式: 1)关闭vrrp协议(阿里云默认关闭),此时keepalived backup收不到其他节点的广播信息,将自己设为leader; 2)用单播方式启动keepalived

问题:

1.  这种实现方式相当于在LB的后端又实现一次LB,但是用户请求多了一次转发, 显然不是一个令人满意的方案。

2. 这种keepalived全主模式不能应用在纯vip场景下(如openstack)。这种情况安装是没问题的,master1先绑定vip,master2,3通过vip访问apiserver时走本地流量,由于本地apiserver:6443还未启动,被haproxy负载到健康节点。这么做安装是没问题的。但是不能保证高可用。当master1 done时,子网内部访问vip还是能找到另外两台健康节点,但是子网外部访问时,路由器还是会路由到master1。

2 绑定vip方式

keepalived的解决方式其实是将vip绑定三台k8s-master,使得三台主机初始化时走本地网络,解决后端访问不了slb的问题。那么其实我们不需要在keepalived后面再加一层haproxy,使得请求多一次转发,更进一步,我们不需要keepalived来绑定vip,手动绑定就好了。

安装步骤:

2.1 init k8s-master-leader

绑定vip:

# ip addr add 172.16.105.26/32 dev eth0

查询绑定结果:

#ip a| grep eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    inet 172.16.104.54/24 brd 172.16.104.255 scope global eth0

    inet 172.16.105.26/32 scope global eth0

kubeadm-config.yaml

apiVersion: kubeadm.k8s.io/v1beta1

kind: ClusterConfiguration

kubernetesVersion: v1.14.1

imageRepository: registry.aliyuncs.com/google_containers

networking:

  podSubnet: 10.244.0.0/16

controlPlaneEndpoint: 172.16.105.26:6443

join

sudo kubeadm init –config=kubeadm-config.yaml –experimental-upload-certs

记录下日志中的join命令

2.2 join k8s-master-follower

分别将k8s-master-follower加入k8s-master-leader

 sudo kubeadm join 172.16.105.26:6443 –token c1d2cb.vx086ez76bpggqj5 \

>     –discovery-token-ca-cert-hash sha256:bc749b4e7e75f93ea9c0055d1c6e36c814b04247ca9e5bb6168ec3a27e5693bd \

>     –experimental-control-plane –certificate-key cdb31f173bf87a573217a4cd1d6e22dc1d396a4da5050e36bdec407bd2aab29d

2.3 为k8s-master-follower绑定vip

您可能注意到follower join时没有先绑定vip。原因是follower join时需要访问k8s-apiserver获取证书等信息,绑定vip直接走本地,获取失败。而此时slb健康检查认为k8s-master-leader是可以负载的,所以直接访问前端slb会负载到k8s-master-leader,可以访问k8s-apiserver。

那为什么还要为k8s-master-follower绑定vip呢?在每个k8s-master-follower请求slb时有1/3的几率负载到自身,此时访问不通。绑定vip后,每个k8s-master-follower访问slb都是访问的本机。

总结

第一篇文章讲述了只有vip,没有实际slb设备的模式下,采用keepalived+haproxy实现高可用的方式。本篇讲述了依赖云厂商SLB高可用和负载均衡时安装k8s。方案一并不完美,通过改良后形成了方案二。当然业内肯定还有很多其他的解决方案,作者才疏学浅,还没来得及一一拜读。

完成本篇的同时又接到了一个新的需要:SLB不是以vip形式提供,而是域名。域名SLB当然比IP要强,大部分云厂商负载均衡肯定不是一台设备,背后都是大规模的集群,会保证SLB服务本身的高可用。这种场景下已经不能通过绑定vip来实现,如何解决呢?敬请期待第三篇。