共计 3540 个字符，预计需要花费 9 分钟才能阅读完成。
Flink 作为大数据和实时数据部门重要的框架和引擎，扮演着重要的角色，Flink 的应用也越来越多，集群治理也变得越来越不容易。为了反对 Flink 上云，容器云团队也对其做了大量的摸索工作，以保障 Flink 可能更好的且安稳的进行容器化。
一：部署形式抉择
目前信也上云的 Flink 版本是 Flink 1.11，Flink 1.11 基于 kubernetes 的部署模式有：Session、Per-job、Application 三种模式，上面阐明三种部署模式的比照
这三种模式的区别在于：
- 集群生命周期和资源隔离保障
- 应用程序的
main()办法是在客户端还是在集群上执行
图：1-1
Application 模式
用户程序的 main 办法将在集群中而不是客户端运行，用户将程序逻辑和依赖打包进一个可执行的 jar 包里，集群的入口程序 (ApplicationClusterEntryPoint) 负责调用其中的 main 办法来生成 JobGraph。Application 模式为每个提交的应用程序创立一个集群，该集群能够看作是在特定应用程序的作业之间共享的会话集群，并在应用程序实现时终止。在这种体系结构中，Application 模式在不同利用之间提供了资源隔离和负载平衡保障。在特定一个应用程序上，JobManager 执行 main() 能够节俭所需的 CPU 周期，还能够节俭本地下载依赖项所需的带宽。
Per-Job 模式
per-job 模式是为每个提交的作业启动 Flink 集群，领有本人的 jobmanager 和 taskmanager。所以在启动的时候该作业模式可能提早会比拟高点。作业实现后，集群将销毁，并清理所有的资源。此模式容许更好的资源隔离，因为运行有问题的作业也不会影响到其它作业。
Session 模式
session 模式假设一个曾经在运行的集群，并应用该集群的资源来执行任何提交的应用程序。在同一个（会话）集群中执行的应用程序应用雷同的资源，并因而竞争雷同的资源。你并没有为每一项工作付出全副的开销。然而，如果其中一个作业行为不当或导致 TaskManager 解体，则该 TaskManager 上运行的所有作业都将受到该故障的影响。除了对导致失败的作业造成负面影响外，这意味着一个潜在的大规模复原过程，即所有重新启动的作业同时拜访文件系统，并使其对其余服务不可用。另外，让一个集群运行多个作业意味着 JobManager 的负载更大，JobManager 负责记录集群中的所有作业。这种模式非常适合于启动提早十分重要的短作业，例如交互式查问。
目前信也科技在服务的容器化方面的反对曾经很成熟，有一套欠缺的构建公布流程，所以通过比照 Flink 的几种部署模式的优缺点，最终咱们采纳了 Application 的部署形式，该形式相比于其它两种模式长处显著，领有更好的隔离性，同时对资源的利用率也高，也更合乎咱们现有的公布流程标准。二：Flink on k8s
图：2-1
创立 Flink Kubernetes 集群时，Flink 客户端将首先连贯到 Kubernetes ApiServer 提交集群，包含 ConfigMap，Job Manager。而后，Kubernetes 将创立 JobManager，在此期间，Kubelet 将拉取镜像，筹备并挂载，而后执行启动命令。启动 JobManager 命令后，Dispatcher 和 KubernetesResourceManager 可用，并且群集已筹备好承受一个或多个作业。当用户通过 Flink 客户端提交作业时，客户端将生成 Job graph，并将其与用户 jar 一起上传到 Dispatcher。JobManager 向 KubernetesResourceManager 申请 slots 资源。如果没有可用的 slots，资源管理器生成 TaskManager 并在集群中注册。这是 Flink 在在 kubernetes 外部的简要交互方式。
三：构建公布
信也采纳的 Flink 版本为 1.11, 部署模式是 Application。咱们把每个 job 形象成一个利用。所以每个 job 的公布流程也就是信也一般利用一样的公布流程:
- 申请 Flink job 相干的利用
- 非 1.11 版本的 job 降级到 1.11 版本，并集成 maven 镜像构建打包插件
- 通过 aladdin 打包平台，打包镜像。通过 stargate 平台抉择相应利用和打包的镜像版本进行 job 的公布
1. 构建
图：3-1
2. 公布
图：3-2
在程序进行降级的时候，进行 job 能够采纳 savepoint 的机制来放弃作业的残缺快照，在下次启动的时候能够利用保留的 savepoint 来进行作业的复原四：监控告警
Flink 部署在 kubernetes 上后，job 的监控和运维也须要相应的配套设施才行。当 Flink job 在运行过程中挂掉了，咱们怎么能力监控到并产生告警？job 在运行过程中可能会呈现不衰弱的运行，比方 checkpoint 工夫过长、gc 频繁、或者产生了重启。这些咱们又如何监控？
1. 配置探针
Flink job 在运行过程中由 jobmanager 进行资源管理、作业调度，所以咱们为每个 Flink job 中的 jobmanager 增加探针，检测 job 是否失常运行，当衰弱检测不通过，咱们通过 zmon 平台进行告警
readinessProbe:
httpGet:
path: /jobs/overview
port: 8081
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 3
periodSeconds: 5
successThreshold: 3
failureThreshold: 122. 指标收集
目前公司上云的利用都是采纳 prometheus 进行指标进行收集，所以 Flink 的指标收集咱们依然采纳 prometheus 进行收集。利用 grafana 进行展现（下图进展现局部）
图：4-1
1. 对于零碎指标最常关注的是作业的可用性，如 uptime (作业继续运行的工夫)、fullRestarts (作业重启的次数)
2. 另外是 checkpoint 相干信息，例如最近实现的 checkpoint 的时长 (lastCheckpointDuration)、最近实现的 checkpoint 的大小(lastCheckpointSize)、作业失败后复原的能力(lastCheckpointRestoreTimestamp)、胜利和失败的 checkpoint 数目(numberOfCompletedCheckpoints、numberOfFailedCheckpoints) 以及在 Exactly once 模式下 barrier 对齐工夫(checkpointAlignmentTime)五：高可用
作业可能因为机器保护、硬件故障导致挂掉，这时候如何疾速复原作业也成为了须要思考的问题。目前咱们采纳的形式是能够通过程序的形式主动复原作业
如下图：
图：5-1
留神：
因为局部 job 并不实用这种形式来复原 job，所以在平台能够设置，如果 job 设置了启用高可用，默认状况下，检测到 job 挂掉，会采纳 checkpoint 的机制来间接复原 job，如果没有设置，job 挂掉后会告诉对应的 job 负责人，负责人收到告警后，须要手动来复原 job六：遇到的问题
1. 网络问题
Flink 在部署的过程中须要拜访 Apiserver, 这时候 job 须要通过 clusterip 来拜访 ApiServer，而公司集群采纳的是 macvlan 网络是无法访问 clusterip 的，所以为了反对 Flink 部署，咱们在大数据集群通过给对应 pod 增加双网卡的形式（一块是 macvlan，一块是 bridge）
2. ip 治理
因为 Flink 部署在 kubernetes 是采纳的 deployment 形式部署，这种形式部署的 pod，咱们无奈治理相干 Flink pod 的 ip，所以容器云团队，部署了一个 webhook 的服务，来监听集群 pod 的相干事件，来调配和开释相干的 ip
图：6-1
3. 配置问题
Flink 在运行过程中在做 checkpoint 和 savepoint 时都依赖于 hdfs，所以 pod 在运行过程中是须要拜访 hdfs 服务的，咱们是通过，将 hdfs-site.xml、core-site.xml 相干配置提前配置到 kubernetes 集群 Configmap 里，并在 Flink 启动过程中指定相应的 ConfigMap
图：6-2
信也容器云平台
stargate 作为信也科技的容器云平台，是基于 kubernetes 开发的一套企业级容器治理平台，具备业务场景笼罩全面、生态丰盛的特点，目前曾经开源
开源地址：https://github.com/ppdaicorp/stargate扫描加群探讨（备注：stargate）