mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
translated
This commit is contained in:
geekpi
parent
d0f45bc755
commit
3a5b6761ce
@ -1,69 +0,0 @@
|
||||
[#]: subject: "Can Kubernetes help solve automation challenges?"
|
||||
[#]: via: "https://opensource.com/article/22/10/kubernetes-solve-automation-challenges"
|
||||
[#]: author: "Rom Adams https://opensource.com/users/romdalf"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "geekpi"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Can Kubernetes help solve automation challenges?
|
||||
======
|
||||
Automation at the organization level has been an elusive goal, but Kubernetes might be able to change all that.
|
||||
|
||||
I started my automation journey when I adopted Gentoo Linux as my primary operating system in 2002. Twenty years later, automation is not yet a done deal. When I meet with customers and partners, they share automation wins within teams, but they also describe the challenges to achieving similar success at an organizational level.
|
||||
|
||||
Most IT organizations have the ability to provision a virtual machine end to end, reducing what used to be a four-week lead time to just five minutes. That level of automation is itself a complex workflow, requiring networking (IP address management, DNS, proxy, networking zones, and so on), identity access management, [hypervisor][2], storage, backup, updating the operating system, applying the latest configuration files, monitoring, security and hardening, and compliance benchmarking. Wow!
|
||||
|
||||
It's not easy to address the business need for high velocity, scaling, and on-demand automation. For instance, consider the classic webshop or an online government service to file tax returns. The workload has well-defined peaks that need to be absorbed.
|
||||
|
||||
A common approach for handling such a load is having an oversized server farm, ready to be used by a specialized team of IT professionals, monitoring the seasonal influx of customers or citizens. Everybody wants a just-in-time deployment of an entire stack. They want infrastructure running workloads within the context of a hybrid cloud scenario, using the model of "build-consume-trash" to optimize costs while benefiting from infinite elasticity.
|
||||
|
||||
In other words, everybody wants the utopian "cloud experience."
|
||||
|
||||
### Can the cloud really deliver?
|
||||
|
||||
All is not lost, thanks mainly to the way [Kubernetes][3] has been designed. The exponential adoption of Kubernetes fuels innovation, displacing standard legacy practices for managing platforms and applications. Kubernetes requires the use of Everything-as-Code (EaC) to define the desired state of all resources, from simple compute nodes to TLS certificates. Kubernetes compels the use of three major design constructs:
|
||||
|
||||
* A standard interface to reduce integration friction between internal and external components
|
||||
* An API-first and API-only approach to standardize the CRUD (Create, Read, Update, Delete) operations of all its components
|
||||
* Use of [YAML][4] as a common language to define all desired states of these components in a simple and readable way
|
||||
|
||||
These three key components are essentially the same requirements for choosing an automation platform, at least if you want to ease adoption by cross-functional teams. This also blurs the separation of duties between teams, helping to improve collaboration across silos, which is a good thing!
|
||||
|
||||
As a matter of fact, customers and partners adopting Kubernetes are ramping up to a state of hyper-automation. Kubernetes organically drives teams to adopt multiple [DevOps foundations and practices][5]—like EaC, [version control with Git][6], peer reviews, [documentation as code][7]—and encourages cross-functional collaboration. These practices help mature a team's automation skills, and they help a team get a good start in GitOps and CI/CD pipelines dealing with both application lifecycle and infrastructure.
|
||||
|
||||
### Making automation a reality
|
||||
|
||||
You read that right! The entire stack for complex systems like a webshop or government reporting can be defined in clear, understandable, universal terms that can be executed on any on-prem or cloud provider. An autoscaler with custom metrics can be defined to trigger a just-in-time deployment of your desired stack to address the influx of customers or citizens during seasonal peaks. When metrics are back to normal, and cloud compute resources don't have a reason to exist anymore, you trash them and return to regular operations, with a set of core assets on-prem taking over the business until the next surge.
|
||||
|
||||
### The chicken and the egg paradox
|
||||
|
||||
Considering Kubernetes and cloud-native patterns, automation is a must. But it raises an important question: Can an organization adopt Kubernetes before addressing the automation strategy?
|
||||
|
||||
It might seem that starting with Kubernetes could inspire better automation, but that's not a foregone conclusion. A tool is not an answer to the problem of skills, practices, and culture. However, a well-designed platform can be a catalyst for learning, change, and cross-functional collaboration within an IT organization.
|
||||
|
||||
### Get started with Kubernetes
|
||||
|
||||
Even if you feel you missed the automation train, don't be afraid to start with Kubernetes on an easy, uncomplicated stack. Embrace the simplicity of this fantastic orchestrator and iterate with more complex needs once you've [mastered the initial steps][8].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/10/kubernetes-solve-automation-challenges
|
||||
|
||||
作者：[Rom Adams][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/romdalf
|
||||
[b]: https://github.com/lkxed
|
||||
[2]: https://www.redhat.com/en/topics/virtualization/what-is-a-hypervisor?intcmp=7013a000002qLH8AAM
|
||||
[3]: https://www.redhat.com/en/topics/containers/what-is-kubernetes?intcmp=7013a000002qLH8AAM
|
||||
[4]: https://opensource.com/article/21/9/yaml-cheat-sheet
|
||||
[5]: https://opensource.com/resources/devops
|
||||
[6]: https://opensource.com/life/16/7/stumbling-git
|
||||
[7]: https://opensource.com/article/21/3/devops-documentation
|
||||
[8]: https://opensource.com/article/17/11/getting-started-kubernetes
|
||||
@ -0,0 +1,69 @@
|
||||
[#]: subject: "Can Kubernetes help solve automation challenges?"
|
||||
[#]: via: "https://opensource.com/article/22/10/kubernetes-solve-automation-challenges"
|
||||
[#]: author: "Rom Adams https://opensource.com/users/romdalf"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "geekpi"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Kubernetes 能否帮助解决自动化挑战？
|
||||
======
|
||||
组织层面的自动化一直是一个难以实现的目标，但 Kubernetes 或许能够改变这一切。
|
||||
|
||||
当我在 2002 年采用 Gentoo Linux 作为我的主要操作系统时，我开始了我的自动化之旅。二十年后，自动化还没有完成。当我与客户和合作伙伴会面时，他们分享了团队内部的自动化胜利，但他们也描述了在组织层面实现类似成功所面临的挑战。
|
||||
|
||||
大多数 IT 组织都能够端到端地配置虚拟机，从而将过去 4 周的交付周期缩短到仅 5 分钟。这种级别的自动化本身就是一个复杂的工作流程，需要网络（IP 地址管理、DNS、代理、网络区域等）、身份访问管理、[hypervisor][2]、存储、备份、更新操作系统、应用最新的配置文件、监控、安全和强化以及合规性基准测试。哇！
|
||||
|
||||
满足高速、可扩展和按需自动化的业务需求并不容易。例如，考虑使用经典的网上商店或在线政府服务来提交纳税申报表。工作负载有明确的峰值需要吸收。
|
||||
|
||||
处理此类负载的一种常见方法是拥有一个超大的服务器集群，以供 IT 专业人员的特定团队使用，监控客户或公民的季节性涌入。每个人都希望及时部署整个栈。他们希望基础架构在混合云场景的上下文中运行工作负载，使用“构建-消耗-垃圾”模型来优化成本，同时从无限弹性中受益。
|
||||
|
||||
换句话说，每个人都想要乌托邦式的“云体验”。
|
||||
|
||||
### 云真的能交付吗？
|
||||
|
||||
一切都没有丢失，这主要归功于 [Kubernetes][3] 的设计方式。 Kubernetes 的指数级采用推动了创新，取代了管理平台和应用的标准传统做法。 Kubernetes 需要使用 Everything-as-Code (EaC) 来定义所有资源的期望状态，从简单的计算节点到 TLS 证书。 Kubernetes 强制使用三种主要的设计结构：
|
||||
|
||||
* 一个标准接口，以减少内部和外部组件之间的整合问题
|
||||
* API 优先及仅 API 的方法来标准化其所有组件的 CRUD（创建、读取、更新、删除）操作
|
||||
* 使用 [YAML][4] 作为通用语言，以简单易读的方式定义这些组件的所有所需状态
|
||||
|
||||
这三个关键组成部分基本上是选择自动化平台的相同要求，至少如果你想让跨职能团队轻松采用。这也模糊了团队之间的职责分工，有助于提高跨孤岛的协作，这是一件好事！
|
||||
|
||||
事实上，采用 Kubernetes 的客户和合作伙伴正在加速进入超自动化状态。 Kubernetes 有机地推动团队采用多种 [DevOps 基础和实践][5]，如： EaC、[使用 Git 进行版本控制][6]、同行评审、[文档即代码][7]并鼓励跨职能协作。这些实践有助于提高团队的自动化技能，并帮助团队在处理应用生命周期和基础架构的 GitOps 和 CI/CD 管道方面获得良好的开端。
|
||||
|
||||
### 让自动化成为现实
|
||||
|
||||
你没看错！网络商店或政府报告等复杂系统的整个栈可以用清晰、可理解、通用的术语定义，可以在任何本地或云提供商上执行。可以定义具有自定义指标的自动伸缩器以触发所需栈的即时部署，以解决季节性高峰期间客户或市民的涌入问题。当指标恢复正常，且云计算资源不再有存在的理由时，你将它们回收并恢复常规运营，一组核心资产在本地接管业务，直到下一次激增。
|
||||
|
||||
### 鸡和蛋的悖论
|
||||
|
||||
考虑到 Kubernetes 和云原生模式，自动化是必须的。但它提出了一个重要的问题：一个组织可以在解决自动化战略之前采用 Kubernetes 吗？
|
||||
|
||||
似乎从 Kubernetes 开始可以激发更好的自动化，但这并不是一个定局。工具不是对技能、实践和文化问题的解决方案。但是，设计良好的平台可以成为 IT 组织内学习、变革和跨职能协作的催化剂。
|
||||
|
||||
### 开始使用 Kubernetes
|
||||
|
||||
即使你觉得自己错过了自动化列车，也不要害怕从简单、不复杂的栈上开始使用 Kubernetes。当你[掌握了初始步骤][8]，就可以拥抱这个出色的编排器的简单性，并根据更复杂的需求进行迭代。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/10/kubernetes-solve-automation-challenges
|
||||
|
||||
作者：[Rom Adams][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/romdalf
|
||||
[b]: https://github.com/lkxed
|
||||
[2]: https://www.redhat.com/en/topics/virtualization/what-is-a-hypervisor?intcmp=7013a000002qLH8AAM
|
||||
[3]: https://www.redhat.com/en/topics/containers/what-is-kubernetes?intcmp=7013a000002qLH8AAM
|
||||
[4]: https://opensource.com/article/21/9/yaml-cheat-sheet
|
||||
[5]: https://opensource.com/resources/devops
|
||||
[6]: https://opensource.com/life/16/7/stumbling-git
|
||||
[7]: https://opensource.com/article/21/3/devops-documentation
|
||||
[8]: https://opensource.com/article/17/11/getting-started-kubernetes
|
||||
Loading…
Reference in New Issue
Block a user