首页 文章 精选 留言 我的

精选列表

搜索[CLI能力],共10000篇文章
优秀的个人博客,低调大师

加强 Kubernetes 能力:利用 CRD 定义多版本资源的实现方式

姚灿武,Rancher 中国研发工程师,拥有 7 年云计算领域经验,热衷开源技术,在云原生相关技术领域拥有丰富的开发和实践经验。 CRD,即自定义资源定义(Custom Resource Definition),是 Kubernetes API 中一个强大的扩展机制。通过 CRD,用户可以定义自己的资源类型,来扩展 Kubernetes 的 API 和资源类型。CRD 定义可以用于创建多个版本的资源,这对于 Kubernetes 集群的演变和升级非常有用。 在本文中,我们将介绍 Kubernetes CRD 的版本概念和使用方法;讨论如何在 CRD 中定义多个版本的资源,并讨论资源数据存储和数据转换的实现方式。最后,我们将介绍如何开发 CRD webhook,以便在 Kubernetes 中实现 CRD 版本兼容。 多版本 CRD 多版本 CRD 是指在 CRD 中定义多个版本的 API,每个版本的 API 可以有自己的规则,这样就可以在不影响旧版本应用程序的情况下,对新版本应用程序进行更新和升级。 要创建多版本 CRD,我们需要定义一个 Custom Resource Definition 对象,该对象包含多个 version 字段。每个 version 字段都有一个 schema,其中包含了自定义资源的属性和规则。 通过一个例子来说明,以下是一个单版本 CRD 示例: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: foos.sample.webhook.io spec: conversion: strategy: None group: sample.webhook.io names: kind: Foo listKind: FooList plural: foos shortNames: - foo - foos singular: foo scope: Namespaced versions: - name: v1 schema: openAPIV3Schema: properties: apiVersion: type: string kind: type: string metadata: type: object type: object served: true storage: true 文件中规定版本信息以及资源的名称、类型等信息。通过 kubectl apply 命令,可以将该 CRD 文件应用到 Kubernetes 集群中,从而在集群中创建一个新的资源类型 Foo,例如: apiVersion: sample.webhook.io/v1 kind: Foo metadata: name: foo-sample 上述自定义资源 Foo 只有一个 v1 版本,如果我们需要更新自定义资源中的某个字段,就需要更新 Foo 的版本,例如更新为 v2 版本,就要在 CRD 文件中添加 v2 版本的定义,例如: apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: foos.sample.webhook.io spec: versions: - name: v1 schema: openAPIV3Schema: properties: apiVersion: type: string kind: type: string metadata: type: object type: object served: true storage: false - name: v2 schema: openAPIV3Schema: properties: alias: type: string apiVersion: type: string kind: type: string metadata: type: object type: object served: true storage: true 在上述 CRD 文件中,我们定义了两个版本,v1 和 v2。v2 相比 v1 新增了一个 alias 字段。 资源数据存储 为确保 Kubernetes 能够正确地将自定义资源持久化到存储中,并且能够正确地从存储中读取和还原自定义资源。CRD 中定义了 spec.versions.storage 字段,用于指示使用哪个版本的 CRD 持久化到存储中。在一个 CRD 定义中,只能有一个版本的 storage 字段的值为 true。 上述例子中,我们定义了两个版本,v1 和 v2。v1 版本 storage 字段为 false,v2 版本 storage 字段为 true,这表明 Kubernetes etcd 中存储的是 v2 版本的资源数据。 那么对于未被选定的版本的数据如何存储呢?以上面foo-sample为例,我们来看下 etcd 中是怎么存储的,结果如下: /registry/sample.webhook.io/foos/default/foo-sample {"apiVersion":"sample.webhook.io/v2","kind":"Foo","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"sample.webhook.io/v1\",\"kind\":\"Foo\",\"metadata\":{\"annotations\":{},\"name\":\"foo-sample\",\"namespace\":\"default\"}}\n"},"creationTimestamp":"2023-05-22T09:49:03Z","generation":1,"managedFields":[{"apiVersion":"sample.webhook.io/v1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:kubectl.kubernetes.io/last-applied-configuration":{}}}},"manager":"kubectl-client-side-apply","operation":"Update","time":"2023-05-22T09:49:03Z"}],"name":"foo-sample","namespace":"default","uid":"3360f129-31f7-4a3f-8991-7694524d9a78"}} 第一行是foo-sample的 key,第二行是foo-samplejson 格式表示的内容,其中apiVersion为sample.webhook.io/v2,这表明即便 v1 版本的资源也以 v2 版本的格式存储。 数据转换 当自定义资源支持多个版本时,因为只能以某一个版本的格式进行存储,所以需要在存储的版本和提供的版本之间进行转换,实现多版本兼容。 如果转换涉及模式变更, 并且需要自定义逻辑,则应该使用 Webhook 来完成。在 CRD 中配置 webhook 示例如下: apiVersion:apiextensions.k8s.io/v1 kind:CustomResourceDefinition ... spec: conversion: strategy:Webhook webhook: clientConfig: caBundle:LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJ2akNDQVdPZ0F3SUJBZ0lCQURBS0JnZ3Foa2pPUFFRREFqQkdNUnd3R2dZRFZRUUtFeE5rZVc1aGJXbGoKYkdsemRHVnVaWEl0YjNKbk1TWXdKQVlEVlFRRERCMWtlVzVoYldsamJHbHpkR1Z1WlhJdFkyRkFNVFk0TkRjegpPRGswTXpBZUZ3MHlNekExTWpJd056QXlNak5hRncwek16QTFNVGt3TnpBeU1qTmFNRVl4SERBYUJnTlZCQW9UCkUyUjVibUZ0YVdOc2FYTjBaVzVsY2kxdmNtY3hKakFrQmdOVkJBTU1IV1I1Ym1GdGFXTnNhWE4wWlc1bGNpMWoKWVVBeE5qZzBOek00T1RRek1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRUZYWDQzaEZRdjRyOApKelR1UkJ0b3lqUmRtWjhIRkExbWZnOXJnTWVlNnVXZ20wMXBNR3lSRnFna3Z1RHF5RUlMTUtCRDduQ2IrVFp3CitBR3loVWhTV0tOQ01FQXdEZ1lEVlIwUEFRSC9CQVFEQWdLa01BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0hRWUQKVlIwT0JCWUVGRzg2VnpCcW1wRUcrUWlrS0d1SGNIQlJwS2R3TUFvR0NDcUdTTTQ5QkFNQ0Ewa0FNRVlDSVFDaQp5SFFyeGNXN3dUM0dwRWhyNklQQWpXWDVJOSt4Y0dkUGQzQURKS0hwZ2dJaEFJQmhTc00xd1hxMU80VUlaWWZwCkNWVkxwaCtvUVMvMzI5OHMwS0VqWW9FTAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== service: name:webhook-sample namespace:default path:/v1/webhook/conversion port:443 conversionReviewVersions: -v1 如果没有模式变更,则可使用默认的None转换策略,为不同版本提供服务时只有apiVersion字段会被改变。 apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition ... spec: ... conversion: strategy: None CRD webhook 开发 与Admission Webhook一样,CRD webhook 也是一个 HTTP 回调,webhook service 就是一个 HTTP 服务。接口结构如下: // ConversionReview describes a conversion request/response. type ConversionReview struct { metav1.TypeMeta `json:",inline"` // request describes the attributes for the conversion request. // +optional Request *ConversionRequest `json:"request,omitempty" protobuf:"bytes,1,opt,name=request"` // response describes the attributes for the conversion response. // +optional Response *ConversionResponse `json:"response,omitempty" protobuf:"bytes,2,opt,name=response"` } Harvester 项目组在harvester webhook框架中增加了 CRD webhook 的支持,开发者只需要实现Converter接口并把它注册到 webhook server 中,然后启动 webhook server 即可。 // Converter is a interface to convert object to the desired version type Converter interface { GroupResource() schema.GroupResource Convert(Object *unstructured.Unstructured, desiredAPIVersion string) (*unstructured.Unstructured, error) } 具体开发细节请参考示例webhook sample。 总 结 在实际产品进化演变过程中,多版本兼容一直是一个重要的问题。Kubernetes CRD 采用选定某一个版本进行持久化,并使用 webhook 实现多版本数据转换的策略来解决多版本兼容性问题。在 Kubernetes 外的其他项目中,这种策略也值得学习借鉴。 参 考 Versions in Custom Resource Definitions:https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning

优秀的个人博客,低调大师

SREWorks v1.1 版本发布 | 组件插拔场景化部署能力

自SREWorks v1.0 版本在3月份开源以来,通过钉钉群、微信群、GitHub等渠道,团队陆续收到了各种反馈。随即团队开始了v1.1版本的功能优化迭代,优先解决用户反馈上来的TOP3问题:存储插拔、最小资源部署、存储类使用,同时针对用户使用过程中暴露出来的小问题也做了相应的优化。 后续产品会持续保持较快的发布频率,快速解决各渠道用户反馈的痛点问题,帮助用户利用SREWorks更好地构建云原生下的数智运维平台。 下面是本次 v1.1 版本发布的新功能介绍: 1. 基础版/数智版 k8s集群的资源消耗让不少尝鲜用户望而却步,因此v1.1版本将基础应用和数智应用部署分离,让用户可以只体验SREWorks的底座平台,而不开启较占用资源的数智化应用。 基础版SREWorks在单台4核16G机器上即可正常启动。 基础应用包含8个应用: 运维中台 应用管理 团队管理 集群管理 模板中心 帮助中心 文件管理 系统设置 数智应用包含7个应用: 数据运维平台 智能运维平台 故障自愈 健康管理 运营中心 作业调度平台 运维搜索 在进行helm部署的时候,传入如下参数即可使用基础版(默认为数智版): --set saas.onlyBase=true 2. 组件插拔: ElasticSearch/MySQL/MinIO 当前不少公司的生产环境下均包含可靠的存储模块,比如ES/MySQL/MinIO等,所以部分用户在部署应用时不希望使用SREWorks v1.0版本中自带的存储模块,而是希望将那些中间件的endpoint直接注入。 团队经过整理和优化,将SREWorks中使用的各种存储模块,抽取出变量支持用户在部署时修改。 在进行helm部署的时候,根据需求传入如下参数即可: # 替换基础应用的主MySQL数据库 # MySQL这块需要注意,通常将主MySQL数据库和数智化MySQL数据库(吞吐较大)分成两个 --set appmanager.server.database.host="*.mysql.rds.aliyuncs.com" --set appmanager.server.database.password="****" --set appmanager.server.database.user="root" --set appmanager.server.database.port=3306 --set appmanagerbase.mysql.enabled=false # 替换数智化应用的MySQL数据库 --set saas.dataops.dbHost="*.mysql.rds.aliyuncs.com" --set saas.dataops.dbUser=root --set saas.dataops.dbPassword="*****" --set saas.dataops.dbPort=3306 # 替换数智化应用的ElasticSearch --set saas.dataops.esHost="*.public.elasticsearch.aliyuncs.com" --set saas.dataops.esPort="9200" --set saas.dataops.esUser="elastic" --set saas.dataops.esPassword="*******" # 替换基础应用的MinIO存储 --set global.minio.accessKey="*******" --set global.minio.secretKey="*******" --set appmanager.server.package.endpoint="minio.*.com:9000" --set appmanagerbase.minio.enabled=false 3. 页面模板中心 低代码的前端开发模式,对于之前没有接触过相关应用的用户依然存在一定的门槛,于是团队借鉴了文档模板的这一概念,将前端组件按照常见的场景类别编排成模板,让用户可以快速导入一个现成的模板页面,在模板之上继续进行前端开发。 同时v1.1版本也支持用户将自己常用的页面保存成模板,提升日常的页面开发效率。 4. 默认存储类支持 很多使用k8s的用户不太清楚StorageClass的使用逻辑,常在这个问题的排查上耗费较多时间。 在综合分析比较了各种社区存储方案后,v1.1版本使用了基于OpenEBS的方案,给用户提供了一个默认的LocalPV方案,减少大家的使用成本。 用户在使用时务必注意,如果使用自己架设的存储集或该k8s集群已经有存储类,请务必将这个默认存储类对应的存储供应openebs关闭,否则容易出现存储目录争抢的问题。 关闭SREWorks默认存储类方案的helm参数如下,以使用阿里云ACK集群的存储类alicloud-disk-available为例: --set appmanagerbase.openebs.enabled=false --set global.storageClass="alicloud-disk-available" 5. 其他优化 解决后端微服务的编辑页面报错 增加后端微服务的默认鉴权开关 解决运维应用删除报错 解决appmanager多次初始化的幂等异常 解决在慢数据库场景下productopsv2导入时候的报错(针对NFS慢数据库场景同样有效) 数据源密码框采用密码输入 6.如何从当前版本升级到v1.1 升级包含底座,故可能页面会有5-10分钟的不可访问,请注意。 用户自行开发的云原生应用不会受影响(不重启),SREWorks网关到应用的流量会有中断。 git clone http://github.com/alibaba/sreworks.git -b v1.1 sreworks cd sreworks./sbin/upgrade-cluster.sh --kubeconfig="****" 如在使用过程中遇到问题,欢迎各位在GitHub中提出Issues或Pull requests。 SREWorks开源地址: https://github.com/alibaba/sreworks 更多开源项目合集: https://www.aliyun.com/activity/bigdata/opensource_bigdata__ai

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册