K8s Service网络详解(二)

K8s Service网络详解(二)

  • Kube Proxy
    • 调度模式
    • Kube-proxy Iptables
    • Kube-proxy IPVS
  • Service Selector
  • Pod DNS
    • 种常见的 DNS 服务
    • Kube-DNS
    • CoreDNS
      • Corefile 配置
    • DNS 记录
      • DNS 记录 Service
      • DNS 记录 Pod
      • DNS 配置策略
    • Pod 的主机名设置优先级
  • Ingress

Kube Proxy

Kubernetes 在设计之初就充分考虑了针对容器的服务发现负载均衡机制。 Service 资源,可以通过 kube-proxy 配合 cloud provider 来适应不同的应用场景。

Service相关的事情都由Node节点上的 kube-proxy处理。在Service创建时Kubernetes会分配IP给Service,同时通过API Server通知所有kube-proxy有新Service创建了,kube-proxy收到通知后通过 Iptables/IPVS 记录 Service和IP/端口 对应的关系,从而让Service在节点上可以被查询到。

kube-proxy还会监控Service和 Endpoint的变化,从而保证Pod重建后仍然能通过Service访问到Pod。

kube-proxy存在于各个node节点上

kube-proxy老版本默认使用的是 iptables模式,通过各个node节点上的iptables规则来实现service的负载均衡,但是随着service数量的增大,iptables模式由于线性查找匹配、全量更新等特点,其性能会显著下降

从k8s的1.8版本开始,kube-proxy引入了IPVS模式,IPVS模式与iptables同样基于Netfilter,但是采用的hash表,因此当service数量达到一定规模时,hash查表的速度优势就会显现出来,从而提高service的服务性能。

目前,kubernetes 中的负载均衡大致可以分为以下几种机制,每种机制都有其特定的应用场景:

Service:直接用 Service 提供 cluster 内部的负载均衡,并借助 cloud provider 提供的 LB 提供外部访问

Ingress Controller:还是用 Service 提供 cluster 内部的负载均衡,但是通过自定义 Ingress Controller 提供外部访问

Service Load Balancer:把 load balancer 直接跑在容器中,实现 Bare Metal 的 Service Load Balancer

Custom Load Balancer:自定义负载均衡,并替代 kube-proxy,一般在物理部署 Kubernetes 时使用,方便接入公司已有的外部服务

Service 与 Endpoints和 Pod的关系

image-20230723113911978

调度模式

基于Linux下的kube-proxy支持的3种调度模式

  • 用户空间(Userspace) k8s 1.1版本前

  • iptables k8s 1.10版本以前

  • IPVS k8s 1.11版本之后,如果没有开启ipvs,则自动降级为iptables

Windows 上的 kube-proxy 只有一种模式可用:

  • kernelspace

kube-proxy 在 Windows 内核中配置数据包转发规则的一种模式

ipvs和iptables都是基于netfilter的,两者差别如下:

  • ipvs 为大型集群提供了更好的可扩展性和性能

  • ipvs 支持比 iptables 更复杂的负载均衡算法(最小负载、最少连接、加权等等)

  • ipvs 支持服务器健康检查和连接重试等功能

image-20230723182011466

Kube-proxy Iptables

kube-proxy监听Kubernetes API Server,一旦Service 和 EndpointSlice 对象有变化(service创建删除和修改, pod的扩张与缩小),就将需要新增的规则添加到 iptables中。

kube-proxy只是作为controller,而不是server,真正服务的是内核的netfilter,体现在用户态则是iptables。

kube-proxy的 iptables方式支持的负载分发策略:

  • RoundRobin(默认模式)

  • SessionAffinity

kubernetes只操作了filter和nat表

Filter表中:一个基本原则是只过滤数据包而不修改他们

​ filter table的优势是小而快,可以hook到input,output和forward。这意味着针对任何给定的数据包,只有可能有一个地方可以过滤它。

NAT表:主要作用是在 PREROUTINGPOSTROUNTING的钩子中,修改目标地址源地址

​ 与filter表稍有不同的是,该表中只有新连接的第一个包会被修改,修改的结果会自动apply到同一连接的后续包中。

kube-proxy 对 iptables 的链 进行了扩充:自定义了 KUBE-SERVICESKUBE-NODEPORTSKUBE-POSTROUTINGKUBE-MARK-MASQKUBE-MARK-DROP 五个链,并主要通过为KUBE-SERVICES chain 增加 规则(rule) 来配制traffic routing 规则。

查看nat表的OUTPUT链,存在kube-proxy创建的KUBE-SERVICE链

iptables -nvL OUTPUT -t nat
iptables -nvL KUBE-SERVICES -t nat |grep service-demo接着是查看这条链,以1/3的概率跳转到其中一条
iptables -nvL KUBE-SVC-EJUV4ZBKPDWOZNF4 -t nat最后KUBE-SEP-BTFJGISFGMEBGVUF链终于找到了DNAT规则
iptables -nvL KUBE-SEP-BTFJGISFGMEBGVUF -t nat

Kube-proxy IPVS

IPVS 模式在工作时,当我们创建了前面的 Service 之后,kube-proxy 首先会在宿主机上创建一个虚拟网卡kube-ipvs0,并为它分配 Service VIP 作为 IP 地址。

接着kube-proxy通过Linux的IPVS模块为这个 IP 地址添加三个 IPVS 虚拟主机,并设置这三个虚拟主机之间使用轮询模式 来作为负载均衡策略。

kube-proxy监听API Server中service和endpoint的变化情况,调用netlink 接口创建相应的ipvs 规则,并定期将ipvs规则与 Services和 Endpoints同步。

IPVS代理模式基于netfilter hook函数,该函数类似于iptables模式,但使用hash表作为底层数据结构,在内核空间中工作。这意味着IPVS模式下的kube-proxy使用更低的重定向流量。其同步规则的效率和网络吞吐量也更高。

IPVS 模式支持更多的负载均衡策略

  • 轮询(Round Robin,RR):依次将请求分配到后端服务器,循环往复。
  • 加权轮询(Weighted Round Robin,WRR):根据服务器的权重分配请求,权重越高的服务器被分配到的请求越多。
  • 最少连接(Least Connections,LC):将请求分配到当前连接数最少的服务器。
  • 源地址哈希(Source Hashing,SH):根据请求来源的 IP 地址进行散列,将相同 IP 地址的请求分配到同一台后端服务器上。
  • 永不排队(never queue)

Service Selector

Service 通过标签来选取服务后端,一般配合 Replication Controller 或者 Deployment 来保证后端容器的正常运行。这些匹配标签的 Pod IP 和端口列表组成 endpoints,由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。

在Kubernetes中,Selector是用于标识一组资源的标签选择器。这些资源可以是Pod、Service或者其他Kubernetes对象,通过在资源上定义标签,可以将它们组织成为相互关联的逻辑单元。Selector是访问这些逻辑单元的关键方式。 Selector的语法形式类似于CSS选择器,在Kubernetes中,我们可以通过使用逗号运算符和括号运算符对多个Selector进行组合,以实现更加复杂的选择方式。

如何使用Selector?

在Kubernetes中,Selector常被用于指定需要操作的对象,例如在创建Service时,需要通过Selector指定它所要代理的Pod。

以下是一个Service的例子,它通过Selector选择标签键为"app",值为"nginx"的Pod:

apiVersion: v1 
kind: Service 
metadata: 
name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 

在以上的配置文件中,selector字段用于指定Service所要代理的Pod。在这个例子中,Service将会代理所有标签键为"app",值为"nginx"的Pod,并将它们对外暴露在端口80上。

Pod DNS

种常见的 DNS 服务

  • kube-dns 也是(Cluster DNS)
  • CoreDNS

在 Kubernetes 1.11 及其以后版本中,推荐使用 CoreDNS

Kube-DNS

GitHub项目地址:https://github.com/kubernetes/dns

image-20230723113657740

kube-dns 的 pod 中包含了 3 个容器

  • kube-dns
  • dns-dnsmasq
  • dns-sidecar

各个容器功能:

kube-dns容器功能

  • 提供service name域名的解析(用于k8s集群内部的域名解析),监视k8s Service资源并更新DNS记录
  • 替换etcd,使用TreeCache数据结构保存DNS记录并实现SkyDNS的Backend接口
  • 接入SkyDNS,对dnsmasq提供DNS查询服务

dnsmasq容器功能

  • 对集群提供DNS查询服务
  • 设置kubedns为upstream
  • 提供DNS缓存,降低kubedns负载,提高性能

dns-sidecar容器功能

定期检查kubedns和dnsmasq的健康状态
为k8s活性检测提供HTTP API

CoreDNS

项目官网:https://coredns.io/

CoreDNS使用Go语言编写。What is CoreDNS?

CoreDNS实现非常灵活,几乎所有功能,都是以插件的方式实现,插件可以是独立使用,也可以协同完成 “DNS 功能”。

有一些插件与Kubernetes通信以提供服务发现,这些插件可以从文件或数据库中读取数据。

Miek Gieben 在 2016 年编写了 CoreDNS 的初始版本,在此之前他还写过一个叫作 SkyDNS 的 DNS 服务器,以及一个用 Go 语言写的 DNS 函数库 Go DNS。

可以通过维护 Corefile,即 CoreDNS 配置文件, 来配置 CoreDNS 服务器。与 BIND 的配置文件的语法相比,CoreDNS 的 Corefile 使用起来非常简单。作为一个集群管理员,你可以修改 CoreDNS Corefile 的 ConfigMap, 以更改 DNS 服务发现针对该集群的工作方式。

CoreDNS的限制

目前 CoreDNS 仍然有一些特别的限制,使得它并不适合所有的 DNS 服务器场景。其中最主要的是,CoreDNS 不支持完整的递归(recursion)功能;即,CoreDNS 不能从根 DNS 命名空间开始处理查询。查询根 DNS 服务器并跟踪引用直到从某个权威 DNS 服务器返回最终结果,需要依赖其他 DNS 服务器(通常称为转发器(forwarder))来实现。

Corefile 配置

在 Kubernetes 中,CoreDNS 安装时使用如下默认 Corefile 配置:

apiVersion: v1
kind: ConfigMap
metadata:name: corednsnamespace: kube-system
data:Corefile: |.:53 {errorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153forward . /etc/resolv.confcache 30loopreloadloadbalance}    

Corefile 配置包括以下 CoreDNS 插件:

  • errors:错误记录到标准输出。

  • health:在 http://localhost:8080/health 处提供 CoreDNS 的健康报告。 在这个扩展语法中,lameduck 会使此进程不健康,等待 5 秒后进程被关闭。

  • ready:在端口 8181 上提供的一个 HTTP 端点, 当所有能够表达自身就绪的插件都已就绪时,在此端点返回 200 OK。

  • kubernetes:CoreDNS 将基于服务和 Pod 的 IP 来应答 DNS 查询。 你可以在 CoreDNS 网站找到有关此插件的更多细节。

    • 你可以使用 ttl 来定制响应的 TTL。默认值是 5 秒钟。TTL 的最小值可以是 0 秒钟, 最大值为 3600 秒。将 TTL 设置为 0 可以禁止对 DNS 记录进行缓存。

    • pods insecure 选项是为了与 kube-dns 向后兼容。

    • 你可以使用 pods verified 选项,该选项使得仅在相同名字空间中存在具有匹配 IP 的 Pod 时才返回 A 记录。

    • 如果你不使用 Pod 记录,则可以使用 pods disabled 选项。

  • prometheus:CoreDNS 的度量指标值以 Prometheus 格式(也称为 OpenMetrics)在 http://localhost:9153/metrics 上提供。

  • forward: 不在 Kubernetes 集群域内的任何查询都将转发到预定义的解析器 (/etc/resolv.conf)。

  • cache:启用前端缓存。

  • loop:检测简单的转发环,如果发现死循环,则中止 CoreDNS 进程。

  • reload:允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后,请等待两分钟,以使更改生效。

  • loadbalance:这是一个轮转式 DNS 负载均衡器, 它在应答中随机分配 A、AAAA 和 MX 记录的顺序。

DNS 记录

DNS 记录 Service

A/AAAA 记录

普通Service 和 没有集群 IP 的Headless Service 都会被赋予一个形如 my-svc.my-namespace.svc.cluster-domain.example 的 DNS A 和/或 AAAA 记录

与普通 Service 不同,无头Service(Headless Service)的DNS记录会被解析成对应 Service 所选择的 Pod IP 的集合。 客户端要能够使用这组 IP,或者使用标准的轮转策略从这组 IP 中进行选择。

SRV 记录

Kubernetes 根据 Service(普通 Service 或无头 Service 均可) 中的命名端口创建 SRV 记录。每个命名端口, SRV 记录格式为 _port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example

普通 Service,该记录会被解析成端口号和域名:my-svc.my-namespace.svc.cluster-domain.example

无头 Service,该记录会被解析成多个结果,及该服务的每个后端 Pod 各一个 SRV 记录, 其中包含 Pod 端口号和格式为 hostname.my-svc.my-namespace.svc.cluster-domain.example 的域名。

DNS 记录 Pod

A/AAAA 记录

一般而言,Pod 会对应如下 DNS 名字解析:

pod-ip-address.my-namespace.pod.cluster-domain.example

例如,对于一个位于 default 名字空间,IP 地址为 172.17.0.3 的 Pod, 如果集群的域名为 cluster.local,则 Pod 会对应 DNS 名称:

172-17-0-3.default.pod.cluster.local

通过 Service 暴露出来的所有 Pod 都会有如下 DNS 解析名称可用:

pod-ip-address.service-name.my-namespace.svc.cluster-domain.example

DNS 配置策略

参阅:Pod 的 DNS 策略

每个Pod所使用的DNS策略,是通过pod.spec.dnsPolicy字段设置的,共有4种DNS策略:

  • ClusterFirst:默认策略,表示使用集群内部的CoreDNS来做域名解析,Pod内/etc/resolv.conf文件中配置的nameserver是集群的DNS服务器,即kube-dns的地址。
  • Default:“Default” 不是默认的 DNS 策略。Pod直接继承集群node节点的域名解析配置,也就是,Pod会直接使用宿主机上的/etc/resolv.conf文件内容。
  • None:忽略k8s集群环境中的DNS设置,Pod会使用其dnsConfig字段所提供的DNS配置,dnsConfig字段的内容要在创建Pod时手动设置好。
  • ClusterFirstWithHostNet:宿主机与 Kubernetes 共存,这种情况下的POD,既能用宿主机的DNS服务,又能使用kube-dns的Dns服务,需要将hostNetwork打开。

ClusterFirst

apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1dnsPolicy: ClusterFirst       # 字段设置为ClusterFirst(该值为默认值,不设置也是该值)
# namserver指向kube-dns service地址
$ kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 241.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5

Default

apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1dnsPolicy: Default
# pod内的resolv.conf与宿主机的resolv.conf一致
$ kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 192.168.234.2
search localdomain$ cat /etc/resolv.conf 
search localdomain
nameserver 192.168.234.2

None

apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1dnsPolicy: NonednsConfig:nameservers: ["192.168.234.1","192.168.234.2"]  # 最多可指定3个IP,当Pod的dnsPolicy设置为None时,列表必须至少包含一个IP地址searches:                                       # Pod中主机名查找的DNS搜索域列表- default.svc.cluster.local- svc.cluster.local- cluster.localoptions:- name: ndotsvalue: "5"
kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 192.168.234.1
nameserver 192.168.234.2
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

ClusterFirstWithHostNet

apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1hostNetwork: true   		# hostNetwork为true时,表示与宿主机共享网络空间dnsPolicy: ClusterFirst  # 即使dnsPolicy设置为集群优先,由于hostNetwork: true也会强制将dnsPolicy设置为Default
# 所以Pod内resolv.conf与宿主机相同
$ kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 192.168.234.2
search localdomain

对于以 hostNetwork 方式运行的 Pod,应将其 DNS 策略显式设置为 “ClusterFirstWithHostNet”。否则,以 hostNetwork 方式和 "ClusterFirst" 策略运行的 Pod 将会做出回退至 "Default" 策略的行为。

apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1hostNetwork: truednsPolicy: ClusterFirstWithHostNet
#只有dnsPolicy: ClusterFirstWithHostNet,此时pod既可以使用宿主机网络也可以使用kube-dns网络
$ kubectl exec -it mypod -- cat /etc/resolv.conf 
nameserver 241.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5

Pod 的主机名设置优先级

Pod 规约中包含一个可选的 hostname 字段,可以用来指定一个不同的主机名。当这个字段被设置时,它将优先于 Pod 的名字成为该 Pod 的主机名(同样是从 Pod 内部观察)。

例如:给定一个 spec.hostname 设置为 “my-host” 的 Pod, 该 Pod 的主机名将被设置为 “my-host”

Pod的子域名

Pod 规约还有一个可选的 subdomain 字段,可以用来表明该 Pod 是名字空间的子组的一部分。

例如:某 Pod 的 spec.hostname 设置为 “foo”spec.subdomain 设置为 “bar”, 在名字空间 “my-namespace” 中,主机名称被设置成 “foo” 并且对应的完全限定域名(FQDN)为 “foo.bar.my-namespace.svc.cluster-domain.example”(还是从 Pod 内部观察)。

Ingress

Service是基于四层TCP和UDP协议转发的,而Ingress可以基于七层的HTTP和HTTPS协议转发,可以通过域名和路径做到更细粒度的划分,如下图所示。

image-20230723095527962

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

Ingress 是对集群中服务的外部访问进行管理的 API 对象

Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。

image-20230718003351498

Ingress工作机制

要想使用Ingress功能,必须在Kubernetes集群上安装Ingress Controller。Ingress Controller有很多种实现,最常见的就是Kubernetes官方维护的NGINX Ingress Controller

对于所有 Kubernetes API,一旦它们被正式发布(GA),就有一个创建、维护和最终弃用它们的过程。Ingress-NGINX 将拥有独立的分支和发布版本来支持这个模型,与 Kubernetes 项目流程相一致。 Ingress-NGINX 项目的未来版本将跟踪和支持最新版本的 Kubernetes。

团队目前正在升级 Ingress-NGINX 以支持向 v1 的迁移, 你可以在此处跟踪进度。

同时,团队会确保没有兼容性问题:

  • 更新到最新的 Ingress-NGINX 版本, 目前是 controller-v1.8.1。

  • Kubernetes 1.22 发布后,请确保使用的是支持 Ingress 和 IngressClass 稳定 API 的最新版本的 Ingress-NGINX。

  • 使用集群版本 >= 1.19 测试 Ingress-NGINX 版本 v1.0.0-alpha.2,并将任何问题报告给项目 GitHub 页面。

外部请求首先到达Ingress Controller,Ingress Controller根据Ingress的路由规则,查找到对应的Service,进而通过Endpoint查询到Pod的IP地址,然后将请求转发给Pod。

参阅:

k8s中的endpoint

k8s 理解Service工作原理

K8s 核心组件讲解——kube-proxy

详解k8s 4种类型Service

kubernetes集群内部DNS解析原理、域名解析超时问题记录

CoreDNS简介

Kubernetes网络

Service

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

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Appium+python自动化(二十五)-获取控件ID(超详解)

简介 在前边的第二十二篇文章里,已经分享了通过获取控件的坐标点来获取点击事件的所需要的点击位置,那么还有没有其他方法来获取控件点击事件所需要的点击位置呢?答案是:Yes!因为在不同的大小屏幕的手机上获取控件的坐…

ModStartCMS v6.9.0 后台多标签改进,主题色自动切换修复

ModStart 是一个基于 Laravel 模块化极速开发框架。模块市场拥有丰富的功能应用,支持后台一键快速安装,让开发者能快的实现业务功能开发。 系统完全开源,基于 Apache 2.0 开源协议,免费且不限制商业使用。 功能特性 丰富的模块市…

Redis学习2--使用java操作Redis

1、java操作Redis库的比较 Redis有各种语言的客户端可以来操作redis数据库,其中java语言主要有Jedis与lettuce ,Spring Data Redis封装了上边两个客户端,优缺点如下: 2、使用Jedis操作Redis Jedis使用的基本步骤: 引…

企业服务器数据库被360后缀勒索病毒攻击后采取的措施

近期,360后缀勒索病毒的攻击事件频发,造成很多企业的服务器数据库遭受严重损失。360后缀勒索病毒是Beijingcrypt勒索家族中的一种病毒,该病毒的加密形式较为复杂,目前网络上没有解密工具,只有通过专业的技术人员对其进…

原生html—摆脱ps、excel 在线绘制财务表格加水印(html绘制表格js加水印)

文章目录 ⭐前言⭐html标签💖table表格的属性💖实现财务报表 ⭐结束 ⭐前言 大家好,我是yma16,本文分享原生html——绘制表格报表加水印。 背景:解决没有ps的情况下使用前端html制作表格报表。 html介绍 HTML&#xf…

【Android知识笔记】UI体系(一)

Activity的显示原理 setContentView 首先开发者Activity的onCreate方法中通常调用的setContentView会委托给Window的setContentView方法: 接下来看Window的创建过程: 可见Window的实现类是PhoneWindow,而PhoneWindow是在Activity创建过程中执行attach Context的时候创建的…

Kotlin多平台最佳架构指南

在这篇文章中,我们将对 Kotlin 多平台移动端的最佳架构进行深入探讨。在2023年,作为 Android 开发者,我们会倾向于采用 MVVM 架构,因为它简单、灵活且易于测试。而作为 iOS 开发者,我们可能会选择 MVC、Viper 等架构。…

QT基于TCP协议实现数据传输以及波形绘制

这个玩意我做了两个,一个是安卓app,一个是Windows程序。代码并非全部都是由我从无到有实现,只是实现了我想要的功能。多亏了巨人的肩膀,开源万岁!!! 我把程序放到GitHub上,需要的可…

Vue项目如何生成树形目录结构

文章底部有个人公众号:热爱技术的小郑。主要分享开发知识、有兴趣的可以关注一手。 前言 项目的目录结构清晰、可以帮助我们更快理顺项目的整体构成。在写文档之类的时候也比较方便。生成树形目录的方式有多种,我这里简单介绍其中一种较为简单的实现 过…

学习数学助手Schooltech Math Resource Studio 7.0 Crack

数学资源工作室 数学工作表生成器:快速轻松地创建数学工作表 使用易于使用的数学工作表生成器软件创建可打印的数学练习工作表。通过练习、谜题、问题等提高数学技能。 瞄准学习需求并激励学生 Math Resource Studio 是个性化数学教学的理想软件解决方案&#xff0c…

【SDOF振荡器的非线性-非弹性多轴时间响应分析】用于SDOF振荡器非线性非弹性时程分析的鲁棒性分析研究(Matlab代码实现)

目录 💥1 概述 📚2 运行结果 🎉3 参考文献 🌈4 Matlab代码实现 💥1 概述 进行SDOF振荡器的非线性非弹性时程分析的鲁棒性分析研究,旨在探究该方法对不同系统参数和分析条件变化的稳定性和可靠性。以下是一…

几百本常用计算机开发语言电子书链接

GitHub - XiangLinPro/IT_book: 本项目收藏这些年来看过或者听过的一些不错的常用的上千本书籍,没准你想找的书就在这里呢,包含了互联网行业大多数书籍和面试经验题目等等。有人工智能系列(常用深度学习框架TensorFlow、pytorch、keras。NLP、…

用HTML写一个简单的静态购物网站

实现代码&#xff1a; <!DOCTYPE html> <html lang"en"> <head><meta charset"UTF-8"><meta name"viewport" content"widthdevice-width, initial-scale1.0"><title>购物网站</title> &l…

FRR+VPP

安装 三者的结合&#xff0c;实际上编译安装好就行了&#xff0c;不需要做任何代码上的修改&#xff0c;只需要安装和配置&#xff0c;然后你就有了一台路由器。 FRRouting使用frr-8.5.2版本&#xff0c;VPP使用23.06版本&#xff0c;DPDK和lcpng是VPP的插件&#xff0c;安装…

DataEase开源BI工具安装_数据全量_增量同步_大屏拖拽自动生成_多数据源支持_数据血缘分析---大数据工作笔记0183

我这里用的是Centos7.9安装的 可以通过uname -p来查看一下我们的电脑架构,可以看到是x86_64架构的 我们下第一个,这个是x86架构的,第二个arm架构的 然后解压到/opt/module中 然后再去重命名一下文件夹. 推荐200G 本地模式的功能比较多 推荐100G

umy-ui树形结构表格懒加载用法详解

效果图 在做后台时&#xff0c;使用的iview组件库中的树形表格&#xff0c;但数据量过大时会导致页面卡死&#xff0c;借助umy-ui的虚拟表格完美解决了数据量大卡顿的问题。 先放文档&#xff1a;http://www.umyui.com/umycomponent/u-table-column-api 安装 npm install u…

apifox 调用camunda engine-rest接口报错“type“: “NotFoundException“

官方文档在这&#xff1a; https://docs.camunda.org/rest/camunda-bpm-platform/7.19/ 现象 engine-rest本是可以直接请求的&#xff0c;我把openapi导入到apifox之中了&#xff0c;我测试一下接口没有能请求成功的&#xff0c;基本都报以下的错。 报错如下 {"type&qu…

Flutter:flutter_local_notifications——消息推送的学习

前言 注&#xff1a; 刚开始学习&#xff0c;如果某些案例使用时遇到问题&#xff0c;可以自行百度、查看官方案例、官方github。 简介 Flutter Local Notifications是一个用于在Flutter应用程序中显示本地通知的插件。它提供了一个简单而强大的方法来在设备上发送通知&#…

【LeetCode-简单】剑指 Offer 24. 反转链表(详解)

题目 定义一个函数&#xff0c;输入一个链表的头节点&#xff0c;反转该链表并输出反转后链表的头节点。 方法&#xff1a;迭代 思路 定义三个指针&#xff0c;一起往后走&#xff0c;走一步就修改mid指针的next&#xff0c;原本是mid的next 是right&#xff0c;我们修改成l…

安装支持vs2019的MFC(解决MSBuild 错误 MSB8041、MSB8042)

安装支持MFC的vs2019&#xff08;解决MSBuild 错误 MSB8041、MSB8042&#xff09; 常用安装选项解决MSBuild 错误 常用安装选项 解决MSBuild 错误 安装上述勾选内容后&#xff0c;即可解决MSBuild 错误 MSB8041 MSB8041&#xff1a;此项目需要 MFC/ATL 库。 https://learn.mic…