阿里云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.mzph.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