2020年的新设置

我们在第344集中讨论了2019年的changelog.com设置，并在去年的这篇文章中也进行了介绍。当时，changelog.com在Docker Swarm上运行，所有内容均由Terraform管理，最终结果更加简单更好是因为：

今年，我们用Linode Kubernetes Engine（LKE）取代了Docker Swarm和Terraform，从而进一步简化和改进了changelog.com的设置。新设置不仅更具凝聚力，而且部署速度提高了20％，changelog.com的恢复能力更强，平均恢复时间（MTTR）不到8分钟，并且通过单个窗格即可完成整个设置的交互玻璃：

我们将回答所有这些问题，并介绍有效的方法，可能会更好的方法以及changelog.com的后续内容。让我们从大的开始：

由于管理基础架构不会为Changelog带来任何价值，因此对企业而言。 Kubernetes使我们能够声明无状态＆amp;状态工作负载，Web流量入口，证书和其他较高级别的概念，而不是服务器，负载平衡器和其他类似的较低级别的概念。归根结底，只要发生以下情况，我们就不会在意事情的发生：在每次提交时自动部署零停机时间，每天备份，在实际服务器消失时将中断降到最低等。Kubernetes使此操作变得容易。

让我们以一个特定的示例进行扩展：续订TLS证书带来了哪些业务价值？是的，我们提供的所有Web请求都必须得到保护，并且SSL证书必须有效，但是为什么我们要花些精力来更新它？

也许您的IaaS提供商已经为您管理SSL，但这是否意味着您被迫使用同一提供商的CDN服务？还是您的CDN提供程序管理一个证书，而IaaS提供程序管理另一个证书？

就我们而言，即使我们的CDN合作伙伴Fastly可以为我们管理Let's Encrypt（LE）证书，我们也需要弄清楚如何在我们的Linode NodeBalancer（又称负载均衡器）中对其进行更新。我们很难学到这一点，但是，如果快速管理某个域的LE证书，则无法为该域配置其他LE供应商。我们的负载均衡器也需要TLS证书，如果我们通过“快速”使用LE，则无法获得负载均衡器的LE证书。根据我们的经验，这是一个非常具体的示例，它显示了可能占用时间和时间的情况类型。高价值工作的努力。

在我们的Linode Kubernetes Engine设置中，cert-manager负责管理我们所有域的证书，并通过一项工作使它们保持快速同步。如果我们需要检查所有证书的状态，则可以从前面提到的同一窗格中进行检查：

单个Linode CLI命令为我们提供了一个托管的Kubernetes集群，随后还有一些命令使我们可以运行changelog.com及其所有相关服务，包括DNS，TLS和Amp。 CDN集成。我们不再提供负载平衡器或配置DNS；我们只需描述我们需要的资源，Kubernetes即可实现。

是的，我们需要安装其他组件，例如ingress-nginx，cert-manager，postgres-operator和其他一些组件，但是一旦完成，我们就可以使用更高级别的资源，例如PostgreSQL集群，加密证书和入口处理负载均衡器配置。

我是否提到过Kubernetes是托管的？这意味着将处理更新，并且请求数量的节点将始终保持运行。如果删除了运行Kubernetes节点的其中一台虚拟机，则几分钟后将自动重新创建该虚拟机，并且应在该虚拟机上运行的所有内容都将被还原。这改变了从IaaS供应商运行所需的会话并收敛到所需状态到Kubernetes的对话，它将在10分钟内自动修复所有问题。

我们坚信，近年来您已经多次听说过“生产Kubernetes”。也许您甚至尝试了一些示例，并通过Kind或k3sup在本地计算机上运行它。对于绝大多数人来说，开始很容易，但是在Kubernetes上运行生产却很困难。许多新手并没有完全完成迁移。即使Monzo和Zalando在制作故事中分享Kubernetes多年了，也并没有使您更轻松。

我们可以考虑帮助您的Kubernetes生产过程的最佳方法是使所有代码可用，包括使我们今天处于今天的所有提交历史。如果您花时间探索过去的提交，您甚至会找到与我们的技术合作伙伴进行公开讨论的链接，从而导致Linode Kubernetes Engine（LKE）以及其他相关领域（例如kube-prometheus＆amp;快速cli。

Changelog.com证明了在Kubernetes上的生产环境上运行非常简单，并且运行良好。即使您的团队很小，可用于基础架构相关工作的时间也很有限，您也可以使用我们的方法开始工作，然后在需要时进行修改和适应。如果changelog.com已在此设置上运行且具有更高的可用性，响应能力和弹性，那么您的生产Web应用程序也可以。

当我与希拉里（Hillary）和安德鲁（Hampary）见面时，一切始于KubeCon + CloudNativeCon North America 2019（还记得＃374和＃375？）来自Linode的Mike。他们让我可以尽早使用Linode Kubernetes引擎（LKE）和一个Linode CLI命令，之后，我们在新泽西州的纽瓦克运行了我们的第一个三节点Kubernetes集群。

顺便说一句，如果您想在新的Linode新产品上市之前就尽早使用它们并提供有价值的反馈意见来影响产品发展方向，那么您也可以加入Linode Green Light。

监控有些棘手，因为我们必须弄清楚Prometheus＆amp; amp;的方法。在Kubernetes中正确使用Grafana。关于如何启动和运行它，存在一些相互矛盾的建议，并且文档对我们不起作用，因此我们贡献了我们的解决方案。在所有可用的方法中，我们选择了kube-prometheus运算符，该运算符使我们可以开箱即用地洞悉Kubernetes和系统指标。我们尚未将kube-prometheus与其他服务集成，例如ingress-nginx，PostgreSQL，Phoenix等。

一旦我们安装了grafana.changelog.com并且所有基线组件都可以很好地协同工作，我们便着手建立了changelog.com的静态实例。这将使我们清楚地了解简单的changelog.com应用在各种情况下（升级，节点丢失等）如何工作。由此产生的伪像是暂时的-一块垫脚石-使事情变得简单，并允许我们观察各种失败情况下的Web请求延迟和错误率。我们的发现使我们对LKE充满信心，并通过分享我们的Linode客户故事为它开了绿灯。

我们选择了Crunchy Data PostgreSQL Operator在K8S上运行生产PostgreSQL。正如我们在Docker上运行PostgreSQL多年没有问题一样，从我们的角度来看，通过Crunchy在K8S上运行PostgreSQL是一个更好的体验。即使我们尚未充分利用Crunchy PostgreSQL的所有功能，我们也对结果感到满意。

对于零停机时间自动应用程序更新，我们选择了Keel。 CircleCI继续构建，测试和测试将容器映像发布到DockerHub。我们为2019年的安装方案做出的决定是保持CI与A生产得到回报：我们无需在工作流程的这一部分进行任何更改。我们可以在Kubernetes的基础上构建新的工作流程的后半部分，同时继续运行现有的Docker Swarm。在新的工作流程中，当changelog.com容器映像更新时，DockerHub将一个webhook事件发送给Keel，这只是LKE中运行的另一个部署。为响应此事件，Keel更新了changelog.com部署，因为我们始终希望运行通过构建和测试的最新提交。测试阶段。是的，我们知道通过Flux或ArgoCD的GitOps是一种更全面，更强大的方法，但是在这种情况下，我们选择了最适合我们的方法。话虽如此，与@fwiles的讨论使我们认为我们应该尽快重新访问Flux。

在我们整个Kubernetes旅程的changelog.com上，Linode工程师Andrew总是在场以提供建议，修正或简单地提出一些想法。我们讨论了Kubernetes的升级并帮助他们提高了性能（首先实施linode-cli lke池回收将立即更新所有节点，这意味着大量的停机时间），启动了对LoadBalancer Services的PROXY协议支持，并谈到了持久卷性能。如果有一件事最能说明我们与安德鲁的互动，那就是这个高度详细的内容。关于如何在LKE上配置PROXY协议支持的清晰示例。

综上所述，我们从Docker Swarm迁移到Kubernetes所花费的时间大约是三周。这段时间中的大部分时间都花在试验和适应基线组件上，例如ingress-nginx，external-dns，cert-manager等。考虑到K8S生态系统被认为多么复杂，我想说一下我们的changelog.com迁移到LKE效果很好。

在LKE中仍有改进持久卷性能的空间。当我们禁用CDN时，为我们所有媒体提供服务的持久卷的磁盘利用率上升到100％，并在此测试方案的整个过程中一直保持在那里。尽管这种情况不太可能发生，但冷缓存将意味着所有媒体资产的高延迟。最糟糕的部分是，从VM本地磁盘提供相同文件的速度比持久卷的速度快44倍（267MB / s和6MB / s）。即使快速放置所有changelog.com介质，这也意味着高速缓存未命中对磁盘IO利用率和饱和：

在迁移过程中，我们为“加密”（LE）证书配置了HTTP验证。将DNS TTL设置为3600秒，将changelog.com DNS A记录更新为指向LKE之后，由于LE仍在使用先前缓存的changelog.com A记录进行验证，因此无法获得新证书。达到LE证书请求限制后，再加上我们没有更改外部DNS中默认的3600的DNS TTL，我们结束了大约30分钟的部分停机，直到A记录还原通过DNS网络传播。此后，我们已切换到LE的基于DNS的验证，并且现在使用通配符证书，但是迁移的这一方面无法正常运行。

Linode Kubernetes Engine（LKE）正常工作。与Linode的互动非常明显，我们迁移所需的所有改进均已及时交付，支持始终在响应之中，并且不断取得进步。谢谢Linode！

首先，我们仍在玩手动升级游戏。现在，我们使用LKE，我们希望自动化K8S升级，基准组件升级（ingress-nginx，cert-manager等）以及应用程序依赖项升级（Erlang＆amp; Elixir，PostgreSQL等）。我们知道这是一个艰巨的任务，但考虑到Kubernetes生态系统解锁的原始要素，现在已经可以实现。第一步是将现有的K8S v1.17升级到v1.18，以便我们在受支持的版本以及最近6个月中具有重要版本的所有其他组件上运行（例如cert-manager 1.0）因为我们开始使用它）。

我们非常想解决LKE上持续的容量受限性能问题。即使可以进行一些工作，我们也可以将所有媒体资产迁移到S3，但我们仍然必须应对PostgreSQL的性能以及高度依赖于磁盘性能的Prometheus。 Linode在2020年路线图上提供的托管数据库服务可能会解决PostgreSQL的性能，而Grafana Cloud可能是Prometheus的解决方案，但是所有这些方法似乎都通过摆脱LKE来解决潜在的LKE改进，这并不令人感到就像朝正确方向迈出的一步。顺便说一句，我想知道我们在Upbound的朋友-Jared＆amp; Dan👋🏻-是否会建议Rook为LKE上的持久卷合并本地SSD存储？ 🤔

我非常期待将我们的所有服务与Grafana＆amp;普罗米修斯（Prometheus）以及从去年起仍在TODO名单中的Loki。我们缺少许多可能突出改进领域的指标，以及我们根本不知道的制造问题。在LKE上与指标一起运行的集中日志记录非常好，尤其是因为这将使我们能够开始在应用程序之外派生更多业务，而该应用程序目前由PostgreSQL＆amp;长生不老药。虽然这种方法行之有效，但我知道我们可以做得更好，并将业务洞察力带入目前无法企及的方向。

我们要注意的另一件事是为仍在LKE之外运行的某些任务选择OpenFaaS，并且我们使用Ruby脚本。尽管我们可以将它们重写为Elixir，以便所有内容都可以在同一应用程序中运行，但将多年来运行良好的Ruby代码提升和转移到在OpenFaaS上运行的一个或多个函数中似乎更加容易。很好发现，提示在上面的视频中。 😉

与往常一样，我们的重点是稳步改善。我觉得我们在2020年交付的产品与以前相比有了很大的改进。我非常期待我们为2021年建立的基础，并与大家分享！

changelog.com的可用性SLO为4个9（99.99％），这意味着一年内停机时间仅超过50分钟。我们的2019年可用性SLI为3个9和6（99.96％），停机时间超过220分钟。 Docker服务配置错误是主要原因，但我们也有50分钟或一两分钟的微停机时间。

随着LKE的持续迁移，我们的2020年可用性SLI为4个9，目前停机时间为38分钟。大部分是由于我的DNS＆amp;在迁移到LKE期间，LE证书出现了严重错误，但是还有2个月的时间，今年我们的可用性SLI比上一个要好6倍。