在本文发表时，Kubernetes大约已经有6年的历史，在过去的两年里，它的受欢迎程度不断上升，成为最受欢迎的平台之一。今年，它成为第三大最受欢迎平台。如果你还没听说过Kubernetes，它是一个允许你运行和协调容器工作负载的平台。
容器最开始是一种Linux内核进程隔离构造，包含2007年的cgroups和2002年的namespaces。自LXC在2008年面世后，容器变得更为重要，谷歌也开发了自己内部的“在容器中运行一切”的机制，名为Borg。快进到2013年，Docker发布，彻底普及了容器。当时Mesos是编排容器的主要工具，然而它并没有被广泛采用。Kubernetes在2015年发布，并迅速成为容器编排的事实标准。
为了了解Kubernetes的流行度，我们来思考一些问题。开发人员最后一次就部署生产应用程序的方式达成一致是什么时候?你知道有多少开发者是按开箱即用的方式运行工具的?如今有多少云操作工程师不了解应用程序的工作原理?我们将在本文中探讨答案。
基础设施即YAML
从Puppet和Chef的世界来看，Kubernetes的一大转变就是从基础设施即代码转向为基础架构即YAML。Kubernetes中所有的资源，包括Pod、配置、部署、数据卷等，都可以简单地用YAML文件来表示。例如：
apiVersion:v1kind:Podmetadata:name:sitelabels:app:webspec:containers:-name:front-endimage:nginxports:-containerPort:80
通过这种表示形式，DevOps或SRE无需使用Python、Ruby或JavaScript等编程语言编写代码，即可更轻松且充分表达其工作负载。
将基础设施作为数据的其他好处包括：
GitOps或Git操作版本控制。通过这种方法，你可以将所有的Kubernetes YAML文件都保存在Git仓库下，这样你就可以精确地知道什么时候进行了更改，谁进行了更改，以及到底更改了什么。这使得整个组织更加透明，避免了成员需要到哪里去寻找所需内容的歧义，提高了效率。同时，只需合并一个拉取请求就可以更容易地自动对Kubernetes资源进行更改。
可伸缩性。将资源定义为YAML使群集操作员能够非常轻松地更改Kubernetes资源中的一个或两个数字来更改缩放行为。Kubernetes有Pod水平自动缩放控制器来帮助你确定一个特定部署需要拥有的最小和的Pod数量，以便能够处理低流量和高流量时间。例如，如果你正在运行的部署可能因为流量突然增加而需要更多的容量，你可以将maxReplicas从10改为20：
apiVersion:autoscaling/v2beta2kind:HorizontalPodAutoscalermetadata:name:myappnamespace:defaultspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:myapp-deploymentminReplicas:1maxReplicas:20metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50
安全和控制。YAML是验证在Kubernetes中部署了什么以及如何部署的好方法。例如，在安全性方面，其中一个主要关注点是工作负载是否以非root用户身份运行。我们可以利用conftest这样的工具，一个YAML/JSON验证器，加上Open Policy Agent这个策略验证器，来检查你的工作负载的SecurityContext是否允许容器以root身份运行。为此，用户可以使用一个简单的OPA rego策略表示，例如：
packagemaindeny[msg]{input.kind=Deploymentnotinput.spec.template.spec.securityContext.runAsNonRoot=truemsg=Containersmustnotrunasroot}
云提供商集成。科技行业的主要趋势之一是在公共云提供商中运行工作负载。在云提供商组件的帮助下，Kubernetes允许每个集群与它所运行的云提供商进行集成。例如，如果用户在AWS中的Kubernetes中运行应用程序，并希望该应用程序可以通过Service访问，云提供商可帮助自动创建一个LoadBalancer服务，该服务将自动配置一个Amazon Elastic Load Balancer，以将流量转发到应用程序Pod中。