K8s 深度拆解：健康检查、认证授权与可视化面板全梳理

暖核2026-10-29 10:23

Kubernetes 健康检查、认证授权与 Web 管理面板学习

博客说明：本文基于课堂实验整理，覆盖 Pod 健康探针、K8s 完整访问控制流程、RBAC 权限体系、ServiceAccount 服务账号、Kuboard、Kubernetes‑Dashboard 可视化面板，包含原理、参数解析、实验现象、踩坑点、生产最佳实践，适合云原生运维学习复盘。

前言

Kubernetes 集群运维，两件事至关重要：应用运行的可用性保障 、集群 API 访问的安全权限管控。

  • 健康检查（Probe）解决：应用内部卡死、假死，但是容器进程不退出的问题，自动实现故障 Pod 重启、流量隔离。
  • 认证 & 授权（AuthN/AuthZ）解决：谁可以访问集群、能够执行哪些操作，是集群安全的基石。
  • 可视化 Web 面板降低运维门槛，方便排查问题，分为官方 Dashboard 和第三方增强工具 Kuboard。

整个 K8s API 访问链路：TLS 传输加密 → 身份认证 (Authentication) → 鉴权授权 (Authorization) → 准入控制 (Admission Control) → 审计 (Audit)

第一部分 Kubernetes Health Check 健康检查

kubelet 是运行在每个节点上的代理组件，探针 Probe 由 kubelet 执行，不是 apiserver，周期性对容器做健康检测，根据返回结果执行不同动作。

没有配置探针的坑：容器主进程正常运行，但是业务逻辑已经故障，比如 web 服务主页文件被删除，进程还活着，Pod 状态显示 Running，但是业务访问报错，流量依旧转发给故障实例。

1. 三种探针 Probe Type

表格

探针名称 中文名称 核心用途 探测失败之后的行为 适用场景
livenessProbe 存活探针 检测容器应用是否还活着，是否卡死死锁 重启该 Pod 容器 业务死锁、内部异常无法自恢复，需要重启修复
readinessProbe 就绪探针 检测容器是否已经完成初始化，可以对外提供业务流量 将此 Pod IP 从 Service Endpoints 列表移除，不再接收业务流量，不会重启 Pod 应用启动慢，需要加载缓存、连接数据库，还没准备好不能接收请求
startupProbe 启动探针 专门应对启动非常慢的应用；startupProbe 成功之前，liveness、readiness 不会执行 失败直接重启 Pod 大数据量初始化、预热缓存，启动耗时很长，防止还没启动完就被 liveness 误杀

重要：startupProbe探测成功完成之后，liveness 和 readiness 探针才会开始工作。慢启动业务生产强烈建议配置。

2. 三种探测方式 Checking Methods

① httpGet HTTP 探测

向容器内指定端口、path 发送 HTTP GET 请求。

  • 判断成功：HTTP 状态码 200 ≤ statusCode ＜400
  • 判断失败：其余状态码、连接超时 适合 Web 服务，httpd、nginx、springboot 等提供 http 接口的业务。 yaml 关键字段：httpGet: {path: "/index.html", port: 80, scheme: HTTP}

② exec 命令探测

在容器内部执行一条 shell 命令。

  • 判断成功：命令退出返回码 exit 0
  • 判断失败：返回非 0，或者超时 适合没有 http 接口的程序，比如中间件、后台脚本服务。
bash 复制代码 
exec:
  command:
  - cat
  - /tmp/healthy

③ tcpSocket TCP 端口探测

kubelet 尝试和容器的端口建立 TCP 连接。

  • 判断成功：TCP 连接可以建立 适合 TCP 长连接服务，mysql、redis 等。
bash 复制代码 
tcpSocket:
  port: 3306

补充：还有 grpc 探测，需要业务实现 grpc 健康检查，课程没有重点讲解。

3. 探针通用配置参数详解

bash 复制代码 
livenessProbe:
  initialDelaySeconds: 5    # 容器启动完成之后，延迟多少秒才第一次执行探针；容器初始化时间长要调大
  periodSeconds: 5          # 探针执行间隔，每多少秒探测一次，默认10s，最小1
  timeoutSeconds: 10        # 单次探测超时时间，如果探测超过这个时间直接判定失败，默认1s，最小1
  successThreshold: 1       # 连续多少次探测成功，标记为健康，失败后生效，一般写1
  failureThreshold: 3      # 连续多少次探测失败，判定整体探针失败，执行对应动作，默认3次

实验现象回顾

  1. livenessProbe httpGet 实验：删除 httpd 的 index.html 页面，http 访问返回 404，连续 3 次失败，Pod RESTARTS 计数 + 1，容器被重启，页面恢复。
  2. readinessProbe httpGet 实验 ：删除 index.html，Pod 状态变为 0/1 Running，Pod 进程还在运行，Service Endpoints 会把这个 Pod 的 IP 剔除，流量不会再转发过来；修复页面之后，readiness 探测成功，重新加入 endpoints 接收流量。

4. Health Check 真实业务场景

场景 1：水平扩容 Scale Up

当执行kubectl scale增加副本数，新创建的 Pod 不会立刻对外提供流量。 readinessProbe保证：只有业务真正就绪之后，才加入 Service 后端接收流量，避免流量打向还没初始化完毕的 Pod。

场景 2：滚动更新 RollingUpdate

滚动更新的时候 K8s 会逐步创建新版本 Pod，销毁旧版本 Pod。

  • ✅配置就绪探针：新版本 Pod 多次 readiness 失败，就不会被认为就绪，滚动更新停止，旧副本不会被回收，业务继续运行。
  • ❌没有配置探针：只要容器进程启动，就判定就绪，全部旧 Pod 被替换；新版本全部故障，整个业务完全宕机。

生产红线：Web 业务必须配置 liveness+readiness 探针；启动慢的业务增加 startupProbe。

5. 环境清理命令

bash 复制代码 
kubectl delete ns health

第二部分 Kubernetes 认证与授权

概念区分 认证 Authentication：你是谁？身份校验 ，返回 401 未认证 授权 Authorization：你可以干什么？权限校验，返回 403 禁止访问

2.1 API 完整访问控制流程

  1. 传输安全 TLS kube‑apiserver 默认监听 6443 端口，全部 HTTPS 加密通信。apiserver 向客户端出示服务端证书；客户端需要 CA 证书确认服务端身份，防止中间人攻击。配置参数：--tls‑cert‑file、--tls‑private‑key‑file。客户端~/.kube/config存放 CA 证书。
  2. 身份认证 Authentication（步骤①） 多种认证插件，apiserver 会依次尝试各个插件，只要一个插件认证成功就通过；全部失败返回 HTTP 401 Unauthorized。

常见认证插件：

  1. X509 客户端证书 ：最常用，我们平时 kubectl 访问集群就是这个方式。apiserver 参数--client‑ca‑file=/etc/kubernetes/pki/ca.crt；证书中的 CN 字段代表用户名，O 代表用户组。
  2. 静态令牌文件 token‑auth‑file：csv 文件，token,username,uid,group，默认不启用。
  3. Bootstrap Token 引导令牌：kubeadm 节点加入集群使用，存放在 kube-system 命名空间 Secret。
  4. ServiceAccount 令牌：Pod 内部访问 apiserver 默认方式，JWT 令牌。
  5. Webhook 令牌认证、身份代理、basic‑auth（1.19 版本已经废弃）

匿名请求：所有认证插件都没有匹配成功，请求变成匿名用户 system:anonymous，用户组system:unauthenticated。
⚠️重点：Kubernetes没有 User 资源对象！K8s 不存储普通用户，普通用户全部依赖外部认证（证书、token），集群不能通过 API 创建 / 删除用户。只有 ServiceAccount 是 K8s 内置 API 资源。
K8s 两类用户

  1. 普通用户 User：给人使用，由 CA 证书、外部系统签发；集群没有 User 对象，不能 kubectl create user。
  2. 服务账号 ServiceAccount (SA)：给 Pod 里面的程序使用，命名空间级别资源，可以 kubectl 增删改查。每个 namespace 自带 default SA。
  1. 鉴权授权 Authorization（步骤②） 身份认证通过之后，进入鉴权。apiserver 会拿到：用户名、用户组、要操作的资源、命名空间、动作 verb。 集群 apiserver 参数 --authorization‑mode=Node,RBAC，代表同时启用 Node 和 RBAC 鉴权。

支持鉴权模式：

  • RBAC：基于角色访问控制，生产主流；
  • Node：专门给 kubelet 节点鉴权；
  • ABAC：基于属性，已经很少使用；
  • Webhook：外部 http 服务做鉴权；
  • AlwaysAllow：全部允许，测试用，生产严禁；
  • AlwaysDeny：全部拒绝。

多个鉴权模块，只要任意一个模块允许，请求放行；全部模块没有允许，则拒绝，返回 403。

  1. 准入控制 Admission Control（步骤③）

只作用于 create/update/patch/delete 等写操作，查询 get/list 不会走准入控制器 。 准入控制器是一系列插件，所有插件全部通过，请求才放行；只要一个拒绝直接 403。 准入控制器可以修改请求内容，设置默认值，校验资源合法性。

  1. 审计 Audit 按时间顺序记录集群安全相关操作日志，记录谁、什么时间、执行了什么 API 操作，用于安全排查追溯。

2.2 普通 X509 证书用户完整实操流程

因为 k8s 没有 User 资源，用户依靠集群 CA 签发的证书实现身份认证。

  1. 客户端生成私钥和证书请求 csr
bash 复制代码 
# 生成私钥
openssl genrsa -out laoma.key 2048
# 生成证书请求，CN是用户名，O是用户组
openssl req -new -key laoma.key -out laoma.csr -subj '/CN=laoma/O=kubernetes'
# 把csr传给master管理员节点
scp laoma.csr root@master30:
  1. 管理员 master 节点，使用集群 CA 签名证书
bash 复制代码 
openssl x509 -req -in laoma.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out laoma.crt -days 1095
# 把证书、CA证书下发给客户端
scp laoma.crt /etc/kubernetes/pki/ca.crt root@client:~
  1. 客户端构建 kubeconfig 两种方式，推荐kubectl config命令生成 config，不建议手写 base64。
bash 复制代码 
# 设置集群信息，embed‑certs把证书内容嵌入config文件，不用外部证书文件
kubectl config set‑cluster kubernetes --kubeconfig=config \
--certificate‑authority=ca.crt --server=https://10.1.8.30:6443 --embed‑certs

# 设置用户凭据
kubectl config set‑credentials laoma --kubeconfig=config \
--client‑key=laoma.key --client‑certificate=laoma.crt --embed‑certs

# 设置上下文context：集群、命名空间、用户绑定在一起
kubectl config set‑context laoma@kubernetes --kubeconfig=config \
--cluster=kubernetes --user=laoma --namespace=default
# 设置当前默认上下文
kubectl config use‑context laoma@kubernetes --kubeconfig=config
  1. 分配权限：证书只是身份，没有 RBAC 绑定依旧什么都做不了
bash 复制代码 
# 给laoma用户绑定集群管理员权限
kubectl create clusterrolebinding laoma‑admin --clusterrole=cluster‑admin --user=laoma
  1. 用户验证与回收权限
bash 复制代码 
# 客户端指定配置文件测试
kubectl get nodes --kubeconfig=config

# 回收权限：删除绑定，证书还在，但是没有权限
kubectl delete clusterrolebinding laoma‑admin

重点坑：删除 rolebinding 只是回收权限。证书如果没有作废，用户依旧可以完成认证，只是鉴权返回 403。想要彻底禁用该用户，需要吊销客户端证书（CA 黑名单）。K8s 不能删除 User，User 不是集群资源。

2.3 RBAC 详解 Role & ClusterRole & Binding

RBAC 思想：把一堆权限规则封装为角色 Role；再通过 Binding 绑定给 User / ServiceAccount。

表格

资源对象 作用范围 绑定对象
Role 仅当前命名空间内生效 RoleBinding
ClusterRole 集群级别，可以作用全部 namespace ClusterRoleBinding（全局生效） / RoleBinding（限定某一个 namespace 使用）
RoleBinding 命名空间内，绑定 Role 或者 ClusterRole，权限限制在本 ns User / Group / SA
ClusterRoleBinding 集群全局绑定 ClusterRole，权限所有 namespace 生效 User / Group / SA

关键点：ClusterRole 是集群资源。如果用 RoleBinding 引用 ClusterRole，权限只会在 RoleBinding 所在的命名空间生效，不会全局生效。

RBAC 规则四要素

bash 复制代码 
apiGroups

：资源所属 API 组

  • pod/service：apiGroups: [""]
  • deployment：apiGroups: ["apps"]
  • job：apiGroups: ["batch"]

  1. resources：资源名称 pods deployments configmaps

  2. resourceNames：选填，限定某一个具体资源名称，不填代表全部该类型资源

bash 复制代码 
verbs

允许的动作

  • get 获取单个资源详情
  • list 获取资源列表，get 和 list 是两个独立权限！有 get 不代表可以 list
  • watch 监听资源变化
  • create 创建
  • update/patch 修改
  • delete 删除
  • exec 进入 pod 终端

查看资源属于哪个 apiGroup：

bash 复制代码 
kubectl api‑resources
kubectl explain deployment

系统预定义 ClusterRole

  • view：只读权限，可以 get/list/watch 绝大多数资源，不能修改删除
  • edit：普通开发，本命名空间读写业务资源，不能看 RBAC 相关
  • admin：命名空间管理员，当前 ns 全部权限
  • cluster‑admin：集群超级管理员，全部权限，生产尽量少分配

Role 简单示例 yaml

bash 复制代码 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod‑reader
  namespace: auth
rules:
‑ apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]

RoleBinding，把 Role 绑定给用户 laoma

bash 复制代码 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: laoma‑pod‑reader
  namespace: auth
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod‑reader
subjects:
‑ kind: User
  name: laoma
  apiGroup: rbac.authorization.k8s.io

2.4 ServiceAccount 服务账号详解

User 给人；ServiceAccount 给 Pod 内部运行的程序。Pod 内部的程序访问 apiserver，就用 SA 身份。

  1. 每个 namespace 会自动创建default SA，如果 Pod 不写 serviceAccountName，就使用 default 账号。
bash 复制代码 
kubectl get sa
  1. SA 令牌挂载机制（k8s1.24 + 重大变更） Pod 启动的时候 kubelet 执行：
  2. 获取 Pod 配置的serviceAccountName；
  3. 通过 TokenRequest API 获取短期 Bound ServiceAccount Token（默认 1 小时有效期）；
  4. 使用 projected 投射卷，自动挂载到容器内部固定路径： /var/run/secrets/kubernetes.io/serviceaccount/ 容器内三个文件：
  • token：JWT 身份令牌
  • ca.crt：集群 CA 证书
  • namespace：当前 Pod 所在命名空间名称

⚠️1.24 之后不再自动创建永久 Secret 存储 SA token。短期 token：Pod 删除、过期自动失效，安全性更高。

Pod 内部程序访问 apiserver 逻辑：

  1. 读取容器内 token；
  2. http 请求头带上 Authorization: Bearer <token>；
  3. apiserver 校验 token，解析对应的 ServiceAccount（namespace/sa‑name）；
  4. 查询所有绑定这个 SA 的 RoleBinding/ClusterRoleBinding；
  5. RBAC 规则判断是否放行 API 请求。

SA 完整操作示例

  1. 创建 SA
bash 复制代码 
kubectl create sa sa1 -n auth
  1. 给 SA 绑定权限，绑定格式 namespace:sa名称
bash 复制代码 
kubectl create clusterrolebinding sa1‑cluster‑admin --clusterrole=cluster‑admin --serviceaccount=auth:sa1
  1. Pod 指定 serviceAccountName 使用 SA
bash 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  serviceAccountName: sa1
  containers:
  ‑ name: web
    image: httpd
  1. 手动生成 SA 的临时 token（推荐）
bash 复制代码 
kubectl create token sa1 -n auth

临时 token，有过期时间。

  1. 手动创建永久 token（不推荐，兼容旧版本） 写一个 type 为kubernetes.io/service‑account‑token的 Secret，增加注解kubernetes.io/service‑account.name: sa1。SA 删除，该 secret 会被自动清理。

用户账号 vs 服务账号对比表

表格

对比项 普通用户 User 服务账号 ServiceAccount
使用对象 人，运维开发人员 Pod 内部应用程序
API 资源对象 集群没有 User 资源，不能 kubectl 创建 k8s 内置 API 资源，命名空间级别，可以 kubectl 增删改查
作用域 集群全局，用户名集群唯一 命名空间隔离，不同 ns 可以同名 SA
凭据来源 X509 客户端证书 JWT 令牌，kubelet 自动挂载到 Pod

思考题：为什么 K8s 不内置数据库存储用户账号？ K8s 专注做容器编排，身份认证做插件化接口。可以无缝对接企业现有的 LDAP、AD、Keycloak 等账号系统，不和集群强耦合，符合 Unix 设计哲学：一个软件只做好一件事。

2.5 清理 auth 命名空间

复制代码 
kubectl delete ns auth

第三部分 Kubernetes Web 可视化面板

kubectl 命令行高效，但是可视化界面降低学习门槛，方便新手，快速浏览资源、查看事件、日志。课程介绍两个主流工具：Kuboard（第三方增强）、Kubernetes‑Dashboard（官方）。

3.1 Kuboard

Kuboard 是国内开源免费的 K8s 管理界面，企业大量用于生产，支持 k8s 1.13+。

核心特点

  1. 多集群管理：一个 Kuboard 界面，管理多套 Kubernetes 集群；v2.x 只支持单集群，v3.x 支持多集群。
  2. 多种身份认证方式 ：内置账号密码、LDAP、GitLab/GitHub SSO 单点登录；不用直接把 ServiceAccount token 分给普通用户，安全很多。
  3. 微服务架构视图：按照微服务分层展示工作负载，架构直观。
  4. 图形化操作，尽量不用手写 YAML，图形界面编辑 Deployment、Service、RBAC 等几乎全部资源。
  5. 内置工具集：
    • 监控套件：Prometheus+Grafana，监控节点、Pod CPU 内存磁盘；
    • 日志套件：Loki 日志聚合；
    • 容器终端、容器文件上传下载浏览器；
    • 告警：支持微信、邮件告警；
    • 完整操作审计日志，记录所有用户在页面上的操作。

Kuboard 三种部署方案

  1. 独立容器运行【官方推荐】 Kuboard 部署在集群外部的机器上，容器运行，和被管理 K8s 解耦；适合管理多集群。
bash 复制代码 
mkdir /kuboard‑data
nerdctl run ‑d --name=kuboard \
‑p 80:80/tcp \
‑p 10081:10081/tcp \
‑e KUBOARD_ENDPOINT="http://10.1.8.30:80" \
‑e KUBOARD_AGENT_SERVER_TCP_PORT="10081" \
‑v /kuboard‑data:/data \
eipwork/kuboard:v3

登录账号密码默认 admin / Kuboard123，导入集群的~/.kube/config连接 K8s 集群。

  1. 在 K8s 集群内部部署为 Pod；
  2. static pod 静态 Pod 部署在 master 节点（自学）。

卸载独立容器版本：

bash 复制代码 
nerdctl rm ‑‑force kuboard
rm ‑rf /kuboard‑data

3.2 Kubernetes Dashboard（官方）

官方原生 WebUI，功能精简，官方维护。

部署

下载官方 yaml 清单部署，命名空间：kubernetes‑dashboard

bash 复制代码 
kubectl apply -f recommended.yaml

默认权限非常小！ 默认 dashboard 的 ServiceAccount 只拥有读取 metrics 指标的权限，默认看不到 pod、deployment 等业务资源。

新版本 Dashboard 只支持 Bearer Token 登录，不再支持用户名密码登录。

获取登录 token

bash 复制代码 
kubectl -n kubernetes‑dashboard create token kubernetes‑dashboard

token 短期有效，过期之后要重新生成。

提升权限（实验环境使用）

⚠️生产环境禁止直接绑定 cluster‑admin 超级管理员，遵循最小权限原则！

bash 复制代码 
kubectl create clusterrolebinding dashboard‑cluster‑admin \
‑‑clusterrole cluster‑admin \
‑‑serviceaccount kubernetes‑dashboard:kubernetes‑dashboard

访问方式

  1. 修改 dashboard service 类型为 NodePort，通过节点 IP+NodePort 端口访问 HTTPS；
  2. 配置 Ingress，开启ssl‑passthrough: trueTLS 透传，Ingress 不解密证书，直接转发 HTTPS 流量到 dashboard 后端。

ingress 示例：

bash 复制代码 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress‑dashboard
  namespace: kubernetes‑dashboard
  annotations:
    nginx.ingress.kubernetes.io/ssl‑passthrough: "true"
    nginx.ingress.kubernetes.io/backend‑protocol: "HTTPS"
spec:
  ingressClassName: nginx
  rules:
  ‑ host: dashboard.laoma.cloud
    http:
      paths:
      ‑ path: /
        pathType: Prefix
        backend:
          service:
            name: kubernetes‑dashboard
            port:
              number: 443

3.3 两个面板选型对比

表格

项目 Kuboard v3.x Kubernetes‑Dashboard
开发方 国内开源第三方 K8s 官方
多集群 ✅支持 ❌单集群
认证体系 账号密码、LDAP、SSO，独立用户库 只能使用 ServiceAccount 的 Token 登录
操作体验 图形化强，少写 yaml，微服务视图 基础浏览，复杂操作还是需要 yaml
监控日志告警 内置全套套件 无，需要额外部署 prometheus
生产适用性 适合生产，权限管控完善 适合测试环境，生产要精细配置 RBAC

最佳实践：测试环境可以用 Dashboard；生产环境优先考虑 Kuboard，不要直接把超级管理员权限给到 Web 面板账号。

总结 & 生产实践建议

  1. 健康检查 Probe
    • liveness 负责重启故障 Pod；readiness 负责流量隔离，两者职责不要搞混。慢启动业务增加 startupProbe。
    • 参数不要照搬模板，根据业务真实启动时间调整initialDelaySeconds，避免过早探测误杀业务。
    • 生产必须配置探针，否则假死业务无法自动恢复。
  2. 认证鉴权安全
    • 认证：区分普通用户和 ServiceAccount；普通用户依靠 X509 证书，集群没有 User 对象；SA 用于 Pod 内部访问 apiserver。
    • RBAC 最小权限原则，尽量避免直接分配cluster‑admin超级权限。Role 绑定 ns 内权限；ClusterRoleBinding 实现集群全局权限。
    • ServiceAccount 优先使用短期 Bound Token，少用永久 Secret token。
  3. Web 管理界面
    • Dashboard 适合学习测试；生产优先 Kuboard，利用内置账号体系，不要直接分发 SA token 给业务人员。
    • Web 面板的 ServiceAccount 也要严格控制 RBAC 权限，杜绝直接绑定 cluster‑admin 上生产。
  4. 链路记忆：TLS加密 → 身份认证(401) → RBAC鉴权(403) → 准入控制器 → 存储etcd → 审计日志

课后实操清单

  1. 练习 liveness、readiness 探针 yaml，模拟业务故障，观察 Pod 重启和 endpoints 变化；
  2. 完整实验 X509 证书创建用户，kubeconfig 配置，RBAC 角色、角色绑定；
  3. 创建 ServiceAccount，Pod 挂载 SA，测试 Pod 内部访问 apiserver；
  4. 部署 Kuboard 或者 Dashboard 体验 web 界面。
相关推荐
分布式存储与RustFS1 小时前
十分钟在自己机器上跑通一个 S3 兼容对象存储（RustFS + Docker）
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准
知已难寻2 小时前
00 · OpenStack 总纲——从云计算到 OpenStack 全景
运维·服务器·云原生·云计算·负载均衡·openstack·perl
小白的码BUG之路2 小时前
K8S -- 集群搭建环境基础
java·服务器·kubernetes
2301_780789662 小时前
SSL 卸载 + WAF + 抗 D：高防 CDN 一站式解决 HTTPS 性能与安全
网络·云原生·ddos
艾伦_耶格宇2 小时前
【kubernetes - 1.28版本】-4 containerd与docker-ce 的区别
docker·容器·kubernetes
切糕师学AI2 小时前
K8s 滚动更新与 Spring Boot 优雅停机实战：如何做到真正的平滑发布？
spring boot·云原生·容器·kubernetes·k8s
Z21-X3 小时前
云原生运维笔记：硬核拆解OpenStack计算与存储——从主机聚合到Cinder挂载全流程
运维·笔记·学习·云原生·openstack
CodeGL3 小时前
一文了解：K8s
云原生·容器·kubernetes
java_logo3 小时前
Docker 部署 Portainer CE 中文版：轻松搭建容器管理平台
运维·docker·容器·portainer·容器管理·轩辕镜像·portainer ce
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04GitHub 镜像站点05几个好用的ip纯净度检测网站06昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战07苹果iPA游戏软件资源下载网站08蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接09Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）10CVE-2026-91403 高危漏洞预警：Java JSSE 信任链被攻破 全场景修复方案与Linux系统级彻底清理实操