在生产环境使用Kuberntes一年后，我们总结了这些经验和教训_有了kubernetes后,负载均衡是不是可以不要了

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注运维）

正文

2015年初，我们计划为开发团队搭建一套全新的部署平台，在此之前我们使用的是Amazon EC2。尽管AWS-based steup我们一直用得很好，但使用自定义脚本和工具自动化部署的设置，对于运维以外的团队来说不是很友好，特别是一些小团队——没有足够的资源来了解这些脚本和工具的细节。这其中的主要问题在于没有“部署单元（unit-of-deployment）”，该问题直接导致了开发与运维之间工作的断层，而容器化趋势看上去是一个不错的方案。

如果你还没有做好将Docker和Kubernetes落地到生产环境的准备，不妨参考参考我们的经验。我们已经在生产环境使用kubernetes一年多了。

从容器和容器编排工具开始

我们相信容器会是未来最主流的部署格式，这项技术让应用封装变得简单了许多。类似于Docker之类的工具提供了实际的容器，但我们还需要复制、故障排除等工具，以及可实现自动部署到多台机器的API，好让容器技术发挥出最大的作用。

在2015年初，Kubernetes、Docker Swarm等集成工具还不成熟，仅提供alpha版本。不过我们还是决定试一试，并选择了Docker Swarm。

我们用Docker Swarm来处理网络，利用Ambassador模式和一组脚本来实现自动化部署。这种方式难度之大，超乎想象，我们也因此收获了第一个教训：容器集成、网络、部署自动化是非常棘手的问题。

好在我们很快意识到了这一点，并决定将筹码压在Kubernetes身上——一款由Google、Red Hat、Core OS及一些对大规模部署颇有见地的组织提供支持的集成工具。

通过Kubernetes实现负载均衡

使用Kubernetes，需要对pods、services、replication controller等概念了然于心。好消息是，包括Kubernetes官方文档在内，网络上有海量资源，可以帮助你快速上手。

成功建立并运行Kubernetes集群后，即可通过kubectl（Kubernetes CLI）部署应用了。然而当我们想要自动化部署时，却发现光有kubectl是不够的。不过，在此之前我们需要解决另一个问题：如何从Internet访问部署的应用？

部署前的服务有一个IP地址，但这个地址仅在Kubernetes集群中可用。这意味着无法通过网络访问该服务！在Google Cloud Engine上运行时，Kubernetes会自动配置一个负载均衡用以访问应用；如果不在Google Cloud Engine上运行（比如我们），那就需要做一些额外的工作来获得负载均衡了。

直接在主机端口上开放服务是一个可行的解决方案（很多人一开始的确是这么做的），但我们发现，这样的做法等于放弃了Kubernetes所提供的许多好处。如果我们依赖主机上的端口，部署多个应用时会遇到端口冲突。另外这样的做法会加大扩展集群和更换主机的难度。

二级负载均衡器配置

我们发现，解决以上问题的更好办法，是在Kubernetes集群前配置负载均衡器，例如HAProxy或者NGINX。于是我们开始在AWS上的VPN中运行Kubernetes集群，并使用AWS ELB将外部web流量路由到内部HAProxy集群。HAProxy为每个Kubernetes服务配置了“后端”，以便将流量交换到各个pods。

这种“二级负载均衡器配置”主要也是为了适应AWS ELB相当有限的配置选项。其中一个限制是，它不能处理多个vhosts。这也是我们同时使用HAProxy的原因。只使用HAProxy（不用ELB）也能工作，只不过需要你在DNS级别解决动态AWS IP地址问题。

图1:我们的“二级负载均衡器配置流程“

在任何情况下，创建新的Kubernetes服务，我们都需要一种机制动态重新配置负载均衡器（在我们的例子中是HAProxy）。

Kubernetes社区目前正在开发一个名为ingress的功能，用来直接从Kubernetes配置外部负载均衡器。可惜的是，目前开发工作还未完成。过去一年，我们采用的是API配合一个小的开源工具来配置负载均衡。

配置负载均衡

首先，我们需要一个地方存储负载均衡器配置。负载均衡器配置可以存储在任何地方，不过因为我们已经有etcd可用，就把这些配置放在了etcd里。我们使用一个名为“confd”的工具观察etcd中的配置变动，并用模板生成了一个新的HAProxy配置文件。当一个新的服务添加到Kubernetes，我们向etcd中添加一个新的配置，一个新的HAProxy配置文件也就此产生。

不断完善的Kubernetes

Kubernetes中仍然存在众多待解决的问题，很多开发者在社区上、设计文档中讨论解决这些问题的新功能，但开发适用于每一个人的解决方案是需要时间的。不过从长远来看，这也是一件好事，用shortcut的方式设计新功能很多时候会适得其反。

当然，问题的存在并不意味着我们现在所使用的Kubernetes功能有限。配合API，Kubernetes几乎可以完成你想要的一切。等Kubernetes增加新功能后，我们再用标准方案替代自己的解决方案不迟。

话说回来，在我们开发了用于负载均衡的解决方案后，另一项挑战接踵而至：蓝绿部署（Blue-green deployments）。

Kubernetes上的蓝绿部署

蓝绿部署是一种不中断服务的部署。与滚动更新不同，蓝绿部署在旧版本仍然正常工作的情况下，通过启用一个运行着新版本的副本集群来实现更新。当新版本的副本集群完全启动并运行时，负载均衡器配置才会更改并将负载切换到新版本上。这种方式的好处是，永远保持至少一个版本的应用正常运行，减少了处理多个并发版本带来的复杂性。蓝绿部署在副本数量很少时也能很好的工作。

图2:Kubernetes下的蓝绿部署

图2展示了“Deployer“如何编排部署。基于Apache License，并作为Amdatu umbrella project的一部分，我们开源了这个组件的实现，供大家参考使用。另外，这个组件带web UI，可以用来配置部署。

这种机制的一个要点是在重新配置负载均衡器之前，执行在pods上的运行状态检查。我们希望每部署的每一个组件都能提供状态检查。目前的做法通常是为每个组件添加一个通过HTTP访问的状态检查。

实现部署自动化

有了Deployer，我们就可以把部署集成到构建流程中了。我们的构建服务器可以在构建成功之后，将新的镜像推送到registry（如Git Hub），而后构建服务器可以调用新版本应用并自动部署至测试环境中。同一个镜像也可以通过触发生产环境中的Deployer被推送上生产。

图3：容器化自动部署流程

资源限制

使用Kubernetes时，搞清楚资源限制很重要。你可以在每个pod上配置资源请求和CPU／内存限制，也可以控制资源保证和bursting limits。

这些设置对于高效运行多个容器极为重要，防止容器因分配内存不足而意外停止。

建议尽早设置和测试资源限制。没有限制时，看起来运行良好，不代表把重要负载放到容器中不会出现问题。

Kubernetes监控

当我们快要搭建好Kubernetes时，我们意识到监控和日志在这个新的动态环境中非常重要。当我们面对大规模服务和节点时，进入服务器查看日志文件是不现实的，建一个中心化的日志和监控系统需要尽快提上议程。

日志

最后的话

最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！

资料预览

给大家整理的视频资料：

给大家整理的电子书资料：

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
加V获取：vip1024b （备注运维）**
[外链图片转存中…(img-C7nZUt7y-1713231434175)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！