让我们讨论一下使用 Kubernetes 时应遵循的一些最佳实践。
Kubernetes 是一个开源容器编排平台，可以自动化容器部署、持续扩展和取消扩展、容器负载均衡等。
容器化用于许多拥有数千个容器的生产服务器中，因此正确管理它们变得非常重要，这就是 Kubernetes 所做的。
如果您使用 Kubernetes，则应该采用最佳实践来改进容器编排。
这里我们列出了您应该遵循的一些 Kubernetes 最佳实践。
#1.设置资源请求和限制
如果您在资源有限的生产集群上部署大型应用程序，那么如果节点内存或 CPU 不足，您的应用程序将停止工作。此应用程序停机可能会对您的业务产生重大影响。但是，您可以通过设置资源请求和限制来解决此问题。
资源请求和限制是 Kubernetes 控制内存和 CPU 等资源使用的机制。如果一个 Pod 消耗了所有的 CPU 和内存，其他 Pod 将耗尽资源并且无法运行该应用程序。因此，您应该对 pod 设置资源请求和限制以提高可靠性。
作为参考，限制始终高于要求。如果请求超出定义的限制，容器将不会运行。您可以为 Pod 中的每个容器设置请求和限制。 CPU 使用毫核定义，内存使用字节（兆字节/兆字节）定义。
以下示例将限制设置为 500 毫核 CPU 和 128 MB，并将请求配额设置为 300 毫核 CPU 和 64 MB。
containers:
- name: prodcontainer1
image: ubuntu
resources:
requests:
memory: “64Mi”
cpu: “300m”
limits:
memory: “128Mi”
cpu: “500m” 
#2.使用 livenessProbe 和 readinessProbe
健康检查在 Kubernetes 中非常重要。
提供两种类型的健康检查： Readiness探针和Liveness探针。
就绪探针用于检查您的应用程序是否准备好开始处理流量。此探测器必须先通过 Kubernetes，然后才能开始向在容器内运行应用程序的 Pod 发送流量。 Kubernetes 停止向 Pod 发送流量，直到此准备情况检查失败。
Liveness探针用于检查应用程序是否仍在运行（alive）或已停止（stopped）。如果您的应用程序运行正常，Kubernetes 不会执行任何操作。如果您的应用程序停止，Kubernetes 会启动一个新的 Pod 并在其中运行您的应用程序。
如果这些检查未正确执行，Pod 可能会在准备就绪之前终止或开始接受用户请求。
您可以使用三种类型的探测器来检查运行状况和就绪情况： HTTP 、 Command和TCP 。
以下是最常见的 HTTP 探测的一些示例。
在这里，应用程序内部是一个 HTTP 服务器。如果 Kubernetes 对 HTTP 服务器的路径执行 ping 操作并获得 HTTP 响应，则将应用程序标记为健康，否则将其标记为不健康。
apiVersion: v1 kind: Pod metadata: name: container10 spec: containers: - image: ubuntu name: container10 livenessProbe: httpGet: path: /prodhealth port: 8080
#3.构建一个小型容器镜像
我们建议使用较小的容器映像，因为它们需要较少的存储空间并且可以更快地提取和构建映像。较小的图像尺寸也降低了安全攻击的可能性。
有两种方法可以减小容器的大小：使用较小的基础映像和使用构建器模式。目前，最新的 NodeJS 基础镜像大小为 345 MB，而 NodeJS Alpine 镜像只有 28 MB，小了十分之一还多。因此，请始终使用小图像并添加运行应用程序所需的依赖项。
为了使容器镜像变得更小，您可以使用构建器模式。容器镜像甚至更小，因为代码构建在第一个容器中，编译后的代码打包到最后一个容器中，而无需创建编译后的代码所需的所有编译器和工具。
#4.安全访问权限级别 (RBAC)
构建安全的 Kubernetes 集群极其重要。
必须正确配置对集群的访问。您必须定义每个用户每秒/分钟/小时的请求数、每个 IP 地址允许的并发会话数、请求大小以及路径和主机名限制。这有助于保护您的集群免受 DDoS 攻击。
在 Kubernetes 集群上工作的开发人员和 DevOps 工程师必须具有定义的访问级别。这就是 Kubernetes 基于角色的访问控制 (RBAC) 功能派上用场的地方。您可以使用角色和集群角色定义访问配置文件。为了使RBAC配置更容易，您可以使用开源的rbac-manager，它有助于简化语法，也可以使用Rancher，它默认提供RBAC。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]Kubernetes Secrets 存储敏感信息，例如身份验证令牌、密码和 SSH 密钥。切勿在 IaC 存储库上检查 Kubernetes Secrets。如果未选中，它将暴露给有权访问您的 Git 存储库的任何人。
DevSecOps 目前是谈论 DevOps 和安全性时的流行词。组织了解其重要性并正在采用这一趋势。
#5.保持最新状态
我们建议您始终在集群上安装最新版本的 Kubernetes。
最新版本的 Kubernetes 包括新功能、先前功能的更新、安全更新、错误修复等。如果您将 Kubernetes 与云提供商一起使用，更新将非常容易。
#6.使用命名空间
Kubernetes 提供了三个不同的命名空间： default 、 kube-system和kube-public 。
这些命名空间在 Kubernetes 集群中对于跨团队组织和安全性发挥着非常重要的作用。
对于只有 5-10 个微服务的小型团队，使用默认命名空间是有意义的。然而，在快速增长的团队或具有在测试或生产环境中工作的多个团队的大型组织中，每个团队需要单独的命名空间以便于管理。
否则，您可能会在没有意识到的情况下意外覆盖或破坏其他团队的应用程序/功能。我们建议创建多个命名空间并使用它们将您的服务划分为可管理的块。
以下是在命名空间中创建资源的示例。
apiVersion: v1
kind: Pod
metadata:
name: pod01
namespace: prod
labels:
image: pod01
spec:
containers:
- name: prod01
Image: ubuntu#7.使用标签
随着 Kubernetes 部署的增长，它不可避免地会包含多个服务、Pod 和其他资源。跟踪这些可能会很痛苦。更困难的是解释这些不同的资源如何交互以及如何使用 Kubernetes 复制、扩展和服务它们。 Kubernetes 标签对于解决这些问题非常有帮助。
标签是用于在 Kubernetes 界面中组织项目的键值对。
例如，应用程序：kube-app，阶段：测试，角色：前端。 Kubernetes 使用它们来描述集群中的不同对象和资源如何协同工作。
apiVersion: v1
kind: Pod
metadata:
name: test-pod
labels:
environment: testing
team: test01
spec:
containers:
- name: test01
image: "Ubuntu"
resources:
limits:
cpu: 1因此，通过始终标记资源和对象，可以减少运行 Kubernetes 的工作量。
#8.审计日志
日志审核对于识别 Kubernetes 集群中的威胁至关重要。审计有助于回答诸如发生了什么、为什么发生以及是谁造成的等问题。
与向 kube-apiserver 发出的请求相关的所有数据都存储在名为audit.log的日志文件中。该日志文件采用 JSON 格式构建。
默认情况下，Kubernetes 将审核日志存储在<em>/var/log/audit.log</em>中，审核策略存储在<em>/etc/kubernetes/audit-policy.yaml</em>中。 <em>/etc/kubernetes/audit-policy.yaml</em> 。
要启用审核日志记录，请使用以下参数启动 kube-apiserver：
--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log下面是一个配置为记录 pod 更改的audit.log文件示例。
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- "RequestReceived"
rules:
- level: RequestResponse
resources:
- group: ""
resources: ["pods"]
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]如果您的 Kubernetes 集群遇到问题，您可以随时返回并查看审核日志。这有助于恢复集群的正确状态。
#9.应用关联规则（节点/pod）
Kubernetes 提供了两种机制来更好地关联 pod 和节点： pod –节点亲和性。我们建议使用这些机制来提高性能。
节点关联性允许您根据定义的条件在节点上调度 pod。根据 Pod 的要求，选择匹配的节点并将其分配给 Kubernetes 集群。
apiVersion: v1
kind: Pod
metadata:
name: ubuntu
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 2
preference:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
containers:
- name: ubuntu
image: ubuntu
imagePullPolicy: IfNotPresentPod 亲和性允许您在同一节点上调度多个 Pod（以改善延迟）或决定将 Pod 保留在单独的节点上以提高性能（以实现高可用性）。
apiVersion: v1
kind: Pod
metadata:
name: ubuntu-pod
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:
- name: ubuntu-pod
image: ubuntu分析集群的工作负载后，您需要决定使用哪种关联策略。
＃10。终止 Kubernetes
Kubernetes 在不再需要 Pod 时终止它们。这可以通过命令或 API 调用来启动，选定的 pod 将处于终端状态，并且不会向它们发送流量。然后，SIGTERM 消息会发送到这些 pod，然后 pod 就会关闭。
Pod 将正常终止。默认宽限期为 30 秒。如果 Pod 仍在运行，Kubernetes 会发送 SIGKILL 消息来强制关闭 Pod。最后，Kubernetes 从 master 机器上的 API 服务器中删除这些 pod。
如果您的 Pod 持续花费超过 30 秒，您可以将此宽限期增加到 45 或 60 秒。
apiVersion: v1
kind: Pod
metadata:
name: container10
spec:
containers:
- image: ubuntu
name: container10
terminationGracePeriodSeconds: 60结论
我们希望这些最佳实践能够帮助您改进 Kubernetes 的容器编排。尝试在 Kubernetes 集群中实现这些以获得更好的结果。
接下来，考虑实现 DevOps 成功的最佳 Kubernetes 工具。
![2021 年如何设置 Raspberry Pi Web 服务器 [指南]](https://i0.wp.com/pcmanabu.com/wp-content/uploads/2019/10/web-server-02-309x198.png?w=1200&resize=1200,0&ssl=1)
