Kubernetes示例yaml:1. service-deployment.yaml

service-deployment.yaml 示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-plus
  namespace: aaaa
  labels:
    app: example-prd
    app_unit: AAAA-EXAMPLE
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-prd
  template:
    metadata:
      labels:
        app: example-prd
        app_unit: AAAA-EXAMPLE
    spec:
      restartPolicy: Always
      imagePullSecrets:
        - name: registrykey
      nodeSelector:
        app_name: share
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - example-prd
                topologyKey: kubernetes.io/hostname
      containers:
        - name: example-prd
          image: artifactory.com.cn/image/example:20241111
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 22
              protocol: TCP
          resources:
            requests:
              memory: "8Gi"
              cpu: "4"
            limits:
              memory: "12Gi"
              cpu: "6"
          lifecycle:
            preStop:
              exec:
                command: ["/bin/bash", "-c", "cat /etc/profile"]
          livenessProbe:
            tcpSocket:
              port: 22
            initialDelaySeconds: 60
            timeoutSeconds: 30
            periodSeconds: 15
            successThreshold: 1
            failureThreshold: 3
          readinessProbe:
            tcpSocket:
              port: 22
            initialDelaySeconds: 20
            timeoutSeconds: 30
            periodSeconds: 5
            successThreshold: 1
            failureThreshold: 3
          env:
            - name: MONITOR_TYPE
              value: "CONTAINER_ONLY"
            - name: test_logs-example
              value: stdout
            - name: test_logs-example_tags
              value: topic=elk-k8s-aaaa
            - name: MODULE
              value: "test"
          volumeMounts:
            - name: online-config
              mountPath: /run/secrets/global.conf
              subPath: global.conf
            - name: jiemi-config
              mountPath: /home/jdk/001.acpk
              subPath: 001.acpk
            - name: jiemi-config
              mountPath: /home/jdk/bris_secret_app_20200116.jar
              subPath: bris_secret_app_20200116.jar
      volumes:
        - name: online-config
          configMap:
            name: config
            items:
              - key: "global.conf"
                path: "global.conf"
        - name: jiemi-config
          configMap:
            name: jiemi
            items:
              - key: "1111.acpk"
                path: "001.acpk"
              - key: "bris_secret_app_20200116.jar"
                path: "bris_secret_app_20200116.jar"

---
apiVersion: v1
kind: Service
metadata:
  name: example-service-plus
  namespace: aaaa
  labels:
    app_unit: AAAA-EXAMPLE
spec:
  selector:
    app: example-prd
  ports:
    - name: example-prd
      port: 22
      targetPort: 22

逐行解释

逐行解释每一部分的作用和含义:

apiVersion: apps/v1
  • apiVersion: 指定要使用的 Kubernetes API 版本。
  • apps/v1: 使用的是 Apps API 中的 v1 版本,表示该文件定义了 Deployment 类型的资源。
kind: Deployment
  • kind: 指定要创建的 Kubernetes 资源类型。
  • Deployment: 表示定义了一个部署资源。
metadata:
  name: example-plus
  namespace: aaaa
  labels:
    app: example-prd
    app_unit: AAAA-EXAMPLE
  • metadata: 定义资源的元数据信息。
    • name: 指定资源的名称为 example-plus
    • namespace: 指定资源所属的命名空间为 aaaa
    • labels: 为资源添加标签,用于标识和选择资源。
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-prd
  template:
    metadata:
      labels:
        app: example-prd
        app_unit: AAAA-EXAMPLE
  • spec: 定义了资源的规格(specification)部分,即资源的具体配置信息。
    • replicas: 2: 指定要创建的 Pod 实例数量为 2 个。
    • selector: 定义了用于选择 Pod 的标签。
      • matchLabels: 指定要匹配的标签,这里选择带有 app: example-prd 的 Pod。
    • template: 定义了要创建的 Pod 的模板。
      • metadata.labels: 为创建的 Pod 添加标签,与 Deployment 的标签保持一致。

接下来是 Pod 模板的详细配置,包括容器、资源请求、生命周期管理等,我将分段解释:

spec:
  restartPolicy: Always
  • restartPolicy: Always: 定义容器的重启策略为始终重启。
  imagePullSecrets:
    - name: registrykey
  • imagePullSecrets: 定义了从私有镜像仓库拉取镜像所需的密钥或凭证,这里使用了名为 registrykey 的密钥。
  nodeSelector:
    app_name: share
  • nodeSelector: 根据节点的标签选择在哪些节点上调度 Pod,这里选择带有 app_name: share 的节点。
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: app
                  operator: In
                  values:
                    - example-prd
            topologyKey: kubernetes.io/hostname
  • affinity: 定义 Pod 的亲和性,控制 Pod 如何在集群中分布。
    • podAntiAffinity: 定义 Pod 的反亲和性,即 Pod 倾向于不被调度到与特定标签相同的其他 Pod 所在的节点上。
      • preferredDuringSchedulingIgnoredDuringExecution: 设置优先级,表示在调度时优先避免与相同标签的其他 Pod 调度在一起。
        • weight: 100: 设置优先级权重为 100。
        • labelSelector: 指定要匹配的标签选择器,这里选择带有 app: example-prd 的 Pod。
          • topologyKey: kubernetes.io/hostname: 指定拓扑域的键,这里使用节点的主机名作为拓扑域的键。

接下来是容器的配置:

containers:
  - name: example-prd
    image: artifactory.com.cn/image/example:20241111
    imagePullPolicy: IfNotPresent
  • containers: 定义了要运行的容器列表。
    • name: 容器的名称为 example-prd
    • image: 指定容器要使用的镜像地址。
    • imagePullPolicy: IfNotPresent: 设置容器拉取镜像的策略为如果本地不存在该镜像才拉取。

继续容器的配置:

    ports:
      - name: http
        containerPort: 22
        protocol: TCP
  • ports: 定义容器暴露的端口列表。
    • name: http: 定义端口的名称为 http
    • containerPort: 22: 容器内部的端口号为 22
    • protocol: TCP: 指定端口的协议为 TCP

接着是容器的资源请求和限制:

    resources:
      requests:
        memory: "8Gi"
        cpu: "4"
      limits:
        memory: "12Gi"
        cpu: "6"
  • resources: 定义容器的资源请求和限制。
    • requests: 指定容器所需的最低资源量,包括内存和CPU。
    • limits: 指定容器的资源上限,包括内存和CPU。

继续是容器的生命周期管理和健康检查:

    lifecycle:
      preStop:
        exec:
          command: ["/bin/bash", "-c", "cat /etc/profile"]
    livenessProbe:
      tcpSocket:
        port: 22
      initialDelaySeconds: 60
      timeoutSeconds: 30
      periodSeconds: 15
      successThreshold: 1
      failureThreshold: 3
    readinessProbe:
      tcpSocket:
        port: 22
      initialDelaySeconds: 20
      timeoutSeconds: 30
      periodSeconds: 5
      successThreshold: 1
      failureThreshold: 3
  • lifecycle: 定义容器的生命周期管理,这里在容器停止之前执行一个命令。
    • preStop: 容器停止之前执行的操作。
      • exec: 使用 exec 执行一个命令。

上面的配置表示,在容器即将停止之前(例如在容器被 Kubernetes 关闭之前),会执行指定的命令 /bin/bash -c "cat /etc/profile"。具体来说:

  • /bin/bash -c "cat /etc/profile":这个命令会在容器中执行,它的作用是打印输出 /etc/profile 文件的内容。
  • 这个操作可以用来在容器即将停止之前执行一些清理或日志记录操作,以确保容器停止前的一些状态或信息被记录下来。

这样的设置对于一些特定的容器应用可能很有用,例如在容器关闭之前需要执行一些清理操作或者记录重要日志信息。这样做可以确保容器关闭时的状态或信息得以保存或记录。

  • livenessProbe:定义容器的存活性检测,用于判断容器是否处于健康状态。
    • tcpSocket:使用 TCP Socket 进行存活性检测。
    • port: 22:指定检测的端口号为 22。
    • initialDelaySeconds: 60:容器启动后等待 60 秒后开始进行首次存活性检测。
    • timeoutSeconds: 30:每次检测的超时时间为 30 秒。
    • periodSeconds: 15:每隔 15 秒进行一次存活性检测。
    • successThreshold: 1:连续成功检测 1 次后认定容器为存活。
    • failureThreshold: 3:连续失败检测 3 次后认定容器为不存活。
  • readinessProbe:定义容器的就绪性检测,用于判断容器是否准备好接收流量。
    • tcpSocket:使用 TCP Socket 进行就绪性检测。
    • port: 22:指定检测的端口号为 22。
    • initialDelaySeconds: 20:容器启动后等待 20 秒后开始进行首次就绪性检测。
    • timeoutSeconds: 30:每次检测的超时时间为 30 秒。
    • periodSeconds: 5:每隔 5 秒进行一次就绪性检测。
    • successThreshold: 1:连续成功检测 1 次后认定容器为就绪状态。
    • failureThreshold: 3:连续失败检测 3 次后认定容器为不就绪状态。

这些配置用于指定 Kubernetes 如何检测和管理容器的存活性和就绪性。存活性检测用于保证容器在运行过程中不会因为某些问题而停止运行,而就绪性检测则用于确保容器能够接收流量进行服务。这些参数需要根据具体的应用特性和需求来进行调整和配置。

环境变量 (env):

env:
  - name: MONITOR_TYPE
    value: "CONTAINER_ONLY"
  - name: test_logs-example
    value: stdout
  - name: test_logs-example_tags
    value: topic=elk-k8s-aaaa
  - name: MODULE
    value: "test"

这部分配置定义了容器中的环境变量,每个条目包含了一个环境变量的名称 (name) 和对应的值 (value)。
例如,MONITOR_TYPE 的值是 “CONTAINER_ONLY”,等等。

Volume 挂载 (volumeMounts):

volumeMounts:
  - name: online-config
    mountPath: /run/secrets/global.conf
    subPath: global.conf
  - name: jiemi-config
    mountPath: /home/jdk/001.acpk
    subPath: 001.acpk
  - name: jiemi-config
    mountPath: /home/jdk/bris_secret_app_20200116.jar
    subPath: bris_secret_app_20200116.jar
  • 这部分配置定义了容器内文件系统的挂载点,将持久化卷(volumes)挂载到容器中,使容器可以访问这些文件。
  • 每个条目指定了挂载的名称 (name)、挂载的路径 (mountPath) 和子路径 (subPath)。

Volumes 定义 (volumes):

volumes:
  - name: online-config
    configMap:
      name: config
      items:
        - key: "global.conf"
          path: "global.conf"
  - name: jiemi-config
    configMap:
      name: jiemi
      items:
        - key: "1111.acpk"
          path: "001.acpk"
        - key: "bris_secret_app_20200116.jar"
          path: "bris_secret_app_20200116.jar"
  • 这部分配置定义了容器使用的持久化卷(volumes)。
  • 每个条目指定了卷的名称 (name),并且指定了从 ConfigMap 中获取数据的方式 (configMap),包括 ConfigMap 的名称 (name) 和其中的条目 (items),每个条目指定了键 (key) 和对应的路径 (path)。

这些配置共同定义了容器的环境变量、文件系统挂载点和持久化卷,使得容器能够以正确的配置和资源访问运行所需的信息和数据。

Service 对象:

---
apiVersion: v1
kind: Service
metadata:
  name: example-service-plus
  namespace: aaaa
  labels:
    app_unit: AAAA-EXAMPLE
  • apiVersion: v1: 表示使用的 Kubernetes API 版本是 v1。
  • kind: Service: 定义了一个 Kubernetes Service 对象,用于暴露应用程序到集群内部或外部的访问。
  • metadata: 元数据部分,用于定义对象的基本信息。
    • name: example-service-plus: Service 的名称为 example-service-plus
    • namespace: aaaa: Service 所属的命名空间为 aaaa
    • labels: 定义了标签,其中 app_unit: AAAA-EXAMPLE 表示这个 Service 关联到标签为 app_unit: AAAA-EXAMPLE 的资源。
spec:
  selector:
    app: example-prd
  ports:
    - name: example-prd
      port: 22
      targetPort: 22
  • spec: 定义了 Service 的规格,包括选择器和端口信息。
    • selector: 指定了由该 Service 管理的 Pod 的标签选择器。这里的 app: example-prd 表示选择标签为 app: example-prd 的 Pod。
    • ports: 指定了 Service 所暴露的端口信息。
      • name: example-prd: 端口的名称为 example-prd,可用于区分多个端口。
      • port: 22: Service 所监听的端口号为 22,表示外部对该 Service 的访问将使用该端口号。
      • targetPort: 22: 将进入该 Service 的流量转发到 Pod 的端口号为 22 的容器。

ports 部分的 name 字段是可选的,您可以不提供该字段。如果不指定 name 字段,则 Kubernetes 会自动为该端口生成一个默认的名称。通常是一个格式化的字符串,类似于 <protocol>-<port>-<auto-generated-number>。在实际使用中,如果不需要对端口进行特别的命名或区分,只是简单地暴露端口用于服务访问,可以不提供 name 字段,让 Kubernetes 自动生成默认的名称即可。但如果需要更好地理解和管理端口配置,建议还是为端口提供一个描述性的名称。

总体来说,这份配置定义了一个名为 example-service-plus 的 Service 对象,它位于命名空间 aaaa 中,并且通过标签选择器 app: example-prd 与具有相同标签的 Pod 相关联,监听端口号为 22,转发流量到 Pod 内部的 22 端口。这样就可以通过 Service 的名称和端口号来访问与该 Service 关联的 Pod。

问题:

问题1

metadata.labels: 为创建的 Pod 添加标签,与 Deployment 的标签保持一致。为什么要保持一致呢?

保持标签一致性在 Kubernetes 中是一种良好的实践,它有助于组织和管理您的资源,使您的部署更加可靠和可维护。以下是保持标签一致性的一些重要原因:

  • 标识和选择
    • 标识性: 标签用于标识资源,例如应用程序名称、环境(开发、测试、生产)等。
    • 选择性:使用标签选择器(selector)时,确保标签一致性可以确保正确地选择相关资源。在这种情况下,Deployment 和 Pod 使用相同的标签,确保 Pod 是由该 Deployment 管理的。
  • 自动化管理
    • 一致的标签使得自动化管理更加简单。例如,您可以编写自动化脚本或配置管理工具来根据标签选择和操作资源,保持标签一致性可以减少错误和混淆。
  • 监控和日志
    • 一致的标签可以帮助您在监控系统或日志记录中识别和过滤特定的资源。例如,您可以轻松地使用标签筛选出特定应用程序或环境的日志或监控数据。
  • 安全性
    • 使用一致的标签还可以帮助您管理访问控制和安全策略。您可以基于标签定义安全策略,确保只有符合特定标签要求的资源可以访问特定服务或资源。
  • 维护和扩展
    • 当您需要维护或扩展部署时,一致的标签可以确保您可以准确地识别和操作相关的资源,而不会误操作或造成不必要的影响。

因此,保持标签一致性有助于提高资源管理的效率、可靠性和安全性,是 Kubernetes 中推荐的最佳实践之一。

问题2

  • restartPolicy: Always: 定义容器的重启策略为始终重启。什么意思?

restartPolicy: Always 是针对 Kubernetes 中容器的重启策略。解释一下这个设置的含义和作用:

在 Kubernetes 中,每个容器都有一个与之相关联的重启策略。restartPolicy 字段用于定义容器的重启行为,其中包括三种主要的选项:AlwaysOnFailureNever

  • Always: 当容器退出(无论是正常退出还是异常退出)时,Kubernetes 会始终重启该容器。这意味着无论何时容器停止运行,Kubernetes 都会尝试将其重新启动到期望的状态。
  • OnFailure: 只有当容器以非零状态退出(即出现失败)时,Kubernetes 才会重启该容器。如果容器以零状态(即成功)退出,则不会自动重启。
  • Never: Kubernetes 不会自动重启容器,即使容器退出或失败。

在您的配置中,将 restartPolicy 设置为 Always,意味着您希望 Kubernetes 始终保持容器的运行状态,并在容器停止时立即重启它们。这对于需要持续运行的应用程序或服务非常有用,以确保它们在出现问题时可以快速恢复并继续提供服务。

问题3

  • imagePullSecrets: 定义了从私有镜像仓库拉取镜像所需的密钥或凭证,这里使用了名为 registrykey 的密钥。怎么获取呢?

要获取 Kubernetes 中用于拉取私有镜像的凭证(密钥),您需要首先创建一个 Secret 对象,并将其指定为 imagePullSecrets 字段的值。这个 Secret 对象包含了您私有镜像仓库的认证信息。

以下是一般步骤:
1、创建 Secret 对象

kubectl create secret docker-registry <secret-name> \
  --docker-server=<registry-server> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email>

<secret-name>: 指定 Secret 对象的名称。
<registry-server>: 私有镜像仓库的地址。
<username>: 认证用户名。
<password>: 认证密码。
<email>: 关联的邮箱地址(可选)。

2、将 Secret 配置到 Deployment 中
在您的 Deployment YAML 文件中,将创建的 Secret 名称配置到 imagePullSecrets 字段下:

imagePullSecrets:
  - name: <secret-name>

3、应用更新
使用 kubectl apply -f your-deployment.yaml 命令或类似命令将更新的 Deployment 配置应用到 Kubernetes 集群中。
这样,Kubernetes 将能够使用指定的凭证从私有镜像仓库拉取镜像。
请确保 <secret-name><registry-server><username><password><email> 的值与您的实际情况相匹配。同时,要保护好敏感信息(如密码),避免明文存储或传输。

问题4

  • nodeSelector: 根据节点的标签选择在哪些节点上调度 Pod,这里选择带有 app_name: share 的节点。解释一下

nodeSelector 是 Kubernetes 中用于节点调度的一种方式,可以根据节点的标签选择在哪些节点上调度 Pod。让我们详细解释一下这段配置的含义和作用:

在 Kubernetes 中,集群中的每个节点都可以通过标签进行标识,这些标签可以根据您的需求进行定义和设置。通过 nodeSelector 字段,您可以告诉 Kubernetes 在调度 Pod 时只选择带有特定标签的节点。

  • nodeSelector:这个字段用于指定节点调度的规则,即选择在哪些节点上调度 Pod。
  • app_name: share:这是一个标签选择器,表示希望将 Pod 调度到带有 app_name: share 标签的节点上。

这样配置的目的可能是为了将特定类型的工作负载调度到具有特定功能或资源的节点上。例如,在这里可能有一些被标记为 app_name: share 的节点,它们可能配置了特定的硬件、网络或存储资源,或者可能专门用于运行特定类型的应用程序。通过这样的标签选择器,可以确保 Pod 被调度到适合它们需求的节点上。

问题5

matchExpressions: - key: app operator: In values: - example-prd,啥意思

这段配置中的 matchExpressions 是 Kubernetes 中用于选择器匹配的一部分。让我们来详细解释一下这个配置的含义:

在 Kubernetes 中,标签选择器(Label Selectors)用于选择要与之关联的资源,如 Pod、Service 等。matchExpressions 是用于更复杂的标签匹配条件的一部分,允许您指定多个条件以匹配标签。

matchExpressions:
  - key: app
    operator: In
    values:
      - example-prd
  • matchExpressions:这是一个用于选择器匹配的表达式列表。
    • - key: app:指定要匹配的标签键为 app
    • operator: In:指定匹配操作符为 In,表示标签的值必须包含在指定的值列表中才能匹配。
    • values:指定要匹配的值列表,这里只有一个值 example-prd

这段配置的意思是,要选择带有 app: example-prd 标签的资源(例如 Pod),因为这个条件是 In,所以只有标签的值为 example-prd 的资源才会被选择。这样可以确保只有特定类型或特定用途的资源会被选择器匹配。

问题6

  • topologyKey: kubernetes.io/hostname: 指定拓扑域的键,这里使用节点的主机名作为拓扑域的键。解释一下

在 Kubernetes 中,topologyKey 是用于定义拓扑域键的字段,它影响 Pod 的调度行为和容错能力。让我们详细解释一下这个配置的含义:

1、拓扑域(Topology Domain)

  • Kubernetes 集群中的拓扑域是指一组相关联的节点,它们可能位于同一区域、同一机架或具有相似的硬件特性。

2、topologyKey 字段:

  • topologyKey 字段用于指定拓扑域的键,即确定拓扑域的方式。
  • 在这里配置为 kubernetes.io/hostname,表示使用节点的主机名作为拓扑域的键。

3、作用:

  • 当 Pod 的调度需要考虑拓扑域时(如使用 PodAntiAffinity 配置避免在同一拓扑域内调度多个相关 Pod),Kubernetes 使用指定的拓扑域键来判断节点的拓扑位置。
  • 使用节点的主机名作为拓扑域键意味着 Kubernetes 将根据节点的主机名来确定节点所属的拓扑域。如果节点的主机名相同或符合某种规律,它们就会被认为属于同一拓扑域。

4、适用情况:

  • 在多节点的 Kubernetes 集群中,如果您有多个拓扑域(例如不同的机架、不同的区域),可以使用 topologyKey 来确保相关的 Pod 在不同的拓扑域内调度,从而提高容错性和可用性。

总之,通过配置 topologyKey: kubernetes.io/hostname,您告诉 Kubernetes 在进行 Pod 调度时使用节点的主机名作为拓扑域的键,这样可以根据节点的拓扑位置来确保 Pod 的合适调度。

问题7

为什么一个是apiVersion: apps/v1,一个是apiVersion: v1
在 Kubernetes 中,不同的资源对象有不同的 API 版本。这也反映了 Kubernetes 的发展和不同资源类型之间的区别。

  1. apiVersion: apps/v1:这个版本用于定义 Deployment、StatefulSet、DaemonSet 等应用相关的控制器对象。通常情况下,用于部署应用的控制器对象会使用 apps/v1 版本,因为这些控制器对象属于应用级别的管理。
  2. apiVersion: v1:这个版本用于定义 Kubernetes 中的核心资源对象,例如 Pod、Service、Namespace 等。这些对象是 Kubernetes 集群的基本构建块,因此使用的是核心的 API 版本。

因此,在您提供的配置中,Deployment 对象使用的是 apiVersion: apps/v1,因为 Deployment 是用于部署和管理应用的控制器对象。而 Service 对象使用的是 apiVersion: v1,因为 Service 是 Kubernetes 的核心资源之一,用于暴露应用到集群内部或外部的访问。

总体来说,不同类型的资源对象对应不同的 API 版本,这是 Kubernetes 中区分不同资源类型的重要标识之一。

结构图片

在这里插入图片描述

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

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

相关文章

gin语言基础学习--会话控制(下)

练习 模拟实现权限验证中间件 有2个路由&#xff0c;/cookie和/home/cookie用于设置cookiehome是访问查看信息的请求在请求home之前&#xff0c;先跑中间件代码&#xff0c;检验是否存在cookie 访问home&#xff0c;会显示错误&#xff0c;因为权限校验未通过 package mainim…

【CXL协议-ARB/MUX层(5)】

5.0 Compute Express Link ARB/MUX 前言&#xff1a; 在CXL协议中&#xff0c;ARB/MUX层&#xff08;Arbitration/Multiplexer layer&#xff09;是负责管理资源共享和数据通路选择的一层。CXL协议包含了几个子协议&#xff0c;主要有CXL.io、CXL.cache 和 CXL.memory。ARB/MU…

2024年福建事业单位招聘详细流程

2024年福建事业单位招聘详细流程&#xff0c;速速查收&#xff01;

Windows安装tomcat,以服务的方式管理,如何设置虚拟内存

之前工作中&#xff0c;部署tomcat都是使用Linux服务器&#xff0c;最近遇到个客户&#xff0c;提供的服务器是Windows server&#xff0c;并且需要通过服务的方式管理tomcat&#xff1b;以自己多年的码农经验&#xff0c;感觉应该没有问题&#xff0c;结果啪啪打脸了&#xf…

【实现100个unity特效之7】unity 3d实现各种粒子效果

文章目录 先看最终效果下雨效果萤火虫和火花四溅的效果 3d下雨粒子效果涟漪效果雨滴和涟漪效果结合水花效果雨滴涟漪水花结合问题雾气效果萤火虫火花效果萤火虫和火花效果结合其他特效爆炸、闪电、火焰、雷雨特效&#xff08;2023/7/5更新&#xff09;源码完结 先看最终效果 下…

使用Nginx1.25.4版本做负载均衡、搭建Nacos2.3.0服务集群

关于使用版本问题上&#xff0c;其实小白更喜欢使用新的版本&#xff0c;因为新的版本功能更多&#xff0c;肯定优化方面不言而喻&#xff0c;懂得都懂&#xff0c;但是新的版本&#xff0c;肯定使用起来更加的速度&#xff0c;性能&#xff0c;也是不言而喻的啊&#xff0c;那…

【学海拾贝】| 关于Python的 PEP 484规则了解:类型提示,函数注解

在实际的工厂在实际的工程代码的开发中&#xff0c;常常可以碰到这种情况 上网查了之后发现这是PEP484规则~ 文章目录 1 Type Hints for Variables&#xff08;变量在这里插入图片描述2 Function Annotations&#xff08;函数注解&#xff09;3 Type Checking Tools&#xff08…

window下迁移SVN仓库到新的windows服务器

一、背景 一个基于 Windows 的 SVN 服务器&#xff0c;用于管理团队的代码库。该 SVN 仓库托管着公司的软件项目&#xff0c;包括多个分支和版本的代码。我们的团队规模约为 50 人&#xff0c;分布在不同的地理位置&#xff0c;他们都依赖 SVN 仓库来进行代码版本控制和协作开…

ETL工具-nifi干货系列 第四讲 Avro schema 序列化框架

一、在使用nifi的过程中会使用到遇到avro schema、avro data、avroReader、avroWriter等&#xff0c;所以本节课和大家一起学习下avro相关知识。 二、什么是Avro Apache Avro是hadoop中的一个子项目&#xff0c;也是一个数据序列化系统&#xff0c;其数据最终以二进制格式&…

ZnO非线性电阻片的老化机理生产厂家

金属氧化物限压器通常不带串联间隙,因此工作电压将长期作用在限压器内的电阻片上&#xff0c;长期有泄漏电流流过。对于工频电压,电流中包括一定分量的阻性电流。虽然阻性电流幅值相对于容性电流要小,但有可能随时间逐渐增加,并导致功率损耗的增加&#xff0c;即ZnO非线性电阻存…

Django 仿博客园练习

数据库搭建 部分功能介绍 【一】注册 &#xff08;1&#xff09;效果显示、简单简介 主要亮点 结合了layui和forms组件默认头像可以随着性别的选择发生改变自定义头像可以实时更新显示forms组件报错信息可以局部刷新显示在对应框体下面 没有直接使用layui的前端验证后端验证…

Flutter(踩坑)之Android sdkmanager tool not found

D:\Flutter\flutter\bin\flutter.bat doctor --verbose [√] Flutter (Channel stable, v1.2.1, on Microsoft Windows [Version 10.0.22631.3296], locale zh-CN)• Flutter version 1.2.1 at D:\Flutter\flutter• Framework revision 8661d8aecd (5 years ago), 2019-02-14 …

1.0 html(1)

html 一、基本介绍 1、定义&#xff1a;html是一种超文本标记语言&#xff0c;也是一种标识性语言&#xff08;不是编程语言&#xff09; 标记&#xff1a;记号&#xff08;绰号&#xff09; 超文本&#xff1a;就是页面内容可以包含图片、链接&#xff0c;音乐&#xff0c…

OC 技术 苹果内购

一直觉得自己写的不是技术&#xff0c;而是情怀&#xff0c;一个个的教程是自己这一路走来的痕迹。靠专业技能的成功是最具可复制性的&#xff0c;希望我的这条路能让你们少走弯路&#xff0c;希望我能帮你们抹去知识的蒙尘&#xff0c;希望我能帮你们理清知识的脉络&#xff0…

RHCE 补充:判断服务状态

内容补充&#xff1a;判断服务状态 systemctl 命令 系统控制管理命令工具 常用指令 1、启动 systemctl start 程序名 若要启动多个程序名&#xff0c;使用空格隔开&#xff0c;下同 2、重启&#xff1a;类似主机先断电再启动的一个状态 systemctl restart 程序名 3、停…

Spring Cloud 八:微服务架构中的数据管理

Spring Cloud 一&#xff1a;Spring Cloud 简介 Spring Cloud 二&#xff1a;核心组件解析 Spring Cloud 三&#xff1a;API网关深入探索与实战应用 Spring Cloud 四&#xff1a;微服务治理与安全 Spring Cloud 五&#xff1a;Spring Cloud与持续集成/持续部署&#xff08;CI/C…

图论最短路径以及floyd算法的MATLAB实现

图论是数学的一个分支&#xff0c;起源于18世纪。1736年&#xff0c;数学家欧拉通过解决“哥尼斯堡七桥问题”&#xff0c;将问题抽象成点和线的关系&#xff0c;并通过理论分析得出结论&#xff0c;这个过程标志着图论的产生&#xff0c;欧拉也因此被称为“图论之父”。图论研…

机器人机械手加装SycoTec 4060 ER-S电主轴高精密铣削加工

随着科技的不断发展&#xff0c;机器人技术正逐渐渗透到各个领域&#xff0c;展现出前所未有的潜力和应用价值。作为机器人技术的核心组成部分之一&#xff0c;机器人机械手以其高精度、高效率和高稳定性的优势&#xff0c;在机械加工、装配、检测等领域中发挥着举足轻重的作用…

利用RWKV-Runner初步感受一下ai的世界

最近又听到群里的高手在讨论RWKV-Runner&#xff0c;于是没忍住&#xff0c;就想试试&#xff0c;没想到第一关就卡住了。 从群里大咖上传的RWKV-Runner_windows_x64.exe文件开始吧&#xff0c;又找了个虚拟机&#xff0c;直接放在桌面上运行一下&#xff0c;结果就跳出一堆文…

Java框架安全篇--Shiro-550漏洞

Java框架安全篇--Shiro-550漏洞 Shiro反序列化源码可以提取&#xff1a; https://codeload.github.com/apache/shiro/zip/shiro-root-1.2.4 JAVA反序列化就不说了&#xff0c;可以参考前面文章 https://blog.csdn.net/m0_63138919/article/details/136751184 初始Apache Sh…