大家好,我是来自 GPB&W 的 Song
Yu,很高兴参加本次云主题分享会。
我在去年通过了 Docker 和 Kubernetes 相关的认证,包括有 DCA、CKAD、CKA
和
CKS。准备这些考试的动机,是因为我在工作中有接触到,并且想更进一步了解和掌握它们。
如今呢,我们已经习惯了通过云为客户提供服务,但在具体地说到云之前,请大家稍微等等,我来给大家讲述一段经历。
让时间来到 5 年前的一个夜晚,大约 23 点 40
分,同事们陆续来到办公室,一边做部署前的准备工作,一边开玩笑道:“希望今晚一切顺利"。
零点,发布准时开始。但是不太走运,仅过了 10
分钟就遇到了错误,重试也无法解决。于是,你在提交了一个 ticket
后便开始等待。
这个 ticket 辗转了 2
个团队,问题终于得到解决。当你完成了发布计划时,时间已经来到了凌晨 2
点至 3 点。这段经历对于开发同事来说并不陌生。
好了,把时间拉回到现在,拥有 Mode2 牌照的团队,不仅不再受 maintence
window 的限制,而且可以把当天的改动即时发布到生产环境中去。
促成如此显著进步的因素有很多,云发挥了重要作用。
(下一页)
云版图非常庞大,屏幕上只显示了几块拼图。这些拼图解决了什么问题,来帮助我们取得显著进步呢?
(下一页)
第一,云计算
云计算平台提供了物理硬件资源,这些组织承诺其基础设施具有高可用性和可靠性。
第二,微服务
云计算解决了物理硬件问题,但开发和部署中的问题仍未解决。这包括有:
1、构建时间长。只是修改了一行代码,就需要部署整个应用。同时,部署整个应用所消耗的时间非常多。
2、开发速度慢。使用一个庞大的代码库,会导致某个开发人员在提交了编译失败的代码后,阻止其他开发人员的构建和部署。
3、抵御失败的能力差。某个业务模块的致命错误可能导致整个应用的崩溃。
4、资源利用率低。当某个业务模块的负载增加时,必须水平扩展整个应用,来将负载进行均衡,但这也导致了系统资源的浪费。
不知道大家是不是也曾经为这些问题而烦恼和痛苦。
微服务架构通过满足以下要求,解决了上面提到的问题,可谓是对症下药:1、根据业务模块划分服务种类;2、每个服务可独立部署且相互隔离;3、通过轻量级
API 调用服务;4、服务需保证良好的高可用性。
第三,容器化
微服务架构帮助开发团队快速构建和部署服务,各项服务在工作(和出现故障)时不会相互影响,并让持续集成和持续交付(CI/CD)更加顺畅。但是,一个经典的错误场景仍然存在:程序在我这跑得好好的,在你那怎么就不行呢?
Docker
镜像解决了微服务的运行环境难以在本地环境、测试环境以及生产环境保持一致的难题。如此一来,开发人员就可以把在本地环境中测试通过的代码,以及所有的依赖打包成一个镜像,然后自动部署在测试环境中进行测试,测试通过后再发布到生产环境中去,这很厉害,打通了整个开发、测试和发布流程。
第四,容器编排
Docker
解决了微服务运行环境的一致性问题,但它无法根据需求自动扩展容器(可扩展性),并且无法自动跨多个节点分发容器(高可用性)。因此,容器编排系统的需求就诞生了。
Kubernetes 帮助我们:
1、运行任何规模的容器化应用,且无需任何停机。
2、自动修复容器化应用,使其能够应对意外故障。
3、根据工作负载自动扩展容器化应用,并确保云资源的最佳利用。
4、极大地简化了部署操作过程。无论操作多么复杂,最多只需执行几条命令就可以可靠地执行。
(下一页)
好了,在粗略地浏览完如何从这些拼图中受益,并帮助我们取得显著进步后,我想大家会更愿意了解和学习它们了。那我们该如何开始呢?以考促学可能是一个不错的选项。这里要做一个巨大的宣传,时刻关注
TA 发出的邮件,全是你想要的干货。
CKAD 和 CKA 是和 Kubernetes 相关的两个认证,通过参加 TA
提供的技术培训课程,可以帮助我们快速入门
Kubernetes,并顺利通过考试。
这里拿出两道试题,来看看考试难度,同时,这两道题也和我们的工作息息相关。一个小提示,在考试中可以查看官方文档。
(自主发挥)
最后,谢谢大家的宝贵时间,我的分享到此结束。