Rancher

Rancher

rancher: Failed to obtain metrics. The metrics service may not be available.

回复

tangjiaxing669 发起了问题 • 1 人关注 • 0 个回复 • 762 次浏览 • 2019-04-13 12:13 • 来自相关话题

RancherOS v1.5.0发布

Rancher 发表了文章 • 1 个评论 • 633 次浏览 • 2019-01-09 10:31 • 来自相关话题

一言不合就发新版本。 年关将至,寒意习习,落叶萧萧下,阳光日日稀。RancherOS团队历时两个来月的开发,正式发布RancherOS v1.5.0版本。 在此期间同为Container Linux阵营的C ...查看全部
一言不合就发新版本。



年关将至,寒意习习,落叶萧萧下,阳光日日稀。RancherOS团队历时两个来月的开发,正式发布RancherOS v1.5.0版本。 在此期间同为Container Linux阵营的CoreOS已经从红帽再入IBM,潮流之变,业界态势,让我们无不更加努力去争得一席之地。 无论是商业用户的积累,还是业界变化带来的社区用户增长,都在催促我们不断革新,应该说1.5.0版本是用户的需求推着我们走出来的。




------------



重大特性更新



本版本的新特征众多,无法一次性全部说明,以下只表述一些用户关注度比较高的特性。个别特性详细说明,我们会不断推出文章一一展开。


启动性能提升



一直以来RancherOS的initrd一直采用xz格式压缩,随着RancherOS的体积不断增大,xz压缩越来越影响系统启动速度。虽然xz格式能够带来比较小的initrd和ISO, 但是我们也需要兼顾启动速度。v1.5.0版本的initrd已经采用了gzip格式,文件体积有所增大,但是启动速度有了质的飞跃。 同时我们也优化了system-docker的镜像加载和cloud-init的启动,对启动速度进行了深度优化。



LUKS磁盘加密支持



支持LUKS,允许用户对跟磁盘分区进行加密,在一些特殊场景下增强了RancherOS的安全性。运行效果参考下图:



WiFi和4G支持



Intel正在micro PC领域不断发力,RancherOS被纳入其生态体系,我们支持了WiFi和4G网络,用户可以通过简单的cloud-config配置就可以开启, 带来了十分简洁的用户体验,这部分我们会在后续其他文章中详细介绍。



Hyper-V支持



很多社区用户一直希望能在Hyper-V使用RancherOS,先前我们一直提供给用户一些custom build的方式来实现它,现在我们正式支持了它,并会持续维护。 无论是docker-machine方式还是boot from ISO方式均可以支持。



下一个版本我们也会带来RancherOS的Azure Cloud支持。



多docker engine支持



这是一个很有趣的特性,目前RancherOS中默认拥有一个user docker。在v1.5.0中,用户可以用过ROS CLI来创建多个user docker engine, 并且每个docker拥有独立的ROOTFS和网络栈,并且可以在console很容易的切换使用任意一个docker。



当然我们并不推荐您在生产中使用,我们的某个商业客户把这个特性应用在其CI环境中,极大的提升了资源的利用率,减少了物理机器数量的开销。



改善VMware的支持


RancherOS的广大用户中Vmware是占有很大的用户群,之前我们的版本中只针对docker-machine方式做了一些改善,但是很多用户还希望使用boot from ISO方式和VMDK方式, 我们相关的镜像也做了支持,用户可以直接下载使用它:



  • [VMDK] https://releases.rancher.com/os/v1.5.0/vmware/rancheros.vmdk
  • [Docker Machine] https://releases.rancher.com/os/v1.5.0/rancheros-vmware.iso
  • [Boot From ISO] https://releases.rancher.com/os/v1.5.0/vmware/rancheros.iso



ARM的支持



由于Rancher和ARM已经开始了战略合作,我们会在一起做很多有趣的事。RancherOS的ARM支持也是其中的一部分,原先我们只是对RPi做了支持, 现在我们提供ARM版本的initrd和vmlinuz,用户可以用它们使用iPXE方式启动:



https://releases.rancher.com/os/v1.5.0/arm64/initrd

https://releases.rancher.com/os/v1.5.0/arm64/vmlinuz



我们依然只会对ARM64支持,且v1.5.0的ARM支持只是实验性质的,并不推荐应用在生产中。 我们会和ARM进行合作进行更广泛的测试,后续的版本将会是更稳定的。



更加友好的自定义



社区中越来越多的发烧友并不局限使用我们的正式发布版本,他们会根据自己的需求修改RancherOS,构建自己的RancherOS。 我们提供了一些友好的编译选项,用户可以自定义自己的RancherOS。



更改默认docker engine



RancherOS的每个版本都会有自己设定的默认docker engine,而在用户的场景下,可能需要一个内部认可的docker engine,且希望它是RancherOS默认的版本。 那么用户可以在构建时候指定docker engine版本,来构建自己的RancherOS,以docker 17.03.2为例:

`USER_DOCKER_VERSION=17.03.2 make release`



更改默认console



RancherOS支持很多console,比如ubuntu、alpine、centos等,由于我们的default console基于busybox,有些用户并不喜欢它,且不希望每次都去切换console。 那么用户可以使用这种方式构建一个默认console是自己喜欢的版本,以alpine console为例:

`$ OS_CONSOLE=alpine make release`



其 他



AWS相关镜像已经上传到各个region中,可以直接搜索查找并使用,包括AWS中国区。其他主要镜像列表参考:

https://github.com/rancher/os/blob/v1.5.x/README.md#release



更多新特性和Bug Fix请参考v1.5.0的Release Notes



文档说明:

https://rancher.com/docs/os/v1.x/en/



最后,RancherOS还是一个小众的开源项目,我们专注Docker在Linux上的精简体验,如果喜欢RancherOS,请在Github上给我们一个star,鼓励我们继续前行。



Rancher Github:

https://github.com/rancher/os/releases/tag/v1.5.0

中国公有云三巨头,同时支持Rancher Kubernetes平台

Rancher 发表了文章 • 1 个评论 • 963 次浏览 • 2018-11-21 22:53 • 来自相关话题

华为云容器引擎(CCE)、阿里云K8S容器服务(ACK)和腾讯云K8S引擎(TKE),中国公有云三巨头正式全面支持Rancher Kubernetes平台。 ------------ Ranch ...查看全部
华为云容器引擎(CCE)、阿里云K8S容器服务(ACK)和腾讯云K8S引擎(TKE),中国公有云三巨头正式全面支持Rancher Kubernetes平台。


------------

Rancher正式宣布扩大对中国领先Kubernetes服务的支持,华为云容器引擎(CCE)、阿里云Kubernetes容器服务(ACK)和腾讯云Kubernetes引擎(TKE),中国公有云三巨头正式全面支持Rancher Kubernetes平台。



想在生产中运行容器和Kubernetes,Rancher Kubernetes平台已是数万企业的第一选择。 Kubernetes在全球范围内的热度持续攀升,Rancher进一步扩大了对云提供商托管的Kubernetes服务的支持。 如今,Rancher自豪地成为了唯一一个与所有领先云提供商达成合作、支持其托管的Kubernetes集群的企业级开源Kubernetes管理平台。



扩大对华为云、阿里云和腾讯云的支持



Rancher是业界唯一100%开源的企业级Kubernetes管理平台,无论何时何地,Rancher均为企业用户提供“Kubernetes即服务(Kubernetes-as-a-Service)”的技术支持,实现对Kubernetes集群的集中部署及管理,不论这些Kubernetes集群是在何处、以何种方式部署的。



在Rancher 2.0上线后,Rancher率先实现了对谷歌云容器服务(GKE)、亚马逊云容器服务(EKS)及微软云容器服务(AKS)的支持,打造一致的安全策略,为用户带来良好的使用体验。现在,Rancher扩大了对华为云容器引擎(CCE)、阿里云容器服务(ACK)和腾讯云容器服务(TKE)的全面支持,帮助中国的企业加快Kubernetes集群的落地。







华为CCE是中国第一个云托管的Kubernetes服务,我们无比欢迎Rancher用户能通过华为CCE与Rancher平台的集成合作,享受华为云所提供的世界级的Kubernetes支持。
——华为Cloud BU PaaS产品部总经理 廖振钦









作为中国最大的公共云服务提供商,也是全球三大IaaS提供商之一,阿里云致力于通过云原生方式和开放式容器技术,帮助企业加速数字化转型。我们很高兴通过阿里云Kubernetes服务(ACK)支持Rancher。ACK已在全球十六个地区推出,我们坚信ACK将推动企业通过Kubernetes完成向云迁移和多云管理。
——阿里云容器技术工程总监 易立







腾讯Kubernetes引擎(TKE)诞生于开源Kubernetes系统,提供以容器为中心、高度可扩展和高性能的容器管理服务。Rancher与TKE之间的集成支持有着很大意义,Rancher用户现在可以最大程度充分享受TKE提供的丰富功能了。
——腾讯云PaaS产品经理 梁文杰





四大更新亮点



为华为云(CCE)、阿里云(ACK)和腾讯云(TKE)提供自服务Kubernetes集群的支持,用户可以通过Rancher UI和API创建并升级CCE、ACK和TKE集群。



集成的云基础设施管理和集群扩展。企业用户可以从 Rancher UI 和 API 配置 CCE、 ACK 和 TKE 集群及集群中的节点数。



跨本地集群和CCE、ACK或TKE集群的集中式用户身份验证。企业用户可以使用Active Directory和 LDAP 凭证登录到他们的 CCE、 ACK 和 TKE 集群。



跨所有 Kubernetes 集群的统一访问控制策略。企业 IT 管理员可以配置跨 CCE、 ACK 和 TKE 集群的一致访问控制策略。



Kubernetes Everywhere



这次集成将会在2019年初发布的Rancher 2.2当中正式实现,现在对华为云、阿里云以及腾讯云的整合支持内容已可demo使用。



这一次,随着Rancher对世界范围内几大主流领先的云托管Kubernetes服务的全面支持,Rancher一直以来“Kubernetes Everywhere”的愿景正在更进一步变为现实。对于企业用户而言,Rancher之旅始于企业开始意识到他们需要一个平台来管理混合云中的资源和开发。我们比以往任何时候都更有信心,Kubernetes将成为企业应用程序的基础平台,而Rancher将帮助企业将Kubernetes落地为现实。

Rancher 2.1全面发布,优化Kubernetes集群运维

Rancher 发表了文章 • 1 个评论 • 1880 次浏览 • 2018-10-18 22:19 • 来自相关话题

Rancher 2.1已于近日全面发布! Rancher 2.1是自去年九月Rancher Labs全面拥抱Kubernetes、发布全新里程碑产品Rancher 2.0——开源的企业级Kubernetes ...查看全部
Rancher 2.1已于近日全面发布!



Rancher 2.1是自去年九月Rancher Labs全面拥抱Kubernetes、发布全新里程碑产品Rancher 2.0——开源的企业级Kubernetes管理平台之后,最为重大的版本更新。



2017年9月Rancher Labs极具前瞻性地成为业界首批全面拥抱Kubernetes的容器管理平台提供商,全新里程碑产品Rancher 2.0是一个开源的企业级Kubernetes管理平台,为企业用户提供Kubernetes-as-a-Service (Kubernetes即服务)。



Rancher 2.1建立在Rancher 2.0的成功基础之上,并引入了下一代自动集群操作和应用程序管理功能,并为用户提供了从Rancher的Cattle编排迁移到Rancher Kubernetes的迁移路径。Rancher 2.1提供了企业在其组织内轻松采用和管理Kubernetes所需的所有关键功能。



Rancher一直是企业在生产中运行容器和Kubernetes的事实上的选择。Rancher 2.1中包含着很多重要的功能升级,将进一步帮助各类企业加快拥抱Kubernetes,缩短IT研发流程,降低基础架构成本,并提高应用程序可靠性。



——Rancher Labs联合创始人及CEO 梁胜





优化Kubernetes集群运维



Rancher 2.1大大加强了可扩展性,并让用户可以使用Rancher来定义和管理Kubernetes 集群。此外,Rancher 2.1允许用户快照并导出Rancher管理的Kubernetes集群的完整配置,并可在之后通过导入相同的配置文件来恢复Kubernetes集群。



Rancher 2.1的其他主要功能包括:



  • 更多身份验证方式
Rancher现在集成了PingID、Microsoft Active Directory联合服务器、OpenLDAP、Keycloak、FreeIPA和Azure Active Directory。
  • 驱散容器功能
在对主机进行维护时,例如升级内核、硬件维护等,这个功能首先会禁止新的容器调度到这个节点,然后会对该节点上的容器有规则的进行驱散。完成主机维护后,可以恢复节点功能。
  • 项目配额管理
集群管理员和项目管理员可以从项目层级设置配额。可以配置该项目的CPU、内存、存储、Pod数量等等的配额。同时,在每个项目里,管理员也可以对每个命名空间的配额进行控制。
  • 更强的应用程序管理功能
Rancher 2.1增加了对helm chart的优化支持,并优化了ingress管理、日志采集和告警功能。
  • CICD功能增强
Rancher 2.1大幅优化了CICD的用户体验,包含完全集成的CI / CD功能,可与Kubernetes一起使用,打通了代码提交、自动测试、自动构建镜像、自动部署镜像的全流程。
  • 支持GitLab
Rancher 2.1增加了对Rancher CI / CD的GitLab支持,CICD可以支持公有GitLab的对接和私有GitLab代码库的对接。
  • 扩展的命令行界面(CLI)
团队现在可以自动化他们与Rancher和Kubernetes的接口。
  • 高可用模式增强
管理员可以配置高可用模式中启用多个Rancher Server实例。提供了Rancher服务横向扩容的能力,提高了Rancher Server的可用性。
  • 应用商店优化和增强

Rancher 2.1引入了Tiller,更好的优化了应用商店,并且新增了例如Kubernetes Dashboard等应用的一键部署。且现在用户可以以编辑YAML的形式来设置应用参数。



从Rancher 1.6迁移到Rancher 2.X



Rancher 2.1同时还是供Rancher 1.6用户使用的升级版本。Rancher 2.1包含一个迁移路径,供用户从Rancher的Cattle编排迁移到Rancher Kubernetes。Rancher 2.1还提供了分析Rancher Compose文件的集成工具,并概述了用户能如何将应用程序直接迁移到Kubernetes。更多版本升级迁移相关的细节与建议请参考:

https://rancher.com/docs/rancher/v2.x/en/v1.6-migration/



Rancher 2.1用户体验计划



大家说,开源才是技术的未来。Rancher也始终怀着这样的理念和勇气在做产品。每一个bug的修复,每一次产品的升级,都是Rancher想献给用户和开源社区的礼物,Rancher一路走来取得的巨大成绩也绝离不开用户和开源社区的支持。



Rancher 2.1新近发布,Rancher Labs中国区团队特为中国用户准备了【千元大奖】,邀您参与【Rancher 2.1用户体验计划】!



找bug,提issue



Rancher团队珍视用户的每一个意见与反馈。新版本2.1发布后还将经历版本完善与优化的阶段。若您在Rancher 2.1的测试或使用中发现了任何bug,欢迎在Rancher GitHub上提交issue:

https://github.com/rancher/rancher/issues



issue提交完毕后,请在此表单上填写相应信息,Rancher中国区研发团队会第一时间优先解决您反馈的问题并联络您:

https://www.wenjuan.com/s/N77JVr2/

如何在Rancher 2.0上快速部署Datadog

Rancher 发表了文章 • 1 个评论 • 1267 次浏览 • 2018-07-19 17:57 • 来自相关话题

Datadog是一种流行的托管监控解决方案,用于聚合和分析分布式系统的指标和事件。从基础架构集成到协作仪表板,Datadog为用户提供了一个简洁的单一窗格视图,用户可以快速查看对其最重要的信息。结合使用Rancher和Datadog,用户可以查看到运行在Kub ...查看全部
Datadog是一种流行的托管监控解决方案,用于聚合和分析分布式系统的指标和事件。从基础架构集成到协作仪表板,Datadog为用户提供了一个简洁的单一窗格视图,用户可以快速查看对其最重要的信息。结合使用Rancher和Datadog,用户可以查看到运行在Kubernetes集群上的应用程序的完整堆栈视图,无论这些Kubernetes集群运行于何处。为了使Datadog更易于与Rancher 2.0一起使用,Rancher的工程师修改了Datadog Helm chart,Rancher用户可以在Rancher的应用商店(Catalog)中快速简单地部署Datadog,且Datadog可在集群内的各Rancher项目(project)中运行。



前期准备


1、Datadog API Key:你可以使用已有的API key的秘钥,也可以让chart新生成一个秘钥。



2、默认情况下,Rancher Kubernetes Engine(RKE)不允许对许多指标所依赖的kubelet API进行未经身份验证的访问。使用RKE安装集群时,我们需要为kubelet服务提供额外的参数。

services:

kubelet:

  extra_args:

    read-only-port: 10255j


注意:你需要确保此端口已正确打开防火墙。



3、你需要一个连接到Rancher安装的Kubernetes 1.8。



设置和配置


默认情况下,Rancher库中有Datadog Rancher Chart(https://github.com/rancher/charts/tree/master/charts/datadog/v1.0.0),在Helm stable中也有一个Datadog Chart,但我们建议您使用Rancher库中的Chart,因为这用起来更方便简洁。Rancher库会默认启动,如果你想禁用Rancher库,可以在Global-> Catalogs下修改此设置。


DataDog-Helm-Chart.png




通过添加questions.yaml文件,用户在Rancher UI中就可以使用chart配置选项了。要了解有关它们的更多信息,请参阅values.yaml文件(https://github.com/rancher/charts/blob/master/charts/datadog/v1.0.0/questions.yml),该文件包含其他信息和描述变量的链接。



AgentConfiguration.png




仪表盘

如果您计划将多个集群数据发送到同一个Datadog端点,则在配置Helm chart时将集群名称添加为主机标记(例如kube-cluster-name:CLUSTERNAME)。这样一来,你就可以按范围将数据排序到特定集群,并按仪表板中的集群对数据进行分组。在下面的仪表板示例中,我们按照集群'dash-1'和dash-2'的一些默认小部件按簇分组节点数据。



datadogDashboard.png




结论
使用Helm部署应用程序是一种经过了测试的、标准化的部署方法。使用Rancher Catalog UI,Helm chart将更易于使用和配置。将Datadog chart添加到Rancher库中,用户就可以利用这一工作流轻松享受顶级的企业级Kubernetes监控和警报解决方案。

使用ExternalDNS自动化DNS配置

Rancher 发表了文章 • 1 个评论 • 1420 次浏览 • 2018-07-18 12:29 • 来自相关话题

Kubernetes社区的生态繁荣和该领域技术的快速茁壮发展,已经是众所周知。Kubernetes领域有太多强大的、创新的技术产品,而最近引起我注意的项目是ExternalDNS。这是在近期的POC期间客户主动咨询起来的,我承诺客户会尝试一下ExternalD ...查看全部
Kubernetes社区的生态繁荣和该领域技术的快速茁壮发展,已经是众所周知。Kubernetes领域有太多强大的、创新的技术产品,而最近引起我注意的项目是ExternalDNS。这是在近期的POC期间客户主动咨询起来的,我承诺客户会尝试一下ExternalDNS子项目,且使用后发现它真的令人印象深刻。



ExternalDNS子项目


ExternalDNS子项目(孵化器流程已被弃用)是由sig-network赞助并由Tim Hockin倡导的,旨在自动配置云DNS提供商。这很重要,因为它进一步支持基础架构自动化,用户可以在应用程序部署的同时直接完成DNS配置。


传统企业部署模型,通常是由多个孤立业务单元,来处理部署过程的不同部分。但带有ExternalDNS的Kubernetes不同于传统企业部署模型,它可以自动完成此过程的这一部分工作。有时候有可能会出现这种不好的情况:一部分软件已准备就绪,但它却必须等待另一个业务部门手动配置DNS。而有了ExternalDNS,这一潜在问题就被解决了。


通过ExternalDNS,组织团队可实现自动化和共同责任协作,而这将避免手动配置的错误,并使各方都能够更有效地将其产品推向市场。


AKS上的ExternalDNS配置和部署


我曾作为软件开发人员在.NET领域有过多年的工作经验。微软开发人员社区在我心中一直有一个特殊的位置,过去几年以来我参加过不少费城地区的Azure用户meetup,分享如何通过ACS(Azure Container Service)和AKS(Azure Kubernetes Service)使用Kubernetes on Azure。恰巧的是,向我咨询ExternalDNS的用户也正是在选择了Azure作为其IaaS产品。


下文是我准备的在AKS集群上启动ExternalDNS的分步说明和帮助程序代码。即使您使用的是其他公有云上的托管的Kubernetes,本教程依然适用。


# 先决条件 #


登录Azure AD,必要情况下请设置订阅。


几点注意事项


1、请注意,本文档中的外部模板文件使用了许多可选设置。

2、它也在debug级别日志中,因此您也可以自行进行troubleshooting。


# 在Azure AKS或Azure IaaS上设置ExternalDNS #


1、创建Azure DNS记录

RESOURCE_GROUP=MC_rancher-group_c-6vkts_eastus
DNS_ZONE=vanbrackel.net
az network dns zone create -g $RESOURCE_GROUP -n $DNS_ZONE


2、根据您的注册商的需要委派DNS


3、创建服务主体以代表Kubernetes行事。

SUBSCRIPTION_ID="$(az account show | jq '.id')" && SUBSCRIPTION_ID=${SUBSCRIPTION_ID//\"}
TENANT_ID=$(az account show | jq '.tenantId') && TENANT_ID=${TENANT_ID//\"}
SCOPE=$(az group show --name $RESOURCE_GROUP | jq '.id') && SCOPE=${SCOPE//\"}
PRINCIPAL=$(az ad sp create-for-rbac --role="Contributor" --scopes=$SCOPE -n ExternalDnsServicePrincipal)
CLIENT_ID=$(echo $PRINCIPAL | jq '.appId') && CLIENT_ID=${CLIENT_ID//\"}
CLIENT_SECRET=$(echo $PRINCIPAL | jq '.password') && CLIENT_SECRET=${CLIENT_SECRET//\"


4、创建你的云提供商配置。

echo "{ \"tenantId\": \"$TENANT_ID\", \"subscriptionId\": \"$SUBSCRIPTION_ID\", \"aadClientId\": \"$CLIENT_ID\", \"aadClientSecret\": \"$CLIENT_SECRET\", \"resourceGroup\": \"$RESOURCE_GROUP\"}" >> azure.json


5、使用云提供商配置来创建一个Kubernetes秘钥。

> kubectl create secret generic azure-config-file --from-file=azure.json
secret "azure-config-file" created


6、如果你使用的是Rancher配置的Azure IaaS Backed Clusters,从集群中删除ingress controller。

> kubectl get ns
NAME STATUS AGE
cattle-system Active 1d
default Active 1d
ingress-nginx Active 1d
kube-public Active 1d
kube-system Active 1d
[quote] kubectl delete ns/ingress-nginx
namespace "ingress-nginx" deleted
[/quote]

注意:如果您是使用Rancher中的 AKS配置的集群,则不会提供ingress controller。


7、安装nginx ingress controller并为ExternalDNS配置它。创建ingress-nginx部署和服务。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml


8、由于在基于Rancher的Kubernetes集群上默认启用了RBAC,因此可以从下面的脚本创建名为

externaldns.yaml的yaml文件,或者使用此repo中的externaldns-template.yaml文件。

apiVersion: v1
kind: ServiceAccount
metadata:
name: external-dns
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata: name: external-dns
rules:
[list]
[*]apiGroups: [""][/*]
[/list] resources: ["services"]
verbs: ["get","watch","list"]
[list]
[*]apiGroups: [""][/*]
[/list] resources: ["pods"]
verbs: ["get","watch","list"]
[list]
[*]apiGroups: ["extensions"] [/*]
[/list] resources: ["ingresses"]
verbs: ["get","watch","list"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata: name: external-dns-viewer
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: external-dns
subjects:
[list]
[*]kind: ServiceAccount[/*]
[/list] name: external-dns
namespace: default
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: external-dns
spec:
strategy:
type: Recreate
template:
metadata:
labels:
app: external-dns
spec:
serviceAccountName: external-dns
containers:
- name: external-dns
image: registry.opensource.zalan.do/teapot/external-dns:v0.5.2
args:
- --source=service
- --source=ingress
- --domain-filter=vanbrackel.net # (optional) limit to only vanbrackel.net domains; change to match the zone created above.
- --provider=azure
- --azure-resource-group=MC_rancher-group_c-6vkts_eastus # (optional) use the DNS zones from above
volumeMounts:
- name: azure-config-file
mountPath: /etc/kubernetes
readOnly: true
volumes:
- name: azure-config-file
secret:
secretName: azure-config-file
EXTERNAL_DNS=$(cat externaldns-template.yaml)
EXTERNAL_DNS=${EXTERNAL_DNS//DOMAIN/$DOMAIN} && echo "${EXTERNAL_DNS//RESOURCE_GROUP/$RESOURCE_GROUP}" >> externaldns.yaml
kubectl create -f externaldns.yaml


# 验证 #

1、以与部署ExternalDNS相同的方式在ingress中创建nginx服务

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
spec:
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: ClusterIP

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: server.vanbrackel.net
http:
paths:
- backend:
serviceName: nginx-svc
servicePort: 80
path: /


NGINX=$(cat nginx-ingress-test-template.yaml) && echo "${NGINX//DOMAIN/$DOMAIN}" >> nginx-ingress-test.yaml


2、创建nginx-ingress controller

kubectl create -f nginx-ingress-test.yaml


3、稍等几分钟


4、检查一下是否已有record被创建出来

[jason@vblinux ~ ]$ az network dns record-set a list --resource-group $RESOURCE_GROUP --zone-name $DNS_ZONE
[
{
"arecords": [
{
"ipv4Address": "13.68.138.206"
}
],
"etag": "0fb3eaf9-7bf2-48c4-b8f8-432e05dce94a",
"fqdn": "server.vanbrackel.net.",
"id": "/subscriptions/c7e23d24-5dcd-4c7c-ae84-22f6f814dc02/resourceGroups/mc_rancher-group_c-6vkts_eastus/providers/Microsoft.Network/dnszones/vanbrackel.net/A/server",
"metadata": null,
"name": "server",
"resourceGroup": "mc_rancher-group_c-6vkts_eastus",
"ttl": 300,
"type": "Microsoft.Network/dnszones/A"
}
]


5、检查日志

kubectl logs external-dns-655df89959-7ztm2 
time="2018-06-13T23:57:11Z" level=info msg="config: {Master: KubeConfig: Sources:[service ingress] Namespace: AnnotationFilter: FQDNTemplate: CombineFQDNAndAnnotation:false Compatibility: PublishInternal:false ConnectorSourceServer:localhost:8080 Provider:azure GoogleProject: DomainFilter:[vanbrackel.net] ZoneIDFilter:[] AWSZoneType: AWSAssumeRole: AzureConfigFile:/etc/kubernetes/azure.json AzureResourceGroup:MC_rancher-group_c-6vkts_eastus CloudflareProxied:false InfobloxGridHost: InfobloxWapiPort:443 InfobloxWapiUsername:admin InfobloxWapiPassword: InfobloxWapiVersion:2.3.1 InfobloxSSLVerify:true DynCustomerName: DynUsername: DynPassword: DynMinTTLSeconds:0 InMemoryZones:[] PDNSServer:http://localhost:8081 PDNSAPIKey: Policy:sync Registry:txt TXTOwnerID:default TXTPrefix: Interval:1m0s Once:false DryRun:false LogFormat:text MetricsAddress::7979 LogLevel:debug}"
time="2018-06-13T23:57:11Z" level=info msg="Connected to cluster at https://10.0.0.1:443"
...
time="2018-06-14T00:02:11Z" level=debug msg="Retrieving Azure DNS zones."
time="2018-06-14T00:02:12Z" level=debug msg="Found 1 Azure DNS zone(s)."
time="2018-06-14T00:02:12Z" level=debug msg="Retrieving Azure DNS records for zone 'vanbrackel.net'."
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service default/kubernetes"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service default/nginx-svc"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/default-http-backend"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/ingress-nginx"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-controller" time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-default-backend"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/heapster"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/kube-dns"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/kubernetes-dashboard"
time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/tiller-deploy"
time="2018-06-14T00:02:12Z" level=debug msg="Endpoints generated from ingress: default/nginx: [server.vanbrackel.net 0 IN A 13.68.138.206]"
time="2018-06-14T00:02:12Z" level=debug msg="Retrieving Azure DNS zones."
time="2018-06-14T00:02:12Z" level=debug msg="Found 1 Azure DNS zone(s)."
time="2018-06-14T00:02:12Z" level=info msg="Updating A record named 'server' to '13.68.138.206' for Azure DNS zone 'vanbrackel.net'."
time="2018-06-14T00:02:13Z" level=info msg="Updating TXT record named 'server' to '\"heritage=external-dns,external-dns/owner=default,external-dns/resource=ingress/default/nginx\"' for Azure DNS zone 'vanbrackel.net'."
time="2018-06-14T00:03:11Z" level=debug msg="Retrieving Azure DNS zones."
time="2018-06-14T00:03:12Z" level=debug msg="Found 1 Azure DNS zone(s)."
time="2018-06-14T00:03:12Z" level=debug msg="Retrieving Azure DNS records for zone 'vanbrackel.net'."
time="2018-06-14T00:03:12Z" level=debug msg="Found A record for 'server.vanbrackel.net' with target '13.68.138.206'."
time="2018-06-14T00:03:12Z" level=debug msg="Found TXT record for 'server.vanbrackel.net' with target '\"heritage=external-dns,external-dns/owner=default,external-dns/resource=ingress/default/nginx\"'."
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service default/kubernetes"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service default/nginx-svc" time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/default-http-backend"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/ingress-nginx"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-controller"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-default-backend"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/heapster"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/kube-dns"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/kubernetes-dashboard"
time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/tiller-deploy"
time="2018-06-14T00:03:12Z" level=debug msg="Endpoints generated from ingress: default/nginx: [server.vanbrackel.net 0 IN A 13.68.138.206]"
time="2018-06-14T00:03:12Z" level=debug msg="Retrieving Azure DNS zones."
time="2018-06-14T00:03:12Z" level=debug msg="Found 1 Azure DNS zone(s)."


您还可以在ExternalDNS的repo中了解更多信息:

https://github.com/kubernetes-incubator/external-dns

如希望对原文中的代码有更深入的了解,请猛戳这里:

https://github.com/JasonvanBrackel/kubernetes-external-dns-in-rancher#prerequisites

管理Kubernetes集群时需要关注的关键指标

Rancher 发表了文章 • 1 个评论 • 752 次浏览 • 2018-07-13 15:43 • 来自相关话题

有时我们在面对分布式系统工程时常感到痛苦。构建分布式系统真的很难,无论是哪个行业的企业,都希望我们在解决他们的业务问题的同时,还能考虑潜在的大规模业务问题。与大规模部署随之而来的一大挑战,是用户还要考虑创建新特性和避免回档。就算能够非常出色地实现这些目标,用户 ...查看全部
有时我们在面对分布式系统工程时常感到痛苦。构建分布式系统真的很难,无论是哪个行业的企业,都希望我们在解决他们的业务问题的同时,还能考虑潜在的大规模业务问题。与大规模部署随之而来的一大挑战,是用户还要考虑创建新特性和避免回档。就算能够非常出色地实现这些目标,用户仍然会担忧很多其他问题,例如信息是否安全、是否遵从法规,以及企业的这一投资是否真的有足够价值。

如果上述描述和你的团队现在的境况很像,而且你们的系统已经在生产环境中运行了,那么恭喜你,你已经通过了第一轮考验。

无论你多么努力建立了一个出色的系统,有时意想不到的事还是会发生。有很多这样的先例。一个杰出的产品,或者是病毒式应用,可能会带来前所未有的成功,而成功之后你就会发现,原先你以为的、你的系统面对大规模应用时的处理方式,好像不适用了。

640.webp_(7)_.jpg

Pokemon Go云数据存储的每秒处理数(预期vs实际)
来源: Bringing Pokémon GO to life on Google Cloud,发布于2018年5月30日

这一情况是可能发生的,而你也应该为此做好准备。这也是本系列文章所要提到的。在本系列教程中我们将向你介绍需要追踪的内容,为什么追踪它们,以及面对可能的根本原因时需要做的缓解处理。

我们会介绍每一种指标、追踪它的方法以及你可以对应采取的措施。我们将使用不同的工具收集和分析这些数据。教程不会涉及到太多细节的内容,但会提供拓展链接,让大家可以获取更多信息。话不多说,让我们开始吧。

Metrics:用于监控,不止监控

这一系列文章主要关注的是如何监控和运行Kubernetes集群。使用日志是一个不错的方法,但在大规模部署的情况下,日志在事后分析工作中可能有很大作用,却难以在过程之中不断警告运维人员那些正在出现的越来越严重的问题。Metrics Server可以监控容器的CPU和内存使用情况,以及容器所运行在的节点的情况。

这让运维人员能够设置并监控KPI(关键绩效指标)。这些运维定义层面的东西可以为运维团队提供一种确定应用程序或者节点何时不健康的方法。同时也给他们提供了查看问题所需要的所有数据。

此外,Metrics Server
(https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/)允许Kubernetes启用Horizontal Pod Autoscaling
(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)。该功能可以让Kubernetes在扩展pod实例数量时,是基于Kubernetes Metrics API报告的指标以及这些指标反映出来的API对象数量来进行扩展的。

在Rancher Kubernetes集群中 设置Metrics Server

从Kubernetes 1.8版本开始,Metrics Server以Kubernetes Monitoring Architecture
(https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)插件的方式成为了拉取容器指标的标准。在该标准出现之前,默认使用的是Heapster,现在已经弃用,而开始支持Metrics Server。

很快,Metrics Server就将可以在Rancher 2.0配置的Kubernetes集群上运行了。您可以在Rancher的Github repo中查看Rancher 2.0最新版本的发布动态,一起期待:https://github.com/rancher/rancher/releases。

如果想让Metric Server工作,你必须通过Rancher Server API修改集群的定义。这样可以允许Rancher服务器修改Kubelet以及KubeAPI参数,让它们包含Metrics Server正常运行所需要的标记。

有关如何在Rancher Provisioned集群上执行这一操作,以及修改其他hyperkube-based集群的说明,可以参考github的这一链接:https://github.com/JasonvanBrackel/metrics-server-on-rancher-2.0.2。

混合云场景下容器技术在新能源功率预测产品中的最佳实践

Rancher 发表了文章 • 1 个评论 • 854 次浏览 • 2018-07-13 15:38 • 来自相关话题

能源互联网是物联网和“互联网+”在能源行业深度融合的产物,是中国制造2025的重要组成部分,我们现在还处于能源互联网的早期阶段。绝大部分能源行业的应用都部署在私有局域网内,并且网络结构异常复杂,这是阻碍互联网技术在能源行业落地的最大挑战。 ...查看全部
能源互联网是物联网和“互联网+”在能源行业深度融合的产物,是中国制造2025的重要组成部分,我们现在还处于能源互联网的早期阶段。绝大部分能源行业的应用都部署在私有局域网内,并且网络结构异常复杂,这是阻碍互联网技术在能源行业落地的最大挑战。

6月28日,金风科技数据平台架构师张利出席了Rancher Labs举办的Container Day 2018容器技术大会,并做了题为《混合云场景下容器技术在新能源功率预测产品中的最佳实践》的演讲。

金风科技是中国成立最早、自主研发能力最强的风电设备研发及制造企业之一。作为金风科技数据平台架构师、Team Leader,张利自2014年加入金风科技后,主要负责公司新能源功率预测产品的研发、数据平台的搭建、以及解决方案的规划。他带领基础架构团队建立多云和混合云场景下的持续交付平台、搭建能源气象平台,实现功率预测产品的微服务化改造、完成该产品端到端的交付,实现产品到解决方案的平台化改造。

在演讲中,张利从金风科技的实战经验出发,为大家解读了容器技术如何应用在传统能源行业中,如何实现混合云场景下功率预测产品的快速落地。本文由演讲内容整理而成。

金风科技主要做的产品是新能源功率预测产品,是一家典型的制造业公司,软件并不是主业。但是随着能源互联网的发展,能源企业开始转型,我们的软件产品也开始变得非常丰富起来,同时有很多场景想强大现有软件的产品线,于是我们开始一点点进行转型,并基于现在的互联网技术去做传统制造业的业务。

金风科技是国际化清洁能源和节能环保的整体解决方案提供商。公司成立了20年,现在管理着38GW的风电场的装机容量,现有风机数量2.5万台,整个在全球排名第3,已经连续至少5年中国市场排名第一。这是目前我们对整个环保做的一些贡献。

业务背景


3.png


功率测产品是个什么样一个场景?它是基于天气预报加上AI两个技术进行预测。天气预报得到了时间跟风速的曲线,然后之后是用AI去训练功率曲线,将风速跟功率的曲线组合,得到的结果就是一个预测的基于时间的功率,也就是整体的发电量的情况,这是我们大概的业务场景。


4.png



实际上,我们的软件在网络层非常复杂。我们有严格的安全保护,将网络分成了两个区,一般所有的系统不能部署在外网,都是部署在隔离区内,中间放了一个应景的防火墙,数据只能通过文件的形式往里进,出去是基于UDP跟阉割版的TCP的协议,这里面很多协议是不能用的,这是非常复杂的部分,所以发布软件的时候是十分困难的,大部分时间只能人为地发布软件产品。


5.png


还有另外一点是,部署架构也特别复杂。在2010年之前,大部分的电场是分布在中国各个偏远山区、戈壁之类的地方,因为那里的太阳能和风能十分丰富。到了2010年的时候,出现了一些区域的中心,他们会把这些散落在各个电场的数据全部都拿上来进行统一的风电场监控。2010年到2015年之间,这些电场开始有集中化的监控。到了2015年,功率测的产品开始变成一个集中化的产品,我大概是那个时候入职金风,开始做集中式的功率测产品。有一个复杂的地方是,所有的软件系统既要部署在边缘节点的电场,也要部署在省中心的一个小机房,还要部署在客户的总部。

最佳实践


6.png



现在我们在边缘节点的架构已经完全的容器化了。在业务层会有一些标准的IOT的场景,比如说采集、存储、ETL展示,这是标准的一个做法。另一方面,由于我们是基于AI进行预测,因此有一部分是基于TensorFlow去做预测,而那个部分是由一个独立的团队进行,因此实际上发布十分困难,尤其是AI的部分。下边会再详细分析这个问题。

7.png


这个AI分两部分,一个是离线的AI,这个我们在2015年已经实现了在云端的预测,是短期一天发布一次。在线的预测是15分钟,我们称为超短期的预测,这个业务现在还是在边缘节点,也就是分布在各个场站和省中心、区域中心,我们现在是计划一点点把它部署到公有云上来计算,进而提高预测准确度。

8.png


在业务系统上边,现在正在面临一些挑战,比如,客户的需求不稳定。我们从2015年才开始开发这个系统,而且每个客户的需求不完全一致,因此这个系统更新的次数很频繁。大家可能认为一个传统的企业,它的软件的产品发布不应该那么频繁,但是事实上并非如此,随着能源互联网,包括可再生能源这些绿色清洁环保的能源受到中国政府的重视,为了实现平价的上网,考核的力度在不断加大。如果这些新能源要平价的上网,包括功率测的准确度,是在其中起到重要支撑作用的一个业务,因此客户的需求不断的变,系统更新的频率也在不断的增加。另外一点,就是之前提到AI算法,其实想放到云端,但是这是一个在线的业务,涉及到数据的回传,如果算完之后再下发下去,整个过程会变得非常复杂。从偏远山区到一个省中心,再到客户的数据中心,一般是在一个大城市,然后再到我们的公有云上,整个链路非常长,数据的回传跟下发十分复杂,再加上刚才说的网络的结构也非常复杂,导致如果在线AI算法十分麻烦。

9.png


另外有一条是在公有云上的业务,底层也是基于容器云平台,我们自己做了一套,数据弧的这一层稍微简单,也分了采集进存储,存储里边是我们自己用的,业务数据库用的是MongoDB,有一部分是Hadoop,GlusterFS,S3。上面分了三部分,一部分是我们做功率测的业务层,包括它的运营也是一条ETL展示。另外一个部分,其中一个核心是天气预报,紫色的那个颜色WRF实际上是天气预报里一个核心的高效能的计算,类似于HPC那样,它一般跑在超算中心或者是公有云上。一般情况下,运行在超算中心,这个超算中心是没有云化的,所以那个业务也比较复杂。另外一点就是一个独立的AI模块,将它做了一个训练进预测的拆分。整个业务是三大业务,再加上底层的容器云平台,把那个存储层作为一个公共的池子,这是现有的业务架构,但实际上这会不断的变化,而且也在不断的扩大。

10.png


在公有云上这套业务系统里边,目前最大挑战是要实现跨业务部门,比如做功率测的,还有一些集中监控、预警等很多个部门,整个产品线大概包括10个到20个产品,因此各个部门之间数据要经常的相互流动,要做成公共的平台性的业务。此外,还要实现对外服务,对客户能够发布一个通用的服务。

11.png


关于能源气象这个部分,我们开始把它做成一个国际化的能源气象服务。另外,风能和太阳能可以同时去提供服务。虽然我们本身是做风力发电的,但是实际上在功率测方面是不分风和太阳能的,所以这个服务是把两个全部加到一起。

12.png



除了在AI算法里边的挑战,在公有云上的挑战就是此前提到的在线的预测系统如何搭建,包括数据的传输层是很复杂的。另外一点就是在大数据跟AI一个整体的解决方案的搭建。

机遇与挑战


13.png



我们现有的机遇跟挑战,从DevOps角度来看,之前我们大概是两周一次的发布频率,速度很慢,因为涉及到很多个电场同时去发布是十分复杂的,但是现在几乎能做到一天一次,这是用容器化的平台的优势,即可以实现更高的发布速度。另外一个挑战是,由于我们是传统企业,大部分的运维人员实际上对新的技术了解得比较少,因此对他们来说要求较高。现在整个运维团队有十几个人,但是实际上真正懂这个技术的只有一两个人,所以这个挑战很大。另外一部分就是在微孵化改造的过程中遇到一些问题,好处是系统扩展性变强了,但是随着业务不断地迭代,业务不断地增加的时候,拆分力度很难把握。现在有些服务开始拆掉,有些服务要合并,这对整个架构是一个非常大的挑战。另外一点挑战就是为了提高准确率,在AI层面会有一些很大的困难。机遇就是对于算法工程师来说,他们不需要再去部署底层的架构,降低运维的成本。首先他们实际上不是在一个公有云、一个集中式的系统上,而是分布在几百个这种电场,运维成本很高。算法工程师在发布这个算法的时候,实际上他们学习Docker技术是十分困难的,因为大部分算法工程师是学数学出身的。

总 结

14.png


金风科技现在大概使用这个系统已经有两年的时间,目前能够实现运维成本能降低50%左右,迭代速度提高10倍,从两周一次增快到一天一次,并且现在已经覆盖50%的电场,大概的规模是200个左右,覆盖的客户有五个大的集团客户,有十多个省中心的客户。

Bare Metal K8S集群在美国快餐连锁Chick-fil-A 的大规模使用

Rancher 发表了文章 • 1 个评论 • 858 次浏览 • 2018-07-13 15:22 • 来自相关话题

快餐连锁店Chick-fil-A在其2000多家餐厅的边缘计算中使用着Kubernetes,在规模上看,这意味着有大约6000台设备上同时运行着Kubernetes。其中与此相关的最大的一个挑战是:如何在餐厅的物理机上部署和管理这么多Kubernetes集群。 ...查看全部
快餐连锁店Chick-fil-A在其2000多家餐厅的边缘计算中使用着Kubernetes,在规模上看,这意味着有大约6000台设备上同时运行着Kubernetes。其中与此相关的最大的一个挑战是:如何在餐厅的物理机上部署和管理这么多Kubernetes集群。本文由Chick-fil-A的技术团队所写,分享他们在Kubernetes集群管理技术选型、物理机上Kubernetes集群的安装和管理方面的经验。

大多数情况下,Kubernetes都在云中部署,或由熟练Kubernetes的技术人员在物理机上部署(再或者至少配有远程访问)。但对Chick-fil-A而言,我们的Kubernetes部署是由那些仅关注初始硬件安装的安装人员完成的。因为其自启动的特性,它们从不需要直接连接到计算设备——而是连接以太网和电源线,并通过查看应用程序app来检查集群的状态 。整个替换过程由对技术并不太专业的餐厅老板/运营者或他们的团队完成。

最大的挑战是,我们的边缘计算部署并不完全在“数据中心环境”中。

640.webp_(4)_.jpg


边缘计算硬件及经典的安装方式

集群管理:我们考虑过的选择

为了解决集群管理的挑战,我们做过全面的技术调研,曾考虑过如下几个选项:

Kubespray - 我们最开始调查了基于Ansible的Kubespray,但我们发现它相当脆弱。当事情进展顺利时,我们能得到了一个集群;但当事情进展不太顺利时,我们就会创建一块难以变回计算机的“砖块”。我们还发现使用Kubespray启动集群的过程非常缓慢,通常在我们的硬件栈上花费的时间长达30分钟。我们相信Kubespray能有更长远的发展,但就我们的调研结果而言,我们认为得从别的方向探索别的解决方案。

Openshift - Openshift可以创建Kubernetes集群,但我们不喜欢在至关重要的基础设施部分跟供应商的解决方案捆绑地太过紧密,不想承担未来可能被技术锁定的风险。

Kops - 我们是Kops的忠实粉丝,我们用它来部署我们云的“控制面板”Kubernetes集群。不幸的是,当我们将其使用到我们的边缘计算中时,Kops并不是一个可行的裸机解决方案。我们期待看到它在未来的发展。

Kubeadm - Kubeadm是另一个不错的Kubernetes集群实用程序。Kubeadm项目看起来很有发展前景,但我们认为它比一些替代品 (尤其在其灵活性上)复杂的多,包括...

RKE

就我们目前的选择而言,RKE是最终赢家。RKE是由Rancher Labs提供的开源的Kubernetes集群管理引擎。虽然我们暂时未使用Rancher 2.0来管理我们的集群,但我们确实喜欢使用RKE来初始化和维护集群的简单性。

640.webp_(2)_.jpg


要使用RKE,你需要确定一个领导节点并为其提供一个配置YAML文件,YAML文件中包含有关该集群的数据,主要是参与集群活动的节点的主机名。

如果集群中的节点发生添加、删除、或死亡,则配置文件需要拥有一个对当前和未来节点的准确描述。如果配置不能保持持续最新,集群就会失败。虽然我们认为缺少节点不应该使群集初始化/更新失败,但目前来看实际情况正是如此。

安装过程

我们在餐厅的安装过程非常简单——将设备拆箱,将其插入电源和标记的交换机端口,就是这样。它们会自动启动电源,并实现自引导和集群创建。RKE让非技术用户能够在不了解Kubernetes甚至整体架构的情况下,通过无比简单的过程执行安装和替换的工作,这一体验非常棒,不过它也确实需要一些更复杂的引导过程。

尚未被纳入集群的节点之间,需要彼此协调以确定谁将被纳入到集群中。他们还需要选出一个主节点来通过RKE执行集群创建。

Highlander

为了解决这个问题,我们开发了Highlander。因为我们只能有一个集群发起者。

Highlander是我们基础边缘镜像的一部分。当每个节点启动时,UDP会广播其存在并询问是否存在已建立的领导者。它也会开始倾听自己。几秒钟后没有回复,它将发送另一个广播,宣布自己成为领导者。有什么异议吗?如果没有反对的讯息,该节点将很快成为集群领导者,并以领导者身份回应未来接收到的所有请求。

如果另一个节点已经声明了自己领导者的角色,新节点将确认该声明。现有的领导者会执行“RKE up”将新节点纳管到现有的集群中。

节点们会定期沟通以确保领导者仍在其中。如果旧领导者已经死亡,一个新的领导者将通过一个使用随机睡眠和领导声明的简单协议来选举而出。虽然这很简单不复杂,容易推理和理解,但它能实现成规模地有效工作。

领导者选举完成后,Highlander还能确保集群被正确得配置。在我们的环境中,这包括:
• 将 KubeDNS切换成CoreDNS
• 创建Istio或其他核心控制面板节点
• OAuth身份认证

注意:我们的每个节点都有自己的身份和短暂的JWT来访问已验证的资源。Highlander提供此身份,并以Kubernetes秘钥的形式来提供token令牌。

整合过程

尽管我们在本文中主要关注集群初始化,接下来我们也介绍一下在餐厅中实时进行节点初始化的整个流程。

640.webp_(3)_.jpg


(不可避免的)失败

最后我们想分享一些失败的经验。若基础设施出现故障,我们希望能够灵活应对。节点故障可能由多种原因导致:设备故障,网络交换机故障,电源线意外拔出。在所有这些情况下,我们必须快速诊断什么是导致故障的真正原因,而什么是无关的异常。这个过程很复杂,未来我们会带来另一篇文章来以此为主题展开分享。也就是说,当我们诊断失败时,我们的流程是向餐厅投放一个基本图片替代品(包含可视化安装说明),并让餐厅老板/运营者或他们的团队执行替换工作。

同时,我们的Kubernetes集群将继续在节点数量减少的情况下运行,并随时准备迎接更换节点。

中国东信基于Kubernetes的容器云PaaS平台

Rancher 发表了文章 • 1 个评论 • 1862 次浏览 • 2018-07-13 12:23 • 来自相关话题

“中国-东盟信息港”是按照国家“一带一路”倡议总体布局要求、建设更为紧密的中国—东盟命运共同体、21世纪海上丝绸之路的一个信息平台:http://www.caih.com。东信基于Rancher Kubernetes架构和建设了他们的容器云PaaS平台,在云原 ...查看全部
“中国-东盟信息港”是按照国家“一带一路”倡议总体布局要求、建设更为紧密的中国—东盟命运共同体、21世纪海上丝绸之路的一个信息平台:http://www.caih.com。东信基于Rancher Kubernetes架构和建设了他们的容器云PaaS平台,在云原生、容器化、微服务、CICD、DevOps等方面的都有了相关实践和应用。

6月28日,负责中国东信容器云PaaS 平台的研发和建设、中国-东盟信息港的研发总监王志雄出席了Rancher Labs举办的Container Day 2018容器技术大会,并做了题为《中国东信基于Kubernetes的容器云PaaS平台》的主题演讲,本文根据演讲内容整理而成。

王志雄,中国-东盟信息港研发总监,负责中国东信公司容器云的研发和管理工作。硕士,曾就职于IBM、华为等公司,在IBM时任研发部门经理、技术专家。10年以上的云计算IaaS、PaaS、容器云、SDN/NFV、微服务、DevOps等研发经验。

各位来宾,各位朋友,大家上午好,我是来自中国-东盟信息港的王志雄,在中国东信负责容器云PaaS 平台的研发和建设。今天我从技术角度、就如下四个方面,给大家分享中国东信基于Kubernetes建设容器云PaaS平台的经验。


image001.png



第一个是PaaS平台,PaaS平台在云计算刚出现的时候就已经和IaaS、SaaS已经共存了,但是刚开始只是不温不火,为什么到这几年PaaS平台才这么火了呢?如何来建设一个PaaS台?PaaS平台需要哪些技术内容来承载?我会在这里做一个分享。

第二个是微服务,微服务我们说有两条路线,第一条是SpringCloud,第二条是Kubernetes,我们来看一看怎么使用Kubernetes来构建一个微服务的平台。

第三个是CICD ,第四个是DevOps。我们会看到有些场合说的CICD,有的场合说的DevOps,这二者有什么关系,有什么区别,如何来构建CICD 和DevOps,我会在这里做一个揭晓。
#Kubernetes与容器云PaaS平台
我们首先来看一下Kubernetes与容器云平台。Kubernetes这个PaaS平台要解决三个方面的IT架构方面的问题。第一,耦合,我们做研发的知道,除了应用程序之外,不管Java,还是Go,还是Python,都需要大量的应用配置,这些配置和我们的系统环境——Windows也好,Linux也好——都是耦合的,所以会经常出现我们在交付产品的时候,明明在研发的环境可用的,到了测试不可用,到了最后的生产发布也不可用,从而出现这样的神秘的BUG、神秘的配置。之前有人提出一个比较好的方法是写一个很好的文档以供参考,但是文档通常还是会遗漏,而且这还要依赖于我们人员写文档的能力,以及理解的能力。第二个,繁杂,现在不论是技术、工具还是语言都非常繁杂,例如语言有java、有Go、有python、有php。第三个,不灵活,我们现在互联网时代是需要从按周发布,提升为按天发布,甚至一天几次、十几次甚至上百次发布,这在以前的物理机或者虚拟机时代是不可能的。


image002.png



所以如何来解决这些问题?Cloud Native是这个答案。Cloud Native能做到什么呢?第一是容器化,把应用以及它的配置打包,保证开发、测试和运维的环境一致,从而避免神秘的配置、神秘的错误、神秘的文档、还有可能是神秘的人。第二是面向微服务,把以前的一体的区域式服务给分解为微服务,从而更灵活,并可以独立更新。第三方面是动态编排管理,如果容器很多,则需要大量的配置文件,需要部署很多容器则必然要用到编排管理,也就是我们在此选择的Kubernetes。


image003.png



下图是中国东信基于Kubernetes、Docker研发的四大场景。第一是企业应用平台,企业应用平台可以将应用在平台上做到一键部署,利用pod auto-scaling进行弹性自动伸缩,如果出现故障则可以通过health check实现故障自愈,另外还有强大的灰度发布功能。之前的互联网公司可能需要一个非常大的团队来做灰度发布,如今使用Kubernetes,Kubernetes已经自带灰度发布功能了。第二个是我们的微服务,用Kubernetes来构建我们的微服务平台,构建之后我们就可以组件化、松耦合、去中心,而且是灵活独立的。第三个我们做了这样一套CICD的系统,CICD的系统从我们的开发、从代码提交、从编译到构建到自动化测试、到容器化发布。第四个是DevOps ,DevOps是可以做到开发运维的协同。


image004.png



这是我们中国东信的PaaS 平台,我们从最底层看起,最底层是容器云的Infra,我们说Infra不是IaaS产品吗?其实不管是IaaS还是PaaS 都需要Infrastructure,当然它们是有区别的。我们不管做Iass做PaaS ,其中的难点归到最后其实都是存储和网络,我在后面会分享存储网络我们是怎么做的。再上来是容器资源管理,以及容器集群编排与调度,需要把这个Pod调度到众多集群节点中的哪一个?根据什么策略来调度?根据CPU调度还是根据内存调度?根据亲和策略还是反亲和策略?再上来是我们容器云应用Service,我们说PaaS 平台是以应用为中心,所以肯定需要这样一个强大的应用Service,PaaS平台应用的Service有服务发现、配置中心、负载均衡、弹性伸缩、服务编排这样一些强大的功能,那么就用我们的PaaS平台,上面我们会提供中间件、数据库、负载均衡、文件存储等等。如果需要哪一个,比如需要一个MySQL ,把一个MySQL容器拿过去用就可以了。再去用我们的中间件,PaaS平台上面就承载我们庞大的、灵活的企业应用。


image005.png



如果研发过Kubernetes应该对这个图很熟悉,这是个典型的Kubernetes集群,我们分两个层面来看。第一个层面一个是我们自己内部的管理,部署Service,Service都是通过Master进行来管理,通过API Server来和各个组件进行交互,用Controller Mananger来控制我们各个组件获得的调度,Scheduler是具体的应用策略,etcd 是一个数据库。那么会调度到我们的Node上,Node上存在我们的Pod ,一个Pod里可以有可以有多个Container,这是我们的内部的管理提供Service。第二个层面是我们从外部的访问,外部的访问一般就是通过Internet经过防火墙来访问我们对外提供一个ingress ,ingress是Kubernetes提供的一个非常强大的功能,有了ingress 之后,我们可以对外提供一个统一的域名系统,外部只要访问我们的统一域名,就可以访问我们内部的不同的应用,通过此域名就可以进行智能的分发。

image006.png


上面我们说的叫物理架构,而下面我会讲讲逻辑架构,这两个的关注面不一样。逻辑架构从我们研发内部看,最底层是容器基础设施层,包括我们的Runtime、Volume Plugin、Network Plugin;再上来是核心层,核心层对外提供API,对内提供Plugin环境;第三层是应用层,可以进行部署,可以进行ingress智能路由;再上来是管理层,可以进行智能化以及Network policy;接口层是对外提供我们的命令行管理工具;Ecosystem是我们的生态。


image007.png


刚才说PaaS的基础架构的终极难题是网络和存储。我们先来看一下中国东信是怎么解决网络问题的。网络的方案非常多,我们看到有单组区域的,开始是单组区域有bridge、host、container、NAT,也有原生的iptables;再上来有主机集群,有OVS,有IPSec;现在最主流的就是最上面一行,一个是Flannel,一个是calico,还有将这两个折在一起的Canal。这里我可以提一下我们的SDN(软件定义网络)。SDN起源于Openflow,什么是Openflow?Openflow是有强大的报文解析能力,可以对报文进行任意的更改,这个强大的能力刚问世时取得了瞩目的关注,并且在当年被评为未来10大创新技术的排名第二位,第一位是云计算,第二位是SDN。但最初Openflow在问世后的广大的应用中碰到了一些问题,因为它和以前传统的不兼容,所以实际上最后被应用最多的是VXLAN。VXLAN是一个overlay的技术。SDN在应用最多的是什么?是VXLAN overlay。第三个是BGP,BGP在网络中应该有二三十年的历史,经过不断地打磨、沉淀、优化,实际上BGP已经开始统一我们的SDN领域了,现在BGP已经可以取代我们的软件定义网络,虚拟化的网络。

image008.png


SDN网络通用的两个方向,第一个是Flannel,Flannel其实本质上是一个Overlay的方案,所以在主机的容器内是自动分布的IP,只是在主机之外,做了一个Overlay叠加的封装,但这个Overlay和我们传统的IaaS的overlay相比其实是不一样的,传统的IaaS的VXLAN除了Overlay的功能,还有多租户的功能,但是这里因为它只在出口做了个封装,所以没有多租户的功能。所以Flannel有什么缺点?它没有安全隔离的功能。第二个它封包解包必然带来开销,所以这个是我们要解决的问题。Flannel官方也表示如果用户想对数据中心做更好的网络安全隔离,推荐用Calico。

image009.png


Calico的核心是基于BGP,如果是小网络可以用BGP的client进行IP路由的自动分发以及路由互联。Calico的好处是什么?简单!若是使用Overlay网络出现故障,用户难以排查故障是来自overlay还是underlay;但用BGP,用户直接定位路由就好了。此外,Calico还带了一个很好的特性就是和network policy结合在一起,可以提供网络的微分段,若一个主机上有多个容器、有多个应用,可以提供很好的安全隔离。Calico的不足是什么?它需要取决于数据中心对于BGP的支持力度,可能现在还不是所有数据中心都是BGP。但我还是推荐BGP的,从最初的的Facebook到现在国内的大公司,很多都已经开使用BGP来取代所有的内部的路由协议,包括二层协议。这是一个很好的方案,可以简化运维工作,数据中心只有一种路由协议多好。

image010.png


图片描述谈完网络,另一个难题就是存储。Kubernetes和Docker相比除了普通的volume之外,还提供了persistent volume和storage class,通过PV和PVC来抽象存储细节。这有什么好处?可以做到管理控制与转化分离。管理员关注PV的存储细节,用户只要关注PVC使用存储就好了。通用的存储ceph、NFS、Gluster都没问题。

image011.png


容器云微服务
下面我们来看一下怎样用Kubernetes来构建一个微服务。下图是我们很熟悉的微服务架构的特性,把一个单体的应用来分解拆分为多个灵活的微服务。微服务的特性是服务的组件化。怎样拆分一个微服务?不是按代码的行数,不是按函数,而是按功能、按产品模式来拆分。有了微服务就可以去中心化的管理。


image013.png



构建微服务,必然要有如下这些功能:有这么多的服务,怎样发现这个服务?所以要服务发现。多个服务如何做到负载均衡?多个应用service怎么样进行智能的路由分发?怎样管理成千上万个服务的配置?怎样弹性伸缩?怎样容错?怎样自动升级?访问控制怎么做?

放在13、14之间.png


下图就是我们使用Kubernetes来构建的微服务。怎样来构建?把上述问题的答案汇聚在一起就是最终答案了。第一个服务发现,使用我们的service,包括我们Kubernetes内置的DNS就可以来做这样一个服务发现。第二个负载均衡,有node上的kube-proxy加上我们的service分发是负载均衡。第三个智能路由,通过ingress可以智能地将不同的应用通过统一的入口分发到后端的服务。配置中心通过我们的Kubernetes的config-map,可以在一个统一的服务器上进行远端多个微服务的配置的统一管理、统一更新。明文用config-map,如果重要的机密的配置可以secret。

再接下来是我们的服务编排,deployment是实际使用过程中用户非常欢迎的一个特性。因为deployment把这个yaml文件写好之后,大家去自动部署了,需要几个副本,它会自动的去扩容以及缩容deployment。如果需要开发一个应用商店,可以去helm开发。

再下来是我们的弹性伸缩,通过RS写好副本数,再通过auto-scaling指定需要自动伸缩的条件,比如说可以基于CPU伸缩,可以基于我们的内存访问伸缩。再下来是我们的容错,使用我们的liveness来监控我们的容器以及应用的健康状况,如果容器挂掉了,可以把它重启,如果这个节点挂掉了,那就把容器调度到另一个节点。熔断怎么做?可以用我们的readiness,readiness不但可以监控我们的容器的存活,还可以监控我们的service是否是健康的。

限流,限流可以通过我们的quota限额,可以通过我们的namespace限额,也可以对我们的pod限额,也可以对容器限额。

升级,rolling updates是自动升级,有问题可以一键回滚。那RBAC是可以提供基于角色的安全访问。Network policy在BGP Calico基础上提供微分段,可以很好的安全隔离,包括日志监控EFK和Prometheus。

放在13、14之间.png


容器云CI/CD
如何来做容器云的CI/CD,自然使用我们的容器云三剑客,Jenkins+Docker+Kubernetes。其实在容器云出现之前,其实已经有CI/CD了,那时CI/CD用Jenkins做,Jenkins可以提供编译、构件、测试、任务调度的流水线;那Docker有什么作用?可以让我们的环境标准化,可以隔离;Kubernetes可以提供一个大的平台,可以让资源共享、弹性伸缩。


image014.png



图片描述CI/CD也就是需要把开发、测试流水线做一个自动化,从开发、编译、构件、测试、打包到部署,所以在我们的测试报告出来之后,如果是通过了就把镜像上传到镜像仓库,然后再发布到Kubernetes的发布平台。

image015.png


DevOps
谈完CI/CD我们来看一下很火的DevOps。通过这张图我们其实就可以看出CI/CD和DevOps有什么区别,有什么联系,什么场合该用CI/CD,什么场合该用DevOps。CI/CD在左边,CI/CD最关注的是开发和测试,关注的具体的序数是什么?是Jenkins来做个流水线,是Git来做一个源代码的仓库、源代码的拉取,Maven来做构建,SonarQube来做静态的代码分析,Robotframework来做自动化的测试。SonarQube这样一个代码分析工具对我们的编译通过之外的一个保证把它良好的代码是有非常好的好处。因为我记得还是在十年前,当时在一个国内特大公司入职培训的时候,一般的导师对每位员工都会培训一个案例:代码规范。好的代码并不是通过编译就行了,而且需要好的编程规范,避免通过了编译但却其实会出现神秘的故障,而且很难定位。

看完CI/CD,我们来看看DevOps关注什么。DevOps的关注的是我们发布的环境要自动伸缩,要A/B Test,要灰度发布,要自动的升级,或者要滚动升级,滚动升级就是指不是一次性升级完所有的pod,还是可以选择性的升级一部分,比如升级20%,或者升级50%。有什么好处?可以使我们的应用服务不中断。它们两者的共同点,当然都需要基于Docker和Kubernetes来做这样的一个容器化封装和自动化。右边的这个DevOps其实是DevOps刚出现的时候,我们叫标准的DevOps。它和CI/CD有区别,但是其实有很大的联系,CI/CD和这样的标准DevOps组合起来就叫做我们的大DevOps,所以这两者是可以结合起来,CI/CD解决我们开发、测试、自动化、标准化的问题,标准DevOps解决我们的开发运维,主要是运维方面的问题,只有这两者结合起来就可以一键式解决我们的开发、测试、运维问题,并且可以形成一个闭环。


image016.png


下图就是滚动升级这一功能,可以通过逐个容器替代,升级其中的25%的容器,然后再确认一下,如果工作正常,我们再可以升级其中的下一批容器。

image017.png


下面是灰度发布。这在我们日新月异的频繁发布的互联网场景特别有用。因为我们有大量的互联网应用。所以有一个特别好的新功能,像看看它的这个功能,看看用户的反馈,用户的使用情况怎么样,我们的灰度发布。用Kubernetes的pod非常方便。开始可以给一个灰度版本1,内部用户使用的没问题,再给一个版本2,给我们的用户群,用户群A,再逐渐的扩大到所有的用户,这是互联网非常好的应用。

image018.png


总结
这里来回顾一下中国东信基于Kubernetes开发的这样四大场景。第一个是PaaS企业应用平台。第二个是Kubernetes的微服务,SpringCloud也是微服务,但SpringCloud微服务是主要关注在应用层面,而且它只是针对Java有效,对别的语言是没有的。Kubernetes是语言无关的,而且是比SpringCloud使用面更广的,但最佳的实践是可以把我们的SpringCloud的每个微服务通过容器化的方式进行封装,再通过Kubernetes进行平台的集群资源调度和自动伸缩。第三个就是我们CICD,第四个是我们的DevOps。

DockOne微信分享(一一六):某股份制商业银行定制化PaaS介绍

DarkForces. 发表了文章 • 0 个评论 • 3030 次浏览 • 2017-05-04 20:11 • 来自相关话题

【编者的话】某股份制商业银行的PaaS平台是由Wise2C与Rancher合作,基于Rancher做的定制化开发。基于业务场景和银行业的特殊需求,同时为了兼顾能够实现对以后Rancher版本的平滑升级,我们在Rancher之上做了一层逻辑抽象。 ...查看全部
【编者的话】某股份制商业银行的PaaS平台是由Wise2C与Rancher合作,基于Rancher做的定制化开发。基于业务场景和银行业的特殊需求,同时为了兼顾能够实现对以后Rancher版本的平滑升级,我们在Rancher之上做了一层逻辑抽象。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
# 1. 软件架构与部署方案
整体软件架构如下图所示:
图片1.png

顶层的DCOS作为统一的管理平台,可以通过PaaS以及IaaS提供的API实现对云平台的集中管控。左侧蓝色部分是原生Rancher,DCOS与红色定制化部分通过API来访问Rancher。由于未对Rancher做任何改动,可以做到对Rancher版本大于1.2的平滑升级。

红色部分为定制化逻辑抽象部分,归纳起来可以按照功能职责大致分为以下微服务(后面会详细介绍):

* 鉴权认证
* 资源管理
* 应用编排
* 弹性伸缩
* 日志收集
* 监控告警
* 镜像仓库

这些微服务在部署时按照Rancher将infrastructure stack部署到环境中的思路,使用一个独立的Rancher环境来部署这些微服务,部署拓扑结构如下图所示:
图片2.png

图中每一个虚线框对应Rancher中的一个环境;“扩展ENV”这个环境直接使用Rancher server的主机作为Agent,上面运行定制化的微服务。其他环境分别对应到某个租户的特定网络,单个网络内部流量不使用Rancher原生的overlay,而采用Wise2C实现的扁平化网络,网络之间流量由外部防火墙控制。
# 2. 角色与权限模型
PaaS平台的角色与权限模型沿用了Rancher的一部分概念,又引入了自己的内容。主要差异在于两方面:

  1. PaaS平台引入了对镜像仓库的管理,这在Rancher中是没有的;即角色的权限,除包含操作Rancher外,还能够操作镜像仓库。镜像仓库与PaaS的权限模型是一致的;
  2. 另外,客户引入了租户的概念,这点与Rancher中不同,租户是可以跨越多个Rancher的环境的;

##Rancher权限模型:

  • 平台管理员:
拥有整个Rancher平台的所有权限;
  • 环境用户:
Owner,拥有环境的所有权限; Member,拥有除对环境内部用户授权外的所有权限; Restricted User,拥有环境内部除对用户授权以及操作基础资源外的所有权限; Read Only,拥有环境内部资源的只读权限。## PaaS平台权限模型
  • 平台管理员:
等同于Rancher的平台管理员权限再加上对镜像仓库管理的所有权限;
  • 租户内部角色:
租户管理员,拥有管理租户资源以及对租户内部用户进行授权的所有权限,再加上对镜像仓库管理的所有权限。 高级成员,在PaaS平台内拥有对租户内用户授权以及操作基础资源外的所有权限,在镜像仓库内,拥有对镜像仓库设置镜像同步规则、创建、删除镜像仓库Namespace、改变镜像状态等权限。 受限成员,在PaaS平台内拥有对租户内用户授权以及操作基础资源外的所有权限,在镜像仓库所属Namespace内,拥有上传、下载镜像的权限。 Read Only,在PaaS平台内,拥有查看租户类资源的权限,在镜像仓库所属Namespace内,拥有查看镜像仓库资源的权限。具体映射关系如下图所示:
图片3.png
鉴权部分的软件设计如下所示:
图片4.png
所有对PaaS访问的API请求均经由API proxy做鉴权控制之后代理到系统内部具体的微服务上。PaaS不直接参与租户的增删查改,API proxy通过与PaaS外部的Keystone通信来获取用户角色以及租户信息。# 3. 资源管理##网络部分[list=1]
  • 由于金融行业对网络安全性方面的要求比较苛刻,而Rancher所能够提供的均是基于某个环境内部的overlay网络。Overlay必然会导致很多报文无法被安全设备透明的过滤,这是行业内无法接受的;因此,必须采用扁平网络。
  • 处于安全的考虑,会出现同一个stack内部的多个service需要分别部署到不同的网络分区的需求,采用当前Rancher的managed网络显然无法满足需求;因此,必须支持多网络。
  • 对于扁平网络的支持,我在之前的文章(在Rancher 1.2中实现基于CNI的扁平网络)中有详细的介绍,主要是使用ebtable直接在linux bridge上对流量做控制,从而避免使用overlay;这样,外部安全设备能够透明的看到各个容器之间的流量。
    图片5.png
    对于多网络的支持,我们是通过在Rancher之上实现一层抽象逻辑来实现的。整个模型演变为一个网络映射为Rancher的一个环境(环境内部运行一个扁平网络)。这部分主要涉及对平台中所有网络的管理,以及维护租户与网络之间的映射关系。下面举一个例子来描述该流程:
    图片6.png
    平台管理员在PaaS上创建一个网络,指定网络的参数(子网掩码、网关、所属安全域、所属隔离域等),这些数据会保存到数据库;平台管理员根据需要为租户分配第一个网络;此时,抽象层需要真正在Rancher上创建出网络所对应的环境;以及创建监控、日志、以及定制化系统所需的system级别的应用堆栈;当平台管理员为租户分配第二个以上的网络时,抽象层还需要将该Rancher环境与租户其他网络对应的Rancher环境之间建立env link关系,否则跨Rancher环境的应用堆栈各service之间无法使用Rancher DNS进行互访。## 存储部分客户PaaS在存储部分最终选定NFS作为其存储方案,前期也有讨论过使用ceph等,这部分我在之前的文章(探讨容器中使用块存储)中也有专门分析过为什么不选用那种方案。由于单个租户可以拥有多个网络(也就是多个Rancher环境),而在Rancher中Rancher-NFS driver所创建volume是基于环境层面的。为了能够将该volume映射到租户层面,我们在抽象层中做了这层映射操作。##具体流程如下:平台管理员在PaaS中指定参数创建出一个NFS server;同网络一样,此时只是将数据保存到数据库;平台管理员为租户分配NFS server,此时抽象层真正操作租户网络所对应的多个Rancher环境,在逐个环境内添加用于提供Rancher-NFS driver的system stack;假设租户内用户创建、删除、更新volume;同上,抽象层需要在逐个租户网络对应的Rancher环境内操作volume。之所以要这样抽象的原因在于客户存在跨网络部署应用栈的需求,因此,存储必须基于租户的粒度,实现跨Rancher环境共享。除此之外,对NFS server的管理方面,客户方面也有自己特殊的要求:物理存储是按照性能分等级的,同一个租户应该可以同时拥有金牌、银牌、铜牌的NFS server。基于业务的级别,可以为不同级别的微服务指定使用不同等级的NFS server。因此,与当前Rancher对存储的使用方式不同体现在:同一个租户可以关联多个NFS server,租户内用户在创建volume的时候,可以指定NFS server。# 4. 应用编排在应用编排方面,基于金融行业的特殊安全需求,客户要求应用堆栈能够基于微服务的安全等级来跨网络部署同一个应用堆栈,即应用堆栈中的多个微服务可能跨域多个不同网络。为了实现跨网络部署微服务,除了对基础资源(网络和存储)模型进行抽象之外,整个应用堆栈的部署流程也需要做相应的调整;另外,对应用堆栈的描述不再使用rancher的catalog,而是基于一套开源的Tosca模板标准;这样做的目的是方便与OpenStack以及其他平台贯通,方面以后使用同一个模板来描述整个IaaS和PaaS的编排情况;对应用堆栈以及内部微服务的更新,要求提供统一的接口,均通过下发新的Tosca模板更新应用栈的方式来实现。在解决应用堆栈的跨网络(Rancher环境)部署以及基于Tosca的编排方面,我们在抽象层中操作流程如下:接受用户输入的Tosca模板,然后交由translator模块做模板语法的check以及翻译,最终输出能够分别部署到各个Rancher环境的rancher-compose文件以及其他附加信息;orchestration模块需要对translator的返回信息进行资源层面的检查,比如是否该租户拥有应用堆栈部署所需的网络(Rancher环境)等;基于Translator的返回信息,按照各个网络之间微服务的依赖关系,决定各个rancher-compose的部署先后顺序,然后开始往网络中(Rancher环境中)部署没有存在依赖的rancher-compose;基于Rancher环境中应用堆栈的部署情况,按照依赖顺序,逐个部署后续的rancher-compose;在确保当前应用堆栈在所有Rancher环境中的rancher-compose都部署完成后,将该应用栈的弹性伸缩规则下发到弹性伸缩模块。
    图片7.png
    # 5. 弹性伸缩自动弹性伸缩是客户基于其业务场景而定制化的需求,大致如下:首先弹性伸缩的策略是基于时间段的,即按照一天为周期,可以设置在一天的某个时间段内采用哪一种弹性伸缩策略;弹性伸缩的策略包括三种:[list=1]
  • 基于微服务下所有容器的CPU利用率的平均值;
  • 基于微服务下所有容器的内存使用率的平均值;
  • 基于时间段,只要进入该时间区间,直接将容器数量伸或缩为某个最大或者最小值;在从该时间区间离去时,恢复容器数;
  • 支持对某个微服务的弹性伸缩策略使能和去使能;在对CPU和内存的监测时,又有如下规则:[list=1]
  • 可设置监控指标的上下阈值;
  • 可设定时长,持续超过指定时长,容器数量增加或减少;
  • 可设定触发伸缩行为时,单次容器数量增减值;
  • 可设定弹性伸缩可调节的容器数最大值和最小值;
  • 可配置弹性伸缩动作之后再触发的时间间隔;
  • 对弹性伸缩功能的实现根据策略的类型不同大致分为两种:[list=1]
  • 基于时间的策略,该策略主要是对当前时间与策略时间区间做匹配,一旦发现进入到基于时间的策略的时间区间就基于微服务的索引,找到并更改目标微服务的容器数量;
  • [list=1]
  • 基于内存和CPU利用率的策略本身并不监测CPU和内存信息,而是依赖于监控模块。在应用编排侧添加或更新了某个微服务的弹性伸缩策略后,弹性伸缩模块会将对这个微服务的弹性伸缩策略转换为监控告警策略下发到监控模块;同时,监听来自监控告警模块的告警信息。当收到告警时,弹性伸缩就从自己维护的映射表中找到是具体触发该告警的微服务,然后基于一系列规则来决定是否伸缩微服务的容器数量以及一次调整多少个。
  • 图片8.png
    由于弹性伸缩策略被设定于各个时间区间内,必然需要维护众多的定时器。一旦规则被设定后,就相当于为微服务定义好了一个周期为24小时,基于时间的状态机。当微服务数量较多时,如何保障既管理好这些状态机、定时器,又能不消耗掉太多的系统资源是软件设计的难点。另外,由于各个运行实例都运行着独立的状态机,如何做好弹性伸缩的高可用(冗余)又能够保障冗余部分的数据同步,也是值得深入思考的问题。# 6. 日志收集客户PaaS对日志的收集主要按照日志的来源可分为三种类型:[list=1]
  • 主机日志收集;
  • 容器日志收集;
  • 应用日志收集;
  • 图片9.png


    对于主机和容器的日志收集相对比较简单,主要通过对指定目录的文件内容进行收集,然后将收集到的日志信息进行格式化后统一发送到kafka集群;

    对于应用的日志收集相对较复杂,既要不对业务容器产生侵入又要保障能够收集到及时的日志。我们是通过在Tosca模板中定义某个微服务的log_files来指定应用日志在容器中的路径以及扩展名的。
    图片10.png

    当容器被调度到某台主机上时,该主机上的日志收集模块就会基于容器标签得知该容器内的应用日志目录,通过分析容器的详情可以获取到该容器内日志目录所映射到主机上的路径,从而将对容器内应用日志的收集,转换为对主机上特定文件内容的收集。具体的收集方式是采用logstash,通过程序自动修改logstach的配置文件来添加日志来源。

    将所有日志收集到kafka之后,客户再采用第三方的日志分析工具来对日志做特定的过滤、分析、搜索和多维度的展现。
    # 7. 监控告警
    客户的监控需求大致如下:

    租户宿主机集群的资源使用情况和运行状况,具体包括:

    * 租户集群的容器宿主机数量和总体资源使用情况
    * 租户集群中不同网络区域、等保区域等细分范围的容器宿主机数量和资源使用情况
    * 集群总体容器数量、容器在集群各容器宿主机节点的运行和分布情况
    * 每个容器宿主机节点的资源使用情况、运行容器列表

    应用(包含Stack和Service)监控数据,监控数据包括应用容器列表(容器IP、所在宿主机)、应用运行情况(健康情况、资源占用)等。

    每个容器所使用CPU、内存、网络、存储、标签、端口号等信息进行监控,提供Restful API。

    事件等信息写入事件审计数据库;同时支持配置事件告警规则,当激活事件告警功能后,根据事先设定的告警规则,从事件审计数据库中读取和过滤信息,转换成syslog格式,再将告警信息通过消息队列发送到PaaS平台外部。
    图片11.png

    该部分的实现主要使用bosun平台, 容器方面从cAdvisor中采集监控数据,主机方面是直接读取主机实时信息,对Rancher的审计日志,主要通过读取Rancher的数据库来实现。所有的监控数据汇集到bosun之后,通过对bosun做一层封装,一方面用于按照自定义的格式设置告警规则、另一方面实现bosun对接Active MQ将监控信息发送到消息队列,从而对接第三方监控大数据平台。
    # 8. 镜像仓库
    镜像仓库分为测试仓库和生成仓库,这两个仓库均实现了与PaaS平台的权限模型对接,实现单点登录以及统一的鉴权控制。

    另外值得提的是,客户对镜像从测试仓库到生产仓库的同步的流程划分为手动和自动,具体如下:

    * 镜像在被提交到测试仓库后,默认为“开发中”状态;
    * 开发完镜像后,受限用户通过外部协同管理平台来通知高级用户将镜像从测试仓库同步到生产仓库;
    * 高级用户登录测试仓库后,可以修改镜像同步规则;在正式同步之前,高级用户可以修改镜像的“待同步”状态为“开发中”;
    * 如果在生产仓库中已存在对应的Namespace,且高级用户勾选了自动同步,测试仓库会在同步周期超时时同步镜像并将“待同步”镜像状态改为“同步中”。如果同步成功,状态自动更新为“已同步”;否则为“待同步”;
    * 如果在生产仓库中已存在对应的Namespace,且高级用户勾选了手动同步,需要高级用户在测试仓库中手动点击“同步”按钮来同步镜像到生产仓库;如果同步成功,状态自动更新为“已同步”;否则为“待同步”。


    #Q&A
    Q:弹性这块,扩容好说,缩的话有个问题,就是还有用户请求在这个容器上,怎么办?

    A: 在该项目中我们并未对这种情况做特殊处理,但是在我们另外的产品中,已经考虑到了该问题。正确的方法应该是基于ingress设置一个销毁容器的宽限时间,即:在这段时间内,不允许新流量导入即将销毁的容器,这些容器在该宽限时间到期后,自动销毁。



    Q:感谢分享,对弹性伸缩部分请教一下:您分享的弹性伸缩的场景业务周期性很明显,所以基于时间区间触发采取不同的伸缩操作,如果业务周期性不明显,伸缩机制能处理吗?如何处理?

    A:在当前项目中,客户明确要求按照1天为周期。在我们自己的PaaS产品线中,弹性伸缩可以调整周期(比如:星期、月份等),另外,还可以不按照时间周期,直接基于CPU、内存或者某一个可监控项。你可以理解为只要能够被监控的监控项,都可以作为弹性伸缩的依据。



    Q:我目前关注的是日志这块,怎么才能把日志集中在一起,能不能说的具体点?

    A:我们是将日志收集后,统一发送到kafka集群,你可以理解为拷贝一份集中存储到kafka集群。这里的集中不是什么难点,难点在于对日志的收集,涉及三个层面:主机、容器、应用。我们的方式是在各台主机上部署容器化后的logstash,然后通过程序修改其配置模板,从而收集不同目录的日志。而这些目录就分别对应着主机日志、容器日志映射到主机的目录、以及应用日志映射到主机的目录。



    Q:根据日志标签获得应用日志目录,请问容器标签具体是什么格式的,采集日志信息中包含节点信息,容器信息,应用信息等跟平台、应用相关的元数据字段吗?

    A:这里的日志标签是可以自定义的,相当于主机上的daemon程序会监听该主机上容器的创建、销毁等event,一旦发现容器创建,就去check其标签,是否有自定义的“日志目录信息”,“日志文件扩展名信息”。这些日志目录都有对应的volume挂载到宿主机上,因此通过分析容器的inspect信息,就能够找到日志目录映射到宿主机的目录。而你提到的节点信息,这些是每个宿主机上的日志收集的服务容器在启动的时候就定义好的,所有由它收集并发送出去的日志,都会有该宿主机的标签。



    Q:关于日志收集的时间取值问题,是日志收集点的本地时间还是系统时间,具体如何保持一致?NTP?

    A:是日志收集点的本地时间,具体通过NTP,但是要注意,需要保障容器时间与宿主机时间(时区)要保持一致。



    Q:弹性伸缩另一个问题,如果不是周期性弹性伸缩是否考虑避免短期脉冲现象引起的不必要的弹性伸缩操作?

    A:所以在弹性伸缩的规则里面有一个参数为:“retrigger time” 也可以把它理解为一个安全的时间片,再一次伸缩动作之后,必须要等待这个时间片结束之后才会再次触发弹性伸缩行为。否则不予响应。



    以上内容根据2017年04月27日晚微信群分享内容整理。分享人陈乐吉,睿云智合(Wice2C)架构师,多年软件及通讯行业研发经验,曾先后在Nokia Siemens Networks、中电科华云从事云计算、SDN以及网络设备的研发工作。现就职于睿云智合成都研发中心,主要从事Wise2C基于容器的PaaS平台产品、以及客户定制化PaaS平台研发。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

    DockOne技术分享(三十八):容器服务如何在企业客户落地?Rancher解决之道分享。

    hongxi 发表了文章 • 1 个评论 • 7160 次浏览 • 2015-12-15 23:22 • 来自相关话题

    【编者的话】以Docker为代表的容器技术风风火火,一些先锋型的Startup和互联网公司已经尝到了甜头,大量的金融、保险、电信等企业客户也在摩拳擦掌、跃跃欲试。然而,对这些企业的CIO来说,首先要考虑的问题就是“容器技术如何在我的企业平稳落地”。本次交流与大 ...查看全部
    【编者的话】以Docker为代表的容器技术风风火火,一些先锋型的Startup和互联网公司已经尝到了甜头,大量的金融、保险、电信等企业客户也在摩拳擦掌、跃跃欲试。然而,对这些企业的CIO来说,首先要考虑的问题就是“容器技术如何在我的企业平稳落地”。本次交流与大家分享Rancher的解决之道,内容将包括Rancher这一开源容器管理平台的诸多“企业级”功能特性的介绍以及通过Rancher构建的企业私有容器服务的典型应用场景。

    @Container容器技术大会将于2016年1月24日在北京举行,来自CoreOS、红帽、SAE、七牛、爱奇艺、微博、腾讯、去哪儿网、美团云、京东、蘑菇街、惠普、暴走漫画、光音网络等知名公司的技术负责人将分享他们的容器应用案例。

    Docker的优势和趋势我想不必再赘述,那么对于非互联网公司的传统企业客户,以及我们大量的围绕企业客户做集成、交付解决方案的服务提供商,需要考虑的一个问题就是怎么样把容器技术以高质量、低成本、易维护的方式落地到企业的生产环境中来。换句话说,如果把容器技术比做KVM和Xen,我们需要一个容器界的OpenStack或是CloudStack。

    Rancher就是定位在提供“企业私有容器服务”这一核心业务需求上,并提出构建 "企业私有、混合容器云"、"像AppStore一样的企业应用商店实现一键式应用部署"、”CI/CD 部署流水线优化践行DevOps“以及”轻量级PaaS平台“等多个被企业客户所关注的一揽子解决方案。

    Rancher公司是一家位于硅谷的美国公司,创建人梁胜博士和他的团队一直是专注于计算技术在企业落地工作的,梁博士创建的CloudStack 项目是很多大的公有、私有IaaS云的支撑平台,他在早期时还是SUN公司JVM和JNI的开发带头人,所以“云计算”、“企业客户”是Rancher公司基因当中的两大关注点。

    纯粹的Docker和可以落地到企业生产环境的容器平台还是有很大距离的,需要做的工作至少有以下这些方面:
    00.png

    举几个例子, Rancher 可以统一管理企业内部多个数据中心的虚拟机、物理机容器环境,以及公有云(阿里、AWS等)内的容器主机,允许我们通过标签把业务灵活的分配到不同属性的"云"上。
    01.png

    以下调度策略为:把容器运行在阿里云上,并且容器尽量分散在多台阿里云主机,以提高可用性。
    02.png

    为了实现公有云和私有云间以及同一片云的主机间的容器通讯,Rancher基于SDN技术创建了 overlay容器网络:
    03.png

    当不同云和不同主机上的容器可以通过容器网络通讯后,再配合Rancher实现的负载均衡、服务发现、健康检查机制就可以帮助企业实现快速业务搭建和扩展,手动或是自动的实现容器甚至是容器主机的跨云动态扩容,这一点对“双11”这样的场景特别有用。
    04.png

    企业应用商店和一键部署是另外一个非常强大的功能,这引申出Rancher 对容器云未来发展方向的一个预见:单纯提供容器编排能力是不够的,提供容器应用的配置管理更能让“以应用为中心”这一容器技术特点发挥得淋漓尽致。因此我们提供了一个开放式的框架,在兼容docker-compose.yml 的基础上把与应用配置相关的信息记录在rancher-compose.yml中,并且允许用户以灵活的方式实现对任何应用的配置管理 : 你只要提供docker-compose.yml和rancher-compose.yml ,Rancher会自动在应用商店中探测到你上架的应用并支持管理你定义的配置项。

    上架应用示例:
    05.png

    应用的配置管理:
    06.png

    基于上述技术,可以做的事情有很多,比如通过一个高可用的MySQL服务实现一个轻量及的PaaS平台:
    07.png

    实现对SysDig 监控云的对接等:
    08.png

    09.png

    Hadoop 动态扩容的支持等:http://www.iqiyi.com/w_19rt9qkn7d.html

    再次强调,上述能力并非是Hadoop 进产品里的,而是通过任何人都可以创建的配置文件完成的,比如:大家可以通过这种技术实现WebLogic应用部署或是Zabbix 监控方案等。

    CI/CD 优化部署流水线是Docker的拿手项目,Rancher通过上述一键部署能力提供快速构建的支持。

    上面说的主要还是容器管理平台Rancher,我们还有一款产品是RancherOS,它是一个只有20几M的操作系统,专门运行容器的,可以看到它的所有系统进程都是在容器里运行的,性能好,升级维护特别方便。更cool的是我们还支持把虚拟机(Windows or Linux)跑在容器里,这样对于还没有上IaaS云的企业来说,直接上容器云也是一个不错的选择。
    10.png

    Rancher 还有很多其它超Cool功能,比如用户和权限管理,多租户管理,界面上集成日志和shell访问,API调用器等,由于时间关系这里不多说了。有兴趣的网友请关注我们的Blog: http://rancher.com/blog/

    说得再多都不如大家自已上手亲自感受一下,一条命令安装好Rancher的容器管理平台:
    sudo docker run -d --restart=always -p 8080:8080 rancher/server

    #Q&A
    Q:rancher-compose 和 docker-compose 关系?

    A:rancher-compose是对docker-compose的扩展,docker-compose 目前的能力太有限。



    Q:Rancher自己有持续集成的工具?

    A:我们本身产品中不带CI,但会在CATALOG里提供这样的工具让客户一键部署,我想这个比直接提供CI集成更COOL



    Q:Rancher产品是付费还是开源的呀?

    A: 我们是开源的,但也会有对应的企业版,像CentOS 和RHEL一样。



    Q:Rancher的网络是如何实现的?

    A:简单来说,我们目前是IPSEC VPN+基于DNS的服务发现。



    Q:我接触Rancher有两个月了,感觉是目前Docker管理平台里比较出色的。stack、service管理逻辑很好。不过目前还是0.4*版,迭代应该比较频繁。现在上业务的话,后期升级会有什么影响么?

    A:升级非常容易,且向后兼容,在这一点上秉承CloudStack的设计原则。



    Q:私有网络与公有云之间的数据安全是怎么控制的?

    A:通过ReverseNAT 下采用IPSec Tunnel,也就是数据是加密的,但要开在服务器间开两个UDP端口。



    Q:请问Rancher 在多租户隔离方面做了那些事,采用哪些安全手段?

    A:容器的隔离是和虚拟机不太一样,目前我们用“环境”的概念做多租户隔离,每个“环境”有自己的容器主机和容器。



    Q:相比于Kubernetes、Mesos和 Swarm、Rancher的优势在哪里?

    A:我们和上述容器编排不是竞争关系(虽然目前编排是我们自己写的),我们会根据用户的需求提供Swarm、Kubernates甚至是Mesos的编排方式。 但容器编排不是全部企业容器服务内容。



    Q:请问Rancher是自己实现了一套容器管理工具吗,能介绍一下你们用到的技术栈吗?

    A:我们是完全自己实现的。借鉴了之前团队做的CloudStack的成功经验。



    Q:Rancher推荐运行在什么样的宿主机之上,Ubuntu or CentOS?

    A:都行,Rancher可以管理标准Docker 主机。



    Q: 我看新版本多了一个存储池storage pool这个是什么作用,可以添加集群存储来供容器使用么?

    A: 这是很牛的一个与存储有关的功能,请大家看视频介绍:
    http://rancher.com/how-rancher-storage-services-unleash-the-power-of-software-defined-storage/。



    Q:请问catalog离线可以使用吗?

    A:很多企业都是没有互联网访问的,我们支持从本地镜像库Registry中拉images。



    Q:请问你们跟Docker公司是如何合作的?是什么一种关系?他们会推广你们的产品吗?

    A:都是硅谷公司,有深入的技术合作,很多Docker 组件如libcompose都是我们贡献的。



    ===========================
    以上内容根据2015年12月15日晚微信群分享内容整理。分享人:马洪喜(Linkedin:Hongxi Ma),专注于企业客户的虚拟化、云计算解决方案。目前担任Rancher公司架构师,负责Rancher中国业务开展中技术方面的工作。曾供职于Citrix公司咨询服务部,Oracle公司Linux和OracleVM研发团队。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesx,进群参与,您有想听的话题可以给我们留言。

    DockOne技术分享(三十四):搭建企业私有Docker Registry实战分享

    nevermosby 发表了文章 • 1 个评论 • 9461 次浏览 • 2015-11-25 15:49 • 来自相关话题

    【编者的话】对于企业内部搭建Docker Registry来说,部署和运维尤为重要。今天为大家简单分享下惠普企业R&D团队在这两方面的项目实战和应用。 @Container容器技术大会将于2016年1月24日在北京举行,来自爱奇艺、微 ...查看全部
    【编者的话】对于企业内部搭建Docker Registry来说,部署和运维尤为重要。今天为大家简单分享下惠普企业R&D团队在这两方面的项目实战和应用。

    @Container容器技术大会将于2016年1月24日在北京举行,来自爱奇艺、微博、腾讯、去哪儿网、美团云、京东、蘑菇街、惠普、暴走漫画等知名公司的技术负责人将分享他们的容器应用案例。
    实战聊天运维ChatOps
    # 什么是ChatOps
    ChatOps这个概念最初是由Github团队提出,简单来说,是基于对话驱动的开发方式。实际做法是:把你的工具带到您的沟通过程中,并使用一个聊天机器人编写定制化的脚本,使团队可以自动执行相应任务和协同工作,使运维工作更透明更高效。

    因此,实施ChatOps需要两个重要组成部分:聊天室和机器人。聊天室也就是我们常说的团队协作平台,比较知名的有:

    * Flowdock,知名团队协作平台,目前我们在使用它。
    * Slack,国外著名的团队协作平台,界面美观。
    * HipChat,国外著名的团队协作平台,界面简洁。
    * Zulip,Dropbox旗下的group chat平台,已开源。
    * Teambition,国内知名的团队协作工具,具有文档管理功能。

    这里是一篇比较Slack、Flowdock和HipChat的文章:
    http://www.slant.co/topics/1359/compare/~slack_vs_hipchat_vs_flowdock

    机器人选取了由Github团队开发的,当下最广泛使用Hubot。它是基于Node.js+CoffeeScript编写的,支持众多协作平台,如果没有你在用的,自己写adapter也很简单。除此之外,还有一些机器人:

    * lita,Ruby写的robot。
    * Errbot,Python写的robot。

    团队中的任何一个人,只要在Flowdock这样的协作平台上,像聊天一样,输入相应指令,比如`hubot show registry status`,收到这条指令的Hubot就会根据后台定制的脚本,自动把相应信息通过一条聊天信息返回给你。
    # 为什么要使用ChatOps
    ChatOps的实施使运维工作更加透明,更加简洁。这样的好处很多:

    * 把过去团队成员在各自工具中输入命令的这个黑匣子过程前端化、透明化了。团队每个成员都能随时了解其他成员的一举一动,打造真正的无死角透明团队。
    * 非常有利于新人的培养。显然,能够直观看到团队的微观运作,对于刚入职的新手来说,比任何培训的效果都更好。

    # 目前是如何利用ChatOps
    我们公司目前内部署了私有Docker Registry,我们希望监控它的运行和使用情况,并且能够快速地对一些可预知的问题进行处理。通过Flowdock+Hubot(Hubot运行在Docker容器里)就能实现这点:

    * 通过Hubot监控Registry是否正常运行。主要使用了Sensu来做Registry的health check。一旦发现Registry没有正常运行,hubot就会发送一条信息到flowdock里,使用@team来通知团队。然后团队的成员可以使用hubot指令`hubot fetch registry error cause`,让hubot帮我们调查并返回出错的原因。根据出错原因,再使用hubot指令进行应急处理。
    * 通过Hubot定时发Registry运行情况到Flowdock Inbox里。通过Sensu作为服务监控,收集Registry本身一些运行数据,包括CPU,内存等,发送到Graphite,生成时序统计图,发布到flowdock上。
    * 通过Hubot实时获取Registry的使用情况。首先Registry进行了notification配置,Registry使用元信息会被发送到定制的收集服务(Notification analysis service)中去。通过分析这些使用元信息,获取不同Registry镜像的pull/push数量,由Notification analysis service提供相应的聚合搜索API。调用这些API,可以获取每小时、每天的Registry使用情况(json),将这些信息发送给相应的GraphOps平台,就能生成相应的图像,发布到flowdock上。我们目前比较常用的指令,就是`hubot graph me registry usage since 24 hours`,hubot立刻会返回最近24小时内Registry的使用情况,包括pull/push的数量等。

    # 对于ChatOps未来计划

    * 目前hubot对于我们的Registry的运维还比较基础,将来我们希望通过增强hubot的运维能力(添加自动化脚本),来提高Registry的负载能力。例如通过hubot监测到Registry运行负载剧增,然后使用hubot实施auto scaling来保证Registry运行稳定。
    * hubot可以作为连接和协同众多独立的微服务的一种桥梁,扩展的便利性尤为重要,而目前手动编写自定义的脚本不是特别方便。我们计划在企业内开发一套图形化扩展hubot的平台,集成企业内常用的各种服务,包括代码管理服务(SVN、Git)、通知服务(邮件、Flowdock)和部署服务(企业私有云)。对于特有应用的服务,可以提供自定义脚本扩展。

    使用Rancher实现Docker容器集群环境的部署和管理
    # 为什么使用Rancher
    我们需要一个平台来管理生产环境中的容器,Rancher是一个开源项目,使用起来非常简单,容易上手,一方面Rancher提供UI,可视化创建开关容器,另一方面,当时我们对docker-compose已有一定的了解,Rancher是支持标准化docker-compose.yml的。除此以外,Rancher实现了跨主机的overlay network。基于以上考虑,我们采用Rancher,基本上满足我们对于容器部署管理的需求。
    # 准备环境

    * 安装Rancher的Server,其名为rancher/server的docker image,主要用于提供用户界面、追踪集群中容器状态、meta data和容器的调度、处理API请求等。
    * 给Rancher添加host,即在host上运行rancher/agent 这个docker image。Rancher的environment对应一个overlay network,把多个主机加入到一个environment中,Rancher根据资源和端口,自主调配容器在哪个主机上运行,每个容器将获得一个IP(10.42.0.0/16),容器之间是网络联通的。

    # Rancher进行部署

    * Rancher根据docker-compose.yml来部署容器,一个docker-compose.yml定义的container cluster,在Rancher里,被称为Stack。一个environment可以起多个Stack。对于docker compose中的link, Rancher有自己的Distributed DNS Service discovery的功能,根据link,生成service name对应IP的DNS record。Rancher也支持Docker volume, 并且提供其快照和备份的功能。我们通常还配有一个私有Registry,这样部署的时候Rancher可以从私有Registry去pull image.
    * 与docker-compse.yml一起工作的有rancher-compose.yml,在rancher-compose.yml中定义service scale,即一个service的container数量。例如
    db:
    scale: 2


    * Rancher内置的load balancer,我们用来做流量的路由。例如,在docker-compose.yml中,有如下定义
    lb:
    image: rancher/load-balancer-service
    labels:
    io.rancher.loadbalancer.target.service1: example.com:443/service1=3000
    io.rancher.loadbalancer.target.service2: example.com:80/service2=5000
    service1:
    ...
    service2:
    ...

    意思是我们定义了一个lb的service,是rancher/load-balancer-service的image,labels中的内容则配置lb的路由规则,即访问example.com:443/service1,流量会被分发到service1,而example.com:80/service2,流量被分发到service2。我们常常在一个envrionment中,指定一台host,专门用于运行lb。然后,云服务上配置DNS,使域名绑定到这个主机的IP。这样无论如何部署,总可以很顺利地通过域名来访问这些服务。

    * 容器编排scheduling的功能。Rancher允许用户给每个host定义label,比如我们常常给专门来运行load balance的主机定义一个label是for=lb,如果要lb这个service一定在此主机上运行,那么可以在docker-compose.yml中这样定义:
    lb:
    labels:
    io.rancher.scheduler.affinity:host_label: for=lb


    Rancher有更多高级的scheduling规则编写的功能,包括否定,软指定等。
    `io.rancher.scheduler.affinity:host_label_ne: for=lb` 指service一定不能在for=lb的host上运行。
    `io.rancher.scheduler.affinity:host_label_soft: for=lb` 指service在条件允许的情况下尽量在for=lb的host上运行。

    * 可以从用户界面上部署容器,Rancher自动生成docker-compose.yml,并且提供Service之间相互link的拓扑图,如图
    RancherServiceLink.JPG


    * Rancher有rancher-compose命令行工具,方便容器部署自动化,与其他流程进行整合。

    # 生产环境使用Rancher

    * 发布新的image,可以用Rancher upgrade的功能,实现无缝更新。本质上Rancher启动新的service,然后切换link到新的service。如果需要回滚,则可以很方便的切换回之前的service。
    * Rancher对于主机和容器进行实时监控,通过用户界面可以查看cpu和memory的使用情况。
    * Service Health Check,是基于HAProxy开发的对于service状态的监控。

    # 目前发现的缺点

    * 缺乏自主修复的功能。如果有些host无法和Rancher Server连接,Rancher无法重新调配container。

    团队

    * 惠普企业RnD部门,从事DevOps及Docker的研究和相关工具的研发,开源社区贡献者。
    * 成员:李文权、林箐、王春阳。

    Q&A
    Q:目前有没有尝到监控Register运行和使用情况的好处,或者在维护私有Register有没有遇到过什么问题?

    A:能够实时监控Registry,就能观察用户的行为,当我们在负载量很大的时候,能够有效保持Registry稳定运行。维护私有的Registry的问题,就是要跟进官方的更新,看看是否也需要同步。



    Q:Rancher实际上是基于Docker的开源PaaS,基于容器技术的开源PaaS很多,比如Deis、Flynn等,但是Rancher跟这些项目不同的地方是,它尽可能的和Docker生态圈工具兼容。请问当初为什么会选择Rancher,在你看来,Rancher最吸引你的地方是什么?

    A:Rancher的UI比较方便于上手和使用。而且Rancher的概念也更接近Docker compose,目前官方的文档也比较齐全。



    Q:Flowdock+Hubot这种方式下的监控是否必须用Sensu,是否支持采用zabbix作监控,Zabbix的远程脚本可以实现一些自动重启等等操作?

    A:Sensu不是必须的,你可以使用你熟悉的监控服务,比如Zabbix。



    Q:Flowdock+Hubot在一些安全性要求比较高的生产环境上是否可用,其发布的命令采用什么方式连接到容器\虚拟机或者主机上?要不要建立SSH免密码连接之类的操作?

    A:Hubot是拉取Flowdock的信息,所以Hubot可以部署在公司防火墙内。目前Hubot使用docker remote API来控制虚拟机上的容器。



    Q:请教一下,Rancher可以理解为Compose的增强版吗,特别是可视化部分?

    Rancher自己有一套rancher-compose,提供load balance和auto scaling,可以算是Compose的增强版。可视化部分,是Rancher的一个Feature。



    Q:Rancher的lb是用的HAProxy么?

    A:是的。



    Q:有没有做过横向比较,Kubernetes和Swarm+Compose,Rancher+Compose,在这几种选择间做过比较,或者说为什么最终选择了Rancher?

    A:最初是选择Swarm+Compose,但是由于那个时候的Swarm不太稳定,有bug,集群管理工作不起来。Rancher部署方便,操作简单,所以就用了它。



    Q:Rancher的网络具体是怎么做的呢?

    A:据目前了解,是overlay模式。各主机之间采用IPsec Tunneling来实现通信,使用udp的500和4500端口。启动时在各个主机部署容器之前启动一个Network Agent管理容器网络。具体可以参看文档:docs.rancher.com



    Q:rancher master如何实现的高可用?之前看了文档搭建之后,cpu等监控图无法显示了

    A:通过rancher-compose提供load balance和auto scaling实现高可用。监控图无法显示也是我们遇到的问题,目前正在解决。



    Q:从描述看Rancher的网络类似于weave吧,给每个容器分配固定IP,对集群规模比较大的或者IP地址段受限的似乎不太够用?

    A:从我们目前的经验来看,的确有这样的限制,如果有大规模集群的需求下,需要重新评估Rancher来管理和部署。



    Q: Hubot是不是也支持非容器方式的部署,比如部署在虚拟机上?

    A:可以,可以参照https://hubot.github.com。



    Q:Hubot使用docker remote API是否采用了安全策略,另外Docker Registry采用了何种安全策略?

    A:Remote API使用了TLS验证。目前我们的private registry使用了LDAP+token作为安全认证。



    Q:在部署方面很重要的是动态伸缩和灰度发布,在这两方面你们是怎么考虑的?Rancher在这两个方面有支持吗?

    A:通过rancher-compose提供load balance和auto scaling实现动态伸缩。其他方面,还没有考虑过。



    Q:Rancher的管理数据是不是都放在了MySQL里面?MySQL需要搭建在物理机上吗?

    A:MySQL是rancher server自己提供的,无需手工部署。



    Q:Rancher能支持云存储吗?

    A:最新版本的Rancher对Docker volume插件有了支持,可以通过它来实现Container的数据存储管理。



    Q:请问你们实践或了解到的基于Rancher的集群规模有多大?

    A:目前我们的使用规模比较小,还没有这方面的准确数据。



    Q:从介绍看整个系统是搭建在OpenStack上的,采用Swift作为存储,那Docker的部署是不是采用的nova-docker呢?容器是部署在物理机上还是虚机上的,如果是虚拟机采用的是哪种hypervisor,性能方面如何,有没有做过相关的压测?

    A:Docker是部署在KVM的虚拟机上,使用的企业私有云平台,目前没有做过性能测试。



    Q:Rancher 实际应用中有哪些要特别注意的问题,麻烦分享下?

    A:Rancher版本更新快,较低的版本会有很多bug。



    Q:有考虑过升级问题么?比如Registry从v1升级到v2?或者docker 升级到1.9?

    A:目前我们使用的就是v2,使用rancher upgrade来升级。 升级Docker的成本较大,目前还没有相关最佳实践。



    Q: Rancher中文资料多嘛,有推荐嘛?

    A:目前我们看的都是官方英文文档,这样能看到最新的信息,中文文档没有关注。



    ===========================================================
    以上内容根据2015年11月24日晚微信群分享内容整理。分享人: 李文权,去年开始参与关于OpenStack的项目forj,这是一个持续集成和分发的开源平台。负责搭建公司内部使用的Docker Registry,跟Docker社区成员一起贡献了OpenStack Swift作为Registry V2的代码。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesx,进群参与,您有想听的话题可以给我们留言。

    rancher: Failed to obtain metrics. The metrics service may not be available.

    回复

    tangjiaxing669 发起了问题 • 1 人关注 • 0 个回复 • 762 次浏览 • 2019-04-13 12:13 • 来自相关话题

    rancher cattle 默认网络环境和集群外应用Dubbo互通问题

    回复

    八月888 回复了问题 • 2 人关注 • 2 个回复 • 2949 次浏览 • 2017-12-11 17:30 • 来自相关话题

    有人使用过rancher 1.6.11部署的k8s,连接ceph吗?

    回复

    overlord 发起了问题 • 1 人关注 • 0 个回复 • 3216 次浏览 • 2017-11-29 10:05 • 来自相关话题

    在Kubernetes中用Helm安装Prometheus为什么PVC一直pending?

    回复

    online 发起了问题 • 1 人关注 • 0 个回复 • 6561 次浏览 • 2017-11-13 11:05 • 来自相关话题

    rancher容器的健康信息不能展示

    回复

    请叫我小路飞 发起了问题 • 1 人关注 • 0 个回复 • 2282 次浏览 • 2017-06-12 15:34 • 来自相关话题

    rancher健康检查不能正常启动

    回复

    niusmallnan 回复了问题 • 2 人关注 • 1 个回复 • 2746 次浏览 • 2017-05-10 15:48 • 来自相关话题

    国内容器领域活跃的技术/服务输出公司信息集合?

    回复

    wisen 回复了问题 • 3 人关注 • 1 个回复 • 2313 次浏览 • 2017-02-18 14:17 • 来自相关话题

    我们应该如何基于容器来进行软件的持续交付(二)?

    回复

    wise2c 发起了问题 • 1 人关注 • 0 个回复 • 2787 次浏览 • 2016-12-26 10:07 • 来自相关话题

    Rancher v1.2.0部署出错

    回复

    kine 发起了问题 • 1 人关注 • 0 个回复 • 2329 次浏览 • 2016-12-15 14:22 • 来自相关话题

    Rancher 支持 ipc=host 参数吗

    回复

    demohi 发起了问题 • 1 人关注 • 0 个回复 • 2763 次浏览 • 2016-04-06 23:38 • 来自相关话题

    RancherOS v1.5.0发布

    Rancher 发表了文章 • 1 个评论 • 633 次浏览 • 2019-01-09 10:31 • 来自相关话题

    一言不合就发新版本。 年关将至,寒意习习,落叶萧萧下,阳光日日稀。RancherOS团队历时两个来月的开发,正式发布RancherOS v1.5.0版本。 在此期间同为Container Linux阵营的C ...查看全部
    一言不合就发新版本。



    年关将至,寒意习习,落叶萧萧下,阳光日日稀。RancherOS团队历时两个来月的开发,正式发布RancherOS v1.5.0版本。 在此期间同为Container Linux阵营的CoreOS已经从红帽再入IBM,潮流之变,业界态势,让我们无不更加努力去争得一席之地。 无论是商业用户的积累,还是业界变化带来的社区用户增长,都在催促我们不断革新,应该说1.5.0版本是用户的需求推着我们走出来的。




    ------------



    重大特性更新



    本版本的新特征众多,无法一次性全部说明,以下只表述一些用户关注度比较高的特性。个别特性详细说明,我们会不断推出文章一一展开。


    启动性能提升



    一直以来RancherOS的initrd一直采用xz格式压缩,随着RancherOS的体积不断增大,xz压缩越来越影响系统启动速度。虽然xz格式能够带来比较小的initrd和ISO, 但是我们也需要兼顾启动速度。v1.5.0版本的initrd已经采用了gzip格式,文件体积有所增大,但是启动速度有了质的飞跃。 同时我们也优化了system-docker的镜像加载和cloud-init的启动,对启动速度进行了深度优化。



    LUKS磁盘加密支持



    支持LUKS,允许用户对跟磁盘分区进行加密,在一些特殊场景下增强了RancherOS的安全性。运行效果参考下图:



    WiFi和4G支持



    Intel正在micro PC领域不断发力,RancherOS被纳入其生态体系,我们支持了WiFi和4G网络,用户可以通过简单的cloud-config配置就可以开启, 带来了十分简洁的用户体验,这部分我们会在后续其他文章中详细介绍。



    Hyper-V支持



    很多社区用户一直希望能在Hyper-V使用RancherOS,先前我们一直提供给用户一些custom build的方式来实现它,现在我们正式支持了它,并会持续维护。 无论是docker-machine方式还是boot from ISO方式均可以支持。



    下一个版本我们也会带来RancherOS的Azure Cloud支持。



    多docker engine支持



    这是一个很有趣的特性,目前RancherOS中默认拥有一个user docker。在v1.5.0中,用户可以用过ROS CLI来创建多个user docker engine, 并且每个docker拥有独立的ROOTFS和网络栈,并且可以在console很容易的切换使用任意一个docker。



    当然我们并不推荐您在生产中使用,我们的某个商业客户把这个特性应用在其CI环境中,极大的提升了资源的利用率,减少了物理机器数量的开销。



    改善VMware的支持


    RancherOS的广大用户中Vmware是占有很大的用户群,之前我们的版本中只针对docker-machine方式做了一些改善,但是很多用户还希望使用boot from ISO方式和VMDK方式, 我们相关的镜像也做了支持,用户可以直接下载使用它:



    • [VMDK] https://releases.rancher.com/os/v1.5.0/vmware/rancheros.vmdk
    • [Docker Machine] https://releases.rancher.com/os/v1.5.0/rancheros-vmware.iso
    • [Boot From ISO] https://releases.rancher.com/os/v1.5.0/vmware/rancheros.iso



    ARM的支持



    由于Rancher和ARM已经开始了战略合作,我们会在一起做很多有趣的事。RancherOS的ARM支持也是其中的一部分,原先我们只是对RPi做了支持, 现在我们提供ARM版本的initrd和vmlinuz,用户可以用它们使用iPXE方式启动:



    https://releases.rancher.com/os/v1.5.0/arm64/initrd

    https://releases.rancher.com/os/v1.5.0/arm64/vmlinuz



    我们依然只会对ARM64支持,且v1.5.0的ARM支持只是实验性质的,并不推荐应用在生产中。 我们会和ARM进行合作进行更广泛的测试,后续的版本将会是更稳定的。



    更加友好的自定义



    社区中越来越多的发烧友并不局限使用我们的正式发布版本,他们会根据自己的需求修改RancherOS,构建自己的RancherOS。 我们提供了一些友好的编译选项,用户可以自定义自己的RancherOS。



    更改默认docker engine



    RancherOS的每个版本都会有自己设定的默认docker engine,而在用户的场景下,可能需要一个内部认可的docker engine,且希望它是RancherOS默认的版本。 那么用户可以在构建时候指定docker engine版本,来构建自己的RancherOS,以docker 17.03.2为例:

    `USER_DOCKER_VERSION=17.03.2 make release`



    更改默认console



    RancherOS支持很多console,比如ubuntu、alpine、centos等,由于我们的default console基于busybox,有些用户并不喜欢它,且不希望每次都去切换console。 那么用户可以使用这种方式构建一个默认console是自己喜欢的版本,以alpine console为例:

    `$ OS_CONSOLE=alpine make release`



    其 他



    AWS相关镜像已经上传到各个region中,可以直接搜索查找并使用,包括AWS中国区。其他主要镜像列表参考:

    https://github.com/rancher/os/blob/v1.5.x/README.md#release



    更多新特性和Bug Fix请参考v1.5.0的Release Notes



    文档说明:

    https://rancher.com/docs/os/v1.x/en/



    最后,RancherOS还是一个小众的开源项目,我们专注Docker在Linux上的精简体验,如果喜欢RancherOS,请在Github上给我们一个star,鼓励我们继续前行。



    Rancher Github:

    https://github.com/rancher/os/releases/tag/v1.5.0

    中国公有云三巨头,同时支持Rancher Kubernetes平台

    Rancher 发表了文章 • 1 个评论 • 963 次浏览 • 2018-11-21 22:53 • 来自相关话题

    华为云容器引擎(CCE)、阿里云K8S容器服务(ACK)和腾讯云K8S引擎(TKE),中国公有云三巨头正式全面支持Rancher Kubernetes平台。 ------------ Ranch ...查看全部
    华为云容器引擎(CCE)、阿里云K8S容器服务(ACK)和腾讯云K8S引擎(TKE),中国公有云三巨头正式全面支持Rancher Kubernetes平台。


    ------------

    Rancher正式宣布扩大对中国领先Kubernetes服务的支持,华为云容器引擎(CCE)、阿里云Kubernetes容器服务(ACK)和腾讯云Kubernetes引擎(TKE),中国公有云三巨头正式全面支持Rancher Kubernetes平台。



    想在生产中运行容器和Kubernetes,Rancher Kubernetes平台已是数万企业的第一选择。 Kubernetes在全球范围内的热度持续攀升,Rancher进一步扩大了对云提供商托管的Kubernetes服务的支持。 如今,Rancher自豪地成为了唯一一个与所有领先云提供商达成合作、支持其托管的Kubernetes集群的企业级开源Kubernetes管理平台。



    扩大对华为云、阿里云和腾讯云的支持



    Rancher是业界唯一100%开源的企业级Kubernetes管理平台,无论何时何地,Rancher均为企业用户提供“Kubernetes即服务(Kubernetes-as-a-Service)”的技术支持,实现对Kubernetes集群的集中部署及管理,不论这些Kubernetes集群是在何处、以何种方式部署的。



    在Rancher 2.0上线后,Rancher率先实现了对谷歌云容器服务(GKE)、亚马逊云容器服务(EKS)及微软云容器服务(AKS)的支持,打造一致的安全策略,为用户带来良好的使用体验。现在,Rancher扩大了对华为云容器引擎(CCE)、阿里云容器服务(ACK)和腾讯云容器服务(TKE)的全面支持,帮助中国的企业加快Kubernetes集群的落地。







    华为CCE是中国第一个云托管的Kubernetes服务,我们无比欢迎Rancher用户能通过华为CCE与Rancher平台的集成合作,享受华为云所提供的世界级的Kubernetes支持。
    ——华为Cloud BU PaaS产品部总经理 廖振钦









    作为中国最大的公共云服务提供商,也是全球三大IaaS提供商之一,阿里云致力于通过云原生方式和开放式容器技术,帮助企业加速数字化转型。我们很高兴通过阿里云Kubernetes服务(ACK)支持Rancher。ACK已在全球十六个地区推出,我们坚信ACK将推动企业通过Kubernetes完成向云迁移和多云管理。
    ——阿里云容器技术工程总监 易立







    腾讯Kubernetes引擎(TKE)诞生于开源Kubernetes系统,提供以容器为中心、高度可扩展和高性能的容器管理服务。Rancher与TKE之间的集成支持有着很大意义,Rancher用户现在可以最大程度充分享受TKE提供的丰富功能了。
    ——腾讯云PaaS产品经理 梁文杰





    四大更新亮点



    为华为云(CCE)、阿里云(ACK)和腾讯云(TKE)提供自服务Kubernetes集群的支持,用户可以通过Rancher UI和API创建并升级CCE、ACK和TKE集群。



    集成的云基础设施管理和集群扩展。企业用户可以从 Rancher UI 和 API 配置 CCE、 ACK 和 TKE 集群及集群中的节点数。



    跨本地集群和CCE、ACK或TKE集群的集中式用户身份验证。企业用户可以使用Active Directory和 LDAP 凭证登录到他们的 CCE、 ACK 和 TKE 集群。



    跨所有 Kubernetes 集群的统一访问控制策略。企业 IT 管理员可以配置跨 CCE、 ACK 和 TKE 集群的一致访问控制策略。



    Kubernetes Everywhere



    这次集成将会在2019年初发布的Rancher 2.2当中正式实现,现在对华为云、阿里云以及腾讯云的整合支持内容已可demo使用。



    这一次,随着Rancher对世界范围内几大主流领先的云托管Kubernetes服务的全面支持,Rancher一直以来“Kubernetes Everywhere”的愿景正在更进一步变为现实。对于企业用户而言,Rancher之旅始于企业开始意识到他们需要一个平台来管理混合云中的资源和开发。我们比以往任何时候都更有信心,Kubernetes将成为企业应用程序的基础平台,而Rancher将帮助企业将Kubernetes落地为现实。

    Rancher 2.1全面发布,优化Kubernetes集群运维

    Rancher 发表了文章 • 1 个评论 • 1880 次浏览 • 2018-10-18 22:19 • 来自相关话题

    Rancher 2.1已于近日全面发布! Rancher 2.1是自去年九月Rancher Labs全面拥抱Kubernetes、发布全新里程碑产品Rancher 2.0——开源的企业级Kubernetes ...查看全部
    Rancher 2.1已于近日全面发布!



    Rancher 2.1是自去年九月Rancher Labs全面拥抱Kubernetes、发布全新里程碑产品Rancher 2.0——开源的企业级Kubernetes管理平台之后,最为重大的版本更新。



    2017年9月Rancher Labs极具前瞻性地成为业界首批全面拥抱Kubernetes的容器管理平台提供商,全新里程碑产品Rancher 2.0是一个开源的企业级Kubernetes管理平台,为企业用户提供Kubernetes-as-a-Service (Kubernetes即服务)。



    Rancher 2.1建立在Rancher 2.0的成功基础之上,并引入了下一代自动集群操作和应用程序管理功能,并为用户提供了从Rancher的Cattle编排迁移到Rancher Kubernetes的迁移路径。Rancher 2.1提供了企业在其组织内轻松采用和管理Kubernetes所需的所有关键功能。



    Rancher一直是企业在生产中运行容器和Kubernetes的事实上的选择。Rancher 2.1中包含着很多重要的功能升级,将进一步帮助各类企业加快拥抱Kubernetes,缩短IT研发流程,降低基础架构成本,并提高应用程序可靠性。



    ——Rancher Labs联合创始人及CEO 梁胜





    优化Kubernetes集群运维



    Rancher 2.1大大加强了可扩展性,并让用户可以使用Rancher来定义和管理Kubernetes 集群。此外,Rancher 2.1允许用户快照并导出Rancher管理的Kubernetes集群的完整配置,并可在之后通过导入相同的配置文件来恢复Kubernetes集群。



    Rancher 2.1的其他主要功能包括:



    • 更多身份验证方式
    Rancher现在集成了PingID、Microsoft Active Directory联合服务器、OpenLDAP、Keycloak、FreeIPA和Azure Active Directory。
    • 驱散容器功能
    在对主机进行维护时,例如升级内核、硬件维护等,这个功能首先会禁止新的容器调度到这个节点,然后会对该节点上的容器有规则的进行驱散。完成主机维护后,可以恢复节点功能。
    • 项目配额管理
    集群管理员和项目管理员可以从项目层级设置配额。可以配置该项目的CPU、内存、存储、Pod数量等等的配额。同时,在每个项目里,管理员也可以对每个命名空间的配额进行控制。
    • 更强的应用程序管理功能
    Rancher 2.1增加了对helm chart的优化支持,并优化了ingress管理、日志采集和告警功能。
    • CICD功能增强
    Rancher 2.1大幅优化了CICD的用户体验,包含完全集成的CI / CD功能,可与Kubernetes一起使用,打通了代码提交、自动测试、自动构建镜像、自动部署镜像的全流程。
    • 支持GitLab
    Rancher 2.1增加了对Rancher CI / CD的GitLab支持,CICD可以支持公有GitLab的对接和私有GitLab代码库的对接。
    • 扩展的命令行界面(CLI)
    团队现在可以自动化他们与Rancher和Kubernetes的接口。
    • 高可用模式增强
    管理员可以配置高可用模式中启用多个Rancher Server实例。提供了Rancher服务横向扩容的能力,提高了Rancher Server的可用性。
    • 应用商店优化和增强

    Rancher 2.1引入了Tiller,更好的优化了应用商店,并且新增了例如Kubernetes Dashboard等应用的一键部署。且现在用户可以以编辑YAML的形式来设置应用参数。



    从Rancher 1.6迁移到Rancher 2.X



    Rancher 2.1同时还是供Rancher 1.6用户使用的升级版本。Rancher 2.1包含一个迁移路径,供用户从Rancher的Cattle编排迁移到Rancher Kubernetes。Rancher 2.1还提供了分析Rancher Compose文件的集成工具,并概述了用户能如何将应用程序直接迁移到Kubernetes。更多版本升级迁移相关的细节与建议请参考:

    https://rancher.com/docs/rancher/v2.x/en/v1.6-migration/



    Rancher 2.1用户体验计划



    大家说,开源才是技术的未来。Rancher也始终怀着这样的理念和勇气在做产品。每一个bug的修复,每一次产品的升级,都是Rancher想献给用户和开源社区的礼物,Rancher一路走来取得的巨大成绩也绝离不开用户和开源社区的支持。



    Rancher 2.1新近发布,Rancher Labs中国区团队特为中国用户准备了【千元大奖】,邀您参与【Rancher 2.1用户体验计划】!



    找bug,提issue



    Rancher团队珍视用户的每一个意见与反馈。新版本2.1发布后还将经历版本完善与优化的阶段。若您在Rancher 2.1的测试或使用中发现了任何bug,欢迎在Rancher GitHub上提交issue:

    https://github.com/rancher/rancher/issues



    issue提交完毕后,请在此表单上填写相应信息,Rancher中国区研发团队会第一时间优先解决您反馈的问题并联络您:

    https://www.wenjuan.com/s/N77JVr2/

    如何在Rancher 2.0上快速部署Datadog

    Rancher 发表了文章 • 1 个评论 • 1267 次浏览 • 2018-07-19 17:57 • 来自相关话题

    Datadog是一种流行的托管监控解决方案,用于聚合和分析分布式系统的指标和事件。从基础架构集成到协作仪表板,Datadog为用户提供了一个简洁的单一窗格视图,用户可以快速查看对其最重要的信息。结合使用Rancher和Datadog,用户可以查看到运行在Kub ...查看全部
    Datadog是一种流行的托管监控解决方案,用于聚合和分析分布式系统的指标和事件。从基础架构集成到协作仪表板,Datadog为用户提供了一个简洁的单一窗格视图,用户可以快速查看对其最重要的信息。结合使用Rancher和Datadog,用户可以查看到运行在Kubernetes集群上的应用程序的完整堆栈视图,无论这些Kubernetes集群运行于何处。为了使Datadog更易于与Rancher 2.0一起使用,Rancher的工程师修改了Datadog Helm chart,Rancher用户可以在Rancher的应用商店(Catalog)中快速简单地部署Datadog,且Datadog可在集群内的各Rancher项目(project)中运行。



    前期准备


    1、Datadog API Key:你可以使用已有的API key的秘钥,也可以让chart新生成一个秘钥。



    2、默认情况下,Rancher Kubernetes Engine(RKE)不允许对许多指标所依赖的kubelet API进行未经身份验证的访问。使用RKE安装集群时,我们需要为kubelet服务提供额外的参数。

    services:

    kubelet:

      extra_args:

        read-only-port: 10255j


    注意:你需要确保此端口已正确打开防火墙。



    3、你需要一个连接到Rancher安装的Kubernetes 1.8。



    设置和配置


    默认情况下,Rancher库中有Datadog Rancher Chart(https://github.com/rancher/charts/tree/master/charts/datadog/v1.0.0),在Helm stable中也有一个Datadog Chart,但我们建议您使用Rancher库中的Chart,因为这用起来更方便简洁。Rancher库会默认启动,如果你想禁用Rancher库,可以在Global-> Catalogs下修改此设置。


    DataDog-Helm-Chart.png




    通过添加questions.yaml文件,用户在Rancher UI中就可以使用chart配置选项了。要了解有关它们的更多信息,请参阅values.yaml文件(https://github.com/rancher/charts/blob/master/charts/datadog/v1.0.0/questions.yml),该文件包含其他信息和描述变量的链接。



    AgentConfiguration.png




    仪表盘

    如果您计划将多个集群数据发送到同一个Datadog端点,则在配置Helm chart时将集群名称添加为主机标记(例如kube-cluster-name:CLUSTERNAME)。这样一来,你就可以按范围将数据排序到特定集群,并按仪表板中的集群对数据进行分组。在下面的仪表板示例中,我们按照集群'dash-1'和dash-2'的一些默认小部件按簇分组节点数据。



    datadogDashboard.png




    结论
    使用Helm部署应用程序是一种经过了测试的、标准化的部署方法。使用Rancher Catalog UI,Helm chart将更易于使用和配置。将Datadog chart添加到Rancher库中,用户就可以利用这一工作流轻松享受顶级的企业级Kubernetes监控和警报解决方案。

    使用ExternalDNS自动化DNS配置

    Rancher 发表了文章 • 1 个评论 • 1420 次浏览 • 2018-07-18 12:29 • 来自相关话题

    Kubernetes社区的生态繁荣和该领域技术的快速茁壮发展,已经是众所周知。Kubernetes领域有太多强大的、创新的技术产品,而最近引起我注意的项目是ExternalDNS。这是在近期的POC期间客户主动咨询起来的,我承诺客户会尝试一下ExternalD ...查看全部
    Kubernetes社区的生态繁荣和该领域技术的快速茁壮发展,已经是众所周知。Kubernetes领域有太多强大的、创新的技术产品,而最近引起我注意的项目是ExternalDNS。这是在近期的POC期间客户主动咨询起来的,我承诺客户会尝试一下ExternalDNS子项目,且使用后发现它真的令人印象深刻。



    ExternalDNS子项目


    ExternalDNS子项目(孵化器流程已被弃用)是由sig-network赞助并由Tim Hockin倡导的,旨在自动配置云DNS提供商。这很重要,因为它进一步支持基础架构自动化,用户可以在应用程序部署的同时直接完成DNS配置。


    传统企业部署模型,通常是由多个孤立业务单元,来处理部署过程的不同部分。但带有ExternalDNS的Kubernetes不同于传统企业部署模型,它可以自动完成此过程的这一部分工作。有时候有可能会出现这种不好的情况:一部分软件已准备就绪,但它却必须等待另一个业务部门手动配置DNS。而有了ExternalDNS,这一潜在问题就被解决了。


    通过ExternalDNS,组织团队可实现自动化和共同责任协作,而这将避免手动配置的错误,并使各方都能够更有效地将其产品推向市场。


    AKS上的ExternalDNS配置和部署


    我曾作为软件开发人员在.NET领域有过多年的工作经验。微软开发人员社区在我心中一直有一个特殊的位置,过去几年以来我参加过不少费城地区的Azure用户meetup,分享如何通过ACS(Azure Container Service)和AKS(Azure Kubernetes Service)使用Kubernetes on Azure。恰巧的是,向我咨询ExternalDNS的用户也正是在选择了Azure作为其IaaS产品。


    下文是我准备的在AKS集群上启动ExternalDNS的分步说明和帮助程序代码。即使您使用的是其他公有云上的托管的Kubernetes,本教程依然适用。


    # 先决条件 #


    登录Azure AD,必要情况下请设置订阅。


    几点注意事项


    1、请注意,本文档中的外部模板文件使用了许多可选设置。

    2、它也在debug级别日志中,因此您也可以自行进行troubleshooting。


    # 在Azure AKS或Azure IaaS上设置ExternalDNS #


    1、创建Azure DNS记录

    RESOURCE_GROUP=MC_rancher-group_c-6vkts_eastus
    DNS_ZONE=vanbrackel.net
    az network dns zone create -g $RESOURCE_GROUP -n $DNS_ZONE


    2、根据您的注册商的需要委派DNS


    3、创建服务主体以代表Kubernetes行事。

    SUBSCRIPTION_ID="$(az account show | jq '.id')" && SUBSCRIPTION_ID=${SUBSCRIPTION_ID//\"}
    TENANT_ID=$(az account show | jq '.tenantId') && TENANT_ID=${TENANT_ID//\"}
    SCOPE=$(az group show --name $RESOURCE_GROUP | jq '.id') && SCOPE=${SCOPE//\"}
    PRINCIPAL=$(az ad sp create-for-rbac --role="Contributor" --scopes=$SCOPE -n ExternalDnsServicePrincipal)
    CLIENT_ID=$(echo $PRINCIPAL | jq '.appId') && CLIENT_ID=${CLIENT_ID//\"}
    CLIENT_SECRET=$(echo $PRINCIPAL | jq '.password') && CLIENT_SECRET=${CLIENT_SECRET//\"


    4、创建你的云提供商配置。

    echo "{ \"tenantId\": \"$TENANT_ID\", \"subscriptionId\": \"$SUBSCRIPTION_ID\", \"aadClientId\": \"$CLIENT_ID\", \"aadClientSecret\": \"$CLIENT_SECRET\", \"resourceGroup\": \"$RESOURCE_GROUP\"}" >> azure.json


    5、使用云提供商配置来创建一个Kubernetes秘钥。

    > kubectl create secret generic azure-config-file --from-file=azure.json
    secret "azure-config-file" created


    6、如果你使用的是Rancher配置的Azure IaaS Backed Clusters,从集群中删除ingress controller。

    > kubectl get ns
    NAME STATUS AGE
    cattle-system Active 1d
    default Active 1d
    ingress-nginx Active 1d
    kube-public Active 1d
    kube-system Active 1d
    [quote] kubectl delete ns/ingress-nginx
    namespace "ingress-nginx" deleted
    [/quote]

    注意:如果您是使用Rancher中的 AKS配置的集群,则不会提供ingress controller。


    7、安装nginx ingress controller并为ExternalDNS配置它。创建ingress-nginx部署和服务。

    kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
    kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml


    8、由于在基于Rancher的Kubernetes集群上默认启用了RBAC,因此可以从下面的脚本创建名为

    externaldns.yaml的yaml文件,或者使用此repo中的externaldns-template.yaml文件。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
    name: external-dns
    ---
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRole
    metadata: name: external-dns
    rules:
    [list]
    [*]apiGroups: [""][/*]
    [/list] resources: ["services"]
    verbs: ["get","watch","list"]
    [list]
    [*]apiGroups: [""][/*]
    [/list] resources: ["pods"]
    verbs: ["get","watch","list"]
    [list]
    [*]apiGroups: ["extensions"] [/*]
    [/list] resources: ["ingresses"]
    verbs: ["get","watch","list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRoleBinding
    metadata: name: external-dns-viewer
    roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: external-dns
    subjects:
    [list]
    [*]kind: ServiceAccount[/*]
    [/list] name: external-dns
    namespace: default
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
    name: external-dns
    spec:
    strategy:
    type: Recreate
    template:
    metadata:
    labels:
    app: external-dns
    spec:
    serviceAccountName: external-dns
    containers:
    - name: external-dns
    image: registry.opensource.zalan.do/teapot/external-dns:v0.5.2
    args:
    - --source=service
    - --source=ingress
    - --domain-filter=vanbrackel.net # (optional) limit to only vanbrackel.net domains; change to match the zone created above.
    - --provider=azure
    - --azure-resource-group=MC_rancher-group_c-6vkts_eastus # (optional) use the DNS zones from above
    volumeMounts:
    - name: azure-config-file
    mountPath: /etc/kubernetes
    readOnly: true
    volumes:
    - name: azure-config-file
    secret:
    secretName: azure-config-file
    EXTERNAL_DNS=$(cat externaldns-template.yaml)
    EXTERNAL_DNS=${EXTERNAL_DNS//DOMAIN/$DOMAIN} && echo "${EXTERNAL_DNS//RESOURCE_GROUP/$RESOURCE_GROUP}" >> externaldns.yaml
    kubectl create -f externaldns.yaml


    # 验证 #

    1、以与部署ExternalDNS相同的方式在ingress中创建nginx服务

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
    name: nginx
    spec:
    template:
    metadata:
    labels:
    app: nginx
    spec:
    containers:
    - image: nginx
    name: nginx
    ports:
    - containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
    name: nginx-svc
    spec:
    ports:
    - port: 80
    protocol: TCP
    targetPort: 80
    selector:
    app: nginx
    type: ClusterIP

    ---
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
    name: nginx
    annotations:
    kubernetes.io/ingress.class: nginx
    spec:
    rules:
    - host: server.vanbrackel.net
    http:
    paths:
    - backend:
    serviceName: nginx-svc
    servicePort: 80
    path: /


    NGINX=$(cat nginx-ingress-test-template.yaml) && echo "${NGINX//DOMAIN/$DOMAIN}" >> nginx-ingress-test.yaml


    2、创建nginx-ingress controller

    kubectl create -f nginx-ingress-test.yaml


    3、稍等几分钟


    4、检查一下是否已有record被创建出来

    [jason@vblinux ~ ]$ az network dns record-set a list --resource-group $RESOURCE_GROUP --zone-name $DNS_ZONE
    [
    {
    "arecords": [
    {
    "ipv4Address": "13.68.138.206"
    }
    ],
    "etag": "0fb3eaf9-7bf2-48c4-b8f8-432e05dce94a",
    "fqdn": "server.vanbrackel.net.",
    "id": "/subscriptions/c7e23d24-5dcd-4c7c-ae84-22f6f814dc02/resourceGroups/mc_rancher-group_c-6vkts_eastus/providers/Microsoft.Network/dnszones/vanbrackel.net/A/server",
    "metadata": null,
    "name": "server",
    "resourceGroup": "mc_rancher-group_c-6vkts_eastus",
    "ttl": 300,
    "type": "Microsoft.Network/dnszones/A"
    }
    ]


    5、检查日志

    kubectl logs external-dns-655df89959-7ztm2 
    time="2018-06-13T23:57:11Z" level=info msg="config: {Master: KubeConfig: Sources:[service ingress] Namespace: AnnotationFilter: FQDNTemplate: CombineFQDNAndAnnotation:false Compatibility: PublishInternal:false ConnectorSourceServer:localhost:8080 Provider:azure GoogleProject: DomainFilter:[vanbrackel.net] ZoneIDFilter:[] AWSZoneType: AWSAssumeRole: AzureConfigFile:/etc/kubernetes/azure.json AzureResourceGroup:MC_rancher-group_c-6vkts_eastus CloudflareProxied:false InfobloxGridHost: InfobloxWapiPort:443 InfobloxWapiUsername:admin InfobloxWapiPassword: InfobloxWapiVersion:2.3.1 InfobloxSSLVerify:true DynCustomerName: DynUsername: DynPassword: DynMinTTLSeconds:0 InMemoryZones:[] PDNSServer:http://localhost:8081 PDNSAPIKey: Policy:sync Registry:txt TXTOwnerID:default TXTPrefix: Interval:1m0s Once:false DryRun:false LogFormat:text MetricsAddress::7979 LogLevel:debug}"
    time="2018-06-13T23:57:11Z" level=info msg="Connected to cluster at https://10.0.0.1:443"
    ...
    time="2018-06-14T00:02:11Z" level=debug msg="Retrieving Azure DNS zones."
    time="2018-06-14T00:02:12Z" level=debug msg="Found 1 Azure DNS zone(s)."
    time="2018-06-14T00:02:12Z" level=debug msg="Retrieving Azure DNS records for zone 'vanbrackel.net'."
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service default/kubernetes"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service default/nginx-svc"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/default-http-backend"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/ingress-nginx"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-controller" time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-default-backend"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/heapster"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/kube-dns"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/kubernetes-dashboard"
    time="2018-06-14T00:02:12Z" level=debug msg="No endpoints could be generated from service kube-system/tiller-deploy"
    time="2018-06-14T00:02:12Z" level=debug msg="Endpoints generated from ingress: default/nginx: [server.vanbrackel.net 0 IN A 13.68.138.206]"
    time="2018-06-14T00:02:12Z" level=debug msg="Retrieving Azure DNS zones."
    time="2018-06-14T00:02:12Z" level=debug msg="Found 1 Azure DNS zone(s)."
    time="2018-06-14T00:02:12Z" level=info msg="Updating A record named 'server' to '13.68.138.206' for Azure DNS zone 'vanbrackel.net'."
    time="2018-06-14T00:02:13Z" level=info msg="Updating TXT record named 'server' to '\"heritage=external-dns,external-dns/owner=default,external-dns/resource=ingress/default/nginx\"' for Azure DNS zone 'vanbrackel.net'."
    time="2018-06-14T00:03:11Z" level=debug msg="Retrieving Azure DNS zones."
    time="2018-06-14T00:03:12Z" level=debug msg="Found 1 Azure DNS zone(s)."
    time="2018-06-14T00:03:12Z" level=debug msg="Retrieving Azure DNS records for zone 'vanbrackel.net'."
    time="2018-06-14T00:03:12Z" level=debug msg="Found A record for 'server.vanbrackel.net' with target '13.68.138.206'."
    time="2018-06-14T00:03:12Z" level=debug msg="Found TXT record for 'server.vanbrackel.net' with target '\"heritage=external-dns,external-dns/owner=default,external-dns/resource=ingress/default/nginx\"'."
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service default/kubernetes"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service default/nginx-svc" time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/default-http-backend"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service ingress-nginx/ingress-nginx"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-controller"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/full-guppy-nginx-ingress-default-backend"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/heapster"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/kube-dns"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/kubernetes-dashboard"
    time="2018-06-14T00:03:12Z" level=debug msg="No endpoints could be generated from service kube-system/tiller-deploy"
    time="2018-06-14T00:03:12Z" level=debug msg="Endpoints generated from ingress: default/nginx: [server.vanbrackel.net 0 IN A 13.68.138.206]"
    time="2018-06-14T00:03:12Z" level=debug msg="Retrieving Azure DNS zones."
    time="2018-06-14T00:03:12Z" level=debug msg="Found 1 Azure DNS zone(s)."


    您还可以在ExternalDNS的repo中了解更多信息:

    https://github.com/kubernetes-incubator/external-dns

    如希望对原文中的代码有更深入的了解,请猛戳这里:

    https://github.com/JasonvanBrackel/kubernetes-external-dns-in-rancher#prerequisites

    管理Kubernetes集群时需要关注的关键指标

    Rancher 发表了文章 • 1 个评论 • 752 次浏览 • 2018-07-13 15:43 • 来自相关话题

    有时我们在面对分布式系统工程时常感到痛苦。构建分布式系统真的很难,无论是哪个行业的企业,都希望我们在解决他们的业务问题的同时,还能考虑潜在的大规模业务问题。与大规模部署随之而来的一大挑战,是用户还要考虑创建新特性和避免回档。就算能够非常出色地实现这些目标,用户 ...查看全部
    有时我们在面对分布式系统工程时常感到痛苦。构建分布式系统真的很难,无论是哪个行业的企业,都希望我们在解决他们的业务问题的同时,还能考虑潜在的大规模业务问题。与大规模部署随之而来的一大挑战,是用户还要考虑创建新特性和避免回档。就算能够非常出色地实现这些目标,用户仍然会担忧很多其他问题,例如信息是否安全、是否遵从法规,以及企业的这一投资是否真的有足够价值。

    如果上述描述和你的团队现在的境况很像,而且你们的系统已经在生产环境中运行了,那么恭喜你,你已经通过了第一轮考验。

    无论你多么努力建立了一个出色的系统,有时意想不到的事还是会发生。有很多这样的先例。一个杰出的产品,或者是病毒式应用,可能会带来前所未有的成功,而成功之后你就会发现,原先你以为的、你的系统面对大规模应用时的处理方式,好像不适用了。

    640.webp_(7)_.jpg

    Pokemon Go云数据存储的每秒处理数(预期vs实际)
    来源: Bringing Pokémon GO to life on Google Cloud,发布于2018年5月30日

    这一情况是可能发生的,而你也应该为此做好准备。这也是本系列文章所要提到的。在本系列教程中我们将向你介绍需要追踪的内容,为什么追踪它们,以及面对可能的根本原因时需要做的缓解处理。

    我们会介绍每一种指标、追踪它的方法以及你可以对应采取的措施。我们将使用不同的工具收集和分析这些数据。教程不会涉及到太多细节的内容,但会提供拓展链接,让大家可以获取更多信息。话不多说,让我们开始吧。

    Metrics:用于监控,不止监控

    这一系列文章主要关注的是如何监控和运行Kubernetes集群。使用日志是一个不错的方法,但在大规模部署的情况下,日志在事后分析工作中可能有很大作用,却难以在过程之中不断警告运维人员那些正在出现的越来越严重的问题。Metrics Server可以监控容器的CPU和内存使用情况,以及容器所运行在的节点的情况。

    这让运维人员能够设置并监控KPI(关键绩效指标)。这些运维定义层面的东西可以为运维团队提供一种确定应用程序或者节点何时不健康的方法。同时也给他们提供了查看问题所需要的所有数据。

    此外,Metrics Server
    (https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/)允许Kubernetes启用Horizontal Pod Autoscaling
    (https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)。该功能可以让Kubernetes在扩展pod实例数量时,是基于Kubernetes Metrics API报告的指标以及这些指标反映出来的API对象数量来进行扩展的。

    在Rancher Kubernetes集群中 设置Metrics Server

    从Kubernetes 1.8版本开始,Metrics Server以Kubernetes Monitoring Architecture
    (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)插件的方式成为了拉取容器指标的标准。在该标准出现之前,默认使用的是Heapster,现在已经弃用,而开始支持Metrics Server。

    很快,Metrics Server就将可以在Rancher 2.0配置的Kubernetes集群上运行了。您可以在Rancher的Github repo中查看Rancher 2.0最新版本的发布动态,一起期待:https://github.com/rancher/rancher/releases。

    如果想让Metric Server工作,你必须通过Rancher Server API修改集群的定义。这样可以允许Rancher服务器修改Kubelet以及KubeAPI参数,让它们包含Metrics Server正常运行所需要的标记。

    有关如何在Rancher Provisioned集群上执行这一操作,以及修改其他hyperkube-based集群的说明,可以参考github的这一链接:https://github.com/JasonvanBrackel/metrics-server-on-rancher-2.0.2。

    混合云场景下容器技术在新能源功率预测产品中的最佳实践

    Rancher 发表了文章 • 1 个评论 • 854 次浏览 • 2018-07-13 15:38 • 来自相关话题

    能源互联网是物联网和“互联网+”在能源行业深度融合的产物,是中国制造2025的重要组成部分,我们现在还处于能源互联网的早期阶段。绝大部分能源行业的应用都部署在私有局域网内,并且网络结构异常复杂,这是阻碍互联网技术在能源行业落地的最大挑战。 ...查看全部
    能源互联网是物联网和“互联网+”在能源行业深度融合的产物,是中国制造2025的重要组成部分,我们现在还处于能源互联网的早期阶段。绝大部分能源行业的应用都部署在私有局域网内,并且网络结构异常复杂,这是阻碍互联网技术在能源行业落地的最大挑战。

    6月28日,金风科技数据平台架构师张利出席了Rancher Labs举办的Container Day 2018容器技术大会,并做了题为《混合云场景下容器技术在新能源功率预测产品中的最佳实践》的演讲。

    金风科技是中国成立最早、自主研发能力最强的风电设备研发及制造企业之一。作为金风科技数据平台架构师、Team Leader,张利自2014年加入金风科技后,主要负责公司新能源功率预测产品的研发、数据平台的搭建、以及解决方案的规划。他带领基础架构团队建立多云和混合云场景下的持续交付平台、搭建能源气象平台,实现功率预测产品的微服务化改造、完成该产品端到端的交付,实现产品到解决方案的平台化改造。

    在演讲中,张利从金风科技的实战经验出发,为大家解读了容器技术如何应用在传统能源行业中,如何实现混合云场景下功率预测产品的快速落地。本文由演讲内容整理而成。

    金风科技主要做的产品是新能源功率预测产品,是一家典型的制造业公司,软件并不是主业。但是随着能源互联网的发展,能源企业开始转型,我们的软件产品也开始变得非常丰富起来,同时有很多场景想强大现有软件的产品线,于是我们开始一点点进行转型,并基于现在的互联网技术去做传统制造业的业务。

    金风科技是国际化清洁能源和节能环保的整体解决方案提供商。公司成立了20年,现在管理着38GW的风电场的装机容量,现有风机数量2.5万台,整个在全球排名第3,已经连续至少5年中国市场排名第一。这是目前我们对整个环保做的一些贡献。

    业务背景


    3.png


    功率测产品是个什么样一个场景?它是基于天气预报加上AI两个技术进行预测。天气预报得到了时间跟风速的曲线,然后之后是用AI去训练功率曲线,将风速跟功率的曲线组合,得到的结果就是一个预测的基于时间的功率,也就是整体的发电量的情况,这是我们大概的业务场景。


    4.png



    实际上,我们的软件在网络层非常复杂。我们有严格的安全保护,将网络分成了两个区,一般所有的系统不能部署在外网,都是部署在隔离区内,中间放了一个应景的防火墙,数据只能通过文件的形式往里进,出去是基于UDP跟阉割版的TCP的协议,这里面很多协议是不能用的,这是非常复杂的部分,所以发布软件的时候是十分困难的,大部分时间只能人为地发布软件产品。


    5.png


    还有另外一点是,部署架构也特别复杂。在2010年之前,大部分的电场是分布在中国各个偏远山区、戈壁之类的地方,因为那里的太阳能和风能十分丰富。到了2010年的时候,出现了一些区域的中心,他们会把这些散落在各个电场的数据全部都拿上来进行统一的风电场监控。2010年到2015年之间,这些电场开始有集中化的监控。到了2015年,功率测的产品开始变成一个集中化的产品,我大概是那个时候入职金风,开始做集中式的功率测产品。有一个复杂的地方是,所有的软件系统既要部署在边缘节点的电场,也要部署在省中心的一个小机房,还要部署在客户的总部。

    最佳实践


    6.png



    现在我们在边缘节点的架构已经完全的容器化了。在业务层会有一些标准的IOT的场景,比如说采集、存储、ETL展示,这是标准的一个做法。另一方面,由于我们是基于AI进行预测,因此有一部分是基于TensorFlow去做预测,而那个部分是由一个独立的团队进行,因此实际上发布十分困难,尤其是AI的部分。下边会再详细分析这个问题。

    7.png


    这个AI分两部分,一个是离线的AI,这个我们在2015年已经实现了在云端的预测,是短期一天发布一次。在线的预测是15分钟,我们称为超短期的预测,这个业务现在还是在边缘节点,也就是分布在各个场站和省中心、区域中心,我们现在是计划一点点把它部署到公有云上来计算,进而提高预测准确度。

    8.png


    在业务系统上边,现在正在面临一些挑战,比如,客户的需求不稳定。我们从2015年才开始开发这个系统,而且每个客户的需求不完全一致,因此这个系统更新的次数很频繁。大家可能认为一个传统的企业,它的软件的产品发布不应该那么频繁,但是事实上并非如此,随着能源互联网,包括可再生能源这些绿色清洁环保的能源受到中国政府的重视,为了实现平价的上网,考核的力度在不断加大。如果这些新能源要平价的上网,包括功率测的准确度,是在其中起到重要支撑作用的一个业务,因此客户的需求不断的变,系统更新的频率也在不断的增加。另外一点,就是之前提到AI算法,其实想放到云端,但是这是一个在线的业务,涉及到数据的回传,如果算完之后再下发下去,整个过程会变得非常复杂。从偏远山区到一个省中心,再到客户的数据中心,一般是在一个大城市,然后再到我们的公有云上,整个链路非常长,数据的回传跟下发十分复杂,再加上刚才说的网络的结构也非常复杂,导致如果在线AI算法十分麻烦。

    9.png


    另外有一条是在公有云上的业务,底层也是基于容器云平台,我们自己做了一套,数据弧的这一层稍微简单,也分了采集进存储,存储里边是我们自己用的,业务数据库用的是MongoDB,有一部分是Hadoop,GlusterFS,S3。上面分了三部分,一部分是我们做功率测的业务层,包括它的运营也是一条ETL展示。另外一个部分,其中一个核心是天气预报,紫色的那个颜色WRF实际上是天气预报里一个核心的高效能的计算,类似于HPC那样,它一般跑在超算中心或者是公有云上。一般情况下,运行在超算中心,这个超算中心是没有云化的,所以那个业务也比较复杂。另外一点就是一个独立的AI模块,将它做了一个训练进预测的拆分。整个业务是三大业务,再加上底层的容器云平台,把那个存储层作为一个公共的池子,这是现有的业务架构,但实际上这会不断的变化,而且也在不断的扩大。

    10.png


    在公有云上这套业务系统里边,目前最大挑战是要实现跨业务部门,比如做功率测的,还有一些集中监控、预警等很多个部门,整个产品线大概包括10个到20个产品,因此各个部门之间数据要经常的相互流动,要做成公共的平台性的业务。此外,还要实现对外服务,对客户能够发布一个通用的服务。

    11.png


    关于能源气象这个部分,我们开始把它做成一个国际化的能源气象服务。另外,风能和太阳能可以同时去提供服务。虽然我们本身是做风力发电的,但是实际上在功率测方面是不分风和太阳能的,所以这个服务是把两个全部加到一起。

    12.png



    除了在AI算法里边的挑战,在公有云上的挑战就是此前提到的在线的预测系统如何搭建,包括数据的传输层是很复杂的。另外一点就是在大数据跟AI一个整体的解决方案的搭建。

    机遇与挑战


    13.png



    我们现有的机遇跟挑战,从DevOps角度来看,之前我们大概是两周一次的发布频率,速度很慢,因为涉及到很多个电场同时去发布是十分复杂的,但是现在几乎能做到一天一次,这是用容器化的平台的优势,即可以实现更高的发布速度。另外一个挑战是,由于我们是传统企业,大部分的运维人员实际上对新的技术了解得比较少,因此对他们来说要求较高。现在整个运维团队有十几个人,但是实际上真正懂这个技术的只有一两个人,所以这个挑战很大。另外一部分就是在微孵化改造的过程中遇到一些问题,好处是系统扩展性变强了,但是随着业务不断地迭代,业务不断地增加的时候,拆分力度很难把握。现在有些服务开始拆掉,有些服务要合并,这对整个架构是一个非常大的挑战。另外一点挑战就是为了提高准确率,在AI层面会有一些很大的困难。机遇就是对于算法工程师来说,他们不需要再去部署底层的架构,降低运维的成本。首先他们实际上不是在一个公有云、一个集中式的系统上,而是分布在几百个这种电场,运维成本很高。算法工程师在发布这个算法的时候,实际上他们学习Docker技术是十分困难的,因为大部分算法工程师是学数学出身的。

    总 结

    14.png


    金风科技现在大概使用这个系统已经有两年的时间,目前能够实现运维成本能降低50%左右,迭代速度提高10倍,从两周一次增快到一天一次,并且现在已经覆盖50%的电场,大概的规模是200个左右,覆盖的客户有五个大的集团客户,有十多个省中心的客户。

    Bare Metal K8S集群在美国快餐连锁Chick-fil-A 的大规模使用

    Rancher 发表了文章 • 1 个评论 • 858 次浏览 • 2018-07-13 15:22 • 来自相关话题

    快餐连锁店Chick-fil-A在其2000多家餐厅的边缘计算中使用着Kubernetes,在规模上看,这意味着有大约6000台设备上同时运行着Kubernetes。其中与此相关的最大的一个挑战是:如何在餐厅的物理机上部署和管理这么多Kubernetes集群。 ...查看全部
    快餐连锁店Chick-fil-A在其2000多家餐厅的边缘计算中使用着Kubernetes,在规模上看,这意味着有大约6000台设备上同时运行着Kubernetes。其中与此相关的最大的一个挑战是:如何在餐厅的物理机上部署和管理这么多Kubernetes集群。本文由Chick-fil-A的技术团队所写,分享他们在Kubernetes集群管理技术选型、物理机上Kubernetes集群的安装和管理方面的经验。

    大多数情况下,Kubernetes都在云中部署,或由熟练Kubernetes的技术人员在物理机上部署(再或者至少配有远程访问)。但对Chick-fil-A而言,我们的Kubernetes部署是由那些仅关注初始硬件安装的安装人员完成的。因为其自启动的特性,它们从不需要直接连接到计算设备——而是连接以太网和电源线,并通过查看应用程序app来检查集群的状态 。整个替换过程由对技术并不太专业的餐厅老板/运营者或他们的团队完成。

    最大的挑战是,我们的边缘计算部署并不完全在“数据中心环境”中。

    640.webp_(4)_.jpg


    边缘计算硬件及经典的安装方式

    集群管理:我们考虑过的选择

    为了解决集群管理的挑战,我们做过全面的技术调研,曾考虑过如下几个选项:

    Kubespray - 我们最开始调查了基于Ansible的Kubespray,但我们发现它相当脆弱。当事情进展顺利时,我们能得到了一个集群;但当事情进展不太顺利时,我们就会创建一块难以变回计算机的“砖块”。我们还发现使用Kubespray启动集群的过程非常缓慢,通常在我们的硬件栈上花费的时间长达30分钟。我们相信Kubespray能有更长远的发展,但就我们的调研结果而言,我们认为得从别的方向探索别的解决方案。

    Openshift - Openshift可以创建Kubernetes集群,但我们不喜欢在至关重要的基础设施部分跟供应商的解决方案捆绑地太过紧密,不想承担未来可能被技术锁定的风险。

    Kops - 我们是Kops的忠实粉丝,我们用它来部署我们云的“控制面板”Kubernetes集群。不幸的是,当我们将其使用到我们的边缘计算中时,Kops并不是一个可行的裸机解决方案。我们期待看到它在未来的发展。

    Kubeadm - Kubeadm是另一个不错的Kubernetes集群实用程序。Kubeadm项目看起来很有发展前景,但我们认为它比一些替代品 (尤其在其灵活性上)复杂的多,包括...

    RKE

    就我们目前的选择而言,RKE是最终赢家。RKE是由Rancher Labs提供的开源的Kubernetes集群管理引擎。虽然我们暂时未使用Rancher 2.0来管理我们的集群,但我们确实喜欢使用RKE来初始化和维护集群的简单性。

    640.webp_(2)_.jpg


    要使用RKE,你需要确定一个领导节点并为其提供一个配置YAML文件,YAML文件中包含有关该集群的数据,主要是参与集群活动的节点的主机名。

    如果集群中的节点发生添加、删除、或死亡,则配置文件需要拥有一个对当前和未来节点的准确描述。如果配置不能保持持续最新,集群就会失败。虽然我们认为缺少节点不应该使群集初始化/更新失败,但目前来看实际情况正是如此。

    安装过程

    我们在餐厅的安装过程非常简单——将设备拆箱,将其插入电源和标记的交换机端口,就是这样。它们会自动启动电源,并实现自引导和集群创建。RKE让非技术用户能够在不了解Kubernetes甚至整体架构的情况下,通过无比简单的过程执行安装和替换的工作,这一体验非常棒,不过它也确实需要一些更复杂的引导过程。

    尚未被纳入集群的节点之间,需要彼此协调以确定谁将被纳入到集群中。他们还需要选出一个主节点来通过RKE执行集群创建。

    Highlander

    为了解决这个问题,我们开发了Highlander。因为我们只能有一个集群发起者。

    Highlander是我们基础边缘镜像的一部分。当每个节点启动时,UDP会广播其存在并询问是否存在已建立的领导者。它也会开始倾听自己。几秒钟后没有回复,它将发送另一个广播,宣布自己成为领导者。有什么异议吗?如果没有反对的讯息,该节点将很快成为集群领导者,并以领导者身份回应未来接收到的所有请求。

    如果另一个节点已经声明了自己领导者的角色,新节点将确认该声明。现有的领导者会执行“RKE up”将新节点纳管到现有的集群中。

    节点们会定期沟通以确保领导者仍在其中。如果旧领导者已经死亡,一个新的领导者将通过一个使用随机睡眠和领导声明的简单协议来选举而出。虽然这很简单不复杂,容易推理和理解,但它能实现成规模地有效工作。

    领导者选举完成后,Highlander还能确保集群被正确得配置。在我们的环境中,这包括:
    • 将 KubeDNS切换成CoreDNS
    • 创建Istio或其他核心控制面板节点
    • OAuth身份认证

    注意:我们的每个节点都有自己的身份和短暂的JWT来访问已验证的资源。Highlander提供此身份,并以Kubernetes秘钥的形式来提供token令牌。

    整合过程

    尽管我们在本文中主要关注集群初始化,接下来我们也介绍一下在餐厅中实时进行节点初始化的整个流程。

    640.webp_(3)_.jpg


    (不可避免的)失败

    最后我们想分享一些失败的经验。若基础设施出现故障,我们希望能够灵活应对。节点故障可能由多种原因导致:设备故障,网络交换机故障,电源线意外拔出。在所有这些情况下,我们必须快速诊断什么是导致故障的真正原因,而什么是无关的异常。这个过程很复杂,未来我们会带来另一篇文章来以此为主题展开分享。也就是说,当我们诊断失败时,我们的流程是向餐厅投放一个基本图片替代品(包含可视化安装说明),并让餐厅老板/运营者或他们的团队执行替换工作。

    同时,我们的Kubernetes集群将继续在节点数量减少的情况下运行,并随时准备迎接更换节点。

    中国东信基于Kubernetes的容器云PaaS平台

    Rancher 发表了文章 • 1 个评论 • 1862 次浏览 • 2018-07-13 12:23 • 来自相关话题

    “中国-东盟信息港”是按照国家“一带一路”倡议总体布局要求、建设更为紧密的中国—东盟命运共同体、21世纪海上丝绸之路的一个信息平台:http://www.caih.com。东信基于Rancher Kubernetes架构和建设了他们的容器云PaaS平台,在云原 ...查看全部
    “中国-东盟信息港”是按照国家“一带一路”倡议总体布局要求、建设更为紧密的中国—东盟命运共同体、21世纪海上丝绸之路的一个信息平台:http://www.caih.com。东信基于Rancher Kubernetes架构和建设了他们的容器云PaaS平台,在云原生、容器化、微服务、CICD、DevOps等方面的都有了相关实践和应用。

    6月28日,负责中国东信容器云PaaS 平台的研发和建设、中国-东盟信息港的研发总监王志雄出席了Rancher Labs举办的Container Day 2018容器技术大会,并做了题为《中国东信基于Kubernetes的容器云PaaS平台》的主题演讲,本文根据演讲内容整理而成。

    王志雄,中国-东盟信息港研发总监,负责中国东信公司容器云的研发和管理工作。硕士,曾就职于IBM、华为等公司,在IBM时任研发部门经理、技术专家。10年以上的云计算IaaS、PaaS、容器云、SDN/NFV、微服务、DevOps等研发经验。

    各位来宾,各位朋友,大家上午好,我是来自中国-东盟信息港的王志雄,在中国东信负责容器云PaaS 平台的研发和建设。今天我从技术角度、就如下四个方面,给大家分享中国东信基于Kubernetes建设容器云PaaS平台的经验。


    image001.png



    第一个是PaaS平台,PaaS平台在云计算刚出现的时候就已经和IaaS、SaaS已经共存了,但是刚开始只是不温不火,为什么到这几年PaaS平台才这么火了呢?如何来建设一个PaaS台?PaaS平台需要哪些技术内容来承载?我会在这里做一个分享。

    第二个是微服务,微服务我们说有两条路线,第一条是SpringCloud,第二条是Kubernetes,我们来看一看怎么使用Kubernetes来构建一个微服务的平台。

    第三个是CICD ,第四个是DevOps。我们会看到有些场合说的CICD,有的场合说的DevOps,这二者有什么关系,有什么区别,如何来构建CICD 和DevOps,我会在这里做一个揭晓。
    #Kubernetes与容器云PaaS平台
    我们首先来看一下Kubernetes与容器云平台。Kubernetes这个PaaS平台要解决三个方面的IT架构方面的问题。第一,耦合,我们做研发的知道,除了应用程序之外,不管Java,还是Go,还是Python,都需要大量的应用配置,这些配置和我们的系统环境——Windows也好,Linux也好——都是耦合的,所以会经常出现我们在交付产品的时候,明明在研发的环境可用的,到了测试不可用,到了最后的生产发布也不可用,从而出现这样的神秘的BUG、神秘的配置。之前有人提出一个比较好的方法是写一个很好的文档以供参考,但是文档通常还是会遗漏,而且这还要依赖于我们人员写文档的能力,以及理解的能力。第二个,繁杂,现在不论是技术、工具还是语言都非常繁杂,例如语言有java、有Go、有python、有php。第三个,不灵活,我们现在互联网时代是需要从按周发布,提升为按天发布,甚至一天几次、十几次甚至上百次发布,这在以前的物理机或者虚拟机时代是不可能的。


    image002.png



    所以如何来解决这些问题?Cloud Native是这个答案。Cloud Native能做到什么呢?第一是容器化,把应用以及它的配置打包,保证开发、测试和运维的环境一致,从而避免神秘的配置、神秘的错误、神秘的文档、还有可能是神秘的人。第二是面向微服务,把以前的一体的区域式服务给分解为微服务,从而更灵活,并可以独立更新。第三方面是动态编排管理,如果容器很多,则需要大量的配置文件,需要部署很多容器则必然要用到编排管理,也就是我们在此选择的Kubernetes。


    image003.png



    下图是中国东信基于Kubernetes、Docker研发的四大场景。第一是企业应用平台,企业应用平台可以将应用在平台上做到一键部署,利用pod auto-scaling进行弹性自动伸缩,如果出现故障则可以通过health check实现故障自愈,另外还有强大的灰度发布功能。之前的互联网公司可能需要一个非常大的团队来做灰度发布,如今使用Kubernetes,Kubernetes已经自带灰度发布功能了。第二个是我们的微服务,用Kubernetes来构建我们的微服务平台,构建之后我们就可以组件化、松耦合、去中心,而且是灵活独立的。第三个我们做了这样一套CICD的系统,CICD的系统从我们的开发、从代码提交、从编译到构建到自动化测试、到容器化发布。第四个是DevOps ,DevOps是可以做到开发运维的协同。


    image004.png



    这是我们中国东信的PaaS 平台,我们从最底层看起,最底层是容器云的Infra,我们说Infra不是IaaS产品吗?其实不管是IaaS还是PaaS 都需要Infrastructure,当然它们是有区别的。我们不管做Iass做PaaS ,其中的难点归到最后其实都是存储和网络,我在后面会分享存储网络我们是怎么做的。再上来是容器资源管理,以及容器集群编排与调度,需要把这个Pod调度到众多集群节点中的哪一个?根据什么策略来调度?根据CPU调度还是根据内存调度?根据亲和策略还是反亲和策略?再上来是我们容器云应用Service,我们说PaaS 平台是以应用为中心,所以肯定需要这样一个强大的应用Service,PaaS平台应用的Service有服务发现、配置中心、负载均衡、弹性伸缩、服务编排这样一些强大的功能,那么就用我们的PaaS平台,上面我们会提供中间件、数据库、负载均衡、文件存储等等。如果需要哪一个,比如需要一个MySQL ,把一个MySQL容器拿过去用就可以了。再去用我们的中间件,PaaS平台上面就承载我们庞大的、灵活的企业应用。


    image005.png



    如果研发过Kubernetes应该对这个图很熟悉,这是个典型的Kubernetes集群,我们分两个层面来看。第一个层面一个是我们自己内部的管理,部署Service,Service都是通过Master进行来管理,通过API Server来和各个组件进行交互,用Controller Mananger来控制我们各个组件获得的调度,Scheduler是具体的应用策略,etcd 是一个数据库。那么会调度到我们的Node上,Node上存在我们的Pod ,一个Pod里可以有可以有多个Container,这是我们的内部的管理提供Service。第二个层面是我们从外部的访问,外部的访问一般就是通过Internet经过防火墙来访问我们对外提供一个ingress ,ingress是Kubernetes提供的一个非常强大的功能,有了ingress 之后,我们可以对外提供一个统一的域名系统,外部只要访问我们的统一域名,就可以访问我们内部的不同的应用,通过此域名就可以进行智能的分发。

    image006.png


    上面我们说的叫物理架构,而下面我会讲讲逻辑架构,这两个的关注面不一样。逻辑架构从我们研发内部看,最底层是容器基础设施层,包括我们的Runtime、Volume Plugin、Network Plugin;再上来是核心层,核心层对外提供API,对内提供Plugin环境;第三层是应用层,可以进行部署,可以进行ingress智能路由;再上来是管理层,可以进行智能化以及Network policy;接口层是对外提供我们的命令行管理工具;Ecosystem是我们的生态。


    image007.png


    刚才说PaaS的基础架构的终极难题是网络和存储。我们先来看一下中国东信是怎么解决网络问题的。网络的方案非常多,我们看到有单组区域的,开始是单组区域有bridge、host、container、NAT,也有原生的iptables;再上来有主机集群,有OVS,有IPSec;现在最主流的就是最上面一行,一个是Flannel,一个是calico,还有将这两个折在一起的Canal。这里我可以提一下我们的SDN(软件定义网络)。SDN起源于Openflow,什么是Openflow?Openflow是有强大的报文解析能力,可以对报文进行任意的更改,这个强大的能力刚问世时取得了瞩目的关注,并且在当年被评为未来10大创新技术的排名第二位,第一位是云计算,第二位是SDN。但最初Openflow在问世后的广大的应用中碰到了一些问题,因为它和以前传统的不兼容,所以实际上最后被应用最多的是VXLAN。VXLAN是一个overlay的技术。SDN在应用最多的是什么?是VXLAN overlay。第三个是BGP,BGP在网络中应该有二三十年的历史,经过不断地打磨、沉淀、优化,实际上BGP已经开始统一我们的SDN领域了,现在BGP已经可以取代我们的软件定义网络,虚拟化的网络。

    image008.png


    SDN网络通用的两个方向,第一个是Flannel,Flannel其实本质上是一个Overlay的方案,所以在主机的容器内是自动分布的IP,只是在主机之外,做了一个Overlay叠加的封装,但这个Overlay和我们传统的IaaS的overlay相比其实是不一样的,传统的IaaS的VXLAN除了Overlay的功能,还有多租户的功能,但是这里因为它只在出口做了个封装,所以没有多租户的功能。所以Flannel有什么缺点?它没有安全隔离的功能。第二个它封包解包必然带来开销,所以这个是我们要解决的问题。Flannel官方也表示如果用户想对数据中心做更好的网络安全隔离,推荐用Calico。

    image009.png


    Calico的核心是基于BGP,如果是小网络可以用BGP的client进行IP路由的自动分发以及路由互联。Calico的好处是什么?简单!若是使用Overlay网络出现故障,用户难以排查故障是来自overlay还是underlay;但用BGP,用户直接定位路由就好了。此外,Calico还带了一个很好的特性就是和network policy结合在一起,可以提供网络的微分段,若一个主机上有多个容器、有多个应用,可以提供很好的安全隔离。Calico的不足是什么?它需要取决于数据中心对于BGP的支持力度,可能现在还不是所有数据中心都是BGP。但我还是推荐BGP的,从最初的的Facebook到现在国内的大公司,很多都已经开使用BGP来取代所有的内部的路由协议,包括二层协议。这是一个很好的方案,可以简化运维工作,数据中心只有一种路由协议多好。

    image010.png


    图片描述谈完网络,另一个难题就是存储。Kubernetes和Docker相比除了普通的volume之外,还提供了persistent volume和storage class,通过PV和PVC来抽象存储细节。这有什么好处?可以做到管理控制与转化分离。管理员关注PV的存储细节,用户只要关注PVC使用存储就好了。通用的存储ceph、NFS、Gluster都没问题。

    image011.png


    容器云微服务
    下面我们来看一下怎样用Kubernetes来构建一个微服务。下图是我们很熟悉的微服务架构的特性,把一个单体的应用来分解拆分为多个灵活的微服务。微服务的特性是服务的组件化。怎样拆分一个微服务?不是按代码的行数,不是按函数,而是按功能、按产品模式来拆分。有了微服务就可以去中心化的管理。


    image013.png



    构建微服务,必然要有如下这些功能:有这么多的服务,怎样发现这个服务?所以要服务发现。多个服务如何做到负载均衡?多个应用service怎么样进行智能的路由分发?怎样管理成千上万个服务的配置?怎样弹性伸缩?怎样容错?怎样自动升级?访问控制怎么做?

    放在13、14之间.png


    下图就是我们使用Kubernetes来构建的微服务。怎样来构建?把上述问题的答案汇聚在一起就是最终答案了。第一个服务发现,使用我们的service,包括我们Kubernetes内置的DNS就可以来做这样一个服务发现。第二个负载均衡,有node上的kube-proxy加上我们的service分发是负载均衡。第三个智能路由,通过ingress可以智能地将不同的应用通过统一的入口分发到后端的服务。配置中心通过我们的Kubernetes的config-map,可以在一个统一的服务器上进行远端多个微服务的配置的统一管理、统一更新。明文用config-map,如果重要的机密的配置可以secret。

    再接下来是我们的服务编排,deployment是实际使用过程中用户非常欢迎的一个特性。因为deployment把这个yaml文件写好之后,大家去自动部署了,需要几个副本,它会自动的去扩容以及缩容deployment。如果需要开发一个应用商店,可以去helm开发。

    再下来是我们的弹性伸缩,通过RS写好副本数,再通过auto-scaling指定需要自动伸缩的条件,比如说可以基于CPU伸缩,可以基于我们的内存访问伸缩。再下来是我们的容错,使用我们的liveness来监控我们的容器以及应用的健康状况,如果容器挂掉了,可以把它重启,如果这个节点挂掉了,那就把容器调度到另一个节点。熔断怎么做?可以用我们的readiness,readiness不但可以监控我们的容器的存活,还可以监控我们的service是否是健康的。

    限流,限流可以通过我们的quota限额,可以通过我们的namespace限额,也可以对我们的pod限额,也可以对容器限额。

    升级,rolling updates是自动升级,有问题可以一键回滚。那RBAC是可以提供基于角色的安全访问。Network policy在BGP Calico基础上提供微分段,可以很好的安全隔离,包括日志监控EFK和Prometheus。

    放在13、14之间.png


    容器云CI/CD
    如何来做容器云的CI/CD,自然使用我们的容器云三剑客,Jenkins+Docker+Kubernetes。其实在容器云出现之前,其实已经有CI/CD了,那时CI/CD用Jenkins做,Jenkins可以提供编译、构件、测试、任务调度的流水线;那Docker有什么作用?可以让我们的环境标准化,可以隔离;Kubernetes可以提供一个大的平台,可以让资源共享、弹性伸缩。


    image014.png



    图片描述CI/CD也就是需要把开发、测试流水线做一个自动化,从开发、编译、构件、测试、打包到部署,所以在我们的测试报告出来之后,如果是通过了就把镜像上传到镜像仓库,然后再发布到Kubernetes的发布平台。

    image015.png


    DevOps
    谈完CI/CD我们来看一下很火的DevOps。通过这张图我们其实就可以看出CI/CD和DevOps有什么区别,有什么联系,什么场合该用CI/CD,什么场合该用DevOps。CI/CD在左边,CI/CD最关注的是开发和测试,关注的具体的序数是什么?是Jenkins来做个流水线,是Git来做一个源代码的仓库、源代码的拉取,Maven来做构建,SonarQube来做静态的代码分析,Robotframework来做自动化的测试。SonarQube这样一个代码分析工具对我们的编译通过之外的一个保证把它良好的代码是有非常好的好处。因为我记得还是在十年前,当时在一个国内特大公司入职培训的时候,一般的导师对每位员工都会培训一个案例:代码规范。好的代码并不是通过编译就行了,而且需要好的编程规范,避免通过了编译但却其实会出现神秘的故障,而且很难定位。

    看完CI/CD,我们来看看DevOps关注什么。DevOps的关注的是我们发布的环境要自动伸缩,要A/B Test,要灰度发布,要自动的升级,或者要滚动升级,滚动升级就是指不是一次性升级完所有的pod,还是可以选择性的升级一部分,比如升级20%,或者升级50%。有什么好处?可以使我们的应用服务不中断。它们两者的共同点,当然都需要基于Docker和Kubernetes来做这样的一个容器化封装和自动化。右边的这个DevOps其实是DevOps刚出现的时候,我们叫标准的DevOps。它和CI/CD有区别,但是其实有很大的联系,CI/CD和这样的标准DevOps组合起来就叫做我们的大DevOps,所以这两者是可以结合起来,CI/CD解决我们开发、测试、自动化、标准化的问题,标准DevOps解决我们的开发运维,主要是运维方面的问题,只有这两者结合起来就可以一键式解决我们的开发、测试、运维问题,并且可以形成一个闭环。


    image016.png


    下图就是滚动升级这一功能,可以通过逐个容器替代,升级其中的25%的容器,然后再确认一下,如果工作正常,我们再可以升级其中的下一批容器。

    image017.png


    下面是灰度发布。这在我们日新月异的频繁发布的互联网场景特别有用。因为我们有大量的互联网应用。所以有一个特别好的新功能,像看看它的这个功能,看看用户的反馈,用户的使用情况怎么样,我们的灰度发布。用Kubernetes的pod非常方便。开始可以给一个灰度版本1,内部用户使用的没问题,再给一个版本2,给我们的用户群,用户群A,再逐渐的扩大到所有的用户,这是互联网非常好的应用。

    image018.png


    总结
    这里来回顾一下中国东信基于Kubernetes开发的这样四大场景。第一个是PaaS企业应用平台。第二个是Kubernetes的微服务,SpringCloud也是微服务,但SpringCloud微服务是主要关注在应用层面,而且它只是针对Java有效,对别的语言是没有的。Kubernetes是语言无关的,而且是比SpringCloud使用面更广的,但最佳的实践是可以把我们的SpringCloud的每个微服务通过容器化的方式进行封装,再通过Kubernetes进行平台的集群资源调度和自动伸缩。第三个就是我们CICD,第四个是我们的DevOps。

    如何在桌面上安装运行Rancher 2.0

    Rancher 发表了文章 • 1 个评论 • 1743 次浏览 • 2018-06-02 13:32 • 来自相关话题

    如果不能访问云基础设施怎么办?或许你希望能够像在生产环境中一样,在本地开发中使用Rancher? 没问题,把Rancher 2.0安装到电脑桌面就可以了。 在本教程中,我将带你安装Docker-for-Des ...查看全部
    如果不能访问云基础设施怎么办?或许你希望能够像在生产环境中一样,在本地开发中使用Rancher?

    没问题,把Rancher 2.0安装到电脑桌面就可以了。

    在本教程中,我将带你安装Docker-for-Desktop Edge版,启用内置的Kubernetes引擎,在桌面上运行自己的Rancher 2.0个人实例。

    先行准备
    在本教程中,要想管理和部署本地Kubernetes实例,你需要提前准备好如下工具:

    Kubectl – Kubernetes CLI工具
    Helm – Kubernetes清单目录工具

    Docker-for-Desktop
    适用于Windows/Mac的Docker CE Edge安装包中包含了基本的Kubernetes引擎。我们可以利用它来安装本地的Rancher Server。从Docker Store上就可以下载并安装它。

    Windows版:
    https://store.docker.com/edit...

    Mac版:
    https://store.docker.com/edit...

    Docker配置
    登陆Docker,右键单击System Tray中的Docker图标,并选择Settings

    Advanced Settings

    在Advanced部分将Memory增加到至少4096MB。当然你可能也想增加分配的CPUs数量和磁盘映像的最大大小(Disk image max size)。

    1.webp_.jpg


    启用Kubernetes

    在Kubernetes部分,选中复选框启用Kubernets API。Docker-for-Desktop会自动创建带有凭证的~/.kube/config文件,以便kubectl能够访问新的本地“集群”。

    如果没有看到Kubernetes部分怎么办?请检查General部分并确保你使用的是Edge版本。

    测试集群

    打开终端测试集群吧。运行kubectl get nodes。kubectl应该会返回一个名为docker-for-desktop的节点。

    2.webp_.jpg


    准备Kubernetes
    Docker-for-Desktop并没有安装任何额外的工具。我们可以将一些静态的YAML清单文件和kubectl一起使用,不过我们希望更多地利用Kubernetes社区中的已有工具,而不是重新造轮子。因此将helm作为Kubernetes首选的打包管理工具。

    helm charts为Kubernetes YAML清单文档提供了模板语法。有了helm我们可以创建能够进行配置的部署,而不是仅仅使用静态文件。有关更多创建自己的部署目录的信息,请参考https://helm.sh/上面的文档。

    在集群上初始化Helm
    Helm在你的集群上会安装tiller服务来管理chart部署。因为在默认情况下docker-for-desktop启用了RBAC,因此我们需要用kubectl创建serviceaccount和clusterrolebinding,这样tiller才能部署到我们的集群中。

    在kube-system命名空间中创建ServiceAccount

    3.webp_.jpg


    创建ClusterRoleBinding让tiller账户能够访问集群

    4.webp_.jpg


    最后使用helm初始化tiller服务

    5.webp_.jpg


    注意:tiller的安装是具有完全的集群访问权限的,可能并不适合生产环境。因此你需要多阅读helm文档,根据自己的安全性需求限制tiller的访问。

    添加Ingress Controller
    Ingress Controller用于提供从外部世界到Kubernetes中运行的服务的L7 http路由。

    我们将使用helm安装nginx-ingress chart。这将在我们本地集群上创建一个ingress controller。

    “rancher”helm chart的默认选项是使用SSL传递回Rancher服务器pod上的自签名证书。为了支持这一选项,我们需要在安装chart时添加--controller.extraArgs.enable-ssl-passthrough=""选项。

    6.webp_.jpg


    安装Rancher
    下面我们使用helm安装Rancher。

    在默认安装下将使用Rancher内置的自签名SSL证书。你可以在这里看到该helm chart的所有选项:https://github.com/jgreat/hel...

    首先将rancher-server仓库添加到helm

    7.webp_.jpg


    现在安装rancher chart

    8.webp_.jpg


    设置hosts文件
    在默认情况下,Rancher服务器将会监听rancher.localhost。如果要访问它,我们需要设置一个主机文件条目,让我们的浏览器能够解析这个名称。

    Windows
    c:windowssystem32driversetchosts
    Mac
    /etc/hosts

    编辑系统的相应文件并添加此条目

    9.webp_.jpg


    连接到Rancher
    浏览器访问到 https://rancher.localhost

    忽略SSL警告,接下来你应该就能看到Rancher的登陆界面了,需要你设置管理员密码。

    10.webp_.jpg


    恭喜你!你已经有了自己的Rancher 2.0本地实例。你可以添加应用程序charts,部署你的应用程序,一切就像在生产环境中一样。

    微信号:RancherLabs