通过kubeadmin安装K8S集群可以做到快速部署，但是如果需要调整K8S各个组件及服务的安全配置，高可用模式，最好通过二进制模式进行K8S的安装
创新互联公司主营兴隆网站建设的网络公司,主营网站建设方案,app软件定制开发,兴隆h5重庆小程序开发公司搭建,兴隆网站营销推广欢迎兴隆等地区企业咨询
生产环境K8S Master节点最好在3个节点以上，且配置不低于4核16g
生产环境：确保Master高可用，启用安全访问机制
PS：
服务器节点只是起名字，与是否为k8s-master或k8s-node无关，可根据需要增加或删减测试用例的数量，如多台master主机只部署k8s-master组件。多台node主机只部署k8s-node组件
master1 192.168.100.100
node1 192.168.100.101
node2 192.168.100.102
注：本节中创建的证书为部署流程全过程证书，测试用例为openssl生成证书，cfssl生成证书需要参考cfssl生成k8s证书，并在对应配置文件的相关证书位置替换对应证书
在配置文件中需要在[alt_names]设置Master服务的全部域名和IP地址，包括：
参数解析
配置文件详解：
分发配置文件
配置文件详解：
配置详解
分发配置文件
分发配置文件
在三个kube-apiserver的前段部署HAProxy和keepalived，使用VIP（虚拟IP地址）192.168.100.200作为Master的唯一入口地址，供客户端访问
将HAProxy和keepalived均部署为至少有两个实例的高可用架构，以避免单点故障。
接下来在主机master（192.168.100.100）和主机node1（192.168.100.101）中部署
HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上，keepalived负责维护VIP的高可用
准备 HAProxy 的配置文件 haproxy.cfg
参数说明：
分发配置文件
在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署HAProxy，并将配置文件挂载到容器的/usr/local/etc/haproxy下
访问192.168.100.100:8888/stats，192.168.100.101:8888/stats
keepalived用于维护VIP地址的高可用，同样在master和node1中部署
主节点配置文件
子节点配置文件
参数解析
主节点和子节点配置异同
健康检查脚本
keeplived需要持续监控HAProxy的运行状态，在某个节点运行不正常时转移到另外的节点上去
监控运行状态需要创建健康检查脚本，定期运行监控
脚本内容如下：
分发脚本
在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署keeplived，并将配置文件挂载到容器的/container/service/keepalived/assets下，将脚本挂载到容器的/usr/bin下
检查ens33网卡是否存在keeplived VIP地址
检测keeplived是否进行转发
注：master集群已经配置完毕，后续需要在node中需要部署docker，kubelet，kube-proxy，且在加入k8s集群后，还需要部署CNI网络插件、DNS插件等
之前已经在master，node1，node2中部署了docker，接下来需要部署其他服务组件，本节部署kubelet组件
参数说明
参数说明
参数说明
当前显示所有node为NOT READY，需要部署完网络插件才可使用
为方便使用kubectl
防火墙等禁用
将桥接的IPv4流量传递到iptables的链
NTP时间同步
配置国内k8s镜像地址
k8s镜像仓库需要翻出去,所以配置国内镜像地址
安装K8s（安装和使能kubelet）
配置cgroupdriver=systemd
默认docker的Cgroup是cgroups，kubelet的Cgroups是systemd，两者的Cgroups不一样，两边需要修改成一致的配置
然后依据提示执行:
然后重新初始化
然后检查健康状况：
上面kubectl get cs结果显示系统不健康，解决方案如下：
把下面文件的 - --port=0注释掉，即前面加上#
修改kube-flannel.yml里面为(vi中使用:set number，然后 :106定位到106行)：
2、高可用测试
接下来我们分别尝试删除pod和停止Container来测试高可用性：
修改内容为：
用firefox浏览器访问：访问
一共有3个Master：
master：192.168.108.88 k8s-master03
backup：192.168.108.87 k8s-master02
backup：192.168.108.86 k8s-master04
二个worker节点：
k8s-node1：192.168.100.49
k8s-node2：192.168.100.50
各个master把自己公钥发到同一个master上汇总（这里选用k8s-master01），然后分发到各个master上：
接下来把汇总的公钥分发给其他master主机（k8s-master02和k8s-master03）：
到各个master上修改文件访问权限：
各个master节点依据自己情况做少量更改，主要是：
1、自己的被选举权重
2、自己的网卡名称
在本例中，主master节点配置（/etc/keepalived/keepalived.conf）为：
第一个备份master节点配置（/etc/keepalived/keepalived.conf）：
第二个备份master节点配置为（/etc/keepalived/keepalived.conf）：
仿造前面做node和master的配置（master到初始化master的前一步）这里略去，参考前面即可
鉴于我们是在非master高可用基础上做的高可用，即原来的master上曾经执行过kubeadm init，所以这里需要在这个节点上先执行reset操作(只需要在原来的那一个master节点上执行即可)
在MASTER上建一个脚本然后执行：
在所有其他的BACKUP master上建一个脚本然后执行：
对5台机器分别修改，同时修改hosts文件
1.1.2修改其它的主机名
所有主机操作
本文的k8s网络使用flannel，该网络需要设置内核参数bridge-nf-call-iptables=1，修改这个参数需要系统有br_netfilter模块。
查看br_netfilter模块：
如果系统没有br_netfilter模块则执行下面的新增命令，如有则忽略。
临时新增br_netfilter模块:
永久新增br_netfilter模块：
永久修改
在所有机器上都添加以下源
所有服务器均安装
查看docker版本
安装docker
在三台master主机上都需要安装keepalived
所有机器全部安装
kubelet 运行在集群所有节点上，用于启动Pod和容器等对象的工具
kubeadm 用于初始化集群，启动集群的命令工具
kubectl 用于和集群通信的命令行，通过kubectl可以部署和管理应用，查看各种资源，创建、删除和更新各种组件
安装版本为最新 1.22.2
也可以根据自己所需要的版本来安装部署
查看版本
安装yum install -y kubelet kubeadm kubectl
启动kubelet并设置开机启动
初始化失败，或出现以下错误，可以重新初始化
如果初始化失败，可执行kubeadm reset后重新初始化
记录kubeadm join的输出，后面需要这个命令将work节点和其他master节点加入集群中。
master01分发证书：
在master01上运行脚本cert-main-master.sh，将证书分发至master02和master03
同时执行
同时执行
work01加入集群
work02加入集群
如果出现worker节点名字没改，后面添加有问题,按以下执行则可以后续添加
CNI网络插件
先关闭master01
查看master02
正常转移。
k8s高可用部署完毕
从 Gitlab 8.0 开始，Gitlab CI 就已经集成在 Gitlab 中，只要在项目中添加一个 .gitlab-ci.yml 文件，然后添加一个 Runner ，即可进行持续集成。在介绍 Gitlab CI 之前，先看看一些 Gitlab CI 的一些相关概念。
Jobs-Stages-Pipeline
一次 Pipeline 其实相当于一次构建任务，里面可以包含很多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者 Merge Request 的合并都可以触发 Pipeline 构建，如下图所示：
Stages 表示一个构建阶段，也就是上面提到的一个流程。可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：
Stages 和 Pipeline 的关系如下所示：
Jobs 表示构建工作，表示某个 Stage 里面执行的工作。可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
Jobs 和 Stage 的关系如下所示：
如果理解了上面的基本概念之后，可能我们就会发现一个问题，我们的构建任务在什么地方来执行呢，以前用 Jenkins 在 Master 和 Slave 节点都可以用来运行构建任务，而来执行我们的 Gitlab CI 构建任务的就是 Gitlab Runner。
我们知道大多数情况下构建任务都是会占用大量的系统资源的，如果直接让 Gitlab 本身来运行构建任务的话，显然 Gitlab 的性能会大幅度下降的。GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情交给一个独立的 Gitlab Runner 来做就会好很多，更重要的是 Gitlab Runner 可以安装到不同的机器上，甚至是我们本机，这样完全就不会影响到 Gitlab 本身了。
安装 Gitlab Runner 非常简单，我们可以完全安装官方文档： 即可，比如可以直接使用二进制、Docker 等来安装。同样的，我们这里还是将 Gitlab Runner 安装到 Kubernetes 集群中来，让我们的集群来统一管理 Gitlab 相关的服务。
1.验证 Kubernetes 集群
执行下面的命令验证 Kubernetes 集群：
cluster-info这个命令会显示当前链接的集群状态和可用的集群服务列表。
2.获取 Gitlab CI Register Token
上节已经成功安装了 Gitlab，在浏览器中打开 hwzxgit.sinoing点虐 页面，然后登录后进入到管理页面 ，然后点击导航栏中的Runner，可以看到该页面中有两个总要的参数，一个是 URL，另外一个就是 Register Token，下面的步骤中需要用到这两个参数值。
图一、
同样将 Runner 相关的资源对象都安装到kube-ops这个 namespace 下面，首先，通过 ConfigMap 资源来传递 Runner 镜像所需的环境变量（runner-cm.yaml）:
要注意 CI_SERVER_URL 对应的值需要指向 Gitlab 实例的 URL（可以是外网地址，也可以是 Kubernetes 集群内部的 Service DNS 地址，因为 Runner 也是运行在 Kubernetes 集群中的），并加上 /ci （ ），也可以是CI_SERVER_URL: " "此外还添加了一些构建容器运行的资源限制，可以自己根据需要进行更改即可。
除了上面的一些环境变量相关的配置外，还需要一个用于注册、运行和取消注册 Gitlab CI Runner 的小脚本。只有当 Pod 正常通过 Kubernetes（TERM信号）终止时，才会触发转轮取消注册。 如果强制终止 Pod（SIGKILL信号），Runner 将不会注销自身。必须手动完成对这种被杀死的 Runner 的清理，配置清单文件如下：（runner-scripts-cm.yaml）
可以看到需要一个 GITLAB_CI_TOKEN，然后复制下图中的Gitlab CI runner token 来创建一个 Kubernetes secret 对象。将 token 进行 base64 编码：
然后接下来就可以来编写一个用于真正运行 Runner 的控制器对象，这里使用 Statefulset。首先，在开始运行的时候，尝试取消注册所有的同名 Runner，当节点丢失时（即NodeLost事件），这尤其有用。然后再尝试重新注册自己并开始运行。在正常停止 Pod 的时候，Runner 将会运行unregister命令来尝试取消自己，所以 Gitlab 就不能再使用这个 Runner 了，这个是通过 Kubernetes Pod 生命周期中的hooks来完成的。
另外通过使用envFrom来指定Secrets和ConfigMaps来用作环境变量，对应的资源清单文件如下：(runner-statefulset.yaml)
可以看到上面我们使用了一个名为 gitlab-ci 的 serviceAccount，新建一个 rbac 资源清单文件：(runner-rbac.yaml)
4.创建 Runner 资源对象
资源清单文件准备好后，直接创建上面的资源对象：
创建完成后，可以通过查看 Pod 状态判断 Runner 是否运行成功：
可以看到已经成功运行了两个（具体取决于StatefulSet清单中的副本数) Runner 实例，然后切换到 Gitlab Admin 页面下面的 Runner 页面：
至此，在kubernetes中安装Gitlab CI Runner结束，当然也可以根据需要更改 Runner 的一些配置，比如添加 tag 标签等。
