使用 Kubernetes 控制器减少系统管理员的辛劳工作

How Kubernetes became the solution for migrating legacy applications

图片来源：

Opensource.com

Kubernetes 是一个平台，它巧妙地伪装成运行容器的平台，实际上是为了减少辛劳工作。允许运行容器和减少辛劳工作的元素是 Kubernetes 的 控制器 概念。

Kubernetes 中的大多数资源都由 kube-controller-manager 管理，简称“控制器”。控制器被定义为“一个控制循环，它监视集群的共享状态……并进行更改，试图使当前状态朝着期望状态发展。” 可以这样理解：Kubernetes 控制器之于微服务，就像 Chef recipe（或 Ansible playbook）之于单体应用。

每个 Kubernetes 资源都由其自己的控制循环控制。这是比以前的系统（如 Chef 或 Puppet）更进一步的，Chef 或 Puppet 都在服务器级别有控制循环，但资源级别没有。控制器是一段相当简单的代码，它在一个资源上创建一个控制循环，以确保该资源的行为正确。这些控制循环可以堆叠在一起，以简单的接口创建复杂的功能。

这方面最典型的例子是我们如何在 Kubernetes 中管理 Pod。Pod 实际上是一个应用程序的正在运行的副本，被要求在特定的工作节点上运行。如果该应用程序崩溃，则在该节点上运行的 kubelet 将重新启动它。但是，如果该节点崩溃，则 Pod 不会被恢复，因为负责该资源的控制循环（通过 kubelet 进程）不再存在。为了使应用程序更具弹性，Kubernetes 具有 ReplicaSet 控制器。

ReplicaSet 控制器捆绑在 Kubernetes controller-manager 中，它在 Kubernetes master 节点上运行，并包含用于这些更高级资源的控制器。ReplicaSet 控制器负责确保始终运行一定数量的应用程序副本。为此，ReplicaSet 控制器请求创建给定数量的 Pod。然后，它定期检查正确数量的 Pod 是否仍在运行，并将请求更多 Pod 或销毁现有 Pod 以实现此目的。

通过从 Kubernetes 请求 ReplicaSet，您可以获得应用程序的自我修复部署。您可以通过请求 Deployment 来进一步为您的工作负载添加生命周期管理，Deployment 是一个控制器，它管理 ReplicaSet 并通过管理应用程序 ReplicaSet 的多个版本来提供滚动升级。

这些控制器非常适合管理 Kubernetes 资源，也非常适合管理 Kubernetes 外部的资源。云控制器管理器是一组 Kubernetes 控制器，它们作用于 Kubernetes 外部的资源，特别是为 Kubernetes 在底层云基础设施上提供功能的资源。这就是驱动 Kubernetes 能够执行诸如 LoadBalancer Service 类型创建和管理云特定的负载均衡器（例如，AWS 上的 Elastic Load Balancer）等操作的能力。

此外，您可以通过编写一个控制器来扩展 Kubernetes，该控制器监视事件和注解，并执行额外的工作，作用于 Kubernetes 资源或具有某种形式的可编程 API 的外部资源。

回顾

控制器是 Kubernetes 功能的基本构建块。
控制器形成一个控制循环，以确保给定资源的状态与请求的状态匹配。
Kubernetes 通过 Controller Manager 和 Cloud Controller Manager 进程提供控制器，这些进程提供额外的弹性和功能。
ReplicaSet 控制器通过确保运行正确数量的副本来增加 Pod 的弹性。
Deployment 控制器为 ReplicaSet 增加了滚动升级功能。
您可以通过编写自己的控制器来扩展 Kubernetes 的功能。

控制器减少系统管理员的辛劳工作

系统管理员队列中最常见的工单是一些相当简单的任务，这些任务应该自动化，但由于各种原因而没有自动化。例如，创建或更新 DNS 记录通常需要更新 zone file，但一个错误的条目可能会导致整个 DNS 基础设施瘫痪。或者那些看起来像 [SYSAD-42214] SSL 证书过期 - 生产环境宕机 的工单呢？

图片来源：

^{来源：HasturHasturHamster}

如果我告诉你 Kubernetes 可以通过运行一些额外的控制器来为您管理这些事情，你会怎么想？

想象一下，在一个世界里，要求 Kubernetes 为您运行应用程序将自动创建和管理 DNS 地址和 SSL 证书。我们生活在一个多么美好的世界！

示例：外部 DNS 控制器

external-dns 控制器是 Kubernetes 将操作视为微服务的完美示例。您使用 DNS 提供商对其进行配置，它将监视包括 Service 和 Ingress 控制器在内的资源。当其中一个资源发生更改时，它将检查它们的注解，这些注解会告诉它何时需要执行操作。

在集群中运行 external-dns 控制器后，您可以将以下注解添加到服务中，它将出去为该资源创建一个匹配的 DNS A 记录

kubectl annotate service nginx \
    "external-dns.alpha.kubernetes.io/hostname=nginx.example.org."

您可以更改其他特性，例如 DNS 记录的 TTL 值

kubectl annotate service nginx \
    "external-dns.alpha.kubernetes.io/ttl=10"

就这样，您现在为 Kubernetes 中的应用程序和服务提供了自动 DNS 管理，它可以对集群中的任何更改做出反应，以确保您的 DNS 是正确的。

示例：证书管理器 Operator

与 external-dns 控制器一样，cert-manager 将对资源中的更改做出反应，但它还附带一个自定义资源定义 (CRD)，它允许您将证书作为其自身的资源请求，而不仅仅是作为注解的副产品。

cert-manager 与 Let's Encrypt 和其他证书来源合作，以请求有效的、签名的传输层安全 (TLS) 证书。您甚至可以将它与 external-dns 结合使用，如下例所示，该示例注册 web.example.com，从 Let's Encrypt 检索 TLS 证书，并将其存储在 Secret 中。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/acme-http01-edit-in-place: "true"
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/tls-acme: "true"
  name: example
spec:
  rules:
  - host: web.example.com
    http:
      paths:
      - backend:
          serviceName: example
          servicePort: 80
        path: /*
  tls:
  - hosts:
    - web.example.com
    secretName: example-tls

您也可以直接从 cert-manager CRD 请求证书，如下例所示。与上面一样，它将导致存储在 Kubernetes Secret 中的证书密钥对

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: example-com
  namespace: default
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt-staging
  commonName: example.com
  dnsNames:
  - www.example.com
  acme:
    config:
    - http01:
        ingressClass: nginx
      domains:
      - example.com
    - http01:
        ingress: my-ingress
      domains:
      - www.example.com