1、K8s架构图：
2、K8s集群组件：
2.1、kube-api-server：
1、kube-api-server 是K8s集群的枢纽中心，最终用户和其他组件通过 kube-api-server 与集群通信。通信是通过TLS进行的，未经授权是无法通信的。
2、kube-api-server 是唯一与 ETCD 通信的组件。
3、控制平面组件和工作节点组件是通过 kube-api-server 来协调的。
2.2、ETCD：
1、etcd 是 Kubernetes 集群的数据库，所有的配置信息都存在这儿。俗称 Kubernetes 集群的大脑。
2、etcd 是1个分布式数据库，一般在多个节点上运行。
3、etcd 存储着 K8s集群的所有配置信息、状态、元数据（pod、secret、daemonsets、deployments、configmaps、statefulsts）。
4、数据存储位置 /registry。
2.3、kube-scheduler(k8s调度器)：
1、kube-scheduler是k8s的调度器，负责调度 k8s 集群中的 pod。
2、在部署 pod 时，要设置 pod 的 CPU、内存、关联性、污点、容错、资源限制、优先级、持久卷等。
2.4、kube controller manager(k8s控制器)：
1、检测集群实际状态和期望状态差异的。确保实际状态实时处于期望状态。
2、它内置了一些控制器列表管理各个模块：
1、Deployment controller：管理Deployment资源的
2、ReplicaSet controller：管理副本数资源的
3、DaemonSet controller：管理守护pod的，每个节点上都会运行一些基础的pod，通常是记录日志用的pod、kube proxy的pod等
4、Job controller：管理短期任务的执行，确保任务完成
5、CronJob controller：管理定时任务的执行，确保任务完成
6、endpoints controller：确保在 Pod 更改时及时更新 Endpoints，Service通过 Endpoints 对象，实现与 pod 通信
7、namespace controller：命名空间资源管理器
8、service account controller：管理 service account 生命周期的
9、Node controller：监控 Node 的状态，并处理相关事件
2.5、Cloud Controller Manager(CCM 云控制管理器)：
1、云环境部署 K8s 时，云控制管理器充当云平台API和K8s之间的桥梁。
2、云控制管理器中包含3个主要组件：
1、节点控制器(Node controller)：
这个控制器通过云厂商提供的API来更新节点的相关信息
2、路由控制器(Router controller)：
控制在云平台上配置组网路由，实现不同节点的pod可以通信
3、服务控制器(Service controller)：
为K8s服务部署负载均衡器，分配IP地址
2.6、kubelet：
1、集群的每个节点上都有 kubelet，当作守护程序运行的，由 systemd 管理。
2、向 kube-apiserver服务器 注册工作节点，把节点信息同步给 kube-aoiserver 。
3、创建、修改、删除容器，同步容器的状态。
4、kubelet 是个控制器，监控节点 pod 的变化。通过节点的运行时拉去、运行容器。
5、由 kubelet 直接管理的 pod 是 静态pod。通常从本节点的/etc/kubernetes/manifests目录下获取的 pod 信息。
6、kubelet 使用 CRI（容器运行时接口）gRPC接口 与容器运行时通信。
7、kubelet 使用 CSI（容器存储接口）gRPC 配置块存储卷。
8、kubelet 使用集群中配置 CNI插件 来分配 Pod IP地址，并为 pod 设置任何必要的网络路由和防火墙规则。
2.7、kube proxy：
1、负责网络通信和负载均衡。
2、是1个守护程序，作为 DaemonSet 运行在每个节点上。
3、kube proxy 会创建网络规则，将流量转发到 service分组 下的 后端pod，主要的流量协议是UDP、TCP、SCTP。
2.8、Container Runtime(容器运行时)：
2.9、CNI插件(容器网络接口)：
3、K8s集群对外暴露接口方式：
3.1、2种外部流量进入K8s集群的方式：
公有云的Loadbalancer模式和自有机房使用Ingress Controller模式 可以理解为1种。
3.1.1、公有云的Loadbalancer模式：
3.1.2、自有机房使用Ingress Controller模式：
3.1.3、NodeProt模式：
允许外部通信打开所有节点特定的接口，请求对应的服务。
3.2、1种只允许集群内部之间服务互相访问的方式：
3.3、3种访问方式的对比：
3.3.1、NodeProt：
通过每个虚拟机的固定端口访问对应服务的，但端口的数量是有限的。
具体流量流向为：
外部流量 ---> 各个虚拟机端口NodeProt(30000---32767) ---> kube-proxy ---> Service ---> Pod
3.3.2、ClusterIP：
只允许集群内部访问服务，不允许外部流量访问集群内服务。
具体流量流向为：
内部流量 ---> kube-proxy ---> Service ---> Pod
3.3.3、Loadbalancer/Ingress Controller：
Loadbalancer：一般云平台用来做外部流量负载均衡。
Ingress Controller：一般用自建机房时，用来做外部流量负载均衡。
3.3.3.1、LoadBalancer 4层(基于TCP/UDP) ：
只能做端口转发。
具体流量流向为：
外部流量(公网IP:端口) ---> LoadBalancer 4层(公网IP:端口) ---> kube-proxy ---> Service ---> Pod
3.3.3.2、LoadBalancer 7层(基于HTTP/HTTPS) ：
能做域名转发，将不同域名的流量转发到不同的端口。
具体流量流向为：
外部流量(域名、路径) ---> LoadBalancer 7层(基于域名、路径进行路由) ---> Ingress Controller 7层(根据规则将流量转发到具体的服务) ---> Service(通过kube-proxy转发到后端Pod) ---> kube-proxy ---> Pod
3.3.3.3、Ingress Controller 4层 ：
只能做端口转发。
具体流量流向为：
外部流量(公网IP:端口) ---> Ingress Controller 4层 (公网IP:端口) ---> kube-proxy ---> Service ---> Pod
3.3.3.4、Ingress Controller 7层 ：
能做域名转发，将不同域名的流量转发到不同的端口。
具体流量流向为：
外部流量(域名、路径) ---> Ingress Controller 7层 (基于HTTP/HTTPS的流量解析) ---> Service ---> kube-proxy ---> Pod