接管 K8s 部署运维，基础架构团队是否做好准备？| SmartX 趋势分享
随着云原生技术逐渐成熟，越来越多的企业开始采用以云原生为核心的现代化开发方式，来实现更快的应用开发与服务交付。国际权威研究机构 IDC 2022 年发布的《中国云原生市场分析》报告显示，到 2024 年，新增的生产级云原生应用在新应用的占比将从 2020 年的 10% 增加到 60%。届时，使用以 Kubernetes 为代表的容器编排平台，来支持容器的高效部署、扩展和管理，将成为大多数企业的“标配”。
Kubernetes 可以实现跨多个主机管理和协调容器化应用，在集群范围内完成应用的自动化部署、扩展和升级，并提供相应集群上的高可靠和负载均衡机制。通常，Kubernetes 的部署运维主要由开发团队或平台团队负责完成，基础架构团队仅负责提供服务器、网络和存储等设备和支持。而现在，不少企业发现，由于 Kubernetes 与承载的应用之间完全解耦的特性，Kuberenetes 非常适合作为一种 Infrastructure as a Service（IaaS），既可以在公有云上提供，也可以在企业私有云上作为新一代的基础架构，为现代化应用提供可靠的基础设施。因此，伴随着这种定位的转变，Kubernetes 的建设和运维也将更多地交由基础架构团队负责。
这篇文章中，我们将粗浅探讨为什么基础架构团队适合负责 Kubernetes 的运维管理，以及这样的转变是否可行。
转变的必要性：开发人员需要从 Kubernetes 的基础运维管理中解放出来
作为现代化应用的载体，容器和 Kubernetes 最开始被认为是“新型 Platform as a Service（PaaS）平台的基础”，由开发团队或平台团队负责规划和建设，包括预热期的学习、调研、技术储备、试用环境搭建及维护、制定技术体系、方法及工具组合（包括针对裸金属的工具软件）。
然而，作为一种新兴的技术，Kubernetes 学习成本较高，大部分开发人员除了进行前期的规划，还需要在使用 Kubernetes 进行应用开发的同时，承担 Kubernetes 集群的基础管理和维护工作，例如多次、重复搭建相似的 Kubernetes 集群：
将一个服务器部署成为 Kubernetes 节点，至少需要进行以下步骤：
使用 kubeadm 初始化集群。
在服务器上安装操作系统并连接到交换机。
在服务器上安装最新版本的容器运行时。
在服务器上安装 kubeadm、kubelet、kubectl。
安装和配置网络插件 CNI。
这些步骤完成后，只是部署了一个 Kubernetes 节点，要使之成为集群，还需要：
设置节点为管理节点。
创建其他 Kubernetes 节点。
将其他节点加入集群，设置为管理节点或工作节点。
验证所有节点是否正常运行。
配置安全访问。
配置容器存储。
这种日常运维不仅会占用开发人员大量的时间精力，还会拖延新应用的开发和上线速度，与企业选择使用 Kubernetes 以加快开发速度、提高服务效率的初衷相违背。而由于基础架构团队拥有从硬件设施到操作系统的全套技能和经验，在上述过程中可以优化部署流程、引入批量配置脚本，快速完成从硬件安装、连接到部署 Kubernetes 环境的全过程，而且这个过程还可以不断复制，不断提高部署的效率和质量。
因此，Gartner 在《CTOs’ Guide to Containers and Kubernetes — Answering the Top 10 FAQs》报告中，就建议企业将 Kubernetes 部署运维等工作移交给其他团队，帮助开发团队专注于软件开发工作。具体职责与工作内容包括：
不难看出，Gartner 在“平台团队”中列举的大部分职责，与传统基础架构团队负责的基本一致。而且由于基础架构工程师习惯于同时监控、保障多个应用/系统/环境，综合管理能力更强，在运维 Kubernetes 平台时具备天然的优势。
同时，基础架构工程师可以灵活利用专业知识，例如在与网络和存储设施的对接方面，进一步发挥 Kubernetes 作为 IaaS 的优势。根据 Juju 2022 年发布的《Kubernetes and Cloud Native Operations Report》，近一半的企业在使用 Kubernetes 和容器时遭遇了技术人员短缺的问题，也有一些企业反映了企业 IT 结构、与原系统不兼容、网络和存储要求未得到解决、日常运维效率较低等问题。将基础架构团队引入 Kubernetes 运维管理，或许可以从更多角度优化 Kubernetes 和企业整体 IT 系统。
转变的可行性：Kubernetes 管理软件/平台可降低运维门槛
现阶段，由基础架构团队负责 Kubernetes 运维管理是否可行？
正如开头所述，由于缺乏容器与 Kubernetes 相关技术知识，以及 Kubernetes 自身操作需要学习等原因，基础架构团队经常被误认为难以主导 Kubernetes 的运维管理。CNCF 的一篇博客《How to Overcome the Day 2 Kubernetes Skills Gap》列举了 Kubernetes 部署运维与传统基础架构的一些不同之处：
在配置存储资源的时候，运维人员不仅需要理解“persistent volumes”和“persistent volume claims”等 Kubernetes 特有的概念，还需要清楚地知道 Kubernetes 如何连接和编排存储。
在网络层面，运维人员需要理解 DNS 如何在 Kubernetes 集群中运行，以及如何使用 CNI 将集群与中央网络连接起来。此外，了解网络策略如何运作、他们对于安全和架构弹性（resiliency）的影响，以及企业需要使用哪种网络，也非常重要。
在安全方面，运维人员需要保证容器镜像没有弱点，保证配置尽可能安全，并防止以 root 权限运行应用程序。
而且，原生 Kubernetes 只支持命令行模式（Kubectl），虽然开发人员使用起来效率较高，但对于更熟悉图形界面，且需要高效监控、管理多个环境的运维人员来说，全盘接手 Kubernetes 的部署和运维将意味着更加繁重的工作量。
不过，随着云原生技术的不断成熟，市面上出现了很多可以辅助基础架构工程师，对 Kubernetes 进行运维管理的商用 Kubernetes 管理软件/平台。这些软件/平台为运维人员提供了丰富的管理工具（如安全、监控和存储的集成）、简单易操作的运维系统、图形化界面，以及对多种运维环境的全面管理支持，运维人员仅需掌握基本的容器/Kubernetes 知识，即可快速上手 Kubernetes 运维管理等工作。具体优势和价值包括：
Kubernetes 集群生命周期的自动化管理：自动化完成 Kubernetes 集群创建、删除、更新、扩缩容等原本流程繁琐的重复性操作，提升整体运维效率。
插件的统一管理：支持多种插件扩展 Kubernetes 功能服务，满足企业特殊需求。
平台数据的可视化展示：Kubernetes 集群的监控指标将被实时采集，通过统一的可视化界面集中展示监控、告警、日志管理、分析等功能，便于运维人员监控和管理。
不同环境的一致性（consistency）支持：统一 Kubernetes 集群的配置和软硬件部署，以支持集群在不同环境下的分发、扩容和升级。
更多高级服务：一些软件/平台还提供一些高级服务，如高性能持久化存储和网络安全服务，进一步提升基础架构的可靠性。
正是基于 Kubernetes 管理软件/平台，目前有越来越多的基础架构团队在掌握容器与 Kubernetes 相关知识和能力后，开始负责 Kubernetes 的运维管理，将 Kubernetes 与物理环境、虚拟化环境进行统一规划和管理，满足企业快速发展的需求。
总结
云原生技术正在不断向各行各业加速渗透，由基础架构团队主导 Kubernetes 的部署与运维工作，将进一步助力企业敏态发展。基础架构工程师需要具备足够的 Kubernetes 技术知识，制定可行的运维管理策略（如选择合适的 Kubernetes 管理模式和辅助的管理软件/平台），做好转变的准备。
SmartX 近期将推出有关云原生、Kubernetes 及管理服务平台等的系列文章，欢迎关注。
参考文章：
1. 中国云原生市场分析，2022，IDC
https://www.idc.com/getdoc.jsp?containerId=CHC48747522&pageType=PRINTFRIENDLY
2. CTOs’ Guide to Containers and Kubernetes — Answering the Top 10 FAQs
https://www.gartner.com/document/4015168
3. Kubernetes and cloud native operations report 2022
https://juju.is/cloud-native-kubernetes-usage-report-2022
4. How to Overcome the Day 2 Kubernetes Skills Gap
https://www.cncf.io/blog/2020/09/02/how-to-overcome-the-day-2-kubernetes-skills-gap/
5. Market Guide for Container Management
https://www.gartner.com/document/4012524
推荐阅读：
点击阅读原文，体验 SmartX 云原生存储产品 IOMesh 免费社区版。