http://xiaorui.cc/archives/6051

 

kubernetes是否靠谱? 中小团队,尤其是小团队是否可以hold的住?

个人认为kubernetes在实践中最难的是网络和存储。网络cni推荐大家使用calico,因为calico对比flannel有更好的想能,另外也完美支持bgp路由协议。如果想更加的易用,可以选择基于overlay的flannel插件。至于存储? 不推荐… 意思是说,推荐大家把一些有状态的服务,比如postgres、mysql、elasticsearch,放在k8s的pod之外。为啥? 我问了一圈在各公司搞云平台开发的,他们k8s每次出问题,大概率都是因为存储。 😅 这个很考验基础架构团队的能力。

Istio是否靠谱?

当然,没问题了。不少国外,国内也有不少公司在用了。istio是基于k8s平台做的一层mesh的封装,就算出现了不可控和未知的问题,我们可以把istio的策略都删掉,让pod走原始的k8s service的逻辑。

如何更好的上手kubernetes、istio ?

首先是把官方的文档简略的看一遍,再把组件的原理看一遍。这个实现原理是不能忽视的,不然在实践k8s/istio遇到问题就抓瞎。在了解原理的基础上,可以适当的看他的关键代码实现,像istio的源码还是相对好理解的。

如何减少业务代码嫁接微服务架构的成本?

像我们先前的架构比较复杂,大部分是通过grpc balancer来直接连接的,但还是有部分系统是基于golang nats mq消息总线,主要是使用nats的request/reply的同步语义来实现异步的发布订阅。如果直接把总线改成grpc的方式,代码量其实不小。没有采用grpc直连而总线模式的服务有20来个,怎么用最小的代码来实现?

利用grpc的各种特性来实现的完美兼容,关键词是 grpc.unknownHandler, grpc reflection,静态protobuf描述符。

 

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐