学习我们相识了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集群部署的一个认识和一些相识。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
