集群
公有云托管K8s服务百花齐放，企业如何统一纳管、便捷管理？
Rancher 发表了文章 • 1 个评论 • 1692 次浏览 • 2017-12-04 12:55
正在美国拉斯维加斯举行的AWS re:Invent 2017大会上，亚马逊新发布的一系列计算及存储相关的功能中，最轰动容器领域，无非是AWS Fargate——一种无需管理服务器即可运行容器的服务，以及EKS（Elastic Container Service ...查看全部
正在美国拉斯维加斯举行的AWS re:Invent 2017大会上，亚马逊新发布的一系列计算及存储相关的功能中，最轰动容器领域，无非是AWS Fargate——一种无需管理服务器即可运行容器的服务，以及EKS（Elastic Container Service for Kubernetes），一个完全托管的Kubernetes服务。
EKS的发布，意味着国际范围内三大最主要的云服务商——AWS、Azure和GCP，已全部提供托管的Kubernetes服务。这对于Kubernetes用户而言无疑是个好消息。尽管用户可以选择自行创建自己的Kubernetes集群，而像Rancher Labs同一时期发布的Rancher Kubernetes Engine（RKE）这样的新工具亦使Kubernetes的创建变得更加简单，但是云管理的Kubernetes安装应该是大多数Kubernetes用户的最佳选择。
Rancher在AWS re:Invent现场展台与技术爱好者demo交流
在Rancher Labs，我们希望Kubernetes有朝一日成为所有云服务商支持的标准化的基础架构，且一直在为了实现这个愿景而努力。EKS的发布，意味着这个愿景正在成为现实。我们亦对可以同时导入和纳管任何类型、来自任何云提供商的Kubernetes集群的Rancher 2.0的前景感到兴奋。
Rancher 2.0现已推出技术预览版，计划于2018年初正式发布，Rancher 2.0包含以下三个主要组件：
如上所有功能都可以在Rancher 2.0技术预览版1.0和RKE中找到。秉承Rancher一贯100%开源的风格，你可以直接从GitHub上下载体验RKE
我们也将持续发布更多技术文章，让您更深入了解和学习使用RKE，敬请保持关注。
原文来源：Rancher Labs
EKS的发布，意味着国际范围内三大最主要的云服务商——AWS、Azure和GCP，已全部提供托管的Kubernetes服务。这对于Kubernetes用户而言无疑是个好消息。尽管用户可以选择自行创建自己的Kubernetes集群，而像Rancher Labs同一时期发布的Rancher Kubernetes Engine（RKE）这样的新工具亦使Kubernetes的创建变得更加简单，但是云管理的Kubernetes安装应该是大多数Kubernetes用户的最佳选择。
Rancher在AWS re:Invent现场展台与技术爱好者demo交流
在Rancher Labs，我们希望Kubernetes有朝一日成为所有云服务商支持的标准化的基础架构，且一直在为了实现这个愿景而努力。EKS的发布，意味着这个愿景正在成为现实。我们亦对可以同时导入和纳管任何类型、来自任何云提供商的Kubernetes集群的Rancher 2.0的前景感到兴奋。
Rancher 2.0现已推出技术预览版，计划于2018年初正式发布，Rancher 2.0包含以下三个主要组件：
- RKE。RKE是Rancher自主研发的轻量级Kubernetes安装程序和发行版，它可以在vSphere和裸机服务器以及尚未提供托管Kubernetes服务的公有云上安装Kubernetes。RKE秉承了Rancher产品一贯易于上手、操作简单、体验友好的特性，能为用户带来极致简单易用、且闪电般快速的Kubernetes安装部署体验。
- Kubernetes集群管理。使用Rancher 2.0，用户现在可以配置由RKE、EKS，Google容器引擎（GKE）、Azure容器服务（AKS）创建的Kubernetes集群，亦可导入纳管任何其他Kubernetes集群。IT管理员可以设置与AD / LDAP集成的集中用户身份验证。Rancher还提供集中的基于角色的访问控制（RBAC）、集群容量管理和成本管理。
- 应用程序管理。Rancher在Kubernetes之上提供了一个易于使用的用户界面，并集成了很多云原生生态系统技术，如CI / CD、集中监控和日志等。
如上所有功能都可以在Rancher 2.0技术预览版1.0和RKE中找到。秉承Rancher一贯100%开源的风格，你可以直接从GitHub上下载体验RKE
我们也将持续发布更多技术文章，让您更深入了解和学习使用RKE，敬请保持关注。
原文来源：Rancher Labs
如何配置Kubernetes以实现最大程度的可扩展性
Rancher 发表了文章 • 1 个评论 • 1606 次浏览 • 2017-10-31 17:59
Kubernetes的设计初衷是要解决管理大规模容器化环境时的困难。不过，这并不意味着Kubernetes在任何的环境下都可以进行扩展。有一些方法可以让用户最大限度地发挥Kubernetes的扩展能力，而在扩展Kubernetes时，有一些重要事项和限制需要注 ...查看全部
Kubernetes的设计初衷是要解决管理大规模容器化环境时的困难。不过，这并不意味着Kubernetes在任何的环境下都可以进行扩展。有一些方法可以让用户最大限度地发挥Kubernetes的扩展能力，而在扩展Kubernetes时，有一些重要事项和限制需要注意，本文中我将对这些内容进行说明。
规模和性能
扩展Kubernetes集群，首先要注意的就是规模和性能之间的平衡。比如，Kubernetes 1.6可被用于多达5000个节点的集群。不过5000个节点并不是硬性限制的最大值，它只是一个推荐的节点最大值。在实际使用中，节点数可以远超过5000个，只是这样会导致性能下降罢了。
这个问题具体来说是这样的：Kubernetes有两个服务层级的目标，一个是在一秒内返回99%的API调用。另一个是在5秒内启动99%的pods。尽管这些目标并不是完整的一套性能指标，但它们确实为评估通用集群性能提供了良好的基准。而据Kubernetes所说，超过5000个节点的集群可能无法实现这些服务层级的目标。
所以有一点请大家注意，在有些时候，为了发挥Kubernetes的扩展性，你有可能不得不牺牲一部分的性能，这些牺牲对你来说既可能是值得的，也可能是不值得的，而这取决于你具体的部署场景。
配额（quotas）
在建立非常大规模的Kubernetes集群时，你可能会遇到的一个主要问题就是配额问题。对于基于云的节点尤为如此，因为云服务提供商通常情况下会设置配额限制。
这个问题之所以如此重要，是因为部署大规模的Kubernetes集群实际上是一个看似简单的过程。config-default.sh文件有NUM_NODES的设置。表面上，你可以通过加大与此设置相关联的值来构建大规模集群。虽然这在某些情况下可行，但最终也可能会遭遇到配额问题。因此，在你打算扩展集群之前，很有必要就现有的任何配额先和云供应商进行沟通。云供应商不仅可以让你了解现有配额的情况，而且至少一部分云供应商会同意用户增加配额限制的请求。
当你在评估这些限制的时候，需要注意，尽管配额限制会直接限制你创建Kubernetes集群的数量，然而集群大小的限制更多是出自与Kubernetes间接相关的配额。例如，提供商可能会限制允许你使用的IP地址数量，或者限制你创建的虚拟机实例数量。而好消息是，主要的几个云服务商已经有多次和Kubernetes打交道的经验，应该能够帮助你解决这些问题。
主节点
除了上述的限制外，还需要考虑的一个问题是集群大小对所需的主节点大小和数量的影响。这些取决于Kubernetes的实现方式，不过要记住的一点是，集群越大，所需的主节点数量也越多，而那些主节点的功能需求也就越高。
如果你正在从头构建新的Kubernetes集群，这可能是一个无关的问题，毕竟确定需要的主节点数量是集群规划过程中的正常阶段。可是如果你打算扩展现有Kubernetes集群，那么你更需要去多加考虑主节点的需求，因为在集群启动时主节点的大小就已经设置好了，而且不能够动态调整。
扩展附加组件（scaling add-ons）
另一件需要我们注意的是，Kubernetes定义了附加组件容器的资源限制。这些资源限制可确保附加组件不会消耗过多的CPU和内存资源。
这些有关限制的问题是，它们是基于相对较小的集群进行定义的。如果你在大规模集群中运行某些附加组件，它们可能会需要超额使用更多的资源。这是因为附加组件必须服务更多的节点，也因此需要额外的资源。如果开始出现与组件相关限制的问题，那么你就会看到附加组件一个一个地被kill掉。
总结
Kubernetes集群可以大规模扩展，但可能会遇到与配额和性能相关的问题。因此，在向Kubernetes集群添加大量新节点之前，请一定要仔细考虑横向扩展所出现的各种需求。
原文来源：Rancher Labs
规模和性能
扩展Kubernetes集群，首先要注意的就是规模和性能之间的平衡。比如，Kubernetes 1.6可被用于多达5000个节点的集群。不过5000个节点并不是硬性限制的最大值，它只是一个推荐的节点最大值。在实际使用中，节点数可以远超过5000个，只是这样会导致性能下降罢了。
这个问题具体来说是这样的：Kubernetes有两个服务层级的目标，一个是在一秒内返回99%的API调用。另一个是在5秒内启动99%的pods。尽管这些目标并不是完整的一套性能指标，但它们确实为评估通用集群性能提供了良好的基准。而据Kubernetes所说，超过5000个节点的集群可能无法实现这些服务层级的目标。
所以有一点请大家注意，在有些时候，为了发挥Kubernetes的扩展性，你有可能不得不牺牲一部分的性能，这些牺牲对你来说既可能是值得的，也可能是不值得的，而这取决于你具体的部署场景。
配额（quotas）
在建立非常大规模的Kubernetes集群时，你可能会遇到的一个主要问题就是配额问题。对于基于云的节点尤为如此，因为云服务提供商通常情况下会设置配额限制。
这个问题之所以如此重要，是因为部署大规模的Kubernetes集群实际上是一个看似简单的过程。config-default.sh文件有NUM_NODES的设置。表面上，你可以通过加大与此设置相关联的值来构建大规模集群。虽然这在某些情况下可行，但最终也可能会遭遇到配额问题。因此，在你打算扩展集群之前，很有必要就现有的任何配额先和云供应商进行沟通。云供应商不仅可以让你了解现有配额的情况，而且至少一部分云供应商会同意用户增加配额限制的请求。
当你在评估这些限制的时候，需要注意，尽管配额限制会直接限制你创建Kubernetes集群的数量，然而集群大小的限制更多是出自与Kubernetes间接相关的配额。例如，提供商可能会限制允许你使用的IP地址数量，或者限制你创建的虚拟机实例数量。而好消息是，主要的几个云服务商已经有多次和Kubernetes打交道的经验，应该能够帮助你解决这些问题。
主节点
除了上述的限制外，还需要考虑的一个问题是集群大小对所需的主节点大小和数量的影响。这些取决于Kubernetes的实现方式，不过要记住的一点是，集群越大，所需的主节点数量也越多，而那些主节点的功能需求也就越高。
如果你正在从头构建新的Kubernetes集群，这可能是一个无关的问题，毕竟确定需要的主节点数量是集群规划过程中的正常阶段。可是如果你打算扩展现有Kubernetes集群，那么你更需要去多加考虑主节点的需求，因为在集群启动时主节点的大小就已经设置好了，而且不能够动态调整。
扩展附加组件（scaling add-ons）
另一件需要我们注意的是，Kubernetes定义了附加组件容器的资源限制。这些资源限制可确保附加组件不会消耗过多的CPU和内存资源。
这些有关限制的问题是，它们是基于相对较小的集群进行定义的。如果你在大规模集群中运行某些附加组件，它们可能会需要超额使用更多的资源。这是因为附加组件必须服务更多的节点，也因此需要额外的资源。如果开始出现与组件相关限制的问题，那么你就会看到附加组件一个一个地被kill掉。
总结
Kubernetes集群可以大规模扩展，但可能会遇到与配额和性能相关的问题。因此，在向Kubernetes集群添加大量新节点之前，请一定要仔细考虑横向扩展所出现的各种需求。
原文来源：Rancher Labs
Docker拥抱k8s早有预兆，Docker现何去何从？
Rancher 发表了文章 • 1 个评论 • 1596 次浏览 • 2017-10-20 11:55
导读
本文由Rancher Labs CEO及联合创始人梁胜博士写于前往参加DockerCon之前。从各家容器编排方案均很不成熟的初期，到三足鼎立的编排之战，到如今k8s似已全面胜利，作为整个发展历程的参与者与见证者，回顾这几年容器领 ...查看全部
导读
本文由Rancher Labs CEO及联合创始人梁胜博士写于前往参加DockerCon之前。从各家容器编排方案均很不成熟的初期，到三足鼎立的编排之战，到如今k8s似已全面胜利，作为整个发展历程的参与者与见证者，回顾这几年容器领域发展和Rancher的发展与选择，梁胜博士分享了他的一些看法。
Docker宣布支持Kubetnetes，拥抱昔日对手，而这一点在回溯过去时就早有苗头。纵观Docker在编排领域的发展之路，大概这一决定是历史的必然。这篇文章或许能从另一种视角带你看看这个业界目前最热议的话题。
目前Docker技术得到了广泛应用，在大量需求的催生下，我们创造了Rancher，在过去三年的各届DockerCon上，Rancher都得到了很多来自用户的热情欢迎和积极反响。
DockerCon有它的特别之处——不仅在于它将主要行业玩家全都召集到了一块，更是因为DockerCon是为数不多的、参会者中用户数量远超供应商数量的技术大会。能够一下子遇到这么多用户，无论是参会还是赞助都十分值得。和我们的用户交谈，听取他们的想法，这激励并启发着我们更好地改进Rancher产品。
Docker的技术革新正处于关键期，因此我对于Docker将在今年DockerCon EU公布的内容非常感兴趣。最近我们发布了Rancher 2.0 Tech Preview，该版本中我们把Rancher从基于Docker的产品转变成基于Kubernetes的产品。虽然Docker作为一个应用程序打包和运行的标准取得了极大成功，而Kubernetes在容器基础设施、编排和生态系统方面都已经超过了Docker，这也是我们选择Kubernetes的原因。
容器基础设施
基础设施所涵盖的范围不仅只是打包和运行，它还包括存储、网络、负载均衡和安全。三年前当我们刚开始研发Rancher时，我们认为Docker将会给容器网络和存储定义行业标准插件接口。尽管Docker和其他诸如SocketPlane（后被Docker收购）、Weveworks和ClusterHQ等早期先驱做了许多出色的工作，并且还得到了如思科、EMC和NetApp等行业领导者的大量支持，然而Docker接口，像libnetwork、容器网络模型（CNM）和Docker volume插件还是没能成为可行的标准。我们在Rancher中仍然在CNM和Docker volume插件方面做努力，不过我们遇到了难以逾越的挑战：
在Rancher 1.2（2016年12月发布）中，通过切换到Kubernetes容器网络接口（CNI）和Kubernetes Flexvolume存储框架，我们已经解决了这些问题。因为Rancher2.0是基于Kubernetes的，任何与Kubernetes集成的网络、存储、负载均衡和安全性方案都可以在Rancher上开箱即用。
容器编排
我们为Rancher开发了名为Cattle的容器编排器，来填补在Docker Swarm早期时缺失的一些功能，包括服务发现、DNS、服务升级和负载均衡器。我们希望当Swarm更加完善之后，能够最终替代Cattle。
然而，在2016年3月Rancher 1.0发布时，Swarm还没准备好。那个时候Kubernetes还未成熟，容器编排的未来也不是很明朗。因此我们决定，Rancher 1.0要同时支持多编排器：Cattle、Swarm、Kubernetes和Mesos。这样一来，用户便不会受限于某个特定的容器编排器，且Rancher的用户都十分喜欢这一设计。
2016年6月时，Docker公布了Swarm Mode，我们都很为此而激动。Swarm Mode提供了早期Docker Swarm中缺少的许多功能，并且非常接近于Cattle所做的工作。于是我们很快在Rancher中添加了Swarm Mode的支持。
可是直到2017年初，Swarm Mode都没有得到重视。或许是早期的Swarm Mode实现上存在质量问题，也可能是Kubernetes的发展已经遥遥领先。绝大数Rancher用户都在使用Cattle和Kubernetes。
Rancher 2.0建立在行业标准Kubernetes之上。Cattle不会消失——它将成为一种内置的Rancher体验，我们也会持续改进它。通过2.0，我们提供了简单的基于Kubernetes的Docker和Docker Compose用户体验。任何对Docker有基本了解的人都可以快速上手，等用户熟练掌握之后还能体验到更进阶的原生Kubernetes体验。
容器生态系统
DockerCon Europe汇聚了大量响当当的赞助商，也无疑吸引了越来越多的Docker用户。我一直从DockerHub上寻找最新的用户数据作为Docker增长的基准。在2017年4月的DockerCon Austin上，这个数字是120亿，并且在那之后还在增长。
构成Kubernetes生态系统的公司其实差不多，不过参与模式却完全不同。大多数的生态系统合作伙伴像我们一样，认为Docker是一种成熟的技术，且拥有大量的用户。而Kubernetes生态系统更加活跃，因为在这一生态系统中有很多积极的发展、创新和整合。
Docker将何去何从？
早在2016年的12月份，我就曾注意到Docker之父、Docker公司CTO Solomon Hykes在他的一篇blog中，将Docker的定位放在了和OpenShift（以及Rancher 2.0）同样的层级，这层级是位于Kubernetes之上的。看来从那时起，Docker就已计划构建一个全新的、基于Kubernetes之上的Docker产品了？
在我从DockerCon回来之后，我会再写一篇文章，分享更多我的一些看法与见解。
Rancher at DockerCon
Rancher Labs全新发布的新产品Rancher 2.0，一方面，把Rancher 提供的Kubernetes分发版的用户体验，从原生的Kubernetes UI修改到被全球客户广泛接受的Rancher UI，解决了业界遗留已久的Kubernetes原生UI易用性差的问题。另一方面，在产品中增加了可以纳管其他厂商提供的Kubernetes分发版功能，如Ubuntu Kubernetes、Dell EMC Kubernetes、Google GKE等等，从而具备了同时管理多个Kubernetes集群的能力，这在业界都还是独一无二的特性。
作为DockerCon的金牌赞助商，Rancher的技术人员将在现场G16展位和技术爱好者进行面对面的技术交流，并受大会之邀将进行两场演讲。
我们还会带来更多来自现场的快报，敬请关注！
原文来源：Rancher Labs
本文由Rancher Labs CEO及联合创始人梁胜博士写于前往参加DockerCon之前。从各家容器编排方案均很不成熟的初期，到三足鼎立的编排之战，到如今k8s似已全面胜利，作为整个发展历程的参与者与见证者，回顾这几年容器领域发展和Rancher的发展与选择，梁胜博士分享了他的一些看法。
Docker宣布支持Kubetnetes，拥抱昔日对手，而这一点在回溯过去时就早有苗头。纵观Docker在编排领域的发展之路，大概这一决定是历史的必然。这篇文章或许能从另一种视角带你看看这个业界目前最热议的话题。
目前Docker技术得到了广泛应用，在大量需求的催生下，我们创造了Rancher，在过去三年的各届DockerCon上，Rancher都得到了很多来自用户的热情欢迎和积极反响。
DockerCon有它的特别之处——不仅在于它将主要行业玩家全都召集到了一块，更是因为DockerCon是为数不多的、参会者中用户数量远超供应商数量的技术大会。能够一下子遇到这么多用户，无论是参会还是赞助都十分值得。和我们的用户交谈，听取他们的想法，这激励并启发着我们更好地改进Rancher产品。
Docker的技术革新正处于关键期，因此我对于Docker将在今年DockerCon EU公布的内容非常感兴趣。最近我们发布了Rancher 2.0 Tech Preview，该版本中我们把Rancher从基于Docker的产品转变成基于Kubernetes的产品。虽然Docker作为一个应用程序打包和运行的标准取得了极大成功，而Kubernetes在容器基础设施、编排和生态系统方面都已经超过了Docker，这也是我们选择Kubernetes的原因。
容器基础设施
基础设施所涵盖的范围不仅只是打包和运行，它还包括存储、网络、负载均衡和安全。三年前当我们刚开始研发Rancher时，我们认为Docker将会给容器网络和存储定义行业标准插件接口。尽管Docker和其他诸如SocketPlane（后被Docker收购）、Weveworks和ClusterHQ等早期先驱做了许多出色的工作，并且还得到了如思科、EMC和NetApp等行业领导者的大量支持，然而Docker接口，像libnetwork、容器网络模型（CNM）和Docker volume插件还是没能成为可行的标准。我们在Rancher中仍然在CNM和Docker volume插件方面做努力，不过我们遇到了难以逾越的挑战：
- 我们还没有实现让CNM在Docker的内置网络实现之外工作。比如，我们现在还不能创建一个脱离Swarm Mode的CNM实现。
- 我们没法让Rancher上的Docker volume插件在Docker守护进程下保持可靠性。我记得有一个极具挑战性的issue，#18504，它导致Docker守护进程会不时地锁住。我们暂时还不能解决它，也还没找到解决方案。
在Rancher 1.2（2016年12月发布）中，通过切换到Kubernetes容器网络接口（CNI）和Kubernetes Flexvolume存储框架，我们已经解决了这些问题。因为Rancher2.0是基于Kubernetes的，任何与Kubernetes集成的网络、存储、负载均衡和安全性方案都可以在Rancher上开箱即用。
容器编排
我们为Rancher开发了名为Cattle的容器编排器，来填补在Docker Swarm早期时缺失的一些功能，包括服务发现、DNS、服务升级和负载均衡器。我们希望当Swarm更加完善之后，能够最终替代Cattle。
然而，在2016年3月Rancher 1.0发布时，Swarm还没准备好。那个时候Kubernetes还未成熟，容器编排的未来也不是很明朗。因此我们决定，Rancher 1.0要同时支持多编排器：Cattle、Swarm、Kubernetes和Mesos。这样一来，用户便不会受限于某个特定的容器编排器，且Rancher的用户都十分喜欢这一设计。
2016年6月时，Docker公布了Swarm Mode，我们都很为此而激动。Swarm Mode提供了早期Docker Swarm中缺少的许多功能，并且非常接近于Cattle所做的工作。于是我们很快在Rancher中添加了Swarm Mode的支持。
可是直到2017年初，Swarm Mode都没有得到重视。或许是早期的Swarm Mode实现上存在质量问题，也可能是Kubernetes的发展已经遥遥领先。绝大数Rancher用户都在使用Cattle和Kubernetes。
Rancher 2.0建立在行业标准Kubernetes之上。Cattle不会消失——它将成为一种内置的Rancher体验，我们也会持续改进它。通过2.0，我们提供了简单的基于Kubernetes的Docker和Docker Compose用户体验。任何对Docker有基本了解的人都可以快速上手，等用户熟练掌握之后还能体验到更进阶的原生Kubernetes体验。
容器生态系统
DockerCon Europe汇聚了大量响当当的赞助商，也无疑吸引了越来越多的Docker用户。我一直从DockerHub上寻找最新的用户数据作为Docker增长的基准。在2017年4月的DockerCon Austin上，这个数字是120亿，并且在那之后还在增长。
构成Kubernetes生态系统的公司其实差不多，不过参与模式却完全不同。大多数的生态系统合作伙伴像我们一样，认为Docker是一种成熟的技术，且拥有大量的用户。而Kubernetes生态系统更加活跃，因为在这一生态系统中有很多积极的发展、创新和整合。
Docker将何去何从？
早在2016年的12月份，我就曾注意到Docker之父、Docker公司CTO Solomon Hykes在他的一篇blog中，将Docker的定位放在了和OpenShift（以及Rancher 2.0）同样的层级，这层级是位于Kubernetes之上的。看来从那时起，Docker就已计划构建一个全新的、基于Kubernetes之上的Docker产品了？
在我从DockerCon回来之后，我会再写一篇文章，分享更多我的一些看法与见解。
Rancher at DockerCon
Rancher Labs全新发布的新产品Rancher 2.0，一方面，把Rancher 提供的Kubernetes分发版的用户体验，从原生的Kubernetes UI修改到被全球客户广泛接受的Rancher UI，解决了业界遗留已久的Kubernetes原生UI易用性差的问题。另一方面，在产品中增加了可以纳管其他厂商提供的Kubernetes分发版功能，如Ubuntu Kubernetes、Dell EMC Kubernetes、Google GKE等等，从而具备了同时管理多个Kubernetes集群的能力，这在业界都还是独一无二的特性。
作为DockerCon的金牌赞助商，Rancher的技术人员将在现场G16展位和技术爱好者进行面对面的技术交流，并受大会之邀将进行两场演讲。
我们还会带来更多来自现场的快报，敬请关注！
原文来源：Rancher Labs
Rancher 2.0快速上手指南
Rancher 发表了文章 • 4 个评论 • 2871 次浏览 • 2017-10-10 12:51
大家好，给大家介绍一下，这是帮助大家率先上手尝试Rancher 2.0的神器 @Rancher 2.0快速上手指南
内容导读
准备一台Linux主机启动Rancher服务器，进入Rancher UI如何在R ...查看全部
大家好，给大家介绍一下，这是帮助大家率先上手尝试Rancher 2.0的神器 @Rancher 2.0快速上手指南
内容导读
在Rancher 2.0中，Cattle用户依然可以享受和以前一样的易于使用的用户体验，还可以额外地利用Kubernetes编排引擎的优势，包括其丰富的基础设施插件、增强的RBAC功能和原生生态系统服务。而Kubernetes用户能在同一平台上管理任何Kubernetes集群，轻松地充分利用Kubernetes的强大能力及其迅速壮大的生态系统。通过基于Kubernetes、简单直观的用户体验，Rancher 2.0将加快Kubernetes在企业中的普及。在本指南中，你将会了解如何快速上手Rancher v2.0。本文将涉及以下内容：准备一台64位主机，系统Ubuntu16.04，至少4GB的内存，内核版本3.10+； 在主机上安装兼容的Docker版本，关于如何在服务器上安装Docker，请参考此教程。 启动Rancher Server只需一条命令和几分钟时间，你就可以安装并启动Rancher Server。安装完成后，打开Web浏览器就能访问Rancher UI。#如何启动Rancher Server第一步：在你的主机上执行如下的Docker命令:8080就可以访问Rancher UI，这里的里要填你主机的IP地址。Rancher可以自动部署和管理Kubernetes，UI界面会展示一个Welcome的页面，其中包含两项有关添加主机的选项。
原文来源：Rancher Labs
内容导读
- 准备一台Linux主机
- 启动Rancher服务器，进入Rancher UI
- 如何在Rancher UI下添加一个主机
- 如何导入现有的Kubernetes集群
- 如何在Rancher UI下添加一个容器
- 启动Calalog应用
- 如何使用高级Kubernetes选项
在Rancher 2.0中，Cattle用户依然可以享受和以前一样的易于使用的用户体验，还可以额外地利用Kubernetes编排引擎的优势，包括其丰富的基础设施插件、增强的RBAC功能和原生生态系统服务。而Kubernetes用户能在同一平台上管理任何Kubernetes集群，轻松地充分利用Kubernetes的强大能力及其迅速壮大的生态系统。通过基于Kubernetes、简单直观的用户体验，Rancher 2.0将加快Kubernetes在企业中的普及。在本指南中，你将会了解如何快速上手Rancher v2.0。本文将涉及以下内容：- 准备一台Linux主机
- 启动Rancher服务器，进入Rancher UI
- 在Rancher UI下添加一个主机
- 导入现有的Kubernetes集群
- 在Rancher UI下添加一个容器
- 启动Calalog应用
- 使用高级Kubernetes选项
- Docker v1.12.6
- Docker v1.13.1
- Docker v17.03-2-ce
- Docker v17.06-ce
$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:preview这一步骤需要花费几分钟来完成第二步：在浏览器中输入http://
第三步：选择添加主机的一个选项，然后进入到如下的相关部分：添加主机 – 如果你想要在Rancher中管理主机，请点击此选项。你可以添加一个已有的、安装好了Docker的主机，亦可以添加其他云服务商提供的新主机（后文会有详解）。使用现有的Kubernetes – 如果你希望集群提供者可以在Rancher外部管理主机，请点击此选项。你可以导入已有的Kubernetes（后文会有详解）。添加主机在这里你可以添加来自Rancher v2.0支持的云服务商的主机，也可以添加自定义主机。如果在UI界面没有看到你的云服务商，不要着急，只需选择自定义主机选项即可。如果你想添加自定义的主机，需要注意这些要求：注意：最开始，Rancher会为你创建一个默认的集群和环境。Rancher能够将资源分组到多个集群和环境中。每个集群都是一组物理（或虚拟）的计算资源。每个环境绑定一个集群，并在集群的主机上运行其容器，而你可以将一个集群共享给多个环境。环境是用来定义应用程序、服务和容器的命名空间。环境中的容器可以通过共享的可管理网络相互通信，你可以通过向不同的用户／组分配访问权限来管理环境中的资源。
- 通常，Rancher会自动检测IP地址来注册主机
- 主机代理会启动与服务器的连接，因此你需要确保防火墙或者安全组允许它通过命令能够到达URL。
- 环境中的所有主机必须允许彼此间的流量能够进行跨主机联网。
- Amazon EC2
- Microsoft Azure
- DigitalOcean
- Packet
sudo docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v2.0-alpha2http://:8080/v3/scripts/D5433C26EC51325F9D98:1483142400000:KvILQKwz1N2MpOkOiIvGYKKGdE
第二步：在你的主机上复制、粘贴并运行该命令，就可以把你的主机注册到Rancher上。这一过程需要几分钟完成。第三步：点击“关闭”。在Hosts页面就可以看到主机的状态。导入Kubernetes集群在Rancher v2.0中，你可以导入已有的在外部安装的Kubernetes v1.7以上版本。这种情况下，集群提供商可以在Rancher之外管理你的主机。我们支持像Google Container Engine、Azure Container Service、IBM Bluemix这样的托管服务，你也可以导入你自己的Kubernetes集群。#如何导入Kubernetes集群第一步：复制、粘贴UI界面的kubectl命令，在你的集群中执行它。第二步：点击“关闭”，在Hosts页面，你就可以看到Kubernetes节点的状态。添加容器在你向环境中添加了至少一个主机或集群后，可能会需要几分钟来启动所有的Rancher系统服务。想要验证自己的环境，那么在“默认”菜单中选择“系统”。如果服务正常，将会显示状态为绿色。当确认所有的系统服务均正常启动后，就可以创建你的第一个容器了。#如何添加容器第一步：在Rancher UI菜单，点击“容器”第二步：点击“添加容器”，进入添加容器页面第三步：输入“名称”，比如“first-container”第四步：输入一个Docker Hub上托管的Docker Image第五步：点击“启动”。该步骤需要几分钟来完成。当容器开始启动，就可以在“容器”页面看到它的状态到目前为止你已经添加了主机，并且启动了第一个容器，接下来将介绍Rancher v2.0的新特性。启动Catalog应用Rancher提供了一个catalog应用模板来部署复杂的应用。#如何启动catalog应用第一步：在Rancher UI菜单，点击Apps，进入Application页面第二步：点击Launch from Catalog，显示可用的catalog应用模板第三步：找到你想要启动的模板，点击View Details第四步：完成必要的填写注意：命令中的IP地址必须对应你的
而且必须能够从主机内部访问。
第五步：点击Launch，在Application页面，你会看到Rancher正在为你的新应用创建堆栈。这一过程需要几分钟时间。如果服务正常启动，新堆栈的状态将显示为绿。使用高级Kubernetes选项在Rancher UI界面，你只需一键点击即可进入本地的Kubernetes dashboard。你也可以从web浏览器上执行kubectl。Kubernetes CLI或者kubectl都可以帮助你部署和管理Kubernetes应用。有关更多信息以及下载kubectl，请访问Kubernetes documentation。另外，你可以创建一个Kubernetes配置文件，以便在桌面上使用kubectl。Kubernetes配置文件（即kubeconfig）允许你配置一个或多个集群的访问。#如何使用高级kubernets选项第一步：在Rancher UI菜单，点击Containers。第二步：选择Advanced标签，将出现下列高级选项：注意：docker-compose.yml和rancher-compose.yml文件与生成应用有关。在启动堆栈前点击Preview即可查看它们。
- Launch Dashboard – 在新浏览器窗口中访问本地Kubernetes dashboard
- Launch kubectl – 使用shell从浏览器运行kubectl命令，单击Close返回到Rancher UI界面
- Download kubeconfig – 生成一个kubeconfig文件以便在桌面使用kubectl。将～/.kube/config文件中的代码复制粘贴到新文件中，然后运行kubectl。点击Close返回到Rancher UI界面。
原文来源：Rancher Labs
梁胜博士亲解Rancher 2.0：K8s之上的Rancher魔法
Rancher 发表了文章 • 1 个评论 • 2004 次浏览 • 2017-09-30 10:59
经过数月的努力，我们终于发布了Rancher 2.0 Technology Preview，这对Rancher Labs而言也是历史性的、值得铭记的一刻。
Rancher 1.x容器管理平台一直为市场和用户所喜爱，自2016年3月Ra ...查看全部
经过数月的努力，我们终于发布了Rancher 2.0 Technology Preview，这对Rancher Labs而言也是历史性的、值得铭记的一刻。
Rancher 1.x容器管理平台一直为市场和用户所喜爱，自2016年3月Rancher 1.0发布以来，Rancher server和Rancher agent的下载量达到了6000多万次。全球范围内Rancher的部署节点已超过10000个，付费客户超过100个。几乎每天都有用户和客户告诉我们，Rancher让他们在生产中运行Docker和Kubernetes变得容易。我们深感感谢，是用户们的激励让Rancher软件变得更好。我还要特别感谢我们的客户，感谢他们对Rancher软件的持续发展提供了资金上的支持！
Rancher 1.0中有一个易于使用的容器编排框架，称为Cattle。且Rancher1.0支持所有主流的容器编排框架，包括Swarm、Mesos和Kubernetes。一个容器管理平台，多个编排框架供其选择，这是Rancher用户一直喜欢Rancher的原因之一。
然而，去年Kubernetes的增长远远高于其他编排引擎。Rancher用户希望在Kubernetes之上得到更好的用户体验和更多的功能。因此，我们决定重新设计Rancher 2.0，将过去大受用户欢迎的Rancher用户体验（即Cattle）架构于Kubernetes之上，从而充分利用Kubernetes的强大力量。
在Rancher 2.0中：
我们的Kubernetes之旅
2015年，当我们刚开始在Rancher中纳入对Kubernetes的支持时，那时的Kubernetes用户面临的最大挑战就是如何安装和配置Kubernetes集群。那时候，Kubernetes自己的脚本和工具很难使用，而且不可靠。但在Rancher中，Kubernetes集群的设置只需一键即可完成。更重要的是，Rancher允许您在任何基础架构上设置Kubernetes集群，包括公有云、vSphere集群和裸机服务器。因此，Rancher很快成为启动Kubernetes集群的最受欢迎的方式之一。
在2016年初，市场上已经有许多现成的和第三方的Kubernetes安装程序。我们的问题不再是如何安装和配置Kubernetes，而是如何持续地运行和升级Kubernetes集群。我们在Rancher中构建了很多功能，用户可以很容易地操作和升级Kubernetes集群及其etcd数据库。
到2016年底，我们开始注意到，Kubernetes运营软件的价值正在迅速下降，这一趋势的出现有两个因素。首先，诸如Kubernetes Operations（kops）等开源工具已经成熟，许多机构与企业能够轻松地在AWS上运行Kubernetes。第二，Kubernetes-as-a-Service（Kubernetes即服务）开始受欢迎。例如，Google Cloud客户不再需要配置和操作自己的集群。他们可以依靠Google——Kubernetes技术的发明者，为他们运行Kubernetes。
#KUBERNETES EVERYWHERE
2016年初，Google Kubernetes项目的创始人、后来创立了Kubernetes公司Heptio的Joe Beda，曾跟我谈及他的“Kubernetes Everywhere”的愿景，他希望Kubernetes可以和无处不在的IaaS相抗衡。
2017年，Kubernetes的流行度在持续上升，且这一势头从未放缓。我们有理由相信在不远的未来，所有基础设施供应商都将提供Kubernetes-as-a-Service。那一天到来的时候，Kubernetes将成为通用的基础设施标准。DevOps团队将不再需要自己操作Kubernetes集群。而唯一剩下的挑战将是如何简单而统一地管理和利用各基础设施上的Kubernetes集群。
基于Kubernetes的Rancher2.0平台
Rancher2.0是一个基于Kubernetes的成熟的容器管理平台。下图展示了Rancher拥有的功能。
与Rancher1.0不同，Rancher server2.0包含了一个嵌入式的Kubernetes主机。这意味着一旦你开始使用Rancher，比如执行命令
马上就有一个Kubernetes集群供你启动和执行，无需再为创建Kubernetes做更多的操作。在这之后，每一个添加的主机都会自动安装Kubelet，并成为Kubernetes集群的一部分。
你可以使用相同的嵌入式Kubernetes主机来创建额外的集群。我们已经建立了一个定制的多租户Kubernetes API服务器，它能够最大限度地减少多个Kubernetes集群所需的资源。
我们认为Kubernetes-as-a-service在未来会成为常态，会越来越少使用嵌入式Kubernetes主机。Rancher2.0能够支持导入和管理由云服务商（例如Google容器引擎GKE)）控制的Kubernetes集群，当然还有使用其他工具（如kops）建立的Kubernetes集群。
#对多个集群的单点控制和可视化
IT管理员可以使用嵌入式的Kubernetes主机创建几个Kubernetes集群，或者导入几个现有的Kubernetes集群，然后使用Rancher作为对多个集群的单点控制和管理平台。
我们举一个例子来说明IT管理员是如何在Rancher中使用centralized RBAC和认证功能的。想象一下，如果企业直接使用Google Container Engine（GKE）作为部署容器应用的标准平台，而GKE却要求每个用户都需要有Google账户，这显然不是大多企业的标准做法。通过Rancher，IT管理员可以使用单一的服务账户将GKE集群导入Rancher，然后就能够用企业现有的ActiveDirectory凭证对其他用户进行身份验证。
#全新的UI
很多用户告诉我们，他们非常喜欢Rancher的UI。在2.0版本我们做得更加美观了！我们自己也很喜欢它的设计，并且也希望把它做得更棒。在默认设置下，2.0的UI提供一个简单的容器视图，对容器只有初步了解的人都可以很轻松地开始使用Kubernetes。高级用户他们仍然可以访问Kubectl和Kubernetes dashboard。其次，Rancher应用服务目录Catalog的使用体验进一步优化，通过简单的鼠标点击不仅可以部署应用程序，还可以在部署后轻松地访问和管理应用。Rancher2.0的UI扩展了更多的容器、服务和主机，并且保持了高度响应，如果你喜欢Rancher 1.X的UI，那么你一定会更喜欢2.0。
#未来，还有更多......
我们现在发布的是一个早期的技术预览，我们现在仍有很多未完成的工作，目前还在忙于修复bug并添加诸如HA部署、RBAC和身份认证、集成CI/CD、监控和日志等等这些特性。我们将会持续发布新的版本，敬请关注，也请一如既往地给我们更多反馈与意见，让我们可以做得更好！
原文来源：Rancher Labs
Rancher 1.x容器管理平台一直为市场和用户所喜爱，自2016年3月Rancher 1.0发布以来，Rancher server和Rancher agent的下载量达到了6000多万次。全球范围内Rancher的部署节点已超过10000个，付费客户超过100个。几乎每天都有用户和客户告诉我们，Rancher让他们在生产中运行Docker和Kubernetes变得容易。我们深感感谢，是用户们的激励让Rancher软件变得更好。我还要特别感谢我们的客户，感谢他们对Rancher软件的持续发展提供了资金上的支持！
Rancher 1.0中有一个易于使用的容器编排框架，称为Cattle。且Rancher1.0支持所有主流的容器编排框架，包括Swarm、Mesos和Kubernetes。一个容器管理平台，多个编排框架供其选择，这是Rancher用户一直喜欢Rancher的原因之一。
然而，去年Kubernetes的增长远远高于其他编排引擎。Rancher用户希望在Kubernetes之上得到更好的用户体验和更多的功能。因此，我们决定重新设计Rancher 2.0，将过去大受用户欢迎的Rancher用户体验（即Cattle）架构于Kubernetes之上，从而充分利用Kubernetes的强大力量。
在Rancher 2.0中：
- Cattle用户依然可以享受和以前一样的易于使用的用户体验，还可以额外地利用Kubernetes编排引擎的优势，包括其丰富的基础设施插件、增强的RBAC功能和原生生态系统服务。
- Kubernetes用户可以享受独有的Rancher用户体验和Rancher应用服务目录。
我们的Kubernetes之旅
2015年，当我们刚开始在Rancher中纳入对Kubernetes的支持时，那时的Kubernetes用户面临的最大挑战就是如何安装和配置Kubernetes集群。那时候，Kubernetes自己的脚本和工具很难使用，而且不可靠。但在Rancher中，Kubernetes集群的设置只需一键即可完成。更重要的是，Rancher允许您在任何基础架构上设置Kubernetes集群，包括公有云、vSphere集群和裸机服务器。因此，Rancher很快成为启动Kubernetes集群的最受欢迎的方式之一。
在2016年初，市场上已经有许多现成的和第三方的Kubernetes安装程序。我们的问题不再是如何安装和配置Kubernetes，而是如何持续地运行和升级Kubernetes集群。我们在Rancher中构建了很多功能，用户可以很容易地操作和升级Kubernetes集群及其etcd数据库。
到2016年底，我们开始注意到，Kubernetes运营软件的价值正在迅速下降，这一趋势的出现有两个因素。首先，诸如Kubernetes Operations（kops）等开源工具已经成熟，许多机构与企业能够轻松地在AWS上运行Kubernetes。第二，Kubernetes-as-a-Service（Kubernetes即服务）开始受欢迎。例如，Google Cloud客户不再需要配置和操作自己的集群。他们可以依靠Google——Kubernetes技术的发明者，为他们运行Kubernetes。
#KUBERNETES EVERYWHERE
2016年初，Google Kubernetes项目的创始人、后来创立了Kubernetes公司Heptio的Joe Beda，曾跟我谈及他的“Kubernetes Everywhere”的愿景，他希望Kubernetes可以和无处不在的IaaS相抗衡。
2017年，Kubernetes的流行度在持续上升，且这一势头从未放缓。我们有理由相信在不远的未来，所有基础设施供应商都将提供Kubernetes-as-a-Service。那一天到来的时候，Kubernetes将成为通用的基础设施标准。DevOps团队将不再需要自己操作Kubernetes集群。而唯一剩下的挑战将是如何简单而统一地管理和利用各基础设施上的Kubernetes集群。
基于Kubernetes的Rancher2.0平台
Rancher2.0是一个基于Kubernetes的成熟的容器管理平台。下图展示了Rancher拥有的功能。
与Rancher1.0不同，Rancher server2.0包含了一个嵌入式的Kubernetes主机。这意味着一旦你开始使用Rancher，比如执行命令
docker run -d -p 8080:8080 rancher/server
马上就有一个Kubernetes集群供你启动和执行，无需再为创建Kubernetes做更多的操作。在这之后，每一个添加的主机都会自动安装Kubelet，并成为Kubernetes集群的一部分。
你可以使用相同的嵌入式Kubernetes主机来创建额外的集群。我们已经建立了一个定制的多租户Kubernetes API服务器，它能够最大限度地减少多个Kubernetes集群所需的资源。
我们认为Kubernetes-as-a-service在未来会成为常态，会越来越少使用嵌入式Kubernetes主机。Rancher2.0能够支持导入和管理由云服务商（例如Google容器引擎GKE)）控制的Kubernetes集群，当然还有使用其他工具（如kops）建立的Kubernetes集群。
#对多个集群的单点控制和可视化
IT管理员可以使用嵌入式的Kubernetes主机创建几个Kubernetes集群，或者导入几个现有的Kubernetes集群，然后使用Rancher作为对多个集群的单点控制和管理平台。
我们举一个例子来说明IT管理员是如何在Rancher中使用centralized RBAC和认证功能的。想象一下，如果企业直接使用Google Container Engine（GKE）作为部署容器应用的标准平台，而GKE却要求每个用户都需要有Google账户，这显然不是大多企业的标准做法。通过Rancher，IT管理员可以使用单一的服务账户将GKE集群导入Rancher，然后就能够用企业现有的ActiveDirectory凭证对其他用户进行身份验证。
#全新的UI
很多用户告诉我们，他们非常喜欢Rancher的UI。在2.0版本我们做得更加美观了！我们自己也很喜欢它的设计，并且也希望把它做得更棒。在默认设置下，2.0的UI提供一个简单的容器视图，对容器只有初步了解的人都可以很轻松地开始使用Kubernetes。高级用户他们仍然可以访问Kubectl和Kubernetes dashboard。其次，Rancher应用服务目录Catalog的使用体验进一步优化，通过简单的鼠标点击不仅可以部署应用程序，还可以在部署后轻松地访问和管理应用。Rancher2.0的UI扩展了更多的容器、服务和主机，并且保持了高度响应，如果你喜欢Rancher 1.X的UI，那么你一定会更喜欢2.0。
#未来，还有更多......
我们现在发布的是一个早期的技术预览，我们现在仍有很多未完成的工作，目前还在忙于修复bug并添加诸如HA部署、RBAC和身份认证、集成CI/CD、监控和日志等等这些特性。我们将会持续发布新的版本，敬请关注，也请一如既往地给我们更多反馈与意见，让我们可以做得更好！
原文来源：Rancher Labs
使用容器和Elasticsearch集群对Twitter进行监控
Rancher 发表了文章 • 1 个评论 • 1989 次浏览 • 2017-05-11 08:56
实战经验分享，教你如何使用容器和Elasticsearch集群实现对Twitter上的特定话题（hashtag）与品牌（brand）的监控。
介绍
Elasticsearch是ELK（Elasticsearc ...查看全部
实战经验分享，教你如何使用容器和Elasticsearch集群实现对Twitter上的特定话题（hashtag）与品牌（brand）的监控。
介绍
Elasticsearch是ELK（Elasticsearch/Logstash/Kibana）的基石。在这篇文章中，我们将使用Rancher Catalog来部署stack，并将它用于追踪Twitter上的tag和brand。
追踪Twitter上的hashtag对于衡量基于Twitter的营销活动的影响力是非常有用的。你可以从中提取出诸如您的推文被转发的次数，你的营销活动为你带来了多少位新的关注者等有效信息。
安装ELK stack
#Elasticsearch
若你已经有了一个正在工作中的Elasticsearch集群，现在只需要调整一些集群中的配置即可。我们将使用JSON创建一个索引模板，来调整相关配置。
现在我们给我们的索引模板起个名字，并且推动其配置。
Elasticsearch集群的配置就到这里。现在让我们接着往下走。#LogstashLogstash让你能够分析所获得的数据并且将数据传输至你的Elasticsearch集群中。它原生支持很多数据源（如Twitter APIs、collectd、Apache日志等）。在处理你的数据时，Logstash可以帮助你解压或格式化你数据中的正确部分。这样，你就不必推送一些不必要的或者（更糟的）错误数据，这些脏数据会使你的Kibana dashboard与实际情况不相符。在我们开始之前，需要创建Twitter应用密钥需要特别关注以下内容：
最后，选择“elasticsearch-clients as the Elasticsearch stack/service”，点击“launch”按钮即可！
接下来的事情Rancher将会帮你做完，包括部署一个完全配置好的Logstash。如果一切顺利，在几分钟之内，你应该能看到数据已经被加入到了你的Elasticsearch主页中。你可以在http://[你的ElasticSearch主机地址]/#kopt 中查看。
#KibanaKibana能帮助你根据Elasticsearch集群中的数据创建一个强大的dashboard。要部署Kibana，你只需要做两件事情：选择正确的Rancher Catalog版本，然后将它连接到elasticsearch-clients容器中。
这样，一个配置正确的Kibana已经准备好被使用了！后续我们还将会对它进行一些配置。现在，整个ELK栈就部署好了。虽然Elasticsearch和Logstash已经部署好了，我们还是需要对Kibana进行一些操作。在这个例子中，我们只需要在Kibana中导入一个JSON仪表盘即可。
剩下的就是在Kibana中创建一个适当的索引设置了。
前往“Indices”页面，然后点击“New”按钮。你应该能看到被创建好的索引和被选择了的@timestamp（时间戳）。
到目前位置，你已经有了一个帮助你监控Twitter上的hashtag和brand的Kibana dashboard。要加载被导入的dashboard，你只需要在这里点击它的名字即可。
几分钟后，重新查看dashboard，你会看到类似下图的界面：
至此，你就能成功监测Twitter上的tag和brand的情况啦！
原文来源：Rancher Labs
介绍
Elasticsearch是ELK（Elasticsearch/Logstash/Kibana）的基石。在这篇文章中，我们将使用Rancher Catalog来部署stack，并将它用于追踪Twitter上的tag和brand。
追踪Twitter上的hashtag对于衡量基于Twitter的营销活动的影响力是非常有用的。你可以从中提取出诸如您的推文被转发的次数，你的营销活动为你带来了多少位新的关注者等有效信息。
安装ELK stack
#Elasticsearch
若你已经有了一个正在工作中的Elasticsearch集群，现在只需要调整一些集群中的配置即可。我们将使用JSON创建一个索引模板，来调整相关配置。
- 在GitHub上获取JSON模板
- 在你的浏览器中输入http://[你的kopf在rancher主机上的路径]
- 在kopf中，点击“more”，然后在下拉菜单中选择“index templates”
现在我们给我们的索引模板起个名字，并且推动其配置。- 使用twitter_elk_example作为模板名称
- 粘贴你之前下载的JSON文件中的内容
- 点击“save”按钮
Elasticsearch集群的配置就到这里。现在让我们接着往下走。#LogstashLogstash让你能够分析所获得的数据并且将数据传输至你的Elasticsearch集群中。它原生支持很多数据源（如Twitter APIs、collectd、Apache日志等）。在处理你的数据时，Logstash可以帮助你解压或格式化你数据中的正确部分。这样，你就不必推送一些不必要的或者（更糟的）错误数据，这些脏数据会使你的Kibana dashboard与实际情况不相符。在我们开始之前，需要创建Twitter应用密钥需要特别关注以下内容：- Consumer Key
- Consumer Secret
- Access Token
- Access Token Secret
现在跳转到目录页并选择Logstash（最好是最新的版本）。你需要在“Logstash inputs*”输入框中加入以下内容（用你自己的APIs认证密钥替换CAP文本）：注意：确保你所有的Rancher主机的时钟均已同步，否则你将无法正确地使用Twitter证书。
twitter { consumer_key => "INSERT YOUR CONSUMER KEY" consumer_secret => "INSERT YOUR CONSUMER SECRET" oauth_token => "INSERT YOUR ACCESS TOKEN" oauth_token_secret => "INSERT YOUR ACCESS TOKEN SECRET" keywords => [ "docker", "rancher_labs", "rancher", "kubernetes" ] full_tweet => true }在“Logstash output*”这个输入框中，你需要加入以下内容注意：在关键字数组中，不要使用“@”或者“#”符号，否则Logstash将运行失败并报“unauthorized message”错误。
output { elasticsearch { host => "elasticsearch:9200" protocol => "http" cluster_name => "NAME OF YOUR ELASTICSEARCH CLUSTER" index => "twitter_elk_example" document_type => "tweets" }最后，选择“elasticsearch-clients as the Elasticsearch stack/service”，点击“launch”按钮即可！接下来的事情Rancher将会帮你做完，包括部署一个完全配置好的Logstash。如果一切顺利，在几分钟之内，你应该能看到数据已经被加入到了你的Elasticsearch主页中。你可以在http://[你的ElasticSearch主机地址]/#kopt 中查看。#KibanaKibana能帮助你根据Elasticsearch集群中的数据创建一个强大的dashboard。要部署Kibana，你只需要做两件事情：选择正确的Rancher Catalog版本，然后将它连接到elasticsearch-clients容器中。这样，一个配置正确的Kibana已经准备好被使用了！后续我们还将会对它进行一些配置。现在，整个ELK栈就部署好了。虽然Elasticsearch和Logstash已经部署好了，我们还是需要对Kibana进行一些操作。在这个例子中，我们只需要在Kibana中导入一个JSON仪表盘即可。- 点击这里获取JSON文件
- 进入Settings –> Object，然后点击“import”，接下来选择刚刚下载好的文件。你应该会看到类似于下图的界面。
剩下的就是在Kibana中创建一个适当的索引设置了。
前往“Indices”页面，然后点击“New”按钮。你应该能看到被创建好的索引和被选择了的@timestamp（时间戳）。
到目前位置，你已经有了一个帮助你监控Twitter上的hashtag和brand的Kibana dashboard。要加载被导入的dashboard，你只需要在这里点击它的名字即可。
几分钟后，重新查看dashboard，你会看到类似下图的界面：
至此，你就能成功监测Twitter上的tag和brand的情况啦！
原文来源：Rancher Labs
德国KubeCon直击：如何轻松且安心地将k8s用于生产？
Rancher 发表了文章 • 1 个评论 • 2123 次浏览 • 2017-03-31 10:17
想要在生产环境中成功部署容器，你需要的不仅仅是容器编排。
2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubernetes、Linkerd、OpenTracing等多个开 ...查看全部
想要在生产环境中成功部署容器，你需要的不仅仅是容器编排。
2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubernetes、Linkerd、OpenTracing等多个开源云原生社区的领先技术专家正汇聚一堂，以进一步推动云原生计算的教育和发展。
Rancher Labs同样亮相此届KubeCon，为大家带来了Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
Kubernetes是一个优秀的容器编排工具，但真正配置和部署Kubernetes往往很困难，企业用户想在生产环境中使用Kubernetes更是顾虑重重。乘着KubeCon的东风，一起来看看Rancher是如何让Kubernetes更易用、如何完美支持企业级生产环境的。
Kubernetes：优秀的容器编排工具
Kubernetes是用于部署和管理容器化应用程序的开源容器编排器。凭借在Google上运行生产环境工作负载15年的经验，它提供了容器固有的优势，同时使DevOps团队能够根据自己的需求，构建定制化的容器就绪环境。
Kubernetes架构由松耦合的组件与丰富的API组成，这使得Kubernetes非常适合运行高度分布式的应用程序架构，包括微服务、单片Web应用程序和批处理应用程序。在生产中，这些应用程序通常跨多个容器和多个服务器主机，这些服务器主机相互连接以形成集群。
Kubernetes提供了为分布式应用程序工作负载部署容器所需的编排和管理功能。它使用户能够构建多容器应用程序服务，并在集群中调度容器以及管理容器的运行状况。由于这些操作任务是自动化的，所以DevOps团队通过容器可以执行许多与其他应用程序平台相同的操作。
配置和部署Kubernetes？可能很困难
人们普遍认为Kubernetes是成功地大规模部署容器的关键。如果您在云端或合理的同质基础架构中运行单个Kubernetes集群，则可能是这样。然而，许多机构具有不同的应用组合和用户需求，因此他们的需求就更广泛和多样化。在这些情况下，设置和配置Kubernetes以及自动化基础架构部署将带来以下几个挑战：
Rancher，让Kubernetes无比简单
通过赋予开发、测试和生产环境中的代码以可移植性，容器使软件开发变得格外容易。一旦投入生产，许多组织都希望Kubernetes能够管理和扩展容器化的应用程序和服务。但是，设计、定制和运行Kubernetes，以及将编工具器与不断变化的技术组合在一起，带来的，是陡峭的学习曲线。
Rancher容器管理平台使您可以轻松管理运行容器需要的一切。 您不再必须需要整合和维护一套复杂的开源技术所需的技术技能。 Rancher不是Docker编排工具，它是最完整的容器管理平台。
Ranche能为用户提供在各类基础设施上部署和使用Kubernetes 所需要的一切，包括：
企业级Kubernetes发行版Rancher为用户提供了已通过认证、提供企业级技术支持的Kubernetes发行版。通过Rancher，您可以轻松利用久经考验且稳定的Kubernetes功能。只需几分钟，在极易于使用的Rancher界面上，你就能轻松启动Kubernetes了。为了确保在所有公共和私有云环境中保持一致的体验，您可以利用Rancher来管理底层容器、执行命令和获取日志。您还可以用它来保持使用最新的Kubernetes稳定版本，并及时采用上游错误修复。您不用再被旧的、过时的和专有的技术所困扰。Kubernetes Dashboard可以通过Rancher自动启动，并可用于每个Kubernetes环境。Helm也能自动用于每个Kubernetes环境，并且每一个开箱即用的kubectl shell控制台中都包含一个方便的Helm客户端。企业级生产环境？完美支持！Rancher既让用户可以轻松使用开源的Kubernetes，还同时遵守企业安全和可用性标准。通过安全的多租户环境，隔离集群内的资源并确保控制分离，Rancher让企业可以安心使用Kubernetes。私有registry可以用Kubernetes配置并且紧密耦合到基础集群配置。（例如Google Cloud Platform registry只能在GCP集群中使用。）诸如基于角色的访问控制、与LDAP和活动目录的集成、详细的审计日志、高可用性、计量（通过Heapster）和加密网络等功能都可以开箱即用。企业级的24x7x365支持让您可以放心地在任意规模的生产环境中部署Kubernetes和容器。多集群，多云部署？没问题！Rancher可以运行多节点、多云集群，甚至部署全状态应用程序。通过容器，Kubernetes集群可以跨越多个资源池和云。而使用Docker machine driver或手动的agent注册添加的所有主机，都将自动添加到Kubernetes集群。用户可以使用可插拔的基础架构服务创建多个Kubernetes集群，这些服务可以以Rancher环境的形式轻松且重复地部署。通过基于角色的访问控制（RBAC），用户可以对这些环境中的每个访问权限进行管理。Rancher用户界面简单易用，并对所有主机以及运行在这些主机中的容器及其总体状态提供了完全可视性。但是，你需要的不仅仅是容器编排...Kubernetes正在成长为一个稳定的平台。它的应用情况及生态系统的发展都很快。然而，同样不应忽视的是，容器应用的最终目标是为开发人员创建应用程序以及更轻松高效地对它们进行管理。应用程序部署和管理不仅仅需要编排。例如，你还需要诸如负载均衡器和DNS的服务来运行应用程序。可定制的基础架构服务Rancher容器管理平台可以轻松地定义和保存各种网络组合、存储和负载平衡器驱动程序。这使得用户在任何基础设施上进行重复且一致的部署，无论是在公有云、私有云、虚拟化集群、还是物理机服务器上。与Rancher集成的服务包括：
如果您选择在原生的Kubernetes上部署ingress controller，则每个提供商都将拥有自己的代码库和一组配置值。Rancher负载均衡器可以进行高级定制，以满足用户的各类需求。Rancher的ingress controller让您可以灵活选择您想要的负载均衡器（包括HAproxy、Traefik和nginx），而配置界面保持不变。Rancher还提供扩展负载均衡器、自定义负载均衡器源端口以及在特定的主机集上调度负载均衡器的功能。
完整的容器管理平台
您现在可能已经有一个比较清晰的概念了，但要知道，Rancher不单纯是容器编排器。它是一个完整的容器管理平台，其中包括管理生产中的容器所需的一切。您可以通过使用Rancher在跨云平台上一键部署和运行多个集群，或从Rancher集成和支持的容器编排器发行版中进行自主选择，包括Kubernet、Mesos、Docker Swarm和Windows。可插拔基础架构服务为基础设施提供商的可移植性提供了基础。
无论是在单个本地集群上运行容器，抑或在Amazon AWS和其他服务提供商上运行的多个集群，Rancher正迅速成为千千万万个Kubernetes用户的首选容器管理平台。
开始使用容器、Kubernetes和Rancher吧！
3月29日-30日正在柏林举办的CloudNativeCon+KubeCon Europe 2017上，Rancher Labs在S17号展位，为您演示Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
原文来源：Rancher Labs
2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubernetes、Linkerd、OpenTracing等多个开源云原生社区的领先技术专家正汇聚一堂，以进一步推动云原生计算的教育和发展。
Rancher Labs同样亮相此届KubeCon，为大家带来了Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
Kubernetes是一个优秀的容器编排工具，但真正配置和部署Kubernetes往往很困难，企业用户想在生产环境中使用Kubernetes更是顾虑重重。乘着KubeCon的东风，一起来看看Rancher是如何让Kubernetes更易用、如何完美支持企业级生产环境的。
Kubernetes：优秀的容器编排工具
Kubernetes是用于部署和管理容器化应用程序的开源容器编排器。凭借在Google上运行生产环境工作负载15年的经验，它提供了容器固有的优势，同时使DevOps团队能够根据自己的需求，构建定制化的容器就绪环境。
Kubernetes架构由松耦合的组件与丰富的API组成，这使得Kubernetes非常适合运行高度分布式的应用程序架构，包括微服务、单片Web应用程序和批处理应用程序。在生产中，这些应用程序通常跨多个容器和多个服务器主机，这些服务器主机相互连接以形成集群。
Kubernetes提供了为分布式应用程序工作负载部署容器所需的编排和管理功能。它使用户能够构建多容器应用程序服务，并在集群中调度容器以及管理容器的运行状况。由于这些操作任务是自动化的，所以DevOps团队通过容器可以执行许多与其他应用程序平台相同的操作。
配置和部署Kubernetes？可能很困难
人们普遍认为Kubernetes是成功地大规模部署容器的关键。如果您在云端或合理的同质基础架构中运行单个Kubernetes集群，则可能是这样。然而，许多机构具有不同的应用组合和用户需求，因此他们的需求就更广泛和多样化。在这些情况下，设置和配置Kubernetes以及自动化基础架构部署将带来以下几个挑战：
- 创建根据DevOps团队的需求定制的Kubernetes环境
- 自动部署多个Kubernetes集群
- 管理Kubernetes群集的健康（例如检测和解决etcd节点的故障）
- 自动升级Kubernetes集群
- 在本地和/或不同云提供商部署多个集群
- 确保能满足企业级的需求，包括提供24×7企业级技术支持
- 自定义然后重复部署基础设施和其他服务（例如存储、网络、DNS、负载平衡器）的多重组合
- 部署和管理Kubernetes附件的升级，如Dashboard、Helm和Heapster
Rancher，让Kubernetes无比简单
通过赋予开发、测试和生产环境中的代码以可移植性，容器使软件开发变得格外容易。一旦投入生产，许多组织都希望Kubernetes能够管理和扩展容器化的应用程序和服务。但是，设计、定制和运行Kubernetes，以及将编工具器与不断变化的技术组合在一起，带来的，是陡峭的学习曲线。
Rancher容器管理平台使您可以轻松管理运行容器需要的一切。 您不再必须需要整合和维护一套复杂的开源技术所需的技术技能。 Rancher不是Docker编排工具，它是最完整的容器管理平台。
Ranche能为用户提供在各类基础设施上部署和使用Kubernetes 所需要的一切，包括：
- 已通过认证、提供企业级技术支持的Kubernetes发行版，具有简化的配置选项
- 包括负载平衡器、跨主机网络、存储驱动程序和安全凭证管理等在内的基础设施服务
- Kubernetes集群的自动部署和升级
- 多集群和多云支持
- 企业级功能，如基于角色的访问控制和24×7支持
企业级Kubernetes发行版Rancher为用户提供了已通过认证、提供企业级技术支持的Kubernetes发行版。通过Rancher，您可以轻松利用久经考验且稳定的Kubernetes功能。只需几分钟，在极易于使用的Rancher界面上，你就能轻松启动Kubernetes了。为了确保在所有公共和私有云环境中保持一致的体验，您可以利用Rancher来管理底层容器、执行命令和获取日志。您还可以用它来保持使用最新的Kubernetes稳定版本，并及时采用上游错误修复。您不用再被旧的、过时的和专有的技术所困扰。Kubernetes Dashboard可以通过Rancher自动启动，并可用于每个Kubernetes环境。Helm也能自动用于每个Kubernetes环境，并且每一个开箱即用的kubectl shell控制台中都包含一个方便的Helm客户端。企业级生产环境？完美支持！Rancher既让用户可以轻松使用开源的Kubernetes，还同时遵守企业安全和可用性标准。通过安全的多租户环境，隔离集群内的资源并确保控制分离，Rancher让企业可以安心使用Kubernetes。私有registry可以用Kubernetes配置并且紧密耦合到基础集群配置。（例如Google Cloud Platform registry只能在GCP集群中使用。）诸如基于角色的访问控制、与LDAP和活动目录的集成、详细的审计日志、高可用性、计量（通过Heapster）和加密网络等功能都可以开箱即用。企业级的24x7x365支持让您可以放心地在任意规模的生产环境中部署Kubernetes和容器。多集群，多云部署？没问题！Rancher可以运行多节点、多云集群，甚至部署全状态应用程序。通过容器，Kubernetes集群可以跨越多个资源池和云。而使用Docker machine driver或手动的agent注册添加的所有主机，都将自动添加到Kubernetes集群。用户可以使用可插拔的基础架构服务创建多个Kubernetes集群，这些服务可以以Rancher环境的形式轻松且重复地部署。通过基于角色的访问控制（RBAC），用户可以对这些环境中的每个访问权限进行管理。Rancher用户界面简单易用，并对所有主机以及运行在这些主机中的容器及其总体状态提供了完全可视性。但是，你需要的不仅仅是容器编排...Kubernetes正在成长为一个稳定的平台。它的应用情况及生态系统的发展都很快。然而，同样不应忽视的是，容器应用的最终目标是为开发人员创建应用程序以及更轻松高效地对它们进行管理。应用程序部署和管理不仅仅需要编排。例如，你还需要诸如负载均衡器和DNS的服务来运行应用程序。可定制的基础架构服务Rancher容器管理平台可以轻松地定义和保存各种网络组合、存储和负载平衡器驱动程序。这使得用户在任何基础设施上进行重复且一致的部署，无论是在公有云、私有云、虚拟化集群、还是物理机服务器上。与Rancher集成的服务包括：- 具有多个负载均衡器的ingress controller（HAproxy、traefik等）
- IPSEC和VXLAN所需的跨主机网络驱动程序
- 存储驱动程序
- 证书和安全凭证管理
- 私有registry的凭证管理
- 代替 SkyDNS 的DNS服务
- 高度可定制的负载均衡器
如果您选择在原生的Kubernetes上部署ingress controller，则每个提供商都将拥有自己的代码库和一组配置值。Rancher负载均衡器可以进行高级定制，以满足用户的各类需求。Rancher的ingress controller让您可以灵活选择您想要的负载均衡器（包括HAproxy、Traefik和nginx），而配置界面保持不变。Rancher还提供扩展负载均衡器、自定义负载均衡器源端口以及在特定的主机集上调度负载均衡器的功能。
完整的容器管理平台
您现在可能已经有一个比较清晰的概念了，但要知道，Rancher不单纯是容器编排器。它是一个完整的容器管理平台，其中包括管理生产中的容器所需的一切。您可以通过使用Rancher在跨云平台上一键部署和运行多个集群，或从Rancher集成和支持的容器编排器发行版中进行自主选择，包括Kubernet、Mesos、Docker Swarm和Windows。可插拔基础架构服务为基础设施提供商的可移植性提供了基础。
无论是在单个本地集群上运行容器，抑或在Amazon AWS和其他服务提供商上运行的多个集群，Rancher正迅速成为千千万万个Kubernetes用户的首选容器管理平台。
开始使用容器、Kubernetes和Rancher吧！
3月29日-30日正在柏林举办的CloudNativeCon+KubeCon Europe 2017上，Rancher Labs在S17号展位，为您演示Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
原文来源：Rancher Labs
Rancher平台部署Percona XtraDB Cluster数据库集群
Rancher 发表了文章 • 1 个评论 • 2652 次浏览 • 2016-12-26 10:15
各种MySQL数据库集群高可用方案
https://bobcares.com/blog/mysql-high-availability-top-7-solutions/
Redundant de ...查看全部
各种MySQL数据库集群高可用方案
https://bobcares.com/blog/mysql-high-availability-top-7-solutions/
PXC技术概要
Percona XtraDB Cluster与MySQL Replication区别在于：
分布式系统的CAP理论：
C：一致性，所有节点的数据一致；
A：可用性，一个或多个节点失效，不影响服务请求；
P：分区容忍性，节点间的连接失效，仍然可以处理请求；
任何一个分布式系统，需要满足这三个中的两个。
MySQLReplication：可用性和分区容忍性；
Percona XtraDBCluster：一致性和可用性。
因此MySQL Replication并不保证数据的一致性，而Percona XtraDB Cluster提供数据一致性。
Percona XtraDBCluster是MySQL高可用性和可扩展性的解决方案。Percona XtraDBCluster提供的特性有：
Percona XtraDBCluster完全兼容MySQL和Percona Server，表现在：
它的集群特点是：
优点如下：
缺点如下：
PXC的传统物理机三节点部署简要说明
那么这样一个MySQL集群方案，在我们传统的物理机环境的安装部署，是否会很复杂呢？熟悉其组件及工作原理之后，安装倒是不特别复杂。我们以CentOS系列为范例，简要看看其安装配置流程：
PXC在Rancher容器管理平台的部署
Percona作为标准的Catalog项目出现在Rancher Server1.1版本之后，如果你使用的是较低的版本，例如v1.0.1，在数据库分类里将只会见到MariaDB Galera Cluster项目。当然你可以在低版本中添加自定义的Catalog，例如
https://github.com/alanpeng/MyRancherCatalog.git
部署好的Percona XtraDB Cluster集群宿主机结构如图所示（除了拉起Percona-XtraDB-Cluster集群之外，还在其前端加入了一个Rancher内置的LoadBalancer）：
将此Catalog项目打开，我们可以看见其docker-compose.yml及rancher-compose.yml文件的内容如下：
Stack/Service结构示意图：
这里的12个容器角色如下：Node节点3个，运行confd服务；ClusterCheck节点3个分别监听集群节点健康状态；Server节点3个，是数据库主服务应用；3个Data作为数据卷共享的提供，是sidekick容器类型。
所有容器列表如下：
数据库连接验证测试：
从前端负载均衡宿主机的IP访问数据库，执行语句show status like 'wsrep%'；返回的结果表明数据库集群节点数为3，同步复制状态正常。
在Rancher平台如何灵活运用Confd+Metadata进行配置管理
以上PXC集群运行于容器之上并被Rancher平台管理，其中的具体实现细节较多，因为我们需要这样的数据库集群满足弹性伸缩的要求，举例来说也就是可以动态的将集群节点数由3个增加至更多，那么必然每个节点的配置文件需要动态的进行更新，要做到这一点，我们可以结合confd与Rancher的metadata元数据服务来实现，当然这里涉及到数据库集群专有的技术，giddyup专有工具的结合也是必不可少的选择。
1. 首先给出整个项目的代码文件供参考
分3个模块：
https://github.com/Flowman/docker-pxc
https://github.com/Flowman/docker-pxc-confd
https://github.com/Flowman/docker-pxc-clustercheck
2. 数据库集群配置工具giddyup
https://github.com/cloudnautique/giddyup
在数据库集群服务的启动脚本
https://github.com/Flowman/docker-pxc/blob/master/start_pxc里我们使用了giddyup工具，其中比较重要的命令有以下项：
获取集群节点成员IP列表，请参照本篇前面章节中my.cnf文件中提及的wsrep_cluster_address=gcomm:// …
获取集群运行状态并返回节点规模数
探测当前容器节点是否属于数据库集群的bootstrap角色（leader）
3. 配置管理工具confd
https://github.com/kelseyhightower/confd 它对rancher提供了很好的支持，能够与Rancher的metadata元数据服务紧密结合：
如何与元数据结合？confd有两个重要文件，一个是模板文件，一个是配置文件，其执行过程就是从backends对象例如Rancher的metadata获取数据，然后将其更新至真正被服务调用的配置文件中去：
这里的pxc.cnf.tmpl文件是模板文件，而pxc.toml文件则是配置文件。confd的配置文件是建立一个服务，监控特定的backends对象（例如etcd、rancher元数据等等）的键值以及当值发生变化时执行某些操作。其文件格式是TOML，易于使用，其规则跟人的直觉也相近。我们可以看到容器执行期间，Rancher预先在rancher-compose.yml中定义的metadata元数据通过confd将一些重要参数传递给了数据库集群服务的配置文件my.cnf：
我们知道Rancher的metadata元数据是有版本差异的，那么如何知道在这个PXC数据库集群里它调用的元数据从何而来呢？
看一下Dockerfile的内容我们不难发现
https://github.com/Flowman/docker-pxc-confd/blob/master/Dockerfile
这里从mysql元数据服务项返回的值正是我们在rancher-compose.yml文件中预先定义好了的：
从Percona XtraDB Cluster这个Rancher的Catalog项目，我们可以较为全面的理解confd配置服务是如何与Rancher的元数据服务进行结合的，这样就能实现较为复杂的数据库集群应用完全自动化的实现弹性伸缩功能。
Q & A
Q：如果在k8s环境部署mysql集群，用什么方案比较好？
A：Rancher的k8s里面的模板没有cattle环境的模板多，Cattle的模板是没有办法直接拿到K8s环境里面来用的，k8s的模板是k8s的yaml文件结合rancher-compose文件。Rancher官网blog有一篇是关于如何转换Prometheus的cattle模板成为k8s模板的，有兴趣的话可以参考一下：http://rancher.com/converting-prometheus-template-cattle-kubernetes/
原文来源：Rancher Labs
https://bobcares.com/blog/mysql-high-availability-top-7-solutions/
- Redundant devices to combat hardware failures
- Shared storage with SAN and NAS
- Storage replication using DRBD
- MySQL replication to avoid single point failures
- MySQL clustering
- Galera multi-master MySQL replication
- Percona XtraDB Cluster
PXC技术概要
Percona XtraDB Cluster与MySQL Replication区别在于：
分布式系统的CAP理论：
C：一致性，所有节点的数据一致；
A：可用性，一个或多个节点失效，不影响服务请求；
P：分区容忍性，节点间的连接失效，仍然可以处理请求；
任何一个分布式系统，需要满足这三个中的两个。
MySQLReplication：可用性和分区容忍性；
Percona XtraDBCluster：一致性和可用性。
因此MySQL Replication并不保证数据的一致性，而Percona XtraDB Cluster提供数据一致性。
Percona XtraDBCluster是MySQL高可用性和可扩展性的解决方案。Percona XtraDBCluster提供的特性有：
- 同步复制，事务要么在所有节点提交或不提交。
- 多主复制，可以在任意节点进行写操作。
- 在从服务器上并行应用事件，真正意义上的并行复制。
- 节点自动配置。
- 数据一致性，不再是异步复制。
Percona XtraDBCluster完全兼容MySQL和Percona Server，表现在：
- 数据的兼容性
- 应用程序的兼容性：无需更改应用程序
它的集群特点是：
- 集群是有节点组成的，推荐配置至少3个节点，但是也可以运行在2个节点上。
- 每个节点都是普通的mysql/percona服务器，可以将现有的数据库服务器组成集群，反之，也可以将集群拆分成单独的服务器。
- 每个节点都包含完整的数据副本。
优点如下：
- 当执行一个查询时，在本地节点上执行。因为所有数据都在本地，无需远程访问。
- 无需集中管理。可以在任何时间点失去任何节点，但是集群将照常工作。
- 良好的读负载扩展，任意节点都可以查询。
缺点如下：
- 加入新节点，开销大。需要复制完整的数据。
- 不能有效的解决写缩放问题，所有的写操作都将发生在所有节点上。
- 有多少个节点就有多少重复的数据。
PXC的传统物理机三节点部署简要说明
那么这样一个MySQL集群方案，在我们传统的物理机环境的安装部署，是否会很复杂呢？熟悉其组件及工作原理之后，安装倒是不特别复杂。我们以CentOS系列为范例，简要看看其安装配置流程：
PXC在Rancher容器管理平台的部署
Percona作为标准的Catalog项目出现在Rancher Server1.1版本之后，如果你使用的是较低的版本，例如v1.0.1，在数据库分类里将只会见到MariaDB Galera Cluster项目。当然你可以在低版本中添加自定义的Catalog，例如
https://github.com/alanpeng/MyRancherCatalog.git
部署好的Percona XtraDB Cluster集群宿主机结构如图所示（除了拉起Percona-XtraDB-Cluster集群之外，还在其前端加入了一个Rancher内置的LoadBalancer）：
将此Catalog项目打开，我们可以看见其docker-compose.yml及rancher-compose.yml文件的内容如下：
Stack/Service结构示意图：
这里的12个容器角色如下：Node节点3个，运行confd服务；ClusterCheck节点3个分别监听集群节点健康状态；Server节点3个，是数据库主服务应用；3个Data作为数据卷共享的提供，是sidekick容器类型。
所有容器列表如下：
数据库连接验证测试：
从前端负载均衡宿主机的IP访问数据库，执行语句show status like 'wsrep%'；返回的结果表明数据库集群节点数为3，同步复制状态正常。
在Rancher平台如何灵活运用Confd+Metadata进行配置管理
以上PXC集群运行于容器之上并被Rancher平台管理，其中的具体实现细节较多，因为我们需要这样的数据库集群满足弹性伸缩的要求，举例来说也就是可以动态的将集群节点数由3个增加至更多，那么必然每个节点的配置文件需要动态的进行更新，要做到这一点，我们可以结合confd与Rancher的metadata元数据服务来实现，当然这里涉及到数据库集群专有的技术，giddyup专有工具的结合也是必不可少的选择。
1. 首先给出整个项目的代码文件供参考
分3个模块：
https://github.com/Flowman/docker-pxc
https://github.com/Flowman/docker-pxc-confd
https://github.com/Flowman/docker-pxc-clustercheck
2. 数据库集群配置工具giddyup
https://github.com/cloudnautique/giddyup
在数据库集群服务的启动脚本
https://github.com/Flowman/docker-pxc/blob/master/start_pxc里我们使用了giddyup工具，其中比较重要的命令有以下项：
获取集群节点成员IP列表，请参照本篇前面章节中my.cnf文件中提及的wsrep_cluster_address=gcomm:// …
获取集群运行状态并返回节点规模数
探测当前容器节点是否属于数据库集群的bootstrap角色（leader）
3. 配置管理工具confd
https://github.com/kelseyhightower/confd 它对rancher提供了很好的支持，能够与Rancher的metadata元数据服务紧密结合：
如何与元数据结合？confd有两个重要文件，一个是模板文件，一个是配置文件，其执行过程就是从backends对象例如Rancher的metadata获取数据，然后将其更新至真正被服务调用的配置文件中去：
这里的pxc.cnf.tmpl文件是模板文件，而pxc.toml文件则是配置文件。confd的配置文件是建立一个服务，监控特定的backends对象（例如etcd、rancher元数据等等）的键值以及当值发生变化时执行某些操作。其文件格式是TOML，易于使用，其规则跟人的直觉也相近。我们可以看到容器执行期间，Rancher预先在rancher-compose.yml中定义的metadata元数据通过confd将一些重要参数传递给了数据库集群服务的配置文件my.cnf：
我们知道Rancher的metadata元数据是有版本差异的，那么如何知道在这个PXC数据库集群里它调用的元数据从何而来呢？
看一下Dockerfile的内容我们不难发现
https://github.com/Flowman/docker-pxc-confd/blob/master/Dockerfile
这里从mysql元数据服务项返回的值正是我们在rancher-compose.yml文件中预先定义好了的：
从Percona XtraDB Cluster这个Rancher的Catalog项目，我们可以较为全面的理解confd配置服务是如何与Rancher的元数据服务进行结合的，这样就能实现较为复杂的数据库集群应用完全自动化的实现弹性伸缩功能。
Q & A
Q：如果在k8s环境部署mysql集群，用什么方案比较好？
A：Rancher的k8s里面的模板没有cattle环境的模板多，Cattle的模板是没有办法直接拿到K8s环境里面来用的，k8s的模板是k8s的yaml文件结合rancher-compose文件。Rancher官网blog有一篇是关于如何转换Prometheus的cattle模板成为k8s模板的，有兴趣的话可以参考一下：http://rancher.com/converting-prometheus-template-cattle-kubernetes/
原文来源：Rancher Labs
实践指南-快速解锁Rancher v1.2
Rancher 发表了文章 • 1 个评论 • 1822 次浏览 • 2016-12-19 10:09
原文来源：Rancher Labs
引言
Rancher v1.2已经发布，相信众多容器江湖的伙伴们正魔拳擦准备好好体验一番。由于Docker能够落地的操作系统众多，各种Docker版本不同的Graph dr ...查看全部
原文来源：Rancher Labs
引言
Rancher v1.2已经发布，相信众多容器江湖的伙伴们正魔拳擦准备好好体验一番。由于Docker能够落地的操作系统众多，各种Docker版本不同的Graph driver，所以通常大版本的第一个release都会在兼容性上有一些小问题。为了更好的体验Rancher v1.2的完整特性，我们选取了Rancher测试比较严格的运行环境。手握众多服务器资源的devops们可以飘过此文，身背MBP或Windows笔记本的Sales/Pre-Sales们可以品读一番。
基础软件安装
首先需要安装基础软件，由于Rancher v1.2已经支持Docker v1.2，所以可以直接使用Docker的Mac或Windows版（以下以Mac为例），下载地址：https://www.docker.com/。在Mac上，Docker会使用xhyve轻量级虚拟化来保证一个Linux环境，所以可以把Rancher Server直接运行起来。
因为要在MBP上添加多个Host组成小集群，所以需要用虚拟化扩展多个节点添加到Rancher集群中。这里可以使用docker-machine控制VirtualBox来添加节点，VirtualBox下载地址：https://www.virtualbox.org/wiki/Downloads。
在Host节点的操作系统上，可以选取RancherOS，我们的目标是快速体验新特性，而Rancher Labs在Rancher和RancherOS的相互兼容性上是做了大量测试的，这样可以避免我们少进坑，直接体验新特性。RancherOS下载地址：https://github.com/rancher/os，推荐使用最新release版本。
在用docker-machine驱动VirtualBox来创建Host时，可以指定操作系统ISO的URL路径，由于我们使用RancherOS，所以最好把RancherOS放到本机HTTP服务器内。MBP内自带Apache HTTPD，将Apache的vhosts模块开启，并添加配置：
Rancher安装
首先打开Docker，并配置registry mirror，配置完成后重启Docker。mirror的服务可以去各个公用云厂商申请一个，比如我这里使用的是阿里云的registry mirror，如图所示：
打开terminal，安装Rancher Server：
若要添加Host节点，则需要通过docker-machine创建Host，这里使用的规格是2核2G（具体可根据自身MBP的性能调整），脚本（add_ros_host.sh）参考如下：
添加节点则需执行：
添加完成后，可以进入虚机内进行设置：
由于我们要使用VirtualBox的虚机组成一个小集群，所以建议把Rancher的Host Registration URL设置为http://192.168.99.1:8080，如下图所示：
添加Rancher agent的时候也要注意，CATTLE_AGENT_IP参数要设置成虚机内192.168.99.0/24网段的IP，如下图所示：
如此就可以基本完全解锁Rancher v1.2的各种功能了，完整演示各种特性。
总结
Docker目前版本分支众多，虽然最新的v1.13即将发布，但是各个公司的使用版本应该说涵盖了v1.9到v1.12，而且Docker graph driver也有很多，再加上很多的LinuxOS，可以说使用Docker而产生组合有很多种，这就会带来各种各样的兼容性问题，因此导致的生产环境故障会让人头疼不已。当然如果纯粹基于演示和调研新功能，我们可以优先兼容性较好的选择。
引言
Rancher v1.2已经发布，相信众多容器江湖的伙伴们正魔拳擦准备好好体验一番。由于Docker能够落地的操作系统众多，各种Docker版本不同的Graph driver，所以通常大版本的第一个release都会在兼容性上有一些小问题。为了更好的体验Rancher v1.2的完整特性，我们选取了Rancher测试比较严格的运行环境。手握众多服务器资源的devops们可以飘过此文，身背MBP或Windows笔记本的Sales/Pre-Sales们可以品读一番。
基础软件安装
首先需要安装基础软件，由于Rancher v1.2已经支持Docker v1.2，所以可以直接使用Docker的Mac或Windows版（以下以Mac为例），下载地址：https://www.docker.com/。在Mac上，Docker会使用xhyve轻量级虚拟化来保证一个Linux环境，所以可以把Rancher Server直接运行起来。
因为要在MBP上添加多个Host组成小集群，所以需要用虚拟化扩展多个节点添加到Rancher集群中。这里可以使用docker-machine控制VirtualBox来添加节点，VirtualBox下载地址：https://www.virtualbox.org/wiki/Downloads。
在Host节点的操作系统上，可以选取RancherOS，我们的目标是快速体验新特性，而Rancher Labs在Rancher和RancherOS的相互兼容性上是做了大量测试的，这样可以避免我们少进坑，直接体验新特性。RancherOS下载地址：https://github.com/rancher/os，推荐使用最新release版本。
在用docker-machine驱动VirtualBox来创建Host时，可以指定操作系统ISO的URL路径，由于我们使用RancherOS，所以最好把RancherOS放到本机HTTP服务器内。MBP内自带Apache HTTPD，将Apache的vhosts模块开启，并添加配置：
# 开启vhost /etc/apache2/httpd.conf
# 以下两行的默认注释去掉
LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so
Include /private/etc/apache2/extra/httpd-vhosts.conf
# vhost的配置 /etc/apache2/extra/httpd-vhosts.conf
# DocumentRoot目录就是在用户根目录下创建Sites
# 如用户名niusmallnan，则DocumentRoot就是/Users/niusmallnan/Sites
DocumentRoot "/Users/niusmallnan/Sites"
ServerName localhost
ErrorLog "/private/var/log/apache2/sites-error_log"
CustomLog "/private/var/log/apache2/sites-access_log"
common
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
Require all granted
# 重启 Apache
$ sudo apachectl restart
# 拷贝 RancherOS的ISO 到 DocumentRoot
$ cp rancheros.iso /Users/niusmallnan/Sites/
Rancher安装
首先打开Docker，并配置registry mirror，配置完成后重启Docker。mirror的服务可以去各个公用云厂商申请一个，比如我这里使用的是阿里云的registry mirror，如图所示：
打开terminal，安装Rancher Server：
$ docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:stable
若要添加Host节点，则需要通过docker-machine创建Host，这里使用的规格是2核2G（具体可根据自身MBP的性能调整），脚本（add_ros_host.sh）参考如下：
#!/usr/bin/env bash
ROS_ISO_URL='http://127.0.0.1/rancheros.iso'
ROS_CPU_COUNT=2
ROS_MEMORY=2048
docker-machine create -d virtualbox \
--virtualbox-boot2docker-url $ROS_ISO_URL \
--virtualbox-cpu-count $ROS_CPU_COUNT \
--virtualbox-memory $ROS_MEMORY \
$1
docker-machine ls
添加节点则需执行：
$ ./add_ros_host.sh ros-1
添加完成后，可以进入虚机内进行设置：
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
ros-1 - virtualbox Running tcp://192.168.99.100:2376 v1.12.3
# 进入VM中
$ docker-machine ssh ros-1
# RancherOS内设置registry mirror
$ sudo ros config set rancher.docker.extra_args \
"['--registry-mirror','https://s06nkgus.mirror.aliyuncs.com']"
$ sudo system-docker restart docker
由于我们要使用VirtualBox的虚机组成一个小集群，所以建议把Rancher的Host Registration URL设置为http://192.168.99.1:8080，如下图所示：
添加Rancher agent的时候也要注意，CATTLE_AGENT_IP参数要设置成虚机内192.168.99.0/24网段的IP，如下图所示：
如此就可以基本完全解锁Rancher v1.2的各种功能了，完整演示各种特性。
总结
Docker目前版本分支众多，虽然最新的v1.13即将发布，但是各个公司的使用版本应该说涵盖了v1.9到v1.12，而且Docker graph driver也有很多，再加上很多的LinuxOS，可以说使用Docker而产生组合有很多种，这就会带来各种各样的兼容性问题，因此导致的生产环境故障会让人头疼不已。当然如果纯粹基于演示和调研新功能，我们可以优先兼容性较好的选择。
有没有人试过持续集成中Jenkins节点用Docker集群实现？
sxdocker 回复了问题 • 2 人关注 • 1 个回复 • 2911 次浏览 • 2016-11-30 23:18
闲谈集群管理模式
taowen 发表了文章 • 0 个评论 • 13630 次浏览 • 2015-06-09 18:00
Docker很火很红，简直到了没有道理的地步了。Docker为什么这么红？因为它是一种可以用来掀桌子的技术。在部署自动化这条产业上的工人和机床制造商们，看家护院的 cmdb，分布式脚本执行等所谓核心技术即便不会变成明日黄花，也会沦为二流技术。仅仅把 Docke ...查看全部
Docker很火很红，简直到了没有道理的地步了。Docker为什么这么红？因为它是一种可以用来掀桌子的技术。在部署自动化这条产业上的工人和机床制造商们，看家护院的 cmdb，分布式脚本执行等所谓核心技术即便不会变成明日黄花，也会沦为二流技术。仅仅把 Docker 当成一个轻量级 vmware 来使用，是没法看穿其实质的。要理解 Docker 的意义，不能从 Docker 是什么，能够干什么说起。让我们先来回忆一下集群管理模式的发展历程，以及这些落后的模式的种种弊端。
#手工管理时代
IP地址是放在 excel 表里的。管理是靠登陆跳板机，用 SSH 连接服务器。手工执行命令做新的服务器部署，已有服务器的程序版本升级，以及各种配置刷新修改的工作。
弊端不言而喻，主要有这么几点：
上面这个扩容的按钮点完之后有让你填 IP 吗？没有！你只需要告诉marathon，我要32个进程实例。它就会去找这些资源运行这 32 个实例。业务最终需要的是 32 个进程，而不是 32 个 IP。IP只是运行进程需要的资源而已。实际运行的时候进程可能是在一个IP上启动了32个端口，也可能是随机分配了5个IP，每个各跑了一些端口。当然这些分配都是可以通过“约束”的方式表达的。而不是让你去搞32个IP来，再跑个脚本去这些IP上部署这些进程。#The Missing Piece拼图游戏就差最后这一块了。Docker 做为一个版本工具是绝对合格的。Marathon 以 Docker 的方式托管所有进程也是靠谱的。但是还不完整：
方案其实非常简单。把 app1 => app2 的网络访问关系，改成 app1 =local=> haproxy =network=> haproxy =local=> app2。通过在容器本地部署 haproxy “托管所有的端口”，也就是用 haproxy 在进程之间做联线，而不是每个进程自己去负责连接网络上的其他进程。试想一下之前是在配置文件里硬编码 10.0.0.1:3306 是某台数据库。硬编码是不对的，是要打屁股的。所以我们把硬编码的 ip 地址改成 127.0.0.1:10010。这一次我们不再硬编码任何 IP 了，我们只硬编码一个特殊的端口号。每个进程都有一堆特殊的本地端口号用于访问自己需要的上下游服务。这个端口号背后的进程到底在哪个 IP，哪个 端口，哪个 container 里执行。做为使用方不需要修改任何代码（比如兼容什么 ZooKeeper/etcd 神马的），也不用关心。甚至这个端口后面是多个远程的IP构成一个基于客户端的高可用。代理甚至还可以做一些出错换一个后端再重试的事情。有了这种神器之后，扩容所容，发布变更，故障替换都很轻松了。容器随便新增，随便删除。网络结构变化了之后，刷新各个地方的 haproxy 配置就是了。各种灰度，各种零停机替换方案都可以搞起。#名字服务与网络类似的方案有很多。最底层的方案是 SDN/IP 漂移，以及网络的bonding。这种方案的特点是保持 IP 地址作为最传统的名字服务，妄图延续其生命。上层一点的方案是 DNS。再上层一些的方案是 ZooKeeper。各种方案争的就是服务如何注册自己，如何彼此发现这个点。各种方案的优缺点可以自己去读：
btw，airbnb 在 13 年就把这套方案投入生产了。
最有意思的是把这种 haproxy 的方案与基于 SDN 的 IP 漂移方案做对比。haproxy 的就是替网络做应用层进程之间联线的事情，通过引入 haproxy 让这种联线更具有灵活性。 而 SDN 的方案是说，你现在的业务进程之间是通过 IP 之间静态链接的，这种连接不够灵活没关系，路由器帮你整。一个 IP 挂掉了，可以把IP漂移到另外一台机器上去继续使用。其实就是在一个场景下实现两个进程的重新联线，突破两 IP 之间静态互访的限制，给基于 IP 的部署方案续命。
两者底层的技术是相通的。所谓 IP 漂移最后靠的是现代牛逼的CPU，和软件路由技术。最后玩的都是用户态转发，dpdk神马的。所以 haproxy 慢，转发效率有问题神马的，长期来看都不会是问题。用软件来联线，是趋势。连路由器都开始这么玩了，连硬件厂商都开始卖软件了。
#The Final Battle
集群管理纯粹变成进程管理，IP不再重要，状态不再重要。CMDB会变得越来越边缘化。
发布变更不再是去修改服务器，而是新建销毁容器，以及更新进程间网络联线关系。分布式作业系统会越来越少用，跳板机就更加不允许使用了。
记住“immutable servers”这个提法吧，它终将会得到历史的认可。
#手工管理时代
IP地址是放在 excel 表里的。管理是靠登陆跳板机，用 SSH 连接服务器。手工执行命令做新的服务器部署，已有服务器的程序版本升级，以及各种配置刷新修改的工作。
弊端不言而喻，主要有这么几点：
- 缺乏一致性，因为是手工操作所以服务器之间总是有一些差异
- 效率低下，一个人可以管理的服务器数量非常有限
- 自动化大跃进时代
- 把本地 excel 表格里的 IP 地址用数据库的方式管理起来，称之为 CMDB
- 基于 SSH 或者 agent 的分布式脚本执行平台
- 大量的脚本，杂乱无章，内容重复，质量难以保证，最终给故障留下隐患
- 没有对现网预期状态的定义和管理，所有的现网状态都是脚本日积月累的产物，导致服务器状态漂移，产生雪花服务器（每个机器都不一样），进而给业务稳定性留下隐患
- CMDB 不再至关重要了。CMDB 连同IP，以及服务器资源变成底层蓝领工人关心的问题了。上层的后台开发和业务运维不再需要也无法再以 IP 为中心的 CMDB 来管理配置。
- 分布式脚本执行平台从核心作业系统退居二线。很简单，服务器不再需要变更了，常规的上新服务器，发布新版本都不再依赖脚本在一个已有的服务器上执行去修改状态。而是创建一个新的容器。
- Docker镜像作为版本发布到现网之后是无法运行的，因为任何一个应用起码都有好几个服务要互相访问。这些硬编码在镜像里的 IP 地址换了一个环境是无法执行的。一个版本里任何配置都可以硬编码，就是 IP 地址和端口是没硬编码的。
- 扩容缩容可以很容易创建和销毁容器，但是引用了这个容器的服务器的其他容器怎么办呢？
- 发布，故障替换都是同样的问题
btw，airbnb 在 13 年就把这套方案投入生产了。
最有意思的是把这种 haproxy 的方案与基于 SDN 的 IP 漂移方案做对比。haproxy 的就是替网络做应用层进程之间联线的事情，通过引入 haproxy 让这种联线更具有灵活性。 而 SDN 的方案是说，你现在的业务进程之间是通过 IP 之间静态链接的，这种连接不够灵活没关系，路由器帮你整。一个 IP 挂掉了，可以把IP漂移到另外一台机器上去继续使用。其实就是在一个场景下实现两个进程的重新联线，突破两 IP 之间静态互访的限制，给基于 IP 的部署方案续命。
两者底层的技术是相通的。所谓 IP 漂移最后靠的是现代牛逼的CPU，和软件路由技术。最后玩的都是用户态转发，dpdk神马的。所以 haproxy 慢，转发效率有问题神马的，长期来看都不会是问题。用软件来联线，是趋势。连路由器都开始这么玩了，连硬件厂商都开始卖软件了。
#The Final Battle
集群管理纯粹变成进程管理，IP不再重要，状态不再重要。CMDB会变得越来越边缘化。
发布变更不再是去修改服务器，而是新建销毁容器，以及更新进程间网络联线关系。分布式作业系统会越来越少用，跳板机就更加不允许使用了。
记住“immutable servers”这个提法吧，它终将会得到历史的认可。
Docker1.12 swarm集群的LB方案和应用原本的LB方案的取舍？
回复babywaiting 回复了问题 • 2 人关注 • 1 个回复 • 2740 次浏览 • 2016-11-04 16:08
公有云托管K8s服务百花齐放，企业如何统一纳管、便捷管理？
Rancher 发表了文章 • 1 个评论 • 1692 次浏览 • 2017-12-04 12:55
正在美国拉斯维加斯举行的AWS re:Invent 2017大会上，亚马逊新发布的一系列计算及存储相关的功能中，最轰动容器领域，无非是AWS Fargate——一种无需管理服务器即可运行容器的服务，以及EKS（Elastic Container Service ...查看全部
正在美国拉斯维加斯举行的AWS re:Invent 2017大会上，亚马逊新发布的一系列计算及存储相关的功能中，最轰动容器领域，无非是AWS Fargate——一种无需管理服务器即可运行容器的服务，以及EKS（Elastic Container Service for Kubernetes），一个完全托管的Kubernetes服务。
EKS的发布，意味着国际范围内三大最主要的云服务商——AWS、Azure和GCP，已全部提供托管的Kubernetes服务。这对于Kubernetes用户而言无疑是个好消息。尽管用户可以选择自行创建自己的Kubernetes集群，而像Rancher Labs同一时期发布的Rancher Kubernetes Engine（RKE）这样的新工具亦使Kubernetes的创建变得更加简单，但是云管理的Kubernetes安装应该是大多数Kubernetes用户的最佳选择。
Rancher在AWS re:Invent现场展台与技术爱好者demo交流
在Rancher Labs，我们希望Kubernetes有朝一日成为所有云服务商支持的标准化的基础架构，且一直在为了实现这个愿景而努力。EKS的发布，意味着这个愿景正在成为现实。我们亦对可以同时导入和纳管任何类型、来自任何云提供商的Kubernetes集群的Rancher 2.0的前景感到兴奋。
Rancher 2.0现已推出技术预览版，计划于2018年初正式发布，Rancher 2.0包含以下三个主要组件：
如上所有功能都可以在Rancher 2.0技术预览版1.0和RKE中找到。秉承Rancher一贯100%开源的风格，你可以直接从GitHub上下载体验RKE
我们也将持续发布更多技术文章，让您更深入了解和学习使用RKE，敬请保持关注。
原文来源：Rancher Labs
EKS的发布，意味着国际范围内三大最主要的云服务商——AWS、Azure和GCP，已全部提供托管的Kubernetes服务。这对于Kubernetes用户而言无疑是个好消息。尽管用户可以选择自行创建自己的Kubernetes集群，而像Rancher Labs同一时期发布的Rancher Kubernetes Engine（RKE）这样的新工具亦使Kubernetes的创建变得更加简单，但是云管理的Kubernetes安装应该是大多数Kubernetes用户的最佳选择。
Rancher在AWS re:Invent现场展台与技术爱好者demo交流
在Rancher Labs，我们希望Kubernetes有朝一日成为所有云服务商支持的标准化的基础架构，且一直在为了实现这个愿景而努力。EKS的发布，意味着这个愿景正在成为现实。我们亦对可以同时导入和纳管任何类型、来自任何云提供商的Kubernetes集群的Rancher 2.0的前景感到兴奋。
Rancher 2.0现已推出技术预览版，计划于2018年初正式发布，Rancher 2.0包含以下三个主要组件：
- RKE。RKE是Rancher自主研发的轻量级Kubernetes安装程序和发行版，它可以在vSphere和裸机服务器以及尚未提供托管Kubernetes服务的公有云上安装Kubernetes。RKE秉承了Rancher产品一贯易于上手、操作简单、体验友好的特性，能为用户带来极致简单易用、且闪电般快速的Kubernetes安装部署体验。
- Kubernetes集群管理。使用Rancher 2.0，用户现在可以配置由RKE、EKS，Google容器引擎（GKE）、Azure容器服务（AKS）创建的Kubernetes集群，亦可导入纳管任何其他Kubernetes集群。IT管理员可以设置与AD / LDAP集成的集中用户身份验证。Rancher还提供集中的基于角色的访问控制（RBAC）、集群容量管理和成本管理。
- 应用程序管理。Rancher在Kubernetes之上提供了一个易于使用的用户界面，并集成了很多云原生生态系统技术，如CI / CD、集中监控和日志等。
如上所有功能都可以在Rancher 2.0技术预览版1.0和RKE中找到。秉承Rancher一贯100%开源的风格，你可以直接从GitHub上下载体验RKE
我们也将持续发布更多技术文章，让您更深入了解和学习使用RKE，敬请保持关注。
原文来源：Rancher Labs
如何配置Kubernetes以实现最大程度的可扩展性
Rancher 发表了文章 • 1 个评论 • 1606 次浏览 • 2017-10-31 17:59
Kubernetes的设计初衷是要解决管理大规模容器化环境时的困难。不过，这并不意味着Kubernetes在任何的环境下都可以进行扩展。有一些方法可以让用户最大限度地发挥Kubernetes的扩展能力，而在扩展Kubernetes时，有一些重要事项和限制需要注 ...查看全部
Kubernetes的设计初衷是要解决管理大规模容器化环境时的困难。不过，这并不意味着Kubernetes在任何的环境下都可以进行扩展。有一些方法可以让用户最大限度地发挥Kubernetes的扩展能力，而在扩展Kubernetes时，有一些重要事项和限制需要注意，本文中我将对这些内容进行说明。
规模和性能
扩展Kubernetes集群，首先要注意的就是规模和性能之间的平衡。比如，Kubernetes 1.6可被用于多达5000个节点的集群。不过5000个节点并不是硬性限制的最大值，它只是一个推荐的节点最大值。在实际使用中，节点数可以远超过5000个，只是这样会导致性能下降罢了。
这个问题具体来说是这样的：Kubernetes有两个服务层级的目标，一个是在一秒内返回99%的API调用。另一个是在5秒内启动99%的pods。尽管这些目标并不是完整的一套性能指标，但它们确实为评估通用集群性能提供了良好的基准。而据Kubernetes所说，超过5000个节点的集群可能无法实现这些服务层级的目标。
所以有一点请大家注意，在有些时候，为了发挥Kubernetes的扩展性，你有可能不得不牺牲一部分的性能，这些牺牲对你来说既可能是值得的，也可能是不值得的，而这取决于你具体的部署场景。
配额（quotas）
在建立非常大规模的Kubernetes集群时，你可能会遇到的一个主要问题就是配额问题。对于基于云的节点尤为如此，因为云服务提供商通常情况下会设置配额限制。
这个问题之所以如此重要，是因为部署大规模的Kubernetes集群实际上是一个看似简单的过程。config-default.sh文件有NUM_NODES的设置。表面上，你可以通过加大与此设置相关联的值来构建大规模集群。虽然这在某些情况下可行，但最终也可能会遭遇到配额问题。因此，在你打算扩展集群之前，很有必要就现有的任何配额先和云供应商进行沟通。云供应商不仅可以让你了解现有配额的情况，而且至少一部分云供应商会同意用户增加配额限制的请求。
当你在评估这些限制的时候，需要注意，尽管配额限制会直接限制你创建Kubernetes集群的数量，然而集群大小的限制更多是出自与Kubernetes间接相关的配额。例如，提供商可能会限制允许你使用的IP地址数量，或者限制你创建的虚拟机实例数量。而好消息是，主要的几个云服务商已经有多次和Kubernetes打交道的经验，应该能够帮助你解决这些问题。
主节点
除了上述的限制外，还需要考虑的一个问题是集群大小对所需的主节点大小和数量的影响。这些取决于Kubernetes的实现方式，不过要记住的一点是，集群越大，所需的主节点数量也越多，而那些主节点的功能需求也就越高。
如果你正在从头构建新的Kubernetes集群，这可能是一个无关的问题，毕竟确定需要的主节点数量是集群规划过程中的正常阶段。可是如果你打算扩展现有Kubernetes集群，那么你更需要去多加考虑主节点的需求，因为在集群启动时主节点的大小就已经设置好了，而且不能够动态调整。
扩展附加组件（scaling add-ons）
另一件需要我们注意的是，Kubernetes定义了附加组件容器的资源限制。这些资源限制可确保附加组件不会消耗过多的CPU和内存资源。
这些有关限制的问题是，它们是基于相对较小的集群进行定义的。如果你在大规模集群中运行某些附加组件，它们可能会需要超额使用更多的资源。这是因为附加组件必须服务更多的节点，也因此需要额外的资源。如果开始出现与组件相关限制的问题，那么你就会看到附加组件一个一个地被kill掉。
总结
Kubernetes集群可以大规模扩展，但可能会遇到与配额和性能相关的问题。因此，在向Kubernetes集群添加大量新节点之前，请一定要仔细考虑横向扩展所出现的各种需求。
原文来源：Rancher Labs
规模和性能
扩展Kubernetes集群，首先要注意的就是规模和性能之间的平衡。比如，Kubernetes 1.6可被用于多达5000个节点的集群。不过5000个节点并不是硬性限制的最大值，它只是一个推荐的节点最大值。在实际使用中，节点数可以远超过5000个，只是这样会导致性能下降罢了。
这个问题具体来说是这样的：Kubernetes有两个服务层级的目标，一个是在一秒内返回99%的API调用。另一个是在5秒内启动99%的pods。尽管这些目标并不是完整的一套性能指标，但它们确实为评估通用集群性能提供了良好的基准。而据Kubernetes所说，超过5000个节点的集群可能无法实现这些服务层级的目标。
所以有一点请大家注意，在有些时候，为了发挥Kubernetes的扩展性，你有可能不得不牺牲一部分的性能，这些牺牲对你来说既可能是值得的，也可能是不值得的，而这取决于你具体的部署场景。
配额（quotas）
在建立非常大规模的Kubernetes集群时，你可能会遇到的一个主要问题就是配额问题。对于基于云的节点尤为如此，因为云服务提供商通常情况下会设置配额限制。
这个问题之所以如此重要，是因为部署大规模的Kubernetes集群实际上是一个看似简单的过程。config-default.sh文件有NUM_NODES的设置。表面上，你可以通过加大与此设置相关联的值来构建大规模集群。虽然这在某些情况下可行，但最终也可能会遭遇到配额问题。因此，在你打算扩展集群之前，很有必要就现有的任何配额先和云供应商进行沟通。云供应商不仅可以让你了解现有配额的情况，而且至少一部分云供应商会同意用户增加配额限制的请求。
当你在评估这些限制的时候，需要注意，尽管配额限制会直接限制你创建Kubernetes集群的数量，然而集群大小的限制更多是出自与Kubernetes间接相关的配额。例如，提供商可能会限制允许你使用的IP地址数量，或者限制你创建的虚拟机实例数量。而好消息是，主要的几个云服务商已经有多次和Kubernetes打交道的经验，应该能够帮助你解决这些问题。
主节点
除了上述的限制外，还需要考虑的一个问题是集群大小对所需的主节点大小和数量的影响。这些取决于Kubernetes的实现方式，不过要记住的一点是，集群越大，所需的主节点数量也越多，而那些主节点的功能需求也就越高。
如果你正在从头构建新的Kubernetes集群，这可能是一个无关的问题，毕竟确定需要的主节点数量是集群规划过程中的正常阶段。可是如果你打算扩展现有Kubernetes集群，那么你更需要去多加考虑主节点的需求，因为在集群启动时主节点的大小就已经设置好了，而且不能够动态调整。
扩展附加组件（scaling add-ons）
另一件需要我们注意的是，Kubernetes定义了附加组件容器的资源限制。这些资源限制可确保附加组件不会消耗过多的CPU和内存资源。
这些有关限制的问题是，它们是基于相对较小的集群进行定义的。如果你在大规模集群中运行某些附加组件，它们可能会需要超额使用更多的资源。这是因为附加组件必须服务更多的节点，也因此需要额外的资源。如果开始出现与组件相关限制的问题，那么你就会看到附加组件一个一个地被kill掉。
总结
Kubernetes集群可以大规模扩展，但可能会遇到与配额和性能相关的问题。因此，在向Kubernetes集群添加大量新节点之前，请一定要仔细考虑横向扩展所出现的各种需求。
原文来源：Rancher Labs
Docker拥抱k8s早有预兆，Docker现何去何从？
Rancher 发表了文章 • 1 个评论 • 1596 次浏览 • 2017-10-20 11:55
导读
本文由Rancher Labs CEO及联合创始人梁胜博士写于前往参加DockerCon之前。从各家容器编排方案均很不成熟的初期，到三足鼎立的编排之战，到如今k8s似已全面胜利，作为整个发展历程的参与者与见证者，回顾这几年容器领 ...查看全部
导读
本文由Rancher Labs CEO及联合创始人梁胜博士写于前往参加DockerCon之前。从各家容器编排方案均很不成熟的初期，到三足鼎立的编排之战，到如今k8s似已全面胜利，作为整个发展历程的参与者与见证者，回顾这几年容器领域发展和Rancher的发展与选择，梁胜博士分享了他的一些看法。
Docker宣布支持Kubetnetes，拥抱昔日对手，而这一点在回溯过去时就早有苗头。纵观Docker在编排领域的发展之路，大概这一决定是历史的必然。这篇文章或许能从另一种视角带你看看这个业界目前最热议的话题。
目前Docker技术得到了广泛应用，在大量需求的催生下，我们创造了Rancher，在过去三年的各届DockerCon上，Rancher都得到了很多来自用户的热情欢迎和积极反响。
DockerCon有它的特别之处——不仅在于它将主要行业玩家全都召集到了一块，更是因为DockerCon是为数不多的、参会者中用户数量远超供应商数量的技术大会。能够一下子遇到这么多用户，无论是参会还是赞助都十分值得。和我们的用户交谈，听取他们的想法，这激励并启发着我们更好地改进Rancher产品。
Docker的技术革新正处于关键期，因此我对于Docker将在今年DockerCon EU公布的内容非常感兴趣。最近我们发布了Rancher 2.0 Tech Preview，该版本中我们把Rancher从基于Docker的产品转变成基于Kubernetes的产品。虽然Docker作为一个应用程序打包和运行的标准取得了极大成功，而Kubernetes在容器基础设施、编排和生态系统方面都已经超过了Docker，这也是我们选择Kubernetes的原因。
容器基础设施
基础设施所涵盖的范围不仅只是打包和运行，它还包括存储、网络、负载均衡和安全。三年前当我们刚开始研发Rancher时，我们认为Docker将会给容器网络和存储定义行业标准插件接口。尽管Docker和其他诸如SocketPlane（后被Docker收购）、Weveworks和ClusterHQ等早期先驱做了许多出色的工作，并且还得到了如思科、EMC和NetApp等行业领导者的大量支持，然而Docker接口，像libnetwork、容器网络模型（CNM）和Docker volume插件还是没能成为可行的标准。我们在Rancher中仍然在CNM和Docker volume插件方面做努力，不过我们遇到了难以逾越的挑战：
在Rancher 1.2（2016年12月发布）中，通过切换到Kubernetes容器网络接口（CNI）和Kubernetes Flexvolume存储框架，我们已经解决了这些问题。因为Rancher2.0是基于Kubernetes的，任何与Kubernetes集成的网络、存储、负载均衡和安全性方案都可以在Rancher上开箱即用。
容器编排
我们为Rancher开发了名为Cattle的容器编排器，来填补在Docker Swarm早期时缺失的一些功能，包括服务发现、DNS、服务升级和负载均衡器。我们希望当Swarm更加完善之后，能够最终替代Cattle。
然而，在2016年3月Rancher 1.0发布时，Swarm还没准备好。那个时候Kubernetes还未成熟，容器编排的未来也不是很明朗。因此我们决定，Rancher 1.0要同时支持多编排器：Cattle、Swarm、Kubernetes和Mesos。这样一来，用户便不会受限于某个特定的容器编排器，且Rancher的用户都十分喜欢这一设计。
2016年6月时，Docker公布了Swarm Mode，我们都很为此而激动。Swarm Mode提供了早期Docker Swarm中缺少的许多功能，并且非常接近于Cattle所做的工作。于是我们很快在Rancher中添加了Swarm Mode的支持。
可是直到2017年初，Swarm Mode都没有得到重视。或许是早期的Swarm Mode实现上存在质量问题，也可能是Kubernetes的发展已经遥遥领先。绝大数Rancher用户都在使用Cattle和Kubernetes。
Rancher 2.0建立在行业标准Kubernetes之上。Cattle不会消失——它将成为一种内置的Rancher体验，我们也会持续改进它。通过2.0，我们提供了简单的基于Kubernetes的Docker和Docker Compose用户体验。任何对Docker有基本了解的人都可以快速上手，等用户熟练掌握之后还能体验到更进阶的原生Kubernetes体验。
容器生态系统
DockerCon Europe汇聚了大量响当当的赞助商，也无疑吸引了越来越多的Docker用户。我一直从DockerHub上寻找最新的用户数据作为Docker增长的基准。在2017年4月的DockerCon Austin上，这个数字是120亿，并且在那之后还在增长。
构成Kubernetes生态系统的公司其实差不多，不过参与模式却完全不同。大多数的生态系统合作伙伴像我们一样，认为Docker是一种成熟的技术，且拥有大量的用户。而Kubernetes生态系统更加活跃，因为在这一生态系统中有很多积极的发展、创新和整合。
Docker将何去何从？
早在2016年的12月份，我就曾注意到Docker之父、Docker公司CTO Solomon Hykes在他的一篇blog中，将Docker的定位放在了和OpenShift（以及Rancher 2.0）同样的层级，这层级是位于Kubernetes之上的。看来从那时起，Docker就已计划构建一个全新的、基于Kubernetes之上的Docker产品了？
在我从DockerCon回来之后，我会再写一篇文章，分享更多我的一些看法与见解。
Rancher at DockerCon
Rancher Labs全新发布的新产品Rancher 2.0，一方面，把Rancher 提供的Kubernetes分发版的用户体验，从原生的Kubernetes UI修改到被全球客户广泛接受的Rancher UI，解决了业界遗留已久的Kubernetes原生UI易用性差的问题。另一方面，在产品中增加了可以纳管其他厂商提供的Kubernetes分发版功能，如Ubuntu Kubernetes、Dell EMC Kubernetes、Google GKE等等，从而具备了同时管理多个Kubernetes集群的能力，这在业界都还是独一无二的特性。
作为DockerCon的金牌赞助商，Rancher的技术人员将在现场G16展位和技术爱好者进行面对面的技术交流，并受大会之邀将进行两场演讲。
我们还会带来更多来自现场的快报，敬请关注！
原文来源：Rancher Labs
本文由Rancher Labs CEO及联合创始人梁胜博士写于前往参加DockerCon之前。从各家容器编排方案均很不成熟的初期，到三足鼎立的编排之战，到如今k8s似已全面胜利，作为整个发展历程的参与者与见证者，回顾这几年容器领域发展和Rancher的发展与选择，梁胜博士分享了他的一些看法。
Docker宣布支持Kubetnetes，拥抱昔日对手，而这一点在回溯过去时就早有苗头。纵观Docker在编排领域的发展之路，大概这一决定是历史的必然。这篇文章或许能从另一种视角带你看看这个业界目前最热议的话题。
目前Docker技术得到了广泛应用，在大量需求的催生下，我们创造了Rancher，在过去三年的各届DockerCon上，Rancher都得到了很多来自用户的热情欢迎和积极反响。
DockerCon有它的特别之处——不仅在于它将主要行业玩家全都召集到了一块，更是因为DockerCon是为数不多的、参会者中用户数量远超供应商数量的技术大会。能够一下子遇到这么多用户，无论是参会还是赞助都十分值得。和我们的用户交谈，听取他们的想法，这激励并启发着我们更好地改进Rancher产品。
Docker的技术革新正处于关键期，因此我对于Docker将在今年DockerCon EU公布的内容非常感兴趣。最近我们发布了Rancher 2.0 Tech Preview，该版本中我们把Rancher从基于Docker的产品转变成基于Kubernetes的产品。虽然Docker作为一个应用程序打包和运行的标准取得了极大成功，而Kubernetes在容器基础设施、编排和生态系统方面都已经超过了Docker，这也是我们选择Kubernetes的原因。
容器基础设施
基础设施所涵盖的范围不仅只是打包和运行，它还包括存储、网络、负载均衡和安全。三年前当我们刚开始研发Rancher时，我们认为Docker将会给容器网络和存储定义行业标准插件接口。尽管Docker和其他诸如SocketPlane（后被Docker收购）、Weveworks和ClusterHQ等早期先驱做了许多出色的工作，并且还得到了如思科、EMC和NetApp等行业领导者的大量支持，然而Docker接口，像libnetwork、容器网络模型（CNM）和Docker volume插件还是没能成为可行的标准。我们在Rancher中仍然在CNM和Docker volume插件方面做努力，不过我们遇到了难以逾越的挑战：
- 我们还没有实现让CNM在Docker的内置网络实现之外工作。比如，我们现在还不能创建一个脱离Swarm Mode的CNM实现。
- 我们没法让Rancher上的Docker volume插件在Docker守护进程下保持可靠性。我记得有一个极具挑战性的issue，#18504，它导致Docker守护进程会不时地锁住。我们暂时还不能解决它，也还没找到解决方案。
在Rancher 1.2（2016年12月发布）中，通过切换到Kubernetes容器网络接口（CNI）和Kubernetes Flexvolume存储框架，我们已经解决了这些问题。因为Rancher2.0是基于Kubernetes的，任何与Kubernetes集成的网络、存储、负载均衡和安全性方案都可以在Rancher上开箱即用。
容器编排
我们为Rancher开发了名为Cattle的容器编排器，来填补在Docker Swarm早期时缺失的一些功能，包括服务发现、DNS、服务升级和负载均衡器。我们希望当Swarm更加完善之后，能够最终替代Cattle。
然而，在2016年3月Rancher 1.0发布时，Swarm还没准备好。那个时候Kubernetes还未成熟，容器编排的未来也不是很明朗。因此我们决定，Rancher 1.0要同时支持多编排器：Cattle、Swarm、Kubernetes和Mesos。这样一来，用户便不会受限于某个特定的容器编排器，且Rancher的用户都十分喜欢这一设计。
2016年6月时，Docker公布了Swarm Mode，我们都很为此而激动。Swarm Mode提供了早期Docker Swarm中缺少的许多功能，并且非常接近于Cattle所做的工作。于是我们很快在Rancher中添加了Swarm Mode的支持。
可是直到2017年初，Swarm Mode都没有得到重视。或许是早期的Swarm Mode实现上存在质量问题，也可能是Kubernetes的发展已经遥遥领先。绝大数Rancher用户都在使用Cattle和Kubernetes。
Rancher 2.0建立在行业标准Kubernetes之上。Cattle不会消失——它将成为一种内置的Rancher体验，我们也会持续改进它。通过2.0，我们提供了简单的基于Kubernetes的Docker和Docker Compose用户体验。任何对Docker有基本了解的人都可以快速上手，等用户熟练掌握之后还能体验到更进阶的原生Kubernetes体验。
容器生态系统
DockerCon Europe汇聚了大量响当当的赞助商，也无疑吸引了越来越多的Docker用户。我一直从DockerHub上寻找最新的用户数据作为Docker增长的基准。在2017年4月的DockerCon Austin上，这个数字是120亿，并且在那之后还在增长。
构成Kubernetes生态系统的公司其实差不多，不过参与模式却完全不同。大多数的生态系统合作伙伴像我们一样，认为Docker是一种成熟的技术，且拥有大量的用户。而Kubernetes生态系统更加活跃，因为在这一生态系统中有很多积极的发展、创新和整合。
Docker将何去何从？
早在2016年的12月份，我就曾注意到Docker之父、Docker公司CTO Solomon Hykes在他的一篇blog中，将Docker的定位放在了和OpenShift（以及Rancher 2.0）同样的层级，这层级是位于Kubernetes之上的。看来从那时起，Docker就已计划构建一个全新的、基于Kubernetes之上的Docker产品了？
在我从DockerCon回来之后，我会再写一篇文章，分享更多我的一些看法与见解。
Rancher at DockerCon
Rancher Labs全新发布的新产品Rancher 2.0，一方面，把Rancher 提供的Kubernetes分发版的用户体验，从原生的Kubernetes UI修改到被全球客户广泛接受的Rancher UI，解决了业界遗留已久的Kubernetes原生UI易用性差的问题。另一方面，在产品中增加了可以纳管其他厂商提供的Kubernetes分发版功能，如Ubuntu Kubernetes、Dell EMC Kubernetes、Google GKE等等，从而具备了同时管理多个Kubernetes集群的能力，这在业界都还是独一无二的特性。
作为DockerCon的金牌赞助商，Rancher的技术人员将在现场G16展位和技术爱好者进行面对面的技术交流，并受大会之邀将进行两场演讲。
我们还会带来更多来自现场的快报，敬请关注！
原文来源：Rancher Labs
Rancher 2.0快速上手指南
Rancher 发表了文章 • 4 个评论 • 2871 次浏览 • 2017-10-10 12:51
大家好，给大家介绍一下，这是帮助大家率先上手尝试Rancher 2.0的神器 @Rancher 2.0快速上手指南
内容导读
准备一台Linux主机启动Rancher服务器，进入Rancher UI如何在R ...查看全部
大家好，给大家介绍一下，这是帮助大家率先上手尝试Rancher 2.0的神器 @Rancher 2.0快速上手指南
内容导读
在Rancher 2.0中，Cattle用户依然可以享受和以前一样的易于使用的用户体验，还可以额外地利用Kubernetes编排引擎的优势，包括其丰富的基础设施插件、增强的RBAC功能和原生生态系统服务。而Kubernetes用户能在同一平台上管理任何Kubernetes集群，轻松地充分利用Kubernetes的强大能力及其迅速壮大的生态系统。通过基于Kubernetes、简单直观的用户体验，Rancher 2.0将加快Kubernetes在企业中的普及。在本指南中，你将会了解如何快速上手Rancher v2.0。本文将涉及以下内容：准备一台64位主机，系统Ubuntu16.04，至少4GB的内存，内核版本3.10+； 在主机上安装兼容的Docker版本，关于如何在服务器上安装Docker，请参考此教程。 启动Rancher Server只需一条命令和几分钟时间，你就可以安装并启动Rancher Server。安装完成后，打开Web浏览器就能访问Rancher UI。#如何启动Rancher Server第一步：在你的主机上执行如下的Docker命令:8080就可以访问Rancher UI，这里的里要填你主机的IP地址。Rancher可以自动部署和管理Kubernetes，UI界面会展示一个Welcome的页面，其中包含两项有关添加主机的选项。
原文来源：Rancher Labs
内容导读
- 准备一台Linux主机
- 启动Rancher服务器，进入Rancher UI
- 如何在Rancher UI下添加一个主机
- 如何导入现有的Kubernetes集群
- 如何在Rancher UI下添加一个容器
- 启动Calalog应用
- 如何使用高级Kubernetes选项
在Rancher 2.0中，Cattle用户依然可以享受和以前一样的易于使用的用户体验，还可以额外地利用Kubernetes编排引擎的优势，包括其丰富的基础设施插件、增强的RBAC功能和原生生态系统服务。而Kubernetes用户能在同一平台上管理任何Kubernetes集群，轻松地充分利用Kubernetes的强大能力及其迅速壮大的生态系统。通过基于Kubernetes、简单直观的用户体验，Rancher 2.0将加快Kubernetes在企业中的普及。在本指南中，你将会了解如何快速上手Rancher v2.0。本文将涉及以下内容：- 准备一台Linux主机
- 启动Rancher服务器，进入Rancher UI
- 在Rancher UI下添加一个主机
- 导入现有的Kubernetes集群
- 在Rancher UI下添加一个容器
- 启动Calalog应用
- 使用高级Kubernetes选项
- Docker v1.12.6
- Docker v1.13.1
- Docker v17.03-2-ce
- Docker v17.06-ce
$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:preview这一步骤需要花费几分钟来完成第二步：在浏览器中输入http://
第三步：选择添加主机的一个选项，然后进入到如下的相关部分：添加主机 – 如果你想要在Rancher中管理主机，请点击此选项。你可以添加一个已有的、安装好了Docker的主机，亦可以添加其他云服务商提供的新主机（后文会有详解）。使用现有的Kubernetes – 如果你希望集群提供者可以在Rancher外部管理主机，请点击此选项。你可以导入已有的Kubernetes（后文会有详解）。添加主机在这里你可以添加来自Rancher v2.0支持的云服务商的主机，也可以添加自定义主机。如果在UI界面没有看到你的云服务商，不要着急，只需选择自定义主机选项即可。如果你想添加自定义的主机，需要注意这些要求：注意：最开始，Rancher会为你创建一个默认的集群和环境。Rancher能够将资源分组到多个集群和环境中。每个集群都是一组物理（或虚拟）的计算资源。每个环境绑定一个集群，并在集群的主机上运行其容器，而你可以将一个集群共享给多个环境。环境是用来定义应用程序、服务和容器的命名空间。环境中的容器可以通过共享的可管理网络相互通信，你可以通过向不同的用户／组分配访问权限来管理环境中的资源。
- 通常，Rancher会自动检测IP地址来注册主机
- 主机代理会启动与服务器的连接，因此你需要确保防火墙或者安全组允许它通过命令能够到达URL。
- 环境中的所有主机必须允许彼此间的流量能够进行跨主机联网。
- Amazon EC2
- Microsoft Azure
- DigitalOcean
- Packet
sudo docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v2.0-alpha2http://:8080/v3/scripts/D5433C26EC51325F9D98:1483142400000:KvILQKwz1N2MpOkOiIvGYKKGdE
第二步：在你的主机上复制、粘贴并运行该命令，就可以把你的主机注册到Rancher上。这一过程需要几分钟完成。第三步：点击“关闭”。在Hosts页面就可以看到主机的状态。导入Kubernetes集群在Rancher v2.0中，你可以导入已有的在外部安装的Kubernetes v1.7以上版本。这种情况下，集群提供商可以在Rancher之外管理你的主机。我们支持像Google Container Engine、Azure Container Service、IBM Bluemix这样的托管服务，你也可以导入你自己的Kubernetes集群。#如何导入Kubernetes集群第一步：复制、粘贴UI界面的kubectl命令，在你的集群中执行它。第二步：点击“关闭”，在Hosts页面，你就可以看到Kubernetes节点的状态。添加容器在你向环境中添加了至少一个主机或集群后，可能会需要几分钟来启动所有的Rancher系统服务。想要验证自己的环境，那么在“默认”菜单中选择“系统”。如果服务正常，将会显示状态为绿色。当确认所有的系统服务均正常启动后，就可以创建你的第一个容器了。#如何添加容器第一步：在Rancher UI菜单，点击“容器”第二步：点击“添加容器”，进入添加容器页面第三步：输入“名称”，比如“first-container”第四步：输入一个Docker Hub上托管的Docker Image第五步：点击“启动”。该步骤需要几分钟来完成。当容器开始启动，就可以在“容器”页面看到它的状态到目前为止你已经添加了主机，并且启动了第一个容器，接下来将介绍Rancher v2.0的新特性。启动Catalog应用Rancher提供了一个catalog应用模板来部署复杂的应用。#如何启动catalog应用第一步：在Rancher UI菜单，点击Apps，进入Application页面第二步：点击Launch from Catalog，显示可用的catalog应用模板第三步：找到你想要启动的模板，点击View Details第四步：完成必要的填写注意：命令中的IP地址必须对应你的
而且必须能够从主机内部访问。
第五步：点击Launch，在Application页面，你会看到Rancher正在为你的新应用创建堆栈。这一过程需要几分钟时间。如果服务正常启动，新堆栈的状态将显示为绿。使用高级Kubernetes选项在Rancher UI界面，你只需一键点击即可进入本地的Kubernetes dashboard。你也可以从web浏览器上执行kubectl。Kubernetes CLI或者kubectl都可以帮助你部署和管理Kubernetes应用。有关更多信息以及下载kubectl，请访问Kubernetes documentation。另外，你可以创建一个Kubernetes配置文件，以便在桌面上使用kubectl。Kubernetes配置文件（即kubeconfig）允许你配置一个或多个集群的访问。#如何使用高级kubernets选项第一步：在Rancher UI菜单，点击Containers。第二步：选择Advanced标签，将出现下列高级选项：注意：docker-compose.yml和rancher-compose.yml文件与生成应用有关。在启动堆栈前点击Preview即可查看它们。
- Launch Dashboard – 在新浏览器窗口中访问本地Kubernetes dashboard
- Launch kubectl – 使用shell从浏览器运行kubectl命令，单击Close返回到Rancher UI界面
- Download kubeconfig – 生成一个kubeconfig文件以便在桌面使用kubectl。将～/.kube/config文件中的代码复制粘贴到新文件中，然后运行kubectl。点击Close返回到Rancher UI界面。
原文来源：Rancher Labs
梁胜博士亲解Rancher 2.0：K8s之上的Rancher魔法
Rancher 发表了文章 • 1 个评论 • 2004 次浏览 • 2017-09-30 10:59
经过数月的努力，我们终于发布了Rancher 2.0 Technology Preview，这对Rancher Labs而言也是历史性的、值得铭记的一刻。
Rancher 1.x容器管理平台一直为市场和用户所喜爱，自2016年3月Ra ...查看全部
经过数月的努力，我们终于发布了Rancher 2.0 Technology Preview，这对Rancher Labs而言也是历史性的、值得铭记的一刻。
Rancher 1.x容器管理平台一直为市场和用户所喜爱，自2016年3月Rancher 1.0发布以来，Rancher server和Rancher agent的下载量达到了6000多万次。全球范围内Rancher的部署节点已超过10000个，付费客户超过100个。几乎每天都有用户和客户告诉我们，Rancher让他们在生产中运行Docker和Kubernetes变得容易。我们深感感谢，是用户们的激励让Rancher软件变得更好。我还要特别感谢我们的客户，感谢他们对Rancher软件的持续发展提供了资金上的支持！
Rancher 1.0中有一个易于使用的容器编排框架，称为Cattle。且Rancher1.0支持所有主流的容器编排框架，包括Swarm、Mesos和Kubernetes。一个容器管理平台，多个编排框架供其选择，这是Rancher用户一直喜欢Rancher的原因之一。
然而，去年Kubernetes的增长远远高于其他编排引擎。Rancher用户希望在Kubernetes之上得到更好的用户体验和更多的功能。因此，我们决定重新设计Rancher 2.0，将过去大受用户欢迎的Rancher用户体验（即Cattle）架构于Kubernetes之上，从而充分利用Kubernetes的强大力量。
在Rancher 2.0中：
我们的Kubernetes之旅
2015年，当我们刚开始在Rancher中纳入对Kubernetes的支持时，那时的Kubernetes用户面临的最大挑战就是如何安装和配置Kubernetes集群。那时候，Kubernetes自己的脚本和工具很难使用，而且不可靠。但在Rancher中，Kubernetes集群的设置只需一键即可完成。更重要的是，Rancher允许您在任何基础架构上设置Kubernetes集群，包括公有云、vSphere集群和裸机服务器。因此，Rancher很快成为启动Kubernetes集群的最受欢迎的方式之一。
在2016年初，市场上已经有许多现成的和第三方的Kubernetes安装程序。我们的问题不再是如何安装和配置Kubernetes，而是如何持续地运行和升级Kubernetes集群。我们在Rancher中构建了很多功能，用户可以很容易地操作和升级Kubernetes集群及其etcd数据库。
到2016年底，我们开始注意到，Kubernetes运营软件的价值正在迅速下降，这一趋势的出现有两个因素。首先，诸如Kubernetes Operations（kops）等开源工具已经成熟，许多机构与企业能够轻松地在AWS上运行Kubernetes。第二，Kubernetes-as-a-Service（Kubernetes即服务）开始受欢迎。例如，Google Cloud客户不再需要配置和操作自己的集群。他们可以依靠Google——Kubernetes技术的发明者，为他们运行Kubernetes。
#KUBERNETES EVERYWHERE
2016年初，Google Kubernetes项目的创始人、后来创立了Kubernetes公司Heptio的Joe Beda，曾跟我谈及他的“Kubernetes Everywhere”的愿景，他希望Kubernetes可以和无处不在的IaaS相抗衡。
2017年，Kubernetes的流行度在持续上升，且这一势头从未放缓。我们有理由相信在不远的未来，所有基础设施供应商都将提供Kubernetes-as-a-Service。那一天到来的时候，Kubernetes将成为通用的基础设施标准。DevOps团队将不再需要自己操作Kubernetes集群。而唯一剩下的挑战将是如何简单而统一地管理和利用各基础设施上的Kubernetes集群。
基于Kubernetes的Rancher2.0平台
Rancher2.0是一个基于Kubernetes的成熟的容器管理平台。下图展示了Rancher拥有的功能。
与Rancher1.0不同，Rancher server2.0包含了一个嵌入式的Kubernetes主机。这意味着一旦你开始使用Rancher，比如执行命令
马上就有一个Kubernetes集群供你启动和执行，无需再为创建Kubernetes做更多的操作。在这之后，每一个添加的主机都会自动安装Kubelet，并成为Kubernetes集群的一部分。
你可以使用相同的嵌入式Kubernetes主机来创建额外的集群。我们已经建立了一个定制的多租户Kubernetes API服务器，它能够最大限度地减少多个Kubernetes集群所需的资源。
我们认为Kubernetes-as-a-service在未来会成为常态，会越来越少使用嵌入式Kubernetes主机。Rancher2.0能够支持导入和管理由云服务商（例如Google容器引擎GKE)）控制的Kubernetes集群，当然还有使用其他工具（如kops）建立的Kubernetes集群。
#对多个集群的单点控制和可视化
IT管理员可以使用嵌入式的Kubernetes主机创建几个Kubernetes集群，或者导入几个现有的Kubernetes集群，然后使用Rancher作为对多个集群的单点控制和管理平台。
我们举一个例子来说明IT管理员是如何在Rancher中使用centralized RBAC和认证功能的。想象一下，如果企业直接使用Google Container Engine（GKE）作为部署容器应用的标准平台，而GKE却要求每个用户都需要有Google账户，这显然不是大多企业的标准做法。通过Rancher，IT管理员可以使用单一的服务账户将GKE集群导入Rancher，然后就能够用企业现有的ActiveDirectory凭证对其他用户进行身份验证。
#全新的UI
很多用户告诉我们，他们非常喜欢Rancher的UI。在2.0版本我们做得更加美观了！我们自己也很喜欢它的设计，并且也希望把它做得更棒。在默认设置下，2.0的UI提供一个简单的容器视图，对容器只有初步了解的人都可以很轻松地开始使用Kubernetes。高级用户他们仍然可以访问Kubectl和Kubernetes dashboard。其次，Rancher应用服务目录Catalog的使用体验进一步优化，通过简单的鼠标点击不仅可以部署应用程序，还可以在部署后轻松地访问和管理应用。Rancher2.0的UI扩展了更多的容器、服务和主机，并且保持了高度响应，如果你喜欢Rancher 1.X的UI，那么你一定会更喜欢2.0。
#未来，还有更多......
我们现在发布的是一个早期的技术预览，我们现在仍有很多未完成的工作，目前还在忙于修复bug并添加诸如HA部署、RBAC和身份认证、集成CI/CD、监控和日志等等这些特性。我们将会持续发布新的版本，敬请关注，也请一如既往地给我们更多反馈与意见，让我们可以做得更好！
原文来源：Rancher Labs
Rancher 1.x容器管理平台一直为市场和用户所喜爱，自2016年3月Rancher 1.0发布以来，Rancher server和Rancher agent的下载量达到了6000多万次。全球范围内Rancher的部署节点已超过10000个，付费客户超过100个。几乎每天都有用户和客户告诉我们，Rancher让他们在生产中运行Docker和Kubernetes变得容易。我们深感感谢，是用户们的激励让Rancher软件变得更好。我还要特别感谢我们的客户，感谢他们对Rancher软件的持续发展提供了资金上的支持！
Rancher 1.0中有一个易于使用的容器编排框架，称为Cattle。且Rancher1.0支持所有主流的容器编排框架，包括Swarm、Mesos和Kubernetes。一个容器管理平台，多个编排框架供其选择，这是Rancher用户一直喜欢Rancher的原因之一。
然而，去年Kubernetes的增长远远高于其他编排引擎。Rancher用户希望在Kubernetes之上得到更好的用户体验和更多的功能。因此，我们决定重新设计Rancher 2.0，将过去大受用户欢迎的Rancher用户体验（即Cattle）架构于Kubernetes之上，从而充分利用Kubernetes的强大力量。
在Rancher 2.0中：
- Cattle用户依然可以享受和以前一样的易于使用的用户体验，还可以额外地利用Kubernetes编排引擎的优势，包括其丰富的基础设施插件、增强的RBAC功能和原生生态系统服务。
- Kubernetes用户可以享受独有的Rancher用户体验和Rancher应用服务目录。
我们的Kubernetes之旅
2015年，当我们刚开始在Rancher中纳入对Kubernetes的支持时，那时的Kubernetes用户面临的最大挑战就是如何安装和配置Kubernetes集群。那时候，Kubernetes自己的脚本和工具很难使用，而且不可靠。但在Rancher中，Kubernetes集群的设置只需一键即可完成。更重要的是，Rancher允许您在任何基础架构上设置Kubernetes集群，包括公有云、vSphere集群和裸机服务器。因此，Rancher很快成为启动Kubernetes集群的最受欢迎的方式之一。
在2016年初，市场上已经有许多现成的和第三方的Kubernetes安装程序。我们的问题不再是如何安装和配置Kubernetes，而是如何持续地运行和升级Kubernetes集群。我们在Rancher中构建了很多功能，用户可以很容易地操作和升级Kubernetes集群及其etcd数据库。
到2016年底，我们开始注意到，Kubernetes运营软件的价值正在迅速下降，这一趋势的出现有两个因素。首先，诸如Kubernetes Operations（kops）等开源工具已经成熟，许多机构与企业能够轻松地在AWS上运行Kubernetes。第二，Kubernetes-as-a-Service（Kubernetes即服务）开始受欢迎。例如，Google Cloud客户不再需要配置和操作自己的集群。他们可以依靠Google——Kubernetes技术的发明者，为他们运行Kubernetes。
#KUBERNETES EVERYWHERE
2016年初，Google Kubernetes项目的创始人、后来创立了Kubernetes公司Heptio的Joe Beda，曾跟我谈及他的“Kubernetes Everywhere”的愿景，他希望Kubernetes可以和无处不在的IaaS相抗衡。
2017年，Kubernetes的流行度在持续上升，且这一势头从未放缓。我们有理由相信在不远的未来，所有基础设施供应商都将提供Kubernetes-as-a-Service。那一天到来的时候，Kubernetes将成为通用的基础设施标准。DevOps团队将不再需要自己操作Kubernetes集群。而唯一剩下的挑战将是如何简单而统一地管理和利用各基础设施上的Kubernetes集群。
基于Kubernetes的Rancher2.0平台
Rancher2.0是一个基于Kubernetes的成熟的容器管理平台。下图展示了Rancher拥有的功能。
与Rancher1.0不同，Rancher server2.0包含了一个嵌入式的Kubernetes主机。这意味着一旦你开始使用Rancher，比如执行命令
docker run -d -p 8080:8080 rancher/server
马上就有一个Kubernetes集群供你启动和执行，无需再为创建Kubernetes做更多的操作。在这之后，每一个添加的主机都会自动安装Kubelet，并成为Kubernetes集群的一部分。
你可以使用相同的嵌入式Kubernetes主机来创建额外的集群。我们已经建立了一个定制的多租户Kubernetes API服务器，它能够最大限度地减少多个Kubernetes集群所需的资源。
我们认为Kubernetes-as-a-service在未来会成为常态，会越来越少使用嵌入式Kubernetes主机。Rancher2.0能够支持导入和管理由云服务商（例如Google容器引擎GKE)）控制的Kubernetes集群，当然还有使用其他工具（如kops）建立的Kubernetes集群。
#对多个集群的单点控制和可视化
IT管理员可以使用嵌入式的Kubernetes主机创建几个Kubernetes集群，或者导入几个现有的Kubernetes集群，然后使用Rancher作为对多个集群的单点控制和管理平台。
我们举一个例子来说明IT管理员是如何在Rancher中使用centralized RBAC和认证功能的。想象一下，如果企业直接使用Google Container Engine（GKE）作为部署容器应用的标准平台，而GKE却要求每个用户都需要有Google账户，这显然不是大多企业的标准做法。通过Rancher，IT管理员可以使用单一的服务账户将GKE集群导入Rancher，然后就能够用企业现有的ActiveDirectory凭证对其他用户进行身份验证。
#全新的UI
很多用户告诉我们，他们非常喜欢Rancher的UI。在2.0版本我们做得更加美观了！我们自己也很喜欢它的设计，并且也希望把它做得更棒。在默认设置下，2.0的UI提供一个简单的容器视图，对容器只有初步了解的人都可以很轻松地开始使用Kubernetes。高级用户他们仍然可以访问Kubectl和Kubernetes dashboard。其次，Rancher应用服务目录Catalog的使用体验进一步优化，通过简单的鼠标点击不仅可以部署应用程序，还可以在部署后轻松地访问和管理应用。Rancher2.0的UI扩展了更多的容器、服务和主机，并且保持了高度响应，如果你喜欢Rancher 1.X的UI，那么你一定会更喜欢2.0。
#未来，还有更多......
我们现在发布的是一个早期的技术预览，我们现在仍有很多未完成的工作，目前还在忙于修复bug并添加诸如HA部署、RBAC和身份认证、集成CI/CD、监控和日志等等这些特性。我们将会持续发布新的版本，敬请关注，也请一如既往地给我们更多反馈与意见，让我们可以做得更好！
原文来源：Rancher Labs
使用容器和Elasticsearch集群对Twitter进行监控
Rancher 发表了文章 • 1 个评论 • 1989 次浏览 • 2017-05-11 08:56
实战经验分享，教你如何使用容器和Elasticsearch集群实现对Twitter上的特定话题（hashtag）与品牌（brand）的监控。
介绍
Elasticsearch是ELK（Elasticsearc ...查看全部
实战经验分享，教你如何使用容器和Elasticsearch集群实现对Twitter上的特定话题（hashtag）与品牌（brand）的监控。
介绍
Elasticsearch是ELK（Elasticsearch/Logstash/Kibana）的基石。在这篇文章中，我们将使用Rancher Catalog来部署stack，并将它用于追踪Twitter上的tag和brand。
追踪Twitter上的hashtag对于衡量基于Twitter的营销活动的影响力是非常有用的。你可以从中提取出诸如您的推文被转发的次数，你的营销活动为你带来了多少位新的关注者等有效信息。
安装ELK stack
#Elasticsearch
若你已经有了一个正在工作中的Elasticsearch集群，现在只需要调整一些集群中的配置即可。我们将使用JSON创建一个索引模板，来调整相关配置。
现在我们给我们的索引模板起个名字，并且推动其配置。Elasticsearch集群的配置就到这里。现在让我们接着往下走。#LogstashLogstash让你能够分析所获得的数据并且将数据传输至你的Elasticsearch集群中。它原生支持很多数据源（如Twitter APIs、collectd、Apache日志等）。在处理你的数据时，Logstash可以帮助你解压或格式化你数据中的正确部分。这样，你就不必推送一些不必要的或者（更糟的）错误数据，这些脏数据会使你的Kibana dashboard与实际情况不相符。在我们开始之前，需要创建Twitter应用密钥需要特别关注以下内容：最后，选择“elasticsearch-clients as the Elasticsearch stack/service”，点击“launch”按钮即可！接下来的事情Rancher将会帮你做完，包括部署一个完全配置好的Logstash。如果一切顺利，在几分钟之内，你应该能看到数据已经被加入到了你的Elasticsearch主页中。你可以在http://[你的ElasticSearch主机地址]/#kopt 中查看。#KibanaKibana能帮助你根据Elasticsearch集群中的数据创建一个强大的dashboard。要部署Kibana，你只需要做两件事情：选择正确的Rancher Catalog版本，然后将它连接到elasticsearch-clients容器中。这样，一个配置正确的Kibana已经准备好被使用了！后续我们还将会对它进行一些配置。现在，整个ELK栈就部署好了。虽然Elasticsearch和Logstash已经部署好了，我们还是需要对Kibana进行一些操作。在这个例子中，我们只需要在Kibana中导入一个JSON仪表盘即可。
剩下的就是在Kibana中创建一个适当的索引设置了。
前往“Indices”页面，然后点击“New”按钮。你应该能看到被创建好的索引和被选择了的@timestamp（时间戳）。
到目前位置，你已经有了一个帮助你监控Twitter上的hashtag和brand的Kibana dashboard。要加载被导入的dashboard，你只需要在这里点击它的名字即可。
几分钟后，重新查看dashboard，你会看到类似下图的界面：
至此，你就能成功监测Twitter上的tag和brand的情况啦！
原文来源：Rancher Labs
介绍
Elasticsearch是ELK（Elasticsearch/Logstash/Kibana）的基石。在这篇文章中，我们将使用Rancher Catalog来部署stack，并将它用于追踪Twitter上的tag和brand。
追踪Twitter上的hashtag对于衡量基于Twitter的营销活动的影响力是非常有用的。你可以从中提取出诸如您的推文被转发的次数，你的营销活动为你带来了多少位新的关注者等有效信息。
安装ELK stack
#Elasticsearch
若你已经有了一个正在工作中的Elasticsearch集群，现在只需要调整一些集群中的配置即可。我们将使用JSON创建一个索引模板，来调整相关配置。
- 在GitHub上获取JSON模板
- 在你的浏览器中输入http://[你的kopf在rancher主机上的路径]
- 在kopf中，点击“more”，然后在下拉菜单中选择“index templates”
现在我们给我们的索引模板起个名字，并且推动其配置。- 使用twitter_elk_example作为模板名称
- 粘贴你之前下载的JSON文件中的内容
- 点击“save”按钮
Elasticsearch集群的配置就到这里。现在让我们接着往下走。#LogstashLogstash让你能够分析所获得的数据并且将数据传输至你的Elasticsearch集群中。它原生支持很多数据源（如Twitter APIs、collectd、Apache日志等）。在处理你的数据时，Logstash可以帮助你解压或格式化你数据中的正确部分。这样，你就不必推送一些不必要的或者（更糟的）错误数据，这些脏数据会使你的Kibana dashboard与实际情况不相符。在我们开始之前，需要创建Twitter应用密钥需要特别关注以下内容：- Consumer Key
- Consumer Secret
- Access Token
- Access Token Secret
现在跳转到目录页并选择Logstash（最好是最新的版本）。你需要在“Logstash inputs*”输入框中加入以下内容（用你自己的APIs认证密钥替换CAP文本）：注意：确保你所有的Rancher主机的时钟均已同步，否则你将无法正确地使用Twitter证书。
twitter { consumer_key => "INSERT YOUR CONSUMER KEY" consumer_secret => "INSERT YOUR CONSUMER SECRET" oauth_token => "INSERT YOUR ACCESS TOKEN" oauth_token_secret => "INSERT YOUR ACCESS TOKEN SECRET" keywords => [ "docker", "rancher_labs", "rancher", "kubernetes" ] full_tweet => true }在“Logstash output*”这个输入框中，你需要加入以下内容注意：在关键字数组中，不要使用“@”或者“#”符号，否则Logstash将运行失败并报“unauthorized message”错误。
output { elasticsearch { host => "elasticsearch:9200" protocol => "http" cluster_name => "NAME OF YOUR ELASTICSEARCH CLUSTER" index => "twitter_elk_example" document_type => "tweets" }最后，选择“elasticsearch-clients as the Elasticsearch stack/service”，点击“launch”按钮即可！接下来的事情Rancher将会帮你做完，包括部署一个完全配置好的Logstash。如果一切顺利，在几分钟之内，你应该能看到数据已经被加入到了你的Elasticsearch主页中。你可以在http://[你的ElasticSearch主机地址]/#kopt 中查看。#KibanaKibana能帮助你根据Elasticsearch集群中的数据创建一个强大的dashboard。要部署Kibana，你只需要做两件事情：选择正确的Rancher Catalog版本，然后将它连接到elasticsearch-clients容器中。这样，一个配置正确的Kibana已经准备好被使用了！后续我们还将会对它进行一些配置。现在，整个ELK栈就部署好了。虽然Elasticsearch和Logstash已经部署好了，我们还是需要对Kibana进行一些操作。在这个例子中，我们只需要在Kibana中导入一个JSON仪表盘即可。- 点击这里获取JSON文件
- 进入Settings –> Object，然后点击“import”，接下来选择刚刚下载好的文件。你应该会看到类似于下图的界面。
剩下的就是在Kibana中创建一个适当的索引设置了。
前往“Indices”页面，然后点击“New”按钮。你应该能看到被创建好的索引和被选择了的@timestamp（时间戳）。
到目前位置，你已经有了一个帮助你监控Twitter上的hashtag和brand的Kibana dashboard。要加载被导入的dashboard，你只需要在这里点击它的名字即可。
几分钟后，重新查看dashboard，你会看到类似下图的界面：
至此，你就能成功监测Twitter上的tag和brand的情况啦！
原文来源：Rancher Labs
德国KubeCon直击：如何轻松且安心地将k8s用于生产？
Rancher 发表了文章 • 1 个评论 • 2123 次浏览 • 2017-03-31 10:17
想要在生产环境中成功部署容器，你需要的不仅仅是容器编排。
2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubernetes、Linkerd、OpenTracing等多个开 ...查看全部
想要在生产环境中成功部署容器，你需要的不仅仅是容器编排。
2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubernetes、Linkerd、OpenTracing等多个开源云原生社区的领先技术专家正汇聚一堂，以进一步推动云原生计算的教育和发展。
Rancher Labs同样亮相此届KubeCon，为大家带来了Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
Kubernetes是一个优秀的容器编排工具，但真正配置和部署Kubernetes往往很困难，企业用户想在生产环境中使用Kubernetes更是顾虑重重。乘着KubeCon的东风，一起来看看Rancher是如何让Kubernetes更易用、如何完美支持企业级生产环境的。
Kubernetes：优秀的容器编排工具
Kubernetes是用于部署和管理容器化应用程序的开源容器编排器。凭借在Google上运行生产环境工作负载15年的经验，它提供了容器固有的优势，同时使DevOps团队能够根据自己的需求，构建定制化的容器就绪环境。
Kubernetes架构由松耦合的组件与丰富的API组成，这使得Kubernetes非常适合运行高度分布式的应用程序架构，包括微服务、单片Web应用程序和批处理应用程序。在生产中，这些应用程序通常跨多个容器和多个服务器主机，这些服务器主机相互连接以形成集群。
Kubernetes提供了为分布式应用程序工作负载部署容器所需的编排和管理功能。它使用户能够构建多容器应用程序服务，并在集群中调度容器以及管理容器的运行状况。由于这些操作任务是自动化的，所以DevOps团队通过容器可以执行许多与其他应用程序平台相同的操作。
配置和部署Kubernetes？可能很困难
人们普遍认为Kubernetes是成功地大规模部署容器的关键。如果您在云端或合理的同质基础架构中运行单个Kubernetes集群，则可能是这样。然而，许多机构具有不同的应用组合和用户需求，因此他们的需求就更广泛和多样化。在这些情况下，设置和配置Kubernetes以及自动化基础架构部署将带来以下几个挑战：
Rancher，让Kubernetes无比简单
通过赋予开发、测试和生产环境中的代码以可移植性，容器使软件开发变得格外容易。一旦投入生产，许多组织都希望Kubernetes能够管理和扩展容器化的应用程序和服务。但是，设计、定制和运行Kubernetes，以及将编工具器与不断变化的技术组合在一起，带来的，是陡峭的学习曲线。
Rancher容器管理平台使您可以轻松管理运行容器需要的一切。 您不再必须需要整合和维护一套复杂的开源技术所需的技术技能。 Rancher不是Docker编排工具，它是最完整的容器管理平台。
Ranche能为用户提供在各类基础设施上部署和使用Kubernetes 所需要的一切，包括：
企业级Kubernetes发行版Rancher为用户提供了已通过认证、提供企业级技术支持的Kubernetes发行版。通过Rancher，您可以轻松利用久经考验且稳定的Kubernetes功能。只需几分钟，在极易于使用的Rancher界面上，你就能轻松启动Kubernetes了。为了确保在所有公共和私有云环境中保持一致的体验，您可以利用Rancher来管理底层容器、执行命令和获取日志。您还可以用它来保持使用最新的Kubernetes稳定版本，并及时采用上游错误修复。您不用再被旧的、过时的和专有的技术所困扰。Kubernetes Dashboard可以通过Rancher自动启动，并可用于每个Kubernetes环境。Helm也能自动用于每个Kubernetes环境，并且每一个开箱即用的kubectl shell控制台中都包含一个方便的Helm客户端。企业级生产环境？完美支持！Rancher既让用户可以轻松使用开源的Kubernetes，还同时遵守企业安全和可用性标准。通过安全的多租户环境，隔离集群内的资源并确保控制分离，Rancher让企业可以安心使用Kubernetes。私有registry可以用Kubernetes配置并且紧密耦合到基础集群配置。（例如Google Cloud Platform registry只能在GCP集群中使用。）诸如基于角色的访问控制、与LDAP和活动目录的集成、详细的审计日志、高可用性、计量（通过Heapster）和加密网络等功能都可以开箱即用。企业级的24x7x365支持让您可以放心地在任意规模的生产环境中部署Kubernetes和容器。多集群，多云部署？没问题！Rancher可以运行多节点、多云集群，甚至部署全状态应用程序。通过容器，Kubernetes集群可以跨越多个资源池和云。而使用Docker machine driver或手动的agent注册添加的所有主机，都将自动添加到Kubernetes集群。用户可以使用可插拔的基础架构服务创建多个Kubernetes集群，这些服务可以以Rancher环境的形式轻松且重复地部署。通过基于角色的访问控制（RBAC），用户可以对这些环境中的每个访问权限进行管理。Rancher用户界面简单易用，并对所有主机以及运行在这些主机中的容器及其总体状态提供了完全可视性。但是，你需要的不仅仅是容器编排...Kubernetes正在成长为一个稳定的平台。它的应用情况及生态系统的发展都很快。然而，同样不应忽视的是，容器应用的最终目标是为开发人员创建应用程序以及更轻松高效地对它们进行管理。应用程序部署和管理不仅仅需要编排。例如，你还需要诸如负载均衡器和DNS的服务来运行应用程序。可定制的基础架构服务Rancher容器管理平台可以轻松地定义和保存各种网络组合、存储和负载平衡器驱动程序。这使得用户在任何基础设施上进行重复且一致的部署，无论是在公有云、私有云、虚拟化集群、还是物理机服务器上。与Rancher集成的服务包括：
如果您选择在原生的Kubernetes上部署ingress controller，则每个提供商都将拥有自己的代码库和一组配置值。Rancher负载均衡器可以进行高级定制，以满足用户的各类需求。Rancher的ingress controller让您可以灵活选择您想要的负载均衡器（包括HAproxy、Traefik和nginx），而配置界面保持不变。Rancher还提供扩展负载均衡器、自定义负载均衡器源端口以及在特定的主机集上调度负载均衡器的功能。
完整的容器管理平台
您现在可能已经有一个比较清晰的概念了，但要知道，Rancher不单纯是容器编排器。它是一个完整的容器管理平台，其中包括管理生产中的容器所需的一切。您可以通过使用Rancher在跨云平台上一键部署和运行多个集群，或从Rancher集成和支持的容器编排器发行版中进行自主选择，包括Kubernet、Mesos、Docker Swarm和Windows。可插拔基础架构服务为基础设施提供商的可移植性提供了基础。
无论是在单个本地集群上运行容器，抑或在Amazon AWS和其他服务提供商上运行的多个集群，Rancher正迅速成为千千万万个Kubernetes用户的首选容器管理平台。
开始使用容器、Kubernetes和Rancher吧！
3月29日-30日正在柏林举办的CloudNativeCon+KubeCon Europe 2017上，Rancher Labs在S17号展位，为您演示Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
原文来源：Rancher Labs
2017年CloudNativeCon+KubeCon Europe正在柏林盛大举行，来自Fluented、Kubernetes、Linkerd、OpenTracing等多个开源云原生社区的领先技术专家正汇聚一堂，以进一步推动云原生计算的教育和发展。
Rancher Labs同样亮相此届KubeCon，为大家带来了Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
Kubernetes是一个优秀的容器编排工具，但真正配置和部署Kubernetes往往很困难，企业用户想在生产环境中使用Kubernetes更是顾虑重重。乘着KubeCon的东风，一起来看看Rancher是如何让Kubernetes更易用、如何完美支持企业级生产环境的。
Kubernetes：优秀的容器编排工具
Kubernetes是用于部署和管理容器化应用程序的开源容器编排器。凭借在Google上运行生产环境工作负载15年的经验，它提供了容器固有的优势，同时使DevOps团队能够根据自己的需求，构建定制化的容器就绪环境。
Kubernetes架构由松耦合的组件与丰富的API组成，这使得Kubernetes非常适合运行高度分布式的应用程序架构，包括微服务、单片Web应用程序和批处理应用程序。在生产中，这些应用程序通常跨多个容器和多个服务器主机，这些服务器主机相互连接以形成集群。
Kubernetes提供了为分布式应用程序工作负载部署容器所需的编排和管理功能。它使用户能够构建多容器应用程序服务，并在集群中调度容器以及管理容器的运行状况。由于这些操作任务是自动化的，所以DevOps团队通过容器可以执行许多与其他应用程序平台相同的操作。
配置和部署Kubernetes？可能很困难
人们普遍认为Kubernetes是成功地大规模部署容器的关键。如果您在云端或合理的同质基础架构中运行单个Kubernetes集群，则可能是这样。然而，许多机构具有不同的应用组合和用户需求，因此他们的需求就更广泛和多样化。在这些情况下，设置和配置Kubernetes以及自动化基础架构部署将带来以下几个挑战：
- 创建根据DevOps团队的需求定制的Kubernetes环境
- 自动部署多个Kubernetes集群
- 管理Kubernetes群集的健康（例如检测和解决etcd节点的故障）
- 自动升级Kubernetes集群
- 在本地和/或不同云提供商部署多个集群
- 确保能满足企业级的需求，包括提供24×7企业级技术支持
- 自定义然后重复部署基础设施和其他服务（例如存储、网络、DNS、负载平衡器）的多重组合
- 部署和管理Kubernetes附件的升级，如Dashboard、Helm和Heapster
Rancher，让Kubernetes无比简单
通过赋予开发、测试和生产环境中的代码以可移植性，容器使软件开发变得格外容易。一旦投入生产，许多组织都希望Kubernetes能够管理和扩展容器化的应用程序和服务。但是，设计、定制和运行Kubernetes，以及将编工具器与不断变化的技术组合在一起，带来的，是陡峭的学习曲线。
Rancher容器管理平台使您可以轻松管理运行容器需要的一切。 您不再必须需要整合和维护一套复杂的开源技术所需的技术技能。 Rancher不是Docker编排工具，它是最完整的容器管理平台。
Ranche能为用户提供在各类基础设施上部署和使用Kubernetes 所需要的一切，包括：
- 已通过认证、提供企业级技术支持的Kubernetes发行版，具有简化的配置选项
- 包括负载平衡器、跨主机网络、存储驱动程序和安全凭证管理等在内的基础设施服务
- Kubernetes集群的自动部署和升级
- 多集群和多云支持
- 企业级功能，如基于角色的访问控制和24×7支持
企业级Kubernetes发行版Rancher为用户提供了已通过认证、提供企业级技术支持的Kubernetes发行版。通过Rancher，您可以轻松利用久经考验且稳定的Kubernetes功能。只需几分钟，在极易于使用的Rancher界面上，你就能轻松启动Kubernetes了。为了确保在所有公共和私有云环境中保持一致的体验，您可以利用Rancher来管理底层容器、执行命令和获取日志。您还可以用它来保持使用最新的Kubernetes稳定版本，并及时采用上游错误修复。您不用再被旧的、过时的和专有的技术所困扰。Kubernetes Dashboard可以通过Rancher自动启动，并可用于每个Kubernetes环境。Helm也能自动用于每个Kubernetes环境，并且每一个开箱即用的kubectl shell控制台中都包含一个方便的Helm客户端。企业级生产环境？完美支持！Rancher既让用户可以轻松使用开源的Kubernetes，还同时遵守企业安全和可用性标准。通过安全的多租户环境，隔离集群内的资源并确保控制分离，Rancher让企业可以安心使用Kubernetes。私有registry可以用Kubernetes配置并且紧密耦合到基础集群配置。（例如Google Cloud Platform registry只能在GCP集群中使用。）诸如基于角色的访问控制、与LDAP和活动目录的集成、详细的审计日志、高可用性、计量（通过Heapster）和加密网络等功能都可以开箱即用。企业级的24x7x365支持让您可以放心地在任意规模的生产环境中部署Kubernetes和容器。多集群，多云部署？没问题！Rancher可以运行多节点、多云集群，甚至部署全状态应用程序。通过容器，Kubernetes集群可以跨越多个资源池和云。而使用Docker machine driver或手动的agent注册添加的所有主机，都将自动添加到Kubernetes集群。用户可以使用可插拔的基础架构服务创建多个Kubernetes集群，这些服务可以以Rancher环境的形式轻松且重复地部署。通过基于角色的访问控制（RBAC），用户可以对这些环境中的每个访问权限进行管理。Rancher用户界面简单易用，并对所有主机以及运行在这些主机中的容器及其总体状态提供了完全可视性。但是，你需要的不仅仅是容器编排...Kubernetes正在成长为一个稳定的平台。它的应用情况及生态系统的发展都很快。然而，同样不应忽视的是，容器应用的最终目标是为开发人员创建应用程序以及更轻松高效地对它们进行管理。应用程序部署和管理不仅仅需要编排。例如，你还需要诸如负载均衡器和DNS的服务来运行应用程序。可定制的基础架构服务Rancher容器管理平台可以轻松地定义和保存各种网络组合、存储和负载平衡器驱动程序。这使得用户在任何基础设施上进行重复且一致的部署，无论是在公有云、私有云、虚拟化集群、还是物理机服务器上。与Rancher集成的服务包括：- 具有多个负载均衡器的ingress controller（HAproxy、traefik等）
- IPSEC和VXLAN所需的跨主机网络驱动程序
- 存储驱动程序
- 证书和安全凭证管理
- 私有registry的凭证管理
- 代替 SkyDNS 的DNS服务
- 高度可定制的负载均衡器
如果您选择在原生的Kubernetes上部署ingress controller，则每个提供商都将拥有自己的代码库和一组配置值。Rancher负载均衡器可以进行高级定制，以满足用户的各类需求。Rancher的ingress controller让您可以灵活选择您想要的负载均衡器（包括HAproxy、Traefik和nginx），而配置界面保持不变。Rancher还提供扩展负载均衡器、自定义负载均衡器源端口以及在特定的主机集上调度负载均衡器的功能。
完整的容器管理平台
您现在可能已经有一个比较清晰的概念了，但要知道，Rancher不单纯是容器编排器。它是一个完整的容器管理平台，其中包括管理生产中的容器所需的一切。您可以通过使用Rancher在跨云平台上一键部署和运行多个集群，或从Rancher集成和支持的容器编排器发行版中进行自主选择，包括Kubernet、Mesos、Docker Swarm和Windows。可插拔基础架构服务为基础设施提供商的可移植性提供了基础。
无论是在单个本地集群上运行容器，抑或在Amazon AWS和其他服务提供商上运行的多个集群，Rancher正迅速成为千千万万个Kubernetes用户的首选容器管理平台。
开始使用容器、Kubernetes和Rancher吧！
3月29日-30日正在柏林举办的CloudNativeCon+KubeCon Europe 2017上，Rancher Labs在S17号展位，为您演示Rancher针对不同基础设施的Kubernetes容器管理的最新增强功能。
原文来源：Rancher Labs
Rancher平台部署Percona XtraDB Cluster数据库集群
Rancher 发表了文章 • 1 个评论 • 2652 次浏览 • 2016-12-26 10:15
各种MySQL数据库集群高可用方案
https://bobcares.com/blog/mysql-high-availability-top-7-solutions/
Redundant de ...查看全部
各种MySQL数据库集群高可用方案
https://bobcares.com/blog/mysql-high-availability-top-7-solutions/
PXC技术概要
Percona XtraDB Cluster与MySQL Replication区别在于：
分布式系统的CAP理论：
C：一致性，所有节点的数据一致；
A：可用性，一个或多个节点失效，不影响服务请求；
P：分区容忍性，节点间的连接失效，仍然可以处理请求；
任何一个分布式系统，需要满足这三个中的两个。
MySQLReplication：可用性和分区容忍性；
Percona XtraDBCluster：一致性和可用性。
因此MySQL Replication并不保证数据的一致性，而Percona XtraDB Cluster提供数据一致性。
Percona XtraDBCluster是MySQL高可用性和可扩展性的解决方案。Percona XtraDBCluster提供的特性有：
Percona XtraDBCluster完全兼容MySQL和Percona Server，表现在：
它的集群特点是：
优点如下：
缺点如下：
PXC的传统物理机三节点部署简要说明
那么这样一个MySQL集群方案，在我们传统的物理机环境的安装部署，是否会很复杂呢？熟悉其组件及工作原理之后，安装倒是不特别复杂。我们以CentOS系列为范例，简要看看其安装配置流程：
PXC在Rancher容器管理平台的部署
Percona作为标准的Catalog项目出现在Rancher Server1.1版本之后，如果你使用的是较低的版本，例如v1.0.1，在数据库分类里将只会见到MariaDB Galera Cluster项目。当然你可以在低版本中添加自定义的Catalog，例如
https://github.com/alanpeng/MyRancherCatalog.git
部署好的Percona XtraDB Cluster集群宿主机结构如图所示（除了拉起Percona-XtraDB-Cluster集群之外，还在其前端加入了一个Rancher内置的LoadBalancer）：
将此Catalog项目打开，我们可以看见其docker-compose.yml及rancher-compose.yml文件的内容如下：
Stack/Service结构示意图：
这里的12个容器角色如下：Node节点3个，运行confd服务；ClusterCheck节点3个分别监听集群节点健康状态；Server节点3个，是数据库主服务应用；3个Data作为数据卷共享的提供，是sidekick容器类型。
所有容器列表如下：
数据库连接验证测试：
从前端负载均衡宿主机的IP访问数据库，执行语句show status like 'wsrep%'；返回的结果表明数据库集群节点数为3，同步复制状态正常。
在Rancher平台如何灵活运用Confd+Metadata进行配置管理
以上PXC集群运行于容器之上并被Rancher平台管理，其中的具体实现细节较多，因为我们需要这样的数据库集群满足弹性伸缩的要求，举例来说也就是可以动态的将集群节点数由3个增加至更多，那么必然每个节点的配置文件需要动态的进行更新，要做到这一点，我们可以结合confd与Rancher的metadata元数据服务来实现，当然这里涉及到数据库集群专有的技术，giddyup专有工具的结合也是必不可少的选择。
1. 首先给出整个项目的代码文件供参考
分3个模块：
https://github.com/Flowman/docker-pxc
https://github.com/Flowman/docker-pxc-confd
https://github.com/Flowman/docker-pxc-clustercheck
2. 数据库集群配置工具giddyup
https://github.com/cloudnautique/giddyup
在数据库集群服务的启动脚本
https://github.com/Flowman/docker-pxc/blob/master/start_pxc里我们使用了giddyup工具，其中比较重要的命令有以下项：
获取集群节点成员IP列表，请参照本篇前面章节中my.cnf文件中提及的wsrep_cluster_address=gcomm:// …
获取集群运行状态并返回节点规模数
探测当前容器节点是否属于数据库集群的bootstrap角色（leader）
3. 配置管理工具confd
https://github.com/kelseyhightower/confd 它对rancher提供了很好的支持，能够与Rancher的metadata元数据服务紧密结合：
如何与元数据结合？confd有两个重要文件，一个是模板文件，一个是配置文件，其执行过程就是从backends对象例如Rancher的metadata获取数据，然后将其更新至真正被服务调用的配置文件中去：
这里的pxc.cnf.tmpl文件是模板文件，而pxc.toml文件则是配置文件。confd的配置文件是建立一个服务，监控特定的backends对象（例如etcd、rancher元数据等等）的键值以及当值发生变化时执行某些操作。其文件格式是TOML，易于使用，其规则跟人的直觉也相近。我们可以看到容器执行期间，Rancher预先在rancher-compose.yml中定义的metadata元数据通过confd将一些重要参数传递给了数据库集群服务的配置文件my.cnf：
我们知道Rancher的metadata元数据是有版本差异的，那么如何知道在这个PXC数据库集群里它调用的元数据从何而来呢？
看一下Dockerfile的内容我们不难发现
https://github.com/Flowman/docker-pxc-confd/blob/master/Dockerfile
这里从mysql元数据服务项返回的值正是我们在rancher-compose.yml文件中预先定义好了的：
从Percona XtraDB Cluster这个Rancher的Catalog项目，我们可以较为全面的理解confd配置服务是如何与Rancher的元数据服务进行结合的，这样就能实现较为复杂的数据库集群应用完全自动化的实现弹性伸缩功能。
Q & A
Q：如果在k8s环境部署mysql集群，用什么方案比较好？
A：Rancher的k8s里面的模板没有cattle环境的模板多，Cattle的模板是没有办法直接拿到K8s环境里面来用的，k8s的模板是k8s的yaml文件结合rancher-compose文件。Rancher官网blog有一篇是关于如何转换Prometheus的cattle模板成为k8s模板的，有兴趣的话可以参考一下：http://rancher.com/converting-prometheus-template-cattle-kubernetes/
原文来源：Rancher Labs
https://bobcares.com/blog/mysql-high-availability-top-7-solutions/
- Redundant devices to combat hardware failures
- Shared storage with SAN and NAS
- Storage replication using DRBD
- MySQL replication to avoid single point failures
- MySQL clustering
- Galera multi-master MySQL replication
- Percona XtraDB Cluster
PXC技术概要
Percona XtraDB Cluster与MySQL Replication区别在于：
分布式系统的CAP理论：
C：一致性，所有节点的数据一致；
A：可用性，一个或多个节点失效，不影响服务请求；
P：分区容忍性，节点间的连接失效，仍然可以处理请求；
任何一个分布式系统，需要满足这三个中的两个。
MySQLReplication：可用性和分区容忍性；
Percona XtraDBCluster：一致性和可用性。
因此MySQL Replication并不保证数据的一致性，而Percona XtraDB Cluster提供数据一致性。
Percona XtraDBCluster是MySQL高可用性和可扩展性的解决方案。Percona XtraDBCluster提供的特性有：
- 同步复制，事务要么在所有节点提交或不提交。
- 多主复制，可以在任意节点进行写操作。
- 在从服务器上并行应用事件，真正意义上的并行复制。
- 节点自动配置。
- 数据一致性，不再是异步复制。
Percona XtraDBCluster完全兼容MySQL和Percona Server，表现在：
- 数据的兼容性
- 应用程序的兼容性：无需更改应用程序
它的集群特点是：
- 集群是有节点组成的，推荐配置至少3个节点，但是也可以运行在2个节点上。
- 每个节点都是普通的mysql/percona服务器，可以将现有的数据库服务器组成集群，反之，也可以将集群拆分成单独的服务器。
- 每个节点都包含完整的数据副本。
优点如下：
- 当执行一个查询时，在本地节点上执行。因为所有数据都在本地，无需远程访问。
- 无需集中管理。可以在任何时间点失去任何节点，但是集群将照常工作。
- 良好的读负载扩展，任意节点都可以查询。
缺点如下：
- 加入新节点，开销大。需要复制完整的数据。
- 不能有效的解决写缩放问题，所有的写操作都将发生在所有节点上。
- 有多少个节点就有多少重复的数据。
PXC的传统物理机三节点部署简要说明
那么这样一个MySQL集群方案，在我们传统的物理机环境的安装部署，是否会很复杂呢？熟悉其组件及工作原理之后，安装倒是不特别复杂。我们以CentOS系列为范例，简要看看其安装配置流程：
PXC在Rancher容器管理平台的部署
Percona作为标准的Catalog项目出现在Rancher Server1.1版本之后，如果你使用的是较低的版本，例如v1.0.1，在数据库分类里将只会见到MariaDB Galera Cluster项目。当然你可以在低版本中添加自定义的Catalog，例如
https://github.com/alanpeng/MyRancherCatalog.git
部署好的Percona XtraDB Cluster集群宿主机结构如图所示（除了拉起Percona-XtraDB-Cluster集群之外，还在其前端加入了一个Rancher内置的LoadBalancer）：
将此Catalog项目打开，我们可以看见其docker-compose.yml及rancher-compose.yml文件的内容如下：
Stack/Service结构示意图：
这里的12个容器角色如下：Node节点3个，运行confd服务；ClusterCheck节点3个分别监听集群节点健康状态；Server节点3个，是数据库主服务应用；3个Data作为数据卷共享的提供，是sidekick容器类型。
所有容器列表如下：
数据库连接验证测试：
从前端负载均衡宿主机的IP访问数据库，执行语句show status like 'wsrep%'；返回的结果表明数据库集群节点数为3，同步复制状态正常。
在Rancher平台如何灵活运用Confd+Metadata进行配置管理
以上PXC集群运行于容器之上并被Rancher平台管理，其中的具体实现细节较多，因为我们需要这样的数据库集群满足弹性伸缩的要求，举例来说也就是可以动态的将集群节点数由3个增加至更多，那么必然每个节点的配置文件需要动态的进行更新，要做到这一点，我们可以结合confd与Rancher的metadata元数据服务来实现，当然这里涉及到数据库集群专有的技术，giddyup专有工具的结合也是必不可少的选择。
1. 首先给出整个项目的代码文件供参考
分3个模块：
https://github.com/Flowman/docker-pxc
https://github.com/Flowman/docker-pxc-confd
https://github.com/Flowman/docker-pxc-clustercheck
2. 数据库集群配置工具giddyup
https://github.com/cloudnautique/giddyup
在数据库集群服务的启动脚本
https://github.com/Flowman/docker-pxc/blob/master/start_pxc里我们使用了giddyup工具，其中比较重要的命令有以下项：
获取集群节点成员IP列表，请参照本篇前面章节中my.cnf文件中提及的wsrep_cluster_address=gcomm:// …
获取集群运行状态并返回节点规模数
探测当前容器节点是否属于数据库集群的bootstrap角色（leader）
3. 配置管理工具confd
https://github.com/kelseyhightower/confd 它对rancher提供了很好的支持，能够与Rancher的metadata元数据服务紧密结合：
如何与元数据结合？confd有两个重要文件，一个是模板文件，一个是配置文件，其执行过程就是从backends对象例如Rancher的metadata获取数据，然后将其更新至真正被服务调用的配置文件中去：
这里的pxc.cnf.tmpl文件是模板文件，而pxc.toml文件则是配置文件。confd的配置文件是建立一个服务，监控特定的backends对象（例如etcd、rancher元数据等等）的键值以及当值发生变化时执行某些操作。其文件格式是TOML，易于使用，其规则跟人的直觉也相近。我们可以看到容器执行期间，Rancher预先在rancher-compose.yml中定义的metadata元数据通过confd将一些重要参数传递给了数据库集群服务的配置文件my.cnf：
我们知道Rancher的metadata元数据是有版本差异的，那么如何知道在这个PXC数据库集群里它调用的元数据从何而来呢？
看一下Dockerfile的内容我们不难发现
https://github.com/Flowman/docker-pxc-confd/blob/master/Dockerfile
这里从mysql元数据服务项返回的值正是我们在rancher-compose.yml文件中预先定义好了的：
从Percona XtraDB Cluster这个Rancher的Catalog项目，我们可以较为全面的理解confd配置服务是如何与Rancher的元数据服务进行结合的，这样就能实现较为复杂的数据库集群应用完全自动化的实现弹性伸缩功能。
Q & A
Q：如果在k8s环境部署mysql集群，用什么方案比较好？
A：Rancher的k8s里面的模板没有cattle环境的模板多，Cattle的模板是没有办法直接拿到K8s环境里面来用的，k8s的模板是k8s的yaml文件结合rancher-compose文件。Rancher官网blog有一篇是关于如何转换Prometheus的cattle模板成为k8s模板的，有兴趣的话可以参考一下：http://rancher.com/converting-prometheus-template-cattle-kubernetes/
原文来源：Rancher Labs
实践指南-快速解锁Rancher v1.2
Rancher 发表了文章 • 1 个评论 • 1822 次浏览 • 2016-12-19 10:09
原文来源：Rancher Labs
引言
Rancher v1.2已经发布，相信众多容器江湖的伙伴们正魔拳擦准备好好体验一番。由于Docker能够落地的操作系统众多，各种Docker版本不同的Graph dr ...查看全部
原文来源：Rancher Labs
引言
Rancher v1.2已经发布，相信众多容器江湖的伙伴们正魔拳擦准备好好体验一番。由于Docker能够落地的操作系统众多，各种Docker版本不同的Graph driver，所以通常大版本的第一个release都会在兼容性上有一些小问题。为了更好的体验Rancher v1.2的完整特性，我们选取了Rancher测试比较严格的运行环境。手握众多服务器资源的devops们可以飘过此文，身背MBP或Windows笔记本的Sales/Pre-Sales们可以品读一番。
基础软件安装
首先需要安装基础软件，由于Rancher v1.2已经支持Docker v1.2，所以可以直接使用Docker的Mac或Windows版（以下以Mac为例），下载地址：https://www.docker.com/。在Mac上，Docker会使用xhyve轻量级虚拟化来保证一个Linux环境，所以可以把Rancher Server直接运行起来。
因为要在MBP上添加多个Host组成小集群，所以需要用虚拟化扩展多个节点添加到Rancher集群中。这里可以使用docker-machine控制VirtualBox来添加节点，VirtualBox下载地址：https://www.virtualbox.org/wiki/Downloads。
在Host节点的操作系统上，可以选取RancherOS，我们的目标是快速体验新特性，而Rancher Labs在Rancher和RancherOS的相互兼容性上是做了大量测试的，这样可以避免我们少进坑，直接体验新特性。RancherOS下载地址：https://github.com/rancher/os，推荐使用最新release版本。
在用docker-machine驱动VirtualBox来创建Host时，可以指定操作系统ISO的URL路径，由于我们使用RancherOS，所以最好把RancherOS放到本机HTTP服务器内。MBP内自带Apache HTTPD，将Apache的vhosts模块开启，并添加配置：
Rancher安装
首先打开Docker，并配置registry mirror，配置完成后重启Docker。mirror的服务可以去各个公用云厂商申请一个，比如我这里使用的是阿里云的registry mirror，如图所示：
打开terminal，安装Rancher Server：
若要添加Host节点，则需要通过docker-machine创建Host，这里使用的规格是2核2G（具体可根据自身MBP的性能调整），脚本（add_ros_host.sh）参考如下：
添加节点则需执行：
添加完成后，可以进入虚机内进行设置：
由于我们要使用VirtualBox的虚机组成一个小集群，所以建议把Rancher的Host Registration URL设置为http://192.168.99.1:8080，如下图所示：
添加Rancher agent的时候也要注意，CATTLE_AGENT_IP参数要设置成虚机内192.168.99.0/24网段的IP，如下图所示：
如此就可以基本完全解锁Rancher v1.2的各种功能了，完整演示各种特性。
总结
Docker目前版本分支众多，虽然最新的v1.13即将发布，但是各个公司的使用版本应该说涵盖了v1.9到v1.12，而且Docker graph driver也有很多，再加上很多的LinuxOS，可以说使用Docker而产生组合有很多种，这就会带来各种各样的兼容性问题，因此导致的生产环境故障会让人头疼不已。当然如果纯粹基于演示和调研新功能，我们可以优先兼容性较好的选择。
引言
Rancher v1.2已经发布，相信众多容器江湖的伙伴们正魔拳擦准备好好体验一番。由于Docker能够落地的操作系统众多，各种Docker版本不同的Graph driver，所以通常大版本的第一个release都会在兼容性上有一些小问题。为了更好的体验Rancher v1.2的完整特性，我们选取了Rancher测试比较严格的运行环境。手握众多服务器资源的devops们可以飘过此文，身背MBP或Windows笔记本的Sales/Pre-Sales们可以品读一番。
基础软件安装
首先需要安装基础软件，由于Rancher v1.2已经支持Docker v1.2，所以可以直接使用Docker的Mac或Windows版（以下以Mac为例），下载地址：https://www.docker.com/。在Mac上，Docker会使用xhyve轻量级虚拟化来保证一个Linux环境，所以可以把Rancher Server直接运行起来。
因为要在MBP上添加多个Host组成小集群，所以需要用虚拟化扩展多个节点添加到Rancher集群中。这里可以使用docker-machine控制VirtualBox来添加节点，VirtualBox下载地址：https://www.virtualbox.org/wiki/Downloads。
在Host节点的操作系统上，可以选取RancherOS，我们的目标是快速体验新特性，而Rancher Labs在Rancher和RancherOS的相互兼容性上是做了大量测试的，这样可以避免我们少进坑，直接体验新特性。RancherOS下载地址：https://github.com/rancher/os，推荐使用最新release版本。
在用docker-machine驱动VirtualBox来创建Host时，可以指定操作系统ISO的URL路径，由于我们使用RancherOS，所以最好把RancherOS放到本机HTTP服务器内。MBP内自带Apache HTTPD，将Apache的vhosts模块开启，并添加配置：
# 开启vhost /etc/apache2/httpd.conf
# 以下两行的默认注释去掉
LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so
Include /private/etc/apache2/extra/httpd-vhosts.conf
# vhost的配置 /etc/apache2/extra/httpd-vhosts.conf
# DocumentRoot目录就是在用户根目录下创建Sites
# 如用户名niusmallnan，则DocumentRoot就是/Users/niusmallnan/Sites
DocumentRoot "/Users/niusmallnan/Sites"
ServerName localhost
ErrorLog "/private/var/log/apache2/sites-error_log"
CustomLog "/private/var/log/apache2/sites-access_log"
common
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
Require all granted
# 重启 Apache
$ sudo apachectl restart
# 拷贝 RancherOS的ISO 到 DocumentRoot
$ cp rancheros.iso /Users/niusmallnan/Sites/
Rancher安装
首先打开Docker，并配置registry mirror，配置完成后重启Docker。mirror的服务可以去各个公用云厂商申请一个，比如我这里使用的是阿里云的registry mirror，如图所示：
打开terminal，安装Rancher Server：
$ docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:stable
若要添加Host节点，则需要通过docker-machine创建Host，这里使用的规格是2核2G（具体可根据自身MBP的性能调整），脚本（add_ros_host.sh）参考如下：
#!/usr/bin/env bash
ROS_ISO_URL='http://127.0.0.1/rancheros.iso'
ROS_CPU_COUNT=2
ROS_MEMORY=2048
docker-machine create -d virtualbox \
--virtualbox-boot2docker-url $ROS_ISO_URL \
--virtualbox-cpu-count $ROS_CPU_COUNT \
--virtualbox-memory $ROS_MEMORY \
$1
docker-machine ls
添加节点则需执行：
$ ./add_ros_host.sh ros-1
添加完成后，可以进入虚机内进行设置：
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
ros-1 - virtualbox Running tcp://192.168.99.100:2376 v1.12.3
# 进入VM中
$ docker-machine ssh ros-1
# RancherOS内设置registry mirror
$ sudo ros config set rancher.docker.extra_args \
"['--registry-mirror','https://s06nkgus.mirror.aliyuncs.com']"
$ sudo system-docker restart docker
由于我们要使用VirtualBox的虚机组成一个小集群，所以建议把Rancher的Host Registration URL设置为http://192.168.99.1:8080，如下图所示：
添加Rancher agent的时候也要注意，CATTLE_AGENT_IP参数要设置成虚机内192.168.99.0/24网段的IP，如下图所示：
如此就可以基本完全解锁Rancher v1.2的各种功能了，完整演示各种特性。
总结
Docker目前版本分支众多，虽然最新的v1.13即将发布，但是各个公司的使用版本应该说涵盖了v1.9到v1.12，而且Docker graph driver也有很多，再加上很多的LinuxOS，可以说使用Docker而产生组合有很多种，这就会带来各种各样的兼容性问题，因此导致的生产环境故障会让人头疼不已。当然如果纯粹基于演示和调研新功能，我们可以优先兼容性较好的选择。
基于Docker运行弹性集群的五个关键点第一篇：运行高可用模式
Rancher 发表了文章 • 1 个评论 • 2884 次浏览 • 2016-11-02 16:34
原文来自：Rancher Labs
当前技术世界的发展形势就是让开发人员从繁琐的应用配置和管理中解放出来，使用容器镜像来处理复杂的程序运行依赖库的需求，保证代码运行环境的一致性。
既然这样的好处是如此 ...查看全部
原文来自：Rancher Labs
当前技术世界的发展形势就是让开发人员从繁琐的应用配置和管理中解放出来，使用容器镜像来处理复杂的程序运行依赖库的需求，保证代码运行环境的一致性。
既然这样的好处是如此清晰，但为什么企业中的基础设施环境没有往容器集群切换呢？关键问题还是风险，新技术意味着未经检验的技术和实践经验的缺乏，这就会带来很多不可预知的风险。
当企业的运维团队去维护一个弹性的容器集群时，传统的软件部署方式需要向容器迁移，这个过程中需要有风险预判和规避之道。而Docker和Rancher正是提供了解决这些风险问题的解决方案，比如基于Rancher的Catalog功能就能快速的完成一些基础软件的部署（比如ElasticSearch）。
在风险管理方面，我们可以看看基于Docker和Rancher来运行弹性集群的五个关键点：
我原本希望展现一下用一台老式笔记本部署Rancher Server，然后用docker-machine加入几个树莓派节点部署Rancher Agent，这样来构建一个Rancher集群。但是这样会有些问题，就是大部分Docker镜像都是基于Intel CPU构建的，这会和树莓派的ARM CPU很不兼容。所以我还是老老实实的用AWS的虚机来构建Rancher集群吧。
初始安装，我们暂时先部署一台Rancher Server和一台Rancher Agent，然后再部署一个简单的多实例应用。
上面这张图展现了我的整个集群的设置，我选择AWS是因为我个人比较熟悉，当然你完全可以选择你擅长的云提供商。
我们可以尝试创建一个Wordpress，顺带来检测一下Rancher是否正确部署了。
这样我们的应用就运行起来了，试想，如果Rancher Server所在服务器出现故障，或者有网络中断问题发生，会对应用产生什么影响，Wordpress还能继续接受请求么？
为了确认我们的疑问，我将会按照下面的步骤执行，然后记录一下其中的运行结果：
最终我们要解决这些问题，那就要看看Rancher HA来怎样解决这些风险。
阻断Rancher Server和Rancher Agent间的网络
进入AWS，然后看我各种犀利的操作：
# 观察结果 #
首先，网络阻断后没过多久Rancher Host就出现了reconnecting状态
此时我依然可以正常访问Wordpress的地址，服务没有中断，IPSec隧道网络还存储，Wordpress实例还是可以正常访问数据库。
现在我们要停掉一个Wordpress实例，看看会发生什么？因为我们已经无法从Rancher UI上管理这些容器了，所以还是到对应的主机上执行docker命令吧。
很遗憾Wordpress容器没有重新启动，这有点麻烦了。我们还是把Rancher Server弄回来吧，看看它能不能感知到其中一个Wordpress容器已经被停掉了。
在各种犀利的操作和等待之后，Rancher Server与Agent重新连接了，Wordpress容器就被重新启动了。完美~
所以我们可以看，Rancher Server还是能够处理间歇性的网络问题，可以实现Rancher Server和Agent的故障重连。但是如果要让网络中断对Rancher的影响进一步减小，那么部署多个Rancher Server就比较重要了。
我们还是回过来，按照先前计划看看Rancher Server 容器停掉后会发生什么？我们会因此失去对这些Rancher Host的管理能力么？看看如何！
停掉Rancher Server
这次我需要登入到Rancher Server的host上手动停止Rancher Server，其实Rancher Server一般是设置 --restart=always，所以自己有一定的恢复能力。但我们可以假设比如磁盘写满了后，Rancher Server真的起不来了。
# 观察结果 #
执行`docker stop rancher-server`之后，Wordpress还是能够正常工作，但是Rancher UI是不能访问了，这可不行，得赶紧把Rancher Server弄回来。
再执行`docker start rancher-server`，Rancher Server启动后又一切恢复正常，这很酷啊，这是什么魔法？赶紧着，麻溜地分析起来！
揭开Rancher Server的神秘面纱
我们来一次对Rancher Server的简要探究之旅，看一看Rancher Server的Dockerfile。
我们可以看到使用了s6-svscan，它可以运行指定的目录结构内的程序，目录内的主要文件就是Run、Down、Finish。下面这张图能看到会运行两个服务cattle（Rancher的核心调度器）和mysql。
其实在容器内部我们也可以看到起了哪些服务。
我们可以看到Rancher的大脑，一个名叫Cattle的Java应用，它需要一个MySQL来存储对应的数据。这确实很方便，但是我们发现这样会有单点故障，所有的数据存储在一个单点的mysql中。如果对mysql中的数据来一些不礼貌的操作，会发生什么呢？
# 破坏MySQL存储数据 #
进入容器中执行一些MySQL命令，我们一起来干点坏事：
结果是可想而知的，Rancher不记得任何事了，你删掉一个Wordpress容器，它也不会恢复。
而且我也删除了network表的数据，Wordpress也不知道如何找到它的MySQL服务了。
显然，若要在生产环境运行Rancher，我们需要一个方式来保护Rancher Server的数据，既然如此那我们就讲一下Rancher HA吧。
Rancher HA安装过程
首先我们要确保数据的安全，我选择了AWS的RDS服务，RDS可以提供一个信赖的MySQL服务，数据安全是可以保证的。当然你也可以使用其他的，我只是对RDS更熟悉一些。
下面我们继续Rancher HA的安装过程：
按照我们之前的约定，我是创建了RDS的MySQL实例，然后把它当做外部数据库和Rancher Server连接。
一旦我们使用了外部数据库模式，UI上将会打开两个选项来设置HA。
怎么办！选择困难症啊！没关系，我来解释一下每个选项的含义。
Cluster size，注意这里怎么都是奇数？因为在后端，Rancher会设置一个ZooKeeper Quorum保证锁同步，ZooKeeper推荐奇数集群，因为偶数节点数量不能提供额外的容错性。我们这里就选择3个Host吧，这是一个可用和易用的平衡。
Host registration URL，这里是填写一个Rancher Cluster入口的FQDN，推荐使用外部负载均衡服务或者DNS服务（round robin策略）。比如图中我使用的是支持SRV记录的DNS服务，通过DNS来做三个Rancher Server的负载均衡：
SSL Certificates是列表中的最后一个选项，如果你有域名的SSL证书可以配置在这里，否则Rancher会自动生成一个自签名证书。
所有都填完后，就会给你提供一个rancher-ha.sh的脚本来下载。
有了脚本就可以到每个Rancher Server节点上执行了，执行前还需要注意目前只能支持docker v1.10.3。安装指定版本的Docker Engine，可以参考下面的方式：
Docker安装之后，就要确认一下端口开放了，需要开放哪些端口可以看这里，不过如果是第一次安装，我建议你把端口全部开放吧，免得坑太深被活埋。
一切准备妥当之后，可以执行脚本，执行后能看到这样的输出：
执行过程中会下载一些额外的镜像，毕竟要支持HA特性么。另外Host的内存建议至少4G，执行完毕后通过docker ps可以看看都启动了什么：
常见的问题和解决方案
正常来说，一般我们会在日志中能看到各个成员加入到Rancher HA Cluster中：
但有时候会有意外，比如会看到一些error信息：
这个问题产生的背后原因有很多，我阅读了一些Github上的issue和各种论坛的帖子，帮大家整理了一些产生此问题的根本原因。
# 网络设置问题 #
有时候容器自动获取了节点的错误的IP，这时候你需要强制指定正确的IP。
# ZooKeeper没有正常启动 #
Zookeeper的容器是分布在每个节点上的，如果节点之间的问题导致Zookeeper容器不能通信，就会导致这个问题，如果要确认这个问题，可以参考这样的日志输出。
# 目录/var/lib/rancher/state 下有残留文件 #
如果多次运行Rancher-ha.sh这个脚本，那么你需要运行前清理一下这个目录下残留文件。
# 多次尝试后HA状态被破坏 #
删库重试，重启大法好。
# 机器资源不足 #
内存至少需要4GB，此外mysql的连接数也要足够，可以按照每个HA节点需要50个连接数来计算。如果你看到下面的错误，那么此问题确信无疑。
# rancher/server版本不匹配 #
rancher-ha.sh执行的时候默认是下载rancher/server:latest镜像，如果你没有host上的镜像不一致会导致难以想象的问题，最好执行的时候指定版本号。比如：
# docker0返回了错误的IP #
这个错误具体就是在HA的安装过程中会去检查agent健康状态，此时它获取了一个错误的docker0 IP地址，因为我先前已经将其设置成了172.17.42.1。
我的解决办法就是重装了我的AWS虚机，导致获取docker0 IP错误的原因，我感觉可能是我在虚机里多次安装了Docker。重装之后，一切就正常了，我也看到了期待的日志信息。
HA部署完毕后
我们终于看到了梦寐以求的正确日志输出，和美好的UI展现：
如果使用了自签名证书且前端希望通过HTTPS来访问，那么你需要把你的证书添加到你的受信任证书中。然后再等待数据库资源约束调整完毕后，三个节点的服务就完全运行起来了。
结论
这比原来想象的要多了很多。这就是为什么分布式系统一直是PHD的研究领域。解决所有的故障点后，我认为Rancher HA已经开始向顶尖分布式系统出发啦。
我最终会将Rancher HA的脚本配置成Ansible的一个简单任务，敬请关注！
附录
对于任何分布式系统来说，基本的套路就是统一管理其中产生的状态和变化，这意味着多个服务需要一个进程来协调更新。
Rancher的处理方式就是把状态都放倒数据库中，需要同步状态时把状态信息放入到event中，发送event就可以向其他组件同步状态。所以当正在处理一个事件时，它有一个锁，事件未处理完前数据库中的状态是不能被修改的。
在单台服务器设置中，所有的协调都发生在主机上的内存中。一旦你涉及多服务器HA配置，像zookeeper和redis是必要的。
---------------
报名参加11月6日成都Docker技术沙龙
[/quote]
当前技术世界的发展形势就是让开发人员从繁琐的应用配置和管理中解放出来，使用容器镜像来处理复杂的程序运行依赖库的需求，保证代码运行环境的一致性。
既然这样的好处是如此清晰，但为什么企业中的基础设施环境没有往容器集群切换呢？关键问题还是风险，新技术意味着未经检验的技术和实践经验的缺乏，这就会带来很多不可预知的风险。
当企业的运维团队去维护一个弹性的容器集群时，传统的软件部署方式需要向容器迁移，这个过程中需要有风险预判和规避之道。而Docker和Rancher正是提供了解决这些风险问题的解决方案，比如基于Rancher的Catalog功能就能快速的完成一些基础软件的部署（比如ElasticSearch）。
在风险管理方面，我们可以看看基于Docker和Rancher来运行弹性集群的五个关键点：
- 运行Rancher高可用模式 （本文将介绍）
- Rancher中使用负载均衡服务
- Rancher中的服务监控和监控检查
- 开发者自定义针对Rancher的安装部署
- 讨论利用Convoy对数据的管理
我原本希望展现一下用一台老式笔记本部署Rancher Server，然后用docker-machine加入几个树莓派节点部署Rancher Agent，这样来构建一个Rancher集群。但是这样会有些问题，就是大部分Docker镜像都是基于Intel CPU构建的，这会和树莓派的ARM CPU很不兼容。所以我还是老老实实的用AWS的虚机来构建Rancher集群吧。
初始安装，我们暂时先部署一台Rancher Server和一台Rancher Agent，然后再部署一个简单的多实例应用。
上面这张图展现了我的整个集群的设置，我选择AWS是因为我个人比较熟悉，当然你完全可以选择你擅长的云提供商。
我们可以尝试创建一个Wordpress，顺带来检测一下Rancher是否正确部署了。
这样我们的应用就运行起来了，试想，如果Rancher Server所在服务器出现故障，或者有网络中断问题发生，会对应用产生什么影响，Wordpress还能继续接受请求么？
为了确认我们的疑问，我将会按照下面的步骤执行，然后记录一下其中的运行结果：
- 阻断Rancher Server和Rancher Agent间的网络
- 停止Rancher Server的容器
- 瞧一瞧Rancher Server的容器里面到底有什么
最终我们要解决这些问题，那就要看看Rancher HA来怎样解决这些风险。
阻断Rancher Server和Rancher Agent间的网络
进入AWS，然后看我各种犀利的操作：
- 阻断Rancher Server和Rancher Agent间的访问
- 记录一下发生了什么
- 干掉几个WordPress的实例
- 恢复原先的网络
# 观察结果 #
首先，网络阻断后没过多久Rancher Host就出现了reconnecting状态
此时我依然可以正常访问Wordpress的地址，服务没有中断，IPSec隧道网络还存储，Wordpress实例还是可以正常访问数据库。
现在我们要停掉一个Wordpress实例，看看会发生什么？因为我们已经无法从Rancher UI上管理这些容器了，所以还是到对应的主机上执行docker命令吧。
很遗憾Wordpress容器没有重新启动，这有点麻烦了。我们还是把Rancher Server弄回来吧，看看它能不能感知到其中一个Wordpress容器已经被停掉了。
在各种犀利的操作和等待之后，Rancher Server与Agent重新连接了，Wordpress容器就被重新启动了。完美~
所以我们可以看，Rancher Server还是能够处理间歇性的网络问题，可以实现Rancher Server和Agent的故障重连。但是如果要让网络中断对Rancher的影响进一步减小，那么部署多个Rancher Server就比较重要了。
我们还是回过来，按照先前计划看看Rancher Server 容器停掉后会发生什么？我们会因此失去对这些Rancher Host的管理能力么？看看如何！
停掉Rancher Server
这次我需要登入到Rancher Server的host上手动停止Rancher Server，其实Rancher Server一般是设置 --restart=always，所以自己有一定的恢复能力。但我们可以假设比如磁盘写满了后，Rancher Server真的起不来了。
# 观察结果 #
执行`docker stop rancher-server`之后，Wordpress还是能够正常工作，但是Rancher UI是不能访问了，这可不行，得赶紧把Rancher Server弄回来。
再执行`docker start rancher-server`，Rancher Server启动后又一切恢复正常，这很酷啊，这是什么魔法？赶紧着，麻溜地分析起来！
揭开Rancher Server的神秘面纱
我们来一次对Rancher Server的简要探究之旅，看一看Rancher Server的Dockerfile。
# Dockerfile contents
FROM ...
...
...
CMD ["/usr/bin/s6-svscan", "/service"]
我们可以看到使用了s6-svscan，它可以运行指定的目录结构内的程序，目录内的主要文件就是Run、Down、Finish。下面这张图能看到会运行两个服务cattle（Rancher的核心调度器）和mysql。
其实在容器内部我们也可以看到起了哪些服务。
PID TTY STAT TIME COMMAND
1 ? Ss 0:00 /usr/bin/s6-svscan /service
7 ? S 0:00 s6-supervise cattle
8 ? S 0:00 s6-supervise mysql
9 ? Ssl 0:57 java -Xms128m -Xmx1g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lib/cattle/logs -Dlogback.bootstrap.level=WARN -cp /usr/share/cattle/1792f92ccdd6495127a28e16a685da7
135 ? Sl 0:01 websocket-proxy
141 ? Sl 0:00 rancher-catalog-service -catalogUrl library=https://github.com/rancher/rancher-catalog.git,community=https://github.com/rancher/community-catalog.git -refreshInterval 300
142 ? Sl 0:00 rancher-compose-executor
143 ? Sl 0:00 go-machine-service
1517 ? Ss 0:00 bash
1537 ? R+ 0:00 ps x
我们可以看到Rancher的大脑，一个名叫Cattle的Java应用，它需要一个MySQL来存储对应的数据。这确实很方便，但是我们发现这样会有单点故障，所有的数据存储在一个单点的mysql中。如果对mysql中的数据来一些不礼貌的操作，会发生什么呢？
# 破坏MySQL存储数据 #
进入容器中执行一些MySQL命令，我们一起来干点坏事：
docker exec -it rancher-server bash
$ > mysql
mysql> use cattle;
mysql> SET FOREIGN_KEY_CHECKS = 0;
mysql> truncate service;
mysql> truncate network;
结果是可想而知的，Rancher不记得任何事了，你删掉一个Wordpress容器，它也不会恢复。
而且我也删除了network表的数据，Wordpress也不知道如何找到它的MySQL服务了。
显然，若要在生产环境运行Rancher，我们需要一个方式来保护Rancher Server的数据，既然如此那我们就讲一下Rancher HA吧。
Rancher HA安装过程
首先我们要确保数据的安全，我选择了AWS的RDS服务，RDS可以提供一个信赖的MySQL服务，数据安全是可以保证的。当然你也可以使用其他的，我只是对RDS更熟悉一些。
下面我们继续Rancher HA的安装过程：
按照我们之前的约定，我是创建了RDS的MySQL实例，然后把它当做外部数据库和Rancher Server连接。
一旦我们使用了外部数据库模式，UI上将会打开两个选项来设置HA。
怎么办！选择困难症啊！没关系，我来解释一下每个选项的含义。
Cluster size，注意这里怎么都是奇数？因为在后端，Rancher会设置一个ZooKeeper Quorum保证锁同步，ZooKeeper推荐奇数集群，因为偶数节点数量不能提供额外的容错性。我们这里就选择3个Host吧，这是一个可用和易用的平衡。
Host registration URL，这里是填写一个Rancher Cluster入口的FQDN，推荐使用外部负载均衡服务或者DNS服务（round robin策略）。比如图中我使用的是支持SRV记录的DNS服务，通过DNS来做三个Rancher Server的负载均衡：
SSL Certificates是列表中的最后一个选项，如果你有域名的SSL证书可以配置在这里，否则Rancher会自动生成一个自签名证书。
所有都填完后，就会给你提供一个rancher-ha.sh的脚本来下载。
有了脚本就可以到每个Rancher Server节点上执行了，执行前还需要注意目前只能支持docker v1.10.3。安装指定版本的Docker Engine，可以参考下面的方式：
#!/bin/bash
apt-get install -y -q apt-transport-https ca-certificates
apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" > /etc/apt/sources.list.d/docker.list
apt-get update
apt-get install -y -q docker-engine=1.10.3-0~trusty
# run the command below to show all available versions
# apt-cache showpkg docker-engine
Docker安装之后，就要确认一下端口开放了，需要开放哪些端口可以看这里，不过如果是第一次安装，我建议你把端口全部开放吧，免得坑太深被活埋。
一切准备妥当之后，可以执行脚本，执行后能看到这样的输出：
...
ed5d8e75b7be: Pull complete
ed5d8e75b7be: Pull complete
7ebc9fcbf163: Pull complete
7ebc9fcbf163: Pull complete
ffe47ea37862: Pull complete
ffe47ea37862: Pull complete
b320962f9dbe: Pull complete
b320962f9dbe: Pull complete
Digest: sha256:aff7c52e52a80188729c860736332ef8c00d028a88ee0eac24c85015cb0e26a7
Status: Downloaded newer image for rancher/server:latest
Started container rancher-ha c41f0fb7c356a242c7fbdd61d196095c358e7ca84b19a66ea33416ef77d98511
Run the below to see the logs
docker logs -f rancher-ha
执行过程中会下载一些额外的镜像，毕竟要支持HA特性么。另外Host的内存建议至少4G，执行完毕后通过docker ps可以看看都启动了什么：
常见的问题和解决方案
正常来说，一般我们会在日志中能看到各个成员加入到Rancher HA Cluster中：
time="2016-07-22T04:13:22Z" level=info msg="Cluster changed, index=0, members=[172.30.0.209, 172.30.0.111, ]" component=service
...
time="2016-07-22T04:13:34Z" level=info msg="Cluster changed, index=3, members=[172.30.0.209, 172.30.0.111, 172.30.0.69]" component=service
但有时候会有意外，比如会看到一些error信息：
time="2016-07-23T14:37:02Z" level=info msg="Waiting for server to be available" component=cert
time="2016-07-23T14:37:02Z" level=info msg="Can not launch agent right now: Server not available at http://172.17.0.1:18080/ping:" component=service
这个问题产生的背后原因有很多，我阅读了一些Github上的issue和各种论坛的帖子，帮大家整理了一些产生此问题的根本原因。
# 网络设置问题 #
有时候容器自动获取了节点的错误的IP，这时候你需要强制指定正确的IP。
# ZooKeeper没有正常启动 #
Zookeeper的容器是分布在每个节点上的，如果节点之间的问题导致Zookeeper容器不能通信，就会导致这个问题，如果要确认这个问题，可以参考这样的日志输出。
# 目录/var/lib/rancher/state 下有残留文件 #
如果多次运行Rancher-ha.sh这个脚本，那么你需要运行前清理一下这个目录下残留文件。
# 多次尝试后HA状态被破坏 #
删库重试，重启大法好。
# 机器资源不足 #
内存至少需要4GB，此外mysql的连接数也要足够，可以按照每个HA节点需要50个连接数来计算。如果你看到下面的错误，那么此问题确信无疑。
time="2016-07-25T11:01:02Z" level=fatal msg="Failed to create manager" err="Error 1040: Too many connections"
# rancher/server版本不匹配 #
rancher-ha.sh执行的时候默认是下载rancher/server:latest镜像，如果你没有host上的镜像不一致会导致难以想象的问题，最好执行的时候指定版本号。比如：
./rancher-ha.sh rancher/server:
# docker0返回了错误的IP #
这个错误具体就是在HA的安装过程中会去检查agent健康状态，此时它获取了一个错误的docker0 IP地址，因为我先前已经将其设置成了172.17.42.1。
curl localhost:18080/ping
[quote] pong
curl http://172.17.0.1:18080/ping
> curl: (7) Failed to connect to 172.17.0.1 port 18080: Connection refused
我的解决办法就是重装了我的AWS虚机，导致获取docker0 IP错误的原因，我感觉可能是我在虚机里多次安装了Docker。重装之后，一切就正常了，我也看到了期待的日志信息。
HA部署完毕后
我们终于看到了梦寐以求的正确日志输出，和美好的UI展现：
time="2016-07-24T20:00:11Z" level=info msg="[0/10] [zookeeper]: Starting "
time="2016-07-24T20:00:12Z" level=info msg="[1/10] [zookeeper]: Started "
time="2016-07-24T20:00:12Z" level=info msg="[1/10] [tunnel]: Starting "
time="2016-07-24T20:00:13Z" level=info msg="[2/10] [tunnel]: Started "
time="2016-07-24T20:00:13Z" level=info msg="[2/10] [redis]: Starting "
time="2016-07-24T20:00:14Z" level=info msg="[3/10] [redis]: Started "
time="2016-07-24T20:00:14Z" level=info msg="[3/10] [cattle]: Starting "
time="2016-07-24T20:00:15Z" level=info msg="[4/10] [cattle]: Started "
time="2016-07-24T20:00:15Z" level=info msg="[4/10] [go-machine-service]: Starting "
time="2016-07-24T20:00:15Z" level=info msg="[4/10] [websocket-proxy]: Starting "
time="2016-07-24T20:00:15Z" level=info msg="[4/10] [rancher-compose-executor]: Starting "
time="2016-07-24T20:00:15Z" level=info msg="[4/10] [websocket-proxy-ssl]: Starting "
time="2016-07-24T20:00:16Z" level=info msg="[5/10] [websocket-proxy]: Started "
time="2016-07-24T20:00:16Z" level=info msg="[5/10] [load-balancer]: Starting "
time="2016-07-24T20:00:16Z" level=info msg="[6/10] [rancher-compose-executor]: Started "
time="2016-07-24T20:00:16Z" level=info msg="[7/10] [go-machine-service]: Started "
time="2016-07-24T20:00:16Z" level=info msg="[8/10] [websocket-proxy-ssl]: Started "
time="2016-07-24T20:00:16Z" level=info msg="[8/10] [load-balancer-swarm]: Starting "
time="2016-07-24T20:00:17Z" level=info msg="[9/10] [load-balancer-swarm]: Started "
time="2016-07-24T20:00:18Z" level=info msg="[10/10] [load-balancer]: Started "
time="2016-07-24T20:00:18Z" level=info msg="Done launching management stack" component=service
time="2016-07-24T20:00:18Z" level=info msg="You can access the site at https://" component=service
如果使用了自签名证书且前端希望通过HTTPS来访问，那么你需要把你的证书添加到你的受信任证书中。然后再等待数据库资源约束调整完毕后，三个节点的服务就完全运行起来了。
结论
这比原来想象的要多了很多。这就是为什么分布式系统一直是PHD的研究领域。解决所有的故障点后，我认为Rancher HA已经开始向顶尖分布式系统出发啦。
我最终会将Rancher HA的脚本配置成Ansible的一个简单任务，敬请关注！
附录
对于任何分布式系统来说，基本的套路就是统一管理其中产生的状态和变化，这意味着多个服务需要一个进程来协调更新。
Rancher的处理方式就是把状态都放倒数据库中，需要同步状态时把状态信息放入到event中，发送event就可以向其他组件同步状态。所以当正在处理一个事件时，它有一个锁，事件未处理完前数据库中的状态是不能被修改的。
在单台服务器设置中，所有的协调都发生在主机上的内存中。一旦你涉及多服务器HA配置，像zookeeper和redis是必要的。
---------------
报名参加11月6日成都Docker技术沙龙
[/quote]