导读：
近些年随着云计算和云原生利用的衰亡，容器技术能够很好地解决许多问题，所以将大数据平台容器化是一种现实的计划。本文将联合袋鼠云数栈在 Flink on Kubernetes 的实际让您对大数据平台容器化的操作和价值有初步的理解。
你能够看到👇👇👇
▫ Kubernetes 如何解决 Hadoop 痛点
▫ 数栈在 Flink on K8S 的实际
▫ 容器化之后的将来构想：资源池化
作者 / 雅泽、狗焕
编辑 / 向山
引言
在过来的很长一段时间，大数据畛域中构建可扩大的分布式应用框架中，Apache Hadoop 占据的是相对的统治位置。
目前绝大多数大数据平台都是基于 Hadoop 生态构建，应用 YARN 作为外围组件进行资源管理与资源调度，然而这些大数据平台广泛都会存在资源隔离性差、资源利用率低等问题，与此同时近些年随着云计算和云原生利用的衰亡，容器技术能够很好地解决这些问题。
所以将大数据平台容器化是一种现实的计划，本文将联合袋鼠云数栈在 Flink on Kubernetes 的实际让您对大数据平台容器化的操作和价值有初步的理解。
Hadoop 痛点频现，亟待解决
大数据平台顾名思义就是解决急速增长的实时、离线数据的大规模应用程序，所以设计大数据平台的解决方案的须要思考的首要问题就是如何确定生产环境中大数据平台的部署架构，使得平台具备紧密联系数据、应用程序与基础设施之间的能力。
Hadoop 次要提供了三个要害性能：资源管理器 (YARN)、数据存储层 (HDFS)、计算范式 (MapReduce)，市面上大多数大数据平台都是基于 Hadoop 生态构建的，然而这类型的平台会存在下列问题：
资源弹性有余
大数据系统的资源应用顶峰是具备周期性的，不同业务线在一天中的高峰期是不一样的，当业务压力增大时，以后的大数据系统广泛不足资源弹性伸缩的能力，无奈按需进行疾速扩容，为了应答业务顶峰只能预留出足够的资源保障工作失常运行；
资源利用率低
存储密集型的业务存储资源应用较高而 CPU 使用率长期处于较低的程度，计算密集型的业务尽管 CPU 使用率绝对较高然而存储的使用率非常低，大量资源闲置；
资源隔离性差
从 Hadoop2.2.0 开始，YARN 开始应用 cgroup 实现了 CPU 资源隔离，通过 JVM 提供的内存隔离机制来实现内存资源隔离，整体上来看 YARN 的资源隔离做的并不欠缺，会造成多个工作运行到同一个工作节点上时，不同工作会呈现资源抢占的状况。
Kubernetes 风头正劲，完满解决 Hadoop 痛点
Kubernetes 是谷歌开源的生产级的容器编排零碎，是建设在谷歌大规模运行生产工作负载方面的十几年的教训根底上的，而且领有一个宏大且快速增长的生态系统，随同着微服务、DevOps、继续交付等概念的衰亡和继续发酵，并依靠与云原生计算基金会 (CNCF)，Kubernetes 放弃着高速倒退。
如下图所示，Google 过来五年对于 Kubernetes 和 Apache Hadoop 热度统计后果展现表明市面上对 Kubernetes 的激情逐步低落而对 Hadoop 热度逐步减退。
那么，Kubernetes 是如何解决 Hadoop 存在的痛点的呢，咱们一一剖析一下。
解决资源弹性有余
对于资源弹性有余的问题，Kubernetes 自身就是设计为一个利用模块化架构来进行扩大的零碎，对用户来说，服务进行扩容只须要批改配置文件中容器的正本数或者是应用 Pod 程度主动扩缩 (HPA)，将利用扩缩容的复杂度交给 Kubernetes 管制能够极大缩小人为染指的老本。HPA 是基于 CPU 使用率、内存使用率或其余实时采集的性能指标主动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。
Kubernetes 中的 Metrics Server 会继续采集所有 Pod 正本的性能指标信息，HPA 控制器通过 Metrics Server 的 API 获取这些数据，并依据用户设置的主动扩缩容规定计算指标 Pod 正本数量，当指标 Pod 数量与以后 Pod 数量不统一时，HPA 控制器就向 Pod 的正本控制器发动扩缩容操作，调整 Pod 数量，实现扩缩容操作。
解决资源使用率低
对于资源使用率低的问题，一方面 Kubernetes 反对更加细粒度的资源划分，这样能够尽量做到资源能用尽用，最大限度的按需应用。另外一方面反对更加灵便的调度，并依据业务 SLA 的不同，业务顶峰的不同，通过资源的混合部署来进一步晋升资源使用率。
解决资源隔离性差
对于资源隔离性差的问题，容器技术自身是具备资源隔离的能力的，底层应用 Linux namespace 进行资源隔离，它将全局零碎的资源包裹在一个形象层中，使得在每个 namespace 外部的过程看起来本人都领有一个独立的全局资源。
同一个 namespace 下的资源变动对于同一 namespace 的过程是可见的，然而对于不同 namespace 下的过程是不可见的。为了可能让容器不占用其它容器的资源（或者说确定每个容器的“硬件”配置），采纳 cgroups 来限度单个过程或者多个过程所应用资源的机制，能够对 cpu，内存等资源实现精细化的管制。
Flink on K8S 实际，数栈钻研小成
正因为大数据组件容器化劣势显著，数栈应用的大数据计算和存储组件均预期往容器化方向排布。
在数栈目前应用的泛滥组件中，咱们首先抉择在 k8s 上尝试实际的是数栈流计算引擎——Flink。通过钻研布设，当初数栈的流计算容器化转换曾经根本实现。接下来是一些 Flink on K8S 的教训分享:
Flink on K8S 概述
目前在 K8S 中执行 Flink 工作的形式有两种，一种是 Standalone，一种是原生模式：Flink native session 模式、Flink native per-job 模式，它们各自对应的优缺点如下：
Flink Standalone 模式：
● 长处：长处是无需批改 Flink 源码，仅仅只需事后定义一些 yaml 文件，集群就能够启动，相互之间的通信齐全不通过 K8s Master；
● 毛病：毛病是资源须要事后申请无奈动静调整。
Flink native session 模式：
● 长处：taskManager 的资源是实时的、按需进行的创立，对资源的利用率更高，所需资源更精准。
● 毛病：taskManager 是实时创立的，用户的作业真正运行前, 与 Per Job 集群一样, 仍须要先期待 taskManager 的创立, 因而对工作启动工夫比拟敏感的用户，须要进行肯定的衡量。
Flink native per-job 模式：
● 长处：资源按需申请，适宜一次性工作，工作执行后立刻开释资源，保障了资源的利用率；
● 毛病：资源是在工作提交后开始创立，同样意味着对于提交工作后对延时比拟敏感的场景，须要肯定的衡量;
数栈 Flink Standalone on K8S 实际
接下来咱们以 standalone 模式容器化为切入点介绍下咱们的一些实际。
咱们通过自定义的资源对象来定义咱们利用的相干部署属性，而后将这个 yaml 文件和所需的配置文件以及镜像打包上传到 easymanager 平台（后续会将其开源）进行一键部署。这里对于利用整体状态的解决大抵如下：
● 对于配置：这里咱们把利用的波及到的状态数据都提炼到利用的配置变成 k8s 中的 configmap，通过该配置作为对立的批改入口。同时拆散出 jobmanager 和 taskmanager 的配置使两者对各自状态进行保护互不烦扰。
● 对于存储：拆散存储状态，可采纳 pvc 来申明咱们所须要的存储类型（storageclass），或者咱们能够在镜像中内置一个 hdfs 的 client 或者 s3 插件来间接对接客户现场的环境，这里咱们是将 hdfs client 和 s3 的插件包封装到了 flink 的镜像中，而后通过下面提取出的配置来进行管制对应的存储对接。
● 对于集群状态信息：咱们在部署 flink 的时候咱们会部署好根底组件包，如 zookeeper、redis、mysql 等，同样也能通过下面提取的配置参数进行批改对接内部根底组件。
实际如下：
1) 定义咱们自定义资源形容：
flink 社区领有大量的插件供咱们应用，通过这些插件咱们能扩大一些须要的能力，然而将这些插件都打包到镜像中，那么这个镜像体积势必会变得十分大，这里咱们将这些插件独自抽离进去做成一个独自的根底服务组件，而后通过咱们的业务镜像去援用这些根底组件，在援用这些根底组件后会以 sidecar 模式注入到咱们的业务容器中实现目录绑定，从而实现按需索取也减小了镜像体积的大小。
下面对应资源形容了在 k8s 上利用最根本的部署能力，这里咱们还须要将公共配置进行映射，而后将这些配置裸露到前端。通过这个对立的配置批改入口简化了交付人员对配置文件的筛查和批改。
2) 自动化出包：
咱们在定义好资源对象的形容后，依据定义的资源形容文件将须要的配置提取以及编写利用须要的相干属性，将这些内容放到一个 yaml 文件中，同时编写 dockerfile、启动脚本、编写 jenkinsfile 接入自动化出包流程，最初出包验证。通过分工合作这样一来就能将外部原先大量人工的操作全副主动流程化，提高效率。
3) 部署：
实现部署后的后果如下：
通过点击“服务扩缩容”，咱们能够一键扩缩 taskmanager 的计算资源：
而后咱们能够通过 k8s 的 ingress 资源对象裸露的地址来拜访 flink 的 ui 进行后续 flink 集群的运维操作。
通过以上 flink standalone 容器化咱们简化了主机模式下 flink 的部署、资源管理划分等问题。那么对于利用日志收集和监控，咱们采纳的是 loki 和 prometheus 的动静服务发现。
容器之后，数栈走向何方
只管 Kubernetes 可能解决传统 Hadoop 生态存在的一些痛点问题，然而间隔它能真正成为一个部署大数据利用切实可行的平台还是有很长的一段路要走的：比方为短生命周期与无状态利用设计的容器技术、不同 job 之间短少共享的长久化存储以及大数据平台关怀的调度、平安以及网络相干问题还须要更好的解决方案。当初，数栈正积极参与开源社区，帮忙 Kubernetes 能成为部署大数据应用程序的实用抉择。
对于数栈而言，基于存算拆散的设计理念，应用 Kubernetes 解决了计算资源弹性扩大的问题后，因为计算资源与存储资源的拆散，可能会呈现计算性能升高、存储的弹性无奈保障等问题。将来咱们会思考在存储层应用对象存储，整体架构在计算和底层存储之间加上一层缓存（比方 JuiceFS 和 Alluxio），存储层选型在 OpenStack Swift、Ceph、MinIO 等成熟的开源计划中。
容器之后，咱们并未停下脚步，对于将来咱们有很多在思考的构想，比方利用云化或者云原生技术对立治理资源池，实现大数零碎产品、计算、存储资源池化，实现全局化、集约化的调度资源等等，技术在迭代，咱们的自我变革也从未进行。
开源我的项目技术交换
ChunJun
https://github.com/DTStack/ch…
https://gitee.com/dtstack_dev…
Taier
https://github.com/DTStack/Taier
https://gitee.com/dtstack_dev…
MoleCule
https://github.com/DTStack/mo…
https://gitee.com/dtstack_dev…
欢送退出开源框架技术交换群
（钉钉群：30537511）