Kubernetes运行大数据组件-设计思路

环境说明

在Kubernetes集群添加三个节点作为大数据测试服务节点：

NAME            STATUS   ROLES      AGE    VERSION
bigdata199056   Ready    worker     2d3h   v1.20.6
bigdata199057   Ready    worker     2d5h   v1.20.6
bigdata199058   Ready    worker     2d3h   v1.20.6

主要原理

配置"hostNetwork: true"，直接使用节点网络；
配置"hostPath"分配节点存储，直接使用本地存储；
配置"hostAliases"为pod注入域名解析，相当于配置/etc/hosts, 添加域名解析（所有节点已配置/etc/hosts可忽略）；根据你提供的内容，看起来像是YAML格式的配置。在YAML中，正确的缩进和标点符号使用非常重要，以确保解析器能够正确理解你的意图。下面是针对你提供内容优化后的版本，修正了标点符号及格式错误：

			hostAliases:- ip: "192.168.199.56"hostnames:- "bigdata199056"- ip: "192.168.199.57"hostnames:- "bigdata199057"- ip: "192.168.199.58"hostnames:- "bigdata199058"nodeSelector:namenode: "true"tolerations:- key: "bigdata"value: "true"operator: "equal"effect: "noschedu1e"

配置"Taints"保证大数据组件外的pod不会调度到这些节点；
配置"nodeSelector"和"tolerations"使得对应角色的pod调度到特定的节点上，类似于CDH部署时角色定义；
参考CDH角色与节点的绑定部署方式：

在Kubernetes中节点配置Taints和Label,只有pod中配置容忍"bigdata=true"才能调度到这些节点上，同时还需要满足nodeSelector中的label匹配调度（找了一张用rancher管理的图，与上面CDH很类似了）：
配置"affinity"(亲和性)和"podAntiAffinity"(pod反亲和)使得数据pod(datanode)和计算pod(nodemanager)不会分布在相同的节点上；
通过"ConfigMap"维护服务配置文件；

apiVersion: v1
kind: ConfigMap
metadata:name: hadoop-config
data:core-site.xml: |<?xml version="1.0"?><configuration><property><name>fs.defaultFS</name><value>hdfs://192.168.199.56:8020</value></property><property><name>io.file.buffer.size</name><value>131072</value></property><property><name>hadoop.proxyuser.root.groups</name><value>*</value></property><property><name>hadoop.proxyuser.root.hosts</name><value>*</value></property></configuration>hdfs-site.xml: |其它配置 。。。

扩容方法

横向扩容

将扩容节点添加到kubernetes集群中
配置新节点污点，保证不被调度其它pod上去
配置新节点label，即配置扩容服务调度需要的标签
修改扩容服务yaml文件，在hostAliases中添加新节点ip和hostname，修改replicas为扩容后的总数(当前3节点，扩容2节点，则修改为5)
根据新的yaml文件更新服务

纵向扩容

停止当前服务，可通过配置replicas为0，kubernets自动清除服务pod（由于数据在节点上，仅仅相当于停止服务，数据不会丢失）
对扩容节点进行关机扩容，扩容后启动节点
kubernets下扩容节点正常上线后，修改扩容服务yaml文件的resources资源，调整为扩容后的数值
根据新的yaml文件更新服务

修改配置

所有的配置都通过kubernetes下ConfigMap类型发布：
在这里插入图片描述
每个ConfigMap包含一个和多个配置文件内容：

修改服务对应的ConfigMap文件内容
发布新的ConfigMap，一般映射到pod中的ConfigMap变更同步会有延迟，大约20s左右
配置文件更新后，服务并不会自动加载，需要手动重启服务，根据实际情况选择a或者b：
a. 直接删除pod，让其自动重建，效果相当于关闭服务再重启服务
b. 进入pod中手动停止服务，再手动启动服务
查看新配置下服务运行情况