15、Kubernetes核心技术 - 探针

目录

一、概述

二、探针类型

2.1、就绪探针(Readiness Probe)

2.2、存活探针(Liveness Probe)

三、探针探测方法

3.1、exec

3.2、httpGet

3.3、tcpSocket

四、探针配置项

五、探针使用

5.1、就绪探针(Readiness Probe)

5.2、存活探针(Liveness Probe)

5.3、TCP就绪/存活探测

六、Liveness Probe(存活探针) VS Readiness Probe(就绪探针)


一、概述

在k8s中,我们不能仅仅通过查看应用的运行状态,来判断应用是否正常,因为在某些时候,容器正常运行并不能代表应用健康,因此,k8s提供了探针(Probe)技术,来帮助我们判断容器内运行的应用是否运行正常,探针有点类似心跳检测。

二、探针类型

Kubernetes 的探针有三种类型:

2.1、就绪探针(Readiness Probe)

判断容器是否启动完成,即容器的 Ready 是否为 True,可以接收请求,如果ReadinessProbe 探测失败,则容器的 Ready 将为 False,控制器将此Pod 的Endpoint 从对应的Service的Endpoint 列表中移除,从此不再将任何请求调度此Pod 上,直到下次探测成功。通过使用 Readiness 探针,Kubernetes 能够等待应用程序完全启动,然后才允许服务将流量发送到新副本。

2.2、存活探针(Liveness Probe)

判断容器是否存活,即 Pod 是否为 running 状态,如果 LivenessProbe探测到容器不健康,则 kubelet 将 kill 掉容器,并根据容器的重启策略是否重启。如果一个容器不包含 LivenessProbe 探针,则 Kubelet 认为容器的 LivenessProbe 探针的返回值永远成功。

有时应用程序可能因为某些原因(后端服务故障等)导致暂时无法对外提供服务,但应用软件没有终止,导致 k8s无法隔离有故障的 pod,调用者可能会访问到有故障的pod,导致业务不稳定。k8s提供 livenessProbe 来检测应用程序是否正常运行,并且对相应状况进行相应的补救措施。

三、探针探测方法

每类探针都支持三种探测方法:

3.1、exec

通过在容器内执行命令来检查服务是否正常,针对复杂检测或无HTTP 接口的服务,返回值为 0,则表示容器健康。

3.2、httpGet

通过发送 http 请求检查服务是否正常,返回 200-399 状态码则表明容器健康。

3.3、tcpSocket

通过容器的 IP 和 Port 执行 TCP 检查,如果能够建立TCP 连接,则表明容器健康。

四、探针配置项

探针(Probe)有许多可选字段,可以用来更加精确的控制探针的行为。这些参数包括:

  • initialDelaySeconds:容器启动后第一次执行探测是需要等待多少秒;
  • periodSeconds:执行探测的间隔时间,默认是10秒;
  • timeoutSeconds:超时时间,当超过我们定义的时间后,便会被视为失败,默认 1 秒;
  • successThreshold:探测失败后,最少连续探测成功多少次才被认定为成功,默认是1次。;
  • failureThreshold:探测成功后,最少连续探测失败多少次才被认定为失败,默认是3次;

五、探针使用

5.1、就绪探针(Readiness Probe)

创建Pod资源清单:vim nginx-readiness-probe.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-readiness-probe
spec:
  containers:
    - name: nginx-readiness-probe
      image: nginx
      readinessProbe:  # 就绪探针
        httpGet:  # 对容器的IP地址、端口和URL路径来发送GET请求
          path: /healthz
          port: 80
        initialDelaySeconds: 10   # 等待10s后便开始就绪检查
        periodSeconds: 5    # 间隔5s检查一次
        successThreshold: 2   # 探测失败后,最少连续探测成功多少次才被认定为成功

我们指定了探针检测方式为httpGet,通过发送 http 请求检查服务是否正常,返回 200-399 状态码则表明容器健康。

$ kubectl apply -f nginx-readiness-probe.yaml 
pod/nginx-readiness-probe created

$ kubectl get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
nginx-readiness-probe   0/1     Running   0          32s   192.168.1.3   node01   <none>           <none>

$ kubectl describe pod nginx-readiness-probe
Name:             nginx-readiness-probe
Namespace:        default
Priority:         0
Service Account:  default
Node:             node01/172.30.2.2
Start Time:       Mon, 16 Jan 2023 03:23:11 +0000
Labels:           <none>
Annotations:      cni.projectcalico.org/containerID: 67b08cbc5b07020dcd7040cd47565c5405ee82641a9d3d68d9fd68b6b599c10f
cni.projectcalico.org/podIP: 192.168.1.3/32
cni.projectcalico.org/podIPs: 192.168.1.3/32
Status:           Running
IP:               192.168.1.3
IPs:
IP:  192.168.1.3
Containers:
nginx-readiness-probe:
Container ID:   containerd://23eca4eaeffce3e6801d3e7c26a60360d33b1fdb4046843ff9cf7c647adcf0a2
Image:          nginx
Image ID:       docker.io/library/nginx@sha256:b8f2383a95879e1ae064940d9a200f67a6c79e710ed82ac42263397367e7cc4e
Port:           <none>
Host Port:      <none>
State:          Running
Started:      Mon, 16 Jan 2023 03:23:16 +0000
Ready:          False
Restart Count:  0
Readiness:      http-get http://:80/healthz delay=10s timeout=1s period=5s #success=2 #failure=3
Environment:    <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-8xsm8 (ro)
Conditions:
Type              Status
Initialized       True 
Ready             False 
ContainersReady   False 
PodScheduled      True 
Volumes:
kube-api-access-8xsm8:
Type:                    Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds:  3607
ConfigMapName:           kube-root-ca.crt
ConfigMapOptional:       <nil>
DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type     Reason     Age               From               Message
----     ------     ----              ----               -------
Normal   Scheduled  43s               default-scheduler  Successfully assigned default/nginx-readiness-probe to node01
Normal   Pulling    43s               kubelet            Pulling image "nginx"
Normal   Pulled     38s               kubelet            Successfully pulled image "nginx" in 4.968467021s (4.968471311s including waiting)
Normal   Created    38s               kubelet            Created container nginx-readiness-probe
Normal   Started    38s               kubelet            Started container nginx-readiness-probe
Warning  Unhealthy  3s (x6 over 28s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 404

通过describe查看Pod描述信息后,可以看到,Readiness probe就绪检测失败了,失败原因就是我们的nginx容器中并不存在/healthz这个接口,所以响应码是404,并不在 200-399 状态码中,所以我们看到的Pod的Ready一直都是未就绪状态。

5.2、存活探针(Liveness Probe)

创建Pod资源清单:vim centos-liveness-probe.yaml

apiVersion: v1
kind: Pod
metadata:
  name: centos-liveness-probe
spec:
  containers:
    - name: centos-liveness-probe
      image: centos
      args:   # 容器启动时,执行如下的命令, 30s后删除/tmp/healthy文件
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
      livenessProbe: # 存活探针
        exec: # 在容器内执行指定命令cat /tmp/healthy
          command:
            - cat
            - /tmp/healthy
        initialDelaySeconds: 5  # 等待5s后开始存活检查
        periodSeconds: 5  # 间隔5s检查一次

在这个配置文件中,可以看到 Pod 中只有一个 Container。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值,kubelet 会杀死这个容器并根据重启策略重新启动它。

当容器启动时,执行如下的命令:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"

这个容器生命的前 30 秒,/tmp/healthy 文件是存在的。 所以在这最开始的 30 秒内,执行命令 cat /tmp/healthy 会返回成功代码。 30 秒之后,执行命令 cat /tmp/healthy 就会返回失败代码。

创建 Pod:

$ kubectl apply -f centos-liveness-probe.yaml 
pod/centos-liveness-probe created

$ kubectl get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
centos-liveness-probe   1/1     Running   0          9s    192.168.1.6   node01   <none>           <none>

# 在 30 秒内,查看 Pod 的事件
$ kubectl describe pod centos-liveness-probe
Name:             centos-liveness-probe
Namespace:        default
Priority:         0
Service Account:  default
Node:             node01/172.30.2.2
Start Time:       Mon, 16 Jan 2023 03:42:49 +0000
Labels:           <none>
Annotations:      cni.projectcalico.org/containerID: 74ae52265e8236ec904a23c98f8eb6a929df6709c29643f8cf3a624274105ab6
                  cni.projectcalico.org/podIP: 192.168.1.6/32
                  cni.projectcalico.org/podIPs: 192.168.1.6/32
Status:           Running
IP:               192.168.1.6
IPs:
  IP:  192.168.1.6
Containers:
  centos-liveness-probe:
    Container ID:  containerd://272c3f8bf293271f3657d98e1e23922312de46afebc3ed76a65104bbe4209e39
    Image:         centos
    Image ID:      docker.io/library/centos@sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6c473f432b177
    Port:          <none>
    Host Port:     <none>
    Args:
      /bin/sh
      -c
      touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    State:          Running
      Started:      Mon, 16 Jan 2023 03:42:50 +0000
    Ready:          True
    Restart Count:  0
    Liveness:       exec [cat /tmp/healthy] delay=5s timeout=1s period=5s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-d69p9 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-d69p9:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  17s   default-scheduler  Successfully assigned default/centos-liveness-probe to node01
  Normal  Pulling    16s   kubelet            Pulling image "centos"
  Normal  Pulled     16s   kubelet            Successfully pulled image "centos" in 458.064227ms (458.070248ms including waiting)
  Normal  Created    16s   kubelet            Created container centos-liveness-probe
  Normal  Started    16s   kubelet            Started container centos-liveness-probe

如上,可以看到,30s内输出结果表明还没有存活探针失败。

那么等待30s以后,我们再次查看Pod详细信息:

$ kubectl describe pod centos-liveness-probe
Name:             centos-liveness-probe
Namespace:        default
Priority:         0
Service Account:  default
Node:             node01/172.30.2.2
Start Time:       Mon, 16 Jan 2023 03:42:49 +0000
Labels:           <none>
Annotations:      cni.projectcalico.org/containerID: 74ae52265e8236ec904a23c98f8eb6a929df6709c29643f8cf3a624274105ab6
                  cni.projectcalico.org/podIP: 192.168.1.6/32
                  cni.projectcalico.org/podIPs: 192.168.1.6/32
Status:           Running
IP:               192.168.1.6
IPs:
  IP:  192.168.1.6
Containers:
  centos-liveness-probe:
    Container ID:  containerd://b03f2aaf2b854071223aae43cdfee4b9d1d4d3dd03f8ee7270b857817d362ca7
    Image:         centos
    Image ID:      docker.io/library/centos@sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6c473f432b177
    Port:          <none>
    Host Port:     <none>
    Args:
      /bin/sh
      -c
      touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    State:          Running
      Started:      Mon, 16 Jan 2023 03:44:05 +0000
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Mon, 16 Jan 2023 03:42:50 +0000
      Finished:     Mon, 16 Jan 2023 03:44:04 +0000
    Ready:          True
    Restart Count:  1
    Liveness:       exec [cat /tmp/healthy] delay=5s timeout=1s period=5s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-d69p9 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-d69p9:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  109s                default-scheduler  Successfully assigned default/centos-liveness-probe to node01
  Normal   Pulled     108s                kubelet            Successfully pulled image "centos" in 458.064227ms (458.070248ms including waiting)
  Warning  Unhealthy  64s (x3 over 74s)   kubelet            Liveness probe failed: cat: /tmp/healthy: No such file or directory
  Normal   Killing    64s                 kubelet            Container centos-liveness-probe failed liveness probe, will be restarted
  Normal   Pulling    33s (x2 over 108s)  kubelet            Pulling image "centos"
  Normal   Created    33s (x2 over 108s)  kubelet            Created container centos-liveness-probe
  Normal   Started    33s (x2 over 108s)  kubelet            Started container centos-liveness-probe
  Normal   Pulled     33s                 kubelet            Successfully pulled image "centos" in 405.865965ms (405.870664ms including waiting)

在输出结果的最下面,有信息显示存活探针失败了(Liveness probe failed: cat: /tmp/healthy: No such file or directory),这个失败的容器被杀死并且被重建了。

再等 30 秒,这个容器被重启了,输出结果显示 RESTARTS 的值增加了 1。 请注意,一旦失败的容器恢复为运行状态,RESTARTS 计数器就会增加 1:

controlplane $ kubectl get pod -o wide
NAME                    READY   STATUS    RESTARTS      AGE     IP            NODE     NOMINATED NODE   READINESS GATES
centos-liveness-probe   1/1     Running   2 (69s ago)   3m39s   192.168.1.6   node01   <none>           <none>

因为默认的重启策略restartPolicy是Always,所以centos-liveness-probe将会一直重启。

5.3、TCP就绪/存活探测

前面两个示例,分别演示了exec和httpGet探测方式,这里演示一下基于tcpSocket的探测方式。

创建资源清单文件:vim tcp-socket-probe.yaml

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:	# 就绪探针
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:	# 存活探针
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

如上配置,kubelet 会在容器启动 5 秒后发送第一个就绪探针。 探针会尝试连接 goproxy 容器的 8080 端口。 如果探测成功,这个 Pod 会被标记为就绪状态,kubelet 将继续每隔 10 秒运行一次探测。

除了就绪探针,这个配置包括了一个存活探针。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 与就绪探针类似,存活探针会尝试连接 goproxy 容器的 8080 端口。 如果存活探测失败,容器会被重新启动。

$ kubectl apply -f tcp-socket-probe.yaml 
pod/goproxy created

$ kubectl get pod/goproxy -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
goproxy   1/1     Running   0          99s   192.168.1.3   node01   <none>           <none>

可以看到,goproxy容器的READY为1/1,说明就绪探测成功了,并且STATUS为Running运行状态,说明goproxy容器当前是健康的。

$ kubectl describe pod/goproxy
Name:             goproxy
Namespace:        default
Priority:         0
Service Account:  default
Node:             node01/172.30.2.2
Start Time:       Mon, 16 Jan 2023 05:15:18 +0000
Labels:           app=goproxy
Annotations:      cni.projectcalico.org/containerID: 24cf48d7ee8e5ea9fe846afb16510c46cd63c9214c3a54aa2d548e647aa162fb
                  cni.projectcalico.org/podIP: 192.168.1.3/32
                  cni.projectcalico.org/podIPs: 192.168.1.3/32
Status:           Running
IP:               192.168.1.3
IPs:
  IP:  192.168.1.3
Containers:
  goproxy:
    Container ID:   containerd://c07e285dda94eb1ebc75c7aef01dc1816d4f027c007a7bb741b2a023ab4112d2
    Image:          registry.k8s.io/goproxy:0.1
    Image ID:       registry.k8s.io/goproxy@sha256:5334c7ad43048e3538775cb09aaf184f5e8acf4b0ea60e3bc8f1d93c209865a5
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 16 Jan 2023 05:15:21 +0000
    Ready:          True
    Restart Count:  0
    Liveness:       tcp-socket :8080 delay=15s timeout=1s period=20s #success=1 #failure=3
    Readiness:      tcp-socket :8080 delay=5s timeout=1s period=10s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-4bcg8 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-4bcg8:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  3m27s  default-scheduler  Successfully assigned default/goproxy to node01
  Normal  Pulling    3m26s  kubelet            Pulling image "registry.k8s.io/goproxy:0.1"
  Normal  Pulled     3m24s  kubelet            Successfully pulled image "registry.k8s.io/goproxy:0.1" in 2.531715761s (2.53172162s including waiting)
  Normal  Created    3m24s  kubelet            Created container goproxy
  Normal  Started    3m24s  kubelet            Started container goproxy

六、Liveness Probe(存活探针) VS Readiness Probe(就绪探针)

liveness probe(存活探针)

readiness probe(就绪探针)

用途

判断容器是否存活

判断Pod是否就绪

检测期

Pod运行期

Pod启动期

失败处理

Kill容器

停止向Pod发送流量

探针类型

httpGet、exec、tcpSocket

httpGet、exec、tcpSocket

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

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

智慧工厂UWB技术定位系统源码,工厂人员轨迹定位系统源码

智慧工厂人员定位系统通过在作业现场部署UWB高精度定位设备及网络&#xff0c;实现人、车、物的实时位置监控。搭建二维或三维业务功能展现平台&#xff0c;集成现场视频监控、门禁系统&#xff0c;实现工厂人员定位与视频监控和门禁联动&#xff0c;实时掌握全厂人员、车辆、作…

C#_var

文章目录 一、前言二、隐式类型的局部变量2.1 var和匿名类型2.2 批注 三、总结 一、前言 C#中有一个 var 类型&#xff0c;不管什么类型的变量&#xff0c;都可以用它接收&#xff0c;实属懒人最爱了。 我没有了解过它的底层&#xff0c;甚至没看过它的说明文档&#xff0c;也…

2023年安全狗答卷:十年命题 安全以赴

你好 2024 2023年&#xff0c;既是网络安全攻防变化的一年 也是安全狗2013年到2023年十年发展里 浓墨重彩的一笔 在新故相推之间 安全狗怀揣着不变的守护初心 迎来了十年安全命题的新起点 2024年&#xff0c;坚守安全&#xff0c;拥抱新命题

SpringBoot整合Elasticsearch报错

本文来记录一下SpringBoot整合Elasticsearch报错 文章目录 报错如下报错原因es7.15.2版本下载 报错如下 报错如下 2024-01-02 15:09:10.349 ERROR 134936 --- [nio-8088-exec-6] o.a.c.c.C.[.[.[/]. [dispatcherServlet] : Servlet.service() for servlet [dispatcherServle…

人工智能在金融领域的应用存在的4大挑战

金融服务供应商应该有计划地应对AI面临的难题 金融行业投资人工智能热潮带来有关数据安全和透明度的新问题。由于数据管理实践随着新的 AI 解决方案的引入而不断发展&#xff0c;应对这些新问题以及金融服务领域 AI 面临的其他挑战尤为重要。各组织必须认识到可能面临以下挑战…

Sharding Sphere 教程 简介

一 文档简介 1.1 分库分表诞生的前景 随着系统用户运行时间还有用户数量越来越多&#xff0c;整个数据库某些表的体积急剧上升&#xff0c;导致CRUD的时候性能严重下降&#xff0c;还容易造成系统假死。 这时候系统都会做一些基本的优化&#xff0c;比如加索引…

Java版商城:Spring Cloud+SpringBoot b2b2c电子商务平台,多商家入驻、直播带货及免 费 小程序商城搭建

​随着互联网的快速发展&#xff0c;越来越多的企业开始注重数字化转型&#xff0c;以提升自身的竞争力和运营效率。在这个背景下&#xff0c;鸿鹄云商SAAS云产品应运而生&#xff0c;为企业提供了一种简单、高效、安全的数字化解决方案。 鸿鹄云商SAAS云产品是一种基于云计算的…

钉钉-蓝牙打卡和平台打卡的区别

钉钉的群是部门概念。 你的账号归属到哪个群&#xff0c;就是哪个群的员工。 -------------------------------------------------------------------- 蓝牙打卡是对账号归属进行打卡的。 平台打卡是只对属于自己平台内的账号打卡的。 ----------------------------------…

安装多版本node

下载不同版本的安装包&#xff0c;windows系统&#xff0c;下载.msi格式的安装包&#xff1a;node版本可以去node中网网下载 或者在这里下载 Index of /dist/&#xff1b; 安装过程由低版本到高版本安装&#xff1b; 在安装下一个版本之前&#xff0c;先修改上一个版本文件夹…

C++基本语言:1.9迭代器精彩演绎,失效分析及弥补、实战

C基本语言包含10章节内容&#xff0c;存于C从入门到精通专栏 目录 一、迭代器简介 二、容器的迭代器类型 三、迭代器begin()/end()、反向迭代器rbegin/rend操作 1&#xff0e;迭代器 1.1begin和end 1.2 反向迭代器 rbegin&#xff08;&#xff09;和rend&#xff08;&am…

C++ DAY5 作业

1.全局变量&#xff0c;int monster 10000;定义英雄类hero&#xff0c;受保护的属性string name&#xff0c;int hp.int attck;公有的无参构造&#xff0c;有参构造&#xff0c;虚成员函数void Atk()blood-0;}&#xff0c;法师类继承自英雄类&#xff0c;私有属性int ap_atk50…

MatrixOne 1.1.0 Release

我们非常高兴地宣布&#xff1a; MatrixOne内核1.1.0版本 正式发布啦&#xff01; 项目文档网站 https://docs.matrixorigin.cn MatrixOne是一款分布式超融合异构数据库&#xff0c;MatrixOne旨在提供一个云原生、高性能、高弹性、高度兼容MySQL的HSTAP数据库&#xff0c;让…

SpringCloud微服务架构,适合接私(附源码)

一个由商业级项目升级优化而来的微服务架构&#xff0c;采用SpringBoot 2.7 、SpringCloud 等核心技术构建&#xff0c;提供基于React和Vue的两个前端框架用于快速搭建企业级的SaaS多租户微服务平台。 架构图 项目介绍 用户权益 仅允许免费用于学习、毕设、公司项目、私活等。…

Java技术栈 —— Hadoop入门(一)

Java技术栈 —— Hadoop入门&#xff08;一&#xff09; 一、Hadoop第一印象二、安装Hadoop三、Hadoop解析3.1 Hadoop生态介绍3.1.1 MapReduce - 核心组件3.1.2 HDFS - 核心组件3.1.3 YARN - 核心组件3.1.4 其它组件3.1.4.1 HBase3.1.4.2 Hive3.1.4.3 Spark 一、Hadoop第一印象…

IoTDB 集群部署——windows

本文的测试环境为window server2016&#xff0c;版本包为1.1.0&#xff0c;jdk版本为1.8 首先下载IoTDB版本包&#xff0c;链接地址如下 https://archive.apache.org/dist/iotdb/1.1.0/apache-iotdb-1.1.0-all-bin.zip 本次部署将使用1个ConfigNode 和3个DataNode模式&#…

Java基础-----集合类(一)

文章目录 1.集合类简介2. 自定义集合类 1.集合类简介 集合和数组一样&#xff0c;都是用来存储多个数据的结构&#xff0c;也可以称作容器。 数组长度是不可变化的&#xff0c;一旦在初始化数组时指定了数组长度&#xff0c;这个长度就不可变。如果需要处理数量变化的数据&am…

我在CSDN的2023年

一、引言 在2023年的这一年当中&#xff0c;在CSDN的生活让我得到许多知识与启发&#xff0c;也让我获得一些快乐和成就 二、自己的收获 在这一年当中&#xff0c;我从一个只会看别人写的文章解决问题到&#xff0c;可以自己写文章帮别人解决问题&#xff0c;这种成就感是极大…

【数据不完整?用EM算法填补缺失】期望值最大化 EM 算法:睹始知终

期望值最大化算法 EM&#xff1a;睹始知终 算法思想算法推导算法流程E步骤&#xff1a;期望M步骤&#xff1a;最大化陷入局部最优的原因 算法应用高斯混合模型&#xff08;Gaussian Mixture Model, GMM&#xff09;问题描述输入输出Python代码实现 算法思想 期望值最大化方法&a…

手把手教你学会接口自动化框架的搭建-前言

在网上看过很多帖子,各种接口自动化的框架眼花缭乱,但是对于很多才做自动化的新手,那是一头雾水。 因此,我决定出一个系列,让你能够按照我的文档一步步把接口自动化都做起来,而不是网上这种一股脑的全部抛出,让你看的云里雾里的。 看完这些文档保证你能去任何一家公司,…

面对众多知识付费平台,如何做出明智的选择?

在当今的知识付费市场中&#xff0c;用户面临的选择越来越多&#xff0c;如何从众多知识付费平台中正确选择属于自己的平台呢&#xff1f;下面&#xff0c;我们将为您介绍明理信息科技知识付费平台相比同行的优势&#xff0c;帮助您做出明智的选择。 一、创新的技术架构&#…