由于开发的平台要进行内部公开测试，我们这周在公司内部私有云搭建了一套平台。涉及到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。 ...
Go语言之父，Google大神Rob Pike代表Go语言的另外两位缔造者Robert Griesemer和Ken Thompson在自己的博客上发表了一篇名为《Go: Ten years and climbing》的文章，用以纪念Go语言从最初的设计idea起到目前的十年发展。笔者读完后，也是深有感触，因此在这里粗略翻译一下全文，希望能有更多的程序员加入到Gopher行列中来。 ...
近期将之前的一个用kube-up.sh安装的Kubernetes 1.3.7的环境更换为最新发布的用kubeadm安装的Kubernetes 1.7.3版本。新版本的安装过程和之前的采用kubeadm安装的k8s 1.5.x、1.6.x版本类似，这里不赘述了。但在安装Dashboard后，发现了一些问题，这里记录一下解决的过程。 一、第一个问题 我们先来做一下回顾。在《解决Kubernetes 1.6.4 Dashboard无法访问的问题》一文中，我们通过把用户admin bind到cluster-admin这个clusterrole角色上使得dashboard得以正常访问。但访问几次后，我发现了一个问题：那就是用safari访问dashboard时，浏览器可以正常弹出鉴权对话框，让我输入用户名和密码；但用chrome访问时，总是无法弹出鉴权对话框，而直接显示如下错误： ...
前一段时间将之前采用kubeadm安装的Kubernetes 1.5.1环境升级到了1.6.4版本，升级过程较为顺利。由于该k8s cluster是一个测试环境，当时并没有过于关注，就忙别的事情了。最近项目组打算在这个环境下做一些事情，而当我们重新“捡起”这个环境时，发现Kubernetes Dashboard无法访问了。 ...
我们有给客户搭建私有容器仓库的需求。开源的私有容器registry可供选择的不多，除了docker官方的distribution之外，比较知名的是VMware China出品的Harbor，我们选择了harbor。 harbor在docker distribution的基础上增加了一些安全、访问控制、管理的功能以满足企业对于镜像仓库的需求。harbor以docker-compose的规范形式组织各个组件，并通过docker-compose工具进行启停。 ...
本文是公司“运营拍档”公众号的专访文稿，这里转载一下^0^。原文链接在这里。 十年生死两茫茫，白天忙，晚上忙，写程序，到天亮。千行代码，Bug何处藏。纵使上线又怎样，朝令改，夕断肠…… ...
续接上文。 五、第三步：启动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 1.3.7集群之外，我这里还有一套1.5.1的Kubernetes测试环境，这个测试环境一来用于验证各种技术方案，二来也是为了跟踪Kubernetes的最新进展。本篇要记录的一个异常就是发生在该测试Kubernetes集群中的。 一、缘起 前两天我在Kubernetes测试环境搭建一套Ceph，为了便于ceph-deploy的安装，我通过hostnamectl命令将阿里云默认提供的复杂又冗长的主机名改为短小且更有意义的主机名： iZ25beglnhtZ -> yypdmaster iz2ze39jeyizepdxhwqci6z -> yypdnode 以yypdmaster为例，修改过程如下： # hostnamectl --static set-hostname yypdmaster # hostnamectl status Static hostname: yypdmaster Transient hostname: iZ25beglnhtZ Icon name: computer-vm Chassis: vm Machine ID: 91aa4b8f2556de49e743dc2f53e8a5c4 Boot ID: 5d0e642ebafa460086388da4177e488e Virtualization: kvm Operating System: Ubuntu 16.04.1 LTS Kernel: Linux 4.4.0-58-generic Architecture: x86-64 # cat /etc/hostname yypdmaster hostnamectl并未修改/etc/hosts，我手动在/etc/hosts中将yypdmaster对应的ip配置上： xx.xx.xx.xx yypdmaster 重新登录后，我们看到主机名状态：Transient hostname不见了，只剩下了静态主机名： ...
在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挂载一次。 ...