【运维】云计算的发展历程，云原生时代的运维理念&工具技术栈(容器/镜像/编排, CI/CD, 网关/日志/监控) ------ 以K8S调度算法与命令为例
文章目录
-
- [1、云计算的发展历程 ------ 计算，为了无法计算的价值](#1、云计算的发展历程 —— 计算，为了无法计算的价值)
- [2、云原生运维的概念 ------ 运维，从手工业到自动化](#2、云原生运维的概念 —— 运维，从手工业到自动化)
- [3、技术栈 ------ 工具，功能化的问题解决器](#3、技术栈 —— 工具，功能化的问题解决器)
说明：
基础架构的研发，还是要会一些运维技能的。
一方面方便自己上集群"手搓"，另一方本身开发的内容也就偏向于是，提供以ToC业务消费用的"工具"，而这里的"工具"，更多的时候其实就是底层服务部署&运维工具的一种上层封装和产品化。
1、云计算的发展历程 ------ 计算，为了无法计算的价值
云计算的发展历程
- 非虚拟化硬件
层次：物理服务器直接部署应用，单机单应用（如一台服务器运行一个数据库）。
用例：裸金属服务器、物理机托管 - 虚拟化
层次：多租户和资源池化，实现资源隔离
用例：通过Hypervisor（如ESXi、KVM）将物理机划分为多个虚拟机（VM），实现资源共享 - IaaS 1
层次：计算，存储，网络 => 提供虚拟化的硬件资源 ，如虚拟机、EBS块存储、VPC网络等
用例：测试和开发、Web服务、存储和备份、大数据分析、虚拟桌面、高性能计算、云原生应用部署 - PaaS paas
层次：提供编程环境和开发工具，如数据库、中间件、操作系统
用例：应用开发、测试、部署、应用托管 - SaaS
层次：提供直接可用的应用软件
用例：邮件服务、客户关系管理（CRM）、协同办公软件 - 容器
层次：轻量化隔离，环境一致性、快速部署
用例：基于容器引擎（Docker）打包应用与依赖，共享主机OS内核，轻量且秒级启动，Kubernetes（2014年）成为容器管理的事实标准 - 云原生
层次：全栈自动化+微服务
用例：应用拆分为松耦合服务（如Spring Cloud），声明式API与自动化（K8s YAML、Helm），服务网格（Istio）、Serverless（AWS Lambda）等新范式
过去的二十年间，云计算几乎重塑了整个行业格局。越来越多的企业开始降低对 IT 基础设施的直接资本投入，不再倾向于维护自建的数据中心，而是通过上云的方式获取更强大的计算、存储、网络资源，并实现按时、按需付费。这不仅降低了 IT 支出，还显著降低了行业技术壁垒，使更多公司，尤其是初创企业，能够更快速地落地业务想法并将其迅速推向市场。
引用：
阿里云创始人王坚：云计算正在重新定义今天的世界 云栖 Creating value beyond computing
深入高可用系统原理与设计 图
1, 2,
2、云原生运维的概念 ------ 运维，从手工业到自动化
云原生运维的本质是将传统运维的"手动干预"转化为"自动化策略"，通过平台工程（Platform Engineering）为开发团队提供自助式基础设施，同时确保稳定性与安全性。
从云原生说起
- 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中 ，构建和运行可弹性扩展的应用 。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统 。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更 。
- 云原生架构必须要在同时满足这 3 个彼此冲突目标的前提下，还要实现成本控制。
- 容器技术
- 微服务
微服务架构是一种面向服务的架构，由松耦合的具有有限上下文的元素组成。
松耦合（Loosely Coupled）：意味着每个服务可以独立的更新 ，更新一个服务无需要求改变其他服务。
限界上下文（Bounded Contexts）：意味着每个服务要有明确的边界性 ，你可以只关注自身软件的发布，而无需考虑谁在依赖你的发布版本。微服务和它的消费者严格通过 API 进行交互 ，不共享数据结构、数据库等。基于契约的微服务规范要求服务接口是稳定的，而且向下兼容。
后微服务时代
- 服务网格
定义：服务网格（ServiceMesh）是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
边车代理 ：
每个节点同时运行着业务逻辑和具备通信治理能力的网络代理（如 Envoy、Linkerd-proxy）。
数据平面（Data plane） ：
通常采用轻量级的网络代理（如 Envoy）作为 Sidecar，网络代理负责协调和控制服务之间的通信和流量处理，解决微服务之间服务熔断、负载均衡、安全通讯等问题。
控制平面（Control plane） ：
包含多个控制组件，它们负责配置和管理 Sidecar ，并提供服务发现（Discovery）、配置管理（Configuration）、安全控制（Certificates）等功能。
- 不可变基础设施
重大故障时，难以快速重新构建服务 ：持续过多的手动操作并且缺乏记录 ，会导致很难由标准初始化的服务器 来重新构建起等效的服务 ；
不一致风险 ：类似于程序变量因并发修改而带来的状态不一致风险 。服务运行过程中，频繁的修改基础设施配置，同样会引入中间状态，导致出现无法预知的问题 。
不可变基础设施思想的核心是，任何基础设施的运行实例一旦创建之后就变成只读状态 。如需修改或升级，应该先修改基础设施的配置模版（例如 yaml、Dockerfile 配置），之后再使用新的运行实例替换 。
- 声明式设计
声明式设计是指一种软件设计理念："我们描述一个事物的目标状态，而非达成目标状态的流程" 。至于目标状态如何达成，则由相应的工具在其内部实现。
1、命令式设计 ：命令"机器"如何去做事情（how） ，这样不管你想要的是什么（what），它都会按照你的命令实现 ；有一批图书的列表，你会编写下面类似的代码来查询列表：
for( var i=0; i< books.length; i++) {
if(booksi.name == "目标书名") {
results.push(books)
}
}
2、声明式设计 ：告诉"机器"你想要的是什么（what） ，让机器想出如何去做（how）。
声明式的查询语言（如 SQL），只需要指定所需的数据、结果满足什么条件以及如何转换数据（如排序、分组和聚合），数据库直接返回我们想要的结果。
SELECT * FROM books WHERE author = 'xiaoming' AND name LIKE '目标书名 %';
3、再看以声明式设计为核心的 Kubernetes：
YAML 文件中定义了一个名为 nginx-deployment 的 Deployment 资源。其中 spec 部分声明了部署后的具体状态（以 3 个副本的形式运行）
YAML 文件提交给 Kubernetes 之后，Kubernetes 会创建拥有 3 个副本的 nginx 服务实例，将持续保证我们所期望的状态。
通过编写 YAML 文件表达我们的需求和意图，资源如何创建、服务如何关联，至于具体怎么实现，我们完全不需要关心，全部甩手给 Kubernetes。
只描述想要什么，中间流程、细节不需关心。工程师们专注于 what，正是我们开发软件真正的目标。
- DevOps
DevOps 核心本质是解决软件开发生命周期中的管理问题 。
瀑布模型：瀑布模型基于工程学的理念将整个过程分成不同的阶段，提供了软件开发的基本框架，便于人员间的分工协作。同时，也可对不同阶段的质量和成本进行严格把控。
瀑布模型产生于硬件领域 ，它是从制造业的角度 去看软件开发的，产品迭代的频率经常按月为单位 进行，在需求变化不多的年代，瀑布模型拥有其价值。随着软件行业的快速爆发，针对市场的快速变化和响应成了新的目标 。这种场景下，需求无法得到快速验证是最大的风险 ，有可能花费数月开发的产品早已不符合市场需求 。
敏捷开发：敏捷开发是一种持续增量、不断迭代的开发模式 。开发者快速发布一个可运行但不完美的版本投入市场 ，在后续迭代中根据用户的反馈改进产品 ，从而逼近产品的最终形态。
敏捷开发提升了开发效率，但它的范围仅限于开发和测试环节，并没有覆盖到部署环节。显然，运维部门并没有收益。相反的，甚至可以说"敏捷"加重了运维的负担。运维追求的目标是稳定，频繁变更是破坏稳定的根源
DevOps 的成功实践离不开工具上的支持 ，这其中包括最重要的自动化 CI/CD 流水线 ，通过自动化的方式打通软件从构建、测试到部署发布的整个流程 。还有实时监控、事件管理、配置管理、协作平台等一系列工具/系统的配合。
- 架构演进
从研发应用的角度看，研发的复杂度降低了。在"强大底层系统"支撑的情况下，应用监控、通信治理、编排调度相关的逻辑从应用中剥离，并下沉到底层系统，已经符合云原生架构 。
但站在整个系统的角度看，复杂度并没有减少和消失，要实现"强大底层系统"付出的成本（人力成本、资源成本、技术试错成本）是非常昂贵的。为了降低成本，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计 。
最后，通过 YAML 文件以声明式的方式，描述底层的基础设施以及各类中间件资源，即应用要什么，云给我什么 ，企业最终走向开放、标准的"云"技术体系。
- 云原生不是简单使用云计算平台运行现有的应用程序，也不是某个开源项目或者某种技术，而是一套指导软件和基础设施架构设计的思想 。基于这套思想构建出来的应用 ，能够天然地与"云"融合，充分发挥"云"的能力和价值。相应的，云原生生态中的开源项目 Kubernetes、Docker、Istio 等，就是这种思想落地的技术手段。
什么是云原生运维？ 1
- 定义：
云原生运维（Cloud Native Operations）是基于云原生技术栈的运维模式，旨在高效管理动态、分布式的云原生应用。它强调自动化、可观测性和弹性，以应对微服务、容器化等现代架构的挑战。 - 对比：
传统运维侧重于硬件和操作系统的管理 ，而云原生运维注重应用程序的开发、部署和管理，通过容器化和微服务架构来提高应用程序的灵活性和可扩展性。
Linux 的计算调度单元是进程，调度范围限制在一台计算节点 。而 Kubernetes 的调度单位是 Pod 一个进程组，它的调度范围是一个分布式集群，支持应用在公共云、专有云等不同环境间进行迁移。 - 技术：
实现云原生运维需要使用容器化技术，如Docker，以及相应的容器编排工具，如Kubernetes。
同时，还需要使用自动化运维工具，如Ansible和Jenkins来实现自动化的部署、配置。
核心挑战与解决方案？
| 挑战 | 解决方案 |
|---|---|
| 动态服务发现 | K8s Service + DNS/Istio服务网格 |
| 配置管理 | ConfigMap/Secrets + 外部化配置（如Vault） |
| 日志/监控分散 | EFK/ELK（日志）、Prometheus+Grafana（指标） |
| 跨云/混合云部署 | K8s多集群管理（如Rancher、Anthos） |
| 安全合规 | 镜像扫描（Trivy）、零信任网络（NetworkPolicy） |
K8S调度算法
-
Kubernetes 调度算法概述 1
收集所有节点的资源信息，包括 CPU、内存、磁盘等。
根据应用程序的需求，计算出每个容器需要的资源。
根据资源需求，找到一个合适的节点来运行容器。
如果没有找到合适的节点，则进行资源调度，将资源从一个节点移动到另一个节点。
将容器运行到节点上，并监控容器的运行状态。
-
1、Service和Deployment的关系
Service 只是一个网络抽象层，用于暴露一组 Pod（通过 selector 匹配 Pod 的标签）
Pod 必须由控制器（如 Deployment/StatefulSet）创建，Service 仅负责流量路由
graph
Deployment -->|创建和管理| Pod
Service -->|通过标签选择器关联| Pod-
2、Deployment和Pod的关系
Deployment => ReplicaSet => Pod => Container
Deployment 创建的是 Pod，而不是直接创建容器 。Pod 是 Kubernetes 的最小调度单元，一个 Pod 可以包含 1 个或多个容器（通常为 1 个主容器 + Sidecar 容器）。
在 Deployment.spec.template.spec.containers 中定义 容器列表 ，Kubernetes 会按照该模板为每个 Pod 创建相同的容器组合。Deployment → ReplicaSet → Pod → Container，Deployment 控制 Pod 副本，Pod 内部运行 容器
扩缩容的单位是 Pod，不是容器。
kubectl scale deployment <dep-name> --replicas=3 -n <namespace>会创建 3 个 Pod，每个 Pod 包含定义的全部容器。 -
3、Service 路由到 Pod 的核心流程
（1）标签匹配（Label Selector）
Service 通过 spec.selector 匹配 Pod 的标签
spec.selector.app: nginx# 匹配所有包含app: nginx标签的 Pod，只有带有app: nginx标签的 Pod 会被纳入该 Service 的流量池（2）Kubernetes 自动创建 Endpoints 对象
Service 并非直接路由到 Pod，而是通过 Endpoints 维护一组 Pod 的 IP 列表。
kubectl get endpoints my-service
my-service 10.244.1.2:80,10.244.2.3:80 # 实时更新的 Pod IP 列表
当 Pod 被创建/删除时，Endpoints 自动更新。
-
Service 的三种类型及路由方式
（1）ClusterIP（默认）
集群内访问，通过虚拟 IP（VIP）负载均衡到后端 Pod。
DNS 解析：
集群内可通过 ..svc.cluster.local 解析到 ClusterIP。
（2）NodePort
在 ClusterIP 基础上，在每个节点开放一个静态端口（如 30080），外部通过 NodeIP:NodePort 访问。
路由路径：
外部请求 → NodeIP:30080 → kube-proxy → Service → Pod
（3）LoadBalancer
依赖云厂商的 LB 服务（如 AWS ELB、Azure LB），将外部流量导到 NodePort 或 Pod。
路由路径：
外部请求 → 云负载均衡器 → NodePort/ClusterIP → Pod
容器编排最佳实践
-
编排的核心目的
自动调度容器到合适的主机（基于资源、亲和性等）。
自动处理容器故障（自愈能力，如重启或迁移）。
提高集群资源利用率（动态分配CPU/内存/存储）。
确保应用零宕机（滚动更新、多副本部署）。
管理微服务间的依赖、网络和存储配置。
-
一个完整的 Deployment + Service + HPA（自动扩缩容） 编排示例
yaml
# kubectl apply -f deployment.yaml # 创建所有资源
# kubectl get pods,svc,hpa # 查看资源状态
---
# 1. Deployment：定义应用副本和更新策略
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment # 部署名称
labels:
app: nginx # 用于Service选择
spec:
replicas: 3 # 初始副本数，保证高可用
revisionHistoryLimit: 3 # 保留的历史版本数（方便回滚）
selector:
matchLabels:
app: nginx # 匹配Pod标签
strategy:
rollingUpdate: # 滚动更新策略
maxSurge: 1 # 更新时最多比期望值多1个Pod
maxUnavailable: 0 # 更新时允许的最大不可用Pod数（0表示全量可用）
type: RollingUpdate
template: # Pod模板
metadata:
labels:
app: nginx # 必须与selector.matchLabels一致
spec:
securityContext: # 安全上下文（最小权限原则）
runAsNonRoot: true
readOnlyRootFilesystem: true
containers:
- name: nginx
image: nginx:1.25.3 # 使用固定版本号，避免latest导致版本漂移
imagePullPolicy: IfNotPresent # 减少镜像拉取时间
resources:
limits: # 资源限制（防止单Pod耗尽节点资源）
cpu: "500m"
memory: "512Mi"
requests: # 请求资源（调度依据）
cpu: "100m"
memory: "128Mi"
ports:
- containerPort: 80
readinessProbe: # 就绪探针（流量只有通过检查才会进入Pod）
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe: # 存活探针（失败会重启Pod）
httpGet:
path: /
port: 80
initialDelaySeconds: 15
periodSeconds: 20
affinity: # 亲和性规则（分散Pod到不同节点）
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values: ["nginx"]
topologyKey: "kubernetes.io/hostname"
---
# 2. Service：暴露Pod服务
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: ClusterIP # 集群内访问（NodePort/LoadBalancer用于外部访问）
selector:
app: nginx # 匹配Deployment中的Pod标签
ports:
- protocol: TCP
port: 80 # Service端口
targetPort: 80 # Pod端口
---
# 3. HorizontalPodAutoscaler（HPA）：自动扩缩容
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment # 关联Deployment
minReplicas: 2 # 最小副本数
maxReplicas: 10 # 最大副本数
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization # 基于CPU利用率扩缩
averageUtilization: 50 # 目标CPU利用率（50%）- 操作系统
Linux ：文件系统、权限管理（chmod/chown）、进程管理（ps/top/kill）、日志分析（journalctl/rsyslog）。
Shell脚本 ：Bash/Python脚本编写（自动化任务、日志处理）。
Windows Server（可选）：AD域管理、PowerShell。 - 网络基础
TCP/IP协议栈、DNS/HTTP/HTTPS、VLAN/VPN、负载均衡（Nginx/HAProxy） 。
抓包工具：Wireshark、tcpdump。 - 配置管理
Ansible（无Agent）、SaltStack/Puppet（复杂场景）
模板化：Jinja（配合Ansible使用） - CI/CD流水线
工具：Jenkins、GitLab CI/CD、ArgoCD（GitOps）。
实践：代码构建（Maven/Gradle）、镜像打包（Docker）、滚动发布（K8s） - 容器化与编排
Docker：镜像构建（Dockerfile）、私有仓库（Harbor）。
Kubernetes：Pod/Deployment/Service、Helm包管理、Ingress路由。 - 监控与日志
指标监控：Prometheus + Grafana（可视化）、Zabbix（传统监控）。
日志系统：ELK（Elasticsearch+Logstash+Kibana）、Loki（轻量级）。
APM：SkyWalking、New Relic（应用性能追踪）。
运维工程师的技能要求
- 1b
1、负责大型混合云项目的网络规划设计和云平台软件部署 工作，保证项目按合同约定成功交付；
2、负责混合云项目转维后的售后问题响应、版本变更、故障处置等，及时拉通后端资源推动解决 ；
3、负责积累交付、运维过程中问题和需求转化 ，对混合云项目的交付效率进行持续优化；
4、持续提升混合云产品交付和运维能力，包含基础网络、虚拟网络、计算、存储、数据库、云原生等方向 。
1、云计算相关交付、运维、研发、架构 工作经验；
2、深入理解网络路由、交换基本技术原理和常见路由协议，熟悉大型项目组网方案，有实践经验；
3、对云基础、云原生底层技术架构有广泛了解，操作系统、虚拟化、分布式存储、数据库、容器 熟练掌握其中2-3项；
4、具备较强的沟通能力和高度的团队合作精神，具备较强组织协调能力； 极强的问题解决能力，习惯于寻找创新方法来达成目标； - 2a
1、负责DevOps平台相关基础设施的维护工作，优化持续集成与持续交付 （CI/CD）流程，提高研发效率；
2、搭建和优化容器化部署环境 （如Docker、Kubernetes），保障应用系统的稳定性与高可用性；
3、推动监控、日志分析体系的建设与完善，负责系统性能调优与故障排查；
4、参与开发运维工具的研发，提升自动化程度，减少人为操作风险 ；
5、推动基础设施即代码 （IaC）的实施，实现资源的自动化配置和版本化管理；
6、与研发团队紧密合作，参与系统架构设计 ，确保服务的安全性、扩展性和可用性；
7、持续学习并应用行业最新的技术实践 ，推动团队技术能力的提升
2、熟悉Linux操作系统 ，掌握Shell、Python、Golang等至少一种脚本或编程语言；
3、熟练掌握CI/CD工具链 （如Jenkins、GitLab CI、Github等）相关的基础设施运维经验；
4、精通至少一种脚本或编程语言（如Python、Bash），能够开发自动化脚本；
5、熟悉Jenkins，具备在Jenkins部署开发自动化脚本 的经验。
6、熟悉容器化技术（如Docker）及编排工具（如Kubernetes） ，了解微服务架构；
7、具备搭建和维护RabbitMQ，Artifacts等 服务的经验，掌握基于这些服务的DevOps开发设计；
8、熟悉常见监控和数据分析工具 （如Prometheus、Grafana等），能够独立完成监控体系搭建与优化；
9、良好的问题排查和解决能力，对高可用架构设计有深刻理解。
1、有DevOps工具链开发经验者优先，具有大规模分布式系统运维经验者优先；
2、有Jenkins基础设施运维相关经验者优先；
3、具备数据库管理经验（MySQL、Redis、MongoDB等）者优先；
4、熟悉HPC集群管理，IBM Spectrum LSF管理调度者优先。 - 3t
1.负责云产品稳定性治理 ，保障业务高度稳定性 ；
2.负责云产品容灾架构的设计和落地，提升故障快速自愈的手段和能力 ；
3.负责云产品线上生产变更管理、大规模故障容灾演练攻防 ，提升云产品稳定性的实战能力；
4.负责云产品技术类故障的生命周期管理 ，持续优化稳定性架构方案。
1.公有云产品相关工作经验，对计算、网络、数据库 等产品有深入的理解；
2.熟悉linux操作系统，具有较强的问题定位能力 ，熟练掌握go、python、java中至少一种开发语言；
3.对稳定性保障管理有丰富的实战经验，如复杂业务场景下的优化改进、系统的高可用性架构实现、业务生命周期稳定性环节治理 ；
4.有较好的沟通交流能力，善于主动思考和行动，乐于解决具有挑战性的问题 ，对待技术有强烈兴趣；
5.掌握同城多活、异地容灾、异地多活等容灾架构方案，在持续集成、容灾演习、混沌工程、监控等领域中，有相关实践经验优先。
3、技术栈 ------ 工具，功能化的问题解决器
什么是工具？
- 工具是目的与结果之间的桥梁 ，将抽象意图转化为具体行动。
- 本质：功能化的"问题解决器" 。核心是人类为达成特定目的而创造的中介手段，它通过延伸或增强人的能力，解决实践中的问题。
- 例如 ：
物理工具（锤子、车轮）延伸体能，扩大改造自然的能力 ；
数字工具（编程语言、AI）延伸认知，处理复杂信息。 - 工具链 ：
既需要广度（覆盖全生命周期），又需要深度（如K8s生态）
云原生技术栈
- 希望让应用更有弹性、容错性、可观测性，让应用更容易部署、管理编写、编排等，希望开发者能够更好的利用云的资源、产品以及交付能力。
- 关键技术栈 云原生技术栈全景图
容器化：Docker作为标准运行时，实现应用环境一致性。
编排平台：Kubernetes（K8s）为核心，管理容器生命周期、调度和自愈。
服务网格：Istio/Linkerd处理服务间通信（如流量控制、熔断）。
CI/CD流水线：ArgoCD、Tekton等实现GitOps驱动的持续交付。
基础设施即代码（IaC）：Terraform/Pulumi自动化云资源管理
- 云计算平台（公有云/私有云）
公有云：Google，Azure，AWS
私有云：OpenStack，VMware vSphere - 基础设施即代码（IaC）
配置管理：Ansible，Puppet，Chef，SaltStack
编排与模板化：Terraform（多云资源编排），Pulumi（支持编程语言定义资源） - 容器化与编排
容器引擎：Docker
容器编排：Kubernetes（K8s，行业标准） - 持续集成与持续部署（CI/CD）
代码托管 & 协作：GitHub / GitLab / Bitbucket
CI/CD 工具：Jenkins，GitLab CI/CD，GitHub Actions - 监控告警
Prometheus + Grafana（指标监控）
Nagios / Zabbix（传统监控）
Datadog / New Relic（SaaS监控） - 日志收集与分析
ELK Stack（Elasticsearch + Logstash + Kibana）
Fluentd / Filebeat（日志采集）
Loki（轻量级日志聚合）
Splunk（企业级日志分析） - 网络管理与安全工具
网络管理：Nginx / Apache（Web服务），Istio / Linkerd（服务网格），HAProxy / Traefik（负载均衡）
安全工具：Vault（密钥管理）Falco（容器运行时安全）Wazuh（安全监控） - 自动化脚本与编程
脚本语言：Bash / Python（运维自动化首选），PowerShell（Windows运维）
配置语言：YAML（K8s、Ansible），JSON / HCL（Terraform） - DevOps扩展工具
Helm（K8s包管理）
Kubectl / K9s（K8s命令行管理） k9s
Skaffold（本地K8s开发）
rclone存储挂载 rclone
K8s生态相关命令
shell
# 1.Docker
# 镜像管理
docker images # 查看本地镜像
docker pull <image> # 拉取镜像
docker rmi <image> # 删除镜像
docker build -t <tag> . # 构建镜像
# 容器管理
docker ps -a # 查看所有容器
docker logs <container> # 查看日志
docker exec -it <container> /bin/bash # 进入容器
docker run -d --name <name> <image> # 启动容器
docker stop <container> # 停止容器
# 2.kubectl
# 集群信息
kubectl cluster-info # 查看集群信息
kubectl config current-context # 当前上下文
kubectl get nodes # 查看节点状态
# 命名空间
kubectl get ns # 查看所有命名空间
kubectl create ns <name> # 创建命名空间
kubectl config set-context --current --namespace=<ns> # 切换当前命名空间
# pod操作
kubectl get pods -n <ns> # 查看Pod
kubectl describe pod <pod> # 查看Pod详情
kubectl logs <pod> # 查看Pod日志
kubectl exec -it <pod> -- /bin/bash # 进入Pod容器
kubectl delete pod <pod> # 删除Pod
kubectl get pods -o wide # 查看Pod分布节点
kubectl describe node <node> # 检查节点资源分配
# 部署和服务
kubectl get deploy,svc # 查看部署和服务
kubectl -n <namespace> get deploy,svc # 查看部署和服务
kubectl apply -f deploy.yaml # 通过YAML创建资源
kubectl scale deploy <name> --replicas=3 # 扩缩容
kubectl expose deploy <name> --port=80 --target-port=8080 # 创建Service
kubectl explain pod.spec.containers # 查看字段说明
# 3.k9s
k9s # 启动K9s（默认当前上下文）
k9s -n <namespace> # 指定命名空间启动
: # 进入命令模式（支持kubectl命令如 get pods）
/ # 搜索资源
d # 描述资源
l # 查看日志
s # 进入Shell
ctrl+d # 删除资源