Kubernetes，当前最热门的系统，很多公司甚至将其列入战略计划，但也有不少人对其三缄其口。 本文仅代表个人简介，如有不同意见，请留言讨论。
前言
名词解答： 1. 银弹: 比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。 2. 智子: 科幻小说《三体》系列中锁死人类科技的人工智能。
毕竟Kubernets在非常底层的位置，用的舒服是得心应手，用的悲剧是鸡飞狗跳。
越来越复杂的Kubernetes
Kubernets越来越像全家桶，除了集群管理外，加入了越来越多的功能。相比之下，Borg只能算是它的一个子集。
全家桶，使用Windows的朋友应该会想起曾经的百度全家桶和360全家桶，反正是要的和不要的都给你装了。
对于部分用户来说可能是好事，但也使得Kubernets越来越复杂。
场景
非常小的规模
本来就只有几个进程的乞丐版服务器，裸奔就行了。
小规模场景
一般公司发展初期，开发力量有限，像什么流量调度，自动化部署之类的。有能用的绝不自己造轮子。
而Kubernetes似乎正好提供所有需要的能力，至于数据库之类的有状态服务，可以直接使用云产品，或者另外部署。
小规模的体量，Kubernetes也不会有太大压力。
大规模场景
有大规模场景的公司，通常都已经成为巨头。这样公司通常有一定的技术积累，更关注性能和稳定性。 对于这样的公司而言，相比收益，使用Kubernetes面临的挑战或许更多。用看上去不是很靠谱的新系统去替换现有的牛逼技术，大概率会鸡飞狗跳。 保不齐是Google为了带歪大公司的智子呢，开个玩笑。
容器管理
Kubernetes显然不是第一个集群管理系统。抛开Borg不说，阿里的T4，百度的Metrix都是不错的集群管理系统。
由于有自身的体量锤炼，稳定性，规模都是开源生态较少关注的。
于是我们发现，Kubernetes能优化到几千的规模，就感觉厉害的不得了，但老系统可能默默无闻的支撑着万级的规模。
标签
在Borg: Kubernetes的前身中，有提到Kubernetes相对于Borg的一个改进，是增加了服务和标签。 显然，这是分布式中间件的地盘，比如阿里系的ConfigServer。我想，在管理功能上应该是强于通用的标签和服务吧。
网络
Kubernetes使用服务抽象支持命名和负载均衡：带名字的服务，会映射到由标签选择器定义的一组动态Pod 集。
Kubernets默认的网络模式是Bridge模式，每个容器会有独立的网络平面，单独的IP。负载均衡则是通过iptables/Proxy实现。
显然，这有两个风险：
1. 大吞吐量下的网络性能堪忧
2. 增加了网络的复杂性，网络问题通常是最难排查的问题。
在大规模的场景下，Host模式直连通常是首选方案。简单而可靠。比如在Borg中，网络就是直连的，由于并没有给每个容器分配IP，所以Borg Name Server解析地址的时候，会返回ip:port，然后直连。阿里也有类似的实现，称之为Vipserver。
除了Host模式直连，硬件虚拟化也是一个办法，比如SR-IOV技术，可以让网卡直接进入Pod。硬件加持下，性能甚至会强于Host模式。
无论哪种方式，都是尽可能简化通信链路。简而言之，大规模场景下，谁都不希望多一次转发。
单元化
如果我们用的是标准的Kubernetes全家桶，那么网络通信其实是封闭在集群内的。Kubernetes做跨城市部署似乎还是有些难度。
这种情况下，就需要一个可以跨Kubernetes的网络平面来实现网络通信。
结论
- 对于规模不是很大的场景，
Kubernetes是个不错的选择。 - 对于超大规模的场景，
Kubernetes的全家桶模式显然力不从心，所以大公司通常会有一些改造，反过来影响Kubernetes的生态。 - 是得心应手还是鸡飞狗跳，能否用好
Kubernetes或许比Kubernetes本身更关键。
