2024年IT基础架构团队的Kubernetes管理

IT基础架构团队的Kubernetes管理 概念⼊⻔ 从⼊⻔到评估 越来越多的企业开始采⽤围绕Kubernetes的云原⽣开发⽅式。通常，Kubernetes的部署运维主要由开发团队或平台团队负责完成，基础架构团队仅负责提供服务器、 ⽹络和存储等设备和⽀持。不过，不少企业发现，由于Kubernetes与承载的应⽤之间完全解耦的特性，它⾮常适合作为⼀种InfrastructureasaService(IaaS)，既可以在公有云上提供，也可以在企业私有云上作为新⼀代的基础架构，为现代化应⽤提供可靠的基础设施。因此，伴随着这种定位的转变，Kubernetes的建设和运维也将更多地交由基础架构团队负责。 对于IT基础架构团队⽽⾔，接管Kubernetes平台的管理运维，⽆疑是⼀项不⼩的挑战。为此，我们将为您提供接管Kubernetes平台所需的核⼼信息，如选型评估要点、部署运维建议、基于虚拟化还是裸⾦属部署等等。 2024年1⽉更新 ⽬录 基础架构团队为何要接管Kubernetes部署运维？基础架构团队接管Kubernetes部署运维的可⾏性如何选择Kubernetes管理平台？ 如何部署运维Kubernetes？来⾃Gartner的建议 Kubernetes部署，选择虚拟化还是裸⾦属？ 适合在虚拟化环境中部署Kubernetes的三个场景虚拟化vs.裸⾦属：⽀持Kubernetes性能对⽐测试资源推荐 基础架构团队为何要接管Kubernetes部署运维？ K8s部署运维占⽤了开发⼈员⼤量的时间精⼒ 作为现代化应⽤的载体，容器和Kubernetes最开始被认为是“新型PlatformasaService(PaaS)平台的基础”，由开发团队或平台团队负责规划和建设，包括预热期的学习、调研、技术储备、试⽤环境搭建及维护、制定技术体系、⽅法及⼯具组合 （包括针对裸⾦属的⼯具软件）。 然⽽，作为⼀种新兴的技术，Kubernetes学习成本较⾼，⼤部分开发⼈员除了进⾏前期的规划，还需要在使⽤Kubernetes进⾏应⽤开发的同时，承担Kubernetes集群的基础管理和维护⼯作，例如多次、重复搭建相似的Kubernetes集群： •使⽤kubeadm初始化集群。 •在服务器上安装操作系统并连接到交换机。 •在服务器上安装最新版本的容器运⾏时。 •在服务器上安装kubeadm、kubelet、kubectl。 •安装和配置⽹络插件CNI。 这些步骤完成后，只是部署了⼀个Kubernetes节点，要使之成为集群，还需要： •设置节点为管理节点。 •创建其他Kubernetes节点。 •将其他节点加⼊集群，设置为管理节点或⼯作节点。 •验证所有节点是否正常运⾏。 •配置安全访问。 •配置容器存储。 这种⽇常运维不仅会占⽤开发⼈员⼤量的时间精⼒，还会拖延新应⽤的开发和上线速度，与企业选择使⽤Kubernetes以加快开发速度、提⾼服务效率的初衷相违背。⽽由于基础架构团队拥有从硬件设施到操作系统的全套技能和经验，在上述过程中可以优化部署流程、引⼊批量配置脚本，快速完成从硬件安装、连接到部署Kubernetes环境的全过程，⽽且这个过程还可以不断复制，不断提⾼部署的效率和质量。 基础架构团队接管具有天然优势 Gartner在《CTOs’GuidetoContainersandKubernetes—AnsweringtheTop10FAQs》报告中，建议企业将Kubernetes部署运维等⼯作移交给其他团队，帮助开发团队专注于软件开发⼯作。具体职责与⼯作内容包括： 团队 职责 ⼯作内容 软件开发 开发⼈员 •编程、软件设计、实现与测试•源代码管理 平台 平台⼯程与运营 •确定平台⼯具•平台安装、配置和管理•⾃动化容器基础设施供应•维护基本映像•DevOps流⽔线和⽇常运维操作⾃动化的集成•为开发⼈员启⽤⾃助服务功能•容量规划、⼯作负载隔离 可靠性⼯程（如站点可靠性⼯程师） •有关平台和应⽤程序的安全性、监控和性能•应⽤弹性（resiliency）•调试与记录⽣产问题•事件管理与响应 搭建与发布⼯程 •选择与管理CI/CD部署流程•开发模板以快速构建新的服务和功能•指导开发团队•量化流程效率和开发⼈员⽣产⼒，并创建可视化界⾯ 不难看出，Gartner在“平台团队”中列举的⼤部分职责，与传统基础架构团队负责的基本⼀致。⽽且由于基础架构⼯程师习惯于同时监控、保障多个应⽤/系统/环境，综合管理能⼒更强，在运维Kubernetes平台时具备天然的优势。 同时，基础架构⼯程师可以灵活利⽤专业知识，例如在与⽹络和存储设施的对接⽅⾯，进⼀步发挥Kubernetes作为IaaS的优势。 根据Juju2022年发布的《KubernetesandCloudNativeOperationsReport》，近⼀半的企业在使⽤Kubernetes和容器时遭遇了技术⼈员短缺的问题，也有⼀些企业反映了企业IT结构、与原系统不兼容、⽹络和存储要求未得到解决、⽇常运维效率较低等问题。 将基础架构团队引⼊Kubernetes运维管理，或许可以从更多⻆度优化Kubernetes和企业整体IT系统。 基础架构团队接管Kubernetes部署运维的可⾏性 挑战：Kubernetes部署运维与传统基础架构的不同之处 由于缺乏容器与Kubernetes相关技术知识，以及Kubernetes⾃身操作需要学习等原因，基础架构团队经常被误认为难以主导Kubernetes的运维管理。CNCF的⼀篇博客《HowtoOvercometheDay2KubernetesSkillsGap》列举了Kubernetes部署运维与传统基础架构的⼀些不同之处： 在配置存储资源的时候，运维⼈员不仅需要理解“persistentvolumes”和“persistentvolumeclaims”等Kubernetes特有的概念，还需要清楚地知道Kubernetes如何连接和编排存储。 在⽹络层⾯，运维⼈员需要理解DNS如何在Kubernetes集群中运⾏，以及如何使⽤CNI将集群与中央⽹络连接起来。此外，了解⽹络策略如何运作、他们对于安全和架构弹性（resiliency）的影响，以及企业需要使⽤哪种⽹络，也⾮常重要。 在安全⽅⾯，运维⼈员需要保证容器镜像没有弱点，保证配置尽可能安全，并防⽌以root权限运⾏应⽤程序。 ⽽且，原⽣Kubernetes只⽀持命令⾏模式（Kubectl），虽然开发⼈员使⽤起来效率较⾼，但对于更熟悉图形界⾯，且需要⾼效监控、管理多个环境的运维⼈员来说，全盘接⼿Kubernetes的部署和运维将意味着更加繁重的⼯作量。 机会：借助管理⼯具，掌握基础Kubernetes知识即可快速上⼿ 随着云原⽣技术的不断成熟，市⾯上出现了很多可以辅助基础架构⼯程师，对Kubernetes进⾏运维管理的商⽤Kubernetes管理软件/平台。 这些软件/平台为运维⼈员提供了丰富的管理⼯具（如安全、监控和存储的集成）、简单易操作的运维系统、图形化界⾯，以及对多种运维环境的全⾯管理⽀持，运维⼈员仅需掌握基本的容器/Kubernetes知识，即可快速上⼿Kubernetes运维管理等⼯作。具体优势和价值包括： 基础架构团队接管Kubernetes部署运维的可⾏性 •Kubernetes集群⽣命周期的⾃动化管理：⾃动化完成Kubernetes集群创建、删除、更新、扩缩容等原本流程繁琐的重复性操作，提升整体运维效率。 •插件的统⼀管理：⽀持多种插件扩展Kubernetes功能服务，满⾜企业特殊需求。 •平台数据的可视化展示：Kubernetes集群的监控指标将被实时采集，通过统⼀的可视化界⾯集中展示监控、告警、⽇志管理、分析等功能，便于运维⼈员监控和管理。 •不同环境的⼀致性（consistency）⽀持：统⼀Kubernetes集群的配置和软硬件部署，以⽀持集群在不同环境下的分发、扩容和升级。 •更多⾼级服务：⼀些软件/平台还提供⼀些⾼级服务，如⾼性能持久化存储和⽹络安全服务，进⼀步提升基础架构的可靠性。 正是基于Kubernetes管理软件/平台，⽬前有越来越多的基础架构团队在掌握容器与Kubernetes相关知识和能⼒后，开始负责Kubernetes的运维管理，将Kubernetes与物理环境、虚拟化环境进⾏统⼀规划和管理，满⾜企业快速发展的需求。 点击链接，阅读原⽂： 接管K8s部署运维，基础架构团队是否做好准备？ 如何选择Kubernetes管理平台？ Kubernetes运维管理有哪些挑战？ 虽然Kubernetes对资源扩展和应⽤程序的部署、管理、监控、迁移、恢复等⽅⾯的⽀持，已经降低了容器管理的复杂度，但采⽤DIY的⽅式搭建和运维Kubernetes依旧具有挑战性。 1.⼿动管理集群⽣命周期费时费⼒ ⽤户在使⽤Kubernetes时可能需要频繁扩展/删除集群，这不仅要求⽤户熟知节点、Pod等相关概念和⼯作原理，还需要执 ⾏⼀系列步骤来调整和配置节点。这个过程劳神费⼒，⽽且⼀旦出现配置错误，可能会导致服务不可⽤，徒增运维负担。 ⽽且，随着集群规模的逐渐扩展，想要⼿动操作每个集群完成Kubernetes版本或安全更新，并保证升级过程不会影响业务⾼效稳定运⾏，也不是⼀件容易的事情。Kubernetes更新速度快，每4个⽉就会发布⼀个新版本（次版本），每1个⽉会发布 ⼀个新的补丁版本（若遇到严重bug，更新节奏会更快）。同时，Kubernetes社区仅为最新的三个版本提供1年的维护⽀持 （1.18及更早的版本⽀持时⻓为9个⽉），这就要求⽤户尽量保持⽣产环境的版本在社区维护范围内，以及时弥补漏洞并获取最新的功能特性。这⼀系列持续、频繁的升级操作，若没有⾃动化⼯具辅助，将耗费运维⼈员⼤量时间和精⼒，也很容易出错。 2.可视化⼯具集成程度低，不便于监控集群整体健康状态 Kubernetes优秀的容器编排能⼒提⾼了集群的可扩展性和应⽤在多环境间的可移植性，但同时也使得应⽤间的关系和资源开销变得更加复杂。为了更好地监测应⽤和基础设施的运⾏状态、对集群进⾏跨平台管理，运维⼈员需要实时、准确地了解从基础架构到应⽤组件间各层级的数据流和资源使⽤情况。虽然Kubernetes官⽅提供了KubernetesDashboard和多种第三⽅可视化⼯具，来⽀持⽤户查看容器、Pod、服务和集群级别的资源使⽤信息，但这些监视功能⼊⼝分散，需要⾃⾏调⽤/安装，缺乏统⼀的可视化管理界⾯。同时，⼀些⾼级的可视化信息，如Pods中的容器⽇志、事件和存储分析，很难在原⽣Kubernetes上进⾏关联和可视化查询。 3.复杂的容器环境更考验安全策略的制定 相⽐传统架构，Kubernetes在安全⽅⾯的运维管理更加复杂：运维⼈员需要制定全⾯的安全策略，包括如何为不同⼈员——开发者、运维⼈员、承包商、合作商、⽤户等——划定相应的访问权限，以及如何保障⽹络、镜像、节点，甚⾄是操作的安全。 如何选择Kubernetes管理平台？ 虽然Kubernetes提供了⼀些⽹络与安全管理功能，如RBAC（基于⻆⾊的访问控制）机制和NetworkPolicy，运维⼈员仍然需要花费⼤量时间学习相关概念（如⻆⾊和⻆⾊绑定）和操作⽅式。同时，由于Kubernetes⽀持容器在多种环境运⾏，⽤户需要设置更严格的应⽤程序⽹络隔离、身份验证和授权规则，以减少攻击⾯，并对数据传输进⾏保护。Kubernetes各代版本也会存在⼀定的安全漏洞，如允许攻击者伪造命令⾏输出来获得控制和访问权限。为了避免遭遇这些漏洞，运维⼈员需要及时更新补丁和新版本，这就⼜出现了前⾯所说的运维复杂的问题。 4.多环境特性提⾼了⼀致性管理的要求 在整个应⽤开发、测试、⽣产流程中，运维⼈员需要保证在不同的环境中，应⽤程序的资源配置、部署流程、问题