容器已成为云原生应用程序开发的标准，Kubernetes，也称为 K8s，可以说是最流行的容器编排工具。云原生计算基金会 (CNCF)的一项 调查显示，91% 的受访者使用 Kubernetes，其中 83% 用于生产。这比前一年的 78% 有所上升。
然而，流行并不等于易于使用。Kubernetes 是一个复杂的系统。开始使用它需要一个重要的学习曲线。虽然以下 Kubernetes 最佳实践和建议可能不适用于您的情况，但它们可以帮助您从 Kubernetes 中获得更多收益——更轻松、更快捷。
20 个 Kubernetes 最佳实践
1) 使用供应商托管
使用外部托管启动您的 Kubernetes 部署。根据您选择的托管服务类型，您的团队无需手动配置控制平面组件、添加节点以扩展集群或配置支持容器的 pod。他们也不必实施基于角色的访问控制 (RBAC) 来保护您的单独环境或对集群进行仪器监控和日志记录。
2) 使用最新版本
使用最新版本的 Kubernetes。除了更新和附加功能外，最新版本还将针对先前版本的安全问题提供补丁。这对于缓解许多可能影响您的集群的漏洞至关重要。旧版本也没有得到 Kubernetes 社区的支持。
3) 使用版本控制系统
在推送到集群之前，您应该将与部署、入口、服务和其他文件相关的配置文件存储在版本控制系统中。这有助于您跟踪谁进行了更改并实施更改批准流程以提高集群的稳定性和安全性。
4) 使用标签和注释
随着集群中对象数量的增加，查找和组织它们变得更加困难。标签——分配给对象的键/值结构——让您可以将有意义和相关的元数据附加到集群对象，以便可以对它们进行分类、查找和批量操作。
您可以使用标签来确定 pod 是生产部署还是金丝雀部署的一部分，以及它是前端还是后端。他们还可以指定对象所属的层及其发布版本，以及区分稳定版本和 alpha 版本。
5) 使用 Readiness 和 Liveness 探针
就绪和活跃度探测本质上是健康检查。在允许负载被定向到该 pod 之前，就绪探测确保给定的 pod 已启动并运行。如果 pod 尚未准备好，则请求会从您的服务中移除，直到探测验证 pod 已启动。活性探针验证应用程序是否仍在运行。它尝试对 pod 执行 ping 操作以获取响应，然后检查其运行状况。如果没有响应，则应用程序未在 pod 上运行。如果检查失败，liveness 探针会启动一个新的 pod 并在其上启动应用程序。
6) 设置资源请求和限制
资源请求指定容器可以使用的最小资源，而资源限制指定最大资源。
如果没有资源请求和限制，集群中的 Pod 可以使用比所需更多的资源。如果 pod 开始在节点上消耗更多的CPU或内存，那么调度程序可能无法放置新的 pod。甚至节点本身也可能崩溃。
对于请求和限制，通常以毫核为单位定义 CPU。内存以兆字节或兆字节定义。
7) 使用更小的容器镜像
基本映像可以包含多达 80% 的不需要的包和库。相反，请使用较小的容器映像，例如比基础映像小 10 倍的 alpine 映像。它们需要更少的存储空间，并将帮助您更快地提取和构建映像。此外，容器映像越小，出现安全问题的可能性就越小。然后，您可以添加运行应用程序所需的任何包和库。
8) 监控控制平面组件
监控工作负载和资源消耗以及控制平面组件的性能，包括 Kubernetes API、kubelet、etcd、controller-manager、kube-proxy 和 kube-dns。这将识别集群内的问题/威胁并增加其延迟。
您还应该使用自动监控工具，而不是手动管理警报。
9) 使用自动缩放
当资源消耗激增时，利用 Kubernetes 中的自动扩展机制自动扩展集群服务。
水平 pod 自动缩放器会根据感知的 CPU 利用率自动扩展部署中的 pod、复制控制器、副本集或有状态集的数量。
Vertical pod autoscaler 建议为 CPU 和内存请求和限制设置合适的值。它可以自动更新值。
集群自动缩放器扩展和缩小工作节点池的大小。它根据当前利用率调整 Kubernetes 集群的大小。
10) 采用 GitOps
使用基于 Git 的工作流 GitOps 作为首选模型，将 Git 用作所有自动化(包括 CI/CD 管道)的单一事实来源。使用 GitOps 框架可以通过加快应用程序开发和缩短部署时间来帮助提高生产力。它还可以增强错误可追溯性并自动化 CI/CD 工作流程。
11) 监控磁盘使用情况
由于高磁盘使用率会影响集群性能，因此您应该定期监控与集群关联的所有磁盘卷以及根文件系统。通过警报监控，您可以在需要时通过扩展或释放磁盘空间来采取纠正措施。
12) 从无状态应用开始
使用无状态后端，开发团队可以确保不存在使扩展更具挑战性的长期连接。使用无状态还使开发人员能够以零停机时间更有效地部署应用程序。
无状态应用程序可以根据业务需求在需要时更轻松地进行迁移和扩展。
Kubernetes 最佳实践：授权和身份验证
13) 采用基于角色的访问控制
为了帮助增强 Kubernetes 工作负载的安全性，请启用 Kubernetes 基于角色的访问控制 (RBAC)。RBAC 通常在 Kubernetes 1.6 及更高版本上默认启用。因为 Kubernetes 结合了授权控制器，所以当您启用 RBAC 时，您还必须禁用旧的基于属性的访问控制 (ABAC)。
为集群中的每个用户和集群中运行的每个服务帐户分配角色。RBAC 中的角色包含用户或服务帐户可以执行的多个权限。您可以将相同的角色分配给多个人，并且每个角色可以拥有多个权限。RBAC 设置也可以应用于命名空间。如果您将角色分配给允许在一个命名空间中使用的用户，他们将无法访问集群中的其他命名空间。Kubernetes 提供了角色和集群角色等 RBAC 属性来定义安全策略。
14) API Server 使用第三方认证
将 Kubernetes 与第三方身份验证提供程序集成，以利用额外的安全功能，例如多因素身份验证。这样做还有助于确保kube-apiserver在您添加或删除用户时不会发生变化。如果可能，请确保不在 API 服务器级别管理用户。
Kubernetes 最佳实践：安全问题
15) 使用网络策略
使用网络策略来限制对 Kubernetes 集群内服务的访问。它们还可以限制从集群中的 pod 对云的元数据 API 的访问，并在 IP 地址或端口级别控制流量。
您可以在Kubernetes 文档中找到有关设置网络策略的信息。
16) 不要以 root 身份运行
运行容器的用户的 UID(Kubernetes 系统生成的唯一标识对象的字符串)直接映射到主机。如果容器作为 UID 0 (root) 运行，它也会在运行它的节点上显示为 root。
Kubernetes 具有内置的保护措施，可以防止通过这种机制提升权限，但是，安全问题总是有可能允许提升权限。通过不以 root 身份运行容器来避免这种情况。相反，修改构建容器的 Dockerfile 以创建和使用具有已知 UID 的用户。
17) 创建防火墙
为您的 API 服务器创建防火墙，以防止攻击者从 Internet 向您的 API 服务器发送连接请求。您可以使用常规防火墙规则或端口防火墙规则。如果您使用的是 GKE 之类的东西，您可以使用主授权网络功能来限制可以访问 API 服务器的 IP 地址。
18) 限制 API 访问
Kubernetes 的大多数云实现已经通过使用 RBAC、身份和访问管理 (IAM) 或 Active Directory (AD) 来限制对集群的 Kubernetes API 的访问。如果您的集群不使用这些方法，请使用开源项目进行设置，以便与各种身份验证方法进行交互。
19) 限制 SSH 访问
另一个重要的安全措施是限制对 Kubernetes 节点的 SSH 访问。您通常不会在任何节点上打开端口 22，但在某些时候可能需要它来调试问题。通过您的云提供商配置您的节点以阻止对端口 22 的访问，除非通过您组织的VPN或堡垒主机。您将能够快速获得 SSH 访问权限，但外部攻击者不会。
20) 审核策略日志
定期审计存储在 /var/log/audit.log 中的所有日志，以识别威胁、监控资源消耗并捕获 Kubernetes 集群的关键事件心跳。Kubernetes 集群默认策略在 /etc/kubernetes/audit-policy.yaml 文件中定义。您可以根据特定要求自定义它们。您还可以使用开源工具 Fluentd 来为您的容器维护一个集中的日志记录层。
Kubernetes 最佳实践：需要不断学习
这些 Kubernetes 最佳实践只是众多可用于帮助使 Kubernetes 成为在应用程序开发中使用更容易、更有价值的系统的一部分。尽管如此，要想有效地使用 Kubernetes，还有很多东西需要学习。
对于已经陷入现代应用程序开发所需的许多任务的开发团队来说，这可能是压倒性的——即使有越来越多的工具和服务来加速所需的流程。但是，从这些技巧开始，您将在使用 Kubernetes 推进复杂的应用程序开发项目的道路上走得很好。
标签：
版权声明：本文由用户上传，如有侵权请联系删除！