关于kubernetes:K8S相关

1次阅读

共计 3775 个字符,预计需要花费 10 分钟才能阅读完成。

k8s 的组件有哪些,作用别离是什么

k8s 次要由 master 节点和 node 节点形成。master 节点负责管理集群,node 节点是容器利用真正运行的中央。
master 节点蕴含的组件有:kube-api-server、kube-controller-manager、kube-scheduler、etcd。
node 节点蕴含的组件有:kubelet、kube-proxy、container-runtime。

kube-api-server:以下简称 api-server,api-server 是 k8s 最重要的外围组件之一,它是 k8s 集群治理的对立拜访入口,提供了 RESTful API 接口, 实现了认证、受权和准入管制等平安性能;api-server 还是其余组件之间的数据交互和通信的枢纽,其余组件彼此之间并不会间接通信,其余组件对资源对象的增、删、改、查和监听操作都是交由 api-server 解决后,api-server 再提交给 etcd 数据库做长久化存储,只有 api-server 能力间接操作 etcd 数据库,其余组件都不能间接操作 etcd 数据库,其余组件都是通过 api-server 间接的读取,写入数据到 etcd。

kube-controller-manager:以下简称 controller-manager,controller-manager 是 k8s 中各种控制器的的管理者,是 k8s 集群外部的治理控制中心,也是 k8s 自动化性能的外围;controller-manager 外部蕴含 replication controller、node controller、deployment controller、endpoint controller 等各种资源对象的控制器,每种控制器都负责一种特定资源的管制流程,而 controller-manager 正是这些 controller 的外围管理者。

kube-scheduler:以下简称 scheduler,scheduler 负责集群资源调度,其作用是将待调度的 pod 通过一系列简单的调度算法计算出最合适的 node 节点,而后将 pod 绑定到指标节点上。shceduler 会依据 pod 的信息,全副节点信息列表,过滤掉不符合要求的节点,过滤出一批候选节点,而后给候选节点打分,选分最高的就是最佳节点,scheduler 就会把指标 pod 安置到该节点。

Etcd:etcd 是一个分布式的键值对存储数据库,次要是用于保留 k8s 集群状态数据,比方,pod,service 等资源对象的信息;etcd 能够是单个也能够有多个,多个就是 etcd 数据库集群,etcd 通常部署奇数个实例,在大规模集群中,etcd 有 5 个或 7 个节点就足够了;另外阐明一点,etcd 实质上能够不与 master 节点部署在一起,只有 master 节点能通过网络连接 etcd 数据库即可。

kubelet:每个 node 节点上都有一个 kubelet 服务过程,kubelet 作为连贯 master 和各 node 之间的桥梁,负责保护 pod 和容器的生命周期,当监听到 master 下发到本节点的工作时,比方创立、更新、终止 pod 等工作,kubelet 即通过管制 docker 来创立、更新、销毁容器;
每个 kubelet 过程都会在 api-server 上注册本节点本身的信息,用于定期向 master 汇报本节点资源的应用状况。

kube-proxy:kube-proxy 运行在 node 节点上,在 Node 节点上实现 Pod 网络代理,保护网络规定和四层负载平衡工作,kube-proxy 会监听 api-server 中从而获取 service 和 endpoint 的变动状况,创立并保护路由规定以提供服务 IP 和负载平衡性能。简略了解此过程是 Service 的通明代理兼负载均衡器,其外围性能是将到某个 Service 的拜访申请转发到后端的多个 Pod 实例上。

container-runtime:容器运行时环境,即运行容器所须要的一系列程序,目前 k8s 反对的容器运行时有很多,如 docker、rkt 或其余,比拟受欢迎的是 docker,然而新版的 k8s 曾经发表弃用 docker。

kubelet 的性能、作用是什么?(重点,常常会问)

答:kubelet 部署在每个 node 节点上的,它次要有 2 个性能:
1、节点治理。kubelet 启动时会向 api-server 进行注册,而后会定时的向 api-server 汇报本节点信息状态,资源应用状态等,这样 master 就可能晓得 node 节点的资源残余,节点是否失联等等相干的信息了。master 晓得了整个集群所有节点的资源状况,这对于 pod 的调度和失常运行至关重要。
2、pod 治理。kubelet 负责保护 node 节点上 pod 的生命周期,当 kubelet 监听到 master 的下发到本人节点的工作时,比方要创立、更新、删除一个 pod,kubelet 就会通过 CRI(容器运行时接口)插件来调用不同的容器运行时来创立、更新、删除容器;常见的容器运行时有 docker、containerd、rkt 等等这些容器运行时,咱们最相熟的就是 docker 了,但在新版本的 k8s 曾经弃用 docker 了,k8s1.24 版本中曾经应用 containerd 作为容器运行时了。
3、容器健康检查。pod 中能够定义启动探针、存活探针、就绪探针等 3 种,咱们最罕用的就是存活探针、就绪探针,kubelet 会定期调用容器中的探针来检测容器是否存活,是否就绪,如果是存活探针,则会依据探测后果对查看失败的容器进行相应的重启策略;
4、Metrics Server 资源监控。在 node 节点上部署 Metrics Server 用于监控 node 节点、pod 的 CPU、内存、文件系统、网络应用等资源应用状况,而 kubelet 则通过 Metrics Server 获取所在节点及容器的上的数据。

参考:这 https://blog.csdn.net/MssGuo/…

版权申明:本文为 CSDN 博主「MssGuo」的原创文章,遵循 CC 4.0 BY-SA 版权协定,转载请附上原文出处链接及本申明。
原文链接:https://blog.csdn.net/MssGuo/…

pod 创立过程

  • 用户通过 kubectl 或其它 API 客户端提交 pod spec 给 API Server。
  • API Server 尝试着将 pod 对象的相干信息存入 etcd 中,带写入操作执行实现后,API Server 会立刻返回确认信息至客户端。
  • Scheduler 通过其 watcher 检测到 API Server 创立了新的 pod 对象,于是为该 pod 对象筛选一个工作节点并将后果信息更新至 API Server。
  • 调度后果信息有 API Server 更新至 etcd 存储系统,并同步给 Scheduler。
  • 相应节点的 kubelet 检测到由调度器绑定于本节点的 pod 后会读取其配置信息,并由本地容器运行时创立相应的容器启动 pod 对象后将后果回存至 API Server。
  • API Server 将 kubelet 发来的 pod 状态信息存入 etcd 零碎,并将确认信息发送至相应的 kubelet。

容器设计模式

单容器模式是指将应用程序封装为利用容器运行。该模式须要遵循简略和繁多准则,每个容器仅承载一种工作负载。

单节点多容器模式

单节点多容器模式是指扩容器的设计模式,其目标是在单个主机之上同时运行多个共生关系的容器,因此容器管理系统须要将它们作为一个原子单位进行同一调度。kubernetes 编排零碎设计的 pod 概念就是这个设计模式的实现之一。

若多个容器间存在强耦合关系,它们具备完全相同的生命周期,或者必须运行于同一节点之上时,通常应该将它们置于同一个 pod 中,较常见的状况是为主容器并行运行一个助理治理过程。单节点多容器模式的常见实现有 Sidercar(边车)、适配器(Adapter)、大使(Ambassador)、初始化(Initializer)容器模式等。

Sidecar 模式
Sidecar 模式是多容器零碎设计的最罕用模式,它由一个主应用程序以及一个辅助容器(Sidecar)组成,该辅助容器用于为主容器提供辅助服务以加强主容器性能,是主应用程序必不可少的一部分,但却不肯定非得存在于应用程序自身外部。

最常见的 sidecar 容器时日志记录服务、数据同步服务、配置服务和代理服务等。对于主容器利用的每个实例,Sidecar 的实例都被部署并托管在它旁边,主容器与 sidecar 容器具备雷同的生命周期,毕竟主容器运行时,运行 sidecar 容器并无实际意义,只管齐全能够将 sidecar 容器集成到主容器外部,然而应用不同的容器来运行解决不同性能还是存在较多劣势;

  • 辅助利用的运行时环境和编译语言与主应用程序无关,因此无需为每种为每种编程语言别离开发一个辅助工具;
  • 二者可基于 IPC、lo 接口或共享存储进行数据交换,不存在显著的通信提早;
  • 容器镜像时公布的根本单位,将主利用与辅助利用划分为两个容器使得可由不同团队开发和保护,从而变得不便及高效,独自测试及集成测试也变得可能;
  • 容器限度了故障边界,使得零碎整体能够优雅降级,例如 sidecar 容器异样时主容器仍可提供服务;
  • 容器时部署的根本单元,每个功能模块均可独立部署及回滚。

https://blog.51cto.com/wanggu…

参考文档

正文完
 0