近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源工具拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄，服务治理难搞！ 一、微服务的“痛点” 微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、apache thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。 ...
关于基于Harbor的高可用私有镜像仓库，在我的博客里曾不止一次提到，在源创会2017沈阳站上，我还专门以此题目和大家做了分享。事后，很多人通过微博私信、个人公众号或博客评论问我是否可以在Kubernetes集群上安装高可用的Harbor仓库，今天我就用这篇文章来回答大家这个问题。 一、Kubernetes上的高可用Harbor方案 首先，我可以肯定给出一个回答：Harbor支持在Kubernetes部署。只不过Harbor官方的默认安装并非是高可用的，而是“单点式”的。在《基于Harbor的高可用企业级私有容器镜像仓库部署实践》一文中，我曾谈到了一种在裸机或VM上的、基于Cephfs共享存储的高可用Harbor方案。在Kubernetes上部署，其高可用的思路也是类似的，可见下面这幅示意图： ...
今天上午一到工位，就收到来自同事的“投诉”：私有云上的Kubernetes cluster中的一个node似乎不工作了，因为专门部署于那个节点上的应用挂掉了，并且长时间没有恢复。这个公司私有云上Kubernetes集群是v1.7.5版本，部署于双节假期之前。最近感觉K8s开发明显提速，连续发布版本，截至发稿时，最新发布的版本为v1.8.1了。这个集群一直运行相对稳定，今天这个异常到底是怎么一回事呢？于是打开terminal，开始了问题的调查。 ...
由于开发的平台要进行内部公开测试，我们这周在公司内部私有云搭建了一套平台。涉及到Kubernetes相关的基础软件，由我来部署。Kubernetes以及其相关组件都在积极的开发中，版本更新也很快。截至本文撰写时，K8s发布最新稳定版是v1.7.6，而与之配套的Dashboard则是v1.7.0。 最初在部署规划时，我选择了Kubernetes v1.7.6+ dashboard v1.6.3的组合。之前K8s v1.7.3的稳定让我对使用最新Release版有一些信心，但dashboard v1.7.0则是三天前刚发布的，看dashboard的commit log，之前还大规模revert了一次。因此，我保守的选择了v1.6.3。 ...
续接上文。 五、第三步：启动emei、wudang上的apiserver 跨三个node的etcd cluster已经建成并完成了数据同步，下面进行ha cluster改造的重要一步：启动wudang、emei上的apiserver ...
Kubernetes集群的核心是其master node，但目前默认情况下master node只有一个，一旦master node出现问题，Kubernetes集群将陷入“瘫痪”，对集群的管理、Pod的调度等均将无法实施，即便此时某些用户的Pod依旧可以正常运行。这显然不能符合我们对于运行于生产环境下的Kubernetes集群的要求，我们需要一个高可用的Kubernetes集群。 不过，目前Kubernetes官方针对构建高可用(high-availability)的集群的支持还是非常有限的，只是针对少数cloud-provider提供了粗糙的部署方法，比如：使用kube-up.sh脚本在GCE上、使用kops在AWS上等等。 高可用Kubernetes集群是Kubernetes演进的必然方向，官方在“Building High-Availability Clusters”一文中给出了当前搭建HA cluster的粗略思路。Kubeadm也将HA列入了后续版本的里程碑计划，并且已经出了一版使用kubeadm部署高可用cluster的方法提议草案。 ...
在Kubernetes集群中运行有状态服务或应用总是不那么容易的。比如，之前我在项目中使用了CephRBD，虽然遇到过几次问题，但总体算是运行良好。但最近发现CephRBD无法满足跨节点挂载的需求，我只好另辟蹊径。由于CephFS和CephRBD师出同门，它自然成为了这次我首要考察的目标。这里将跨节点挂载CephFS的考察过程记录一下，一是备忘，二则也可以为其他有相似需求的朋友提供些资料。 一、CephRBD的问题 这里先提一嘴CephRBD的问题。最近项目中有这样的需求：让集群中的Pod共享外部分布式存储，即多个Pod共同挂载一份存储，实现存储共享，这样可大大简化系统设计和复杂性。之前CephRBD都是挂载到一个Pod中运行的，CephRBD是否支持多Pod同时挂载呢？官方文档中给出了否定的答案: 基于CephRBD的Persistent Volume仅支持两种accessmode： ReadWriteOnce和ReadOnlyMany，不支持ReadWriteMany。这样对于有读写需求的Pod来说，一个CephRBD pv仅能被一个node挂载一次。 ...
Kubernetes API Server是整个Kubernetes集群的核心，我们不仅有从集群外部访问API Server的需求，有时，我们还需要从Pod的内部访问API Server。 然而，在生产环境中，Kubernetes API Server都是“设防”的。在《Kubernetes集群的安全配置》一文中，我提到过：Kubernetes通过client cert、static token、basic auth等方法对客户端请求进行身份验证。对于运行于Pod中的Process而言，有些时候这些方法是适合的，但有些时候，像client cert、static token或basic auth这些信息是不便于暴露给Pod中的Process的。并且通过这些方法通过API Server验证后的请求是具有全部授权的，可以任意操作Kubernetes cluster，这显然是不能满足安全要求的。为此，Kubernetes更推荐大家使用service account这种方案的。本文就带大家详细说说如何通过service account从一个Pod中访问API Server的。 ...
Kubernetes集群搭建起来后，一直跑得很稳定。之前的关注点更多集中在安装、配置、组件调试方面，一些细枝末节被忽略了。Pod中时区的设置就是其中之一。今天腾出功夫打算解决一下这个问题。 一、问题现象 在我的Kubernetes 1.3.7集群的Master Node上，我们执行： # date Mon Feb 20 11:49:20 CST 2017 之后，在该Node上随意找到一个Pod中的Container，通过docker exec切入到容器内执行： ...
所有涉及到存储的地方都是极易出现“坑”的地方，Kubernetes也不例外。 一、问题起因 问题始于昨天升级一个stateful service的操作。该service下的Pod挂载了使用ceph RBD提供的一个Persistent Volume。该Pod是用普通deployment部署的，并没有使用处于alpha状态的PetSet。改动仅仅是image的版本发生了变化。我执行的操作如下： ...