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
本身更关键。
暂无评论内容