在生产环境中，您可以遵循那些良好的Kubernetes实践应用程序（如今不到30%）。而到2025年，这一比例将超过85%。由于云原生应用对基础设施的自动化程度要求很高，目前以Docker、Kubernetes为代表的DevOps实施平台都是以容器编排工具的形式出现，让更多的企业能够以更快的速度构建、发布和交付他们的软件产品.总的来说，Kubernetes具有支持自动扩容、零宕机部署、服务发现、自动部署、回滚等优秀丰富的特性，非常适合大规模的容器部署和管理。尽管Kubernetes可以灵活地分配资源和工作负载，但它具有复杂而陡峭的学习曲线。为了节省时间和精力，您当然可以将其外包给KaaS提供商。但是，如果您需要在生产中完全控制Kubernetes，则需要一些时间来掌握Kubernetes的各个方面，例如可观察性、日志记录、集群监控和安全配置。同时，由于在生产环境中运行容器往往需要大量的计算资源和能力，人们选择了各种基于云的编排平台。但是，也存在潜在的安全问题。例如：虽然KubernetesPod可以在所有基础设施中快速启动，但是随着Pod之间内部流量的增加，Kubernetes的攻击面会逐渐增大，安全风险也会相应增加。此外，Kubernetes固有的高度动态和短暂的操作环境往往无法与传统安全工具完美集成。我们迫切需要制定一套能够满足存储安全、网络监控与治理、容器生命周期管理、平台选择等需求的Kubernetes配置策略。下面，我将与大家一起探讨在生产环境中可以遵循的Kubernetes的各种良好实践和探索。使用就绪且存活的探针（Probes）进行健康检查，是线上业务保证服务正常稳定的重中之重。及时处理故障服务，避免业务影响，快速恢复，一直是DevOps的难点。在管理大型分布式系统时，为了保证应用实例的正常运行，我们需要提前设置Kubernetes健康检查。您可以根据目标环境和需求创建和定制各种健康检查项。例如，我们可以使用Wea??veWorks。它可以创建一个虚拟网络，以网络交换机的形式连接到部署在多台主机上的Docker容器，让应用程序不需要一一配置端口映射、链接等信息。详情请参考--https://www.weave.works/blog/resilient-apps-with-liveness-and-readiness-probes-in-kubernetes。值得注意的是，这些就绪探针可以让Kubernetes知道应用程序是否准备好为流量提供相应的服务。也就是说，Kubernetes需要始终确保在分配服务和向Pod发送流量之前进行健康的就绪探测。那么，我们如何知道申请的有效性呢？这里，我们需要通过Livelinessprobe来保证一旦应用出现故障，Kubernetes会立即删除旧的Pod，并用新的Pod替换。通过上述对Kubernetes的健康检查，我们可以对检测到的故障服务及时自动下线或重启服务，使其自行恢复。资源管理通常，我们需要指定或限制单个容器的资源请求数量，将Kubernetes环境划分为不同的命名空间，以供不同的团队、部门、应用程序和客户使用。详情请参考--http://blog.kubecost.com/blog/requests-and-limits/。值得一提的是，这里的Kubernetes资源使用量是指生产环境中容器和KubernetesPod使用的资源量。因此，我们可以合理控制转换所需的成本。另外，运维团队通常需要了解容器的平均CPU使用率和Pod消耗的资源百分比，从而判断当前Kubernetes生产环境是否处于最佳状态。启用RBAC（基于角色的访问控制）是一种授予或限制用户和应用程序访问系统和网络的方法。Kubernetes从1.8版本开始就引入了RBAC。我们可以使用rbac.authorization.k8s.ioAPI组创建各种授权策略来限制可以访问目标生产环境和集群的用户和进程。可以说，RBAC为Kubernetes集群增加了额外的安全层。您可以在Kubernetes中添加或删除某些帐户权限，并设置特定的访问规则。具体可以参考--https://medium.com/@danielckv/what-is-rbac-in-kubernetes-c54457eff2dc集群配置和负载均衡为了满足生产环境级别，Kubernetes架构需要具备高可用,multi-master,以及multi-etcd集群等特性。在实际应用中，我们经常使用Terraform、Ansible等工具来配置集群。一旦我们设置了所有集群并为正在运行的应用程序创建了pod，我们应该考虑为这些pod配备负载均衡器，以将各种网络流量路由到相应的服务。但是，开源Kubernetes项目默认不提供负载均衡器。因此，我们需要借助NGINXIngresscontroller、HAProxy或ELB等工具，或者Kubernetes的插件来实现负载均衡功能。详情请参考--https://medium.com/avmconsulting-blog/external-ip-service-type-for-kubernetes-ec2073ef5442。为Kubernetes对象附加标签我们可以将诸如键/值对（key/valuepairs）之类的标签作为某种属性附加到诸如Pod之类的对象上。在生产环境中，我们可以通过标签对Kubernetes对象进行识别、分组、批量查询等操作。例如：我们可以根据容器所属的应用对容器进行分组。当然，团队可以预先建立任意数量的标签约定。详情请参考--https://theithollow.com/2019/01/31/kubernetes-services-and-labels/。设置NetworkPolicyNetworkPolicy可以通过明确的声明让我们更容易决定哪些流量适合通过，这样Kubernetes就可以阻断所有不合格（non-conforming）或不需要的流量。例如，作为一项基本的安全措施，我们可以定义和限制集群中的某些网络流量。事实上，Kubernetes中的每个网络策略都可以定义为授权连接列表。根据创建的网络策略，只有满足条件的pod才有资格接受给定的连接。简而言之，网络策略根据白名单授权和允许“来自”或“至”Pod的连接。详情请参考--https://theithollow.com/2019/10/21/kubernetes-network-policies/。集群监控和日志记录集群监控对于确保Kubernetes配置、性能和生产流量的安全性至关重要。同时，我们有必要在系统架构的每一层设置日志功能。这些生成的日志将帮助我们通过安全工具执行分析和审计功能。可以这么说，如果没有日志记录和监控，就不可能在问题发生时对其进行诊断并确保合规性。详情请参考--https://dzone.com/articles/logging-amp-monitoring-of-kubernetes-applications。从无状态应用程序开始由于无状态应用程序比有状态应用程序更容易运行，对于刚接触Kubernetes的团队，他们可以使用无状态后端，避免设置长时间运行（long-running），轻松灵活地迁移并根据业务需求按需扩展。此外，通过使用无状态，开发人员可以零停机时间更高效地部署应用程序。启用自动伸缩插件（AutoScaler）Kubernetes为部署提供了三种自动伸缩功能，分别是：水平Pod自动伸缩插件（HPA）、垂直Pod自动伸缩插件（VPA）和集群自动伸缩-缩放。其中：水平Pod自动扩容插件会根据感知到的CPU利用率，自动扩容deployments、replicationcontrollers、replicasets、statesets的数量。垂直Pod自动伸缩插件会为CPU和内存的请求数和限制设置合适的值，并能自动更新这些值。集群自动扩缩Worker节点池大小，可以根据当前利用率调整Kubernetes集群大小。控制运行时的各种来源如果你只允许Pod从公共源拉取图像，那么你可能对运行时一无所知。因此，我们需要对集群中的所有容器进行源码控制。通过对注册表应用策略，我们可以从受信任的注册表中提取安全且经过身份验证的图像。持续评估我们需要持续评估目标应用的状态和设置的合理性。例如，通过查看容器的历史内存使用情况，我们可以从长远来看分配更少但更合理的内存量以节省成本。保护那些重要的服务通过使用Pod优先级，您可以设置不同服务的重要性。例如，为了获得更好的稳定性，可以将RabbitMQPod设置为比其他应用程序Pod更重要；或者通过设置IngressControllerPod的重要性来优先处理数据处理Pod，从而维护那些面向用户的服务的可用性。零停机说到可用性，我们还可以通过设置集群和服务的HA（高可用性）来确保零停机。例如，使用Pod反亲和性（Podantiaffinity），我们可以保证一个Pod的多个副本分布在不同的节点上，通过计划内和计划外的集群节点中断来保证服务的可用性。此外，通过使用Pod中断预算，我们还能够确保最少的副本数。小结综上所述，为了交付稳定可靠的应用服务，我们从可用性、可扩展性、安全性、负载均衡、资源管理、资源管理等方面深入探讨了Kubernetes在生产环境中可以遵循的各个方面。监控。好的做法。原标题：KubernetesinProduction:BestPracticestoFollow，作者：PavanBelagatti
