第一次采用kube-up.sh脚本方式安装的Kubernetes cluster目前运行良好，master node上的组件状态也始终是“没毛病”： # kubectl get cs NAME STATUS MESSAGE ERROR controller-manager Healthy ok scheduler Healthy ok etcd-0 Healthy {"health": "true"} 不过在第二次尝试用kubeadm安装和初始化Kubernetes cluster时遇到的各种网络问题还是让我“心有余悸”。于是趁上个周末，对Kubernetes的网络原理进行了一些针对性的学习。这里把对Kubernetes网络的理解记录一下和大家一起分享。 ...
由于2016年年中调换工作的原因，对容器网络的研究中断过一段时间。随着当前项目对Kubernetes应用的深入，我感觉之前对于容器网络的粗浅理解已经不够了，容器网络成了摆在前面的“一道坎”。继续深入理解K8s网络、容器网络已经势在必行。而这篇文章就算是一个重新开始，也是对之前浅表理解的一个补充。 我还是先从Docker容器网络入手，虽然Docker与Kubernetes采用了不同的网络模型：K8s是Container Network Interface, CNI模型，而Docker则采用的是Container Network Model, CNM模型。而要了解Docker容器网络，理解Linux Network Namespace是不可或缺的。在本文中我们将尝试理解Linux Network Namespace及相关Linux内核网络设备的概念，并手工模拟Docker容器网络模型的部分实现，包括单机容器网络中的容器与主机连通、容器间连通以及端口映射等。 ...
在《当Docker遇到systemd》一文中，我提到过这两天儿一直在做的一个task：使用kubeadm在Ubuntu 16.04上安装部署Kubernetes的最新发布版本-k8s 1.5.1。 年中，Docker宣布在Docker engine中集成swarmkit工具包，这一announcement在轻量级容器界引发轩然大波。毕竟开发者是懒惰的^0^，有了docker swarmkit，驱动developer去安装其他容器编排工具的动力在哪里呢？即便docker engine还不是当年那个被人们高频使用的IE浏览器。作为针对Docker公司这一市场行为的回应，容器集群管理和服务编排领先者Kubernetes在三个月后发布了Kubernetes1.4.0版本。在这个版本中K8s新增了kubeadm工具。kubeadm的使用方式有点像集成在docker engine中的swarm kit工具，旨在改善开发者在安装、调试和使用k8s时的体验，降低安装和使用门槛。理论上通过两个命令：init和join即可搭建出一套完整的Kubernetes cluster。 ...
此文为《使用Kubeadm安装Kubernetes》的第二部分。文章第一部分在这里可以看到。 五、weave network for pod 经过上面那么多次尝试，结果是令人扫兴的。Weave network似乎是最后一颗救命稻草了。有了前面的铺垫，这里就不详细列出各种命令的输出细节了。Weave network也有专门的官方文档用于指导如何与kubernetes集群集成，我们主要也是参考它。 ...
近期在做Kubernetes集群的升级的相关试验，即从原先的K8s 1.3.7版本升级到最新的K8s 1.5.1版本。k8s自1.4版本开始引入kubeadm，试图简化K8s的安装和使用门槛，提升开发者体验。但kubeadm仅支持16.04及以上的Ubuntu版本，于是我们在升级K8s集群前会遇到另外一个问题：Ubuntu 16.04已经由Upstart初始化系统换成了systemd初始化系统，Ubuntu 16.04上的Docker engine的使用和配置方法与以前在Ubuntu 14.04上将有所不同。Docker是K8s支持的容器引擎之一，也是目前最主流的容器引擎，弄清楚Docker的配置和使用也是后续用好K8s的前提之一。于是这里打算记录一下Docker与Systemd是如何相生共存的^0^。 ...
作为VIMer，日常编码中，Vim编辑器依然是我的首选。以前以C语言为主要语言的时候是这样，现在以Go为主要语言时亦是这样。不过近期发现Mac上使用Vim在编写Go代码时，Vim时不时的“抽风”：出现一些“屏幕字符被篡改”的问题，比如下面这幅图中”func”变成了”fknc”: 虽然一段时间后，显示会自动更正过来，但这种“篡改”是会让你产生“幻觉”的。你会想：是不是我真的将”func”写成”fknc”了呢？久而久之，这个瑕疵将会影响你的编码效率。至于为何会出现这个问题，初步怀疑可能是因为vim加载较多插件导致的一些性能问题，我在安装了Ubuntu 16.04的台式机上至今还没发现这个问题（相同的.vimrc配置）。 ...
使用kubernetes/cluster/kube-up.sh脚本在装有Ubuntu操作系统的bare metal上搭建的Kubernetes集群并不安全，甚至可以说是“完全不设防的”，这是因为Kubernetes集群的核心组件：kube-apiserver启用了insecure-port。insecure-port背后的api server默认完全信任访问该端口的流量，内部无任何安全机制。并且监听insecure-port的api server bind的insecure-address为0.0.0.0。也就是说任何内外部请求，都可以通过insecure-port端口任意操作Kubernetes集群。我们的平台虽小，但“裸奔”的k8s集群也并不是我们想看到的，适当的安全配置是需要的。 ...
这段日子，一直在搞与Kubernetes有关的东东：像什么Kubernetes集群搭建、DNS插件安装和配置、集成Ceph RBD持久卷、Private Registry镜像库访问等，这些都缘于正在开发的一个类PaaS小平台的需要：“平台虽小，五脏俱全”。整个平台由Kubernetes集群承载，对于K8s集群内部的Service来说，目前还欠缺一个服务入口。之前的《Kubernetes集群中的Nginx配置热更新方案》一文实际上就是入口方案设计的一个前奏，而本文则是说明一下Nginx入口服务部署设计和实施过程中遇到的一些坑。 一、Nginx入口方案简述 Nginx作为集群入口服务，从功能上说，一般都是充当反向代理和负载均衡的角色。在我们这里它更多是用于反向代理，因为负载均衡的事情“移交”给了K8s去实现了。k8s通过ClusterIP- 一种VIP机制，默认基于iptables的负载分担实现服务请求的负载均衡（如iptable nat table的规则：-m statistic –mode random –probability 0.33332999982），查看iptables nat链的rules，可以看到如下样例： ...
在《使用Ceph RBD为Kubernetes集群提供存储卷》一文中，我们提到：借助Kubernetes和Ceph的集成，Kubernetes可以使用Ceph RBD为集群内的Pod提供Persistent Volume。但这一过程中，RBD所使用的image的创建、删除还需要手动管理，于是我们又基于go-ceph实现了对RBD image的程序化管理，我们的最终目标是要这种对RBD image的管理服务以一个K8s service的形式发布到Kubernetes集群中去，这就是本文标题中描述的那样：Kuberize Ceph RBD API服务。 ...
Nginx已经是互联网IT业界一个无敌的存在，作为反向代理、负载均衡、Web服务器等多种角色的扮演者，Nginx在全球各个互联网公司落地、开花和结果，Ngnix已经成为了支撑全球互联网应用的一个不可获取的组成部分。 在我们的平台中，Nginx同样被拿来作为服务接入的最前端的反向代理，并且我们的Nginx也是作为一个Service跑在我们的Kubernetes集群中的。Ngnix背后的服务众多，服务的生生死死都要在Nginx上这些服务路由的配置中有所体现，这就要求部署在Kubernetes集群中的Nginx需要有一个合理的配置热更新方案。 Nginx自身是支持配置热更新的，通过nginx -s reload命令可以实现这一点： ...