k8s豹之篇——搭建自己的 k8s 集群,实战部署 LuckyBlog 和 LuckyTalk 服务
写在前面的碎碎念
本篇文章是拿来记录我第一次玩 k8s 的成果的,最开始本来是打算写一篇教学向的文章的,结果开始了才发现,现在网上的教程已经非常详尽了,没有必要重复做了,所以就先放上实践篇,理论篇( k8s in Action 的读书笔记)后面再放上来
因此,请不要把本篇看作教程,来康康热闹就可以了
给初学 k8s 的朋友指指路,看了下面这些,只要有点容器技术的基础,一天时间就能上手 k8s
【推荐先学习入门的东西】
一条命令安装高可用kubernetes,3min装完,700M,100年证书,生产环境稳如老狗
推荐使用 Kuboard 面板,非常方便好用
【推荐后面慢慢看的东西】
如何基于K8s(Kubernetes)部署成PaaS/DevOps
书目:
《 k8s in Action 》
《云原生服务网格 Istio :原理、实践、架构与源码解析》
我的实践
规划、安装虚拟机
根据前面的学习情况,我决定直接上手集群,绕过单节点部署,因为服务全迁到新服务器上了,所以在旧服务器里面直接来拉上6台虚拟机
这拉虚拟机,起名字是头等大事,身为老八月厨,那名字必须从八月社的作品里面来,带伙可以猜猜出处
上面的 akari eustia kotone 三个节点是 Master 节点,内网 ip 分别是 201 202 和 203 ,下面的 colette licia shirasaki 三个节点是 Worker 节点,内网 ip 分别是 204 205 和 206 ,以上节点全部使用相同的 root 密码,节点详细规划如下
节点类型 | ip | cpu | ram | name | disk | dns |
---|---|---|---|---|---|---|
master | 25.201 | 2c | 4g | akari | 100g | 223.5.5.5 |
master | 25.202 | 2c | 4g | eustia | 100g | 223.5.5.5 |
master | 25.203 | 2c | 4g | kotone | 100g | 223.5.5.5 |
worker | 25.204 | 2c | 4g | colette | 100g | 223.5.5.5 |
worker | 25.205 | 2c | 4g | licia | 100g | 223.5.5.5 |
worker | 25.206 | 2c | 4g | shirasaki | 100g | 223.5.5.5 |
虚拟机全部采用 CentOS 8.2 最小安装,使用自建 NTP 服务器进行时间同步,并安装 wget 和 tar 两个软件包
安装 k8s 集群
在其中一台机器(我选的 akari 节点)上运行以下命令即可完成 k8s 集群的安装(我选的是 1.17 版,1.19 以后不再使用 docker 跑容器了,docker 我比较熟,所以选了 1.17 )
wget -c https://sealyun.oss-cn-beijing.aliyuncs.com/latest/sealos && \ |
安装 Kuboard
安装完成之后,在一个节点(我还是选的 akari 节点)运行下面的命令安装 Kuboard
kubectl apply -f https://addons.kuboard.cn/kuboard/kuboard-v3.yaml |
然后执行以下指令,等待 kuboard 名称空间中所有的 Pod 就绪( STATUS 是 Running 状态,就像下面截图那样)
watch kubectl get pods -n kuboard |
然后即可在 http://your-node-ip-address:30080 (任一节点 ip:30080)进入 Kuboard
进去之后,可以看到我们六个机器的情况
配置反向代理
需要注意的是,如果使用跑在宝塔面板里面的 Nginx 做反向代理的话,配置样例里面的 http 部分需要在面板根目录的 Nginx 配置文件手动配置
http { |
配置样例如下,照葫芦画瓢即可
http { |
最初的实践——把 plumemo 跑进 k8s
先从简单的开始,咱们先把 LuckyBlog 跑到 k8s 里面吧~
在 plumemo 容器跑,轻松提效省资源 这篇文章里,我们已经准备好了 LuckyBlog 的 Docker image ( LuckyBlog 连接一个外部数据库(一个 k8s 外部已经做了数据持久化的容器),所以只需要把镜像本身跑起来即可,不需要考虑数据持久化的问题)
在私有容器迁移怎么办?来搭个私有镜像源吧~——Harbor的简单搭建与使用 这篇文章里,我们已经准备好了私有镜像源,同时,已经将生产环境的 LuckyBlog 镜像上传至自建 Harbor 服务器中
导入工作负载——负载类型选择 Deployment (部署),仓库选择自建 Harbor 服务器,填写好各项参数(命令:bash /root/blog_auto_start.sh 和 参数 -tid)暴露端口 80( http ) 443( https ) 以及 3306( 数据库 ),在 80 端口部署容器存活和就绪探针,即可将 LuckyBlog 运行起来,如图
我们初次运行了三个副本,我们可以根据当前的负载情况对其的数量进行左右调整,可以增加,也可以减少,可以手动调整,也可以自动调整,如图:
但是现在在外部是访问不到它的,我们只能通过内部的代理进行访问
通过 NodePort 模式,我们可以将 LuckyBlog 以服务的方式发布到外部,我们选择将容器(组)的 80 端口映射到 k8s 集群的 32601 端口上,将将容器(组)的 443 端口映射到 k8s 集群的 32602 端口上,然后我们来试试效果
我们可以发现一个很神奇的现象,无论你运行了几个 LuckyBlog 的容器副本,你都可以在 k8s 集群中的任一一个节点( Master 和 Worker 节点均可)的 ip:port 上访问 LuckyBlog 容器(组)提供的服务,那么,如果用于生产环境,我们在仅有一个公网 ip 的情况下,结合我们运行服务的其它情况,可以通过下图的方式将 k8s 中的 LuckyBlog 发布给公网访问,这样做,可以大大提高 LuckyBlog 服务的可用性,如果我们有多台服务器进行部署(不像实验中我们只用了一台服务器),就能打造高可用服务,减少单点故障引起服务炸掉的可能
当然,实际上我并不打算这么做,因为旧服务器的功耗实在太高了(一天 8 度电+),新服务器一天一度电,使用旧服务器后面日常不会开了,只留着做冷存储,后面会写文章介绍新旧服务器和迁移过程
接着,我们来增加一点难度
稍稍提高难度,将全部服务跑进 k8s
LuckyBlog 使用的是外部的数据库,我们不妨尝试一下将服务的全部部分跑进 k8s 里面
我们选择的是将 LuckyTalk (在线聊天室)作为我们的目标
选择 LuckyTalk 的原因如下:
- LuckyTalk 是由多个微服务组成的,各个微服务之间分工明确,符合 k8s 的架构要求,不像 LuckyBlog 那样是一个巨型单体应用( LuckyBlog 也是应该拆开的,但是我懒,加上水平不行,加上没有迭代需求就没拆)
- LuckyTalk 架构相对简单
- LuckyTalk 需要用到数据库,需要做数据持久化
- LuckyTalk 需要用到环境变量
我们先来审视一下 LuckyTalk 的构成
LuckyTalk 使用的是碎碎酱大佬的 fiora 项目,文档在此
我们可以看出,运行 LuckyTalk 至少需要这样三个容器,如图
其中
fiora 需要与 MongoDB 和 Redis 通信( TCP 27017 和 TCP 6379 )
MongoDB 的配置文件夹( /data/configdb )和数据库( /data/db )需要做数据持久化
Redis 的配置文件夹( /usr/local/etc/redis )需要做数据持久化
对于数据持久化,Kuboard 支持如下方式
我们的 Unraid 已经有现成的 NFS 服务器了,我们就用它了
将数据卷映射好,就能解决数据持久化的问题
和 LuckyTalk 不同, MongoDB 和 Redis 工作在持久层,工作负载属于 StatefulSet (有状态副本集),公布它们的服务,需要将服务类型指定为 Headless (无头服务,专用于 StatefulSet),k8s 外面访问不到,但容器间可以通信
将这些部署好之后,我们就完成了上面两个服务的部署了,只需要完成 fiora 部署即可
fiora 运行时需要指定两个环境变量,如下:
-e Database=mongodb://fioradb:27017/fiora -e RedisHost=fioraredis |
在 Unraid 中,我们是通过 Extra Parameters 来写入这些变量的(也包括类似 -tid 这样的参数),在 Post Arguments 写入需要执行的命令(如:bash /root/blog_auto_start.sh ),Unraid 的 Extra Parameters 和 Post Arguments 相当于 docker run 【 Extra Parameters 】 容器镜像 【 Post Arguments 】这样一前一后的关系,而在面板当中,我们不能通过在命令里面 -e 解决这个问题,而且单独配置环境变量
在 Docker 运行时,我们指定的环境变量如下:
-e Database=mongodb://177.229.25.18:27017/fiora -e RedisHost=177.229.25.17 |
而在 k8s 中,我们需要把 MongoDB 和 Redis 发布成服务后用服务名指定,如图:
把关于 ip 地址的部分使用服务名替换即可,这样,即使运行 MongoDB 和 Redis 具体容器改变,服务也不会炸, k8s 会动态地将流量打到新生成的容器中去
一番配置之后,我们的 LuckyTalk 就跑到 k8s 集群里面啦~
事不宜迟,马上来发个言康康
好耶!它跑起来啦!
搞定了复杂一点的东西,下面来整点炫的!
大屏展示
有了大屏展示,我们就能向大家很好地展示我们先进的服务(也就是装X ),还能准确的向领导展示我们服务运行的情况
我们选择 Grafana 作为监控工具,在 Kuboard 中,只需要配置好存储卷,就能轻松跑起来, Grafana 的界面能够很好的适配各种大小的屏幕,越大的屏幕看的越舒服,当然我是没有大屏幕的,这里放几张图给带伙大概康康效果:
最后,一句话来总结一下
k8s 是先进的全自动容器编排技术,一次上线,终生运行,自动排障,零人工干预,金院办公OA运维同款,你,值得学习!