关于Kubernetes 趋势和落地的专家讨论

关于Kubernetes 趋势和落地的专家讨论

关键要点Kubernetes 的受欢迎程度继续呈爆炸式增长，但伴随这种增长而来的是挑战和裂隙：包括文化转变、技术趋势和技术进步。

Kubernetes 上的软件开发生命周期 (SDLC) 和基于微服务的应用程序仍在不断发展，这可能是未来几年发生重大革新的地方。

在 Kubernetes 平台上采用 DevOps 实践比 SDLC 相对更成熟。然而，随着 GitOps 等新兴模式的出现，这也是一个预期的增长领域。

随着下一波微服务和更多有状态应用程序部署在基于 Kubernetes 的平台上，需要更多的运维可视化以及针对恶意应用程序（有意或无意）进行自我防御和自我修复的工具。

对于在生产中运行 Kubernetes 的用户，基于Kubernetes Operator 模式的本土工具已经出现，并将继续发展以解决工具间距（gaps）。

最近，云原生计算（CNCF）调查的头条新闻指出，“自 2016 年以来，生产环境中容器的使用增加了300%。”随着这种高速增长的趋势，用户面临的挑战不仅是个人的，而且是整个社区将面临的。InfoQ 最近采访了几位 Kubernetes 专家，讨论了该平台用户面临的主要动向和最重要的挑战。

小组成员：

KatieGamanji - CNCF 的生态系统倡导者

BrianGracely - Red Hat OpenShift 产品战略高级总监

WilliamJimenez - Rancher/Suse 的技术产品经理

QiKe - 微软 Azure 工程总监

SuhailPatel - Monzo 银行的高级工程师

SunilShah - Airbnb 工程经理

InfoQ：请您用两三句话谈谈您第一次接触 Kubernetes，您的第一反应，以及您是如何参与其中的？

KatieGamanji：对Kubernetes 功能的第一次探索是我尝试为现有应用程序引入更好的资源管理和自我修复功能时。当时，我不得不以“艰难的方式”安装 Kubernetes，包括为核心组件手动配置systemd 单元。从那之后，我已经配置、管理和维护了数十个托管在多个基础设施提供商上的与一系列不同的云原生技术集成的集群。

BrianGracely: Docker Swarm 和 Mesos/Marathon 已经存在，然后 Google 以奇怪的名字宣布了这个新项目。几个月后，KubeCon宣布（在 CNCF 之前），我想，“我们真的需要一个容器调度程序的整个事件吗？”只有在我听说过一家大型金融服务公司在v1.0 时代使用它后，我才认为它可能是真的。自 2016 年以来，我一直领导Red Hat 的 Kubernetes 平台 OpenShift的产品战略。我们与数千家跨私有和公共云部署 Kubernetes 的公司合作。

WilliamJimenez：我第一次接触 Kubernetes 是我在一家数字教育公司(Chegg) 领导一个 DevOps 现代化项目时。我们面对的是一个复杂的管理依赖的场景，这个场景的体量和脆弱性都在增加。容器化立即显示了效果，我们在AWS ECS 上进行了大量投资以进行容器编排，因此当 Kubernetes 出现时，我非常关注。当时，处理安全、CI/CD和工具化等使容器在快速发展的业务中可用的基本要素，已是很大的挑战，而Kubernetes试图解决的问题似乎过于高大上，与我们的现实脱节。所以事后看来，直到很久以后，当我开始在 Rancher Labs 工作并意识到 Kubernetes 可以变得平易近人时，我才真正关注它，让工程界重量级Google云以外的公司能从中看到真正的价值。

QiKe:Kubernetes和GKE对外公布时，我正在谷歌工作。我第一次接触GKE是为了评估在GKE上运行的应用程序的追踪。那时候还没有服务网格，所以不可能在不修改应用程序代码的情况下进行跨调用追踪。我也未料到几年后我会每天都在Kubernetes上工作。

SuhailPatel:Kubernetes 在 v1.0 的早期就被引入Monzo。我们可能就是布莱恩提到的金融服务公司！我最初接触Kubernete是在加入 Monzo 时，我看到这个出色的编排器非常适合微服务架构。我们使用Kubernetes 运行 1500 多项服务，涵盖银行运营的各个方面。

作为最终用户，我们一直在与云原生社区合作，改进项目并提供公开帖子，以及对运行Kubernetes、Prometheus、Envoy 等大规模生产系统的反馈。

SunilShah:那是在 2014 年，我开始在担任Mesosphere（与Apache Mesos项目结盟的创业公司）担任工程师一两周后。我的第一反应既恐惧又兴奋——当像谷歌这样的行业巨头发布一个免费且资金充足的产品来和你公司的核心产品竞争时，总是有点害怕！事实上，从另一个角度来看，他们进入这个领域是一个好兆头，表明我们正在做的事很有价值！

从那以后，Kubernetes 很明显地胜过了 Mesos，看到社区发展得如此迅速，真是令人惊讶。在 Yelp，我们的团队开始探索用Kubernetes 替换 Mesos 来处理新的工作负载。现在在Airbnb，我支撑着一个团队，该团队管理着数十个 Kubernetes 集群来运行我们几乎所有的在线工作负载，为来自世界各地的流量提供服务。

InfoQ：开发人员/架构师应该关注的三大 Kubernetes 趋势是什么？

Gamanji: 在过去几年中，Kubernetes 的使用率不断增长，根据 2020年CNCF的调查，Kubernetes 的采用率达到83%。有了一套稳定的核心功能，社区的重点就转移到增强开发体验和工作负载的轻量级执行。因此，需要继续探索的技术是GitOps、云原生门户和IDE，以及作为边缘平台的Kubernetes。

Gracely:让我们从那些让开发者不必关心容器或Kubernetes而只需专注于编写代码的工具开始（Buildpacks、s2i等）。有一套不错的工具让他们简单地开始（VSCode插件、红帽Code-Ready Containers、minikube、Katacoda）。而Knative正在致力于使开发更简单，不必关心运营。

在Kubernetes生命周期的五年多时间里，我们必须记住，大多数开发人员不会考虑pod或CRD，所以工具需要满足他们今天的学习曲线和业务目标。

诸如buildpacks和s2i等工具允许他们只需编写代码，这些工具将自动把代码和依赖关系转化成一个容器。

IDE插件和基于Web的IDE（VSCode、Code-Ready Containers等）不仅能够让他们快速入门，而且还提供有关Kubernetes 如何增强其部署的背景信息。

而像Knative这样的新功能允许他们使用这些容器，并将其应用于新的、事件驱动的应用程序。

Jimenez:首先，针对开发人员的宣传。工程界的大多数人实际上是开发者。虽然Kubernetes通常以IT现代化的故事开始，但这只是冰山一角。当开发者开始认识到它的价值时，采用才真正开始。我们需要更多的工具和语言来邀请开发者加入这个故事。

第二，云原生存储。Kubernetes一开始是作为无状态应用程序的解决方案，因为状态在分布式系统中是很难处理的。随着 Kubernetes 的日趋成熟，用户将对接下来的挑战感到越来越满意，并且投资回报率将非常有吸引力，不容错过。

最后，我们将看到Kubernetes无处不在。Kubernetes将成为一种存在于IT环境中（数据中心、边缘、嵌入式和物联网）符合我们期望的商品。因此，作为一个技术社区，我们释放了许多传统上用于使软件适应定制环境的资源。而且我们还需要一些工具来对接这种规模和范围的集群，平等对待所有的Kubernetes环境。

Ke:

1.多集群管理、跨集群网络和存储Kubernetes客户通常在云中的生产环境管理一个以上的集群。这有很多原因，有些是为了更小的爆炸半径，有些是为了区域性和地域性，有些是为了安全边界，有些是为了克服规模限制。而当他们的集群数量增加时，集群生命周期管理、配置管理、应用管理和所有集群的策略执行都变得费力且容易出错。

2.恶意（也许是无意）应用程序的自我防御和自我修复并非所有的应用程序都是以对Kubernetes基础设施友好的方式来编写的。作为一个受管理的Kubernetes服务，我们已经看到了许多案例，集群被应用程序的无意行为破坏到了不健康的状态。有时是由于大型集群上的DaemonSet对API服务器的查询或观察。有时是由于破坏性日志记录触发了操作系统磁盘上的IO节流并冻结了docker。如何配置你的Kubernetes集群，编排基础设施并设置监控，以防御来自集群内运行的应用程序的有意或无意的攻击。以及如何快速恢复。

3.DevOps工具不用说，Kubernetes的开发者体验需要更多的爱。清单文件提供了灵活性，但带来了复杂性和维护的痛苦。VSCode插件不仅能帮助开发者跳转，还能检测到不正确的缩进或错别字以提高生产力。此外，服务器端的dry-run和kubectl diff加入插件将是很棒的功能。

Patel:可靠地运行 Kubernetes 需要大量时间投入。各种供应商提供的不同价位的托管产品无处不在，这使得全球的工程师都可以使用Kubernetes。它并不是为大型云供应商或拥有大型平台团队的公司保留的。如果您需要自己托管它，有许多预配置和打包的发行版，只需几个命令就可以使用，其中沉淀了多年的经验。

我对Controllers和Operators特别兴奋。Controllers 允许您将自己的自定义控制循环引入 Kubernetes，Operators允许您引入“系统”并将它们紧密集成到Kubernetes 生命周期中。Kubernetes 可以成为您运行的所有其他系统的SRE。

Kubernetes将继续存在，并且是一个可以依赖的成熟的基础平台。它是在整个组织的部署、工具、监控、可观察性等方面引入统一做法的推动者。希望这也意味着更多的公司和工程师直接参与CNCF 生态系统并贡献他们的经验。

Shah: 我个人对三个方面的改进感到兴奋：Pod资源优化，有状态服务的协调，以及运维自动化。

首先，资源申请（CPU、内存等）是大多数用户不习惯考虑的事情。如果你在多租户环境中很好地运行Kubernetes，几乎必须设置合理的请求，以保护竞争状态下的运行服务。用工具来改善用户管理和关注资源的方式是令我们兴奋的事情。理想情况下，他们根本不需要考虑资源的问题，我们的系统就能解决这个问题！"。一些初创公司正在朝这个方向努力，但除了让用户可以观察到资源消耗外，还有改进的余地。

第二，有状态服务（想想Spark、Flink等）的整合比一年甚至两年前要好得多，但我们仍然看到分布式系统的开发者正在使用Kubernetes原语（如operators）作为协调其系统的一流方式。Spark现在有一个成熟的Kubernetes调度器，我很高兴能开始实验，因为它将为基础设施操作性方面提高一些效率。

第三，通过Stackpulse等系统实现的运行簿（或剧本）自动化仍处于起步阶段，但有很大的潜力。每个大型组织都在努力定期验证操作协议并将其转换为代码，这使我们能够在API 更改时自动进行测试。

InfoQ：在生产环境中部署 Kubernetes 的三大挑战是什么？

Gamanji:

云平台/基础设施团队面临的最大挑战是保持Kubernetes与最新版本的同步。许多组织选择将集群维护委托给云供应商，使用诸如EKS、GKE或AKS等管理服务。然而，除了这些情况之外，团队需要分配大比例的资源来执行集群升级。作为回应，Kubernetes社区已经将每年的发布次数从4次减少到3次，确保最终用户组织有足够的时间来消化和整合最新的功能。

Gracely: 许多公司将 Kubernetes 视为其现有过程的新版本，其中大部分不是为频繁更改的软件而设计的。安全性必须“左移”并成为软件供应链的一部分，并集成到 Kubernetes 平台中。

Jimenez: 与几年前相比，现在Kubernetes实施到生产环境要容易得多。诸如kubespray、kubeadm和RKE等自动化技术是对Kubernetes管理中容易出错的复杂领域的勇敢尝试。然而，我认为我们可以有把握地说，这些都是 "容易 "的问题，而且我们已经很好地解决了这些问题。我想知道的真正挑战是我们如何兑现Kubernetes 的承诺，这不仅仅是让它运行起来。

为了像在谷歌那样实现转变，Kubernetes需要在组织内获得大量的采用，否则它有可能成为另一个 "平台"，存在于许多其他平台的背景之下。Kubernetes 的强大之处在于可以快速开发软件，然后将其发布给大量用户。开发人员、安全研究人员和SRE需要被授权来拥抱Kubernetes的所有工具和功能，以实现这一愿景。我经常发现Kubernetes被孤立或限制在一个点上，即使一个组织花了这么多时间和精力来实施它，它也只能提供有限的价值。

Ke:可见性，可见性，可见性。作为托管 Kubernetes 的提供商，我们发现大多数客户升级是由于缺乏对集群中正在发生的事情的可见性。连接是否由SLB 重置？磁盘是否受到限制？扩容是否因配额不足而失败？Kubelet 是否因为内存或CPU 过度使用而挂起？云基础设施和 Kubernetes 集群上的性能、QoS和日志的可见性是问题关键原因。随着时间的推移，我们从这些指标中寻找线索并将其记录到问题检测器中，并针对常见问题开发了自动修复器以实现自我修复。这是我们自己管理大规集群的方式。

Patel: Kubernetes并没有让你摆脱需要开发自己的组件来抽象基础设施的问题。许多应用工程师不关心/不愿意关心Kubernetes是如何工作的，所以在公司内部进行整合以利用所有优势是很重要的。Kubernetes提升了基础设施团队处理的抽象单元，并提供了一套丰富的协调功能，你不需要自己构建。

运行你自己的集群需要时间和精力。我看到的一个常见的困难点是建设只支持一个或两个集群的支持和工具（即一个开发集群和一个生产集群）。相反，像对待牛一样对待集群，并有能力无缝启动新的集群，这是一个很好的前期时间投资，以方便测试新的功能和流程。

Shah:在我看来，最大的挑战与Kubernetes的普及有关。首先，Kubernetes的发展速度很快! 我们经常感觉到，我们只是为了跟上Kubernetes的每次升级而奔波。在像Airbnb这样规模的组织中，我们有许多补丁和自定义集成，需要对每个新版本进行细致的测试。自动化在这方面有帮助，但它本身仍是一项全心全意投入的工作。

其次，Kubernetes在工程社区中被誉为管理云资源的事实方式，有时会导致团队低估了运行一个可生产的集群所需的努力。这有时会适得其反，团队最终没有将时间投入到自动化或与大型企业所需的其他基础设施系统的集成，如成本投入或可观察性。即使有供应商管理的解决方案，当你有一个复杂的标签分类法时，这也不是免费的。

最后，在一个大型工程组织中运行Kubernetes，需要对我们的团队，即 "Kubernetes专家"，提供大量支持。我们经常被叫去帮助处理一些基本的操作（例如，重启服务），这些操作大多数工程师知道如何在传统的Linux环境中操作，但在Kubernetes上没有信心或不熟悉。更好的开发者工具可以帮助我们，但这需要与有潜在危险的命令风险相平衡。

总结

小组成员谈论了他们与Kubernetes的第一次接触，并讨论了该平台面临的主要趋势和挑战，特别是在生产中。从保持最新的版本部署到需要更多的端到端可见性，特别是在服务管理方面，有各种各样的操作挑战。甚至软件开发生命周期（SDLC）也可以在该平台上得到改善，它需要 "左移 "以适应云原生世界的安全。小组成员讨论了正在进行的弥补一些差距的努力。