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

https://github.com/zq2599/blog_demos

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

Flink Kubernetes 与 Flink Native Kubernetes 是不同的概览，先回顾一下 Flink Kubernetes：

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

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

先比照官网的 1.9 和 1.10 版本文档，如下图和红框和蓝框所示，可见 Flink Native Kubernetes 是 1.10 版本才有的新性能：

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

更乏味的是，提交工作的命令也来自 Flink 安装包，就是咱们平时提交工作用到 flink run 命令，如下图：

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

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

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

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

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

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

kubernetes 版本不低于 1.9
kubernetes 环境的 DNS 是失常的
KubeConfig 文件，并且这个文件是有权对 pod 和 service 资源做增删改查的（kubectl 命令有权对 pod 和 service 做操作，也是因为它应用了对应的 KubeConfig 文件），这个文件个别在 kubernetes 环境上，全门路：~/.kube/config
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 的；

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

kubectl create namespace flink-session-cluster

执行以下命令创立名为 flink 的 serviceaccount：

kubectl create serviceaccount flink -n flink-session-cluster

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

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

SSH 登录部署了 flink 的 CentOS7 电脑，在 flink 目录下执行以下命令，即可创立名为 session001 的 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

如下图，控制台提醒创立胜利，并且红框中提醒了 flink web UI 的拜访地址是 http://192.168.50.135:31753：

下载镜像和启动容器须要肯定的工夫，能够用 kubectl get 和 kubectl describe 命令察看对应的 deployment 和 pod 的状态：

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

回到 CentOS7 电脑，在 flink 目录下执行以下命令，将官网自带的 WindowJoin 工作提交到 session cluster：

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

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

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

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

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

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

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

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

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

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

控制台提醒操作胜利：

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

在 CentOS7 电脑的 flink 目录下，执行以下命令，和之前相比，惟一变动就是 -Dkubernetes.taskmanager.cpu 参数的值：

./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

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

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

用 kubectl describe pod 命令查看 TaskManager 的 pod，如下图红框所示，可见该 pod 的 CPU 用量是 500 单位 ，合乎之前的揣测：

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

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

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

在 CentOS7 电脑上进行 session cluster：

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

在 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

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

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

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

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

欢送拜访我的 GitHub

回顾 Flink Kubernetes

对于 Flink Native Kubernetes

Flink Kubernetes 和 Flink Native Kubernetes 的区别

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

官网要求

实战环境信息

实战内容简介

实战

清理资源

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