【运维】云盘算的发展进程，云原生时代的运维理念&工具技能栈，高可用体系的云运维 —— 以K8S集群调度算法与命令为例
【运维】云盘算的发展进程，云原生时代的运维理念&工具技能栈(容器/镜像/编排, CI/CD, 网关/日志/监控) —— 以K8S调度算法与命令为例阐明：
基础架构的研发，还是要会一些运维技能的。
一方面方便自己上集群"手搓"，另一方自己开辟的内容也就方向于是，提供以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）等新范式
https://i-blog.csdnimg.cn/direct/fb5d0278f72d4c2ea82fc8d45762234e.png
https://i-blog.csdnimg.cn/direct/6788611693ca44579d1d0eee8badbe3f.png
https://i-blog.csdnimg.cn/direct/717178f753d64763a6204179fc36789b.png
https://i-blog.csdnimg.cn/direct/ab53cddd1e2a46c7a99dba0a1db60e6f.png
过去的二十年间，云盘算几乎重塑了整个行业格局。越来越多的企业开始低沉对 IT 基础办法的直接资源投入，不再倾向于维护自建的数据中心，而是通过上云的方式获取更强大的盘算、存储、网络资源，并实现按时、按需付费。这不仅低沉了 IT 支出，还显著低沉了行业技能壁垒，使更多公司，尤其是初创企业，能够更快速地落地业务想法并将其迅速推向市场。
https://i-blog.csdnimg.cn/direct/317c90737ff5469f8c96df32ced6d09f.png
https://i-blog.csdnimg.cn/direct/3d8b2705eeec4dcc9d554f9fcaee6031.png
引用：
阿里云创始人王坚：云盘算正在重新定义今天的世界 云栖 Creating value beyond computing
深入高可用体系原理与设计 图
1, 2,
2、云原生运维的概念 —— 运维，从手工业到自动化
云原生运维的本质是将传统运维的“手动干预”转化为“自动化计谋”，通过平台工程（Platform Engineering）为开辟团队提供自助式基础办法，同时确保稳定性与安全性。
从云原生说起
[*]云原生技能有利于各构造在公有云、私有云和混合云等新型动态情况中，构建和运行可弹性扩展的应用。云原生的代表技能包罗容器、服务网格、微服务、不可变基础办法和声明式 API。
这些技能能够构建容错性好、易于管理和便于观察的松耦合体系。结合可靠的自动化手段，云原生技能使工程师能够轻松地对体系作出频仍和可预测的重大变更。
https://i-blog.csdnimg.cn/direct/9897585c13234318a82d5e45f97ff691.png
[*]云原生架构必须要在同时满意这 3 个彼此冲突目标的前提下，还要实现本钱控制。
https://i-blog.csdnimg.cn/direct/3af961d9e59645b6976e8251f8774f65.png
[*]容器技能
https://i-blog.csdnimg.cn/direct/602d8ad37cff48eca9cb54c911d24147.png
[*]微服务
微服务架构是一种面向服务的架构，由松耦合的具有有限上下文的元素构成。
松耦合（Loosely Coupled）：意味着每个服务可以独立的更新，更新一个服务无必要求改变其他服务。
限界上下文（Bounded Contexts）：意味着每个服务要有明确的边界性，你可以只关注自身软件的发布，而无需思量谁在依赖你的发布版本。微服务和它的消耗者严格通过 API 举行交互，不共享数据结构、数据库等。基于契约的微服务规范要求服务接口是稳定的，而且向下兼容。
https://i-blog.csdnimg.cn/direct/982e83ff1e3a41cda5a53f5e182d43cd.png
https://i-blog.csdnimg.cn/direct/03685b4520e945dab8ea01b09bed9764.png
后微服务时代
https://i-blog.csdnimg.cn/direct/488a3c2e8e2e49deaa7be0721fd34201.png
[*]服务网格
定义：服务网格（ServiceMesh）是一个基础办法层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在现实应用当中，服务网格通常是由一系列轻量级的网络署理构成的，它们与应用步伐摆设在一起，但对应用步伐透明。
边车署理：
每个节点同时运行着业务逻辑和具备通信治理本事的网络署理（如 Envoy、Linkerd-proxy）。
数据平面（Data plane）：
通常采用轻量级的网络署理（如 Envoy）作为 Sidecar，网络署理负责协调和控制服务之间的通信和流量处理，解决微服务之间服务熔断、负载均衡、安全通讯等问题。
控制平面（Control plane）：
包含多个控制组件，它们负责设置和管理 Sidecar ，并提供服务发现（Discovery）、设置管理（Configuration）、安全控制（Certificates）等功能。
https://i-blog.csdnimg.cn/direct/cd4733c372154b2ab752ef8a3cf8f753.png
https://i-blog.csdnimg.cn/direct/d0ebac73d748457a8b16272dfc2911bb.png
https://i-blog.csdnimg.cn/direct/d9e332ab9a344b5db97676896e7b3dff.png
[*]不可变基础办法
重大故障时，难以快速重新构建服务：一连过多的手动操作并且缺乏记载，会导致很难由尺度初始化的服务器来重新构建起等效的服务；
不一致风险：类似于步伐变量因并发修改而带来的状态不一致风险。服务运行过程中，频仍的修改基础办法设置，同样会引入中间状态，导致出现无法预知的问题。
不可变基础办法思想的核心是，任何基础办法的运行实例一旦创建之后就变成只读状态。如需修改或升级，应该先修改基础办法的设置模版（比方 yaml、Dockerfile 设置），之后再使用新的运行实例替换。
https://i-blog.csdnimg.cn/direct/2dfdbadc81974a5da8a014f2de0da883.png
[*]声明式设计
声明式设计是指一种软件设计理念：“我们形貌一个事物的目标状态，而非达成目标状态的流程”。至于目标状态如何达成，则由相应的工具在其内部实现。
1、命令式设计：命令“呆板”如何去做事变（how），这样不管你想要的是什么（what），它都会按照你的命令实现；有一批图书的列表，你会编写下面类似的代码来查询列表：
for( var i=0; i< books.length; i++) {
if(books.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，正是我们开辟软件真正的目标。
https://i-blog.csdnimg.cn/direct/86e9c57d75ce4e21b81e44900c63c213.png
[*]DevOps
DevOps 核心本质是解决软件开辟生命周期中的管理问题。
瀑布模型：瀑布模型基于工程学的理念将整个过程分成差别的阶段，提供了软件开辟的基本框架，便于人员间的分工协作。同时，也可对差别阶段的质量和本钱举行严格把控。
瀑布模型产生于硬件范畴，它是从制造业的角度去看软件开辟的，产品迭代的频率常常按月为单元举行，在需求变革不多的年代，瀑布模型拥有其代价。随着软件行业的快速爆发，针对市场的快速变革和相应成了新的目标。这种场景下，需求无法得到快速验证是最大的风险，有大概花费数月开辟的产品早已不符合市场需求。
https://i-blog.csdnimg.cn/direct/37927b967fbf4a3fa99987fd45c10c9a.png
敏捷开辟：敏捷开辟是一种一连增量、不停迭代的开辟模式。开辟者快速发布一个可运行但不完善的版本投入市场，在后续迭代中根据用户的反馈改进产品，从而逼近产品的最终形态。
https://i-blog.csdnimg.cn/direct/928f7feb88bd428db96e2c4708fd9ef0.png
敏捷开辟提拔了开辟效率，但它的范围仅限于开辟和测试环节，并没有覆盖到摆设环节。显然，运维部门并没有收益。相反的，乃至可以说“敏捷”加重了运维的负担。运维追求的目标是稳定，频仍变更是破坏稳定的根源
https://i-blog.csdnimg.cn/direct/700f6aa61aaf4ee8a81480ac99e615d2.png
DevOps 的成功实践离不开工具上的支持，这其中包罗最紧张的自动化 CI/CD 流水线，通过自动化的方式买通软件从构建、测试到摆设发布的整个流程。尚有实时监控、事故管理、设置管理、协作平台等一系列工具/体系的配合。
https://i-blog.csdnimg.cn/direct/57d0e4205f114a6c8230aeb527b88ae7.png
[*]架构演进
从研发应用的角度看，研发的复杂度低沉了。在“强大底层体系”支撑的情况下，应用监控、通信治理、编排调度相干的逻辑从应用中剥离，并下沉到底层体系，已经符合云原生架构。
但站在整个体系的角度看，复杂度并没有淘汰和消失，要实现“强大底层体系”付出的本钱（人力本钱、资源本钱、技能试错本钱）黑白常昂贵的。为了低沉本钱，选择上云托管，将底层体系的复杂度交给云基础办法，让云提供保姆式服务，最终演变为无基础架构设计。
最后，通过 YAML 文件以声明式的方式，形貌底层的基础办法以及各类中间件资源，即应用要什么，云给我什么，企业最终走向开放、尺度的“云”技能体系。
https://i-blog.csdnimg.cn/direct/a04ec913fff34f4887770fefbda11b4e.png
[*]云原生不是简单使用云盘算平台运行现有的应用步伐，也不是某个开源项目大概某种技能，而是一套指导软件和基础办法架构设计的思想。基于这套思想构建出来的应用，能够天然地与“云”融合，充实发挥“云”的本事和代价。相应的，云原生生态中的开源项目 Kubernetes、Docker、Istio 等，就是这种思想落地的技能手段。
https://i-blog.csdnimg.cn/direct/3c265c15120248ef88c3e1b5be5071a4.png
什么是云原生运维？ 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 仅负责流量路由
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（自动扩缩容） 编排示例
# 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%）
运维通常必要掌握的技能 1 2
[*]操作体系
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自动化云资源管理
https://i-blog.csdnimg.cn/direct/e5d1c35cd4bb4719a5e000ffbc077a1d.png
重要工具推荐 1 2
[*]云盘算平台（公有云/私有云）
公有云：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生态相干命令
# 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 # 删除资源
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]