运维小弟 - K8s
type: channel
link: https://blog.srebro.cn/tag/K8s/
items: IngressNginx v1.14.3 部署笔记 (DaemonSet + NodePort模式)
items: 基于 NFS 的 Kubernetes StorageClass 动态供给部署指南
items: Kubernetes 外部 etcd 集群的快速 Docker Compose 部署指南
items: Kubernetes 外部 etcd 集群的二进制部署指南
items: kubeadm部署 Kubernetes(k8s) 高可用集群 V1.28+ Etcd集群
items: K8S部署Metrics-Server服务
items: K8s私有云：Nginx真实客户端IP透传全攻略（HAProxy + Ingress 实战）
items: K8s 节点管理：使用 kubeadm 删除和重新添加节点
items: Velero 快速上手：使用 Velero 实现 Kubernetes 集群备份与迁移
items: 调整k8s node单节点可运行的pod突破110上限

IngressNginx v1.14.3 部署笔记 (DaemonSet + NodePort模式)
type: item
date: 2026-02-04T03:40:00+00:00
description: 这是一个整合了 Ingress-NGINX v1.14.3 部署、配置修改以及外部 HAProxy 负载均衡器的完整部署文档。😭 截止发文前，Ingress NGINX 宣布退役，官方宣布尽力维护将持续至2026年3月。下面的内容只是为了纪念。🐶该方案的架构目标是：全节点覆盖（DaemonSet） + 本地流量转发（Local） + 真实 IP 透传（Proxy Protocol）1. 架构与环境说明一个 3 主 3 从的 K8s 集群,k8s 版本: 1.32Ingress 版本: v1.14.3部署模式: DaemonSet (覆盖所有 Node 节点)流量策略: externalTrafficPolicy: Local (仅接收本机流量，防止 SNAT 丢失 IP)IP 透传技术: Proxy Protocol (v2)节点规划:HAProxy (外部 LB): 172.22.33.100 负责K8s API Server 转发 (6443)，负责Ingress HTTPS 流量转发 (443 -> NodePort 32443)K8s master Nodes：172.22.33.101, 172.22.33.102, 172.22.33.103K8s Worker Nodes: 172.22.33.110, 172.22.33.111, 172.22.33.1122. 第一步：部署外部负载均衡器 (HAProxy)我们需要在 K8s 集群外部（或独立节点）部署 HAProxy，负责将流量分发到各个 Worker 节点的 NodePort 上，并封装 Proxy Protocol 包头。2.1 安装 HAProxy在节点 172.22.33.100 上执行：# CentOS/OpenEuler/RHEL yum -y install haproxy2.2 配置 HAProxy编辑 /etc/haproxy/haproxy.cfg关键配置点：后端 server 必须开启 send-proxy-v2，这是 Ingress 能获取真实 IP 的前提。端口需与后续 Ingress Service 定义的 NodePort (32443) 对应，最外侧的 4 层负载均衡只做 443 端口的转发，整个 K8s ingress nginx 使用 https 方式访问。这里 K8s API Server 转发 (6443) 的部署过程忽略，可以参考 k8s 的部署文档： https://blog.srebro.cn/archives/102global log /dev/log local0 warning chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats defaults log global option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 # K8s API Server 转发 (6443) frontend kube-apiserver bind *:6443 mode tcp option tcplog default_backend kube-apiserver backend kube-apiserver mode tcp option tcplog option tcp-check balance roundrobin default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100 server kube-apiserver-1 172.22.33.101:6443 check server kube-apiserver-2 172.22.33.102:6443 check server kube-apiserver-3 172.22.33.103:6443 check # Ingress HTTPS 流量转发 (443 -> NodePort 32243) frontend kube-https bind *:443 mode tcp option tcplog default_backend kube-https backend kube-https mode tcp option tcplog option tcp-…

基于 NFS 的 Kubernetes StorageClass 动态供给部署指南
type: item
date: 2026-01-27T08:26:08+00:00
description: 一、StorageClass介绍StorageClass 用于描述集群中的“存储类型”和动态供给策略。它把后端存储（如 NFS、Ceph、云盘）的供给逻辑抽象为一个“provisioner”，并通过 parameters 传递供给参数。应用只需在 PVC 中声明 storageClassName，即可按需创建 PV。provisioner：指定供给器的唯一名称，必须与供给器部署时的环境变量保持一致parameters：供给器的行为配置，例如是否在删除 PVC 时保留数据reclaimPolicy：PV 的回收策略，通常由系统默认或 StorageClass 设定本实验使用 nfs-subdir-external-provisioner 作为动态供给器，它会在 NFS 后端的指定目录下为每个 PVC 创建一个子目录，实现按需供给。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-dynamic provisioner: k8s-sigs.io/nfs-subdir-external-provisioner parameters: archiveOnDelete: "false"二、NFS介绍NFS（Network File System）是基于网络的文件系统协议，允许多个主机通过网络共享同一目录。其在 Kubernetes 中常用于共享型持久化存储场景，典型特征是支持 ReadWriteMany（RWX），适合多副本工作负载共享同一数据目录。优点：简易、通用、支持 RWX、和现有基础设施容易集成注意：网络和 NFS 服务器性能会影响 IO；生产环境应考虑权限隔离、备份与高可用先决条件：K8s 节点需安装 NFS 客户端（如 nfs-utils / nfs-common），并能访问 NFS 服务器端口（一般为 2049 等）三、实验介绍本实验在现有 NFS 服务基础上，部署 nfs-subdir-external-provisioner，实现 PVC 的动态供给，并通过示例 Pod 验证挂载与读写。3.1、环境介绍Kubernetes 集群已可用NFS 服务器：172.22.33.100NFS 共享路径：/home/application/nfs/data供给器命名空间：kube-nfs3.2、安装配置nfs服务如果尚未配置 NFS 服务，需在服务器上完成以下步骤（示例）：安装 NFS 服务端（不同发行版命令略有差异）Debian/Ubuntu：apt install -y nfs-kernel-serverCentOS/RHEL：yum install -y nfs-utils创建共享目录：mkdir -p /home/application/nfs/data配置导出（编辑 /etc/exports）：/home/application/nfs/data *(insecure,rw,sync,no_root_squash)启动并刷新导出：systemctl start nfs-serverexportfs -arv验证：showmount -e 172.22.33.100 应显示共享目录确保 K8s 节点能访问nfs 服务器四、PersistenVolume动态供给部署本节基于以下文件完成部署与验证：步骤如下：创建命名空间kubectl create namespace kube-nfs配置 RBAC（见 [rbac.yaml]）该文件创建供给器使用的 ServiceAccount、ClusterRole/Binding，以及 leader 选举所需的 Role/Binding：apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: kube-nfs --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: nfs-client-provisioner-runner rules: - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] …

Kubernetes 外部 etcd 集群的快速 Docker Compose 部署指南
type: item
date: 2026-01-26T06:39:39+00:00
description: 一、背景在高可用 Kubernetes 部署中，需要单独部署外部 etcd 集群，而不是使用 kubeadm 默认在 master 节点上部署的 etcd。以下是关于这一配置场景的详细记录。二、etcd简介etcd 是一个高可用的分布式键值存储系统，主要用于存储和管理配置信息、服务发现信息以及其他重要的元数据。etcd 是由 CoreOS 开发的，基于 Raft 共识算法来保证数据的一致性和可靠性。2.1 etcd 关键特点分布式：etcd 运行在多个节点上，通过 Raft 协议确保数据一致性。高可用性：即使部分节点出现故障，etcd 也能继续提供服务。一致性保证：使用 Raft 协议来确保数据的一致性，支持强一致性读写。键值存储：数据以键值对的形式存储，适合存储配置和元数据。支持事务：支持原子操作，如事务操作来保证数据的正确性。2.2 etcd 主要功能分布式键值存储：etcd 是一个高可用的分布式键值存储系统，支持高效的键值对存储和读取，并提供强一致性保证。一致性保证：etcd 使用 Raft 协议确保数据一致性，即使部分节点故障，数据仍然保持一致。高可用性：etcd 通过数据复制到多个节点提供高可用性和容错能力，只要大多数节点正常，数据依然可用。事务支持：etcd 支持原子操作和事务，确保对多个键值对的更改安全一致。观察和通知：etcd 支持事件监听和观察功能，客户端可以订阅键值变化，适合动态配置更新。持久化存储：etcd 将数据持久化到磁盘，确保在节点重启或故障时数据不丢失。分布式锁：etcd 提供分布式锁，支持节点间的协调和同步，常用于确保资源唯一性或任务协调。范围查询：etcd 支持对键值对的范围查询，便于批量检索数据。API 接口：etcd 提供 HTTP/gRPC API，支持基本的 CRUD 操作、事务和观察功能。这些功能使 etcd 成为一个强大且可靠的分布式键值存储系统，适合用于需要高一致性和高可用性的场景，特别是在 Kubernetes 这样的集群管理系统中。2.3 etcd 在 Kubernetes 中使用场景在 Kubernetes (K8S) 集群中，etcd 扮演着至关重要的角色。它主要用于存储和管理 Kubernetes 的所有集群状态信息和配置数据。以下是 etcd 在 Kubernetes 中的一些关键使用场景：集群状态存储：Kubernetes 的所有集群状态、配置信息、资源定义等都存储在 etcd 中。包括 Pod、Service、ConfigMap、Secret 等对象的状态和配置都被存储在 etcd 中。高可用性配置：提供高可用性和容错能力，保证即使在集群中的一些节点失效的情况下，Kubernetes 也能继续运行和提供服务。数据一致性保证： 使用 Raft 协议确保数据的一致性，这对于 Kubernetes 来说是非常重要的，因为它需要确保所有操作和状态在集群中的一致性。服务发现：Kubernetes 的服务发现机制依赖于 etcd 存储服务的状态和信息。etcd 记录服务的 IP 地址和端口信息，允许其他组件进行服务发现。动态配置管理：Kubernetes 使用 etcd 来管理配置变化，比如部署新的应用版本或调整资源配置。etcd 的事务支持使得配置更改能够被安全地提交和应用。审计和恢复：etcd 的持久化存储允许 Kubernetes 在发生故障或恢复操作时能够重建集群状态。etcd 的备份和恢复机制是确保 Kubernetes 集群数据安全的重要手段。三、使用docker-compose快速部署etcd参考官方文档：https://github.com/etcd-io/etcd/releases3.1 etcd单节点部署PS: 请勿在K8S 集群中的机器上 使用docker-compose 去部署etcd ，可能会存在子网冲突； 在条件允许的情况下，我们还是申请机器去单独部署etcd3.1.1 环境准备机器IP主机名etcd版本docker 版本docker-compose版本172.22.33.213etcdv3.3.820.10.18v2.10.23.1.2 创建etcd 工作目录，编写docker-compose 文件ETCD_NAME 每个节点的 etcd 服务名称ETCD_ADVERTISE_CLIENT_URLS 填写每个 etcd 容器所在节点对外提供服务的 IPETCD_INITIAL_ADVERTISE_PEER_URLS 填写每个 etcd 容器所在节点对外提供服务的 IPETCD_INITIAL_CLUSTER: ETCD 集群配置包含所有节点的名称和 ETCD_INITIAL_ADVERTISE_PEER_URLS 地址，我这里目前就一个节点ETC…

Kubernetes 外部 etcd 集群的二进制部署指南
type: item
date: 2026-01-26T06:36:13+00:00
description: 一、背景在高可用 Kubernetes 部署中，需要单独部署外部 etcd 集群，而不是使用 kubeadm 默认在 master 节点上部署的 etcd。以下是关于这一配置场景的详细记录。二、etcd简介etcd 是一个高可用的分布式键值存储系统，主要用于存储和管理配置信息、服务发现信息以及其他重要的元数据。etcd 是由 CoreOS 开发的，基于 Raft 共识算法来保证数据的一致性和可靠性。2.1 etcd 关键特点分布式：etcd 运行在多个节点上，通过 Raft 协议确保数据一致性。高可用性：即使部分节点出现故障，etcd 也能继续提供服务。一致性保证：使用 Raft 协议来确保数据的一致性，支持强一致性读写。键值存储：数据以键值对的形式存储，适合存储配置和元数据。支持事务：支持原子操作，如事务操作来保证数据的正确性。2.2 etcd 主要功能分布式键值存储：etcd 是一个高可用的分布式键值存储系统，支持高效的键值对存储和读取，并提供强一致性保证。一致性保证：etcd 使用 Raft 协议确保数据一致性，即使部分节点故障，数据仍然保持一致。高可用性：etcd 通过数据复制到多个节点提供高可用性和容错能力，只要大多数节点正常，数据依然可用。事务支持：etcd 支持原子操作和事务，确保对多个键值对的更改安全一致。观察和通知：etcd 支持事件监听和观察功能，客户端可以订阅键值变化，适合动态配置更新。持久化存储：etcd 将数据持久化到磁盘，确保在节点重启或故障时数据不丢失。分布式锁：etcd 提供分布式锁，支持节点间的协调和同步，常用于确保资源唯一性或任务协调。范围查询：etcd 支持对键值对的范围查询，便于批量检索数据。API 接口：etcd 提供 HTTP/gRPC API，支持基本的 CRUD 操作、事务和观察功能。这些功能使 etcd 成为一个强大且可靠的分布式键值存储系统，适合用于需要高一致性和高可用性的场景，特别是在 Kubernetes 这样的集群管理系统中。2.3 etcd 在 Kubernetes 中使用场景在 Kubernetes (K8S) 集群中，etcd 扮演着至关重要的角色。它主要用于存储和管理 Kubernetes 的所有集群状态信息和配置数据。以下是 etcd 在 Kubernetes 中的一些关键使用场景：集群状态存储：Kubernetes 的所有集群状态、配置信息、资源定义等都存储在 etcd 中。包括 Pod、Service、ConfigMap、Secret 等对象的状态和配置都被存储在 etcd 中。高可用性配置：提供高可用性和容错能力，保证即使在集群中的一些节点失效的情况下，Kubernetes 也能继续运行和提供服务。数据一致性保证： 使用 Raft 协议确保数据的一致性，这对于 Kubernetes 来说是非常重要的，因为它需要确保所有操作和状态在集群中的一致性。服务发现：Kubernetes 的服务发现机制依赖于 etcd 存储服务的状态和信息。etcd 记录服务的 IP 地址和端口信息，允许其他组件进行服务发现。动态配置管理：Kubernetes 使用 etcd 来管理配置变化，比如部署新的应用版本或调整资源配置。etcd 的事务支持使得配置更改能够被安全地提交和应用。审计和恢复：etcd 的持久化存储允许 Kubernetes 在发生故障或恢复操作时能够重建集群状态。etcd 的备份和恢复机制是确保 Kubernetes 集群数据安全的重要手段。三、使用二进制方式部署etcd参考官方文档：https://github.com/etcd-io/etcd/releasesetcd 软件包下载地址： https://github.com/etcd-io/etcd/releases/download/v3.5.15/etcd-v3.5.15-linux-amd64.tar.gz3.1 etcd单节点部署3.1.1 环境准备机器IP主机名etcd版本172.22.33.223etcdv3.3.83.1.2 下载软件包,创建etcd工作目录etcd 软件包下载地址： https://github.com/etcd-io/etcd/releases/download/v3.5.15/etcd-v3.5.15-linux-amd64.tar.gz#创建etcd工作目录 $ mkdir -p /home/application/etcd/{bin,cfg,data,ssl} # 下载软件包并解压 $ wget https://github.com/etcd-io/etcd/releases/download/v3.5.15/etcd-v3.5.15-linux-amd64.tar.g…

kubeadm部署 Kubernetes(k8s) 高可用集群 V1.28+ Etcd集群
type: item
date: 2026-01-26T06:33:00+00:00
description: kubeadm部署 Kubernetes(k8s) 高可用集群 V1.28+ Etcd集群kubeadm是官方社区推出的一个用于快速部署kubernetes集群的工具。1. 安装要求在开始之前，部署Kubernetes集群机器需要满足以下几个条件：10台机器，操作系统Openeuler22.03 LTS SP4硬件配置：2GB或更多RAM，2个CPU或更多CPU，硬盘30GB或更多，docker 数据卷单独挂载集群中所有机器之间网络互通可以访问外网，需要拉取镜像，【镜像代理自行解决】禁止swap分区2. 准备环境角色IP组件功能描述Haproxy172.22.33.210haproxyK8S入口，负载均衡k8s-master01172.22.33.215docker，cri-dockerd，kube-apiserver，kube-scheduler，kube-controller-manager，kubelet，kube-proxy，coredns，calicok8s master01节点k8s-master02172.22.33.216docker，cri-dockerd，kube-apiserver，kube-scheduler，kube-controller-manager，kubelet，kube-proxy，calicok8s master02节点k8s-master03172.22.33.217docker，cri-dockerd，kube-apiserver，kube-scheduler，kube-controller-manager，kubelet，kube-proxy，calicok8s master03节点k8s-node01172.22.33.218docker，cri-dockerd，kubelet，kube-proxy，coredns，calicok8s-node01 工作节点k8s-node02172.22.33.219docker，cri-dockerd，kubelet，kube-proxy，coredns，calicok8s-node02 工作节点k8s-node03172.22.33.220docker，cri-dockerd，kubelet，kube-proxy，coredns，calicok8s-node03 工作节点etcd-01172.22.33.223etcdetcd-01服务器etcd-02172.22.33.224etcdetcd-02服务器etcd-0372.22.33.225etcdetcd-03服务器2.1 环境初始化K8S 集群服务器 都需要配置关闭防火墙： $ systemctl stop firewalld $ systemctl disable firewalld 关闭selinux： $ sed -i 's/enforcing/disabled/' /etc/selinux/config # 永久 $ setenforce 0 # 临时 关闭swap：[临时和永久关闭] #临时关闭 $ swapoff -a #永久关闭 $ sed -ri 's/.*swap.*/#&/' /etc/fstab 设置主机名： $ hostnamectl set-hostname k8s-master01 $ hostnamectl set-hostname k8s-master02 $ hostnamectl set-hostname k8s-master03 $ hostnamectl set-hostname k8s-node01 $ hostnamectl set-hostname k8s-node02 $ hostnamectl set-hostname k8s-node03 #在K8S上所有节点添加hosts： $ cat >> /etc/hosts << EOF 172.22.33.215 k8s-master01 172.22.33.216 k8s-master02 172.22.33.217 k8s-master03 172.22.33.218 k8s-node01 172.22.33.219 k8s-node02 172.22.33.220 k8s-node03 EOF #开启内核路由转发 sed -i 's/net.ipv4.ip_forward=0/net.ipv4.ip_forward=1/g' /etc/sysctl.conf #将桥接的IPv4,IPV6流量传递到iptables的链： $ cat > /etc/sysctl.d/k8s.conf << EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bri…

K8S部署Metrics-Server服务
type: item
date: 2026-01-26T04:45:00+00:00
description: 一、Metrics-Server 介绍​ Metrics-Server是k8s集群采集监控数据的聚合器，如采集node、pod的cpu、内存等数据，从 Kubernetes1.8 开始默认使用Metrics-Server采集数据，并通过Metrics API的形式提供查询，但是，kubeadm安装的k8s集群默认是没有安装Metrics-Server的。⚠️ 注意：​ 在 Kubernetes 1.7 版本引入了聚合层，允许第三方应用程序通过将自己注册到kube-apiserver上，仍然通过 API Server 的 HTTP URL 对新的 API 进行访问和操作。为了实现这个机制，Kubernetes 在 kube-apiserver 服务中引入了一个API 聚合层（API Aggregation Layer），用于将扩展 API 的访问请求转发到用户服务的功能。如果你是kubadm 的部署方式，默认已开启Kubernetes API聚合层。Metrics Server项目地址： https://github.com/kubernetes-sigs/metrics-servermetrics-server版本与k8s版本对应关系: https://github.com/kubernetes-sigs/metrics-server#compatibility-matrix本次部署环境： K8S1.32 ，Metrics Server 0.8.0二、部署Metrics-Server下载 Metrics Server 的部署文件:$ wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.8.0/components.yaml修改components.yaml 文件:国内墙，需要替换 registry.k8s.io/metrics-server/metrics-server:v0.8.0 镜像地址为：registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.8.0apiVersion: v1 kind: ServiceAccount metadata: labels: k8s-app: metrics-server name: metrics-server namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: k8s-app: metrics-server rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rbac.authorization.k8s.io/aggregate-to-view: "true" name: system:aggregated-metrics-reader rules: - apiGroups: - metrics.k8s.io resources: - pods - nodes verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: k8s-app: metrics-server name: system:metrics-server rules: - apiGroups: - "" resources: - nodes/metrics verbs: - get - apiGroups: - "" resources: - pods - nodes verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: labels: k8s-app: metrics-server name: metrics-server-auth-reader namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: extension-apiserver-authentication-reader subjects: - kind…

K8s私有云：Nginx真实客户端IP透传全攻略（HAProxy + Ingress 实战）
type: item
date: 2026-01-23T09:51:00+00:00
description: 一、背景记一次私有云 K8s 项目交付中，Ingress‑NGINX 采用外部 HAProxy 作为四层入口后，发现业务 Pod（如 Nginx）的访问日志记录的并非客户端真实 IP，而是K8s 内部地址或 HAProxy 的地址。要使最终的 Pod 准确采集到客户端真实 IP。实测后发现，需要同时完成链路“透传”：HAProxy 发送 PROXY v2 保留真实 IP，Ingress‑NGINX 打开 透传配置，并由后端应用读取 X‑Forwarded‑For,ingress-nginx 的Service 侧使用 externalTrafficPolicy=Local 保源 IP。可以看我👇的图：二、实战在实战开始之前，我们需要先了解下 K8s service中的externalTrafficPolicy参数2.1 关于service中的externalTrafficPolicy参数两种取值Cluster（默认）：集群内访问会负载到任意就绪后端，可跨节点。Local：仅转发给“源节点的本地后端”，没有本地后端则失败；适合就近访问、降低跨节点带宽/延迟，或依赖本地资源。2.1.1 当 service 的externalTrafficPolicy=Cluster集群内访问会负载到任意就绪后端，可跨节点。目标是任何节点都能访问我们以一个案例：K8s中运行一个Nginx ，以 NodePort 暴露#demo.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx spec: type: NodePort selector: app: nginx externalTrafficPolicy: Cluster ports: - port: 80 targetPort: 80 protocol: TCP nodePort: 31043#apply应用 $ kubectl apply -f demo.yaml deployment.apps/nginx created service/nginx created #查看 pod 状态以及 nodeport 端口 $ kubectl get pod,svc NAME READY STATUS RESTARTS AGE pod/nginx-5869d7778c-4z7kd 1/1 Running 0 15s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 7d service/nginx NodePort 10.111.180.29 <none> 80:31043/TCP 7s访问：http://K8s中任意节点ip:31043现象与结论：master / worker 任意节点的 31043 都能访问。源 IP 通常是节点 IP，不保留真实客户端 IP。2.1.2 当 service 的externalTrafficPolicy=Local仅转发给有源节点的本地后端，没有本地后端则失败我们还是以一个案例：K8s中运行一个Nginx-1 ，以 NodePort 暴露#demo-1.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-1 spec: replicas: 1 selector: matchLabels: app: nginx-1 template: metadata: labels: app: nginx-1 spec: containers: - name: nginx image: nginx ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx-1 spec: type: NodePort selector: app: nginx-1 externalTrafficPolicy: Local ports: - port: 80 targetPort…

K8s 节点管理：使用 kubeadm 删除和重新添加节点
type: item
date: 2025-09-04T16:04:00+00:00
description: 一、需求：在 Kubernetes 中，使用 kubeadm 的方式 删除和 重新添加节点二、删除节点从集群中删除节点首先，需要在主节点上将节点从集群中删除。假设要删除的节点名称为 node-1：kubectl delete node node-1在要删除的节点上执行你还需要在要删除的节点上执行以下命令，以清理本地的 K8s 配置和状态：kubeadm reset这个命令会删除 K8s 集群的所有配置文件和数据。执行后，还需要删除节点上的 K8s 配置文件和网络插件的配置，例如：rm -rf /etc/kubernetes rm -rf /var/lib/etcd以及清理 CNI 网络插件的配置，例如：rm -rf /var/lib/cni/三、重新添加节点重新初始化节点确保节点上的 kubeadm 工具已安装，并且网络插件和其他相关工具也已正确配置。然后，使用 kubeadm join 命令重新将节点加入集群。首先，你需要从主节点获取 kubeadm join 命令的令牌。可以通过以下命令生成新的令牌：kubeadm token create --print-join-command这条命令会输出类似以下内容的命令：kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>在要重新加入的节点上执行输出的 kubeadm join 命令：kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>验证节点状态重新加入节点后，可以在主节点上检查节点状态以确保它成功加入：kubectl get nodes如果节点状态显示为 Ready，则说明节点已经成功加入集群。注意事项确保在执行 kubeadm reset 命令时，节点上的所有数据和配置都被清除，以避免潜在的冲突。在重新加入节点之前，确保集群和节点的网络配置正常。如果你的集群使用了自定义的网络插件或配置，确保在节点上进行相应的配置。

Velero 快速上手：使用 Velero 实现 Kubernetes 集群备份与迁移
type: item
date: 2025-09-04T16:02:00+00:00
description: 一、velero 简介Velero 是vmware开源的一个云原生的灾难恢复和迁移工具，它本身也是开源的,采用Go语言编写，可以安全的备份、恢复和迁移Kubernetes集群资源数据；Velero 是西班牙语意思是帆船，非常符合Kubernetes社区的命名风格，Velero的开发公司Heptio，已被VMware收购。Velero 支持标准的K8S集群，既可以是私有云平台也可以是公有云，除了灾备之外它还能做资源移转，支持把容器应用从一个集群迁移到另一个集群。Velero 的工作方式就是把kubernetes中的数据备份到对象存储以实现高可用和持久化，默认的备份保存时间为720小时，并在需要的时候进行下载和恢复。github: https://github.com/vmware-tanzu/velero官网：https://velero.io/二、 velero 和 ETCD 备份的区别2.1 velero 备份Velero 是一个开源工具，用于备份和恢复 Kubernetes 集群中的资源和持久化数据。它支持对 Kubernetes 资源（如 Pods、Services、Deployments 等）和持久卷（Persistent Volumes）进行备份和恢复。主要特点：备份 Kubernetes 资源：包括集群的 API 对象和元数据。备份持久化数据：通过与存储供应商（如 AWS S3、Azure Blob、Google Cloud Storage 等）集成，备份 PVC 中的数据。备份计划：可以设置定期备份和备份策略。迁移支持：可以用于跨集群或跨云的迁移。恢复功能：支持恢复整个集群或部分资源。使用场景：需要备份和恢复整个 Kubernetes 集群的配置和持久化数据。需要支持跨集群的迁移。需要定期备份和恢复 Kubernetes 对象和 PVC 数据。2.2 etcd 备份etcd 是 Kubernetes 的核心组件之一，存储了集群的所有状态和配置信息。etcd 备份 是针对 etcd 数据库的备份，主要用于备份和恢复 Kubernetes 的集群状态和配置。主要特点：备份 Kubernetes 状态：包括集群的所有配置和状态数据。原生备份：直接备份 etcd 数据库，而不是通过 Kubernetes API。恢复集群状态：可以恢复整个集群的状态到备份时的状态。使用场景：需要备份和恢复 Kubernetes 集群的核心状态和配置信息。需要恢复集群的状态到某个时间点。需要直接操作 etcd 数据库进行备份和恢复。2.3 对比特性Veleroetcd 备份备份内容Kubernetes 资源和持久卷etcd 数据库（集群状态和配置）备份方式通过 Velero CLI，存储在外部存储使用 etcdctl 工具，存储在指定位置恢复内容Kubernetes 资源和持久卷恢复集群的状态和配置使用场景跨集群迁移、集群资源备份与恢复集群状态恢复、紧急恢复自动化支持定期备份和恢复策略通常手动执行备份和恢复2.4.选择建议使用 Velero 如果你需要备份和恢复整个 Kubernetes 集群的资源和持久化数据，包括跨集群迁移和定期备份。使用 etcd 备份 如果你专注于备份和恢复 Kubernetes 的核心状态和配置，特别是在需要恢复整个集群状态到某个时间点时。有时，你可能需要同时使用这两种备份策略，以确保全面的数据保护和恢复能力。例如，你可以使用 Velero 备份 Kubernetes 资源和持久卷，而使用 etcd 备份来保护集群的核心状态和配置； 本文呢 主要阐述对 velero 的备份详解三、velero整体架构需要部署一个 Velero 服务端到集群，该服务端拥有访问集群资源的权限；通过 velero 二进制程序部署服务端的同时，其也会向 kubernetes 集群中同时注册一些 crd 资源，这些 crd 资源可以对我们备份、还原的资源做抽象；通过 crd 资源创建一个备份请求对象，服务端控制器会根据请求内容完成目标预期的备份，并将备份后的文件上传至配置的远端存储（需要支持 S3 协议，如 Ceph、Minio 都可以）；备份完毕后，可以通过获取特定的 crd 资源来查看备份的记录（文件）；通过 crd 资源创建一个还原请求对象，服务端控制器会根据请求内容对应的备份文件，将备份内容恢复到集群；四、velero备份流程Velero 客户端调用Kubernetes API Server创建Backup任务。Backup 控制器基于watch 机制通过API Server获取到备份任务。Backup 控制器开始执行备份动作，其会通过请求API Server获取需要备份的数据。Backup 控制器将获取到的数据备份到指定的对象存储…

调整k8s node单节点可运行的pod突破110上限
type: item
date: 2025-09-04T16:00:00+00:00
description: 调整k8s node单节点可运行的pod突破110上限官方文档： https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/使用 systemctl status kubelet 查看kubelet.service文件的路径可以看到配置文件在 /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf[root@k8s-node1]# cat /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf # Note: This dropin only works with kubeadm and kubelet v1.11+ [Service] Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" # This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use # the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file. EnvironmentFile=-/etc/sysconfig/kubelet ExecStart= ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS此文件我们发现 KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml直接在KUBELET_CONFIG_ARGS 中添加参数即可修改 /var/lib/kubelet/config.yaml 配置文件，在最下面添加一行 maxPods: xxx 我们修改下maxPods的数值，增大到300（具体按照你node节点资源情况设置，不建议设置的过大）修改完成之后重启下kubelet服务[不会影响正在运行的容器]$ systemctl daemon-reload $ systemctl restart kubelet模拟调整pod 数量，运行500个pod；观察运行情况#调整pod数量到500 [root@k8s-master01 system]# kubectl scale deployment my-nginx-test --replicas=500 deployment.apps/my-nginx-test scaled #两个mode节点 [root@k8s-master01 system]# kubectl get nodes NAME STATUS ROLES AGE VERSION k8s-master01 Ready control-plane,master 24h v1.20.15 k8s-master02 Ready control-plane,master 24h v1.20.15 k8s-node1 Ready <none> 24h v1.20.15 k8s-node2 Ready <none> 53m v1.20.15 #查看run 的pod 数量 [root@k8s-master01 system]# kubectl get pods | grep -i run | wc -l 5…