Java程序员马意浓在互联网公司维护老旧电商后台系统。
渴望学习新技术的他在工作中无缘Docker和K8s。
他开始自学Vue3并使用SpringBoot3完成了一个前后端分离的Web应用系统，并打算将其用Docker容器化后用K8s上云。
为了体验上云，马意浓在网上查阅了大量资料。
?他发现，在k8s云集群里运行前后端分离的web应用，有两种选择。
第一种，可以使用云服务商所提供的k8s新用户免费试用服务。
第二种，可以使用能在本地电脑上运行的轻量级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。
马意浓上网查了一下，发现EC2是亚马逊公司知名的云服务。它可以让用户在上面租用虚拟机，运行应用程序。最后依据应用程序实际使用量和数据流出量，按月计费。
?马意浓寻思，自己这个上云新手，要是没有设计好云服务上的微服务，导致流量不合理，那么产生高昂云服务账单的风险也很大。
他不禁心里有点发虚。
?他于是打算试试能在本地电脑运行的轻量级k8s发行版。
他在网上搜到了DevOps工程师Kasper Siig在earthly.dev网站上发表的相关文章，以及microk8s.io和thechief.io网站上的相关文章，了解了7种轻量级k8s发行版的有关信息。
但他不知道在这7种发行版中，究竟该选哪个。或许可以先试用一下用户量最大的那个发行版。
马意浓注意到Siig在文章中使用了Google Trends趋势图，来查看全球网友以这7种发行版的名字进行搜索的搜索量排名。
他觉得这是一个很聪明的做法。用户最近几年用谷歌对这7种发行版的搜索量，可以近似认为就是这7种发行版的用户量。
因为google trends一次最多只能对比5种搜索词，所以马意浓通过替换搜索词，对比了三次。如图2。
根据Google Trends显示的从2019到2024年这5年来，网友用谷歌对5种轻量级k8s发行版名字的搜索量对比图，他把这7种轻量级k8s发行版，按搜索量从大到小粗略地排了3个阵营。
第一阵营：Docker Desktop
第二阵营：minikube 和 k3s
第三阵营：k3d、MicroK8s、kubeadm 和 kind (K8s IN Docker)?马意浓从趋势图清楚地看出，从2022年初到如今的2024年初这两年，图中用蓝色曲线代表的Docker Desktop的用户量，已经一骑绝尘，远远甩开其他竞争对手，独占第一阵营，实现了遥遥领先。
而同属于第二阵营的红色曲线代表的minikube，以及黄色曲线代表的k3s，与Docker Desktop相比，用户量少了一大截。
剩下的4个发行版，就都属于第三阵营了。它们与第二阵营相比，用户量也少了一大截。
他又根据上面三篇文章，在笔记软件里，分别记录了这7种发行版的创建者、一句话介绍、优势和劣势等信息。
?用户量排名第一阵营中，只有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须付费。
?用户量排名第二阵营中，有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开源社区中的程序员，仅出于个人兴趣而为用户提供帮助。他们无法提供稳定的技术支持服务。
?用户量排名第二阵营中，有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功能。
?用户量排名第三阵营中，有Rancher公司参与的开源社区所开发和维护的k3d。
k3d于2019年4月3日首次发布。它可以看作是k3s的扩展和改进版。
k3d是一款轻量级的封装器，用于在Docker容器中运行k3s，使得在Docker中创建单node和多node的k3s集群变得非常容易。
?k3d支持多node集群，支持自动化高可用。
?k3d的劣势，则与k3s相同。
?用户量排名第三阵营中，有Canonical公司所开发和维护的产品MicroK8s。这家公司因开发Ubuntu而大名鼎鼎。
MicroK8s于2018年12月首次发布，也是一款开源产品。
它能用于容器化应用程序的自动化部署、扩展和管理。它提供核心k8s组件的功能。
?MicroK8s占用空间较小。它支持自动化高可用。它不仅适用于单node集群，也适用于高可用的多node的生产集群。
它适用于云环境、本地环境、边缘设备和IoT设备。
Canonical公司将其定位为产品，这意味着这家公司能为企业客户提供稳定的技术支持服务。
?但MicroK8s难以在不支持 snap 包管理器的 Linux 计算机上安装。它不允许自定义k8s功能。同时它也缺乏Canonical官方支持的社区。
?用户量排名第三阵营中，有vmware公司参与的开源社区所开发和维护的kubeadm。
Kubeadm于2016年9月首次发布。它是为方便创建k8s集群而设计的快捷工具，融入了创建k8s集群的最佳实践。
?Kubeadm的优势，是一切k8s功能皆可配置。用户可借助配置过程，学习k8s。一旦配置成功，用户就可快捷创建k8s集群。
因大量运维工程师都在使用kubeadm创建生产环境的k8s集群，故它更贴近生产场景。
另外它属k8s自家工具，所以用户可获得k8s社区专家的帮助。
?Kubeadm的劣势，是配置过程较复杂且易出错。另外，它仅能在Linux上安装和运行。
?用户量排名第三阵营中，有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功能，他也不在乎。
之前为了能在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。
他觉得这应该表示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。
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云集群上，并能顺利使用后，马意浓把整个容器化和上云之旅，写成系列文章，分享给其他程序员。
?你能否跟着马意浓一步步做下来？在阅读中有任何疑问，欢迎在留言区留言。我会一一回复。
??如果喜欢本文，那么点赞和留言，并转发给身边有需要的朋友，就是对我的最大支持???。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
