Kubernetes控制平面組件：API Server詳解（二）

云原生學習路線導航頁（持續更新中）

  • kubernetes學習系列快捷鏈接
    • Kubernetes架構原則和對象設計（一）
    • Kubernetes架構原則和對象設計（二）
    • Kubernetes架構原則和對象設計（三）
    • Kubernetes控制平面組件：etcd（一）
    • Kubernetes控制平面組件：etcd（二）
    • Kubernetes控制平面組件：API Server詳解（一）
    • Kubernetes常見問題解答
    • 查看云機器的一些常用配置

本文是kubernetes的控制面組件API Server詳解（二），首先總覽了API Server的整個處理流程，然后對 max-in-flight限流限制、authorization授權鑒權機制、aggregator擴展apiserver機制、內置apiserver的請求轉換處理和admission準入控制模塊 分別進行了詳細介紹

  • 希望大家多多 點贊 關注 評論 收藏，作者會更有動力繼續編寫技術文章

1.API Server處理流程概覽

在這里插入圖片描述

  • request-timeout：request進來，會先去做request-timeout
  • authenatication：進行身份認證
  • audit：認證通過后會進行 審計日志 Audit 的記錄，主要是記錄什么人做了什么修改操作，方便在出問題時定位請求的來源，比如對象被刪時可以用來定責
  • impersonation：用于模擬用戶身份的字段
    • 在request-header中有一個impersonation header，可以指定該值來模擬用戶身份。
    • 比如a用戶發起的一個請求，但是它可以通過 impersonation header 把這個請求模擬成b用戶，Kubernetes會把該請求認為是b用戶，即a用戶代替b用戶來做操作，且后續的鑒權將會按照b用戶進行
    • 一個不太常用的功能
  • max-in-flight：用于做限流（正在飛的請求–正在運行的請求）
    • 可以配置 允許API Server同時處理多少請求，即允許有多少尚未返回的請求
  • authorization：鑒權
  • kubernetes aggregator：擴展API Server處理器
    • Kubernetes為 內置資源提供了 默認的 API Server處理器，可以處理pod、deployment等內置資源
    • 但如果你希望自己來處理資源，也可以自己編寫一個API Server處理器，掛載上來
    • 那么在kubernetes aggregator這里，就會判斷使用哪個處理器，進而往下走
  • resource handler
    • kubernetes內置apiserver處理器的核心邏輯，包括解碼、版本轉換、默認值填充、準入、校驗、和etcd交互等
    • decoding：解碼
    • request conversion & defaulting：當用戶請求的 API 版本與最新版本不一致時，轉成內部通用版本，然后進行默認值填充
    • admission：準入校驗
    • rest logic：rest處理模塊
      • storage conversion & defaulting：將請求轉成rest請求，操作存儲etcd
    • result conversion：處理響應
    • encoding：對響應編碼

request-timeout、authenatication、audit、impersonation 模塊，請見 Kubernetes控制平面組件：API Server詳解（一）

2.max-in-flight 請求限流

  • Kubernetes控制平面組件：APIServer 限流機制詳解

3.authorization授權鑒權

在這里插入圖片描述

3.1.認證和授權概念辨析

  • 在 Kubernetes控制平面組件：API Server詳解（一） 中，我們詳細講解了 apiserver 的認證機制，那么認證和授權有什么區別呢？
  • 認證（Authentication）
    • 目的：驗證請求者的身份，側重于身份的校驗，攔截非法身份
    • 支持方式：
      • 靜態密碼文件
      • X509證書
      • Bearer Token
      • ServiceAccount Token
      • Webhook 等
    • 失敗響應：認證失敗返回 401 Unauthorized
  • 授權鑒權（Authorization）
    • 目的：驗證請求者 有沒有權限 執行當前操作，此時已經知道請求者身份了，側重于權限校驗，攔截 用戶越權 的行為
    • 三要素：
      1. 操作主體（Subject）
      2. 目標資源（Resource）
      3. 操作動作（Verb）
    • 核心問題：誰（Who）能對什么資源（What）執行什么操作（How）
    • 失敗響應：鑒權失敗返回 403 Forbidden

3.2.API Server 支持的授權模式

以下是補充了縮寫全稱的表格：

模式全稱特點適用場景
ABACAttribute-Based Access Control基于屬性配置，需重啟API Server簡單測試環境
RBACRole-Based Access Control通過API對象動態配置生產環境主流方案
WebhookWebhook Authorization對接外部授權系統企業統一權限體系
NodeNode Authorization節點組件專用授權kubelet權限控制

3.3.RBAC 與 ABAC 對比

在這里插入圖片描述

3.3.1.ABAC 特點

  • 使用方法
    # 需在 apiserver master 節點配置策略文件
--authorization-policy-file=/etc/kubernetes/policy.json
  • 缺點：
    • 靜態文件方式定義授權策略，每次更改都需要重啟API Server
    • 策略更新困難
    • 缺乏靈活性

3.3.2.RBAC 優勢

  • 通過API對象管理權限（Role/ClusterRole），無需重啟API Server即可更新授權策略
  • 支持動態更新
  • 細粒度權限控制
  • 支持命名空間隔離

3.4. authorization 4種授權模式詳解

3.4.1.ABAC授權模式詳解

3.4.2.RBAC授權模式詳解

3.4.3.Webhook授權模式詳解

3.4.4.Node授權模式詳解

3.5.與權限相關的最佳實踐

在這里插入圖片描述

4.kubernetes aggregator 擴展 APIServer 處理器

4.1.APIServer擴展 基本原理

4.1.1.APIServer 擴展核心組件

  • Kubernetes Aggregator（聚合層）是 Kubernetes APIServer 的擴展機制，允許將自定義或第三方 APIServer 無縫集成到主 APIServer（kube-apiserver）中。
  • 核心組件包括：
    • APIService 對象：聲明 API 組和版本的訪問規則，并關聯后端服務（Service）。
    • 聚合層（Aggregator）：作為七層負載均衡，動態路由請求到擴展APIServer。
    • GenericAPIServer：提供通用 APIServer 功能（如認證、鑒權、路由），所有子 APIServer 均基于此構建。

4.1.2.APIServer擴展工作流程

  1. 請求入口：客戶端通過主 APIServer 發起請求（如 /apis/custom.group/v1）。
  2. 路由決策：聚合層根據 APIService 配置匹配請求路徑，轉發到擴展 APIService 的 Service。
  3. 安全認證：主 APIServer 使用 TLS 證書與擴展 APIServer 雙向認證，確保通信安全。
  4. 代理與響應：擴展 APIServer 處理請求后，結果通過主 APIServer 返回客戶端。

4.2.自定義 APIServer 的開發步驟

4.2.1.開發準備

  • 技術選型：基于 k8s.io/apiserver 庫構建，實現標準的 Kubernetes API 接口。
  • 核心接口：
    • REST.Storage：處理資源的增刪查改操作，需實現 Getter、Lister 等接口。
    • Scheme 注冊：定義資源的序列化規則（如 runtime.Object 結構體）。

4.2.2.代碼結構

// 示例代碼框架（基于 k8s.io/apiserver）
func main() {config := genericapiserver.NewConfig()  // 創建通用配置config.EnableMetrics = true// 注冊自定義資源 Schemescheme := runtime.NewScheme()customv1.AddToScheme(scheme)// 構建 APIGroupInfoapiGroupInfo := genericapiserver.NewDefaultAPIGroupInfo(...)apiGroupInfo.VersionedResourcesStorageMap["v1"] = storageMap// 初始化 GenericAPIServerserver, _ := config.Complete().New("my-apiserver", genericapiserver.NewEmptyDelegate())server.InstallAPIGroup(&apiGroupInfo)server.PrepareRun().Run(stopCh)
}

4.2.3.關鍵組件實現

  • 存儲層：對接數據庫或自定義存儲（需實現 etcd3.Store 接口）。
  • 認證與鑒權：
    • 復用 Kubernetes 的 RBAC 機制，通過 SubjectAccessReview 驗證權限。
    • 使用 --requestheader-client-ca-file 和 --proxy-client-cert-file 配置 TLS 證書。

4.3.與 kube-apiserver 的集成

4.3.1.創建 APIService 對象

# APIService 定義示例
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:name: v1.custom.group
spec:group: custom.groupversion: v1service:namespace: custom-systemname: custom-api-server  # 指向自定義 APIServer 的 Serviceport: 443caBundle: <base64-encoded-CA>  # 用于驗證擴展 APIServer 的 CA

4.3.2.服務發現與負載均衡

  • Service 配置：需創建 ClusterIP 或 NodePort 類型的 Service，確保主 APIServer 可訪問。
  • Endpoints 驗證：通過 kubectl get endpoints 檢查后端 Pod 狀態。

4.3.3.權限配置

  • RBAC 規則：需為自定義 APIServer 分配 system:auth-delegator 角色，允許代理請求。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: custom-apiserver-auth-delegator
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: system:auth-delegator
subjects:
- kind: ServiceAccountname: custom-apiservernamespace: custom-system

4.4.注意事項

1. 安全與證書管理

  • CA 一致性：主 APIServer 與擴展 APIServer 的證書必須由同一 CA 簽發。
  • 證書輪換：定期更新 TLS 證書，避免過期導致通信中斷。

2. 性能與調試

  • 請求代理開銷：聚合層代理可能增加延遲，建議優化擴展 APIServer 處理邏輯。
  • 日志與監控：啟用 APIServer 的 --v=4 日志級別，結合 Prometheus 監控指標。

3. 版本兼容性

  • 多版本共存：支持 v1 和 v1beta1 等版本，通過 spec.versionPriority 控制優先級。
  • 廢棄策略：逐步淘汰舊版本，使用 deprecated 注解標記。

4.5.實操案例：Metrics Server 的實現

4.5.1.案例背景

  • Metrics Server 是 Kubernetes 官方提供的聚合 APIServer，用于采集 Node 和 Pod 的 CPU/內存指標。

4.5.2.實現步驟

  1. APIService 注冊：
    apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:name: v1beta1.metrics.k8s.io
spec:service:name: metrics-servernamespace: kube-systemgroup: metrics.k8s.ioversion: v1beta1
  2. 自定義 APIServer：實現 metrics/v1beta1 組資源的 GET /nodes/{node}/metrics 接口。
  3. 權限配置：為 metrics-server ServiceAccount 綁定 system:metrics-server 角色。

4.5.3.驗證

kubectl top nodes  # 查看節點指標
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq  # 直接訪問 API

5.resource handler 內置 APIServer 處理器

5.1.請求conversion & defaulting

5.1.1.基礎概念

  1. Conversion（版本轉換）
    ? 定義：將不同 API 版本的資源對象轉換為統一 內部版本（Internal Version） 的機制，確保多版本兼容性。例如，用戶提交的 apps/v1beta1.Deployment 會被轉換為 apps/v1.Deployment 的內部表示。
    ? 核心目標：實現 API 版本的平滑升級和降級，避免因版本變更導致數據丟失或服務中斷。

  2. Defaulting（默認值填充）
    ? 定義：為資源對象中未顯式指定的字段填充默認值的機制。例如，未設置 Pod 的 imagePullPolicy 時，默認填充 IfNotPresent。
    ? 核心目標：簡化用戶配置，確保資源的完整性和一致性，避免因字段缺失導致運行時錯誤。

5.1.2.設計理念

  1. 多版本兼容性
  • 向后兼容：通過版本轉換支持舊版本 API 請求，允許用戶逐步遷移到新版本。
  • 版本共存：API Server 可同時處理多個版本的資源對象（如 v1 和 v1beta1）。
  1. 配置簡潔性
  • 用戶友好：通過默認值隱藏復雜配置細節，例如自動填充 Service 的 ClusterIP 或 Deployment 的滾動更新策略。
  • 規范化：確保資源對象符合 Schema 定義，減少人工校驗成本。
  1. 擴展性與解耦
  • 插件化機制：Conversion 和 Defaulting 均可通過擴展點（如 CustomResourceDefinition 或 Admission Webhook）實現自定義邏輯。
    • mutatingwebhookconfigurations：修改資源屬性
    • validatingwebhookconfigurations：校驗資源

5.1.3.實現原理

  1. Conversion 實現機制
  • 版本注冊表：每個 API 組（如 apps、batch）注冊其支持的版本及轉換函數。
  • 轉換鏈（Conversion Chain）：
    • 步驟1：將用戶提交的外部版本（如 v1beta1）轉換為內部版本。
    • 步驟2：持久化到 etcd 時，轉換為存儲版本（Storage Version）。
    • 步驟3：響應時根據請求的 API 版本反向轉換。
  • 轉換函數：通過 conversion-gen 工具自動生成或手動實現字段映射邏輯。
  1. Defaulting 實現機制
  • Schema 定義：在資源的 OpenAPI Schema 中聲明字段的 default 值（如 spec.replicas: 1）。
  • 準入控制階段：在請求驗證前，由 Mutating Admission Controller 或內置邏輯填充默認值。
  • 自定義默認值：通過編寫 Admission Webhook 動態填充（如根據 Namespace 設置資源配額）。

5.1.4.處理流程
是
否
用戶請求
版本轉換 Conversion
是否需轉換?
調用轉換函數
生成內部版本
默認值填充 Defaulting
填充 Schema 定義的默認值
執行 Admission Control
驗證 & 持久化到 etcd

  1. Conversion 流程
    ? 用戶請求攜帶 apiVersion 字段（如 apps/v1beta1）。
    ? API Server 根據注冊的轉換函數，將對象轉換為內部版本。
    ? 存儲到 etcd 時，轉換為存儲版本（由 --storage-versions 指定）。

  2. Defaulting 流程
    ? 在驗證階段前遍歷資源對象字段。
    ? 若字段未設置且 Schema 中定義默認值，則自動填充。

5.1.5.參數配置

  1. Conversion 相關配置
    ? API 版本啟用：通過 --runtime-config=apps/v1beta1=true 啟用特定 API 版本。
    ? 存儲版本設置：在 CRD 中指定 spec.versions.storage: true 定義存儲版本。

  2. Defaulting 相關配置
    ? Schema 默認值：在 CRD 的 OpenAPI Schema 中定義 default 字段：

    spec:versions:- name: v1schema:openAPIV3Schema:properties:spec:properties:replicas:type: integerdefault: 1

    ? Admission Webhook：配置 Mutating Webhook 實現動態默認值。

5.1.6.實操案例

  1. 自定義 Conversion 函數
    場景：將自定義資源 MyApp 從 v1alpha1 升級到 v1。
    步驟：
    ? 定義轉換函數：

    func Convert_v1alpha1_MyApp_To_v1_MyApp(in *v1alpha1.MyApp, out *v1.MyApp, s conversion.Scope) error {out.Spec.Replicas = in.Spec.ReplicaCount  // 字段重命名映射return nil
}

    ? 注冊轉換函數到 scheme：

    scheme.AddConversionFunc(&v1alpha1.MyApp{}, &v1.MyApp{}, Convert_v1alpha1_MyApp_To_v1_MyApp)

    ? 更新 CRD 的 spec.versions 和 storage 標志。

  2. 動態 Defaulting 示例
    場景：為所有新創建的 Pod 自動添加 env: prod 標簽。
    步驟：
    ? 編寫 Mutating Webhook：

    func mutatePod(ar v1.AdmissionReview) *v1.AdmissionResponse {pod := corev1.Pod{}if err := json.Unmarshal(ar.Request.Object.Raw, &pod); err != nil {return denyRequest(err)}if pod.Labels == nil {pod.Labels = make(map[string]string)}pod.Labels["env"] = "prod"return createPatchResponse(ar.Request.Object.Raw, pod)
}

    ? 配置 Webhook 的 ValidatingWebhookConfiguration，指定匹配規則為 CREATE Pod。

5.1.7.優化與注意事項

  1. 性能優化
    ? Conversion 緩存：緩存常用版本的轉換結果，減少重復計算。
    ? Defaulting 延遲加載：僅在必要時填充默認值，避免資源浪費。

  2. 兼容性風險
    ? 版本廢棄策略：通過 deprecated 注解標記舊版本，逐步淘汰。
    ? 默認值變更：修改 Schema 默認值時需考慮已存在資源的影響。

  3. 調試工具
    ? 查看內部版本：使用 kubectl get --raw /apis/<group>/<version>/<resource>?as=internal 查看轉換后的內部對象。
    ? Dry-Run 模式：通過 kubectl apply --dry-run=server 驗證默認值填充邏輯。

5.2.admission準入控制

  • 請見：Kubernetes控制平面組件：APIServer 準入控制機制詳解

6.API Server代碼學習

Kubernetes控制平面組件：API Server代碼基礎概念

7.應用案例：如何搭建一個多租戶的kubernetes集群

在這里插入圖片描述

  • 基于前面對kubernetes集群架構 + API Server的學習，現在應該具備設計一個多租戶kubernetes集群的能力。下面介紹基本思路。
    • 1.以ns為隔離域的租戶隔離設計
      • 首先通過準入控制的 Webhook + Controller，在ns create階段自動為ns綁定用戶權限，實現：只有指定用戶才可以訪問某個ns。具體實現如下：
      • 在ns創建時，通過一個mutatingwebhookconfigurations變形webhook插件，將用戶信息寫入ns的annotation
    • 2.做好用戶訪問的授權鑒權
      • 關閉匿名訪問，只允許可信用戶操作
      • 鑒權時，判斷請求用戶信息是否存在于ns的annotation，即可判斷當前用戶是否有權限訪問該ns
      • 管理員可以控制指定用戶的ns權限和可見范圍，其實就是控制ns上anno中是否包含某個用戶的信息
    • 3.做好ns的配額管理
      • 通過在ns下創建ResourceQuota，定義ns下資源的配額，比如最多允許的pod數量、cm數量、service/ingress數量等
      • 還可以編寫一個Controller，監聽ns create事件，自動創建配額。
  • 用戶視角下的隔離性
    • 可見性隔離，用戶只能看到自己創建的ns下面的應用和服務，沒有其他ns權限
    • 資源隔離，用戶只能使用自己ns下的資源配額之內的資源，其他的用不了；另外，特有node上可以通過 打上污點Taint 的方式，防止其他用戶調度上來，實現資源層隔離
    • 應用訪問隔離，用戶可以對自己應用配置訪問限制
  • 實現以上內容，集群其實就已經是一個多租戶集群了

8.應用案例：如何與企業現有認證系統集成

在這里插入圖片描述

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/news/902538.shtml
繁體地址，請注明出處：http://hk.pswp.cn/news/902538.shtml
英文地址，請注明出處：http://en.pswp.cn/news/902538.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

云服務器存儲空間不足導致的docker image運行失敗或Not enough space in /var/cache/apt/archives

云服務器存儲空間不足導致的docker image運行失敗或Not enough space in /var/cache/apt/archives

最近遇到了兩次空間不足導致docker實例下的mongodb運行失敗的問題。 排查錯誤 首先用nettools看下mongodb端口有沒有被占用&#xff1a; sudo apt install net-tools netstat --all --program | grep 27017 原因和解決方案 系統日志文件太大 一般情況下日志文件不會很大…
閱讀更多...
爬蟲學習——下載文件和圖片、模擬登錄方式進行信息獲取

爬蟲學習——下載文件和圖片、模擬登錄方式進行信息獲取

一、下載文件和圖片 Scrapy中有兩個類用于專門下載文件和圖片&#xff0c;FilesPipeline和ImagesPipeline&#xff0c;其本質就是一個專門的下載器&#xff0c;其使用的方式就是將文件或圖片的url傳給它(eg:item[“file_urls”])。使用之前需要在settings.py文件中對其進行聲明…
閱讀更多...
拒絕用電“盲人摸象”，體驗智能微斷的無縫升級

拒絕用電“盲人摸象”，體驗智能微斷的無縫升級

&#x1f31f; 為什么需要智能微型斷路器&#xff1f; 傳統斷路器只能被動保護電路&#xff0c;而安科瑞智能微型斷路器不僅能實時監測用電數據&#xff0c;還能遠程控制、主動預警&#xff0c;堪稱用電安全的“全能衛士”&#xff01;無論是家庭、工廠還是商業樓宇&#xff0…
閱讀更多...
如何優雅地為 Axios 配置失敗重試與最大嘗試次數

如何優雅地為 Axios 配置失敗重試與最大嘗試次數

在 Vue 3 中&#xff0c;除了使用自定義的 useRequest 鉤子函數外&#xff0c;還可以通過 axios 的攔截器 或 axios-retry 插件實現接口請求失敗后的重試邏輯。以下是兩種具體方案的實現方式&#xff1a; 方案一&#xff1a;使用 axios 攔截器實現重試 實現步驟&#xff1a; 通…
閱讀更多...
【Leetcode刷題隨筆】242.有效的字母異位詞

【Leetcode刷題隨筆】242.有效的字母異位詞

1. 題目描述 給定兩個僅包含小寫字母的字符串 s 和 t &#xff0c;編寫一個函數來判斷 t 是否是 s 的 字母異位詞。 字母異位詞定義&#xff1a;兩個字符串包含的字母種類和數量完全相同&#xff0c;但順序可以不同&#xff08;例如 “listen” 和 “silent”&#xff09;。 …
閱讀更多...
示例：spring xml+注解混合配置

示例：spring xml+注解混合配置

以下是一個 Spring XML 注解的混合配置示例&#xff0c;結合了 XML 的基礎設施配置&#xff08;如數據源、事務管理器&#xff09;和注解的便捷性&#xff08;如依賴注入、事務聲明&#xff09;。所有業務層代碼通過注解簡化&#xff0c;但核心配置仍通過 XML 管理。 1. 項目結…
閱讀更多...
Crawl4AI：打破數據孤島，開啟大語言模型的實時智能新時代

Crawl4AI：打破數據孤島，開啟大語言模型的實時智能新時代

當大語言模型遇見數據饑渴癥 在人工智能的競技場上&#xff0c;大語言模型&#xff08;LLMs&#xff09;正以驚人的速度進化&#xff0c;但其認知能力的躍升始終面臨一個根本性挑戰——如何持續獲取新鮮、結構化、高相關性的數據。傳統數據供給方式如同輸血式營養支持&#xff…
閱讀更多...
【機器學習-周總結】-第4周

【機器學習-周總結】-第4周

以下是本周學習內容的整理總結&#xff0c;從技術學習、實戰應用到科研輔助技能三個方面歸納&#xff1a; 文章目錄 &#x1f4d8; 一、技術學習模塊&#xff1a;TCN 基礎知識與結構理解&#x1f539; 博客1&#xff1a;【時序預測05】– TCN&#xff08;Temporal Convolutiona…
閱讀更多...
Mysql--基礎知識點--79.1--雙主架構如何避免回環復制

Mysql--基礎知識點--79.1--雙主架構如何避免回環復制

1 避免回環過程 在MySQL雙主架構中&#xff0c;GTID&#xff08;全局事務標識符&#xff09;通過以下流程避免數據回環&#xff1a; 1 事務提交與GTID生成 在Master1節點&#xff0c;事務提交時生成一個全局唯一的GTID&#xff08;如3E11FA47-71CA-11E1-9E33-C80AA9429562:2…
閱讀更多...
安寶特科技 | AR眼鏡在安保與安防領域的創新應用及前景

安寶特科技 | AR眼鏡在安保與安防領域的創新應用及前景

隨著科技的不斷進步&#xff0c;增強現實&#xff08;AR&#xff09;技術逐漸在多個領域展現出其獨特的優勢&#xff0c;尤其是在安保和安防方面。AR眼鏡憑借其先進的功能&#xff0c;在機場、車站、海關、港口、工廠、園區、消防局和警察局等行業中為安保人員提供了更為高效、…
閱讀更多...
Linux第十講：進程間通信IPC

Linux第十講：進程間通信IPC

Linux第十講&#xff1a;進程間通信IPC 1.進程間通信介紹1.1什么是進程間通信1.2為什么要進程間通信1.3怎么進行進程間通信 2.管道2.1理解管道2.2匿名管道的實現代碼2.3管道的五種特性2.3.1匿名管道&#xff0c;只能用來進行具有血緣關系的進程進行通信(通常是父子)2.3.2管道文…
閱讀更多...
微信小程序通過mqtt控制esp32

微信小程序通過mqtt控制esp32

目錄 1.注冊巴法云 2.設備連接mqtt 3.微信小程序 備注 本文esp32用的是MicroPython固件&#xff0c;MQTT服務用的是巴法云。 本文參考巴法云官方教程&#xff1a;https://bemfa.blog.csdn.net/article/details/115282152 1.注冊巴法云 注冊登陸并新建一個topic&#xff…
閱讀更多...
SQLMesh隔離系統深度實踐指南：動態模式映射與跨環境計算復用

SQLMesh隔離系統深度實踐指南：動態模式映射與跨環境計算復用

在數據安全與開發效率的雙重壓力下&#xff0c;SQLMesh通過動態模式映射、跨環境計算復用和元數據隔離機制三大核心技術&#xff0c;完美解決了生產與非生產環境的數據壁壘問題。本文提供從環境配置到生產部署的完整實施框架&#xff0c;助您構建安全、高效、可擴展的數據工程體…
閱讀更多...
Spring Data詳解：簡化數據訪問層的開發實踐

Spring Data詳解：簡化數據訪問層的開發實踐

1. 什么是Spring Data&#xff1f; Spring Data 是Spring生態中用于簡化數據訪問層&#xff08;DAO&#xff09;開發的核心模塊&#xff0c;其目標是提供統一的編程模型&#xff0c;支持關系型數據庫&#xff08;如MySQL&#xff09;、NoSQL&#xff08;如MongoDB&#xff09;…
閱讀更多...
15 nginx 中默認的 proxy_buffering 導致基于 http 的流式響應存在 buffer, 以 4kb 一批次返回

15 nginx 中默認的 proxy_buffering 導致基于 http 的流式響應存在 buffer, 以 4kb 一批次返回

前言 這也是最近碰到的一個問題 直連 流式 http 服務, 發現 流式響應正常, 0.1 秒接收到一個響應 但是 經過 nginx 代理一層之后, 就發現了 類似于緩沖的效果, 1秒接收到 10個響應 最終 調試 發現是 nginx 的 proxy_buffering 配置引起的 然后 更新 proxy_buffering 為…
閱讀更多...
源超長視頻生成模型：FramePack

源超長視頻生成模型：FramePack

FramePack 是一種下一幀&#xff08;下一幀部分&#xff09;預測神經網絡結構&#xff0c;可以逐步生成視頻。 FramePack 將輸入上下文壓縮為固定長度&#xff0c;使得生成工作量與視頻長度無關。即使在筆記本電腦的 GPU 上&#xff0c;FramePack 也能處理大量幀&#xff0c;甚…
閱讀更多...
第6次課 貪心算法 A

第6次課 貪心算法 A

向日葵朝著太陽轉動&#xff0c;時刻追求自身成長的最大可能。 貪心策略在一輪輪的簡單選擇中&#xff0c;逐步導向最佳答案。 課堂學習 引入 貪心算法&#xff08;英語&#xff1a;greedy algorithm&#xff09;&#xff0c;是用計算機來模擬一個「貪心」的人做出決策的過程…
閱讀更多...
Windows使用SonarQube時啟動腳本自動關閉

Windows使用SonarQube時啟動腳本自動關閉

一、解決的問題 Windows使用SonarQube時啟動腳本自動關閉&#xff0c;并發生報錯&#xff1a; ERROR: Elasticsearch did not exit normally - check the logs at E:\Inori_Code\Year3\SE\sonarqube-25.2.0.102705\sonarqube-25.2.0.102705\logs\sonarqube.log ERROR: Elastic…
閱讀更多...
人機共跑，馬拉松人型機器人同跑

人機共跑，馬拉松人型機器人同跑

馬拉松比賽對人形機器人來說&#xff0c;是一場對硬件極限的測試&#xff0c;涉及機械、傳感器、能源管理等多個方面。用戶問的是硬件方面的考察和改進&#xff0c;這意味著我的回答需要聚焦于硬件性能&#xff0c;而不是算法或軟件的優化。 對人形機器人硬件的考研 機械結構與…
閱讀更多...
Ubuntu Linux 中文輸入法默認使用英文標點

Ubuntu Linux 中文輸入法默認使用英文標點

先ubuntu從wayland切換到x11, sudo nano /etc/gdm3/custom.conf WaylandEnablefalse #取消注釋 sudo systemctl restart gdm3 #使設置生效然后安裝fcitx(是fcitx4版本)和 fcitx-googlepinyin, sudo apt install fcitx fcitx-googlepinyin 再sudo dpkg -i 安裝百度輸入法deb…
閱讀更多...
最新文章

Copyright @ 2022~2023