别被“僵尸”吃掉大脑！学会用Kubernetes (K8s)思考
全文共1818字，预计学习时长5分钟
来源：Pexels
当我第一次接触kubernetes的时候，它是一个“容器编排平台”，与我的专业并不怎么搭边。kubernetes是一个奇怪的词-它的发音对于讲英语的人来说会有些吃力。
当我参与到这个平台上时，我开始意识到了它的意义。它给平台带来的自动化程度与我之前所见过的都不同。它打开了一扇关不上的门。我不得不开始深入学习它。
然后，我就遇到了一个问题。
当你用传统的方式思考的时候，你就是在对抗Kubernetes
连Kubernetes自己也不承认自己是解决问题的万全之策。然而，许多人还是从这个角度来看待它。Kubernetes不是下一个甲骨文公司，它不会表面上主张“彻底改变你的工作”，而实际上则是要求用户支付费用，Kubernetes扮演的角色其实更为卑微。除非你摆正观念，否则这个角色可能看起来很奇怪。
所以我想我应该在观念转变上多费些笔墨，就像Kubernetes一直鼓励的那样。如果你能在早点转变好观念，那么你在学习和使用Kubernetes中就能一帆风顺了。
控制反转
Kubernetes内置了卓越的自动化功能。自动冗余、高可用性、自我修复、配置管理等等。我曾见过人们在自动化这件事上犯糊涂。
他们已经花了很多年的时间来整合他们自己的自动化系统，而且现在这个系统可以为平台带来更多的收益。当然，他们也会继续保持程序化思维。
要声明，不要限定
幸运的是，接受这种自动化很简单。定义kubernetes资源时，需采用陈述性语句。告诉kubernetes 什么是“好”。其目的是向K8S区域中投入尽可能多的内容。并且在需要的地方自动补充。
让Kubernetes做最擅长的事情，这样可以帮助你填补自己的业务空白。
平台思维
许多kubernetes概念都适合于平台思维。这种思维鼓励建立共享的集中服务，并通过定制解决方案减少项目的浪费和返工。
与平台思维伴随之而来的是风险。如果每个人都依赖同一个共享的监控服务，那么一次中断可能就会造成大范围的爆炸式影响。您可以通过分离监视服务器限制其影响，但最终，您单个服务的责任也会随之增加。
Kubernetes乐于支持其中任意一者，但是当你们都生活在同一个集群中时，相较于silo中特定产品的服务，集中化的战略服务的构建会更自然。它们的好处也显而易见：
- 通过获得生产级服务进行实验
- 构建新事物的成本降低，可尝试的新事物也会增多。实验得越多，学得越多。
把“产品”从“生产”中拿出来
除非产品非常大，否则该产品很可能会被部署到现有的生产集群中。将生产环境与应用程序分离从一开始就是很奇怪的。
通过使用不同的技术，你只需在产品准备好交付时再构建你的环境。整个环境都属于你。
但现在呢？你处于一个共享的生活空间-与租户和客人同住一个屋檐下。这让人很不舒服，感觉自主性受到了限制。以前，你可以在你的环境里随心所欲。现在？所有的东西上面都有别人的名字，你必须小心了。那怎么摆脱这种现象呢？
合作
这可能会让人不安。你不认识其他人。如果他们都不通情理呢？好吧，信任的建立最初都是这样的。你已经认识到你需要依赖另一个伙伴。与你共同承担责任。处理这件事的最好方法是什么呢？见面，解释你的焦虑，建立一些宽松的工作机制，并定期改进。
你共享的kubernetes集群将迫使你说话。如果不说话，你也不会好过。你会为更积极、更紧密的合作做好准备。这需要慢慢适应，对于团队所占领的神圣空间来说，这感觉像是一种入侵，但只要稍加练习，这种合作会变得自然而然，而且益处多多。
大量的自动化
kubernetes鼓励声明式配置，而不是通过一系列严格的程序指令告诉k8s该做什么。这是它的一大优势，它提高了应用程序的自动化程度。你会欣然发现只需简单地编写一下YAML格式，就可以把剩下的全都交给kubernetes，因为API服务器可以提供帮助。
然后您将查看集群中的其他所有信息……
你会看到那些手工创建的数据库、手工创建的安全组、分散的ec2实例。你会渴望集群自动化所带来的便利。你已经走出了柏拉图的洞穴，尽管已尽全力，你也不能回到过去了。是时候准备撸起袖子大干一场了。
That skull represents the dodgy scripts on your DBAs laptop
骷髅代表了你DBAs笔记本电脑上的那些狡猾的脚本。
kubernetes设置了一个标准，它很容易将你任务中的其他部分都提升到这一标准上来。
我唯一的建议是：谨慎。
自动化很好，但自动化程度越高，就越需要管理。通常，面临的更难的问题是：一旦构建了所有自动化工具，您将如何在操作上维护它们呢？
推荐阅读专题
留言 点赞 关注
我们一起分享AI学习与发展的干货
如需转载，请后台留言，遵守转载规范