关于云计算:Flink-Native-Kubernetes实战

欢送拜访我的 GitHub

https://github.com/zq2599/blog_demos

内容：所有原创文章分类汇总及配套源码，波及 Java、Docker、Kubernetes、DevOPS 等；

回顾 Flink Kubernetes

<font color=”blue”>Flink Kubernetes</font> 与 <font color=”blue”>Flink Native Kubernetes</font> 是不同的概览，先回顾一下 Flink Kubernetes：

1. 如下图，从 1.2 版本到目前最新的 1.10，Flink 官网都给出了 Kubernetes 上部署和运行 Flink 的计划：

1. 在 kubernetes 上有两种形式运行 flink：<font color=”blue”>session cluster</font> 和 <font color=”blue”>job cluster</font>，其中 session cluster 是一套服务能够提交多个工作，而 job cluster 则是一套服务只对应一个工作；
2. 下图是典型的 session cluster 部署操作，可见要害是筹备好 service、deployment 等资源的 yaml 文件，再用 kubectl 命令创立：

对于 Flink Native Kubernetes

1. 先比照官网的 1.9 和 1.10 版本文档，如下图和红框和蓝框所示，可见 <font color=”blue”>Flink Native Kubernetes</font> 是 1.10 版本才有的新性能：

1. 看看 Native Kubernetes 是如何运行的，如下图，创立 session cluster 的命令来自 Flink 安装包：

1. 更乏味的是，提交工作的命令也来自 Flink 安装包，就是咱们平时提交工作用到 <font color=”blue”>flink run</font> 命令，如下图：

1. 联合官网给出的提交和部署流程图就更清晰了：kubernetes 上部署了 Flink Master，由 Flink Client 来提交 session cluster 和 job 的申请：

Flink Kubernetes 和 Flink Native Kubernetes 的区别

至此，能够小结 Flink Kubernetes 和 Flink Native Kubernetes 的区别：

1. <font color=”blue”>Flink Kubernetes</font> 自 1.2 版本首次呈现，<font color=”red”>Flink Native Kubernetes</font> 自 1.10 版本首次呈现；
2. <font color=”blue”>Flink Kubernetes</font> 是把 JobManager 和 TaskManager 等过程放入容器，在 kubernetes 治理和运行，这和咱们把 java 利用做成 docker 镜像再在 kubernetes 运行是一个情理，都是用 kubectl 在 kubernetes 上操作；
3. <font color=”red”>Flink Native Kubernetes</font> 是在 Flink 安装包中有个工具，此工具能够向 kubernetes 的 Api Server 发送申请，例如创立 Flink Master，并且能够和 Flink Master 通信，用于提交工作，咱们只有用好 Flink 安装包中的工具即可，无需在 kubernetes 上执行 kubectl 操作；

Flink Native Kubernetes 在 Flink-1.10 版本中的不足之处

1. Flink Native Kubernetes 只是 Beta 版，属于试验性质（官网原话：still experimental），<font color=”red”> 请勿用于生产环境！</font>
2. 只反对 session cluster 模式（一个常驻 session 执行多个工作），还不反对 Job clusters 模式(一个工作对应一个 session)

只管还没有进入 Release 阶段，但这种操作模式对不相熟 kubernetes 的开发者来说还是很敌对的，接下来通过实战来体验吧；

官网要求

为了体验 Native Kubernetes，flink 官网提出了下列前提条件：

1. kubernetes 版本不低于 <font color=”blue”>1.9</font>
2. kubernetes 环境的 DNS 是失常的
3. KubeConfig 文件，并且这个文件是有权对 pod 和 service 资源做增删改查的（kubectl 命令有权对 pod 和 service 做操作，也是因为它应用了对应的 KubeConfig 文件），这个文件个别在 kubernetes 环境上，全门路：<font color=”blue”>~/.kube/config</font>
4. pod 执行时候的身份是 service account，这个 service account 曾经通过 RBAC 赋予了 pod 的减少和删除权限；

后面两点须要您本人保障已达到要求，第三和第四点当初先不用关怀，前面有具体的步骤来实现；

实战环境信息

本次实战的环境如下图所示，一套 kubernetes 环境（版本是 1.15.3），另外还有一台 CentOS7 电脑，下面已部署了 flink-1.10（这里的部署是说把安装包解压，不启动任何服务）：

筹备结束，开始实战了~

实战内容简介

本次实战是在 kubernetes 环境创立一个 session cluster，而后提交工作到这个 sessionc cluster 运行，与官网教程不同的是本次实战应用自定义 namespace 和 service account，毕竟生产环境个别是不容许应用 default 作为 namespace 和 service account 的；

实战

1. 在 CetnOS7 电脑上操作时应用的是 root 账号；
2. 在 kubernetes 的节点上，确保有权执行 kubectl 命令对 pod 和 service 进行增删改查，将文件 <font color=”blue”>~/.kube/config</font> 复制到 CentOS7 电脑的 <font color=”blue”>~/.kube/</font> 目录下；
3. 在 kubernetes 的节点上，执行以下命令创立名为 <font color=”blue”>flink-session-cluster</font> 的 namespace：

kubectl create namespace flink-session-cluster

1. 执行以下命令创立名为 <font color=”blue”>flink</font> 的 serviceaccount：

kubectl create serviceaccount flink -n flink-session-cluster

1. 执行以下命令做 serviceaccount 和角色的绑定：

kubectl create clusterrolebinding flink-role-binding-flink \
  --clusterrole=edit \
  --serviceaccount=flink-session-cluster:flink

1. SSH 登录部署了 flink 的 CentOS7 电脑，在 flink 目录下执行以下命令，即可创立名为 <font color=”blue”>session001</font> 的 session cluster，其中 -Dkubernetes.namespace 参数指定了 namespace，另外还指定了一个 TaskManager 实例应用一个 CPU 资源、4G 内存、内含 6 个 slot：

./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.jobmanager.service-account=flink \
  -Dkubernetes.cluster-id=session001 \
  -Dtaskmanager.memory.process.size=8192m \
  -Dkubernetes.taskmanager.cpu=1 \
  -Dtaskmanager.numberOfTaskSlots=4 \
  -Dresourcemanager.taskmanager-timeout=3600000

1. 如下图，控制台提醒创立胜利，并且红框中提醒了 flink web UI 的拜访地址是 <font color=”blue”>http://192.168.50.135:31753</font>：

1. 下载镜像和启动容器须要肯定的工夫，能够用 <font color=”blue”>kubectl get</font> 和 <font color=”blue”>kubectl describe</font> 命令察看对应的 deployment 和 pod 的状态：

1. pod 启动胜利后拜访 flink web，如下图，此时还没有创立 TaskManager，因而 Slot 为零：

1. 回到 CentOS7 电脑，在 flink 目录下执行以下命令，将官网自带的 <font color=”blue”>WindowJoin</font> 工作提交到 session cluster：

./bin/flink run -d \
  -e kubernetes-session \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.cluster-id=session001 \
  examples/streaming/WindowJoin.jar

1. 控制台提醒提交工作胜利：

1. 页面上也会同步显示减少了一个 TaskManager，对应 6 个 slot，曾经用掉了一个：

1. 再间断提交 5 次雷同的工作，将此 TaskManager 的 slot 用光：

1. 这时候再提交一次工作，按理来说应该减少一个 TaskManager，可是页面如下图所示，TaskManager 数量还是 1，并没有减少，并且红框中显示新增的工作并没有失常运行起来：

1. 在 kubernetes 环境查看 pod 状况，如下图红框所示，有个新建的 pod 状态是 Pending，看来这就是第七个工作不能执行就是因为这个新建的 pod 无奈失常工作导致的：

1. 再看看这个 namespace 的事件告诉，如下图红框所示，名为 session001-taskmanager-1- 2 的 pod 有一条告诉信息：<font color=”blue”> 因为 CPU 资源有余导致 pod 创立失败 </font>：

1. 穷到没钱配置 kubernetes 环境，连一核 CPU 都凑不齐：

1. 一时半会儿也找不出多余的 CPU 资源，惟一能做的就是升高 TaskManager 的 CPU 要求，方才配置的是一个 TaskManager 应用一核 CPU，我打算升高一半，即 <font color=”red”>0.5 核 </font>，这样就够两个 TaskManager 用了；
2. 您可能会纳闷：怎么会有 0.5 个 CPU 这样的配置？这个和 kubernetes 的资源限度无关，kubernetes 对 pod 的 CPU 限度粒度是千分之一个 CPU，也是就是在 kubernetes 中，配置 1000 单位的 CPU 示意应用 1 核，咱们配置 0.5 核，不过是配置了 500 单位而已（所以我还能够更穷 ….）
3. 接下来的操作是先停掉以后的 session cluster，再从新创立一个，创立的时候参数 <font color=”blue”>-Dkubernetes.taskmanager.cpu</font> 的值从 1 改为 <font color=”red”>0.5</font>
4. 在 CentOS7 电脑上执行以下命令，将 session cluster 停掉，开释所有资源：

echo 'stop' | \
  ./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.cluster-id=session001 \
  -Dexecution.attached=true

1. 控制台提醒操作胜利：

1. 稍等一分钟左右，再去查看 pod，发现曾经全副不见了：

1. 在 CentOS7 电脑的 flink 目录下，执行以下命令，和之前相比，惟一变动就是 <font color=”blue”>-Dkubernetes.taskmanager.cpu</font> 参数的值：

./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.jobmanager.service-account=flink \
  -Dkubernetes.cluster-id=session001 \
  -Dtaskmanager.memory.process.size=4096m \
  -Dkubernetes.taskmanager.cpu=0.5 \
  -Dtaskmanager.numberOfTaskSlots=6 \
  -Dresourcemanager.taskmanager-timeout=3600000

1. 从控制台提醒失去新的 flink web UI 端口值，再拜访网页，发现启动胜利了：

1. 像之前那样提交工作，间断提交 7 个，这一次很顺利，在提交了第七个工作后，新的 TaskManager 创立胜利，7 个工作都胜利执行了：

1. 用 <font color=”blue”>kubectl describe pod</font> 命令查看 TaskManager 的 pod，如下图红框所示，可见该 pod 的 CPU 用量是 <font color=”red”>500 单位 </font>，合乎之前的揣测：

这里再揭示一下，升高 CPU 用量，意味着该 pod 中的过程获取的 CPU 执行工夫被升高，会导致工作执行变慢，所以这种办法不可取，正确的思路是确保硬件资源能满足业务需要(像我这样穷到一核 CPU 都凑不齐的状况还是不多的 ….)

清理资源

如果已实现 Flink Native Kubernetes 体验，想彻底清理掉后面的所有资源，请依照以下步骤操作：

1. 在 web 页面点击 Cancel Job 进行正在运行的工作，如下图红框：

1. 在 CentOS7 电脑上进行 session cluster：

echo 'stop' | \
  ./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.cluster-id=session001 \
  -Dexecution.attached=true

1. 在 kubernetes 节点清理 service、clusterrolebinding、serviceaccount、namespace：

kubectl delete service session001 -n flink-session-cluster
kubectl delete clusterrolebinding flink-role-binding-flink
kubectl delete serviceaccount flink -n flink-session-cluster
kubectl delete namespace flink-session-cluster

1. 所有 cluster session 相干的 ConfigMap、Service、Deployment、Pod 等资源，都通过 kubernetes 的 <font color=”blue”>ownerReferences</font> 配置与 service 关联，因而一旦 service 被删除，其余资源被被主动清理掉，无需解决；

至此，Flink Native Kubernetes 相干的实战就实现了，如果您也在关注这个技术，心愿本文能给您一些参考

欢送关注公众号：程序员欣宸

微信搜寻「程序员欣宸」，我是欣宸，期待与您一起畅游 Java 世界 …
https://github.com/zq2599/blog_demos