企业官网建设流程全解析

网站添加微信分享代码,网站建设陆金手指下拉壹玖,句容网站制作哪家好,山东济南seo优化前言 如果你刚接触 Kubernetes#xff08;简称 K8s#xff09;#xff0c;那一定绕不开 “Pod” 这个核心概念。Pod 是 K8s 集群里最小的部署单元#xff0c;就像一个 “容器工具箱”—— 它不直接跑业务#xff0c;而是把容器和集群的网络、存储资源打包在一起#xff0…前言如果你刚接触 Kubernetes简称 K8s那一定绕不开 “Pod” 这个核心概念。Pod 是 K8s 集群里最小的部署单元就像一个 “容器工具箱”—— 它不直接跑业务而是把容器和集群的网络、存储资源打包在一起让应用能在集群中稳定运行。不管是简单的 Nginx 服务还是需要多个组件协作的复杂应用都得靠 Pod 落地。今天这篇文章就用 “大白话 实战” 的方式带你吃透 Pod 的核心知识从概念到配置全搞懂。一、Pod 基础详解1.1 Pod 的基本概念简单说Pod 是 K8s 里 “最小的可部署单元”代表集群中的一个运行进程。你可以把它理解为 “容器的封装盒”里面能装一个或多个联系紧密的容器这些容器共享 Pod 的网络、存储等资源就像住在同一个房子里的室友共用客厅和网络。K8s 不会直接管理容器所有的高级功能比如自动重启、滚动升级都是通过控制器像 Deployment、StatefulSet 这些 “管理工具”围绕 Pod 实现的。所以搞懂 Pod就是入门 K8s 的第一步。1.2 Pod 的使用方式根据里面装的容器数量Pod 主要有两种用法其中单容器 Pod 最常见。1.2.1 单容器 Pod这是最普遍的用法一个 Pod 里只装一个容器。此时 Pod 就像给容器穿了件 “外套”K8s 管理的是这个 “外套”而不是里面的容器。比如部署一个 Nginx 服务就可以用单容器 Pod。简单配置示例直接复制就能用apiVersion:v1# K8s 的 API 版本Pod 用 v1 就行kind:Pod# 资源类型是 Podmetadata:name:single-container-pod# Pod 的名字自己随便起spec:containers:-name:nginx# 容器的名字image:nginx:1.14# 要使用的镜像相当于容器的“安装包”1.2.2 多容器 Pod一个 Pod 里装多个容器这些容器通常是 “工作搭档”—— 比如一个主应用容器跑业务和一个边车容器收集日志、处理配置。它们共享网络和存储能通过localhost直接通信不用走复杂的网络配置。简单配置示例apiVersion:v1kind:Podmetadata:name:multi-container-podspec:containers:-name:app# 主应用容器image:my-app:latest# 自己的业务镜像-name:sidecar# 边车容器辅助作用image:log-collector:latest# 日志收集镜像1.3 Pause 容器基础容器每个 Pod 里都藏着一个 “隐形地基”—— Pause 容器也叫基础容器。它不用我们手动配置K8s 会自动创建主要做两件关键事提供 Pod 级别的 “基础环境”Linux 命名空间让里面的所有容器能共享网络和存储维护 Pod 的网络端点让容器间通信更高效。你可以在集群节点上执行docker ps命令看到这个 “隐形容器”它的镜像通常是这样的registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0作用就是 “稳住” 整个 Pod 的基础资源。1.4 Pod 中的共享资源Pod 里的容器之所以能协作核心是共享了两种关键资源网络和存储。1.4.1 网络共享每个 Pod 会分配一个唯一的 IP 地址相当于这个 “房子” 的门牌号所有容器共享这个 IP 和端口就像室友共用一个门牌号互相拜访通信直接喊 “localhost 端口” 就行要和集群外的服务通信就得通过宿主机的端口映射相当于给房子装个对外的大门。1.4.2 存储共享Pod 可以创建多个 “共享文件夹”叫 Volume所有容器都能访问这些 “文件夹” 支持持久化存储就算容器重启里面的数据也不会丢比如数据库的存储卷重启后数据还在。1.5 Pod 的使用场景Pod 不是随便用的主要适合两种场景单一进程应用最常见一个 Pod 跑一个业务容器比如 Nginx、MySQL简单直接多进程协作多个容器一起完成任务比如主应用 日志收集器 配置更新器它们必须紧密配合缺一不可。1.6 Pod 的类型根据管理方式Pod 分两种生产环境里几乎都用第二种。1.6.1 自主式 Pod直接手动创建的 Pod就像 “没人管的孩子”如果它所在的节点出故障比如宕机这个 Pod 会被删除而且不会自动重建适合临时测试。1.6.2 控制器管理的 Pod由 K8s 的 “管理工具”控制器比如 Deployment创建的 Pod就像 “有监护人的孩子”支持自动修复节点故障了会在其他节点重建 Pod能管理多个副本比如同时跑 3 个 Nginx Pod负载均衡支持滚动升级更新应用时不中断服务是生产环境的首选。1.7 Pod 容器的分类一个 Pod 里的容器分工明确主要分三类1.7.1 基础容器Infrastructure Container就是前面说的 Pause 容器K8s 自动创建维护基础资源对我们透明不用管它。1.7.2 初始化容器Init Containers“准备工作专员”必须在应用容器启动前跑完而且要按顺序执行第一个做完第二个才开始。主要做这些事等待依赖服务就绪比如先等数据库启动再启动应用生成配置文件、设置权限等初始化操作如果初始化失败K8s 会根据重启策略重试直到成功。1.7.3 应用容器Main Containers我们真正要部署的业务容器比如 Nginx、MySQL是 Pod 的核心。只有所有初始化容器都成功后应用容器才会并行启动。1.7.4 示例等待myservice和mydb服务就绪的初始化容器下面用一个实战例子带你看懂初始化容器的作用我们要启动一个应用但它必须等myservice和mydb两个服务启动后才能运行。步骤 1创建带初始化容器的 Pod新建文件myapp-pod.yaml内容如下apiVersion:v1kind:Podmetadata:name:myapp-pod# Pod 名字labels:app:myappspec:# 应用容器要等初始化完成才启动containers:-name:myapp-containerimage:busybox:1.28# 轻量级工具镜像command:[sh,-c,echo 应用启动成功 sleep 3600]# 模拟应用运行# 初始化容器按顺序执行initContainers:# 第一个等 myservice 服务就绪-name:init-myserviceimage:busybox:1.28command:[sh,-c,until nslookup myservice; do echo 等 myservice...; sleep 2; done;]# 第二个等 mydb 服务就绪-name:init-mydbimage:busybox:1.28command:[sh,-c,until nslookup mydb; do echo 等 mydb...; sleep 2; done;]步骤 2查看 Pod 状态初始化阻塞执行命令创建 Podkubectl apply -f myapp-pod.yaml然后查看状态kubectl get pods会看到 Pod 状态是Init:0/2两个初始化容器都没完成因为myservice和mydb还没创建初始化容器一直在等。步骤 3创建依赖服务让初始化完成分别创建myservice和mydb服务模拟依赖就绪新建myservice.yamlapiVersion:v1kind:Servicemetadata:name:myservicespec:ports:-protocol:TCPport:80targetPort:9376执行kubectl apply -f myservice.yaml新建mydb.yamlapiVersion:v1kind:Servicemetadata:name:mydbspec:ports:-protocol:TCPport:80targetPort:9377执行kubectl apply -f mydb.yaml步骤 4验证应用启动再查看 Pod 状态kubectl get pods会发现状态变成Running应用启动成功。执行命令查看日志kubectl logs myapp-pod -c myapp-container会输出应用启动成功说明初始化容器完成了依赖检查。二、Pod 的核心配置Pod 的稳定运行关键靠两个核心配置镜像拉取策略和重启策略。2.1 镜像拉取策略imagePullPolicy容器是基于 “镜像” 启动的镜像相当于容器的 “安装包”这个策略决定了 K8s 怎么获取镜像有三种选择策略作用适用场景IfNotPresent本地有镜像就用没有才从网上拉默认生产环境高效Always每次启动都重新从网上拉镜像开发环境实时更Never只用地本地镜像绝不从网上拉离线环境配置示例给 Nginx 容器设置 Always 策略spec:containers:-name:nginximage:nginx:1.14imagePullPolicy:Always# 每次启动都拉新镜像2.1.1 镜像拉取策略案例我们用一个实战案例看看策略配置错了会怎么样步骤 1创建一个有问题的 Pod新建pod1.yamlapiVersion:v1kind:Podmetadata:name:pod-test1spec:containers:-name:nginximage:nginximagePullPolicy:Alwayscommand:[echo,SUCCESS]# 问题所在执行完就退出执行创建命令kubectl create -f pod1.yaml步骤 2观察异常状态查看 Pod 状态kubectl get pods -o wide会发现状态是CrashLoopBackOff崩溃循环重启。原因echo SUCCESS执行完就结束了容器生命周期结束但重启策略是默认的Always一直重启而且镜像拉取策略是Always所以每次重启都要重新拉镜像反复循环。步骤 3修复配置修改pod1.yaml删除错误命令修改拉取策略apiVersion:v1kind:Podmetadata:name:pod-test1spec:containers:-name:nginximage:nginx:1.14imagePullPolicy:IfNotPresent# 本地有就不用拉执行更新kubectl apply -f pod1.yaml步骤 4验证结果再查看状态kubectl get pods -o wide会显示Running正常运行。在集群节点上执行curl -I Pod的IP会返回HTTP/1.1 200 OK说明 Nginx 正常工作。2.2 重启策略restartPolicy这个策略决定了容器退出后K8s 要不要重启它也有三种选择策略作用适用场景Always不管退出码是什么都重启默认长期服务如 NginxOnFailure只有容器非正常退出退出码非 0才重启重要任务怕意外崩溃Never退出后绝不重启一次性任务如数据备份注意K8s 不能直接重启 Pod只能删除后重建这个策略只针对容器。配置示例设置 OnFailure 策略spec:containers:-name:busyboximage:busyboxargs:[sh,-c,sleep 30; exit 3]# 30 秒后非正常退出restartPolicy:OnFailure# 非正常退出才重启2.2.1 重启策略案例步骤 1创建默认策略的 Pod新建pod3.yamlapiVersion:v1kind:Podmetadata:name:foospec:containers:-name:busyboximage:busyboxargs:[sh,-c,sleep 10; exit 3]# 10 秒后非正常退出执行创建kubectl apply -f pod3.yaml步骤 2观察重启情况10 秒后查看状态kubectl get pods会发现RESTARTS重启次数变成 1说明默认的Always策略生效了一直在重启。步骤 3修改为 Never 策略修改pod3.yaml添加重启策略apiVersion:v1kind:Podmetadata:name:foospec:containers:-name:busyboximage:busyboxargs:[sh,-c,sleep 10; exit 3]restartPolicy:Never# 绝不重启执行更新kubectl delete -f pod3.yaml kubectl apply -f pod3.yaml步骤 4验证结果实时监控状态kubectl get pods -w10 秒后容器退出状态变成Error但RESTARTS一直是 0说明不再重启策略生效。总结Pod 是 K8s 的 “基础积木”核心要点其实很简单本质是 “容器封装盒”里面有基础容器Pause、初始化容器做准备、应用容器跑业务容器共享网络和存储适合单一进程或紧密协作的多进程场景生产环境用 “控制器管理的 Pod”配合IfNotPresent镜像拉取策略和Always重启策略稳定又高效遇到问题用kubectl get pods看状态、kubectl describe pod 名字查原因、kubectl logs 名字 -c 容器名看日志基本能解决大部分问题。