kubeadm生产token，加入新节点

默认kubeadm在安装集群后，会打印出join新节点的命令。不过只有24小时的有效期

若期望新增节点，则需要重新生成token，默认是24小时有效期，这里可以通过设置ttl=0为永久有效

输出：

查看token列表

查看--discovery-token-ca-cert-hash值

1

提取登录接口中的token值 添加边界提取器,获取token值,填写引用名称

2

使用_setProperty函数设置为全局变量 添加BeanShell PostProcessor,打开函数助手使用_setProperty函数,填写要设置的全局变量名称及要将哪个变量设置为全局变量,将函数助手生成的结果复制到BeanShell PostProcessor

3

使用函数助手_property获取全局变量 打开函数助手使用_property函数,填写全局变量名称及存储结果的变量名,点击生成复制结果

4

将复制的结果添加到下一个线程组的信息头管理器作为全局使用即可

本文会以 最简单 、 最直接 、 最完整 的方式记录kubernetes（下面统称K8S）单master多工作节点（worker nodes）的集群步骤

首先要简单了解一下本文的3个核心概念：

内存建议至少4G

问：如何查看主机名？

答：执行命令hostname

问：如何修改主机名？

答：永久生效的做法：执行命令vi /etc/hostname，把第一行去掉（不能注释掉，要去掉），然后重新写上自定义的主机名（注意命名规范），保存并重启后生效；

临时生效的做法：执行以下命令

问：如何查看MAC地址？

答：执行命令ip link，然后看你的第一网卡

问：如何查看product_uuid？

答：执行命令sudo cat /sys/class/dmi/id/product_uuid

注意：30000-32767这个端口范围是我们创建服务的端口必须要设置的一个范围（如果设置范围以外的会有限制提示并创建失败），这是K8S规定的。

另外，如果你要直接关闭防火墙可以执行

⑥必须禁用Swap

Swap total大于0，说明Swap分区是开启的

问：如何关闭Swap？

答：编辑文件/etc/fstab，在swap行前面加上#号注释， 保存并重启服务器

再次查看分区状态，已生效

常见的容器引擎（Container runtime，简称runtime）：

本文使用的容器引擎是Docker

安装完成后查看版本：

当出现可能跟Docker引擎相关的奇怪异常时可以尝试把Docker卸载干净并重新安装，但一定要注意镜像、容器、卷或配置文件这些是否需要备份。

下面记录卸载Docker引擎的步骤：

①卸载 Docker Engine、CLI 和 Containerd 包：

②主机上的映像、容器、卷或自定义配置文件不会自动删除。删除所有镜像、容器和卷：

③配置文件如果有不合法的字符时会导致启动失败，我们需要将其删除然后重建

此时Docker引擎已卸载干净

官网用的是谷歌的yum源，因为国内是连不上的，所以这里替换成阿里提供的yum源

①安装

从安装信息中可以看到版本号是122

Installing:

kubeadm x86_64 1224-0 kubernetes 93 M

kubectl x86_64 1224-0 kubernetes 97 M

kubelet x86_64 1224-0 kubernetes 20 M

②启动

这就是一个驱动程序，注意cgroup和cgroupfs不要混淆了

引用官方的一段话

“由于 kubeadm 把 kubelet 视为一个系统服务来管理，所以对基于 kubeadm 的安装， 我们推荐使用 systemd 驱动，不推荐 cgroupfs 驱动。”

kubeadm默认是使用systemd 驱动，而我们的Docker默认驱动是cgroupfs（docker info可以查看），所以需要将Docker的驱动改成systemd

①编辑Docker配置文件

②重启Docker服务

再次docker info查看驱动信息已变成了systemd

工作节点（worker nodes）的最小配置就到这里了

①镜像源参数说明

默认情况下, kubeadm 会从 k8sgcrio 仓库拉取镜像，国内是拉不了的。官方文档明确表示允许你使用其他的 imageRepository 来代替 k8sgcrio。

--image-repository 你的镜像仓库地址

接下来我找了一些国内的镜像源，并简单做了下分析

综合上述统计，我选择阿里云的镜像源

②ip地址范围参数说明

--pod-network-cidr =19216800/16

注意:如果19216800/16已经在您的网络中使用，您必须选择一个不同的pod网络CIDR，在上面的命令中替换19216800/16。

集群初始化命令：

因为我用的是演示机器，所以这里把完整的执行信息都贴出来方便查阅，平时工作中一定要注意保护好敏感的信息（我的ip地址范围是自定义的便于下面的功能演示，另外初次init需要下载镜像文件，一般需要等几分钟）

如上所示，集群初始化成功，此时一定要注意看上面执行结果最后的那部分 *** 作提示，我已用标明了初始化成功后还需要执行的3个步骤

注意：如果init成功后发现参数需要调整，可以执行kubeadm reset，它的作用是尽最大努力恢复kubeadm init 或者 kubeadm join所做的更改。

To start using your cluster, you need to run the following as a regular user:

翻译：开始使用集群前，如果你是普通用户（非root），你需要执行以下的命令：

Alternatively, if you are the root user, you can run:

翻译：或者，如果你使用的是root，你可以执行以下命令：

（注意：export只是临时生效，意味着每次登录你都需要执行一次）

网络配置配的就是Pod的网络，我的网络插件选用calico

cidr就是ip地址范围，如果您使用 pod CIDR 19216800/16，请跳到下一步。

但本文中使用的pod CIDR是19210000/16，所以我需要取消对清单中的 CALICO_IPV4POOL_CIDR 变量的注释，并将其设置为与我选择的 pod CIDR 相同的值。（注意一定要注意好格式，注意对齐）

可根据需求自定义清单，一般不需要的就直接跳过这步

在所有的工作节点上执行join命令（复制之前初始化成功后返回的加入集群命令到所有的工作节点执行即可）

master上查看所有节点的状态

到这里集群已经创建完成

最后我再安装K8S的可视化界面kubernetes-dashboard，方便我们日常使用

①下载yaml文件

②修改yaml文件，新增type和nodePort，使服务能够被外部访问

③安装并查看运行情况

④新建用户

文件创建完成后保存并apply

⑤获取Token，用于界面登录

⑥登录dashboard

192168189128是我的master服务器ip，另外要注意必须使用>

随着大数据集群的使用，大数据的安全受到越来越多的关注一个安全的大数据集群的使用，运维必普通的集群更为复杂。

集群的安全通常基于kerberos集群完成安全认证。kerberos基本原理可参考 ：一张图了解Kerberos访问流程

Spark应用(On Yarn模式下)在安全的hadoop集群下的访问，需要访问各种各样的组件/进程，如ResourceManager，NodeManager，NameNode，DataNode,Kafka,Hmaster,HregionServer，MetaStore等等。尤其是在长时运行的应用，如sparkStreaming，StructedStreaming，如何保证用户认证后的长期有效性，其安全/认证更为复杂。

一个Spark应用提交用户要先在kdc中完成用户的认证，及拿到对应service服务的票据之后才能访问对应的服务。由于Spark应用运行时涉及yarnclient，driver，applicationMaster，executor等多个服务，这其中每个进程都应当是同一个用户启动并运行，这就涉及到多个进程中使用同一个用户的票据来对各种服务进行访问，本文基于Spark23对此做简要分析。

spark应用的提交用户认证之后才能提交应用，所以在yarnclient/driver的逻辑中必然会执行到kerberos认证相关的登录认证。然而其他的进程如applicationMaster，executor等均需要经过认证，应用提交后才由用户启动，这些进程则可以不进行kerberos认证而是利用Hadoop的token机制完成认证，减小kerberos服务压力，同时提高访问效率。

Hadoop的token实现基类为orgapachehadoopsecuritytokenToken，

不同的服务也可hadoop的token来交互，只要使用不同的identifer来区分token即可。 如NMTokenIdentifier, AMRMTokenIdentifier,AuthenticationTokenIdentifier等不同的tokenIdentifier来区分不同的服务类型的token。

此处yarnclient指的是向ResourceManager提交yarn应用的客户端。在spark中，向yarn提交应用有两种应用有yarn-client,yarn-cluster模式。在这两种应用模式下提交应用，yarn client逻辑有些许不同。

安全hadoop场景下spark的用户登录认证机制

在client的submitApplication方法中提交app，之后创建amContext，准备本地资源，此时会将本地的文件上传至HDFS，其中就包括keytab文件，同时会生成 spark_conf properties配置文件以供am使用，该配置文件中会包含keytab的配置

其中的amKeytabFileName是在setUpCredentials时设置如下，该值为指定的keytab文件加上随机的字符串后缀，骑在am重点使用，可参考下节的介绍。

获取相关组件的token，注意：此处的token均非与yarn服务交互相关token，这里只有与HDFS，HBASE，Hive服务交互的token。

}

Spark中常访问的服务使用token机制的有hive，hbase，hdfs，对应的tokenProvider如下：

以HbaseDelegationTokenProvider为例，主要是通过反射调用hbase的TokenUtil类的obtainTOken方法，对应的obtainDelegationTokens方法如下：

PS ： HBase的token获取的用户需要具有hbase:meta表的exec权限，否则无法成功获取token

在获取token后，将token设置到amContainer中，并放入appContext中

在yarn-client模式下，driver在yarnclient进程中启动，同样需要访问业务层及集群的相关组件如hdfs。driver通过读取am更新在hdfs路径下的credentials文件来保证driver节点的token有效。

在yarn-cluster模式下，driver运行在applicationMaster的JVM中，其安全相关由Am同一 *** 作

applicationMaster是Yarn进行应用调度/管理的核心，需要与RM/NM等进行交互以便应用运行。其中相关的交互均通过token完成认证，认证实现由Yarn内部框架完成。查看am日志发现，即是在非安全（非kerberos）的场景下，同样会使用到token。而与hdfs，hbase等服务交互使用的token则需Spark框架来实现。

在ResourceManager接收到应用提交的ApplicationSubmissionContext后，在其AmLauncherjava的run方法中为am设置生成“YARN_AM_RM_TOKEN，该token用于am于rm通信使用”

Am在启动之后，会向ResourceManager申请container，并与对应的NodeManager通信以启动container。然而AM与NM通信的token是如何得到的呢？

查看AMRMClientImpl类可以看到，AM向RM发送分配请求，RM接收到请求后，将container要分配至的NM节点的Token放置response中返回给AM。Am接收到response后，会保存NMToken，并判定是否需要更新YARN_AM_RM_TOKEN

RM通过ApplicationMasterService响应allocation请求

AM在准备启动container时，将当前用户的token都设置进ContainerLaunchContext中

查看Am启动命令大致如下，可以发现有指定配置文件，而该配置文件即为yarnclient生成上传至hdfs，在am启动前由NodeManager从hdfs中copy至本地路径，供container使用：

查看此配置文件可以看到有如下配置项：

下图为am进程使用到的资源文件

如上可以看出，am虽然运行在集群中，但运行时认证相关的资源已经准备就绪。下面分析其运行中关于安全的逻辑

在applicationMaster中，定期更新token，并写入文件到hdfs的相关目录，并清理旧文件以供各executor使用。

在ApplicationMaster启动后，进行login登录并启动名为am-kerberos-renewer的dameon线程定期登录，保证用户认证的有效性

private val ugi = {

val original = UserGroupInformationgetCurrentUser()

在am中启动AMCredentialRenewerStarter线程,调度认证登录及token renew逻辑

在scheduleLoginFromKeytab中，会周期调度登录，token获取更新写入hdfs文件等 *** 作。

其核心逻辑如下

调度周期：

调度流程：

executor的认证同样使用的是token机制。executor启动之后，根据driver启动设置的${sparkyarncredentialsfile}启动token更新：

Executor中的token更新是读取hdfs目录 {timeStamp}-${nextSuffix}目录下的文件，读取到缓存中，以便保证读取到的是更新后的token使用。

Spark框架完成的kerberos认证及使用token与其他服务交互的机制使用较为简单，只需要在提交应用时的spark-submit命令行中加入--principal appuserName --keytab /path/to/userkeytab即可

一、token在header中的传输规范

二、uuid在header中的传输规范

三、防重放攻击传输规范：

四、权限校验失败返回值

>

概述：为解决临时数据导致的集群资源争用问题，我们采用了container日志分离方案，但在Hadoop Security机制下，该方案存在跨集群的认证问题。经过对Hadoop Security机制及NodeMagager日志聚集功能源码的分析，探索了两种解决方案：1）在各计算框架以个人用户独立认证；2）在日志聚集功能模块以Yarn用户统一认证，并对两种解决方案的优劣进行了对比。

1 、概述

集群上的数据可以拆分为业务数据、临时数据（日志、 app jars等），两类数据（或其 *** 作）共同争用RPC, 存储等资源。经统计，每天NN RPC总量约为906亿，其中，存储日志数据导致的RPC约占RPC总量的10%，为了降低计算集群的RPC压力，我们结合 YARN-3269 提出了Container日志分离方案：将Container日志数据进行聚集，然后存储至独立的用于存放冷数据的集群，从而消除日志存储对计算集群的影响。

目前，集群采用了基于Kerberos的Hadoop Security机制，而该安全机制会导致日志聚集功能中HDFSClient访问冷数据集群NameNode认证失败，从而影响分离方案实施。

为了解决该问题，保障分离方案顺利实施，对Hadoop Security机制做了深入研究，并结合NodeManager日志聚集功能源码分析，探索了两种解决方案：

1） 在各计算框架以个人用户独立认证。

2） 在日志聚集功能模块以Yarn用户统一认证。

下文将对Hadoop Security 机制，日志分离功能遇到的问题的原因及解决方案进行详细分析，不足之处，也请批评指正。

2 、Hadoop Security

Hadoop Security机制采用Kerberos 与Delegation Tokens（代理Token）相结合的方案。

21 Kerberos

211 Kerberos 原理

为了更加形象的说明Kerberos的原理，我们采用举例的方式进行说明（官方示例）。

比如：用户要去游乐场，首先要在门口检查用户的身份(即 CHECK 用户的 ID 和 PASS), 如果用户通过验证，游乐场的门卫 (AS) 即提供给用户一张门卡 (TGT)。

这张卡片的用处就是告诉游乐场的各个场所，用户是通过正门进来，而不是后门偷爬进来的，并且也是获取进入场所一把钥匙。

现在用户有张卡，但是这对用户来不重要，因为用户来游乐场不是为了拿这张卡的而是为了游览游乐项目，这时用户摩天楼，并想游玩。

这时摩天轮的服务员 (client) 拦下用户，向用户要求摩天轮的 (ST) 票据，用户说用户只有一个门卡 (TGT), 那用户只要把 TGT 放在一旁的票据授权机 (TGS) 上刷一下。 票据授权机 (TGS) 就根据用户现在所在的摩天轮，给用户一张摩天轮的票据 (ST), 这样用户有了摩天轮的票据，现在用户可以畅通无阻的进入摩天轮里游玩了。

当然如果用户玩完摩天轮后，想去游乐园的咖啡厅休息下，那用户一样只要带着那张门卡 (TGT) 到相应的咖啡厅的票据授权机 (TGS) 刷一下，得到咖啡厅的票据 (ST) 就可以进入咖啡厅。

当用户离开游乐场后，想用这张 TGT 去刷打的回家的费用，对不起，用户的 TGT 已经过期了，在用户离开游乐场那刻开始，用户的 TGT 就已经销毁了。

如图1所示，Kerberos认证的过程可以分为三步：1）Client获取KDC访问许可TGT（我是谁），2）向TGS请求要访问的目标服务的票具（我要干什么），3）访问目标服务（干什么），图中具体流程与举例说明相仿，下面我们结合HDFS的访问过程对其进行描述。

212 HDFS Client 的认证流程

下面以大家常用的hdfs dfs – ls dir（或 hadoop fs –ls dir） 为例，描述Kerberos的认证流程。

1） 首先使用kinit进行登录，输入密码后，Kerberos 客户端收集user-principle（kinit时产生，可以使用Klist进行查看） 和password，发送至KDC（AS）进行认证。

2） KDC认证通过后，下发TGT（user-kdc-ticket）给客户端。客户端收到TGT进行校验通过后，将TGT缓存在本地（用户只读）。

3） 将执行hdfs dfs –ls dir时，首先从缓存中取出TGT, 然后向KDC（TGS）获取连接NameNode(NN)访问许可。KDC收到请求，用户身份校验通过后，下发User-NN-Ticket

4） HDFS客户端使用得到的User-NN-Ticket连接NN。NN收到请求后，对Ticket进行验证，认证通过后，使用加密数据回复客户端，客户端收到信任信息后，发送listFiles(dir)请求，并等待响应。

以上为HDFS Client简要流程，。

22 Delegation Token

理论上，可以单独使用Kerberos进行身份认证，然而，在Hadoop这样的分布式系统中使用时，存在一个问题：对于每一个Job, 如果所有的工作任务者使用TGT通过Kerberos TGS进行身份认证，那么Kerberos将很快成为瓶颈。图2中的红线说明了问题：一个作业可能有数千个节点到节点的通信，导致相同的KDC通信量。事实上，在大集群中会不经意地在KDC上执行分布式拒绝服务攻击。

因此，引入了Delegation Token作为一种轻量级的认证方法来补充Kerberos身份验证。Kerberos是三方协议；相比之下，Delegation Token认证是两方认证协议。引入Delegation Token之后的认证过程如图3所示。

为了简洁起见，图3省略了Kerberos身份验证的步骤和任务分配的细节。假设，现在已经完成了Kerberos的三步式认证，后续流程如下（KMS Delegation与HDFS Delegation协同，下面统一以HDFS的角度进行说明）：

1）Client在进行完Kerberos的三步式认证后，获得NameNode产生的HDFS Delegation Token，并缓存于UGI

2）Client 向RM（ResourceManager）提交App时，会携带该Token信息。

3）RM接到Token之后, 会马上对Token进行Renew *** 作已验证其合法性，并将其持久化到要启动ApplicationMaster的Worker(NodeManager)，Worker在启动ApplicationMaster加载该Token（后续Worker类似）。

4）Worker 通过Token 对HDFS进行访问。

5）运行结束，RM撤销Token

图3 Delegation Token 补充方案认证流程

值得注意的是，Token具有超时时间，默认为24小时。在不对Token更新的情况下，超过24小时的App将会失败。因此，存在Renewer对Token进行更新以保证长任务执行（token最终超时时间由yarn参数delegationtokenmax-lifetime决定)。

3 、日志聚集功能

31 日志分离失败case

在原有配制基础上，开启日志分离功能（跨集群日志聚集）后，发现未按预期进行日志分离，且NodeManager节点存在以下异常信息：

通过观察日志，可以清晰的发现，该异常系权限认证失败所致。通过分析源码，该异常发生的位置进行的 *** 作为：通过userUGIdoAs创建AppLogDir。日志显示的结果可能为userUGI中没有访问远程集群的Token，导致失败。

311 UGI 追踪（UGI从哪里来）

分析userUGI中是否具有访问冷数据集群的Token, 我们需要对UGI的来源进行跟踪。通过分析源码，我们发现UGI关联的User及Token(图中Credentials为工具类，用于读写存储在内存或磁盘中密钥和令牌)是通过解析LogAggregationServicer接收的APPLICATION_STARTED Event 得到的，具体跟踪流程如图4所示，其中Hander, Initializer为方便说明，抽象出来的对象。

根据时序图中访问流程，结合异常日志信息，可以确定异常原因的确userUGI没有访问远程集群的Toket(Credentials)

312 Credentials ( 或Tokens) 追踪（Creadential 从哪里来）

本节从Spark计算引擎的角度，对Credentials（或Tokens）来源进行追踪。通过分析yarn/Client源码，Client在启动AM (ApplicationMaster)前，会进行一系列准备工作。准备工作过程中存在与其它组件的通信，其中包括准备本地资源时（prepareLocalResources）与NN(NameNode)的通信：1）通过TGT 获取user-nn-ticket（Client启动在客户机，可以使用TGT） ；2）使用user-nn-ticket 访问NN，并获取Delegation Tokens 获取到Tokens后会通过Credentials将Tokens（不含TGT）存储在ContainerLaunchContext中。并随同ApplicationSubmissionContext一起提交至Yarn，请求启动AM；Yarn收到请求后，会为其选择NodeManager,使用ContainerLaunchContext 拉起AM

从上图可知，最后LogAggregationServicer可使用的Tokens是客户端（Agent）初始化时，获取的。换句话说，客户端获取了访问某NN的Token时，LogAggregationServicer才具有访问该NN的Token 而默认情况下，客户端仅会获取fsdefaultFS（HADOOP_CONF:core-sitexml中配置），因此，跨集群访问时无访问日志集群的权限。

32 解决方案

通过上述分析可知，若想访问某服务，需具备以下一种条件：

1） 拥有该服务授予的合法Token

2） 角色持用TGT（password认证或keytabs）,可以通过Kerberos完成完整的服务认证。

基于以上分析，我们对日志分离认证问题提出了两种方案：

1） 各计算框架以个人用户独立认证

该方案的核心思想是向Yarn提交应用前，使客户端（Agent）获取所有必要的Token。客户端启动在使用kinit进行登录的客户机，因此其可使用TGT 完成Kerberos认证，并可以获取到任务想访问的服务（类211节流程）。

因此，针对日志分离跨集群认证问题，应使客户端在向Yarn提交应用前，获取到所有NN 的Token，以便传递到NM以用户身份进行日志聚集 *** 作。

该方案需要在各计算引擎进行配置或修改，以使在提交应用前，获取到所需的Tokens目前，Spark（“sparkyarnaccessnamenodes”）及MR（“ mapreducejobhdfs-servers”）引擎，自带配制参数，用于指定额外的NN，以获取Tokens。其它引擎目前未进行调研。

2 ）日志聚集功能模块以Yarn用户统一认证

该方案的核心思想是使用NodeManager的启动用户Yarn进行日志聚集，从而使用Yarn统一进行认证。

NodeManager使用KeyTabs方式进行登录，其可以通过Kerberos认证访问所有服务（包括NN）；另外，日志聚集功能，以AbstractService方式运行于NodeManger。因此，理论上可以使用NodeManager获取的Tokens 访问远程NN，创建日志目录或上传日志等。

日志聚集不仅包括日志上传等工作，还包括container本地日志清理工作，而Container日志的管理是以应用提交用户的名义进行的管理，若直接将UserUGI简单的更换成NodeManager LoginUGI，则日志后处理工作将无法进行，因此，我们采用Token劫持方案进行实现（若集群支持ProxyUser，可使用ProxyUser），即：使用用户的UGI + NodeManager 获取的Token方式进行实现，具体如下：

33 方案对比

表1 跨集群日志分离认证问题解决方案对比

综上，我们采用 日志聚集功能模块以Yarn用户统一认证 的方式来解决跨集群日志分离认证问题。

4 结论

本文分析了Hadoop Security的原理，提出了两种跨集群日志分离认证问题解决方案。并对比了两种方案的优劣，最终选用 日志聚集功能模块以Yarn用户统一认证方案 解决跨集群日志分离认证问题，现该方案已上线验证，截止目前运行良好。

我们要做的就是将code值发送给后端，后端去相应的接口请求之后就能给我们返回token值！在其他页面也需要用到token来请求数据,所以拿到它时候我们还需将其存到

全局变量

中，以便页面可以直接拿到。

以上就是关于kubeadm生产token，加入新节点全部的内容，包括:kubeadm生产token，加入新节点、全局token怎么传、K8S安装和创建集群终极教程（单master多worker）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！