博客当企业享受增长并采取措施扩展其数据基础设施以应对增长时，变革是不可避免的。将数据仓库移到云端是一种强大而有效的扩展方式。当然，要优化升级带来的好处，您需要确保您的公司在云计算原生BI和分析平台上运行。在这个关键时刻，利用像Kubernetes和Docker这样的技术将促进和加速这种转变，为公司的进一步发展奠定基础。在本博客中，我们将了解Sisense for Cloud Data Team（以前的潜望镜数据）是如何从Heroku迁移到Kubernetes以在云中更好地运行，以及它如何为其他希望做出同样决定的公司提供有用的案例研究。从Heroku开始对于初创公司来说，Heroku是一个很棒的平台，因为它可以显著降低运营复杂性，使您能够专注于产品的运输。设置DevOps管道将应用程序从开发转移到生产很容易，而且不必在内部创建和维护连续的交付系统。它需要最少的基础设施才能使应用程序实时运行，而且很容易根据需要扩展应用程序。这是Sisense在Heroku上的架构：对于一个试图找到适合产品/市场的小团队来说，这是理想的，而团队则专注于构建和迭代其产品。但随着业务的发展，业务重心转移到扩展产品上，对Heroku的工作变得具有挑战性。为什么要离开赫罗库？随着企业的发展，其基础设施需求也会随之增长。赫罗库没法跟上他们。出现的一些新要求是：要求1：对服务器资源的细粒度控制Heroku提供4种不同类型的二极体：1x、2x、Perf M、Perf L。当你在规模工作时，被锁定在这四个选项中是非常有限的。为了经济地扩展应用程序的基础设施，云计算与大数据，必须对资源进行更精细的控制。要求2：后台进程的可靠调度Heroku调度器是一个非常简单的应用程序，提供对调度作业的频率（每天、每小时或10分钟）的有限控制。另外，很难控制版本。如果需要禁用作业，则作业定义将丢失。最糟糕的是，它是Heroku提供的"尽力而为"的服务——有时调度程序会跳过运行，这是预期的行为。要求3：没有数据库或后端微服务应面向互联网将postgres数据库移出Heroku可以更好地控制数据库。当需要超级用户权限和更好的安全性时，消费返利新模式，Heroku数据库就不能被防火墙保护，许多组织也不愿意让他们的数据库面向互联网。由于Heroku上的私有网络异常昂贵，一个解决方案是通过SSH隧道将数据库连接从Heroku发送到RDS（在VPC中）。这会增加操作开销并影响性能。如果您想使用pgbouncer等工具添加连接池，那么这与SSH隧道一起意味着另一层复杂性。每一个新的微服务都需要一个类似的网络设置，并且开销变得太大而难以管理。要求4：影响产品正常运行时间的最小外部依赖性对外部工具的任何依赖性都会为系统的性能创造一个上限。对于Heroku，这意味着可以为客户提供的正常运行时间保证设置上限Heroku也会影响发布进度。假设您一天要多次发送代码，所以当任何相关的Heroku组件的状态为黄色或红色时，就不发布代码。你可能会因为自己的错误而使Heroku中断更加严重，因此在Heroku事件期间发货是有风险的，即使对于看似无关的问题也是如此。这通常会导致延迟或跳过部署，这会降低您向客户发送产品的能力。要求5：基础设施的开发应考虑到可扩展性通过每一个定制和附加组件，您可以按照Heroku的方式构建基础设施。离开Heroku越早，将应用程序迁移到一个更可扩展的架构中就越容易，这样可以为您提供长期服务。这包括管理操作基础设施、监视、持续集成和部署管道等。从长远来看，不管理自己的核心操作总是会更加昂贵。所以，当Heroku为任何一个年轻的创业公司工作时，你实际上已经不再把它当作一个平台了，而谨慎的做法是在内部引入更多的基础设施，减少外部依赖和更直接的控制。为什么选择库伯内特斯？在决定将您的基础设施内部化之后，使用Kubernetes的决定相对容易一些。它是一个更基于容器的平台，提供了构建和管理云原生应用程序所需的灵活性。Kubernetes提供了一组优秀的工具来管理容器化应用程序。您可以将其视为管理容器的所需状态。以下是它的一些吸引人的特点：可伸缩性：通过增加分配的资源，可以轻松地扩展应用程序。通过增加控制器的副本数量，向外扩展同样容易。水平自动缩放可以根据某些资源自动缩放值。版本控制：应用程序的新版本在部署时创建一个新的副本集；在回归的情况下，可以很容易地将其回滚到旧版本版本。分发：滚动更新策略允许您一次发布应用程序的新版本n个pods，因此，在任何给定的时间。装载平衡：Kubernetes为容器提供自己的IP地址和一组容器的单一DNS名称，并且可以跨容器进行负载平衡。[更多信息]一旦您在内部测试了Kubernetes的服务，您就可以尝到它所提供的强大功能，这就明白了为什么Kubernetes正在迅速成为业界的黄金标准。迁移制定计划当时，Sisense的网络应用有50多个后台工作和大约一半的微服务。web应用程序是Rails，后台作业主要用ruby编写，带有rake接口。微服务都在golang，只有一个是Java的。webwebassets是使用yarn编译的。作为迁移的一部分，决定首先移动微服务。这将为活的KubNeNETs设置奠定基础，随后为开发和测试提供内部设置。首先移动微服务也降低了风险；路由到托管在不同域的微服务要比在web服务器前重做网络安全得多。还需要为DevOps选择一种技术；为Kubernetes建立一个构建和发布管道，商业大数据分析，并构建/存储docker映像。接下来，后台作业被移到新系统中，这样应用程序的ruby部分就可以被处理了。最后一步是迁移web应用程序。这将涉及到编译web资产、路由和服务http请求、构建和发布以及性能负载测试。这里的关键挑战是如何管理部署，并将实时流量从Heroku转移到Kubernetes。这是如何实现的？下面是Kubernetes的Sisense系统的一个可比较的架构，下面的部分讨论了在迁移过程中吸取的一些经验教训。第1课：反向代理应用程序可以成为管理HTTP请求的强大工具Heroku路由器返回错误代码，如H12（请求超时）、H15（空闲连接）和H18（服务器请求中断），这些代码有助于隐藏警报配置的复杂性。例如，我们的"请求超时过多"警报配置为：计数：1米（代码='H12'）>50。如果rails应用程序花费的时间超过30秒，那么Heroku路由器会在请求完成之前返回503响应。所以他们同意使用HAProxy应用来实现类似的功能。这里的关键挑战包括根据所需的行为设置正确的HTTP选项，以及在代理和负载平衡器之间调整客户端、请求和响应超时。这使得对请求的管理非常高效[更多信息]。在早期，云服务器租用，有一个HAProxy问题，请求将失败，因为代理应用程序无法解析服务器主机。结果发现，要使DNS解析正确进行，必须为代理应用程序配置运行状况检查[详细信息]。第2课：水平可伸缩的服务并不总是能跨不同的部署进行扩展在将第一个后台作业移到Kubernetes时，发生了一个并发错误，导致同一个作业多次运行。在Sisense的产品中，用户可以克隆仪表板，这样做可以为克隆过程安排一个后台工作。多个微服务实例正在获取作业，仪表板将被多次克隆。这个问题的根源是在内部开发的job runner中使用env变量来消除运行的作业和在发布过程中被杀死的作业之间的歧义。作业运行器线程将用特定的发布版本锁定作业，以确保它不会被其他线程获取。Kubernetes中的jobs的版本格式与Heroku上的不同。管理锁的版本控制逻辑变得过于复杂，因此最终切换到一个更干净的解决方案，使其版本不可知。这促使重新评估所有Heroku env变量。第3课：仔细选择并发资源的比率可以获得高度优化的设置迁移过程中的一个实验是在pod大小（CPU和内存）、Phusion Passenger应用程序进程的数量和每个进程的线程数之间取得适当的平衡。这在某种程度上取决于请求的类型。长时间运行的请求与短时间请求的行为不同。与IO绑定请求相比，CPU绑定请求的使用模式不同。代理应用程序的5xx错误类型，自助建站开发，以及