广告

DevOps成为“新的遗产”,更高阶的技能是SRE

  • 浏览(399)
  • 评论(0)
  • 译者:k8s

在这个领域,我常与工具制造者、创新者以及那些那些引领“无服务器”云应用的开发人员一起沟通。本次,我与Kelsey Hightower进行了交谈,他是谷歌云平台的开发引领者以及“Kubernetes Up and Running”的联合作者。为保证质量,以下访谈内容已被精编过。(译者注:黄色对话框为“我”,蓝色对话框为Kelsey Hightower)

Q: Kelsey ,你是 Google 开源容器编排系统 Kubernetes 的领导专家。 你是如何参与 Kubernetes 的,最初让你兴奋的是什么?

A: 我先说一点背景帮助大家理解,我以前做过财务、初创公司以及网络托管的系统管理员;曾经在一些数据中心工作过,我深知基础设施管理的痛点。我知道在容器出现之前,所有的维护类型 “一次写入,随处运行” 、虚拟化、配置管理等。

从一个系统管理员转变为开发人员,我知道怎么维护代码,也知道如何处理开发人员和运维人员之间的摩擦。

几年前,我在一家叫 “CoreOS” 做容器的公司工作,我在那得知了谷歌在2014在 DockerCon 发布了 Kubernetes 。他们发了新闻稿和一个 GitHub 仓库,但由于没有文档,你无法真正使用该项目。

所以,我撸起袖子,深挖代码,并发表了第一篇文章“如何在你的电脑上安装 Kubernetes 以及如何玩转它”。这篇文章在《HackerNews》排名第一,谷歌的新闻稿排名第二,这也就意味着刚才说的 CoreOS 在 Kubernetes 社区找到了自己的位置。

但当时的 CoreOS 并没有致力于 Kubernetes 的探究,所以我就在家努力。晚上,我就投入 bug 得修复和重构测试,组织代码。在我在台上讲述 Kubernetes 之前,我是 Kubernetes 的贡献者。

我对 Kubernetes 感到兴奋,因为我知道它能解决我过去遇到的问题。如果十年前我有这个,生活就会更好。所以我清楚地知道它可以改善人们工作的潜力,不是未来,而是现在!

Q: 那么 Kubernetes 究竟是如何改善人们的生活的呢?

A: 如果你把 Kubernetes 拟人化,它正在做最优秀的系统管理员做的事情。如果我给你一段代码,它可以很容易的被部署到对应的环境中。

特别是三、四年前,在我们拥有卷和所有这些网络技术之前,Kubernetes 的核心价值非常明显: 部署和管理容器。

你有一些容器和一些机器。使用 Kubernetes ,你可以使用非常小的配置片段运行这个容器,然后只观察它的运行。如果你毁坏了一台机器, Kubernetes 会将容器“移动”到不同的机器上。仅这一点就比大多数人正在做的事情更先进,即使是在今天。

Q: 三四年后的今天,Kubernetes 正在蚕食着容器的世界。但是同时也出现了“无服务器”技术,即服务功能,它解决了你刚才提到的一些基础设施管理问题。你对 FaaS 这个概念有什么看法?

A: 我第一次看到 FaaS 的想法是在 CGI 时代。编写一些 PHP 代码,把它放在 Apache 后面,然后 Apache 在收到 HTTP 请求时调用它。当时的限制是:没有可伸缩性,没有云的概念,也没有针对每种语言的整洁API 。

现在我们看到 Amazon 在 Lambda 上又做了一次尝试。他们说:“现在我们有了云,并且对这个弹性计算环境可以做什么有了一些了解,我们可以使用你的源代码并将其与云上其余部分——身份验证、数据库和 API 网关——一起运行了。“

Q: Lambda 和 CGI 脚本之间的另一个差异是成本模型。你认为功能性计费会改变游戏规则吗?

A: 我可以理解“每次调用付费”的成本模型。我几乎把它看作是进入云的更大部分的入口。

我个人认为 FaaS 是云的编程环境。作为云提供商,我有事件、消息队列和所有这些服务——这就是我提供的价值。我不会向你收取 SDK 的费用来利用这些服务。这就是为什么我不想在函数的成本上设置一个巨大的障碍。

Q: 实际上,你可以在 Kubernetes 集群上运行函数 Kubeless 。这对你来说是两全其美吗?

A: 如果你有一个基于 vm 的环境,那么在运行应用程序之前,你需要做大量的工作。

Kubernetes 用更好的抽象提高了标准——你只需给它一个容器,声明它应该如何运行,就可以了。但是 Kubernetes 仍然缺少一些关键的工作,比如由无服务器平台提供的工作。如果你想要这些工作,你可以通过安装类似于 Kubeless 的东西,在 Kubernetes 上对它们进行分层。

现在你可以上传代码片段(也称为函数)并运行它了。记住,所有这些 FaaS 产品会在盖子下建造一个容器。但是对于 Kubernetes ,它是开源的,你有充分的可见性和控制力。

FaaS 为某些用例提供了一个很好的抽象,但它并不适合所有人。Kubernetes 代表了当今大多数人能够理解和利用的最高抽象级别,特别是来自VMs的抽象级别。然后无服务器是上面的一个步骤。

如果你有一个 Kubernetes 集群,多年来我们已经看到它得到了广泛的采用,那么在其上运行 Lambda 这样的工作难道不是很好吗?所有必要的抽象都在那里,这使 Kubernetes 成为人们用来在其上创建新工作的基础。甚至 Serverless 。

Q: 长期来看,Kubernetes 会继续成为人们所熟悉的抽象,还是会有更多的人向上移动技术栈并在 FaaS 级别上构建?

A: 人们应该为他们正在做的事情使用正确的抽象。例如,当我编写谷歌 Assistant 集成时,我只想运行响应用户查询的代码片段。我可以在谷歌云函数上运行。我不需要容器,不需要数据量或存储,我只想作为一个函数运行它。它是该用例的完美抽象。

现在,如果我想做一些机器学习,使用 TensorFlow ,然后我想给我的代码一个完整的容器,它可以装载一个数据量,使用一个 GPU ,这并不是当今无服务器平台的最佳位置。所以我认为人们应该做的是使用最高层次的抽象。

Q: 我们也正在远离传统上与 DevOps 相关的技能。当我为这个系列采访 Simon Wardley 时,他说 DevOps 是“新的遗产”。这和你的经验相符吗?

A: 我同意 Simon 的观点。我认为在科技领域,每当我们学习一门学科,我们就给它起一个名字。“我是一名系统管理员。我做 DevOps 、我做 SRE ”。我们真正想说的是:在这一点上,我们要检查我们的纪律(discipline),给它起个名字。

应该发生的是,在我们给一个纪律命名之后,它应该融入到技术中去。你没有理由要做 40 年的 DevOps 。一旦我们得到正确的实践,它应该变成技术。

Kubernetes 出生在 DevOps 。即使它起源于谷歌,它也不一定是谷歌内部的克隆,它实际上很好地配合了 Docker 社区中正在发生的事情以及来自 Puppet 和 Chef 的人们试图实现的内容。

我们的意思是,如果你使用配置管理来部署应用程序, Kubernetes 将我们所学的知识作为一个集体社区,并将其设置为默认值,从而简化了部署。我们不再需要“编写”最佳实践。

如果一个节点失败了,戴上“ DevOps 帽子”,你会怎么做?你将自动将服务故障转移到另一台机器。这是 Kubernetes 所固有的。我们还通过 DevOps 实践了解到,你应该拥有集中的日志和监视等功能。

你知道吗,Kubernetes 已经打开了盒子。所以我们已经将许多 DevOps 实践应用到技术中。当我说到“我们”的时候,我指的是所有对 Kubernetes 项目做出贡献的人。

Q: 如果现在许多这些经典的 DevOps 规程都已经自动化了,那么人们应该掌握的下一个更高阶的技能是什么呢?

A: 站点可靠性工程(SRE)。现在你有了一个像 Kubernetes 这样的系统,甚至 Lambda 这样的系统——谁来监视监视者?即使云提供商正在做所有的事情,我也需要再次检查我的延迟是否在客户需要的地方?供应商会尽最大努力为我提供优质服务,但如果我的客户不同意,那么我就有问题了。

也许我使用了错误的库,或是无用的数据库。这就是你的 SRE 团队增加了很多价值的地方。谁在乎部署?一言为定。但是一旦部署完毕,我该如何调整客户的体验呢?

在这里,我们可以解放自己,处理待办事项。每个 DevOps 人员都有一个 backlog 。“总有一天我们会得到集中监控。总有一天我们会得到 CI/CD 。“好吧,现在你就可以开始反击。

Q: 你认为谷歌云平台使用 无服务器 和/或 Kubernetes 做了什么真正让你兴奋的事情?

A: 我们相信我们已经做了无服务器很长时间了。App Engine无疑代表了 AWS 自上次 re:Invent大会以来一直在说的:无服务器不只是 FaaS 。我们希望给人们带来无痛使用的体验,我们相信 App Engine 已经这样做了近8年。或者 BigQuery ——它是完全管理的,你只需运行查询并决定希望它运行得多快。

在计算方面,我们有云功能,通过添加对更多编程语言和特性的支持,我们将 FaaS 产品扩展到更广泛的开发人员社区,这些编程语言和特性让人们关注代码,而不是基础设施。

我们也有人们不一定知道的端到端解决方案:我们已经将云功能集成到对话流中。如果你想为谷歌助手构建自己的 Alexa 技能或谷歌操作,你可以使用对话流。在构建这些技能或操作时,所有 ML 培训都在浏览器中完成,在后台利用 GCP 。

这就是无服务器的思想和价值所在。你没有提供基础设施,但仍然在进行计算。因此,我们已经采用了无服务器的思想并将其真正接近于价值线。

Q: 读这篇文章的一些人现在会感到有点沮丧。他们可能会想:“ Kubernetes 和 serverless 太酷了,但我不会在日常工作中使用它们。”现在让我和我的组织参与进来是不是太晚了?“你能给这些人一些鼓励或建议吗?”

A: 我想说:“你已经具备了开始采用这些新技术的必要技能。”这些技能来自于管理 Kubernetes 之前的平台所付出的鲜血、汗水和眼泪。

他们比任何人都更了解自己的组织,所以无论技术环境如何变化,他们都是有价值的。

所以我们为“没有人能从你那里夺走它,没有服务器,没有云提供商”而自豪。

但你必须采取行动,展示你的价值。这就是我认为人们会犯错误的地方。他们走进来,想要进行一次 Kubernetes 式的对话,或者一次没有服务器的对话。他们应该做的是说“我的团队或组织想要做什么?”

也许你的开发人员抱怨说,在他们能够完成某些工作之前,必须先启动基础设施。告诉他们:“试试这个。上线你的代码并观察它的部署。“如果他们看到其中的价值,他们会支持你,支持你的经历。”然后有一天你可以告诉他们这是 Kubernetes ,或者 Lambda ,或者别的什么。

我们必须变得更有商业头脑,谈谈为什么我们想做一件不同的事情,而不是穿着 Kubernetes 的衬衫到处走,比如:“嘿,我去参加了一个会议,我认为我们现在应该做 Kubernetes。”

慢下来!你确切地知道业务问题在哪里。解决问题,然后再讨论 Kubernetes 。

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头