k8s-pod 控制器

文章目录

  • k8s-pod 控制器
    • 无状态服务与有状态服务
    • 无状态服务pod 控制器
      • ReplicationController(RC)
      • ReplicaSet(RS)
        • Label 和 Selector
      • Deployment
        • 创建
        • 滚动更新
        • 回滚版本
        • 扩容/缩容
        • 暂停和恢复
      • StatefulSet
        • 创建
        • 扩容/缩容
        • 更新
          • RollingUpdate->金丝雀发布
          • OnDelete
        • 删除
      • DaemonSet
        • 节点选择器
        • 滚动更新
    • HAP
      • 开启指标服务
      • 测试方案

k8s-pod 控制器

当 Pod 被创建出来,Pod 会被调度到集群中的节点上运行,Pod 会在该节点上一直保持运行状态,直到进程终止、Pod 对象被删除、Pod 因节点资源不足而被驱逐或者节点失效为止。Pod 并不会自愈,当节点失效,或者调度 Pod 的这一操作失败了,Pod 就该被删除。如此,单单用 Pod 来部署应用,是不稳定不安全的。

Kubernetes 使用更高级的资源对象 *“控制器”* 来实现对Pod的管理。控制器可以为您创建和管理多个 Pod,管理副本和上线,并在集群范围内提供自修复能力。 例如,如果一个节点失败,控制器可以在不同的节点上调度一样的替身来自动替换 Pod。

无状态服务与有状态服务

pod 控制器针对不同类型服务,有着更细致的划分。在k8s 中,会根据容器是需要在运行过程中存储数据到宿主机上将服务分为 无状态 和有状态两种

在这里插入图片描述

针对于这两种状态服务以及监控服务,k8s分别推出了不同的控制器来实现管理

在这里插入图片描述

无状态服务pod 控制器

ReplicationController(RC)

在这里插入图片描述

Replication Controller 简称 RC,RC 是 Kubernetes 系统中的核心概念之一,简单来说,RC 可以保证在任意时间运行 Pod 的副本数量,能够保证 Pod 总是可用的。如果实际 Pod 数量比指定的多那就结束掉多余的,如果实际数量比指定的少就新启动一些Pod,当 Pod 失败、被删除或者挂掉后,RC 都会去自动创建新的 Pod 来保证副本数量,所以即使只有一个 Pod,我们也应该使用 RC 来管理我们的 Pod。可以说,通过 ReplicationController,Kubernetes 实现了 Pod 的高可用性。

v1.11+ 已经弃用,了解即可

ReplicaSet(RS)

Kubernetes 官方建议使用 RS(ReplicaSet ) 替代 RC (ReplicationController ) 进行部署,RS 跟 RC 没有本质的不同,只是名字不一样,并且 RS 支持集合式的 selector, 对pod。功能强大了点

Label 和 Selector

label (标签)是附加到 Kubernetes 对象(比如 Pods)上的键值对,用于区分对象(比如Pod、Service)。 label 旨在用于指定对用户有意义且相关的对象的标识属性,但不直接对核心系统有语义含义。 label 可以用于组织和选择对象的子集。label 可以在创建时附加到对象,随后可以随时添加和修改。可以像 namespace 一样,使用 label 来获取某类对象,但 label 可以与 selector 一起配合使用,用表达式对条件加以限制,实现更精确、更灵活的资源查找。

label 与 selector 配合,可以实现对象的“关联”,“Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod,可以给 Pod 设置 label,然后给“控制器”设置对应的 selector,这就实现了对象的关联。

  1. label 使用
1. 配置文件中在各类资源的 metadata.labels  或者 sepc.metadata.labels中进行配置apiVersion: v1kind: Podmetadata:name: nginx-demolabels:   # 设置标签type: app   # 标签 k,vtest: 1.0.0  # label 的值需要使用字符串,如果是数字,需要加 '' 框起来
2. 通过临时创建修改kubectl label po <资源名称> app=hello
3. 修改labelkubectl label po <资源名称> app=hello2 --overwrite
4. 查看label 信息kubectl get po  --show-labels
5. 根具label 值查找podkubectl get po -A -l app=hellokubectl get po -A -l 'kind=nginx-demo, test=1.0.0'  # 可以多条件查询 in 查询 != # 匹配单个值,查找 app=hello 的 podkubectl get po -A -l app=hello# 匹配多个值kubectl get po -A -l 'k8s-app in (metrics-server, kubernetes-dashboard)'# 查找 version!=1 and app=nginx 的 pod 信息kubectl get po -l version!=1,app=nginx# 不等值 + 语句kubectl get po -A -l version!=1,'app in (busybox, nginx)'
  1. selector 使用

    在各对象的配置 spec.selector 或其他可以写 selector 的属性中编写

    selector 在 deployment 和 service 中配置有点去呗

apiVersion: apps/v1  
kind: Deployment  
metadata:  name: web-app-deployment  
spec:  replicas: 3  selector:  matchLabels:  app: web-app  template:  metadata:  labels:  app: web-app  env: production  spec:  containers:  - name: web-app  image: my-web-app-image  ports:  - containerPort: 8080
apiVersion: v1  
kind: Service  
metadata:  name: web-app-service  
spec:  selector:  app: web-app    # service 中配置 selector 不需要使用matchLabels ports:  - protocol: TCP  port: 80  targetPort: 8080

至于 为啥 deployment 中的 selector 比 service 中多了一层的原因如下

Deployment中的selector字段是用来指定如何识别Pod的,以确保Deployment控制器能够正确地管理这些Pod。selector字段内通常包含matchLabelsmatchExpressions,它们定义了用来选择Pod的标签条件。

当使用matchLabels时,你需要提供一个或多个键值对,这些键值对必须与Pod模板中的标签完全匹配,这样Deployment才能正确地识别和管理这些Pod。通过定义这些匹配条件,Deployment控制器能够确保它所管理的Pod集合始终符合期望的状态。

为什么selector的使用需要加上matchLabels(或matchExpressions)呢?这主要有以下几个原因:

  1. 精确识别:通过matchLabels,你可以精确地指定要由Deployment管理的Pod的标签。这有助于避免管理错误的Pod或遗漏应该管理的Pod。
  2. 标签选择器灵活性:除了简单的键值对匹配外,你还可以使用matchExpressions来执行更复杂的标签选择逻辑,如“存在某个标签”或“标签的值在某个集合中”等。
  3. 状态一致性:当Deployment的期望状态与实际状态不一致时(例如,Pod数量不足或配置不匹配),控制器会使用selector来识别需要创建、更新或删除的Pod,以确保集群中的Pod集合始终符合Deployment的期望状态。
  4. 避免冲突:在Kubernetes集群中,可能同时存在多个Deployment和其他资源对象,它们可能都试图管理相同或不同的Pod。通过使用特定的selector,每个Deployment都可以明确指定它应该管理哪些Pod,从而避免潜在的冲突。

综上所述,selector中的matchLabels(或matchExpressions)是确保Deployment能够正确、有效地识别和管理其目标Pod集合的关键组成部分。

Service中不需要matchLabels是因为它的职责是提供网络访问入口和流量路由,而不是直接管理Pod的生命周期。标签选择器用于在Service中识别需要暴露的Pod集合,而Pod的管理则由其他资源对象(如Deployment)通过matchLabels等方式来负责。

Deployment

Deployment 在 RS 的基础上,又包了一层,实现了更多的功能

在这里插入图片描述

在这里插入图片描述

创建

yaml文件

apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息labels: # 标签app: nginx-deploy # 具体的 key: value 配置形式name: nginx-deploy # deployment 的名字namespace: default # 所在的命名空间
spec:replicas: 1 # 期望副本数revisionHistoryLimit: 10 # 进行滚动更新后,保留的历史版本数selector: # 选择器,用于找到匹配的 RSmatchLabels: # 按照标签匹配app: nginx-deploy # 匹配的标签key/valuestrategy: # 更新策略rollingUpdate: # 滚动更新配置maxSurge: 25% # 进行滚动更新时,更新的个数最多可以超过期望副本数的个数/比例maxUnavailable: 25% # 进行滚动更新时,最大不可用比例更新比例,表示在所有副本数中,最多可以有多少个不更新成功type: RollingUpdate # 更新类型,采用滚动更新template: # pod 模板metadata: # pod 的元信息labels: # pod 的标签app: nginx-deployspec: # pod 期望信息containers: # pod 的容器- image: nginx:1.7.9 # 镜像imagePullPolicy: IfNotPresent # 拉取策略name: nginx # 容器名称restartPolicy: Always # 重启策略terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间
1. 通过命令创建一个 deployment
kubectl create deploy nginx-deploy --image=nginx:1.7.92. 通过 yaml 文件创建
kubectl create -f xxx.yaml --record
--record 会在 annotation 中记录当前命令创建或升级了资源,后续可以查看做过哪些变动操作。#查看部署信息
kubectl get deployments#查看 rs
kubectl get rs#查看 pod 以及展示标签,可以看到是关联的那个 rs
kubectl get pods --show-labels# 快速获取一个yaml 文件方案
1. 通过命令创建一个 deploy
2. kubectl get deploy <deploy_name> -o yaml  # 去除不需要的,改一改就可以用了
滚动更新

只有修改了 deployment 配置文件中的 template 中的属性后,才会触发更新操作

#修改 nginx 版本号
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1#或者通过 kubectl edit deployment/nginx-deployment 进行修改#查看滚动更新的过程
kubectl rollout status deploy <deployment_name>#查看部署描述,最后展示发生的事件列表也可以看到滚动更新过程
kubectl describe deploy <deployment_name>
'''
通过 kubectl get deployments 获取部署信息,UP-TO-DATE 表示已经有多少副本达到了配置中要求的数目
通过 kubectl get rs 可以看到增加了一个新的 rs
通过 kubectl get pods 可以看到所有 pod 关联的 rs 变成了新的
'''

注:假设当前有 5 个 nginx:1.7.9 版本,你想将版本更新为 1.9.1,当更新成功第三个以后,你马上又将期望更新的版本改为 1.9.2,那么此时会立马删除之前的三个,并且立马开启更新 1.9.2 的任务

回滚版本

有时候你可能想回退一个Deployment,例如,当Deployment不稳定时,比如一直crash looping。

默认情况下,kubernetes会在系统中保存前两次的Deployment的rollout历史记录,以便你可以随时会退(你可以修改revision history limit来更改保存的revision数)。

#更新 deployment 时参数不小心写错,如 nginx:1.9.1 写成了 nginx:1.91
kubectl set image deployment/nginx-deploy nginx=nginx:1.91#监控滚动升级状态,由于镜像名称错误,下载镜像失败,因此更新过程会卡住
kubectl rollout status deployments nginx-deploy#结束监听后,获取 rs 信息,我们可以看到新增的 rs 副本数是 2 个
kubectl get rs#通过 kubectl get pods 获取 pods 信息,我们可以看到关联到新的 rs 的 pod,状态处于 ImagePullBackOff 状态#为了修复这个问题,我们需要找到需要回退的 revision 进行回退
#通过命令可以获取 revison 的列表
kubectl rollout history deployment/nginx-deploy#通过可以查看详细信息
kubectl rollout history deployment/nginx-deploy --revision=2 #确认要回退的版本后,可以回退到上一个版本
kubectl rollout undo deployment/nginx-deploy #也可以回退到指定的 revision
kubectl rollout undo deployment/nginx-deploy --to-revision=2再次通过 kubectl get deployment 和 kubectl describe deployment 可以看到,我们的版本已经回退到对应的 revison 上了可以通过设置 .spec.revisonHistoryLimit 来指定 deployment 保留多少 revison,如果设置为 0,则不允许 deployment 回退了。
扩容/缩容

通过 kube scale 命令可以进行自动扩容/缩容,以及通过 kube edit 编辑 replcas 也可以实现扩容/缩容

扩容与缩容只是直接创建副本数,没有更新 pod template 因此不会创建新的 rs

kubectl scale --replicas=3 deploy nginx-deploy
暂停和恢复

由于每次对 pod template 中的信息发生修改后,都会触发更新 deployment 操作,那么此时如果频繁修改信息,就会产生多次更新,而实际上只需要执行最后一次更新即可,当出现此类情况时我们就可以暂停 deployment 的 rollout

 # 实现暂停,直到你下次恢复后才会继续进行滚动更新kubectl rollout pause deployment <name> # 恢复更新kubectl rollout deploy <name>

StatefulSet

用于有状态服务

StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster.local

  • serviceName 为 Headless Service 的名字
  • 0…N-1 为 Pod 所在的序号,从 0 开始到 N-1
  • statefulSetName 为 StatefulSet 的名字
  • namespace 为服务所在的 namespace,Headless Servic 和 StatefulSet 必须在相同的 namespace
  • .cluster.local 为 Cluster Domain

特点:

  1. Pod 重新调度后还是能访问到相同的持久化数据,基于 PVC 来实现
  2. 稳定的网络标志,即 Pod 重新调度后其 PodName 和 HostName 不变,基于 Headless Service(即没有 Cluster IP 的 Service)来实现
  3. 有序部署,有序扩展,即 Pod 是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从 0到 N-1,在下一个Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态),基于 init containers 来实现
  4. 有序收缩,有序删除(即从 N-1 到 0)

注意事项:

kubernetes v1.5 版本以上才支持

所有pod 的vloume 必须使用PersistentVolume 或者是管理员提前建好

为了保证数据安全, 删除 StatefulSet时不会删除Volume

StatefulSet 需要一个 Headless Service 来定义DNS domain,需要在 StatefulSet之前创建好

在这里插入图片描述

创建
---
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---     # 先创建上面的service
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web  # statefulset 对象name
spec:serviceName: "nginx"  # 使用 name 为nginx 的service 来管理 dnsreplicas: 2selector:matchLabels:  # 匹配对应的标签app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.7.9ports:   # 对外暴露的端口- containerPort: 80  # 具体端口号name: web     # 端口配置的namevolumeMounts:   # 加载数据卷   使用pvc 需要提取创建 pv - name: www			# 数据卷的namemountPath: /usr/share/nginx/html  # 挂载容器内的目录volumeClaimTemplates:  # 数据卷模板- metadata:   # 数据卷描述name: www  # 数据卷nameannotations:  # 数据卷的注解volume.alpha.kubernetes.io/storage-class: anything  # sspec:   # 数据卷的规约accessModes: [ "ReadWriteOnce" ]resources:requests:storage: 1Gi  # 需要的存储资源
# 查看 service 和 statefulset => sts
kubectl get service nginx
kubectl get statefulset web# 查看 PVC 信息
kubectl get pvc# 查看创建的 pod,这些 pod 是有序的
kubectl get pods -l app=nginx# 查看这些 pod 的 dns
# 运行一个 pod,基础镜像为 busybox 工具包,利用里面的 nslookup 可以看到 dns 信息
kubectl run -i --tty --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh
nslookup web-0.nginx
扩容/缩容
$ kubectl scale sts web --replicas=5# 缩容
$ kubectl patch statefulset web -p '{"spec":{"replicas":3}}'
更新

statefulset 有两种更新方式 RollingUpdate 和 OnDelete,默认采用RollingUpdate 方式

# 镜像更新(1.23版本还不支持直接更新 image,需要 patch 来间接实现) 也就是直接改sts yaml文件
kubectl patch sts web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:1.9.1"}]'
RollingUpdate->金丝雀发布

statefulset 管理的pod 命令和deployment 不同, deploy 后缀是uuid,statefulset 管理的pod 后缀从0 开始递增,也是基于这个特性,可以通过设置 partition 的值来实现灰度发布

在这里插入图片描述

  updateStrategy:rollingUpdate:partition: 0  # 这里设置值越高, 自动更新的容器越少,设置为0,有修改就全部更新type: RollingUpdate
OnDelete
  updateStrategy:type: OnDelete  # 设置为OnDelete后,有更新后,先删除原有容器,才会更新新的容器
删除
# 删除 StatefulSet 和 Headless Service
# 级联删除:删除 statefulset 时会同时删除 pods
kubectl delete statefulset web
# 非级联删除:删除 statefulset 时不会删除 pods,删除 sts 后,pods 就没人管了,此时再删除 pod 不会重建的
kubectl deelte sts web --cascade=false
# 删除 service
kubectl delete service nginx

DaemonSet

DaemonSet 保证在每个 Node 上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:

  • 日志收集,比如 fluentd,logstash 等
  • 系统监控,比如 Prometheus Node Exporter,collectd,New Relic agent,Ganglia gmond 等
  • 系统程序,比如 kube-proxy, kube-dns, glusterd, ceph 等

在这里插入图片描述

apiVersion: apps/v1
kind: DaemonSet
metadata:name: fluentd  
spec:template:metadata:labels:app: logging  id: fluentdname: fluentd   spec:containers:- name: fluentd-esimage: agilestacks/fluentd-elasticsearch:v1.3.0env:- name: FLUENTD_ARGSvalue: -qqvolumeMounts:- name: containersmountPath: /var/lib/docker/containers- name: varlogmountPath: /varlogvolumes:- hostPath:path: /var/lib/docker/containersname: containers- hostPath:path: /var/logname: varlog

其他命令和上面sts deploy 差不多

节点选择器

DaemonSet 会忽略 Node 的 unschedulable 状态,有两种方式来指定 Pod 只运行在指定的 Node 节点上:

  • nodeSelector:只调度到匹配指定 label 的 Node 上
  • nodeAffinity:功能更丰富的 Node 选择器,比如支持集合操作
  • podAffinity:调度到满足条件的 Pod 所在的 Node 上

nodeSelector

#先为 Node 打上标签
# kubectl label nodes k8s-node1 svc_type=microsvc
# 配置后,可以通过给node 添加标签来自动添加删除 daemonset 服务
#然后再 daemonset 配置中设置 nodeSelector
spec:template:spec:nodeSelector:svc_type: microsvc

nodeAffinity

nodeAffinity 目前支持两种:requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution,分别代表必须满足条件和优选条件。比如下面的例子代表调度到包含标签 wolfcode.cn/framework-name 并且值为 spring 或 springboot 的 Node 上,并且优选还带有标签 another-node-label-key=another-node-label-value 的Node。

podAffinity

podAffinity 基于 Pod 的标签来选择 Node,仅调度到满足条件Pod 所在的 Node 上,支持 podAffinity 和 podAntiAffinity。这个功能比较绕,以下面的例子为例:
如果一个 “Node 所在空间中包含至少一个带有 auth=oauth2 标签且运行中的 Pod”,那么可以调度到该 Node
不调度到 “包含至少一个带有 auth=jwt 标签且运行中 Pod”的 Node 上

apiVersion: v1
kind: Pod
metadata:name: with-pod-affinity
spec:affinity:podAffinity:  # 将相关pod放在一起requiredDuringSchedulingIgnoredDuringExecution:  # 硬限制条件,必须满足才能调度到对应pod- labelSelector:matchExpressions:- key: authoperator: Invalues:- oauth2topologyKey: failure-domain.beta.kubernetes.io/zonepodAntiAffinity:  # 将相关标签的pod 分散开preferredDuringSchedulingIgnoredDuringExecution: # 软限制权限, 没有满足的条件,就当这个配置不存在- weight: 100podAffinityTerm:  # 定义具体反亲和性条件labelSelector:matchExpressions:- key: authoperator: Invalues:- jwttopologyKey: kubernetes.io/hostnamecontainers:- name: with-pod-affinityimage: pauseyyf/pause
滚动更新

ds 的默认滚动更新策略时RollingUpdate ,但是生产环境中不建议使用 RollingUpdate,建议使用 OnDelete 模式,这样避免频繁更新 ds

 # 默认配置updateStrategy:rollingUpdate:maxSurge: 0maxUnavailable: 1type: RollingUpdate# 建议配置updateStrategy:type: OnDelete

HAP

Pod 自动扩容:可以根据 CPU 使用率或自定义指标(metrics)自动对 Pod 进行扩/缩容。

  • 控制管理器每隔30s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
  • 支持三种metrics类型
    • 预定义metrics(比如Pod的CPU)以利用率的方式计算
    • 自定义的Pod metrics,以原始值(raw value)的方式计算
    • 自定义的object metrics
  • 支持两种metrics查询方式:Heapster和自定义的REST API
  • 支持多metrics

通常用于 Deployment/StatefulSet,不适用于无法扩/缩容的对象,如 DaemonSet

开启指标服务

kubectl top pod 相关命令需要metrics-server 服务来支撑

# 下载 metrics-server 组件配置文件
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml# 修改镜像地址为国内的地址
sed -i 's/egistry.k8s.io\/metrics-server/registry.cn-hangzhou.aliyuncs.com\/google_containers/g' metrics-server-components.yaml# 修改容器的 tls 配置,不验证 tls,在 containers 的 args 参数中增加 --kubelet-insecure-tls 参数# 安装组件
kubectl apply -f metrics-server-components.yaml# 查看 pod 状态
kubectl get pods --all-namespaces | grep metrics

测试方案

实现 cpu 或内存的监控,首先有个前提条件是该对象必须配置了 resources.requests.cpu 或 resources.requests.memory 才可以,可以配置当 cpu/memory 达到上述配置的百分比后进行扩容或缩容创建一个 HPA:
1. 先准备一个好一个有做资源限制的 deployment
2. 执行命令 kubectl autoscale deploy nginx-deploy --cpu-percent=20 --min=2 --max=5
3. 通过 kubectl get hpa 可以ku获取 HPA 信息测试:找到对应服务的 service,编写循环测试脚本提升内存与 cpu 负载
while true; do wget -q -O- http://<ip:port> > /dev/null ; done可以通过多台机器执行上述命令,增加负载,当超过负载后可以查看 pods 的扩容情况 kubectl get pods查看 pods 资源使用情况
kubectl top pods扩容测试完成后,再关闭循环执行的指令,让 cpu 占用率降下来,然后过 5 分钟后查看自动缩容情况

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://xiahunao.cn/news/2982175.html

如若内容造成侵权/违法违规/事实不符,请联系瞎胡闹网进行投诉反馈,一经查实,立即删除!

相关文章

JumpServer 堡垒机架构

需求背景&#xff1a; 最近由于项目审计需要&#xff0c;要求企业加固应用和系统&#xff0c;顺便加固一些日常使用的软件和系统&#xff0c;远程接入访问安全问题。 需求目的&#xff1a; 部署实施&#xff1a; 1、系统安装 安装执行 curl -sSL https://resource.fit2clou…

Spring 注解开发详解

1. 注解驱动入门案例介绍 1.1 需求描述 1.需求&#xff1a;实现保存一条数据到数据库。 2.表结构&#xff1a;create table account(id int primary key auto_increment,name varchar(50),money double(7,2)); 3.要求&#xff1a;使用spring框架中的JdbcTemplate和DriverMana…

问题记录:交换两行printf -打印结果不同

环境 os: windows IDE: iar toolchain&#xff1a;iar9.32 board: STM32F429 问题描述 同一个float变量&#xff0c;用两行printf打印&#xff0c;先%d打出来&#xff0c;再%.3f打出来&#xff0c;前者输出32&#xff08;正确&#xff09;&#xff0c;后者打出来是0.000。顺…

贝叶斯网络(概念、应用、实例)

目录 一、贝叶斯网络基本概念 1.1主要组成 1.2概率模型 1.3应用场景 1.4推理方法 1.5学习 二、贝叶斯网络在机器学习中的应用 三、应用实例 3.1分类 3.2推荐系统 3.3自然语言处理 一、贝叶斯网络基本概念 贝叶斯网络&#xff0c;也称为信念网络或有向无环图模型&am…

微信小程序开发六(自定义组件)

自定义组件的创建&#xff1a; 如何创建&#xff1a; 右键选择新建component 创建完成之后需要打开app.json&#xff0c;这是全局使用这个组件&#xff0c;想要单独的页面使用&#xff0c;就在当前页面的json文件中定义 "usingComponents": {"my-zj": &quo…

电子邮件免费版有哪些?免费注册电子邮箱

电子邮件有付费版和免费版两种类型&#xff0c;付费版通常具有更大的电子邮箱容量和更强大的电子邮箱功能。但是对于我们个人用户或者是中小型企业来说注册电子邮箱免费版的就够日常使用了。电子邮件的免费版提供商有Zoho Mail、微软、腾讯等&#xff0c;今天我们就来具体了解下…

电子温度计不准需要怎么处理?

电子温度计不准需要怎么处理&#xff1f; 首选将温度计完全浸入温度为0℃左右的水中&#xff0c;使温度计指示值与0℃相等&#xff0c;拿出测量待测物的温度。其次将温度计完全浸入温度为100℃左右的水中&#xff0c;使温度计指示值与100℃相等&#xff0c;拿出测量待测物的温…

丙级资质升级乙级实操:河南灌溉排涝项目所需材料清单

丙级资质升级乙级实操&#xff1a;河南灌溉排涝项目所需材料清单 在河南灌溉排涝项目中&#xff0c;从丙级资质升级到乙级资质是一个重要且复杂的过程。为了成功完成这一过程&#xff0c;需要准备一系列详尽且符合规定的材料。以下是针对此实操所需的关键材料清单&#xff1a;…

产品推荐 | 基于Intel (Altera) Cyclone IV 打造的水星Mercury CA1核心板

01 产品概述 水星Mercury CA1核心板结合了Intel Cyclone IV FPGA、通用接口如USB 2.0和Gigabit Ethernet&#xff0c;具备大量的LVDS I/O、大容量DDR2 SDRAM和大量硬件乘法器&#xff0c;这些使得水星CA1核心板非常适合数字信号处理、网络、高速I/O以及使用Intel NiosII软处理…

Laravel 6 - 第六章 服务容器

​ 文章目录 Laravel 6 - 第一章 简介 Laravel 6 - 第二章 项目搭建 Laravel 6 - 第三章 文件夹结构 Laravel 6 - 第四章 生命周期 Laravel 6 - 第五章 控制反转和依赖注入 Laravel 6 - 第六章 服务容器 Laravel 6 - 第七章 服务提供者 Laravel 6 - 第八章 门面 Laravel 6 - …

OpenAI 笔记:chat API

聊天模型接受一系列消息作为输入&#xff0c;并返回模型生成的消息作为输出。 1 导入openai 的api key from openai import OpenAIclient OpenAI(api_key***) 2 调用聊天API completion client.chat.completions.create(model"gpt-3.5-turbo",messages[{"…

TypeScript 中 interface 和 type 的使用#记录

一、interface&#xff1a;接口 interface A{label: string; }const aa ((aObj: A) > {console.log(aObj.label);//123return aObj.label; })aa({label: 123}) 1、可选属性 interface A{label: string;age?: number; } 2、只读属性 interface A{label: string;age?:…

Go Sync并发包之errgroup

你是否写过一个函数&#xff0c;它之所以很长&#xff0c;是因为它要完成很多任务&#xff0c;即使这些任务之间并不相互依赖&#xff1f; 你是否写过一个很长的函数&#xff0c;因为它要完成很多任务&#xff0c;即使这些任务并不相互依赖&#xff1f;我就遇到过这种情况。 想…

BRC铭文NFT铸造质押挖矿系统开发运营

区块链技术的不断演进与应用拓展&#xff0c;为数字资产领域带来了更多可能性。BRC铭文NFT铸造质押挖矿系统的开发与运营&#xff0c;将为用户提供一种全新的数字资产体验&#xff0c;下文将介绍其版/需求方案/逻辑项目。 1. 系统概述 BRC铭文NFT铸造质押挖矿系统旨在结合区块…

数据库之数据库恢复技术思维导图+大纲笔记

大纲笔记&#xff1a; 事务的基本概念 事务 定义 用户定义的一个数据库操作系列&#xff0c;这些操作要么全做&#xff0c;要么全不做&#xff0c;是一个不可分割的基本单位 语句 BEGIN TRANSACTION 开始 COMMIT 提交&#xff0c;提交事务的所有操作 ROLLBACK 回滚&#xff0c…

电商技术揭秘三十一:智能风控与反欺诈技术

相关系列文章 电商技术揭秘相关系列文章合集&#xff08;1&#xff09; 电商技术揭秘相关系列文章合集&#xff08;2&#xff09; 电商技术揭秘二十八&#xff1a;安全与合规性保障 电商技术揭秘二十九&#xff1a;电商法律合规浅析 电商技术揭秘三十&#xff1a;知识产权保…

科林Linux_3 进程

一、进程基础 操作系统基础的执行单元&#xff0c;调度单位 静态数据&#xff1a;只占用磁盘空间&#xff0c;不消耗其他资源 动态数据&#xff1a;磁盘 内存 CPU 1. 编译器将源码编译成一个可执行文件.exe/.elf 2. 运行后系统生成一个同名的进程 程序是进程的静态表现&a…

网络变压器的磁芯在使用中起着至关重要的作用

网络变压器的磁芯在使用中起着至关重要的作用。它主要有以下几个功能&#xff1a; 1. **提供磁通路径**&#xff1a;磁芯为变压器中电磁感应提供了闭合的磁通路径。这有助于提高变压器的效率&#xff0c;因为它确保了磁场能够有效地通过绕组。 2. **减少能量损失**&#xff1…

开发环境中的调试视图(IDEA)

当程序员写完一个代码时必然要运行这个代码&#xff0c;但是一个没有异常的代码却未必满足我们的要求&#xff0c;因此就要求程序员对已经写好的代码进行调试操作。在之前&#xff0c;如果我们要看某一个程序是否满足我们的需求&#xff0c;一般情况下会对程序运行的结果进行打…

Spring框架九大核心功能全面揭秘(一)

目录 资源管理 Java资源管理 1、来个Demo 2、原理 Spring资源管理 1、资源抽象 Resource WritableResource 2、资源加载 3、小结 环境 1、Environment 2、配置属性源PropertySource 3、SpringBoot是如何解析配置文件 类型转换 1、类型转换API …