Day03 k8s的架构和历史
K8s的架构-重要-理解
登录后复制
说到K8，了解它的作用和架构很重要
许多监控和插件都是k8s 外部的。
首先，在我们更好的理解如何使用k8s之前，我们需要了解和理解k8s的架构。
k8s是一个工具和调度框架。
1.2.3.4。
登录后复制
K8s主控节点组件
api-server: 通俗地说，我自己的理解是API服务器就像是所有组件的中心点，所有的请求都要经过它，它的作用就是处理传入的请求。用户请求的主要作用是向外界提供一个安静的接口。
这是唯一可以与etcd 集群进行通信的组件，以获取用于查看集群状态的读请求和用于更改集群状态的写请求。
Scheduler：调度器监控新创建的没有指定节点的Pod。与部门经理类似，调度决策时考虑的因素包括标记节点并将其分配给不同的节点进行工作。要求
亲和性、反亲和性、数据位置、有效负载……
Controller Manager：运行在主节点上的控制器组件。为了降低复杂性，控制器被编译成相同的可执行文件并在一个进程中运行。
控制器包括节点控制器、副本控制器、端点控制器、服务帐户和令牌控制器。
节点控制器负责在节点出现问题或故障时进行通知和响应。
副本控制器负责为系统中的每个副本控制器对象维护正确的pod 数量。
在端点控制之前输入端点对象并添加SVC和Pod。
服务帐户和令牌控制器为新命名空间创建默认帐户和API 访问令牌。
etcd：一致且高可用的键值数据库，可以作为后端数据库来存储所有k8s集群数据。
1.2.3.4.5.6.7.8.9.10.11.12.13。
登录后复制
工作节点上的主要组件是kubelet 和kube-proxy
kubelet：在工作节点上执行操作的代理，负责特定容器的生命周期管理。
您可以从数据库检索信息来管理容器并报告Pod 执行状态。
kube-proxy：也是一个简单的网络访问代理，负责将对特定服务器的请求分配给工作节点上具有相同标签的Pod。其本质是与防火墙规则iptables 或ipvs 配合使用。实施Pod 映射。
容器运行时：容器运行时docker在1.24之后不再支持，但是可以下载docker-cri。
容器运行环境是运行容器的软件。 K8s支持多种容器执行环境。
如何实现k8s cri-docker、containerd、cri-o、rktlet
1.2.3.4.5.6.7。
登录后复制
API Server如何处理用户的访问请求？
用户访问- API 接收请求- 转发到API 服务器- 查看服务和端点并决定用户想要访问哪个服务Pod – 打开代理端口并设置规则- 用户访问将被重定向到随机代理端口- 当用户请求时同一个pod，proxy会将请求转发给label。
1.2.
登录后复制
调度执行器属于API内部调度
Scheduler外部调度
身份验证授权ID Token 身份验证
1.2.3.
k8s集群中的高等级架构
登录后复制
高层架构图中的关系更加清晰，节点资源池之间的分层也更加清晰。
硬件-系统-容器运行时-KubeLet-网络
1.2.
网络插件
登录后复制
1.印花布
Calico 包括用于保护网络通信的**网络**和用于大规模保护云原生微服务/应用程序的高级**网络策略**。
1.2.
组件描述主要功能Calico CNIC for Networks Calico CNI 是用于对多个数据平面进行编程的控制平面。它是一种L3/L4 网络解决方案，可保护容器、Kubernetes 集群、虚拟机和基于本机主机的工作负载。 • 内置数据加密• 高级IPAM 管理• 覆盖和非覆盖网络选项• 数据平面选择：用于iptables、eBPF、Windows HNS 或VPP 网络策略的Calico 网络策略套件Calico 网络策略套件提供对Calico CNI 的支持它是一个接口。数据平面应用的规则。 Calico 网络策略： • 采用零信任安全模型设计（拒绝一切，仅在必要时允许） • 与Kubernetes API 服务器集成（以便您可以继续使用Kubernetes 网络策略） • 支持旧系统（裸机、集群）主机）。 • 命名空间和全局策略，用于允许/拒绝集群内、Pod 与外部世界之间以及集群外主机之间的流量。 • 限制工作负载出站和入站流量的IP 范围的一组网络（任意一组IP 子网、CIDR 或域）。 • 应用层(L7) 策略，使用HTTP 方法、路径和加密安全ID 等属性强制流量。
登录后复制
2.法兰绒
flannel是CoreOS提供的覆盖网络工具，用于解决Dokcer集群中的跨主机通信。主要思想是提前预留一个网段，每个主机使用其中的一部分，并且每个容器被分配不同的IP，使得所有容器都认为它们在同一个直连网络上，而下层是使用UDP。 /VxLAN 等封装并转发消息。
1.2.
登录后复制
3. Cilium是一个很难的插件，但是一旦你学会了它，它就非常容易使用。后面还会有专门的学习。
Cilium 是开源软件，用于透明地保护在Docker 和Kubernetes 等管理平台上使用Linux 容器部署的应用程序服务之间的网络连接。
Cilium 的基础是一种名为eBPF 的新Linux 内核技术。这允许将强大的安全可见性和控制逻辑动态注入Linux 本身。由于eBPF 在Linux 内核中运行，因此Cilium 可以应用和更新安全策略，而无需应用程序代码或容器配置。
1.2.3.
除了组件还有一些比较重要的插件
登录后复制
coreDns：创建集群中svc的域名IP对应的DNS服务。
Dashboard：提供访问B/S架构的入口点。
Ingress控制器：7层代理实现
Prometheus：提供k8s集群资源的监控，通常与grafana集成。
Federation：提供跨集群中心集中管理多个K8、跨可用区服务集群的能力。
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 定义的接口规范封装成协议缓冲区格式的消息，通过gRPC 进行序列化和反序列化，从而在Kubernetes 主节点和工作节点之间进行通信。
概括：
CNI 和CRI 是Kubernetes 的两个不同组件，分别用于管理容器网络设置和运行时环境。 CNI 负责为Pod 提供网络连接，CRI 负责管理容器的生命周期。两者共同为Kubernetes 提供完整的容器管理能力。
OCI：OCI（开放容器倡议）是一个轻量级的开放治理结构，旨在促进跨平台容器格式的标准化。 OCI 由Docker、CoreOS 和其他几家容器技术公司于2015 年创立，旨在解决容器运行时和镜像格式中的碎片问题。
OCI 的主要目的是定义两个规范：
运行时规范：该规范描述了容器应如何在符合OCI 的运行时中运行。它定义了容器的配置、生命周期、文件系统、进程、网络、挂钩和其他低级操作系统交互。这使得容器可以在任何符合OCI 运行时规范的平台上运行，而无需担心底层操作系统的差异。
镜像规范：该规范定义了容器镜像的格式和内容。描述如何打包应用程序及其依赖项，以便其可以在符合OCI 映像规范的任何平台上运行。 OCI 镜像规范基于tar 和JSON 等现有标准，可以轻松跨不同系统和分发渠道传输和共享容器镜像。
OCI运行时和镜像规范为容器生态系统中的各种组件（例如容器运行时、镜像构建工具和容器编排系统）提供了标准化的接口和格式。这使得开发人员可以更轻松地跨不同平台和环境迁移容器化应用程序，同时也加速了容器技术的创新和发展。
符合OCI 规范的开源项目包括：
runc：符合OCI 运行时规范的轻量级容器运行时。这允许您使用OCI 容器配置运行容器。
containerd：高性能、可扩展的容器运行时，符合OCI运行时和镜像规范，支持多种容器镜像格式。 Containerd 是Kubernetes 和Docker 等项目的核心组件之一。
BuildKit：一种可扩展的模块化构建工具，用于创建符合OCI 镜像规范的容器镜像。 BuildKit 是Docker 和BuildKit 项目的一部分。
OCI以及这些标准的建立将使容器技术更加开放和可移植，促进容器生态系统的健康发展。
OSI：开放系统互连（OSI）是国际标准化组织（ISO）提出的一种网络体系结构模型。它不是实际的网络协议，而是描述网络系统内各个层和组件如何通信的网络协议设计标准的集合。 OSI模型将网络通信分为七层，从底层开始：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。
OSI模型各层的主要功能和特点是：
物理层：
定义了传输数据的物理介质（光缆、双绞线等）的特性、连接器和接口标准。
它负责处理比特流的传输，并不关心传输的内容。
数据链路层：
负责将数据封装成帧并建立、维护和释放发送者和接收者之间的数据链路。
提供流量控制、错误控制、帧同步等功能。
常见的协议包括以太网、PPP（点对点协议）等。
网络层：
它负责将数据包从源地址路由到目标地址。
它提供路由选择、拥塞控制、报文转发等功能。
常见协议包括IP（互联网协议）、ICMP（互联网控制消息协议）等。
传输层：
负责提供端到端的数据传输服务。
提供可靠（如TCP）或不可靠（如UDP）的数据传输机制。
实现流控制、错误控制、分段和重组等功能。
会话层：
负责建立、管理和终止会话，包括同步不同设备上的应用程序之间的对话。
提供会话控制、令牌管理和同步等功能。
表示层：
它负责表示和转换数据，以便应用层能够理解和处理它。
它提供数据压缩、加密、解密、字符编码转换等功能。
应用层：
为文件传输、电子邮件、远程登录等网络应用提供服务接口。
常见的协议包括HTTP（超文本传输协议）、FTP（文件传输协议）和SMTP（简单邮件传输协议）。
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.4 4.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
阿里云OSS
兼容版本如下
1.2.3.4.5.6。
登录后复制
Velero分为服务器和客户端，服务器运行在k8s集群内。
客户端使用本地命令行工具运行，并且必须在具有Kubectl 和集群kubeconfig 的计算机上进行配置。
备份流程：客户端调用k8s API服务器创建备份任务
备份控制器通过基于手表机的API服务器检索备份任务。
备份控制器开始执行备份操作并向API服务器发出请求以检索需要备份的数据。
备份控制器将检索到的数据备份到指定的对象存储服务器。
1.2.3.4.5.6.7.8。
k8s的容器运行时在哪里查看？
登录后复制
cd /opt/kubernetes/cfg
下面的bootstrap.kubeconfig 和kubelet.kubeconfig 是在API 服务器提供服务时自动生成的。
您可以在kubelet.conf 中找到容器运行时。
底层文件调度涉及kubelet.conf kubelet-config.yml。
1.2.3.4。
登录后复制
您可以在/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理论和历史的相关内容来源仅供参考。相关信息请参见官方公告。
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/92939.html
