Kubernetes最佳实践
Kubernetes是一个开放源代码的容器编排平台，可自动执行容器部署，连续扩展和降级，容器负载平衡等操作
Kubernetes是一个开放源代码的容器编排平台，可自动执行容器部署，连续扩展和降级，容器负载平衡等操作。
由于在具有1000个容器的许多生产服务器上都使用了容器化，因此很好地管理它们变得非常重要，这就是Kubernetes所做的。
如果您正在使用Kubernetes，则必须采用最佳实践来更好地进行容器编排。
这是您必须遵循的一些Kubernetes最佳实践的列表。
＃1。设置资源请求和限制
在资源有限的生产集群上部署大型应用程序时，如果节点或内存不足，该应用程序将停止工作。应用程序的停机时间会对业务产生巨大影响。但是您可以通过具有资源请求和限制来解决此问题。
对资源的请求和限制是Kubernetes中控制诸如内存和CPU之类的资源使用情况的机制。如果一个Pod耗尽了所有CPU和内存，则其他Pod将会耗尽资源，并且将无法运行该应用程序。因此，您需要在Pod上设置资源请求和限制以提高可靠性。
仅供参考，限制将始终高于要求。如果您的请求高于定义的限制，则您的容器将无法运行。您可以为窗格中的每个容器设置请求和限制。使用千位定义CPU，使用字节（兆字节/兆字节）定义内存。
以下是将限制设置为500毫秒CPU和128兆字节，并为请求设置300百万CPU和64兆字节的配额的示例。
＃2。使用livenessProbe和readinessProbe
健康检查在Kubernetes中非常重要。
它提供两种健康检查–准备就绪探针和活动性探针。
准备情况探针用于检查应用程序是否准备好开始提供流量。该探针需要先传入Kubernetes，然后才能开始将流量发送到在容器内运行应用程序的Pod。Kubernetes将停止将流量发送到Pod，直到此准备状况健康检查失败。
活动度探针用于检查应用程序是否仍在运行（活动）或已停止（死机）。如果该应用程序正常运行，则Kubernetes不会执行任何操作。如果您的应用程序已死，Kubernetes将启动一个新的pod并在其中运行该应用程序。
如果未正确执行这些检查，则窗格可能会终止，或者甚至在准备就绪之前也会开始接收用户请求。
有三种类型的探针可用于活动性和准备情况检查：HTTP，Command和TCP。
让我展示一个最常见的示例，即HTTP探针。
您的应用程序将在其中包含一个HTTP服务器。当Kubernetes ping通HTTP服务器的路径并获得HTTP响应时，它将标记该应用程序运行状况为良好，否则为不正常。
＃3。构建小容器图像
最好使用较小的容器映像，因为它占用较少的存储空间，并且您将能够更快地提取和构建映像。由于图像的大小将较小，因此安全攻击的机会也将较小。
有两种减小容器大小的方法-使用较小的基本图像和构建器模式。当前，最新的NodeJS基本映像为345 MB，而NodeJS高山映像仅为28 MB，比原来小十倍。因此，请始终使用较小的映像并添加运行应用程序所需的依赖项。
要使容器图像更小，可以使用构建器模式。该代码在第一个容器中构建，然后将编译后的代码打包在最终容器中，而无需制作该编译后的代码所需的所有编译器和工具，从而使容器映像更小。
＃4。授予安全访问级别（RBAC）
拥有安全的Kubernetes集群非常重要。
对群集的访问应配置良好。您必须定义每位用户每秒/分钟/小时的请求数，每个IP地址允许的并发会话，请求大小以及路径和主机名的限制。这将有助于确保群集免受DDoS攻击的侵害。
在Kubernetes集群上工作的开发人员和DevOps工程师应具有定义的访问级别。Kubernetes的基于角色的访问控制（RBAC）功能在这里很有用。您可以使用Roles和ClusterRoles定义访问配置文件。为了简化配置RBAC的过程，您可以使用开源的rbac-managers来帮助您简化语法或使用Rancher（默认情况下它提供RBAC）。
Kubernetes Secrets存储机密信息，例如身份验证令牌，密码和ssh密钥。您永远不要在IaC信息库上检查Kubernetes Secrets ，否则，那些可以访问您的git信息库的人就会发现它。
DevSecOps是现在的流行语，它谈论DevOps和安全性。各组织在了解趋势的重要性时就采用了这种趋势。
＃5。不断更新
建议始终在群集上安装最新版本的Kubernetes。
Kubernetes的最新版本包括新功能，先前功能的更新，安全更新，错误修复等。如果您将Kubernetes与云提供商一起使用，则更新起来非常容易。
＃6。使用命名空间
Kubernetes船舶三种不同的命名空间-默认情况下，KUBE-系统，和KUBE-公众。
这些名称空间在Kubernetes集群中对于团队之间的组织和安全起着非常重要的作用。
如果您是一个仅工作5-10个微服务的小型团队，则使用默认名称空间是有意义的。但是，快速成长的团队或大型组织将有几个团队在测试或生产环境中工作，因此每个团队都需要有一个单独的命名空间以简化管理。
如果他们不这样做，他们最终可能会意外覆盖甚至破坏另一个团队的应用程序/功能，甚至没有意识到。建议创建多个名称空间，并使用它们将您的服务分段为可管理的块。
这是在名称空间内创建资源的示例：
＃7。使用标签
随着您的Kubernetes部署的增长，它们将始终包含多个服务，pod和其他资源。跟踪这些信息可能会变得很麻烦。可能更具挑战性的是描述Kubernetes，这些各种资源如何相互作用，如何复制，扩展和服务它们。Kubernetes中的标签对于解决这些问题非常有帮助。
标签是用于在Kubernetes界面中组织项目的键值对。
例如，app：kube-app，阶段：test，角色：前端。它们用于描述Kubernetes集群中各种对象和资源如何协同工作。
因此，您可以通过始终标记资源和对象来减轻Kubernetes生产的痛苦。
＃8。审核记录
为了确定Kubernetes集群中的威胁，日志审计非常重要。审核有助于回答诸如发生的事情，发生的原因，发生的原因等问题。
与对kube-apiserver的请求有关的所有数据都存储在名为的日志文件中audit.log。该日志文件以JSON格式构建。
在Kubernetes中，默认情况下，审核日志存储在中/var/log/audit.log，审核策略位于处/etc/kubernetes/audit-policy.yaml。
要启用审核日志记录，请使用以下参数启动kube-apiserver：
--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log
这是audit.log配置用于记录窗格中更改的示例文件：
如果Kubernetes集群中有任何问题，您始终可以返回并检查审核日志。这将帮助您恢复群集的正确状态。
＃9。应用相似性规则（节点/窗格）
Kubernetes中有两种机制可以更好地将Pod 与节点相关联-Pod和Node关联。建议使用这些机制以获得更好的性能。
使用节点亲缘关系，您可以根据定义的条件在节点上调度容器，根据容器要求，在Kubernetes集群中选择并分配匹配的节点。
使用Pod关联性，您可以在同一节点上调度多个Pod（以改善延迟），或决定将Pod放在单独的节点上（以实现高可用性）以提高性能。
在分析群集的工作负载之后，您需要确定要使用的亲和力策略。
＃10。Kubernetes终止
当不再需要Kubernetes时，它们会终止Pod。您可以通过命令或API调用来启动它，选定的Pod处于终止状态，并且没有流量发送到这些Pod。然后将SIGTERM消息发送到这些容器，然后容器关闭。
吊舱会正常终止，默认情况下，宽限期为30秒。如果Pod仍在运行，Kubernetes会发送SIGKILL消息来强制关闭Pod。最后，Kubernetes从主机上的API服务器中删除了这些Pod。
如果您的广告连播始终花费超过30秒的时间，则可以将该宽限期增加到45或60秒。
