来源：https://baijiahao.baidu.com/s?id=1687609645264653650众所周知，Kubernetes很难! 以下是在生产中使用它应遵循的一些最佳实践。遵循这些步骤能够确保更高的安全性和生产效率。毫无疑问，DevOps已经走过了一段很长的路! 借助于Kubernetes编排平台使得公司比以往更快地发布软件。随着容器用于构建和发布软件的使用量不断增加，Kubernetes已经成为事实上的容器编排工具标准，在软件企业中非常受欢迎。Kubernetes具有优秀的特性，比如：支持可扩展、零停机部署、服务发现、自动重启和回滚功能等。要大规模管理容器部署，Kubernetes是必须的。它支持灵活地分配资源和工作负载。毫无疑问，生产环境中的Kubernetes是一个很好的解决方案，但需要花费一些时间来设置和熟悉这个工具。由于现在许多公司都希望在生产中使用Kubernetes，因此有必要考虑一些最佳实践。在本文中，我们将讨论一些Kubernetes的最佳实践。Kubernetes是一个复杂并且学习曲线陡峭的编排工具，但它具有丰富的功能。生产操作应尽可能小心谨慎处理。如果您面临内部人才短缺的问题，您可以将其外包给PaaS供应商，为您提供所有最佳实践。但假设您在生产中独自管理Kubernetes。在这种情况下，关注最佳实践是非常重要的，特别是关于可观察性、日志记录、集群监控和安全配置。我们很多人都知道，在生产环境中运行容器不是一件容易的事情。它需要大量的工作和计算资源等等。市场上有许多编排平台，但Kubernetes已经获得了巨大的吸引力和大多数云提供商的支持。总之——Kubernetes、集装箱化和微服务都是美好的基础设施，但同时带来了安全挑战。Kubernetes Pod可以在所有基础设施类之间快速切换，从而导致Pod之间的内部流量增加，引发安全隐患。此外，Kubernetes的攻击面通常更大。您必须考虑到Kubernetes的高度动态且全新的环境无法与旧版安全工具完美融合的问题。Gartner预测，到2022年，超过75%的全球组织将在生产中运行集装箱应用程序，而目前这一比例还不到30%。到2025年，超过85%的全球组织将在生产中推动集装箱应用，较2019年的不到35%有显著增长。本地云应用程序需要高度的基础设施自动化、DevOps和专门的操作技能，这些在普通IT组织中很难找到这些技能。所以必须使用Kubernetes的一些策略，在安全性、监控、网络、治理、存储、容器生命周期管理和平台选择方面应用最佳实践。下面让我们来看看Kubernetes的一些生产最佳实践。在生产中运行Kubernetes并不容易; 有以下几个方面需要注意。管理大型分布式系统可能会很复杂，特别是当出现问题时，我们无法及时得到通知。为了确保应用实例正常工作，设置Kubernetes健康检查至关重要。
通过创建自定义运行健康检查，可以有效避免分布式系统中僵尸服务运行，具体可以根据环境和需要对其进行调整。
Readiness-就绪探针
就绪探针的目的是让Kubernetes知道该应用是否已经准备好为流量服务。Kubernetes将始终确保准备就绪探针通过之后开始分配服务，将流量发送到Pod。
Liveness-存活探针
你怎么知道你的应用程序是活的还是死的?存活探针可以让你做到这一点。如果你的应用死了，Kubernetes会移除旧的Pod并用新Pod替换它。
另一个好的实践是将Kubernetes环境划分为不同团队、部门、应用程序和客户机的独立名称空间。
Kubernetes资源使用情况
Kubernetes资源使用指的是容器/pod在生产中所使用的资源数量。因此，密切关注pods的资源使用情况是非常重要的。一个明显的原因是成本，因为越高的资源利用证明越少的资源浪费。
Resource utilization资源利用率
Ops团队通常希望优化和最大化pods消耗的资源百分比。资源使用情况是Kubernetes环境实际优化程度的指标之一。您可以认为优化后的Kubernetes环境中运行的容器的平均CPU等资源利用率是最优的。RBAC代表基于角色的访问控制。它是一种用于限制系统/网络上的用户和应用程序的访问和准入的方法。
他们从Kubernetes 1.8版本引入了RBAC。使用rbac.authorization.k8s RBAC用于创建授权策略。在Kubernetes中，RBAC用于授权，使用RBAC，您将能够授予用户、帐户、添加/删除权限、设置规则等权限。因此，它基本上为Kubernetes集群添加了额外的安全层。RBAC限制谁可以访问您的生产环境和集群。生产级Kubernetes基础设施通常需要考虑某些关键方面，例如高可用性、多主机、多etcd Kubernetes集群等。此类集群的配置通常涉及到Terraform或Ansible等工具。
一旦集群都设置好了，并且为运行应用程序创建了pods，这些pods就配备了负载平衡器;这些负载均衡器将流量路由到服务。开源的Kubernetes项目并不是默认的负载平衡器;因此，它需要与NGINX Ingress controller与HAProxy或ELB等工具集成，或任何其他工具，扩大Kubernetes的Ingress插件，以提供负载均衡能力。
标签就像附加到对象上的键/值对，比如pods。标签是用来标识对象的属性的，这些属性对用户来说是重要的和有意义的。在生产中使用Kubernetes时，不能忽视的一个重要问题是标签;标签允许批量查询和操作Kubernetes对象。标签的特殊之处在于，它们还可以用于识别Kubernetes对象并将其组织成组。这样做的最佳用例之一是根据pod所属的应用程序对它们进行分组。在这里，团队可以构建并拥有任意数量的标签约定。使用Kubernetes时，设置网络策略至关重要。
网络策略只不过是一个对象，它使你能够明确地声明和决定哪些流量是允许的，哪些是不允许的。这样，Kubernetes将能够阻止所有其他不想要的和不符合规则的流量。在我们的集群中定义和限制网络流量是强烈推荐的基本且必要的安全措施之一。Kubernetes中的每个网络策略都定义了一个如上所述的授权连接列表。无论何时创建任何网络策略，它所引用的所有pod都有资格建立或接受列出的连接。简单地说，网络策略基本上就是授权和允许连接的白名单——一个连接，无论它是到还是从pod，只有在应用于pod的至少一个网络策略允许的情况下才被允许。在使用Kubernetes时，监控部署是至关重要的。确保配置、性能和流量保持安全更是重要。如果不进行日志记录和监控，就不可能诊断出发生的问题。为了确保合规性，监视和日志记录变得非常重要。
在进行监视时，有必要在体系结构的每一层上设置日志记录功能。生成的日志将帮助我们启用安全工具、审计功能和分析性能。运行无状态应用要比运行有状态应用简单得多，但随着Kubernetes运营商的不断增长，这种想法正在改变。对于刚接触Kubernetes的团队来说，建议首先使用无状态应用程序。
建议使用无状态后端，这样开发团队就可以确保不存在长时间运行的连接，从而增加了扩展的难度。使用无状态，开发人员还可以更有效地、零停机部署应用程序。人们普遍认为，无状态应用程序可以方便地根据业务需要进行迁移和扩展。Kubernetes有三种用于部署的自动伸缩功能:水平pod自动伸缩(HPA)、垂直pod自动伸缩(VPA)和集群自动伸缩。
水平pod autoscaler根据感知到的CPU利用率自动扩展deployment、replicationcontroller, replicaset, statefulset的数量。Vertical pod autoscaling为CPU和内存请求和限制推荐合适的值，它可以自动更新这些值。Cluster Autoscaler扩展和缩小工作节点池的大小。它根据当前的利用率调整Kubernetes集群的大小。控制在集群中运行所有容器的镜像源。如果您允许您的Pod从公共资源中拉取镜像，您就不知道其中真正运行的是什么。如果从受信任的注册表中提取它们，则可以在注册表上应用策略以提取安全和经过认证的镜像。不断评估应用程序的状态和设置，以学习和改进。例如，回顾容器的历史内存使用情况可以得出这样的结论:我们可以分配更少的内存，在长期内节省成本。使用Pod优先级，您可以决定设置不同服务运行的重要性。例如，为了更好的稳定性，你需要确保RabbitMQ pod比你的应用pod更重要。或者你的入口控制器pods比数据处理pods更重要，以保持服务对用户可用。通过在HA中运行所有服务，支持集群和服务的零停机升级。这也将保证您的客户获得更高的可用性。使用pod反亲和性来确保在不同的节点上调度一个pod的多个副本，从而通过计划中的和计划外的集群节点停机来确保服务可用性。使用pod Disruptions策略，不惜一切代价确保您有最低的Pod副本数量!硬件最终会失败，软件最终会运行。--（迈克尔·哈顿）众所周知，Kubernetes实际上已经成为DevOps领域的编排平台标准。Kubernetes从可用性、可伸缩性、安全性、弹性、资源管理和监控的角度来应对生产环境产生的风暴。由于许多公司都在生产中使用Kubernetes，因此必须遵循上面提到的最佳实践，以顺利和可靠地扩展应用程序。
