k8s的架构

k8s架构分为两个板块，一个是控制面板一个是工作节点。
集群大脑，控制面的核心组件
第一个叫kube-apiserver他是整个集群唯一的api接入入口，所有kubectl操作，集群组件交互，资源变更请求都必须经过他，核心负责身份认证，权限授权，资源准入控指，也是集群里唯一可以读取etcd数据的组件（很多人误以为它可以调度pod，这是典型错误，apiserver只做数据处理和请求转发，不参与任何pod调度决策）。
第二个就是etcd，他是一款强一致性分布式键值数据库（分布式：多台机器一起跑，就算一台坏了，数据还在。强一致性：集群多个节点，写入数据之后，所有节点读到的数据完全一模一样，不会出现 A 节点读到老数据、B 读到新数据。）专门用于k8s集群元数据持久化存储（业务数据：Pod 里面跑的程序、日志、业务输出。元数据：Pod 名字、命名空间、标签 label、注解 annotations、创建时间、UID、属于哪个 Deployment。），集群的节点信息，pod和server配置清单，权限资格，各类资源状态都会统一持久化存储在etcd中，etcd是集群的核心命脉，一旦数据损坏或丢失，整个集群会瘫痪，所以需要定期做快照备份。
第三个就是kube-controller-manager，他是集群的自愈调谐中心，内部集成多种控制器，持续巡检集群运行状态，并且时刻对比期望状态和实际运行状态，当副本缺失节点异常，后端端点失联，自动完成修复与自愈，保障集群稳定运行。关键区分，他只负责状态矫正，不会为pod选择分配节点，不要和调度器混淆。
第四个就是kube-scheduler，他的职责单一且专一，只处理pending待调度，未绑定节点的pod，结合节点剩余量，污点策略，亲和性规则，节点整体负载，筛选出最优解点，完成pod节点绑定。他只负责节点选择，不干预容器生命周期。
工作节点有两个常驻运行的核心组件
一个是kubectl，他是每台工作节点的本地代理，接受apiserver下达的指令，全权管理当前节点下所有的pod与容器，负责容器生命周期管理，监控探针检测，节点资源采集监控，同时实时向控制面上报节点与pod运行状态。
第二个是kube-proxy，他被部署在每一台工作节点上，核心是维护本机流量转发规则，主要实现server负载均衡，集群内部跨节点pod互通，同时支撑nodeport模式的外部流量接入。在生产环境总ipvs模式是大规模集群首选，对比传统iptables模式，并发性能更强，资源损耗更低。
1