为什么说Kubernetes是新的应用服务器？【多图】

在容器流行起来之前，应用服务器提供了一些非功能性需求(NFR，non-functional requirement)，比如安全性、隔离性、容错、配置管理等等。打个比方，应用服务器和应用之间的关系就像 CD 播放器和 CD 之间的关系一样。

作为开发人员，你应该遵循预定义的标准并按照特定的格式分发应用，而应用服务器会“执行”你的应用并带来一些额外的功能，这些功能因服务器“品牌”的差异而有所不同。

与 CD 播放器的类比方式相似，随着容器的流行，容器镜像成为了新的 CD 格式。实际上，容器镜像仅仅是用来分发容器的格式。

容器的真正收益在你需要为应用添加企业级功能时才体现出来。为容器化的应用提供这些功能的最佳方式就是使用 Kubernetes 作为它们的平台。另外，Kubernetes 平台还为其他项目提供了很棒的基础实施，这些项目包括 Red Hat OpenShift、Istio 以及 Apache OpenWhisk，基于这些基础设施能够更容易的构建和部署健壮的生产级质量的应用。

接下来，我们探讨九个这样的功能：

1. 服务发现

服务发现指的是确定如何连接服务的过程。要获得容器以及云原生应用的很多收益，我们需要将配置从容器镜像中移除出去，这样的话，我们就能把相同的容器镜像应用到所有的环境中。将配置提取到应用外部是 12 要素应用的核心原则之一。服务发现是从运行时环境中获取配置信息的方式之一，这样能够避免将其硬编码到应用之中。Kubernetes 自带了服务发现。Kubernetes 还提供了 ConfigMaps 和 [Secrets] (https://kubernetes.io/docs/concepts/configuration/secret/) 用来将配置从应用容器中移除。在运行时环境中，如果要连接数据库这样的服务，我们会存储凭证信息，Secrets 解决了一些这方面所面临的挑战。借助 Kubernetes，我们无需使用外部的服务器或框架。

2. 基本调用

容器中的应用可以通过 Ingress 进行访问，也就是从外部世界路由到你所暴露的服务。OpenShift 提供了基于 HAProxy 的 route objects，它具有各项功能和负载均衡策略。你可以使用路由功能进行轮流部署。这可以作为一些非常复杂的 CI/CD 策略的基础。参见下文的“6. 构建和部署管道”。

如果你想运行一次性的任务，比如一个批处理或者只是使用集群来计算一个结果(比如计算 Pi 的位数)，那该怎么办呢?针对这种场景，Kubernetes 提供了 job objects。同时还有一个 cron job，能够管理基于时间的任务。

3. 弹性

在 Kubernetes 中，弹性(elasticity)是通过 ReplicaSets(它过去被称为 Replication Controllers)解决的。与面向 Kubernetes 的大多数配置类似，ReplicaSet 是一种协调所需状态的方式：你告诉 Kubernetes，系统应该处于各种状态，Kubernetes 就能知道如何达到该状态。在任意时间，ReplicaSet 都能控制副本的数量或应用程序精确的实例数量。

但是，如果你所构建的服务受欢迎程度超出了预先的规划，计算资源耗尽了该怎么办呢?你可以借助 Kubernetes Horizontal Pod Autoscaler，它会基于观测到的 CPU 利用率(或所支持的自定义指标，以及应用提供的指标)扩展 pod 的数量。

4. 日志

因为 Kubernetes 集群能够运行容器化应用的多个副本，所以将这些日志聚合起来，以便于在同一个地方进行查看就变得非常重要了。同时，为了利用自动扩展(以及其他云原生应用的功能)所带来的收益，容器应该是不可变的。所以，我们应该将日志存储在容器之外，这样它们才能跨运行时持久化。OpenShift 允许我们部署 EFK 技术栈来聚合来自主机和应用的日志，即便这些日志来自多个容器甚至已删除的 pod 均是可以的。

EFK 技术栈的组成如下所示：

• Elasticsearch(ES)，存储日志内容的对象存储;
• Fluentd，从节点收集日志并将其发送至 Elasticsearch
• Kibana，针对 Elasticsearch 的 Web UI。

5. 监控

尽管日志和监控看上去解决的是相同的问题，但是它们之间是不同的。监控是观察、检查、通常还有告警以及记录，而日志则只有记录。

Prometheus 是一个开源的监控系统，它包含了时序数据库。它可以用来存储和查询指标、告警，并使用可视化的方式查看系统内部的运行状况。Prometheus 可能是监控 Kubernetes 集群方面最流行的可选方案。

6. 构建和部署管道

对于你的应用来说，CI/CD(持续集成 / 持续交付)并不是“必备”的要求。但是，CI/CD 通常被认为是成功软件开发和 DevOps 实践的支柱。如果没有经过 CI/CD 管道的话，软件不应该发布到生产环境中。Jez Humble 和 David Farley 合著的《持续交付：发布可靠软件的系统方法》中是这样描述 CD 的：“持续交付能够将各种类型的变更发布到生产环境中，包括新特性、配置变化、缺陷修正以及体验性的功能，或者说以可持续的方式将这些变更安全且快速地交到用户的手里”。

7. 适应性

Kubernetes 为集群本身提供了适应性(resilience)方案，它还提供了 PersistentVolumes 来支持卷(volume)的副本，从而帮助应用实现适应性。Kubernetes 的 ReplicationControllers/ 部署能够确保指定数量的 pod 副本在整个集群中始终正常运行，它会自动处理任何可能出现的节点故障。

结合适应性，容错能够作为一种有效的方式来处理用户对于可靠性和可用性的关切。运行在 Kubernetes 上的应用还可以通过 Istio 的重试规则、断路器和池弹射(pool ejection，即移除掉出现故障的容器——译注)来实现容错。

8. 认证

在 Kubernetes 中，认证可以通过 Istio 的 mutual TLS 认证来实现，它致力于增强微服务及其通信的安全性，而无需服务代码的变更。它会负责：

为每个服务提供一个代表其角色的强标识(identity)，从而允许它能够跨集群和云进行互操作;

保护服务与服务之间的通信，以及终端用户与服务之间的通信;

提供 key 管理系统，自动化 key 和证书生成、分发、轮换和撤销。

另外，值得一提的是，我们还可以在 Kubernetes/OpenShift 集群中运行 Keycloak 以提供认证和授权。Keycloak 是 Red Hat Single Sign-on 的上游产品。

9. 跟踪

基于 Istio 的应用可以配置为使用 Zipkin 或 Jaeger 收集跟踪的 span。不管使用什么语言、框架或平台来构建应用，Istio 都能支持分布式跟踪。