提供在 etcd 中存储对象的一致方式。 执行这些对象的验证,以便客户端无法存储配置不正确的对象,如果它们直接写入 etcd 数据存储区可能会发生这种情况。 提供 RESTful API 来创建、更新、修改或删除资源。 提供乐观并发锁定,因此在并发更新的情况下,对对象的更改永远不会被其他客户端覆盖。 对客户端发送的请求执行身份验证和授权。它使用插件提取客户端的用户名、用户 ID 和用户所属的组,并确定经过身份验证的用户是否可以对请求的资源执行请求的操作。 如果请求试图创建、修改或删除资源,则执行准入控制 [2]。示例:AlwaysPullImages、DefaultStorageClass、ResourceQuota 等。 为客户端实现监视机制(类似于 etcd)以监视更改。这允许调度程序和 Controller Manager 等组件以松散耦合的方式与 API Server 交互。
Replication Manager(ReplicationController 资源的控制器) ReplicaSet、DaemonSet 和 Job 控制器 Deployment 控制器 StatefulSet 控制器 node 控制器 service 控制器 endpoints 控制器 namespace 控制器 PersistentVolume 控制器
过滤所有节点的列表以获取 pod 可以调度到的可接受节点列表。(例如,PodFitsResources 过滤器检查候选节点是否有足够的可用资源来满足 Pod 的特定资源请求) 对从第 1 步获得的节点列表进行评分并对它们进行排名以选择最佳节点。如果多个节点得分最高,则使用循环法确保 pod 均匀地部署在所有节点上。
Pod 对硬件 / 软件资源的请求?节点是否报告内存或磁盘压力情况? 该节点是否具有与 pod 规范中的节点选择器匹配的标签? 如果 pod 请求绑定到特定的主机端口,该端口是否已在该节点上占用? pod 是否容忍节点的污点? pod 是否指定节点亲和性或反亲和性规则?等。
通过在 API Server 中创建节点资源来注册它正在运行的节点。 持续监控 API Server 上已调度到节点的 Pod。 使用配置的容器运行时启动 pod 的容器。 持续监控正在运行的容器并将其状态、事件和资源消耗报告给 API Server。 运行容器活性探测,在探测失败时重新启动容器,在容器的 Pod 从 API Server 中删除时终止容器,并通知服务器 Pod 已终止。
创建服务时,会立即分配一个虚拟 IP 地址。 API Server 通知在工作节点上运行的 kube-proxy 代理已经创建了新服务。 每个 kube-proxy 通过设置 iptables 规则使服务可寻址,确保拦截每个服务 IP / 端口对,并将目标地址修改为支持服务的 pod 之一。 监视 API Server 对服务或其端点对象的更改。
如果本地不可用,则从镜像注册表中拉取容器所需的容器镜像。 将镜像提取到写入时复制文件系统,所有容器层相互重叠以创建合并文件系统。 准备容器挂载点 从容器镜像设置元数据,例如覆盖 CMD、来自用户输入的 ENTRYPOINT、设置 SECCOMP 规则等,以确保容器按预期运行。 更改内核以向该容器分配某种隔离,例如进程、网络和文件系统。 提醒内核分配一些资源限制,如 CPU 或内存限制。 将系统调用(syscall)传递给内核以启动容器。 确保 SElinux/AppArmor 设置正确。
参考资料
[2] 准入控制: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
[3] 级联删除垃圾回收: https://kubernetes.io/docs/concepts/architecture/garbage-collection/
作者:SanSan-33
来源:OSC DevOps 社区
链接:https://my.oschina.net/u/4518151/blog/5518666
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...