Kubernetes 1.18GA,15个稳定11个beta,引入kubectl debug命令

王延飞阅读(15517)评论(0)

我们很高兴宣布Kubernetes 1.18的交付,这是我们2020年的第一版!Kubernetes 1.18包含38个增强功能:其中15个功能已趋于稳定,beta版本中有11个,alpha版本中有12个。

Kubernetes 1.18是一个“完美”的版本。为了改善用户体验,我们在beta和 stable 功能改进方面进行了大量工作:增加新的开发和新功能。对alpha,beta和 stable 版进行几乎一样多的增强是一项伟大的成就。这说明,社区在提高Kubernetes的可靠性以及继续扩展其现有功能方面所做的巨大努力。

Kubernetes 1.18主要更新内容

Kubernetes拓扑管理器(Topology Manager ) 升级到Beta版 !

拓扑管理器功能 是1.18版中Kubernetes的beta版本功能,它可以使CPU和设备(如SR-IOV VFs)实现NUMA,这将使你的工作负载在针对低延迟而优化的环境中运行。在引入拓扑管理器之前,CPU和设备管理器会做出彼此独立的资源分配决策,那么可能会导致在多套接字( multi-socket )系统上分配不良,从而导致关键型应用程序的性能下降。

Serverside Apply引入Beta 2版本

Server-side Apply 在1.16中被升级为Beta,在1.18中引入Beta 2版本。这个新版本将跟踪和管理所有新Kubernetes对象的字段更改,从而使你知道更改了什么资源以及何时更改的。

使用IngressClass扩展Ingress,并用IngressClass替换不推荐使用的注释

在Kubernetes 1.18中,Ingress有两个重要的补充:一个新pathType字段和一个新IngressClass资源。该pathType字段允许指定路径应如何匹配。除了默认ImplementationSpecific类型外,还有new Exact和Prefixpath类型。

该IngressClass资源用于描述Kubernetes集群中的Ingress类型。入口可以通过ingressClassName在入口上使用新字段来指定与它们关联的类。这个新资源和字段替换了不建议使用的kubernetes.io/ingress.class注释。

SIG-CLI引入kubectl debug命令

SIG-CLI一直在争论是否需要调试实用程序。随着临时容器(ephemeral containers)的发展,开发人员越来越需要更多类似kubectl exec的命令。该kubectl debug命令的添加(它是Alpha版本,但欢迎你提供反馈),使开发人员可以轻松地在集群中调试其Pod。我们认为这种增加是无价的。此命令允许创建一个临时容器,该容器在要检查的Pod旁边运行,并且还附加到控制台以进行交互式故障排除。

Alpha版本引入Windows CSI

随着Kubernetes 1.18的发布,用于Windows的CSI代理的Alpha版本也已发布。CSI代理使非特权(预先批准)的容器能够在Windows上执行特权存储操作。现在,可以利用CSI代理在Windows中支持CSI驱动程序。

Kubernetes 1.18其他更新

稳定特性💯

主要变化

发行说明

在我们的发行说明中查看Kubernetes 1.18发行版的完整详细信息。

可用性

Kubernetes 1.18可以在GitHub上下载。如果要开始使用Kubernetes,可以看看这些互动式教学或使用 kind.运行本地Kubernetes集群。你还可以使用kubeadm轻松安装1.18 。

发布团队

通过数百名贡献了技术和非技术内容的个人的努力,使此发行成为可能。特别感谢Searchable AI网站可靠性工程师Jorge Alarcon Ochoa领导的发布团队。34位发布团队成员协调了发布的许多方面,从文档到测试,验证和功能完整性。

随着Kubernetes社区的发展,我们的发布过程很好地展示了开源软件开发中的协作。Kubernetes继续快速地获得新用户。这种增长创造了一个积极的反馈周期,其中有更多的贡献者提交了代码,从而创建了更加活跃的生态系统。到目前为止,Kubernetes已有超过40,000个人贡献者,活跃社区有3,000多人。

发布徽标

为什么选择大型强子对撞机?

LHC是世界上最大,功能最强大的粒子加速器。这是来自世界各地成千上万科学家合作的结果,所有这些都是为了促进科学的发展。以类似的方式,Kubernetes已经成为一个项目,它聚集了来自数百个组织的数千名贡献者–所有人都朝着在各个方面改善云计算的相同目标努力!发行名称“ A Quarky”的意思是提醒我们,非常规的想法可以带来巨大的变化,对开放性保持开放态度将有助于我们进行创新。

关于设计师

Maru Lango是目前居住在墨西哥城的设计师。尽管她的专长是产品设计,但她还喜欢使用CSS + JS进行品牌,插图和视觉实验,并为技术和设计社区的多样性做出了贡献。你可能会在大多数社交媒体上以@marulango的身份找到她,或查看她的网站: https://www.marulango.com/

Kubernetes 用户实践亮点

  • 爱立信正在使用Kubernetes和其他云原生技术来交付高要求的5G网络,从而节省多达90%的CI / CD。
  • Zendesk正在使用Kubernetes 运行约70%的现有应用程序。它还构建了所有也可以在Kubernetes上运行的新应用程序,这节省了时间,提高了灵活性并提高了其应用程序开发的速度。
  • 由于改用Kubernetes,LifeMiles已将基础设施支出减少了50%。它还使他们可以将其可用资源容量增加一倍。

生态系统更新

  • CNCF公布了其年度调查的结果,该结果表明Kubernetes在生产中的使用量正在猛增。调查发现,有78%的受访者在生产中使用Kubernetes,而去年这一比例为58%。
  • CNCF举办的“ Kubernetes简介”课程已超过100,000个注册

项目速度

CNCF继续完善DevStats,这是一个雄心勃勃的项目,旨在可视化项目中的大量贡献。K8s DevStats展示了主要公司贡献者的贡献细目,以及一系列令人印象深刻的预配置报告,包括从各个贡献者到请求生命周期时间的所有内容。

在过去的一个季度中,有641家不同的公司和6,409多名个人为Kubernetes做出了贡献。查看DevStats,以了解有关Kubernetes项目和社区整体速度的更多信息。

活动更新

Kubecon + CloudNativeCon EU 2020推迟发布-有关最新信息,请查看Novel Coronavirus更新页面

Kubernetes 1.18即将举行的在线讲座

将于2020年4月23日举行在线讲座,以了解Kubernetes 1.18版本的主要功能,包括 kubectl debug ,Topology Manager,Ingress to V1 graduation 和 client-go 。在此处注册: https://www.cncf.io/webinars/kubernetes-1-18/

欢迎你参与其中

参与Kubernetes的最简单方法是加入符合你的兴趣的众多特殊兴趣小组(SIG)之一。你有什么想向Kubernetes社区广播的内容吗?在我们的每周社区会议上以及通过以下渠道分享你的声音。感谢你一直以来的反馈和支持。

k8s高可用部署后续:SLB

Young阅读(5911)评论(3)

前一段时间写了使用keepalived+haproxy部署k8s高可用集群,核心思想是利用keepalived生成vip实现主备容灾,以及haproxy负载k8s-apiserver流量。k8s高可用部署:keepalived + haproxy

这种方式是自己实现了负载均衡。本文将探讨在用户已有SLB的场景下如何实现k8s高可用

SLB概念

阿里云文档中SLB(Server Load Balancer)介绍如下:

负载均衡基础架构是采用集群部署,提供四层(TCP协议和UDP协议)和七层(HTTP和HTTPS协议)的负载均衡,可实现会话同步,以消除服务器单点故障,提升冗余,保证服务的稳定性。

负载均衡作为流量转发服务,将来自客户端的请求通过负载均衡集群转发至后端服务器,后端服务器再将响应通过内网返回给负载均衡。

本文还涉及到SLB的一个关键技术限制:

在 4 层(TCP 协议)服务中,不支持添加进后端的服务器既作为 Real Server,又作为客户端向所在的 SLB 实例发送请求。因为,返回的数据包只在服务器内部转发,不经过负载均衡,所以通过配置在 SLB 后端的 服务器去访问其 VIP 是不通的。

另外对于SLB的健康检查、调度算法等最佳实践不做探讨,请查阅相关文档。文本探讨的范围仅限于架构可行性验证。

架构

1 keepalived+haproxy

 

由于4层SLB不支持后端服务访问其VIP,根据kubeadm官方安装文档:

 

 

 

 

 

 

指定vip会发生如下超时错误:

[etcd] Creating static Pod manifest for local etcd in “/etc/kubernetes/manifests”

[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory “/etc/kubernetes/manifests”. This can take up to 4m0s

[kubelet-check] Initial timeout of 40s passed.

查看kubele日志:

# sudo journalctl -u kubelet.service

k8s.io/kubernetes/pkg/kubelet/kubelet.go:442: Failed to list *v1.Service: Get https://172.16.105.26:9443/api/v1/services?limit=500&resourceVersion=0: dial tcp 172.16.105.26:9443: connect: connection refused

还记得之前说的4层负载的技术限制吗?

基于此我们出了一个比较”脏”的方案:keepalived+haproxy。安装步骤与上一篇文章一样,只是结果不同:

  •  这种方式还是先启用keepalived绑定vip,此时对vip的请求属于本地访问,不会转发出去,因此不会出现访问不通的情况。
  • 三台keepalived都必须是leader, 否则只有一台能绑定vip,其他两台还是加入不了
  • 如何使三台都是keepalived leader? 两种方式: 1)关闭vrrp协议(阿里云默认关闭),此时keepalived backup收不到其他节点的广播信息,将自己设为leader; 2)用单播方式启动keepalived

问题:

1.  这种实现方式相当于在LB的后端又实现一次LB,但是用户请求多了一次转发, 显然不是一个令人满意的方案。

2. 这种keepalived全主模式不能应用在纯vip场景下(如openstack)。这种情况安装是没问题的,master1先绑定vip,master2,3通过vip访问apiserver时走本地流量,由于本地apiserver:6443还未启动,被haproxy负载到健康节点。这么做安装是没问题的。但是不能保证高可用。当master1 done时,子网内部访问vip还是能找到另外两台健康节点,但是子网外部访问时,路由器还是会路由到master1。

2 绑定vip方式

keepalived的解决方式其实是将vip绑定三台k8s-master,使得三台主机初始化时走本地网络,解决后端访问不了slb的问题。那么其实我们不需要在keepalived后面再加一层haproxy,使得请求多一次转发,更进一步,我们不需要keepalived来绑定vip,手动绑定就好了。

安装步骤:

2.1 init k8s-master-leader

绑定vip:

# ip addr add 172.16.105.26/32 dev eth0

查询绑定结果:

#ip a| grep eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    inet 172.16.104.54/24 brd 172.16.104.255 scope global eth0

    inet 172.16.105.26/32 scope global eth0

kubeadm-config.yaml

apiVersion: kubeadm.k8s.io/v1beta1

kind: ClusterConfiguration

kubernetesVersion: v1.14.1

imageRepository: registry.aliyuncs.com/google_containers

networking:

  podSubnet: 10.244.0.0/16

controlPlaneEndpoint: 172.16.105.26:6443

join

sudo kubeadm init –config=kubeadm-config.yaml –experimental-upload-certs

记录下日志中的join命令

2.2 join k8s-master-follower

分别将k8s-master-follower加入k8s-master-leader

 sudo kubeadm join 172.16.105.26:6443 –token c1d2cb.vx086ez76bpggqj5 \

>     –discovery-token-ca-cert-hash sha256:bc749b4e7e75f93ea9c0055d1c6e36c814b04247ca9e5bb6168ec3a27e5693bd \

>     –experimental-control-plane –certificate-key cdb31f173bf87a573217a4cd1d6e22dc1d396a4da5050e36bdec407bd2aab29d

2.3 为k8s-master-follower绑定vip

您可能注意到follower join时没有先绑定vip。原因是follower join时需要访问k8s-apiserver获取证书等信息,绑定vip直接走本地,获取失败。而此时slb健康检查认为k8s-master-leader是可以负载的,所以直接访问前端slb会负载到k8s-master-leader,可以访问k8s-apiserver。

那为什么还要为k8s-master-follower绑定vip呢?在每个k8s-master-follower请求slb时有1/3的几率负载到自身,此时访问不通。绑定vip后,每个k8s-master-follower访问slb都是访问的本机。

总结

第一篇文章讲述了只有vip,没有实际slb设备的模式下,采用keepalived+haproxy实现高可用的方式。本篇讲述了依赖云厂商SLB高可用和负载均衡时安装k8s。方案一并不完美,通过改良后形成了方案二。当然业内肯定还有很多其他的解决方案,作者才疏学浅,还没来得及一一拜读。

完成本篇的同时又接到了一个新的需要:SLB不是以vip形式提供,而是域名。域名SLB当然比IP要强,大部分云厂商负载均衡肯定不是一台设备,背后都是大规模的集群,会保证SLB服务本身的高可用。这种场景下已经不能通过绑定vip来实现,如何解决呢?敬请期待第三篇。

Kubernetes的“无BS”清单

solerho阅读(773)评论(0)

如果您是k8s的新手,此时您被安排为您的企业研究供应商支持平台,你很有可能不知所措。你会遇到一个看似永无止境的供应商列表,当然,所有的供应商或多或少都一样。

为了帮助你浏览并向供应商询问正确的问题,我们创建了此 no- BS Kubernetes 清单。清单中包括了面向未来的Kubernetes策略的所有必备品

企业级Kubernetes必备

  • 基础架构管理

默认情况下,Kubernetes无法配置基础架构,因此如果节点崩溃,Kubernetes将无法配置新的基础架构。Kubernetes所能做的就是在可用节点内重组Pod。但是,如果没有足够的可用基础架构资源,Kubernetes将无法保证自我修复。这里有一个小秘密;至今为止,市场上的大多数解决方案尚未管理基础架构,或者仅仅在选定的环境中进行配置。

  • 自我修复的Kubernetes

几乎每个平台都有望实现自愈。但是,您需要在三个不同的层面进行自我修复:(1)基础架构:取决于上述基础架构的管理能力;(2Kubernetes组件:这是您必须验证以确认这一点;(3)应用程序级别:默认情况下,由Kubernetes通过自我修复的容器(自愈容器)提供。对于真正可靠的应用程序,您需要在所有层上进行自我修复。

  • 多集群支持和集中管理

虽然早期采用Kubernetes的方法可能包括一个或几个静态集群,但随着业务规模的增长和成熟的DevOps实践,就需要将Kubernetes集群视为牛,而不是宠物。大多数组织必须同时运行多个集群,根据需要创建和销毁它们,并为其开发团队启用自助服务。如果对每个群集分别进行管理,则此方案很快就变得难以管理。

  • 多环境支持

随着云和软件变得越来越复杂,托管应用程序的位置将越来越影响系统性能。根据451 Research的调查,所有的企业中,超过一半选择混合云和多云作为他们理想的IT架构,大约63%的企业正在使用两个或多个云。这就是为什么您需要一种可在各种环境下工作的解决方案的原因。

  • 多站点支持可靠性和容灾

大型企业不会在一个数据中心、区域或云中运行其关键任务应用程序。它们分布在不同的站点,以确保可靠性和容灾。在这种情况下,您的平台必须支持多站点部署,并且能够在多个站点之间协调自动故障转移和恢复过程。

  • 集中记录和监控

集中日志记录和监控对于OpsDevOps团队快速识别并修复基础架构、Kubernetes和应用程序问题至关重要。与很多零碎的视图相比,它提供了单个集成图片。趋势和相关性更容易发现,有助于尽早采取预防或纠正措施。此外,为了安全性和审计,infosec需要一些所有遥测的集中图片。

  • 安全

Kubernetes本身具有强大的安全功能特点,但正在寻找可以将这些功能连接到企业系统的提供商。这不仅应包括集群和容器的安全功能(例如TLS,密钥和证书的轮换和管理,AAA和身份管理等),而且具有企业IDMSAMLOIDCLDAP)和KubernetesRBAC集成能力。

  • 2天操作的完全自动化

该解决方案应处理在集群上的所有管理任务。恢复、还原,更新、升级等等。如果不是自动化的,则需要您自己去做,这很快会让您的资源和预算紧张。

  • 开放开源

开源的主要好处是它开放且灵活,允许用户根据市场需求进行调整。但是,我们看到了一些新的自以为是的开源​​”产品,这些产品会锁定您。虽然有些将您绑定到特定的基础结构或技术堆栈,但有些则在修改原始的开源技术。尽管后者可能是开源的,但它们特定于该供应商,并且不受社区支持。确保您的平台没有被绑定到特定的技术堆栈或基础架构,从而损害了敏捷性。

  • 可配置性

尽管利用供应商支持的Kubernetes平台的整体想法是所有东西都已预先配置,但是一旦冒险进入更高级的用例,您需要能够覆盖参数。由于Kubernetes是一个复杂的多组件系统,因此配置灵活性可能会有所不同,例如,数据科学集群配置会与无状态应用程序或微服务的配置不同。根本就没有那种四海皆准的方法。确保您有权访问主节点和工作节点组件配置,包括交换机,资源请求和限制,操作系统级别的配置等。

  • 命令行和API

当您的Kubernetes和与容器相关的用例成熟时,一些团队成员将更喜欢通过命令行(CLI)进行工作。CLIAPI支持复杂的自动化和集成方案,包括将Kubernetes集群操作集成到CI / CD管道、扩展、平衡、故障转移和恢复方案等。

  • 智能监控和警报

Kubernetes和容器化的应用程序会生成大量原始数据,您必须转换这些原始数据才能了解集群的状况。早期发现和干预对于预防灾难至关重要。如果您无法理解Kubernetes告诉您的内容,那么您就有问题了。通过合并自动智能监视和警报(不会给您充斥不重要的细节),您会从状态、错误、事件和警告等关键信息中受益,从而使您的团队拥有采取行动所需的洞察力。

  • 支持多个Kubernetes版本

企业中任何有意义的Kubernetes部署都将包含多个集群和环境,无论是devprodstagingQA环境,还是组织内不同部门和组或不同应用程序使用的环境和集群。希望所有的都维持相同的配置和补丁/ Kubernetes版本级别是不可行的,因此企业Kubernetes解决方案必须能够同时支持多个Kubernetes版本和配置。

  • 支持Kubernetes升级和更新

Kubernetes平台由整个堆栈组成。仅Kubernetes每年就有四个主要版本。其他项目也有自己的版本。如何处理更新和升级?故障期怎么办?请注意,尽管有些供应商声称支持升级,但如果您进行更深入的研究,您会发现他们需要(有时甚至是很长时间)停机才能进行集群的重新初始化。

  • 24/7支持

最后,随着您的团队开始学习Kubernetes技能,重要的是要有一家提供24/7支持和培训的供应商,以确保您的Kubernetes旅程顺利。

乐于助人

  • 对初学者的用户友好型UI

友好的用户界面对刚接触Kubernetes的企业特别有利。它们通过提供方便的下拉菜单简化了大部分部署,确保几乎不可能创建故障集群。这将使您的团队组织在开始构建内部专业知识时迅速上手Kubernetes

  • Kubernetes“Essentials”的集成

有很多组件不是Kubernetes的一部分,但是对于Kubernetes用户实现任何有意义的目标来说都是必不可少的。其中包括组件和框架,例如容器覆盖网络提供商、入口控制器、Kubernetes自动缩放器、云原生存储系统、用于不同类型卷的持久卷供应器、GPU集成等。

显然,在迁移到基于Kubernetes的面向未来的架构时,企业需要进行多方面的考虑。不幸的是,并不是所有的企业在研究其选择方案时都完全理解他们的要求。如果您考虑一下大多数情况下很新的Kubernetes和云原生技术,这并不让人感到很意外。

无论您选择Kublr的企业级平台还是其他替代产品,我们希望该清单将帮助您浏览生态系统并找到适合您需求的平台。

 

作者:Oleg Chunikhin

原文地址:https://thenewstack.io/a-no-bs-checklist-for-kubernetes/

 

轻松构建基于 Serverless 架构的弹性高可用音视频处理系统

alicloudnative阅读(571)评论(0)

作者 | 罗松(西流)  阿里巴巴技术专家

本文整理自架构师成长系列 2 月 12 日直播课程。

关注“阿里巴巴云原生”公众号,回复 “212”,即可获取对应直播回放链接及 PPT 下载链接。

前言

随着计算机技术和 Internet 的日新月异,视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青睐,而在当前, 云计算平台厂商的产品线不断成熟完善, 如果想要搭建视频点播类应用,告别刀耕火种, 直接上云会扫清硬件采购、 技术等各种障碍,以阿里云为例:

1.png

这是一个非常典型的解决方案, 对象存储 OSS 可以支持海量视频存储,采集上传的视频被转码以适配各种终端,CDN 加速终端设备播放视频的速度。此外还有一些内容安全审查需求, 比如鉴黄、鉴恐等。

而在视频点播解决方案中, 视频转码是最消耗计算力的一个子系统,虽然您可以使用云上专门的转码服务,但在很多情况下,您会选择自己搭建转码服务。比如:

  • 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它有更弹性、更高的可用性?
  • 您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长,自己搭建成本更低;
  • 各种格式的音频转换或者各种采样率自定义、音频降噪等功能;
  • 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力;
  • 您有并发处理大量视频的需求;
  • 您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的大视频, 但是希望当天几个小时后全部处理完;
  • 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响;
  • 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将它们再迁移到 OSS 上。

如果您的视频处理系统有上述需求,或者您期望实现一个 弹性高可用低成本免运维灵活支持任意处理逻辑 的视频处理系统,那么本文则是您期待的最佳实践方案。
2.png

Serverless 自定义音视频处理

在介绍具体方案之前, 先介绍两款产品:

  • 函数计算 :阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询、性能监控、报警等功能;
  • 函数工作流:函数工作流(Function Flow,以下简称 FnF)是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序,分支,并行等方式来编排分布式任务,FnF 会按照设定好的步骤可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。

免费开通函数计算,按量付费,函数计算有很大的免费额度。

免费开通函数工作流,按量付费,函数工作流有很大的免费额度。

函数计算可靠的执行任意逻辑, 逻辑可以是利用 FFmpeg 对视频任何处理操作, 也可以更新视频 meta 数据到数据库等。

函数工作流对相应的函数进行编排, 比如第一步的函数是转码, 第二步的函数是转码成功后,将相应 meta 数据库写入数据库等。

至此,您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求,接下来,本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统,并与传统方案进行性能、成本和工程效率的对比。

简单视频处理系统

假设您是对短视频进行简单的处理, 架构方案图如下:
3.png

如上图所示, 用户上传一个视频到 OSS, OSS 触发器自动触发函数执行, 函数调用 FFmpeg 进行视频转码, 并且将转码后的视频保存回 OSS。

OSS 事件触发器, 阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数,当 OSS 系统捕获到指定类型的事件后,会自动调用函数处理。例如,您可以设置函数来处理 PutObject 事件,当您调用 OSS PutObject API 上传视频到 OSS 后,相关联的函数会自动触发来处理该视频。

附:简单视频处理系统示例工程地址

您可以直接基于示例工程部署您的简单音视频处理系统服务,因为音视频是强 CPU 密集型计算,强烈建议直接函数内存设置为 3G(2vCPU),但是当您想要处理大视频(比如 test_huge.mov ) 或者对小视频进行多种组合操作的时候, 您会发现函数还是大概率会执行失败,原因是函数计算的执行环境有最大执行时间为 10 分钟的限制,如果最大的 10 分钟不能满足您的需求, 您可以选择:

  • 对视频进行分片 -> 转码 -> 合成处理, 详情参考:fc-fnf-video-processing, 下文会详细介绍。
  • 联系函数计算团队(钉钉群号: 11721331) 或者提工单
    • 适当放宽执行时长限制
    • 申请使用更高的函数内存 12G(8vCPU)

为了突破函数计算执行环境的限制(或者说加快大视频的转码速度),引入函数工作流 FnF 去编排函数实现一个功能强大的全功能视频处理系统是一个很好的方案。

全功能视频处理系统-Example

4.gif

如上图所示, 假设用户上传一个 mov 格式的视频到 OSS,OSS 触发器自动触发函数执行, 函数调用 FnF,并行进行提取音频文件,同时进行 avi,mp4,flv 格式的转码。 所以您可以实现如下需求:

  • 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理,比如增加水印处理或者在 after-process 更新信息到数据库等;
  • 当有多个文件同时上传到 OSS,函数计算会自动伸缩, 并行处理多个文件;
  • 对于每一个视频,先进行切片处理,然后并行转码切片,最后合成,通过设置合理的切片时间,可以大大加速较大视频的转码速度;

所谓的视频切片,是将视频流按指定的时间间隔,切分成一系列分片文件,并生成一个索引文件记录分片文件的信息。

  • 结合 NAS + 视频切片, 可以解决超大视频(大于 3G )的转码。

附:全功能视频处理系统示例工程地址

当然, 具体的处理流程是可以根据您的需求修改 fnf 工作流流程, 上面的只是一个示例。

示例效果:

5.gif

函数计算 + 函数工作流 Serverless 方案 VS 传统方案

卓越的工程效率

自建服务 函数计算 + 函数工作流 Serverless
基础设施 需要用户采购和管理
开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署
并行&分布式视频处理 需要很强的开发能力和完善的监控系统来保证稳定性 通过 FnF 资源编排即可实现多个视频的并行处理以及单个大视频的分布式处理,稳定性和监控交由云平台
学习上手成本 除了编程语言开发能力和熟悉 FFmpeg 以外,可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码和熟悉 FFmpeg 使用即可
项目上线周期 在具体业务逻辑外耗费大量的时间和人力成本,保守估计大约 30 人天,包括硬件采购、软件和环境配置、系统开发、测试、监控报警、灰度发布系统等 预计 3 人天, 开发调试(2人天)+ 压测观察(1 人天)

弹性伸缩免运维,性能优异

自建服务 函数计算 + 函数工作流 Serverless
弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维,全功能视频处理系统 (FnF + FC) 压测;性能优异, 详情见下面的转码性能表
监控报警查询 ECS 或者容器级别的 metrics 提供更细粒度的 FnF 流程执行以及函数执行情况, 同时可以查询每次函数执行的 latency 和日志等, 更加完善的报警监控机制

比如短视频处理系统的监控的一个 Example:

5.gif

函数计算 + 函数工作流 Serverless 方案转码性能表

实验视频为是 89s 的 mov 文件 4K 视频: 4K.mov,云服务进行 mov -> mp4 普通转码需要消耗的时间为 188s, 将这个参考时间记为 T。

视频切片时间 FC 转码耗时 性能加速百分比
45s 160s 117.5%
25s 100s 188%
15s 70s 268.6%
10s 45s 417.8%
5s 35s 537.1%

性能加速百分比 = T / FC转码耗时

从上表可以看出,设置的视频切片时间越短, 视频转码时间越短, 函数计算可以自动瞬时调度出更多的计算资源来一起完成这个视频的转码, 转码性能优异。

更低的成本

  • 具有明显波峰波谷的视频处理场景(比如只有部分时间段有视频处理请求,其他时间很少甚至没有视频处理请求),选择按需付费,只需为实际使用的计算资源付费;
  • 没有明显波峰波谷的视频处理场景,可以使用预付费(包年包月),成本仍然极具竞争力;

函数计算成本优化最佳实践文档

  • 假设有一个基于 ECS 搭建的视频转码服务,由于是 CPU 密集型计算, 因此在这里将平均 CPU 利用率作为核心参考指标对评估成本,以一个月为周期,10 台 C5 ECS 的总计算力为例, 总的计算量约为 30% 场景下, 两个解决方案 CPU 资源利用率使用情况示意图大致如下:

6.png

由上图预估出如下计费模型:

  • 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5;
  • ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元;
  • 函数计算按量付费占整个计算量的占比 <= 10%,费用约为 3×864×10% = 259.2 元,(3G 规格的函数满负载跑满一个月费用为:0.00011108×3×30×24×3600 = 863.8,详情查看计费)。
ITEM 平均CPU利用率 计算费用 总计
函数计算组合付费 >=80% 998(246.27×3+259.2) <= 998
按峰值预留ECS <=30% 2190(10*219) >=2190
  • 在这个模型预估里面,可以看出 FC 方案具有很强的成本竞争力,在实际场景中, 基于 ECS 自建的视频转码服务 CPU 利用甚至很难达到 20%, 理由如下:可能只有部分时间段有视频转码请求;为了用户体验,视频转码速度有一定的要求,可能一个视频转码就需要 10 台 ECS 并行处理来转码, 因此只能预备很多 ECS;
  • 因此,在实际场景中, FC 在视频处理上的成本竞争力远强于上述模型;
  • 即使和云厂商视频转码服务单价 PK, 该方案仍有很强的成本竞争力

经实验验证, 函数内存设置为3G,基于该方案从 mov 转码为 mp4 的费用概览表:

实验视频为是 89s 的 mov 文件视频, 测试视频地址:
480P.mov 720P.mov 1080P.mov 4K.mov
测试命令: ffmpeg -i test.mov -preset superfast test.mp4

  • 格式转换
分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 腾讯云视频处理费用 成本下降百分比
标清 640*480 618 kb/s 24 11s 0.00366564 0.032 88.5%
高清 1280*720 1120 kb/s 24 31s 0.01033044 0.065 84.1%
超清 1920*1080 1942 kb/s 24 66s 0.02199384 0.126 82.5%
4K 3840*2160 5250 kb/s 24 260s 0.0866424 0.556 84.4%

成本下降百分比 = (腾讯云视频处理费用 – FC 转码费用)/ 腾讯云视频处理费用

腾讯云视频处理,计费使用普通转码,转码时长不足一分钟,按照一分钟计算,这里计费采用的是 2 min,即使采用 1.5 min 计算, 成本下降百分比也在 80% 左右。

从上表可以看出, 基于函数计算 + 函数工作流的方案在计算资源成本上具有显著优势。

操作部署

详情见各自示例工程的 README:

总结

基于函数计算 FC 和函数工作流 FnF 的弹性高可用视频处理系统天然继承了这两个产品的优点:

  • 无需采购和管理服务器等基础设施,只需专注视频处理业务逻辑的开发,大幅缩短项目交付时间和人力成本
  • 提供日志查询、性能监控、报警等功能快速排查故障
  • 以事件驱动的方式触发应用响应用户请求
  • 免运维,毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,性能优异
  • 成本极具竞争力

Q & A

最后一一回答一下之前列出的问题:

Q1: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性?

A: 如工程示例所示,在虚拟机/容器平台上基于 FFmpeg 的服务可以轻松切换到函数计算, FFmpeg 相关命令可以直接移值到函数计算,改造成本较低, 同时天然继承了函数计算弹性高可用性特性。

Q2:您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF 等。 自己搭建成本更低。

A: 函数计算天生就是解决这些自定义问题, 你的代码你做主, 代码中快速执行几个 FFmpeg 的命令即可完成需求。
典型示例: fc-oss-ffmpeg

Q3: 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。

A: 详情见全功能视频处理系统(函数计算 + 函数工作流方案),after-process 中可以做一些自定义的操作, 您还可以基于此流程再做一些额外处理等, 比如:再增加后续流程;最开始增加 pre-process。

Q4: 您有并发同时处理大量视频的需求。

A: 详情见全功能视频处理系统(函数计算 + 函数工作流方案), 当有多个文件同时上传到 OSS, 函数计算会自动伸缩, 并行处理多个文件。详情可以参考 全功能视频处理系统 (FnF + FC) 压测

Q5: 您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的大视频, 但是希望当天几个小时后全部处理完。

A: 详情可以参考 全功能视频处理系统 (FnF + FC) 压测,  可以通过控制分片的大小, 可以使得每个大视频都有足够多的计算资源参与转码计算, 大大提高转码速度。

Q6: 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF,后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。

A: 详情见全功能视频处理系统(函数计算 + 函数工作流方案), FnF 只负责编排调用函数, 因此只需要更新相应的处理函数即可,同时函数有 version 和 alias 功能, 更好地控制灰度上线, 函数计算版本管理

Q7: 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将他们再迁移到 OSS 上。

A: 函数计算可以挂载 NAS, 直接对 NAS 中的文件进行处理。

如果你对函数计算的能力还不是很了解,欢迎加入钉钉交流群:

7.png

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

 使用Artifactory集群作为文件共享中心

JFrogchina阅读(583)评论(0)

一、背景和痛点

大企业内部,跨团队,跨地域,导致文件共享困难

如果不使用Artifactory,如何实现跨数据中心的文件共享呢?

  • 挂载NFS文件系统,开通跨数据中心的rsync/sftp协议
  • 自研解决方案,通过REST API或者CLI方式, 例如,雅虎的dist工具
  • 私有或者公有的云储存方案
  • 利用SCM版本控制系统

–         对于编译构建效率影响很大

 

NFS和云储存的方式对网络要求很高,稳定性得不到保证。自研的方式需要投入很多人力物力,利用SCM版本控制工具对二进制文件支持不好,尤其是大文件,还有可能会对构建效率造成影响。可以看到上面几种方式稳定性不能保证,而且需要额外的投入。

 

 二、 Artifactory用作文件共享中心

那么,Artifactory 如何解决这个问题:

首先,虽然Artifactory被当做管理全语言二进制文件的制品仓库。Artifactory通常被集成到构建流程中,这样构建工件可以方便的部署到不同环境或者用于后续Docker镜像和亚马逊系统镜像的构建。

然而,Artifactory首先是一个支持元数据的文件管理系统,可以管理任何类型文件以及相关数据,利用其可以在集群之间同步复制的功能,也可以被用作跨数据中心分发不同类型文件的通用平台。

架构图

只允许在指定的一个Artifactory集群上传,然后同步到其它生产环境。例如: IDC1,IDC2,AWS这几个环境不允许手动上传,只允许从Corp环境同步,确保数据的来源只有一个,保证数据的一致性。

 

搭建步骤

对于Artifactory用户来说,只需要创建相应对的共享仓库,然后开启同步功能即可,不需要增加额外的投入。而且同步功能对网络要求不高。

开启Artifactory的同步功能:

 

上传下载文件

例如, 将sharefile.tgz上传到my-local-repo仓库

 

命令行方式:

jfrog rt u  sharefile.tgz  my-local-repo

REST API方式:

curl -H "X-JFrog-Art-Api: ${API_KEY}" -X PUT "${artURL}/ my-local-repo/sharefile.tgz " -T sharefile.tgz

 

下载sharefile.tgz 文件

 

命令行方式:

jfrog rt dl my-local-repo/sharefile.tgz

 

REST API方式:

curl -H "X-JFrog-Art-Api: ${API_KEY}" -X GET "${artURL}/my-local-repo/ sharefile.tgz " -o sharefile.tgz

这样即可进行文件的上传和下载,一旦上传成功,会自动触发同步机制,推送到远端的 Artifactory Server 或者公有云的 Artifactory Server。

三、 收益

l  使用Artifactory的好处

Artifactory已经是CI/CD流程的一部分,可以方便的集成

对于跨数据中心的文件分发只需要开启同步功能

  • 对网络要求不高
  • 具备友好的界面供用户使用
  • 支持REST API方式上传和下载文件,方便实现自动化
  • 统一多数据中心的文件来源,确保文件一致

 

使用Artifactory可以解决的问题

  • 管理第三方工具和包

–  可以指定特殊版本

– 解决网络访问受限的情况

  •  作为DevOps流程中配置文件和资源文件管理的中心
  • 储存不适合在代码版本控制系统中管理的文件

–  大文件

–  二进制文件

  • 储存数据库备份和应用目录的快照

– 可以作为灾备系统的一部分

 

更多精彩内容可以专注我们的在线课堂

微信搜索公众号:jfrogchina 获取课程通知

 

有状态Stateful,富含数据的CI/CD怎么做?

Portworx阅读(1187)评论(0)

CI/CD with Data: 通过AWS Developer Tools、 Kubernetes和Portworx来实现软件交付Pipeline的数据迁移能力

数据是应用最重要的部分。容器技术让应用打包和部署变得更快更容易。对于软件的可靠交付来说,测试环节变得更加重要。由于所有的应用都包含数据,开发团队需要办法来可靠的控制、迁移、和测试真实的应用数据。

对于一些团队来说,通过CI/CD pipeline来移动应用数据,为了保持合规性和兼容其他一些问题,一直是通过手动方式来完成的,无法有效扩展。通常只能适用于一小部分应用,而且无法在不同环境中迁移。目标应该是运行和测试有状态容器,如同无状态容器一样简单(有状态容器 – 例如数据库或者消息总线,其中运行是被追踪的;无状态容器 – 例如网页前端)

为什么测试场景中“状态-State”十分重要?一个原因是许多bug只会在真实数据的环境下才会产生。例如,你需要测试一个数据库的schema的升级,而一个小的数据集并不能完全代表包含复杂商业逻辑的关键应用。如果你需要进行端到端的完整测试,我们需要能够容易的管理我们的数据和State。

在本篇文章中,我们定义CI/CD Pipeline的参考架构,从而能够达到应用间的自动数据迁移。我们也展示如何配置CI/CD pipeline的步骤。

有状态Pipelines: 需要可迁移的卷

作为持续集成、测试、部署的一部分,我们需要在分段setup(staging setup)中重现生产环境中发现的bug。这里,Hosting环境由一个集群组成:Kubernetes作为调度器,Portworx作为持久存储卷。测试的工作流通过AWS CodeCommit、AWSCodePipeline、和AWS CodeBuild来自动完成。

Portworx提供Kubernetes存储,从而可以实现在AWS环境和Pipeline之间的永久卷的迁移。AWS Developer Tools配合Portworx按照Kubernetes参考架构的持续部署,为Kubernetes集群添加了持久存储和存储调度。我们使用MongoDB作为有状态应用的例子,但实际上,工作流可以应用到任何容器化应用:例如Cassandra、MySQL、Kafka、以及Elasticsearch。

使用参考架构,开发者调用CodePipeline来触发运行MongoDB数据库生产系统的快照。Portworx接着会创建基于块的,可写的MongoDB卷的快照。这个过程中,MongoDB数据库的生产系统一直在运行,最终用户不会中断。

如果没有Portworx在其中,手动操作将会需要在CI/CD过程之外,进行一个应用层面的数据库备份实例。如果数据库较大,这会花费好几个小时,并且会影响到生产环境。使用基于块的快照,是实现稳固的不停机备份的最佳方式。

作为工作流的一部分,CodePipeline部署了一个新的MongoDB实例,Staging到Kubernetes集群上,并且Mount第二个具备生产数据的Porworx卷。CodePipeline通过AWS Lambda功能,来触发Portworx卷的快照。

如下图所示:

AWS Developer Tools与Kubernetes:通过工作流与Portworx集成

在下面的工作流中,开发者测试正在使用MongoDB的容器化应用的一个变化。测试是针对一个Staging的MongoDB的实例。如果变化是在服务器端的话,测试工作流也是一样的。最初的生产部署是作为Kubernetes的部署对象来被调度的,并且使用Portworx作为持久卷的存储。

持续部署Pipeline按照如下来运行:

  • 开发者集成Bug修改的变化到一个主要的开发分支,这个开发分支会被合并到CodeCommit的主分支上
  • 当代码被合并到AWS      CodeCommit repository的主分支后,Amazon CloudWatch触发Pipeline
  • AWS CodePipeline 发送新的版本到AWS CodeBuild, CodeBuild会创建一个含有build ID的Docker容器镜像
  • AWS CodeBuild推送新的已标记build      ID的Docker容器镜像,到Asazon ECR      registry
  • Kubernetes从Amazon ECR下载新的容器(为数据库的客户端)、部署应用(作为一个pod)、然后Staging MongoDB实例(作为一个部署对象)
  • AWS CodePipeline, 通过Lambda功能,调用Portworx来为MongoDB生产系统做快照,并且部署一个Staging的MongoDB实例
  • Portworx提供生产实例的快照,作为Staging MongoDB的持久存储
  • MongoDB实例Mounts快照

到这里,Staging的Setup模拟了一个生产环境。团队可以运行集成和端到端的完整测试,使用合作伙伴的工具,不会影响到生产环境的负载。完整的Pipeline如下所示:

总结

这个参考架构展示了开发团队可以很容易的在生产环境中迁移数据,以及为测试来做Staging。并不需要对应用做特定的手动操作,所有CodePipeline的运行都是自动的,并且作为CI/CD过程的一部分被追踪。

这个集成过程使得有状态容器和无状态容器一样容易。通过使用AWS Codepipeline来对CI/CD过程进行管理,开发者使用Portworx存储,可以容易的在Kubernetes集群上部署有状态容器,并且自动的在流程中进行数据管理。

参考架构和代码在Github上:

  • Reference architecture: https://github.com/portworx/aws-kube-codesuite
  • Lambda function source code for Portworx additions: https://github.com/portworx/aws-kube-codesuite/blob/master/src/kube-lambda.py

关于容器持久存储的更多内容,请访问Portworx网站(https://portworx.com/)。关于Code Pipeline的更多内容,请访问AWS CodePipeline User Guide (https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)

解读神书《凤凰项目》,带你跳出DevOps转型的所有坑

JFrogchina阅读(501)评论(0)

提高DevOps工程师软技能,可以了解一下笔者前一篇文章《DevOps工程师必备软技能》

《凤凰项目》是DevOps界神书,虽然内容表现形式是小说,但是依然是敏捷开发及DevOps领域的必读书籍。很多知名的咨询师都是通过此书开启了DevOps及敏捷之旅,书中故事均来源于运维的日常工作,正是体现了艺术源于生活、高于生活的本质。笔者间隔两年时间,阅读此书两次,希望可以讲书中了解到的一些经验分享给大家。

小说主人公比尔,临时接任了IT运维经理的职位,然而此时,公司已经经历了多轮裁员,生产线上故障不断。董事会指望凤凰项目重启拯救公司,然而面对的着层层困难,比尔开始不停的应付突发的线上故障,身心俱疲。为了生存及公司的正常运转,尝试出一套适合该公司的IT转型方案,整个转型过程就像我们从传统开发模式转型DevOps的开发模式一样,踩过很多坑,总结出很多道理,小说的内容我不过多叙述,了解精彩的故事可以直接去购买图书,下面会给大家总结一下书中的一些重要的经验。

  • IT的四种工作形态

在故事中,主人公比尔在接替IT部经理后,通过一系列的故障处理与人际交流的过程中,得出了这个结论。IT的工作无非就是如下四种类型:

  • IT部门内部项目
  • 业务组项目
  • 变更工作
  • 救火工作

其实上述四种工作类型与我们目前运维部门的状态基本一致,我们需要开发自己的运维与监控平台,要参与到业务部门的开发测试中,要进行所有基础设施及应用版本的变更与升级。而这些都是属于正常的工作,我们往往最不愿意处理的就是救火工作,比如线上的突发故障导致的所有用户的功能无法使用,往往运维人员会在技术vp、cto、甚至ceo的注视下一行一行敲着命令,修复问题。大量运维人员应该都有过类似经历,回想起来一定是惨不忍睹,所以我们要减少这种救火工作,并把前三种工作合理分配。

  • 加强变更管理,减少救火行为

从IT的四种工作形态中,我们引申出一个问题,如何减少救火行为呢,我们先看运维圈里的两个定律

  • 著名的二八定律:线上80%的故障来自于20%的变更。
  • GoogleSRE理论:大概 70% 的生产事故由某种部署的变更而触发

我们不去纠结80%与70%的差异是怎么产生的,但是结论是统一的,大量的线上的故障都是由于变更导致的,变更包括对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作。可以看到,这些内容覆盖了大量的运维工作了,为什么运维容易背锅呢,就是因为平时要处理这些高风险的变更操作,才容易引起线上的故障。而外人看来,运维就是在制造麻烦,之后开始救火工作、解决故障。为了避免种情况,该怎么处理呢?文章中给了我们很重要的方法,就是用看板的方法,规范化所有变更的管理,有计划的进行每一次变更,评估每次变更带来的风险点,就算出现故障,也可以快速修复。

  • 加强技术储备,避免个人英雄主义

在解决所有变更导致的故障的时候,小说中出现了一个重要的人,杜伦特,这是运维团队中的一个英雄角色,没有他解决不了的问题。但是就是这么厉害的一个人,所有开发人员都喜欢找他进行变更,所有的系统故障都需要他去处理,所以这么厉害的人,每天都从事的是救火工作。这个角色就变成了我们运维规范化过程中的一个瓶颈点。只要他的工作无法被其他人员替代,就无法让他去做运维团队更重要的事,比如自动化的建设,比如重要的监控建设。小说里为了解决这个问题,比尔设置了故障处理分级机制,把杜伦特保护起来,不允许开发人员直接与杜伦特沟通,同时安排其他工程师接触杜伦特原来的工作,让杜伦特的工作重心在自动化建设与监控建设上。这样在关键位置上增加了技术储备的同时,也将核心技术人员用在了最重要的位置上。

  • 限制在制品数量,多做从0到1,减少0.5的数量(看板)

小说的名称叫《凤凰项目》,所以故事核心是围绕着凤凰项目来的,凤凰项目是一个计划了三年,经过了三年的憋大招勉强上线的一个项目,当然,准备了这么久的项目最后以失败告终,这个问题告诉我们什么呢。主人公在工厂车间意识到,如果工厂的人力是固定的,如果半成品积累的过多,就会导致最终成品交付给用户会变慢,这也就是我们在软件开发领域常说的在制品数量影响着交付的速度,如果开发团队同时迭代着过多的需求,那么必然需求交付到用户的手中的时间要延长。所以限制在制品数量是DevOps建设的一个核心内容,我们应该多做从0-1的事,而减少0.5的数量。书中总结的很好,一旦研发资本以半成品的形式锁定超过一年而未向公司返还现金,他就几乎不可能再为公司产生回报。

 

  • 三步工作法

小说的最后作者总结了三步工作法,包含:

  • 流动原则

流动原则是DevOps建设的基础,缩短满足客户需求的潜质时间,建立自动化工具链,减少人工干预过程,减小在制品数量,快速迭代,便可以有效地提高工作质量和产量。

  • 反馈原则

在源头发现问题,尽早发现问题,测试及安全左移,在生产的源头就要保证质量。

  • 持续学习与实验原则

把生产效率、工作流程上升到领导层,推进DevOps文化的落地。

总结:还等什么,买书去看吧,《凤凰项目》。

 

​更多精彩内容可以专注我们的在线课堂

微信搜索公众号:jfrogchina 获取课程通知

 

阿里巴巴副总裁肖力:云原生安全下看企业新边界——身份管理

alicloudnative阅读(775)评论(0)

作者 | kirazhou

导读:在 10000 多公里之外的旧金山,网络安全盛会 RSAC2020 已经落下了帷幕。而身处杭州的肖力,正在谈起今年大会的主题——Human Element。2020 年,从“人”出发,这颗石子将在国内的安全市场池子里激起怎样的涟漪?Human Element 的背后隐藏着怎样的安全洞见?

在 Gartner 的《2020 年规划指南:身份和访问管理》报告中,我们看到了 IT 必须推进 IAM(身份和访问管理)计划,而身份治理和管理、混合/多云环境作为可预见的趋势,更是已经在风口蓄势待发。

人、身份和云端,这三者之间的角力、千丝万缕和无限可能,正是此次采访的最大收获。

1.png

Human Element:了解人的脆弱性

我们常常谈起,“安全的本质在于人与人之间的对抗。”

从攻防对抗的视角来看,人的因素使得攻防对抗成为一个动态的持久过程。攻击者的手段、工具和策略都在发生变化,而防御者的安全防护能力也在提升,两者之间持续对抗,安全水位线一直动态变化。

在整个攻防对抗过程中,人,既是防御者,也可能成为攻击者,而对抗不仅会发生在企业与外部的对峙中,很多时候也发生在企业内部。

人,是绝对的安全核心,这是今年 RSAC 大会传递给我们的讯息。而在关注人的安全技能与能力建设之余,也要清晰地认知:人的脆弱性使人本身成为安全中薄弱的一环。因此,企业在应对来自外部攻击的同时,如何防范来自企业内部人员的威胁同样关键。

2017 年卡巴斯基的调查报告中提出,46% 的 IT 安全事故是由企业员工造成的。现在,这个比例已经上升至 70%~80%,譬如内部开发者由于未遵守安全规范或自身安全能力不足,而导致所研发的应用在设计之初就留下了漏洞,亦或是在职/离职员工由于操作不规范或直接的恶意行为导致企业安全问题。

“整个安全体系绝对不仅是和自动化蠕虫做对抗,这只是冰山一角”。

面对“人”带来的安全影响,肖力认为问题根源在于企业的安全基线做得不到位。目前,很多企业更注重于威胁检测与响应,这一部分确实有用,但还不够。“我们思考的不是出了问题后如何去解决,而是如何不出问题。”因此,事前的安全基线设置比起事后的检测与响应更为关键。企业安全基线包括了:

  1. 所有应用系统的统一身份认证与授权
  2. 安全运营:设置红线
  3. 建立应用开发安全流程:确定开发人员培训、内部安全考试与认证等规范

如果说企业的安全基线是走向安全的基础 60 分,那么,只有先做好安全基线再去做事后检测响应能力的提升,才能让企业安全体系更为稳固。其中,“身份”作为在互联网中的直观映像,身份管理对于有效降低内部人员的行为带来的安全威胁可以说有着重要作用。

身份:零信任理念下的新旧边界交替

网络身份的重要性无需再赘述,而身份如何从安全因素之一转变为企业安全防护的“主角”,2010 年是一个隐形的节点。

肖力指出,在过去的 IT 环境中,尤其是 2000~2010 年期间,边界隔离是企业安全防护的主要手段。但 2010 年后, IT 整体环境发生了巨大的变化:

  1. IT 架构根源性的变化:随着移动互联、lOT 设备的普及,整个内网、办公网络都受到了巨大的冲击,大量的设备接入,导致原来的边界难以守住;
  2. 企业数据库从 IDC 迁移到云上:随着云计算的浪潮,越来越多的企业选择全站上云或 50% 业务上云,导致防护环境发生变化。
  3. 企业 SaaS 服务发展:企业网盘、钉钉等企业 SaaS 服务的发力,意味着越来越多的企业工作流、数据流和身份都到了外部,而非固定在原本的隔离环境中。

随着环境因素的变化,传统的边界将渐渐消亡,仅依靠传统的网络隔离行之无效,这时候,基于零信任理念的统一身份管理为企业重新筑造了“安全边界”。

基于零信任理念,企业可以构建统一的身份认证与授权系统,将所有账号、认证、权限统一管理。譬如,离职员工被视为企业的重要威胁之一。在整个企业安全体系建设的实践中,必须要做到账户对应到应用系统的权限统一,实现每天离职员工的所有身份、账号权限可以在企业内部系统中一键删除。

包括近一段时间安全圈内热议的微盟员工删库事件,从身份认证与管理的技术角度来看,也是完全可以避免的。肖力认为:

  • 一方面,企业在实施 IAM(身份和访问管理)时,秉持最小权限原则,通过帐号的权限分级,给到员工应有的权限即可,而类似“删库”的特权账号不应该给到任何一个员工;
  • 其次,哪怕员工下发了批量数据删除的指令,企业也可以通过内部异常行为检测,识别出该类指令基本不会发生在正常的生产环境中,从而不执行该指令。

除了技术层面的实现,身份认证与管理的本质依旧是安全基线。同时肖力指出,安全团队在企业中的位置与影响力则决定了基线能否被确定、切实地落实到业务中去。判断安全团队在企业、业务中的影响力大小,最直观的就是组织架构:安全团队是否为独立部门,直接汇报给 CTO 甚至 CEO。

未来,IAM 应该还会向零信任架构推进,并基于零信任理念衍生出多应用场景下的身份治理方案,打通“身份认证”与云安全产品,构建云上零信任体系。

基于云原生安全的 IAM

身份管理提供商 SailPoint 的首席执行官兼联合创始人 Mark McClain 曾经说过:“治理的世界是有关谁有权限访问什么东西,谁应该访问什么东西,以及如何正确使用这些权限的世界。但现实是,大多数消费者距离前两条都差得很远,更不用说第三条了。”幸运的是,现在的 IAM 工具/服务越来越易用,并且加快延伸至云端环境。

肖力指出,云原生的安全红利是可见的。“常态化”的云几乎成为了企业操作系统,涉及 IaaS 层、PaaS 层和 SaaS 层。各个云服务商在安全上注入巨额投资,以规模化的人力物力打磨云安全产品和技术,让企业开始尝到云原生技术带来的安全红利。

普通企业不必重复造轮子,搭载上阿里云等云服务厂商的航母,就能在云计算浪潮里前行,享受高等的安全水位。
其次,云化带来的 6 大云原生安全能力:全方位网络安全隔离管控、全网实时情报驱动自动化响应、基于云的统一身份管理认证、默认底层硬件安全与可信环境、DevSecOps 实现上线即安全,让企业脱离原本复杂的安全管理模式,从“碎片化”到“统一模式”。

随着企业上云趋势日益明显。IT 基础设施云化、核心技术互联网化,最终让企业架构发生变革。而“云化”的过程中,越来越多的企业开始思考混合和多云环境下的 IAM(身份和访问管理)问题。

混合云:场内工作+公有云环境服务的使用;
多云:多个公有云服务商服务的使用。

关于混合云,基于企业上云后的统一管理模式,可以在复杂的混合云环境下直接实现统一的身份接入,将企业云上与云下身份打通,并且基于对云端上的用户环境做评估,动态地授于不同人以不同权限,从而让任何人在任何时间、地点,都可以正确地访问内部资源。而多云的环境则可以利用活动目录的工作负载实现身份管理。

云上的环境,赋予了统一身份管理更多的可行性,而进一步探索混合和多云 IAM 实现方案将成为企业战略的新方向。

最后,由身份管理衍生的数据安全问题,同样值得关注。2019 年,数据安全绝对是最热的话题之一,不管是高发的动辄上亿级别的数据泄露,或是陆续出台的数据隐私法规,都在反复强调数据安全的重要性。

在采访的尾声,肖力同样谈到了今年 RSAC 的创新沙盒冠军 Securiti.ai。有意思的是,过去 3 年创新沙盒冠军中有 2 年都是做数据安全的,似乎给网络安全企业的下一步发展提出了一个非常明确的方向。

首先,数据安全本身的命题就很大,数据的流动性使得数据安全问题横跨各个安全技术领域,并出现在企业的各个环节中;其次,市场需求大。企业对于如何保障内部数据安全、保障客户的数据隐私安全有着迫切的需求。如此看来,“说不定明年的冠军也是做数据安全的呢。”

因此,在未来的 5~10 年,如果安全公司可以通过核心的产品和技术突破帮助用户解决数据安全问题,比如依靠技术摸清底盘,了解用户隐私数据在哪里有哪些,必然可以在市场分得很大一块蛋糕。

肖力最后指出,需求正在倒逼技术的发展。数据安全领域亟需通过技术突破迎来爆发。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

k8s高可用部署:keepalived + haproxy

Young阅读(7196)评论(0)

最近依照网上不少文章部署K8s高可用集群,遇到了一些麻烦,在这里记录下来。

关键问题

根据K8s官方文档将HA拓扑分为两种,Stacked etcd topology(堆叠ETCD)和External etcd topology(外部ETCD)。 https://kubernetes.cn/docs/setup/production-environment/tools/kubeadm/ha-topology/#external-etcd-topology

堆叠ETCD: 每个master节点上运行一个apiserver和etcd, etcd只与本节点apiserver通信。

外部ETCD: etcd集群运行在单独的主机上,每个etcd都与apiserver节点通信。

官方文档主要是解决了高可用场景下apiserver与etcd集群的关系, 三master节点防止单点故障。但是集群对外访问接口不可能将三个apiserver都暴露出去,一个挂掉时还是不能自动切换到其他节点。官方文档只提到了一句“使用负载均衡器将apiserver暴露给工作程序节点”,而这恰恰是生产环境中需要解决的重点问题。

Notes: 此处的负载均衡器并不是kube-proxy,此处的Load Balancer是针对apiserver的。

部署架构

以下是我们在生产环境所用的部署架构:

  1. 由外部负载均衡器提供一个vip,流量负载到keepalived master节点上。
  2. 当keepalived节点出现故障, vip自动漂到其他可用节点。
  3. haproxy负责将流量负载到apiserver节点。
  4. 三个apiserver会同时工作。注意k8s中controller-manager和scheduler只会有一个工作,其余处于backup状态。我猜测apiserver主要是读写数据库,数据一致性的问题由数据库保证,此外apiserver是k8s中最繁忙的组件,多个同时工作也有利于减轻压力。而controller-manager和scheduler主要处理执行逻辑,多个大脑同时运作可能会引发混乱。

下面以一个实验验证高可用性。准备三台机器以及一个vip(阿里云,openstack等都有提供)。

haproxy

haproxy提供高可用性,负载均衡,基于TCP和HTTP的代理,支持数以万记的并发连接。https://github.com/haproxy/haproxy

haproxy可安装在主机上,也可使用docker容器实现。文本采用第二种。

创建配置文件/etc/haproxy/haproxy.cfg,重要配置以中文注释标出:

#---------------------------------------------------------------------
# Example configuration for a possible web application.  See the
# full configuration options online.
#
#   https://www.haproxy.org/download/2.1/doc/configuration.txt
#   https://cbonte.github.io/haproxy-dconv/2.1/configuration.html
#
#---------------------------------------------------------------------

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    # to have these messages end up in /var/log/haproxy.log you will
    # need to:
    #
    # 1) configure syslog to accept network log events.  This is done
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in
    #    /etc/sysconfig/syslog
    #
    # 2) configure local2 events to go to the /var/log/haproxy.log
    #   file. A line like the following can be added to
    #   /etc/sysconfig/syslog
    #
    #    local2.*                       /var/log/haproxy.log
    #
    log         127.0.0.1 local2

#    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
#    user        haproxy
#    group       haproxy
    # daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend  kubernetes-apiserver
    mode tcp
    bind *:9443  ## 监听9443端口
    # bind *:443 ssl # To be completed ....

    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js

    default_backend             kubernetes-apiserver

#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend kubernetes-apiserver
    mode        tcp  # 模式tcp
    balance     roundrobin  # 采用轮询的负载算法
# k8s-apiservers backend  # 配置apiserver,端口6443
 server master-10.53.61.195 10.53.61.195:6443 check
 server master-10.53.61.43 10.53.61.43:6443 check
 server master-10.53.61.159 10.53.61.159:6443 check

分别在三个节点启动haproxy

docker run -d --name=diamond-haproxy --net=host  -v /etc/haproxy:/etc/haproxy:ro haproxy:2.1.2-1

keepalived

keepalived是以VRRP(虚拟路由冗余协议)协议为基础, 包括一个master和多个backup。 master劫持vip对外提供服务。master发送组播,backup节点收不到vrrp包时认为master宕机,此时选出剩余优先级最高的节点作为新的master, 劫持vip。keepalived是保证高可用的重要组件。

keepalived可安装在主机上,也可使用docker容器实现。文本采用第二种。(https://github.com/osixia/docker-keepalived)

配置keepalived.conf, 重要部分以中文注释标出:

global_defs {
   script_user root 
   enable_script_security

}

vrrp_script chk_haproxy {
    script "/bin/bash -c 'if [[ $(netstat -nlp | grep 9443) ]]; then exit 0; else exit 1; fi'"  # haproxy 检测
    interval 2  # 每2秒执行一次检测
    weight 11 # 权重变化
}

vrrp_instance VI_1 {
  interface eth0

  state MASTER # backup节点设为BACKUP
  virtual_router_id 51 # id设为相同,表示是同一个虚拟路由组
  priority 100 #初始权重
nopreempt #可抢占

  unicast_peer {

  }

  virtual_ipaddress {
    10.53.61.200  # vip
  }

  authentication {
    auth_type PASS
    auth_pass password
  }

  track_script {
      chk_haproxy
  }

  notify "/container/service/keepalived/assets/notify.sh"
}
  1. vrrp_script用于检测haproxy是否正常。如果本机的haproxy挂掉,即使keepalived劫持vip,也无法将流量负载到apiserver。
  2. 我所查阅的网络教程全部为检测进程, 类似killall -0 haproxy。这种方式用在主机部署上可以,但容器部署时,在keepalived容器中无法知道另一个容器haproxy的活跃情况,因此我在此处通过检测端口号来判断haproxy的健康状况。
  3. weight可正可负。为正时检测成功+weight,相当与节点检测失败时本身priority不变,但其他检测成功节点priority增加。为负时检测失败本身priority减少。
  4. 另外很多文章中没有强调nopreempt参数,意为不可抢占,此时master节点失败后,backup节点也不能接管vip,因此我将此配置删去。

分别在三台节点启动keepalived:

docker run --cap-add=NET_ADMIN --cap-add=NET_BROADCAST --cap-add=NET_RAW --net=host --volume /home/ubuntu/keepalived.conf:/container/service/keepalived/assets/keepalived.conf -d osixia/keepalived:2.0.19 --copy-service

查看keepalived master容器日志:

# docker logs cc2709d64f8377e8
Mon Mar 16 02:26:37 2020: VRRP_Script(chk_haproxy) succeeded # haproxy检测成功
Mon Mar 16 02:26:37 2020: (VI_1) Changing effective priority from 100 to 111 # priority增加
Mon Mar 16 02:26:41 2020: (VI_1) Receive advertisement timeout
Mon Mar 16 02:26:41 2020: (VI_1) Entering MASTER STATE
Mon Mar 16 02:26:41 2020: (VI_1) setting VIPs. # 设置vip 
Mon Mar 16 02:26:41 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:26:41 2020: (VI_1) Sending/queueing gratuitous ARPs on eth0 for 10.53.61.200
Mon Mar 16 02:26:41 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:26:41 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:26:41 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:26:41 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
I'm the MASTER! Whup whup.

查看master vip:

# ip a|grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.53.61.159/24 brd 10.53.61.255 scope global eth0
    inet 10.53.61.200/32 scope global eth0

可以看到vip已绑定到keepalived master

下面进行破坏性测试:

暂停keepalived master节点haproxy

docker stop $(docker ps -a | grep haproxy)

查看keepalived master日志

# docker logs cc2709d64f8377e8
Mon Mar 16 02:29:35 2020: Script `chk_haproxy` now returning 1
Mon Mar 16 02:29:35 2020: VRRP_Script(chk_haproxy) failed (exited with status 1)
Mon Mar 16 02:29:35 2020: (VI_1) Changing effective priority from 111 to 100
Mon Mar 16 02:29:38 2020: (VI_1) Master received advert from 10.53.61.195 with higher priority 101, ours 100
Mon Mar 16 02:29:38 2020: (VI_1) Entering BACKUP STATE
Mon Mar 16 02:29:38 2020: (VI_1) removing VIPs.
Ok, i'm just a backup, great.

可以看到haproxy检测失败,priority降低,同时另一节点10.53.61.195 priority 比master节点高,master置为backup

查看10.53.61.195 keepalived日志:

# docker logs 99632863eb6722
Mon Mar 16 02:26:41 2020: VRRP_Script(chk_haproxy) succeeded
Mon Mar 16 02:26:41 2020: (VI_1) Changing effective priority from 90 to 101
Mon Mar 16 02:29:36 2020: (VI_1) received lower priority (100) advert from 10.53.61.159 - discarding
Mon Mar 16 02:29:37 2020: (VI_1) received lower priority (100) advert from 10.53.61.159 - discarding
Mon Mar 16 02:29:38 2020: (VI_1) received lower priority (100) advert from 10.53.61.159 - discarding
Mon Mar 16 02:29:38 2020: (VI_1) Receive advertisement timeout
Mon Mar 16 02:29:38 2020: (VI_1) Entering MASTER STATE
Mon Mar 16 02:29:38 2020: (VI_1) setting VIPs.
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: (VI_1) Sending/queueing gratuitous ARPs on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: (VI_1) Received advert from 10.53.61.43 with lower priority 101, ours 101, forcing new election
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: (VI_1) Sending/queueing gratuitous ARPs on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
Mon Mar 16 02:29:38 2020: Sending gratuitous ARP on eth0 for 10.53.61.200
I'm the MASTER! Whup whup.

可以看到10.53.61.195被选举为新的master。

至此高可用实验完成,接下来就是使用kubeadm安装k8s组件,这里就不展开了。

深度解读!阿里统一应用管理架构升级的教训与实践

alicloudnative阅读(736)评论(0)

作者 | 李响、张磊

从 2019 年初开始,阿里巴巴云原生应用平台团队开始逐步在整个阿里经济体内,基于标准应用定义与交付模型进行应用管理产品与项目统一架构升级的技术工作。

事实上,早在 2018 年末,当 Kubernetes 项目正式成为阿里巴巴的应用基础设施底盘之后,阿里内部以及阿里云产品线在应用管理领域的碎片化问题就开始日渐凸显出来。

尤其是在云原生生态日新月异的今天,阿里巴巴与阿里云的应用管理产品架构(包括阿里内部 PaaS 和云上 PaaS 产品),如何以最佳姿态拥抱云原生生态、如何以最高效的技术手段借助生态日新月异的能力构建出更强大的 PaaS 服务,而不是重复造轮子甚至和生态“背道而驰”,很快就成为了阿里团队亟待解决的重要技术难题。

但棘手的是,这个问题并不是简单把 PaaS 迁移或者集成到 Kubernetes 上来就能够解决的:PaaS 与 Kubernetes 之间,从来就没有存在这样一条清晰的分界线,可是 Kubernetes 本身又并不是面向最终用户设计的。

如何既让全公司的研发和运维充分享受云原生技术体系革新带来的专注力与生产力提升,又能够让现有 PaaS 体系无缝迁移、接入到 Kubernetes 大底盘当中,还要让新的 PaaS 体系把 Kubernetes 技术与生态的能力和价值最大程度的发挥出来,而不是互相“屏蔽”甚至“打架”?这个“既要、又要、还要”的高标准要求,才是解决上述 “Kubernetes vs PaaS” 难题的关键所在。

什么是“应用模型”?

在 2019 年 10 月,阿里巴巴宣布联合微软共同推出开放应用模型项目(Open Application Model – OAM),正是阿里进行自身应用管理体系标准化与统一架构升级过程中,逐步演进出来的一项关键技术。

所谓“应用模型”,其实是一个专门用来对云原生应用本身和它所需运维能力进行定义与描述的标准开源规范。所以对于 Kubernetes 来说,OAM 即是一个标准的“应用定义”项目(类比已经不再活跃的 Kubernetes Application CRD 项目),同时也是一个专注于封装、组织和管理 Kubernetes 中各种“运维能力”、以及连接“运维能力”与“应用”的平台层项目。而通过同时提供“定义应用”和“组织管理应用的运维能力”这两大核心功能,OAM 项目自然成为了阿里巴巴进行统一应用架构升级和构建下一代 PaaS/Serverless 过程中“当仁不让”的关键路径。

此外,OAM 模型并不负责应用和能力的具体实现,从而确保了它们都是由 Kubernetes 本身直接提供的 API 原语和控制器实现。所以, OAM 也成为了当前阿里构建 Kubernetes 原生 PaaS 的一项主要手段。

在 OAM 中,一个应用程序包含三个核心理念:

  • 第一个核心理念是组成应用程序的组件(Component),它可能包含微服务集合、数据库和云负载均衡器;
  • 第二个核心理念是描述应用程序运维特征(Trait)的集合,例如,弹性伸缩和 Ingress 等功能。它们对应用程序的运行至关重要,但在不同环境中其实现方式各不相同;
  • 最后,为了将这些描述转化为具体的应用程序,运维人员使用应用配置(Application Configuration)来组合组件和相应的特征,以构建应部署的应用程序的具体实例。

阿里巴巴在 OAM 这个项目中融入了大量互联网规模场景中管理 Kubernetes 集群和公共云产品方面的实际经验,特别是阿里从原先不计其数的内部应用 CRD 转向基于 OAM 的标准应用定义过程中的诸多收获。作为工程师,我们从过去的失败和错误中吸取教训,不断开拓创新、发展壮大。

在本文中,我们将会详细分享 OAM 项目背后的动机和推动力,希望能够帮助更多人更好地了解这个项目。

背景

1. 关于我们

我们是阿里巴巴的“基础设施运维人员”,或者说 Kubernetes 团队。具体来说,我们负责开发、安装和维护各种 Kubernetes 级别的功能。具体工作包括但不限于维护大规模的 K8s 集群、实现控制器/Operator,以及开发各种 K8s 插件。在公司内部,我们通常被称为“平台团队(Platform Builder)”。

不过,为了与兄弟团队区分,即那些在我们之上基于 K8s 构建的 PaaS 工程人员区分,我们在本文中将自称为“基础设施运维人员(Infra Operator)”。过去几年里,我们已通过 Kubernetes 取得了巨大成功,并在使用过程中通过出现的问题获取了宝贵的经验教训。

2. 我们管理各种 Kubernetes 集群

毫无疑问,我们为阿里巴巴电商业务维护着世界上最大、最复杂的 Kubernetes 集群,这些集群:

  • 可纵向扩展至 1 万个节点;
  • 运行 1 万多种应用程序;
  • 在高峰期每天处理 10 万次应用部署。

同时,我们还协助支持着阿里云的 Kubernetes 服务(ACK),该服务类似于面向外部客户的其他公有云 Kubernetes 产品,其中包含大量集群(约 1 万个),不过通常均为小型或中型的集群。我们的内部和外部客户在工作负载管理方面的需求和用例非常多样化。

3. 我们服务的对象是“运维”;而运维的服务对象是“研发”

与其他互联网公司类似,阿里巴巴的技术栈由基础设施运维人员、应用运维人员和业务研发人员合作完成。业务研发和应用运维人员的角色可以概括如下:

业务研发人员

以代码形式传递业务价值。大多数业务研发都对基础设施或 K8s 不甚了解,他们与 PaaS 和 CI 流水线交互以管理其应用程序。业务研发人员的生产效率对公司而言价值巨大。

应用运维人员

为业务研发人员提供有关集群容量、稳定性和性能的专业知识,帮助业务研发人员大规模配置、部署和运行应用程序(例如,更新、扩展、恢复)。请注意,尽管应用运维人员对 K8s 的 API 和功能具有一定了解,但他们并不直接在 K8s 上工作。在大多数情况下,他们利用 PaaS 系统为业务研发人员提供基础 K8s 功能。在这种情况下,许多应用运维人员实际上也是 PaaS 工程人员。

总之,像我们这样的基础设施运维人员为应用运维人员提供服务,他们随之为业务研发人员提供服务。

合作问题

综上所述,这三方显然拥有不同的专业知识,但他们却需要协调一致以确保顺利工作。这在 Kubernetes 的世界里可能很难实现!

我们将在下面的章节中介绍不同参与方的痛点,但简而言之,我们面临的根本问题是不同参与方之间缺乏一种标准化的方法来进行高效而准确的交互。这会导致低效的应用程序管理流程,甚至导致运行失败。

而标准应用模型正是我们解决此问题的关键方法。

基础设施运维人员和应用运维人员之间的交互

Kubernetes 具有高度的可扩展性,使得基础设施运维人员能够随心所欲地构建自己的运维功能。但 Kubernetes 巨大的灵活性也是一把双刃剑:这些功能的用户(即应用运维人员)会遇到一些棘手的问题。

举例来说,在阿里巴巴,我们开发了 CronHPA CRD 以根据 CRON 表达式扩展应用程序。当应用程序的水平扩展策略希望在白天和晚上有所不同时,这非常有用。CronHPA 是一种可选功能,仅在集群中按需部署。

CronHPA 的 yaml 示例如下所示:

apiVersion: “app.alibaba.com/v1”
kind: CronHPA
metadata:
  name: cron-scaler
spec:
  timezone: America/Los_Angeles
  schedule:
  - cron: ‘0 0 6 * * ?’
    minReplicas: 20
    maxReplicas: 25
  - cron: ‘0 0 19 * * ?’
    minReplicas: 1
    maxReplicas: 9
  template:
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        name: php-apache
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50

这是一个典型的 Kubernetes 自定义资源(CRD),可以直接安装使用。

但是,当我们把这些功能交付出去,应用运维人员开始使用诸如 CronHPA 等自定义插件时,他们很快就遇到麻烦了:

1. 这些 K8s 自定义功能的使用方法不明确。

应用运维人员经常抱怨这些插件功能的使用方法(也就是 spec) 分布的非常随意。它有时位于 CRD 中,有时位于 ConfigMap 中,有时又位于某个随机位置的配置文件中。此外,他们还感到非常困惑:为什么 K8s 中很多插件(例如,CNI 和 CSI 插件)的 CRD 并不是对应的能力(例如:网络功能和存储功能)描述,而只是那些插件本身的安装说明?

2. 很难确认 K8s 集群中是否存在某项具体能力。

应用运维人员对某项运维能力是否已在集群中准备就绪毫无把握,尤其是当该能力是新开发的插件提供时更是如此。基础设施运维人员和应用运维人员之间需要进行多轮沟通,才能澄清这些问题。

除上述可发现性问题外,还有一个与可管理性相关的额外难题。

3. 运维能力之间的冲突可能会相当麻烦。

K8s 集群中的运维能力之间的关系可以概括为以下三类:

  • 正交 —— 能力彼此独立。例如,Ingress 用于流量管理,持久性存储用于存储管理;
  • 可组合 —— 多个能力可以协同应用于同一应用程序。例如,Ingress 和 Rollout:Rollout 升级应用程序并控制 Ingress 以便实现渐进式流量切换;
  • 冲突 —— 多个能力不能应用于同一应用程序。例如,如果将 HPA 和 CronHPA 应用于同一应用程序,则会彼此冲突。

正交和可组合能力相对安全。然而,互相冲突的功能可能导致意外/不可预测的行为。

这里的问题在于, Kubernetes 很难事先向应用运维人员发送冲突警告。因此,他们可能会对同一应用程序使用彼此冲突的两个运维能力。而当实际发生冲突时,解决冲突会产生高昂的成本,在极端情况下,这些冲突会导致灾难性的故障。当然,在管理平台能力时,应用运维人员显然不希望面临“头顶悬着达摩克里斯之剑”的情况,因此希望找到一种更好的方法来提前避免冲突情况。

应用运维人员如何发现和管理可能相互冲突的运维能力?换而言之,作为基础设施运维人员,我们能否为应用运维人员构建可发现且易管理的运维能力呢?

OAM 中的运维特征(Trait)

在 OAM 中,我们通过“运维特征(Trait)”来描述和构建具备可发现性和可管理性的平台层能力。

这些平台层能力实质上是应用程序的运维特征,而这正是 OAM 中“Trait”这个名称的来历。

1. 打造可发现的运维能力

在阿里的 K8s 集群中,大多数 Trait 都由基础设施运维人员定义,并使用 Kubernetes 中的自定义控制器实现,例如:

  • Ingress
  • Auto-scaler
  • Volume-mounter
  • Traffic-shifting、Security-policy 等

请注意, Trait 并不等同于 K8s 插件。比如:一个集群可具有多个网络相关 Trait ,如“动态 QoS  Trait ”、“带宽控制 Trait ”和“流量镜像 Trait ”,这些 Trait 均由一个 CNI 插件提供。

实际上, Trait 安装在 K8s 集群中,并供应用运维人员使用。将能力作为 Trait 呈现时,应用运维人员使用简单的 kubectl get 命令即可发现当前集群支持的运维能力:

$ kubectl get traitDefinition
NAME                AGE
cron-scaler         19m
auto-scaler         19m

上面的示例显示此集群支持两种 “scaler” 能力。用户可以将需要基于 CRON 的扩展策略的应用程序部署到该集群。

Trait 提供给定运维能力的结构化描述。

这使应用运维人员通过简单的 kubectl describe 命令即可轻松准确地理解特定能力,而不必深入研究其 CRD 或文档。能力描述包括“此 Trait 适用于何种工作负载”和“它的使用方式”等。

例如,kubectl describe traitDefinition cron-scaler:

apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name: cron-scaler
spec:
  appliesTo:
    - core.oam.dev/v1alpha1.ContainerizedWorkload
  definitionRef:
    name: cronhpas.app.alibaba.com

请注意,在 OAM 中, Trait 通过 definitionRef 引用 CRD 来描述其用法,同时也与 K8s 的 CRD 解耦。

Trait 采用了规范与实现分离的设计,同样一个 Trait 的 spec,可以被不同平台不同环境完全基于不同的技术来实现。通过引用的方式,实现层既可以对接到一个已有实现的 CRD,也可以对接到一个统一描述的中间层,底下可插拔的对接不同的具体实现。考虑到 K8s 中的一个特定的能力比如 Ingress 可能有多达几十种实现,这种规范与实现分离的思想会非常有用。Trait 提供了统一的描述,可帮助应用运维人员准确理解和使用能力。

2. 打造可管理的运维能力

应用运维人员通过使用 ApplicationConfiguration(将在下一部分中详细介绍),对应用程序配置一个或多个已安装的 Trait 。ApplicationConfiguration 控制器将处理 Trait 冲突(如果有)。

我们以此示例 ApplicationConfiguration 为例:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: failed-example
spec:
  components:
    - name: nginx-replicated-v1
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.alibabacloud.com/v1
            kind: CronHPA
            spec:            
              timezone: "America/Los_Angeles"
              schedule: "0 0 6 * * ?"
              cpu: 50
              ...

在 OAM 中,ApplicationConfiguration 控制器必须保证这些 Trait 之间的兼容性,如果不能满足要求,应用的部署就会立刻失败。所以,当运维人员将上述 YAML 提交给 Kubernetes 时,由于“Trait 冲突”,OAM 控制器将会报告部署失败。这就使得应用运维人员能够提前知道有运维能力冲突,而不是在部署失败后大惊失色。

总的来说,我们团队不提倡提供冗长的维护规范和运维指南(它们根本无法防止应用运维人员出错),我们倾向于是使用 OAM  Trait 来对外暴露基于 Kubernetes 的可发现和可管理的运维能力。这使我们的应用运维人员能够“快速失败”,并满怀信心地组合运维能力来构建无冲突的应用运维解决方案,这就像玩“乐高积木”一样简单。

应用运维人员和业务研发之间的交互

Kubernetes 的 API 对象并不关心自己的使用者到底是运维还是研发。这意味着任何人都可能对一个 Kubernetes API 对象中的任何字段负责。这也称为“all-in-one”的 API,它使得新手很容易上手。

但是,当具有不同关注点的多个团队必须在同一个 Kubernetes 集群上展开协作时,特别是当应用运维人员和业务研发人员需要在相同 API 对象上展开协作时,all-in-one API 缺点就会凸显出来。

让我们先来看一个简单的 Deployment YAML 文件:

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      deploy: example
  template:
    metadata:
      labels:
        deploy: example
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          securityContext:
            allowPrivilegeEscalation: false

在我们的集群中,应用运维人员与业务研发人员需要面对面开会来填写这个 yaml 文件。这种合作既耗时又复杂,但我们别无选择。原因何在?

“抱歉,这个字段与我无关”

显而易见,这里最直接的方法是让业务研发人员自己填写 Deployment yaml。但是,业务研发人员可能会发现 Deployment 里的某些字段与他们的关注点没有丝毫关联。例如:

有多少业务研发人员知道 allowPrivilegeEscalation 是什么意思?

事实上,很少有业务研发人员知道,在生产环境里,这个字段务必要设置为 false (默认是 true),才能确保应用程序在宿主机中具有合理的权限。在实践中,这个字段只能应用运维人员配置。而现实是,一旦把整个 Deployment 暴露给业务研发填写,这些字段最终就会沦为“猜谜游戏”,甚至完全被业务研发人员忽视。

这个字段到底是研发还是运维负责?

如果你了解 K8s 的话,就一定会发现 K8s 中有大量的 API 字段很难说清楚到底是应该由研发还是运维来填写。

例如,当业务研发人员设置 Deployment 的 replicas:3 时,他会假设该数字在应用程序生命周期中固定不变。

但是,大多数业务研发人员并不知道 Kubernetes 的 HPA 控制器可以接管该字段,并可能会根据 Pod 负载改变 replicas 的值。这种由系统自动化流程带来的变更很容易导致问题:这意味着当业务研发人员想要更改副本数时,他对 replicas 的修改可能根本不会生效。

在此种情况下,一个 Kubernetes 的 YAML 文件就不能表示工作负载的最终状态,从业务研发人员角度而言,这非常令人困惑。我们曾尝试使用 fieldManager 来处理此问题,但 fieldManager 进行冲突解决的过程仍颇具挑战性,因为我们很难弄清这些冲突方的修改目的。

“割裂研发与运维”能否解决上述问题?

如上所示,当使用 K8s API 时,业务研发人员和运维人员的关注点会不可避免地被混在一起。这使得多个参与方可能很难基于同一个 API 对象展开协作。

此外,我们也发现,阿里内部的很多应用程序管理系统(如 PaaS)并不愿意暴露 K8s 的全部能力,显然他们并不希望向业务研发人员暴露更多的 Kubernetes 概念。

对于上述问题,最简单的解决方案是在业务研发人员和运维人员之间划一条“明确的界限”。例如,我们可以仅允许业务研发人员设置 Deployment yaml 的一部分字段(这正是阿里很多 PaaS 曾经采用的办法)。但是,这种“割裂研发与运维”的解决方案可能并不奏效。

运维需要听取业务研发人员的意见

在很多情况下,业务研发人员都希望运维人员听取他们的一些关于运维的“意见”。

例如,假定业务研发人员为应用程序定义了 10 个参数,然后他们发现应用运维人员可能会覆盖这些参数以适配不同的运行环境的差异。那么问题来了:业务研发如何才能做到仅允许运维人员修改其中特定的 5 个参数?

实际上,如果采用“割裂研发与运维”应用管理流程,要传达业务研发人员的运维意见将变得难上加难。这样类似的例子有许多,业务研发人员可能希望表述很多关于他们的应用程序的信息:

  • 无法水平扩展(即单一实例);
  • 是一个批处理作业,而不是长运行的服务;
  • 需要最高级别的安全性等等。

上述所有这些请求都是合理的,因为只有业务研发人员才是最了解应用程序的那个人。这就提出了一个我们亟待解决的重要问题:我们的 Kubernetes 能否既为业务研发和运维人员提供单独的 API,同时又允许业务研发人员有效传达自己对运维的诉求?

OAM 中的 Component 和 ApplicationConfiguration

在 OAM 中,我们从逻辑上对 K8s 的 API 对象进行了拆分,并且做到了既使得业务研发人员能够填写属于自己的那些字段,同时又能有条理地向运维人员传达诉求。

定义你的应用程序,而不是仅仅描述它。

1. Component

在 OAM 中,Component(组件) 就是一个完全面向业务研发人员设计的、用于定义应用程序而不必考虑其运维详细信息的载体。一个应用程序包含一个或多个 Component 。例如,一个网站应用可以由一个 Java web 组件和一个数据库组件组成。

以下是业务研发人员为 Nginx 部署定义的 Component 示例:

1.png

OAM 中的 Component 包含两个部分:

  • 工作负载描述 —— 如何运行此 Component,以及它的运行内容,实际上就是一个完整的 K8s CR;
  • 可重写参数列表 —— 研发通过这个字段表示该 Component 的哪些字段后续可以被运维或者系统覆盖。

在 Component 中,workload 字段可以直接向运维人员传达业务研发人员关于如何运行其应用程序的说明。同时,OAM 围绕容器应用定义了一种核心工作负载 ContainerizedWorkload,涵盖了云原生应用程序的典型模式。

与此同时,OAM 可以通过定义扩展工作负载来自由声明用户自己的工作负载类型。在阿里巴巴,我们在很大程度上依赖于扩展工作负载来使业务研发人员定义阿里云服务 Component ,例如,阿里云函数计算 Component 等。

请注意,在上面的示例中,业务研发人员不再需要设置副本数;因为这并不是他所关注的字段:他选择让 HPA 或应用运维人员完全控制副本数的值。

总体来说,Component 允许业务研发人员使用自己的方式定义应用程序的声明式描述,但同时也为他/她提供了随时向运维人员准确传达意见或信息的能力。这些信息包括对运维的诉求,例如,“如何运行此应用程序”和“可重写参数”。

2. ApplicationConfiguration

最终,通过引用 Component 名称并对它绑定 Trait ,运维人员就可以使用 ApplicationConfiguration 来实例化应用程序。

使用 Component 和 ApplicationConfiguration 的示例协作工作流:

  • Kubernetes 里安装了各种工作负载类型(workloadType);
  • 业务研发人员使用所选工作负载类型定义一个 component.yaml;
  • 然后,应用运维人员(或 CI / CD 系统)运行 kubectl apply -f component.yaml 来安装此 Component;
  • 应用运维人员接下来使用 app-config.yaml 来定义 ApplicationConfiguration 以实例化应用程序;
  • 最后,应用运维人员运行 kubectl apply -f app-config.yaml 以触发整个应用程序的部署。

这个 app-config.yaml 文件的内容如下所示:

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-awesome-app
spec:
  components:
    - componentName: nginx
      parameterValues:
        - name: connections
          value: 4096
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.aliaba.com/v1
            kind: SecurityPolicy
            spec:           
                allowPrivilegeEscalation: false

我们来重点说明以上 ApplicationConfiguration YAML 中的一些详细信息:

  • parameterValues —— 供运维人员使用,用于将 connections 值重写为 4096,在该组件中,该值最初为 1024。请注意,运维人员必须填写整数 4096,而不是字符串 “4096”,因为此字段的 schema 已在 Component 中明确定义;
  • Trait  AutoScaler —— 供运维人员使用,用于将 autoscaler  Trait (如 HPA)绑定给 Component 。因此,其副本数将完全由 autoscaler 控制;
  • Trait SecurityPolicy —— 供运维人员使用,用于将安全策略规则应用于 Component。请注意,运维人员还可以修改 Trait 列表以绑定更多 Trait。例如,“Canary Deployment Trait ”意味着这个应用程序在后期升级过程中遵循金丝雀发布策略。

实质上,ApplicationConfiguration 的主要功能,就是让应用运维人员(或系统)了解和使用业务研发人员传达的信息,然后自由的为 Component 组合绑定不同的运维能力以相应实现其最终的运维目的。

并不止是应用管理

综上所述,我们使用 OAM 的主要目标是解决应用程序管理中的以下问题:

  • 如何在 Kubernetes 中构建可发现、可组合和可管理的运维能力;
  • 如何使 Kubernetes 中的多个参与方围绕同一个 API 对象准确有效地协作。

所以说,对于阿里巴巴来说,OAM 其实是阿里巴巴 Kubernetes 团队提出的一种 Application CRD 规范,从而使得所有参与者可以采用结构化的标准方法来定义应用程序及其运维能力。

阿里巴巴开发 OAM 的另一个强大动力,则是在混合云和多环境中进行软件分发与交付。随着 Google Anthos 和 Microsoft Arc 的出现,我们已然看到 Kubernetes 正成为新的 Android,并且云原生生态系统的价值正迅速转移到应用层的趋势。我们将在以后讨论这一主题。

本文中的实际使用案例由阿里云原生团队和蚂蚁金服共同提供。

OAM 的未来

目前,OAM 规范和模型实际已解决许多现有问题,但它的路程才刚刚开始。例如,我们正在研究使用 OAM 处理组件依赖关系、在 OAM 中集成 Dapr 工作负载等。

我们期待在 OAM 规范及其 K8s 实现方面与社区展开协作。OAM 是一个中立的开源项目,其所有贡献者都应遵循非营利性基金会的 CLA。

目前,阿里巴巴团队正在上游贡献和维护这套技术,如果大家有什么问题或者反馈,也非常欢迎与我们在上游或者钉钉联系。

参与方式:

  • 钉钉扫码进入 OAM 项目中文讨论群

2.png

作者简介
李响,阿里云资深技术专家。他在阿里巴巴从事集群管理系统工作,并协助推动阿里巴巴集团内的 Kubernetes 采用。在效力于阿里巴巴之前,李响曾是 CoreOS Kubernetes 上游团队的负责人。他还是 etcd 和 Kubernetes Operator 的创建者。

张磊,阿里云高级技术专家。他是 Kubernetes 项目的维护者之一。张磊目前在阿里的 Kubernetes 团队工作,其工作领域包括 Kubernetes 和云原生应用管理系统。

有一个阿里团队需要你!

云原生应用平台诚邀 Kubernetes / Serverless / PaaS / 应用交付领域专家( P6-P8 )加盟:

  • 工作年限:建议 P6-7 三年起,P8 五年起,具体看实际能力;
  • 工作地点:国内(北京 / 杭州 / 深圳);海外(旧金山湾区 / 西雅图);
  • 岗位包含:架构师、技术专家、全栈工程师等。

简历立刻回复,2~3 周出结果,简历投递:jianbo.sjb AT alibaba-inc.com。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

Artifactory清理未使用的二进制品的最佳实践

JFrogchina阅读(641)评论(0)

Artifactory充分利用了基于Checksum的存储,但是这种机制无法代替常规的工件清理任务。软件开发可能很杂乱,很多时候Artifactory中的许多工件都从未使用过。

例如,许多CI / CD构建都配置为基于源代码控制“提交”运行,并且一旦将这些快照构建发送到Artifactory,就永远不会实际下载它们。

考虑到软件开发的动态性质,大多数组织都有自己的数据保留策略。由您决定可以清除哪些数据,但是内置工具可以覆盖大多数情况。

通常,在Artifactory中使用三种技术来管理工件存储:

–限制保留多少SNAPSHOT
–清除超大缓存
–删除未使用的工件

限制保留多少SNAPSHOT

Artifactory具有内置机制来限制构建的“快照”。该系统的目的是确保在覆盖“release”工件之前将其从“snapshots”存储库中升级出来。

Artifactory支持六种存储库类型的“最大唯一快照”标记:

– Maven  – NuGet
– Gradle  –Ivy
– Docker  – SBT

 

Artifactory使用Artifactory Layout系统跟踪快照的数量。这意味着用户在上载快照工件时需要遵循预定义的模式(大多数客户端会自动处理)。

例如,此Maven JAR文件被识别为快照运行编号3的一部分:

jfrog / hello / 1.0.5-SNAPSHOT / hello-1.0.5-20190620.224837-3.jar  

 

大多数CLI客户端使用特定模式进行上传,Artifactory的默认布局应涵盖这些情况。您可以根据需要自定义这些存储库类型的布局,以处理自定义上传路径。

要在Artifactory中启用此功能,请更新本地存储库设置:

启用此设置后,在“最大唯一快照数”上方进行的上传将在下次构建运行期间删除所有较早的发行版。

最高的数字将始终是最新版本。

清除超大缓存

Artifactory的远程存储库将下载的文件存储在缓存中。通常,保留整个缓存是有益的,因为它可以加快下载速度。但是,如果项目使用的工件有所更改,则值得定期清除缓存。

在Artifactory中有支持此功能的内置系统。要启用自动缓存清除,请转到远程存储库菜单的“高级”部分。

您可以在“ 未使用的工件清理期部分中添加清理工件之前的小时数:

这并不意味着工件会在12小时后被删除。相反,它在内部将工件标记为“未使用”。

在“ 管理员”->“高级”->“维护 ” 下找到一个单独的作业,称为“清理未使用的缓存工件”,它将执行清理。默认情况下,此cron作业每天运行一次。

删除未使用的工件

通常,Artifactory通常不会自动删除二进制文件。也有例外,例如本文中已讨论的字段。

话虽如此,通过删除长时间未下载的工件可以节省大量存储空间。自动清除未使用的文件的最佳方法是实施Artifactory User Plugin。

JFrog开发的最受欢迎的用户插件之一是“ artifactCleanup”插件。该插件在Cron Job上运行,并自动删除“ X”天之内尚未下载的任何工件。

如果您需要进一步自定义插件,则可以在代码中更改Artifactory Query Language语句:

 def aql =“ items.find{” repo“”“ + repoKey +”“” type“” any“” @ cleanup.skip“” true“})。include” repo“” path “名称类型

需要注意的一件事:artifactCleanup在Docker Repositories上不起作用。

Docker映像层作为单独的工件存储在“ image”文件夹中。如果大多数Docker客户端中已经有一个层,则不会经常下载该层。由于行为上的差异,建议使用单独的“ cleanDockerImages”插件。

它依赖manifest.json文件的下载计数,该文件始终在发生“ docker pull”时下载。

 

 

参考资料:

https://jfrog.com/knowledge-base/artifactory-cleanup-best-practices/

 

补充资料:

– AQL清理:

 

https://jfrog.com/blog/advanced-cleanup-using-artifactory-query-language-aql/

 

清理已有数据:通过 Rest API 清理 90 天内无人下载的 snapshot,或者是 90 天以前的所有 snapshot,这样能够大大减少存储量,加快索引速度。

 

https://www.jfrog.com/confluence/display/RTF/Managing+Disk+Space+Usage#ManagingDiskSpaceUsage-ManualCleanupwiththeRESTAPI

 

定期清理新增数据:在页面上配置实时清理 snapshot:

 

https://www.jfrog.com/confluence/display/RTF/Managing+Disk+Space+Usage#ManagingDiskSpaceUsage-LimitingtheNumberofSnapshots

 

更多精彩内容可以专注我们的在线课堂

微信搜索公众号:jfrogchina 获取课程通知