K8S安装和创建集群终极教程（单master多worker）

本文会以 最简单 、 最直接 、 最完整 的方式记录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，另外要注意必须使用>

单机模式下，我们可以使用 Docker Compose 来编排多个服务，而在 上一篇文章 中介绍的 Docker Swarm 只能实现对单个服务的简单部署。于是就引出了本文的主角 Docker Stack ，通过 Docker Stack 我们只需对已有的 docker-composeyml 配置文件稍加改造就可以完成 Docker 集群环境下的多服务编排。

注意：如果有多个 manager 节点，portainer 和 visualizer 可能分别部署在两台机器上，所以ip可能会不一样。

评论区有小伙伴提到，容器间通过服务名 ( 比如文中的 nginx ) 通讯时，对应的 IP 却和容器的实际 IP 对不上。出现这个情况是因为负载均衡（ 对外表现为一个服务，内部为多个服务 ）。下面是我做的试验，希望能帮助大家理解。

总结下：

整个请求的调用流程应该就是： 通过服务名 nginx 访问 -- 指向 --> stack 集群网关 ( 10065 ) -- 转发 --> stack 集群中，位于当前服务器的负载均衡实例 ( 10064 ) -- 分发 --> 最终的应用 。

ES版本依赖: >

市面上存在两种数据库负载均衡的思路：1

基于数据库连接的负载均衡：例如总共有100个数据库连接，50个连接登录到数据库机器A，另外50个连接登录到数据库机器B，这样每个连接中接下来的所有请求全都是发往同一台数据库机器的

这种数据库负载均衡的思路模拟了WEB上的负载均衡方法，但是由于WEB连接是短时间连接(连接建立后，获取需要的HTML等资源后，连接马上被关闭)，而数据库连接是长时间连接(连接建立后，可长时间保持，客户可不停向数据库发送SQL请求，数据库做出回答，如此不断循环直到连接被人为或因错而断开为止)，因此这种数据库负载均衡思路存在着明显的缺点：有可能会发生绝大部分的请求压力都集中到某台数据库机器上去，从而使得负载均衡效果失效

2

基于批处理请求的负载均衡：在建立数据库连接的时候，会同时与每台数据库服务器建立连接，之后针对客户端的每次请求，都会根据负载均衡算法，独立地选出某个数据库节点来执行这个请求

此种思路符合数据库长时间连接的特征，不存在上面所述的基于连接的负载均衡方法的缺点

市面上的负载均衡厂商，既有基于连接的，也有基于批处理请求的，用户需仔细辨别才能找到自己想要的合适产品

集群 顾名思义就是把很多台提供服务器的机器汇集到一块来完成某些数据的处理。它把很多台服务器通过软件虚拟成一台机器，不管其中某一台服务器宕机了，其它的服务器都能接替它的工作，保证服务器不宕机，集群也大大减少了单个服务器的压力，延长服务器寿命。

全分布式集群是指将系统的计算和存储资源分散到多台服务器上，通过网络互相连接，形成一个高可用、高可靠、高性能的分布式计算环境。搭建全分布式集群可以提高系统的计算能力、数据处理能力和容错能力。
实现全分布式集群需要遵循以下原则：
1 水平扩展：将系统的计算和存储资源分散到多个节点上，可以根据业务需求按需增加或减少节点，从而方便地扩展系统的性能和容量。
2 节点均衡：每个节点都应该具有相同的硬件配置和软件环境，以保证节点之间的任务分配均衡，并且方便进行故障转移和负载均衡。
3 数据一致性：在分布式环境下，数据的一致性是非常重要的。为了保证数据的一致性，需要采用合适的同步机制，如数据复制、数据分片等。
4 故障容错：从节点故障恢复和任务重试等方面提供容错功能，使得系统可以在节点故障的情况下继续工作。
5 高性能通信：使用高速网络通信协议，如Infiniband、RDMA等，保证节点间的通信速度和吞吐量。
搭建全分布式集群需要使用一些分布式系统的基础组件，如分布式文件系统、分布式数据库、分布式缓存、分布式任务调度等，并且需要根据实际业务需求进行选择和调整。常用的分布式平台包括Hadoop、Spark、HBase、Cassandra等。同时，为了更好地管理和监控集群，还需要使用一些集群管理工具，如Zookeeper、Ambari等。

因公司开发人员查询线上日志困难需求，故计划搭建 ELK 系统解决这一问题。了解到之前搭建过单机单节点的 ELK，但由于负载内存过高，停止弃用了。所以这次准备了三台性能不错的服务器，开始搭建 ELK 集群。
过程曲折且艰辛，记录下来以备不时之需。

由于这种方案，每个 logstash 都需要占用较大内存，这对线上各日志收集的应用服务器，压力太大难以承受。

filebeat是一个轻量级的日志采集器，部署简单占用内存小。这一方案总体上比较好了，只是 logstash 这一节点的压力比较大，查询到filebeat可以负载均衡输出到多个logstash，所以后边考虑了在准备的三台 elk 服务器上都安装一个 logstash ，这样就实现了下边这一方案。

上边的方案其实已经能够满足一般公司的日志需求，但超大的日志数量可能会存在数据错乱缺失，节点脑裂等多个问题。要尽量解决这些问题，要做的工作还很多，这里收集部分网上的建议，记录如下：

在个服务器上通过 yum install -y rpm 直接快速安装
安装后程序位置都在 /usr/share/ 下
配置文件都在 /etc/ 下

建议用 ansible 管理
启动：elasticsearch --- logstash --- filebeat --- kibana
停止：kibana --- filebeat --- logstash --- elasticsearch

单台服务器创建集群，多台也是一样 *** 作，使用集群端口6380,6381,6382,6383,6384,6385

1、宝塔安装redis，路径一般是 />