书籍来源：《Kubernetes进阶实战（第2版）》
一边学习一边整理读书笔记，并与大家分享，侵权即删，谢谢支持！
附上汇总贴：Kubernetes进阶自学系列 | 汇总_COCOgsta的博客-CSDN博客
1.2.1 Kubernetes集群概述
Kubernetes是一个跨多主机的容器编排平台，它使用共享网络将多个主机构建成统一的集群。其中Master（主节点），作为控制中心负责管理整个集群系统，余下的所有主机运行为Worker Node（工作节点），这些工作节点使用本地和外部资源接收请求并以Pod（容器集）形式运行工作负载。
概括来说，Kubernetes将所有工作节点的资源集结在一起形成一台更加强大的“服务器”，其计算和存储接口通过Master之上的API服务暴露，再由Master通过调度算法将客户端通过API提交的工作负载运行请求自动指派至某特定的工作节点以Pod对象的形式运行。
Kubernetes程序自身更像是构建在底层主机组成的集群之上的“云操作系统”或“云原生应用操作系统”，而容器是运行其上的进程，Pod类似于单机操作系统上的“进程组”，它包含一到多个容器，却是Kubernetes上的最小调度单元，因而同一Pod内的容器必须运行于同一工作节点之上，如图1-7所示。
Kubernetes本质是“以应用为中心”的现代应用基础设施，它通过管理各种基础支撑类服务将各种传统中间件“下沉”至自身内部，并经由声明式API向上层应用暴露这些基础设施能力。
在开发基于Kubernetes的云原生应用时，程序员可更好地集中精力于应用程序的业务本身而无须为程序中需要集成基础设施的能力而困扰。
Kubernetes以资源形式抽象出多种概念以描述应用程序及其周边组件，这些程序及组件被统称为API对象，它们有特定的类型，例如Node、Namespace、Pod、Service和Deployment等。Kubernetes使用“名称空间”为名称提供了作用域，并将大多数资源类型归属到名称空间级别。
运行应用的请求需要以配置清单（manifest）格式提交给Kubernetes API进行。Kubernetes支持JSON或YAML编码的配置清单，由API服务器通过HTTP/HTTPS协议接收配置清单并存储于etcd中，查询请求的结果也将以JSON序列化格式返回，同时支持更高效的Protobuf格式。
1.2.2 Kubernetes集群架构
Kubernetes属于典型的Server-Client形式的二层架构，Master主要由API Server、Controller-Manager和Scheduler这3个组件，以及一个用于集群状态存储的etcd存储服务组成；而每个Node节点则主要包含kubelet、kube-proxy及容器运行时3个组件，它们承载运行各类应用容器。
- Master组件
Master组件负责持续管理对象状态并响应集群中各种资源对象的管理操作，以及确保各资源对象的实际状态与所需状态相匹配。控制平面各组件及其主要功能如下。
（1）API Server
API Server是Kubernetes控制平面的前端，支持不同类型应用的生命周期编排。它还是整个集群的网关接口，由kube-apiserver将RESTful API公开给用户，是发往集群的所有REST操作命令的接入点，用于接收、校验以及响应所有的REST请求，并将结果状态持久存储于集群状态存储系统（etcd）中。
（2）集群状态存储
Kubernetes集群的所有状态信息都需要持久存储于存储系统etcd中。
etcd还为其存储的数据提供了监听机制，用于监视和推送变更。
（3）控制器管理器
控制器负责实现用户通过API Server提交的终态声明，它通过一系列操作步骤驱动API对象的当前状态逼近或等同于期望状态。
（4）调度器
Kubernetes系统上的调度是指为API Server接收到的每一个Pod创建请求，并在集群中为其匹配出一个最佳工作节点。kube-scheduler是默认调度器程序，它在匹配工作节点时的考量因素包括硬件、软件与策略约束，亲和力与反亲和力规范以及数据的局部性等特征。
- Node组件
Node组件是集群的“体力”输出者，因而一个集群通常会有多个Node以提供足够的承载力来运行容器化应用和其他工作负载。每个Node会定期向Master报告自身的状态变动，并接受Master的管理。
（1）kubelet
kubelet是运行于每个Node之上的“节点代理”服务，负责接收并执行Master发来的指令，以及管理当前Node上Pod对象的容器等任务。它支持从API Server以配置清单形式接收Pod资源定义，或者从指定的本地目录中加载静态Pod配置清单，并通过容器运行时创建、启动和监视容器。
kubelet会持续监视当前节点上各Pod的健康状态，包括基于用户自定义的探针进行存活状态探测，并在任何Pod出现问题时将其重建为新实例。
（2）容器运行时环境
Pod是一组容器组成的集合并包含这些容器的管理机制，真正负责运行容器的依然是底层的容器运行时。kubelet通过CRI（容器运行时接口）可支持多种类型的OCI容器运行时，例如docker、containerd、CRI-O、runC、fraki和Kata Containers等。
（3）kube-proxy
kube-proxy把API Server上的Service资源对象转换为当前节点上的iptables或（与）ipvs规则，这些规则能够将那些发往该Service对象ClusterIP的流量分发至它后端的Pod端点之上。kube-proxy本质上更像是Pod的代理及负载均衡器，负责确保集群中Node、Service和Pod对象之间的有效通信。
- 核心附件
附件（add-ons）用于扩展Kubernetes的基本功能，根据重要程度将其划分为必要和可选两个类别。网络插件是必要附件，常用的有Flannel、Calico、Canal、Cilium和Weave Net等。KubeDNS通常也是必要附件之一，而Web UI、容器资源监控系统、集群日志系统和Ingress Controller等是常用附件。
在这些附件中，CoreDNS、监控系统、日志系统和Ingress控制器基础支撑类服务是可由集群管理的基础设施，而Dashboard则是提高用户效率和体验的可视化工具，类似的项目还有polaris和octant等。