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 main

import (
    "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.Clientset
    informer   cache.SharedIndexInformer
    workqueue  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) {
            // 创建 ConfigMap
            configMap = &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/

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

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

相关文章

分布式系统：常见的陷阱和复杂性

分布式系统：常见的陷阱和复杂性

分布式系统的复杂性是工程师和开发人员面临的重要挑战。复杂性往往会随着系统的发展而增加&#xff0c;因此积极主动非常重要。让我们来谈谈您可能会遇到哪些类型的复杂性以及在工作中应对它的有效策略。 分布式系统和复杂性 在开发中&#xff0c;分布式系统是相互连接并执行…
阅读更多...
nacos 简述 安装运行

nacos 简述 安装运行

一、下载 官网:Redirecting to: https://nacos.io/ 文档:Nacos 快速开始 github地址:GitHub - alibaba/nacos: an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications. 下载nacos server(tips:也…
阅读更多...
CVPR2024｜vivo提出使用对抗微调获得泛化性更强的SAM，分割性能直接登顶 SOTA！

CVPR2024｜vivo提出使用对抗微调获得泛化性更强的SAM，分割性能直接登顶 SOTA！

在计算机视觉不断发展的领域中&#xff0c;基础模型已成为一种关键工具&#xff0c;显示出对多种任务的出色适应性。其中&#xff0c;由 Meta AI 开发的 Segment Anything Model&#xff08;SAM&#xff09;在图像分割任务中表现杰出。然而&#xff0c;和其他类似模型一样&…
阅读更多...
docker环境安装redis

docker环境安装redis

docker下载redis镜像 docker pull redis:bullseye查看redis镜像 docker images创建redis容器 docker run \ -d \ --name redis \ -p 6379:6379 \ --restart unless-stopped \ -v /mydata/redis/data:/data \ -v /mydata/redis/conf/redis.conf:/etc/redis/redis.conf \ redi…
阅读更多...
【Leetcode】520. 检测大写字母

【Leetcode】520. 检测大写字母

文章目录 题目思路代码复杂度分析时间复杂度空间复杂度 结果总结 题目 题目链接&#x1f517;我们定义&#xff0c;在以下情况时&#xff0c;单词的大写用法是正确的&#xff1a; 全部字母都是大写&#xff0c;比如 “USA” 。单词中所有字母都不是大写&#xff0c;比如 “le…
阅读更多...
【前端项目笔记】4 权限管理

【前端项目笔记】4 权限管理

权限管理 效果展示&#xff1a; &#xff08;1&#xff09;权限列表 &#xff08;2&#xff09;角色列表 其中的分配权限功能 权限列表功能开发 新功能模块&#xff0c;需要创建新分支 git branch 查看所有分支&#xff08;*表示当前分支&#xff09; git checkout -b ri…
阅读更多...
机器学习辅助的乙醇浓度检测（毕设节选）

机器学习辅助的乙醇浓度检测（毕设节选）

目录 1.为什么要机器学习 2. 神经网络一般组成 3.BP神经网络工作过程 4.评价指标 5.实操代码 1.为什么要用机器学习 人工分析大量的谐振模式&#xff0c;建立各种WGM的响应与未知目标之间的关系&#xff0c;是一个很大的挑战。机器学习(ML)能够自行识别全谱的全部特征。作为…
阅读更多...
021.合并两个有序链表，递归和遍历

021.合并两个有序链表，递归和遍历

题意 将两个升序链表合并为一个新的 升序 链表并返回。新链表是通过拼接给定的两个链表的所有节点组成的。 难度 简单 标签 链表、排序 示例 输入&#xff1a;l1 [1,2,4], l2 [1,3,4] 输出&#xff1a;[1,1,2,3,4,4]输入&#xff1a;l1 [], l2 [] 输出&#xff1a;[]…
阅读更多...
Maven列出所有的依赖树

Maven列出所有的依赖树

在 IntelliJ IDEA 中&#xff0c;你可以使用 Maven 插件来列出项目的依赖树。Maven 插件提供了一个名为dependency:tree的目标&#xff0c;可以帮助你获取项目的依赖树详细信息。 要列出项目的依赖树&#xff0c;可以执行以下步骤&#xff1a; 打开 IntelliJ IDEA&#xff0c;…
阅读更多...
未来科技中的RTK接收机应用探索

未来科技中的RTK接收机应用探索

RTK实时差分定位技术&#xff08;RTK&#xff0c;Real-Time Kinematic&#xff09;&#xff0c;作为高精度定位技术的一种重要手段&#xff0c;已经在地理测绘、测量工程、航空航天等领域取得了广泛应用。随着科技的不断发展&#xff0c;RTK导航接收机的应用领域也日益拓宽。首…
阅读更多...
文华wh6均线交易策略多空波段止盈止损提示主图指标公式源码

文华wh6均线交易策略多空波段止盈止损提示主图指标公式源码

文华wh6均线交易策略多空波段止盈止损提示主图指标公式源码&#xff1a; EMA120:EMA(C,120); RSV:(CLOSE-LLV(LOW,9))/(HHV(HIGH,9)-LLV(LOW,9))*100; K:SMA(RSV,3,1); D:SMA(K,3,1); J:3*K-2*D; DRAWTEXT(C>EMA120&&J<0,L,多),VALIGN0; DRAWTEXT(C<EMA…
阅读更多...
Blazor的SSR服务端渲染是不是交互式的

Blazor的SSR服务端渲染是不是交互式的

从.NET8开始&#xff0c;Blazor引入了SSR服务端渲染&#xff0c;归功于MVC和RazePage的沉淀&#xff0c;虽然来得晚&#xff0c;但一经发布&#xff0c;就将Blazor推向了新的高度。从今年开始&#xff0c;Youtube上关于Blazor的优质教学视频&#xff0c;以肉眼可见的速度在增加…
阅读更多...
基于Java的门禁系统【附源码】

基于Java的门禁系统【附源码】

第1章 绪论 1.1 课题背景 门禁系统就是对出入口通道进行管制的系统&#xff0c;它是在传统的门锁基础上发展而来的。传统的机械门锁仅仅是单纯的机械装置&#xff0c;无论结构设计多么合理&#xff0c;材料多么坚固&#xff0c;人们总能通过各种手段把它打开。在出入人员很多的…
阅读更多...
写程序100道41-50

写程序100道41-50

41.定义一个Father和Child类&#xff0c;并进行测试。 要求如下&#xff1a; (1)Father类为外部类&#xff0c;类中定义一个私有的String类型的属性name&#xff0c;name的值为“Join”。 (2)Child类为Father类的内部类&#xff0c;其中定义一个readName()方法&#xff0c;方…
阅读更多...
PHP 界的扛把子 Swoole 异步通信利器

PHP 界的扛把子 Swoole 异步通信利器

大家好&#xff0c;我是码农先森。 引言 我今天主要介绍的内容是包括但不仅限于 Swoole &#xff0c;也有一部分 Go 语言的内容。 为什么要介绍 Swoole ? 先说一说背景吧&#xff0c;我们项目组之前要为《香港 01》开发一个积分系统的项目&#xff0c;这个系统的主要功能包…
阅读更多...
LINUX centos 安装jenkins超超超超超超级详细步骤

LINUX centos 安装jenkins超超超超超超级详细步骤

Jenkins安装 配置jdkmavengit jenkins 拉取 配置 jdk 1.安装jdk8 yum install java-1.8.0-openjdk-devel2.检查版本 java -version出现如下图查看版本信息 3. 设置JAVA_HOME环境变量 vim /etc/profile最下方输入 export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk expor…
阅读更多...
鸿蒙开发HarmonyOS NEXT（一）

鸿蒙开发HarmonyOS NEXT（一）

最近总听见大家讨论鸿蒙&#xff0c;前端转型的好方向&#xff1f;先入门学习下 目前官方版本和文档持续更新中 一、开发环境 提示&#xff1a;要占用的空间比较多&#xff0c;建议安装在剩余空间多的盘 1、下载&#xff1a;官网最新工具 - 下载中心 - 华为开发者联盟 (huaw…
阅读更多...
记一次 APK 逆向动静调试 + so 动态链接库分析

记一次 APK 逆向动静调试 + so 动态链接库分析

0x00 前言&#xff1a; 好久没有做过安卓逆向了&#xff0c;最近重新系统地学习了安卓逆向技术。找到了一道较为典型的逆向分析题来练手&#xff0c;以锻炼动静态分析和动态链接库分析的基本能力。在这里记录基本的分析流程手法。 0x01 逆向分析&#xff1a; 一、使用 Genym…
阅读更多...
视频汇聚平台LntonCVS视频集中存储平台技术解决方案

视频汇聚平台LntonCVS视频集中存储平台技术解决方案

安防视频监控技术是一种利用各种监控设备捕捉实时画面&#xff0c;并将其传输至监控中心或数据存储设备的技术。随着科技的不断进步&#xff0c;监控视频技术也在不断改进&#xff0c;应用领域也在不断扩展。 然而&#xff0c;尽管技术进步&#xff0c;当前视频监控技术仍然面临…
阅读更多...
线性代数基础概念：向量空间

线性代数基础概念：向量空间

目录 线性代数基础概念&#xff1a;向量空间 1. 向量空间的定义 2. 向量空间的性质 3. 基底和维数 4. 子空间 5. 向量空间的例子 总结 线性代数基础概念&#xff1a;向量空间 向量空间是线性代数中最基本的概念之一&#xff0c;它为我们提供了一个抽象的框架&#xff0c…
阅读更多...
最新文章

Copyright @ 2022~2023