1. 使用 PreStop Hooks 优雅地关闭 Pod
PreStop 钩子允许在 Pod 即将终止之前在其中执行特定命令或脚本。这种能力对于确保应用程序优雅关闭、在必要时保存状态，或执行清理任务以避免数据损坏并确保平稳重启至关重要。
案例：
apiVersion: v1
kind: Pod
metadata:
name: graceful-shutdown-example
spec:
containers:
- name: sample-container
image: nginx
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 30 && nginx -s quit"]这个配置确保了 nginx 服务器在关闭之前有 30 秒的时间来完成正在处理的请求。
什么情况使用呢？
在对服务连续性至关重要的环境中实施PreStop钩子，以确保在部署、扩展或Pod重启期间零或最小的停机时间。
注意：
Kubernetes允许Pod的终止宽限期。如果PreStop钩子脚本执行时间超过这个宽限期，Kubernetes将强制终止Pod。
2. 使用Kubelet进行自动Secret轮换
Kubernetes支持对Secret进行自动轮换，而无需重新启动使用这些Secret的Pod。这一功能特别有助于保持安全标准，定期更改敏感信息，而不影响应用程序的可用性。
案例：
假设您已经在 Kubernetes 中更新了一个Secret。Kubernetes 将自动更新挂载在 Pod 中的Secret，无需任何干预，确保应用程序始终具有最新的凭据，无需手动更新或重新启动。
什么情况使用呢？
这一功能对于需要高水平安全合规性的应用程序至关重要，需要频繁进行Secret轮换，比如数据库、API密钥或TLS证书。
注意：
应用程序必须设计成能够动态读取更新的Secret。一些应用程序在启动时会缓存Secret，这意味着它们在没有重新启动的情况下无法识别更新的Secret。确保您的应用程序定期检查Secret的更新，或者对变化做出适当的反应。
3. 使用临时容器调试 Pod
Ephemeral containers 提供了一种临时将调试容器附加到运行中的 Pod 上的方式，而不会改变其原始规范。这对于在生产环境中调试实时问题非常有帮助，因为您不能扰乱服务。
案例：
kubectl alpha debug -it podname --image=busybox --target=containername这个命令会向您现有的 Pod 中添加一个 busybox 容器，使您能够执行命令并检查 Pod 的环境，而不会改变其运行状态。
什么情况使用呢？
在实时环境中诊断问题时，特别是当标准日志和指标无法提供足够信息时，可以利用短暂容器。这是一个强大的工具，用于实时深入分析生产问题。
注意：
由于临时容器可以访问Pod的资源和敏感数据，因此在生产环境中要谨慎使用它们。确保只有授权人员可以部署临时容器，以避免潜在的安全风险。
4. Horizontal Pod Autoscaling 基于自定义指标
HPA可以根据自定义指标而非仅仅是标准的 CPU 和内存使用情况来调整Pod副本。这对于需要根据特定业务指标或性能指标进行调整的应用程序特别有用，比如队列长度、请求延迟或自定义应用程序指标。
案例：
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: custom-metric-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: your-application
minReplicas: 1
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: your_custom_metric
target:
type: AverageValue
averageValue: 10这个 HPA 配置根据自定义指标 your_custom_metric 的平均值来调整您的应用程序的规模。
什么情况使用呢？
为那些传统基于资源的度量无法准确反映负载情况或基于业务需求进行精细调整的应用程序，采用自定义度量标度。
注意：
建立自定义指标涉及与支持自定义指标的指标服务器集成，例如Prometheus。确保您的指标是可靠的负载指标，以防止过度或不足扩展。
使用初始化容器来运行脚本
初始化容器在 Pod 中的应用容器之前运行，非常适合需要在应用启动之前完成的初始化配置脚本。这可能包括数据库迁移、配置文件创建或等待外部服务可用等任务。初始化容器可以运行一系列初始化任务，确保在主应用容器启动之前每个步骤都成功完成。
案例：
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp-container
image: myapp
initContainers:
- name: init-myservice
image: busybox
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']这个示例使用一个初始化容器来等待一个名为"myservice"的服务在启动主应用容器之前变得可用。
什么情况使用呢？
初始化容器在您的应用容器在启动之前依赖于外部服务或配置可用时非常重要。它们确保您的应用在环境准备就绪的情况下启动。
注意：
整个 Pod 的启动将被阻塞，直到所有 init 容器成功完成。确保 init 容器高效且能够优雅地处理失败，以防止它们成为瓶颈或导致 Pod 启动失败。
6. 适用于特定工作负载调度的节点亲和性
节点亲和性允许您指定规则，根据节点上的标签限制您的 Pod 可以调度到哪些节点上。这对于将工作负载定向到具有特定硬件（如 GPU）的节点，确保数据局部性，或遵守合规性和数据主权要求非常有用。
案例：
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd这个 Pod 只会被调度到具有标签 disktype=ssd 的节点上。
什么情况使用呢？
当您的应用程序需要特定节点功能时，请使用节点亲和性。
注意：
过度使用节点亲和性可能导致集群利用率低和调度复杂性增加。确保您的集群具有标签和亲和性的平衡分布，以保持资源利用的高效性。
7. Pod的污点和容忍配置
Taints和tolerations共同作用，确保Pods不会被调度到不适当的节点上。节点上的Taint会排斥不容忍该Taint的Pods。Tolerations应用于Pods，使它们能够在带有Taint的节点上调度。这种机制对于将节点专门用于特定工作负载（例如GPU密集型应用程序）或确保只有特定的Pods在带有敏感数据的节点上运行至关重要。
案例：
# Applying a taint to a node
kubectl taint nodes node1 key=value:NoSchedule# Pod specification with toleration
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: nginx
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"这个配置确保了 mypod 可以被调度到具有特定污点的 node1 上，其他 pod 无法容忍这个污点。
什么情况使用呢？
Taints和tolerations在多租户集群中特别有用，对于安全性或性能原因而隔离工作负载至关重要。它们还有助于运行需要专用资源的专业工作负载。
注意：
配置污点和容忍度不当可能导致调度问题，导致Pod未按预期调度或某些节点被低效利用。定期审查您的污点和容忍度设置，确保其符合您的调度要求。
8. 工作负载的 Pod 优先级和抢占
Kubernetes允许您为Pod分配优先级，如果必要，较高优先级的Pod可以抢占（驱逐）较低优先级的Pod。这确保了关键工作负载在高度拥挤的集群中也能获得所需的资源。
案例：
# PriorityClass definition
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."# Pod specification with priorityClassName
apiVersion: v1
kind: Pod
metadata:
name: high-priority-pod
spec:
containers:
- name: high-priority
image: nginx
priorityClassName: high-priority这个配置定义了一个高优先级类，并将其分配给一个 pod，确保它可以抢占其他低优先级的 pods。
什么情况使用呢？
使用Pod优先级和抢占功能来管理那些对您的业务运营至关重要的应用程序，特别是在资源争用频繁的集群环境中运行时。
注意：
不当使用可能导致次要应用程序资源匮乏。平衡不同工作负载的需求，并考虑对集群健康和应用程序性能的整体影响是至关重要的。
9. 动态配置的ConfigMaps和Secrets
ConfigMaps和Secrets提供了将配置数据注入到Pod中的机制。这使得配置外部化，使得应用程序更容易配置，而无需硬编码配置数据。ConfigMaps适用于非敏感数据，而Secrets则用于敏感数据。
案例：
# ConfigMap Example
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
config.json: |
{
"key": "value",
"databaseURL": "http://mydatabase.example.com"
}# Pod Spec using ConfigMap
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp-container
image: myapp
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: app-config这个配置将 app-config 的内容注入到 pod 中，使应用程序能够从 /etc/config/config.json 中读取其配置。
什么情况使用呢？每当您需要将应用程序的配置或机密数据外部化，使其更易于管理、更新和维护，而无需重新构建容器映像时。
注意：虽然 ConfigMaps 非常适合存储非敏感数据，但应避免将需要保密的任何数据存储在其中。始终使用 Secrets 来存储、令牌、密钥和其他敏感数据，并且要了解保护 Secrets 的最佳实践，例如在静态状态下对其进行加密。
10. Kubectl Debug 用于直接容器调试
kubectl debug 提供了一种方法，可以创建一个临时的 pod 副本，并用调试版本的容器替换其原有的容器，或者在不影响原始 pod 的情况下添加新的故障排查工具。这对于在不影响应用程序运行状态的情况下调试实时环境中的问题非常有用。
案例：
kubectl debug pod/myapp-pod -it --copy-to=myapp-debug --container=myapp-container --image=busybox这个命令创建了一个myapp-pod的副本，为了调试目的，用busybox镜像替换了myapp-container。
什么情况使用呢？
当你需要对崩溃的或在生产中表现不如预期的pod进行故障排查时进行实时调试，对服务的影响最小。
注意：
调试Pod仍然可能影响整个集群的资源分配，并可能访问敏感数据。请确保严格控制对调试命令的访问，并在使用后清理调试Pod。
11. 通过请求和限制进行高效的资源管理
Kubernetes允许您为pod中的每个容器指定CPU和内存（RAM）的请求和限制。请求保证容器获得指定数量的资源，而限制确保容器永远不会使用超过分配的数量。这有助于有效管理资源分配，并防止任何单一应用程序垄断集群资源。
案例：
apiVersion: v1
kind: Pod
metadata:
name: resource-demo
spec:
containers:
- name: demo-container
image: nginx
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"这个pod规格要求为demo-container分配特定数量的CPU和内存，以确保它具有实现最佳性能所需的资源，同时防止其超过指定的限制。
什么情况使用呢？
请对所有容器应用请求和限制，以确保应用程序的性能可预测，并避免在集群中运行的应用程序之间的资源争抢。
注意：将限制设置得过低可能会导致如果集群无法提供请求的资源，Pods可能会被终止或无法调度。相反，将它们设置得过高可能会导致集群资源的利用效率低下。请监控应用程序的性能，并根据需要调整请求和限制
12. 用于扩展Kubernetes的自定义资源定义（CRD）
CRD 允许你通过自己的 API 对象扩展 Kubernetes，从而实现创建像原生 Kubernetes 对象一样运作的自定义资源。这对于向你的集群添加特定领域的功能、促进自定义操作以及与外部系统集成具有强大的作用。
案例：
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct这个CRD在集群中定义了一种新的资源类型CronTab，它可以像传统的cron作业一样用于调度任务，但是采用了Kubernetes原生的管理方式。
什么情况使用呢？CRD 是扩展 Kubernetes 功能以满足您的应用程序或服务特定需求的理想选择，例如引入特定领域的资源类型或与外部服务和 API 进行集成。
注意：
设计和管理CRD需要对Kubernetes内部结构和API机制有深入的理解。设计不良的CRDs可能会导致性能问题，并使集群管理变得复杂。始终确保对CRDs进行彻底的测试，并考虑其对集群稳定性和性能的影响。
13. 用于动态交互和自动化的Kubernetes API
Kubernetes API使您能够动态地与您的集群进行交互，从而可以以编程方式自动化扩展、部署和管理任务。通过利用API，您可以创建与您的集群实时交互的脚本或应用程序，实现复杂的自动化和集成场景，这超出了静态配置文件和手动命令所能实现的范围。
案例：
以下是一个基本示例，使用curl与Kubernetes API交互，以获取默认命名空间中的pod列表。这假设您有一个访问令牌，并且可以在https://处访问Kubernetes API。
curl -X GET https:///api/v1/namespaces/default/pods \
-H "Authorization: Bearer " \
-H 'Accept: application/json' 对于更复杂的交互，可以考虑使用各种编程语言（如Go、Python、Java）中可用的客户端库，这些库抽象化了HTTP请求，并提供了更便捷的接口来操作Kubernetes API。
什么情况使用呢？
Kubernetes API对于开发自定义自动化、动态扩展策略、CI/CD集成，甚至扩展Kubernetes功能的自定义控制器具有难以置信的强大功能。当你需要将Kubernetes操作与外部系统集成或创建自定义部署工作流时，它尤其有用。
注意：
与Kubernetes API进行交互时，需要谨慎处理身份验证和授权。确保你的脚本和应用程序坚持最小权限原则，只请求它们运行所需的权限。此外，当进行频繁或复杂的查询时，要注意可能对API服务器的负载产生的影响，因为这可能会影响集群性能。始终验证并清理你的API客户端的输入，以避免安全漏洞，特别是如果它们与外部系统或用户生成的内容进行交互。
