注意：该测试是在我自己本地搭建的kubernetes集群上测试的，不需要使用Google Cloud Platform。
不需要GCE及其他组件，你只需要有一个kubernetes集群即可。
如果你还没有kubernetes集群，可以参考kubernetes-handbook部署一个。
sample-webapp 目录下包含一个简单的web测试应用。我们将其构建为docker镜像，在kubernetes中运行。你可以自己构建，也可以直接用这个我构建好的镜像index.tenxcloud.com/jimmy/k8s-sample-webapp:latest。
在kubernetes上部署sample-webapp。
$ cd kubernetes-config
$ kubectl create -f sample-webapp-controller.yaml
$ kubectl create 阿里云是国内非常受欢迎的基础云平台，随着Kubernetes的普及，越来越多的企业开始筹划在阿里云上部署自己的Kubernetes集群。 本文将结合实战中总结的经验，分析和归纳一套在阿里云上部署生产级别Kubernetes集群的方法。 文中所采取的技术方案具有一定的主观性，供各位读者参考。在实践中可以根据具体使用场景进行优化。
当我们刚接触Kubernetes进行测试集群的搭建时，往往会选择一篇已有的教程，照着教程完成集群搭建。我们很少去质疑教程作者每一步操作的合理性， 只想快点把集群搭建起来，早点开始实际的上手体验。
与测试集群不同，对于生产级别的部署，我们会有更加严格的要求，更加强调合理的规划以及每个步骤的合理性以及可管理性。以下是我们设定的目标：
因为篇幅的原因，以下内容将不作为本文的目标，留待日后再做分享：
目前Kubernetes主要支持的云平台还是海外的几大主流平台，但是对比阿里云提供的基础设施，我们已经具有了基本相同的底层环境。 阿里云提供的VPC，云盘，SLB，NAS等组件，都为搭建生成级别Kubernetes集群提供了很好的支持。充分利用这些组件， 我们应该可以搭建出完整可用的Kubernetes集群。但是仔细研究Kubernetes的代码我们会发现，阿里云的CloudProvider暂时没有被合并到上游当中， 所以我们需要设计方案来解决Kubernetes暂时还没有原生阿里云支持的问题。
Kubernetes生态圈发展迅速，目前已经有了像kops这种集群自动创建工具帮助运维工程师创建集群。但是目前已有的集群创建工具均只支持国外的云平台， 使得国内云平台的用户只能采取手动搭建的办法。像kubeadm这种半自动工具还可以使用，也算是减轻了不少负担。从目前状况来看， 运维的负担依然很严重，为我们实现生产级别部署所追求的自动化、规模化的目标带来了不小的障碍。
由于网络原因造成的镜像拉取困难也给我们创建Kubernetes集群制造了不小的麻烦，好在阿里云一直在致力于解决这个问题，为用户提供了镜像拉取加速服务以及重要镜像的Mirror。
另一个问题是操作系统镜像的问题，在后面分析操作系统的时候再详细展开。
基于消除单点故障以及降低复杂度的考虑，我们设计了由5台服务器，分两个服务器组构成的Kubernetes集群的控制节点，并视业务需求情况由N台服务器， 分多个服务器组，构成集群的运行节点。如下图所示：
在设计这一架构时，我们考虑了以下几点：
在有了架构蓝图后，接下来让我们来实际搭建这个集群。
搭建集群首先会面临的问题是，选什么配置的服务器，用什么操作系统。服务器硬件配置相对好解决，控制节点在业务量不大的时候选择入门级别的配置再随着业务增长不断提升即可， 运行节点应当根据业务需要来选择，可能要做一些尝试才能定下来最适合的硬件配置。比较困难的选择是操作系统的选型。
只要是使用较新的Kernel的Linux主机，均可以用来运行Kubernetes集群，但是发行版的选择却需要从多个方面来考虑。在这里我们选择了CoreOS作为最基础的操作系统。
… 阅读全文大家好，说到容器、Docker，大家一定会想到Kubernetes，确实如此，在2016年ClusterHQ容器技术应用调查报告显示，Kubernetes的使用率已经达到了40%，成为最受欢迎的容器编排工具；那么Kubernetes到底是什么呢？它是一个用于容器集群的自动化部署、扩容以及运维的开源平台；那么通过Kubernetes能干什么呢？它能快速而有预期地部署你的应用，极速地扩展你的应用，无缝对接新的应用功能，节省资源，优化硬件资源的使用。
随着Kubernetes王者时代的到来，计算、网络、存储、安全是Kubernetes绕不开的话题，本次主要分享Kubernetes网络原理及方案，后续还会有Kubernetes其它方面的分享，另外有容云5.22发布了基于Kubernetes的容器云平台产品UFleet，想要获取新品试用，欢迎联系有容云。
在Kubernetes网络中存在两种IP（Pod IP和Service Cluster IP），Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的，Service Cluster IP它是一个虚拟IP，是由kube-proxy使用Iptables规则重新定向到其本地端口，再均衡到后端Pod的。下面讲讲Kubernetes Pod网络设计模型：
1、基本原则：
每个Pod都拥有一个独立的IP地址（IPper Pod），而且假定所有的pod都在一个可以直接连通的、扁平的网络空间中。
2、设计原因：
用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑将容器端口映射到主机端口等问题。
3、网络要求：
所有的容器都可以在不用NAT的方式下同别的容器通讯；所有节点都可在不用NAT的方式下同所有容器通讯；容器的地址和别人看到的地址是同一个地址。
1、网络的命名空间：Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信；docker利用这一特性，实现不容器间的网络隔离。
2、Veth设备对：Veth设备对的引入是为了实现在不同网络命名空间的通信。
3、Iptables/Netfilter：Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核 模式中；Iptables模式是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表；通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。
4、网桥：网桥是一个二层网络设备,通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。
5、路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里。
下图展示了Docker网络在整个Docker生态技术栈中的位置：
1、单机网络模式：Bridge 、Host、Container、None，这里具体就不赘述了。
2、多机网络模… 阅读全文
Flannel概述
值得探讨的是，flannel的这个overlay网络支持多种后端实现，除上图中的UDP，还有VXLAN和host-gw等。此外，flannel支持通过两种模式来维护隧道端点上FDB的信息，其中一种是通过连接Etcd来实现，另外一种是直接对接K8S，通过K8S添加删除Node来触发更新。
我的K8S环境使用kubeadm来容器化运行K8S的各个组件（除kubelet直接运行在裸机上外），当我使用kubeadm join命令加入新的Minion Node到K8S集群中后，通过kubectl get node会发现所有的node都还是not ready状态，这是因为还没有配置好flannel网络。
我使用的是K8S的1.6.4的版本，然后按照官方的说明，使用kube-flannel.yml来创建flannel deamon set，结果始终报错。正确的姿势是先使用kube-flannel-rbac.yml来创建flannel的ClusterRole并授权。该yml的主要作用是创建名叫flannel的ClusterRole，然后将该ClusterRole与ServiceAccount(flannel)绑定。接下来，当我们使用kube-flannel.yml来创建flannel daemon set的时候，该daemon set明确指定其Pod的ServiceAccount为flannel，于是通过它启动起来的Pod就具有了flannel ClusterRole中指定的权限。
我之前在我的Mac Pro上跑了三个VM，为了能够访问公网拉取镜像，我为每个VM分配了一张网卡使用NAT模式，其分配到的IP地址可能重启后发生变化。另外，为了我本机方便管理，我为每台VM又分配了一张网卡使用Host-Only网络模式，每个网卡都有一个固定的IP地址方便SSH。然后，奇怪的事情就这样发生了….
原因在与在kube-flannel.yml中，kube-flannel容器的command被指定为：
command: [ "/opt/bin/flanneld", "--ip-masq", "--kube-subnet-mgr"]
可见，其并没有指定使用哪一张网卡作为flanneld对外通信的物理网卡，于是，可能由于机器上面路由配置的差异，导致三台机器并没有一致通过Host-Only网络模式的网卡来打通Overlay网络。遇到这种情况，如果几台机器的配置一致，可以手动修改kube-flannel.yml文件中kube-flannel的command的值，添加参数–iface=ethX,这里的ethX就为我们希望flanneld通信使用的网卡名称。
这个现象比较坑，遇到这种情况的第一反应就是去查看install-cni容器到底做了什么。我们打开kube-flannel.yml可以看到，该容器的command字段只有简单的一行Shell：
command:… 阅读全文
MySQL 是一个开源的关系型数据库管理系统，使用标准的sql语言，由瑞典 MySQL AB 公司开发，当前属于 Oracle 公司。能够 支持大型的数据库，可以处理上千万条的数据记录。可以运行于在Windows、Linux等多种系统上；支持C、C++、Python、Java、Perl、PHP、Eiffel、Ruby和Tcl等编程语言。对于32位系统，MySQL的表文件最大可支持4GB，对于64位系统，MySQL支持最大的表文件为8TB。
本文的MySQL高可用方案为主从复制+读写分离，即由单一的master和多个slave所构成。其中，客户端通过master对数据库进行写操作，通过slave端进行读操作。master出现问题后，可以将应用切换到slave端。 此方案是MySQL官方提供的一种高可用解决方案，节点间的数据同步采用MySQL Replication技术。
MySQL Replication从一个MySQL数据库服务器（master）的数据复制到一个或多个MySQL数据库服务器（slave）。在默认情况下，复制是异步的；slave不需要一直接收来自主机的更新。根据配置，可以复制数据库中的所有数据库、选定的数据库，或者特定的表。
MySQL中复制的优点包括：
此高可用的解决方案适用于对数据实时性要求不是特别严格的场景，在使用时可以通过廉价的硬件来扩展slave的节点数量，将读压力分散到多台slave的机器上面。此方案能够在很大的程度上解决数据库读取数据的压力瓶颈问题，这是因为在大多的应用系统中，读压力要比写压力大很多多。
此示例由一个ConfigMap、两个Service和一个StatefulSet所组成。
通过YAML文件创建名为mysql的ConfigMap：
$ kubectl create -… 阅读全文
数人云上海&深圳两地“容器之Mesos/K8S/Swarm三国演义”的嘉宾精彩实录第三更来啦。唯品会是数人云Meetup的老朋友，去年曾做过RPC服务框架和Mesos容器化的分享。本次分享中，嘉宾王成昌分享了唯品会在Kubernetes上两年的PaaS实践，干货满满诚意奉上~
王成昌，唯品会PaaS平台高级开发工程师
主要工作内容包括：平台DevOps方案流程优化，持续部署，平台日志收集，Docker以及Kubernetes研究。
大家好，我是唯品会PaaS团队的王成昌，与大家分享一下PaaS在Kubernetes的实践。基于2014年底或2015年初PaaS没有推广的现状，唯品会PaaS部门目前已经做了两年的时间。
PaaS 主要工作将分为三个部分进行介绍，首先，PaaS定义的标准构建流程，持续集成和持续部署的架构以及已有组建上的功能定制；第二部分，基于Kubernetes实现的网络方案，以及根据网络方案做的扩展定制；第三部分，PaaS如何做日志收集和监控方案，最后列一下唯品会目前为止所遇到的问题和总结。
唯品会目前线上有一千多个域，每个域之间相互的依赖比较复杂，每次的部署发布困难。线下有多套的测试环境，每套测试环境都要去维护单独的应用升级和管理。公司层面也没有统一的持续集成和部署的流程，大家各自去维护一个Jenkins或者一个Jenkins slave，看工程师的个人追求是否能够写一个完整的从源代码、到打包、最后到部署的脚本。
唯品会线上全部用物理机在跑，之前Openstack方式没有在线上，只是在测试环境跑，物理机的使用效率还是比较低的。即使在7周年大促的高峰时段，60~80%的物理机利用率也均低于10%。
基于前面提到的现状，唯品会的PaaS定义了一个构建流程，整个流程不是一蹴而就，这是目前为止的定义，首先从源代码的角度出发，即Git，所有的7个Phase全部包括在Jenkins Pipeline里，由于是基于Kubernetes，所以Jenkins Pipeline的执行是通过Jenkins k8s Plugin去调度后台的k8s Cluster，由k8s产生的Pod去运行Pipeline。整个Pipeline的几个阶段，除了传统的编译单元测试和打包之外，加入了烘焙镜像、部署以及集成公司的集成测试（即VTP），打包和镜像完成后会正常上传到公司统一的包管理系统Cider和平台维护的Docker registry。
部署完成后会触发集成测试，如果通过测试的话，会把这个包或者是镜像标记为可用的状态，一般先从测试环境标记，然后通过到staging环境。目前PaaS 平台主要是维护测试环境和staging环境，线上还没有，但是已经定义了一个审批的流程，如果标记了这个包为可用的状态，需要一个审批来决定它是否可以上线。部署后通过k8s client，由另外一套k8s的集群来管理部署里面所有的节点。
这是唯品会的PaaS架构，主要包含持续集成和持续部署。首先由一个统一UI的入口Dashboard，使用Nginx和Tomcat作为服务的网关。其背后有两套系统——CPMS和API server，CPMS主要管理持续集成的各个流程，API server主要管理应用部署，在CPMS背后是使用多个Jenkins server统一连到一个Kubernetes集群上产生Pod作为Jenkins slave去运行，不同的构建有多种语言也有不同的模板，这里会提供各种方案让不同的Jenkins Pipeline运行在不同的Kubernetes node里面。
在部署实现一个Cloud Framework，可以接入各种cloud provider，目前使用的是k8s provider，背后的服务发现也是k8s推荐使用的Skydns。为了兼容公司基于包发布的这样一套模式，镜像管理这部分会把包管理系统Cider接入进入，平台的Docker Registry，以及应公司安全方面的要求，通过Clair对镜像的内容进行检查。
在日志收集方面，使用fluentd+ELK的组合，采用Prometheus做监控。在PaaS架构里，安全是通过接入公司的CAS做认证的动作，有一个Oauth组件做鉴权机制，通过Gnats做消息传输的系统。配额的问题在构建和部署中都会有所体现，包括用户对于Pipeline的个数控制或者Pipeline触发的个数，以及对应用上的物理配额或者逻辑资源配额等。
… 阅读全文