编写 Kubernetes 部署脚本将 httpserver 部署到 Kubernetes 集群

Deployment

deployment controller 生成 rs，rs controller 去启动配置。

优雅启动

一个服务刚启动，可能会有一堆东西要加载，比如需要 load 大量数据等等，此时程序启动了，但是并未准备好处理外部请求，所以利用一些探针来测试程序是否启动完成，然后进入下一步：

Probe 探针

https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

 readinessProbe:  httpGet:        path: /healthzport: 8080  scheme: HTTP    initialDelaySeconds: 5    periodSeconds: 3

优雅中止

https://kubernetes.io/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/

容器终止流程

1. Pod 被删除，状态置为 Terminating。

2. kube-proxy 更新转发规则，将 Pod 从 service 的 endpoint 列表中摘除掉，新的流量不再转发到该 Pod。

3. 如果 Pod 配置了 preStop Hook ，将会执行。

4. kubelet 对 Pod 中各个 container 发送 SIGTERM 信号以通知容器进程开始优雅停止。

5. 等待容器进程完全停止，如果在 terminationGracePeriodSeconds 内 (默认 30s) 还未完全停止，就发送 SIGKILL 信号强制杀死进程。

6. 所有容器进程终止，清理 Pod 资源。

SIGTERM & SIGKILL

9 - SIGKILL 强制终端

15 - SIGTEM 请求中断

容器内的进程不能用 SIGTEM 中断的，都不能算优雅中止，所以这里有个常见问题，为什么有些容器 SIGTEM 信号不起作用。

如果容器启动入口使用了 shell，比如使用了类似  /bin/sh -c my-app  或  /docker-entrypoint.sh  这样的 ENTRYPOINT 或 CMD，这就可能就会导致容器内的业务进程收不到 SIGTERM 信号，原因是:

• 容器主进程是 shell，业务进程是在 shell 中启动的，成为了 shell 进程的子进程。

• shell 进程默认不会处理 SIGTERM 信号，自己不会退出，也不会将信号传递给子进程，导致业务进程不会触发停止逻辑。

• 当等到 K8S 优雅停止超时时间 (terminationGracePeriodSeconds，默认 30s)，发送 SIGKILL 强制杀死 shell 及其子进程。

perStop hook

lifecycle:  preStop:    exec:      command:      - /stop.sh

源需求和 QoS

• QoS 服务质量

• Guaranteed

• Burstable

• BestEffort

QoS 类为 Guaranteed 的 Pod：

• Pod 中的每个容器都必须指定内存限制和内存请求。

• 对于 Pod 中的每个容器，内存限制必须等于内存请求。

• Pod 中的每个容器都必须指定 CPU 限制和 CPU 请求。

• 对于 Pod 中的每个容器，CPU 限制必须等于 CPU 请求。

QoS 类为 Burstable 的 Pod

• Pod 不符合 Guaranteed QoS 类的标准。

• Pod 中至少一个容器具有内存或 CPU 请求。

QoS 类为 BestEffort 的 Pod

没有设置内存和 CPU 限制或请求

配置和代码分离，日志等级

https://kubernetes.io/zh/docs/concepts/configuration/configmap/