那么，您可能已经使用 Docker 容器有一段时间了，对吧？我知道旋转第一个容器的兴奋感就像魔法一样，但随后现实袭来。您开始注意到大规模管理容器很快就会成为物流噩梦。就在那时，Kubernetes（K8s）像经验丰富的项目经理一样进入房间，准备接管并简化一切。
在这篇文章中，我们将探讨独立容器的挑战、Kubernetes 如何帮助解决这些难题，以及何时（以及何时不）使用 Kubernetes。让我们开始吧！
如果您使用过独立容器，这些问题可能听起来很熟悉：
扩展独立容器就像玩打地鼠游戏。需要更多容量？手动启动另一个容器。哦，现在需要减少资源吗？手动关闭一些容器。这很快就会变得难以管理，尤其是当您遇到不可预测的流量峰值时。
您的容器如何相互通信？使用 Docker，您最终需要硬编码 IP 地址或设置一些感觉不自然的自定义网络。它笨重且难以维护。
当您的一个容器发生故障时会发生什么？独立的 Docker 本身并不能很好地处理。您需要监控一切并手动重新启动死容器。我们都知道周六凌晨 3 点这听起来有多有趣。
管理多容器应用程序变得很棘手。您需要协调它们的交互方式，处理它们的依赖关系，并确保它们在正确的时间启动。突然间，一个简单的应用程序就像一座纸牌屋。
Kubernetes，每个人都在谈论的容器编排器，可以自动化解决很多这些痛点。以下是它如何介入并挽救局面：
K8s 允许您根据 CPU 或内存使用情况定义扩展规则。您可以将其设置为在流量增加时自动启动更多容器，并在流量冷却时自动关闭它们。不再需要照顾孩子。
使用 Kubernetes，您的容器无需担心所有内容在哪里。 K8s 自动为服务分配 DNS 名称，以便您的容器可以顺利通信。
如果容器死亡，Kubernetes 会自动重新启动它。无需再在黎明时分从床上爬起来重新启动容器。 K8s 凭借其自我修复能力让您的应用程序平稳运行。
K8s 可以轻松处理复杂的多容器应用程序。它将它们组织成 Pod 和服务，从而可以轻松推出新版本、处理依赖关系并确保一切和谐运行。
所以，Kubernetes 听起来很棒，但它并不是解决所有问题的灵丹妙药。以下是 Kubernetes 是正确选择的五个案例：
如果您的应用程序遇到流量波动或者您需要动态自动调整资源，Kubernetes 的自动缩放功能将改变游戏规则。
如果您的应用程序由微服务组成，K8s 可以更轻松地管理多个服务并确保它们都能顺利通信。
需要一个即使部分故障也能保持弹性的应用程序吗？ Kubernetes 的自我修复功能可确保最短的停机时间。
如果您正在构建持续集成/持续部署管道，Kubernetes 的滚动更新和轻松回滚功能使其成为一个不错的选择。
如果您需要跨多个云提供商或您自己的数据中心管理工作负载，K8s 是理想的选择。它抽象了基础设施，以便您可以专注于您的应用程序。
但是 Kubernetes 并不总是必要的。以下是您可能想要避免复杂性的时候：
如果您的应用程序是一个小型的单容器服务，那么 Kubernetes 就有点大材小用了。为了简单起见，坚持使用 Docker。
如果您的团队是容器新手，那么直接跳入 Kubernetes 可能会令人畏惧。在深入 K8s 之前先掌握 Docker。
对于具有可预测的低流量、不需要持续扩展或故障转移的应用程序，Kubernetes 的开销是不值得的。
如果您正在启动一些临时项目，例如黑客马拉松项目或快速 POC，Kubernetes 可能会带来更多麻烦，而不是其价值。
K8s 可能会占用大量资源。如果您在 CPU、内存或存储空间有限的环境中工作，它可能会拖慢您的速度，而不是带来帮助。
当您需要可扩展性、弹性和流畅的容器编排时，Kubernetes 是一个很棒的工具。它通过自动化许多难以使用独立容器手动管理的复杂任务来减轻您肩上的负担。但是，不要仅仅因为它很流行就跳入其中。首先评估您的应用程序的需求。
如果您正在运行小型、可预测的应用程序，仅 Docker 可能就足够您使用了。但随着您的成长和扩展，Kubernetes 将成为您最好的朋友。
作为一名初级开发人员，我承认 Kubernetes 及其所有移动部件（Pod、服务、Ingress、自动缩放）的庞大范围可能令人难以承受。人们很容易迷失在它的功能中。但关键的教训是知道什么时候让事情变得简单，什么时候复杂是值得的。始终仔细权衡利弊，因为有时坚持使用独立容器可以节省大量时间和麻烦。
@piyushsachdeva
第四天视频
以上是CKA 全程课程日 为什么使用 Kubernetes？的详细内容。更多信息请关注PHP中文网其他相关文章！
