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…
参考文档