作者:Janakiram MSV 译者:殷龙飞 原文地址:https://thenewstack.io/how-to-map-cloud-native-workloads-to-kubernetes-controllers/

Kubernetes 不仅仅是一个容器管理工具。它是一个平台,旨在处理包装在任意数量的容器和组合中的各种工作负载。Kubernetes内置了多个控制器,可映射到云原生架构的各个层。

DevOps工程师可以将Kubernetes控制器视为指示团队运行的各种工作负载的基础架构需求的手段。他们可以通过声明方法定义所需的配置状态。例如,容器/pod作为ReplicationController的一部分部署保证始终可用。打包为DaemonSet的容器保证在集群的每个节点上运行。声明式的方法使DevOps团队能够利用代码控制基础架构。下面讨论的一些部署模式遵循不可变基础结构的原则,其中每个新的部署都会导致原子部署。

DevOps工程师可以通过声明方法定义所需的配置状态——每个工作负载映射到控制器。

了解云原生用例

Kubernetes的控制平面不断跟踪部署,以确保它们符合DevOps定义的所需配置状态。

Kubernetes的基本部署单位是一个pod。它是Kubernetes的基本构建块,是Kubernetes对象模型中最小和最简单的单元。pod表示集群上正在运行的进程。无论服务是有状态的还是无状态的,它总是打包并部署为pod。

控制器可以在集群中创建和管理多个pod,处理在集群范围内提供自我修复功能的副本。例如,如果节点发生故障,控制器可能会通过在不同节点上安排相同的pod用来自动替换该故障pod。

Kubernetes配有多个控制器,可以处理所需的pod状态。如ReplicationController、Deployment、DaemonSet和StatefulSet控制器。Kubernetes控制器使用提供的pod模板,来创建其负责pod的所需状态。与其他Kubernetes对象一样,Pod在YAML文件中定义并提交给控制平面。

在Kubernetes中运行云原生应用程序时,运维人员需要了解控制器解决的用例,以充分利用平台的特性。这有助于他们定义和维护应用程序的所需配置状态。

上一节中介绍的每种模式都映射到特定的Kubernetes控制器,这些控制器允许对Kubernetes的工作负载进行