在撰写本文时，Kubernetes已有6年历史了，在过去的两年中，它的流行度不断提高，一直成为最受欢迎的平台之一。今年，它成为最受欢迎的第三大平台。如果您还没有听说过Kubernetes，那么它是一个平台，可以让您运行和协调容器工作负载。
容器最初是一个Linux内核进程隔离结构，其中包含2007年的cgroup和2002 年的命名空间。当LXC于2008年可用时，容器变得越来越重要，而Google开发了自己的内部“在容器中运行所有机制”，称为Borg。快进到2013年，Docker正式发布，并完全面向大众普及。当时，Mesos是编排容器的主要工具，但是，它并没有被广泛采用。Kubernetes于2015年发布，并迅速成为事实上的容器编排标准。
为了理解Kubernetes的流行，让我们考虑一些问题。开发人员最后一次可以在何时达成部署生产应用程序的方式？您知道有多少开发人员开箱即用地运行工具？如今有多少云运营工程师不了解应用程序如何工作？我们将在本文中探讨答案。
以YAML的基础架构
来自Puppet和Chef的世界，Kubernetes的重大转变之一就是从以代码为基础的基础架构过渡到以数据为基础的基础架构（特别是YAML）。Kubernetes中的所有资源，包括Pod，配置，部署，卷等，都可以简单地在YAML文件中表示。例如：
apiVersion: v1 |
这种表示形式使DevOps或站点可靠性工程师可以更轻松地完全表达其工作负载，而无需使用Python，Ruby或Javascript等编程语言编写代码。
将基础架构用作数据的其他好处包括：
- GitOps或Git Operations版本控制。使用这种方法，您可以将所有Kubernetes YAML文件保留在git存储库下，这使您可以准确地知道何时进行更改，由谁进行更改以及究竟进行了哪些更改。这样可以避免整个组织需要成员去哪里寻找所需内容的模棱两可，从而提高了整个组织的透明度并提高了效率。同时，通过合并合并请求，可以更轻松地自动更改Kubernetes资源。
- 可扩展性。将资源定义为YAML，使集群运营商可以非常轻松地更改Kubernetes资源中的一个或两个数字来更改缩放行为。Kubernetes具有水平Pod自动缩放器，可帮助您确定特定部署必须能够处理的最小和最大数量的Pod，才能处理低流量和高流量时间。例如，如果您正在运行的部署由于流量突然增加而可能需要更多容量，则可以maxReplicas从更改10为20：
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-deployment
minReplicas: 1
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
- 安全和控制。YAML是验证在Kubernetes中部署什么以及如何部署的好方法。例如，有关安全性的主要问题之一是您的工作负载是否以非root用户身份运行。我们可以使用conftest（一种YAML / JSON验证器）等工具以及Open Policy Agent（一种策略验证器）来检查您的工作负荷是否不允许容器作为根运行。为此，用户可以使用一个简单的开放策略代理 rego 这样的政策：
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}
- 云提供商集成。科技行业的主要趋势之一是在公共云提供商中运行工作负载。借助云提供商组件，Kubernetes允许每个群集与其运行的云提供商集成。例如，如果用户在AWS的Kubernetes中运行某个应用程序，并且希望通过服务可访问该应用程序，则云提供商将自动创建LoadBalancer服务，该服务将自动配置Amazon Elastic Load Balancer以将流量转发到应用程序容器。
可扩展性
Kubernetes具有很好的可扩展性，开发人员对此非常满意。有一组现有资源，例如Pod，Deployment 、、StatefulSetsSecrets ConfigMaps等。但是，用户和开发人员可以以“ 自定义资源定义”的形式添加更多资源。例如，如果我们想定义一个CronTab资源，我们可以用以下方法做到这一点：
apiVersion: apiextensions.k8s.io/v1 |
我们可以稍后使用以下内容创建CronTab资源：
apiVersion: "my.org/v1" |
Kubernetes可扩展性的另一种形式是，开发人员具有编写自己的Operators的能力，Operator是在Kubernetes集群中运行的，遵循控制循环模式的特定进程。Operator允许用户通过与Kubernetes API进行对话来自动管理CRD（自定义资源定义）。
该社区有几种工具，允许开发人员创建自己的Operator。这些工具之一是Operator Framework及其Operator SDK。SDK为开发人员提供了一个框架，使他们可以快速开始创建Operator。例如，您可以使用以下命令：
$ operator-sdk new my-operator --repo github.com/myuser/my-operator |
它将为您的操作员创建整个样板，包括YAML文件和Golang代码：
|____cmd |
然后你可以加入API和控制器：
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService |
最后构建发布operator 到容器注册表：
$ operator-sdk build your.container.registry/youruser/myapp-operator |
如果开发人员需要更多控制权，则可以修改Golang文件中的样板代码。例如，要修改控制器的详细信息，他们可以对controller.go文件进行更改。
另一个项目KUDO允许您仅使用声明性YAML文件来创建运算符。例如，对于Apache的Kafka的运营商会喜欢这个东西来定义这个功能，可以让用户安装上Kubernetes顶部的Kafka集群与zookeeper的命令：
$ kubectl kudo install zookeeper |
然后还使用另一个命令对其进行调整：
$ kubectl kudo install kafka --instance=my-kafka-name \ |
革新
在过去的几年中，Kubernetes每三四个月发布一次主要版本，这意味着每年都有三到四个主要版本。引入的新功能的数量并未减慢，最新版本的 30多种添加和更改证明了这一点。此外，Kubernetes项目Github活动表明，即使在这些困难时期，捐款也不会显示出放缓的迹象。
这些新功能使集群运营商在运行各种不同的工作负载时具有更大的灵活性。软件工程师还喜欢拥有更多控件，以将其应用程序直接部署到生产环境中。
社区
Kubernetes受欢迎的另一个重要方面是其强大的社区。首先，Kubernetes在2015年达到1.0版本时就捐赠给了与供应商无关的家庭：Cloud Native Computing Foundation。
随着项目的推进，还有各种各样的社区SIG（特殊兴趣小组）针对Kubernetes中的不同区域。他们不断添加新功能，并使其更加用户友好。
Cloud Native Foundation还组织了CloudNativeCon / KubeCon，截至撰写本文时，CloudNativeCon / KubeCon是世界上最大的开源活动。该活动通常每年举行三届，吸引了数千名希望改善Kubernetes及其生态系统以及利用每三个月发布的新功能的技术人员和专业人士。
此外，Cloud Native Foundation拥有一个技术监督委员会，与SIG一起，负责研究基金会在云原生生态系统中的新项目和现有项目。大多数项目都有助于增强Kubernetes的价值主张。
最后，我相信，如果没有社区的有意识的努力来互相包容并欢迎任何新来者，Kubernetes就不会取得成功。
未来
开发人员未来面临的主要挑战之一是如何将更多的精力放在代码的细节上，而不是代码运行所在的基础结构上。为此，无服务器正在成为应对这一挑战的领先架构范例之一。已经有非常高级的框架，例如Knative和OpenFaas，它们使用Kubernetes从开发人员那里提取基础架构。
我们在本文中对Kubernetes进行了简要介绍，但这只是冰山一角。用户可以利用更多资源，功能和配置。我们将继续看到增强或发展Kubernetes的新开源项目和技术，正如我们所提到的，贡献和社区无处不在。
HackerNews讨论:
Kubernetes变得越来越流行是因为：
1）解决了许多不同的通用基础结构级别的问题。2）越来越多的人正在使用容器。K8s可帮助您管理容器。3）与供应商无关。将k8s应用程序重新定位到其他集群很容易5）人们看到它越来越流行。6）它是开源的。7）帮助著名公司运行大型系统。8）人们认为履历表看起来不错，他们想在一家知名公司工作。9）一旦掌握了K8，就可以轻松解决大小问题。（请注意，我不是在谈论安装和管理集群。我是在谈论成为集群用户。）10）这引起争议，这意味着人们一直在谈论它。这给了K8的心灵共享。
我并不是说K8没有问题或不利之处。
1）自行安装和管理很痛苦。2）有很多东西要学习-特别是如果您不认为自己会使用其中的大部分功能。3）尽管文档已改进很多，但在某些地方仍然薄弱无方向。
我认为K8s越来越受欢迎，因为它的优点远远超过了缺点。
Kubernetes中的网络非常复杂。如果您是Google规模的公司，那么这种复杂和抽象很有意义。大多数都不具备Google规模，因此不需要这种级别的可扩展性。在进行诊断时，网络抽象的代价是复杂性。
如果您将Kubernetes视为新的Linux，这会更有意义：业界公认的共同基础，并且您可以在其之上构建其他抽象。
作为系统管理员，我喜欢k8s，因为它以标准化的方式解决了系统管理员的问题。诸如安全滚动部署，合并日志记录，活动性和就绪性探测等之类的事情。是的，还因为它是可重复的。它承担了我工作中所有无聊的任务，让我专注于更有意义的工作，例如仪表板和监控。
在使用K8S之前，要运行服务，您需要：-设置VM：及其依赖关系，工具链。如果您使用诸如具有镜像处理等本机组件的软件包之类的事件，则需要在VM上设置一些编译器-部署过程-负载均衡器-Systemd单元以自动重启它。设置内存限制等，所有这些都是在K8S中完成的。只要发布Dockerfile，就完成了。
这在开发人员和运营人员之间建立了通用的术语。运营细节从开发人员中隐藏，而开发细节（工作负载的详细信息）从运营工程师中隐藏。
Kubernetes之所以变得流行是因为它是对现有事物（如防火墙，虚拟ip，进程设置等）的不二之选。
昨天，当我看到一家由YC支持的招聘公司正在使用Kubernetes时，我认为这简直太疯狂了。绝对疯了。它已成为每家公司即使在不需要时也必须拥有的最新，最热门，最技术性的东西。
你们认为k8s正在做jvm以前在企业中所做的工作吗？即，如果一切都在jvm上，则构建分布式系统不需要容器。JVM更类似于Docker。K8s位于上方。
Kubernetes实际上并不是它所描述的任何东西。但是，它是云的操作系统。它是一组通用抽象层，可以位于任何IaaS提供程序之上并与之配合使用，并允许您通过标准化且易于使用的API使用基础结构即代码的概念来构建和部署应用程序。
Kubernetes是部署容器的一种方法。诸如Ansible / Salt / Puppet / Chef / etc之类的配置系统是部署容器的另一种方法。Kubernetes还可以动态扩展您的工作负载。但是Auto Scaling组（AWS术语）和GCP / Azure等效项也是如此。现实情况是99％的用户实际上并不需要Kubernetes。在大多数情况下，它带来了大量的复杂性，开销和不稳定性。