企业官网建设流程全解析

网站的数据库丢失,建网站不花钱免费,宣传型网站,做论坛网站 备案吗作为 10 年运维专家#xff0c;先把核心逻辑捋清楚#xff0c;再给落地步骤和可直接跑的案例 —— 全程说人话#xff0c;不堆砌术语#xff0c;适配 K8s 1.33 的特性#xff08;比如废弃的 API 都规避掉#xff09;。 一、核心技术逻辑#xff1a;先搞懂 Helm 到底在干…作为 10 年运维专家先把核心逻辑捋清楚再给落地步骤和可直接跑的案例 —— 全程说人话不堆砌术语适配 K8s 1.33 的特性比如废弃的 API 都规避掉。一、核心技术逻辑先搞懂 Helm 到底在干嘛1. Helm 的本质Helm 是 K8s 的包管理器把 K8s 的 YAML 配置Deployment、Service、Ingress 等打包成一个「Chart」相当于 Linux 的 rpm/deb 包解决零散 YAML 不好管理的问题环境差异化配置开发 / 测试 / 生产版本追溯、回滚、升级的管控一键部署 / 卸载不用手动改 YAML。2. Chart 的核心逻辑一个 Chart 就是一个目录结构核心是「模板 配置」模板templates带变量的 K8s YAML 文件比如镜像版本、副本数用变量 {{.Values.xxx}} 代替配置values.yaml模板变量的默认值部署时可通过-f或--set覆盖元数据Chart.yamlChart 的版本、名称、依赖、适配 K8s 版本等核心信息关键要适配 1.33。3. 版本管控的核心逻辑Helm 的版本管控分两层Chart 版本Chart.yaml 里的version语义化版本比如 1.0.0、1.0.1对应 Chart 包的迭代Release 版本Helm 部署 Chart 后生成的 Release比如部署 myapp-1.0.0 生成 release myapp-v1Helm 会记录每个 Release 的配置支持回滚helm rollback配合仓库Chart Repository把打好的 Chart 包推到仓库比如 Harbor、ChartMuseum实现版本归档和团队共享。4. K8s 1.33 适配要点1.33 版本主要废弃 / 变更的 API 要规避Ingress必须用networking.k8s.io/v1v1beta1 早已废弃StatefulSet/Deployment用apps/v1没问题1.33 仍支持PodSecurityPolicyPSP已完全移除改用 Pod Security StandardsPSS Pod Security AdmissionPSA其他核心 APIService、ConfigMap、Secret无变更正常用v1。二、自定义 Chart 开发详细操作步骤步骤 1环境准备适配 1.33先确认 Helm 版本建议 3.14适配 1.33# 安装Helm 3.14Linux示例 curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash # 验证版本 helm version # 输出v3.14.x即可 # 验证K8s集群1.33 kubectl version --short # 确保Server Version是v1.33.x步骤 2初始化 Chart 骨架Helm 提供create命令生成标准目录结构不用手动建# 创建名为myapp的Chart自定义Chart的核心目录 helm create myapp生成的目录结构重点标★myapp/ ├── Chart.yaml ★ Chart元数据版本、名称、K8s适配 ├── values.yaml ★ 模板默认配置镜像、副本数、端口等 ├── charts/ ★ 依赖的其他Chart比如redis、mysql ├── templates/ ★ 核心模板目录K8s资源YAML │ ├── deployment.yaml ★ 部署模板 │ ├── service.yaml ★ 服务模板 │ ├── ingress.yaml ★ 入口模板适配1.33 │ ├── _helpers.tpl ★ 辅助函数变量复用 │ ├── NOTES.txt ★ 部署后提示信息 └── .helmignore ★ 忽略文件类似.gitignore步骤 3定制 Chart 元数据Chart.yaml核心是适配 K8s 1.33示例如下注释讲清楚每一项apiVersion: v2 # Helm Chart的API版本v2是通用版v1是旧版 name: myapp # Chart名称全局唯一 description: A simple web app Chart for K8s 1.33 # 描述 type: application # 类型application/库chart # Chart版本语义化主版本.次版本.补丁比如1.0.0 # 迭代规则主版本大改、次版本新增功能、补丁bug修复 version: 1.0.0 # App版本对应业务应用的版本比如v1.0.0 appVersion: v1.0.0 # 适配的K8s版本1.33.x避免部署到不兼容的集群 kubeVersion: 1.33.0 1.34.0 # 可选依赖比如需要redis dependencies: - name: redis version: 17.3.1 repository: https://charts.bitnami.com/bitnami condition: redis.enabled # 条件启用步骤 4定制默认配置values.yaml核心是「默认值 可覆盖」适配 1.33 的 Ingress示例如下# 全局配置可被依赖Chart继承 global: namespace: myapp # 默认命名空间 # 部署配置 deployment: replicas: 2 # 默认副本数 strategy: type: RollingUpdate # 滚动更新1.33支持 rollingUpdate: maxSurge: 1 maxUnavailable: 0 pod: # 容器配置 containers: name: myapp-web image: nginx:1.25-alpine # 基础镜像1.33兼容 imagePullPolicy: IfNotPresent ports: - containerPort: 80 name: http # 资源限制避免资源抢占 resources: limits: cpu: 500m memory: 512Mi requests: cpu: 100m memory: 256Mi # 健康检查1.33推荐配置 livenessProbe: httpGet: path: / port: http initialDelaySeconds: 10 periodSeconds: 10 readinessProbe: httpGet: path: / port: http initialDelaySeconds: 5 periodSeconds: 5 # PSS适配替代PSP1.33必用 securityContext: runAsUser: 1000 runAsGroup: 1000 fsGroup: 1000 # Service配置 service: type: ClusterIP # 类型ClusterIP/NodePort/LoadBalancer port: 80 targetPort: http # Ingress配置适配1.33的networking.k8s.io/v1 ingress: enabled: true className: nginx # Ingress Controller类名需提前部署nginx-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / hosts: - host: myapp.example.com paths: - path: / pathType: Prefix # 1.33必填Prefix/Exact/ImplementationSpecific tls: false # 暂时关闭TLS生产可开启 # 依赖配置redis redis: enabled: false # 默认不启用 auth: enabled: true步骤 5定制模板templates/模板是「带变量的 K8s YAML」核心是复用 values.yaml 的配置适配 1.335.1 Deployment 模板deployment.yamlapiVersion: apps/v1 # 1.33支持 kind: Deployment metadata: name: {{ .Release.Name }}-myapp # Release名称固定后缀避免冲突 namespace: {{ .Values.global.namespace }} labels: app: {{ .Chart.Name }} version: {{ .Chart.AppVersion }} spec: replicas: {{ .Values.deployment.replicas }} strategy: {{- toYaml .Values.deployment.strategy | nindent 4 }} # 复用values的更新策略 selector: matchLabels: app: {{ .Chart.Name }} template: metadata: labels: app: {{ .Chart.Name }} spec: securityContext: {{- toYaml .Values.deployment.pod.securityContext | nindent 8 }} containers: - name: {{ .Values.deployment.pod.containers.name }} image: {{ .Values.deployment.pod.containers.image }} imagePullPolicy: {{ .Values.deployment.pod.containers.imagePullPolicy }} ports: {{- toYaml .Values.deployment.pod.containers.ports | nindent 12 }} resources: {{- toYaml .Values.deployment.pod.containers.resources | nindent 12 }} livenessProbe: {{- toYaml .Values.deployment.pod.containers.livenessProbe | nindent 12 }} readinessProbe: {{- toYaml .Values.deployment.pod.containers.readinessProbe | nindent 12 }}5.2 Service 模板service.yamlapiVersion: v1 # 1.33支持 kind: Service metadata: name: {{ .Release.Name }}-myapp-service namespace: {{ .Values.global.namespace }} labels: app: {{ .Chart.Name }} spec: type: {{ .Values.service.type }} selector: app: {{ .Chart.Name }} ports: - port: {{ .Values.service.port }} targetPort: {{ .Values.service.targetPort }} protocol: TCP name: http5.3 Ingress 模板ingress.yaml适配 1.33重点必须用networking.k8s.io/v1pathType 必填{{- if .Values.ingress.enabled }} # 条件渲染enabled为true才生成 apiVersion: networking.k8s.io/v1 # 1.33唯一支持的版本 kind: Ingress metadata: name: {{ .Release.Name }}-myapp-ingress namespace: {{ .Values.global.namespace }} annotations: {{- toYaml .Values.ingress.annotations | nindent 4 }} spec: ingressClassName: {{ .Values.ingress.className }} rules: {{- range .Values.ingress.hosts }} # 循环渲染多个host - host: {{ .host }} http: paths: {{- range .paths }} - path: {{ .path }} pathType: {{ .pathType }} # 1.33必填 backend: service: name: {{ $.Release.Name }}-myapp-service # 引用Service名称 port: number: {{ $.Values.service.port }} {{- end }} {{- end }} {{- if .Values.ingress.tls }} # TLS配置 tls: {{- toYaml .Values.ingress.tls | nindent 4 }} {{- end }} {{- end }}步骤 6模板校验避免语法错误开发完模板后先校验语法和适配性# 1. 检查Chart语法核心 helm lint myapp/ # 2. 渲染模板看最终生成的YAML不部署 helm template myapp/ --namespace myapp # 3. 模拟部署dry-run检查K8s 1.33兼容性 helm install myapp-test myapp/ --namespace myapp --create-namespace --dry-run如果报错优先看API 版本是否正确比如 Ingress 用 networking.k8s.io/v1变量是否存在比如 {{.Values.xxx}} 有没有在 values.yaml 定义K8s 1.33 的特性是否兼容比如 pathType 必填。三、版本管控从打包到仓库全流程步骤 1Chart 打包版本固化把 Chart 目录打成 tgz 包版本对应 Chart.yaml 里的 version# 打包生成myapp-1.0.0.tgz helm package myapp/ # 查看包信息 helm show chart myapp-1.0.0.tgz步骤 2搭建 Chart 仓库团队共享推荐用 Harbor自带 Chart 仓库或 ChartMuseum这里用 ChartMuseum 快速搭建适配 1.33# 1. 部署ChartMuseum用Helm本身部署 helm repo add chartmuseum https://chartmuseum.github.io/charts helm install chartmuseum chartmuseum/chartmuseum \ --namespace chartmuseum \ --create-namespace \ --set env.open.DISABLE_APIfalse # 开启API允许推送 # 2. 获取ChartMuseum地址 kubectl get svc -n chartmuseum chartmuseum-chartmuseum -o jsonpath{.spec.clusterIP} # 假设地址是10.96.0.100:8080步骤 3推送 Chart 到仓库版本归档用cm-push插件推送需先安装# 安装cm-push插件 helm plugin install https://github.com/chartmuseum/helm-push.git # 添加仓库到Helm helm repo add myrepo http://10.96.0.100:8080 # 推送包到仓库版本1.0.0 helm cm-push myapp-1.0.0.tgz myrepo # 刷新仓库 helm repo update myrepo # 查看仓库里的Chart版本 helm search repo myrepo/myapp步骤 4部署指定版本版本管控核心部署时指定版本避免随意升级# 部署1.0.0版本 helm install myapp vmyrepo/myapp --version 1.0.0 \ --namespace myapp \ --create-namespace \ # 覆盖默认配置比如生产环境副本数3 --set deployment.replicas3 \ --set ingress.hosts[0].hostmyapp.prod.example.com # 查看Release版本 helm list -n myapp # 输出示例NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION # myapp myapp 1 2025-12-15 10:00:00 deployed myapp-1.0.0 v1.0.0步骤 5版本升级 / 回滚运维核心操作5.1 版本升级比如迭代到 1.0.1修改 Chart.yaml 的 version 为 1.0.1更新功能比如增加资源限制重新打包helm package myapp/推送新版本helm cm-push myapp-1.0.1.tgz myrepo升级 Releasehelm upgrade myapp myrepo/myapp --version 1.0.1 -n myapp \ --set deployment.replicas4 # 同时覆盖配置5.2 版本回滚升级出问题时Helm 会记录每个 Release 的版本REVISION回滚到上一版本# 查看Release历史 helm history myapp -n myapp # 输出示例REVISION UPDATED STATUS CHART DESCRIPTION # 1 2025-12-15 10:00:00 superseded myapp-1.0.0 Install complete # 2 2025-12-15 10:10:00 deployed myapp-1.0.1 Upgrade complete # 回滚到REVISION 11.0.0版本 helm rollback myapp 1 -n myapp # 验证回滚结果 helm status myapp -n myapp步骤 6版本清理避免冗余# 卸载Release保留Chart版本 helm uninstall myapp -n myapp # 从仓库删除指定Chart版本1.0.0 curl -X DELETE http://10.96.0.100:8080/api/charts/myapp/1.0.0 # 清理本地Chart缓存 helm repo remove myrepo rm -rf myapp-1.0.0.tgz myapp-1.0.1.tgz四、完整案例部署一个 Nginx Web 应用适配 1.33案例目标开发一个 myapp Chart部署 Nginx 应用支持自定义副本数、镜像版本Ingress 访问myapp.example.com版本升级1.0.0→1.0.1版本回滚。前置条件K8s 1.33 集群已部署 nginx-ingress ControllerIngress 需要Helm 3.14 已安装本地 hosts 配置集群节点IP myapp.example.com。步骤 1创建并定制 Chart# 1. 创建Chart helm create myapp # 2. 修改Chart.yaml按前面的示例version1.0.0kubeVersion1.33.0 # 3. 修改values.yaml按前面的示例镜像用nginx:1.25-alpine副本数2 # 4. 校验模板 helm lint myapp/ helm template myapp/ --namespace myapp步骤 2部署 1.0.0 版本# 1. 创建命名空间 kubectl create namespace myapp # 2. 部署Release helm install myapp myapp/ -n myapp \ --set ingress.hosts[0].hostmyapp.example.com \ --set deployment.replicas2 # 3. 验证部署 helm status myapp -n myapp kubectl get pods -n myapp # 应该有2个nginx pod kubectl get ingress -n myapp # Ingress已创建 curl myapp.example.com # 应该返回Nginx默认页面步骤 3升级到 1.0.1 版本# 1. 修改Chart.yamlversion改为1.0.1appVersion改为v1.0.1 # 2. 修改values.yaml镜像改为nginx:1.26-alpine副本数3 # 3. 打包并推送这里用本地测试不用仓库 helm package myapp/ # 4. 升级Release helm upgrade myapp myapp-1.0.1.tgz -n myapp \ --set deployment.replicas3 # 5. 验证升级 helm status myapp -n myapp # 显示REVISION2CHARTmyapp-1.0.1 kubectl get pods -n myapp # 3个pod镜像为1.26-alpine curl myapp.example.com # 仍返回Nginx页面步骤 4回滚到 1.0.0 版本# 1. 查看Release历史 helm history myapp -n myapp # 2. 回滚到REVISION1 helm rollback myapp 1 -n myapp # 3. 验证回滚 helm status myapp -n myapp # 显示REVISION3CHARTmyapp-1.0.0 kubectl get pods -n myapp # 2个pod镜像为1.25-alpine步骤 5卸载 Releasehelm uninstall myapp -n myapp kubectl delete namespace myapp五、核心总结运维视角Chart 开发核心模板 配置分离适配 K8s 1.33 的 API 版本尤其是 Ingress版本管控核心Chart 版本包迭代 Release 版本部署迭代通过仓库归档支持升级 / 回滚避坑点不要硬编码 K8s 资源名称用 {{.Release.Name}} 避免冲突必须校验模板helm lint/helm template避免部署时出错K8s 1.33 的 Ingress 必须用 networking.k8s.io/v1pathType 必填版本号严格遵循语义化便于团队协作和追溯。可以基于这个框架扩展到更复杂的场景比如 StatefulSet、ConfigMap/Secret、多环境配置核心逻辑不变 —— 模板复用、配置可覆盖、版本可管控。