首先

使用容器可以带来很多优势，但增加容器环境也意味着被迫做出更困难的选择。我们需要考虑最适合我们情况的编配工具是什么，以及如何监控系统。 Docker是容器运行时的标准，但从容器编配工具中选择的选项有很多。这些领导者包括亚马逊的弹性容器服务和CNCF的Kubernetes。事实上，根据调查，83％的企业使用Kubernetes作为容器编配解决方案，而ECS仅占24％。

在这篇文章中，MetricFire的社区成员将分别介绍Kubernetes和AWSECS。从监控的角度来看，Grafana和Prometheus在Kubernetes上有很大优势，而Kubernetes支持的功能也很丰富，但是否应该继续讨论使用AWSECS是个问题。通过免费试用来访问平台，您可以尝试来自两种编排平台的指标。

本文将比较ECS与Kubernetes，并提供用户决定使用哪个的判断依据。

使用Kubernetes进行容器编排的好处

1. 完全开源且无需锁定

Kubernetes可以在本地或云端同时使用，无需重建容器编排策略。该软件完全开源，可以重新部署而无需支付传统的软件许可费用。您可以在公共云和私有云上运行Kubernetes集群，同时提供虚拟化层在公共资源和私有资源之间。

强大的灵活性 de

此外，如果存在能够产生利润的重要应用程序，Kubernetes是一个优秀的方法，它能满足高可用性要求，而不牺牲效率和可扩展性。使用Kubernetes可以精确控制工作负载的扩展方式，从而避免依赖ECS或其他容器服务的供应商锁定，当需要切换到更强大的平台时。

3. 高度可靠的能力：

由于Kubernetes旨在解决应用程序和基础架构的可用性问题，在部署容器到生产环境时是不可或缺的。

• ヘルスチェックと自己修復： Kubernetesは、ノードとコンテナーのヘルスを常にチェックすることで、コンテナー化されたアプリケーションを障害から保護します。 Kubernetesは、自己修復と自動置換も提供します。エラーが原因でコンテナまたはポッドがクラッシュした場合、Kubernetesが対応します。

 

トラフィックルーティングと負荷分散： トラフィックルーティングは適切なコンテナにリクエストを送信します。 Kubernetesには、複数のポッドに負荷を分散するためのロードバランサーも組み込まれているため、停止、ピーク時または偶発的なトラフィック、バッチ処理に対応するために、リソースをすばやく（再）分散できます。 外部ロードバランサーを使用することも可能です。

4. 工作量的可伸缩性：

Kubernetes以其在基础设施资源利用方面的高效性而闻名，并为实现扩展提供了几项便利功能。

• 水平インフラストラクチャのスケーリング：Kubernetesは個々のサーバーレベルで動作し、水平スケーリングを実装します。 新しいサーバーは簡単に追加または削除できます。

 

• 自動スケーリング：自動スケーリングを使用すると、CPU使用率またはその他のアプリケーション提供のメトリックに基づいて、実行中のコンテナーの数を自動的に変更できます。

 

• 手動スケーリング：コマンドまたはインターフェースを使用して、実行中のコンテナーの数を手動でスケーリングできます。

 

レプリケーションコントローラー：レプリケーションコントローラーは、クラスターで指定された数の同等のポッド（コンテナーのグループ）が実行されていることを確認します。 ポッドが多すぎる場合、ReplicationControllerは余分なポッドを終了します。 数が少なすぎると、より多くのポッドが開始されます。

展开设计:

容器化的主要好处之一是可以加快软件构建、测试和发布过程。Kubernetes是专为部署设计的，并提供一些方便的功能。

• 自動ロールアウトとロールバック： アプリの新しいバージョンをロールアウトしたり、構成を更新したりしますか？ Kubernetesは、ロールアウト中にコンテナの状態を監視しながら、ダウンタイムなしでそれを処理します。失敗した場合、自動的にロールバックします。

 

• カナリアデプロイメント： カナリアデプロイメントを使用すると、新しいデプロイメントをスケールアップすると同時に以前のデプロイメントをスケールダウンする前に、以前のバージョンと並行して新しいデプロイメントを本番環境でテストできます。

 

プログラミング言語とフレームワークのサポート：Kubernetesは、Java、Go、.Netなどの幅広いプログラミング言語とフレームワークをサポートしています。Kubernetesは、追加のプログラミング言語とフレームワークを維持している開発コミュニティからも多くのサポートを受けています。アプリケーションをコンテナで実行できる場合は、Kubernetesで正常に実行されるはずです。

6. 服务的发现可行性：

所有服务之间具备可预测的通信方式是重要的。然而，在Kubernetes中，由于容器会被创建和销毁多次，特定服务可能不会永久存在于特定位置。传统上，为了跟踪每个容器的位置，需要创建某种服务注册表或使应用逻辑适应此需求。在Kubernetes中，有原生服务的概念，它将Pod进行分组并简化了服务发现。Kubernetes为每个Pod提供了IP地址，并为Pod集中的每个集合分配了DNS名称，然后分流流量到集合中的Pod上进行负载均衡。这样创建了一个可以从容器级别抽象出服务发现的环境。

应用程序部署中的网络策略一部分。

默认情况下，Kubernetes中的所有Pod可以相互通信。集群管理员可以声明性地应用网络策略，并且这些策略可以限制对特定Pod或命名空间的访问。基本的网络策略限制可以通过指定Pod或命名空间的名称来应用于特定Pod的输出和输入功能。

长期解决方案：

考虑到Kubernetes的兴起，许多云服务提供商正在将研发重点从传统选项转移到扩展托管Kubernetes服务上。在制定长期IT战略时，请考虑使用Kubernetes。

正在进行中的开发：

Kubernetes发布初期，迅速获得了一个非常庞大且活跃的社区。目前，有大约2000名来自Fortune 500企业工作的工程师以及个人开发者和工程师为Github做出贡献，并且不断发布新功能。这个庞大且多样化的用户社区也参与其中，以回答问题并促进协作。

10. 充满活力的社区：

Kubernetes是一个活跃的社区，得到了像CNCF这样的主要企业和机构的支持，拥有广泛的模块化开源扩展功能。成千上万的开发者和多家大企业为Kubernetes做出了贡献，使其成为最适合最新软件基础设施的平台。这也意味着社区不仅积极合作，而且构建功能以轻松解决现代问题。

使用AWS弹性容器服务的好处

传统的ECS：

Amazon EC2在2015年发布，为在云中轻松运行Docker容器提供了解决方案。以前的ECS可以基本上控制容器的EC2计算选项。这种灵活性意味着可以选择运行工作负载的实例类型。此外，还可以连接其他AWS服务，用于监视和记录这些EC2实例上的活动。

Fargate ECS：
无服务器计算引擎

一方Fargate ECS是在2017年发布的一种无需管理基础EC2计算，而是直接运行容器的方法。相反，Fargate会自动计算所需的CPU和内存要求。通常，Fargate适用于需要快速运行工作负载，而不想被纠缠于计算基础选项的计算和理解的情况。

3. 适用于小型工作负载：

如果计划执行的是预计没有大规模扩展的小型工作负载，那么ECS是最合适的选择。 任务定义易于注册和理解。

4. 不是太复杂的应用程序架构

如果应用程序由少量微服务组成，并且在某种程度上可以独立运行，并且整体架构并不复杂（即外部依赖较少或可动部分过多），那么ECS从一开始就是一个很好的选择。

5. 更简单的学习曲线：比较起来更简单的学习过程：

Kubernetes拥有一个陡峭的学习曲线，这就是为什么与传统的Kubeadm或KOPS版本相比，Hosted Kubernetes的提供获得成功的主要原因。此外，使用诸如ECS Fargate之类的产品，您甚至不需要担心基础主机。 AWS会处理一切。

6. 更简便的监控和日志记录：

ECS会与AWSCloudwatch监控和日志无缝集成。如果在ECS上运行容器工作负载，则无需额外的工作即可配置容器工作负载的可见性。

Kubernetes的挑战之一

理解Kubernetes景观：

提供完整的端到端解决方案需要包含其他各种技术和服务，因此理解Kubernetes生态系统是开始的重要因素。然而，每个附加技术的状态都有很大差异。例如，一些解决方案可以追溯到Unix的黄金时代，而其他解决方案不到一年的时间，商业应用和支持都较少。因此，除了理解可以安全实施的组件之外，还需要理解每个组件如何适应更大的解决方案。虽然有大量相关的信息和文档，但它们分散且难以整理。结果，找到最适合特定任务的解决方案变得困难。即使在确定要使用的解决方案之后，也需要一个详细的计划来将其作为服务提供并持续管理。

理解功能和项目的区别：

任务不仅仅限于这个。虽然找到关于如何管理项目生命周期的建议可能会有所帮助，但无法解决在区分Kubernetes功能和Kubernetes社区项目时产生的混淆问题。像Kubernetes这样的开源技术的优势在于用户社区可以创建并共享创新的应用。但是，这个优势同时也可能带来混乱。特定利益团体可以开发添加到核心Kubernetes的功能，但其他独立项目则在核心之外。由个别开发者或供应商提供的项目可能还没有准备好用于生产环境。实际上，许多项目处于开发的不同阶段。（注：如果不在GitHub上，那就不是Kubernetes的官方功能。）

学习掌握超越Kubernetes的知识。

这种混乱的恶化完全是由于解决方案的复杂性。Kubernetes本身是经过精细设计的。然而，组织还想提供其他复杂解决方案，比如提供分布式数据存储服务。通过管理所有这些服务的组合，问题可能会进一步扩大。不仅需要精通Kubernetes，还需要熟练掌握作为端到端服务的一部分提供的所有内容。

管理Kubernetes很困难。

使用Kubernetes进行运营和管理是不同的。因为Kubernetes只能提供Kubernetes本身，所以对Kubernetes的管理主要是通过手动操作实施的。由于平台本身没有用于运行Kubernetes的功能，所以必须理解如何通过Kubernetes自身来运维资源，这并不是一件容易的事情。

如果要满足企业的需求，就需要加强Kubernetes的安全性，并将其与现有的基础设施集成。除了处理升级、补丁和其他基础设施特定的管理任务之外，还需要适当的知识、专业技能、流程和工具来有效地运营和扩展Kubernetes。考虑到要将Kubernetes作为服务提供给不同行业和不同用户，必须解决以下管理方面的挑战。

• 複数のKubernetesクラスターを管理するのは困難: 複数のKubernetesクラスターを管理すると、内部チームにさらにプレッシャーがかかり、多大な時間とリソースの投資が必要になります。

 

• Kubernetesの監視とトラブルシューティングは困難: 他の複雑なシステムと同様に、問題が発生する可能性があります。 Kubernetesを使用すると、大規模なテストができず、問題が発生した場合の修正が難しく、アップグレードを自動化できません。

 

大規模なサポートが難しい： 企業組織にとって、規模は非常に重要です。 しかし、すぐに使用できるKubernetesでスケールをサポートするのは困難です。 複数のクラスターのバージョン管理は時間がかかり、困難であり、特別なリソース計画が必要です。 さらに、プラットフォームを真にスケーリングするには、構成スクリプトを手動で実行する必要があります。

总结一下

尽管Kubernetes有一些缺点，但在容器编排竞争中仍然明显地处于领先地位，这已经变得非常清楚。说实话，Kubernetes显然是胜利者。Kubernetes已成为实际上的容器编排标准，各大小组织都投入了大量资源来采用它。

亚马逊ECS是一个不错的选择，但在许多情况下仍然不够。当使用适当的工具链时，采用Kubernetes不仅可以无缝进行，还可以真正实现云原生，为未来提供帮助。Kubernetes集群和部署的工作负载提供了许多简化可观测性的解决方案。如果您有任何监控和日志记录的需求，请随时联系MetricFire，我们将乐意帮助您。您可以预约视频通话演示或者免费试用。您也可以直接在客户支持的聊天框中与我们交流。