家喻户晓，Kubernetes 很难! 以下是在生产中应用它应遵循的一些最佳实际。遵循这些步骤可能确保更高的安全性和生产效率。
毫无疑问，DevOps 曾经走过了一段很长的路! 借助于 Kubernetes 编排平台使得公司比以往更快地公布软件。随着容器用于构建和公布软件的使用量一直减少，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 健康检查至关重要。
通过创立自定义运行健康检查，能够无效防止分布式系统中僵尸服务运行，具体能够依据环境和须要对其进行调整。
就绪探针的目标是让 Kubernetes 晓得该利用是否曾经筹备好为流量服务。Kubernetes 将始终确保准备就绪探针通过之后开始调配服务，将流量发送到 Pod。
Liveness- 存活探针
你怎么晓得你的应用程序是活的还是死的? 存活探针能够让你做到这一点。如果你的利用死了，Kubernetes 会移除旧的 Pod 并用新 Pod 替换它。
Resource Management- 资源管理
为单个容器指定资源申请和限度是一个很好的实际。
另一个好的实际是将 Kubernetes 环境划分为不同团队、部门、应用程序和客户机的独立名称空间。
Kubernetes 资源应用状况
Kubernetes 资源应用指的是容器 /pod 在生产中所应用的资源数量。
因而，亲密关注 pods 的资源应用状况是十分重要的。一个显著的起因是老本，因为越高的资源利用证实越少的资源节约。
Resource utilization 资源利用率
Ops 团队通常心愿优化和最大化 pods 耗费的资源百分比。资源应用状况是 Kubernetes 环境理论优化水平的指标之一。
您能够认为优化后的 Kubernetes 环境中运行的容器的均匀 CPU 等资源利用率是最优的。
启用 RBAC
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 插件，以提供负载平衡能力。
给 Kubernetes 对象增加标签
标签就像附加到对象上的键 / 值对，比方 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，因而必须遵循下面提到的最佳实际，以顺利和牢靠地扩大应用程序。
起源：https://my.oschina.net/u/1787…