阿里云ack的創建與實戰應用案例

阿里云ack的創建與應用案例

      • 創建前開通ack相關服務：
      • 開始創建
      • 簡單的魔方游戲，熟悉sv與clb自動注冊創建
      • 部署一個nginx 服務示例：
      • 走不同域名訪問不同svc資源：
          • 為什么需要 Ingress ？
          • 創建第一個域名的 Deployment和Service。
          • 創建第二個域名的 Deployment和Service。
          • 部署Ingress
          • 測試訪問情況
      • 灰度發布與藍綠發布參考：
      • 探針場景
        • 為什么要用探針？
        • **探針案例**
      • 生命周期舉例
      • ack云日志如何接入（阿里的Logtail產品）

創建前開通ack相關服務：

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/getting-started/quick-start-for-first-time-users/?spm=a2c4g.11186623.help-menu-85222.d_1_1.1b1c15442gwzA8&scm=20140722.H_161387._.OR_help-T_cn#DAS#zh-V_1

開始創建

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/create-an-ack-managed-cluster-2?spm=a2c4g.11186623.help-menu-85222.d_2_0_2_0.71e34e25vspFLq&scm=20140722.H_95108._.OR_help-T_cn#DAS#zh-V_1

測試環境：選擇使用 EIP 暴露 API Server, 才能在遠程連接或者通過控制臺的cloudshell管理集群

生產環境：找一臺內網安裝有kebctl客戶端機器進行訪問（做好訪問權限控制）

連接設置：

復制k8s的外網遠程連接配置到conf中

記得先備份好本地的config文件

cd $HOME/.kube/
cp config config.local.back
echo > config
vi config

查看nodes節點情況:

lantai@lantaideMacBook-Pro .kube % kubectl get nodes
NAME                       STATUS   ROLES    AGE   VERSION
cn-chengdu.10.194.33.154   Ready    <none>   54m   v1.31.1-aliyun.1
cn-chengdu.10.245.11.206   Ready    <none>   54m   v1.31.1-aliyun.1

注：沒有節點信息就不正常，一般原因是余額不足，導致無法創建節點資源。

簡單的魔方游戲，熟悉sv與clb自動注冊創建

基于clb注冊暴露服務端口，會新創建一個clb進行轉發到node的暴露端口上，

不太推薦生產，多創建一個clb就多消耗資源（根據業務規模情況吧）

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/getting-started/getting-started-with-ack-using-kubectl?spm=a2c4g.11186623.help-menu-85222.d_1_3.202c1a00AcmOam&scm=20140722.H_309552._.OR_help-T_cn#DAS#zh-V_1

部署前的clb：

部署后的clb:

NAME           TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
ack-cube-svc   LoadBalancer   192.168.31.155   47.108.xx.xx   80:31547/TCP   32s

在瀏覽器地址欄輸入該服務EXTERNAL-IP字段的IP地址，即可開始魔方游戲。

刪除練習相關資源：

kubectl delete -f ack-cube-svc.yaml
kubectl delete -f  ack-cube.yaml

slb中的資源會自己刪除：

部署一個nginx 服務示例：

基于clb注冊暴露服務端口

  1. 先配置deployment
apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
metadata:name: nginx-test #應用名稱。labels:app: nginx-test
spec:replicas: 1 #設置副本數量。selector:matchLabels:app: nginx-test #對應服務中Selector的值需要與其一致，才可以通過服務公開此應用。template:metadata:labels:app: nginx-testspec:containers:- name: nginx-testimage: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 #替換為您實際的鏡像地址，格式為：<image_name:tags>。ports:- containerPort: 80 #需要在服務中暴露該端口。

Deployment資源創建與驗證：

kubectl apply -f  nginx-test.yaml
kubectl get deployment nginx-test
  1. 配置nginx的 sv
apiVersion: v1
kind: Service
metadata:labels:app: nginx-testname: nginx-test-svcnamespace: default
spec:ports:- port: 8080    #公網暴露的端口，用了clb下面是LoadBalancer會自動開放端口到eip中protocol: TCPtargetPort: 80  selector:app: nginx-test # 需要與Deployment YAML文件中的matchLabels的值一致。type: LoadBalancer # 使用clb自動注冊，需要配置為LoadBalancer類型

Service資源創建與驗證：

kubectl apply -f nginx-svc.yaml
kubectl get svc nginx-test-svc

lantai@lantaideMacBook-Pro .kube % kubectl get svc nginx-test-svc
NAME             TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)          AGE
nginx-test-svc   LoadBalancer   192.168.31.180   47.108.*.*   8080:30456/TCP   18m

瀏覽器中訪問： EXTERNAL-IP:8080

EXTERNAL-IP ： 外部可訪問的公網ip地址

刪除資源：

kubectl delete -f nginx-svc.yaml
kubectl delete -f  nginx-test.yaml

走不同域名訪問不同svc資源：

為什么需要 Ingress ？
  • Service 可以使用 NodePort 暴露集群外訪問端口，但是性能低、不安全并且端口的范圍有限。
  • Service 缺少七層（OSI 網絡模型）的統一訪問入口，負載均衡能力很低，不能做限流、驗證非法用戶、鏈路追蹤等等。
  • Ingress 公開了從集群外部到集群內 服務 的 HTTP 和 HTTPS 路由，流量路由由 Ingress 資源上定義的規則控制。
  • 我們使用 Ingress 作為整個集群統一的入口，配置 Ingress 規則轉發到對應的 Service 。

基于ack中的ingress進行域名的轉發規則實驗：

ack的ingress配置參考：

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/create-an-nginx-ingress-1?spm=a2c4g.11186623.0.0.1b1c4d29tyipum

ack ingress的副本數量控制：

https://help.aliyun.com/zh/ack/deploy-ingresses-in-a-high-reliability-architecture?spm=a2c4g.11186623.0.0.17ffae7bmNEj0W#task-1339886

k8s的ingress參考：

https://kubernetes.io/docs/concepts/services-networking/ingress/

生產環境的svc的type類型建議如下

type: ClusterIP
創建第一個域名的 Deployment和Service。
 創建一個old-nginx.yaml 資源清單

apiVersion: apps/v1
kind: Deployment
metadata:name: old-nginx
spec:replicas: 1selector:matchLabels:run: old-nginx  # 標簽和service資源定義的對應好template:metadata:labels:run: old-nginxspec:containers:- image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx # 用的阿里封裝過的鏡像，生產根據實際情況配置鏡像倉庫地址imagePullPolicy: Alwaysname: old-nginxports:- containerPort: 80protocol: TCPrestartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:name: old-nginx
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:run: old-nginxsessionAffinity: Nonetype: NodePort

b. 執行以下命令，創建Deployment和Service。

kubectl apply -f old-nginx.yaml


創建第二個域名的 Deployment和Service。

創建new-nginx.yaml。

apiVersion: apps/v1
kind: Deployment
metadata:name: new-nginx
spec:replicas: 1selector:matchLabels:run: new-nginxtemplate:metadata:labels:run: new-nginxspec:containers:- image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginximagePullPolicy: Alwaysname: new-nginxports:- containerPort: 80protocol: TCPrestartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:name: new-nginx
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:run: new-nginxsessionAffinity: Nonetype: NodePort

b. 執行以下命令，創建Deployment和Service。

kubectl apply -f new-nginx.yaml
部署Ingress

創建ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress-http
spec:rules: # 規則,這里配置的域名規則，類似nginx# 第一個svc域名- host: www.example.comhttp:paths:# 老版本nginx服務。- path: /backend:service: name: old-nginxport:number: 80  # 后端svc的端口號pathType: ImplementationSpecific# 第二個svc域名- host: www.test.comhttp:paths:# 新版本nginx服務。- path: /backend:  # 指定路由到后端服務的service 相關配置service: name: new-nginxport:number: 80  # 后端svc的端口號pathType: ImplementationSpecific # ImplementationSpecific 匹配方法取決于 IngressClass

執行以下命令，部署Ingress。

kubectl apply -f ingress.yaml
測試訪問情況

查看ingress, 獲取外部訪問IP:

lantai@lantaideMacBook-Pro .kube % kubectl get ingress
NAME           CLASS   HOSTS                           ADDRESS          PORTS   AGE
ingress-http   nginx   www.example.com,www.test.com    47.108.*.184     80      18s

查看clb控制面板并沒有增加條目，因為這次不是LoadBalancer類型的svc, 是NodePort類型的svc，不會向clb注冊條目，這次依靠ack內部的ingress組件進行域名轉發：

本地電腦主機編輯/etc/hosts進行測試：

47.108.*.184 www.test.com
47.108.*.184 www.example.com

然后，通過瀏覽器訪問不同的域名進行測試，測試效果如下：

測試完清空資源：

kubectl delete -f ingress.yaml
kubectl delete -f old-nginx.yaml
kubectl delete -f new-nginx.yaml

灰度發布與藍綠發布參考：

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/implement-gray-scale-and-blue-green-publishing-through-nginx-ingress?spm=a2c4g.11186623.help-menu-85222.d_2_3_5_2_7.7d9fae7beFROdE&scm=20140722.H_200941._.OR_help-T_cn~zh-V_1#38348104fea19

可基于請求頭、cookie 、請求參數，流量權重等控制。

探針場景

為什么要用探針？

主要做 健康檢查

  • 在 Kubernetes 中，探針不是默認配置的，需要手動添加到 Pod 的定義中。
    • 如果沒有添加livenessProbe和readinessProbe，Kubernetes 不會自動進行基于應用層協議（如 HTTP）的健康檢查，只會檢查容器是否成功啟動（即容器的主進程是否運行）。

  1. 容器啟動狀態檢查

    • 默認情況下，Kubernetes主要關注容器是否成功啟動并進入Running狀態。當Kubernetes調度一個Pod到節點上后，它會等待容器的主進程啟動。如果主進程能夠正常啟動，容器就會被標記為Running。

  2. 容器運行后的健康監測缺失（默認情況）

    • 然而，僅容器啟動成功并不意味著應用在整個生命周期內都能正常提供服務。例如，應用可能會出現死鎖、進入無限循環、耗盡資源等情況，導致雖然容器仍在運行，但服務已經不可用。默認情況下，Kubernetes沒有內置對這些應用層問題的檢查機制，這就需要通過手動添加探針（如livenessProbe和readinessProbe）來實現更細致的健康監測。

  3. 與Pod生命周期的關系

    • 在Pod的生命周期管理中，默認的Running狀態判斷相對比較基礎。從創建Pending到進入Running，Kubernetes確保了容器能夠啟動，但對于后續可能出現的各種應用故障場景，沒有默認的主動監測。添加探針后，可以更好地管理Pod在Running狀態下的健康狀況，例如通過livenessProbe來決定是否重啟故障容器，通過readinessProbe來確定容器是否可以接收流量，這些操作有助于維護應用的高可用性和穩定性。

  4. Pod生命周期概述

    • 創建階段（Pending）：當創建一個Pod時，它首先進入Pending狀態。此時，Kubernetes正在為Pod分配節點資源，包括下載鏡像等操作。例如，若Pod請求的資源（如CPU、內存）在集群中暫時無法滿足，或者鏡像拉取出現問題，Pod就會一直處于Pending狀態。
    • 運行階段（Running）：當Pod成功被調度到節點并且容器啟動后，進入Running狀態。此時，容器內的應用程序開始運行，提供相應的服務。但這并不意味著應用完全健康，可能還需要進一步的健康檢查（通過探針）來確保服務的質量。
    • 終止階段（Succeeded或Failed）：當容器內的主進程正常退出時，Pod狀態變為Succeeded；如果容器內主進程異常退出或者容器無法啟動，Pod狀態變為Failed。

  5. kubernetes提供了兩種探針來實現容器探測，分別是：

    • 存活探針（livenessProbe）：
      • 用于判斷容器是否還在“存活”狀態。
      • 如果存活探針檢測失敗，Kubernetes會根據配置的策略（如重啟容器）來嘗試恢復服務。
      • 例如，對于一個Web應用，可以設置一個HTTP存活探針，定期發送HTTP請求到應用的某個端點，如果連續多次無法得到正確響應（如返回狀態碼不是200-299），就認為容器可能出現問題，需要重啟。
      • 在 Kubernetes 中，當livenessProbe（存活探針）檢測失敗達到一定次數（failureThreshold）時，默認行為是重啟容器。
        • 對于httpGet類型的存活探針，Kubernetes 會按照periodSeconds設置的時間間隔（這里是 5 秒）來檢查容器內應用的健康狀況。如果連續多次檢查（默認failureThreshold為 3 次）都無法通過（例如，返回的 HTTP 狀態碼不是 200 - 399 范圍內），Kubernetes 就會判定容器不健康，并采取重啟操作，以嘗試恢復應用的正常運行。
      • kubernetes就會對容器所在的Pod進行重啟，其實這是由Pod的重啟策略決定的，Pod的重啟策略有3種，分別如下：
        - Always：容器失效時，自動重啟該容器，默認值。
        - OnFailure：容器終止運行且退出碼不為0時重啟。
        - Never：不論狀態如何，都不重啟該容器。
      restartPolicy: Never # 重啟策略設置格式
    • 就緒探針（readinessProbe）：
      • 用于判斷容器是否已經“準備好”接收流量。
      • 只有當就緒探針檢測成功時，Service才會將流量轉發到該容器對應的Pod。
      • 例如，一個應用可能在啟動后需要一些時間來加載配置文件或者初始化數據庫連接，在這個過程中，雖然容器已經運行（存活），但還沒有準備好接收流量。通過就緒探針可以確保只有在應用真正準備好后，才會讓流量進入。
探針案例
  • 將帶有探針的Pod納入Service管理
    • 在Pod配置中添加探針（以Deployment為例）：
      假設要部署一個nginx應用的Pod，并且添加探針。
    • 創建一個Deployment的YAML文件如下：
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment-with-probes
spec:replicas: 3selector:matchLabels:app: nginx-probestemplate:metadata:labels:app: nginx-probesspec:containers:- name: nginx-container-with-probesimage: nginx:latestports:- containerPort: 80livenessProbe:httpGet:   # 表示通過發送 HTTP GET 請求的方式來檢測容器內應用的狀態path: /port: 80initialDelaySeconds: 15  # 在容器啟動后，延遲多少秒才開始第一次進行存活探針檢測periodSeconds: 5  #它定義了每隔多長時間進行一次存活探針檢測，這里設置為 5 秒readinessProbe:httpGet:path: /port: 80initialDelaySeconds: 10  #表示容器啟動后，延遲 10 秒才開始第一次進行就緒探針檢測periodSeconds: 3

注：在這個配置中，livenessProbe和readinessProbe都是基于httpGet（還有其它方式）方式，即發送HTTP請求來檢查容器的狀態。path: /表示發送請求到容器內應用的根路徑（對于nginx來說就是首頁），port: 80表示通過80端口發送請求。initialDelaySeconds是容器啟動后延遲多久開始第一次探測，periodSeconds是每次探測的間隔時間。

創建Service來管理帶有探針的Pod：

apiVersion: v1
kind: Service
metadata:name: nginx-service-for-probes
spec:selector:app: nginx-probesports:- port: 80targetPort: 80type: ClusterIP
  • 當Pod配置好探針后，創建Service來管理這些Pod。例如：
  • 在Service的spec部分，selector字段通過app: nginx-probes來選擇帶有這個標簽的Pod，這些Pod正是之前在Deployment中配置了探針的nginx Pod。
  • ports部分定義了Service本身的端口（port: 80）和轉發到Pod的目標端口（targetPort: 80）。
  • 這樣，Service就會根據Pod的就緒狀態（通過就緒探針來判斷）將外部流量轉發到合適的Pod上。當Pod的存活探針檢測到容器出現問題時，Kubernetes會按照配置（如重啟容器）來處理，而Service會自動更新其流量轉發的目標Pod列表，確保流量始終導向健康的Pod。

生命周期舉例

  1. lifecycle配置可以添加到Deployment中
    • 在Kubernetes的Deployment資源中，可以為容器定義生命周期鉤子（lifecycle hooks），用于在容器啟動后（postStart）和容器停止前（preStop）執行特定的操作。
    • 這對于需要在容器生命周期的關鍵階段進行自定義操作（如初始化配置、清理資源等）非常有用。
  2. 示例
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment-with-lifecyclelabels:app: nginx
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:latestlifecycle:postStart: # 啟動后exec:command: ["/bin/sh","-c","echo postStart... > /usr/share/nginx/html/index.html"]preStop:  # 停止前exec:command: ["/usr/sbin/nginx","-s","quit"]
  • 以下是一個包含lifecycle配置的Deployment示例，用于部署一個簡單的Nginx應用：
    - 在這個示例中：
    • apiVersion、kind和metadata部分：
      • apiVersion指定了使用的Kubernetes API版本（apps/v1用于Deployment資源）。
      • kind定義資源類型為Deployment。
      • metadata包含了Deployment的名稱（nginx-deployment-with-lifecycle）和標簽（app: nginx），用于標識和組織資源。
    • spec部分：
      • replicas字段設置為1，表示希望運行的Pod副本數量為1個。
      • selector定義了如何選擇這個Deployment管理的Pod，通過匹配標簽app: nginx來確定。
      • template部分定義了Pod的模板。
        • metadata中的標簽（app: nginx）用于Pod的識別。
        • spec中的containers字段定義了容器相關信息。
          • 容器名稱為nginx，使用nginx:latest鏡像。
          • lifecycle配置包含了postStart和preStop鉤子。
            • postStart鉤子在容器創建后執行，通過exec方式運行一條命令，將postStart...寫入Nginx容器的/usr/share/nginx/html/index.html文件，從而修改了Nginx的首頁內容。
            • preStop鉤子在容器停止前執行，通過exec方式運行命令/usr/sbin/nginx - s quit來優雅地停止Nginx服務，確保在容器完全停止之前，Nginx能夠正常關閉，避免數據丟失或服務異常。
  1. 應用和驗證
kubectl apply -f nginx-deployment-with-lifecycle.yaml
  • 可以使用kubectl命令來應用這個Deployment配置：
  • 之后，可以通過以下方式驗證lifecycle鉤子的執行情況：
    • 驗證postStart：
      • 可以通過訪問Nginx服務（如果已經配置了服務暴露），查看Nginx的首頁內容是否被修改為postStart...。
        • 例如，如果使用NodePort服務類型暴露Nginx服務，可以通過http://<node-ip>:<node-port>訪問，查看返回的頁面內容。
    • 驗證preStop：
      • 可以通過手動刪除Deployment
      • kubectl delete deployment nginx-deployment-with-lifecycle）
      • 然后查看容器日志
        • （kubectl logs <pod-name>）來確認preStop命令是否被執行。
        • 在日志中，應該可以看到Nginx服務被優雅地停止的相關信息。

ack云日志如何接入（阿里的Logtail產品）

配置參考：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/collect-log-data-from-containers-by-using-log-service?spm=a2c4g.11186623.help-menu-85222.d_2_9_1_1.341a455bvxC9TP

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

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

相關文章

青少年編程都有哪些比賽可以參加

青少年編程都有哪些比賽可以參加

Python小學生可參加的賽事&#xff1a; 電子學會青少年編程考級、中國計算機學會編程能力等級認證、藍橋杯、 信奧賽CSP-J/S初賽/NOIP(推薦C)、編程設計、信息素養、科技創新賽&#xff1b; 升學助力(科技特長生、大學)、企業、出國留學&#xff1b; python比賽&am…
閱讀更多...
MinIO在 Docker中修改登錄賬號和密碼

MinIO在 Docker中修改登錄賬號和密碼

MinIO在 Docker中修改登錄賬號和密碼 隨著云計算和大數據技術的快速發展&#xff0c;對象存儲服務逐漸成為企業數據管理的重要組成部分。MinIO 作為一種高性能、分布式的對象存儲系統&#xff0c;因其簡單易用、高效可靠的特點而備受開發者青睞。然而&#xff0c;在實際應用中…
閱讀更多...
pycharm編寫ai大模型api調用程序及常見錯誤

pycharm編寫ai大模型api調用程序及常見錯誤

這里寫目錄標題 一級目錄1. 訪問Django項目&#xff0c;python web url時&#xff0c;報錯2. 傳參報名&#xff0c;python web url時&#xff0c;報錯正確訪問結果&#xff1a; 二、購買價格 和 見錯誤碼 一級目錄 1. 訪問Django項目&#xff0c;python web url時&#xff0c;…
閱讀更多...
RISCV指令集解析

RISCV指令集解析

參考視頻&#xff1a;《RISC-V入門&進階教程》1-4-RV32I基本指令集&#xff08;1&#xff09;_嗶哩嗶哩_bilibili privilege是特權指令集&#xff0c;有點系統調用的感覺&#xff0c;要走內核態。unprivilege指令集有點像普通的函數調用。
閱讀更多...
Java中的TreeMap

Java中的TreeMap

TreeMap繼承自AbstractMap&#xff0c;并實現了NavigableMap接口(NavigableMap繼承自SortedMap接口)。底層的數據結構是紅黑樹&#xff0c;按照鍵的自然排序或者自定義實現的規則排序&#xff0c;實現元素的有序性。 特點 元素是有序的&#xff1a;按照key的自然排序或者是自…
閱讀更多...
vue3表單驗證的時候訪問接口如果有值就通過否則不通過.主動去觸發校驗

vue3表單驗證的時候訪問接口如果有值就通過否則不通過.主動去觸發校驗

頁面有個身份證號碼的校驗。校驗完身份證格式是否符合之后還要去訪問接口查詢這個用戶是否存在。如果存在才通過驗證。否則就校驗不通過 <el-form ref"ruleFormRef" :model"form" label-width"140px" label-position"right" label…
閱讀更多...
Python常見面試題的詳解24

Python常見面試題的詳解24

1. 如何對關鍵詞觸發模塊進行測試 要點 功能測試&#xff1a;驗證正常關鍵詞觸發、邊界情況及大小寫敏感性&#xff0c;確保模塊按預期響應不同輸入。 性能測試&#xff1a;關注響應時間和并發處理能力&#xff0c;保證模塊在不同負載下的性能表現。 兼容性測試&#xff1a;測…
閱讀更多...
前端Javascrip后端Net6前后分離文件上傳案例（完整源代碼）下載

前端Javascrip后端Net6前后分離文件上傳案例（完整源代碼）下載

文件上傳功能在項目開發中非常實用&#xff0c;本案例前端用Javascrip實現&#xff0c;后端用Net6實現 前端Javascrip后端Net6前后分離文件上傳案例&#xff08;完整源代碼&#xff09; 下載鏈接 https://download.csdn.net/download/luckyext/90437795?spm1001.2014.3001.5…
閱讀更多...
DeepSeek行業應用實踐報告-智靈動力【112頁PPT全】

DeepSeek行業應用實踐報告-智靈動力【112頁PPT全】

DeepSeek&#xff08;深度搜索&#xff09;近期引發廣泛關注并成為眾多企業/開發者爭相接入的現象&#xff0c;主要源于其在技術突破、市場需求適配性及生態建設等方面的綜合優勢。以下是關鍵原因分析&#xff1a; 一、技術核心優勢 開源與低成本 DeepSeek基于開源架構&#xf…
閱讀更多...
C語言綜合案例：學生成績管理系統

C語言綜合案例：學生成績管理系統

C語言綜合案例&#xff1a;學生成績管理系統 需求 1.存儲最多50名學生的信息&#xff08;不使用結構體&#xff09; 2.每個學生包含&#xff1a; 學號&#xff08;字符數組&#xff09;姓名&#xff08;字符數組&#xff09;3門課程成績&#xff08;一維數組&#xff09; …
閱讀更多...
Day 51 卡瑪筆記

Day 51 卡瑪筆記

這是基于代碼隨想錄的每日打卡 647. 回文子串 給你一個字符串 s &#xff0c;請你統計并返回這個字符串中 回文子串 的數目。 回文字符串 是正著讀和倒過來讀一樣的字符串。 子字符串 是字符串中的由連續字符組成的一個序列。 示例 1&#xff1a; 輸入&#xff1a;s &q…
閱讀更多...
結構型模式---外觀模式

結構型模式---外觀模式

概念 外觀模式是一種結構型設計模式&#xff0c;它的核心思想是為復雜的子系統提供一個統一的接口&#xff0c;簡化客戶端與子系統的交互。外觀模式通過引入一個高層接口&#xff0c;隱藏子系統的復雜性&#xff0c;使客戶端更容易使用。 適用場景 用于客戶端無需具體操作子…
閱讀更多...
DeepSeek開源周第二彈：DeepEP如何用RDMA+FP8讓MoE模型飛起來？

DeepSeek開源周第二彈：DeepEP如何用RDMA+FP8讓MoE模型飛起來？

一、引言&#xff1a;MoE模型的通信瓶頸與DeepEP的誕生 在混合專家&#xff08;MoE&#xff09;模型訓練中&#xff0c;專家間的全對全&#xff08;All-to-All&#xff09;通信成為性能瓶頸。傳統方案在跨節點傳輸時帶寬利用率不足50%&#xff0c;延遲高達300μs以上。DeepSee…
閱讀更多...
多通道數據采集和信號生成的模塊化儀器如何重構飛機電子可靠性測試體系？

多通道數據采集和信號生成的模塊化儀器如何重構飛機電子可靠性測試體系？

飛機的核心電子系統包括發電與配電系統&#xff0c;飛機內部所有設備和系統之間的內部數據通信系統&#xff0c;以及用于外部通信的射頻設備。其他所有航空電子元件都依賴這些關鍵總線進行電力傳輸或數據通信。在本文中&#xff0c;我們將了解模塊化儀器&#xff08;無論是PCIe…
閱讀更多...
【Godot4.3】基于繪圖函數的矢量蒙版效果與UV換算

【Godot4.3】基于繪圖函數的矢量蒙版效果與UV換算

概述 在設計圓角容器時突發奇想&#xff1a; 將圓角矩形的每個頂點坐標除以對應圓角矩形所在Rect2的size&#xff0c;就得到了頂點對應的UV坐標。然后使用draw_colored_polygon&#xff0c;便可以做到用圖片填充圓角矩形的效果。而且這種計算的效果就是圖片隨著其填充的圖像縮…
閱讀更多...
數據存儲：一文掌握存儲數據到MongoDB詳解

數據存儲：一文掌握存儲數據到MongoDB詳解

文章目錄 一、環境準備1.1 安裝MongoDB1.2 安裝Python MongoDB驅動 二、連接到MongoDB2.1 基本連接2.2 連接到MongoDB Atlas&#xff08;云服務&#xff09; 三、基本CRUD操作3.1 創建&#xff08;Create&#xff09;&#xff1a;插入數據3.2 讀取&#xff08;Read&#xff09;…
閱讀更多...
算法教程：島的最大面積

算法教程：島的最大面積

算法教程：島的最大面積 我們將首先討論問題和解決方案，然后使用可視化工具（上一篇博客中進行了介紹）來更好地理解搜索過程。 問題描述 我們將要演練的具體問題是問題 Leetcode：島嶼的最大面積。在 Leetcode 上找到的直接問題描述是： 給你一個 m x n 二進制矩陣網格。島…
閱讀更多...
Scrapy：隧道代理中移除 Proxy-Authorization 的原理解析

Scrapy：隧道代理中移除 Proxy-Authorization 的原理解析

隧道代理中移除 Proxy-Authorization 的原理解析 背景 在 Scrapy 的 HTTP 下載處理中&#xff0c;當使用隧道代理&#xff08;TunnelingAgent&#xff09;時&#xff0c;會移除請求頭中的 Proxy-Authorization。這個操作看似簡單&#xff0c;但背后有著重要的安全考慮和技術原…
閱讀更多...
大中型虛擬化園區網絡設計

大中型虛擬化園區網絡設計

《大中型虛擬化園區網絡設計》屬于博主的“園區網”專欄&#xff0c;若想成為HCIE&#xff0c;對于園區網相關的知識需要非常了解&#xff0c;更多關于園區網的內容博主會更新在“園區網”專欄里&#xff0c;請持續關注&#xff01; 一.前言 華為云園區網絡解決方案(簡稱Cloud…
閱讀更多...
sklearn中的決策樹-分類樹：剪枝參數

sklearn中的決策樹-分類樹：剪枝參數

剪枝參數 在不加限制的情況下&#xff0c;一棵決策樹會生長到衡量不純度的指標最優&#xff0c;或者沒有更多的特征可用為止。這樣的決策樹 往往會過擬合。為了讓決策樹有更好的泛化性&#xff0c;我們要對決策樹進行剪枝。剪枝策略對決策樹的影響巨大&#xff0c;正確的剪枝策…
閱讀更多...
最新文章

Copyright @ 2022~2023