目前越来越多的客户使用并购买了华为云会议的SmartRooms大屏设备，它可以同样加入到华为云会议中，通过RESTful API调用的方式将设备拉入会议中，满足企业多场景自定义下的使用问题。SmartRooms激活具体步骤可参考链接：https://support.huaweicloud.com/smartroom-meeting/toctopics/zh-cn_topic_0000001167929241.html调用服务端查询企业通讯录接口serchKey字段中填写SmartRooms的名称，便于搜索响应样例获取到sip号码后，可以通过创建会议接口自动邀请或者会中邀请与会人添加SmartRooms到会议中SmartRooms可设置来电自动接听（可选）

作者：包宜强（华为云开天aPaaS专家）API是一种使用公开的系统功能而不是 UI 从系统访问信息的方法。API允许人们创建与系统交互的应用程序或在现有系统之上创建新的应用程序/UI。这时候您需要属性API接口定义/协议，使用不同语言的开发工具去调用它们，使用的是有一定门槛的。有了API，为什么我们还需要用连接器？ 因为API对开发技能有要求啊。我们以笔记本电脑输出视频到电视为例，类比如下所示： 可以看到连接器是在API的基础之上，结合事件和业务场景，进行了封装，并提供了可视化操作UI，降低了使用门槛，例如上面的分别连接到电脑和电视的接头。通过使用连接器您可以避免点对点集成，通过集成应用如流编排组合使用不同的连接器，来访问不同的应用系统。假设您用到制造MES、办公OA系统，这些系统有自己的“语言”，您就需要1个翻译人员，他能打开两个不同系统的钥匙，从而简化这两个系统之间的沟通。 接下来大家可以对API进行组合编排，发布成新API的连接器-API流，通过它，您可以很方便实现场景化API。例如点击 创建流定义组合的API的请求和响应，并添加其它连接器调用不同的API。 例如您有天气API，获取位置信息API，您可以通过API编排，发布一个新的带有位置信息的API，您只要输入位置信息既可返回所在位置的天气，这样的话可以简化API的多次调用。 相关术语：1、连接器对接各类应用/系统的工具，开发者以可编排实例的方式集成第三方系统，无需关注具体代码实现，只需要配置服务地址和鉴权信息。2、操作操作是和对接系统的交互例如使用某个操作在 SQL 数据库中查找、写入、更新或删除数据。3、触发器在发生特定事件时选择某个操作。4、连接连接器存在各种的认证配置信息，而连接就是来保存这些认证信息，只有在配置了连接之后，才可以正常使用连接器。~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~立即体验开天aPaaS集成工作台

CloudLink Kit_21.0.0.6_SDK包含私有api，不能上架App Store被拒原因如下：ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/tsdk_service.framework/tsdk_service: _rdft. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/

CloudLink Kit_21.0.0.6_SDK包含私有api，不能上架App Store被拒原因如下：ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/tsdk_service.framework/tsdk_service: _rdft. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/

Carl M. Kadie喜欢创建软件库。两个月前将一个 Python 包移植到 Rust crate 中。这个新的 Rust crate 与 Python 包的易用性和表现力相匹配。实践中，他学到了九条规则，可以帮助你在 Rust 中创建漂亮的库。规则是：1.创建简洁明了的例子2.改进函数参数使其能够接受更多的类型3.了解你的用户的需求，知道用户到底想要什么4.使用构建器(builder) 来让其可配置化5.写好文档让你的设计更有诚意6.定义 From 来接收常见类型7.编写API测试8.定义并返回有意义的错误9.使用Clippy在这种情况下，库是供其他程序使用的 Rust crate。库的 API是程序可以调用的一组公共函数和对象。功能性 API 只是让用户做他们需要做的一切；而优美的 API 可以让他们以简单而明智的方式完成他们需要做的事情。

【功能模块】【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

留言功能挺实用的， 但是每次手动导出很麻烦，也不能做到及时，开发者是否可以考虑增加一个sdk或者接口提供留言导出功能

【功能模块】API 负载均衡 pool 中添加云服务器报错【操作步骤&问题现象】1、LB中添加pool2、pool 中添加云服务器报错所有的操作都是通过API请求的看报错信息是由于云服务的subnet 与 loadbalancer 的子网不匹配导致的，请问如何通过LB 的subnet去AP查询可添加云主机，筛选条件是什么【截图信息】【日志信息】（可选，上传日志内容或者附件）"NeutronError": {"type": "MemberRouterLoadBalancerRouterMismatch", "message": "Router of member's subnet ff65f2cc-d8f9-42d1-9200-d492f3da3d00 and router of loadbalancer's subnet d62410b4-7b03-4e2a-819d-2e744b15f7b0 mismatch

【功能模块】执行器或管理中心【操作步骤&问题现象】执行器或管理中心是否有API可供外部调用，触发启动运行机器人【截图信息】【日志信息】（可选，上传日志内容或者附件）

【摘要】 Karmada已经实现了多集群场景下的Kubernetes资源（包括CRD）的分发以及管理。但当前多集群应用往往不是单一的资源形式，使用Helm对应用进行打包的使用场景也非常常见。借助Karmada原生API的支持能力，Karmada可以借助Flux轻松实现Helm应用的跨集群部署。本文分享自华为云社区《 使用Karmada实现Helm应用的跨集群部署【云原生开源】》，作者：华为云云原生开源团队。背景通过使用 Kubernetes 原生 API 并提供高级调度功能，Karmada已经实现了多集群场景下的Kubernetes资源（包括CRD）的分发以及管理。但当前多集群应用往往不是单一的资源形式，使用Helm对应用进行打包的使用场景也非常常见。借助Karmada原生API的支持能力，Karmada可以借助Flux轻松实现Helm应用的跨集群部署。部署Karmada要部署Karmada，你可以参考社区的安装文档（https://github.com/karmada-io/karmada/blob/master/docs/installation/installation.md）。如果想快速体验Karmada，我们建议通过hack/local-up-karmada.sh构建一个Karmada的开发环境。部署Flux在Karmada控制面中，你需要安装Flux的CRD，但不需要安装Flux控制器来调和基于CRD创建的CR对象，它们被视为资源模板，而不是特定的资源实例。基于Karmada的work API，它们将被封装为一个work对象下发给成员集群，最终由成员集群中的Flux控制器进行调和。kubectl apply -k github.com/fluxcd/flux2/manifests/crds?ref=main --kubeconfig ~/.kube/karmada.config在成员集群中，你可以基于以下命令安装完整的Flux组件。flux install --kubeconfig ~/.kube/members.config --context member1 flux install --kubeconfig ~/.kube/members.config --context member2你可以参考此处的文档（https://fluxcd.io/docs/installation/）来获得更详细的安装Flux的细节。提示：如果你想在你所有的集群上管理基于HelmRelease的应用，你需要在你的所有成员集群中安装Flux。Helm release分发准备工作就绪，下面将以一个podinfo的简单应用为例演示如何完成Helm chart分发。1.在 Karmada 控制平面中定义一个 Flux 的HelmRepository CR对象和一个 HelmRelease CR对象。它们将视作资源模板。apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: podinfo spec: interval: 1m url: https://stefanprodan.github.io/podinfo---apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: podinfo spec: interval: 5m chart: spec: chart: podinfo version: 5.0.3 sourceRef: kind: HelmRepository name: podinfo2. 定义一个 Karmada的PropagationPolicy 对象将它们的资源实例下发到成员集群：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: helm-repo spec: resourceSelectors: - apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository name: podinfo placement: clusterAffinity: clusterNames: - member1 - member2---apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: helm-release spec: resourceSelectors: - apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease name: podinfo placement: clusterAffinity: clusterNames: - member1 - member2上述配置将会把Flux的资源对象下发到成员集群member1和member2中。3. 将上述对象提交给Karmada-apiserver：kubectl apply -f ../helm/ --kubeconfig ~/.kube/karmada.config你将会得到以下的输出结果：helmrelease.helm.toolkit.fluxcd.io/podinfo created helmrepository.source.toolkit.fluxcd.io/podinfo created propagationpolicy.policy.karmada.io/helm-release created propagationpolicy.policy.karmada.io/helm-repo created4. 切换至成员集群验证应用是否成功下发helm --kubeconfig ~/.kube/members.config --kube-context member1 list你将会得到以下的输出结果：基于 Karmada 的 PropagationPolicy，你可以灵活地将 Helm应用发布到你期望的集群。为特定集群定制 Helm 应用上述的示例显示了如何将同一个Helm应用分发到 Karmada 中的多个集群。此外，你还可以使用 Karmada 的 OverridePolicy 为特定集群定制Helm应用。例如，上述应用包括了一个Pod副本，如果你只想更改 member1集群中的应用所包含的Pod副本数，你可以参考以下的 OverridePolicy策略。1.定义一个Karmada的OverridePolicy对象。apiVersion: policy.karmada.io/v1alpha1 kind: OverridePolicy metadata: name: example-override namespace: default spec: resourceSelectors: - apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease name: podinfo overrideRules: - targetCluster: clusterNames: - member1 overriders: plaintext: - path: "/spec/values" operator: add value: replicaCount: 22. 将上述对象提交给Karmada-apiserver：kubectl apply -f example-override.yaml --kubeconfig ~/.kube/karmada.config你将会得到以下的输出结果：overridepolicy.policy.karmada.io/example-override created3. 在 Karmada 控制平面中应用上述策略后，你会发现 member1成员集群中的Pod实例数已变更为 2，但 member2 集群中的那些保持不变。kubectl --kubeconfig ~/.kube/members.config --context member1 get po你将会得到以下的输出结果：NAME READY STATUS RESTARTS AGE podinfo-68979685bc-6wz6s 1/1 Running 0 6m28s podinfo-68979685bc-dz9f6 1/1 Running 0 7m42s参考文档：https://github.com/karmada-io/karmada/blob/master/docs/working-with-flux.md附：Karmada社区技术交流地址添加Karmada社区助手微信k8s2222进入社区交流群，和Maintainer零距离。项目地址https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/

【功能模块】华为云stack manage one运营侧以vdc管理员的身份调用api接口可以获取token信息，但是用该token去调用资源集相关api接口时报403无权限异常；除此之外，使用以上token信息调用《ManageOne8.1.0运营面API参考》手册里的大多数api接口都报403【操作步骤&问题现象】1、华为云stack manage one运营侧以vdc管理员的身份调用api接口可以获取token信息，但是用该token去调用资源集相关api接口时报403无权限异常；2、除此之外，使用以上token信息只能调用《ManageOne 8.1.0 OTenantSecurity服务API参考》文档里的api接口，调用《ManageOne8.1.0运营面API参考》手册里的大多数api接口都报403；【截图信息】比如调用以下接口在该vdc下创建一个资源集project显示403无权限：【日志信息】（可选，上传日志内容或者附件）

在使用 Server SDK 之前，需要准备环信 appkey、Client ID、ClientSecre。开发环境JDK1.8 &&MAVEN1. 在pom中引入sdk依赖2. 初始化EMService 根据业务资源，API 分为：Attachment  用于上传下载附件Block  用于限制访问(将用户加入黑名单、群组/聊天室禁言等)Contact  用于管理联系人(添加好友等)Group  用于管理群组Message  用于发送消息User  用于管理用户UserMetadata  用于管理用户属性Push  用于管理用户推送(设置推送免打扰等)Token  用于获取用户TokenRoom  用于管理聊天室每个业务资源对应一个方法，例如，用户相关的 API，都可以在 .user() 找到。举个例子，我们要注册一个用户，就可以这样写：API的返回值是响应式的，如果希望阻塞，可以使用上面例子中的 .block()。注意：如果你的项目不是响应式的编程，那么请在调用的 Server SDK API 的结尾添加 .block()对使用的 api 添加 try/catch ，如果使用的 api 没有抛出异常，代表请求成功，反之则请求失败，通过异常EMException对象的 getErrorCode()/getMessage() 拿到错误码以及错误描述

Everybody 看过来~ 工作台的体验过程中是不是有些不明白、不会处理的地方？是不是想找个专家带带？没问题！集中指导这不就来了本周六 下午16:00-18:00我们特地邀请了来自开天aPaaS集成工作台开发团队的专家为大家答疑解惑准备好你的问题，周六下午咱们开发者群里见~

本文来自微信公共号：分布式实验室。文章观点独特，比喻形象，分享给大家~本文论述了 Kubernetes 的核心价值是其通用、跨厂商和平台、可灵活扩展的声明式 API 框架， 而不是容器（虽然容器是它成功的基础）；然后手动创建一个 API Extension（CRD）， 通过测试和类比来对这一论述有一个更直观的理解。例子及测试基于 Kubernetes v1.21.0。— 1 —Kubernetes 的核心是其 API 框架而非容器 容器是基础时间回到 2013 年。当一条简单的 docker run postgre 命令就能运行起 Postgre 这样复杂的传统服务时，开发者在震惊之余犹如受到天启；以 Docker 为代表的实用容器技术的横空出世，也预示着一扇通往敏捷基础设施的大门即将打开。此后，一切都在往好的方向迅速发展：越来越多的开发者开始采用容器作为一种标准构建和运行方式。业界也意识到，很容易将这种封装方式引入计算集群，通过 Kubernetes 或 Mesos 这样的编排器来调度计算任务 —— 自此，容器便成为这些调度器最重要的 Workload 类型。但本文将要说明，容器并非 Kubernetes 最重要、最有价值的地方，Kubernetes 也并非仅仅是一个更广泛意义上的 Workload 调度器 —— 高效地调度不同类型的 Workload 只是 Kubernetes 提供的一种重要价值，但并不是它成功的原因。API 才是核心“等等 —— Kubernetes 只是一堆 API？”“不好意思，一直都是！”Kubernetes 的成功和价值在于，提供了一种标准的编程接口（API），可以用来编写和使用软件定义的基础设施服务（本文所说的“基础设施”，范围要大于 IaaS）：Specification + Implementation 构成一个完整的 API 框架 —— 用于设计、实现和使用各种类型和规模的基础设施服务；这些 API 都基于相同的核心结构和语义：typed resources watched and reconciled by controllers （资源按类型划分，控制器**相应类型的资源，并将其实际 status 校准到 spec 里期望的状态）。为了进一步解释这一点，考虑下 Kubernetes 出现之前的场景。Kubernetes 之前：各自造轮子，封装厂商 API 差异Kubernetes 之前，基础设施基本上是各种不同 API、格式和语义的“云”服务组成的大杂烩：云厂商只提供了计算实例、块存储、虚拟网络和对象存储等基础构建模块，开发者需要像拼图一样将它们拼出一个相对完整的基础设施方案；对于其他云厂商，重复过程 1，因为各家的 API、结构和语义并不相同，甚至差异很大。虽然 Terraform 等工具的出现，提供了一种跨厂商的通用格式，但原始的结构和语义仍然是五花八门的，—— 针对 AWS 编写的 Terraform descriptor 是无法用到 Azure 的。Kubernetes 面世：标准化、跨厂商的 API、结构和语义现在再来看 Kubernetes 从一开始就提供的东西：描述各种资源需求的标准 API。例如：描述 Pod、Container 等计算需求的 API；描述 Service、Ingress 等虚拟网络功能的 API；描述 Volumes 之类的持久存储的 API；甚至还包括 Service Account 之类的服务身份的 API 等等。这些 API 是跨公有云/私有云和各家云厂商的，各云厂商会将 Kubernetes 结构和语义对接到它们各自的原生 API。因此我们可以说，Kubernetes 提供了一种管理软件定义基础设施（也就是云）的标准接口。或者说，Kubernetes 是一个针对云服务（Cloud Services）的标准 API 框架。Kubernetes API 扩展：CRD提供一套跨厂商的标准结构和语义来声明核心基础设施（Pod/Service/Volume/ServiceAccount/……）， 是 Kubernetes 成功的基础。在此基础上，它又通过 CRD（Custom Resource Definition）， 将这个结构扩展到任何/所有基础设施资源。CRD 在 1.7 引入，允许云厂商和开发者自己的服务复用 Kubernetes 的 spec/impl 编程框架。有了 CRD，用户不仅能声明 Kubernetes API 预定义的计算、存储、网络服务，还能声明数据库、task runner、消息总线、数字证书……任何云厂商能想到的东西！Operator Framework 以及 SIG API Machinery 等项目的出现，提供了方便地创建和管理这些 CRD 的工具，最小化用户工作量，最大程度实现标准化。例如，Crossplane 之类的项目，将厂商资源 RDS 数据库、SQS queue 资源映射到 Kubernetes API，就像核心 Kubernetes controller 一样用自己的 controller 来管理网卡、磁盘等自定义资源。Google、RedHat 等 Kubernetes 发行商也在它们的基础 Kubernetes 发行版中包含越来越多的自定义资源类型。小结我们说 Kubernetes 的核心是其 API 框架，但并不是说这套 API 框架就是完美的。事实上，后一点并不（非常）重要，因为 Kubernetes 模型已经成为一个事实标准：开发者理解它、大量工具主动与它对接、主流厂商也都已经原生支持它。用户认可度、互操作性 经常比其他方面更能决定一个产品能否成功。随着 Kubernetes 资源模型越来越广泛的传播，现在已经能够 用一组 Kubernetes 资源来描述一整个软件定义计算环境。就像用 docker run 可以启动单个程序一样，用 kubectl apply -f 就能部署和运行一个分布式应用， 而无需关心是在私有云还是公有云以及具体哪家云厂商上，Kubernetes 的 API 框架已经屏蔽了这些细节。因此，Kubernetes 并不是关于容器的，而是关于 API。— 2 —Kubernetes 的 API 类型 可以通过 GET/LIST/PUT/POST/DELETE 等 API 操作，来创建、查询、修改或删除集群中的资源。各 controller **到资源变化时，就会执行相应的 reconcile 逻辑，来使 status 与 spec 描述相符。标准 API（针对内置资源类型）‍Namespaced 类型，这种类型的资源是区分 namespace，也就是可以用 namespace 来隔离。大部分内置资源都是这种类型，包括：podsservicesnetworkpoliciesAPI 格式：格式：/api/{version}/namespaces/{namespace}/{resource}举例：/api/v1/namespaces/default/podsUn-namespaced 类型，这种类型的资源是全局的，不能用 namespace 隔离，例如：nodesclusterroles（clusterxxx 一般都是，表示它是 cluster-scoped 的资源）API 格式：格式：/api/{version}/{resource}举例：/api/v1/nodes扩展 API（apiextension）1、Namespaced 类型API 格式：格式：/apis/{apiGroup}/{apiVersion}/namespaces/{namespace}/{resource}举例：/apis/cilium.io/v2/namespaces/kube-system/ciliumnetworkpolicies2、Un-namespaced 类型CRD用户发现了 Kubernetes 的强大之后，希望将越来越多的东西（数据）放到 Kubernetes 里面， 像内置的 Pod、Service、NetworkPolicy 一样来管理，因此出现了两个东西：CRD：用来声明用户的自定义资源，例如它是 namespace-scope 还是 cluster-scope 的资源、有哪些字段等等，Kubernetes 会自动根据这个定义生成相应的 API；官方文档的例子[1]， 后文也将给出一个更简单和具体的例子。CRD 是资源类型定义，具体的资源叫 CR。Operator 框架：“Operator” 在这里的字面意思是“承担运维任务的程序”， 它们的基本逻辑都是一样的：时刻盯着资源状态，一有变化马上作出反应（也就是 reconcile 逻辑）。这就是扩展 API 的（最主要）声明和使用方式。至此，我们讨论的都是一些比较抽象的东西，接下来通过一些例子和类比来更直观地理解一下。— 3 —直观类比：Kubernetes 是个数据库，CRD 是一张表，API 是 SQL 在本节中，我们将创建一个名为 fruit 的 CRD，它有 name/sweet/weight 三个字段， 完整 CRD 如下：apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata:  name: fruits.example.org        # CRD 名字spec:  conversion:    strategy: None  group: example.org              # REST API: /apis/<group>/<version>  names:    kind: Fruit    listKind: FruitList    plural: fruits    singular: fruit  scope: Namespaced               # Fruit 资源是区分 namespace 的  versions:  - name: v1                      # REST API: /apis/<group>/<version>    schema:      openAPIV3Schema:        properties:          spec:            properties:              comment:            # 字段 1，表示备注                type: string              sweet:              # 字段 2，表示甜否                type: boolean              weight:             # 字段 3，表示重量                type: integer            type: object        type: object    served: true                  # 启用这个版本的 API（v1）    storage: true    additionalPrinterColumns:     # 可选项，配置了这些 printer columns 之后，    - jsonPath: .spec.sweet       # 命令行 k get <crd> <cr> 时，能够打印出下面这些字段，      name: sweet                 # 否则，k8s 默认只打印 CRD 的 NAME 和 AGE      type: boolean    - jsonPath: .spec.weight      name: weight      type: integer    - jsonPath: .spec.comment      name: comment      type: string后面会解释每个 section 都是什么意思。在此之前，先来做几个（直观而粗糙的）类比。Kubernetes 是个数据库像其他数据库技术一样，它有自己的持久存储引擎（etcd），以及构建在存储引擎之上的 一套 API 和语义。这些语义允许用户创建、读取、更新和删除（CURD）数据库中的数据。下面是一些概念对应关系：关系型数据库Kubernetes（as a database）说明DATABASEcluster一套 Kubernetes 集群就是一个 database 【注 1】TABLEKind每种资源类型对应一个表；分为内置类型和扩展类型 【注 2】COLUMNproperty表里面的列，可以是 string、boolean 等类型rowsresources表中的一个具体 record表中的一个具体 record【注 1】 如果只考虑 namespaced 资源的话，也可以说一个 namespace 对应一个 database。【注 2】 前面已经介绍过，内置 Kind：Job、Service、Deployment、Event、NetworkPolicy、Secret、ConfigMap 等等；扩展 Kind：各种 CRD，例如 CiliumNetworkPolicy。所以，和其他数据库一样，本质上 Kubernetes 所做的不过是以 schema 规定的格式来处理 records。另外，Kubernetes 的表都有自带文档‍：$ k explain fruitsKIND:     FruitVERSION:  example.org/v1DESCRIPTION:     <empty>FIELDS:   apiVersion   <string>     APIVersion defines the versioned schema of this representation of an     object. Servers should convert recognized schemas to the latest internal     value, and may reject unrecognized values. More info:     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources   kind <string>     Kind is a string value representing the REST resource this object     represents. Servers may infer this from the endpoint the client submits     requests to. Cannot be updated. In CamelCase. More info:     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds   metadata     <Object>     Standard object's metadata. More info:     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata   spec <Object>另外，Kubernetes API 还有两大特色：极其可扩展：声明 CRD 就会自动创建 API；支持事件驱动。CRD 是一张表CRD 和内置的 Pod、Service、NetworkPolicy 一样，不过是数据库的一张表。例如，前面给出的 fruit CRD，有 name/sweet/weight 列，以及 “apple”、“banana” 等 entry。用户发现了 Kubernetes 的强大，希望将越来越多的东西（数据）放到 Kubernetes 里面来管理。数据类 型显然多种多样的，不可能全部内置到 Kubernetes 里。因此，一种方式就是允许用户创建自己的 “表”，设置自己的“列” —— 这正是 CRD 的由来。1、定义表结构（CRD spec）CRD（及 CR）描述格式可以是 YAML 或 JSON。CRD 的内容可以简单分为三部分：常规 Kubernetes metadata：每种 Kubernetes 资源都需要声明的字段，包括 apiVersion、kind、metadata.name 等‍‍。 apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata:   name: fruits.example.org        # CRD 名字Table-level 信息：例如表的名字，最好用小写，方便以后命令行操作‍； spec:   conversion:     strategy: None   group: example.org              # REST API: /apis/<group>/<version>   names:     kind: Fruit     listKind: FruitList     plural: fruits     singular: fruit   scope: Namespaced               # Fruit 资源是区分 namespace 的Column-level 信息：列名及类型等等，遵循 OpenAPISpecification v3 规范。   versions:   - name: v1                      # REST API: /apis/<group>/<version>     schema:       openAPIV3Schema:         properties:           spec:             properties:               comment:            # 字段 1，表示备注                 type: string               sweet:              # 字段 2，表示甜否                 type: boolean               weight:             # 字段 3，表示重量                 type: integer             type: object         type: object     served: true                  # 启用这个版本的 API（v1）     storage: true     additionalPrinterColumns:     # 可选项，配置了这些 printer columns 之后，     - jsonPath: .spec.sweet       # 命令行 k get <crd> <cr> 时，能够打印出下面这些字段，       name: sweet                 # 否则，k8s 默认只打印 CRD 的 NAME 和 AGE       type: boolean     - jsonPath: .spec.weight       name: weight       type: integer     - jsonPath: .spec.comment       name: comment       type: string2、测试：CR 增删查改 vs. 数据库 SQL创建 CRD：这一步相当于 CREATE TABLE fruits ...;。 $ kubectl create -f fruits-crd.yaml customresourcedefinition.apiextensions.k8s.io/fruits.example.org created创建 CR：相当于 INSERT INTO fruits values(...);。apple-cr.yaml‍： apiVersion: example.org/v1 kind: Fruit metadata:   name: apple spec:   sweet: false   weight: 100   comment: little bit rottenbanana-cr.yaml： apiVersion: example.org/v1 kind: Fruit metadata:   name: banana spec:   sweet: true   weight: 80   comment: just bought创建‍： $ kubectl create -f apple-cr.yaml fruit.example.org/apple created $ kubectl create -f banana-cr.yaml fruit.example.org/banana created查询 CR：相当于 SELECT * FROM fruits ... ; 或 SELECT * FROM fruits WHERE name='apple';。 $ k get fruits.example.org # or kubectl get fruits NAME     SWEET   WEIGHT   COMMENT apple    false   100      little bit rotten banana   true    80       just bought $ kubectl get fruits apple NAME    SWEET   WEIGHT   COMMENT apple   false   100      little bit rotten删除 CR：相当于 DELETE FROM fruits WHERE name='apple';。 $ kubectl delete fruit apple可以看到，CRD/CR 的操作都能对应到常规的数据库操作。API 是 SQL上一节我们是通过 kubectl 命令行来执行 CR 的增删查改，它其实只是一个外壳，内部 调用的是 Kubernetes 为这个 CRD 自动生成的 API —— 所以又回到了本文第一节论述的内容：Kubernetes 的核心是其 API 框架。只要在执行 kubectl 命令时指定一个足够大的 loglevel，就能看到背后的具体 API 请求。例如：$ kubectl create -v 10 -f apple-cr.yaml  ...  Request Body: {"apiVersion":"example.org/v1","kind":"Fruit",\"spec\":{\"comment\":\"little bit rotten\",\"sweet\":false,\"weight\":100}}\n"},"name":"apple","namespace":"default"},"spec":{"comment":"little bit rotten","sweet":false,"weight":100}}  curl -k -v -XPOST 'https://127.0.0.1:6443/apis/example.org/v1/namespaces/default/fruits?fieldManager=kubectl-client-side-apply'  POST https://127.0.0.1:6443/apis/example.org/v1/namespaces/default/fruits?fieldManager=kubectl-client-side-apply 201 Created in 25 milliseconds  ...— 4 —其他 给 CR 打标签（label），根据 label 过滤和内置资源类型一样，Kubernetes 支持对 CR 打标签，然后根据标签做过滤：# 查看所有 frutis$ k get fruitsNAME     SWEET   WEIGHT   COMMENTapple    false   100      little bit rottenbanana   true    80       just bought# 给 banana 打上一个特殊新标签$ k label fruits banana tastes-good=truefruit.example.org/banana labeled# 按标签筛选 CR$ k get fruits -l tastes-good=trueNAME     SWEET   WEIGHT   COMMENTbanana   true    80       just bought# 删除 label$ k label fruits banana tastes-good-fruit.example.org/banana labeledKubernetes API 与鉴权控制（RBAC）不管是内置 API，还是扩展 API，都能用 Kubernetes 强大的 RBAC 来做鉴权控制。关于如何使用 RBAC 网上已经有大量文档；但如果想了解其设计，可参考 Cracking Kubernetes RBAC Authorization Model[2]， 它展示了如何从零开始设计出一个 RBAC 鉴权模型（假设 Kubernetes 里还没有）。相关链接：https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinitionhttps://arthurchiao.art/blog/cracking-k8s-authz-rbac/参考链接：https://blog.joshgav.com/2021/12/16/kubernetes-isnt-about-containers.htmlhttps://github.com/gotopple/k8s-for-users-intro/blob/master/database.mdhttps://itnext.io/crd-is-just-a-table-in-kubernetes-13e15367bbe4原文阅读：https://mp.weixin.qq.com/s/MEhDJYg_lmjbPEdFFLdedg

目录一、心知天气API密钥获取二、编写代码三、设置为自启动项目一、心知天气API密钥获取首先，访问https://www.seniverse.com，进行登录或者注册操作，然后在控制台上创建一个免费版的项目，创建后，项目信息为：二、编写代码代码如下：12345678910111213141516171819202122232425262728293031323334353637383940import requestsfrom plyer import notification """plyer是用来显示弹窗的模块安装命令：pip install plyer""" params = {    "key": "你的API密钥",    "location": "ip",    # 查询地点设置为访问IP所在地    "language": "zh-Hans",    "unit": "c",} url = "https://api.seniverse.com/v3/weather/now.json" # 获取数据r = requests.get(url, params=params) # 解析数据data = r.json()["results"] address = data[0]["location"]['path']        # 地点temperature = data[0]['now']["temperature"]  # 温度text = data[0]['now']["text"]                # 天气情况 # 弹窗显示消息message = address + " 当前天气：\n" + \          "温度：" + temperature + "℃" + \          "\n天气情况：" + text + \          "\n祝您心情愉悦！(^o^)"           """标题为“当前天气”显示10秒钟（timeout参数）"""notification.notify(title="当前天气",                    message=message,                    timeout=10)运行代码，可以看到屏幕右下角出现了提示弹窗。三、设置为自启动项目这里我以Windows系统为例，首先，在桌面创建一个bat文件，命名为weather.bat，输入代码：1python D:\Python爬虫\demo.py其中“D:\Python爬虫\demo.py”是我的Python代码路径，你可以根据自己的进行修改。接下来，右击“计算机”，选择“管理”，再找到任务计划程序库，点击右边的“创建基本任务”，如图：接下来，每一次登录这个账号，都会自动启动这个项目，如图，笔者退出账号后，再登录，可以看到右下角出现了弹窗：