在任何情况下，创建新的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时，我们意识到监控和日志在这个新的动态环境中非常重要。当我们面对大规模服务和节点时，进入服务器查看日志文件是不现实的，建一个中心化的日志和监控系统需要尽快提上议程。
日志
有很多用于日志记录的开源工具，我们使用的是Graylog和Apache Kafka（从容器收集摘录日志的消息传递系统）。容器将日志发送给Kafka，Kafka交给Graylog进行索引。我们让应用组件将日志打给Kafka，方便将日志流式化，成为易于索引的格式。也有一些工具可以从容器外收集日志，然后发送给日志系统。
监控
Kubernetes具备超强的故障恢复机制，Kubernetes会重启意外停止的pod。我们曾遇到过因内存泄露，导致容器在一天内宕机多次的情况，然而令人惊讶的是，甚至我们自己都没有察觉到。
Kubernetes在这一点上做得非常好，不过一旦问题出现，即使被及时处理了，我们还是想要知道。因此我们使用了一个自定义的运行状况检查仪表盘来监控Kubernetes节点和pod，以及包括数据存储在内的一些服务。可以说在监控方面，Kubernetes API再次证明了其价值所在。
检测负载、吞吐量、应用错误等状态也是同样重要的，有很多开源软件可以满足这一需求。我们的应用组件将指标发布到InfluxDB，并用Heapster去收集Kubernetes的指标。我们还通过Grafana（一款开源仪表盘工具）使存储在InfluxDB中的指标可视化。有很多InfluxDB／Grafana堆栈的替代方案，无论你才用哪一种，对于运行情况的跟踪和监控都是非常有价值的。
数据存储和Kubernetes
很多Kubernetes新用户都有一个问题：我该如何使用Kubernetes处理数据？
运行数据存储时（如MangoDB或MySQL），我们很可能会有持久化数据储存的需求。不过容器一但重启，所有数据都会丢失，这对于无状态组件没什么影响，但对持久化数据储存显然行不通。好在，Kubernetes具有Volume机制。
Volume可以通过多种方式备份，包括主机文件系统、EBS（AWS的Elastic Block Store）和nfs等。当我们研究持久数据问题是，这是一个很好的方案，但不是我们运行数据存储的答案。
副本问题
在大多数部署中，数据存储也是有副本的。Mongo通常在副本集中运行，而MySQL可以在主／副模式下运行。我们都知道数据储存集群中的每个节点应该备份在不同的volume中，写入相同volume会导致数据损坏。另外，大多数数据存储需要明确配置才能使集群启动并运行，自动发现和配置节点并不常见。
同时，运行着数据存储的机器通常会针对某项工作负载进行调整，例如更高的IOPS。扩展（添加/删除节点）对于数据存储来说，也是一个昂贵的操作，这些都和Kubernetes部署的动态本质不相符。
决定不在生产环境数据存储上使用Kubernetes
以我们的情况，在Kubernetes内运行数据存储没有想象中那么完美，设置起来也比其他Kubernetes部署复杂得多。
于是我们决定不在生产环境数据存储上使用Kubernetes，而是选择在不同的机器上手动启动这些集群，我们在Kubernetes内部运行的应用正常连接到数据存储集群。
所以说，没必要运行Kubernetes的一切，按自身情况与其他工具配合使用，会有意想不到的效果，比如我们的数据存储和HAProxy服务器。
为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！
这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。
本份面试集锦涵盖了
- 174 道运维工程师面试题
- 128道k8s面试题
- 108道shell脚本面试题
- 200道Linux面试题
- 51道docker面试题
- 35道Jenkis面试题
- 78道MongoDB面试题
- 17道ansible面试题
- 60道dubbo面试题
- 53道kafka面试
- 18道mysql面试题
- 40道nginx面试题
- 77道redis面试题
- 28道zookeeper
总计 1000+ 道面试题， 内容 又全含金量又高
- 174道运维工程师面试题
1、什么是运维?
2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?
3、现在给你三百台服务器，你怎么对他们进行管理?
4、简述raid0 raid1raid5二种工作模式的工作原理及特点
5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?
6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?
7、Tomcat和Resin有什么区别，工作中你怎么选择?
8、什么是中间件?什么是jdk?
9、讲述一下Tomcat8005、8009、8080三个端口的含义？
10、什么叫CDN?
11、什么叫网站灰度发布?
12、简述DNS进行域名解析的过程?
13、RabbitMQ是什么东西?
14、讲一下Keepalived的工作原理?
15、讲述一下LVS三种模式的工作过程?
16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?
17、如何重置mysql root密码?
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
到真正的技术提升。**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
538
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
