k8s 控制器：Daemonset 和 Job_deamonset-程序员宅基地

技术标签： kubernetes  容器  Linux 运维  学习笔记  k8s Job  云计算  

  • DaemonSet 概述

  • DaemonSet 控制器能够确保 k8s 集群所有的节点都运行一个相同的 pod 副本，当向 k8s 集群中增加 node 节点时，这个 node 节点也会自动创建一个 pod 副本，当 node 节点从集群移除，这些 pod 也会自动删除；删除 Daemonset 也会删除它们创建的 pod

  • DaemonSet 工作原理：如何管理 Pod？

  • daemonset 的控制器会监听 kuberntes 的 daemonset 对象、pod 对象、node 对象，这些被监听的对象之变动，就会触发 syncLoop 循环让 kubernetes 集群朝着 daemonset 对象描述的状态进行演进。

    此部分代码位于 pkg/kubelet/kubelet.go

  • Daemonset 典型的应用场景

    在集群的每个节点上运行存储，比如：glusterd 或 ceph。

    在每个节点上运行日志收集组件，比如：flunentd 、 logstash、filebeat 等。

    在每个节点上运行监控组件，比如：Prometheus、 Node Exporter 、collectd 等。
     

  • DaemonSet 与 Deployment 的区别

    Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本。

    DaemonSet 的不同之处在于：每个 Node 上最多只能运行一个副本。 

  • DaemonSet 资源清单文件编写技巧

  • #查看定义 Daemonset 资源需要的字段有哪些？

    # kubectl explain ds

    KIND: DaemonSet
    VERSION: apps/v1
    DESCRIPTION:
     DaemonSet represents the configuration of a daemon set.
    FIELDS:
     apiVersion <string> #当前资源使用的 api 版本，跟 VERSION: apps/v1 保持一致
     kind <string> #资源类型，跟 KIND: DaemonSet 保持一致
     metadata <Object> #元数据，定义 DaemonSet 名字的
     spec <Object> #定义容器的
     status <Object> #状态信息，不能改

     
  • #查看 DaemonSet 的 spec 字段如何定义？
     
  • # kubectl explain ds.spec

    KIND: DaemonSet
    VERSION: apps/v1
    RESOURCE: spec <Object>
    DESCRIPTION:
     The desired behavior of this daemon set. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/apiconventions.md#spec-and-status
     DaemonSetSpec is the specification of a daemon set.
    FIELDS:
     minReadySeconds <integer> #当新的 pod 启动几秒种后，再 kill 掉旧的 pod。
     revisionHistoryLimit <integer> #历史版本
     selector <Object> -required- #用于匹配 pod 的标签选择器
     template <Object> -required- #定义 Pod 的模板，基于这个模板定义的所有 pod 是一样的 updateStrategy <Object> #daemonset 的升级策略
     
  • #查看 DaemonSet 的 spec.template 字段如何定义？

    #对于 template 而言，其内部定义的就是 pod，pod 模板是一个独立的对象

    # kubectl explain ds.spec.template

    KIND: DaemonSet
    VERSION: apps/v1
    RESOURCE: template <Object>
    FIELDS:
     metadata <Object>
     spec<Object>

  •  DaemonSet 使用案例-日志收集组件 fluentd

  • vim daemonset.yaml

    所有节点均创建了 fluentd 这个 pod

  • #资源清单详细说明

  • apiVersion: apps/v1 #DaemonSet 使用的 api 版本
    kind: DaemonSet # 资源类型
    metadata:
     name: fluentd-elasticsearch #资源的名字
     namespace: kube-system #资源所在的名称空间
     labels:
     k8s-app: fluentd-logging #资源具有的标签
    spec:
     selector: #标签选择器
     matchLabels:
     name: fluentd-elasticsearch
     template:
     metadata:
     labels: #基于这回模板定义的 pod 具有的标签
     name: fluentd-elasticsearch
     spec:
     tolerations: #定义容忍度
     - key: node-role.kubernetes.io/master
     effect: NoSchedule
     containers: #定义容器
     - name: fluentd-elasticsearch
     image: xuegod/fluentd:v2.5.1
     resources: #资源配额
     limits:
     memory: 200Mi
     requests:
     cpu: 100m
     memory: 200Mi
     volumeMounts:
     - name: varlog
     mountPath: /var/log #把本地/var/log 目录挂载到容器
     - name: varlibdockercontainers
     mountPath: /var/lib/docker/containers #把/var/lib/docker/containers/挂载到容器里
     readOnly: true #挂载目录是只读权限
     terminationGracePeriodSeconds: 30 #优雅的关闭服务
     volumes:
     - name: varlog
     hostPath:
     path: /var/log #基于本地目录创建一个卷
     - name: varlibdockercontainers
     hostPath:
     path: /var/lib/docker/containers #基于本地目录创建一个卷

     
  • 扩展：什么是 terminationGracePeriodSeconds？
    解释这个参数之前，先来回忆一下 K8S 滚动升级的步骤:
    1.K8S 首先启动新的 POD
    2.K8S 等待新的 POD 进入 Ready 状态
    3.K8S 创建 Endpoint，将新的 POD 纳入负载均衡
    4.K8S 移除与老 POD 相关的 Endpoint，并且将老 POD 状态设置为 Terminating，此时将不会有新的请求到达老 POD
    5.同时 K8S 会给老 POD 发送 SIGTERM 信号，并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为 30 秒)
    6.超过 terminationGracePeriodSeconds 等待时间后， K8S 会强制结束老 POD
     
  • erminationGracePeriodSeconds 就是 K8S 给你程序留的最后的缓冲时间，来处理关闭之前的操作。

  • DaemonSet 实现 pod 的滚动更新

  • 查看 daemonset 的滚动更新策略
    # kubectl explain ds.spec.updateStrategy
     

    KIND:     DaemonSet
    VERSION:  apps/v1

    RESOURCE: updateStrategy <Object>

    DESCRIPTION:
         An update strategy to replace existing DaemonSet pods with new pods.

         DaemonSetUpdateStrategy is a struct used to control the update strategy for
         a DaemonSet.

    FIELDS:
       rollingUpdate    <Object>
         Rolling update config params. Present only if type = "RollingUpdate".

       type    <string>
         Type of daemon set update. Can be "RollingUpdate" or "OnDelete". Default is
         RollingUpdate.

    #查看 rollingUpdate 支持的更新策略
    ]# kubectl explain ds.spec.updateStrategy.rollingUpdate
    KIND: DaemonSet
    VERSION: apps/v1
    RESOURCE: rollingUpdate <Object>
    DESCRIPTION:
     Rolling update config params. Present only if type = "RollingUpdate".
     Spec to control the desired behavior of daemon set rolling update.
    FIELDS:
     maxUnavailable <string>#表示 rollingUpdate 更新策略只支持 maxUnavailabe，先删除在更新；因为我们不支持一个
    节点运行两个 pod，因此需要先删除一个，在更新一个。

    #更新镜像版本，可以按照如下方法：
    kubectl set image daemonsets fluentd-elasticsearch *=ikubernetes/filebeat:5.6.6-alpine -n kube-system

    kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N [options]

     

  • Job 概念、原理解读

  • Job 控制器用于管理 Pod 对象运行一次性任务，比方说我们对数据库备份，可以直接在 k8s 上启动一个 mysqldump 备份程序，也可以启动一个 pod，这个 pod 专门用来备份用的，备份结束 pod 就可以终止了，不需要重启，而是将 Pod 对象置于"Completed"(完成)状态，若容器中的进程因错误而终止，则需要按照重启策略配置确定是否重启，对于 Job 这个类型的控制器来说，需不需要重建 pod 就看任务是否完成，完成就不需要重建，没有完成就需要重建 pod。

    Job 控制器的 Pod 对象的状态转换如下图所示：
     

    Job 用来创建 1 个或多个 Pod,并保证指定数量(.spec.completions)的 Pod 成功完成。当一个 Pod成功完成时(.status.phase=Succeeded)，Job 会记录已完成的 Pod 的数量，但完成的数量达到指定值时，这个 Job 就完成了。

    可以通过以下 3 种方式来判断一个 Job 是否已完成：
     .status.completionTime 是否为空。Job 完成时该字段会被设置成 Job 完成的时间，否则为空

     .spec.completions 和.status.succeeded 是否相等,即对比期望完成数和已成功数，当二者相等时，表示 Job 已经完成

     .status.conditions[0].type：type 为 Complete 和 Failed 时，分别表示 Job 执行成功和失败

    Pod 中的容器可能因为各种各样的原因失败，比如退出码不为 0、超出内存限制被 kill 掉，容器失败分两种情况：
     .spec.template.spec.restartPolicy = "OnFailure":容器失败后会不断重启，直到成功（退出码为 0）
     .spec.template.spec.restartPolicy = "Never"：容器不会重启，Pod 的状态转为 Failed当 Pod 执行失败时，Job 会不断创建一个新的 Pod 进行重试，直到失败次数达到.spec.backoffLimit 指定的数值，整个 Job 的执行失败。可以通过判断.status.failed和.spec.backoffLimit 是否相等，即已失败数是否已经达到上限，来判断 Job 是否已经执行失败。
    如下，当.spec.backoffLimit 设置为 3 时，.status.failed 已经达到 3，Job 失败，不会再尝试创建新的Pod


    Job 三种使用场景：
    1、非并行任务：只启一个 pod，pod 成功，job 正常结束
    2、并行任务同时指定成功个数：.spec.completions 为指定成功个数，可以指定也可以不指定.spec.parallelism（指定>1，会有多个任务并行运行）。当成功个数达到.spec.completions，任务结束。
    3、有工作队列的并行任务：.spec.completions 默认为 1，.spec.parallelism 为大于 0 的整数。此时并行启动多个 pod，只要有一个成功，任务结束，所有 pod 结束

    适用场景：
    Job 不是设计用来完成通信密集型的并行程序，如科学计算领域常见的场景。它支持并行地处理一组独立但相关的 work item，如发送邮件，渲染帧，转码文件和扫描 NoSql 数据库中的 key

    相关配置：
    .spec.completions：完成该 Job 需要执行成功的 Pod 数
    .spec.parallelism：能够同时运行的 Pod 数
    .spec.backoffLimit：允许执行失败的 Pod 数，默认值是 6，0 表示不允许 Pod 执行失败。如果Pod 是 restartPolicy 为 Nerver，则失败后会创建新的 Pod，如果是 OnFailed，则会重启 Pod，不管是哪种情况，只要 Pod 失败一次就计算一次，而不是等整个 Pod 失败后再计算一个。当失败的次数达到该限制时，整个 Job 随即结束，所有正在运行中的 Pod 都会被删除。
    .spec.activeDeadlineSeconds: Job 的超时时间，一旦一个 Job 运行的时间超出该限制，则 Job失败，所有运行中的 Pod 会被结束并删除。该配置指定的值必须是个正整数。不指定则不会超时
     

  • CronJob 概念、原理解读

  • CronJob 跟 Job 完成的工作是一样的，只不过 CronJob 添加了定时任务能力可以指定时间，实现周期性运行。

    Job，CronJob 和 Deployment，DaemonSet 显著区别在于不需要持续在后台运行Deployment 主要用于管理无状态的应用（kubernetes 集群有一些 pod，某一个 pod 出现故障，删除之后会重新启动一个 pod，那么 kubernetes 这个集群中 pod 数量就正常了，更多关注的是群体，这就是无状态应用）。

    使用场景：
    1、在给定时间点只运行一次。
    2、在给定时间点周期性地运行。

    CronJob 的典型用法如下：
    1、在给定的时间点调度 Job 运行。
    2、创建周期性运行的 Job，例如数据库备份、发送邮件
     

  • Job 控制器：资源清单编写技巧

  • #查看 Job 资源对象由哪几部分组成

    [~]# kubectl explain Job

    KIND: Job
    VERSION: batch/v1
    DESCRIPTION:
     Job represents the configuration of a single job.
    FIELDS:
     apiVersion <string> #当前 Job 的 api 版本
     kind <string> #指定当前的资源类型
     metadata <Object> #元数据，定义资源的名字和所在名称空间
     spec <Object>


    #查看 Job 下的 spec 字段

    [~]# kubectl explain Job.spec

    KIND: Job
    VERSION: batch/v1
    RESOURCE: spec <Object>
    DESCRIPTION:
     Specification of the desired behavior of a job. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/apiconventions.md#spec-and-status
     JobSpec describes how the job execution will look like.
    FIELDS:
     activeDeadlineSeconds <integer> #通过指定 job 存活时间，来结束一个 job。当 job 运行时间达到 activeDeadlineSeconds 指定的时间后，job 会停止由它启动的所有任务（如：pod），并设置 job 的状态为 failed
     backoffLimit <integer> #job 建议指定 pod 的重启策略为 never，如：.spec.template.spec.restartPolicy = "Never"，然后通过 job 的 backoffLimit 来指定失败重试次数，在达到 backoffLimit 指定的次数后，job 状态设置为 failed（默认为 6 次） completions <integer> #指定 job 启动的任务（如：pod）成功运行 completions 次，job 才算成功结束
     manualSelector <boolean>
     parallelism <integer> #指定 job 同时运行的任务（如：pod）个数，Parallelism 默认为 1，如果设置为 0，则 job 会暂定
     selector <Object>
     template <Object> -required-
     ttlSecondsAfterFinished <integer> #默认情况下，job 异常或者成功结束后，包括 job 启动的任务（pod），都不会被清理掉，因为你可以依据保存的 job 和 pod，查看状态、日志，以及调试等。这些用户可以手动删除，用户手动删除 job，job controller 会级联删除对应的 pod，除了手动删除，通过指定参数 ttlSecondsAfterFinished 也可以实现自动删除 job，以及级联的资源，如：pod。如果设置为 0，job 会被立即删除。如果不指定，job 则不会被删除

     

  • #查看 Job 下的 spec.template 字段

  • #template 为定义 Pod 的模板，Job 通过模板创建 Pod

    [~]# kubectl explain Job.spec.template
    KIND: Job
    VERSION: batch/v1
    RESOURCE: template <Object>
    DESCRIPTION:
     Describes the pod that will be created when executing a job. More info:
     https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-tocompletion/
    FIELDS:
     metadata <Object>
     spec <Object>


    #查看 Job 下的 spec.template.spec 字段
    [~]# kubectl explain Job.spec.template.spec
    KIND: Job
    VERSION: batch/v1
    RESOURCE: spec <Object>
    DESCRIPTION:
     Specification of the desired behavior of the pod. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/apiconventions.md#spec-and-status
     PodSpec is a description of a pod.
    FIELDS:
     activeDeadlineSeconds <integer>
     affinity <Object>
     containers <[]Object> -required-
     dnsConfig <Object>
     dnsPolicy <string>
     enableServiceLinks <boolean>
     ephemeralContainers <[]Object>
     hostAliases<[]Object>
     hostIPC <boolean>
     hostNetwork <boolean>
     hostPID <boolean>
     hostname <string>
     imagePullSecrets <[]Object>
     initContainers <[]Object>
     nodeName <string>
     nodeSelector <map[string]string>
     overhead <map[string]string>
     preemptionPolicy <string>
     priority <integer>
     priorityClassName <string>
     readinessGates <[]Object>
     restartPolicy <string> #重启策略，对于 Job，只能设置为 Never 或者 OnFailure。对于其他 controller（比如 Deployment）可以设置为 Always 。
     runtimeClassName <string>
     schedulerName <string>
     securityContext <Object>
     serviceAccount <string>
     serviceAccountName <string>
     setHostnameAsFQDN <boolean>
     shareProcessNamespace <boolean>
     subdomain <string>
     terminationGracePeriodSeconds <integer>
     tolerations <[]Object>
     topologySpreadConstraints <[]Object>
     volumes <[]Object>
     

  • Job -创建一个一次性任务

  • vim job.yaml

    COMPLETIONS : 成功退出的 pod 数/并行运行的 pod 数

  • #资源清单文件详细解读

  • apiVersion: batch/v1
    kind: Job
    metadata:
     name: my-busybox-job
    spec:
    ttlSecondsAfterFinished: 20
     completions: 6 # job 结束需要成功运行的 Pod 个数，即状态为 Completed 的 pod 数
     parallelism: 3 #一次运行 3 个 pod 指的是一次性运行几个 pod，这个值不会超过 completions 的值
    backoffLimit: 6 #如果 job 失败，则重试几次，
     template:
     spec:
     restartPolicy: Never
     containers:
     - name: my-container-job
     image: busybox
     imagePullPolicy: IfNotPresent
     command: ['sh', '-c']
     args: ['echo "Welcome to xuegod";sleep 60; echo "Next to Meet you"']

  • CronJob 使用案例-创建周期性的定时任务

  • vim cronjob.yaml 

    观察大概一分钟，等待 CronJob创建:

    #现在可以看到由 hello 这个 cronjob 调度的正在运行的 job
    #可以看到 hello 这个 CronJob 成功地在 LAST SCHEDULE 中指定的时间点调度了一个作业。当前有 1 个活动作业，这意味着该作业已经完成或失败。

  •  

  • 使用 CronJob 定期备份 MySQL 数据

  • CronJob 所描述的，正是定时任务。
    1、在给定时间点只运行一次
    2、在给定时间点周期性地运行

    一个 CronJob 对象类似于 crontab （cron table）文件中的一行。它根据指定的预定计划周期性地运行一个 Job。在这里简单的说一下 cron，是指 unix 中 cron 表达式。比如："*/1 * * * *"，这个Cron 表达式里*/1 中 *表示从 0 开始，/表示"每"，1 表示偏移量，所以它的意思是：从 0 开始，每 1个时间单位执行一次。Cron 表达式中五个部分分别代表：分钟，小时，日，月，星期。

    所以上述这句Cron 表达式的意思是：从当前开始，每分钟执行一次。那么我们可以利用这个机制来指定创建 mysql备份任务的对象:

     apiVersion: batch/v1beta1
     kind: CronJob
     metadata:
     name: mysqldump
     spec:
     schedule: "50 15 * * *"
     jobTemplate:
     spec:
     completions: 1
     template:
     spec:
     restartPolicy: Never
     volumes:
     - name: mysql-master-script
     hostPath:
     path: /root/app/mysql/shell
     - name: mysql-master-backup
     hostPath:
     path: /root/app/db/backup
     - name: local-time
     hostPath:
     path: /etc/localtime
     containers:
     - name: mysqldump-container
     image: nacos/nacos-mysql-master:latest
     volumeMounts:
     - name: mysql-master-script
     mountPath: /var/db/script
     - name: local-time
     mountPath: /etc/localtime
     - name: mysql-master-backup
     mountPath: /var/db/backup
     command:
     - "sh"
     - "/var/db/script/mysqldump.sh"

    在这个 Yaml 文件当中，最重要的关键词就是 jobTemplate。它是由 job 对象控制的 Controller,还有几点关键的属性这里解释说明一下：

    1、spec.concurrencyPolicy 这个属性主要是由于定时任务的特殊性，很可能某个 job 还没执行完，另外一个新的 job 就产生了。它的取值分别为:Allow(job 可以同时存在)，Forbid(不会创建新的job，该周期会被跳过),Replace(新产生的 Job 替换旧的，没有执行完的 Job)

    2、如果某一次 Job 创建失败，这次创建会被标记为"Miss"。当在指定的事件窗口内，miss 数目达到 100 时，那么 CronJob 会停止再创建这个 Job，这个时间窗口可以有spec.startingDeadlineSeconds 来指定

    3、在 Job 对象中，负责并行控制的参数有两个：spec.parallelism 它定义的是一个 Job 在任意时间最多可以启动多少个 Pod 同时运行。spec.comletions 它定义的是 job 至少完成的 Pod 数目这里容器与宿主机时差相差 8 小时。注意在设置定时任务的时候一定算好时间


     
  • 备份数据库的脚本 ， mysqldump.sh 脚本如下:

    #!/bin/bash
     #保存备份个数
     number=3
     #备份保存路径
     backup_dir=/var/db/backup
     #日期
     dd=`date +%Y%m%d`
     #备份工具
     tool=/usr/bin/mysqldump
     #用户名
     username=root
     #密码
     password=root
     #将要备份的数据库
     database_name=test
     #简单写法 mysqldump -u root -p123456 users > /root/mysqlbackup/users-
    $filename.sql
     $tool -u $username -p$password -hmysql-master -P3306 --databases 
    $database_name > $backup_dir/$database_name-$dd.sql
     
     #写创建备份日志
     echo "create $backup_dir/$database_name-$dd.sql" >> $backup_dir/log.txt
     #找出需要删除的备份
     delfile=`ls -l -crt $backup_dir/*.sql | awk '{print $9 }' | head -1`
     #判断现在的备份数量是否大于$number
     count=`ls -l -crt $backup_dir/*.sql | awk '{print $9 }' | wc -l`
     if [ $count -gt $number ]
     then
     rm $delfile //删除最早生成的备份只保留 number 数量的备份
     #写删除文件日志
     echo "delete $delfile" >> $backup_dir/log.txt
     fi
  •  
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/gaofei0428/article/details/121194614

智能推荐

分布式光纤传感器的全球与中国市场2022-2028年：技术、参与者、趋势、市场规模及占有率研究报告_预计2026年中国分布式传感器市场规模有多大-程序员宅基地

文章浏览阅读3.2k次。本文研究全球与中国市场分布式光纤传感器的发展现状及未来发展趋势，分别从生产和消费的角度分析分布式光纤传感器的主要生产地区、主要消费地区以及主要的生产商。重点分析全球与中国市场的主要厂商产品特点、产品规格、不同规格产品的价格、产量、产值及全球和中国市场主要生产商的市场份额。主要生产商包括：FISO TechnologiesBrugg KabelSensor HighwayOmnisensAFL GlobalQinetiQ GroupLockheed MartinOSENSA Innovati_预计2026年中国分布式传感器市场规模有多大

07_08 常用组合逻辑电路结构——为IC设计的延时估计铺垫_基4布斯算法代码-程序员宅基地

文章浏览阅读1.1k次，点赞2次，收藏12次。常用组合逻辑电路结构——为IC设计的延时估计铺垫学习目的：估计模块间的delay，确保写的代码的timing 综合能给到多少HZ，以满足需求！_基4布斯算法代码

OpenAI Manager助手（基于SpringBoot和Vue）_chatgpt网页版-程序员宅基地

文章浏览阅读3.3k次，点赞3次，收藏5次。OpenAI Manager助手（基于SpringBoot和Vue）_chatgpt网页版

关于美国计算机奥赛USACO，你想知道的都在这_usaco可以多次提交吗-程序员宅基地

文章浏览阅读2.2k次。USACO自1992年举办，到目前为止已经举办了27届，目的是为了帮助美国信息学国家队选拔IOI的队员，目前逐渐发展为全球热门的线上赛事，成为美国大学申请条件下，含金量相当高的官方竞赛。USACO的比赛成绩可以助力计算机专业留学，越来越多的学生进入了康奈尔，麻省理工，普林斯顿，哈佛和耶鲁等大学，这些同学的共同点是他们都参加了美国计算机科学竞赛（USACO)，并且取得过非常好的成绩。适合参赛人群USACO适合国内在读学生有意向申请美国大学的或者想锻炼自己编程能力的同学，高三学生也可以参加12月的第_usaco可以多次提交吗

MySQL存储过程和自定义函数_mysql自定义函数和存储过程-程序员宅基地

文章浏览阅读394次。1.1 存储程序1.2 创建存储过程1.3 创建自定义函数1.3.1 示例1.4 自定义函数和存储过程的区别1.5 变量的使用1.6 定义条件和处理程序1.6.1 定义条件1.6.1.1 示例1.6.2 定义处理程序1.6.2.1 示例1.7 光标的使用1.7.1 声明光标1.7.2 打开光标1.7.3 使用光标1.7.4 关闭光标1.8 流程控制的使用1.8.1 IF语句1.8.2 CASE语句1.8.3 LOOP语句1.8.4 LEAVE语句1.8.5 ITERATE语句1.8.6 REPEAT语句。_mysql自定义函数和存储过程

半导体基础知识与PN结_本征半导体电流为0-程序员宅基地

文章浏览阅读188次。半导体二极管——集成电路最小组成单元。_本征半导体电流为0

随便推点

【Unity3d Shader】水面和岩浆效果_unity 岩浆shader-程序员宅基地

文章浏览阅读2.8k次，点赞3次，收藏18次。游戏水面特效实现方式太多。咱们这边介绍的是一最简单的UV动画（无顶点位移），整个mesh由4个顶点构成。实现了水面效果（左图），不动代码稍微修改下参数和贴图可以实现岩浆效果（右图）。有要思路是1，uv按时间去做正弦波移动2，在1的基础上加个凹凸图混合uv3，在1、2的基础上加个水流方向4，加上对雾效的支持，如没必要请自行删除雾效代码(把包含fog的几行代码删除)S..._unity 岩浆shader

广义线性模型——Logistic回归模型（1）_广义线性回归模型-程序员宅基地

文章浏览阅读5k次。广义线性模型是线性模型的扩展，它通过连接函数建立响应变量的数学期望值与线性组合的预测变量之间的关系。广义线性模型拟合的形式为：其中g(μY)是条件均值的函数（称为连接函数）。另外，你可放松Y为正态分布的假设，改为Y 服从指数分布族中的一种分布即可。设定好连接函数和概率分布后，便可以通过最大似然估计的多次迭代推导出各参数值。在大部分情况下，线性模型就可以通过一系列连续型或类别型预测变量来预测正态分布的响应变量的工作。但是，有时候我们要进行非正态因变量的分析，例如：（1）类别型.._广义线性回归模型

HTML+CSS大作业 环境网页设计与实现(垃圾分类) web前端开发技术 web课程设计 网页规划与设计_垃圾分类网页设计目标怎么写-程序员宅基地

文章浏览阅读69次。环境保护、 保护地球、 校园环保、垃圾分类、绿色家园、等网站的设计与制作。 总结了一些学生网页制作的经验：一般的网页需要融入以下知识点：div+css布局、浮动、定位、高级css、表格、表单及验证、js轮播图、音频 视频 Flash的应用、ul li、下拉导航栏、鼠标划过效果等知识点，网页的风格主题也很全面：如爱好、风景、校园、美食、动漫、游戏、咖啡、音乐、家乡、电影、名人、商城以及个人主页等主题，学生、新手可参考下方页面的布局和设计和HTML源码（有用点赞△） 一套A+的网_垃圾分类网页设计目标怎么写

C# .Net 发布后,把dll全部放在一个文件夹中,让软件目录更整洁_.net dll 全局目录-程序员宅基地

文章浏览阅读614次，点赞7次，收藏11次。之前找到一个修改 exe 中 DLL地址 的方法, 不太好使,虽然能正确启动, 但无法改变 exe 的工作目录,这就影响了.Net 中很多获取 exe 执行目录来拼接的地址 ( 相对路径 ),比如 wwwroot 和 代码中相对目录还有一些复制到目录的普通文件 等等,它们的地址都会指向原来 exe 的目录, 而不是自定义的 “lib” 目录,根本原因就是没有修改 exe 的工作目录这次来搞一个启动程序,把 .net 的所有东西都放在一个文件夹,在文件夹同级的目录制作一个 exe._.net dll 全局目录

BRIEF特征点描述算法_breif description calculation 特征点-程序员宅基地

文章浏览阅读1.5k次。本文为转载，原博客地址：http://blog.csdn.net/hujingshuang/article/details/46910259简介 BRIEF是2010年的一篇名为《BRIEF:Binary Robust Independent Elementary Features》的文章中提出，BRIEF是对已检测到的特征点进行描述，它是一种二进制编码的描述子，摈弃了利用区域灰度..._breif description calculation 特征点

房屋租赁管理系统的设计和实现，SpringBoot计算机毕业设计论文_基于spring boot的房屋租赁系统论文-程序员宅基地

文章浏览阅读4.1k次，点赞21次，收藏79次。本文是《基于SpringBoot的房屋租赁管理系统》的配套原创说明文档，可以给应届毕业生提供格式撰写参考，也可以给开发类似系统的朋友们提供功能业务设计思路。_基于spring boot的房屋租赁系统论文

推荐文章

热门文章

相关标签