http://www.sebible.cn/blog/ Recent content in Blogs on 思百博 Hugo -- gohugo.io en-us © 2018 Copyright 成都思百博科技有限公司 Fri, 20 Oct 2017 23:03:36 +0800 http://www.sebible.cn/blog/kubernetes-master-ha/ Fri, 20 Oct 2017 23:03:36 +0800 http://www.sebible.cn/blog/kubernetes-master-ha/ Kubernetes高可用也许是完成了初步的技术评估，打算将生产环境迁移进Kubernetes集群之前普遍面临的问题。 为了减少因为服务器当机引起的业务中断，生产环境中的业务系统往往已经做好了高可用，而当引入Kubernetes这一套新的集群管理系统之后， 服务器不再是单一的个体，位于中央位置的Kubernetes Master一旦中断服务，将导致所有Node节点均不可控，有可能造成严重的事故。 总体来讲这是一个被多次讨论，但暂时没有形成统一解决方案的话题。今天主要介绍一些Kubernetes Master高可用的策略，供大家参考。 一个小目标 高可用是复杂的系统工程。出于篇幅的考虑以及能力的限制，今天我们先关注一个小目标：所有的Kubernetes Master服务器没有单点故障，任何一台服务器当机均不影响Kubernetes的正常工作。 实现这一目标带来的直接收益是我们可以在不影响业务正常运行的前提下实现所有服务器的滚动升级，有助于完成系统组件升级以及安全补丁的下发。 为了实现没有单点故障的目标，需要为以下几个组件建立高可用方案： etcd kube-apiserver kube-controller-manager与kube-scheduler kube-dns 这些组件的关系可参考下面这张集群架构示意图。 下面为大家逐个详细介绍各个组件的高可用策略。 etcd高可用 etcd是Kubernetes当中唯一带状态的服务，也是高可用的难点。Kubernetes选用etcd作为它的后端数据存储仓库正是看重了其使用分布式架构，没有单点故障的特性。 虽然单节点的etcd也可以正常运行。但是推荐的部署方案均是采用3个或者5个节点组成etcd集群，供Kubernetes使用。 大家常使用的kubeadm工具默认是在一个单节点上启动etcd以及所有的Master组件。虽然使用起来非常方便，但是要用到生产环境还是要注意这个节点当机的风险。 etcd的高可用基本有三种思路： 一是使用独立的etcd集群，使用3台或者5台服务器只运行etcd，独立维护和升级。甚至可以使用CoreOS的update-engine和locksmith，让服务器完全自主的完成升级。这个etcd集群将作为基石用于构建整个集群。 采用这项策略的主要动机是etcd集群的节点增减都需要显式的通知集群，保证etcd集群节点稳定可以更方便的用程序完成集群滚动升级，减轻维护负担。 二是在Kubernetes Master上用static pod的形式来运行etcd，并将多台Kubernetes Master上的etcd组成集群。 在这一模式下，各个服务器的etcd实例被注册进了Kubernetes当中，虽然无法直接使用kubectl来管理这部分实例，但是监控以及日志搜集组件均可正常工作。在这一模式运行下的etcd可管理性更强。 三是使用CoreOS提出的self-hosted etcd方案，将本应在底层为Kubernetes提供服务的etcd运行在Kubernetes之上。 实现Kubernetes对自身依赖组件的管理。在这一模式下的etcd集群可以直接使用etcd-operator来自动化运维，最符合Kubernetes的使用习惯。 这三种思路均可以实现etcd高可用的目标，但是在选择过程中却要根据实际情况做出一些判断。简单来讲预算充足但保守的项目选方案一， 想一步到位并愿意承担一定风险的项目选方案三。折中一点选方案二。各个方案的优劣以及做选择过程中的取舍在这里就不详细展开了，对这块有疑问的朋友可以私下联系交流。 kube-apiserver高可用 apiserver本身是一个无状态服务，要实现其高可用相对要容易一些，难点在于如何将运行在多台服务器上的apiserver用一个统一的外部入口暴露给所有Node节点。 说是难点，其实对于这种无状态服务的高可用，我们在设计业务系统的高可用方案时已经有了相当多的经验积累。需要注意的是apiserver所使用的SSL证书要包含外部入口的地址，不然Node节点无法正常访问apiserver。 apiserver的高可用也有三种基本思路： 一是使用外部负载均衡器，不管是使用公有云提供的负载均衡器服务或是在私有云中使用LVS或者HaProxy自建负载均衡器都可以归到这一类。 负载均衡器是非常成熟的方案，在这里略过不做过多介绍。如何保证负载均衡器的高可用，则是选择这一方案需要考虑的新问题。 二是在网络层做负载均衡。比如在Master节点上用BGP做ECMP，或者在Node节点上用iptables做NAT都可以实现。采用这一方案不需要额外的外部服务，但是对网络配置有一定的要求。 三是在Node节点上使用反向代理对多个Master做负载均衡。这一方案同样不需要依赖外部的组件，但是当Master节点有增减时，如何动态配置Node节点上的负载均衡器成为了另外一个需要解决的问题。 从目前各个集群管理工具的选择来看，这三种模式都有被使用，目前还没有明确的推荐方案产生。建议在公有云上的集群多考虑第一种模式，在私有云环境中由于维护额外的负载均衡器也是一项负担，建议考虑第二种或是第三种方案。 kube-controller-manager与kube-scheduler高可用 这两项服务是Master节点的一部分，他们的高可用相对容易，仅需要运行多份实例即可。这些实例会通过向apiserver中的Endpoint加锁的方式来进行leader election， 当目前拿到leader的实例无法正常工作时，别的实例会拿到锁，变为新的leader。 目前在多个Master节点上采用static pod模式部署这两项服务的方案比较常见，激进一点也可以采用self-hosted的模式，在Kubernetes之上用DaemonSet或者Deployment来部署。 Kube-dns高可用 严格来说kube-dns并不算是Master组件的一部分，因为它是可以跑在Node节点上，并用Service向集群内部提供服务的。但在实际环境中， 由于默认配置只运行了一份kube-dns实例，在其升级或是所在节点当机时，会出现集群内部dns服务不可用的情况，严重时会影响到线上服务的正常运行。 为了避免故障，请将kube-dns的replicas值设为2或者更多，并用anti-affinity将他们部署在不同的Node节点上。这项操作比较容易被疏忽，直到出现故障时才发现原来是kube-dns只运行了一份实例导致的故障。 总结 上面介绍了Kubernetes Master各个组件高可用可以采用的策略。其中etcd和kube-apiserver的高可用是整个方案的重点。由于存在多种高可用方案，集群管理员应当根据集群所处环境以及其他限制条件选择适合的方案。 这种没有绝对的通用方案，需要集群建设者根据不同的现状在多个方案中做选择的情况在Kubernetes集群建设过程中频频出现， 也是整个建设过程中最有挑战的一部分。容器网络方案的选型作为Kubernetes建设过程中需要面对的另外一个大问题也属于这种情况，今后有机会再来分享这个话题。 在实际建设过程中，在完成了上述四个组件的高可用之后，最好采取实际关机检验的方式来验证高可用方案的可靠性，并根据检验的结果不断调整和优化整个方案。 此外将高可用方案与系统自动化升级方案结合在一起考虑，实现高可用下的系统自动升级，将大大减轻集群的日常运维负担，值得投入精力去研究。 虽然本篇主要在讲Kubernetes Master高可用的方案，但需要指出的是，高可用也并不是必须的，为了实现高可用所付出的代价并不低， 需要有相应的收益来平衡。对于大量的小规模集群来说，业务系统并没有实现高可用，贸然去做集群的高可用收益有限。这时采用单Master节点的方案，做好etcd的数据备份，不失为理性的选择。 http://www.sebible.cn/blog/goodbye-elk-hello-fluent-bit-aliyun/ Wed, 28 Jun 2017 17:40:05 +0800 http://www.sebible.cn/blog/goodbye-elk-hello-fluent-bit-aliyun/ ELK是Elasticsearch，Logstash，Kibana的缩写，是我们在处理日志时最常用到的方案。其中Logstash负责日志采集， Elasticsearch负责日志存储，Kibana负责日志展示。三款开源项目分工合作，提供了完整的解决方案。 此外也有使用Fluentd替换Logstash组成的EFK方案，同样也非常受欢迎。 针对不同的环境，已经有大量的文档详细介绍了安装和配置的方法。在Kubernetes环境中，管理员甚至可以使用一键部署脚本完成安装。 这些总结下来的经验极大的降低了ELK的上手门槛，运维人员可以很方便的开始将所有服务器产出日志统一的搜集起来。 但在使用了一段时间之后，随着数据量的增加以及集群规模的扩大，维护一套高效运转的ELK系统所需要付出的运维成本在逐渐增大。 管理员将面临以下几个挑战： 多种不同应用的日志格式不同，需要为不同的应用配置专门的日志解析器 在所有服务器上更新组件版本以及配置带来的运维工作量的增加 单机版本的Elasticsearch的性能跟不上日志产出的速度，需要集群化部署ES ES集群的搭建和管理过程中的复杂度对运维人员的能力要求较高。过度依赖脚本和教程的工程师可能无法顺利完成 ES消耗的IO，CPU，内存资源均较高。为了能够提供足够的日志处理能力，ELK所需要的计算资源投入对于小型团队来说是不小的负担 ELK方案中缺少日志归档，持久保存的功能。而ES的存储能力受集群规模的限制无法无限扩张。管理员需要面临删除老数据或是研发数据导出存档功能的选择 在Kubernetes环境中，使用k8s所提供的调度功能和ConfigMap所提倡的配置管理最佳实践，再配合上elasticsearch-operator这样的工具， 可以大大降低日常的运维负担，但在算力消耗以及成本增加的问题上，能够带来的改善有限。 对于小型项目，我们需要更加轻量更加经济的解决方案，将日志管理SaaS化，交给合适的供应商来提供，用户按需付费可能是更适合的解决方案。 阿里云日志服务 阿里云提供的日志服务是一套完整的日志管理解决方案。它提供的搜集、消费、存储、查询、归档等功能基本覆盖了日志管理绝大部分的需求。 具体的功能清单如下图所示，在阿里云的网站上有更加详细的介绍，这里就不进一步展开了。 阿里云日志服务对运行在阿里云上的服务器有原生的支持，但是对于Kubernetes下的容器环境的支持有限，此外对于非阿里云服务器， 用户需要自己完成配置和对接。为了解决容器环境的日志搜集以及方便大量的非阿里云用户使用阿里云日志服务， 我们为fluent-bit开发了插件来支持向阿里云日志服务输出日志。 fluent-bit-aliyun fluent-bit和fluentd来自同一家公司。fluent-bit使用C语言开发，比使用Ruby开发的fluentd性能更好，资源占用更低。 作为一个新项目，虽然目前支持的插件还没有fluentd丰富，但已经有不少团队开始在生产环境中使用它。 fluent-bit-aliyun是使用Go语言开发的fluent-bit插件，通过API调用将日志输出到阿里云日志服务。 项目地址在https://github.com/kubeup/fluent-bit-aliyun。 为了方便使用，我们提供了打包好的Docker镜像，在https://hub.docker.com/r/kubeup/fluent-bit-aliyun/ 在Docker环境中安装 Docker原生支持fluentd格式日志输出。我们可以在容器中运行fluent-bit-aliyun，然后在启动新容器时进行配置将日志发送给它即可。 $ docker run -d --network host -e ALIYUN_ACCESS_KEY=YOUR_ACCESS_KEY -e ALIYUN_ACCESS_KEY_SECRET=YOUR_ACCESS_KEY_SECRET -e ALIYUN_SLS_PROJECT=YOUR_PROJECT -e ALIYUN_SLS_LOGSTORE=YOUR_LOGSTORE -e ALIYUN_SLS_ENDPOINT=cn-hangzhou.log.aliyuncs.com kubeup/fluent-bit-aliyun:master /fluent-bit/bin/fluent-bit -c /fluent-bit/etc/fluent-bit-forwarder.conf -e /fluent-bit/out_sls.so $ docker run --log-driver=fluentd -d nginx 如果在启动Docker Daemon时进行配置，还可以默认将所有日志发送到阿里云日志服务。 在Kubernetes环境中安装 在Kubernetes环境中，我们使用DaemonSet在集群中的所有Node上部署fluent-bit-aliyun，它将搜集每台服务器上所有Pod所输出的日志。 fluent-bit内置的kubernetes过滤器会将Pod的元数据附加到日志上。 首先，我们创建一个新的Secret来保存所有的配置信息： http://www.sebible.cn/blog/load-testing-with-kubernetes/ Sat, 13 May 2017 23:53:02 +0800 http://www.sebible.cn/blog/load-testing-with-kubernetes/ 压力测试是用来检测系统承载能力的有效手段。在系统规模较小的时候，在一台空闲的服务器上使用ab，wrk，siege 等工具发起一定量的并发请求即可得到一个初步的测试结果。但在系统复杂度逐步提高，特别是引入了负载均衡， 微服务等架构后，单机的压力测试方案不再可用，企业需要搭建分布式测试集群或者付费使用外部供应商提供的压力测试服务。 不管是采取自主搭建或是采用外购的手段，都会面临系统使用率不高以及成本的问题。基于Kubernetes的动态资源调度功能， 以及Kubernetes集群的动态伸缩特性，我们可以充分利用集群内的闲置计算资源，在需要进行压力测试时启动测试节点， 在测试结束后释放资源给其他业务，甚至通过集群扩容和缩容临时为压力测试提供更多的计算资源。 支持分布式部署的压力测试工具有多款，今天我们将介绍在Kubernetes集群中使用Tsung进行压力测试的方法。 Tsung Tsung是一款使用Erlang开发的分布式压力测试系统，它支持HTTP，Jabber，MySQL等多种协议，可以用于不同场景的压力测试。 与传统的针对单一测试目标重复请求的压测系统不同，Tsung更侧重于模拟真实使用场景。测试人员指定新用户到访频率， 并设定一系列的模拟操作请求。所有的Slave节点将在Master节点的统一调度下，按照到访频率创建虚拟用户，并发送操作请求。 所有请求的耗时以及错误信息将传回Master节点用于统计和报表。 选择Tsung主要有三方面的考虑： 性能优越。Erlang语言天生就是为高并发网络系统设计的。合理配置的Tsung集群可以实现100W以上的并发流量。 描述式的配置方法。不论简单还是复杂，Tsung均统一使用XML文件描述整个测试步骤以及各种参数。这样可以在集群架构保持不变时完成各种测试。 模拟真实用户的测试理念。在真实场景中，用户会访问系统的各项功能。只有支持模拟真实用户的压力测试系统才能比较准确的反应系统各个部分在压力下的状态，找到瓶颈环节。 由于Tsung采取的工作模式是在配置中注明Slave地址，然后由Master连上Slave完成测试，传统的部署方法是启动多台物理机或者虚拟机， 分别配置它们。在这种工作模式下，会产生大量的运维工作，同时这些计算资源在不进行测试时处于闲置状态，降低了硬件使用率。 在Kubernetes中使用容器运行Tsung 利用Kubernetes强大的调度能力，我们可以将Tsung运行在容器当中，动态的启动和删除。当需要提高测试规模时， 我们仅需要使用Archon等已有的工具对集群进行扩容，就可以很方便的一键扩容Slave的数量，几乎没有带来任何的运维负担。 以下是具体的操作流程： 创建Namespace $ kubectl create namespace tsung 使用StatefulSet部署Tsung Slave 这里不能使用Deployment，只有使用StatefulSet才能在为每一个Pod分配独立的内部域名，供Master连接。 将以下文件保存为tsung-slave-svc.yaml apiVersion: v1 kind: Service metadata: labels: run: tsung-slave name: tsung-slave spec: clusterIP: None selector: run: tsung-slave ports: - port: 22 type: ClusterIP 将以下文件保存为tsung-slave.yaml apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: tsung-slave spec: serviceName: "tsung-slave" replicas: 1 template: metadata: labels: run: tsung-slave spec: containers: - name: tsung image: ddragosd/tsung-docker:1. http://www.sebible.cn/blog/ipvs-loadbalancer-for-kubernetes/ Tue, 25 Apr 2017 00:04:28 +0800 http://www.sebible.cn/blog/ipvs-loadbalancer-for-kubernetes/ 新搭建的Kubernetes集群如何承接外部访问的流量，是刚上手Kubernetes时常常会遇到的问题。 在公有云上，官方给出了比较直接的答案，使用LoadBalancer类型的Service，利用公有云提供的负载均衡服务来承接流量， 同时在多台服务器之间进行负载均衡。而在私有环境中，如何正确的将外部流量引入到集群内部，却暂时没有标准的做法。 本文将介绍一种基于IPVS来承接流量并实现负载均衡的方法，供大家参考。 IPVS IPVS是LVS项目的一部分，是一款运行在Linux kernel当中的4层负载均衡器，性能异常优秀。 根据这篇文章的介绍，使用调优后的内核，可以轻松处理每秒10万次以上的转发请求。目前在中大型互联网项目中， IPVS被广泛的使用，用于承接网站入口处的流量。 Kubernetes Service Service是Kubernetes的基础概念之一，它将一组Pod抽象成为一项服务，统一的对外提供服务，在各个Pod之间实现负载均衡。 Service有多种类型，最基本的ClusterIP类型解决了集群内部访问服务的需求，NodePort类型通过Node节点的端口暴露服务， 再配合上LoadBalancer类型所定义的负载均衡器，实现了流量经过前端负载均衡器分发到各个Node节点暴露出的端口， 再通过iptables进行一次负载均衡，最终分发到实际的Pod上这个过程。 在Service的Spec中，externalIPs字段平常鲜有人提到，当把IP地址填入这个字段后，kube-proxy会增加对应的iptables规则， 当有以对应IP为目标的流量发送到Node节点时，iptables将进行NAT，将流量转发到对应的服务上。一般情况下， 很少会遇到服务器接受非自身绑定IP流量的情况，所以externalIPs不常被使用，但配合网络层的其他工具，它可以实现给Service绑定外部IP的效果。 今天我们将使用externalIPs配合IPVS的DR(Direct Routing)模式实现将外部流量引入到集群内部，同时实现负载均衡。 环境搭建 为了演示，我们搭建了4台服务器组成的集群。一台服务器运行IPVS，扮演负载均衡器的作用，一台服务器运行Kubernetes Master组件， 其他两台服务器作为Node加入到Kubernetes集群当中。搭建过程这里不详细介绍，大家可以参考相关的文档。 所有服务器在172.17.8.0/24这个网段中。服务的VIP我们设定为172.17.8.201。整体架构如下图所示： 接下来让我们来配置IPVS和Kubernetes。 使用externalIPs暴露Kubernetes Service 首先在集群内部运行2个nginx Pod用作演示。 $ kubectl run nginx --image=nginx --replicas=2 再将它暴露为Service，同时设定externalIPs字段 $ kubectl expose deployment nginx --port 80 --external-ip 172.17.8.201 查看iptables配置，确认对应的iptables规则已经被加入。 $ sudo iptables -t nat -L KUBE-SERVICES -n Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVC-4N57TFCL4MD7ZTDA tcp -- 0. http://www.sebible.cn/blog/in-or-out/ Fri, 24 Mar 2017 07:33:00 +0800 http://www.sebible.cn/blog/in-or-out/ 如一切顺利的话，Kubernetes 1.6将于3月29日发布。虽然比预期延迟了一周，但是赶在了KubeCon之前， 对Kubernetes这个规模的项目来说已经实属不易。为了庆祝1.6版本的发布，撰文一篇讲讲目前Kubernetes生态圈的现状。 自2014年发布以来，Kubernetes发展迅速，从最开始以源自Google最佳实践的容器管理平台亮相， 再与Docker Swarm和Mesos一起争夺容器编排领域的主导位置，到最近开始整合整个容器生态的上下游。 Kubernetes始终保持着小步快跑的节奏，在每个Release当中不断推出新的Feature。 同时Kubernetes背后的组织CNCF还在不断吸收Kubernetes生态圈中的优秀开源项目，解决最终用户在生产部署中所存在的监控、 日志搜集等需求。 如今，Kubernetes已经超越了单纯的容器编排工具，企业选择Kubernetes本质上是拥抱以Kubernetes为核心的云原生最佳实践。 其中包含了网络、存储、计算等运行资源的调度，还涵盖了监控、日志搜集、应用分发、系统架构等研发和运维的操作流程。 容器引擎接口(Container Runtime Interface) 众所周知，Kubernetes和Docker是既合作又竞争的关系。Kubernetes使用Docker Engine作为底层容器引擎，在容器编排领域与Docker Swarm展开竞争。为了减少对Docker的依赖，同时满足生态中其他容器引擎与Kubernetes集成的需要，Kubernetes制定了容器引擎接口CRI。 随后Kubernetes发布了cri-o项目，开始研发自己的Docker兼容容器引擎。目前已经有Docker，rkt，cri-o三款容器引擎支持CRI接口。 此外支持CRI的还有Hyper.sh主导的frakti项目以及Mirantis主导的virtlet项目， 它们为Kubernetes增加了直接管理虚拟机的能力。 CRI的发布将Docker推到了一个非常难受的位置，如果不支持CRI，面临着在Kubernetes体系当中被其他容器引擎所替换的风险。 如果支持CRI，则意味着容器引擎的接口定义被竞争对手所主导，其他容器引擎也可以通过支持CRI来挑战Docker在容器引擎领域的事实标准地位。 最终，为了不被边缘化，Docker只能妥协，选择将containerd项目捐献给CNCF。在同一天，CoreOS也宣布将rkt项目捐献给CNCF。 至此CRI成为了容器引擎接口的统一标准，今后如果有新的容器引擎推出，将首先支持CRI。 容器网络接口(Container Network Interface) 因为Kubernetes没有内置容器网络组件，所以每一个Kubernetes用户都需要进行容器网络的选型，给新用户带来了不小的挑战。 从现状来看，不内置网络组件的策略虽然增加了部署的复杂度，但给众多SDN厂商留下了足够的公平竞争空间，从中长期来讲是有利于容器网络领域的良性发展的。 1.0版本的Kubernetes没有设计专门的网络接口，依赖Docker来实现每个Pod拥有独立IP、Pod之间可以不经过NAT互访的网络需要。 随着与Docker的竞争加剧以及Docker主导的CNM接口的推出，Kubernetes也推出了自己的容器网络接口CNI。 随着CNI的推出，各家SDN解决方案厂商纷纷表示支持。目前Flannel，Calico，Weave，Contiv这几款热门项目均已支持CNI， 用户可以根据需要为自己的Kubernetes集群选择适合的网络方案。面对CNI和CNM，主流厂商目前的选择是同时支持，但从中长期来看， 厂商一定会根据各个生态的发展进度来动态配置资源，这时Docker内置的原生网络组件有可能反而会影响和其他网络厂商的协作。 容器存储接口(Container Storage Interface) 在统一了容器引擎和容器网络之后，Kubernetes又将触角伸到了存储领域。目前还在制定过程当中的容器存储接口CSI有望复制CRI和CNI的成功， 为Kubernetes集群提供可替换的存储解决方案。不论是硬件存储厂商或是软件定义存储解决方案厂商，预计都将积极拥抱CSI。 因为不支持CSI就意味着放弃整个Kubernetes生态圈。 软件打包与分发(Packaging and Distribution) 在使用CRI，CNI，CSI解决底层运行环境的抽象以外，Kubernetes还在试图通过Helm项目以及Helm Charts来统一软件打包与分发的环节。 由于Kubernetes提供了底层的抽象，应用开发者可以利用Kubernetes内置的基础元素将上层应用打包为Chart，用户这时就能使用Helm完成一键安装以及一键升级的操作。 在系统架构越来越复杂的今天，能够方便的将复杂的分布式系统运行起来，无疑为Kubernetes的推广增加了不少亮点。 目前一些常见的开源系统，比如Redis，ElasticSearch等已经可以通过使用官方的Charts进行部署。相信未来会有更多的开源项目加入这个清单。 看到这一块商机的公司，比如CoreOS，已经推出了自己的软件仓库服务。由于这块离最终用户最近，相信未来在这一领域的竞争将会非常激烈。 云原生计算基金会(Cloud Native Computing Foundation) 前面列举的案例主要偏重技术解决方案，Kubernetes最有潜力的其实是在幕后团结容器生态中各方力量的CNCF组织。 与同期建立的Docker主导的OCI组织相比，当前CNCF不论是在项目数量，会员数量，会员质量等多个方面都明显领先。 可以说CNCF是事实上在推动整个容器生态向前发展的核心力量。 人的力量是最根本的也是最强大的，只有团结到尽可能多的玩家，才能制定出各方都能接受的标准。面对这么多的会员企业，要平衡各方的诉求实在不是容易的事情。 目前CNCF做的还不错，中立的基金会形式似乎更加容易被各方所接受。最近正在进行决策小组选举的讨论，有兴趣的朋友可以自行围观。 总结 有两句经常听到的话在Kubernetes身上得到了很好的体现，一是没有什么是不能通过增加一个抽象层解决的，二是一流的企业做标准，二流的企业做品牌，三流的企业做产品。 Kubernetes通过在具体实现上增加抽象层，试图为整个容器生态圈建立统一的标准。当标准逐步建立，用户开始依照标准选择解决方案， 将进一步强化Kubernetes位于整个容器生态核心的地位。这时容器生态的上下游将不得不面对，要么选择In拥抱Kubernetes所提出的标准， 要么选择Out被整个生态圈孤立的情况。面对这种选择，想必大部分厂商都将选择In，而更多的厂商加入将进一步强化标准的力量。 可以预见Kubernetes构建的组织、标准、开源项目三层体系，将有望统一容器生态圈的各方力量，而这种统一对最终用户是有益的。 在容器生态中的各个领域，开源的解决方案将与商业解决方案直接竞争，甚至开源解决方案之间也将展开竞争。这种竞争将促进整个容器生态的发展， 由于大家都遵守相同的标准，不论你在最初建设时选择的是哪一套解决方案，将来也可以用更新更好的方案来替换， 规避了商家绑定的风险。希望捐献给CNCF的项目将会越来越多，因为进入CNCF就意味着比其他相同功能的开源项目更加容易获得Kubernetes生态圈的认可。 http://www.sebible.cn/blog/deploy-production-ready-kubernetes-cluster-on-aliyun/ Sat, 25 Feb 2017 09:38:05 +0800 http://www.sebible.cn/blog/deploy-production-ready-kubernetes-cluster-on-aliyun/ 阿里云是国内非常受欢迎的基础云平台，随着Kubernetes的普及，越来越多的企业开始筹划在阿里云上部署自己的Kubernetes集群。 本文将结合实战中总结的经验，分析和归纳一套在阿里云上部署生产级别Kubernetes集群的方法。 文中所采取的技术方案具有一定的主观性，供各位读者参考。在实践中可以根据具体使用场景进行优化。 目标 当我们刚接触Kubernetes进行测试集群的搭建时，往往会选择一篇已有的教程，照着教程完成集群搭建。我们很少去质疑教程作者每一步操作的合理性， 只想快点把集群搭建起来，早点开始实际的上手体验。 与测试集群不同，对于生产级别的部署，我们会有更加严格的要求，更加强调合理的规划以及每个步骤的合理性以及可管理性。以下是我们设定的目标： 没有单点故障。任何一台服务器离线不会影响到整个集群的正常运转 充分利用阿里云原生提供的SLB，云盘等工具，支持Volume挂载，LoadBalancer类型的Service等Kubernetes基础功能。 获得完整的Kubernetes使用体验。 在不牺牲安全性和稳定性的前提下，尽可能降低日常运维所需要的投入，将可以由程序完成的重复性工作自动化 支持随着业务规模扩展的动态集群规模扩展 因为篇幅的原因，以下内容将不作为本文的目标，留待日后再做分享： 集群运行成本控制 监控、日志等运维系统的搭建 安全防护以及权限设计 现状 目前Kubernetes主要支持的云平台还是海外的几大主流平台，但是对比阿里云提供的基础设施，我们已经具有了基本相同的底层环境。 阿里云提供的VPC，云盘，SLB，NAS等组件，都为搭建生成级别Kubernetes集群提供了很好的支持。充分利用这些组件， 我们应该可以搭建出完整可用的Kubernetes集群。但是仔细研究Kubernetes的代码我们会发现，阿里云的CloudProvider暂时没有被合并到上游当中， 所以我们需要设计方案来解决Kubernetes暂时还没有原生阿里云支持的问题。 Kubernetes生态圈发展迅速，目前已经有了像kops这种集群自动创建工具帮助运维工程师创建集群。但是目前已有的集群创建工具均只支持国外的云平台， 使得国内云平台的用户只能采取手动搭建的办法。像kubeadm这种半自动工具还可以使用，也算是减轻了不少负担。从目前状况来看， 运维的负担依然很严重，为我们实现生产级别部署所追求的自动化、规模化的目标带来了不小的障碍。 由于网络原因造成的镜像拉取困难也给我们创建Kubernetes集群制造了不小的麻烦，好在阿里云一直在致力于解决这个问题，为用户提供了镜像拉取加速服务以及重要镜像的Mirror。 另一个问题是操作系统镜像的问题，在后面分析操作系统的时候再详细展开。 架构 基于消除单点故障以及降低复杂度的考虑，我们设计了由5台服务器，分两个服务器组构成的Kubernetes集群的控制节点，并视业务需求情况由N台服务器， 分多个服务器组，构成集群的运行节点。如下图所示： 在设计这一架构时，我们考虑了以下几点： 整个集群的主要构成元素为服务器组。一组服务器具有相同的硬件配置，服务相同的功能，在软件配置上也基本相同。这样为服务器的自动化管理打下了很好的基础。 由3台服务器组成的etcd集群，在其中任何一台服务器离线时，均可以正常工作。为整个Kubernetes集群的数据持久化保存提供了稳定可靠的基础 2台同时运行着Kubernetes核心组件kube-apiserver，kube-controller-manager，kube-scheduler的服务器，为整个集群的控制平面提供了高可用性。 多个运行节点服务器组，有着不同的CPU，内存，磁盘配置。让我们可以灵活的根据业务对运行环境的要求来选择不同的服务器组。 集群搭建 在有了架构蓝图后，接下来让我们来实际搭建这个集群。 操作系统选型 搭建集群首先会面临的问题是，选什么配置的服务器，用什么操作系统。服务器硬件配置相对好解决，控制节点在业务量不大的时候选择入门级别的配置再随着业务增长不断提升即可， 运行节点应当根据业务需要来选择，可能要做一些尝试才能定下来最适合的硬件配置。比较困难的选择是操作系统的选型。 只要是使用较新的Kernel的Linux主机，均可以用来运行Kubernetes集群，但是发行版的选择却需要从多个方面来考虑。在这里我们选择了CoreOS作为最基础的操作系统。 做出这一选择是基于以下这些因素： CoreOS是专门为运行容器设计的操作系统，非常适合用来运行Kubernetes集群 CoreOS去除了包管理，使用镜像升级的方式，大大简化了运维的复杂度 CoreOS可以使用cloud-init，方便的对服务器进行初始化 阿里云提供了CoreOS的支持 CoreOS的详细介绍，大家可以参考官方的文档，在这里就不展开了。需要指出的是阿里云提供的CoreOS镜像版本较低，需要先进行升级才能正常使用，增加了不少麻烦。 希望以后阿里云能够提供最新版本的CoreOS镜像，改善这一问题。 CoreOS版本升级 由于网络的原因，CoreOS在国内不能正常进行升级。我们需要在国内搭建升级服务器。CoreRoller是一个可选项。具体的搭建可以参考相关文档，在这里就略过了。 在顺利搭建好升级服务器之后，可以修改/etc/coreos/update.conf，添加SERVER=https://YOUR_SERVER/v1/update/这一条配置，然后使用以下指令来升级服务器： sudo systemctl restart update-engine update_engine_client -update 我们搭建了自己的升级服务器，如果有需要的朋友可以联系我们获得服务器地址。后面所有启动的CoreOS服务器，我们均假设管理员已经提前完成了版本升级的工作， 在流程中不再重复。如果阿里云开始提供最新的CoreOS镜像，那这一步可以省略掉。 http://www.sebible.cn/blog/your-kubernetes-cluster-may-not-need-sdn/ Sun, 29 Jan 2017 21:33:29 +0800 http://www.sebible.cn/blog/your-kubernetes-cluster-may-not-need-sdn/ SDN是Software-defined networking的缩写。在许多介绍Kubernetes的文档，特别是安装文档中， 当介绍到Kubernetes所需的容器网络时常常会提到这个缩写，告知用户需要使用某种SDN技术用以解决“每个Pod有独立IP， Pod之间可以不经过NAT直接互访”这一Kubernetes集群最基本的技术要求。 大多数非网络工程师背景的技术人员对SDN这个概念会比较陌生，当读到这个段落时，往往会选择把它当作Kubernetes的底层依赖， 照着文档所推荐的流程安装一款SDN工具，比如Flannel，Calico，Weave等。由于不了解这些工具的原理，同时缺乏实际的使用经验， 当出现文档以外的异常情况时，整个安装流程就卡住了。SDN俨然成为了Kubernetes大规模普及的拦路虎。 那些按照文档顺利搭建起来的集群当中，还有不少使用了并不适合该集群所处环境的SDN技术，造成了额外的运维负担以及潜在的安全风险。 让我们不得不思考一个问题，怎样才是正确的在Kubernetes集群中使用SDN技术的方法？ 今天我们来详细聊聊这个话题。 结论先行 在大多数的Kubernetes集群中，都不需要使用SDN技术，Kubernetes的容器网络要求可以使用更加简单易懂的技术来实现， 只有当企业有特定的安全或者配置要求时，才需要使用SDN技术。SDN应当作为一个附加选项，用以解决特定的技术问题。 理解Kubernetes的容器网络 下图是一张Kubernetes容器网络的示意图 可以看到在图中，每台服务器上的容器有自己独立的IP段，各个服务器之间的容器可以根据目标容器的IP地址进行访问。 为了实现这一目标，重点解决以下这两点： 各台服务器上的容器IP段不能重叠，所以需要有某种IP段分配机制，为各台服务器分配独立的IP段 从某个Pod发出的流量到达其所在服务器时，服务器网络层应当具备根据目标IP地址将流量转发到该IP所属IP段所对应的目标服务器的能力。 总结起来，实现Kubernetes的容器网络重点需要关注两方面，分配和路由。 Flannel的工作方式 这里我们以比较常见的Flannel为例子，看看SDN系统是如何解决分配和路由的问题的。 下图是Flannel的架构示意图 可以看到Flannel依赖etcd实现了统一的配置管理机制。当一台服务器上的Flannel启动时，它会连接所配置的etcd集群， 从中取到当前的网络配置以及其他已有服务器已经分配的IP段，并从未分配的IP段中选取其中之一作为自己的IP段。 当它将自己的分配记录写入etcd之后，其他的服务器会收到这条新记录，并更新本地的IP段映射表。 Flannel的IP段分配发生在各台服务器上，由flannel进程将结果写入到etcd中。路由也由Flannel完成，网络流量先进入Flannel控制的Tunnel中， 由Flannel根据当前的IP段映射表转发到对应的服务器上。 需要指出的是Flannel有多种backend，另外新增的kube-subnet-mgr参数会导致Flannel的工作方式有所不同，在这里就不详细展开了。 有兴趣的朋友可以去查阅Flannel的文档以及源代码了解更多的细节。 更见简化的网络配置方法 Flannel的工作方式有2点是需要注意的。一是所有服务器上运行的Flannel均需要etcd的读写权限，不利于权限的隔离和安全防护。 二是许多教程中所使用的默认backend类型为vxlan，虽然它使用了内核中的vxlan模块，造成的性能损失并不大， 但是在常见的二层网络的环境中，其实并不需要使用Tunnel技术，直接利用路由就可以实现流量的转发， 这时使用hostgw模式就可以达成目标。 大部分的Kubernetes集群服务器数量并不会超过100台，不论是在物理机房当中或是利用IaaS提供的VPC技术，我们会把这些服务器均放在同一个网段， 这时我们可以去掉Flannel这一层，直接使用Kubernetes内置的kubenet功能，配合上我们为Kubernetes定制的hostroutes工具， 即可实现容器网络的要求。 kubenet kubenet是kubelet内置的网络插件中的一个，它非常的简单，会根据当前服务器对应的Node资源上的PodCIDR字段所设的IP段，配置一个本地的网络接口cbr0， 在新的Pod启动时，从IP段中分配一个空闲的IP，用它创建容器的网络接口，再将控制权交还给kubelet，完成后续的Pod创建流程。 由于kubenet会自己管理容器网络接口，所以使用kubenet时，不需要修改任何的Docker配置，仅需要在启动kubelet时，传入--network-plugin=kubenet 参数即可。 allocate-node-cidrs allocate-node-cidrs是controller-manager的一个参数，当它和cluster-cidr参数共同使用的时候，controller-manager会为所有的Node资源分配容器IP段， 并将结果写入到PodCIDR字段。 hostroutes hostroutes是我们为kubenet开发的一个配套小工具，它也非常的简单，它会watch所有的Node资源的变化，用所有Node资源的PodCIDR字段来配置服务器本地路由表。 这时所有Pod发出的流量将通过Linux自带的路由功能进行转发，性能优异。Linux的路由功能也是大部分技术人员已经掌握的技能，理解维护起来没有任何负担。 在这一简化的模式下，controller-manager负责分配容器IP段，kubenet负责本地网络接口的控制，hostroutes负责路由。 我们最大程度使用了Kubernetes已有的功能，并且用hostroutes来解决kubenet只管网络接口不管路由的问题。整个方案中， 需要写入权限的仅有部署在master节点的controller-manager，运行在Node节点上的kubenet和hostroutes均只需要读取权限即可，增强了安全性。 另外此方案将Kubernetes作为唯一的配置来源，去除了对etcd的依赖，简化了配置，降低了运维负担和安全风险。 不同的技术方案虽说实现细节不同，但是只要围绕着分配和路由这两个关键点进行比较，我们就可以更加明确的在不同方案之间进行选择。 容器网络技术方案选型推荐 任何的技术方案都离不开场景，在这里我们根据不同的场景给大家推荐几种技术方案： 单服务器：不需要网络组件，使用Docker自带的网络即可 小规模集群：使用kubenet + hostroutes，简单、易配合管理 云环境中的小规模集群：使用kubenet + master组件上运行的网络控制器，充分利用IaaS所提供的VPC环境中的路由功能，简化网络配置 服务器不在一个网段的集群：使用Flannel提供的vxlan或者其他类似的Tunnel技术 安全要求高的集群：使用Calico或者Open vSwitch等支持Policy的SDN技术 总结 在本篇文章中，我们探讨了Kubernetes的容器网络的工具方式，并以Flannel为案例分析了已有的SDN解决方案，并提出了适合小规模集群的kubenet + hostroutes的解决方案。希望可以帮助读者理清在Kubernetes集群搭建过程中容器网络这一部分的思路，不再因为容器网络影响了Kubernetes的整体使用。 http://www.sebible.cn/blog/single-node-kubernetes/ Sat, 21 Jan 2017 13:43:27 +0800 http://www.sebible.cn/blog/single-node-kubernetes/ 在传统的概念当中，Docker是简单易用的，Kubernetes是复杂强大的。 深入了解之后会发现Docker的简单是因为用户可以从基本功能开始用起， 只需要一台Linux主机，运行一下apt-get install docker-engine 或者yum install docker-engine，立马就可以用docker run启动一个新的容器， 整个过程与用户之前积累的Linux软件使用体验高度一致。 而Kubernetes则要求用户要分别配置SDN，ssl证书，etcd，kubelet，apiserver， controller-manager，scheduler，proxy，kubectl等多个组件， 刚刚接触对架构还不了解的新人一下就懵了。 过高的早期门槛把许多对Kubernetes感兴趣的用户挡在了外面，给人留下一种难以上手的感觉。 事实上，当整个系统扩展到多个节点，需要通盘考虑身份认证，高可用， 服务发现等高级功能后，Docker Swarm与Kubernetes的复杂度是接近的。 也许我们最初的比较出现了一点偏差， 将位于更高阶的集群管理和调度系统Kubernetes和位于底层的容器引擎Docker Engine直接比较并不恰当。 现在我们了解到Kubernetes的复杂是因为它提供了更多的功能， 但是如果我们无法解决Kubernetes的上手困难问题，始终会有推广上的障碍。 对此，Kubernetes社区做出了许多努力。比如： minikube可以方便的在本机用虚拟机创建一个开箱即用的Kubernetes集群 kubeadm可以自动化的将多台Ubuntu或者CentOS主机组建成集群 nanokube，kid等自动初始化脚本 充分利用已有的工具， 我们可以在单台服务器上把Kubernetes的上手体验简化到与Docker接近的程度， 新用户可以不再纠结于安装和配置，尽快开始使用Kubernetes完成工作， 在业务需求增长时，再扩展集群成为多节点高可用的完整集群。 下图是一张学习曲线的示意图，可以看到当引入单节点Kubernetes作为过渡之后， 整个学习曲线更加平滑，在早期简单环境时更接近Docker， 在后期环境完整时又能够充分利用Kubernetes的优势。 有多种方法可以创建单节点的Kubernetes集群，接下来分享其中一个比较简单方便的。 准备工作 首先准备一台Linux服务器，根据Docker官方的文档安装好Docker。 接着下载localkube和kubectl: $ curl -o localkube https://storage.googleapis.com/minikube/k8sReleases/v1.5.1/localkube-linux-amd64 $ chmod +x localkube $ curl -O https://storage.googleapis.com/kubernetes-release/release/v1.5.2/bin/linux/amd64/kubectl $ chmod +x kubectl localkube将Kubernetes所有的依赖程序全部打包成为了一个独立的可执行文件， 使用它可以省略掉几乎所有的配置流程，直接将Kubernetes跑起来。 目前localkube已经被合并进了minikube，最新的版本需要从minikube中下载。 kubectl是Kubernetes的客户端程序，可以用它控制集群。 启动Kubernetes 使用localkube启动集群非常简单: $ ./localkube 当不加任何参数时，localkube会使用默认参数启动， 它所监听的localhost:8080将被用于接受控制指令。 http://www.sebible.cn/blog/extend-prometheus-with-node-exporter/ Mon, 08 Aug 2016 22:38:48 +0800 http://www.sebible.cn/blog/extend-prometheus-with-node-exporter/ 在前一篇文章当中，我们介绍了在Kubernetes中使用Prometheus进行集群监控的方法，并配置了服务发现，让Prometheus从Kubernetes集群的各个组件中采集运行数据。 在之前的例子中，我们主要是通过kubelet中自带的cadvisor采集容器的运行状态。今天我们来进一步完善监控系统，使用Node Exporter采集底层服务器的运行状态。 Node Exporter简介 Exporter是Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据，并将其转化为Prometheus支持的格式。 与传统的数据采集组件不同的是，它并不向中央服务器发送数据，而是等待中央服务器主动前来抓取，默认的抓取地址为http://CURRENT_IP:9100/metrics Prometheus提供多种类型的Exporter用于采集各种不同服务的运行状态。Node Exporter顾名思义，主要用于采集底层服务器的各种运行参数。 目前Node Exporter支持几乎所有常见的监控点，比如conntrack，cpu，diskstats，filesystem，loadavg，meminfo，netstat等。 详细的监控点列表请参考其Github repo。 部署Node Exporter 在Kubernetes中部署Node Exporter非常简单，我们使用DaemonSet功能，可以非常方便的在集群内的所有主机上启动Node Exporter。 在配合上Prometheus的服务发现功能，无需额外的设置，我们就可以把这些Node Exporter Pod加入到被采集的列表当中。 将以下配置文件保存为node-exporter.yaml， 并运行 kubectl create -f node-exporter.yaml。 apiVersion: v1 kind: Service metadata: annotations: prometheus.io/scrape: 'true' labels: app: node-exporter name: node-exporter name: node-exporter spec: clusterIP: None ports: - name: scrape port: 9100 protocol: TCP selector: app: node-exporter type: ClusterIP ---- apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: node-exporter spec: template: metadata: labels: app: node-exporter name: node-exporter spec: containers: - image: prom/node-exporter:latest name: node-exporter ports: - containerPort: 9100 hostPort: 9100 name: scrape hostNetwork: true hostPID: true 国内的Kubernetes集群可以使用registry. http://www.sebible.cn/blog/kubernetes-monitoring-with-prometheus/ Wed, 03 Aug 2016 21:03:52 +0800 http://www.sebible.cn/blog/kubernetes-monitoring-with-prometheus/ 当你完成了Kubernetes集群的最初搭建后，集群监控的需求随之而来。 集群内的N台服务器在Kubernetes的管理下自动的创建和销毁着Pod， 但所有Pod和服务器的运行状态以及消耗的资源却不能方便的获得和展示， 给人一种驾驶着一辆没有仪表板的跑车在高速公路飞驰的感觉。 对于单机的Linux服务器监控，已经有了Nagios，Zabbix这些成熟的方案。 在Kubernetes集群中，我们使用新一代的监控系统Prometheus来完成集群的监控。 Prometheus简介 Prometheus是SoundCloud开源的一款监控软件。它的实现参考了Google内部的监控实现， 与同样源自Google的Kubernetes项目搭配起来非常合拍。同时它也是继Kubernetes之后 第二款捐赠给CNCF的开源软件。相信有CNCF的推广，它将逐步成为集群时代的重要底层组件。 Prometheus集成了数据采集，存储，异常告警多项功能，是一款一体化的完整方案。 它针对大规模的集群环境设计了拉取式的数据采集方式、多维度数据存储格式以及服务发现等创新功能。 今后我们会进一步探讨Prometheus的特性以及使用技巧，在这里我们直接演示在Kubernetes集群中 使用Prometheus的方式。 使用服务发现简化监控系统配置 与传统的先启动监控系统，然后配置所有服务器将运行数据发往监控系统不同。Prometheus 可以通过服务发现掌握集群内部已经暴露的监控点，然后主动拉取所有监控数据。 通过这样的架构设计，我们仅仅只需要向Kubernetes集群中部署一份Prometheus实例， 它就可以通过向apiserver查询集群状态，然后向所有已经支持Prometheus metrics的kubelet 获取所有Pod的运行数据。如果我们想采集底层服务器运行状态，通过DaemonSet在所有服务器上运行 配套的node-exporter之后，Prometheus就可以自动采集到新的这部分数据。 这种动态发现的架构，非常适合服务器和程序都不固定的Kubernetes集群环境，同时 也大大降低了运维的负担。 启动Prometheus服务 首先将Prometheus的配置文件，存为ConfigMap。 apiVersion: v1 kind: ConfigMap metadata: name: prometheus-config data: prometheus.yml: | global: scrape_interval: 30s scrape_timeout: 30s scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] - job_name: 'kubernetes-cluster' scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - api_servers: - 'https://kubernetes.default.svc' in_cluster: true role: apiserver - job_name: 'kubernetes-nodes' scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.