下载掌阅APP，畅读海量书库
立即打开
我们将从前端开始介绍我们的应用程序（由于完整的应用程序太大，在本书中不会全部介绍）。日志系统的前端是一个采用TypeScript实现的Node.js应用程序，该应用程序使用暴露在8080端口上的HTTP服务来处理 / api/* 路径的请求，并采用Redis作为后端来添加、删除或查询当前日志条目。应用程序可以使用代码中提供的Dockerfile来构建容器镜像，并将其推送到镜像仓库中。你可以在随后的YAML示例中替换该镜像名称。
通常来说，如何构建和维护容器镜像超出了本书的范围，但是有必要明确一些镜像构建和命名的最佳实践。一般来说，镜像的构建过程容易受到“供应链攻击”（supply-chain attack）。在这种攻击下，恶意用户将代码或二进制文件注入来自可信源的某些依赖项中，随后被构建到应用程序中。考虑到这类攻击的风险，当你构建镜像时，务必确保只基于那些知名且受信任的镜像源进行构建，这一点至关重要。或者，你也可以从头构建所有镜像。对于一些可以构建静态二进制文件的语言（如Go）来说，从头开始构建很容易，但是对于解释型语言（如Python、JavaScript或Ruby）来说，则要复杂得多。
还有一些与镜像命名相关的最佳实践。虽然同一个容器镜像在镜像仓库中的版本理论上是可变的，但是你还是应该将镜像的版本标签视为不可变。另外，将语义化版本（semantic version）和当前提交的SHA哈希进行组合的命名方式也是一种良好实践（例如，
v1.0.1-bfeda01f
）。如果你未指定一个镜像的版本，它将默认使用
latest
版本号。虽然这对于开发来说很方便，但是如果将它用于生产就不太明智了，因为每次创建新的镜像时，
latest
版本所对应的镜像都会发生变化。
我们的前端应用程序是无状态的，其状态完全由后端的Redis进行维护。所以我们可以在不影响请求流量的情况下任意地复制它。虽然我们的应用程序不太可能进行大规模的扩容，但最好还是运行至少两个副本，以便你可以应对单点故障或不停机部署新版本的应用程序。
在Kubernetes中，ReplicaSet是管理容器化应用副本的资源，然而直接使用ReplicaSet不是一个最佳实践，你应当使用Deployment资源来代替它。Deployment组合了ReplicaSet的副本复制功能、版本控制以及阶段式部署能力。通过Deployment，你可以使用Kubernetes的内置工具将应用程序更新到下一个版本。
示例应用程序的Kubernetes Deployment资源如下所示：
上述Deployment中有几点需要注意。首先，我们使用Label来标记Deployment及其创建的ReplicaSet和Pod。我们已将
app: frontend
标签添加到所有相关资源中，这样我们可以在一次请求中检查指定层的所有资源。你会发现我们在添加其他资源时，也会遵循相同的实践。
此外，我们在YAML中添加了许多注释。虽然它们并不会存储在服务器的Kubernetes资源中，但是就像代码中的注释一样，它们有助于指导初次查看此配置的人。
你还应该注意到，对于Deployment中的容器，我们同时指定了Request和Limit的资源请求参数，并将两者设为相同值。当运行应用程序时，Request参数是指在宿主机上需要预留的资源，Limit参数是指允许容器使用的最大资源。当你刚开始接触Deployment时，将Rquest和Limit的参数设为相同值将使应用程序的行为最可预测。这种可预测性是以降低资源利用率为代价的，因为将两者设为相同值会避免应用程序的过度调度或消耗过量的空闲资源，除非你非常细心地调整Request和Limit，否则将无法最大限度地提高资源利用率。随着你对Kubernetes资源模型越来越了解，你可能会考虑为应用程序分别配置Request和Limit，但是总的来说，大多数用户会发现牺牲资源利用率所带来的稳定性是值得的。
定义好Deployment资源之后，让我们将其提交到版本控制系统并部署到Kubernetes：
确保集群与源代码中的配置完全一致也是一种最佳实践。实现这一目标的最佳模式是采用GitOps，并且仅将源代码的特定分支通过CI/CD（持续集成/持续交付）自动化部署到生产环境，这样就保证了源代码和生产环境的一致。尽管完整的CI/CD流水线对一个简单的应用程序来说似乎有些多余，即便不考虑CI/CD带来的可靠性，其提供的自动化能力同样值得花时间去搭建。此外，对一个已经使用命令式部署的应用程序再进行CI/CD改造是相当困难的。
后续的章节中我们将会查看此应用程序的其他YAML文件（例如，ConfigMap以及秘密卷）和Pod的QoS（服务质量）。