Day03 k8s的架构和历史

K8s的架构-重要-理解

关于K8s,重点在于理解其作用,架构
很多监控,插件都是在k8s之外的东西
首先要理解,明白k8s的架构,才能更好的去理解如何使用k8s
 k8s是工具,也是一个调度框架。
  • 1.
  • 2.
  • 3.
  • 4.

Day03 k8s的理论、历史_ico

Day03 k8s的理论、历史_OSI_02

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.
api-server 如何处理用户的访问请求?
用户访问-> api接受到请求->转发给api-server-> 查看service 以及 endpoint 确定用户要访问的服务Pod->打开代理端口,设置规则-> 用户访问重定向到随机的代理端口->代理将请求转发给labels为用户请求相同的Pod
  • 1.
  • 2.

Day03 k8s的理论、历史_Pod_03

Day03 k8s的理论、历史_ico_04

scheduling actuator 属于是api 内部调度
scheduler 外部调度
authentication authorization 身份令牌认证
  • 1.
  • 2.
  • 3.

k8s集群中的高等级架构

Day03 k8s的理论、历史_Pod_05

高等级架构图中的关系就更加清晰,node节点的资源池之间分层也十分明晰
硬件-系统-容器运行时-KubeLet-网络
  • 1.
  • 2.

网络插件

1、calico
Calico 包括用于保护网络通信的**网络**,以及用于大规模保护云原生微服务/应用程序的高级**网络策略**。
  • 1.
  • 2.
元件描述主要特点
用于网络的 Calico CNICalico CNI 是一个控制平面,用于对多个数据平面进行编程。它是一种 L3/L4 网络解决方案,可保护容器、Kubernetes 集群、虚拟机和基于本机主机的工作负载。• 内置数据加密 • 高级 IPAM 管理 • 覆盖和非覆盖网络选项 • 数据平面选择:iptables、eBPF、Windows HNS 或 VPP
用于网络策略的 Calico 网络策略套件Calico 网络策略套件是 Calico CNI 的接口,其中包含数据平面要执行的规则。 Calico 网络策略: • 采用零信任安全模型设计(全部拒绝,仅在需要时允许) • 与 Kubernetes API 服务器集成(因此您仍然可以使用 Kubernetes 网络策略) • 支持使用相同网络策略模型的遗留系统(裸机、非集群主机)。命名空间全局策略,用于允许/拒绝集群内、Pod 与外部世界之间以及非集群主机的流量。 • 网络集(任意一组 IP 子网、CIDR 或域),用于限制工作负载的出口和入口流量的 IP 范围。 • 应用层 (L7) 策略,用于使用 HTTP 方法、路径和加密安全身份等属性强制执行流量。
2、flannel
flannel是CoreOS提供用于解决Dokcer集群跨主机通讯的覆盖网络工具。它的主要思路是:预先留出一个网段,每个主机使用其中一部分,然后每个容器被分配不同的ip;让所有的容器认为大家在同一个直连的网络,底层通过UDP/VxLAN等进行报文的封装和转发。
  • 1.
  • 2.

Day03 k8s的理论、历史_OSI_06

3、cilium 较难一些,但是学好了是非常好用的插件,后面有专门的学习
Cilium 是用于透明保护网络的开源软件 使用 Linux 容器部署的应用程序服务之间的连接 Docker 和 Kubernetes 等管理平台。
Cilium 的基础是一种新的 Linux 内核技术,称为 eBPF,它 支持动态插入强大的安全可见性和控制逻辑 在 Linux 本身中。因为 eBPF 运行在 Linux 内核内部,所以 Cilium 可以应用和更新安全策略,而无需对 应用程序代码或容器配置。
  • 1.
  • 2.
  • 3.

Day03 k8s的理论、历史_Pod_07

除了组件还有一些比较重要的插件

coreDns:为集群中的svc创建一个域名Ip的对应解析关系的dns服务
Dashboard:提供一个B/S架构的访问入口
Ingress Controller:七层代理实现
Prometheus:提供k8s集群资源监控,一般和grafana集成使用
Federation:提供可以跨集群中心多k8s统一管理的功能,提供跨可用区的集群
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.

概念补充

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.
如何冲浪
1、上楼梯
2、还有一些镜像源可用
3、武当梯云纵
  • 1.
  • 2.
  • 3.

Velero - K8s 备份工具

velero 是云原生时代的灾难恢复和迁移工具,采用go语言编写
可以安全备份、迁移、恢复k8s集群资源和持久卷等资源的备份恢复软件
可以做到快速恢复k8s集群资源到生产环境、测试环境
支持多种存储资源:AWS S3、Azure Blob、Google Cloud Stora
Alibaba Cloud OSS
版本支持情况如下
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.

Day03 k8s的理论、历史_ico_08

velero 分为服务端和客户端,服务端运行在k8s集群中
客户端运行在本地的命令行工具中,需要已配置好Kubectl 及集群kubeconfig的机器上

备份流程: 客户端调用k8s api server 创建Backup任务
 Backup控制器基于watch机器通过api server 获取到备份任务
 Backup控制器开始执行备份动作,会通过请求api server获取到需求备份的数据
 Backup控制器将获取到的数据备份到指定的对象存储server端
 
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.

k8s的容器运行时在哪里查看?

cd /opt/kubernetes/cfg
下的bootstrap.kubeconfig kubelet.kubeconfig 是API server下发的时候自动生成的
kubelet.conf中可以查看到我们的容器运行时
调度底层的文件是会涉及到kubelet.conf  kubelet-config.yml
  • 1.
  • 2.
  • 3.
  • 4.

Day03 k8s的理论、历史_ico_09

在/var/run里面可以看到cri-dockerd.sock,也就是容器运行时



在k8s部署好kube-dns后
kube-dns.kube-system.svc.cluster.local

k8s默认的最大Pod数量是110个,正常是达不到的
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.

Day03 k8s的理论、历史_OSI_10