Kubernetes之Controller详解

本文尝试从Kubernetes Controller的种类、交互逻辑、最佳实践、伪代码示例及历史演进5个方面对其进行详细阐述,希望对您有所帮助!

一、Kubernetes Controller种类

Kubernetes Controller Manager 是 Kubernetes 集群的核心组件之一,负责管理和协调集群内各种控制器。控制器是实现 Kubernetes 集群自动化管理的核心部分,通过持续协调集群的实际状态和期望状态,确保资源的正确配置和运行。

Kubernetes Controller Manager 包含多个控制器,每个控制器负责特定的资源和任务。以下是一些主要控制器及其功能:

  1. Node Controller

    • 作用:监控节点的状态,负责在节点不可用时执行相应的操作,例如将 Pod 标记为不可调度、在节点无法通信时驱逐 Pod。
  2. Replication Controller

    • 作用:确保指定数量的 Pod 副本在任何时候都在运行。如果 Pod 被删除或崩溃,Replication Controller 会创建新的 Pod 来满足副本数要求。
  3. Endpoint Controller

    • 作用:填充 Endpoints 对象,使服务能够正确地找到相应的 Pod,确保服务与后端 Pod 之间的通信。
  4. Service Account & Token Controllers

    • 作用:创建默认的 Service Account 并管理 API 访问令牌,确保每个命名空间都有一个默认的 Service Account。
  5. Namespace Controller

    • 作用:处理命名空间的创建和删除,确保在删除命名空间时清理相关资源。
  6. Job Controller

    • 作用:管理 Job 对象,确保 Job 中定义的任务(Pod)按预期运行和完成,适用于一次性任务或批处理任务。
  7. CronJob Controller

    • 作用:管理 CronJob 对象,按照预定义的时间表周期性地运行 Job。
  8. DaemonSet Controller

    • 作用:确保每个节点上都运行一个 DaemonSet 定义的 Pod,通常用于节点级别的任务,例如日志收集和监控。
  9. StatefulSet Controller

    • 作用:管理有状态应用,确保有状态 Pod 的创建、删除和更新按序执行,维护 Pod 的稳定网络标识和持久存储。
  10. Deployment Controller

    • 作用:管理 Deployment 对象,确保应用按期望的版本和副本数运行,支持滚动更新和回滚。
  11. ReplicaSet Controller

    • 作用:类似于 Replication Controller,但功能更强大,通常与 Deployment 一起使用,确保指定数量的 Pod 副本在任何时候都在运行。
  12. Horizontal Pod Autoscaler (HPA) Controller

    • 作用:根据资源使用情况(例如 CPU 或内存)自动扩展或缩减 Pod 数量,以满足应用的需求。
  13. Vertical Pod Autoscaler (VPA) Controller

    • 作用:根据实际资源使用情况调整 Pod 的资源请求和限制(CPU 和内存),提高资源利用率。
  14. Garbage Collector Controller

    • 作用:负责清理被删除资源的相关依赖资源,例如删除被删除 Pod 关联的 PersistentVolumeClaim(PVC)。
  15. Certificate Signing Request (CSR) Controller

    • 作用:管理和批准/拒绝证书签名请求,通常用于自动化证书管理。

这些控制器通过不断检查集群的实际状态和期望状态,执行必要的操作来确保 Kubernetes 集群的稳定和可靠运行。

Kubernetes Controller Manager 包含的控制器非常多,以下是一些更高级的或特定于某些功能的控制器:

  1. Ingress Controller

    • 作用:管理 Ingress 资源,提供外部访问到集群内部服务的方式,通过 HTTP/HTTPS 路由流量。
  2. ResourceQuota Controller

    • 作用:管理和执行 ResourceQuota 资源,确保命名空间内的资源使用不超过设定的配额。
  3. LimitRange Controller

    • 作用:管理和执行 LimitRange 资源,设置命名空间内 Pod 和容器的默认资源请求和限制。
  4. PersistentVolume Controller

    • 作用:管理 PersistentVolume 资源,确保持久存储卷的生命周期,包括创建、绑定和回收。
  5. PersistentVolumeClaim Controller

    • 作用:管理 PersistentVolumeClaim 资源,确保持久存储卷正确地绑定到请求的 Pod。
  6. StorageClass Controller

    • 作用:管理 StorageClass 资源,定义不同存储提供者的存储类型和配置,支持动态存储卷的创建。
  7. Certificate Controller

    • 作用:管理 Kubernetes 内部证书的创建和分发,通常与 Cert-Manager 等工具集成。
  8. PodDisruptionBudget (PDB) Controller

    • 作用:管理 PodDisruptionBudget 资源,限制计划内的 Pod 中断(例如滚动更新或节点维护)以确保应用的高可用性。
  9. NetworkPolicy Controller

    • 作用:管理 NetworkPolicy 资源,控制 Pod 间的网络流量,增强集群的安全性。
  10. Service Controller

    • 作用:管理 Service 资源,确保服务的负载均衡和 IP 地址分配。
  11. TTL Controller for Finished Resources

    • 作用:管理和清理已完成的 Job 和 Pod,根据定义的 TTL(生存时间)自动删除这些资源。
  12. EndpointSlice Controller

    • 作用:管理 EndpointSlice 资源,提供比传统 Endpoints 更高效和可扩展的服务发现机制。
  13. CSIDriver and CSINode Controllers

    • 作用:管理和协调 CSI(容器存储接口)驱动程序,确保 CSI 驱动程序的注册和节点能力的报告。
  14. VolumeAttachment Controller

    • 作用:管理 VolumeAttachment 资源,处理动态存储卷的挂载和卸载请求。
  15. ServiceAccountToken Controller

    • 作用:管理 ServiceAccount 令牌的创建和分发,为 Pod 提供安全的 API 访问凭证。

这些控制器涵盖了 Kubernetes 集群中广泛的资源和功能,通过不断协调和管理这些资源,确保集群的自动化操作、资源管理和高可用性。

以下是一些更为细分和特定功能的控制器:

  1. CSIDriver Controller

    • 作用:管理 CSI 驱动程序的生命周期,确保 CSI 驱动程序正确注册和使用。
  2. CSINode Controller

    • 作用:协调 CSI 驱动程序和 Kubernetes 节点,确保节点报告正确的存储能力。
  3. VolumeSnapshot Controller

    • 作用:管理 VolumeSnapshot 和 VolumeSnapshotContent 资源,支持持久卷的快照和恢复功能。
  4. CronJob Controller

    • 作用:管理 CronJob 资源,按照预定义的时间表定期运行 Job。
  5. ResourceClaim and ResourceClaimTemplate Controllers

    • 作用:管理资源声明(ResourceClaim)和资源声明模板(ResourceClaimTemplate),用于动态分配和管理共享资源。
  6. CustomResourceDefinition (CRD) Controller

    • 作用:管理 CRD 资源,允许用户定义和使用自定义资源类型。
  7. Event Controller

    • 作用:管理集群中的事件对象,用于记录和追踪集群中的重要操作和状态变化。
  8. Garbage Collector

    • 作用:自动清理被删除资源的相关依赖资源,例如删除被删除 Pod 关联的 PersistentVolumeClaim(PVC)。
  9. Priority and Fairness (P&F) Controller

    • 作用:管理 API 请求的优先级和公平性,确保高优先级请求得到及时处理,同时防止资源耗尽。
  10. TokenCleaner Controller

    • 作用:清理过期的服务账户令牌,确保集群安全性。
  11. PodSecurityPolicy (PSP) Controller

    • 作用:管理 Pod 安全策略,控制 Pod 的安全设置和权限。
  12. CertificateSigningRequest (CSR) Controller

    • 作用:管理和批准/拒绝证书签名请求,通常用于自动化证书管理。
  13. RuntimeClass Controller

    • 作用:管理 RuntimeClass 资源,支持不同的容器运行时配置。
  14. EndpointSlice Controller

    • 作用:管理 EndpointSlice 资源,提供比传统 Endpoints 更高效和可扩展的服务发现机制。
  15. MutatingAdmissionWebhook and ValidatingAdmissionWebhook Controllers

    • 作用:管理和执行动态准入控制策略,通过 Webhook 实现对资源创建、更新的动态验证和修改。
  16. ClusterRole and ClusterRoleBinding Controllers

    • 作用:管理集群级别的角色和角色绑定,控制集群内用户和服务账户的权限。
  17. Role and RoleBinding Controllers

    • 作用:管理命名空间级别的角色和角色绑定,控制命名空间内用户和服务账户的权限。
  18. Lease Controller

    • 作用:管理租约资源(Lease),用于协调集群中的主选举等分布式协调任务。
  19. APIService Controller

    • 作用:管理 APIService 资源,协调 Kubernetes API 聚合层的注册和可用性。

这些控制器共同工作,确保 Kubernetes 集群的自动化管理、资源调度、安全性和高可用性。通过这些控制器,Kubernetes 实现了对集群资源的全面管理和高效运行。

二、Kubernetes 主要控制器与其他组件交互示意图

示意图

在这里插入图片描述

交互说明

  1. kubectl / CLI 与 API Server 的交互

    • 用户通过 kubectl 或其他客户端工具向 API Server 发出 CRUD 操作请求(创建、读取、更新、删除)。
  2. API Server 与 etcd 的交互

    • API Server 将集群状态存储到 etcd,并从 etcd 读取状态数据。
  3. API Server 与 Scheduler 的交互

    • Scheduler 从 API Server 获取未调度的 Pod,确定它们的调度位置后将结果返回给 API Server。
  4. API Server 与 Controller Manager 的交互

    • Controller Manager 从 API Server 获取资源状态,根据控制逻辑进行必要的调整,然后将更新后的状态提交回 API Server。
  5. Controller Manager 内部控制器的交互

    • 各控制器(如 Node Controller、Replication Controller 等)负责特定资源的管理,通过 API Server 获取和更新状态。
  6. API Server 与 Kubelet 的交互

    • Kubelet 从 API Server 获取调度到该节点的 Pod 信息,管理 Pod 和容器的生命周期,并将节点和 Pod 的状态报告给 API Server。
  7. Kubelet 与 Container Runtime 的交互

    • Kubelet 通过 CRI 接口与容器运行时(如 Docker 或 containerd)通信,管理容器的创建、启动、停止等操作。
  8. Kubelet 与 Pod Network 的交互

    • Kubelet 配置 Pod 的网络,通过 CNI 插件设置网络连接。
  9. Kubelet 与 kube-proxy 的交互

    • Kube-proxy 维护网络规则和服务发现,通过 API Server 获取服务信息并在节点上配置网络规则。
  10. Controller Manager 与 Persistent Storage 的交互

    • Controller Manager 通过 CSI 插件管理持久存储卷的生命周期,包括卷的创建、绑定和删除。

通过这样的示意图和详细说明,可以更直观地理解 Kubernetes 各主要组件和控制器之间的交互关系。

三、Kubernetes Controller最佳实践

在 Kubernetes 中,控制器(Controller)是保持系统实际状态与期望状态一致的关键组件。为了确保控制器的高效、可靠和安全运行,以下是一些最佳实践:

设计和实现控制器的最佳实践

  1. Idempotency(幂等性)

    • 确保控制器的操作是幂等的,这意味着无论操作执行多少次,结果应该是相同的。这可以避免因重复执行而产生的副作用。
  2. Reconciliation Loop(协调循环)

    • 实现一个可靠的协调循环来监控资源状态变化,并采取相应行动使其达到期望状态。这个循环应该能够处理突发的事件和定期的状态检查。
  3. Event Handling(事件处理)

    • 使用 Kubernetes 提供的 Informer 和 Watch 机制来监听资源变化事件,减少不必要的 API 调用,提高响应速度。
  4. Error Handling(错误处理)

    • 设计可靠的错误处理机制,记录错误日志,避免控制器因未处理的异常而崩溃。重试机制应考虑指数退避策略(exponential backoff)以避免过载。
  5. Rate Limiting(限流)

    • 实施限流机制来控制控制器的执行频率,防止由于频繁的重试和协调操作导致的资源消耗过大。

部署和管理控制器的最佳实践

  1. Scalability(可扩展性)

    • 确保控制器能够水平扩展(Horizontal Scaling),通过增加副本数来处理更多的负载。
  2. Resource Management(资源管理)

    • 为控制器设置合理的资源请求和限制(CPU 和内存),避免因资源耗尽导致控制器性能下降或崩溃。
  3. Observability(可观察性)

    • 实施日志记录、监控和告警机制。使用 Prometheus 监控控制器的指标,确保系统运行健康。
  4. Security(安全性)

    • 使用 Kubernetes RBAC(角色访问控制)来限制控制器的权限,仅授予其所需的最低权限(Principle of Least Privilege)。
    • 定期更新控制器的镜像,确保使用最新的安全补丁。

开发控制器的最佳实践

  1. Controller Libraries and Frameworks(控制器库和框架)

    • 利用现有的 Kubernetes 控制器库和框架(如 Kubebuilder 和 Operator SDK)来简化控制器的开发和管理。
  2. Testing(测试)

    • 实施单元测试、集成测试和端到端测试,确保控制器在各种条件下的正确性和稳定性。
    • 使用 Kind 或 Minikube 等本地 Kubernetes 环境进行测试,模拟真实场景。
  3. Documentation(文档)

    • 提供详细的控制器文档,包括架构设计、配置选项、使用指南和故障排除步骤,帮助用户理解和使用控制器。

高可用性和容错的最佳实践

  1. Redundancy(冗余)

    • 部署多个副本的控制器来提高高可用性,确保在单个副本失败时仍有其他副本继续工作。
  2. Health Checks(健康检查)

    • 配置 Liveness 和 Readiness 探针,以便 Kubernetes 能够自动检测和恢复故障的控制器实例。
  3. Graceful Shutdown(优雅停机)

    • 实现优雅停机机制,确保控制器在接收到终止信号时能够完成当前的协调任务,避免中间状态不一致。

通过遵循这些最佳实践,可以确保 Kubernetes 控制器的高效、可靠和安全运行,有助于维护集群的稳定性和高可用性。

四、Controller伪代码实现

为了实现一个遵循最佳实践的 Kubernetes 控制器,以下是一个使用 Go 语言编写的伪代码示例。该控制器监控自定义资源 Foo,并确保每个 Foo 对象对应一个名为 bar-{foo_name} 的 ConfigMap 存在。

完整的 Go 语言实现 Kubernetes 控制器伪代码

package mainimport ("context""fmt""log""time"metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"corev1 "k8s.io/api/core/v1""k8s.io/client-go/informers""k8s.io/client-go/kubernetes""k8s.io/client-go/rest""k8s.io/client-go/tools/cache""k8s.io/client-go/util/retry""k8s.io/client-go/util/workqueue""k8s.io/apimachinery/pkg/util/wait"
)// FooController 定义控制器结构体
type FooController struct {clientset  *kubernetes.Clientsetinformer   cache.SharedIndexInformerworkqueue  workqueue.RateLimitingInterface
}// NewFooController 创建新的控制器实例
func NewFooController(clientset *kubernetes.Clientset, informer cache.SharedIndexInformer) *FooController {workqueue := workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "Foo")informer.AddEventHandler(cache.ResourceEventHandlerFuncs{AddFunc: func(obj interface{}) {key, err := cache.MetaNamespaceKeyFunc(obj)if err == nil {workqueue.Add(key)}},UpdateFunc: func(oldObj, newObj interface{}) {key, err := cache.MetaNamespaceKeyFunc(newObj)if err == nil {workqueue.Add(key)}},DeleteFunc: func(obj interface{}) {key, err := cache.DeletionHandlingMetaNamespaceKeyFunc(obj)if err == nil {workqueue.Add(key)}},})return &FooController{clientset: clientset,informer:  informer,workqueue: workqueue,}
}// Run 启动控制器
func (c *FooController) Run(stopCh <-chan struct{}) {defer c.workqueue.ShutDown()go c.informer.Run(stopCh)if !cache.WaitForCacheSync(stopCh, c.informer.HasSynced) {log.Fatalf("Error syncing cache")return}wait.Until(c.runWorker, time.Second, stopCh)
}// runWorker 处理队列中的项目
func (c *FooController) runWorker() {for c.processNextItem() {}
}// processNextItem 处理队列中的下一个项目
func (c *FooController) processNextItem() bool {key, quit := c.workqueue.Get()if quit {return false}defer c.workqueue.Done(key)err := c.syncHandler(key.(string))if err != nil {c.workqueue.AddRateLimited(key)} else {c.workqueue.Forget(key)}return true
}// syncHandler 同步资源状态
func (c *FooController) syncHandler(key string) error {namespace, name, err := cache.SplitMetaNamespaceKey(key)if err != nil {return fmt.Errorf("invalid resource key: %s", key)}// 获取 Foo 对象foo, err := c.informer.GetIndexer().ByNamespace(namespace).Get(name)if err != nil {if cache.IsNotFound(err) {// Foo 对象已被删除return nil}return err}// 确保对应的 ConfigMap 存在configMapName := fmt.Sprintf("bar-%s", name)configMap, err := c.clientset.CoreV1().ConfigMaps(namespace).Get(context.TODO(), configMapName, metav1.GetOptions{})if err != nil {if cache.IsNotFound(err) {// 创建 ConfigMapconfigMap = &corev1.ConfigMap{ObjectMeta: metav1.ObjectMeta{Name:      configMapName,Namespace: namespace,},Data: map[string]string{"foo": name,},}_, err = c.clientset.CoreV1().ConfigMaps(namespace).Create(context.TODO(), configMap, metav1.CreateOptions{})if err != nil {return err}} else {return err}}return nil
}func main() {config, err := rest.InClusterConfig()if err != nil {log.Fatalf("Error building kubeconfig: %s", err.Error())}clientset, err := kubernetes.NewForConfig(config)if err != nil {log.Fatalf("Error building kubernetes clientset: %s", err.Error())}informerFactory := informers.NewSharedInformerFactory(clientset, time.Minute)fooInformer := informerFactory.Core().V1().ConfigMaps().Informer()controller := NewFooController(clientset, fooInformer)stopCh := make(chan struct{})defer close(stopCh)go controller.Run(stopCh)<-stopCh
}

代码说明

  1. 初始化控制器

    • NewFooController 函数初始化控制器,设置事件处理程序,将资源事件添加到工作队列。
  2. 运行控制器

    • Run 方法启动控制器,运行 Informer 并同步缓存,然后启动工作线程处理队列中的项目。
  3. 处理队列中的项目

    • runWorker 方法从队列中提取项目并调用 processNextItem 处理它们。
    • processNextItem 方法调用 syncHandler 同步资源状态,并根据处理结果决定是否重新调度该项目。
  4. 同步资源状态

    • syncHandler 方法获取 Foo 对象,并确保对应的 ConfigMap 存在。如果不存在,则创建它。

最佳实践

  • Idempotency(幂等性):确保每次处理同一个资源时,结果是一致的,不会产生副作用。
  • Reconciliation Loop(协调循环):通过 syncHandler 实现协调循环,保持实际状态与期望状态一致。
  • Event Handling(事件处理):使用 Informer 监听资源变化,减少 API 调用。
  • Error Handling(错误处理):通过重试机制处理错误,并使用速率限制器防止过载。
  • Rate Limiting(限流):使用 RateLimitingInterface 控制工作队列的处理速率。
  • Scalability(可扩展性):使用工作队列和多工作线程,提高处理能力。
  • Resource Management(资源管理):在实际部署时,应设置合理的资源请求和限制。
  • Observability(可观察性):记录日志(在实际实现中应添加日志记录)和监控指标。
  • Security(安全性):使用适当的 RBAC 配置,确保控制器仅有必要的权限。

五、Kubernetes Controller历史演进

Kubernetes Controller Manager 作为 Kubernetes 集群的核心组件之一,其功能和架构在不同版本的 Kubernetes 中不断演进。以下是 Kubernetes Controller Manager 的历史演进概述:

初期阶段 (v1.0 之前)

在 Kubernetes 的早期版本中,Controller Manager 的概念并不明确。早期的控制器逻辑直接内置在 API Server 中,负责管理 Pod 和其他资源的生命周期。随着 Kubernetes 的发展,控制器逻辑逐渐被抽象和独立出来,形成了一个单独的组件。

v1.0 (2015)

  • 单一二进制:最初,所有控制器都是作为一个单一的二进制文件 kube-controller-manager 运行。这种设计简化了部署和管理,但缺乏灵活性。
  • 基本控制器:包括 Node Controller、Replication Controller、Endpoint Controller 和 Service Account Controller 等基本控制器。

v1.2 (2016)

  • Horizontal Pod Autoscaler (HPA):引入了 HPA 控制器,用于基于 CPU 使用率自动扩展 Pod 数量。

v1.5 (2016)

  • CustomResourceDefinition (CRD):替换了 ThirdPartyResource (TPR),允许用户定义自定义资源。CRD 控制器负责管理这些自定义资源。
  • StatefulSet Controller:引入 StatefulSet 控制器,用于管理有状态应用,确保有序和稳定的 Pod 部署。

v1.6 (2017)

  • Multiple Schedulers:引入了对多调度器的支持,允许用户使用自定义调度器。
  • PodDisruptionBudget (PDB):引入 PDB 控制器,限制计划内的 Pod 中断以确保应用的高可用性。

v1.8 (2017)

  • Taints and Tolerations:增强了调度功能,引入了污点和容忍,允许节点标记不适合运行某些 Pod 的原因。

v1.9 (2017)

  • Workloads API 组:引入了新的工作负载 API 组,包括 Deployment、DaemonSet 和 StatefulSet 等,简化了工作负载管理。

v1.10 (2018)

  • Volume Snapshots:引入 VolumeSnapshot 和 VolumeSnapshotContent 控制器,支持持久卷的快照和恢复功能。

v1.12 (2018)

  • Topology Aware Volume Scheduling:改进了持久卷调度,考虑到存储卷的拓扑要求,以优化性能。

v1.14 (2019)

  • Cluster API:引入 Cluster API 控制器,用于管理 Kubernetes 集群的生命周期(创建、升级、删除)。

v1.16 (2019)

  • Custom Metrics:扩展 HPA 控制器,支持基于自定义指标的自动扩展。

v1.18 (2020)

  • EndpointSlice:引入 EndpointSlice 控制器,提供比传统 Endpoints 更高效和可扩展的服务发现机制。

v1.19 (2020)

  • CSI Volume Health Monitoring:改进了 CSI 控制器,添加了卷健康监控功能。

v1.20 (2020)

  • Storage Capacity Tracking:增强了存储调度,支持跟踪和报告存储容量。

v1.21 (2021)

  • Immutable Secrets and ConfigMaps:引入不可变的 Secrets 和 ConfigMaps,提高集群的安全性和性能。

v1.22 (2021)

  • PodSecurityPolicy (PSP) Deprecated:宣布弃用 PodSecurityPolicy,逐步引入新的安全策略机制。

v1.23 (2021)

  • CronJob Controller:CronJob 控制器正式成为稳定版,用于管理定时任务。

v1.24 (2022)

  • PodSecurity Admission:引入 Pod 安全准入控制器,取代 PSP,提供灵活的 Pod 安全策略。

v1.25 (2022)

  • Dynamic Resource Allocation:引入动态资源分配控制器,支持共享资源的动态分配和管理。

总结

Kubernetes Controller Manager 的演进体现了 Kubernetes 不断扩展和增强其功能以满足各种需求的过程。随着 Kubernetes 的发展,Controller Manager 添加了许多新功能和控制器,以更好地管理和调度集群资源,提升系统的自动化和智能化水平。这些演进帮助 Kubernetes 成为一个强大且灵活的容器编排平台。

完。
希望对您有用!关注锅总,及时获得更多花里胡哨的运维实用操作!
在这里插入图片描述

锅总微信公众号
在这里插入图片描述
锅总个人博客

https://gentlewok.blog.csdn.net/

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

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

相关文章

文件批量重命名001到100 最简单的数字序号递增的改名技巧

文件批量重命名001到100 最简单的数字序号递增的改名方法。最近看到很多人都在找怎么批量修改文件名称&#xff0c;还要按固定的ID需要递增&#xff0c;这个办法用F2或者右键改名是不能做到的。 这时候我们可以通过一个专业的文件批量重命名软件来批量处理这些文档。 芝麻文件…

今年哪两个行业可能有贝塔?

银行和综合板块存在比较明显的行业贝塔&#xff0c;背后原因是&#xff1a;银行板块中&#xff0c;最小的几家银行市值也不小&#xff1b;综合板块中&#xff0c;最大的几家市值也不大。 一、今年哪两个行业可能有贝塔&#xff1f; 我们一直强调今年市场呈现出【行业弱beta、风…

indexedDB---浏览器本地数据库实现增删改查

关于indexedDB indexedDB的基本使用&#xff0c;可以参考&#xff1a;indexedDB---掌握浏览器内建数据库的基本用法_indexdb浏览器使用-CSDN博客 indexedDB是浏览器本地数据库&#xff0c;既然是数据库就能够实现增删改查&#xff0c;了解了indexedDB的基本使用后&#xff0c…

计算机网络之奇偶校验码和CRC冗余校验码

今天我们来看看有关于计算机网络的知识——奇偶校验码和CRC冗余校验码&#xff0c;这两种检测编码的方式相信大家在计算机组成原理当中也有所耳闻&#xff0c;所以今天我就来跟大家分享有关他们的知识。 奇偶校验码 奇偶校验码是通过增加冗余位使得码字中1的个数恒为奇数或偶数…

嵌入式项目分享| 终极智能手表,全过程+全开源分享

这是一个非常完整的智能手表开源项目,功能齐全,且资料开源,如果你是:自己平时喜欢diy的工程师,想要提升开发技能的学生,马上要做毕设的大四学生,这个手表很值得一做,别错过了~~ 所有开源的资料以及原文链接见文末。 先来看下这个手表的功能: 首先,是一个可以佩戴的手…

微型导轨:手术机器人的高精度“骨骼”

微型导轨精度高&#xff0c;摩擦系数小&#xff0c;自重轻&#xff0c;结构紧凑&#xff0c;被广泛应用在医疗器械中&#xff0c;尤其是在手术机器人中的应用&#xff0c;通过手术机器人&#xff0c;外科医生可以远离手术台操纵机器人进行手术。可以说&#xff0c;是当之无愧的…

经验分享,在线word转图片

这里分享一个在线word转图片的网站&#xff0c;比较好用 网址&#xff1a;http://www.docpe.com/word/word-to-image.aspx 截图&#xff1a;

Spring Boot如何实现跨域资源共享(CORS)?

&#x1f345; 作者简介&#xff1a;哪吒&#xff0c;CSDN2021博客之星亚军&#x1f3c6;、新星计划导师✌、博客专家&#x1f4aa; &#x1f345; 哪吒多年工作总结&#xff1a;Java学习路线总结&#xff0c;搬砖工逆袭Java架构师 &#x1f345; 技术交流&#xff1a;定期更新…

浔川3样AI产品即将上线!——浔川总社部

浔川3样AI产品即将上线&#xff01; 浔川AI翻译v3.0 即将上线&#xff01; 浔川画板v5.1 即将上线&#xff01; 浔川AI五子棋v1.4 即将上线&#xff01; 整体通告详见&#xff1a;浔川AI五子棋&#xff08;改进&#xff08;完整&#xff09;版1.3&#xff09;——浔川python社…

Java洗鞋预约小程序源码

&#x1f4a5;洗鞋神器来袭&#xff01;轻松预约&#xff0c;让你的鞋子焕然一新&#x1f45f; &#x1f389; 告别洗鞋烦恼&#xff0c;洗鞋预约小程序来啦&#xff01; 你是不是常常为洗鞋而烦恼&#xff1f;手洗太累&#xff0c;送去洗衣店又贵又麻烦。现在&#xff0c;好…

初识Java(二)

初识Java的main方法 1.1 main方法示例 public class world {public static void main(String[] args) {System.out.println("hello,world!");}}通过上述代码&#xff0c;我们可以看到一个完整的Java程序的结构&#xff0c;Java程序的结构由如下三个部分组成&#x…

Day 34:2368. 受限条件下可到达节点的数目

Leetcode 2368. 受限条件下可到达节点的数目 现有一棵由 n 个节点组成的无向树&#xff0c;节点编号从 0 到 n - 1 &#xff0c;共有 n - 1 条边。 给你一个二维整数数组 edges &#xff0c;长度为 n - 1 &#xff0c;其中 edges[i] [ai, bi] 表示树中节点 ai 和 bi 之间存在一…

【广度优先搜索 深度优先搜索 图论】854. 相似度为 K 的字符串

本文涉及知识点 广度优先搜索 深度优先搜索 图论 图论知识汇总 深度优先搜索汇总 CBFS算法 LeetCode 854. 相似度为 K 的字符串 对于某些非负整数 k &#xff0c;如果交换 s1 中两个字母的位置恰好 k 次&#xff0c;能够使结果字符串等于 s2 &#xff0c;则认为字符串 s1 和…

three.js 第十一节 - uv坐标

// ts-nocheck // 引入three.js import * as THREE from three // 导入轨道控制器 import { OrbitControls } from three/examples/jsm/controls/OrbitControls // 导入lil.gui import { GUI } from three/examples/jsm/libs/lil-gui.module.min.js // 导入tween import * as T…

基于Java微信小程序民宿短租系统设计和实现(源码+LW+调试文档+讲解等)

&#x1f497;博主介绍&#xff1a;✌全网粉丝10W,CSDN作者、博客专家、全栈领域优质创作者&#xff0c;博客之星、平台优质作者、专注于Java、小程序技术领域和毕业项目实战✌&#x1f497; &#x1f31f;文末获取源码数据库&#x1f31f;感兴趣的可以先收藏起来&#xff0c;还…

Linux rpm包管理

rpm用于互联网下载包的打包及安装工具&#xff0c;它包含在某些Linux分发版中。它生成具有.RPM扩展名的文件。RPM是RedHat Package Manager (RedHat软件包管理工具&#xff09;的缩写&#xff0c;类似windows的setup.exe&#xff0c;这一文件格式名称虽然打上了RedHat的标志&am…

【Redis】

Redis 常见面试题 认识 Redis 什么是 Redis&#xff1f; 我们直接看 Redis 官方是怎么介绍自己的。 Redis 官方的介绍原版是英文的&#xff0c;我翻译成了中文后截图的&#xff0c;所以有些文字读起来会比较拗口&#xff0c;没关系&#xff0c;我会把里面比较重要的特性抽出来…

经典游戏案例:仿植物大战僵尸

学习目标&#xff1a;仿植物大战僵尸核心玩法实现 游戏画面 项目结构目录 部分核心代码 using System; using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.SceneManagement; using Random UnityEngine.Random;public enum…

STM32启动流程 和 map文件的作用

一&#xff0c;启动流程 1. 复位/上电 2. 根据 BOOT0/BOOT1 确定程序从哪个存储位置执行 3. 初始化 SP 及 PC 指针 将 0X08000000 位置的栈顶地址存放在 SP 指针中 将 0x08000004 位置存放的向量地址装入 PC 程序计数器 4. 初始化系统时钟 5. 初始化用户堆栈 6. 进入main函数 二…

idea中maven新增的配置文件xx.xml没生效问题

项目场景&#xff1a; 因为公司使用自己的私服下载jar,则没有使用默认的settings.xml文件。而是新增了一个settingsold.xml文件 问题描述 公司项目有用自己的私服,Maven正常去私服下载jar包是没问题的。但是一直是去找的阿里云镜像,到导致阿里云镜像找不到相关的jar包报错!!!…