企业官网建设流程全解析

网站制作课程介绍,医疗器械分为哪三类,做视频网站设备需求,帮别人做网站后期维护目录 一、云原生的核心定义 二、云原生核心技术栈 1. 容器化技术#xff08;基础载体#xff09; 2. 容器编排与调度#xff08;核心管理工具#xff09; 3. CI/CD 流水线#xff08;自动化交付#xff09; 4. 微服务架构支撑技术 5. 镜像仓库#xff08;容器镜像…目录一、云原生的核心定义二、云原生核心技术栈1. 容器化技术基础载体2. 容器编排与调度核心管理工具3. CI/CD 流水线自动化交付4. 微服务架构支撑技术5. 镜像仓库容器镜像存储6. 声明式 API 与基础设施即代码IaC三、技术栈协同逻辑四、K8s 的核心定义4.1、K8s 解决的核心问题4.2 Kubernetes 集群架构与组件4.2.1 发起指令用户→kubectl→API Server4.2.2. 存储与决策API Server→Etcd→Controller Manager4.2.3. 调度分配Scheduler→API Server→工作节点4.2.4. 执行启动工作节点→Kubelet→容器运行时→Pod4.2.5. 网络访问Kube-proxy→Service4.2.6. 状态监控与自愈Controller Manager→Etcd→Kubelet4.3架构详解4.3.1.主节点Master集群的 “指挥中枢”核心组件及分工每个组件都是 “指挥岗”主节点的 “特殊保护”默认不运行业务 Pod. 主节点在 Jenkins 部署中的角色4.3.2、工作节点Node集群的 “干活机器”1. 核心组件及分工每个组件都是 “执行岗”2. 工作节点的 “资源标识”标签Label一、云原生的核心定义云原生Cloud-Native是一套技术体系和方法论核心目标是让应用程序 “为云而生”—— 充分利用云计算的弹性、可扩展性、高可用特性实现快速迭代、按需伸缩、故障自愈最终降低运维成本、提升业务交付效率。关键特征容器化应用及依赖被打包成标准化容器如 Docker保证 “一次构建到处运行”解决环境一致性问题这也是你正在实践的 Docker 核心价值微服务架构应用拆分为独立部署、松耦合的微服务而非单体应用每个服务聚焦单一功能可独立扩容、迭代DevOps 与 CI/CD开发Dev和运维Ops协同通过自动化流水线如你搭建的 Jenkins实现代码提交→构建→测试→部署全流程自动化弹性伸缩基于负载自动调整资源如 CPU / 内存高峰期扩容、低峰期缩容节约成本故障自愈通过编排工具如 K8s自动检测故障容器 / 服务重启或替换无需人工干预声明式 API通过配置文件而非命令定义应用期望状态如 “需要 3 个副本”编排工具负责将实际状态向期望状态对齐。二、云原生核心技术栈1. 容器化技术基础载体核心工具Docker、containerdDocker 的底层核心更轻量作用将应用、依赖如 Java 的 JDK、Python 的库、配置文件打包成 “容器镜像”镜像可在任何支持容器的环境中运行彻底解决 “开发环境能跑生产环境跑不了” 的问题2. 容器编排与调度核心管理工具核心工具KubernetesK8s业界事实标准、Docker Compose轻量级编排适合单机多容器如本地搭建 Jenkins 数据库作用管理海量容器的生命周期启动、扩容、缩容、故障恢复、负载均衡3. CI/CD 流水线自动化交付核心工具Jenkins、GitLab作用实现 “代码提交→自动构建镜像→自动测试→自动部署到容器平台” 的全流程自动化是 DevOps 的核心载体4. 微服务架构支撑技术服务注册与发现Eureka、Nacos、Consul解决微服务之间的通信问题服务启动后自动注册其他服务通过名称即可找到它无需硬编码 IP配置中心Nacos、Apollo集中管理所有微服务的配置如数据库地址、接口密钥修改后无需重启服务即可生效服务网格Service MeshIstio解决微服务的流量控制、熔断、监控、安全通信等问题无需修改业务代码。5. 镜像仓库容器镜像存储核心工具Docker Hub公共仓库、Harbor企业级私有仓库、阿里云镜像仓库作用存储你构建的 Docker 镜像如 Jenkins 镜像、你的应用镜像供 CI/CD 流水线或容器平台拉取使用。6. 声明式 API 与基础设施即代码IaC核心工具K8s YAML 文件、Terraform、HelmK8s 包管理工具作用用代码 / 配置文件定义基础设施如 K8s 的服务、容器副本数实现 “基础设施可版本控制、可重复部署”避免人工操作失误。三、技术栈协同逻辑以“DockerJenkins” 为起点完整的云原生流程是开发者在本地编写代码提交到 Git 仓库Jenkins容器化部署监听 Git 仓库变化自动拉取代码用 Docker 构建应用镜像构建好的镜像推送到私有镜像仓库如 HarborK8s 通过声明式配置YAML 文件从镜像仓库拉取镜像启动指定数量的容器副本服务注册中心如 Nacos自动注册新启动的服务其他服务通过名称调用PrometheusGrafana 监控容器和服务状态出现故障时 K8s 自动自愈若需扩容只需修改 K8s 配置文件的 “副本数”或设置自动扩容规则K8s 会自动新增容器。云原生技术帮助企业在公有云、私有云和混合云等动态环境中构建和运行可弹性扩展的应用。四、K8s 的核心定义K8sKubernetes缩写为 K8s因为 “K” 和 “s” 之间有 8 个字母是开源的容器编排与管理平台核心目标是自动化管理大规模容器化应用的全生命周期 —— 简单说它就是容器的 “大管家”能搞定成百上千个 Docker 容器的启动、扩容、缩容、故障恢复、负载均衡等工作。可以把 K8s 想象成一个 “容器操作系统”Docker 负责把应用打包成标准化的 “容器程序”而 K8s 负责调度这些 “程序” 在多台服务器上高效、稳定地运行就像 Windows/macOS 调度电脑上的软件一样。4.1、K8s 解决的核心问题之前用 Docker 单机部署 Jenkins能搞定单台服务器的容器运行但遇到以下场景就会力不从心想让 Jenkins 高可用需要在多台服务器上跑 3 个 Jenkins 容器手动管理太麻烦某台服务器宕机上面的容器需要自动迁移到其他服务器业务高峰期需要给应用扩容 10 个容器低峰期缩容到 2 个手动操作效率低多容器之间的网络互通、负载均衡需要手动配置。而 K8s 正是为解决这些问题而生它的核心价值是自动化替代人工完成容器的部署、启停、扩容缩容服务发现与负载均衡通过Service为Pod提供稳定的访问入口并自动分发请求弹性伸缩根据 CPU / 内存使用率或业务指标自动调整容器数量容灾/自愈当某个节点或容器失败时K8S会自动重建或迁移Pod保证副本数量和期望状态。滚动升级与回滚支持渐进式升级一旦出错可以回滚到之前版本集中配置与密钥管理通过ConfigMap、Secret等资源集中管理配置与敏感数据批处理/定时任务支持Job、CronJob用于一次性或定时任务4.2Kubernetes集群架构与组件角色设计Kubernetes 集群架构图包含主节点Master和工作节点Node两部分主节点有 kubectl、API Server、Etcd、Scheduler、Controller Manager 组件工作节点有 Kubelet、Kube - proxy、Pod、容器运行时Docker组件整体采用清晰的架构示意图风格突出各组件之间的连接和数据流向。4.2.1 发起指令用户→kubectl→API Server用户通过kubectl命令行工具输入指令kubectl create deployment nginx --replicas3要求创建 3 个 Nginx 副本kubectl 将指令转化为 K8s 能识别的 API 请求发送给主节点的API Server集群通信枢纽所有请求必须经过它。4.2.2. 存储与决策API Server→Etcd→Controller ManagerAPI Server 验证请求合法性后将 “期望状态3 个 Nginx” 存入Etcd集群数据库保存所有配置和状态Controller Manager状态守护者实时监听 Etcd 中的期望状态发现 “当前集群没有 3 个 Nginx”立即向 API Server 发起 “创建 3 个 Nginx Pod” 的请求Pod 是 K8s 最小部署单元容器必须封装在 Pod 中。4.2.3. 调度分配Scheduler→API Server→工作节点Scheduler调度器收到 “创建 3 个 Nginx Pod” 的请求后通过 “预选 优选” 算法预选排除资源不足的节点如节点只有 1G 内存而 Nginx Pod 需要 2G直接淘汰优选从剩余节点中选择负载最低、资源最充足的节点如标注 “4C8G” 的节点优先于 “1C2G” 的节点Scheduler 将 “3 个 Pod 分别部署到哪 3 个工作节点” 的调度结果通过 API Server 反馈给 Etcd 存储并同步给目标工作节点。4.2.4. 执行启动工作节点→Kubelet→容器运行时→Pod目标工作节点的Kubelet主节点的 “代理人”实时监听 API Server收到调度指令后调用节点上的容器运行时如 Docker拉取 Nginx 镜像启动容器并将 3 个容器分别封装为 3 个Pod每个 Pod 对应 1 个 Nginx 容器Kubelet 持续监控 Pod 状态如是否存活、资源使用情况并实时上报给 API Server。4.2.5. 网络访问Kube-proxy→Service工作节点的Kube-proxy网络代理为 3 个 Nginx Pod 创建一个Service稳定访问地址解决 Pod 动态 IP 的问题Pod 崩溃重建后 IP 会变Service 提供固定虚拟 IP实现负载均衡外部请求通过 Service 时Kube-proxy 将请求均匀分发到 3 个 Nginx Pod避免单个 Pod 过载。4.2.6. 状态监控与自愈Controller Manager→Etcd→KubeletController Manager 持续对比 Etcd 中的 “期望状态3 个 Nginx” 和 Kubelet 上报的 “实际状态”若某个 Nginx Pod 崩溃实际状态变为 “2 个 Nginx”Controller Manager 立即触发自愈通过 API Server 指令 Kubelet 在合适节点重建 1 个 Pod所有状态变化如 Pod 重建、IP 更新都会实时同步到 Etcd确保集群状态始终与期望一致。4.3架构详解4.3.1.主节点Master集群的 “指挥中枢”核心组件及分工每个组件都是 “指挥岗”组件通俗角色具体功能结合 Jenkins 部署API Server“总机接线员 权限门卫”所有指令的唯一入口接收 kubectl “部署 Jenkins” 的请求验证权限后转发给其他组件所有组件通过它通信Etcd“集群数据库 账本”存储集群所有配置和状态比如 “Jenkins 要运行 3 个副本”“Pod 在哪个节点”“节点标签” 等核心信息Controller Manager“状态监控官 自愈指挥官”确保实际状态 期望状态若 Jenkins Pod 崩溃它立即下令重建若节点宕机它下令迁移 PodScheduler“调度分配员”给 Pod 选 “干活的节点”根据节点资源如 4C8G、标签如 storagessd把 Jenkins Pod 分配到合适的工作节点主节点的 “特殊保护”默认不运行业务 Pod原因主节点是集群核心若运行 Jenkins 等业务 Pod会占用控制组件的资源导致集群管理卡顿甚至崩溃. 主节点在 Jenkins 部署中的角色当执行kubectl apply -f jenkins-deploy.yaml时指令先到 API Server验证后存入 EtcdController Manager 读取到 “要部署 Jenkins”创建 Pod 请求Scheduler 根据节点资源和标签给 Jenkins Pod 分配工作节点全程监控 Jenkins Pod 状态若异常则触发自愈。4.3.2、工作节点Node集群的 “干活机器”1. 核心组件及分工每个组件都是 “执行岗”组件通俗角色具体功能结合 Jenkins 部署Kubelet“主节点的代理人 Pod 管家”接收主节点指令启动 / 停止 Jenkins Pod监控 Pod 状态如存活、内存使用实时上报给主节点Kube-proxy“网络管理员 负载均衡员”给 Jenkins Pod 配置网络创建 Service固定访问地址把外部请求均匀分发到多个 Jenkins 副本容器运行时Docker/Containerd“容器启动工具”拉取 Jenkins 镜像启动容器将容器封装为 Pod提供运行环境如依赖、网络Pod“应用运行容器”K8s 最小部署单元每个 Pod 包含 1 个 Jenkins 容器或多个关联容器如日志收集容器2. 工作节点的 “资源标识”标签Label作用主节点的 Scheduler 通过标签识别节点特性实现精准调度工作节点在 Jenkins 部署中的角色当主节点下达 “在 node-2 部署 Jenkins” 的指令后node-2 的 Kubelet 接收指令调用 Docker 拉取 Jenkins 镜像启动 Jenkins 容器封装为 Pod分配资源如 1 核 CPU、2G 内存Kube-proxy 为 Jenkins Pod 创建 Service暴露 8080 端口Kubelet 持续监控 Jenkins Pod若崩溃则上报主节点等待重建指令