写在前面的碎碎念

本篇文章是拿来记录我第一次玩 k8s 的成果的,最开始本来是打算写一篇教学向的文章的,结果开始了才发现,现在网上的教程已经非常详尽了,没有必要重复做了,所以就先放上实践篇,理论篇( k8s in Action 的读书笔记)后面再放上来

因此,请不要把本篇看作教程,来康康热闹就可以了doge

给初学 k8s 的朋友指指路,看了下面这些,只要有点容器技术的基础,一天时间就能上手 k8s

【推荐先学习入门的东西】

k8s 入门教程

一条命令安装高可用kubernetes,3min装完,700M,100年证书,生产环境稳如老狗

推荐使用 Kuboard 面板,非常方便好用

【推荐后面慢慢看的东西】

k8s 官方文档

如何基于K8s(Kubernetes)部署成PaaS/DevOps

书目:

《 k8s in Action 》

《云原生服务网格 Istio :原理、实践、架构与源码解析》

我的实践

规划、安装虚拟机

根据前面的学习情况,我决定直接上手集群,绕过单节点部署,因为服务全迁到新服务器上了,所以在旧服务器里面直接来拉上6台虚拟机

准备虚拟机

这拉虚拟机,起名字是头等大事,身为老八月厨,那名字必须从八月社的作品里面来huaji,带伙可以猜猜出处

上面的 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 && \
chmod +x sealos && mv sealos /usr/bin
sealos init --passwd root密码 \
--master 177.229.25.201 --master 177.229.25.202 --master 177.229.25.203 \
--node 177.229.25.204 --node 177.229.25.205 --node 177.229.25.206 \
--pkg-url https://sealyun.oss-cn-beijing.aliyuncs.com/413bd3624b2fb9e466601594b4f72072-1.17.0/kube1.17.0.tar.gz \
--version v1.17.0

安装 Kuboard

安装完成之后,在一个节点(我还是选的 akari 节点)运行下面的命令安装 Kuboard

kubectl apply -f https://addons.kuboard.cn/kuboard/kuboard-v3.yaml
# 您也可以使用下面的指令,唯一的区别是,该指令使用华为云的镜像仓库替代 docker hub 分发 Kuboard 所需要的镜像
# kubectl apply -f https://addons.kuboard.cn/kuboard/kuboard-v3-swr.yaml

然后执行以下指令,等待 kuboard 名称空间中所有的 Pod 就绪( STATUS 是 Running 状态,就像下面截图那样)

watch kubectl get pods -n kuboard

Kuboard

然后即可在 http://your-node-ip-address:30080 (任一节点 ip:30080)进入 Kuboard

进去之后,可以看到我们六个机器的情况

各节点运行状况

配置反向代理

需要注意的是,如果使用跑在宝塔面板里面的 Nginx 做反向代理的话,配置样例里面的 http 部分需要在面板根目录的 Nginx 配置文件手动配置

http {

# 使用宝塔面板,在面板根目录的 Nginx 配置文件里面找到 http{} 部分,加入 map 那部分内容

map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}

配置样例如下,照葫芦画瓢即可

http {

# 您需要的其他配置

map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}

server {
listen 80;
server_name kuboard.this-is-a-sample.com; # 替换成你的域名

location / {
proxy_pass http://192.168.32.205:80/; # 替换成你的 Kuboard IP 地址和端口,应该是 IP 地址,而不是 KUBOARD_ENDPOINT 参数的值
gzip on;
}

location /k8s-ws/ {
proxy_pass http://192.168.32.205:80/k8s-ws/; # 替换成你的 Kuboard IP 地址和端口
proxy_http_version 1.1;
proxy_pass_header Authorization;
proxy_set_header Upgrade "websocket";
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_set_header X-Forwarded-Proto https; # 如果您在反向代理上启用了 HTTPS
}

location /k8s-proxy/ {
proxy_pass http://192.168.32.205:80/k8s-proxy/; # 替换成你的 Kuboard IP 地址和端口
proxy_http_version 1.1;
proxy_pass_header Authorization;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_set_header X-Forwarded-Proto https; # 如果您在反向代理上启用了 HTTPS
gzip on;
}

error_page 404 /404.html;
location = /40x.html {
}

error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
}

最初的实践——把 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 运行起来,如图

LuckyBlog_in_k8s1

我们初次运行了三个副本,我们可以根据当前的负载情况对其的数量进行左右调整,可以增加,也可以减少,可以手动调整,也可以自动调整,如图:

LuckyBlog_in_k8s2

LuckyBlog_in_k8s3

但是现在在外部是访问不到它的,我们只能通过内部的代理进行访问

通过 NodePort 模式,我们可以将 LuckyBlog 以服务的方式发布到外部,我们选择将容器(组)的 80 端口映射到 k8s 集群的 32601 端口上,将将容器(组)的 443 端口映射到 k8s 集群的 32602 端口上,然后我们来试试效果

201http

202http

202https

203http

204http

205http

206http

我们可以发现一个很神奇的现象,无论你运行了几个 LuckyBlog 的容器副本,你都可以在 k8s 集群中的任一一个节点( Master 和 Worker 节点均可)的 ip:port 上访问 LuckyBlog 容器(组)提供的服务,那么,如果用于生产环境,我们在仅有一个公网 ip 的情况下,结合我们运行服务的其它情况,可以通过下图的方式将 k8s 中的 LuckyBlog 发布给公网访问,这样做,可以大大提高 LuckyBlog 服务的可用性,如果我们有多台服务器进行部署(不像实验中我们只用了一台服务器),就能打造高可用服务,减少单点故障引起服务炸掉的可能

将LuckyBlog_in_k8s用于生产环境

当然,实际上我并不打算这么做,因为旧服务器的功耗实在太高了xiaoku(一天 8 度电+),新服务器一天一度电,使用旧服务器后面日常不会开了,只留着做冷存储,后面会写文章介绍新旧服务器和迁移过程

接着,我们来增加一点难度

稍稍提高难度,将全部服务跑进 k8s

LuckyBlog 使用的是外部的数据库,我们不妨尝试一下将服务的全部部分跑进 k8s 里面

滑稽你我他

我们选择的是将 LuckyTalk (在线聊天室)作为我们的目标

选择 LuckyTalk 的原因如下:

  1. LuckyTalk 是由多个微服务组成的,各个微服务之间分工明确,符合 k8s 的架构要求,不像 LuckyBlog 那样是一个巨型单体应用( LuckyBlog 也是应该拆开的,但是我懒,加上水平不行,加上没有迭代需求就没拆挠头滑稽)
  2. LuckyTalk 架构相对简单
  3. LuckyTalk 需要用到数据库,需要做数据持久化
  4. LuckyTalk 需要用到环境变量

我们先来审视一下 LuckyTalk 的构成

LuckyTalk 使用的是碎碎酱大佬的 fiora 项目,文档在此

我们可以看出,运行 LuckyTalk 至少需要这样三个容器,如图

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 发布成服务后用服务名指定,如图:

luckytalk_in_k8s1

把关于 ip 地址的部分使用服务名替换即可,这样,即使运行 MongoDB 和 Redis 具体容器改变,服务也不会炸, k8s 会动态地将流量打到新生成的容器中去

一番配置之后,我们的 LuckyTalk 就跑到 k8s 集群里面啦~

luckytalk_in_k8s_running

事不宜迟,马上来发个言康康huaji

luckytalk_in_k8s_running1

好耶!它跑起来啦!

滑稽_喝嘤料

搞定了复杂一点的东西,下面来整点炫的!

大屏展示

有了大屏展示,我们就能向大家很好地展示我们先进的服务(也就是装X 冷汗滑稽),还能准确的向领导展示我们服务运行的情况

我们选择 Grafana 作为监控工具,在 Kuboard 中,只需要配置好存储卷,就能轻松跑起来, Grafana 的界面能够很好的适配各种大小的屏幕,越大的屏幕看的越舒服,当然我是没有大屏幕的,这里放几张图给带伙大概康康效果:

Grafana01

Grafana02

Grafana03

Grafana04

Grafana05

Grafana06

Grafana07

Grafana08

Grafana09

Grafana10

最后,一句话来总结一下

k8s 是先进的全自动容器编排技术,一次上线,终生运行,自动排障,零人工干预,金院办公OA运维同款,你,值得学习!

滑稽_超高解析度的无损掌声