简介Kubernetes简称K8s是一个开源的容器编排平台用于自动化部署、扩展、管理容器化应用的工具。假设你有很多个应用比如用 Docker 打包的服务Kubernetes 能帮你✅自动部署像安装软件一样部署多个容器。管理资源统一分配 CPU、内存等资源。自动重启服务挂了自动重启。⬆️滚动升级不中断服务的情况下发布新版本。负载均衡用户访问自动分配到不同容器上。自动扩容缩容根据流量自动增加或减少容器数量。Kubernetes 通常运行在一个集群中包括一个或多个控制节点Master多个工作节点Node节点上运行的是容器比如用 Docker、containerd 等。Docker用来“打包”应用像造车。Kubernetes用来“调度管理”这些容器像管车队。Docker 管一个容器Kubernetes 管一堆容器。Kubernetes 架构采用了主从Master-Node模式具有高度的可扩展性和模块化。--------------------------------------------------------------- | Kubernetes 集群 | | | | ---------------- --------------------------- | | | Master 节点 | ------- | Node 节点工作节点 | | | ---------------- --------------------------- | | 控制面Control Plane 每个节点上运行 Pod、容器等资源 | ---------------------------------------------------------------Master 控制面组件kube-apiserver对外暴露的统一接口所有操作都要通过它进行。是 Kubernetes 的“前门”。etcd高可用的键值存储系统。用于保存所有集群状态如节点信息、Pod 状态、配置等。kube-scheduler调度器负责将 Pod 分配到合适的节点上。kube-controller-manager管理集群中的各种控制器例如节点控制器副本控制器ReplicaSet端点控制器Endpoints服务账户控制器cloud-controller-manager可选用于和云平台交互如创建负载均衡器、磁盘等。Node 工作节点组件kubelet与 API Server 通信确保容器按照 Pod 规范运行。监控 Pod 和容器状态。kube-proxy管理服务的网络通信Service - Pod。实现 Kubernetes 的服务发现与负载均衡。容器运行时Container Runtime比如 Docker、containerd、CRI-O。负责真正拉取镜像并运行容器。其他关键概念PodK8s 最小的调度单位一个或多个容器的集合。Service提供稳定的访问入口负责负载均衡。Deployment控制 Pod 的副本数量实现滚动更新等。Namespace多租户隔离机制。 总结图示简化用户 - kubectl - kube-apiserver - etcd | ---------------------------- | | | scheduler controller-manager ... | 控制 Pod 部署 / 更新 / 状态 | 各 Node 节点 ---------------------- | kubelet kube-proxy | | 容器运行时 | ----------------------Pod 是 Kubernetes 中最小的调度单元。它是运行一个或多个紧密关联容器的封装体**比如dockerrun nginx在 Kubernetes 里它不会直接运行容器而是运行一个PodPod 里面装着这个容器。一个 Pod 可能包含一个容器最常见多个容器共享网络 存储用于协作比如主服务 辅助 sidecar Pod 特性特性说明共享网络Pod 里的容器用同一个 IPlocalhost 之间可以通信共享存储可挂载同一个 Volume持久化数据生命周期一致一个 Pod 里的容器是一起创建、一起销毁的短暂性Pod 本身是“易失”的挂了就没了通常通过 Deployment 来控制它们重建 Pod 工作流程创建一个 Pod直接或通过 Deployment 等kube-scheduler 把它调度到某个 Nodekubelet 在 Node 上启动里面的容器kube-proxy 负责网络连接Pod 运行、暴露端口、接收流量等Kubernetes 中导致 pod 重启的原因应用程序异常应用进程崩溃Pod 内部的应用程序由于未处理的异常、内存溢出OOM、访问非法地址等原因崩溃导致容器退出并被 K8s 重新拉起。主动退出exit 非 0如果容器的主进程PID 1主动退出并返回非零状态码K8s 会认为容器异常终止并可能触发重启。OOMOut Of Memory杀死内存不足OOMKilled当容器内存超出requests或limits限制K8s 可能会触发 OOM 终止容器。Node 级别 OOM如果 Node 本身内存不足K8s 可能会触发 OOM 终止某些 Pod优先终止低优先级的 Pod。Liveness Probe 检测失败存活探针Liveness Probe失败如果 Pod 配置了livenessProbe但探测失败例如健康检查接口未响应或返回错误K8s 会认为该容器不健康并重启它。Readiness Probe 失败就绪探针Readiness Probe失败虽然 Readiness Probe 失败不会直接导致重启但如果 Pod 一直无法进入就绪状态可能会被调度器驱逐或被运维人员删除并重新创建。节点问题Node 故障如果运行 Pod 的 Node 发生故障如宕机、网络异常等K8s 会将该 Node 标记为NotReady并可能在其他 Node 上重新调度 Pod。Node 重启如果 Node 由于系统更新、管理员操作等原因重启Pod 也会随之重启。可以使用以下命令查看 Pod 的状态和重启原因kubectl get podpod_name-owide kubectl describe podpod_namekubectl logspod_name--previous# 查看上次退出的日志kubectl get events --sort-by.metadata.creationTimestamp# 查看最近的事件如果 Pod 处于CrashLoopBackOff状态可以进一步检查kubectl get podpod_name-oyaml|grepreason如果怀疑是 OOMKilledkubectl describe podpod_name|grep-ioom如果 Pod 运行的是 Java 应用JVM 的堆内存Heap和 Kubernetes 分配的内存可能存在不匹配的问题JVM 默认会基于物理内存计算-Xmx最大堆内存但 K8s 容器中的可用内存是受limits.memory限制的。如果 JVM 误以为它可以使用整个节点的内存而不是容器的限制可能导致堆内存Heap 其他非堆内存Metaspace、Stack总和超出 K8s 限制最终触发 OOMKilled。如何避免 OOMKilled使用requests.memory和limits.memoryrequests.memory表示Pod 启动时的最小预留内存用于调度时分配。limits.memory表示Pod 最大可使用的内存超出后会触发 OOMKilled。resources:requests:memory:512Mi# 申请 512MBlimits:memory:1Gi# 限制最大 1GB避免limits.memory过低否则 JVM 可能会因 GC 频繁触发 OOM。如果业务允许可以不设置limits.memory仅使用requests.memory这样 Kubernetes 不会强行杀死超限的进程而是让 JVM 进行 GC 以尝试释放内存。监控和优化内存使用监控 JVM 内存占用使用Prometheus Grafana监控 Pod 内存使用情况结合JVM MetricsMicrometer、JMX Exporter监控 Heap、GC 频率优化代码通过调优 GCG1GC、ZGC减少堆外内存泄露避免大量对象滞留减少OutOfMemoryError: MetaspaceKubernetes 中 Pod 节点相关问题重启是否导致 Pod 名称发生变化在 Kubernetes 中Pod 的名称是否变化取决于它是如何创建的。手动创建的 Pod裸 Pod如果你是用kubectl apply -f pod.yaml创建的裸 Pod那么Pod 重启节点重启后不会自动恢复如果节点崩溃了Pod 会直接消失不会自动迁移到其他节点如果你自己重新创建 Pod名称可能会改变取决于你是否指定相同名称Pod 是不可恢复的资源—— 不推荐在生产中使用裸 Pod。由控制器管理的 Pod如 Deployment、StatefulSetDeployment / ReplicaSet 管理的 Pod如果节点重启、Pod 宕机Deployment 会重建一个新的 Pod新的 Pod 名称会变化因为它们是动态生成的比如my-app-7cc7b569b6-lmwvh → my-app-7cc7b569b6-k9zdfStatefulSet 管理的 PodStatefulSet 会保留 Pod 名称有状态名称不会变例如my-db-0、my-db-1 这种格式即使节点重启、Pod 被重新调度名称还是my-db-0。在现代生产环境中使用最多的是 Deployment ReplicaSet 管理的 Pod原因如下✅Deployment 是默认的无状态服务部署方式适合大多数业务场景如 Web 服务、API 服务、Worker 等支持滚动更新、回滚、扩缩容、健康检查简单易用社区支持广泛与 HPA水平自动扩展无缝配合。✅StatefulSet 用于有状态服务使用相对少一些适用于数据库、Kafka、ZooKeeper 这类有状态服务支持固定 Pod 名称和稳定持久化存储如my-app-0,my-app-1支持有序部署、扩容、缩容配置和管理更复杂不适合大规模无状态服务。✅DaemonSet 适合做守护进程用于每个节点运行一个 Pod比如日志采集Fluentd、监控 AgentPrometheus Node Exporter等用量少但场景明确。❌裸 Pod 几乎不用于生产不具备自愈能力无法自动调度、自动扩缩容容易丢失不安全。在现代生产环境中大多数情况下一个 Pod 只运行一个主要容器但也存在运行多个容器的情况具体看应用场景。单容器 Pod最常见绝大多数业务服务Web 服务器、API 服务、后台任务都是一个 Pod 只运行一个主容器简单、易管理、资源隔离清晰Kubernetes 的设计理念是“一组紧密相关的容器组成一个 Pod”但大多数场景一个容器足够了。多容器 PodSidecar 模式等多个容器共享一个 Pod 网络和存储彼此协作常见场景包括Sidecar 容器日志采集如 Fluentd sidecar 跟主容器一起工作配置更新如 Envoy 代理、Istio Sidecar监控 Agent数据同步Adapter 容器对主应用进行辅助处理例如缓存、代理等。多容器 Pod 让业务容器和辅助容器能紧密协同且共享生命周期。在一个 Pod 里运行多个容器时Pod 的生命周期是绑定在这些容器上的所以只要 Pod 里任意一个容器崩溃或异常整个 Pod 都会被认为“异常”Kubernetes 会根据 Pod 的重启策略restartPolicy来决定是重启单个容器还是整个 Pod 重启但实际上Pod 里的容器共享同一个 Pod 生命周期和调度单元当关键容器挂掉通常会触发 Pod 重启Pod 里的所有容器都会被杀死并重新启动这意味着任何一个容器异常都会导致整个 Pod 重启。