学习我们了解了the flink on your的一些集群的一些原理，以及它的一个部署的一些实践的一些操作。在这节课程的话，我们去了解一下flink on k8S的这样的一个集群部署的一些原理，以及相应的一些实践的一些操作。
首先我们来看一下combo test集群的一个架构的一个概览。Carbonates也叫做K8SK8S的话原由是中间有八个这样的一个英文字母，我的一个缩写，所以叫简称叫K8S这里的话我们也用K8S进行相应的这样的一个描述。对于K8S的集群来讲的话，它其实也涵盖了master和worker这样两个角色主要的一个角色。对于master节点上面来讲的话，它主要涵盖了几个主要的一些组件的一些服务。包括像APR server以及ETCD controller manager，还有schedule等级主要它的一个服务。对于master节点来讲的话，它是负责了整个集群的一个管理和资源的一个管理。它和hat PER之间的话，其实都是完成了一个对于我们物理的一些主机，包括一些虚拟机上面的一些资源，进行统一的一个计算资源的一个管理。这里面的话其实就跟哈托比亚其实所产生的一个作用是一致的。
另外一个的话，在master节点里面刚才提到的几种服务。其中比较重要的话有一个叫做APR server。APR server的话它其实是负责了我们整个集群内部的一个rest一个接口APR的一个管理。用户这边所有的一些操作都可以通过APR server这边提供的这样的一个rest APR进行相应的这样的一个操作。包括像我们flink on k8S的这样这种部署模式里面，也使用到的是这样的一种交互的一个模式。它也是去调用的是APR server相关那些接口去操作的这样的一个flink相关的一些部署一些操作。
另外一个的话是ETCD这样的一个高价值的这样的一个从靠高可用键值存储服务。它是用来去保存我carbon native集群所使用到的一些对象，那些状态信息和一些网络信息。这个有点像我们hello平台里面的zoo keeper pod这样的一个键值对的一个存储服务，另外一个controller manager的话，他是负责去管理我们每一个这样的一个node上面执行的一些pod的一些服务的最小的一些副本级。比如说我们在去启动的一个作业的时候，它能够去保证我的这个作业的最小副本能够按照指定的这样的一个数量进行运行。如果不足的情况下，它通过controller manager进行相应的这样的一个重启的这样的一个作用。
对于schedule这边的话，就是说对于用户这边提交的一些作业，通过schedule去把相应的这样的一个pod去绑定到我们的这样的一个node的一个计算节点上面去。刚才其实提到对于我这样的一个work节点上面的话，它其实也是涵盖了几个主要的一些组件。对于我node节点的话，它其实是提供了相应的这样的一些计算的一些资源。它也是集群操作的这样的一个单元。Pod它其实运行的是一个我们所说的这样的一个pod所运行的这样的一个宿主机。对于我们运行作业的过程中的所有的业务的负载，他们都会通过在node上面启动对应的这样的一个pod去进行相应的这样的一个操作。
这地方的话，其实我们可以去了解一下这个pod是什么样的一个概念。它pod是启动在我们的node节点上面，它可以理解成多个相关的一个continuer的一个组合。我们肯定的其实就是我们如果使用过刀客来讲的话，其实就是刀客启动完成了之后，对于镜像启动了之后，它都会运行相应的这样的一个continuer的一个容器。肯听到的一个容器其实就是我们刀客里面的一个动态的一个服务。在一个pod里面的话，它就会涵盖了多个相关的这样的一个continuer的一个组合。可以比如说我们在一个pod里面可以运行多个，比如说task manager的这样一个continuer。也可以去运行您不同的这样的一些服务的一些肯定在一个pod里面。Pod它其实是cob native集群创建和管理的一个最小的一个执行的一个单元。
在我们node节点上面，另外一个还有一个非常关键的一个核心的一个组件叫cb late。这个组件的话，它是运行在node上面的一个二进制的一个服务。它其实是可以去维护和管理我node节点上面的一些容器。可以通过一些命令的这种方式去操作我启动和管理我对应的这样的一个node节点上面的一些continue的一些资源，还有一些pod的一些资源。
在我们node节点的话，另外一个就continued的一个run time。它其实就是我们docker镜像所执行的一个容器的一个执行的一个环境。这个环境的话是负责去管理和创建我对应的这样的一些continued的一些创建和和一些continue的一些销毁的一些操作。我们在重点还有几个主要的一些combinator相关的一些概念。
还有一个叫做刚才其实已经介绍了一个republication controller。Republication controller它其实就是一个RC，RC的话其实就是它保证我们pod的一个高可用的一个APR的一个对象。通过监控我运行中的一个pod来保证我集群中的运行指令数目的一个pod的一个副本。
另外一个就是我们的一个service的一个服务。这个service的话它其实是所有pod的这样的一个抽象。为一组这样的一个pose的话，它可以去提供这样的一个service的一个服务的一个管理。它可以去提供我们不同的这样的一个pose，它的一个入口。举个例子，比如说我们通过service层的话，可以去路由到不同的这样的一个pod节点上面去。在carbonates就是通过service这样的一个抽象层的这样的一个组件去进行一个服务的一些管理。
另外一个就是我们的一个存储服务。存储服务其实我们在使用刀客的一些进程和使用open native这些容器的时候，数据在容器里面往往是无法去进行一个持久化的。在容器关闭或停止了之后，随着容器的一个停止的话，我们里面的数据也会进行消失。所以在刀客里面去提供了这样的一个volume的一个机制，以便将我们的数据持久化到一些外部的一些存储里面。常见的比如说像NFS这样的文件系统，以及我们的本地化的在node节点上面进行一个存储。这个的话其实就是一个这样的一个容器的一个数据卷存储卷的这样的一个服务组件。这其实就是我们在cuba tis或在刀客里面提供的这样的一个数据的一个存储的一个服务。
另外一个的话是config map。Configure map的话其实是提供了保存我们配置数据的一个建筑队。它可以去用来保护单个的这样的一些属性，同时也可以去保存我一些config的一些文件。这个的话后面我们会在部署的时候会用到，我们会将flink conf的这样的一个样本文件去存储到我们的config GM map里面，进行一个持久话。当我们进行集群启动的时候，是通过configure map去拉取我对应的这样的一个flink的一些configure的一些配置。前面其实我们已经讲到了，就是carbonates相关的一些基本的一些概念和它的一个架构的一个组成。
对于我们如果想去将flink集群部署在COO notice集群上面的这样的一个步骤的时候，事先的话我们需要去安装相应的这样的一个集群的一个环境。在这里的话，我们去提供了相应的这样的一个安装的一个教程。这个教程的话可以通过这样的一个链接的话，去看到对应的这样的一个安装的一个服务。这个叫做q board，它提供了一套安装K8S的这样的一个比较完整的一些步骤。可以参考对应的这样的一个步骤进行K8S集群的一个搭建。同时这样的一个q board的这样的一个组件的话，也提供了一个可视化的这样的一个对K8S集群进行管理的这样的一界面。可以方便我们对一些K8S的集群的一些运维的一些操作。如果是初学的这样的一个同学来讲的话，可以通过这种方式更加容易去操作我们的一个carbon ties的一个集群。
我们在cuba s集群安装完毕了之后，下面的话其实是需要去重点关注的，就是我们的一个镜像制作的一个过程。其实我们在on k8S里面，其实都是通过使用的是刀刻的一些镜像，刀客的进。这样的话我们在对于flink的一个集群也是一样的。Flink集群它其实也是需要去构建相应的这样的一个刀刻的一个镜像。
我们刀刻镜像的一个flink集群的一个刀客镜像的一个获取取得方式的话主要有几种，我们把它分为三种。第一种的话，你可以通过我们在docks hub的官方镜像库里面去进行一个下载。这个官方镜像库提供了相应的一些下载的一些包。这个里面的镜像的一个这样的一个镜像的tag的一个说明的话，都是通过flink比如说杠latest或1.11以及1.11杠scala的2.11的版本。通过标签进行对镜像进行一个区分。
另外一种的话就是说我们除了可以直接去使用我们官方提供的这样的一个docker镜像之外的话，我们也可以去自定义docket镜像。自定义的话可以通过我们进行对源码进行一个编译。编译完成了之后，我们可以到flink continued的这样的一个路径里面来，然后去运行我们的有一个bt的这样的一个脚本。
BU的脚本执行的过程中需要去指定几个参数。比如说如果我们是通过本地的这种方式的话，我们可以指定它的一个from local的这样的一个参数。From local参数的话，它就可以把我们编译出来的这样的一些运行的一个环境全部打包到成对应的这样的一个镜像。这个镜像的一个就会在本地产生对应的这样的一个镜像。然后我们再通过镜像的这样的一个上传的这种方式，传递到我们的一个私有仓库里面来。这个私有仓库的话，通过刀客连tag，然后先进行一个标签的一个处理。然后再通过docker push去push到我们的一个私有的镜像仓库里面去。下面的话我们就可以去使用对应我们的这样的一个自定义的一些flink的一些集群的一些镜像。
除了科可以通过源码进行编译之外，我们也可以通过flink提供的官方安装包去构建自定义的一个镜像。这种情况下就会去用户这边需要去先进行一个源码的一个编译，而是直接去把安装包下载下来了之后，去指定我们的一个安装包的一个路径。这个安装包的一个路径的话，可以通过from这样的一个参数进行一个指令，然后同时提供我们的一个镜像的一个名称。它也可以去构建出来我对应的这样的一个docker的一个镜像。
所有的一些基本操作全部都完成了。包括docker镜像那些构附件以及我们的carbonates的集群的一个安装的操作全部都ready了之后。我们下面看一下我们在flink on k8S上面如何进行对于我们的一个flink集群的一个部署。在前面的章节我们已经了解到flink基于K8S可以去支持session model，然后per job的model以及我们的application model。首先我们来看一下基于session的这种模式的话，它的一个集群部署的一个架构的一个原理。同样的当我们去构建好了相应的这样的一个K8S的集群了之后，我们去提交我们的flink的一个集群，让在K8S这样的一个class manager上面去运行。
从图中我们也可以看得到，flink其实在Q8S上面也是启动了这样的一个flink job manager的一个deployment。这个job manager deployment其实就涵盖了我们所有的flink的master节点的一些主要的服务。它其实也是在这样的一个deployment里面去启动了一个job manager的一个pod b manager的一个pod里面的话可以看到它其实涵盖了flink job manager的一个continuer。这个continuer其实就是我们的一个flink的一个进程。就是我们的一个master节点的一个进程。它也涵盖了resource manager，job manager以及我们dispatcher等主要的一些集群的一些组件。
我们可以从这张图里面可以看得到。首先我们最外面的话是通过一个deployment，然后去部署它的一个然后里面含盖了我们的一个对应的这样的一个flink job manager的一些container的这样的一个集群的一个服务。然后当我们这样的一个服务去启动完成了之后，我们需要去启动几个相应的这样的一个service。
第一个service的话就是我们的一个job manager service。前面其实提到对于我外面的这样的一些数据的话，就是外面的一些访问的话，都需要通过service这样的一个入口，然后才能到我的这样的一个pod里面去。对于我job manager的话，因为像task manager以及我们的外面的用户这边的话，都需要通过要通过一些网络的方式进行对我们这样的一个pod里面的这样的一个job manager进行一个网络的一个通信。所以说这个地方的话，我们需要去安装一个job manager的这样一个service。然后保证我的外面的这样的一些组件，能够跟我的一个job manager进行一个有效的一个通信。
另外一个的话，对于我们像基于session的这种model的话，用户往往需要去通过我们的一个8081的这样的一个端口，以及我们的一个一个管理的一个页面。我们需要通过一些，需要去进行对管理页面进行一些操作。这个时候的话，就需要我们装一个flink的一个rest的一个服务的一个这样的一个service。这个service的话其实就是暴露出来我们的一个8081的这样的一个端口给用户。这个用户的话才能去通过集群以外的这样的一些服务，或者集群以外的一些RP才能够进入到我们的一个carbonates集群里面来。然后去访问到我对应的这样的一个flink的一些集群的一些服务。
这样的话，其实我们可以看得到，对于我在K8S上面部署我们的session的集群的时候，它涵盖了几个主要的一些点。第一个就是我们首先得有我们的jump manager的一个deployment，他去部署我对应的这样的一个flink的jump manager服务。接下来的话就是我们的task manager的一个deployment。他是负责去部署我对应的这样的一些task manager的一些服务。另外一个的话就是我们的一个UR的一个service，还有我们的job manager的一个service。这个其实都是在K8S上面去部署我们flink集群的时候，它是需要去涵盖的几个主要的一些组件。
对于我们来讲的话，就是说我们用户这边当一旦集群全部都启动完成了之后，第一步他就可以去提交对应的这样的一个的去通过UI service。也就是说我们暴露出外面的这样的一个外部的一个的服务的接口，去提交到我们的一个机型上面。然后再通过job manager service去连接到我对应的这样的一个drop manager服务里面，去启动对应的这样的一个drop manager的一个服务OK。接下来的话，其实就是通过去调用K8S的这样的一个服务，去启动我的task manager的一些pod的这样的一些镜像和一些continuer。这个地方的话其实就是我们整个flink on k8S的这样的一个集群的一个架构。
另外一个的话，这个地方需要去补充一点的话，就是我们flink的一个config map。这个configure map的话，其实刚才也在前面的一个章节里面讲到，我们所有的flink相关的一些配置文件都会在flink conflict map里面去进行一个存储。它也会在我们的这个job manager的服务以及我们task manager的服务启动的过程中，它都会去到我们的这个configure map里面去获取我对应的这样的一些flink的一些配置。这样的话，其实就整个来讲的话，我们整个的一个集群就完成了这样的一个flink on k8S的一个部署以及启动。我所有的话其实跟我们的flink on your其实有一些相似之处。对于我们破job的这种模式，在K8S集群上面去运行的时候的话，其实跟我们的这样的一个三摄模式的话，它之间的话也是有一定的区别的。
最主要的几个部分，第一个flink的这样的一个job manager的一个deployment和我们的一个flink task manager的一个deployment基本上保持不变。同样的job manager的一个service，它可以提供我们的一个动态端口的这样的一个，外部数据的一个访问的这样的一个service。这个的话也是跟我们session的一个集群上面是保持一致的。另外一个的话像config map以及我们的一个UR service，其实也是根据我们session model里面其实也是一样的。
唯一的区别就是在这里我们需要去在启动我们的一个job的一个application的时候，我们需要去把我们的一个架包应用的一个架包的话，是需要去从我们的一个本地的一个路径里面，或者说通过NFS这样一种文件系统里面去搂到我的这样的一个镜像里面了之后，然后再进行一个这样的一个启动。的话，我们应用的架包的话是通过外部的这种方式去把它加载进来。而不是通过我们在三省模式里面的话。我们可以通过用户这边进行一个提交，然后再进行一个上传。我们的一个dependency到我们的一个job manager里面，然后再进行相应的一些提交和执行的一个操作。对于我们拍照模式的话，这个里面的架包的一些dependency的一些信息都是通过本地或通过一些外部的这样的一个存储介质，进行一个炸包的一个获取。然后再进行一个drop manager和task manager的一些初始化和启动的一些操作。
同样的，我们在这个地方的话，其实并没有提供相应的用户可以通过再去提交job graph的这样一种模式去提交相应的这样的一个作业。因为我们在poor job这种模式下，job manager其实是独享的。它不允许我们再去启动多个这样的一个drop的一个管理的一个job manager的一个操作。
所以说这个地方的话就是我们整个flink on corporates的这样的一个集群的一个在pod rob模式下面的一个集群的一个架构。我们前面其实也讲到了，就是在我们的整个的这个过程里面的话，其实对于flink on k8S的话需要几个比较核心的一个资源配置。在K8S里面，不管是这个map service还是development，它其实都是一些资源。这些资源的话我们在flink里面的话是相有相应对应的一些资源的一些配置。
首先的话，其实不管是在我们的session的model，还是我们的一个per job的模式。我们每个都需要去配置相应的这样的一个flink conf的一个config gm map的一个资源对象。用于存储我们的flink conf里面的Young文件以及log for g等一些配置信息。这个时候的话，flink job manager和task manager启动的时候，都会去获取我们的配置好的这样的一些配置文件。也是通过config map进行一个获取。
另外一个就是drop manager的一个service。我们通过service name和pod去暴露我们的一个drop manager的一个服务。让我们外面的task manager能够连接到我的一个job manager上面去。这个的话就是需要去启动相应的这样的一个job manager的一个service。这个job manager service去连接就提供了这样的一个叫maner服务暴露的这样的一个过程。
另外一个就是job manager的一个deployment，它其实是定义我们job manager port的一个副本的一个数量和版本等这些信息。他去保证我POS至少有一个这样的一个副本。这个deployment的话其实就是描述了我们整个job manager的一个部署的一个整个的一个抽象。
然后另外一个的话就是task manager的一个deployment。它是定义了我们task manager里面的这个pose的一个副本的数量和一些版本的一些信息。从而保证我的这样的一个pose里面可以至少有一个这样的一个副本的一个保障。整体下来的话，我们对于flink on k8S里面的话，需要去进行这么多的这样的一个资源的一个配置。
首先我们来看一下对于configure map的一个配置。Config map其实可以看得到，其实左右边的话其实就是一个flink config figuration configure map一个配置。可以看得到在data这样的一个数据集里面，我们将flink conf的一个样本文件，通过文本的这种方式去把它进行一个配置。所有的一些包括集群的job manager、task manager, 所有的集群的一些配置相关的参数，去写到configure map里面来。Config map里面的话，最后还是以ym的这种文件的形式去保存。当我们去创建的这个config map的时候，是通过bbn ates里面提供的这个cuba AE copulate这样的一个工具。
当我们去创建flink configure map的时候，其实也是通过这样的一个copulate，这样的一个工具，它去create一个flink config的这样的一个Young。这个时候的话，其实我们config map的一个资源对象就已经成功创建完成。如果我们想去更改，或者说我们想去调整我们的一个flink的一些配置参数的时候，同样的你也需要去到我们的一个flink configuration configure map的一个ym里面去进行一个配置。这个的话其实是需要用户这边需要去注意的。
对于我们刚才提到的这个job manager的一个service，job manager的一个service的一个创建的一个过程，其实相对来说比较简单。同样它也需要一个job manager service的一个样本文件的一个描述。样本文件的话其实看到了就这么几行的一个配置。它其实会在这里面的话配置的它的一个看的类型，就是我们的一个commonalities里面的service。然后它的一个meta data的话是flink job manager。另外一个的话，它的一个类型的话，这个里面的话是指定的是一个cluster的一个RP，也就是我们的集群那个RP。
在这个地方的话，我们需要去配置几个信息。第一个就是我们的一个RPC的一个端口，以及我们的一个block server。Block server的话就是在后面会讲原理的时候，它其实提供了我们的一个所有的基于上传到我们的flink集群里面提供的一个这样的一个文件的一个服务。然后这个服务的话可以把相关的一些价包的一些信息去传到我对应的这样的一个集群里面。然后再通过对应的K去获取。在整个flink集群内部的话，可以达到一个资源共享的这样的一个block的一个server对象的一个管理的一个服务。
另外一个的话就是指定我们的一个web UR里面的这个8081的这样的一个端口。这个端口其实也是我们要去把job manager的这样的一个pod去暴露出来了这样的一个服务。这个地址就是我们的一个8081，在这里面的话就是我们的有一个需要去指定它的一些参数，这个其实就是我们的一个drop manager的一个service的一个配置。
前面其实提到我们在配置flink job manager service的时候，它其实是提供了我们的一个pod的一个统一的一个入口。但是这个pod的统一的一个入口的话，仅是在我们这样的一个cover ites集群内部的话，实现了这样的一个互通。但是它对于我们这样的一个covenanted集群以外的这样的一些包括一些RP或一些服务去访问的时候，它其实是不能去进行一个有效的一个访问的。这个时候的话，其实我们需要把我们的这样的一个端口进行一个代理。我们这样的话才能够通过我们的，比如说PC或通过一些外部的这样的一些地址，去对我们这样的一个flink的一个集群进行访问。这个时候的话就需要对于我们flink用web UR进行访问的一个进行一个配置。
这个时候的话，我们可以看到对于在flink on k8S里面的话，提供了3种方式可以去将我们的这样的一个端口暴露出来。第一个的话就是我们可以用我们的cube late这样的一个工具，然后去进行一个proxy的一个构建。我们直接通过这样的一个在终端里面输入一个proxy的一个命令的话，就可以把我们的这样的一个代理启动。在外面的话就可以通过我们代理的这种形式进行对我们的一个集群的一个访问。另外一个就是我们提供K8S里面的一个put forward的这种方式。
端口的一个转发。端口的转发的话是需要去指定job manager它的一个pod的一个名称。同时要告诉他的一个端口。把8081的这样的一个端口转发到外面的这样的一个8081的一个端口，这个的话其实是需要我们在通过这种方式可以去进行。
另外一个就是我们可以通过node pod的这种方式。Node pod的话其实就是是我们去创建我们的一个UI的一个11个，它其实也是一种可以将我们的一个端口暴露出来的一种方式。我们在右边可以看得到，我们这个地方的话也是以看的为service这种方式。但是我们的一个资源描述符是node port。它可以去帮我们把我们的这样一个内部的一个node l port的话，就是说把我们对应的这样的一个内部的一个端口8081集群内部的一个8081的一个端口。通过node pod再进行一个转发，然后转发到30081的这样的一个端口。这样我们就能够通过我们的一个暴露出来的一个node pod的端口，加上我们的主机的node的一个地址，就可以访问到我们的flink集群。
整个来讲的话，其实这样三种模式都是可以访问到我们的一个flink的一个集群。也就是说在我们carbonate集群以外，访问我们的一个flink的一个集群的一个氟。当我们所有的一些配置完成了之后，我们比如说我们把对应的这样的一个服务端口暴露出来。我们就可以通过这样的一个rest port去提交到我们对应的这样的一个作业。这个的话可以通过杠M的这种形式去指定。
接下来的话我们来看一下flink on k8S的一个集群部署。在三胜model的时候，主要去创建了几个服务。首先我们来看一下，我们需要去创建job manager的一个deployment的时候，我们需要去创建的一个drop manager的一个session的一个deployment。这个的话其实是我们在实践的课程里面可以看得到。另外一个task manager的一个deployment的话，一样的去创建它的一个task manager session的一个deployment。然后当这两个deployment全部创建完成了，同时前面的一些公用的一些服务全部都创建完成了之后。我们接下来就可以通过这种方式去提交我对应的这样的一个作业。当我们如果想去停止集群的时候，可以直接去指定delete这种命令的话，去删除对应启动的这样的一个pod的一个资源，相应的它就会把对应的这样的一个deployment进行一个删除。
在per job的这种模式下的话，其实也是一样的。我们创建job manager的一个deployment的话，也是通过copulate这样的一个create job manager的一个job的这样的一种ym的一个文件。然后另外一个可以去创建task manager的一个deployment，也是通过这样的一个命令进行一个创建。停止的时候也是通过这种方式。通过本节课的学习，我们掌握了弗林刚K8S的部署的一些基本原理和一些资源配置的一些定义，以及在不同的一些运行的模式，30 model和per job模式的一些相关的一些配置。在下节课课程的话，我们是将通过一些具体的实践来去加深对福临刚K8S集群部署的一个认识和一些了解。