kubernetes架构设计理论
kubernetes架构设计
kubernetes概述
Kubernetes是生产级的开源基础架构，用于跨主机集群应用程序容器的自动化部署、扩展、管理和组合，有便携性，灵活性，可扩展性，自动化等属性。侧重于微服务和云原生应用程序的部署和管理，支持多数工作负载，比如单体服务、微服务、无状态、有状态、批处理、定时任务等。受到之前Google工作中Borg系统的启发。 Kubernetes不仅仅是一个“容器协调者”， 它旨在消除编排物理/虚拟机、网络和存储基础架构的负担，并使应用程序操作者和开发人员能够完全专注于以容器为中心的平台，以实现自助服务操作。 Kubernetes提供稳定并便携的基础平台，用于构建定制的工作流程和更高级别的自动化。 Kubernetes主要针对由多个容器组成的应用程序。它使用容器和标签将容器分组为紧密耦合和松散耦合的结构，以便于管理和服务发现。
范围
Kubernetes是一个用于部署和管理容器的平台。Kubernetes提供容器运行，容器编排，以容器为中心的架构流程，自我修复机制，如运行状况检查和重新调度，以及服务发现和负载平衡。 Kubernetes希望成为一个可扩展，可插拔，构建块的OSS平台和工具包。因此，在架构上，我们希望将Kubernetes构建为可插入组件和层的集合，能够使用备用调度程序，控制器，存储系统和分发机制，并且我们正在朝着这个方向发展。此外，我们希望其他人能够扩展Kubernetes功能，例如更高级别的PaaS功能或多群集层，而无需修改核心Kubernetes源码。因此，它的API不仅仅是（甚至主要是）针对最终用户，而是针对工具和扩展开发人员。其API旨在作为工具，自动化系统和更高级API层的开放生态系统的基础。因此，没有“内部”组件间API。所有API都是可见的和可用的，包括scheduler, node controller, replication-controller manager, Kubelet’s API等使用的API。为了处理更复杂的用例，人们可以访问低层API以完全透明，可组合的方式。
架构
一个运行着的Kubernetes集群包含节点代理程序（kubelet）和集群控制平面（就是master模式），集群状态由分布式存储系统(etcd)支持
master节点
Kubernetes控制平面分为一组组件，这些组件可以在单个主节点上运行，也可以复制以支持高可用性集群，甚至可以在Kubernetes本身上运行（即自托管）。Kubernetes提供REST API，主要支持（多数）持久性资源上的CRUD操作，这些资源充当其控制平面的中心。Kubernetes的API提供类似IaaS的以容器为中心的服务，如Pod，Services和Ingress，以及生命周期API，以支持常见类型的工作负载的编排（自我修复，扩展，更新，终止），例如ReplicaSet（简单可替换/无状态应用程序管理器），部署（编排无状态应用程序的更新），作业（批处理），CronJob（cron），DaemonSet（集群服务）和StatefulSet（有状态应用程序）。我们故意将服务命名/发现和负载均衡与应用程序实现分离，因为后者是多样的，开放式的。 用户客户端和包含异步控制器的组件都与相同的API资源交互，这些API资源用作协调点，通用中间表示(common intermediate representation)和共享状态。大多数资源包含元数据，包括标签和注释，完全详细说明的所需状态（规范），包括默认值和观察状态（状态）。 控制器保证将实际状态驱动到期望状态，同时向用户和其他控制器报告当前观察到的状态。 虽然控制器是基于级别的，以最大限度地提高容错能力，但它们通常会关注相关资源的更改，以最大限度地减少反应延迟和冗余工作。这样就可以在没有消息总线的情况下实现分散和分离的编排协调
API Server
API服务由Kubernetes API 提供。它旨在成为一个相对简单的服务器，大多数/所有业务逻辑在单独的组件或插件中实现。它主要处理REST操作、验证、并更新etcd中的相应对象。请注意，由于多种原因，Kubernetes故意不支持跨多个资源的原子事务。 如果没有这种基本的API机制，Kubernetes就无法运行，其中包括：
- REST语义，监控，持久性和一致性保证，API版本控制，默认设置和验证
- 内置的准入控制语义，同步准入控制hook和异步资源初始化
- API注册和发现
此外，API服务器充当群集的网关。根据定义，客户端必须可以从群集外部访问API服务器，而节点（当然也可以是容器）可能不是。客户端对API服务器进行身份验证，并将其用作nodes和pods（和服务）的代理/隧道。
Cluster state store
所有持久性群集状态都存储在etcd的实例中。这提供了一种可靠地存储配置数据的方法。通过监视支持，可以非常快速地通知协调组件的更改
Controller-Manager Server
多数其他集群级功能当前由称为Controller Manager的单独进程执行。它执行生命周期功能（例如，命名空间创建和生命周期，事件垃圾收集，终止pod垃圾收集，级联删除垃圾收集，节点垃圾收集）和API业务逻辑（例如，由ReplicaSet控制的pod的缩放）。 应用程序管理和组合层，提供自我修复，扩展，应用程序生命周期管理，服务发现，路由以及服务绑定和配置。这些功能最终可以分成单独的组件，以便更容易地扩展或替换它们
Scheduler
Kubernetes使用户能够要求集群运行一组容器。调度程序组件自动选择要运行这些容器的主机。 调度程序监视未调度的pod，并根据所请求资源的可用性，服务质量要求，关联性和反关联性规范以及其他约束，通过 /binding pod 子资源API将它们绑定到节点。 Kubernetes使用Omega开创的共享状态方法支持用户提供的调度程序和多个并发集群调度程序。除了Omega论文描述的悲观并发的缺点之外，隐藏来自上层调度程序的信息的两级调度模型需要在所有上层调度程序所需的低级调度程序中实现所有相同的功能。为了确保可以通过可用的所需资源满足他们的调度请求
node节点
Kubernetes node节点具有运行应用程序容器所需的服务，并可从主节点进行管理
Kubelet
Kubernetes中最重要和最突出的控制器是Kubelet，它是驱动容器执行层的Pod和Node API的主要实现者。如果没有这些API，Kubernetes将只是一个面向CRUD的REST应用程序框架，由一个键值存储支持（也许API机制最终将作为一个独立项目分离出来）。 Kubernetes执行独立的应用程序容器作为其默认的本机执行模式，而不是进程和传统的操作系统包。应用程序容器不仅彼此隔离，而且还与它们执行的主机隔离，这对于将各个应用程序的管理彼此分离以及与底层群集物理/虚拟基础架构的管理分离至关重要。 Kubernetes提供可以托管多个容器和存储卷的Pod作为其基本执行单位，以便于为每个容器打包单个应用程序，将构建时关注点与构建时问题分离，以及从物理/虚拟机迁移。Pod容器是现代云平台（如Kubernetes）上部署的关键。 API准入控制可能会拒绝pod或向其添加额外的调度约束，但Kubelet是pod可不可以在给定节点上运行的最终仲裁者，而不是调度程序或DaemonSets。
Container runtime
每个节点都运行一个容器运行时，它负责下载映像和运行容器。Kubelet不参与基本容器运行。相反，我们正在定义一个Container Runtime Interface来控制底层运行时并促进该层的可插拔性。需要这种去耦以保持清晰的组件边界，便于测试并促进可插拔性。现在支持的运行时，无论是上游还是通过分支，至少包括docker（适用于Linux和Windows），rkt，cri-o和frakti
Kube Proxy
服务抽象提供了一种在公共访问策略（例如，负载平衡）下对 pods 进行分组的方法。此实现创建了一个虚拟IP，客户端可以访问该虚拟IP，并透明地代理服务中的pod。每个节点都运行一个kube-proxy进程，该进程对iptables规则进行编程，以捕获对服务IP的访问并将它们重定向到正确的后端。这通过平衡来自同一节点上的节点的客户端流量，提供了具有低性能开销的高可用性负载平衡解决方案。各服务endpoints主要通过DNS发现
附加组件
DNS
Ingress controller
Heapster (resource monitoring)
Dashboard (GUI)
源自：k8s架构
2019年02月19日 于 linux工匠 发表