前言

在详解之前我们再来回忆一下架构图和前面说过一点的内容。

k8s可以管理分布式分布式集群中的微服务和容器化程序，并且提供了停机时间部署、自动回滚、资源缩放和容器的自愈等功能。

其中有自动配置、自动重启、复制的高弹性基础设施

其实它重要的设计因素之一是能够横向扩展意思就是高可用性提高了。

设计者这样大型的系统架构，且保证“运行时”健壮、可扩展、移植是具有挑战性的，因为体系结构会直接影响其运行方式和对环境的依赖程度及相关组件的耦合程度。

在这一体系之下的微服务，它是一种软件设计模式，适用于集群中的可扩展部署。

开发人员使用这一模式能够创建小型、可组合的应用程序，通过定义良好的HTTP REST API接口进行通信。Kubernetes也是遵循微服务架构模式的程序，具有弹性、可观察性和管理功能，可以适应云平台的需求。

复习

Kubernetes系统架构遵循客户端/服务端（C/S）架构，系统架构分为Master和Node两部分，Master作为服务端，Node作为客户端。Kubernetes系统具有多个Master服务端，可以实现高可用。在默认的情况下，一个Master服务端即可完成所有工作。

Master服务端也被称为主控节点，它在集群中主要负责如下任务。

（1）集群的“大脑”，负责管理所有节点（Node）。

（2）负责调度Pod在哪些节点上运行。

（3）负责控制集群运行过程中的所有状态。

Node客户端也被称为工作节点，它在集群中主要负责如下任务。

（1）负责管理所有容器（Container）。

（2）负责监控/上报所有Pod的运行状态。

Master服务端（主控节点）主要负责管理和控制整个Kubernetes集群，对集群做出全局性决策，相当于整个集群的“大脑”。集群所执行的所有控制命令都由Master服务端接收并处理。Master服务端主要包含如下组件。

● kube-apiserver组件：集群的HTTP REST API接口，是集群控制的入口。

它将Kubernetes“资源组/资源版本/资源”以RESTful的形式对外暴露并提供服务。
Kubernetes集群中的所有组件都通过kube-apiserver组件操作资源对象。kube-apiserver组件也是集群中唯一与Etcd集群进行交互的核心组件。

● kube-controller-manager组件：集群中所有资源对象的自动化控制中心。

● kube-scheduler组件：集群中Pod资源对象的调度服务。

Node客户端（工作节点）是Kubernetes集群中的工作节点，Node节点上的工作由Master服务端进行分配，比如当某个Node节点宕机时，Master节点会将其上面的工作转移到其他Node节点上。Node节点主要包含如下组件。

● kubelet组件：负责管理节点上容器的创建、删除、启停等任务，与Master节点进行通信。

● kube-proxy组件：负责Kubernetes服务的通信及负载均衡服务。

● container组件：负责容器的基础管理服务，接收kubelet组件的指令。

因为深入理解，所以我会尽量高强度详细描述组件原理

kube-apiserver

其一、概述

众所周知它运行在master节点上，在默认情况下kube-apiserver进程在本机的8080端口（对应参数
–insecure-port）提供REST服务。

并可以同时启动https安全端口（–secure-port=6443）来启动安全机制，加强rest api访问的安全性

除了大架构之下，还有小架构，就像生态圈一样，一层围着一层相互制衡，组件与组件之间也是相互配合，也有部分的耦合性

其二、架构白话

API Server的架构可以分为四层和一个监听机制
简单来说，Kubernetes API Server就像是集群的大脑中枢和通讯中心，它的运作机制相当关键：

1. API层：就像一个大管家，它对外开放了一套标准的RESTful API接口，任何想要跟集群打交道的家伙（无论是人还是机器）都可以通过这套接口来操控Kubernetes里面的各种东西。

比如创建新的Pod、查看正在运行的服务、更新应用部署或者删除不再需要的资源等。同时，它还提供了一些实用工具，帮助我们查看集群的健康状况、日志信息和性能指标，便于日常管理和维护。

2. 访问控制层：扮演着门卫的角色，确保只有合法的用户才能进行操作，且只能做他们权限范围内的事。API Server会验证每个请求的来源，看看是不是得到了正确的授权。这就好比是拿着通行证进入，不同级别的通行证允许你进入不同的区域，也就是采用了角色基础的访问控制（RBAC）策略。

想必这个策略大家也是第一次见，别担心我们下次还会讲到，到时候就会恍然大悟了

3. 注册表层：想象一下是一个巨大的账本，记录着Kubernetes里的所有资源对象，每个对象的种类、出生到消亡的过程以及不同版本间的变换规则都在这里得到定义和管理。这些资源对象还会被翻译成计算机容易理解的语言（比如JSON或ProtoBuf格式）进行存储和传输。

4. etcd数据库：就像是集群的记忆库，所有资源对象的状态信息都被保管在这里，永不丢失。API Server跟etcd保持着紧密联系，每当记忆库里有任何风吹草动（即资源状态发生变化），etcd都会立刻告诉API Server。

---

List-Watch机制：

为了让大家都能及时知道集群里发生了什么新鲜事，API Server采用了一种叫List-Watch的通知方式。
其他的Kubernetes组件们先向API Server要份当前的“快照”（资源全量数据），再设置“提醒”（Watch）

这样只要有资源更新、添加或删除，API Server就会马上把消息推送给关注的组件们，组件们收到消息后就可以迅速地在本地更新自己的“小抄”（缓存）。

这样一来，集群内的各个部分就能够在几乎实时的情况下保持数据同步，协同工作起来既准确又高效。

总之，Kubernetes API Server运用了一套精巧的设计，尤其是借助etcd的实时监听功能，搭建起了一个反应灵敏、稳定可靠的资源管理平台，使得整个集群能够顺畅无阻地进行复杂的应用编排和管理任务。

总结

实践说明

1. etcd数据库今天只是简述，他大概有许久的篇幅，为了大家不看长篇大论所以就留在后边单节篇章讲解

2. 还有一个关于api url的实践，这里简单的说明一下，后期组件原理讲完教大家部署再来实践
   比如

• curl localhost:8080/api
• curl localhost:8080/api/v1/replicationcontrillers

3. 架构之下还有一个独特的Kubernetes Proxy API接口
   在Kubernetes的世界里，API Server可不仅仅是个简单的数据交换中心，它还拥有特殊技能——代理请求。我们知道，API Server最基本的功能就是处理关于集群内各种资源对象（像Pod、Service那些）的增删改查操作，但更酷的是，它还能化身成为“信使”，通过Proxy API接口传递消息。

想象一下，当你想直接和集群内的某个Node上的kubelet守护进程交流时，无需亲自找到那个Node，只需通过Kubernetes API Server发个请求就行。

具体来说，你可以发起一个特殊的REST请求到API Server，比如请求路径可能是这样的：“/api/v1/nodes//proxy/”，后面跟着你想让kubelet执行的具体服务或端口路径。

举个例子，如果你想查看某个Node上kubelet提供的Pods列表，你不需要直接连接到那个Node，而是可以通过API Server发送如下请求：

curl localhost:8080/api/v1/nodes/node1/proxy/api/v1/pods

在这个请求中，API Server就像一个贴心的中介，它接收到你的请求后，并不会自己去查找Pod列表，而是聪明地帮你把这个请求“转寄”给了目标Node上的kubelet守护进程。

kubelet收到这个请求后，便会返回你需要的信息，这样我们就能够间接地与集群内的各个kubelet通信，大大方便了集群管理和监控。这就是Kubernetes Proxy API接口在实际场景中的作用。

Kubernetes API Server 在整个集群架构中起到至关重要的作用，它是集群内部各组件之间通信的桥梁和数据中心。下面以更通俗的方式解释几个典型交互场景：

1. kubelet 与 API Server 的交互

每台 Node 上的 kubelet 守护进程就像是工兵，定期向 API Server 报告自己所在节点的健康状况和资源使用情况。例如，它可能会说：“嘿，API Server，我这里是 Node A，目前一切正常，CPU 使用率和内存占用是这样的……”。API Server 收到这个状态报告后，会将这些数据妥善保存到集群的共享大脑——etcd 数据库中。

另一方面，kubelet 不仅汇报，还在时刻监听 API Server 发来的命令。就像听广播一样，一旦听到有新的 Pod 被指派到本节点，kubelet 就开始执行指令，启动相应的容器；如果听说某个 Pod 不再需要运行，kubelet 就会结束本地容器的生命周期；若接收到 Pod 配置的更改信息，kubelet 还会按照指示调整容器的运行参数。

2. kube-controller-manager 与 API Server 的交互

kube-controller-manager 中的 Node Controller 更像是一个监控员，它通过 API Server 设置的警报系统（Watch 接口）实时盯着所有节点的动静。一旦发现某个节点出状况（比如离线或者资源紧张），它就会触发相应的恢复措施，保证集群的稳定性。

3. kube-scheduler 与 API Server 的交互

kube-scheduler 担任调度员的角色，它密切关注 API Server 发布的“待安排任务”——新创建的 Pod。一旦有新的 Pod 出现，scheduler 便开始忙碌起来，根据预设的调度策略筛选出最合适的 Node，并通过 API Server 安排 Pod 到达选定的位置运行。

为了提高集群整体效率和降低 API Server 的负载，各个组件都有各自的“笔记本”——本地缓存，它们会定期或按需从 API Server 获取最新数据，并将这些数据暂存在本地。

这样，在大部分时候，组件可以直接查阅本地缓存来获取所需信息，避免频繁直接访问 API Server，从而优化了集群内部的通信效率和响应速度。

而 List-Watch 机制正是实现这一高效数据同步的关键技术手段，组件不仅可以一次性拉取全部数据（List），还可以持续监听数据变化（Watch），做到及时、准确地更新本地缓存。