Day03 k8s的架构和历史
K8s的架构-重要-理解
K8s中 Master 控制节点的组件
api-server:通俗一些来讲,按照我自己的理解,api-server像是所有的组件的中心点,就是我们必须经过的大门的作用,请求都要经过api-server,它的作用是负责处理来自用户的请求,其主要作用就是对外提供restful的接口
以查看集群状态的读请求以及改变集群状态的写请求,也是唯一一个可以与etcd集群通信的组件。
scheduler:调度器,监控那些新创建没有指定Node的pod,像部门经理把他们按照需求分配到不同的Node上面进行工作,比如打了label的node,调度决策考虑的因素包括单个Pod和Pod集合的资源需求
亲和、反亲和、数据位置、负载……
controller-manager:在主节点上运行的控制器组件,每个控制器都是一个单独的进程,为降低复杂性,就把他们都编译到同一个可执行文件并在一个进程中运行
控制器包括:节点控制器、副本控制器、端点控制器、服务账户和令牌控制器
节点控制器负责节点出现问题故障时候进行通知和响应
副本控制器负责为系统中每个副本控制器对象维护正确数量的Pod
端点控制前负责填充端点endpoint对象,加入svc与pod
服务账户和令牌控制器为新的命名空间创建默认账户和api访问令牌
etcd:是兼具一致性和高可用的键值数据库,可以作为保存k8s 所有集群数据的后台数据库
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
在worker 节点上的组件,主要是kubelet 和kube-proxy
kubelet:是工作节点执行操作的agent,负责具体的容器生命周期管理
从数据库中获取信息来管理容器,上报pod的运行状态等。
kube-proxy:简单的网络访问代理,也是一个Load balancer,负责把访问到某个服务器上的请求具体分配到工作节点上同一类标签的pod,它的本质是操作防火墙规则iptables或者ipvs实现Pod的映射
container runtime:容器运行时,1.24之后不支持docker了,但是可以下载docker-cri
容器运行环境是负责运行容器的软件,k8s支持多个容器运行环境
实现k8s cri的方式-docker,containerd,cri-o,rktlet
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
k8s集群中的高等级架构
网络插件
元件 | 描述 | 主要特点 |
---|---|---|
用于网络的 Calico CNI | Calico CNI 是一个控制平面,用于对多个数据平面进行编程。它是一种 L3/L4 网络解决方案,可保护容器、Kubernetes 集群、虚拟机和基于本机主机的工作负载。 | • 内置数据加密 • 高级 IPAM 管理 • 覆盖和非覆盖网络选项 • 数据平面选择:iptables、eBPF、Windows HNS 或 VPP |
用于网络策略的 Calico 网络策略套件 | Calico 网络策略套件是 Calico CNI 的接口,其中包含数据平面要执行的规则。 Calico 网络策略: • 采用零信任安全模型设计(全部拒绝,仅在需要时允许) • 与 Kubernetes API 服务器集成(因此您仍然可以使用 Kubernetes 网络策略) • 支持使用相同网络策略模型的遗留系统(裸机、非集群主机)。 | • 命名空间和全局策略,用于允许/拒绝集群内、Pod 与外部世界之间以及非集群主机的流量。 • 网络集(任意一组 IP 子网、CIDR 或域),用于限制工作负载的出口和入口流量的 IP 范围。 • 应用层 (L7) 策略,用于使用 HTTP 方法、路径和加密安全身份等属性强制执行流量。 |
除了组件还有一些比较重要的插件
概念补充
CNI:CNI是一个容器网络的标准,它定义了容器运行时如何创建、配置和管理网络。CNI的目标是为不同的容器运行时提供一个通用的网络插件框架,使得它们可以使用不同的网络插件来实现网络功能。
特点:
插件化:CNI采用插件化的设计,允许使用不同的网络插件来满足不同的网络需求。
标准化:CNI规范为容器运行时和网络插件之间提供了一个通用的接口,实现了容器网络配置的标准化。
动态配置:CNI插件可以根据操作类型(如ADD、CHECK、DELETE等)接收相应的网络配置参数,执行网络配置或清理任务,并与容器生命周期保持同步。组成部分:网络插件:负责创建和配置容器的网络接口,以及连接容器到宿主机或其他容器的网络。
IPAM插件:负责为容器分配IP地址和配置网络路由。
示例:目前已有多个开源项目支持以CNI网络插件的形式部署到Kubernetes集群中,如Flannel、Calico、Cilium等。
CRI:CRI是Kubernetes中的一个标准化接口,用于实现容器运行时和Kubernetes的交互。它定义了Kubernetes与底层容器运行时的通信协议和接口规范。
特点:
开放性:CRI提供了开放的、标准化的接口,使得Kubernetes可以与不同的容器运行时进行交互。
解耦性:通过CRI,Kubernetes解耦了容器运行时的实现细节,可以针对不同的运行时实现进行灵活的扩展和定制。
兼容性:各个容器运行时只需要实现CRI接口,就可以与Kubernetes进行无缝集成,提供各种容器运行时功能。
功能:
CRI负责管理容器的生命周期,包括创建、启动、停止、销毁等操作。它允许Kubernetes支持多种不同的容器运行时,如Docker、containerd、CRI-O等。
实现原理:
CRI的原理是通过gRPC协议实现Kubernetes与容器运行时的通信。Kubernetes将CRI定义的接口规范封装成Protocol Buffers格式的消息,通过gRPC进行序列化和反序列化,在Kubernetes master节点和worker节点之间进行通信。
总结:
CNI和CRI是Kubernetes中两个不同的组件,分别用于管理容器的网络设置和运行时环境。CNI负责为Pod提供网络连接,而CRI负责管理容器的生命周期。两者协同工作,为Kubernetes提供了完整的容器管理能力。
OCI:OCI(Open Container Initiative)是一个轻量级的、开放的治理结构,旨在推进跨平台容器格式的标准化。OCI 成立于 2015 年,由 Docker、CoreOS 和其他几家容器技术公司共同发起,旨在解决容器运行时和镜像格式的碎片化问题。
OCI 的主要目标是定义两个规范:
运行时规范(Runtime Specification):这个规范描述了容器应该如何在任何符合 OCI 规范的运行时中执行。它定义了容器的配置、生命周期、文件系统、进程、网络、钩子(hooks)以及其他低级操作系统交互。这允许容器可以在任何符合 OCI 运行时规范的平台上运行,而不必担心底层操作系统的差异。
镜像规范(Image Specification):这个规范定义了容器镜像的格式和内容。它描述了如何打包应用程序及其依赖项,以便它们可以在任何符合 OCI 镜像规范的平台上运行。OCI 镜像规范基于现有的标准(如 tar 和 JSON),确保容器镜像可以在各种系统和分发渠道之间轻松传输和共享。
OCI 运行时规范和镜像规范为容器生态系统中的不同组件(如容器运行时、镜像构建工具、容器编排系统等)提供了标准化的接口和格式。这使得开发人员可以更容易地在不同的平台和环境之间迁移容器化应用程序,同时也促进了容器技术的创新和发展。
一些符合 OCI 规范的开源项目包括:
runc:一个轻量级的、符合 OCI 运行时规范的容器运行时。它允许您使用 OCI 容器配置运行容器。
containerd:一个高性能、可扩展的容器运行时,它符合 OCI 运行时和镜像规范,并支持多种容器镜像格式。containerd 是 Kubernetes 和 Docker 等项目的核心组件之一。
BuildKit:一个可扩展、模块化的构建工具,用于创建符合 OCI 镜像规范的容器镜像。BuildKit 是 Docker 和 BuildKit 项目的一部分。
OCI 的成立和这些标准化的规范使得容器技术更加开放和可移植,促进了容器生态系统的健康发展。
OSI:OSI(Open Systems Interconnection)是一个由国际标准化组织(ISO)提出的网络体系结构模型。它不是一个实际的网络协议,而是一组网络协议设计标准的集合,用于描述网络系统中的不同层次和组件之间的通信方式。OSI 模型将网络通信划分为七个层次,从底层到顶层依次是:物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。
以下是OSI模型中各层的主要功能和特点:
物理层(Physical Layer):
定义了传输数据的物理介质(如光缆、双绞线等)的特性、连接器和接口标准。
负责处理比特流(bit stream)的传输,不关心传输的内容。
数据链路层(Data Link Layer):
负责将数据封装成帧(frame),并在发送端和接收端之间建立、维持和释放数据链路。
提供了流量控制、差错控制、帧同步等功能。
常见的协议有以太网(Ethernet)、PPP(Point-to-Point Protocol)等。
网络层(Network Layer):
负责将数据包(packet)从源地址路由到目标地址。
提供了路由选择、拥塞控制、分组转发等功能。
常见的协议有IP(Internet Protocol)、ICMP(Internet Control Message Protocol)等。
传输层(Transport Layer):
负责提供端到端(end-to-end)的数据传输服务。
提供了可靠的(如TCP)或不可靠的(如UDP)的数据传输机制。
实现了流量控制、差错控制、分段和重组等功能。
会话层(Session Layer):
负责建立、管理和终止会话(session),包括同步不同设备上的应用程序之间的对话。
提供了对话控制、令牌管理、同步等功能。
表示层(Presentation Layer):
负责数据的表示和转换,以确保应用层能够理解和处理数据。
提供了数据压缩、加密、解密、字符编码转换等功能。
应用层(Application Layer):
提供了网络应用的服务接口,如文件传输、电子邮件、远程登录等。
常见的协议有HTTP(Hypertext Transfer Protocol)、FTP(File Transfer Protocol)、SMTP(Simple Mail Transfer Protocol)等。
OSI模型为理解和设计网络系统提供了一个概念框架,虽然在实际应用中,许多网络协议和系统并不完全符合OSI模型的所有层次,但OSI模型仍然是网络设计和通信协议开发的重要参考。
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.