1、Kubernetes结构

Kubernetes的结构主要由Master节点和Worker节点两部分组成。采用基于CS的HTTP协议。

1、Master节点

（也被称为控制平面） 是Kubernetes集群的控制中心（不需要很高的性能，不跑任务，通常一个就行，也可以用集群提高可用性），主要包括以下组件：

API Server: 作为Kubernetes的前端接口，其他组件都通过API Server交互信息(kubectl、Scheduler 、Controller  、etcd、kubelet、kube proxy)。

etcd: 用于存储集群的配置信息，以及各种资源的状态信息，为分布式键值存储服务，采用基于CS的HTTP协议。

Controller Manager: 负责处理集群级别的操作，如Pod失效时的副本控制，节点故障的处理等。

Scheduler: 负责选择合适的节点分配任务，所以它需要知道整个集群的资源使用情况。将任务交给api Server,api Server将请求写入etcd。

2、Worker/node/host节点

是真正运行应用容器的地方（每一个工作节点，都是由主节点来管理和分配任务），包括以下组件：

Kubelet: 是Master节点在每个Node上运行的代理，会操作CRI （docker）来创建容器，负责Pod的创建、启停、监视等生命周期管理以及回报给Master节点。

kube-proxy: 负责为Service提供集群内部的服务发现和负载均衡，负责写入规则至IPTABLES、IPVS实现服务映射访问，默认操作防火墙firewall实现pod映射。 （iptables 是一个在 Linux 系统上广泛使用的防火墙工具，用于配置和管理网络数据包的过滤和转发规则。IPVS（IP Virtual Server）是一个在 Linux 内核中实现的负载均衡器，用于分发网络流量到后端的多个服务器上，以提高系统的性能、可扩展性和可靠性。）

Container Runtime: 基础容器运行环境，Kubernetes支持多种容器运行环境，包括Docker，containerd等。

Worker节点上运行着各种类型的Pod，Pod是Kubernetes中运行容器的最小单位，它可以包含一个或者多个紧密相关的容器。

Kubernetes中还有一些其他的资源对象用于描述不同的服务，比如Deployment，StatefulSet，DaemonSet等用于描述不同类型的应用，Service用于提供服务发现和负载均衡，Ingress用于描述如何对外暴露服务等等。

3、其他插件

3.1 CoreDNS:可以为集群中色SVC创建一个域名IP的对应关系。访问pod的时候不需要ip地址，可以用coreDNS提供的域名来访问。是实现负载均衡的重要组件。

3.2 Dashboard：给K8S集群提供一个B/S结构访问体系。

3.3 Ingress Controller：官方集群只能实现4层代理，Ingress 可实现7层代理，根据域名/主机名进行负载均衡。

3.4 Fedetation：提供一个可以跨集群中心多K8S统一管理功能

3.5 Prometheus：提供一个k8s集群的监控能力

3.6 Elk：集群日志统一分析接入平台

2、简介

2.1、Master节点相关组件

1、 etcd

基本架构：

集群节点：etcd通过Raft一致性算法实现多节点的数据一致性和容错性，它可以容忍集群中部分节点失败。

Raft协议：etcd使用了Raft协议实现一致性，Raft协议是一种容易理解和实现的一致性协议。读写信息都被存储在此处

WAL\Entry\Snapshot：是etcd执行Raft一致性协议的重要组成部分

WAL（Write-Ahead Logging）：预写日志。etcd使用WAL来记录即将执行但未真正持久化的操作，这些操作包括对键值对的增删改等操作，也包括集群的配置变更等记录。它是在操作真正被执行前，提前将日志写入文件系统，以确保在系统发生宕机或错误时，此些操作日志能够被找回并重新执行。

Entry：etcd使用的Raft一致性协议中，所有即将变更的操作被封装到entry对象中，这些entry包含了要执行的操作以及操作的元信息。在Raft协议的流程中，leader节点将这些entry复制到所有的follower节点上，并等待绝大多数的follower节点确认写入后，再将这些entry标记为committed，然后异步应用到状态机上。

Snapshot：etcd使用snapshot进行日志的压缩和数据的备份，当WAL中的日志过多，或日志中的entry已经被持久化并应用，将不再被需要时，etcd会通过snapshot的方式对日志进行压缩。同时，snapshot也是进行数据备份的一种方式，通过定期创建的snapshot，即可在系统错误或数据丢失时恢复数据。定时总量备份+持续增量备份。

Store：写入本地磁盘进行持久化

gRPC接口：客户端和etcd服务端交互主要通过基于HTTP/2的gRPC协议，以支持多语言的客户端。

watch机制：客户端可以watch一个或多个key，当key发生变化，etcd会将变化通知给客户端。

Multi-Version Concurrency Control（MVCC）：etcd通过MVCC解决并发控制问题，使得读写操作无需锁定。

快照和压缩：etcd定期生成快照，并对键值存储空间进行定期压缩，来保证数据的安全以及服务的性能。

TTL机制：etcd支持设置键值对的生存时间，使得KV数据可以自动过期。

认证和权限控制：etcd还提供了用户认证和按角色的权限控制机制。

etcd还包含一系列的API提供服务，包括key-value存储API，watchAPI，集群管理API，安全认证API等。

2.2、Worker/node/host节点相关组件

1、Pod 容器组

（1）分组

自主式Pod：一旦死亡，不会被拉起

控制器管理的Pod

（2）定义

一个Pod 下可以有多个容器，多个容器共用容器组的ip、主机名等信息，共享容器挂接的Volume。

一个Pod通常运行一个主应用容器。它也可以运行拥有辅助程序的其他容器，这些程序支持主应用程序。例如，某些辅助程序可能会拉取外部数据或文件，或者与其他程序交互以服务于主应用程序。

Pod模拟了一个"物理主机"，在其中，一个或多个应用程序可以在里面一起运行。在物理主机世界中，这些应用程序共享相同的网络和存储资源；在Pod世界中，容器也以同样的方式共享网络和存储资源。

Pod是Kubernetes调度的原子单位。Kubernetes并不会尝试运行容器，运行的单位总是Pod。默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问题并重新启动这个Pod（重启Pod里的所有容器）。

Pod有短暂的生命周期。Pod被创建后，被分配到一个节点上运行，直到进程终止，或者被移除出网络，或者被计划中止。永远不会有任何一个被停止后的Pod重新恢复运行在某个节点上。

一种常见的用例是将Pod视为单个组成部分的实例：一种微服务或者一个应用程序层。这一点和其他一些容器集群解决方案（如Docker Swarm，Apache Mesos）有着不同之处。在这些解决方案中，最小的部署单元是单个容器；而在Kubernetes中，最小的部署单元是Pod，Pod内部可以包含一个或者多个紧密关联的容器。同时，Pod还封装了容器应用运行时环境的网络和存储上下文。

特点：

共享存储：一个Pod内的所有容器都可以访问共同的存储卷。这种存储可以用来存储持久化数据，或者用来在Pod内的不同容器之间共享文件。

共享网络命名空间：一个Pod内的所有容器都有相同的IP地址，可以通过localhost来相互通信。这也使得Pod内的容器可以相互协作来为用户提供一个单体应用的体验。

同步生命周期：Pod内的所有容器启动时都会同时启动，停止时也会同时停止。Pod的生命周期不是由它内部的容器决定的，而是由Kubernetes系统来管理的。

 容器内协同工作：Pod内的容器可以协同工作，提供复杂的服务。比如，一个容器运行主应用，另一个容器可以为主应用提供辅助功能，如日志管理，数据备份等。 

统一管理：Pod是Kubernetes的调度单元，它使用一套规则来决定每个Pod运行在哪个节点上。在调度过程中，会考虑Pod内所有容器的资源需求，以及节点的资源使用情况等因素。

一次性：Pod在创建之后，不能进行迁移。当Pod所在的节点发生故障，或者迁移Pod到另一个节点时，原来的Pod会被销毁，然后在新的节点上创建新的Pod。

同一个Pod既共享网络(pause)，也共享存储卷。

问题1：Pod中的容器可以部署不同的应用么？

在Kubernetes中，一个Pod中的容器是可以部署不同的应用的。然而，应用之间需要有一些共享资源或某种形式的直接通信，这是因为Pod内的容器共享网络命名空间，可以通过localhost进行通信，并且它们可以共享存储卷。

但是在实际使用中，一般会将每个应用单独部署在一个Pod中，而不是将多个不相关的应用部署在同一个Pod中，因为这样更加符合微服务架构的思想，每个微服务都应该是可以独立部署和缩放的。

例如，一种常见的做法是将主应用程序和辅助应用程序（如日志和监控代理）部署在同一Pod中，这样辅助应用程序可以方便地访问和处理主应用程序的数据。

问题2：两个应用之间怎么通过localhost访问

（1）将两个不同的镜像封装在同一个容器内

（2）在同一个主机上运行的两个容器之间，通过共享网络实现

（3）Pod 的控制器

用于管理和维护Pod的生命周期，类型有以下几种：https://blog.csdn.net/qq_59323083/article/details/125838669

1、无状态服务

ReplicationController：这是最早的控制器类型，用于确保系统中任何时间点上指定数量的Pod副本正在运行。它支持基本的扩展和收缩功能。如果有容器异常退出，会创建新的Pod来代替。

ReplicaSet：这是ReplicationController的升级版本，它在selector的匹配方式上更强大，支持集合匹配。命令式编程(create)

Deployment：这是现在最常用的控制器类型，它在ReplicaSet的基础上添加了版本控制和升级策略。使用Deployment控制器，即使在滚动更新过程中出现了错误也可以随时回滚到稳定版本。但是它并不负责pod创建，是通过创建RS达到创建pod。声明式编程(apply)

Horizontal Pod Autoscaling :仅适用于Deployment和ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩容。

2、有状态服务

StatefulSet：这个控制器适用于管理有状态的应用，如数据库。应用场景：

*稳定的持久化存储，即 Pod重新调度后还是能访问到相同的持久化数据，基于PVC 来实现

*稳定的网络标志，即 Pod 重新调度后其PodName和HostName不变，基于Headless Service(即没有ClusterIP的Service或者说 没有ip跟端口的ClusterIP)来实现

*有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基干 init containers 来实现

*有序收缩，有序删除(即从N-1到0)

3、DaemonSet：此控制器类型确保全部（或一些）Node上运行一个Pod的副本（守护进程），通常用于运行一些全局服务，如日志收集，监控等。Pod的副本，只能运行一个，如果有多个服务需要使用，可以将这多个服务部署在一个Pod的多个容器中，或者设置多个不同的DaemonSet。---Prometheus Node Exporter

4、

Job：负责批处理任务，这是一个一次性任务控制器，用于处理短时间内完成的任务。它保证批处理任务的一个或多个Pod成功结束（可以定义job的成功退出次数，达到成功退出次数，Job的生命周期=pod达到成功退出次数后结束）。

CronJob：这是一个定时任务控制器，用于定期执行任务。通过在特定时间循环创建job实现。（在给定时间只运行一次/周期性在给定时间运行）

2、Node                                                                                                                                                                                                     

Node是Kubernetes的工作节点，可以看作是一个物理机或者虚拟机。每个Node都被分配有CIDR（无类别域间路由）范围内的IP地址。Node内部运行着构成Kubernetes运行时环境的基本服务，如Kubelet（与Master通信）、Docker服务（运行容器）、kube-proxy（负载均衡和服务发现）等。Node也具有一定的资源限制，如CPU、内存等。

Node与 Pod区别： 

Pod是 Kubernetes 中的一个抽象概念，是一个或一组容器运行在同一台机器上的集合，这个机器被 Kubernetes 称为 Node。

Node是物理性的部署单位，每个Node内包含了运行Pod所需要的环境和服务。而Pod 是逻辑上的部署单位，用来管理和调度一组特定的容器。

Node负责为Pod提供运行所需的环境，Pod则负责运行其中的一个或多个容器。

3、网络通讯

概念：

子网掩码的作用是指示网络设备或主机如何识别 IP 地址中的网络部分和主机部分。它由一串连续的二进制位组成，与 IP 地址的每一位进行逻辑与（AND）运算，以确定网络地址和主机地址的范围。例如，对于 IP 地址 192.168.1.10 和子网掩码 255.255.255.0，进行逻辑与运算的结果是 192.168.1.0，表示该 IP 地址所在的网络地址是 192.168.1.0。子网掩码的长度决定了网络中可用的 IP 地址数量。较长的子网掩码（如 255.255.255.0）将网络划分为较小的子网，可用的 IP 地址数量较少。较短的子网掩码（如 255.255.0.0）将网络划分为较大的子网，可用的 IP 地址数量较多。

ip地址组成：网络地址和主机地址，地址长度由子网掩码决定，子网掩码中的“1”表示网络地址的位，而“0”表示主机地址的位。例如，假设有两个 IP 地址：192.168.1.10 和 192.168.1.20，子网掩码为 255.255.255.0。在这种情况下，这两个 IP 地址的网络地址部分（192.168.1）是完全相同的，因此它们属于同一网段。

同一个Pod内部通讯，共享网络命名空间(pause)，共享Linux协议栈，使用localhost:端口通讯。

同一主机的不同Pod进行访问，因为在同一个网桥下的不同子网，所以走docker0的网桥。

跨主机不同Pod进行访问，Pod与docker0在同一网段，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通讯只能通过宿主机的物理网卡进行。将Pod的IP跟所在Node的IP关联起来，通过关联，让Pod可以互相访问。通过对方ip直接到达：不是同一网段，Flannel0从etcd中获取路由表记录，Flanneld对地址进行封装，加上主机的源+目的ip地址，使用udp协议转发。 

etcd存储管理Flannel可分配的IP地址段资源；监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表。

Overlay Network(Fannel-网络规划服务：可以让集群中的不同节点主机创建的Docker容器都有全集群唯一的虚拟ip地址，而且还能在这些ip地址之间建立一个覆盖网络- Overlay Network ，通过这个覆盖网络，将数据包原封不动地传递到目标容器内)

Pod 与service之间的通讯：各节点的Iptables规则/ivs。

Pod到外网：查找路由表，转发数据包到宿主机的网卡，宿主机网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主机网卡的IP,然后向外网服务器发送。

外网访问Pod：借助service的NodePort方式。  Internet -- Ingress -- Service --Pod

二、pod/node关系

详见：https://www.jianshu.com/p/b3eaa86ed94d?v=1702538562911

三、Kubernetes YAML文件

四、集群命令安装

详见：https://www.jianshu.com/p/e1d2624c39ba?v=1702451196257

五、k8s资源清单与容器生命周期

详见：https://www.jianshu.com/p/ca91739b9486?v=1705028446930

六、k8s资源控制器

详见：https://www.jianshu.com/p/e0428d28324c?v=1705028479040