说起来,上周三在星巴克和几个做运维的朋友聊天,大家都在吐槽K8S。一个人说:"K8S这玩意,学的时候觉得挺简单,一上生产全是坑。"另一个人接话:"是啊,我上周刚搞瘫一个集群,就因为一个探针配置没写好。"我听着挺有感触的。作为AI Native Coder,我接触K8S也挺久了。从第一次在minikube上跑hello world,到现在管理几十个节点的生产集群,中间踩了不少坑。今天想聊聊我对K8S的理解,以及从"会用"到"用好"这个过程。先说说什么是"会用"很多人学K8S,是这样的路径:先看几篇教程,了解Pod、Deployment、Service这些概念;然后本地装个minikube或者kind,跑几个demo;最后找个云服务商,点几下鼠标,集群就起来了。这时候你会觉得:K8S还挺简单的。但问题在于,这种"会用",只是"知道怎么用",不是"理解原理"。举个例子,你知道Deployment可以管理Pod副本,也知道滚动更新可以零停机部署。但你可能不知道,滚动更新的过程是怎么控制的,什么时候会触发回滚,如果新旧版本都起不来会发生什么。再比如,你知道Service可以通过ClusterIP暴露服务,也知道LoadBalancer可以对外访问。但你可能不知道,kube-proxy是怎么维护网络规则的,为什么有些请求会丢包,怎么排查网络问题。这种"会用"的状态,在日常开发、测试环境是够的。但到了生产环境,一旦出问题,你就不知道从哪开始排查。那什么是"用好"呢?我觉得,"用好"有几个标志:第一,你能理解K8S的核心原理,而不是只会敲命令;第二,你有自己的踩坑经验和最佳实践,而不是照搬文档;第三,你能根据业务场景做架构设计,而不是套用模板;第四,你能快速定位和解决问题,而不是到处搜答案。接下来,我想从这几个方面聊聊。K8S的核心架构先说说架构。K8S集群由控制平面(Control Plane)和工作节点(Worker Node)组成。控制平面就是"大脑",负责做全局决策。工作节点就是"四肢",负责实际跑应用。控制平面有几个核心组件:API Server是前台,所有请求都经过它。你执行kubectl命令,其实就是调API Server的接口。etcd是档案室,存着集群的所有状态数据。节点信息、Pod状态、Service配置,都存在这里。Controller Manager是运营总监,确保实际状态和期望状态一致。比如你创建了3个副本的Deployment,Controller Manager会一直盯着,如果挂了一个就重启一个。Scheduler是人力资源部,负责给Pod分配节点。它会看节点资源够不够,有没有亲和性要求,哪个节点最合适。工作节点也有几个组件:kubelet是每个节点的监工,跟控制平面通信,确保Pod按预期运行。kube-proxy是网络管理员,维护节点上的网络规则,实现Service的负载均衡。容器运行时是实际跑容器的软件,比如containerd、Docker。[图片] K8S集群架构图这个架构的核心思想是"声明式API"。什么是声明式API呢?简单说,你告诉K8S"想要什么",而不是"怎么做"。比如你写一个Deployment,说"我要3个nginx的副本"。K8S会自动判断:现在有几个?在哪几个节点?要不要调度新的?要不要删多余的?这就像你跟老板说"这个项目要3个人负责",老板会自己去安排谁负责什么、怎么分工。你不需要告诉老板"先派张三去写文档,再让李四写代码"。声明式API的好处是,整个系统是自驱动的。控制平面一直盯着状态,发现问题就自动修复。节点挂了?Controller Manager会在其他节点重建Pod。副本数不够?ReplicaSet Controller会启动新的。但这种"自动"也是双刃剑。如果你不理解它的原理,一旦出问题,你根本不知道它在干嘛。我踩过的坑说点我踩过的坑吧。坑1:没有探针配置有一次,我部署一个需要长时间启动的应用,忘了配置readinessProbe。结果新Pod启动后,马上被Service选上,开始接收流量。但应用还在初始化,所有请求都超时。用户疯狂刷新页面,我查日志发现应用还没完全ready。最后花了3小时才定位到问题,就是因为readinessProbe没配。正确做法是:// yamlreadinessProbe:httpGet:path: /healthport: 8080initialDelaySeconds: 30 # 应用启动需要30秒periodSeconds: 10这样,K8S会等Pod完全ready,才让Service把流量打过来。坑2:资源限制没配还有一次,我在测试环境把一个 Deployment 的replicaCount从2改成了10,想测试一下高并发。结果所有Pod都Pending,集群资源被吃光了。其他服务也开始出问题,因为节点已经没有资源调度新的Pod。这还挺猛的。一个测试配置,差点把整个集群搞瘫。正确做法是,每个Pod都要配requests和limits:// yamlresources:requests:cpu: "500m"memory: "256Mi"limits:cpu: "1000m"memory: "512Mi"requests决定调度优先级,limits防止单个Pod狂吃资源。这样Pod之间才能"和平共处"。坑3:网络策略配太严刚接触NetworkPolicy的时候,我配过一个"默认拒绝所有"的策略:// yamlapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:name: deny-allspec:podSelector: {}policyTypes:- Ingress- Egress结果整个集群的流量全被掐断了。服务A调不到服务B,Pod连DNS都解析不了。我当时一脸懵逼,还以为是网络插件坏了。后来用kubectl describe看了下,发现NetworkPolicy生效了,但没有任何allow规则。正确做法是,先从宽松策略开始,逐步收紧。或者用Calico/Cilium的可视化工具,看看网络策略到底干了什么。坑4:滚动更新配置错了有一次,我给Deployment更新,设置了这样的滚动更新策略:// yamlstrategy:type: RollingUpdaterollingUpdate:maxUnavailable: "50%" # 一半Pod同时更新maxSurge: "0" # 不允许超出副本数结果更新的时候,服务能力直接腰斩。10个副本,5个先被停掉,5个新Pod还在启动。中间那段时间,用户请求全挂。这个数据还挺意外的。我本以为滚动更新会平滑过渡,结果变成"断崖式替换"。正确做法是:// yamlstrategy:type: RollingUpdaterollingUpdate:maxUnavailable: "25%" # 最多1/4不可用maxSurge: "25%" # 允许临时超25%minReadySeconds: 30 # 新Pod稳定30秒再继续这样更新过程中,始终有75%的Pod在运行,用户几乎无感知。坑5:ConfigMap改了没生效我之前一直以为,ConfigMap改了,Pod会自动读取新配置。但实际不是。除非你配置了热更新机制,否则Pod会一直用旧配置,直到重启。有次我改了一个Redis的连接参数,ConfigMap更新了,但Pod还是用旧配置。调试了半天才发现这个问题。正确做法有几个:一是给ConfigMap打版本号,每次改都创建新的:// yamlenvFrom:- configMapRef:name: redis-config-v20250123二是用Operator或者自己写个Controller,监听ConfigMap变化,自动触发滚动更新。三是用Kustomize或Helm,每次变更都触发release更新。坑6:用了:latest镜像标签这个坑太经典了。我之前开发环境一直用nginx:latest,没出什么问题。结果生产环境一部署,拉下来的镜像不是本地测的版本,因为:latest指向了新发布的tag。排查了半天才发现,生产环境用的镜像跟测试环境根本不一样。这个教训还挺深刻的。永远不要用:latest,要固定版本号:// yamlcontainers:- name: nginximage: nginx:1.25.1-20250120 # 明确版本号坑7:Service selector写错了有次我配置Service,selector是app: web,但Pod的label是app: frontend。结果Service找不到后端Pod,所有请求都超时。我查了半天,用kubectl get endpoints看,发现Service的endpoint是空的。再用kubectl describe看Pod,发现label确实不匹配。这种低级错误,最容易忽略。Service找不到Pod,第一反应是网络问题,其实可能是selector写错了。正确做法是,写完YAML后,用kubectl apply --dry-run先验证一遍,再实际部署。生产环境的最佳实践说了这么多坑,再聊聊生产环境的最佳实践吧。1. 集群高可用生产环境的控制平面,至少要3个Master节点。单个Master挂了,整个集群就瘫了,这种单点故障是绝对不能接受的。而且要用HAProxy+Keepalived做负载均衡,给API Server配个VIP。这样单个Master挂了,VIP会漂移到健康节点,对用户无感知。etcd也要高可用,3个或5个节点,用Raft协议保证一致性。最好跟Master节点分开,别混在一起。2. 网络插件选型CNI插件选型很重要。小规模集群,用Flannel就行,简单易用。但记得开启DirectRouting,同节点Pod通信不走VXLAN,性能会好不少。大规模或者对网络性能要求高的场景,用Calico BGP模式,关掉封装。延迟能降低30%-50%。有安全策略需求的,用Calico的NetworkPolicy。想做可观测性+服务网格的,用Cilium eBPF,性能强得多。关键一点,别在一个集群里混用多个CNI插件,这是找死。3. GitOps部署2025年,GitOps已经是K8S部署的标准模式了。核心思想是:Git仓库是唯一数据源,ArgoCD或Flux负责把Git里的配置同步到集群。好处有几个:一是所有变更可追溯,谁改了什么、什么时候改的,都在Git历史里;二是回滚简单,切回上一个commit就行;三是多人协作方便,PR机制可以review变更;四是审计容易,所有改动都有记录。部署一个ArgoCD很简单:// bashkubectl create namespace argocdkubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.12.0/manifests/install.yaml然后创建一个Application,把Git仓库和集群关联起来就行。4. 监控和日志生产环境必须配齐监控和日志,这是底线。监控用Prometheus+Grafana,采集资源、QPS、错误率这些指标。Pod重启了、CPU超了、内存泄露了,第一时间告警。日志用Loki或者ELK,把分散的日志集中起来。排查问题的时候,能在一个地方看到所有Pod的日志,效率会高很多。而且日志里最好带上Trace ID,这样跨服务链路能串起来。不然你不知道请求A在服务B、服务C里发生了什么,只能一个个查日志,效率太低。5. 安全加固K8S的默认配置是不够安全的,生产环境必须加固。RBAC要精细化,别动不动就给cluster-admin。按命名空间分配权限,该给read的别给write,该给namespace的别给cluster。镜像要固定版本,不要用:latest。定期用Trivy扫描镜像漏洞,集成到CI/CD里。Pod安全策略要开启,禁止以root用户运行容器,强制只读文件系统。Kubernetes 1.25+已经弃用PSP了,改用Pod Security Admission:// yamlapiVersion: v1kind: Namespacemetadata:name: untrustedlabels:pod-security.kubernetes.io/enforce: restricted网络策略要配,默认拒绝所有,只允许必要的通信。这样就算某个Pod被攻破,攻击者也横向不出去。6. 资源规划资源规划很重要,别等集群满了再加节点。CPU和内存的requests加起来,不要超过节点总资源的70%。留30%做buffer,应对突发流量和调度碎片。存储也要规划,不同类型的数据用不同的存储类。数据库用全闪存块存储,日志用对象存储,临时数据用本地存储。7. 定期维护集群要定期维护,别等出问题了再处理。比如证书,kubeadm部署的集群证书默认有效期只有1年。过期了集群就瘫了,某公司因为这个停机了8小时。要么提前续期,要么用cert-manager自动管理。再比如备份,etcd数据要定期备份,最好能自动测试恢复流程。不然真出问题的时候,你发现备份不可用,那就彻底凉了。还有升级,K8S版本要跟着社区走。但别跨大版本升级,1.24→1.26要过1.25,不然可能API有破坏性变更。 

在 Kubernetes (K8s) 中，ServiceAccount 是一种特殊类型的 账户对象，用于为 Pod 中的容器提供身份标识。它的核心作用是为 Pod 内的进程（如应用程序）授予对集群内资源的访问权限。以下是详细说明及查看方法：一、什么是 ServiceAccount？核心功能：身份标识每个 ServiceAccount 都有一个唯一的名称和一个关联的加密签名密钥对（存放在 Secret 中），用于证明请求来自该账户。权限控制通过与 Role/ClusterRole + RoleBinding/ClusterRoleBinding 的组合，定义此账户能执行的操作（如读写 ConfigMap、调用外部 API 等）。自动挂载凭证当 Pod 使用了某个 ServiceAccount，Kubernetes 会自动将其凭证（包含 CA证书、命名空间、Token）注入到 Pod 的特定挂载点：/var/run/secrets/kubernetes.io/serviceaccount/包括三个文件：ca.crt, namespace, token。关键特点：特性    说明作用域    可作用于单个命名空间（默认）或整个集群（需配合 ClusterRole）默认行为    新创建的 Pod 若未显式指定 SA，则使用命名空间下的 default SA安全性    推荐遵循最小权限原则，仅授予必要权限二、如何查看 ServiceAccount 对象？以下是常用查看方式及命令示例：查看当前命名空间的所有 ServiceAccount# 查看当前命名空间的所有 SA（含简要信息）kubectl get serviceaccounts# 显示完整详细信息（JSON/YAML格式）kubectl get serviceaccounts -o wide          # 表格+额外字段kubectl get serviceaccounts -o json        # JSON格式kubectl get serviceaccounts -o yaml        # YAML格式查看指定命名空间的 ServiceAccount# 查看名为 "my-namespace" 命名空间下的所有 SAkubectl get serviceaccounts --namespace=my-namespace# 查看特定 SA 的详细信息（如名为 "my-sa"）kubectl describe serviceaccount my-sa --namespace=my-namespace跨命名空间搜索 ServiceAccount# 查看所有命名空间下的 SA 列表kubectl get serviceaccounts --all-namespaces1.2.导出 ServiceAccount 的配置为文件# 将名为 "my-sa" 的 SA 配置导出为 YAML 文件kubectl get serviceaccount my-sa -n my-namespace -o yaml > my-sa.yaml三、典型使用场景示例假设你有一个名为 app-pod 的 Pod，它使用了自定义的 app-sa ServiceAccount，并绑定了一个允许读取 ConfigMap 的角色：# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: app-deploymentspec:  replicas: 1  template:    metadata: {}    spec:      serviceAccountName: app-sa # 指定使用的 ServiceAccount      containers:      - name: app-container        image: my-image此时，app-sa 就是该 Pod 的身份标识，其权限由对应的 RoleBinding 决定。四、注意事项不要混淆 IAM 账号Kubernetes 的 ServiceAccount ≠ 云厂商的 IAM 账号，它是集群内部的虚拟身份。避免裸奔权限默认的 default SA 通常没有绑定任何角色，但如果你手动绑定了高权限角色（如 edit），可能导致安全风险。多租户环境隔离在共享集群中，建议为不同团队/应用创建独立的 ServiceAccount 并严格限制权限。五、相关概念扩展对象类型    描述Role / ClusterRole    定义一组权限规则RoleBinding / ClusterRoleBinding    将角色绑定到 ServiceAccountPod    使用 ServiceAccount 的主体Secret    存储 ServiceAccount 的私钥和令牌总结ServiceAccount 是 Pod 的身份卡，用于控制容器对集群资源的访问。查看命令：kubectl get serviceaccounts（基础）、kubectl describe serviceaccount <name>（详情）。最佳实践：为每个应用创建专用 SA，并按需绑定最小权限角色。

**Raft协议**是一种专为分布式系统设计的共识算法，旨在解决多个节点之间的数据一致性问题。以下是对Raft协议的介绍以及核心内容的详细说明：### Raft协议概述1. **目标定位**：作为一种替代传统Paxos协议的新型方案诞生，侧重于提升可理解性与工程实践便利性。2. **核心理念**：采用强领导权模式，将复杂的一致性问题拆解为相互独立的子问题进行处理。3. **适用场景**：适用于构建高可用分布式存储系统、数据库集群等需强一致性的场景。### 核心角色与状态转换1. **三种节点状态**   - **Leader（领导者）**：唯一有权接受客户端请求并协调日志复制的中心节点。   - **Follower（追随者）**：被动响应领导者或候选人的请求，定期接收心跳信号维持状态。   - **Candidate（候选人）**：当追随者超时未收到心跳时触发选举产生的临时角色，参与投票竞争成为新领导者。2. **状态转换逻辑**   - **稳定期**：领导者持续发送心跳消息压制其他节点的选举行为。   - **选举触发**：若超过选举超时时间未收到心跳，追随者转为候选人发起投票。   - **多数决选**：获得集群多数选票的候选人晋升为领导者，开启新的任期。### 关键机制详解1. **领导者选举**   - **任期机制**：每个任期用单调递增的数字标识，确保过期无效的请求不会被处理。   - **随机超时**：每个节点设置随机范围的选举超时时间，减少分裂投票概率。   - **投票规则**：节点按“先到先得”原则投票，且仅支持同一任期内的单一候选者。   - **心跳抑制**：领导者定期发送心跳消息重置追随者的选举定时器，防止不必要的选举。2. **日志复制**   - **指令序列化**：客户端请求被领导者转换为日志条目，按顺序编号后同步至多数追随者。   - **提交条件**：当日志条目被复制到多数节点后，领导者提交该条目并通知所有节点执行。   - **一致性保障**：通过前缀匹配原则确保日志一致性，落后节点会丢弃冲突日志并同步最新条目。3. **安全属性**   - **领导完备性**：领导者必须包含所有已提交的日志条目，保证后续操作基于完整数据。   - **日志匹配原则**：若两个日志条目索引和任期相同，则认定其内容一致。   - **只追加特性**：领导者不会修改或删除已存在的日志条目，仅做增量添加。### 技术优势1. **模块化设计**：将一致性问题分解为领导者选举、日志复制、安全性等独立模块，降低实现复杂度。2. **强领导权简化逻辑**：所有操作由领导者驱动，避免无主状态下的决策冲突。3. **容错能力**：可容忍集群内少数节点故障，只要多数节点存活即可维持服务。4. **易于调试**：清晰的日志结构和状态转换便于排查问题。总的来说，Raft协议通过结构化的领导权设计和严格的日志复制机制，在保证强一致性的同时提供了良好的可扩展性和容错能力。其模块化思想和清晰的状态转换逻辑使其成为分布式系统领域的重要基础组件。

k8s-node02 节点 `NotReady` 状态的详细分析和解决方案### **一、核心问题定位**从 `kubectl describe node` 输出可见，所有关键条件（MemoryPressure/DiskPressure/PIDPressure/Ready）均处于 **Unknown** 状态，且最终错误原因是 **"Kubelet stopped posting node status"**。这表明 **Kubelet 进程未能正常向 API Server 汇报节点状态**，导致节点被标记为 `NotReady`。### **二、分步解决方案**#### **1️⃣ 紧急修复：重启 Kubelet 服务**```bashsystemctl restart kubelet```**目的**：尝试恢复 Kubelet 进程与 API Server 的通信。  **注意**：若重启后仍无法恢复，需进一步排查底层原因。#### **2️⃣ 深度排查：查看 Kubelet 日志**```bashjournalctl -f -u kubelet          # 实时查看日志journalctl -u kubelet --since "1 hour ago"  # 查看历史日志``` **重点关注以下错误类型**：| 错误类型 | 可能原因 | 解决方案 ||||-|| `NetworkPluginNotReady` | CNI 插件（如 Calico）未就绪 | 检查 CNI 组件状态 || `Failed to connect to API Server` | 网络隔离/证书过期 | 检查网络连通性及证书 || `Disk pressure detected` | 磁盘空间不足 | 清理磁盘 || `Container runtime failed` | Docker/Containerd 异常 | 重启容器运行时 |#### **3️⃣ 检查 CNI 网络插件（Calico）**```bashkubectl get pods -n kube-system -l k8s-app=calico-node``` **若发现 Calico Pod 异常**：- 重新部署 Calico 组件：    ```bash  kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml  ```- 确保宿主机网络策略允许 Calico 流量（检查 `iptables` 规则）。#### **4️⃣ 验证容器运行时（Docker）**```bashsystemctl status docker       # 检查服务状态docker info                   # 验证 Docker 功能```**若 Docker 异常**：- 重启 Docker 服务：    ```bash  systemctl restart docker  ```- 检查 Docker 日志：    ```bash  journalctl -u docker.service  ```#### **5️⃣ 检查磁盘空间**```bashdf -h                       # 查看全局磁盘使用率du -sh /var/lib/docker/*    # 检查 Docker 目录占用``` **若磁盘空间不足**：- 清理无用镜像：    ```bash  docker system prune -a  ```- 扩展磁盘配额或迁移数据到更大分区。#### **6️⃣ 校验 Kubelet 配置**检查 `/etc/kubernetes/kubelet.conf` 文件：- 确保 `cgroupDriver` 与集群其他节点一致（如 `systemd` 或 `cgroupfs`）。- 确认 `--container-runtime` 参数指向正确的容器运行时（如 `remote` 对应 containerd）。#### **7️⃣ 升级 Kubelet 版本**当前版本 **v1.20.15** 已过时，建议升级至最新稳定版（如 v1.28+）：```bash# 示例：升级 Kubelet（需匹配控制平面版本）yum install -y kubelet-<new_version> && systemctl restart kubelet``` **注意**：升级前需备份配置文件，并确保控制平面兼容新版本。#### **8️⃣ 清理节点 Taints**当前节点存在两个危险 Taints：```bashTaints:             node.kubernetes.io/unreachable:NoExecute                    node.kubernetes.io/unreachable:NoSchedule``` **清理命令**：```bashkubectl taint nodes k8s-node02 node.kubernetes.io/unreachable:NoExecute-kubectl taint nodes k8s-node02 node.kubernetes.io/unreachable:NoSchedule-```### **三、典型错误场景及处理**| **现象**                          | **可能原因**               | **解决方案**                     ||--||-|| `NetworkPluginNotReady`          | Calico 组件未启动           | 重启 Calico Pod 或重新部署        || `Failed to dial tcp ...`         | API Server 网络不通        | 检查防火墙规则及节点网络配置     || `No space left on device`       | 磁盘空间不足               | 清理磁盘或扩容                    || `Connection refused by API Server` | API Server 未响应          | 检查控制平面健康状态              |### **四、预防措施**1. **监控告警**：部署 Prometheus + Grafana，监控节点 CPU/内存/磁盘使用率及 Kubelet 状态。2. **日志轮转**：定期清理 Kubelet 日志（`/var/log/kubelet.log`），避免磁盘占满。3. **版本管理**：保持 Kubelet 与 API Server 版本同步，避免兼容性问题。4. **CNI 高可用**：确保 Calico 等网络插件的冗余配置，避免单点故障。### **五、最终验证**执行以下命令确认节点状态：```bashkubectl get nodes k8s-node02      # 应显示 Ready 状态kubectl describe node k8s-node02  # 检查 Conditions 均为 True```若问题仍未解决，请提供以下信息进一步分析：1. `kubectl describe node k8s-node02 -o json > node.json`（导出完整 JSON）。2. `journalctl -u kubelet --since "1 hour ago"`（最近 1 小时 Kubelet 日志）。3. `docker ps` 和 `crictl ps`（容器运行时状态）。

在 Kubernetes 中，**`Role`**、**`RoleBinding`** 和 **`ServiceAccount`** 三者共同构成了 **基于角色的访问控制（RBAC）机制**的核心框架。它们之间的关系可以理解为一种 **“策略 + 映射 + 主体”** 的组合逻辑。以下是详细解析：--- **核心概念速览**| 对象类型               | 作用                                                                 | 作用域          ||------------------------|--------------------------------------------------------------------|-----------------|| `ServiceAccount`       | **身份载体**：代表 Pod 的身份，用于身份验证                       | 命名空间级     || `Role`                | **权限模板**：定义一组可执行的操作（如 `get`, `list`, `create`） | 命名空间级     || `RoleBinding`         | **绑定关系**：将 `Role` 的权限授予给某个 `ServiceAccount`        | 命名空间级     || `ClusterRole`         | 类似 `Role`，但作用于整个集群                                   | 集群级         || `ClusterRoleBinding`  | 类似 `RoleBinding`，但可将 `ClusterRole` 绑定到任意 `ServiceAccount` | 集群级         |---**三者关系详解**#### 1️⃣ **`ServiceAccount` — “谁”（Who）**- **本质**：一个虚拟用户账号，属于某个命名空间。- **用途**：作为 Pod 的身份标识，其内部的容器可以通过此身份向 API Server 发起请求。- **关键行为**：  - 自动生成 JWT Token 并存入 Secret。  - Token 会被挂载到 Pod 的 `/var/run/secrets/kubernetes.io/serviceaccount/` 目录下。- **示例场景**：一个名为 `webapp-sa` 的 ServiceAccount 被分配给前端 Pod，使其能够拉取镜像或访问特定 Service。#### 2️⃣ **`Role` — “能做什么”（What）**- **本质**：一组预定义的权限规则集合。- **结构**：由多个 **Rule** 组成，每个 Rule 描述对某类资源的操作权限（如 `verbs: ["get", "list"]`, `resources: ["pods"]`）。- **作用域限制**：仅适用于当前命名空间内的资源（若需全局权限，需改用 `ClusterRole`）。- **示例规则**：  ```yaml  rules:  - apiGroups: [""]    resources: ["pods"]    verbs: ["get", "list", "watch"] # 允许查看本命名空间下的 Pod  ```#### 3️⃣ **`RoleBinding` — “关联谁来做”（To Whom）**- **本质**：建立 `Role` 与 `ServiceAccount` 之间的绑定关系。- **关键点**：  - **单向绑定**：一个 `RoleBinding` 只能将一个 `Role` 绑定到一个 `ServiceAccount`。  - **同命名空间生效**：`RoleBinding` 必须创建在目标 `ServiceAccount` 所在的命名空间内。  - **动态生效**：一旦绑定成功，对应 ServiceAccount 的 Pod 立即获得该角色的权限。- **示例绑定**：  ```yaml  apiVersion: rbac.authorization.k8s.io/v1  kind: RoleBinding  metadata:    name: webapp-rolebinding    namespace: frontend # 必须与 ServiceAccount 同命名空间  roleRef:    apiGroup: rbac.authorization.k8s.io    kind: Role    name: pod-reader # 引用已存在的 Role  subjects:  - kind: ServiceAccount    name: webapp-sa # 目标 ServiceAccount    namespace: frontend # 必须与上面一致  ```---**完整流程示例**假设我们要实现以下目标：  > **让 `frontend` 命名空间下的 `webapp-sa` ServiceAccount 能够查看本命名空间的所有 Pod。**#### 步骤 1：创建 ServiceAccount（身份）```bashkubectl create sa webapp-sa -n frontend```现在 `frontend` 命名空间下有了一个叫 `webapp-sa` 的身份。#### 步骤 2：创建 Role（权限模板）```yaml# role-pod-reader.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  namespace: frontend  name: pod-readerrules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "list", "watch"]``` 这个角色定义了对 Pod 的读权限。#### 步骤 3：创建 RoleBinding（绑定关系）```bashkubectl apply -f rolebinding-webapp.yaml```其中 `rolebinding-webapp.yaml` 内容如下：```yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: webapp-rolebinding  namespace: frontend # 关键！必须与 SA 同命名空间roleRef:  apiGroup: rbac.authorization.k8s.io  kind: Role  name: pod-reader # 引用上面创建的 Rolesubjects:- kind: ServiceAccount  name: webapp-sa # 目标 SA  namespace: frontend # 必须与上面一致``` 现在 `webapp-sa` 这个身份获得了 `pod-reader` 角色的权限。#### 验证效果部署一个使用 `webapp-sa` 的 Pod：```yaml# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: webapp  namespace: frontendspec:  replicas: 1  template:    spec:      serviceAccountName: webapp-sa # 关键！指定使用的 SA      containers:      - name: webapp-container        image: busybox        command: ["sleep", "3600"] # 保持运行以便测试```进入容器后尝试访问 API：```bash# 进入容器kubectl exec -it <pod-name> -- /bin/sh# 尝试获取 Pod 列表（会成功）curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \     -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \     https://kubernetes.default.svc/api/v1/namespaces/frontend/pods```如果返回 Pod 列表，说明权限生效。--- **权限层级对比表**| 组合                  | 适用场景                                                                 | 权限范围               ||-----------------------|--------------------------------------------------------------------------|------------------------|| `Role` + `RoleBinding` | 本命名空间内的精细化权限控制（推荐）                                   | 当前命名空间           || `ClusterRole` + `ClusterRoleBinding` | 跨命名空间的全局权限（如系统组件）                                 | 整个集群               || `Role` + `ClusterRoleBinding` | &#10060; 不允许：不能用集群级绑定关联命名空间级角色                      | N/A                   || `ClusterRole` + `RoleBinding`    | &#10060; 不允许：不能用命名空间级绑定关联集群级角色                     | N/A                   |---**常见误区 & 最佳实践**1. **避免过度授权**：不要直接使用 `edit` 或 `admin` 这类高风险角色，遵循最小权限原则。2. **命名空间隔离**：优先使用 `Role` + `RoleBinding`，避免不必要的集群级绑定。3. **定期审计**：通过 `kubectl get rolebindings --all-namespaces` 检查现有绑定关系。4. **使用工具可视化**：借助 `kubectl krew` 插件或第三方工具（如 Lens）查看 RBAC 拓扑图。5. **删除旧残留**：清理不再使用的 ServiceAccount、Role 和 Binding，防止僵尸权限。---**总结**| 元素               | 类比                     | 功能                          ||--------------------|--------------------------|-------------------------------|| `ServiceAccount`   | **身份证**               | 证明“你是谁”                  || `Role`             | **菜单清单**             | 规定“你可以吃什么菜”          || `RoleBinding`      | **服务员递菜单**         | 把菜单交给具体的客人（SA）    || `ClusterRole`      | **全国通用菜单**         | 适用于所有餐厅（命名空间）    || `ClusterRoleBinding` | **总部直接派发菜单**     | 跨餐厅（命名空间）分发菜单    |通过这种组合，Kubernetes 实现了灵活且安全的权限管理体系，既保证了多租户环境下的资源隔离，又能满足复杂场景下的权限需求。

在 Kubernetes (K8s) 中，**`ServiceAccount`** 是一种特殊类型的 **账户对象**，用于为 Pod 中的容器提供身份标识。它的核心作用是为 Pod 内的进程（如应用程序）授予对集群内资源的访问权限。以下是详细说明及查看方法：--- **一、什么是 ServiceAccount？**#### 核心功能：1. **身份标识**     每个 `ServiceAccount` 都有一个唯一的名称和一个关联的加密签名密钥对（存放在 Secret 中），用于证明请求来自该账户。   2. **权限控制**     通过与 **Role/ClusterRole** + **RoleBinding/ClusterRoleBinding** 的组合，定义此账户能执行的操作（如读写 ConfigMap、调用外部 API 等）。3. **自动挂载凭证**     当 Pod 使用了某个 `ServiceAccount`，Kubernetes 会自动将其凭证（包含 `CA证书`、`命名空间`、`Token`）注入到 Pod 的特定挂载点：   - `/var/run/secrets/kubernetes.io/serviceaccount/`   - 包括三个文件：`ca.crt`, `namespace`, `token`。 关键特点：| 特性                | 说明                                                                 ||---------------------|--------------------------------------------------------------------|| **作用域**          | 可作用于单个命名空间（默认）或整个集群（需配合 `ClusterRole`）       || **默认行为**        | 新创建的 Pod 若未显式指定 SA，则使用命名空间下的 `default` SA      || **安全性**          | 推荐遵循最小权限原则，仅授予必要权限                               |--- **二、如何查看 ServiceAccount 对象？**以下是常用查看方式及命令示例： 1. 查看当前命名空间的所有 ServiceAccount```bash# 查看当前命名空间的所有 SA（含简要信息）kubectl get serviceaccounts# 显示完整详细信息（JSON/YAML格式）kubectl get serviceaccounts -o wide          # 表格+额外字段kubectl get serviceaccounts -o json        # JSON格式kubectl get serviceaccounts -o yaml        # YAML格式```2. 查看指定命名空间的 ServiceAccount```bash# 查看名为 "my-namespace" 命名空间下的所有 SAkubectl get serviceaccounts --namespace=my-namespace# 查看特定 SA 的详细信息（如名为 "my-sa"）kubectl describe serviceaccount my-sa --namespace=my-namespace```3. 跨命名空间搜索 ServiceAccount```bash# 查看所有命名空间下的 SA 列表kubectl get serviceaccounts --all-namespaces``` 4. 导出 ServiceAccount 的配置为文件```bash# 将名为 "my-sa" 的 SA 配置导出为 YAML 文件kubectl get serviceaccount my-sa -n my-namespace -o yaml > my-sa.yaml```---**三、典型使用场景示例**假设你有一个名为 `app-pod` 的 Pod，它使用了自定义的 `app-sa` ServiceAccount，并绑定了一个允许读取 ConfigMap 的角色：```yaml# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: app-deploymentspec:  replicas: 1  template:    metadata: {}    spec:      serviceAccountName: app-sa # 指定使用的 ServiceAccount      containers:      - name: app-container        image: my-image```此时，`app-sa` 就是该 Pod 的身份标识，其权限由对应的 RoleBinding 决定。---**四、注意事项**1. **不要混淆 IAM 账号**     Kubernetes 的 `ServiceAccount` ≠ 云厂商的 IAM 账号，它是集群内部的虚拟身份。   2. **避免裸奔权限**     默认的 `default` SA 通常没有绑定任何角色，但如果你手动绑定了高权限角色（如 `edit`），可能导致安全风险。3. **多租户环境隔离**     在共享集群中，建议为不同团队/应用创建独立的 `ServiceAccount` 并严格限制权限。--- **五、相关概念扩展**| 对象类型           | 描述                                 ||--------------------|--------------------------------------|| `Role` / `ClusterRole` | 定义一组权限规则                     || `RoleBinding` / `ClusterRoleBinding` | 将角色绑定到 ServiceAccount         || `Pod`              | 使用 ServiceAccount 的主体            || `Secret`           | 存储 ServiceAccount 的私钥和令牌      |---**总结**- **`ServiceAccount` 是 Pod 的身份卡**，用于控制容器对集群资源的访问。- **查看命令**：`kubectl get serviceaccounts`（基础）、`kubectl describe serviceaccount <name>`（详情）。- **最佳实践**：为每个应用创建专用 SA，并按需绑定最小权限角色。

一、引言1、Jenkins简介Jenkins 是一个开源的自动化服务器，主要用于持续集成（Continuous Integration, CI）和持续交付（Continuous Delivery, CD）。它由Sun Microsystems的前员工在2004年左右开发，最初命名为Hudson。后来由于一些商标争议，项目改名为Jenkins，并且迅速成为构建、测试和部署软件项目的流行工具。Jenkins的主要特点包括：持续集成与持续交付：Jenkins可以自动监控版本控制系统中的代码变更，触发构建过程，运行测试，并根据结果决定是否部署到生产环境。这有助于快速发现集成问题并缩短开发周期。插件生态系统：Jenkins拥有庞大的插件库，支持几乎所有现代软件开发中可能用到的工具和技术，比如Git、Maven、Gradle等。易于扩展：由于Jenkins是基于Java编写的，因此它非常灵活，用户可以通过编写自定义脚本或插件来扩展其功能。分布式构建：Jenkins支持通过“主从”架构进行分布式构建，允许将构建任务分配给多个节点，以提高效率和资源利用率。图形化界面：Jenkins提供了直观的Web界面，使得配置和管理CI/CD流程变得简单。Pipeline即代码：Jenkins Pipeline是一个特性集，它允许用户定义其CI/CD流程为代码的形式（通常使用Groovy语言），这样可以将其纳入版本控制，并与其他团队成员共享。安全性：Jenkins提供了一些安全特性和认证机制，确保只有授权用户才能执行特定的操作。社区和支持：作为一个开源项目，Jenkins有一个活跃的社区，提供文档、论坛讨论以及第三方服务和支持。 ​2、k8s简介Kubernetes（通常简写为K8s）是一个开源平台，用于自动化部署、扩展和管理容器化的应用程序。它最初由Google设计并开发，并于2014年捐赠给了云原生计算基金会（CNCF）。Kubernetes提供了强大的机制来管理分布式系统中的应用，使其能够在物理机或虚拟机集群上运行。特性自动化容器编排：自动重启失败的容器、替换和重新调度容器、水平扩展容器等。自我修复：如果某个节点故障，Kubernetes会自动将该节点上的工作负载迁移到其他健康的节点上。横向扩展：通过简单的命令、用户界面或者基于CPU使用情况自动调整应用的规模。服务发现与负载均衡：无需修改代码即可实现服务之间的通信，Kubernetes为容器提供了自己的IP地址以及一个DNS名称，并且可以负载均衡分配到容器上。自动发布与回滚：逐步发布新的版本，同时监视应用健康状况，如有问题则自动回滚更改。密钥与配置管理：让您可以轻松地管理和分发密码、OAuth令牌和其他敏感数据，而无需重建镜像。  ​3、什么在k8s中部署Jenkins在Kubernetes（简称K8s）中部署Jenkins，可以带来许多好处，尤其是对于那些需要高效、可扩展和可靠的持续集成/持续交付（CI/CD）流程的企业或团队。1. 动态资源管理想象一下，你有一家餐厅，有时候客人很多，有时候客人很少。如果每次客人都很多时，你都需要临时雇佣更多的服务员，而当客人少时又得解雇他们，这样不仅麻烦还浪费资源。而在Kubernetes中部署Jenkins就像是有一个智能管理系统，它可以根据当前的工作负载自动调整所需的服务员数量（即Jenkins构建节点）。当有很多构建任务时，系统会自动增加更多“服务员”来帮忙；反之，则减少“服务员”，从而更有效地利用资源。2. 提高可靠性和容错能力如果你的餐厅只有一个厨房，一旦这个厨房出现问题，整个餐厅就无法正常运营了。同样，在传统设置下，如果Jenkins主节点出现故障，所有的构建任务都会停止。但在Kubernetes环境中，即使一个节点出问题，其他健康的节点可以立即接管工作，确保服务不间断。3. 快速响应变化假设你的餐厅突然接到一个大型宴会订单，你需要快速准备好额外的食物和服务。有了Kubernetes的帮助，Jenkins可以迅速扩展其处理能力，就像瞬间增加了多个厨房一样，以应对突如其来的大量工作。完成后，还可以快速缩减规模，节省成本。4. 统一环境无论是在家中准备食物还是在商业厨房里烹饪，保持一致的食谱和做法是非常重要的。将Jenkins部署到Kubernetes上，意味着你可以确保开发、测试和生产环境尽可能地相似，避免由于环境差异导致的问题。 ​二、准备工作1、准备k8s集群这里我们用的k8s版本为 1.23.1，大家也可以使用其他的k8s发行版本，如果还未安装k8s请参考下面的文章。《在Centos中搭建 K8s 1.23 集群超详细讲解》《深度解析：Kubernetes 1.28.2集群安装过程中的关键步骤》 2、Jenkins官方镜像版本介绍官方镜像的推荐Jenkins官方推荐使用 jenkinsci/blueocean 这个镜像。与直接下载Jenkins的镜像相比，Blue Ocean镜像提供了更为现代和直观的用户界面，使得Jenkins的使用和管理变得更加容易。因此，对于新用户或者希望简化Jenkins使用的用户来说，推荐使用jenkinsci/blueocean镜像。镜像版本标签Jenkins官方镜像在Docker Hub上提供了多个版本标签，以便用户选择。以下是一些常见的版本标签：latest：表示最新版本的Jenkins，包括最新的功能和安全更新。然而，由于它是最新的版本，可能存在一些未知的问题或不稳定因素。lts：表示长期支持版本的Jenkins，通常更稳定且经过更多的测试。它适合用于生产环境，因为提供了更多的安全更新和稳定性修复。具体版本号：例如2.401.1、1.24.1-bcc31d32159f等，表示特定版本的Jenkins。用户可以根据自己的需求选择特定的版本号。 3、Jenkins镜像准备这里我们使用的Jenkins版本为2.410，镜像我放在个人资源中了，大家也可以自行下载或使用其他的发行版本。上传至worker节点后，执行下面的命令解压docker load -i jenkins-2.410.tar.gzAI写代码如果k8s版本大于1.23，则执行下面的命令ctr -n=k8s.io images import jenkins2.410AI写代码三、在Kubernetes中部署Jenkins1、准备存储资源我们准备一个PVC，将Jenkins的数据持久化到当中，以免pod漂移到其他节点后，历史数据丢失。下面简单介绍下如何创建PVC，更详细的可以参考《k8s PV与PVC持久化存储详解与实际应用分享》这篇文章首先准备一个NFS共享目录yum install nfs-utils -ysystemctl enable nfs --nowmkdir /data/jenkins -pvim /etc/exports# 添加下面的内容/data/jenkins *(rw,no_root_squash)#保存、退出exportfs -arvAI写代码创建一个名称空间，用于部署Jenkinskubectl create namespace jenkins-k8sAI写代码 编写pv的yaml文件apiVersion: v1kind: PersistentVolumemetadata:  name: jenkins-k8s-pvspec:  capacity:    storage: 10Gi  accessModes:  - ReadWriteMany  nfs:    server: 192.168.40.181    path: /data/jenkinsAI写代码kind: PersistentVolume：定义了这个资源对象的类型是一个PersistentVolume（持久卷）。PersistentVolume是集群中的一段存储，它独立于Pod的生命周期而存在。metadata: 开始元数据部分，这里包含了资源对象的一些基本信息。name: jenkins-k8s-pv：给这个PersistentVolume指定一个名称，这里是jenkins-k8s-pv。在Kubernetes集群中，每个资源对象都需要一个唯一的名称。spec:：开始定义PersistentVolume的具体规格和配置。capacity:：定义了这个持久卷的容量。storage: 10Gi：指定了持久卷的存储大小为10GiB（Gibibytes）。accessModes:：描述了持久卷可以被访问的方式或模式。- ReadWriteMany：表示这个卷可以被多个节点同时以读写方式挂载。其他可能的访问模式包括ReadWriteOnce（只能由一个节点以读写方式挂载）和ReadOnlyMany（可以被多个节点以只读方式挂载）。nfs:：指定了这个持久卷使用NFS（网络文件系统）作为其后端存储机制。server: 192.168.40.181：指定了NFS服务器的IP地址，这里是192.168.40.181。path: /data/jenkins：指定了NFS服务器上共享的路径，即实际存储数据的位置，在这个例子中是/data/jenkins。创建PVkubectl  apply -f pv.yamlAI写代码编写创建PVC的yaml文件kind: PersistentVolumeClaimapiVersion: v1metadata:  name: jenkins-k8s-pvc  namespace: jenkins-k8sspec:  resources:    requests:      storage: 10Gi  accessModes:  - ReadWriteManyAI写代码 创建PVCkubectl apply -f  pvc.yamlAI写代码2、准备账号创建sa账号kubectl create sa jenkins-k8s-sa -n jenkins-k8sAI写代码进行RBAC授权kubectl create clusterrolebinding jenkins-k8s-sa-cluster -n jenkins-k8s  --clusterrole=cluster-admin --serviceaccount=jenkins-k8s:jenkins-k8s-saAI写代码3、部署Jenkins准备yaml文件kind: DeploymentapiVersion: apps/v1metadata:  name: jenkins  namespace: jenkins-k8sspec:  replicas: 1  selector:    matchLabels:      app: jenkins  template:    metadata:      labels:        app: jenkins    spec:      serviceAccount: jenkins-k8s-sa      containers:      - name: jenkins        image:  jenkins/jenkins:2.410        imagePullPolicy: IfNotPresent        ports:        - containerPort: 8080          name: web          protocol: TCP        - containerPort: 50000          name: agent          protocol: TCP        resources:          limits:            cpu: 2000m            memory: 2Gi          requests:            cpu: 500m            memory: 512Mi        livenessProbe:          httpGet:            path: /login            port: 8080          initialDelaySeconds: 60          timeoutSeconds: 5          failureThreshold: 12        readinessProbe:          httpGet:            path: /login            port: 8080          initialDelaySeconds: 60          timeoutSeconds: 5          failureThreshold: 12        volumeMounts:        - name: jenkins-volume          subPath: jenkins-home          mountPath: /var/jenkins_home      volumes:      - name: jenkins-volume        persistentVolumeClaim:          claimName: jenkins-k8s-pvcAI写代码部署Jenkinskubectl apply -f jenkins-deployment.yamlAI写代码4、创建Service部署成功后，创建一个service，以供外部访问编写yaml文件apiVersion: v1kind: Servicemetadata:  name: jenkins-service  namespace: jenkins-k8s  labels:    app: jenkinsspec:  selector:    app: jenkins  type: NodePort  ports:  - name: web    port: 8080    targetPort: web    nodePort: 30089  - name: agent    port: 50000    targetPort: agentAI写代码创建servicekubectl apply -f  service.yamlAI写代码5、访问测试浏览器输入worker节点的IP+30089端口，如果显示下面的页面，证明部署成功————————————————                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                        原文链接：https://blog.csdn.net/weixin_53269650/article/details/146060495

随着Kubernetes（K8s）成为容器编排的事实标准，如何高效地管理和监控Kubernetes集群成为DevOps和SRE团队的重要课题。目前，主流的Kubernetes管理工具包括原生的`kubectl`命令行工具、开源的桌面客户端`Lens`，以及企业级管理平台`Rancher`。本文将从功能、易用性、适用场景、扩展性等多个维度进行深度对比，帮助读者选择最适合自身需求的工具。 1.kubectl：Kubernetes的原生命令行工具1.1核心功能kubectl是Kubernetes官方提供的命令行工具，用于与KubernetesAPIServer交互，支持几乎所有K8s操作，包括：集群管理（`apply`、`delete`、`scale`）资源查看（`get`、`describe`、`logs`）调试（`exec`、`port-forward`、`top`）1.2优势✅最底层控制：直接与KubernetesAPI交互，适合高级用户。✅脚本化&自动化：可与CI/CD工具（如Jenkins、GitLabCI）集成。✅轻量级：无需额外安装GUI，适合终端用户。1.3劣势❌学习曲线陡峭：需要熟悉YAML和K8s资源模型。❌可视化能力弱：依赖`kubectl`插件（如`k9s`）增强可视化。❌多集群管理复杂：需手动切换`kubeconfig`。适用场景：开发者和运维专家需要自动化脚本的场景对GUI无硬性要求的场景2.Lens：开源的KubernetesIDE2.1核心功能Lens是一款基于Electron的桌面应用，提供强大的K8s集群可视化能力：实时集群状态监控（CPU、内存、Pod状态）内置终端（直接运行`kubectl`命令）多集群管理（支持一键切换）日志和事件查看（支持时间范围筛选）2.2优势✅直观的UI：降低K8s学习门槛，适合新手。✅多集群支持：可同时管理多个K8s环境（Dev/Prod）。✅插件生态：支持Helm、Prometheus等扩展。2.3劣势❌资源占用较高：基于Electron，内存消耗较大。❌企业功能缺失：如RBAC审计、企业级安全策略。适用场景：开发者和中小团队需要可视化操作但不想用WebUI的场景本地开发和调试3.Rancher：企业级Kubernetes管理平台3.1核心功能Rancher是一个完整的K8s管理平台，支持：多集群集中管理（跨云、混合云）内置应用商店（HelmChart部署）RBAC和审计日志（企业级安全）监控和告警（集成Prometheus+Grafana）3.2优势✅企业级功能：支持SSO、审计、合规性检查。✅开箱即用的监控：无需额外配置Prometheus。✅应用生命周期管理：简化CI/CD流程。3.3劣势❌部署复杂：需要额外维护RancherServer。❌资源开销大：适合中大型企业，小团队可能过度设计。适用场景：企业级多集群管理需要统一安全策略和审计混合云/多云环境4.横向对比总结  5.如何选择？个人开发者/小团队：Lens是最佳选择，兼顾易用性和功能。K8s专家/自动化场景：`kubectl`+`k9s`更高效。企业级多集群管理：Rancher提供完整的解决方案。6.未来趋势kubectl：仍然是底层标准，但生态插件（如`kubectl-tree`）增强功能。Lens：可能进一步优化性能，并增强企业功能。Rancher：向GitOps（如Fleet）和边缘计算扩展。没有“最好”的工具，只有“最合适”的工具。`kubectl`适合深度控制，`Lens`适合开发者体验，`Rancher`适合企业级管理。根据团队规模、技术栈和安全需求选择，甚至可以组合使用（如`kubectl`+Rancher）。 

 在Kubernetes中，服务（Service）是一个抽象层，它定义了一组Pod的访问策略。通常情况下，服务会分配一个集群内的IP地址，并通过这个IP地址和端口来路由流量到后端Pod。然而，Kubernetes还提供了一种特殊类型的服务——无头服务（Headless Service），它有着独特的用途和优势。  概念 无头服务是一种没有被分配集群IP的服务（所以它本身还是一个 Cluster 服务，只是IP被特定设置为 None）。当你创建一个无头服务时，通过设置 spec.clusterIP 字段为 "None" 来实现这一点。这意味着 Kubernetes 不会为该服务分配一个虚拟IP地址，而是直接将DNS解析配置指向后端Pod的真实IP地址。因为它不分配集群IP，这意味着客户端可以直接访问后端Pod，而无需通过服务的负载均衡。  核心作用 直接访问Pod：无头服务允许客户端应用程序直接连接到各个Pod，而不是通过一个统一的入口点。 简化服务发现：DNS查询会返回所有匹配选择器的Pod IP列表，便于应用直接使用这些地址进行通信。 使用场景 无头服务特别适用于以下场景：  主从选举 或者 分布式计算，需要与特定Pod直接交互。 构建如 数据库副本集 或 缓存集群 等复杂网络拓扑。 创建方式 要创建一个无头服务，只需在服务定义中设置 spec.clusterIP 为 "None" 即可。  apiVersion: v1 kind: Service metadata:   name: my-headless-service spec:   clusterIP: None   selector:     app: my-app 总结 无头服务提供了更直接的Pod访问方式，简化了某些应用场景下的网络配置和服务发现。它赋予了开发人员更多的控制权，尤其是在那些对网络通信模式有特定需求的应用场景下。通过消除中间层的抽象，无头服务不仅提高了效率，也增强了系统的灵活性和可扩展性。 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/catoop/article/details/144673093 

Kubernetes（K8s）是一个开源的容器编排系统，用于自动化部署、扩展和管理容器化应用程序。在K8s集群中，为了保证通信的安全性和可靠性，使用了多种证书来确保组件之间的身份验证和加密通信。本文将介绍K8s中的证书管理，以及当证书过期后如何进行续期。一、K8s证书概述K8s集群中的证书主要用于以下方面：API Server证书：用于API Server与客户端之间的通信加密和身份验证。Kubelet证书：用于Kubelet与API Server之间的通信加密和身份验证。etcd证书：用于etcd集群节点之间的通信加密和身份验证。这些证书通常具有一定的有效期，一般为1年。当证书过期后，如果不进行续期，将导致K8s集群中的组件之间无法正常通信，从而影响整个集群的稳定性和可用性。二、证书续期方法1. 手动续期手动续期证书是一种比较直接的方法，但操作相对繁琐。具体步骤如下：生成新证书：使用K8s提供的工具（如kubeadm）或第三方工具生成新的证书。替换旧证书：将新生成的证书替换掉集群中对应的旧证书。这通常涉及到修改配置文件、重启服务等操作。验证证书：确保新证书已生效，并且集群中的组件能够正常通信。2. 自动续期为了简化证书管理过程，K8s提供了自动续期的功能。具体实现方式依赖于所使用的证书管理方案，以下是一些常见的自动续期方法：(1) 使用kubeadm对于使用kubeadm初始化的K8s集群，可以通过kubeadm命令进行证书续期。kubeadm会自动检测集群中的证书过期情况，并提示用户进行续期操作。(2) 使用cert-managercert-manager是一个K8s原生的证书管理工具，它可以自动管理K8s集群中的TLS证书。通过配置cert-manager，可以自动检测证书过期情况，并在证书过期前生成新的证书，实现自动续期。(3) 使用第三方工具除了kubeadm和cert-manager外，还有一些第三方工具可以帮助实现K8s证书的自动续期。这些工具通常提供了丰富的功能和灵活的配置选项，可以根据实际需求进行选择。三、注意事项在进行证书续期时，需要注意以下几点：备份旧证书：在替换旧证书之前，务必备份好旧证书和相关配置文件，以便在出现问题时能够恢复到之前的状态。谨慎操作：证书替换涉及到集群的敏感信息和安全配置，因此在进行操作时务必谨慎，避免误操作导致集群故障。监控和告警：建议设置证书过期监控和告警机制，以便在证书即将过期时及时收到通知并进行处理。四、总结K8s证书管理是确保集群安全和稳定的重要一环。通过合理的证书管理和续期策略，可以确保K8s集群中的组件能够持续、稳定地进行通信和协作。在实际应用中，可以根据集群的规模和需求选择合适的证书管理方案，并结合自动续期功能简化证书管理过程。

Kubernetes（K8s）作为容器编排领域的领导者，以其强大的容器管理能力、自动化部署以及高度可扩展性受到了广泛关注。在K8s的众多概念中，Pod是其最核心也是最基本的管理单元。那么，为什么K8s会选择Pod作为最小的管理单元呢？本文将从多个方面深入阐述这一问题。1. 容器间的协作与依赖关系在实际应用中，一个完整的服务或应用往往由多个容器组成，这些容器之间可能存在依赖关系，需要协同工作。例如，一个Web应用可能包含一个前端容器、一个后端容器和一个数据库容器。这些容器需要相互通信、共享数据，并且作为一个整体对外提供服务。Pod的设计正是为了支持这种容器间的协作与依赖关系。通过将多个容器封装在一个Pod中，K8s可以确保这些容器在同一台主机上运行，共享相同的网络命名空间、存储卷等资源。这使得容器间的通信变得简单高效，同时也方便了资源的统一管理和调度。2. 简化资源管理在K8s中，Pod是资源调度的基本单位。通过将多个容器组合成一个Pod，K8s可以简化资源管理。K8s只需要关注Pod的资源需求，而不需要关心Pod内部每个容器的具体资源使用情况。这种简化的管理方式使得资源分配更加灵活高效，也降低了管理的复杂性。3. 生命周期管理Pod作为最小的管理单元，其生命周期管理也更为简单和统一。K8s通过控制Pod的创建、调度、运行和销毁等生命周期阶段，可以确保整个应用或服务的稳定性和可靠性。同时，K8s还提供了丰富的钩子函数和自定义操作，允许用户在Pod的不同生命周期阶段执行特定的操作，进一步增强了其灵活性和可扩展性。4. 横向扩展与容错性在K8s中，Pod的副本集（ReplicaSet）和部署（Deployment）等高级对象允许我们轻松地对Pod进行横向扩展，以应对高并发访问或提高容错性。当某个Pod出现故障或无法提供服务时，K8s可以自动创建新的Pod来替换它，确保服务的连续性和可用性。这种自动扩展和容错机制使得K8s在处理大规模分布式系统时表现出色。5. 标准化与兼容性Pod作为K8s的核心概念之一，已经得到了广泛的认可和应用。许多云服务商和开源社区都提供了对Pod的支持和扩展。这使得基于Pod构建的应用和服务可以在不同的平台和环境中无缝迁移和部署，提高了应用的标准化程度和兼容性。总结综上所述，K8s选择Pod作为最小的管理单元是出于多方面的考虑。Pod的设计既满足了容器间协作与依赖关系的需求，又简化了资源管理、生命周期管理以及横向扩展与容错性等方面的处理。同时，Pod的标准化和兼容性也使得基于K8s构建的分布式系统更加稳定可靠、易于管理和扩展。因此，Pod作为K8s的最小管理单元具有其合理性和优越性。

在Kubernetes（K8s）集群中，Pod是最小且最简单的部署单元。它代表了在集群上运行的一个进程。Pod封装了应用的容器（例如Docker容器），存储、唯一的网络IP，以及一个或多个容器运行所需的选项。Pod也提供了一种部署和管理容器的模式。Pod的基本概念Pod是K8s管理的最小部署单元，一个Pod可以包含一个或多个容器。这些容器共享Pod的网络命名空间、存储系统以及进程ID空间。在Pod内部，容器之间可以直接通过localhost进行通信。Pod的设计初衷是为了支持多个容器协同工作，例如一个容器作为主程序，另一个容器作为辅助程序。Pod的状态Pod在K8s集群中有多种状态，这些状态描述了Pod的当前运行情况。通过kubectl get pods命令可以查看集群中所有Pod的状态。常见的Pod状态包括：Running：Pod已经绑定到了一个节点上，Pod中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。Succeeded：Pod中的所有容器都已成功终止，并且不会再重启。Failed：Pod中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非零状态退出或者被系统终止。Unknown：因为某些原因无法取得Pod的状态，通常发生在与Pod所在节点通信失败时。Pod的生命周期Pod的生命周期从创建开始，经历调度、启动、运行、终止等阶段，最终可能被删除。在Pod的生命周期中，K8s提供了许多钩子函数，允许用户在Pod的不同阶段执行自定义的操作，如初始化容器、前置和后置操作等。例子：一个简单的Pod定义下面是一个简单的Pod定义YAML文件示例：apiVersion: v1 kind: Pod metadata: name: my-pod labels: app: myapp spec: containers: - name: myapp-container image: myapp:v1 ports: - containerPort: 8080在这个例子中，我们定义了一个名为my-pod的Pod，它有一个容器myapp-container，该容器使用myapp:v1镜像，并监听8080端口。当我们使用kubectl create -f pod.yaml命令创建这个Pod时，K8s会尝试在集群中找到一个合适的节点来运行这个Pod。一旦Pod被调度并成功启动，我们就可以通过kubectl get pods来查看Pod的状态。Pod的状态查看假设我们已经创建了上面的Pod，并且它正在运行。执行kubectl get pods命令，我们会看到类似下面的输出：NAME READY STATUS RESTARTS AGE my-pod 1/1 Running 0 1m在这个输出中：NAME：Pod的名称。READY：Pod中就绪的容器数量与Pod中容器总数的比值。STATUS：Pod的当前状态，这里是Running。RESTARTS：Pod中容器的重启次数。AGE：Pod已经运行的时间。通过这个命令，我们可以快速了解Pod的状态和运行情况。如果需要更详细的信息，可以使用kubectl describe pod my-pod命令来查看Pod的详细描述。总结Pod是Kubernetes中最基础的部署单元，它封装了应用容器及其运行环境。通过理解Pod的基本概念、状态以及生命周期，我们可以更好地在K8s集群中部署和管理应用。掌握Pod的定义和状态查看方法，是使用K8s进行容器化应用部署的关键一步。

你是一个程序员，你用代码写了一个博客应用服务，并将它部署在了云平台上。但应用服务太过受欢迎，访问量太大，经常会挂。所以你用了一些工具自动重启挂掉的应用服务，并且将应用服务部署在了好几个服务器上，总算抗住了。后来你又上线了商城应用服务和语音应用服务，随着应用服务变多，需求也千奇百怪。有的应用服务不希望被外网访问到，有的部署的时候要求内存得大于 xxGB 才能正常跑。你每次都需要登录到各个服务器上，执行手动操作更新。不仅容易出错，还贼浪费时间。原本就没时间找女朋友的你，现在哭得更大声了。那么问题就来了，有没有一个办法，可以解决上面的问题？当然有，没有什么是加一个中间层不能解决的，如果有，那就再加一层。这次我们要加的中间层，叫 Kubernetes。Kubernetes的位置 Kubernetes 是什么？Kubernetes，它是开源的神器，因为单词太长，所以我们习惯省略中间 8 个字母，简称它为 k8s。k8s名称的由来它介于应用服务和服务器之间，能够通过策略，协调和管理多个应用服务，只需要一个 yaml文件配置，定义应用的部署顺序等信息，就能自动部署应用到各个服务器上，还能让它们挂了自动重启，自动扩缩容。听起来有些厉害，它是怎么实现这些功能的呢？Kubernetes 架构原理为了实现上面的功能，Kubernetes 会将我们的服务器划为两部分，一部分叫控制平面（control plane，以前叫master），另一部分叫工作节点，也就是 Node。简单来说它们的关系就是老板和打工人， 用现在流行的说法就是训练师和帕鲁。控制平面负责控制和管理各个 Node，而 Node 则负责实际运行各个应用服务。k8s控制平面和Node的关系我们依次看下这两者的内部架构。控制平面内部组件• 以前我们需要登录到每台服务器上，手动执行各种命令，现在我们只需要调用 k8s 的提供的 api 接口，就能操作这些服务资源，这些接口都由 API Server 组件提供。• 以前我们需要到处看下哪台服务器 cpu 和内存资源充足，然后才能部署应用，现在这部分决策逻辑由 Scheduler（调度器）来完成。• 找到服务器后，以前我们会手动创建，关闭服务，现在这部分功能由 Controller Manager（控制器管理器）来负责。• 上面的功能都会产生一些数据，这些数据需要被保存起来，方便后续做逻辑，因此 k8s 还会需要一个存储层，用来存放各种数据信息，目前是用的 etcd，这部分源码实现的很解耦，后续可能会扩展支持其他中间件。以上就是控制平面内部的组件。k8s控制平面组件我们接下来再看看 Node 里有哪些组件。Node 内部组件Node 是实际的工作节点，它既可以是裸机服务器，也可以是虚拟机。它会负责实际运行各个应用服务。多个应用服务共享一台 Node 上的内存和 CPU 等计算资源。Node可以是裸机服务器或虚拟机在文章开头，我们聊到了部署多个应用服务的场景。以前我们需要上传代码到服务器，而用了 k8s 之后，我们只需要将服务代码打包成Container Image(容器镜像)，就能一行命令将它部署。如果你不了解容器镜像的含义，你可以简单理解为它其实就是将应用代码和依赖的系统环境打了个压缩包，在任意一台机器上解压这个压缩包，就能正常运行服务。为了下载和部署镜像，Node 中会有一个 Container runtime组件。将容器镜像粗略理解为压缩包每个应用服务都可以认为是一个 Container（容器）, 并且大多数时候，我们还会为应用服务搭配一个日志收集器 Container 或监控收集器 Container，多个 Container 共同组成一个一个 Pod，它运行在 Node 上。一个pod内有多个容器k8s 可以将 pod 从某个 Node 调度到另一个 Node，还能以 pod 为单位去做重启和动态扩缩容的操作。所以说 Pod 是 k8s 中最小的调度单位。Node调度Pod另外，前面提到控制平面会用 Controller Manager（通过API Server）控制 Node 创建和关闭服务，那 Node 也得有个组件能接收到这个命令才能去做这些动作，这个组件叫 kubelet，它主要负责管理和监控 Pod。最后，Node 中还有个 Kube Proxy，它负责 Node 的网络通信功能，有了它，外部请求就能被转发到 Pod 内。控制平面和Node的组件 Cluster控制平面和Node共同构成了一个 Cluster，也就是集群。在公司里，我们一般会构建多个集群, 比如测试环境用一个集群，生产环境用另外一个集群。同时，为了将集群内部的服务暴露给外部用户使用，我们一般还会部署一个入口控制器，比如 Ingress 控制器（比如Nginx），它可以提供一个入口让外部用户访问集群内部服务。生产和测试环境 kubectl 是什么上面提到说我们可以使用 k8s 提供的 API 去创建服务，但问题就来了，这是需要我们自己写代码去调用这些 API 吗？答案是不需要，k8s 为我们准备了一个命令行工具 kubectl，我们只需要执行命令，它内部就会调用 k8s 的 API。kubectl调用k8s的API接下来我们以部署服务为例子，看下 k8s 是怎么工作的。怎么部署服务？首先我们需要编写 YAML 文件，在里面定义 Pod 里用到了哪些镜像，占用多少内存和 CPU 等信息。然后使用 kubectl 命令行工具执行 kubectl apply -f xx.yaml ，此时 kubectl 会读取和解析 YAML 文件，将解析后的对象通过 API 请求发送给 Kubernetes 控制平面内 的 API Server。API Server 会根据要求，驱使 Scheduler通过 etcd提供的数据寻找合适的 Node， Controller Manager会通过 API Server 控制 Node 创建服务，Node 内部的 kubelet在收到命令后会开始基于 Container runtime组件去拉取镜像创建容器，最终完成 Pod的创建。至此服务完成创建。部署应用服务整个过程下来，我们只需要写一遍 yaml 文件，和执行一次 kubectl 命令，比以前省心太多了！部署完服务后，我们来看下服务是怎么被调用的。怎么调用服务？以前外部用户小明，直接在浏览器上发送 http 请求，就能打到我们服务器上的 Nginx，然后转发到部署的服务内。用了 k8s 之后，外部请求会先到达 Kubernetes 集群的 Ingress 控制器，然后请求会被转发到 Kubernetes 内部的某个 Node 的 Kube Proxy上，再找到对应的 pod，然后才是转发到内部容器服务中，处理结果原路返回，到这就完成了一次服务调用。用户调用k8s内应用服务的流程到这里我们就大概了解了 k8s 的工作原理啦，它本质上就是应用服务和服务器之间的中间层，通过暴露一系列 API 能力让我们简化服务的部署运维流程。并且，不少中大厂基于这些 API 能力搭了自己的服务管理平台，程序员不再需要敲 kubectl 命令，直接在界面上点点几下，就能完成服务的部署和扩容等操作，是真的嘎嘎好用。总结• k8s 是 G 家开源的神器，用于管理海量容器服务。• k8s 集群内分为控制平面和 Node，控制平面是大脑，负责发指令，Node 是手脚，负责执行任务。• 控制平面内有 API Server，Scheduler，Controller Manager 以及 etcd 等组件。Node 中含有 Pod，Kubelet,Container runtime, Kube Proxy 等组件。控制平面和 Node 共同构成一个 Cluster。• 文章通过怎么部署服务和怎么调用服务两个例子将这些组件串联了起来，方便大家加深理解。最后给大家留一个问题，我们提到 k8s 的时候，一般会提一下 docker, 但为了避免大家混淆，我在写这篇文章的时候，只字不提 docker，你知道 docker 和 k8s 之间是什么关系吗？欢迎评论区聊聊。

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请于4月30日下班前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】华为云云原生FinOps解决方案，为您释放云原生最大价值【直播时间】2024年4月24日 16:30-18:00【直播专家】Roc 华为云云原生DTSE技术布道师【直播简介】还在对CCE集群成本评估感到束手无策？还在担心不合理的K8s集群资源申请和过度浪费？华为云容器服务CCE全新上线云原生FinOps中心，为用户提供多维度集群成本可视化，结合智能规格推荐、混部、超卖等成本优化手段，助力客户降本增效，释放云原生最大价值。观看直播：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年4月25日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制长袖卫衣活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制POLO衫更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制雨伞等好礼。【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年4月30日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

前言随着云计算技术的不断发展和普及，容器化技术已成为现代软件开发和部署的主流方式。而在容器编排领域，Kubernetes（简称K8s）无疑是当之无愧的领军者。本文将带您走进K8s的世界，了解其基本概念、核心组件以及如何使用K8s来管理和调度容器。一、什么是Kubernetes？Kubernetes是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。它提供了丰富的功能，包括自动调度、滚动更新、回滚、水平扩展、服务发现和存储编排等。通过使用K8s，开发人员和运维人员可以更加高效地管理和维护复杂的容器化应用程序。二、K8s的核心组件Master节点Master节点是K8s集群的控制中心，负责整个集群的管理和调度工作。它包括以下几个核心组件：API Server：提供RESTful API，供其他组件和客户端调用，实现集群资源的增删改查。Scheduler：负责根据一定的调度算法，将Pod分配到合适的Node节点上运行。Controller Manager：负责管理集群中的各种资源对象，如Pod、Service等，确保它们的状态与预期一致。Node节点Node节点是K8s集群中的工作节点，负责运行容器化应用程序。Node节点上运行的主要组件包括：Kubelet：负责与Master节点通信，接收并执行Master节点的调度指令。Kube-proxy：实现Service到Pod的流量转发功能。容器运行时：如Docker、containerd等，负责运行容器。三、如何使用K8s？安装和配置K8s集群您可以通过多种方式安装和配置K8s集群，如使用kubeadm、minikube等工具进行快速搭建，或者使用云服务提供商提供的托管K8s服务。安装完成后，您需要通过kubectl命令行工具与集群进行交互。部署应用程序在K8s中，您可以通过编写YAML或JSON格式的资源配置文件来定义您的应用程序。这些文件描述了Pod、Service、Deployment等K8s资源对象的属性。通过kubectl apply命令将这些文件提交给K8s集群，K8s将自动为您创建和管理这些资源对象。管理和维护应用程序K8s提供了丰富的功能来管理和维护您的应用程序。例如，您可以使用滚动更新功能来平滑地升级您的应用程序版本；使用自动扩展功能来根据负载情况自动调整Pod的数量；使用Service发现功能来实现服务之间的自动发现和通信等。四、总结Kubernetes作为容器编排领域的领军者，为现代软件开发和部署提供了强大的支持。通过了解K8s的基本概念、核心组件以及使用方法，您可以更加高效地管理和维护您的容器化应用程序。随着K8s生态系统的不断完善和发展，相信它将为未来的云计算领域带来更多的创新和突破。