有一段时间，Kubernetes和container似乎是Sitecore基础设施的未来。人们一度普遍认为Sitecore会放弃对App Services的支持。目前的想法是，Sitecore将在未来很长一段时间内支持应用服务，所以在构建或升级Sitecore环境时，一个常见的问题是，是选择Kubernetes还是应用服务。我认为这个问题的答案在很大程度上取决于你。以下是在评估未来的基础设施体系结构时应该考虑的一些问题。
您计划使用XP还是XM?
Sitecore XP和xDB的基础设施需求比XM的需求复杂得多。XP需要内容交付、内容管理、身份、处理、报告、搜索、收集、参考数据、营销自动化和营销自动化报告等角色。Sitecore XM只需要内容交付，内容管理和身份。如果你正在寻找更加无头的架构，将内容交付卸载到CDN(如Experience Edge)，你甚至可能不需要内容交付角色。
Kubernetes真正的亮点在于管理跨角色的部署和依赖关系。对于Sitecore XP，价值主张非常高。有大量的服务，管理它们如何一起部署提供了切实的好处。使用Sitecore XM，管理环境配置没有那么复杂。这仍然是一个好处，但它不那么引人注目了。
你决心使用Azure吗?
正如您所期望的那样，Azure应用程序服务仅在您在Azure上托管时可用。Kubernetes提供了更多的跨平台支持。Azure有自己的Kubernetes实现，但是你可以在任何支持Windows容器的云上的容器上运行Sitecore。这个电流包括AWS和GKE。
话虽如此，Sitecore仍然与微软和Azure保持着非常密切的关系，而且大多数客户的目标都是Azure Kubernetes服务，所以很多文档和支持都是为Azure量身定制的。尽管如此，采用Kubernetes会给你一些信心，如果需要，你可以转移到另一个供应商。在Kubernetes周围的生态系统中采用与云无关的工具来管理CI/CD (helm, Kudo)，日志记录和监控(Prometheus)限制了对Azure服务的直接依赖，尽管你通常可以配置它们来利用像App Insights这样的Azure工具来提供额外的好处。
但如果你不担心需要转移到不同的云提供商，利用Azure应用程序服务可能会很好地满足你的需求。
您是否有其他可以或将要在容器中运行的应用程序?
在Kubernetes上运行SOLR可能是采用Kubernetes的一个途径。一般来说，SOLR很难管理，如果您不知道自己在做什么，那么在VM上使用Zookeeper运行SOLR集群并不有趣。Kubernetes通过SOLR运营商和舵机图，使它更像一个配置驱动的事情。我仍然推荐解决方案，比如搜索Stax如果您没有管理SOLR环境的内部专业知识，更不用说管理Kubernetes集群了。
但是SOLR并不是Sitecore解决方案的唯一依赖项。近年来，微服务架构变得越来越流行，Kubernetes已经成为部署和管理微服务架构的首选方式。如果您的解决方案高度依赖于服务，那么为您的解决方案和服务使用一致的部署和配置方法将带来许多优势。
你有管理Kubernetes环境的专业知识吗?
如果您没有在生产环境中运行Kubernetes，那么您需要准备好让您的工程团队加快速度，以支持Kubernetes实现。即使在Azure中，AKS提供了Kubernetes特定的集成，比如应用程序洞察和Web应用程序防火墙，它们也倾向于在Kubernetes上下文中运行，所以你需要真正理解它们是如何集成到你的堆栈中的。
要准备好在生产环境中管理Kubernetes环境，请确保您的团队完全理解:
- 部署——App Services支持插槽来实现蓝绿部署，而Kubernetes更加健壮，支持蓝绿、金丝雀、斜坡甚至AB测试。
- 网络，安全和入口选项- Kubernetes可以很容易地将应用程序隐藏在环境的其余部分。暴露正确的部分，与入口控制器、密钥库、Web应用网关和前门一起工作，给你提供了大量的灵活性，但也有一个不错的学习曲线。
- 日志和监控——像Grafana和Prometheus这样的Kubernetes本地工具提供了集中的日志记录、可视化和监控。Azure提供挂钩，将它们连接到Log Analytics和Application Insights。确保您了解您的选项并正确配置是能够管理环境的关键。
- 灾难恢复-确保您了解在发生灾难时如何进行切换。当使用Kubernetes和App Services时，如何构建热、热、热、冷的DR架构将有其自身的细微差别(和成本影响)。
您的开发人员准备好采用容器了吗?
Kubernetes的学习曲线可能是采用Kubernetes的最大障碍。这就像学习一门全新的语言:Docker、Compose、KubeCtl、Kudo、Prometheus、Grafana、Operators、Helm、Charts，这些只是你需要熟练掌握的一些新术语。
克服这个学习曲线有很多好处，包括:
- 更快的本地环境设置——使用容器，启动和运行您的解决方案和环境通常只需要运行几个脚本。
- 你可以更容易地运行多个项目——如果你需要支持多个Sitecore实例和解决方案，能够运行一个解决方案，关闭它，然后运行另一个解决方案，这让它变得更容易。
- 复制上层环境—如果上层环境使用容器，则可以在本地运行这些映像，以便更快地进行调试和故障排除。
- 组合附加功能的能力——无需对Sitecore包进行逆向工程并找出如何正确部署它们，您只需使用多阶段构建就可以在创建映像时拉入所需的工件。许多开源模块都提供了这个选项，您可以使用这个策略来提高可重用性。
仅由于这些原因，您可能需要考虑本地环境设置，甚至使用Kubernetes在Dev或QA中运行容器。这可以让您在深入尝试在生产环境中运行容器和Kubernetes之前，快速了解容器和Kubernetes。
需要帮助做决定?
在Perficient，我们一直在磨练我们的方法来帮助我们的客户做出这个决定。通过发现研讨会来了解您的需求，通过架构研讨会来深入了解目标架构，我们可以确保您做出正确的决策，并了解下游的含义，包括托管和维护的成本差异。
