首页 文章 精选 留言 我的

精选列表

搜索[k8s],共3940篇文章
优秀的个人博客,低调大师

k8s 管理机密信息 - 每天5分钟玩转 Docker 容器技术(155)

应用启动过程中可能需要一些敏感信息,比如访问数据库的用户名密码或者秘钥。将这些信息直接保存在容器镜像中显然不妥,Kubernetes 提供的解决方案是 Secret。 Secret 会以密文的方式存储数据,避免了直接在配置文件中保存敏感信息。Secret 会以 Volume 的形式被 mount 到 Pod,容器可通过文件的方式使用 Secret 中的敏感数据;此外,容器也可以环境变量的方式使用这些数据。 Secret 可通过命令行或 YAML 创建。比如希望 Secret 中包含如下信息: 用户名admin 密码123456 创建 Secret 有四种方法创建 Secret: 1. 通过--from-literal: kubectl create secret generic mysecret --from-literal=username=admin --from-literal=password=123456 每个--from-literal对应一个信息条目。 2. 通过--from-file: echo -n admin > ./username echo -n 123456 > ./password kubectl create secret generic mysecret --from-file=./username --from-file=./password 每个文件内容对应一个信息条目。 3. 通过--from-env-file: cat << EOF > env.txt username=admin password=123456 EOF kubectl create secret generic mysecret --from-env-file=env.txt 文件env.txt中每行 Key=Value 对应一个信息条目。 4. 通过 YAML 配置文件: 文件中的敏感数据必须是通过 base64 编码后的结果。 执行kubectl apply创建 Secret: 下一节我们学习如何使用这些创建好的 Secret。 书籍: 1.《每天5分钟玩转Kubernetes》https://item.jd.com/26225745440.html 2.《每天5分钟玩转Docker容器技术》https://item.jd.com/16936307278.html 3.《每天5分钟玩转OpenStack》https://item.jd.com/12086376.html

优秀的个人博客,低调大师

收购最大 K8s 服务商,重回独立的 SUSE 又要和 Red Hat 拼混合云

7月8日,SUSE 宣布收购 Kubernetes 管理平台公司 Rancher Labs,交易预计在2020年10月底之前完成。有外媒称,收购价预估在6亿至7亿美元之间。 宣布要收购之后,SUSE的介绍前缀中又多了个关键词——Kubernetes,变成企业级 Linux、Kubernetes、边缘计算和 AI 的首选开源创新者。 曾经,SUSE 是最早做 Linux 发行版的企业,但从2004年开始,SUSE 三度易主,直到去年才重新独立,估值早已无法比肩几乎同时成立的 Linux发行商红帽。SUSE 似乎也并不执着于企业版 Linux市场,而是向云业务、以及更多的IT 服务拓展,这才有了现在一长串的介绍前缀和收购动作。 2004年,Novell 收购 SUSE。 2010年,Attachmate 收购 Novell。 2014年,Micro Focus 收购 Attachmate。 2018-2019年, SUSE 与私募股权公司 EQT 的合作,重回独立。 SUSE 分配很多资源在 Linux 之外 “SUSE 在过去25年已经非常成功地交付了企业级 Linux产品……我们的客户对跨越边缘到核心数据中心,到云的计算解决方案需求日益增长,SUSE 必须能够跨越这些计算模型无缝部署和管理”,SUSE 某一部门总裁 Thomas Di Giacomo 去年曾提到,基于客户需求,SUSE 拓宽了产品覆盖范围,而不仅仅局限于 Linux。 用 SUSE时任公司副总裁,亚太区及日本总经理江永清接受采访时的言论,简单来说,SUSE 会分配很多资源在新产品方面。 其中就包括 Kubernetes 产品。Rancher Labs 提供开源企业级 Kubernetes 管理平台,旗舰产品 Rancher 有37,000个活跃用户,下载量超过1亿。Rancher 提供完整的 Kubernetes 软件栈,支持任何经过 CNCF 认证的 Kubernetes 发行版,包括 Google GKE,Amazon EKS 和 Microsoft AKS。 此前,Rancher Labs 的付费客户包括美国运通等大品牌,在中国,也有中国联通、华为、中国平安、中国人寿等大客户。收购完成之后,Rancher 将继续开放方式、并支持多种 Kubernetes 发行版和操作系统。Rancher Labs 的销售部门将纳入 SUSE,Rancher Lab 的 CEO 盛亮表示,他将领导 SUSE 的功能和创新部门合并,之后不需要再为 Rancher 保留单独的销售团队。 SUSE 近年非常重视云业务,也曾多次表达过对 Kubernetes 及混合云方向的看好。 2017年年初,彼时还在 MicroFocus 控制下的 SUSE收购了 HPE 公司旗下的云资产业务,包括 OpenStack基础设施即服务(IaaS),Cloud Foundry 平台即服务(PaaS),和 Stackato 云资产。SUSE 当时计划用这些资产,扩充自身的 OpenStack。 时任 SUSE 战略总裁 Michael Miller 对此评价:SUSE 的根基已经从企业 Linux 发行商,演变为开源的、定义软件的基础架构提供商。 SUSE 新发布的旗舰操作系统 SUSE LinuxEnterprise15服务器(SLES)ServicePack1,被认为是创建了一个桥接服务器和云之间的操作系统,可以合并容器开发与传统开发,结合旧有应用程序和微服务。此外,Leap 15.2还首次提供 Kubernetes 支持作为正式包。 去年年中,SUSE 的新总裁Melissa Di Donato 上任,被前任 CEO 评价为:“她是一位久经考验且充满活力的变革推动者,她的许多成就都发生在高增长云环境中的订阅业务上。” 对云的重视和看好也直接反映在SUSE 的营收上。2019年11月,SUSE 披露财务信息,称云服务提供商生态呈指数增长,在 Amazon Web Services,Google Cloud 和 Microsoft Azure 等云提供商的推动下,云收入增长了64%。 SUSE 的“新产品”还有边缘计算和 AI。 对标前文提及的关键词“边缘计算”,SUSE 官网在2019年发过一篇名为《2019年是物联网和边缘计算时代的到来吗?》的文章。文中提到,每家主要的 IT 分析公司都将边缘计算纳入到2019年度的顶级战略技术预测中。根据 IDC 的数据,到2023年,将有超过50%的新企业 IT 基础架构在边缘部署,而边缘应用程序数量则会增加800%。 今年5月,SUSE 的一篇博文还列举了一些边缘计算的应用场景,包括医疗保健和医院、智慧城市、自动驾驶。 同时,近期发布的 SLES 15 SP1也增强了对边缘工作负载的支持。用于 Arm 15的 SLES 15 SP1支持两倍于片上系统(SoC)处理器的选择,这扩大了对64位 Arm 服务器和物联网(IoT)设备上的存储和工业自动化应用程序的支持。对于64位 Raspberry Pi 设备,现在支持完整的 HDMI 音频和视频,并提供 ISO 映像以加快安装速度。 AI 方面。SUSE 官网最早从2018年开始更新有关 AI 的博客,也提出可以做 AIaaS 的服务商。 AIaaS 是人工智能即服务,是由 Amazon Web Services(AWS),Google Cloud,IBM Cloud 和 Microsoft Azure 等大型技术供应商提供的相对较新的公共云产品。它使企业可以将 AI 需求外包给供应商,如公共云供应商可以提供各种机器人,API 和机器学习框架,其他技术供应商提供 AIaaS 解决方案的其他要素。 而 SUSE Linux Enterprise 可为高性能数据分析工作负载,如人工智能和机器学习提供一个并行计算平台。 最新进展是,随着 Tensorflow 2.1最终进入 Package Hub,SUSE已经在免费和商业产品上,都提供了 AI 工具和框架。如 openSUSE Leap 15.2添加了许多机器学习和人工智能方面的软件包,包括 Tensorflow,PyTorch,ONNX 和其他流行的 AI / ML 解决方案包。 SUSE 对上述系列企业 IT 服务抱有很大期待。Melissa Di Donato 在今年5月的一个采访中透露, 三年内,计划将收入翻番,从近十亿,增加到十亿。 曾是最早的 Linux 发行商 SUSE 是成立最早,也曾是世界上最大的 Linux发行商之一。 SUSE 1992年成立,最初的目的是成为 UNIX 技术公司,并以 SlackeraLinux 为基础,推出 SoftlandingLinux System(SLS)/Slackware软件及 UNIX/Linux帮助文档。1994年,推出安装光盘,并重新命名为 S.u.S.E. Linux 1.0,之后又更名为 SUSE,还延伸出Professional等系列。 (从 SuSE 到 SLE / openSUSE 安装盒 图片来源:SUSE 官方网站) 早期 SUSE 的开发工作都是内部进行的,直到2005年,SUSE 在新雇主 Novell的领导下,开放 SUSE LinuxProfessional 系列的开发。2005年8月4日,Novell 公共关系科的领导及代言人Bruce Lowry表示,SUSE Linux Professional 系列的开发将变得更开放,也会让社群参与工作,新的开发计划名为 openSUSE,目的是为了吸引更多的用户及开发人员。2005年10月,新更新的 SUSE Linux 就有了 OSS 版、试用版和盒装零售版。 从 SUSE 开放开发的时间也可以看出,虽然 SUSE 早期的业务是基于开源软件,但他们却并没有采用开源开发的方式。并且,在模仿红帽的订阅模式之前,SUSE 也并没有走出自己的商业模式。 SUSE 面向企业用户的主打产品是 SUSE Linux Enterprise系列,采用订阅模式。现在,SUSE 的企业版也有针对不同业务的服务,包括针对 SAP 应用、X86服务器、和针对 X86服务器的高可用拓展(服务器双活/HA)。 订阅模式帮 SUSE 挣到了一部分市场。2019财年,SUSE 公布,交付订阅收入增长了299%,SUSE 也已经取得连续九年的增长。 但与此同时,红帽已经达成约连续20年的营收增长。当红帽用订阅模式从一众零售商中脱颖而出之后,SUSE 名气渐弱。2018年,私募股权公司 EQT 收购 SUSE 时,花了25亿美元,次年,IBM收购红帽花了340亿美元。 不仅如此,SUSE 还经常被拿来与 Red Hat、Ubuntu 一起作比较。尤其是在中国,SUSE 远不如后两者人气高。有人分析过,为什么 SUSE 会错失发展的机会。2012年,有自称是 openSUSE 中文维基唯一的非官方维护者的用户发表观点,解释为什么 openSUSE 的人气为何远不如 Ubuntu 和 Fedora。 相较 Ubuntu,openSUSE 不够重视桌面用户,而是侧重企业用户。 德国注重版权保护,openSUSE 纯净度高,且设置了更复杂的分发条件,对用户来说有使用壁垒。 早年并不注重中国市场。而老对手红帽是中国政府邀请进来的。 SUSE 官方的人从来没有专职专业的去做过社区,SUSE 的中文社区人员没有一个是专职的开发者和程序员,没有大学资源。 这些观点在今天看来,也有参考意义。如第一点,SUSE 的目标客户是企业,拼社区自然拼不过 Ubuntu。此外,对于中国市场,SUSE 虽然正在努力开拓,但效果如何并不好说,有开发者表示 SUSE 的热度在下降,Melissa Di Donato 去年在接受中国媒体采访时,并未透露中国市场的份额,而是说,不会针对某一个具体地区去分拆来看具体的营收,但可以说中国市场在以每年双位数的速度在增长。 值得注意的是,即便是在 SUSE 的起源地德国,SUSE 的使用率似乎也不算太高。SUSE 在欧洲的业务未占一半,北美市场占比接近40%。而德国慕尼黑政府近年多次在微软和开源软件之间更换时,也并未采用 SUSE 的 Linux。 不过,SUSE 也明确表示,不会放弃 Linux 和开源的策略。 江永清在说 SUSE 会分配很多资源在新产品方面时,也强调,传统的操作系统业务非常重要,“因为现在还有很多客户,还有以前遗留下来老的操作系统,大部分会迁移到开源的平台上,开源到底是用免费的开源,还是用订阅的开源,对我们来说生意上会有很大的不一样,我们肯定要保证住。”此外,他还表示,中国市场,应用交付的要求比境外高很多,搞数据中心的主管人员可能原则上都会往开源的方向走。 开源独立性与混合云 经历去年的换将和重回独立之后,SUSE 常强调两点,一是 SUSE 是最大的独立开源公司,二是会将开源与混合云结合。 早在2019年4月,IBM 对红帽的收购完成之前,SUSE 时任 CEO Brauckmann 就表示,SUSE 将很快成为最大的、独立的 Linux 公司。有外媒报道,SUSE 的几位高管表示,客户已经与他们接触,因为他们不依赖于 IBM。这次在官宣收购消息时,也再次强调 SUSE 是世界上最大的独立开源公司。 开源界几次大的收购,让“独立的”开源公司成为珍稀。 2018 年,微软以 75 亿美元收购了全球最大源代码托管平台 GitHub。2019年,IBM 收购最大 Linux 发行商 Red Hat……这也让开源公司的独立性问题受到关注。开发者会担心,开源公司产品会受到控股企业的影响,从而影响中立性。 不过,即便红帽已经被 IBM 收购,而 SUSE 又重回独立,但是,SUSE 已经依附在其他大型公司下经营了十多年,此时站出来大肆强调独立性对开源厂商的重要性,似乎并没有多大的说服力。 “我并不想特别强调我们是一个反潮流者。兼并和收购都是生意,到最后买卖双方当成一个协议。另外,看买方想要得到什么?有时候买方希望得到更好的回报,从这个角度来看,各有所取。”江永清曾说,独立之后,变化比较大的是优先级会按自身的意思去执行,“大企业有自己的经营方向,你要配合他的经营方向,你还要跟各个部门之间进行协调。当然也有两面性的,一方面大家帮你忙,但是你永远是之一,不是唯一。” 此外,关于混合云。SUSE 加快转向混合云是在去年8月换了新的 CEO 之后。去年10月,SUSE 决定停止 OpenStack 新版本的生产,并不再销售 SUSE OpenStack Cloud,针对老用户的剩余订购期,SUSE 会提供过渡帮助。 放弃 Openstack,全面转向 Kubernetes,也代表着从传统私有云服务向混合云以及云原生的过渡。 Openstack 2010年7月诞生,由 RackSpace 公司和美国国家航空航天局 NASA 合作开发,是一个基于虚拟机技术的开源云计算平台。由于 OpenStack 底层使用虚拟化技术,而虚拟机隔离性好,稳定,OpenStack 适用于搭建私有云以及基于私有云的使用场景。 Kubernetes 是 Google 在2014年发布的一个开源项目,之后捐献给 CNCF 基金会,是基于容器的集群管理平台。一个 Kubernetes 系统,通常称为一个 Kubernetes 集群(Cluster),主要包括两部分,一 个 Master 节点(主节点),和一群 Node 节点(计算节点)。Kubernetes 被认为适用于业务变化快,业务量未知的静态使用场景。 “SUSE 正在将重点放在应用交付市场及其机遇上 ,并增加我们的战略投资,以适应行业中的技术趋势。”SUSE 发展和战略联盟总裁 Michael Miller 在一封电子邮件中说道。而 Kubernetes 更加灵活的场景部署,更符合 SUSE 的战略。 看好 Kubernetes 的也不只是 SUSE。Gartner 预测,随着本地云应用和基础设施的普及,到2024年,成熟经济体中,容器管理,尤其是 Kubernetes 的使用,将从2020年不到35%,上升到75%以上。 此次收购,也会让 SUSE 在云市场上,再次和老对手 Red Hat 直接竞争。Red Hat 也有自己的 Kubernetes 管理平台 OpenShift,Red Hat 今年4月新上任的总裁Paul Cormier 同样是开放式混合云的倡导者。 现在 SUSE 似乎希望将开源、独立、云服务三个词融在一起,以凸显优势。就像其 CEO Melissa Di Donato 所说:“此次收购增强了我们提供更全面的产品组合、选择更大的客户、不锁定供应商的能力。它还将使我们在与云服务提供商、独立的硬件供应商、系统集成商、和渴望提供更优客户体验的经销商的合作中发挥更战略性的作用。 ” 不过,独立与开源对 SUSE 以后的商业发展作用有多大,也并不好说。 “你说我是一家开源公司,不代表就是一个可以商业化的东西”,从投资者的角度看市场,职业 VC 高宁认为,选择开源本质上只是个技术方向性的问题,不是商业问题,更不能成为一种商业模式,“首先是你面对什么样的客户、想要解决什么样的问题,然后才是去考虑选择什么样的商业模式。” 那么,混合云是否会是未来?

优秀的个人博客,低调大师

如何使用k3s+树莓派在生产中构建轻量K8S裸机集群

Boogie Software是欧洲著名的金融科技公司,多年来致力于为银行提供Fintech、AI、大数据高性能后端、移动应用程序、数据分析及UX等创新服务,帮助银行推动数字化转型。凭借过去十多年在该领域的独特经验,Boogie已成为数字银行服务提供商中的领导者。 本文作者是Boogie Software的资深软件架构师Jari Tenhunen。他拥有超过15年的软件开发经验,擅长信息安全和网络协议。并且长期管理项目和团队,在其中主导软件架构和技术,成功将多个产品推向市场。 Boogie Software的IT团队在很多客户银行的核心银行业务数字化的项目中使用到了Kubernetes和容器技术,因此我们始终在想Kubernetes能如何使用更合适的硬件在本地工作。在本文中,我将详细介绍我们如何在树莓派上构建轻量级裸机集群,以在公司网络中运行应用程序和服务。 我们之所以这么做,有两个原因:第一,通过建立集群,我们将可以拥有一个平台,来可靠、灵活地运行公司网络内部应用程序和服务;第二,我们可以通过这次机会学习更多关于Kubernetes、微服务以及容器的技能。如果你也想要参照我们的经验来构建一个相似的系统,我建议你至少要了解关于Docker容器、Kubernetes关键概念(节点、pod、服务、deployment等)以及IP网络的基础知识。 硬件准备 你需要准备以下设备: 树莓派2B/3B/3B+ 的型号,至少一个。你甚至在单个开发板上运行某些应用程序,但是建议使用两个或更多的开发板来分散负载并增加冗余。 电源和可用于树莓派的SD卡,现有的以太网交换机或空闲端口以及一些电缆。 在我们的设置中,我们目前有4个树莓派3代B+开发板,所以在集群中有一个master/server和3个代理节点。如果树莓派有外壳当然更好,我们的同事用3d打印机设计了一个。此外,机壳的背面有两个用于冷却的风扇,每个开发板都位于一个托盘上,该托盘可以热插拔以进行维护。这些托盘前面还设有activity/heartbeat LED和电源开关的位置,它们都连接到开发板的GPIO接头。 软件准备 对于Kubernetes的实现,我们使用的是k3s。k3s是由Rancher Labs推出的一款轻量级、通过CNCF一致性认证的Kubernetes发行版。尽管这是一款刚推出不久的产品,但它真的十分稳定和易用,可以实现秒级启动。让k3s从其他轻量的Kubernetes发行版脱颖而出的原因是,k3s可供生产使用,而诸如microk8s或Minikube之类的项目则无法实现这一目的,并且k3s十分轻巧,还可以在基于ARM的硬件上很好地运行。在k3s中,任何设备上安装Kubernetes所需的一切都包含在这一个40MB的二进制文件当中。 k3s几乎能在任何Linux发行版中很好地运行,因此我们决定将Raspbian Stretch Lite作为基础OS,因为我们不需要在开发板上添加任何额外的服务或者桌面UI。k3s确实需要在Linux内核中启用cgroup,这可以在Raspbian上通过向/boot/cmdline.txt:添加以下参数来实现: cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory 安装k3s k3s非常友好的地方在于,它可以实现平滑安装过程。你准备好你的server硬件之后,仅需几分钟就可以完成设置,因为它仅需一行命令就能安装server(主节点): curl -sfL https://get.k3s.io | sh - 代理节点也是如此: curl -sfL https://get.k3s.io | K3S_TOKEN=<token_from_server> K3S_URL=https://<server_ip>:6443 sh - 其中token_from_server是来自服务器的文件/ var / lib / rancher / k3s / server / node-token的内容,server_ip是服务器节点的IP地址。至此,我们的集群已经启动并正在运行,我们可以开始部署工作负载: root@k3s-server:~# kubectl get nodes NAME STATUS ROLES AGE VERSION k3s-node1 Ready <none> 40s v1.13.4-k3s.1 k3s-server Ready <none> 108s v1.13.4-k3s.1 为了管理和监控集群,我们安装了Kubernetes Dashboard,它能够提供给非常方便的web界面来查看整个系统的状态、执行管理员操作并访问日志。同时,本地安装和运行kubectl命令也非常有帮助,因为它可以让你从自己的计算机管理集群,而无需ssh进入集群。为此,你只需要安装kubectl,然后将集群信息从服务器节点config /etc/rancher/k3s/k3s.yaml复制到本地kubeconfig文件中(通常是${HOME}/.kube/config)。 使用负载均衡器暴露服务 默认情况下,部署在Kubernetes集群上的应用程序仅可以在集群中获取(默认服务类型是ClusterIP)。如果想要从集群外部获取应用程序,有两个选项。你可以使用NodePort类型配置服务,该服务在静态端口的每个节点IP上暴露服务,你也可以使用负载均衡器(服务类型LoadBalancer)。然而,NodePort服务有限制:它们使用自己专用的端口范围,我们只能通过端口号来区分应用。k3s内置了一个简单的负载均衡器,但由于它使用的是节点的IP地址,我们可能很快就会用完IP/端口组合并且无法将服务绑定到某个虚拟IP。基于这些原因,我们决定部署MetalLB——一种用于裸机集群的负载均衡器实现。 只需应用YAML manifest即可安装MetalLB。在现有网络中运行MetalLB的最简单方法是使用所谓的第2层模式,这意味着集群节点通过ARP协议宣布本地网络中服务的虚拟IP。为此,我们从内部网络保留了一小部分IP地址用于集群服务。MetalLB的配置如下所示: apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | address-pools: - name: company-office protocol: layer2 addresses: - 10.10.10.50-10.10.10.99 使用此配置,集群服务将被暴露在范围为10.10.10.50—10.10.10.99的地址中。为了绑定服务到指定的IP,你可以在服务清单中使用loadBalancerIP参数: apiVersion: v1 kind: Service metadata: name: my-web-app spec: ports: - name: http port: 80 protocol: TCP targetPort: 8080 loadBalancerIP: 10.10.10.51 selector: app: my-web-app type: LoadBalancer 在负载均衡中,我们面临诸多挑战。例如,Kubernetes中限制在单个负载均衡器中同时使用TCP和UDP端口。要解决这一问题,你可以定义两个服务实例,一个用于TCP端口,另一个用于UDP端口。其缺点是,除非启用IP地址共享,否则你需要在不同的IP地址中运行这两个服务。而且,由于MetalLB是一个年轻项目,因此也存在一些小问题,但我们相信这些很快都会得到解决。 添加存储 k3s暂时没有内置的存储解决方案,所以为了使Pod能够访问持久性文件存储,我们需要使用Kubernetes的插件来创建一个。由于Kubernetes的目标之一是使应用程序与基础架构解耦并使其可移植,因此Kubernetes中用PersistentVolume(PV)和PersistentVolumeClaim(PVC)的概念定义了用于存储的抽象层。详细的概念解释可以参照我们之前发过的文章:详解Kubernetes存储关键概念。PV是通常由管理员配置并可供应用程序使用的存储资源。另一方面,PVC描述了应用程序对某种类型和一定数量的存储的需求。创建PVC(通常作为应用程序的一部分)时,如果有一个尚未使用且满足应用程序PVC要求的可用PVC,它将绑定到PV。配置和维护所有这些需要手动工作,因此动态配置卷应运而生。 在我们的基础架构中,我们已经有一个现有的NFS服务器,因此我们决定将其用于集群持久性文件存储。在我们的案例中,最简单的方法是使用支持动态配置PV的NFS-Client Provisioner。Provisioner只需在现有的NFS共享上为每个新PV(集群映射到PVC)上创建新目录,然后将PV目录挂载在使用它的容器中。这样就无需配置NFS共享到单个pod中的卷,而是全部动态运行。 为ARM交叉构建容器镜像 显然,在基于ARM的硬件上(如树莓派)运行应用程序容器时,需要根据ARM的架构构建容器。在ARM架构容器中构建自己的应用程序时,可能会遇到一些陷阱。首先,基础镜像需要可用于你的目标架构体系。对于树莓派3来说,通常需要使用arm32v7的基础镜像,它们可以在大部分Docker镜像仓库中被调用。所以,当交叉构建应用程序时,确保你的Dockerfile包含以下代码: FROM arm32v7/alpine:latest 第二件需要注意的事是,你的主机Docker需要能够运行ARM二进制文件。如果你在mac上运行Docker,那操作将十分轻松,因为它对此有内置支持。如果是在Linux上,你需要执行一些步骤: 添加QEMU二进制文件到你的基础镜像 为了在Linux上的Docker中运行ARM二进制文件,镜像需要一个QEMU二进制文件。你可以选择一个已经包含了QEMU二进制文件的基础镜像,也可以在镜像构建过程中复制 qemu-arm-static二进制文件到其中,例如,通过将以下行添加到你的Dockerfile中: COPY --from=biarms/qemu-bin /usr/bin/qemu-arm-static /usr/bin/qemu-arm-static 安全警示:请注意下载和运行未知的容器就如同下载和运行位置的.exe文件。除业余项目外,其他任何项目都应使用扫描/审核过的镜像(如Docker官方镜像)或来自信任的组织和公司的容器镜像。 然后,你需要在创建Docker镜像的主机OS上注册QEMU。这可以简单地通过以下方式实现: docker run --rm --privileged multiarch/qemu-user-static:register --reset 可以在构建实际镜像之前将该命令添加到你的构建脚本中。总结一下,你的Dockerfile.arm应该看起来像这样: FROM arm32v7/alpine:latest COPY --from=biarms/qemu-bin /usr/bin/qemu-arm-static /usr/bin/qemu-arm-static # commands to build your app go here… # e.g. RUN apk add --update <pkgs that you need…> 并且你的build /CI脚本应该是: docker run --rm --privileged multiarch/qemu-user-static:register --reset docker build -t my-custom-image-arm . -f Dockerfile.arm 这将为你提供ARM架构的容器镜像。如果你对细节很感兴趣,请参阅: https://www.ecliptik.com/Cross-Building-and-Running-Multi-Arch-Docker-Images/ 自动化构建和上传到镜像仓库 最后一步是自动化整个流程,以便容器镜像可以自动构建并且自动上传到一个镜像仓库,在那里可以轻松地将其部署到我们地k3s集群。在内部,我们使用GitLab进行源代码管理和CI/CD,因此我们自然希望在其中运行这些构建,它甚至包括一个内置的容器镜像仓库,因此不需要设置单独的镜像仓库。 关于构建Docker镜像,GitLab有十分完善的文档(https://docs.gitlab.com/ee/ci/docker/using_docker_build.html ) ,因此我们不在此赘述。在为docker构建配置GitLab Runner之后,剩下要做的就是为该项目创建.gitlab-ci.yml文件。在我们的例子中,它看起来像这样: image: docker:stable stages: - build - release variables: DOCKER_DRIVER: overlay2 CONTAINER_TEST_IMAGE: ${CI_REGISTRY_IMAGE}/${CI_PROJECT_NAME}-arm:${CI_COMMIT_REF_SLUG} CONTAINER_RELEASE_IMAGE: ${CI_REGISTRY_IMAGE}/${CI_PROJECT_NAME}-arm:latest before_script: - docker info - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY build_image: stage: build script: - docker pull $CONTAINER_RELEASE_IMAGE || true - docker run --rm --privileged multiarch/qemu-user-static:register --reset - docker build --cache-from $CONTAINER_RELEASE_IMAGE -t $CONTAINER_TEST_IMAGE . -f Dockerfile.arm - docker push $CONTAINER_TEST_IMAGE release: stage: release script: - docker pull $CONTAINER_TEST_IMAGE - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE - docker push $CONTAINER_RELEASE_IMAGE 既然在容器镜像仓库中我们有了我们的镜像,我们只需要将它们部署到我们的集群中。为了授予集群访问镜像仓库的权限,我们在GitLab中创建了一个deploy令牌,然后将令牌凭据作为docker-registry 密钥添加到集群中: kubectl create secret docker-registry deploycred --docker-server=<your-registry-server> --docker-username=<token-username> --docker-password=<token-password> --docker-email=<your-email> 之后,可以在YAML文件PodSpec中使用deploy 令牌密钥: imagePullSecrets: - name: deploycred containers: - name: myapp image: gitlab.mycompany.com:4567/my/project/my-app-arm:latest 完成所有这些步骤之后,我们终于拥有了一个从私有镜像仓库中的源代码到ARM容器镜像的自动CI / CD流水线,可以将其部署到集群中。 结 语 总而言之,事实证明,建立和运行自己的裸机Kubernetes集群比预期的要容易。而且k3s确实是在边缘计算场景中和一般配置较低的硬件上运行容器化服务的明智选择。 一个小缺点是k3s尚不支持高可用(多主设备配置)。尽管单个主服务器设置已经具有相当的弹性,因为即使主服务器离线,服务仍可在代理节点上继续运行,我们还是希望为主节点提供一些冗余。显然,此功能正在开发中,但在此功能可用之前,我们建议从服务器节点配置中进行备份。

优秀的个人博客,低调大师

Spring Boot 2.3 分层jar包、优雅停机、完美支持 Docker\k8s,一起尝鲜儿吧

我是风筝,公众号「古时的风筝」,一个兼具深度与广度的程序员鼓励师,一个本打算写诗却写起了代码的田园码农! 文章会收录在 JavaNewBee 中,更有 Java 后端知识图谱,从小白到大牛要走的路都在里面。 Spring Boot 2.3 已经发布一个月了,这两天才想起来尝一尝鲜儿。除了常规的升级外,很大部分的升级是针对 Docker 的,让你不得不相信,Docker 容器化微服务已然大势所趋。还没有用过的同学,再不下手就晚了。 此次升级主要包括如下几个方面,接下来就跟着我一起来尝一尝吧。 准备工作 为了说明 Spring Boot 2.3 的新特性,必须创建一个项目,以便试验。 创建一个项目并启动 1、创建一个 Spring Boot 项目,可以到 https://start.spring.io/ 上创建,也可以使用 IDEA 自带的功能创建。选择版本 2.3.1,JDK 还是选择亲爱的 Java 8,引入 Web 和 Actuator 两个依赖包。 有一点要注意一下,在我写本文的时候,Spring Boot 2.3.1 还不能从中央仓库下载,需要添加 Spring Boot 官方的里程碑仓库。 <repositories> <repository> <id>spring-milestone</id> <name>Spring Milestone Repository</name> <url>https://repo.spring.io/milestone</url> </repository> </repositories> 2、在 pom 文件中引入 Maven 插件 <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>2.3.1.RELEASE</version> </plugin> </plugins> </build> 3、添加一个 Controller,做测试用。 @RestController public class PlayController { @GetMapping(value = "play") public String play(){ return "hey, play with me!"; } } 4、启动项目 mvn spring-boot:run 5、访问 http://localhost:8080/play,说明项目启动成功 更好的 Docker 支持 如果不使用 Docker 呢,那就直接打成 jar 包,使用如下命令 mvn package spring-boot:repackage 然后就可以把这个 Jar包部署到服务器了,当然这个过程可能是用自动化部署工具实现的,不如 jenkins 或者自研系统。 之前 Docker 打包方式 抛开公司(尤其是大厂)里成熟的自动化部署流程不谈,我这里说的是一般性小厂或者是个人项目。 如果你在之前的版本就已经用 Docker 方式,那基本上都是自己写 Dockerfile ,然后自己写脚本使用 Dockerfile 打镜像包,或者使用 Maven 插件,比如 dockerfile-maven-plugin,我之前写过一篇 Spring Boot 和 Docker 实现微服务部署,就是用的这种方式,可以对比着看一下。 Cloud Native Buildpacks 如果你了解 Dockerfiles 的话,那你肯定了解用 Dockerfiles 构建镜像的过程,需要你创建一个 Dockerfile 文件然后在里面写上构建镜像所需的一系列动作,而 Cloud Native Buildpacks 则无需配置类似的过程文件,很大程度上减轻了开发者的工作,提高了效率。这还不是最重要的,最重要的是它提供了更高层次的抽象能力,使镜像的分层更加清晰,并且合理有效的利用层缓存,这样一来,当我们对应用程序进行修改之后,再次构建镜像时的速度飞快,比如我们的应用只改了几行代码,那当我们使用 Buildpacks 构建镜像时,只需要在应用程序层进行重新构建,其他层使用缓存就可以,也就是只对变化了的层重新构建。 Spring Boot 2.3 Docker 方式 首先要确保你本地已经正常启动了 Docker 服务。 Spring Boot 2.3 官方的 Docker Maven 插件,从此不用再借助第三方了。我们前面创建项目的时候已经引入了这个 Maven 插件。 此插件不仅提供了打镜像包的功能,还有其他的常用功能,比如 run、repackage 等。 为什么前面要说 Cloud Native Buildpacks 呢,不是跑题啊,是因为 Spring Boot 2.3 生成 Docker 镜像包的方式就是集成了 Cloud Native Buildpacks。 那我们就打个镜像包试一下吧 mvn spring-boot:build-image 你以为马上就能看到成果了吗,还是太年轻。 大中华区开发者怎么了 对于中国的开发者来说,打包这一步不会太顺利,原因大家都很清楚。不出意外的话,应该会出现这样的错误,不出错可能才是意外。 [ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.3.1.RELEASE:build-image (default-cli) on project play: Execution default-cli of goal org.springframework.boot:spring-boot-maven-plugin:2.3.1.RELEASE:build-image failed: Docker API call to 'localhost/v1.24/images/create?fromImage=gcr.io%2Fpaketo-buildpacks%2Fbuilder%3Abase-platform-api-0.3' failed with status code 500 "Internal Server Error" and message "Get https://gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)" -> [Help 1] 出现这个问题的原因是因为 Buildpacks 调用 Docker API 创建镜像的方法,要访问 https://gcr.io ,从上面 pull 一些基础镜像下来,这是 Google 的 Google Cloud ,是 Google 的容器仓库,然而对于中国的开发者来说,这个地址是 404 的。 所以我们要加个系统级别代理,或者专门为 Docker 配置代理。我是在 Docker 中配置的代理,系统代理的影响太大。我本机安装的是 Docker Desktop,直接打开设置,在里面加上代理就可以了(别问我代理怎么搞,问我就是没有代理)。 好了,通过上面一顿猛如虎的操作,再次运行命令 mvn spring-boot:build-image 根据你的网速,等上一段时间,就会出现下面的结果,说明镜像创建成功了。 之后你可以使用 docker images命令查看。这时间也是醉了,40 years ago。 使用此镜像启动容器 使用命令直接启动容器。 docker run -it -p8080:8080 play:0.0.1-SNAPSHOT 然后访问 8080 端口,得到正确的返回结果,说明启动成功了。 Docker Image 的一个特点是,每个层都是前一层变化的增量。有一个工具叫做 dive,可以清楚的查看分层结构里面包含的内容。具体安装和使用请自行搜索。 使用 dive 查看的一个小技巧,因为镜像层包含的指令很多,所以我们选择只查看相对于上一层的增量内容,使用 Ctrl+L组合键。 然后按 Tab进入视图,然后按 Ctrl+U,去掉没有更改的选项,也就是只看变化的部分。 然后上下箭头可以切换层查看,比如下面这个图展示了一个 18 M 的层相对于上一层的变化内容,可以看出来这个层实际上就是应用程序层,包含了很多当前应用程序的类和第三方依赖包等。 分层 jar 包 分层打包配置很方便,最简单的方式就是在 pom 文件中加上如下配置: <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>2.3.1.RELEASE</version> <configuration> <layers> <enabled>true</enabled> </layers> </configuration> </plugin> 加上分层配置之后,仍然使用常规的命令打包 mvn package spring-boot:repackage 分层打包其实和以前的打包方式没有什么不同,打出来的包几乎和之前是完全一样的,分层其实只是逻辑上的抽象而已。打出的 jar 包结构如下(jar包其实就是个压缩包,可以解压缩查看目录结构) 在 jar 包的 BOOT-INF 目录下可以看到 classpath.idx和layers.idx两个文件,这两个就是为了分层 jar 的关键。 默认情况下会分成如下四个层。 dependencies 对版本没有要求的依赖包,也就是你的应用程序无论怎么改,都几乎不会影响的依赖包。 spring-boot-loader Spring Boot 加载类。 snapshot-dependencies对应用版本有要求的依赖包,比如应用升级后,可能同时需要升级的依赖包。 application 应用程序编译类和配置文件等。 在 layers.idx可以看出这个分层结构,用普通的文本编辑器就可以打开,比如 sublime。打开之后看到这样一个类似于 yaml 的结构,四个层以及他们所指的目录都清晰的列出来了。 - "dependencies": - "BOOT-INF/lib/" - "spring-boot-loader": - "org/" - "snapshot-dependencies": - "application": - "BOOT-INF/classes/" - "BOOT-INF/classpath.idx" - "BOOT-INF/layers.idx" - "META-INF/" classpath.idx文件列出了依赖的 jar 包列表,到时候会按照这个顺序载入。 - "spring-boot-starter-actuator-2.3.1.RELEASE.jar" - "spring-boot-starter-2.3.1.RELEASE.jar" - "spring-boot-2.3.1.RELEASE.jar" - "spring-boot-autoconfigure-2.3.1.RELEASE.jar" - "spring-boot-starter-logging-2.3.1.RELEASE.jar" - "logback-classic-1.2.3.jar" - "logback-core-1.2.3.jar" - "log4j-to-slf4j-2.13.3.jar" 自定义分层结构 如果我们想要在默认的 4 层上增加新的分层,Spring Boot 2.3 也提供了定制分层的功能。配置也很简单,在 plugin配置如下,指定了 layers.xml作为自定义分层配置 <configuration> <layers> <enabled>true</enabled> <configuration>${project.basedir}/src/layers.xml</configuration> </layers> </configuration> layers.xml的配置像下面这样 <layers xmlns="http://www.springframework.org/schema/boot/layers" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/boot/layers https://www.springframework.org/schema/boot/layers/layers-2.3.xsd"> <application> <into layer="spring-boot-loader"> <include>org/springframework/boot/loader/**</include> </into> <into layer="application" /> </application> <dependencies> <into layer="snapshot-dependencies"> <include>*:*:*SNAPSHOT</include> </into> <into layer="dependencies" /> </dependencies> <layerOrder> <layer>dependencies</layer> <layer>spring-boot-loader</layer> <layer>snapshot-dependencies</layer> <layer>application</layer> </layerOrder> </layers> 当你开启分层功能后,可以使用 -Djarmode查看分层情况。 java -Djarmode=layertools -jar target/play-0.0.1-SNAPSHOT.jar list 显示的结果就是分层情况,比如默认情况下就是这样,列出了 4 个默认分层。 dependencies spring-boot-loader snapshot-dependencies application 题外话: Djarmode其实就是个 Java-Agent,关于Java-Agent,可以看我之前写的一篇文章,Java 调试工具、热部署、JVM 监控工具都用到了它,挺有意思的。 分层包的意义 说了半天分层包了,那分层包到底有啥用呢? 这么说吧,它其实是为了和 Docker 配合使用的,如果你不用 Docker 方式部署,还是用原始 jar 包的方式,可以说没什么用,如果非得说有什么用,那就是让你更加清楚项目的依赖情况。 分层包 和 Docker 结合 前面介绍 Docker 镜像包的时候说了 Buildpacks 可以让你的镜像分层清晰,而 Spring Boot 2.3 提供的分层 jar 功能可以在镜像分层的基础上更上一层楼,使分层更加清晰。 那我们开启分层配置,然后重新打个 Docker 镜像出来看一看。 mvn spring-boot:build-image 然后再使用 dive 工具看一下启用分层 jar 功能后的 Docker 镜像分层情况,是不是变得更好了。前面的层都是一样的,都是一些集成镜像和配置,从 18 MB 的这个层开始的 4 个层就是启用分层后的4个层,分别对应 dependencies、spring-boot-loader、snapshot-dependencies、application 比如这个 5.4K 的 application 层。 那这样做有什么好处呢,前面不是说了吗,Buildpacks 打镜像包会使用缓存的,如果这一层没变那就不用重新打这一层,只需要重新打包修改过的层,这样一来,如果你只修改了 application 中的内容,比如新加了 Controller 或者配置文件等,那么只需要重新打包这一层,也就是几 K,几十K 不会很大,这样一来打包速度就很快了,要不然一个上百兆的镜像包也得需要一段时间。 优雅停机功能 什么叫优雅停机呢,假设这是一个分布式服务,其中一台服务所在的实体机需要打安全补丁,需要关机重启,那实体机关机之前要先把这个服务停掉。 关掉服务的方式,比如: 我不管,我就直接关实体机,至于服务,你命由我不由天。 也好办,kill -9 ,一行命令解决,也挺省心。 额,还行吧,但是有点儿问题,比如当前服务实例正在处理请求,还没处理完,你咔嚓一下就给它结束了,谁受得了,不要太刺激。 我们把前面的那个 Controller 中的 play方法改一下,加一个延时,等待 6 秒才返回,模拟一个比较慢的请求。 @GetMapping(value = "play") public String play() throws InterruptedException{ Thread.sleep(6000); return "hey, play with me!"; } 效果就是你访问这个地址,然后等了 6 秒之后才显示出 hey, play with me!。 如果在这 6 秒钟之内我杀掉了进程,将会在浏览器中出现下面这个讨厌的界面。 启用优雅关机 只需要在配置文件中增加 server.shutdown的配置,一种是 immediate,也就是立即停止,另一种就是所谓的优雅关机 graceful。 server: port: 8081 shutdown: graceful # 缓冲10s,上面定义的那个方法延时 6秒,所以10秒肯定够了 spring: lifecycle: timeout-per-shutdown-phase: 10s 之后,再启动服务,然后访问这个页面,这个过程中结束进程。然后会看到控制台有输出,提示优雅关机的过程,并提示说会等待活动状态的请求处理完成。 请求也变得正常了。 活动状态检测 之前版本的 spring-boot-starter-actuator就已经有健康状态检测了,不开启活性状态检测,当我们访问 health 的时候,会看到下面的信息,说明服务是可用的。 通过在配置文件中配置如下信息,可开启活动状态检测。 management: health: probes: enabled: true endpoint: health: show-details: always 开启上述配置之后,重启服务,在访问 health 页面,看到的内容如下 除了状态标示外,还多了一个 groups节点。 Liveness:应用程序是否处于可用状态 可通过 /actuator/health/liveness 路径查看 Readiness:应用程序是否准备好接受客户端请求了。 可通过 /actuator/health/readiness路径查看 这个功能其实是针对部署在 Kubernetes 上的服务做的支持。Kubernetes 提供了 LivenessProbe 和 cProbe 两类探针,活动状态检查便是对这两类探针提供无缝支持。 在配置文件中增加配置即可,与 kubernetes 做无缝对接。 spring: main: cloud-platform: kubernetes 那应该怎么用呢 拿 Readiness 来说吧,假设我们要对外宣布次服务暂时不接受请求,那就改变 readiness 的状态,当探针过来的时候发现不接受请求,那就去请求其他实例了。 具体怎么做呢,我在 Controller 中加了两个方法,一个开启接受请求,一个停止接收请求。 @RestController public class PlayController { private final ApplicationEventPublisher publisher; public PlayController(ApplicationEventPublisher publisher) { this.publisher = publisher; } @GetMapping(value = "play") public String play() throws InterruptedException{ Thread.sleep(6000); return "hey, play with me!"; } @GetMapping(value = "up") public String up(){ AvailabilityChangeEvent.publish(publisher,this, ReadinessState.ACCEPTING_TRAFFIC); return "up"; } @GetMapping(value = "down") public String down(){ AvailabilityChangeEvent.publish(publisher,this, ReadinessState.REFUSING_TRAFFIC); return "down"; } } 通过 AvailabilityChangeEvent这个类的 publish 方法,更改自身服务状态。当我们访问 down 接口之后,再次查看 health/readiness的状态情况,会显示如下内容: OUT_OF_SERVICE表示离线,不接受请求。 而当我们请求 up 接口后,服务状态又变成了 up,这也就实现了服务下线和上线的功能。 支持 JDK 14 Spring Boot 2.3 支持 JDK 14了,但跟我有啥关系吗,没有。我依然用我的 Java 8。真香。 Spring Data Neumann Spring Boot 2.3发布了 Spring Data Neumann,其中包含许多主要版本和驱动程序升级。此版本还增加了对 R2DBC(Reactive Relational Database Connectivity) 的稳定版本支持。R2DBC 提供了异步编程方式访问数据库的 API,主要是配合开发异步非阻塞式的应用程序使用的。 总结 从中可以看出很大部分内容都是与 Docker 容器技术有关的,比如分层打镜像包、无缝支持 kubernetes 等,可见 docker 微服务已然成为很多开发者的选择。但是仍然有待改进,比如默认的 docker hub 是 Google Cloud,就不能灵活配置,支持国内的镜像仓库不好吗。 你们用的 Spring Boot 哪个版本,会来尝个鲜儿吗? 参考文档: https://docs.spring.io/spring-boot/docs/2.3.1.RELEASE/maven-plugin/reference/html/index.html#goals https://medium.com/@TimvanBaarsen/whats-new-in-spring-boot-2-3-22d01d036f11 壮士且慢,先给点个赞吧,总是被白嫖,身体吃不消! 我是风筝,公众号「古时的风筝」。一个兼具深度与广度的程序员鼓励师,一个本打算写诗却写起了代码的田园码农!你可选择现在就关注我,或者看看历史文章再关注也不迟。

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册