PaaS系统/容器TiDB Operator、Escalator、SOFAArk、Laradock介绍

以下为你介绍的PaaS系统/容器都可用在Linux系统上:TiDB Operator(自动化部署运维工具)、Escalator(Kubernetes 自动扩展工具)、SOFAArk(轻量级 Java 类隔离容器)、Laradock(PHP 的 Docker 完整本地开发环境)。

1、TiDB Operator(自动化部署运维工具)

PaaS系统/容器TiDB Operator、Escalator、SOFAArk、Laradock介绍

TiDB Operator 是 TiDB 在 Kubernetes 平台上的自动化部署运维工具,借助 TiDB Operator,TiDB 可以无缝运行在公有云厂商提供的 Kubernetes 平台上,让 TiDB 成为真正的 Cloud-Native 数据库。

为什么我们要做 TiDB Operator:

第一,使用传统的自动化工具带来了很高的部署和运维成本。TiDB 的分层架构对于分布式系统是比较常见的,各个组件都可以根据业务需求独立水平伸缩,并且 TiKV 和 TiDB 都可以独立使用。比如,在 TiKV 之上可以构建兼容 Redis 协议的 KV 数据库,而 TiDB 也可以对接 LevelDB 这样的 KV 存储引擎。

但是,这种多组件的分布式系统增加了手工部署和运维的成本。一些传统的自动化部署和运维工具如 Puppet/Chef/SaltStack/Ansible,由于缺乏全局状态管理,不能及时对各种异常情况做自动故障转移,并且很难发挥分布式系统的弹性伸缩能力。其中有些还需要写大量的 DSL 甚至与 Shell 脚本一起混合使用,可移植性较差,维护成本比较高。

第二,在云时代,容器成为应用分发部署的基本单位,而谷歌基于内部使用数十年的容器编排系统 Borg 经验推出的开源容器编排系统 Kubernetes 成为当前容器编排技术事实上的标准。如今各大云厂商都开始提供托管的 Kubernetes 集群,部署在 Kubernetes 平台的应用可以不用绑定在特定云平台,轻松实现在各种云平台之间的迁移,其容器化打包和发布方式也解决了对操作系统环境的依赖。

Kubernetes 项目最早期只支持无状态服务(Stateless Service)的管理。无状态服务通过 ReplicationController 定义多个副本,由 Kubernetes 调度器来决定在不同节点上启动多个 Pod,实现负载均衡和故障转移。对于无状态服务,多个副本对应的 Pod 是等价的,所以在节点出现故障时,在新节点上启动一个 Pod 与失效的 Pod 是等价的,不会涉及状态迁移问题,因而管理非常简单。

但是对于有状态服务(Stateful Service),由于需要将数据持久化到磁盘,使得不同 Pod 之间不能再认为成等价,也就不能再像无状态服务那样随意进行调度迁移。

Kubernetes v1.3 版本提出 PetSet 的概念,用来管理有状态服务并于 v1.5 将其更名为 StatefulSet。StatefulSet 明确定义一组 Pod 中每个的身份,启动和升级都按特定顺序来操作。另外使用持久化卷存储(PersistentVolume)来作为存储数据的载体,当节点失效 Pod 需要迁移时,对应的 PV 也会重新挂载,而 PV 的底层依托于分布式文件系统,所以 Pod 仍然能访问到之前的数据。同时 Pod 在发生迁移时,其网络身份例如 IP 地址是会发生变化的,很多分布式系统不能接受这种情况。所以 StatefulSet 在迁移 Pod 时可以通过绑定域名的方式来保证 Pod 在集群中网络身份不发生变化。

但是由于有状态服务的特殊性,当节点出现异常时,出于数据安全性考虑,Kubernetes 并不会像无状态服务那样自动做故障转移。尽管网络存储能挂载到不同的节点上供其上的 Pod 使用,但是如果出现节点故障时,简单粗暴地将网络 PV 挂载到其它节点上是比较危险的。

Kubernetes 判断节点故障是基于部署在每个节点上的 Kubelet 服务是否能正常上报节点状态,Kubelet 能否正常工作与用户应用并没有必然联系,在一些特殊情况下,Kubelet 服务进程可能无法正常启动,但是节点上的业务容器还在运行,将 PV 再挂载到其它节点可能会出现双写问题。

为了在 Kubernetes 上部署和管理 TiDB 这种有状态的服务,我们需要扩展 StatefulSet 的功能。TiDB Operator 正是基于 Kubernetes 内置的 StatefulSet 开发的 TiDB 集群管理和运维工具。

Kubernetes 直到 v1.7 才试验性引入本地 PV,在这之前只有网络 PV,TiKV 自身在存储数据时就是多副本的,网络 PV 的多副本会增加数据冗余,降低 TiDB 的性能。在这之前我们基于 Kubernetes 内置的 hostPath volume 实现了本地 PV 满足 TiKV 对磁盘 IO 的要求。官方本地 PV 方案直到最近的 Kubernetes v1.10 才相对稳定地支持调度功能,满足用户对本地 PV 的需求。为了降低用户的使用和管理成本并且拥抱 Kubernetes 开源社区,我们又重新基于官方的本地 PV 方案实现了对数据的管理。

TiDB Operator 原理解析:

Operator 本质上是 Kubernetes 的控制器(Controller),其核心思想是用户给定一个 Spec 描述文件,Controller 根据 Spec 的变化,在 Kubernetes 集群中创建对应资源,并且不断调整资源使其状态满足用户预期的 Spec。

上图是 TiDB Operator 工作流程原理图,其中 TidbCluster 是通过 CRD(Custom Resource Definition)扩展的内置资源类型:

1]、用户通过 Helm 往 Kubernetes API Server 创建或更新 TidbCluster 对象。

2]、TiDB Operator 通过 watch API Server 中的 TidbCluster 对象创建更新或删除,维护 PD/TiKV/TiDB StatefulSet, Service 和 Deployment 对象更新。

3]、Kubernetes 根据 StatefulSet, Service 和 Deployment 对象创建更新或删除对应的容器和服务。

在第 2 步中,TiDB Operator 在更新 StatefulSet 等对象时会参考 PD API 给出的集群状态来做出 TiDB 集群的运维处理。通过 TiDB Operator 和 Kubernetes 的动态调度处理,创建出符合用户预期的 TiDB 集群。

快速体验 TiDB Operator:

TiDB Operator 需要运行在 Kubernetes v1.10 及以上版本。TiDB Operator 和 TiDB 集群的部署和管理是通过 Kubernetes 平台上的包管理工具 Helm 实现的。运行 TiDB Operator 前请确保 Helm 已经正确安装在 Kubernetes 集群里。

如果没有 Kubernetes 集群,可以通过 TiDB Operator 提供的脚本快速在本地启动一个多节点的 Kubernetes 集群:

git clone https://github.com/pingcap/tidb-operator

cd tidb-operator

NUM_NODES=3    # the default node numble is 2

KUBE_REPO_PREFIX=uhub.ucloud.cn/pingcap manifests/local-dind/dind-cluster-v1.10.sh up

等 Kubernetes 集群准备好,就可以通过 Helm 和 Kubectl 安装部署 TiDB Operator 和 TiDB 集群了。

1].安装 TiDB Operator 

kubectl apply -f manifests/crd.yaml

helm install charts/tidb-operator --name=tidb-operator --namespace=tidb-admin

2].部署 TiDB 集群

helm install charts/tidb-cluster --name=demo-tidb --namespace=tidb --set clusterName=demo

集群默认使用 local-storage 作为 PD 和 TiKV 的数据存储,如果想使用其它持久化存储,需要修改 charts/tidb-cluster/values.yaml 里面的 storageClassName。

下载地址:https://github.com/pingcap/tidb-operator

2、Escalator(Kubernetes 自动扩展工具)

Escalator 是 Atlassian 开源的一款 Kubernetes 自动扩展工具,专为大批量或基于作业任务(job-based)的工作负载而设计。当集群需要按比例缩放时,无法强制释放和移动,Escalator 将确保在终止节点之前已在节点上完成了 pod 。它还针对集群扩展进行了速度优化,以确保 pod 不会处于挂起状态。

主要特性:

计算请求和容量,以确定是按比例扩容、缩容还是保持当前比例。

在终止节点之前等待节点上的非守护进程 pod 已完成。

可指定需要自动扩展的群组,以允许默认的 Kubernetes Autoscaler 继续扩展基于服务的工作负载。

优先自动终止最老的节点。

提供残留区,以确保在计划容器出现峰值时有额外空间。

允许 cordoned nodes 持续进行调试。

支持不同的云提供商 - 目前仅限 AWS。

扩展率和利用率度量指标。

Building:

# Install dependencies

make setup

# Build Escalator

make build

下载地址:https://github.com/atlassian/escalator

3、SOFAArk(轻量级 Java 类隔离容器)

SOFAArk 是一款基于 Java 实现的轻量级类隔离容器,由蚂蚁金服公司开源贡献;主要为应用程序提供类隔离和依赖包隔离的能力;基于 Fat Jar 技术,应用可以被打包成一个自包含可运行的 Fat Jar,应用既可以是简单的单模块 Java 应用也可以是 Spring Boot 应用。可访问网址进入快速开始并获取更多详细信息。

背景:

日常使用 Java 开发,常常会遇到包依赖冲突的问题,尤其当工程应用变得臃肿庞大,包冲突的问题也会变得更加棘手,导致各种各样的报错,例如LinkageError, NoSuchMethodError等。实际开发中,可以采用多种方法来解决包冲突问题,比较常见的是类似 SpringBoot 的做法,统一管理应用所有依赖包的版本,保证这些三方包不存在依赖冲突;这种做法只能有效避免包冲突的问题,不能根本上解决包冲突的问题;如果某个应用的确需要在运行时使用两个相互冲突的包,例如 protobuf2 和 protobuf3,那么类似 SpringBoot 的做法依然解决不了问题。

为了彻底解决包冲突的问题,我们需要借助类隔离机制,使用不同的 Classloader 加载不同版本的三方依赖,进而隔离包冲突问题;OSGI 作为业内最出名的类隔离框架,自然是可以被用于解决上述包冲突问题,但是 OSGI 框架太过臃肿,功能繁杂;为了解决包冲突问题,引入 OSGI 框架,有牛刀杀鸡之嫌,反而使工程变得更加复杂,不利于开发。

SOFAArk 专注于解决类隔离问题,采用轻量级的类隔离方案来解决日常经常遇到的包冲突问题,在蚂蚁金服内部服务于整个 SOFABoot 技术体系,弥补 SpringBoot 没有的类隔离能力。实际上,SOFAArk 是一个通用的轻量级类隔离框架,并不限于 SpringBoot 应用,也可以和其他的 Java 开发框架集成。

原理:

SOFAArk 框架包含有三个概念,Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑结构图如下:

PaaS系统/容器TiDB Operator、Escalator、SOFAArk、Laradock介绍

在介绍这三个概念之前,为了统一术语,有必要先说一下所谓的 Ark 包;Ark 包是满足特定目录格式要求的 Executed Fat Jar,使用官方提供的 Maven 插件 sofa-ark-maven-plugin可以将工程应用打包成一个标准格式的 Ark 包;使用命令 java -jar application.jar即可在 Ark 容器之上启动应用;Ark 包 通常包含 Ark Container、Ark Plugin、 Ark Biz;以下我们针对这三个概念简单做下名词解释:

Ark Container: Ark 容器,负责整个运行时的管理;Ark Plugin 和 Ark Biz 运行在 Ark 容器之上;容器具备管理多插件、多应用的功能;容器启动成功后,会自动解析 classpath 包含的 Ark Plugin 和 Ark Biz 依赖,完成隔离加载并按优先级依次启动之。

Ark Plugin: Ark 插件,满足特定目录格式要求的 Fat Jar,使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以将一个或多个普通的 Java Jar 包打包成一个标准格式的 Ark Plugin;Ark Plugin 会包含一份配置文件,通常包括插件类导入导出配置、插件启动优先级等;运行时,Ark 容器会使用独立的 PluginClassLoader 加载插件,并根据插件配置构建类加载索引表,从而使插件与插件、插件与应用之间相互隔离。

Ark Biz: Ark 业务模块,满足特定目录格式要求的 Fat Jar ,使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以将工程应用打包成一个标准格式的 Ark-Biz 包;是工程应用模块及其依赖包的组织单元,包含应用启动所需的所有依赖和配置。

在运行时,Ark Container 优先启动,自动解析 classpath 包含的 Ark Plugin 和 Ark Biz,并读取他们的配置,构建类加载索引关系;然后使用独立的 Classloader 加载他们并按优先级配置依次启动;需要指出的是,Ark Plugin 优先 Ark Biz被加载启动;Ark Plugin 之间是双向类索引关系,即可以相互委托对方加载所需的类;Ark Plugin 和 Ark Biz 是单向类索引关系,即只允许 Ark Biz 索引 Ark Plugin 加载的类,反之则不允许。

场景:

SOFAArk初衷是为了解决包冲突问题,那什么情况下可以使用 SOFAArk 以及如何使用呢? 假设如下场景,如果工程需要引入两个三方包:A 和 B,但是 A 需要依赖版本号为 0.1 的 C 包,而恰好 B 需要依赖版本号为 0.2 的 C 包,且 C 包的这两个版本无法兼容:

PaaS系统/容器TiDB Operator、Escalator、SOFAArk、Laradock介绍

此时,即可使用 SOFAArk 解决该依赖冲突问题;只需要把 A 和版本为 0.1 的 C 包一起打包成一个 Ark Plugin,然后让应用工程引入该插件依赖即可。

下载地址:https://gitee.com/sofastack/sofa-ark

4、Laradock(PHP 的 Docker 完整本地开发环境)

PaaS系统/容器TiDB Operator、Escalator、SOFAArk、Laradock介绍

Laradock 是为 PHP 提供的完整 Docker 本地开发环境,有助于在 Docker 上运行 PHP 应用程序,和 Homestead 一样提供了一系列打包好(包括配置)的 Docker Image。Laradock 早期专注为 Laravel 打造 Docker 开发环境,因而最早在 Laravel 社区中出名,后来随着影响力的扩大,逐渐被 PHP 社区接纳和采用,目前支持的 PHP 项目除了 Laravel 之外,还有 Symfony、CodeIgniter、WordPress、Drupal 等等。

功能特性:

可在各 PHP 版本之间轻松切换:7.2,7.1,5.6 ...

可选择你最喜欢的数据库引擎:MySQL,Postgres,MariaDB ......

可运行专属的软件组合:Memcached,HHVM,Beanstalkd ...

每个软件都在单独的容器上运行:PHP-FPM,NGINX,PHP-CLI ...

易于定制,只需简单编辑 Dockerfile 即可;

所有镜像均从官方基础镜像扩展而来,安全可靠;

易于使用环境变量安装/删除容器中的软件;

简洁、结构良好的 Dockerfiles(Dockerfile);

一切都是可见的和可编辑的。

下载地址:https://github.com/laradock/laradock

注明

以上就是PaaS系统/容器TiDB Operator、Escalator、SOFAArk、Laradock的介绍内容,这些PaaS系统/容器都能使用在Linux操作系统中。

栏目相关文章