多云部署的方案设计
最近在完成一项多云部署的工作，具体背景是业务需要开展在多个地区，每个地区都需要三套环境即test-opn-prod，因此如何快速的减少人力成本的完成部署就是一个问题了，对于不同环境的切换需要处理以下几个方面的问题，
1 | - 每个地区资源的配置，包括集群数量，网络拓扑，域名等 |
而在效率方面需要解决
1 | - 多个服务的配置更改需要高权限以及完备的流水线配置 |
在以上的前提下，来聊一下解决方案，关于网络拓扑的配置是op方面的工作，下面在知识中会聊一下k8s的基础，这里不再赘述。 而替换步骤可以通过（gerrit流程）
- clone 仓库并准备部署分支。
- 复制文件并提交 commit。
- 替换字段并提交 commit。
- 人工根据 cr_list 审阅并 merge Gerrit CR。
- 显式执行 pipeline 触发并查询 pipe 流水线。
这样的方式来实现，其中的两次commit是利用gerrit的cr机制来判断具体改动项。具体的替换字段方法是这样写在一个conf文件
1 | 旧值|||新值 |
利用bash脚本的匹配命中与替换完成任务。
k8s相关知识
首先 这个知乎作者写的文章非常好,我也是从中学习了很多，下文部分呢内容摘抄由此
什么是k8s
自动化运维容器的集群
底层通过cri接口与容器运行时通信，包括但不限于docker运行时。
架构是什么样的
master-slave架构，具备一个master节点，和一个worker节点，一般来说业务的pod都在worker下。
masterNode
其包含以下组件
API Server。 K8S的请求入口服务。API Server负责接收K8S所有请求（来自UI界面或者CLI命令行工具），然后，API Server根据用户的具体请求，去通知其他组件干活。从图中可以知道，API Server实际可以部署多个实例，以增大请求吞吐。
**Scheduler。**K8S中的调度服务。当用户要部署服务时，Scheduler会选择最合适的Worker Node（服务器）来部署。从上图可以知道，Scheduler也可以部署多个实例，以增大处理能力。
**Controller Manager。**K8S的控制服务。Controller Manager本身就是总称，实际上有很多具体的Controller，在文章Components of Kubernetes Architecture中提到的有Node Controller、Service Controller、Volume Controller等，分别负责不同K8S对象。举个例子，比如用户要求A服务部署2个副本，那么当其中一个服务挂了的时候，Controller会马上调整，让Scheduler再选择一个Worker Node重新部署服务。
**etcd。**K8S的存储服务。etcd存储了K8S的关键配置和用户配置，K8S中仅API Server才具备读写权限，其他组件必须通过API Server的接口才能读写数据（见Kubernetes Works Like an Operating System）。
workerNode
其包含以下组件
**Kubelet。**Worker Node的监视器，以及与Master Node的通讯器。Kubelet是Master Node安插在Worker Node上的“眼线”，它会定期向Master Node汇报自己Node上运行的服务的状态，并接受来自Master Node的命令，并执行。
**Kube-Proxy。**K8S的网络代理。私以为称呼为Network-Proxy可能更适合？Kube-Proxy负责Node在K8S的网络通讯、以及对外部网络流量的负载均衡。
**Container Runtime。**Worker Node的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如Docker Engine。大白话就是帮忙装好了Docker运行环境。
**Logging Layer。**K8S的监控状态收集器。私以为称呼为Monitor可能更合适？Logging Layer负责采集Node上所有服务的CPU、内存、磁盘、网络等监控项信息。
**Add-Ons。**K8S管理运维Worker Node的插件组件。有些文章认为Worker Node只有三大组件，不包含Add-On，但笔者认为K8S系统提供了Add-On机制，让用户可以扩展更多定制化功能，是很不错的亮点。
pod
对于一个业务服务通常是以pod形式存在，并且挂在workerNode下被调度，pod时k8s中调度的最小单位。同时k8s提供了多种类型的pod用来满足不同的业务需求
是的。一个 Pod 内可以包含一个或多个容器。
关于 Pod 的分类，在 Kubernetes 体系中，主要从管理方式（生命周期），业务形态（控制器类型）两个核心维度进行划分。
一、 按管理方式分类（生命周期归属）
- 自主式 Pod (Autonomous Pod) / 静态 Pod (Static Pod)
- 自主式 Pod：用户直接通过 API Server 创建的 Pod，未绑定任何控制器。此类 Pod 缺乏自愈能力，一旦节点故障或容器进程异常退出，Kubernetes 不会自动重新调度或重建它。
- 静态 Pod：直接由特定节点上的 kubelet 进程根据本地磁盘文件（如
/etc/kubernetes/manifests）进行管理，不受 API Server 控制。常用于部署控制平面组件（如 kube-apiserver、etcd）。
- 控制器管理的 Pod (Controller-managed Pod)
由 Kubernetes 的各类控制器基于 Pod 模板（PodTemplate）动态创建和维护。当 Pod 发生故障时，控制器会介入并触发重建与重新调度。
二、 按业务形态分类（绑定的控制器类型）
根据所绑定的控制器，Pod 的行为特征可分为以下几类：
无状态应用 Pod (Stateless)
由 Deployment 或 ReplicaSet 控制器管理。特征：各个 Pod 副本之间完全对等且可互相替代，无持久化网络标识或严格的启停顺序要求。有状态应用 Pod (Stateful)
由 StatefulSet 控制器管理。特征：具备唯一且固定的网络标识（如独立的 DNS 记录），严格按照顺序进行创建、更新和删除，通常强绑定特定的持久化存储卷（PersistentVolume）。守护进程 Pod (Daemon)
由 DaemonSet 控制器管理。特征：确保在集群内的每个节点（或符合特定标签选择器的节点）上运行且仅运行一个 Pod 副本。常用于日志采集、网络插件或节点监控。任务类 Pod (Batch/Job)
由 Job 或 **CronJob 控制器管理。特征：设计为短期运行的批处理任务。任务执行成功并正常退出后，Pod 即被标记为完成状态，不会被永远重启。
三. 补充说明：Pod 内部容器的功能分类
若聚焦于单个多容器 Pod 内部，按运行时序与功能边界，容器可细分为：
- 应用容器 (App Containers)：Pod 的核心工作负载。在 Pod 初始化阶段完成后启动，多个应用容器在 Pod 生命周期内并发运行。
- 初始化容器 (Init Containers)：在应用容器启动前按定义顺序串行执行的容器。前一个 Init 容器必须成功退出（退出码为 0），下一个才会启动。常用于环境依赖检查、权限修改或配置拉取。
- 临时容器 (Ephemeral Containers)：主要用于在线故障排查。在现有运行中的 Pod 内通过 API 动态注入，执行完毕后退出，不支持配置端口映射或资源配额。
常用命令
1 | # 集群信息与配置 |
