智联云科，你的云原生管家

概要在 Kubernetes 的生产环境下，使用 StorageClass + 动态供应（Provisioner）的 NFS、云厂商 CSI 插件（如阿里云、AWS EBS）已经成为有状态服务持久化的主流。然而，很多人遇到“服务挂掉重建后卷丢失”、“PVC 不小心被删就数据没了”这类生产事故。本篇就结合实战，系统梳理 K8s 动态供应存储卷的生命周期管理和高可用恢复策略。 1. Kubernetes 动态供应存储的核心机制 PVC（PersistentVolumeClaim）创建时，Kubernetes StorageClass 动态供应器会自动生成 PV（PersistentVolume）和后端实际存储盘。 服务重建，只要继续挂载原 PVC，数据依然不变！ 一旦 PVC 删除，PV 及其盘会根据 StorageClass 的回收策略 (reclaimPolicy) 决定是“删除”还是“保留”。 Delete：PV 和底层存储盘一起删除（危险，数据全无，云磁盘直接销毁） Retain：PV/PVC 解绑但数据和 PV 依然保留（可手动恢复，最安全） 结论： ...

从零入门Kubernetes（三节学习笔记）：核心对象、持久化存储与网络基础 本文作者：yanghuajun336更新时间：2025-12-31 本篇笔记适合Kubernetes入门和有一定实战经验的提升者，内容涵盖核心K8s资源对象（Deployment、StatefulSet等）、持久化卷存储机制、以及Service/Pod/Ingress的网络通信和基础安全要点。 第一章：K8s核心对象进阶——Deployment、StatefulSet、DaemonSet1. Pod1.1 概念 Pod是Kubernetes中最小的可调度单元 通常包含一个（或极少数几个）高度耦合的容器 1.2 作用与使用场景 跑临时、一次性任务 需要多个协作容器（如主应用+sidecar） 演示实验性容器运行 1.3 示例 YAML12345678910apiVersion: v1kind: Podmetadata: name: mypodspec: containers: - name: nginx image: nginx:1.25 ports: ...

前言在 Kubernetes 集群中使用 Velero 进行备份时，遇到了 BackupStorageLocation 一直处于 Unavailable 状态的问题，导致备份任务无法执行。本文详细记录了从问题发现到最终解决的完整排查过程，涉及多个常见的配置陷阱和已知 Bug，希望能为遇到类似问题的朋友提供参考。 环境信息 Kubernetes 版本: v1.32.0 Velero 版本: v1.17.1 Velero AWS 插件版本: v1.1.0（初始）→ v1.10.0（最终） 对象存储: 腾讯云 COS（兼容 S3 协议） 存储桶: backup-1356016796 地域: ap-guangzhou（广州） 问题现象初始错误执行备份命令后，BackupStorageLocation 一直显示 Unavailable： 123456$ velero backup create gitea-backup --include-namespaces app-codehub -n kube-backupBackup request "gitea-backup&q...

本文总结了一次在 Higress/Gateway API 环境中，HTTPRoute 无法生效的排查与修复过程。 背景 集群用了 Higress 作为 Gateway API 的实现（gateway 名为 higress-gateway）。 Gateway 上配置了若干 HTTPS listener：services.zlinkcloudtech.com（名为 https）、blog.zlinkcloudtech.com（https-blog）、workflow.zlinkcloudtech.com（https-workflow）、repo.zlinkcloudtech.com（https-repo）等。 我们在 app-harbor 命名空间创建了一个 HTTPRoute，host 是 repo.zlinkcloudtech.com，parentRef 指向 higress-gateway 并使用 sectionName: https（对应 services.zlinkcloudtech.com） 现象 kubectl describe httproute ha...

摘要本文以实践视角解释 Gateway API（规范）与 Higress（实现）之间的关系，何时使用它们、如何理解常见概念、以及在集群中部署与调试时应注意的关键点。面向正在从 Ingress 迁移或者准备引入 Gateway API 的平台与应用开发者。 什么是 Gateway API（简明）Gateway API 是 Kubernetes SIG-Networking 推出的下一代边缘流量 API，一套由 CRD 构成的规范，目标代替传统 Ingress 的表达能力限制。核心设计目标包括： 将网关（Gateway）职责与路由（Route）职责分离； 支持多协议、多端口、多监听器（Listener）与更丰富的匹配规则； 更好地支持多团队、跨命名空间委托与权限控制（ReferenceGrant）； 提供可扩展的“平台管理员负责网关，应用开发者负责路由”的工作流。 关键概念（快速参照） GatewayClass：类似于 StorageClass，定义一种网关实现类型，由某个 controller 负责实现（通过 controllerName 识别）。 Gateway：在命名空间...

摘要本文记录一次在 Kubernetes 上部署 PhotoPrism 时遇到 CrashLoopBackOff 的完整排查过程，以及在安装 Gateway API CRD（用于 Higress）时遇到的兼容性问题与解决办法。文中包含了要运行的命令、分析思路与最终的解决方案，便于在类似场景中快速定位与修复。 环境说明 Kubernetes Server: v1.21.1 kubectl Client: v1.34.2 PhotoPrism 镜像: photoprism/photoprism:250321 部署方式: Helm chart（StatefulSet，使用 PVC） 目标：启动 PhotoPrism 并安装 Gateway API CRD 供 Higress 使用 一、问题现象（简述）部署后 Pod 一直处于 CrashLoopBackOff，kubectl logs 看到 PhotoPrism 启动日志能走到打开 SQLite，但随后 s6 停止服务并退出；同时 kubectl describe pod 有大量 probe 报错（connection re...

摘要本文记录一次在 Kubernetes 上部署 PhotoPrism 时遇到 CrashLoopBackOff 的完整排查过程，以及在安装 Gateway API CRD（用于 Higress）时遇到的兼容性问题与解决办法。文中包含了要运行的命令、分析思路与最终的解决方案，便于在类似场景中快速定位与修复。 环境说明 Kubernetes Server: v1.21.1 kubectl Client: v1.34.2 PhotoPrism 镜像: photoprism/photoprism:250321 部署方式: Helm chart（StatefulSet，使用 PVC） 目标：启动 PhotoPrism 并安装 Gateway API CRD 供 Higress 使用 一、问题现象（简述）部署后 Pod 一直处于 CrashLoopBackOff，kubectl logs 看到 PhotoPrism 启动日志能走到打开 SQLite，但随后 s6 停止服务并退出；同时 kubectl describe pod 有大量 probe 报错（connection re...

在生产集群中修改 Master 节点 IP 是一项高风险操作。这篇笔记记录了我在单 Master（kubeadm 部署）集群中，将控制平面地址从 43.139.105.42（master.cluster.zlinkcloudtech.com）迁移到 172.16.16.10 的完整过程。 ⚠️ 强烈建议：先在测试环境演练，并务必做好 ETCD 与 /etc/kubernetes 目录的完整备份，失败时才能快速回滚。 1. 前提检查与备份1234# 备份 /etc/kubernetes 全量配置（含 kubeconfig、证书、静态 Pod 清单）sudo cp -Rf /etc/kubernetes/ /etc/kubernetes_bak# 根据自身情况创建 ETCD 快照（略） 2. 替换配置文件中的旧地址集中处理 Master 节点本地配置以及当前用户的 kubeconfig。 12345678910111213# 1) 处理 /etc/kubernetes 下所有文件cd /etc/kubernetessudo find . -type f -exec se...

前言Kubernetes RBAC（基于角色的访问控制）是集群安全的核心机制。本文通过”剧场模型”和”公司架构”两个类比，深入剖析 RBAC 的设计逻辑和实现原理。 一、RBAC 的核心模型：剧场类比1.1 三要素关系在 RBAC 中，权限控制由三个核心要素构成： 123角色（Role/ClusterRole）= 剧本（定义可执行的操作）绑定（RoleBinding/ClusterRoleBinding）= 选角（建立身份与角色的映射）主体（User/ServiceAccount）= 演员（实际执行操作的身份） 设计哲学： 角色与身份分离：剧本（Role）独立于演员（Subject），实现权限复用 声明式授权：通过绑定（Binding）声明”谁拥有什么权限” 最小权限原则：精细化定义每个角色的操作范围 1.2 权限授予的完整链路123456789101112131415161718192021222324# 1. 定义剧本（Role）：运维工程师能做什么apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: ...

kcptun 极速网络隧道，让数据传输飞起来！ 下载 kcptunLinux 下载1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071#!/usr/bin/env bash# Detect the operating system type and architectureOS=$(uname | tr '[:upper:]' '[:lower:]')ARCH=$(uname -m)# Map architecture to the corresponding string used in the release namescase "$ARCH" in x86_64 | amd64) ARCH="amd64" ;; i386 | i686) ...