灵雀云

灵雀云 查看完整档案

北京编辑清华大学  |  计算机 编辑Alauda  |  经理 编辑 www.alauda.cn 编辑
编辑

灵雀云Alauda成立于2014年,由原微软Azure云平台的核心创始团队创立。作为容器服务和企业级PaaS领域的领军企业,灵雀云的技术团队拥有全球领先、超大规模企业级云平台的开发、运维和管理经验,并在西雅图和北京都设有研发中心。
2017年11月,灵雀云获得由腾讯云战略领投,高榕资本、宽带资本跟投的超亿元人民币B轮融资;6个月后,又获得由英特尔投资领投,明照资本等战略投资人跟投的新一轮融资。目前在国内的容器PaaS领域,灵雀云在融资轮次、企业估值和总融资额等方面均领跑于行业。

个人动态

灵雀云 发布了文章 · 2020-10-22

利用EndpointSlices扩展Kubernetes网络,提供更强的可伸缩性和功能

EndpointSlices是一个令人兴奋的新API,它提供了Endpoints API的可扩展和可扩张的替代方案。EndpointSlice跟踪Pod服务后面的IP地址,端口,准备情况和拓扑信息。
在Kubernetes(https://www.alauda.cn/product/detail/id/240.html) 1.19中,默认情况下从EndpointSlices中通过kube-proxy读取启用了此功能,而非Endpoints。尽管这个更改看起来不起眼,但它可以使大型群集中的可伸缩性得到显著改善。它还在将来的Kubernetes版本中启用了重要的新功能,例如拓扑路由感知。
1 Eendpoints API的可扩展性限制
使用Endpoints API,一个服务只有一个Endpoints资源。这意味着它需要为支持相应服务的每个Pod存储IP地址和端口(网络端点)。这导致使用巨大的API资源。为了解决此问题,kube-proxy在每个节点上运行,并监视Endpoints资源的任何更新。如果在Endpoints资源中甚至只有一个网络端口发生更改,则整个对象也必须发送到每个实例的kube-proxy。
Endpoints API的另一个限制是,它限制了可以为服务跟踪的网络端点的数量。存储在etcd中的对象的默认大小限制为1.5MB。在某些情况下,这可能会将Endpoints资源限制为5,000个Pod IP。对于大多数用户而言,这不是问题,但是对于服务接近此大小的用户而言,这将成为一个重大问题。
为了说明这些问题的严重性,举一个简单的例子是有帮助的。考虑具有5,000个Pod的服务,它最终可能具有1.5MB的Endpoints资源。如果该列表中的单个网络Endpoints都发生了更改,则将需要将完整的Endpoints资源分配给群集中的每个节点。在具有3,000个节点的大型群集中,这成为一个很大的问题。每次更新将涉及跨集群发送4.5GB数据(1.5MB Endpoints * 3,000个节点)。这几乎足以填满DVD,并且每次Endpoints更改都会发生这种情况。想象一下,如果滚动更新会导致全部5,000个Pod都被替换-传输的数据量超过22TB(或5,000 DVD)。
2 使用EndpointSlice API拆分端点
EndpointSlice API旨在通过类似于分片的方法来解决此问题。我们没有使用单个Endpoints资源跟踪服务的所有Pod IP,而是将它们拆分为多个较小的EndpointSlice。
考虑一个示例,其中一个服务后端有15个Pod。我们最终将获得一个跟踪所有端点的单个Endpoints资源。如果将EndpointSlices配置为每个存储5个端点,我们最终将获得3个不同的端点EndpointSlices:
默认情况下,EndpointSlices每个存储多达100个端点,尽管可以使用kube-controller-manager上的--max-endpoints-per-slice标志进行配置。EndpointSlices将可扩展性提高了10倍。该API大大提高了网络可伸缩性。现在,当添加或删除Pod时,只需更新1个小的EndpointSlice。当单个Service有成百上千的Pod时,这种差异变得非常明显。
可能更重要的是,既然服务的所有Pod IP都不需要存储在单个资源中,那么我们就不必担心etcd中存储的对象的大小限制。EndpointSlices已用于将服务扩展到超过100,000个网络端点。
所有这些都与kube-proxy所做的一些重大性能改进结合在一起。当大规模使用EndpointSlices时,用于端点更新的数据将大大减少,并且kube-proxy应该更快地更新iptables或ipvs规则。除此之外,服务现在可以扩展到至少任何以前的限制的10倍。
3 EendpointSlices启用新功能
作为Kubernetes(https://www.alauda.cn/product/detail/id/240.html) v1.16中的alpha功能引入的EndpointSlices旨在在将来的Kubernetes版本中启用一些令人兴奋的新功能。这可能包括双栈服务,拓扑路由感知和端点子设置。
双栈服务是一项与EndpointSlices一起开发的令人兴奋的新功能。他们将同时使用IPv4和IPv6地址作为服务,并依靠EndpointSlices上的addressType字段按IP系列跟踪这些地址。
拓扑感知路由将更新kube-proxy,以在同一区域或区域内完成路由请求。这利用了为EndpointSlice中的每个端点存储的拓扑字段。作为对此的进一步改进,我们正在探索端点子集的潜力。这将允许kube-proxy只观看EndpointSlices的子集。例如,这可以与拓扑路由感知结合使用,以便kube-proxy仅需监视包含同一区域内端点的EndpointSlice。这将提供另一个非常重要的可伸缩性改进。
4 这对Endpoints API意味着什么?
尽管EndpointSlice API为Endpoints API提供了更新和更可扩展的替代方案,但是Endpoints API将继续被认为是普遍可用且稳定的。为Endpoints API计划的最重要的更改将涉及开始截断Endpoints,否则将遇到可伸缩性问题。
Endpoints API并没有消失,但是许多新功能将依赖于EndpointSlice API。为了利用EndpointSlices提供的新的可伸缩性和功能,当前使用Endpoints的应用程序可能在将来考虑支持EndpointSlices。
原文链接:
Scaling Kubernetes Networking With EndpointSlices
https://kubernetes.io/blog/202 ... ices/
作者: Rob Scott(Google)
译者:刘博(资深云计算售前架构师)

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-09-28

使用Crossplane构建专属PaaS体验:Kubernetes,OAM和CoreWorkflows

关键点:
•许多组织的目标是构建自己的云平台,这些平台通常由内部部署架构和云供应商共建完成。
•虽然Kubernetes没有提供开箱即用的完整PaaS平台式服务,但其具备完整的API,清晰的技术抽取和易理解的扩展性,可以让其他的完备功能组件在其上运行。
•Crossplane是一个开源的云控制组件,让工程师能够直接通过Kubernetes管理一些基础架构或者云服务。该控制组件为用户提供了唯一的交互入口,通过该入口可以实现策略下发、安全防护以及实施审计。
•可以使用K8s资源自定义(CRD)和YAML配置基础结构,也可以通过建立工具(如kubectl)或Kubernetes API本身对其进行管理,作为工作流的最佳实践(如GitOps)。
•开源应用程序模型(OAM)描述了核心软件交付角色,定义了清晰的职责:开发人员,应用操作人员和基础架构人员。Crossplane是规范Kubernetes最佳实现。
近期,InfoQ访谈了Upbound的创始人兼首席执行官Bassam Tabbara,探讨了如何跨多个云和基础架构来构建应用平台。
这个话题的前提条件是每一个软件提供商将应用程序部署到一个平台上,他们是否愿意使用这个平台。当前Kubernetes作为许多“云原生”架构的基础平台,虽然Kubernetes并未提供开箱即用的完整平台式服务(PaaS)体验,但其具备完整的API,清晰的技术抽取和易理解的扩展性,可以让其他的完备功能组件在其上运行。
Tabbara 表示Crossplane这个开源项目,让工程师可以直接在Kubernetes上管理任何基础架构或云服务。这种“跨云的控制组件”是构建在Kubernetes(https://www.alauda.cn/product/detail/id/240.html)原生配置声明上,它允许工程师定义架构以利用现有的K8s工具链。访谈也提到了开源应用程序模型(OAM),探讨了Crossplane如何成为以团队为中心的基于Kubernetes构建云原生应用的最佳实践。
1 每个工程团队都需要一个平台
许多公司的目标是打造自己的云平台,通常都是通过自己部署基础架构或云供应商组建。这些公司的领导认识到,降低部署过程中的冲突,缩短交付时间,以及提供稳定和安全,可以提升自身的竞争优势。同时,他们还认识到,任何成功的企业通常都需要将现有的“资产”应用程序和基础架构构建在一个公共的平台上。许多公司还希望平台支持多个云供应商,避免被一家绑定以寻求降低成本,和跨供应商实施容灾。
平台团队也希望为应用开发和操作人员提供自助服务。但是,也要考虑平台如何兼容安全性、合规性和法规要求。所有大型公共云供应商,像Amazon Web Service(AWS),Microsoft Azure和Google Cloud Platform(GCP)都是通过控制组件提供类似服务的。该控制组件包含用户交互(UI),命令行交互(CLI)和程序接口(API),让平台团队和操作人员可以完成基于底层基础数据的配置和部署。尽管云控制组件采用的是典型的全局分布模式,但最终呈现给用户的是集中展现。该控制组件为用户提供了唯一的交互入口,通过该入口可以实现策略下发、安全防护以及实施审计。
正如Zimki,Heroku和Cloud Foundry这样的先驱组织一样,应用程序开发人员非常希望获得类似平台即服务(PaaS)的经验来定义和部署应用程序。部署一个新的应用只需要通过简单的“git pushheroku master”,毫不费力就能完成。应用操作人员和SRE团队希望能够轻松的构建、运行和维护应用或者是完成各自的管理配置。
Tabbara 提示到,如果组织选择不当,这些需求会让组织花费昂贵的成本来维护PaaS:“现代商业PaaS常常满足组织80%的要求,这就意味着基础架构团队需要创建额外的平台资源来满足其他20%的要求。”
2 构建PaaS平台的体验
构建PaaS平台不是一件容易的事。需要花费时间和探究技术,考虑如何将所有相关角色的需求抽取为技术实现。著名的Google公司有上千名训练有素的工程师打造这个平台,Netflix也拥有庞大的专家团队专注于内部PaaS平台的构建与维护,甚至像Shopify这样的小公司也有专门的PaaS平台团队。抽取的技术实现范围很广,从Libcloud和OpenStack 提供大众化的功能,到通常的工作流,甚至像HashiCorp的Terraform或Pulumi这样完整的云特定配置组件。传统的PaaS抽取的技术实现在云领域也很常见,典型的如GCP的App Engine,AWS的ElasticBeanstalk或Azure的Service Fabric。
许多公司正在选择以Kubernetes为基础构建平台。不管怎样,正如Tabbara在Twitter提示的那样,这可能需要大量的前期投入,再加上80%用户场景挑战,这可能导致“PaaS困境 ”:
“PaaS的困境就是您的PaaS完成了想要的80%需求,我就需要花费80%的时间来维护kubernetes。”
Tabbara表示,开源Crossplane项目旨在成为一种通用的多云控制组件,用于构建一种定制化的PaaS式体验。
Crossplane是“cross”云控制“plane”的融合。我们想用这个名字来表示连接不同云提供商并充当跨连接的控制组件。Cross表示“跨云”,plane增加“控制水平”。
通过构建在被大家广泛应用的Kubernetes(https://www.alauda.cn/product/detail/id/240.html)原生样式基础上进行配置,提供现成的基础架构组件和注册共享其他资源两种方式,这样就减轻了基础架构和应用程序操作员的负担。另外,通过提供一套完整的API,封装了关键基础架构技术抽取,可以分离平台操作员(不依赖“API”工作的)和应用程序开发、操作员(依赖“ API”工作的)关注点。
“开发人员只需关注工作负载,而不必担心实现细节、环境约束或者策略。管理员可以定义环境细节和策略。这就可以实现更高的可重用性,降低复杂度。”
3 Crossplane:通过Kubernetes控制基础架构
Crossplane作为Kubernetes附加组件的实现方式,通过提供和管理云基础架构、服务和应用程序来扩展集群能力。Crossplane使用Kubernetes的样式声明、API驱动配置和管理来控制本地或云的基础架构。通过这种方法,可以使用资源自定义(CRD)和YAML来配置基础架构,也可以通过建立工具(如kubectl)或Kubernetes API本身对其进行管理。使用Kubernetes还允许通过RBAC或Gatekeeper的开放策略代理(OPA)来定义安全控制。
作为Crossplane安装的一部分,Kubernetes资源控制器对资源的整个生命周期进行管理,负责准备、健康检查、扩展、故障转移、以及积极响应偏离所需配置的外部变化。Crossplane整合了持续交付(CD)流水线,可以使应用的基础架构配置储存在单个控制集群中。团队可以使用像GitOps等云原生CD最佳实践来创建,跟踪和审批更改。Crossplane让应用程序和基础架构配置共存在同一个Kubernetes集群上,从而降低了工具链和部署流水线的复杂性。

PIC1.jpg

通过OAM模型,展现了整个工作情况,清晰的技术抽取、对不同角色的使用,以及“线上线下”处理方式。
4 OAM:以团队为中心标准化构建云原生的应用
开放应用程序模型(OAM)规范最初由Microsoft,阿里巴巴和Upbound创建,它定义了一个模型,开发人员负责定义应用程序组件,应用程序操作员负责创建这些组件的实例并为其配置,而基础架构操作员则是负责声明,安装和维护平台上可用的基础服务。Crossplane是规范Kubernetes的最佳实现。
使用OAM,平台构建者可以以Components,Traits和Scopes的格式提供可重用的模块。允许平台将它们打包在预定义的应用程序配置文件中。用户可以通过选择配置文件来选择如何运行其应用程序,例如,高服务水平目标(SLO)要求的微服务应用程序,拥有持久卷的有状态应用程序或具有自动扩缩容的事件驱动功能。
在OAM规范介绍文档中,描述了一个典型的应用交付生命周期实践的例子。
1、开发人员创建一个Web应用程序;
2、应用程序操作员部署该应用程序的实例,并为其配置操作特性,像自动扩缩容等;
3、基础架构人员决定基于哪种技术来完成部署和操作。
为了交付应用程序,应用程序开发人员将程序的每个单独组件用YAML定义。该文件封装了工作负载以及运行它所需的信息。
为了运行和操作应用程序,应用程序操作员为组件设置参数,并在应用配置的YAML中定义,例如副本数,自动扩缩容策略,入口点和流量路由规则。在OAM中,这些操作特性称为特征,编写在部署应用配置文件中,用于部署应用程序。底层平台根据工作负载和应用配置文件定义的操作特征进行创建。
基础架构人员负责声明,安装和维护平台上可用的基础服务。例如,基础架构人员可能会选择特定的负载均衡器来暴露服务,或者完成一个数据库配置来确保数据全局范围内进行加密和复制。
5 探索典型的Crossplane工作流程
为了使讨论更加聚焦,让我们探索一个典型的Crossplane工作流程,从项目的安装到使用。
首先,安装Crossplane并创建一个Kubernetes集群。接下来,安装提供程序并配置凭据。原生架构可以从预分配的提供商获得(例如GCP,AWS,Azure,Alibaba或者是用户自己建立的基础设施。)
平台操作员使用YAML 定义声明,组合和发布自己的基础架构资源,从而将自己的基础架构CRD添加到Kubernetes API中以供应用程序使用。
应用程序开发人员发布应用程序组件,表明服务必须的、建议的或者是可选的需求,以及基础架构需求。
应用程序操作员将基础架构和应用程序组件,通过定义配置关联在一起,然后运行该应用程序。
6 小结
Kubernetes(https://www.alauda.cn/product/detail/id/240.html)是许多“云原生”平台构建的基础,因此,团队与平台交互和集成底层组件,这两个模型对于公司是至关重要的,并且具有潜在的竞争优势。正如Nicole Forsgren博士等在Accelerate中所述,高绩效组织是能够缩小交付周期和增加部署频率的。正是与此,平台起着至关重要的作用。
Crossplane是一个不断发展的项目,随着社区的扩展,希望看到越来越多的反馈意见。工程师们可以访问Crossplane网站来使用这个开源项目,也可以在Crossplane Slack中共享反馈情况。

原文作者:Daniel Bryant(infoQ)
译者:赵淳

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-09-25

第三届全球云原生技术实践峰会(CNBPS 2020)提案征集CFP开启!

image

第三届云原生技术实践峰会(CNBPS 2020)来了!这是云原生领域一年一度的科技盛会,众多云原生业内“顶流”将聚集于此,展现云原生世界的科技想象力和落地成果。
云原生技术实践峰会(CNBPS)由云原生技术实践联盟(CNBPA)主办,始自2018年,至今已举办两届。当业内还在疑惑云原生究竟为何物时,CNBPS领行业之先,探讨云原生技术创新和应用实践。如今,CNBPS是业内最富影响力的云原生技术盛会之一,已成为云原生领域的标杆会议品牌,每年峰会都会聚集云原生先锋力量和典型客户,并带来持久的话题影响力。
1 CNBPS 2020关键词
关键词1:全球
今年的CNBPS 2020视野将更加开阔,我们把目标投向了全球。除了往年出席的国内知名技术厂商、咨询公司、生态伙伴、行业客户之外,我们还将持续邀请国内外云原生相关领域的技术大咖、意见领袖以及客户代表,一起来探讨云原生技术趋势,展现全球客户面对数字化业务的应用创新实践。
关键词2:全栈
本次峰会议题范围也更加广泛,不再局限于容器/Kubernetes、DevOps、微服务云原生黄金三角的探讨,还将拓展到与云原生相关的其他技术领域,尝试对云原生基础设施、云原生开发流程、云原生应用架构、数据服务、开源等方向的技术趋势、技术创新、应用实践进行解读。无论你是开发者、架构师、运维人员,还是企业IT主管,总能找到你感兴趣的内容。
关键词3:全渠道
本届 CNBPS2020 将通过线上+线下全渠道形式举办。11月,让我们突破时空的界限,云端相见!
2 现面向全球征集演讲议题
目前CNBPS 2020处于大会筹备阶段,数场平行论坛,开放数十个演讲时段。提案征集(Call for Proposals,CFP)正式开启,欢迎大家提交议题!
重要日期:
提案征集开放:9月21日
提案征集截止:10月17日
提案征集通知:10月27日
会议日程通告:11月5日
议题方向:
CNBPS 2020 主题是“1+X”。1为容器,围绕容器所建立的云原生基础设施、云原生开发流程、云原生应用架构、数据服务等领域的最新技术趋势、技术创新、应用实践都是本次峰会非常欢迎的议题(这是一场社区会议,请尽量避免推销产品)。
演讲嘉宾:
1、对云原生相关领域技术方向(如容器/Kubernetes、DevOps、微服务、Serverless、中间件、数据库、存储、网络等)有实际开发、运维等经验;
2、对云原生技术的某个技术点有突破与创新,或有深刻见解;
3、有过线上线下峰会、Meetup、技术沙龙、workshop等分享经验为佳(非必须);
提案撰写可参考如下内容:
1、为何要发表此演讲?
2、希望观众从演讲中收获什么?
3、说明此主题与云原生技术的关联。
峰会旅程即将开启,
会议联系:
商务合作:付女士 13717573070(同微信)
媒体/社区合作:张女士 13810533842(同微信)

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-09-21

灵雀云开源网络插件Kube-OVN 1.4.0 版发布!支持跨集群容器网络、NetworkPolicy 日志

从 1.4 开始 Kube-OVN 支持将多个 Kubernetes 集群容器网络打通,不同集群之间的 Pod 可以通过 Pod IP 直接互相通信。本版本还支持 ACL 日志,可以记录因 NetworkPolicy 而丢弃的数据包的数量和原因。本版本还更新了相关依赖并对性能进行了提升,欢迎使用。
1 新功能
•集成 OVN-IC 支持跨集群网络
•启用 ACL 日志记录 NetworkPolicy 触发情况
•NodePort 类型 Service 访问本地 Pod 的源 IP 保留
•支持 vlan 网关类型的动态调整
2 问题修复
•增加 Forward Accept 规则
•修复 kubectl-ko 寻找网卡问题
•修复subnet更新冲突问题
•修复subnet acl 重叠问题
修复 session lb 丢失问题
3 其他改进
•升级 ovs 至 2.14
•升级 golang 至 1.15
•日志级别调整
•增加 psp 规则
•删除 juju 依赖
4 Kube-OVN企业版开启限时免费试用!
事实上,社区版和企业版是共生的关系。Kube-OVN社区版已经集结了大量社区开源贡献者的智慧,汇聚了顶尖的技术,Kube-OVN企业版的诞生,受益于大量社区用户创建的生态,而Kube-OVN社区版又将受益于企业版的不断改进。免费试用地址(https://www.alauda.cn)

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-08-26

Lyft 宣布开源基础设施工具管理平台 Clutch!

今天我们很高兴地宣布,Lyft 的基础设施工具可扩展 UI 和 API 平台clutch已开放源代码,clutch使工程团队能够构建、运行和维护用户友好的工作流,这些工作流还包含特定于域的安全机制和访问控制。clutch兼容多种管理平台功能(如 AWS、Envoy和 Kubernetes),强调可扩展性,因此它可以为堆栈中任何组件提供托管功能。

PIC1.png

云计算的动态属性显著地降低了新基础设施的采用成本。CNCF云原生计算基金会全景图跟踪了300多个以上开源项目和1000多个商业产品。尽管各组织们能快速采用这些项目和供应商,但每种新技术都有它自带的一套配置、工具、日志和指标。为了让开发者快速、安全地在整个堆栈中变更,需要在工具方面进行大量前期和持续的投资,而大多数组织都未能考虑到这一点。所以,虽然新基础设施越来越容易采用,但日益扩大的新组件的规模难以管理,特别是随着整个平台的复杂性和工程团队规模的增长。Clutch解决了这一难题,通过让基础设施团队向他们整个工程组织提供直观和安全的基础设施管理接口。

Clutch是一年开发周期的成果,用来解决“Lyft”开发人员经验和工具的短板。Clutch由两个核心部件组成。go后端设计为可扩展的基础设施控制平面,将单个由protobuf驱动的API拼凑成具有通用授权,可观测性和审计日志记录的系统。React前端是一个可插拔并且面向工作流的UI允许用户和开发者在单个窗格后创建新功能,这只需要很少的代码和很少的JavaScript知识及更少的维护工作。

1 设计和架构

在设计和架构方面,比起其他解决方案,clutch提供了与众不同的开发人员工具空间。在项目开始时,我们在构建自己的工具前对现有工具做了深入分析。采用工具的主要目的是:

•减少平均维修时间。基础设施什么时候响应告警,工程师们待命时花太多时间在阅读runbooks和操作复杂的工具。

•消除意外中断。当执行维护任务时,当用户在使用runbook时漏掉警告或者删除错误的资源(例如,他们认为没有使用,但占用了很大流量的资源),从而导致严重中断。

•强化细粒度的权限并以通用格式审计所有活动,一些权限过于宽泛,是因为供应商的访问控制不支持细粒度控件,此外,当我们出于安全目的从各种工具收集审计日志时,很难将那些数据提炼成为如何帮助我们改善工具的可执行见解。

•提供一个极大简化未来工具开发的平台。以“Lyft”这样的规模,如果不考虑团队外的贡献资源,项目范围很大时很难成功,我们没有足够的资源来构建Lyft需要的每一个特性,更别说支持它了。

一开始我们看到现有供应商UI的不足:由于缺乏专业化,供应商工具很慢 (并且在某些情况下是危险的)。他们需要不必要的步骤来执行常见任务,并提供超出必要的信息集。除了简单的访问控制外,通常很少有防护,结果导致运营人员可能会执行看似无害但实际降低系统性能的操作。另外,他们也许不太熟悉该工具从而延误补救。理想情况下,工程师每四到六周只来一次。人们很容易忘记如何使用这个工具,特别是考虑到没有用特定的交互系统情况下,又去多种执行任务。

由于碎片化和信息杂乱无序,依赖供应商工具的后果是高认知负荷。

相比之下,Clutch这样一个与供应商无关的工具能将不相关的系统一体化为清晰,一致的用户体验,并且提供专用功能来执行常见任务,只需很少的点击和培训。

然后我们转向开源社区,发现开源基础设施管理工具通常仍然局限于单个系统,并不是为广泛的自定义设计的,它并不能解决认知负荷和碎片化的问题。此外,虽然有用于构建控制台的其他前端框架,但没有一个框架包含具有身份验证,授权,审计,可观察性,API模式和丰富插件模型的集成后端框架。有一个很流行的持续交付平台,它解决了与Clutch相同的首要问题(例如,降低MTTR,用户友好的UI)但是,它需要大量的投入来运行微服务和迁移应用到不同于我们自己的架构上。Clutch后端功能开发简化,是通过上面列出的集成核心功能为每个API端点免费。它还开发为单个二进制文件,只需要很少的操作投入。

最后,我们想要一个平台,可以对它进行投资,对其他内部团队来说它需要更容易理解和构建。Clutch提供一个集成的和引导式开发模型,使其功能开发成为简明直接的过程。除了一流的后端功能外,Clutch 的前端还为状态管理和多步表单提供了独特的抽象,没有大量JavaScript 经验的基础架构团队更容易实现前端开发。

2 特性

"控制平面"模型

Envoy 代理是Lyft创建的。如今,它是最受欢迎的代理之一,部署在许多大型互联网公司,并不断推进云网络标准。我们的团队从与大社区一起维护Envoy中学到了很多东西。Envoy用户讨论的最热门主题之一是控制平面的开发进展,特别是如何系统地集成各种不同的组件,以便Envoy能够有效地路由和报告网络流量。Envoy类似于 Clutch,它集成不同的基础设施系统于统一的API。

PIC2.png

Clutch采用了许多envoy代理的核心模式,这些模式是在网络控制平面多年的工作中脱颖而出的。

像Envoy 一样,Clutch 是配置驱动、模式驱动的,并利用基于模块化扩展的架构,使其适用于各种用例,同时不影响可维护性。扩展Clutch不需要分支或重写,自定义代码可以很容易地从自定义公共或私有外部存储库编译到应用程序中。这些相同模式使具有独特技术堆栈的大小组织能够聚集在单个代理解决方案上,有望使相似的独特组织聚焦在Clutch这样的基础设施控制平面上。

3 安全和保障

此外,Clutch附带身份验证和授权组件。OpenID Connect (OIDC) 身份验证流用于单点登录、RBAC,以及对所有操作的自动审核,并能够运行附加的输出接收器,例如Slackbot。

PIC3.png

Clutch 还具有降低事故风险的功能。通常记录在 Runbook 中的护栏和启发式方法可以以编程方式实现。例如,我们绝不允许用户一次将群集缩减 50% 以上,因为这种操作曾经导致过正常维护时的意外中断。不久以后,我们计划获取CPU 和其他使用数据,以便与群集信息一起显示,甚至在确定可能导致停机的情况下,限制缩小规模的下限。通过将护栏和启发式方法直接实施到工具中,避免了仅仅依靠于培训和运行手册来防止事故的发生。

4 部署和用户引导

Clutch作为包含前端和后端的单个二进制文件进行传输,使部署工作变得很简单。许多更改可以通过配置实现,而不是重新编译新的二进制文件。

提供基础设施生命周期工具的其他系统,则需要一组复杂的微服务或迁移到一种固有的方式管理和部署应用程序。Clutch旨在完善现有系统,而不是更换它们。

5 框架和组件

Clutch由Go后端和React前端驱动。它为后端和前端开发提供了功能齐全的框架。Clutch的所有组件都是可组合的,允许使用部分框架功能或完全自定义功能。

这样的组件和工作流体系结构让前端经验有限的开发人员在不到一个小时的开发时间内,就能使用清晰且易于使用的分步 UI 替换笨重的工具或命令行脚本。

Clutch的前端封装提供的组件,可轻松构建一致且连续用户体验的分步工作流程,包括:

•DataLayout:是一个工作流-本地状态管理控件,用于处理来自 API 调用的用户输入和数据。

•Wizard:用于向用户显示分步表单,自定义元素的 UI 插件,用于在以最少的代码以一致的方式显示丰富的信息。

•Clutch的后端重度依赖从ProtobufAPI 定义生成的代码。

Protobuf 工具还生成前端客户端,随着 API 的发展,该客户端保持后端和前端的同步。后端的组件包括:

•模块:代码生成的 API 存根的实现

•服务:用于与外部数据源交互

•中间件:用于检查请求和响应数据以及应用审核、授权等。

•解析器:一种基于自由格式文本搜索或结构化查询查找资源的通用接口

解析器是一个Clutch抽象,我们希望会对将功能抽象到多个组织的方式产生重大影响。解析器使用自定义资源位置代码可轻松扩展,允许操作员通过组织习惯的通用名称(而不是普通的规范标识符)定位资源(如 K8s pod 或 EC2 实例)。例如,如果开发人员称其应用程序为"myService-staging",则很容易添加一种将此类查询解释为结构化元素的代码"$application\_name=-${environment}"。此外,前端自动从后端定义生成用户输入表单。

前端有一行代码:
1

<Resolver type="clutch.aws.ec2.v1.Instance" />

渲染的表单如下:

PIC4.png

在后端配置额外的搜索维度,将会自动映射在前端渲染表单。

6 Clutch在Lyft公司

PIC5.png

在 Clutch 之前,Lyft 工程师依靠一系列大杂烩式命令行工具、Web 接口和 Runbook 来执行简单的任务。Lyft 最常见的警报需要解决多达六个不同的信息源:警报、其他服务仪表板、Runbook、其他文档源、供应商控制台或脚本以及配置设置。随着 Lyft 在团队、产品和堆栈方面进行扩张,我们意识到这些工具没有跟上步伐。我们用现有的框架解决这些问题没有出路,这导致了Clutch的第一个迭代开发。

在过去的一年里,Clutch 在使用和开发方面拥有令人难以置信的内部采用率。Clutch经受住了数千个与基础设施管理相关的风险操作,每一个操作都有带来意外或延迟的可能,导致用户失去对我们的信任。

在撰写本文时,七个内部工程团队已经计划到 2020 年底添加新功能,其中至少一半面向开源。工程师(包括我们出色的实习生)在有限的指导下能够开发出有意义的功能。最重要的是,我们终于能够看到一条路线,通过单一虚拟管理平台交付我们的内部平台,使 Lyft 基础设施成为满足客户需求的一个产品,而不是拼凑的系统和工具集合。

我们在内部收到了很多积极的反馈,例如:

"我很满意它的存在, 否则我将仍然在等待选项卡加载到云提供商的控制台中。

有关 Lyft Clutch的更多细节,可以在 Lyft 案例研究文章中找到。

7 路线图

在整个构建Clutch的过程中,产品不断发展,我们的内外部路线图目前包含了 Lyft 的全体开发人员经验。我们的长期愿景是构建一个情景感知开发者门户,不仅向开发者提供一套工具,而且在用户登录门户时提供最有价值的工具和信息。

即将推出的功能包括:

Envoy UI,为用户提供一个实时仪表盘,以监视其分布式应用程序的网络性能和配置。
混沌测试,与Envoy集成来允许预定的故障注入和挤压测试与自动停机条件。自动修正,通过适当的Clutch操作自动响应警报。
安全增强,包括性能升级、考察模态和两阶段审批。
附加的基础设施生命周期管理功能,查看群集的状态以查找异常值,执行长时间运行的维护任务。
服务健康状况仪表板,使用可配置的报告机制向开发者提供有关其服务状态的反馈(例如代码覆盖率、成本、活跃的突发事件)。
通用配置管理,允许用户通过引导式 UI 管理复杂配置,或以其他方式将基础结构中的变更反映为代码声明。
拓扑图,将用户与其拥有的服务关联,并在登陆页上向他们显示相关的数据和工具。

作者:Daniel Hochman & DerekSchaller

译者:时间

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-08-21

Kong 微服务网关在 Kubernetes 的实践

本文主要介绍将 Kong 微服务网关作为 Kubernetes 集群统一入口的最佳实践,之前写过一篇文章使用 Nginx Ingress Controller 作为集群统一的流量入口:使用 Kubernetes Ingress 对外暴露服务,但是相比于 Kong Ingress Controller来说,Kong 支持的功能更加强大,更适合微服务架构:

◾拥有庞大的插件生态,能轻易扩展 Kong 支持的功能,比如 API 认证,流控,访问限制等;

◾Kong 服务本身和 Admin 管理 API 都集成在一个进程,通过端口区分两者,简化了部署的复杂度;

◾Kong 节点的配置统一持久化到数据库,所有节点通过数据库共享数据,在 Ingress 更新后能实时同步到各个节点,而 Nginx Ingress Controller 是通过重新加载机制响应 Ingress 更新,这种方式代价比较大,可能会导致服务的短暂中断;

◾Kong 有成熟的第三方管理 UI 和 Admin 管理 API 对接,从而能可视化管理 Kong 配置。

本文先介绍 Kong 微服务网关在 Kubernetes 的架构,然后进行架构实践,涉及到的话题有:

1 Kong 微服务网关在 Kubernetes 的架构

Kubernetes 简化了微服务架构,以 Service 为单位,代表一个个微服务,但是 Kubernetes 集群整个网络对外是隔离的,在微服务架构下一般需要一个网关作为所有 API 的入口,在 Kubernetes 中架构微服务同样也需要一个网关,作为集群统一的入口,作为服务消费方和提供方的交互中间件。Kong 可以充当这一网关角色,为集群提供统一的外部流量入口,集群内部 Service 之间通信通过 Service 名称调用:

那么 Kong 是如何在 Kubernetes 集群上跑起来?具体机制是什么样的?

Kong 作为服务接入层,不仅提供了外部流量的接收转发,而且其本身还提供了 Admin 管理 API,通过 Admin 管理 API 实现 Kong 的路由转发等相关配置,这两项功能都是在一个进程中实现。

在 Kubernetes 中 Kong 以 Pod 形式作为节点运行,Pod 通过 Deployment 或者 DaemenSet 管理。所有 Kong 节点共享一个数据库,因此通过 Admin API 配置,所有节点都能同步感知到变化。既然 Kong 以 Pod 的形式运行在 Kubernetes 集群中,那么其本身需要对外暴露,这样外部流量才能进来,在本地可以 nodePort 或者 hostNetwork 对外提供服务,在云平台一般通过 LoadBalancer 实现。一般的部署最佳实践是将 Kong 的 Admin 管理功能独立出来一个 Pod,专门作为所有其他节点的统一配置管理,不对外提供流量转发服务,只提供配置功能,而其他 Kong 节点专门提供流量转发功能。

说一说 Kong Ingress Controller:其实没有 Kong Ingress Controller 也完全够用,其存在的意义是为了实现 Kubernetes Ingress 资源对象。我们知道 Ingress 只不过是定义了一些流量路由规则,但是光有这个路由规则没用,需要 Ingress Controller 来将这些路由规则转化成相应代理的实际配置,比如 Kong Ingress Controller 就可以将 Ingress 转化成 Kong 的配置。与 Nginx Ingress Controller 不同,Kong Ingress Controller 不对外提供服务,只作为 Kubernetes Ingress 资源的解析转化服务,将解析转化的结果(Kong 的配置:比如 Service、Route 实体等)通过与 Kong Admin API 写入 Kong 数据库,所以 Kong Ingress Controller 需要和 Kong Admin API 打通。所以当我们需要配置 Kong 的路由时,既可以通过创建 Kubernetes Ingress 实现,也可以通过 Kong Admin API 直接配置。

2 Helm 部署 Kong

说明:本地集群部署,为了方便 Kong Proxy 和 Kong Admin 没有独立开,共用一个进程,同时提供流量转发和 Admin 管理 API。

使用 Helm 官方 Chart:stable/kong[3],由于我是在本地裸机集群部署,很多云的功能不支持,比如:LoadBalancer、PV、PVC 等,所以需要对 Chart 的 values 文件做一些定制化以符合本地需求:

1、由于本地裸机集群不支持 LoadBalancer,所以采用 nodePort 方式对外暴露 Kong proxy 和 Kong admin 服务,Chart 默认是 nodePort 方式,在这里自定义下端口:Kong proxy 指定 nodePort 80 和 443 端口,Kong Admin 指定 8001 端口:Values.proxy.http.nodePort: 80 Values.proxy.tls.nodePort: 443, Values.admin.nodePort: 8001;

注意:默认 Kubernetes nodePort 端口范围是 30000~32767,手动分配该范围之外的端口会报错!该限制可以调整,具体见之前文章:《Kubernetes 调整 nodePort 端口范围[4]》。

2、启用 Kong admin 和 Kong proxy Ingress,部署时会创建相应的 Ingress 资源,实现服务对外访问:Values.admin.ingress.enabled: true, Values.proxy.ingress.enabled: true,另外还得设置对外访问的域名(没有域名的话可以随便起个域名,然后绑 /etc/hosts 访问):Values.admin.ingress.hosts: [admin.kong.com], Values.proxy.ingress.hosts: [proxy.kong.com];

3、作为练习,为了方便,Kong admin 改用监听 HTTP 8001 端口:Values.admin.useTLS: false, .Values.admin.servicePort: 8001, .Values.admin.containerPort: 8001。另外也需要将 Pod 探针协议也改为 HTTP:Values.livenessProbe.httpGet.scheme: HTTP, Values.readinessProbe.httpGet.scheme: HTTP;

4、Kong proxy Ingress 启用 HTTPS,这样后续 kong 就可以同时支持 HTTP 和 HTTP 代理了,这里展开下具体过程:

创建 TLS 证书:域名为 proxy.kong.com:

openssl req -x509 -nodes -days 65536 -newkey rsa:2048 -keyout proxy-kong.key -out proxy-kong.crt -subj "/CN=proxy.kong.com/O=proxy.kong.com"

使用生成的证书创建 Kubernetes Secret 资源:

kubectl create secret tls proxy-kong-ssl --key proxy-kong.key --cert proxy-kong.crt -n kong

编辑 values 文件启用 Kong Proxy Ingress tls,引用上面创建的 Secret:Values.proxy.ingress.tls:

- hosts: - proxy.kong.com
  secretName: proxy-kong-ssl

5、启用 Kong Ingress Controller,默认是不会部署 Kong Ingress Controller:ingressController.enabled: true;

6、由于本地裸机环境不支持 PV 存储,所以在部署时禁用 Postgres 数据持久化:helm 安装时指定 –set postgresql.persistence.enabled=false,这样 Postgres 存储会使用 emptyDir 方式挂载卷,在 Pod 重启后数据会丢失,本地自己玩的话可以先这么搞。当然要复杂点的话,可以自己再搭个 nfs 支持 PV 资源对象。

定制后的 values 文件在这里:https://raw.githubusercontent. … s.yml

Helm 部署:

helm install stable/kong --name kong --set postgresql.persistence.enabled=false -f https://raw.githubusercontent... --namespace kong

验证部署:

[root@master kong]# kubectl get pod -n kong NAME                                   READY   STATUS      RESTARTS   AGE
kong-kong-controller-76d657b78-r6cj7 2/2 Running 1 58s kong-kong-d889cf995-dw7kj 1/1 Running 0 58s kong-kong-init-migrations-c6fml 0/1 Completed 0 58s kong-postgresql-0 1/1 Running 0 58s [root@master kong]# kubectl get ingress -n kong NAME              HOSTS            ADDRESS   PORTS     AGE
kong-kong-admin   admin.kong.com 80 84s kong-kong-proxy   prox.kong.com 80, 443 84s

curl 测试试:

[root@master kong]# curl -I http://admin.kong.com HTTP/1.1 200 OK Content-Type: application/json ... [root@master kong]# curl http://proxy.kong.com {"message":"no Route matched with those values"

}

3 部署 Konga

上面已经将整个 Kong 平台运行在了 Kubernetes 集群,并启用了 Kong Ingress Controller,但是目前做 Kong 相关的路由配置只能通过 curl 调 Kong Admin API,配置起来不是很方便。所以需要将针对 Kong 的 UI 管理服务 Konga 部署到集群,并和 Kong 打通,这样就可以可视化做 Kong 的配置了。由于 Konga 的部署很简单,官方也没有 Chart,所以我们通过 yaml 文件创建相关资源。

为了节省资源,Konga 和 Kong 共用一个 Postgresql,Konga 和 Kong 本身对数据库资源占用很少,所以两个同类服务共用一个数据库是完全合理的。下面为 Kubernetes 资源文件,服务对外暴露方式为 Kong Ingress,域名设为(名字随便起的,绑 host 访问):konga.kong.com:

数据库密码在前面安装 Kong 时 Chart 创建的 Secret 中,获取方法:

kubectl get secret kong-postgresql -n kong -o yaml | grep password | awk -F ':' '{print $2}' | tr -d ' ' | base64 -d

konga.yml
apiVersion: extensions/v1beta1
kind: Deployment metadata: labels: app: konga
name: konga
spec: replicas: 1 selector: matchLabels: app: konga
strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate template: metadata: labels: app: konga
spec: containers: - env: - name: DB_ADAPTER
      value: postgres - name: DB_URI
      value: "postgresql://kong:K9IV9pHTdS@kong-postgresql:5432/konga_database" image: pantsel/konga
    imagePullPolicy: Always name: konga
    ports: - containerPort: 1337 protocol: TCP
  restartPolicy: Always --- apiVersion: v1
kind: Service metadata: name: konga
spec: ports: - name: http
port: 1337 targetPort: 1337 protocol: TCP
selector: app: konga --- apiVersion: extensions/v1beta1
kind: Ingress metadata: name: konga-ingress
spec: rules: - host: konga.kong.com
http: paths: - path: / backend: serviceName: konga
      servicePort: 1337

kubectl 部署 Konga:
kubectl create -f konga.yml -n kong

部署完成后绑定 host 将 konga.kong.com 指向集群节点 IP 即可访问:

接下来随便注册个账号,然后配置连接到 Kong Admin 地址,由于都在集群内部,所以直接用 Kong Admin 的 ServiceName 端口号连就可以:

连接没问题后,主页面会显示 Kong 相关的全局信息:

4 示例:通过 Konga 配置对外访问 Kubernetes Dashboard

之前我们基于 Nginx Ingress Controller 对外暴露 Kubernetes Dashboard,现在我们基于集群中 Kong 平台配置对外访问,通过 Konga 可视化操作。

通过 Konga 配置服务对外访问只需要两步:

1.创建一个对应服务的 Service(不是 Kubernetes 的 Servide,是 Kong 里面 Service 的概念:反向代理上游服务的抽象);

2.创建对应 Service 的路由。

下面以配置 Kubernetes dashboard 服务对外访问为例,对外域名设为 dashboard.kube.com(名字随便起的,绑 host 访问)。

创建 Kong Service:

创建服务路由:

配置完成,浏览器测试访问:https://dashboard.kube.com

 

来源:分布式实验室
译者:qianghaohao

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-08-18

微软开源Kubernetes服务网格项目Open Service Mesh​

尽管微服务环境提供可移植性,允许更快更频繁的部署周期,甚至还能让组织创建关注于特定领域的团队,但这也伴随着对于流量管理、安全以及可观测性等需求的增长。在整个生态系统中,针对这些需求的服务网格模式的实现方法不计其数。微软一直活跃在 Service Mesh Interface (https://smi-spec.io/) (SMI) 社区中,协助定义一组标准可移植的 API 规范,能够实现横跨在不同服务网格之上的通用服务网格功能。供应商可以应用 SMI 来确保生态系统工具能够在不同的网格上工作,同时也允许客户选择网格提供方。

今天我们很高兴推出一个新的开源项目--Open Service Mesh (https://openservicemesh.io/) (OSM) ,一个运行于 Kubernetes 上的轻量的、可扩展的服务网格。OSM 能够让使用者在高度动态化的微服务环境中对服务到服务间的通信做到一致地管理、保护和观测。我们希望 OSM 能成为一个社区主导的项目,这将促进 SMI 在新的和现有的 API 上的协作。我们打算让 OSM 成为开放治理,这样能够轻松的与社区进行协作。因此我们已经提交了一份提议,来启动将 OSM 捐赠给云原生计算基金会(https://cncf.io/) (CNCF) 的进程。

我们要让 Kubernetes运维人员们能够毫不费力的安装、维护和运行 OSM;与此同时,也要让 OSM 足够简单,让整个社区都能够理解并做出贡献。

这些目标根植于客户需求之中,也将我们引向三个基本的设计准则。首先,OSM 提供一个与SMI规范兼容的控制平面,以此来保留用户的选择。其次,我们使用 Envoy 作为数据平面,因为 Envoy 具有很强的社区动力。最后,OSM 背后最重要的理念是“非陡峭(no cliffs)”设计,能够让 OSM 足够灵活,在简单或复杂的场景下都可以直接使用 SMI 和编写 Envoy xDS API 来处理。

“很高兴 OSM 能够加入 Envoy 家族,为 Kubernetes 构建一个供应商中立的服务网格方案,并强调简便性”。--Envoy创始人Matt Klein

OSM 简化了许多任务,诸如为通用部署方案的配置流量转移,使用 mLTS 来保护服务到服务间通信的安全,为服务实施细粒度的访问控制策略,观察用于调试和监视服务的指标,集成本地或外部证书管理解决方案,以及使用自动的 sidecar 注入将应用载入到网格中。

很高兴能与社区一起改进、开发 、学习 OSM,并与广大 SMI 社区一同发布 SMI 规范的进展。我们将在 KubeCon EU Virtual 2020 ( https://events.linuxfoundation ... urope/) ,以及8月14日举办的 CNCF Webinar(https://www.cncf.io/webinars/c ... ystem/) 上展示 OSM。

1 了解微软 Open Service Mesh

微软已经发布了它的开源服务网格实现。这对 Azure 上的 Kubernetes 来说意味着什么?

仅仅在几年前,当我们提到基础架构时,我们指的是物理上的基础设施:服务器、内存、磁盘、网络交换机以及所有连接它们所必须的线缆。我曾经有一些电子表格,当我构建一个可以支持成千上万用户的 Web 应用时,我需要向表格中键入某个数字,先得到我所需要的硬件规范,然后才去实施。

现在一切都改变了。首先到来的是虚拟基础设施,它们位于那些物理机架的服务器上。通过一组虚拟机管理程序和软件定义的网络与存储,可以指定应用程序的计算要求,并在别人为我管理的物理硬件上配置应用程序及其虚拟网络。今天,在超大规模的公有云上,我们将在自动管理扩展(包括纵向和横向)的编排框架上构建分布式应用。

2使用分布式网格来管理分布式应用架构

新的应用基础设施需要属于它们自己的基础设施层,它必须足够智能,能够响应自动扩展、处理负载均衡和服务发现,并仍能支持策略驱动的安全性。在微服务容器之外,你的应用基础设施被实现为一个服务网格,每一个容器都被链接到作为 sidecar 运行的代理上。这些代理管理容器之间的通信,允许开发团队专注于他们的服务和托管的 API,而所有连接这些服务的服务网格由应用操作团队管理。

一个人在应用服务网格时,或许面临的最大问题是选择困难症:谷歌的出名的 Istio、开源的 Linkerd、HashiCorp 的 Consul,抑或是更多的实验性工具如 F5 的 Aspen Mesh。选择一个已经很难,而更难的是在整个组织中标准化一个实现。

当下,如果你想通过 Azure Kubernetes Service 来使用服务网格(https://docs.microsoft.com/en- ... -about),你得到的建议是使用 Istio、Linkerd 或是 Consul,在 AKS 文档中都有它们的相关说明。这并不是最简单的方法,因为你需要一个独立的虚拟机来管理服务网格,同时还需要一个运行在 AKS 上的 Kubernetes 集群。然而,另一个还在开发中的方法是 Service Mesh Interface (https://smi-spec.io/) (SMI), 它提供一组连接 Kubernetes 到服务网格的标准接口。Azure 已经支持 SMI 有一段时间了,因为其 Kubernetes 团队一直领导着 SMI 的开发。

3 SMI: 一组通用服务网格 API

和 Kuebernetes 一样, SMI 也是一个 CNCF 项目,尽管当前只是一个sandbox项目。处于沙箱意味着它尚未被视为稳定,随着 CNCF 开发计划的各个阶段,它的前景将发生重大变化。当然,云厂商和 Kubernetes 供应商以及赞助其开发的其他服务网格项目也提供了大量支持。SMI 旨在为 Kubernetes 提供一组基本 API,以便连接到符合 SMI 的服务网格。因此你的脚本和运维人员可以使用任何的服务网格;没有必要被锁定在单个提供方。

作为一组自定义的资源定义和扩展 API 服务器,SMI 可安装在任何经过认证的 Kubernetes 发行版上,如 AKS。一旦应用到位,你可以使用熟悉的工具和技术来定义应用程序和服务网格之间的连接。SMI 会使应用程序具有可移植性;你可以使用 SMI 在本地的 Kubernetes 实例上开发,并可以将任何应用程序转移到一个托管有符合 SMI 规范的服务网格的 Kubernetes 上,且无需担心兼容性。

有一点很重要,SMI 本身并不是一个服务网格;它是一个规范,服务网格需要实现它来获得一组通用的功能特性。没有什么能阻止服务网格添加属于自己的扩展和接口,但是它们需要足够引人注目才会被应用程序和应用运维团队使用。SMI 背后的开发者们也声称他们并不反感将新的功能迁移到 SMI 规范中,因为服务网格的定义在不断发展,那些预期功能也在不断改变。

4 Open Service Mesh:微软开发的 SMI 实现

微软最近发布了它的第一个 Kubernetes 服务网格 (https://openservicemesh.io/),它基于微软在 SMI 社区的成果之上。Open Service Mesh 是一个符合 SMI 规范的、轻量的服务网格,它是一个托管于 Github (https://github.com/openservicemesh/osm) 的开源项目。微软希望 OSM 成为一个社区主导的项目,并打算尽早将其捐赠给 CNCF。你可以视 OSM 为一个基于现有服务网格组件和概念的 SMI 参考实现。

尽管微软并没有明确表态,但在 OSM 的声明和文档中,有一条它在Azure上使用服务网格的经验,它们重点关注的是与运维相关的东西 (https://github.com/openservice ... IGN.md)。在最初的博客 (https://openservicemesh.io/blo ... -mesh/)中, Michelle Noorali 描述 OSM 为 “让Kubernetes 运营人员毫不费力的安装、维护和运行”。那是一个明智的决定。OSM 是供应商中立的,但是它很有可能成为 AKS 的众多服务网格选项之一,因此易于安装和管理将是推动人们接受它的一个重要因素。

OSM 基于其他服务网格项目的成果之上。尽管它拥有自己的控制平面,但是它的数据平面基于 Envoy。同样,这是一个务实且明智的办法。SMI 是关于如何控制和管理服务网格实例的,因此使用大家熟悉的 Envoy 来处理策略将允许 OSM 在现有的功能上构建,这减少了学习曲线,同时也让应用程序运营人员能跨过有限的 SMI 功能集,在必要的情况下使用更复杂的 Envoy 的特性。

目前 OSM 实现了一组通用服务网格特性。这些包括支持流量转移、保护服务到服务的连接、应用访问控制策略和处理服务的可观测性。通过自动部署 Envoy sidecar 代理,OSM 会自动添加新的应用和服务到网格中。

5 部署和使用 OSM

想要开始尝试 OSM alpha 版本 (https://github.com/openservice ... ide.md),可以在项目的 Github Release (https://github.com/openservicemesh/osm/releases) 页面上下载它的命令行工具 osm。当运行osm install时,它会以默认的命名空间和网格名称把 OSM 控制平面添加到 Kubernetes 集群中。你可以在安装过程中进行修改。安装并运行 OSM 后,可以向网格中添加服务 (https://github.com/openservice ... ces.md),使用策略定义来添加 Kubernetes 命名空间,以及自动将 sidecar 代理添加到托管的命名空间下的所有pod中。

这些步骤将实现你选择的策略,因此在开始部署前就设计好一组 SMI 策略将会是一个不错的主意。OSM Github repo 上的策略样例将会给你帮助。OSM 中包含了 Prometheus 监控工具包和 Grafana 可视化工具 (https://github.com/openservice ... ity.md),因此你可以快速查看服务网格和 Kubernetes 应用的运行情况。

Kubernetes 在现代云原生应用中是一个重要的基础设施元素,因此我们要开始重视它。这要求你将它同运行在它之上的应用独立开来进行管理。AKS、OSM、Git 和 Azure Arc 的组合成为管理 Kubernetes 应用环境的基础配置。应用基础架构团队管理 AKS 和 OSM,为应用和服务设置策略,与此同时, Git 和 Arc 将通过 OSM 的可视化工具传递的实时应用指标来控制应用的开发和部署。

这些元素完全融合还需要一段时间,但很明确微软正在为分布式应用管理及其必要的工具做出重要的承诺。现在就动手吧,使用这个套件的基础元素 AKS,并添加上 OSM 和 Arc。你现在就可以在 Azure 上构建和部署 Kubernetes,使用 Envoy 作为服务网格,同时在实验室中使用 OSM 和 Arc 进行原型设计,为适合生产的时机做好准备。这不会需要等待很久。

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-08-14

基于OVN的K8s网络组件Kube-OVN 企业版发布,现开放试用申请

1Kube-OVN社区版V1.3再升级 支持容器网络硬件加速,自定义网关,网关Qos以及更多

Kube-OVN 社区版v1.3近日全新发布,从此版本起,Kube-OVN支持基于智能网卡的硬件加速,能够大幅提升容器网络吞吐量,降低网络延迟,并且能减少主机CPU的损耗,可以大幅提升裸金属场景下的性能和资源利用率。同时,社区版v1.3增加了网关的功能,用户可以自定义Pod路由策略选择集群内的特定Pod作为流量网关并进行自定义的网关功能开发,例如 EIP,计费,审计等功能。另外,网关增加了QoS控制的功能,用户可以对同一子网的总对外带宽进行动态调整。

详细功能见:https://github.com/alauda/kube ... 1.3.0

2 基于企业用户需求推出Kube-OVN企业版 功能、服务更加完善

Kube-OVN 开源以来,获得了大批开发者和用户的关注,并已经在若干项目和实际环境中投入使用。随着多个电信级客户的认同,以及企业用户的增加,Kube-OVN在版本更迭中也更加注重稳定性、安全性、易部署等特性。所以,在Kube-OVN社区版本的基础上,Kube-OVN企业版应时而生。在网络功能、网络运维、网络安全、技术支持方面,有以下差异:

社区版
企业版

网络功能
•单集群容器网络

•IPtables网关

•单集群容器网络

•IPtables网关

•Pod EIP

•多集群互通容器网络

•OVN高性能网关

•智能网卡支持

网络运维
•命令行工具

•基本连通性指标

•控制平面状态指标

•命令行工具

•基本连通性指标

•控制平面状态指标

•性能监控指标

•流量统计指标

•网络异常指标

•大屏面板

网络安全
•随社区2-3个月统一发版

•维护最近一个版本安全和Bug相关问题

•官方订阅,安全和Bug相关修复第一时间推送

•用户版本长期支持

•定制升级方案策略

•控制平面TLS加密

•网络流量加密

技术支持
•社区支持

•技术公开课

•社区支持

•技术公开课

•原厂专家5*8技术支持

1.针对企业场景下多集群和联邦的场景,将容器其网络从单集群容器网络拓展到多集群容器网络,容器网络可跨集群互通,提供了更灵活的组网控制。

2.针对大规模集群的性能问题,使用 OVN 内置网关代替 Iptables 大幅提升网关吞吐量能力,并提供基于网关的容器EIP能力。

3.针对裸金属性能需求提供和Mellanox智能网卡厂商集成的能力,利用智能网卡处理网络数据平面处理,提升吞吐量性能同时降低物理机CPU的消耗。

4.更多监控指标集成,可接入第三方云杉网络DeepFlow网络监控系统,提升容器网络的可视化能力,更快速的进行故障定位,流量统计,性能分析。

5.后期运维支持,服务与产品能力同样重要,提供及时并专业的技术支持能帮助注重安全、稳定的企业用户将问题降至最低。Kube-OVN企业版将提供官方订阅,第一时间推送软件升级、补丁更新、安装调优等信息。提供畅通的问题反馈渠道,由原厂专家团队支持售后服务,且响应时间(SLA)可选,满足不同程度的企业需求。

**3 Kube-OVN企业版
现推出限时免费试用**

事实上,社区版和企业版是互相共生的关系。

Kube-OVN社区版已经集结了大量社区开源贡献者的智慧,汇聚了顶尖的技术,Kube-OVN企业版的诞生,受益于大量社区用户创建的生态,而Kube-OVN社区版又将受益于企业版的不断改进。

查看原文

赞 0 收藏 0 评论 0

灵雀云 发布了文章 · 2020-08-13

基于OVN的K8s网络组件Kube-OVN 企业版发布,现开放试用申请

1Kube-OVN社区版V1.3再升级 支持容器网络硬件加速,自定义网关,网关Qos以及更多

Kube-OVN 社区版v1.3近日全新发布,从此版本起,Kube-OVN支持基于智能网卡的硬件加速,能够大幅提升容器网络吞吐量,降低网络延迟,并且能减少主机CPU的损耗,可以大幅提升裸金属场景下的性能和资源利用率。同时,社区版v1.3增加了网关的功能,用户可以自定义Pod路由策略选择集群内的特定Pod作为流量网关并进行自定义的网关功能开发,例如 EIP,计费,审计等功能。另外,网关增加了QoS控制的功能,用户可以对同一子网的总对外带宽进行动态调整。

详细功能见:https://github.com/alauda/kube ... 1.3.0

2 基于企业用户需求推出Kube-OVN企业版 功能、服务更加完善

Kube-OVN 开源以来,获得了大批开发者和用户的关注,并已经在若干项目和实际环境中投入使用。随着多个电信级客户的认同,以及企业用户的增加,Kube-OVN在版本更迭中也更加注重稳定性、安全性、易部署等特性。所以,在Kube-OVN社区版本的基础上,Kube-OVN企业版应时而生。在网络功能、网络运维、网络安全、技术支持方面,有以下差异:

社区版
企业版

网络功能
•单集群容器网络

•IPtables网关

•单集群容器网络

•IPtables网关

•Pod EIP

•多集群互通容器网络

•OVN高性能网关

•智能网卡支持

网络运维
•命令行工具

•基本连通性指标

•控制平面状态指标

•命令行工具

•基本连通性指标

•控制平面状态指标

•性能监控指标

•流量统计指标

•网络异常指标

•大屏面板

网络安全
•随社区2-3个月统一发版

•维护最近一个版本安全和Bug相关问题

•官方订阅,安全和Bug相关修复第一时间推送

•用户版本长期支持

•定制升级方案策略

•控制平面TLS加密

•网络流量加密

技术支持
•社区支持

•技术公开课

•社区支持

•技术公开课

•原厂专家5*8技术支持

1.针对企业场景下多集群和联邦的场景,将容器其网络从单集群容器网络拓展到多集群容器网络,容器网络可跨集群互通,提供了更灵活的组网控制。

2.针对大规模集群的性能问题,使用 OVN 内置网关代替 Iptables 大幅提升网关吞吐量能力,并提供基于网关的容器EIP能力。

3.针对裸金属性能需求提供和Mellanox智能网卡厂商集成的能力,利用智能网卡处理网络数据平面处理,提升吞吐量性能同时降低物理机CPU的消耗。

4.更多监控指标集成,可接入第三方云杉网络DeepFlow网络监控系统,提升容器网络的可视化能力,更快速的进行故障定位,流量统计,性能分析。

5.后期运维支持,服务与产品能力同样重要,提供及时并专业的技术支持能帮助注重安全、稳定的企业用户将问题降至最低。Kube-OVN企业版将提供官方订阅,第一时间推送软件升级、补丁更新、安装调优等信息。提供畅通的问题反馈渠道,由原厂专家团队支持售后服务,且响应时间(SLA)可选,满足不同程度的企业需求。

**3 Kube-OVN企业版
现推出限时免费试用**

事实上,社区版和企业版是互相共生的关系。

Kube-OVN社区版已经集结了大量社区开源贡献者的智慧,汇聚了顶尖的技术,Kube-OVN企业版的诞生,受益于大量社区用户创建的生态,而Kube-OVN社区版又将受益于企业版的不断改进。

查看原文

赞 0 收藏 0 评论 0

灵雀云 分享了头条 · 2020-07-27

近日,全球权威咨询分析机构Gartner发布了“2020中国ICT技术成熟度曲线(Hype Cycle for ICT in China, 2020 )”报告,灵雀云作为国内容器和云原生领域翘楚,成功入选CaaS容器云代表性厂商(sample vendor)。这是国内容器厂商首次入选Gartner相关报告,也是对灵雀云...

赞 0 收藏 0 评论 0

认证与成就

  • 获得 37 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2018-12-18
个人主页被 2.4k 人浏览