2024程序员容器化上云之旅-第5集-Ubuntu-WSL2-Windows11版:上云之路

故事梗概

Java程序员马意浓在互联网公司维护老旧电商后台系统。

渴望学习新技术的他在工作中无缘Docker和K8s。

他开始自学Vue3并使用SpringBoot3完成了一个前后端分离的Web应用系统,并打算将其用Docker容器化后用K8s上云。

7 上云之路

为了体验上云,马意浓在网上查阅了大量资料。

✅他发现,在k8s云集群里运行前后端分离的web应用,有两种选择。

第一种,可以使用云服务商所提供的k8s新用户免费试用服务。

第二种,可以使用能在本地电脑上运行的轻量级k8s发行版。

他觉得要真正体验上云,还是第一种更地道。

7.1 三大主要的k8s云集群服务厂商

😃他在网上搜索了一下,了解到2024年2月份市面上主要的k8s云集群服务厂商有3家。

第一家是k8s的创造者谷歌。它在2015年推出了Google Kubernetes Engine,简称GKE。目前支持K8s的1.29版。

第二家是k8s的拥趸微软。它在2017年推出了Azure Kubernetes Service,简称AKS。目前支持K8s的1.28版。

第三家是云计算的鼻祖AWS。它紧随微软之后,在2018年推出了Elastic Kubernetes Service,简称EKS。目前支持K8s的1.29版。

马意浓知道,这些云厂商一般会让新用户免费试用k8s云集群1~3个月。

考虑到访问的便利性,他计划选择微软的Azure k8s服务。该服务提供1个月的免费试用,且提供2个节点。

他去Azure k8s service云平台官网,免费注册了一个账号。

但天有不测风云。注册完的第二天,他所维护的公司老旧系统的生产环境,就开始频繁出现故障。

他不得不经常在晚上和周末去单位加班修bug。这搞得他一点都没空去试用。

💔等到他终于忙过这阵,要试用时,发现已经过了1个多月,免费试用刚好过期。

但AKS页面有提示,说虽然免费试用已经过期,但可以按实际使用量来付费使用。

⚠️他想起前不久网上出现的一些文章。这些文章提到,由于云厂商的k8s服务收费昂贵,一些之前使用云服务的企业不堪承受高昂的云服务费用,因此选择离开公有云,转而自建私有云。结果确实节省了不少费用。

😃另外,那段时间,他还在网上看到一幅相关的漫画。

画面中有两个流浪汉。他们坐在公园的长椅上,翘着二郎腿在聊天。

一个问:「你咋变穷的?赌博?还是吸毒?」

一个答:「我忘了关一个EC2实例。」

看完这幅漫画,马意浓会心一笑。如图1。

图1 程序员因忘关一个EC2实例而变穷成为流浪汉

马意浓上网查了一下,发现EC2是亚马逊公司知名的云服务。它可以让用户在上面租用虚拟机,运行应用程序。最后依据应用程序实际使用量和数据流出量,按月计费。

💔马意浓寻思,自己这个上云新手,要是没有设计好云服务上的微服务,导致流量不合理,那么产生高昂云服务账单的风险也很大。

他不禁心里有点发虚。

7.2 能在本地电脑运行的7种轻量级k8s发行版

✅他于是打算试试能在本地电脑运行的轻量级k8s发行版。

他在网上搜到了DevOps工程师Kasper Siig在earthly.dev网站上发表的相关文章,以及microk8s.io和thechief.io网站上的相关文章,了解了7种轻量级k8s发行版的有关信息。

但他不知道在这7种发行版中,究竟该选哪个。或许可以先试用一下用户量最大的那个发行版。

马意浓注意到Siig在文章中使用了Google Trends趋势图,来查看全球网友以这7种发行版的名字进行搜索的搜索量排名。

他觉得这是一个很聪明的做法。用户最近几年用谷歌对这7种发行版的搜索量,可以近似认为就是这7种发行版的用户量。

因为google trends一次最多只能对比5种搜索词,所以马意浓通过替换搜索词,对比了三次。如图2。

图2 Google Trends显示的从2019到2024年这5年来网友用谷歌对5种轻量级k8s发行版名字的搜索量对比

根据Google Trends显示的从2019到2024年这5年来,网友用谷歌对5种轻量级k8s发行版名字的搜索量对比图,他把这7种轻量级k8s发行版,按搜索量从大到小粗略地排了3个阵营。

代码语言:javascript
复制
第一阵营:Docker Desktop
第二阵营:minikube 和 k3s
第三阵营:k3d、MicroK8s、kubeadm 和 kind (K8s IN Docker)

✅马意浓从趋势图清楚地看出,从2022年初到如今的2024年初这两年,图中用蓝色曲线代表的Docker Desktop的用户量,已经一骑绝尘,远远甩开其他竞争对手,独占第一阵营,实现了遥遥领先。

而同属于第二阵营的红色曲线代表的minikube,以及黄色曲线代表的k3s,与Docker Desktop相比,用户量少了一大截。

剩下的4个发行版,就都属于第三阵营了。它们与第二阵营相比,用户量也少了一大截。

他又根据上面三篇文章,在笔记软件里,分别记录了这7种发行版的创建者、一句话介绍、优势和劣势等信息。

7.2.1 Docker公司的Docker Desktop

🔥用户量排名第一阵营中,只有Docker公司的Docker Desktop。

自2019年8月8日发布Docker Desktop Community 2.1.0.1以来,Docker Desktop的用户量开始稳步接近昔日老大minikube。

2020年1月,Docker Desktop的用户量已经超越了minikube。

2021年8月底,在Docker公司开始对中大型企业收取Docker Desktop使用费后,Docker Desktop的用户量就开始实现跳跃性增长,大幅领先于minikube。

✅Docker Desktop应该是2024年特别易于安装和使用,且用户界面特别友好的快速开发容器化应用的软件。

Docker Desktop还有一个特别吸引人的地方,就是对于个人用户、学校师生、非商业的开源项目、员工数没超过250人且年收入没超过1000万美元的小型公司,完全免费。

💔但Docker Desktop只支持单node集群,不支持多node的集群,也不允许自定义k8s功能。

另外,从2021年8月31日开始,对于那些员工数超过250人或年收入超过1000万美元的中大型公司,使用Docker Desktop须付费。

7.2.2 K8s SIG开源社区的minikube

🔥用户量排名第二阵营中,有K8s特别兴趣小组(Special Interest Group, SIG)的一个开源社区所开发和维护的minikube。

在2016年5月31日首次发布之后的5年里,minikube用户量一直在轻量级k8s发行版领域稳居榜首。

直到2022年1月,它的用户量才被Docker Desktop远远甩开。

✅minikube的优势,是能较全面地支持本地开发所需的所有k8s功能。另外,它还允许用户自定义k8s功能。

💔但minikube与Docker Desktop一样,也只支持单node集群,不支持多node集群。也不支持自动化高可用。

另外维护minikube的SIG开源社区中的程序员,仅出于个人兴趣而为用户提供帮助。他们无法提供稳定的技术支持服务。

7.2.3 Rancher公司的k3s

🔥用户量排名第二阵营中,有Rancher公司专为无人值守和资源受限的IoT和边缘设备,开发和维护的高可用k8s发行版k3s。

K3s于2019年2月26日首次发布。在2023年10月,它的用户量就赶上了排名第二的minikube,跻身第二阵营。

✅k3s的优势是占用空间小,支持多node集群,支持自动化高可用,使用场景可以逼真模拟IoT生产环境。

另外,k3s背后的Rancher公司实力雄厚,能为企业客户提供稳定的技术支持服务。

💔然而,由于k3s是专为资源受限的IoT或边缘设备设计,所以其k8s功能是经过剪裁的。这对于某些用户来说,就显得不够完整。

这或许就是它以k8s的字母数量3,而将自己命名为k3s的用意。

另外,k3s只能在Linux上安装和运行。当配置多k8s服务器时,k3s的手工配置工作量较大。它还不允许自定义k8s功能。

7.2.4 有Rancher公司参与的开源社区的k3d

🔥用户量排名第三阵营中,有Rancher公司参与的开源社区所开发和维护的k3d。

k3d于2019年4月3日首次发布。它可以看作是k3s的扩展和改进版。

k3d是一款轻量级的封装器,用于在Docker容器中运行k3s,使得在Docker中创建单node和多node的k3s集群变得非常容易。

✅k3d支持多node集群,支持自动化高可用。

💔k3d的劣势,则与k3s相同。

7.2.5 Canonical公司的MicroK8s

🔥用户量排名第三阵营中,有Canonical公司所开发和维护的产品MicroK8s。这家公司因开发Ubuntu而大名鼎鼎。

MicroK8s于2018年12月首次发布,也是一款开源产品。

它能用于容器化应用程序的自动化部署、扩展和管理。它提供核心k8s组件的功能。

✅MicroK8s占用空间较小。它支持自动化高可用。它不仅适用于单node集群,也适用于高可用的多node的生产集群。

它适用于云环境、本地环境、边缘设备和IoT设备。

Canonical公司将其定位为产品,这意味着这家公司能为企业客户提供稳定的技术支持服务。

💔但MicroK8s难以在不支持 snap 包管理器的 Linux 计算机上安装。它不允许自定义k8s功能。同时它也缺乏Canonical官方支持的社区。

7.2.6 有vmware公司参与的开源社区的kubeadm

🔥用户量排名第三阵营中,有vmware公司参与的开源社区所开发和维护的kubeadm。

Kubeadm于2016年9月首次发布。它是为方便创建k8s集群而设计的快捷工具,融入了创建k8s集群的最佳实践。

✅Kubeadm的优势,是一切k8s功能皆可配置。用户可借助配置过程,学习k8s。一旦配置成功,用户就可快捷创建k8s集群。

因大量运维工程师都在使用kubeadm创建生产环境的k8s集群,故它更贴近生产场景。

另外它属k8s自家工具,所以用户可获得k8s社区专家的帮助。

💔Kubeadm的劣势,是配置过程较复杂且易出错。另外,它仅能在Linux上安装和运行。

7.2.7 K8s SIG开源社区的kind

🔥用户量排名第三阵营中,有K8s特别兴趣小组SIG的另一个开源社区所开发和维护的kind。kind就是Kubernetes IN Docker的缩写。

Kind于2019年2月11日首次发布。它是将 Docker 容器作为node来运行本地k8s集群的工具。

虽然它主要为测试k8s本身而设计,但也可用于本地k8s应用开发或CI持续集成流水线。

✅kind的优势,是支持多node集群。它还可用于测试k8s本身。另外也可用于在CI持续集成流水线上测试k8s应用的质量。它还允许自定义k8s功能。

💔kind的主要劣势,是在启用k8s功能时,只能编辑 YAML 文件,而缺乏方便易用的 CLI 命令。另外它所属的开源社区中的程序员,也仅出于个人兴趣为用户提供帮助。企业客户无法购买稳定的技术支持服务。

😃马意浓在回顾了这7种轻量级k8s发行版的优势和劣势后,决定选用最省事的发行版,也就是使用Docker Desktop所提供的k8s功能。

马意浓知道,他目前最大的需求,就是体验k8s。所以尽管Docker Desktop中的k8s不支持多node集群,也不允许自定义k8s功能,他也不在乎。

7.3 在Docker Desktop中打开k8s开关以让kubectl正常工作

之前为了能在WSL2的Ubuntu中使用docker,他已经在Windows 11上安装好了Docker Desktop。

他从Stuart Leeks的WSL2的书中了解到,要使用Docker Desktop的k8s功能,无须安装新软件,只须在Docker Desktop里打开一个开关即可。

他在Docker Desktop界面中,点击最上方靠右的齿轮图标,打开Settings页面。

然后他点击左侧的Kubernetes选项,并在右侧勾选Enable Kubernetes。然后点击Apply & restart按钮。

Docker Desktop界面左下角,很快出现了一个背景为黄色的代表k8s的小舵轮的图标。

等了好一会儿,小舵轮的背景色才从黄色,变为绿色。如图3。

图3 在Docker Desktop中打开Kubernetes开关以让kubectl能正常工作

他觉得这应该表示k8s已经正常运行了。

为了证实这一点,马意浓打开了一个Ubuntu终端窗口。

✅他先运行显示k8s版本号的命令kubectl version -o yaml

屏幕很快显示出clientVersion、kustomizeVersion和serverVersion的详细信息。

他问AIGC这3个version分别对应什么软件的版本。

AIGC回答:「clientVersion,指访问k8s集群控制平面的客户端工具kubectl的版本。」

「kustomizeVersion,指定制化k8s配置的工具kustomize的版本。」

「serverVersion,指kubectl工具所访问的k8s集群控制平面,也就是主服务器的版本。」

能够成功运行这条命令,就表明k8s已经在Ubuntu终端里正常运行了。

✅马意浓还是感觉意犹未尽。他又运行了查看node的命令kubectl get nodes

屏幕只显示了一个名为docker-desktop的node。

代码语言:javascript
复制
NAME             STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane   16m   v1.29.1

这就印证了他之前所读到的Docker Desktop的劣势,也就是它只支持单node的集群。

「单node……」

马意浓自言自语:「node是k8s里面的什么概念?它和曾经读到过的pod、container和cluster之间,到底有什么关系?」

欲知后事如何,且听下回分解。

🔥【未完待续


❤️欲读系列故事的全集内容,可搜用户“程序员吾真本”,找到“2024程序员容器化上云之旅”专栏阅读。

🔥后面连载内容大纲先睹为快

🔥8 复活重生

8.1 在k8s云集群中运行shopping list web app时如何配置前端app在k8s云集群中的对外域名和端口号以解决CORS问题

8.2 在全绽园的帮助下为前端app配置ingress后解决了这个问题

8.3 在k8s云集群中的软件架构

8.4 如何新增k8s的deployment、service和ingress的配置文件,以便使用kubectl命令将ingress和postgres、shopping-list-api和shopping-list-front-end这3个微服务部署到k8s上

8.5 构建后端docker image并推送到docker hub

8.6 构建前端docker image并推送到docker hub

8.7 在k8s云集群上配置postgres、shopping-list-api和shopping-list-front-end三个微服务和ingress并运行

8.8 清理现场

🔥9 取经归来

当最终把前后端分离的web应用成功部署到azure k8s云集群上,并能顺利使用后,马意浓把整个容器化和上云之旅,写成系列文章,分享给其他程序员。


😃你能否跟着马意浓一步步做下来?在阅读中有任何疑问,欢迎在留言区留言。我会一一回复

❤️如果喜欢本文,那么点赞留言,并转发给身边有需要的朋友,就是对我的最大支持😃🤝🙏。