Kubernetes之Controller详解

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/
相关阅读:
nodejs创建web服务器
 JavaScript(WebAPI) (前端）
【概念】数据仓库和数仓建模
 html网页设计期末大作业_网页设计平时作业(诗词网页 4页)
Python3《机器学习实战》学习笔记（五）：Logistic回归基础篇之梯度上升算法
 绿盾加密如何顺利切换成IP-Guard加密
 软件工程导论：概述引言
 WEB核心【记录网站登录人数，记录用户名案例】Cookie技术实现
 渗透测试之分享常用工具、插件和脚本（干货）
ubuntu 操作杂项
原文地址：https://blog.csdn.net/qq_35630153/article/details/139999155

一、Kubernetes Controller种类

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

示意图

交互说明

三、Kubernetes Controller最佳实践

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

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

开发控制器的最佳实践

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

四、Controller伪代码实现

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

代码说明

最佳实践

五、Kubernetes Controller历史演进

初期阶段 (v1.0 之前)

v1.0 (2015)

v1.2 (2016)

v1.5 (2016)

v1.6 (2017)

v1.8 (2017)

v1.9 (2017)

v1.10 (2018)

v1.12 (2018)

v1.14 (2019)

v1.16 (2019)

v1.18 (2020)

v1.19 (2020)

v1.20 (2020)

v1.21 (2021)

v1.22 (2021)

v1.23 (2021)

v1.24 (2022)

v1.25 (2022)

总结