作为滚动更新的一部分,第 1 版 pod 与第 2 版 pod 一起汇总。
我们需要查看 Pod(版本一)中服务关闭过程的日志。
滚动更新是否会删除版本一的 pod?
如果是,我们可以查看已删除 pod(版本一)的日志吗?验证版本一 pod 中服务的关闭过程...
作为滚动更新的一部分,第 1 版 pod 与第 2 版 pod 一起汇总。
我们需要查看 Pod(版本一)中服务关闭过程的日志。
滚动更新是否会删除版本一的 pod?
如果是,我们可以查看已删除 pod(版本一)的日志吗?验证版本一 pod 中服务的关闭过程...
- 滚动更新是否会删除版本一的 pod?
简短的回答是:是的。
当
.spec.strategy.type==RollingUpdate
. 您可以指定maxUnavailable
和maxSurge
控制滚动更新过程。
请参阅以下示例:
spec:
replicas: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
在此示例中,将maxSurge: 1
在所需数量 2 之上增加一个 Pod ( ),并且可用 Pod 的数量不能低于该数量 ( maxUnavailable: 0
)。
选择这个配置,Kubernetes 将启动一个额外的 Pod,然后停止一个“旧的”。如果有另一个节点可用于部署此 Pod,系统将能够在部署期间处理相同的工作负载。如果没有,该 Pod 将部署在已使用的节点上,代价是来自同一节点上托管的其他 Pod 的资源。
你也可以尝试这样的事情:
spec:
replicas: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 0
maxUnavailable: 1
在上面的示例中,将没有额外的 Pod ( maxSurge: 0
),并且一次只有一个 Pod 不可用 ( maxUnavailable: 1
)。
在这种情况下,Kubernetes 会先停止一个 Pod,然后再启动一个新的 Pod。这样做的好处是基础架构不需要扩展,但最大工作负载会更低。
- 如果是,我们可以查看已删除 pod(版本一)的日志吗?验证版本一 pod 中服务的关闭过程...
请参阅调试运行 Pods文档。您可以找到几种检查日志/事件的有用方法,例如:
通过执行kubectl describe pods ${POD_NAME}
和检查失败背后的原因来调试 Pod 。
检查 pod 日志:使用kubectl logs ${POD_NAME} ${CONTAINER_NAME}
或kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
使用容器 exec 进行调试:通过在特定容器内运行命令kubectl exec
使用临时调试容器进行调试kubectl exec
:当容器崩溃或容器映像不包含调试实用程序(例如distroless 映像)不足时,临时容器可用于交互式故障排除。
通过节点上的 shell 进行调试:如果这些方法都不起作用,您可以找到运行 pod 的主机并通过 SSH 连接到该主机。
但是,--previous
仅当先前的容器实例仍然存在于 Pod 中时,标志才有效。查看此答案以获取更多选项。
另外,请参阅此主题:如何列出 Kubernetes 最近删除的 pod?