当企业团队将Kubernetes视为一种不可思议的自动化技术而不是必须维护和改进的工具时，可能会遇到一些问题。企业在管理Kubernetes方面应该考虑行业专家的建议。
容器存储厂商Portworx公司首席技术官兼联合创始人Gou Rao说，“越来越多的团队开始在生产中使用Kubernetes来运行其容器化工作负载和应用程序。当零停机时间和安全性至关重要时，Kubernetes迅速成为在生产中运行大规模复杂应用程序的最简单方法。Kubernetes很复杂，以至于并不适合所有人，但是对于需要跨多个云平台和数据中心运行的具有高度规模和复杂性的应用程序，Kubernetes并非遥不可及。”
但Kubernetes并不是一个一成不变的工具，无论其具有多么强大的自动化能力。很多企业正在实施的管理任务值得关注。
Harness公司DevOps技术传播者Ravi Lachhman说，“与任何平台一样，Kubernetes也需要管理和维护。”
与此同时，Red Hat公司安全策略师Kirsten Newcomer说，“安全性应该尽早将其纳入企业的流程中。新技术可以挑战现有的安全方法。例如，数据收集和网络安全解决方案需要适应应用程序运行的环境。最佳实践是永远不要修补正在运行的容器。如果这样做，则下次从映像部署该容器实例时，这个修补程序将会丢失。这意味着企业需要重新评估其对DevOps的投资以及加强安全性。”
长期管理Kubernetes的7个技巧
行业专家可以为企业团队和从业人员提供有关管理Kubernetes的7个建议：
1.企业必须将Kubernetes视为一项重大投资
企业在笔记本电脑或沙箱环境中修改Kubernetes是一回事(许多团队都是从这种方式开始的，而Minikube和类似的工具使这种方式相对简单)，而在生产环境中运行是另一种回事。
Rao说，“正确地采用Kubernetes要求企业认真对待它。确实，所有技巧实质上都源于此。”他认为，这是一个功能强大的软件引擎，因此需要认真对待它。
Rao说，“这个引擎希望能够根据企业提供的参数，随时随地运行、移动和重新移动应用程序。企业需要采用Kubernetes做什么，如何实现。如果要从这种运营效率中受益，则需要为其提供有效运行的环境。”
这意味着企业需要拥有合适的人员、基础设施、流程和文化。很多企业希望Kubernetes能够解决现有的结构问题，这些问题会使其环境管理变得混乱。
2.即使协调者也需要管理和维护
一些团队(尤其是刚起步的团队)可能认为Kubernetes会自己运行。考虑到协调者的声明性和对自动化的重视，这个实际上具有一种伪基准。但是Kubernetes像其他系统一样需要一些管理和维护。
Lachhman说：“每个企业都是不同的，并且初次掌握新的知识和经验将对其组织产生长期的影响。”
Lachhman指出了常见维护和管理任务的示例，例如：
修补或升级集群及其基础设施;
添加和减去工作节点;
插入新功能，例如Istio和Traefik等服务网格工具;
建立明确定义的命名空间分类法，尤其是随着越来越多的团队开始使用Kubernetes。
为什么名称空间很重要?它们有助于保护多个用户之间对容器中资源的访问。
3. Kubernetes需要适当的基础设施才能成功
长期成功管理Kubernetes的基本需求之一是采用适当的基础设施，例如混合云和多云环境。
Rao说，“我看到团队犯下的错误正在转向Kubernetes，因为他们想要敏捷性，但随后又影响了Kubernetes提供推动其最初决策的运营成果的能力。这种做法有些自欺欺人。任何系统都只有其最小敏捷性元素才具有敏捷性，因此，如果在静态数据中心环境中运行Kubernetes，而该环境中存储的硬件和软件为不那么敏捷的虚拟机环境提供了相同的硬件和软件，如果企业没有认真对待Kubernetes，那么不会获得所追求的好处。”
Zettaset公司工程副总裁Maksim Yankovskiy表示，存储是基础设施的一个特定子集，可能需要进行规划。例如，有状态容器带有特殊的存储注意事项。
Yankovskiy说，“为工作负载规划存储至关重要。某些工作负载可能需要专门的存储或按应用程序调整存储参数。并非所有存储都应该由Kubernetes管理。”
Rao还以存储为例，这是团队在采用Kubernetes时可能会忽略的特定领域的示例，该过程旨在变得更加敏捷，而这将会在管理方面引起麻烦。
Rao说，“与许多与在Kubernetes上运行数据服务的客户合作，而我一直听到的一句话是‘我曾尝试在Kubernetes上运行MongoDB，但SAN一直存在问题。’可以采用SAN，但是它们并不是为Kubernetes的规模、密度和动态性而设计的。为了充分利用Kubernetes，企业需要为其提供有效运行所需的基础设施。如果只为其提供静态基础设施，它将无法发挥其作用。”
4. Kubernetes的可靠性会让企业过分自信
正如Rao一开始指出的那样，Kubernetes的自我修复和可靠性功能是其具有吸引力的重要组成部分，只是不要以它们为借口而忽略其运行状况。例如，仍然需要确保有适当的监视。
Yankovskiy说：“不要依靠Kubernetes的可靠性功能来解决错误的服务。仅仅因为Kubernetes出色地完成了自动重启失败的Pod的工作，并不意味着不应该监视应用程序的运行时错误。”
随着企业的发展和成长，日志记录是另一个重要的管理需求。
Yankovskiy说：“Kubernetes集群是高度分布式的，因此，部署Kubernetes集群的第一步应包括计划集中式日志记录设施。在监视性能或诊断问题时访问单个节点上的日志是不可扩展的。出色的日志管理系统是强大的Kubernetes管理的基础之一。”
Red Hat公司技术传道者Gordon Haff补充说：“部署到Kubernetes的云原生应用程序基本上是分布式应用程序，IT商店习惯于运行整体程序的架构可能没有很多经验。Kubernetes轨道上的开源项目生态系统包括监视、日志记录、分布式跟踪等。但是企业可能想要一个已经将该工具与Kubernetes集成在一起的平台，而不是着手进行大型的DIY项目。企业的员工也可能会从新的云原生应用程序开发实践培训中受益。”
总的来说，当团队将Kubernetes视为一种灵丹妙药，而不是像其他任何重要系统一样必须维护和改进的工具时，团队往往会遇到问题。
Lachhman说：“企业可能会有多位管理员和一个定期更改的拓扑结构，并且在使用Kubernetes时不受网络延迟的影响。”
5.实验和无聊之间需要定期调整
Lachhman指出，使用Kubernetes本身已不再具有实验性的资格。该项目开展了将近5年，如今已成为一个稳定可靠的平台。也就是说，生态系统正在不断发展：考虑诸如运算符、集群API、GitOps和上述服务网格工具之类的事情。 Lachhman说，Kubernetes团队将需要决定如何在创新和控制之间进行切换，这是企业管理层的考虑。
一方面，大多数团队可能会因为在“无聊”方面犯错误，特别是在采用的早期阶段。
Lachhman说：“通过保持简单的方法，需要了解不在CNCF中的最新测试版或特殊兴趣小组(SIG)上对企业的Kubernetes工作负载没有损害。另一方面，企业不想错过可能解决实际问题的新功能。因此，企业必须确定适合自己的方法，在Kubernetes内部权衡更多经过实践检验的方法与新方法的选择。”
6.刚性开发在容器和编排中不能很好地发挥作用
现代IT工具最适合现代IT惯例和文化。这既可能是人员管理问题，也可能是技术管理问题。
Zettaset公司的Yankovskiy说：“ Kubernetes就是关于快速开发和部署的。一些组织可能需要过渡到DevOps模式，以实现Kubernetes的全部利益。”
这一原则也适用于应用程序本身。并不是所有的东西都适合容器和编排，“提升和转移”并不总是将传统应用程序迁移到容器并与Kubernetes一起运行的最佳策略。事实上，更好的选择可能是根本不迁移这个应用程序。
Yankovskiy说，“并不是所有事情都必须在Kubernetes上运行，Kubernetes是工作的工具。它对很多事情都有好处，但是随着许多传统应用程序迁移到容器中，重要的是要了解并非所有内容都必须在容器中运行。”
7.量力而行
企业善于学习是一件好事，但了解自己的局限性也是件好事。否则，长期管理Kubernetes可能会面临一些问题，因此需要知道何时寻求外部帮助。
Lachhman建议说：“企业避免寻求获得更多的技能，并且知道何时将复杂性转移出去。而从头开始构建自己的集群，并在每次部署时运行一致性测试，这似乎是一个黄金标准，但对于大多数工作负载来说，将这种复杂性交给PaaS或Kubernetes供应商并不是一个坏主意。”
