原文链接:https://overcast.blog/13-kubernetes-tricks-you-didnt-know-647de6364472
## 使用 PreStop 优雅关闭 Pod
yaml
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"]
PreStop 允许 Pod 在终止前执行一个命令或者是脚本,使用它就可以在应用退出前释放一些资源,确保应用可以优雅退出。
比如可以在 Nginx 的 Pod 退出前将当前的请求执行完毕。
使用临时容器调试 Pod
临时容器可以不修改一个运行的容器的前提下调试容器,可以很方便的调试一些生产环境的 bug,可以避免重启应用。生产环境谨慎使用,只有在当前环境下无法排查问题的时候才使用。
kubectl alpha debug -it podname --image=busybox --target=containername
基于自定义的 Metrics 自动扩容Pod
kubernetes 是提供了 HPA 机制可以跟进 CPU 内存等标准数据进行自动扩缩容,但有时需要根据自定义的数据进行扩缩容。 比如某个接口的延迟、队列大小等。
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
用 Init Containers 配置启动脚本
Kubernetes的Init Container,是容器编排中的关键组件,为应用初始化阶段提供了强大支撑。它是Pod中完成初始化任务的专用容器。
执行顺序机制
Init Container是串行执行的。每个Init Container必须在前一个成功完成后才能启动,而普通容器是并行启动的。这种机制在处理复杂依赖时特别有用。
初始化容器可以在应用容器启动前运行,可以使用它来初始化应用需要的配置、等待依赖的服务启动完成等工作:比如这个初始化容器会等待 myservice 可用后才会启动应用。 看个例子:一个需要等待Redis就绪的Web应用。
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;']
需要注意的是如果初始化容器会阻塞应用启动,所以要避免在初始化容器里执行耗时操作。
apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
initContainers:
- name: wait-redis
image: redis:alpine
command: ['sh', '-c', 'until redis-cli -h redis-svc ping; do sleep 2; done;']
containers:
- name: web
image: nginx:alpine
运行特性
Init Container只运行一次。完成任务就退出,不会重启。普通容器则会一直运行,必要时还会按策略重启。
有个坑要注意:Init Container执行失败会导致Pod重启,已完成的Init Container也会重新执行。所以写代码时要考虑重复执行的情况。资源分配策略
Init Container的资源分配有个特殊规则:取所有Init Container中的最大值。这个配置中,Pod实际申请的内存是512Mi,而不是两个容器的总和。
spec:
initContainers:
- name: init-cache
resources:
requests:
memory: "512Mi"
- name: init-db
resources:
requests:
memory: "256Mi"
应用场景
实战中,Init Container主要用在这些地方:- 前置准备 配置文件生成、数据库初始化、目录权限设置
- 服务检查 确认依赖服务是否就绪,比如数据库连接性检查
- 安全配置 证书分发、密钥初始化
实战经验
- 保持专注:一个Init Container只做一件事
- 要可重试:设计时考虑重复执行的情况
- 加超时限制:防止无限等待卡住整个Pod
- 资源预留:按实际需求设置,避免资源不足
initContainers:
- name: sysctl
image: busybox
command: ["sysctl", "-w", "vm.max_map_count=262144"]
securityContext:
privileged: true
Node 亲和性调度
当需要将某些应用部署到硬件配置较高的节点时(比如需要 SSD 硬盘),就可以使用节点亲和性来部署应用:这个 Pod 会被部署到有这个
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
<font style="color:rgb(30, 107, 184);">disktype=ssd</font>
标签的 节点上。
动态配置:ConfigMap 和 Secrets
ConfigMap 和 Secrets可以动态注入到 Pod 中,避免对这些配置硬编码。 ConfigMap 适合非敏感的数据,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
<font style="color:rgb(30, 107, 184);">/etc/config/config.json</font>
读取数据了。
当然也可以把这些数据写入到环境变量中。以上这些个人技巧用的最多的是:
- 临时容器调试 Pod,特别是业务容器缺少一些命令时。
- Init Container 等待依赖的服务启动完成。
- Node 亲和性调度。
- ConfigMap 是基础操作了。