网上销售型企业网站,dw网页制作成品12页,南浔区住房和城乡建设局网站,电子商务网站开发需要注意问题参考 Kubernetes 官方文档#xff0c;简要概述 Kubernetes 中的核心组件用途及部分原理。 一个 K8S 集群#xff0c;可以分为两个部分#xff1a;
控制平面(Control Plane)。它是一套管理系统#xff0c;专门来管理集群节点和服务#xff0c;为集群做出全局决策#xff… 参考 Kubernetes 官方文档简要概述 Kubernetes 中的核心组件用途及部分原理。 一个 K8S 集群可以分为两个部分
控制平面(Control Plane)。它是一套管理系统专门来管理集群节点和服务为集群做出全局决策比如资源的调度以及检测和响应集群事件如图左侧所示。 kube-apiserveretcdkube-schedulerkube-controller-manager 工作机器即常规集群节点(Nodes)。运行容器化的应用程序如图右侧所示。 kubeletkubelet-proxy
除了这些核心组件要让一个 K8S 集群正常的运行起来还需要一个容器运行环境来负责运行和管理容器的整个生命周期。K8S 支持许多容器运行环境例如 containerd、CRI-O 以及 K8S CRI 的其它任何实现。 kube-controller-manager 和 kube-scheduler 都是直接调用 kube-apiserver只有 kube-apiserver 会调用到 etcd。
kube-apiserver
API Server 就是一个 https 服务器通过 https 协议请求 API Server 创建资源删除资源查看资源等操作。
负责公开了 Kubernetes API负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。kube-apiserver 设计上考虑了水平扩缩也就是说它可通过部署多个实例来进行扩缩可以运行 kube-apiserver 的多个实例并在这些实例之间平衡流量。
API Server
简单来讲API Server 就是 K8S 集群的 Web 接口服务 K8S 组件之间、插件之间的数据交换都是通过 API Server 来完成。另外所有与 etcd 打交道的事情都要通过 API Server 来完成。
不论是通过命令行还是通过 SDK 编程实现来管理 K8S 集群上的资源对象都需要调用 API Server 提供的接口才可以完成。
网关
为了保证安全的对外暴露还需具有身份认证、鉴权的功能而消息转发的功能是一个 Proxy 接口可以通过代理方式将 API Server 收到的 REST 请求转发到某个 Node 上的 kubelet 上由 kubelet负责响应。
访问 K8S 集群的时候API Server 做统一协调需要经过三个安全步骤 认证。判断用户是否为能够访问集群的合法用户。 匿名认证Anonymous requests白名单认证BasicAuth认证Token认证Webhooks、ServiceAccount Tokens、OpenIDConnect Tokens等X509证书认证clientCA认证TLS bootstrapping等这是 K8S 组件间内部默认使用的认证方式 鉴权。通过鉴权策略决定一个 API 调用是否合法。 Always当集群不需要鉴权时选择AlwaysAllowABAC基于属性的访问控制RBAC基于角色的访问控制是目前 K8S 中最主要的鉴权方式Node一种对 kubelet 进行授权的特殊模式Webhook通过调用外部 REST 服务对用户鉴权 准入控制。一个类似 acl 的列表以插件的形式运行在 API Server 进程中如果列表有请求内容就通过否则不通。在鉴权阶段之后对象被持久化 etcd 之前拦截 API Server 的请求对请求的资源对象执行自定义校验、修改、拒绝等操作。
资源对象管理
API Server 有很多的接口这些接口都是负责对 K8S 资源对象的管理功能像资源的注册和发现。
K8S 资源就是设计系统时的一个数据模型或者定义的一张表的数据。一些常用资源如下
工作负载资源需要使用到服务器的 CPU/内存这些计算资源。最常见到的 Pod、DeploymentService 资源可以把 Pod 内部的应用暴露出去。像 Service、Ingress配置和存储资源定义配置信息存储卷等比如 ConfigMap、Secret身份认证资源定义使用人的账号和访问认证方式等例如 ServiceCount鉴权资源定义哪些角色、身份、主题可以访问和操作集群资源等如 ClusterRoleBinding策略资源以定义服务资源策略网络访问策略等像 LimitRange集群资源定义集群的节点、命名空间等比如 NodeNameSpace扩展资源定义哪些资源可以对外公开哪些可以通过 webhook 来调用等
所有的资源对象都会保存到 etcd 中其它的组件需要查询某些资源可以通过 API Server 提供的查询接口。如果需要实时掌握资源对象的状态变更也可以使用 API Server 的 watch 方法。
API Server 的访问方式
通过 curl 或者浏览器中直接请求 https 接口。使用 kubectl 工具通过 https 协议请求 API Server。使用编程方式比如 K8S 开源的 client-go 项目以及其相关二次开发工具。
K8S 组件怎样利用 API Server 通信
当本机的 pod 状态发生变更时比如新建成功、出现异常、销毁kubelet 组件都要调用 API Server 的接口上报这些数据。同时 kubelet 也需要通过 watch 接口来监听 pod 的变更。kube-controller-manager 中有很多的控制器它们也会使用 watch 接口监听自己关注的资源对象然后做出相应的处理。kube-scheduler 也是要通过 watch 接口监听到新建 pod 的信息后再查询节点列表然后开始执行pod 调度逻辑调度成功将 pod 绑定到目标节点上。K8S 利用缓存来缓解高并发下 API Server 的压力在各个组件本地都有一份缓存数据不需要每次都实时从 API Server 中读取数据。
etcd
etcd 是一种开源的分布式统一键值存储用于分布式系统或计算机集群的共享配置、服务发现和的调度协调。etcd 有助于促进更加安全的自动更新协调向主机调度的工作并帮助设置容器的覆盖网络。
etcd 是 K8S 的首要数据存储也是容器编排的实际标准系统。使用 etcd 云原生应用可以保持更为一致的运行时间而且在个别服务器发生故障时也能正常工作。应用从 etcd 读取数据并写入到其中通过分散配置数据为节点配置提供冗余和弹性。
etcd 的高可用
etcd 集群基于 raft 协议实现数据一致性。 整个 etcd 集群需要奇数个服务器。这些 etcd 服务会自动投票选举将一个 etcd 服务选择为 leader其他则都是follow。leader 节点接收全部的读写请求然后会把写请求广播给所有的 follow 节点。 follow节点对外是只读的如果 leader 节点异常了其他的 follow 节点就要重新开始选举。选举过程如下
每个节点会启动一个随机延时推举自己成为 leader节点拥有最新的数据可以成为 leader得到一票如果多个节点的票数相同它们会再次重复过程 1再来第二轮投票
拥有超过半数的投票就可以成为 leader其他则都变成 follow在选举的过程中etcd 服务不可用。综上通过集群的多节点以及异常时自动恢复来保证高可用性。虽然性能方面不如 Redis但是数据一致性方面优于 MySQL、Redis。
kube-scheduler
kube-scheduler 是 K8S 集群的默认调度器负责监视新创建的、未指定运行节点node的 Pods 并选择节点来让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。
如果没有任何一个节点满足 pod 的资源请求那么这个 pod 将一直停留在未调度状态。找到所有可调度节点之后再根据一系列函数对这些节点打分选出得分最高的节点来运行 pod。调度器将这个调度决定通知给 kube-apiserver。
kube-scheduler工作流程 Scheduler 通过 watch 新建 pod 的事件得到一个新建 pod 的消息之后就开始内部的工作
过滤出满足资源调度需求的所有可调度节点。对这些节点打分把得分最高的节点找出来。选择得分最高的一个节点如果得分最高的节点有多个随机选一个。成功找到调度节点之后就把这个节点信息写入新建 pod 消息中保存到 api-server。
扩展调度器 Scheduler Framework 分为两个阶段左边的是调度周期右边的是绑定周期。调度周期为 pod 选择一个节点绑定周期将该决策应用于集群。
调度周期和绑定周期一起被称为调度上下文。调度周期是串行运行的而绑定周期可以是并行运行。 两个周期里有许多扩展点pod 选择、节点过滤、打分、排名、绑定等。用户可以实现扩展点定义的接口来实现自己的调度逻辑并将扩展注册到扩展点上。
kube-controller-manager
kube-controller-manager 负责运行控制器进程是处理集群中常规任务的后台线程。
节点控制器Node Controller负责在节点出现故障时进行通知和响应比如集群中某个 pod 挂掉了或者将 pod 从某个节点上驱逐了Controller Manager 便会实现 pod 的自动重建。任务控制器Job Controller监测代表一次性任务的 Job 对象然后创建 Pods 来运行这些任务直至完成端点分片控制器EndpointSlice controller填充端点分片EndpointSlice对象以提供 Service 和 Pod 之间的链接。服务账号控制器ServiceAccount controller为新的命名空间创建默认的服务账号ServiceAccount。
K8S 控制平面另外还有一个 cloud-controller-manager 组件是可选的。
kube-controller-manager 是集群内部的管理控制中心由负责不同资源的多个 Controller 构成共同负责集群内的 Node、Pod 等所有资源的管理。几乎每种特定资源都有特定的 Controller 维护管理以保持预期状态而 Controller Manager 的职责便是把所有的 Controller 聚合起来保证集群中各种资源的实际状态status和用户定义的期望状态spec一致。
Controller Manager 主要提供了一个分发事件的能力。在 client-go 中不同的 Controller 只需要注册对应的 Handler 来等待接收和处理事件。Controller 运行起来之后只需要等着事件回调它就行了。
更多细节见 client-go 源码
kubelet
kubelet 是部署在每一个常规集群节点上的核心组件。它保证容器都运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 PodSpecs确保这些 PodSpecs 中描述的容器处于运行状态且健康。它不会管理不是有 k8s 创建的容器。
kubelet 的功能主要包括上报 Node 节点信息、管理 Pod。
kubelet 架构
从网上找了一张 kubelet 架构图的一部分
实际上kubelet 中的组件远远不止图中所展示节点上的资源都交给 kubelet 来管理对于各种不同资源都有对应的管理组件比如podcontainer、image、secret、configmap、certificatevolumeplugin 等资源的管理。
另外还有一些更重要的组件比如
PLEG (Pod Lifecycle Event Generator)维护着 Pod 缓存定期通过容器运行时获取 Pod 的信息与缓存中的信息比较生成相应的事件然后把事件写入到通道中。PodWorkers处理事件中 Pod 的信息同步如果 Pod 正在创建记录器延迟记录 Pod 从 pending 到 running 的耗时杀掉不应该运行的 pod使用VolumeManager 为 Pod 挂载卷等。PodManager存 储Pod 的期望状态。StatsProvider提供节点和容器的统计信息。ContainerRuntime 容器运行时与遵循 CRI 规范的高级容器运行时进行交互。syncLoop接受来自 PodConfig 的 Pod 变更通知、定时任务、PLEG 的事件将 Pod 同步到期望状态。PluginManager运行一组异步循环根据此节点确定哪些插件需要注册、取消注册并执行。
kubelet 工作原理
kubelet 按照控制器模式来工作的。它的核心是一个控制循环即事件和 SyncLoop。事件的来源包括
PodConfig 的更新事件PLEG- Pod 生命周期事件kubelet 本身设置的执行周期如Pod 的健康检测等定时的清理事件。
Woker 接收到相应的事件完成指定的某项具体工作例如
NodeStatusManager 负责响应 Node 状态变化把 Node 的状态收集起来并上报给 ApiServer。CpuManager 负责维护该节点的 CPU 信息能够正确的管理 CPU 的使用量和可用量。
如果此时接收到一个绑定 Pod 事件需要在这个节点上新建一个Pod。kubelet 就会为这个新的 Pod 生成对应的 Pod Status检查 Pod 所声明使用的 Volume 是不是已经准备好。然后调用下层的容器运行时比如 Docker开始创建这个 Pod 所定义的容器。kubelet 调用下层容器运行时的执行过程并不会直接调用 Docker 的 API而是通过一组叫作 CRIContainer RuntimeInterface容器运行时接口的 gRPC 接口来间接执行的。
kube-proxy 集群中每个节点上运行的网络代理。它维护节点上的一些网络规则这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
