企业官网建设流程全解析

营销型网站建设试题,百度品牌专区怎么收费,网站建设竞品调研,个人pc wordpress文章目录前言一、项目生命周期管理1、项目生命周期阶段2、创建阶段#xff08;kubectl create#xff09;3、发布阶段#xff08;kubectl expose#xff09;4、更新阶段#xff08;kubectl set#xff09;5、回滚阶段#xff08;kubectl rollout#xff09;6、删除阶段…文章目录前言一、项目生命周期管理1、项目生命周期阶段2、创建阶段kubectl create3、发布阶段kubectl expose4、更新阶段kubectl set5、回滚阶段kubectl rollout6、删除阶段kubectl delete二、发布版本1、三种发布方式概述2、金丝雀发布实战三、声明式资源管理方法1、基本原理2、查看和解释配置清单3、修改资源配置清单并应用4、删除资源配置清单四、yaml文件编写方法1、kubernetes支持两种文件格式2、yaml语法格式3、api资源版本标签4、yaml文件示例4.1、创建deployment和Pod4.2、创建service4.3、详解k8s中的Port5、快速生成yaml文件模板方法5.1、快速生成yaml方法示例5.2、查看快速生成的yaml文件5.3、通过命令查看帮助重点总结前言本文围绕 K8s 项目生命周期全流程展开详解发布策略、声明式资源管理及 YAML 文件编写技巧为实操运维提供清晰指引。一、项目生命周期管理1、项目生命周期阶段创建 → 发布 → 更新 → 回滚 → 删除2、创建阶段kubectl create创建”容器端口“# 创建并运行一个或多个容器镜像。 # 创建一个deployment 或job 来管理容器。 kubectl create --help //启动 nginx 实例暴露容器端口 80设置副本数 3 kubectl create deployment nginx --imagenginx:1.14 --port80 --replicas3 kubectl get pods kubectl get all# 查看容器端口 kubectl get pods -o custom-columnsNAME:.metadata.name,PORT:.spec.containers[0].ports[0].containerPort # 查看归属是不是受控Pod kubectl get pods -o custom-columnsNAME:.metadata.name,CONTROLLER:.metadata.ownerReferences[0].kind,NAME:.metadata.ownerReferences[0].name3、发布阶段kubectl expose将资源暴露为 Servicekubectl expose --help kubectl expose deployment nginx --port80 --target-port80 --namenginx-service --typeNodePort1service 类型2扩展端口类型portport 是 k8s 集群内部访问service的端口即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到servicenodePortnodePort 是外部访问 k8s 集群中 service 的端口通过 nodeIP: nodePort 可以从外部访问到某个service。targetPorttargetPort 是 Pod 的端口从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上最后进入容器。containerPort:containerPort 是 Pod 内部容器的端口targetPort 映射到 containerPort。3查看网络状态与服务端口#查看pod网络状态详细信息和 Service暴露的端口 kubectl get pods,svc -o wide ##查看关联后端的节点 kubectl get endpoints #查看 service 的描述信息 kubectl describe svc nginx4) 负载均衡查看节点上#在 node01 节点上操作查看负载均衡端口 yum install ipvsadm -y ipvsadm -Ln TCP 192.168.10.21:44847 rr - 172.17.26.3:80 Masq 1 0 0 - 172.17.36.2:80 Masq 1 0 0 - 172.17.36.3:80 Masq 1 0 0 TCP 10.0.0.189:80 rr - 172.17.26.3:80 Masq 1 0 0 - 172.17.36.2:80 Masq 1 0 0 - 172.17.36.3:80 Masq 1 0 0 curl 10.0.0.189 curl 192.168.10.20:44847 ###在master01操作 查看访问日志 kubectl logs nginx-cdb6b5b95-fjm2x kubectl logs nginx-cdb6b5b95-g28wz kubectl logs nginx-cdb6b5b95-x4m24轮询查看4、更新阶段kubectl set#更改现有应用资源一些信息。 kubectl set --help #获取修改模板 kubectl set image --help Examples: # Set a deployments nginx container image to nginx:1.9.1, and its busybox container image to busybox. kubectl set image deployment/nginx busyboxbusybox nginxnginx:1.9.1 # 查看当前 nginx 的版本号 curl -I http://192.168.10.20:44847 curl -I http://192.168.10.21:44847 ##将nginx 版本更新为 1.15 版本 kubectl set image deployment/nginx nginxnginx:1.15 kubectl get pods -w #/处于动态监听 pod 状态由于使用的是滚动更新方式所以会先生成一个新 的pod然后删除一个旧的pod往后依次类推 kubectl get pods -o wide #再看更新好后的 Pod 的 ip 会改变更新示例5、回滚阶段kubectl rollout##对资源进行回滚管理 kubectl rollout --help //查看历史版本 kubectl rollout history deployment/nginx //执行回滚到上一个版本 kubectl rollout undo deployment/nginx //执行回滚到指定版本 kubectl rollout undo deployment/nginx --to-revision1 //检查回滚状态 kubectl rollout status deployment/nginx回滚示例6、删除阶段kubectl delete//删除副本控制器 kubectl delete deployment/nginx //删除service kubectl delete svc/nginx-service kubectl get all删除示例二、发布版本1、三种发布方式概述蓝绿发布同时部署新版本绿和旧版本蓝两套环境验证通过后直接切换流量到新版本旧版本作为备份随时回滚。滚动发布按批次逐步替换旧版本 Pod每替换一批验证一批全程无服务中断支持灰度放量和风险可控。金丝雀发布先将少量流量切到新版本金丝雀版本验证无问题后再逐步扩大流量占比最终全量切换。2、金丝雀发布实战1监控更新的过程kubectl get pods -w2更新deployment的版本并配置暂停deploymentkubectl set image deployment/nginx-deployment nginxnginx:1.15 kubectl rollout pause deployment/nginx-deployment可以看到已经新增了一个资源但是并未按照预期的状态去删除一个旧的资源就是因为使用了pause暂停命令验证版本号正常轮询新创建的就是1.15所以正常的只要看到1.14.2即可curl -I 10.96.0.147:803确保更新的pod没问题了继续更新kubectl rollout resume deployment/nginx-deploymentcurl -I 10.96.0.147:803、k8s发布的方法使用的滚动发布三、声明式资源管理方法1、基本原理1.适合于对资源的修改操作2.声明式资源管理方法依赖于资源配置清单文件对资源进行管理资源配置清单文件有两种格式yaml人性化易读json易于api接口解析3.对资源的管理是通过事先定义在统一资源配置清单内再通过陈述式命令应用到k8s集群里4.语法格式kubectl create/apply/delete -f xxxx.yaml2、查看和解释配置清单//查看资源配置清单(yaml的格式) kubectl get deployment nginx -o yaml //解释资源配置清单 kubectl explain deployment.metadata # 查询yaml文件相关命令参数 kubectl get service nginx -o yaml # 查看service的yaml格式展示的内容 kubectl explain service.metadata查看资源配置清单3、修改资源配置清单并应用离线修改修改yaml文件并用 kubectl apply -f xxxx.yaml 文件使之生效注意当apply不生效时先使用delete清除资源再apply创建资源# 导出yaml文件模板 kubectl get service nginx -o yaml nginx-svc.yaml vim nginx-svc.yaml #修改port: 8080 # 删除该yaml文件产生的旧资源 kubectl delete -f nginx-svc.yaml # 重新加载该文件 kubectl apply -f nginx-svc.yaml kubectl get svc在线修改直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效如port: 888PS此修改方式不会对yaml文件内容修改4、删除资源配置清单陈述式删除命令行操作kubectl delete service nginx声明式删除yaml文件进行操作kubectl delete -f nginx-svc.yaml扩展一般都是使用陈述式删除声明式创建资源四、yaml文件编写方法1、kubernetes支持两种文件格式支持yaml和json格式来管理资源对象json格式主要用于 api 接口之间消息的传递yaml格式用于配置和管理YAML 是一种简洁的非标记性语言内容格式人性化较易读2、yaml语法格式● 大小写敏感● 使用缩进表示层级● 不支持Tab键制表符作缩进只能使用空格缩进● 缩进的空格格数不重要只要相同层级对齐即可通常用两个空格● 符号字符后面一个空格 如冒号、逗号、-等● ”—“表示一个yml文件的开始用于分割yml文件● ”#“ 表示注释3、api资源版本标签注意点如果是业务场景一般首选使用 apps/v1带有beta字样的代表的是测试版本不用在生产环境中如apps/v1beta1api版本标签的作用1 区分资源的 “成熟度”控制功能迭代 。区分稳定版 / 测试版指导生产环境使用2 规范资源 YAML 的定义格式YAML 必须指定正确版本K8s 才能解析3保证集群的版本兼容集群升级时通过版本平滑过渡避免功能中断4按功能分组管理资源范围按业务域归类资源让 API 结构更清晰输出api版本标签:kubectl versions输出4、yaml文件示例4.1、创建deployment和Podmkdir /opt/demo cd /opt/demovim nginx-deployment.yaml# 第一部分资源的“身份标识”——告诉 K8s 这是什么类型的资源、用什么版本解析 apiVersion: apps/v1 # 【必选】指定解析这个资源的API版本 # 通俗相当于“文件格式版本”Deployment 必须用 apps/v1写错会报错 # 核心Deployment/StatefulSet 用 apps/v1Pod/Service 用 v1Ingress 用 networking.k8s.io/v1 kind: Deployment # 【必选】定义资源类型 # 通俗告诉 K8s 你要创建“部署控制器”Deployment而非 Service/Ingress 等 # 核心常用值——Deployment部署应用、Service服务入口、Ingress域名路由、Pod最小运行单元 # 第二部分资源的“基础信息”——给资源起名字、打标签、指定归属 metadata: # 【必选】资源的元数据描述信息固定字段 name: nginx-deployment # 【必选】资源名称Deployment的名字 # 核心同一 Namespace 内名称必须唯一比如不能有两个叫 nginx-deployment 的 Deployment labels: # 【可选】给 Deployment 本身打标签不是 Pod 的标签 app: nginx # 标签键值对keyappvaluenginx # 作用方便用标签筛选资源比如 kubectl get deploy -l appnginx # 第三部分资源的“核心配置”——定义 Deployment 要管理多少 Pod、Pod 长什么样 spec: # 【必选】Deployment 的核心配置段固定字段 replicas: 3 # 【必选】指定要运行的 Pod 副本数 # 通俗启动 3 个相同的 Nginx Pod实现负载均衡 # 核心改这个数值可以扩缩容比如改成 5 就是 5 个 Pod selector: # 【必选】标签选择器——Deployment 靠这个找到要管理的 Pod matchLabels: # 【必选】匹配标签规则精确匹配 app: nginx # 核心必须和下面 template.metadata.labels 里的标签完全一致 # 作用Deployment 只管理带 appnginx 标签的 Pod避免管错其他 Pod template: # 【必选】Pod 模板——定义要创建的 Pod 长什么样所有副本都按这个模板创建 metadata: labels: # 【必选】给 Pod 打标签关键 app: nginx # 核心必须和上面 selector.matchLabels 一致否则 Deployment 找不到 Pod spec: # 【必选】Pod 的核心配置段 containers: # 【必选】定义 Pod 里的容器一个 Pod 可以有多个容器 - name: nginx # 【必选】容器名称Pod 内唯一 image: nginx:1.15.4 # 【必选】容器使用的镜像镜像名版本 # 核心不写版本默认拉 latest生产环境必须指定具体版本如 1.15.4避免镜像更新导致故障 ports: # 【可选】声明容器要暴露的端口仅声明不实际映射 - containerPort: 80 # 声明容器监听 80 端口 # 注意这只是“告诉 K8s 容器用了 80 端口”要对外访问还需配 Service创建资源对象kubectl create -f nginx-deployment.yaml验证结果查看Pod和deploymentkubectl get all 或 kubectl get pods查看Pod的ip和部署的node节点kubectl get pods -o wide查看pod的标签kubectl get pods --show-labels4.2、创建servicevim nginx-service.yaml# 第一部分资源身份标识——告诉 K8s 这是 Service 类型的资源 apiVersion: v1 # 【必选】Service 属于核心资源固定用 v1和 Deployment 的 apps/v1 区分开 # 通俗Service 的“文件格式版本”写错会报错比如写成 apps/v1 就识别不了 kind: Service # 【必选】定义资源类型为 Service服务入口 # 通俗告诉 K8s 你要创建一个“门牌号”用来访问 Pod # 第二部分资源基础信息——给 Service 起名字、打标签 metadata: name: nginx-service # 【必选】Service 的名称同一 Namespace 内唯一 # 作用集群内可以通过 “nginx-service” 这个名字访问不用记 IP labels: app: nginx # 【可选】给 Service 本身打标签不是绑定 Pod 的标签 # 作用方便筛选 Service比如 kubectl get svc -l appnginx # 第三部分Service 核心配置——类型、端口、绑定 Pod 的规则 spec: type: NodePort # 【必选】Service 类型决定怎么暴露服务 # 可选值 # - ClusterIP默认仅集群内访问 # - NodePort暴露到所有 Node 的固定端口集群外可访问 # - LoadBalancer对接云厂商 LB生产常用 ports: # 【必选】定义端口映射规则Service 端口 ↔ Pod 端口 - port: 80 # 【必选】Service 自身的集群内端口ClusterIP:80 # 通俗门牌号的“内部窗口号”集群内访问 Service 时用这个端口 targetPort: 80 # 【必选】Pod 内容器的端口对应 Pod 里 nginx 监听的 80 端口 # 核心把 Service 的 80 端口请求转发到 Pod 的 80 端口 selector: # 【核心关联 Pod 的关键行】标签选择器 app: nginx # ✅ 这一行就是绑定 Pod 的核心 # 作用Service 会自动找到所有带 “appnginx” 标签的 Pod # 要求必须和 Pod 的 labels比如 Deployment 模板里的 appnginx完全一致创建资源对象kubectl create -f nginx-service.yaml查询servicekubectl get svc测试192.168.10.112:32305curl 192.168.10.112:32305 或者 浏览器访问http://192.168.10.112:323054.3、详解k8s中的Portportport 是 k8s 集群内部访问service的端口即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 servicenodePortnodePort 是外部访问 k8s 集群中 service 的端口通过 nodeIP: nodePort 可以从外部访问到某个 service。targetPorttargetPort 是 Pod 的端口从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上最后进入容器。containerPortcontainerPort 是 Pod 内部容器的端口targetPort 映射到 containerPort。5、快速生成yaml文件模板方法5.1、快速生成yaml方法示例kubectl run --dry-runclient 打印相应的 API 对象而不执行创建kubectl run nginx-test --imagenginx --port80 --dry-runclient kubectl create deployment nginx-deploy --imagenginx --port80 --replicas3 --dry-runclient查看生成yaml格式kubectl run nginx-test --imagenginx --port80 --dry-runclient -o yaml kubectl create deployment nginx-deploy --imagenginx --port80 --replicas3 --dry-runclient -o yaml查看生成json格式kubectl run nginx-test --imagenginx --port80 --dry-runclient -o json kubectl create deployment nginx-deploy --imagenginx --port80 --replicas3 --dry-runclient -o json使用yaml格式导出生成模板并进行修改以及删除一些不必要的参数kubectl run nginx-test --imagenginx --port80 --dry-runclient -o yaml nginx-test.yaml kubectl create deployment nginx-deploy --imagenginx --port80 --replicas3 --dry-runclient -o yaml nginx-deploy.yaml5.2、查看快速生成的yaml文件使用yaml格式导出生成模板并进行修改以及删除一些不必要的参数kubectl create deployment nginx-deploy --imagenginx --port80 --replicas3 --dry-runclient -o yaml nginx-deploy.yamlapiVersion: apps/v1 # 必留Service 用 v1Deployment 必须用 apps/v1 kind: Deployment # 必留定义资源类型为 Deployment metadata: creationTimestamp: null # 可删自动生成的字段手动写了也会被 K8s 覆盖 labels: app: nginx # 可选建议留给 Deployment 打标签方便筛选 name: nginx # 必留Deployment 名称唯一 spec: replicas: 2 # 必留Pod 副本数核心配置 selector: matchLabels: app: nginx # 必留关联 Pod 的核心标签必须和 template.labels 一致 strategy: {} # 可删空配置会用 K8s 默认的滚动更新策略写了没用 template: metadata: creationTimestamp: null # 可删自动生成的字段手动写无意义 labels: app: nginx # 必留Pod 的标签和 selector.matchLabels 绑定 spec: containers: - image: nginx # 必留容器镜像建议加版本比如 nginx:1.24 name: nginx # 必留容器名称Pod 内唯一 ports: - containerPort: 80 # 可选建议留声明容器端口仅标识不影响访问 resources: {} # 可选可删空配置表示不限制资源删了也会用默认值 status: {} # 可删status 是 K8s 自动维护的状态字段手动写空毫无意义将现有的资源生成模板导出并保存到文件中kubectl get svc service -o yaml my-svc.yamlcat my-svc.yamlapiVersion: v1 # 必留Service 属于核心资源固定用 v1Deployment 才用 apps/v1 kind: Service # 必留定义资源类型为 Service metadata: creationTimestamp: 2026-01-07T12:20:11Z # 可删K8s 自动生成的创建时间手动写会被覆盖 labels: app: nginx # 可选建议留给 Service 打标签方便筛选和绑定 Pod 无关 managedFields: # 可删K8s 内部记录谁修改了资源手动写无意义 - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: .: {} f:app: {} f:spec: f:externalTrafficPolicy: {} f:ports: .: {} k:{port:80,protocol:TCP}: .: {} f:port: {} f:protocol: {} f:targetPort: {} f:selector: .: {} f:app: {} f:sessionAffinity: {} f:type: {} manager: kubectl-create operation: Update time: 2026-01-07T12:20:11Z name: service # 必留Service 名称同一 Namespace 唯一 namespace: default # 可选可删默认就是 default 命名空间不写也会自动归到 default resourceVersion: 150531 # 可删K8s 内部版本号自动生成 uid: 773b38cb-5e41-4fde-ae92-86f30182c6f4 # 可删K8s 自动生成的资源唯一标识 spec: clusterIP: 10.96.0.147 # 可删K8s 自动分配 ClusterIP手动写会被覆盖除非指定固定 IP clusterIPs: # 可删和 clusterIP 重复自动生成 - 10.96.0.147 externalTrafficPolicy: Cluster # 可选可删默认值就是 Cluster删了不影响 ports: - nodePort: 32305 # 可选可删手动指定 NodePort 端口不写 K8s 会自动分配30000-32767 port: 80 # 必留Service 集群内端口核心 protocol: TCP # 可选可删默认协议就是 TCP删了等价 targetPort: 80 # 必留Pod 内容器的端口和容器监听端口一致 selector: app: nginx # 必留绑定 Pod 的核心标签必须和 Pod 标签一致 sessionAffinity: None # 可选可删默认就是无会话亲和性删了不影响 type: NodePort # 必留Service 类型ClusterIP/NodePort/LoadBalancer status: loadBalancer: {} # 可删status 是 K8s 自动维护的状态手动写空没用5.3、通过命令查看帮助重点查看deployment控制器的pod模板里容器的参数kubectl explain deployments.spec.template.spec.containers或者kubectl explain pods.spec.containers总结本文系统梳理 K8s 项目管理、发布方式与配置清单编写要点助力高效掌握声明式资源管理及 YAML 实操技能。