第 1 阶段：架构与组件实战
1. Kubernetes 架构通俗理解
K8s 集群分为两个部分：
- Master 节点（控制平面 Control Plane）： 调度中心。
- Node 节点（工作节点 Worker Node）： 业务代码。
2. 核心组件介绍
为了让你真正理解，我们通过命令去“抓”出这些组件。请在终端执行以下命令：
A. 看节点node
查看有多少控制中心、工作节点
kubectl get nodes -o wide
- 看点：
ROLES: 标记为control-plane或master的是调度中心；<none>或worker通常是干活的节点。STATUS: 必须是Ready才是健康的。VERSION: 看看你们公司用的 K8s 是什么版本（例如 v1.20+）。
[root@xos-hnbk692u ~]# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
xos-00002-294e Ready control-plane 517d v1.25.16-12+92530656e308a8 10.107.58.51 <none> PlatOS 1.3 (LTS) 4.18.0-372.32.1.90.po1.x86_64 docker://20.10.24
xos-00003-3760 Ready control-plane 517d v1.25.16-12+92530656e308a8 10.107.58.52 <none> PlatOS 1.3 (LTS) 4.18.0-372.32.1.90.po1.x86_64 docker://20.10.24
xos-hnbk692u Ready control-plane 517d v1.25.16-12+92530656e308a8 10.107.58.50 <none> PlatOS 1.3 (LTS) 4.18.0-372.32.1.90.po1.x86_64 docker://20.10.24
B.看组件
K8s 的神奇之处在于：它的核心组件（除了 Kubelet）通常也是以 Pod 的形式运行的。它们通常藏在 kube-system 这个命名空间里。
执行这条命令，这是了解架构最重要的一步：
kubectl get pods -n kube-system
你会看到类似下面的列表，我们来逐一对应架构知识：
1. API Server (kube-apiserver-xxx)
- 角色： “唯一入口”。
- 知识点： 所有命令（kubectl）、所有组件之间的通信，必须经过 API Server。它是集群唯一操作 etcd（数据库）的组件。
- 实战动作： 只要你能执行
kubectl get命令并得到反馈，说明 API Server 是活着的。
2. Etcd (etcd-xxx)
- 角色： “核心账本”。
- 知识点： 保存了集群所有的状态信息（有哪些 Node，跑了哪些 Pod）。如果它挂了，集群就失忆了。
- 实战动作： 通常你不需要直接操作它，知道它是数据库即可。
3. Controller Manager (kube-controller-manager-xxx)
- 角色： “自动化管理员”。
- 知识点： 它包含很多控制器。比如“副本控制器”发现某个应用少了一个副本，就会立刻补上。它是维持期望状态的核心。
4. Scheduler (kube-scheduler-xxx)
- 角色： “调度员”。
- 知识点： 当你创建一个新 Pod，调度员会根据资源空闲情况、策略，决定把它放到哪个 Node 上去跑。
5. Kube-Proxy (kube-proxy-xxx)
- 角色： “网络交警”。
- 知识点： 它是跑在每台 Node 上的。它负责维护网络规则，让你能通过 Service IP 访问到后端的 Pod。
6. CNI 插件 (例如 calico-node, flannel, cilium 等)
- 角色： “修路队”。
- 知识点： K8s 本身不提供网络功能，需要插件。你在列表中可能会看到
calico或flannel之类的名字，这就是负责让 Pod 之间能互相通信的组件。
[root@xos-hnbk692u ~]# kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
cadvisor-9jp79 1/1 Running 0 33d
cadvisor-dgccv 1/1 Running 0 33d
cadvisor-lm74p 1/1 Running 0 33d
coredns-558698fb9f-6n4mq 1/1 Running 0 33d
coredns-558698fb9f-fw6bp 1/1 Running 0 33d
etcd-xos-00002-294e 1/1 Running 8 293d
etcd-xos-00003-3760 1/1 Running 5 293d
kube-apiserver-xos-00002-294e 1/1 Running 31 307d
kube-apiserver-xos-00003-3760 1/1 Running 43 307d
kube-apiserver-xos-hnbk692u 0/1 CrashLoopBackOff 65301 (118s ago) 71d
kube-controller-manager-xos-00002-294e 1/1 Running 1202 517d
kube-controller-manager-xos-00003-3760 1/1 Running 1229 517d
kube-controller-manager-xos-hnbk692u 1/1 Running 353 517d
kube-proxy-6nkbl 1/1 Running 5 286d
kube-proxy-j872x 1/1 Running 8 286d
kube-proxy-qwrxf 1/1 Running 6 286d
kube-scheduler-xos-00002-294e 1/1 Running 1211 517d
kube-scheduler-xos-00003-3760 1/1 Running 1218 517d
kube-scheduler-xos-hnbk692u 1/1 Running 349 517d
metrics-server-7759b56654-blhq2 1/1 Running 0 33d
open-local-agent-5nqpw 3/3 Running 45 517d
open-local-agent-7xdbb 3/3 Running 47 517d
open-local-agent-nbp82 3/3 Running 43 517d
open-local-controller-6d4f6ff9d7-pxdqd 6/6 Running 0 33d
open-local-scheduler-extender-6976f89876-cdpw9 1/1 Running 0 33d
tigera-operator-6bbdd8d949-z4lll 1/1 Running 1392 307d
3. 架构实战总结命令
为了巩固对架构的理解，请运行下面这条命令查看集群的“健康体检报告”：
kubectl cluster-info
[root@xos-hnbk692u ~]# kubectl cluster-info
Kubernetes control plane is running at https://k8s.sangfor.novalocal:8443
CoreDNS is running at https://k8s.sangfor.novalocal:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
然后，挑选一个 Master 节点上的组件（例如 API Server），看看它的详细信息：
# 先复制上面 get pods -n kube-system 里的一个 apiserver 的名字
# 例如: kube-apiserver-node-01
kubectl describe pod kube-apiserver-<你的节点名> -n kube-system
- 看点： 往下翻，看到
Containers->Command。你会看到 API Server 启动时带了巨多的参数，这展示了它是如何被配置的（比如加密配置、权限配置等）。
[root@xos-hnbk692u ~]# kubectl describe pod kube-apiserver-xos-00002-294e -n kube-system
Name: kube-apiserver-xos-00002-294e
Namespace: kube-system
Priority: 2000001000
Priority Class Name: system-node-critical
Node: xos-00002-294e/10.107.58.51
Start Time: Thu, 20 Nov 2025 11:21:30 +0800
Labels: component=kube-apiserver
tier=control-plane
Annotations: kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.107.58.51:6443
kubernetes.io/config.hash: 31b5f8acc9b8b7c6e31a37d26c5249b7
kubernetes.io/config.mirror: 31b5f8acc9b8b7c6e31a37d26c5249b7
kubernetes.io/config.seen: 2025-03-06T10:41:13.375729979+08:00
kubernetes.io/config.source: file
Status: Running
IP: 10.107.58.51
IPs:
IP: 10.107.58.51
Controlled By: Node/xos-00002-294e
Containers:
kube-apiserver:
Container ID: docker://ad019dd68b5b26a03e60043fbbe4bea4f7197aabc63cee91bbe924549b054f83
Image: docker.sangfor.com/paas-docker-base/kube-apiserver:v1.25.16
Image ID: docker-pullable://docker.sangfor.com/paas-docker-base/kube-apiserver@sha256:eb99f1fb043d3f1d42f070bcc215897d938bbfc864dbfda1be11f05dba3e80d6
Port: <none>
Host Port: <none>
Command:
kube-apiserver
--advertise-address=10.107.58.51
--allow-privileged=true
--anonymous-auth=true
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100
--audit-log-path=/tmp/audit.log
--authorization-mode=Node,RBAC
--client-ca-file=/etc/kubernetes/pki/ca.crt
--enable-admission-plugins=DefaultStorageClass,NodeRestriction
--enable-bootstrap-token-auth=true
--etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
--etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
--etcd-servers=https://127.0.0.1:2379
--kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
--kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
--max-mutating-requests-inflight=8000
--max-requests-inflight=4000
--profiling=false
--proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
--proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
--requestheader-allowed-names=front-proxy-client
--requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--secure-port=6443
--service-account-issuer=https://kubernetes.default.svc.cluster.local
--service-account-key-file=/etc/kubernetes/pki/sa.pub
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key
--service-cluster-ip-range=10.192.0.0/16
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key
State: Running
Started: Thu, 20 Nov 2025 11:21:31 +0800
Ready: True
Restart Count: 31
Requests:
cpu: 250m
Liveness: http-get https://10.107.58.51:6443/livez delay=10s timeout=15s period=10s #success=1 #failure=8
Readiness: http-get https://10.107.58.51:6443/readyz delay=0s timeout=15s period=1s #success=1 #failure=3
Startup: http-get https://10.107.58.51:6443/livez delay=10s timeout=15s period=10s #success=1 #failure=24
Environment: <none>
Mounts:
/etc/kubernetes/pki from k8s-certs (ro)
/etc/localtime from localtime (ro)
/etc/pki from etc-pki (ro)
/etc/ssl/certs from ca-certs (ro)
/usr/share/zoneinfo from zoneinfo (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
ca-certs:
Type: HostPath (bare host directory volume)
Path: /etc/ssl/certs
HostPathType: DirectoryOrCreate
etc-pki:
Type: HostPath (bare host directory volume)
Path: /etc/pki
HostPathType: DirectoryOrCreate
k8s-certs:
Type: HostPath (bare host directory volume)
Path: /etc/kubernetes/pki
HostPathType: DirectoryOrCreate
localtime:
Type: HostPath (bare host directory volume)
Path: /etc/localtime
HostPathType: File
zoneinfo:
Type: HostPath (bare host directory volume)
Path: /usr/share/zoneinfo
HostPathType: Directory
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: :NoExecute op=Exists
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 10m kubelet Readiness probe failed: HTTP probe failed with statuscode: 500
✅ 第 1 阶段作业
请在你的环境中执行上述命令，并确认以下几点：
- 你们公司集群有几个 Master，几个 Worker？ 3个master 但是没有worker
- 你们用的网络插件（CNI）是什么？（在
kube-system的 Pod 里找名字，通常是 Calico, Flannel 或 Cilium）。
-
答案： 你们用的是 Calico。
- 解释： Tigera 是 Calico 背后的公司。Calico 是业界最常用的网络方案之一，性能好，支持网络策略。
- API Server 是高可用的吗？（看有几个 apiserver 的 pod）。 是，3个。
🧐 深度解读：你的集群现状
1. 为什么是 3 Master + 0 Worker？
- 现象： 你有 3 个节点，全是
control-plane（Master）。 - 结论： 这是一个**“超融合”架构。这意味着你的 Master 节点既当爹又当妈**——它们既负责发号施令（控制平面），也负责干苦力（跑业务 Pod）。
- 注意点： 原生 K8s 默认不让 Master 跑业务（会有“污点 Taint”），但你的环境大概率已经去掉了这个限制，否则没法跑业务。
2. 网络插件（CNI）找到了！
- 线索：
tigera-operator。 - 答案： 你们用的是 Calico。
- 解释： Tigera 是 Calico 背后的公司。Calico 是业界最常用的网络方案之一，性能好，支持网络策略。
3. ⚠️ 发现故障：高可用的实地演示
你刚才提到的“controller-manager 挂了一个”其实看错了，挂的那个是更核心的组件！
请仔细看这行：
kube-apiserver-xos-hnbk692u 0/1 CrashLoopBackOff 65301 (118s ago) 71d
- 真相： 节点
xos-hnbk692u上的 API Server（集群入口）挂了，而且重启了 6 万多次都没成功（CrashLoopBackOff）。 - 为什么你还能操作？
- 这就是 Kubernetes 高可用（HA） 的魅力！虽然
hnbk692u的入口挂了，但另外两个节点（xos-00002和xos-00003）的 API Server 是好的。你的kubectl命令自动连接到了活着的节点。
- 这就是 Kubernetes 高可用（HA） 的魅力！虽然
- 关于 Etcd 只有 2 个：
- 通常 3 节点集群应该有 3 个 Etcd。这里
xos-hnbk692u上的 Etcd 也没显示出来，说明这个节点xos-hnbk692u可能有比较严重的底层问题（可能是磁盘满了，或者静态 Pod 配置文件丢失）。 - 风险提示： Etcd 也是集群架构，遵循“过半存活”原则。3 个死 1 个没关系，但如果再死 1 个，你的集群就会变成“只读”甚至彻底瘫痪。
- 通常 3 节点集群应该有 3 个 Etcd。这里
-
GPA 2.95/4.00，获得三等奖学金、学科竞赛专项奖学金。
-
获得全国大学生数字媒体科技作品及创意比赛国家三等奖，湖南省大学生计算机程序设计竞赛省级一等奖。
-
英语四级。
-
计算机基础 ：具有良好的计算机网络基础，熟悉操作系统基础知识，熟悉常用的数据结构与算法。
-
开发规范 ：具备良好编码习惯与代码规范，熟练运用模板方法、策略、工厂、责任链、单例等设计模式降低模块耦合度；深入实践DDD领域驱动设计，熟悉充血模型、领域对象、依赖倒置等思想，曾在项目中通过DDD重构提升开发效率（如营销系统抽奖模块）；熟悉CI/CD流程，熟练使用Git、Maven、Jenkins等工具实现自动化部署。
-
Java ：精通Java语言及Spring全家桶（Spring、Spring Boot、Spring Cloud Alibaba），能进行二次开发与扩展；熟练掌握JUC并发工具（锁机制、线程池），能针对业务场景优化代码执行效率；深入理解Spring Cloud生态（Nacos、Ribbon、Gateway等），具备高可用微服务开发经验。
-
数据库 ：精通MySQL，熟悉InnoDB引擎原理、索引机制、事务特性与锁机制，具备SQL优化与主从同步经验；熟练掌握Redis，能灵活运用数据结构、持久化机制与集群部署，解决缓存穿透/击穿/雪崩问题，处理过双写数据一致性问题。
-
分布式 ：具备微服务项目开发经验，熟悉Spring Cloud Alibaba、Dubbo等框架，掌握服务注册发现、网关路由、熔断降级等设计；熟悉分布式事务解决方案（本地消息表、两阶段提交、事务补偿），了解分布式锁实现原理。
-
消息中间件 ：熟练使用Kafka、RabbitMQ，了解底层原理，具备顺序消息、消息积压等场景的实践经验。
-
云原生 ：熟练使用Docker、K8S进行容器化部署与运维，掌握Nginx反向代理与负载均衡配置，具备系统监控与故障排查能力。
2025年新人优秀转正员工，被评为 “团队AI先锋” ，积极推动并实践AI编程提效。
核心成果与项目贡献：
- OA审批Mock-Server工具研发：针对内网开发环境无法访问外网OA平台的阻塞性问题，主导设计并研发了Mock-Server。成功Mock了企微、钉钉、飞书三大平台的审批、组织架构等核心接口，彻底消除了内网测试断点，显著提升OA审批功能的开发和测试效率。在接口文档不全的情况下，创新性使用AI辅助快速定位和解析接口文档，高效完成开发。
- 数据地图功能从0到1建设：在研发周期紧、任务重的情况下，独立负责控制面12个API接口设计与业务逻辑实现。通过深度应用AI进行“并发编程”（如并行生成gRPC接口与HTTP网关代码），提升开发效率约80% ，按时完成开发并转测。高效修复40+TD，并主动识别并解决了MQ灰度消息抢占、定时器边界条件风险等深层隐患，保障功能稳定上线。目前已有超23家租户使用。
- XDLP泄密分析页面性能优化：针对历史遗留的复杂SQL查询导致客户在大数据量下功能不可用的问题，独立完成底层架构重构。通过深入分析15个动态查询条件，设计并实施“字段冗余+查询分离”方案，将五层嵌套的复杂Join查询优化为高效分页查询。实现查询性能提升1800% ，磁盘占用从~122MB降至近乎为0，彻底解决客户端的字段缺失与查询超时问题。
具备扎实Java技术栈和微服务架构经验的后端开发工程师。在深信服担任核心开发期间，不仅独立承担了从Mock工具研发、数据地图从0到1建设到重大性能优化等关键任务，展现出优秀的技术攻坚和问题解决能力；更积极拥抱新技术，是团队公认的AI应用实践者，能显著提升开发效率。我具备快速融入新团队和业务领域的能力，工作严谨，沟通主动，渴望在高速发展的技术团队中持续成长并创造价值。
