搜索到
92
篇与
的结果
-
解决磁盘空间不足报错的常用方法 在收到磁盘空间不足的警报时，在不能对存储空间扩容的情况下，通常可以使用以下两种方式解决。方法一使用 df -h 命令查看磁盘空间的使用情况，确定哪个目录占用的磁盘空间过高；确定目录后，使用 du -h 命令进行逐级定位，找到占用空间最大的大文件；查看文件内容，确认是否需要保留。如果保留就压缩导出，不保留就直接删除。方法二使用find命令查找目录下的大文件，如大于500M的文件，然后根据实际情况判断是否需要删除或导出。注意：使用df -h命令有时并不能发现大文件，可能的原因是文件已被删除，但是进程仍然在调用这个文件。此时可以通过 lsof | grep delete 命令找到占用的进程，把这个进程kill掉然后重启服务即可。 -
zabbix实现自动修复 核心逻辑zabbix的“监控-触发-动作”联动机制核心原则只处理“原因明确、修复方式固定、重复执行无副作用”的问题，目的是减少人工的重复劳动，而非代替人工决策。适用场景服务/进程异常：服务意外停止（如nginx、mysql进程消失）→ 自动重启；进程资源占用过高（内存/cpu超限）→自动重启释放资源资源阈值超标：磁盘空间满（如日志占满）→ 自动清理旧文件\日志；非核心进程资源超限→自动杀死异常进程网络/端口问题：关键端口未监听（如80，3306）→ 自动重启对应服务；临时网络抖动导致断开→ 自动重连服务配置文件/权限异常：服务配置文件误改→ 自动覆盖为备份文件；目录/文件权限错误→ 自动修正权限不适用的场景复杂故障：数据损坏、硬件故障（如硬盘坏道）；业务逻辑错误，代码bug需人工判断的情况：业务流量突增；多原因导致的同一现象高风险操作：删除数据库表、修改核心配置；可能引发连锁故障的操作
-
Linux常用系统监控工具介绍 在服务器管理和系统运维的日常工作中，实时监控系统资源使用情况是一项基础且关键的任务。除了比较基础的top命令外，比较常用的还有以下这些：htop：top命令的增强版glances：提供更全面的系统监控，包括网络、磁盘IO等atop：专注于长期性能监控和记录btop++：htop的现代替代品，提供更华丽的界面和更多功能iotop：专门监控磁盘IO使用情况nmon：IBM开发的系统监控工具，提供更多性能数据下面重点介绍一下htop命令。htop是一款功能强大且易于使用的Linux系统监控工具，它通过直观的界面和丰富的交互功能，大大提升了系统管理员监控和管理进程的效率。从基本的系统资源监控到复杂的进程管理，从简单的排序过滤到自定义显示配置，htop几乎能满足所有与进程监控相关的需求。在日常运维工作中，掌握htop的使用技巧不仅能帮助你快速定位系统问题，还能提高工作效率，减少排障时间。无论是处理高CPU负载、内存泄漏，还是需要快速终止失控进程，htop都能提供直观且高效的解决方案。htop界面详解运行htop时会看到一个分为上下两个部分的界面。顶部区域顶部区域显示系统的整体资源使用情况，包括：CPU使用率 每个CPU核心都有独立的使用率条，不同颜色代表不同类型的进程蓝色：低优先级进程绿色：普通用户进程红色：内核进程黄色/橙色：IRQ时间洋红色：软中断时间灰色：IO等待时间内存使用情况 显示物理内存和交换空间的使用百分比和具体数值绿色：已使用内存蓝色：缓冲区黄色/橙色：缓存负载平均值 显示1分钟、5分钟和15分钟的系统负载平均值正常运行时间 系统启动至今的运行时间任务统计 显示总进程数、运行中的进程数等信息底部区域底部区域显示系统中运行的进程列表，默认按CPU使用率排序。每个进程显示以下信息：PID：进程IDUSER：进程所有者PRI：进程优先级NI：nice值VIRT：虚拟内存大小RES：常驻内存大小SHR：共享内存大小S：进程状态（R=运行，S=睡眠，Z=僵尸等）CPU%：CPU使用百分比MEM%：内存使用百分比TIME+：进程运行时间Command：命令名称和参数htop操作技巧基本操作上下左右键：在进程列表中导航F5：切换树形视图，显示进程父子关系F6：选择排序字段F9：向进程发送信号（如终止进程）F10或q：退出htop进程管理htop最强大的功能之一是其直观的进程管理能力：终止进程：选中进程后按F9，然后选择要发送的信号（如SIGTERM或SIGKILL）调整进程优先级：选中进程后按F7（降低nice值）或F8（提高nice值）追踪进程系统调用：选中进程后按s，启动strace（需要安装strace工具）查看进程打开的文件：选中进程后按l，启动lsof（需要安装lsof工具）搜索功能在htop中，按下/键可以搜索特定进程。输入关键字后，htop会高亮显示匹配的进程。这在系统运行大量进程时特别有用。过滤功能 按下\键可以激活过滤功能，输入过滤条件后，htop只会显示符合条件的进程。例如，输入"apache"将只显示与apache相关的进程。自定义显示列 htop允许你自定义显示哪些进程信息列：按F2进入设置菜单选择"Columns"选项使用空格键选择或取消选择要显示的列F10保存并退出设置自定义配色方案如果你不喜欢默认的颜色方案，可以在设置菜单中进行更改：按F2进入设置菜单选择"Colors"选项选择预设的配色方案或自定义各元素的颜色F10保存并退出设置使用示例场景一：系统资源异常高，定位问题进程 当服务器CPU或内存使用率异常高时，可以通过以下步骤快速定位问题：启动htop，查看顶部的CPU和内存使用情况按F6，选择按CPU%或MEM%排序观察排在顶部的进程，这些通常是资源消耗最大的如果发现异常进程，可以进一步分析或终止它场景二：监控多核CPU的负载均衡情况在多核服务器上，理想情况下工作负载应该均匀分布在各个CPU核心上：启动htop，观察顶部的CPU使用率条检查各个核心的使用率是否平衡如果发现某个核心长期满负荷而其他核心空闲，可能表明应用程序不支持多线程或存在配置问题场景三：内存泄漏排查对于疑似内存泄漏的情况，可以使用htop进行初步排查：启动htop，按F6选择按MEM%排序记录可疑进程的内存使用情况定期观察这些进程的内存使用是否持续增长而不释放如果确认某进程存在内存泄漏，可以重启该进程作为临时解决方案，并进一步分析根本原因
-
PV与PVC之subPath（容器根目录设置） 在某些应用中，同一个Volume可能会被多个Pod或者一个Pod中的多个容器共享。此时可能存在个应用需要不同子目录的需求，可以通过Pod中volumeMounts定义的subPath字段进行设置。通过对subPath的设置，容器将以subPath设置的目录而不是Volume中提供的默认根目录作为根目录。subPath中的路径名称不能以“/”开头，需要使用相对路径的形式。如果希望通过环境变量的形式来设置subPath路径，可以通过subPathExpr字段来实现。subPath和subPathExpr字段是互斥的，不能同时使用。示例{tabs}{tabs-pane label="subPath"}--- apiVersion: v1 kind: Pod metadata: name: mysql spec: containers: - name: mysql image: mysql env: - name: MYSQL_ROOT_PASSWORD volue: "rootpassword" volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php image: php volumeMounts: - mountPath: /var/www/html name: site-data subPath: html volumes: - name: site-data persitentVolumeClaim: claimName: site-data-pvc{/tabs-pane}{tabs-pane label="subPathExpr"}--- apiVersion: v1 kind: Pod metadata: name: pod1 spec: containers: - name: containers1 image: busybox command: ["sh","-c","sleep 6000"] env: - name: POD_NAME volueFrom: fieldRef: apiVersion: v1 FilePath: metadata.name volumeMounts: - name: workdir1 mountPath: /logs subPathExpr: $(POD_NAME) restartPolicy: Never volumes: - name: workdir1 hostpath: path: /var/log/pods {/tabs-pane}{/tabs}
-
集群存储之PV与PVC PVPV：Persistent Volume 持久卷。资源提供者，根据集群的基础设施变化而变化，由集群管理员进行配置管理。PV将存储定义为一种容器应用可以使用的资源。PV由管理员创建和配置，它与存储资源提供者的具体实现直接相关。不同提供者提供的PV类型包括NFS、iSCSI、RBD或者由公有云提供的共享存储。PV与普通的临时卷一样，也是通过插件机制进行实现的，只是PV的生命周期独立于使用它的Pod。PV并不直接属于某个Pod。如果某个Pod想要使用PV，需要使用PVC来完成申请。随后Kubernetes会完成从PVC到PV的绑定。之后被绑定的PV就可以被申请的Pod使用了。一个PV只能被一个PVC绑定，被绑定的PV不能再被其他PVC绑定。 PART.01 PV详解 PV作为对存储资源的定义，主要涉及存储能力，访问模式，存储类型，回收策略，后端存储类型等关键信息的设置。不同类型的PV是以不同的插件进行设计和实现的，主要包括以下几类：CSI：CSI容器存储借口，由存储资源提供者提供驱动程序和存储管理程序FC（Fibre channel）：光纤存储设备hostPath：宿主机目录，仅供单Node测试iSCSI：iSCSI存储设备Local：本地持久化存储NFS：基于NFS协议的网络文件系统# 示例 apiVersion：v1 kind: PersistentVolume metadata: name: pv1 spec: capacity: storage: 5Gi volumeMode: Filesystem accesModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 10.15.55.55 存储容量（capacity）存储容量用于描述存储的容量，目前仅支持对存储空间的设置（storage=XX）。存储卷模式（volumeMode）可选性只有两个：Filesystem（文件系统，默认值）和Block（块设备）。文件系统模式的PV将以目录（Directory）形式被挂载到Pod内。访问模式ReadWriteOnce（RWO）：读写权限，只能被单个Node挂载（单用户读写）ReadOnlyMany（ROX）：只读权限，允许被多个Node挂载（多用户只读）ReadWriteMany（RWX）：读写权限，允许被多个Node挂载（多用户读写）ReadWriteOncePod（RWOP）：可以被单个Pod以读写方式挂载，仅支持CSI存储卷，用于集群中只有一个Pod时以读写方式使用这种模式的PVC。某些PV可能同时支持多种访问模式，但PV在挂载时只能使用一种访问模式，多种访问模式不能同时生效。节点亲和性（nodeAffinity）PV可以通过设置节点亲和性来实现只能通过某些Node访问Valume，这可以在PV定义的nodeAffinity字段中进行设置。使用这些Volume的Pod将被调度到满足亲和性要求的Node上。大部分存储驱动提供的volume都已自动完成亲和性的设置，通常无需用户手动设置。对于Local类型的PV，需要手动设置。apiVersion: v1 kind: PersistentVolume metadata: name: local-pv spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-storage local: path: /mnt/disks/ssd1 nodeAffinity: required: nodeSelectorterms: - matchExpressions: - key: kubernetes.io/hostname operator: In volues: - my-nodePV生命周期Available：可用状态，还未与某个PVC绑定Bound：以与某个PVC绑定Released：与之绑定的PVC已被删除，但未完成资源回收，不能被其他PVC使用Failed：自动资源回收失败 PART.01 PVC详解 PVC：PersistentVolumeClaim 持久卷声明。资源的使用着，根据业务的需求变化来配置，用户无需知道PV的技术细节，只需要声明你需要什么样的资源资源即可。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 8Gi storageClassName: slow selector: matchLabels: release: "stable" matchExpressions: - { key: environment, operator: In, values: [dev] } 说明resources：资源请求，描述对存储资源的请求，通过resources.requests.storage字段设置需求的存储空间的大小accessModes：访问模式，PVC也可以设置访问模式，用于描述用户应用对存储资源的访问权限volumeMode：存储卷模式，用于描述希望使用的PV存储卷模式，包括文件系统和块设备。PVC设置的存储卷模式最好与PV存储卷模式相同，以实现绑定。如果不同可能会出现无法绑定的结果。selector：PV选择条件，通过设置Label Selector，可以使PVC对于系统中已经存在的各种PV进行筛选。系统将根据标签选出合适的PV与该PVC进行绑定。对于选择条件，可以通过matchLabels和matchExpressions进行设置。如果两个字段都已设置，则Selector要同时满足才能完成匹配。Clas：存储类别，在定义PVC时可以设定需要的后端存储类别（通过storageClassName字段进行指定），以减少对后端存储特性的详细信息的依赖。只有设置了Class的PV才能被系统筛选出来，与该PV进行绑定。PVC也可以不设置Class需求，如果storageClassName字段的值被设置为空（storageClassName=""）,则表示该PVC不需求特定的Class，系统只选择未设定Class的PV与之绑定。PVC也可以完成不设置storageClassName字段，此时将根据系统是否启用了名为DefaultStorageClass的Admission Controller进行相应的操作。{mtitle title="PV和PVC的工作原"/}1.资源供应Kubernetes支持两种资源供应模式：静态（static）和动态（Dynamic）模式。资源供应的结果就是将适合的PV与PVC成功绑定。静态模式：集群管理员预先创建若干PV，在PV的定义中能够体现存储资源的特征。动态模式：集群管理员无需预先创建PV，而是通过StorageClass的设置对后端存储资源进行描述，标记存储的类型和特征。用户通过创建的PVC对存储类型进行申请。之后，StorageClass中的驱动提供者将自动完成PV的创建工作，并将创建出的PV与PVC进行绑定。如果PVC声明的Class为空，则说明PVC不适用动态模式。Kubernetes支持设置集群范围内默认的StorageClass，为用户创建的PVC设置一个默认的存储类StrongClass。2.资源绑定在用户定义好PVC后，系统将根据PVC对存储资源的请求（存储空间和访问模式），在已存在的PV中选择一个满足PVC要求的PV。一旦找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了。如果系统中没有满足PVC要求的PV，那么PVC会无限期处在pending状态，直到系统为其创建了一个满足要求的PV。PV一旦与某个PVC完成绑定，就会被这个PVC独占，不能再与其他的PVC绑定。PVC与PV的绑定关系是一对一的，不会存在一对多的情况。但是同一个PVC可以被多个Pod同时挂载（应用需要处理完成多个进程访问同一个存储的问题）。如果PVC申请的存储空间比PV拥有的存储空间少，则整个PV的空间都能为PVC所用。但是这可能造成一定的资源浪费。如果资源供应使用的是动态模式，那么系统在为PVC找到合适的StorageClass后，将自动创建一个PV并完成与PVC的绑定。3.资源使用当Pod需要使用存储资源时，需要在Volume的定义中引用PVC类型的Volume，将PVC挂载到容器内的某个路径下进行使用。Volume的类型字段为“persistentVolumeClaim”。Pod在被挂载了PVC后，就可以使用存储资源了。4.资源回收用户使用完存储资源后，可以删除PVC。与该PVC绑定的PV会被标记为“已释放”，但它还不能立刻与其他PVC绑定。Pod在该PVC中生成的数据可能还被保留在PV对应的存储设备上。只有在清楚了这些数据后，才能再次使用该PV。PV的回收策略Retain（保留）Delete（删除）Retain策略 表示在删除PVC后，与之绑定的PV不会被删除，仅被标记为已释放（released）。PV中的数据仍然存在，在清空数据之前不能被新的PVC使用，需要管理员手动清理之后才能继续使用。清理步骤：删除PV资源对象，此时与该PV关联的某些外部存储资源提供者的后端存储资产（Asset）中的数据仍然存在。手动清理PV后端存储资产中的数据。手动删除后端存储资产。如果希望重用该资产，可以创建一个新的PV与之关联。Delete策略 表示自动删除PV资源对象和相关后端存储资产，同时会删除与该PV关联的后端存储资产。但并不是所有类型的存储资源都支持Delete策略。通过动态供应机制创建的PV将继承StorageClass的回收策略，默认为delete策略。管理员应该基于用户的需求来设置StorageClass的回收策略，或者在创建出PV后手动更新其回收策略。存储对象保护机制存储资源（PV、PVC）相对于容器应用（Pod）是可以独立管理的资源，可以单独将其删除。在执行删除操作时，系统会检测存储资源当前是否正在被使用，如果仍被使用，则相关资源对象的删除操作会被推迟，直到没有被使用才会执行删除操作。这样可以确保资源在仍被使用的情况下，不会被直接删除而导致数据丢失，这个机制被称为使用中的存储对象的保护机制（Storage Object in Use Protection）。对于PVC的删除操作将等到使用它的Pod被删除后再执行。当用户删除一个正在使用中的PVC时，PVC资源对象不会被立即立即删除，查看PVC资源对象的状态，可以看到其为“Terminating”，以及系统为其设置的Finalizer为“kubernetes.io/pvc-protection”，说明PVC资源对象处于被保护状态。对PV的删除操作将等到绑定的PVC删除之后再执行。当用户删除一个仍被PVC绑定的PV时，PV对象不会立即被删除，查看PV资源对象的状态，可以看到其为“Terminating”，以及系统为其设置的Finalizer为“kubernetes.io/pv-protection”，说明PV资源对象处于被保护状态。总的来说，PV与PVC的删除顺序是这样的：先删除正在使用PVC的Pod，再删除PVC，最后删除PV。
