Kubernetes 集群
架构
一个有效的 Kubernetes 部署称为集群,可以将 Kubernetes 集群分为两个部分:
**控制平面与计算设备(或称为节点)**
控制组件
控制平面
K8s 集群的神经中枢,负责处理重要的工作,以确保容器以足够的数量和所需的资源运行。
- kube-apiserver
为 REST 操作提供服务,并为集群的共享状态提供前端。
- kube-scheduler
- K8s 调度程序
- 考虑容器集的资源需求以及集群的运行状况,负责将 Pods 指派到节点上
- kube-controller-manager
是一个控制回路,通过 API 服务器监视集群的共享状态
K8s 控制器,用于查询调度程序,并确保有正确数量的容器集在运行。
- etcd
配置数据以及有关集群状态的信息位于 etcd。
节点(Node)
- Kubernetes 通过将容器放入在节点(Node)上运行的 Pod 中来执行你的工作负载。
- 节点可以是一个虚拟机或者物理机器,取决于所在的集群配置
- 每个节点都运行由若干容器组成的容器集
- Pod
- 是K8s中创建和管理的、最小的可部署的计算单元。是一组(一个或多个)容器。
- 网络
- 每一个Pod都会被指派一个唯一的Ip地址,在Pod中的每一个容器共享网络命名空间,包括Ip地址和网络端口
- 在同一个Pod中的容器可以同locahost进行互相通信,当Pod中的容器需要与Pod外的实体进行通信时,则需要通过端口等共享的网络资源。
- 存储
- Pod能够配置共享存储卷,在Pod中所有的容器能够访问共享存储卷,允许这些容器共享数据
- 存储卷也允许在一个Pod持久化数据,以防止其中的容器需要被重启。
- 自主式Pod
- 本身是不能自我修复的,当Pod被创建后,会被K8s调度到集群的Node上,直到Pod的进程终止
- 控制器管理的Pod
- Controller可以创建和管理多个Pod,提供副本管理、滚动升级和集群级别的自愈能力
- 容器运行时引擎
为了运行容器,每个计算节点都有一个容器运行时引擎。
- kube-proxy
- 用于优化 Kubernetes 网络服务的网络代理
- 负责处理集群内部或外部的网络通信——靠操作系统的数据包过滤层,或者自行转发流量
- kubelet
- 一个与控制平面通信的微型应用
- 可确保容器在容器集内运行,当控制平面需要在节点中执行某个操作时,kubelet 就会执行该操作
存储组件
- 持久化存储
- k8s允许用户请求存储资源,而无需了解底层存储基础架构的详细信息
- 持久卷是集群(而非容器集)所特有的,因此其寿命可以超过容器集
- 容器镜像仓库
- K8s 所依赖的容器镜像存储于容器镜像仓库中
- 可以自己配置,也可以由第三方提供
工作负载管理
ReplicaSet
- 是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合
- 每个 ReplicaSet 通过创建和删除 Pod 使得副本个数达到期望值,进而实现其存在价值
Deployment
- 为 Pod 和 ReplicaSet 提供声明式的更新能力
- 以受控速率更改实际状态, 使其变为期望状态
-
事件和状态查看:可以查看Deployment对象升级的详细进度和状态
-
回滚:升级操作完成后发现问题时,支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上
-
版本记录:对Deployment对象的每一个操作都予以保存,以供后续可能执行的回滚操作使用
-
暂停和启动:对于每一次升级,都能够随时暂停和启动
-
多种自动更新方案:
- Recreate:即重建更新机制,全面停止、删除旧有的Pod后用新版本替代
- RollingUpdate:即滚动升级机制,逐步替换旧有的Pod至新的版本
StatefulSet
- 用来管理 "有状态应用" 的工作负载 API 对象
- 用来管理某 Pod 集合的部署和扩缩, 并为这些 Pod 提供持久存储和持久标识符
- 为它们的每个 Pod 维护了一个有粘性的 ID
- 特点:
- 唯一的网络标识符
- 有序的部署和扩缩
DaemonSet
- 确保全部(或者某些)节点上运行一个 Pod 的副本
- 当有节点加入集群时, 也会为他们新增一个 Pod
- 当有节点从集群移除时,这些 Pod 也会被回收
- 删除 DaemonSet 将会删除它创建的所有 Pod
- 用途:
- 在每个节点上运行集群守护进程
- 在每个节点上运行日志收集守护进程
- 在每个节点上运行监控守护进程
Job
- 会创建一个或者多个 Pod,并将继续重试 Pod 的执行,直到指定数量的 Pod 成功终止
- 一次性任务
- 流程:
- 随着 Pod 成功结束,Job 跟踪记录成功完成的 Pod 个数
- 删除 Job 的操作会清除所创建的全部 Pod
- 挂起 Job 的操作会删除 Job 的所有活跃 Pod,直到 Job 被再次恢复执行
CronJob
- 创建基于时隔重复调度的 Job
- 用 Cron 格式进行编写
- 定时执行一次性任务
ReplicationController
- 确保在任何时候都有特定数量的 Pod 副本处于运行状态
- 当 Pod 数量过多时,ReplicationController 会终止多余的 Pod
- 当 Pod 数量太少时,ReplicationController 将会启动新的 Pod
Service
- 将运行在一组 Pod 上的网络应用程序公开为网络服务的方法
- Service 有自己 IP,这个 IP 是固定不变的
- 客户端只需要访问 Service 的 IP,Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系
-
公开级别:
-
Clusterlp:默认类型,自动分配一个仅 Cluster 内部可以访问的虚拟 IP
-
NodePort:在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口,可以通过 “:NodePort” 来访问该服务
-
LoadBalancer:在 NodePort 的基础上,借助 cloud provider 创建一个外部负载均衡器,并将请求转发到:NodePort
-
ExternalName:把集群外部的服务引入到集群内部来,在集群内部直接使用
-
配置Port:
- port:service的的端口
- targetport:pod的端口
- nodeport:容器所在宿主机的端口
Gateway API
- 通过使用可扩展的、角色导向的、协议感知的配置机制来提供网络服务
- 它是一个附加组件,包含可提供动态基础设施配置和高级流量路由的 API 类别
-
GatewayClass: 定义一组具有配置相同的网关,由实现该类的控制器管理
-
Gateway: 定义流量处理基础设施(例如云负载均衡器)的一个实例
-
HTTPRoute: 定义特定于 HTTP 的规则,用于将流量从网关监听器映射到后端网络端点的表
将 HTTP 流量路由到服务
- 简单示例
- 客户端开始准备 URL 为 http://www.example.com 的 HTTP 请求
- 客户端的 DNS 解析器查询目标名称并了解与 Gateway 关联的一个或多个 IP 地址的映射
- 客户端向 Gateway IP 地址发送请求;反向代理接收 HTTP 请求并使用 Host: 标头来匹配基于 Gateway 和附加的 HTTPRoute 所获得的配置
- 可选的,反向代理可以根据 HTTPRoute 的匹配规则进行请求头和(或)路径匹配
- 可选地,反向代理可以修改请求;例如,根据 HTTPRoute 的过滤规则添加或删除标头
- 最后,反向代理将请求转发到一个或多个后端