Kubernetes - Kubernetes 组件

当你部署完Kubernetes, 即拥有了一个完整的集群。

Kubernetes集群由一组称为节点（ ​

​nodes​

​）的工作机器组成，它们运行容器化的应用程序。每个集群至少有一个工作节点。

工作节点托管作为应用程序工作负载的组件 - Pod。控制平面（​

​control plane​

​）管理集群中的工作节点和Pod。在生产环境中，控制平面通常跨多台计算机运行，集群通常运行多个节点，从而提供容错性和高可用性。

这是一张Kubernetes集群的图，所有组件都绑定在一起。

1. 控制平面组件 - Control Plane Components

控制平面组件做出关于集群的全局决策（如调度），以及检测和响应集群事件（例如，当不满足部署的​

​replicas​

​字段时，启动新的Pod）。

控制平面组件可以在集群中的任何计算机上运行。但是，为了简单起见，设置脚本通常在同一台计算机上启动所有控制平面组件，而不在此计算机上运行用户容器。

kube-apiserver

API服务器是公开Kubernetes API的控制平面组件。API服务器是控制平面的前端。

Kubernetes API服务器的主要实现是​

​kube-apiserver​

​​。​

​kube-apiserver​

​​设计为水平扩展，即通过部署更多实例来扩展。你可以运行多个​

​kube-apiserver​

​实例，并在这些实例之间平衡流量，即负载均衡。

etcd

具备一致性和高可用性的键值存储，作为保存Kubernetes所有集群数据的后台数据库。

​

​etcd​

​​是CoreOS团队发起的开源项目，它的目标是构建一个高可用的分布式键值(​

​key-value​

​​)数据库。​

​etcd​

​​内部采用​

​raft​

​​协议作为一致性算法，​

​etcd​

​基于Go语言实现。

kube-scheduler

该控制平面组件，用于监视没有指定节点的新创建的Pod，并为它们选择要在其上运行的节点。

调度决策要考虑的因素包括：单个Pod和Pod集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据局部性、工作负载间的干扰和截止日期。

kube-controller-manager

运行控制器进程的控制平面组件。

从逻辑上讲，每个控制器都是一个独立的进程，但是为了降低复杂性，它们都被编译成一个二进制文件并在单个进程中运行。

这些控制器包括：

• 节点控制器（​

  ​Node controller​

  ​）：负责节点发生故障时的通知和响应。
• 副本控制器（​

  ​Replication controller​

  ​）：负责为系统中的每个副本控制器对象维护正确数量的Pod。
• 端点控制器（​

  ​Endpoints controller​

  ​​）：填充端点（​

  ​Endpoints​

  ​）对象（即加入Service与Pod）。
• 服务帐户和令牌控制器（​

  ​Service Account & Token controllers​

  ​）：为新命名空间创建默认帐户和API访问令牌。

cloud-controller-manager

云控制器管理器（​

​cloud-controller-manager​

​）是嵌入特定云的控制逻辑的控制平面组件。云控制器管理器允许你将集群链接到云提供商的API中，并将与该云平台交互的组件与仅与集群交互的组件分离。

云控制器管理器只运行特定云提供商的控制器。如果你在自己的环境中运行Kubernetes，或者在本地计算机的学习环境中运行Kubernetes，那么集群没有云控制器管理器。

与​

​kube-controller-manager​

​一样，云控制器管理器将若干个逻辑上独立的控制回路组合成一个二进制文件，你可以将其作为单个进程运行。你可以水平扩展（运行多个副本）以提高性能或增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（​

  ​Node controller​

  ​）：用于检查云提供商，以确定节点停止响应后是否已在云中删除。
• 路由控制器（​

  ​Route controller​

  ​）：用于在底层云基础设施中设置路由。
• 服务控制器（​

  ​Service controller​

  ​）：用于创建、更新和删除云提供商负载均衡器。

2. 节点组件 - Node Components

节点组件运行在每个节点上，维护运行中的Pod并提供Kubernetes运行环境。

kubelet

在集群中每个节点上运行的代理。它保证容器都运行在Pod中。

​

​kubelet​

​​采用一组PodSpecs ，这些PodSpecs通过各种机制提供，并确保这些PodSpecs中描述的容器运行正常。​

​kubelet​

​不管理非Kubernetes创建的容器。

kube-proxy

​

​kube-proxy​

​​是一个网络代理，运行在集群中的每个节点上，实现了Kubernetes服务（​

​Service​

​） 概念的一部分。

​

​kube-proxy​

​在节点上维护网络规则。这些网络规则允许通过集群内外的网络会话与Pod进行网络通信。

​

​kube-proxy​

​​使用操作系统包过滤层（如果有并且可用的话），​

​kube-proxy​

​​会通过它来实现网络规则。否则，​

​kube-proxy​

​转发流量本身。

Container runtime

容器运行环境（​

​Container runtime​

​）是负责运行容器的软件。

Kubernetes支持多个容器运行环境：​

​Docker​

​​、​

​containerd​

​​、​

​CRI-O​

​​和​

​Kubernetes CRI​

​（容器运行环境接口）的任何实现。

3. 插件 - Addons

插件（​

​Addons​

​​）使用Kubernetes资源（​

​DaemonSet​

​​、 ​

​Deployment​

​​等）来实现集群功能，因为它们提供集群级别的功能，所以插件的命名空间资源属于​

​kube-system​

​命名空间。

• ​

  ​DaemonSet​

  ​​：​

  ​DaemonSet​

  ​​确保全部（或者某些）节点上运行一个Pod的副本。当有节点加入集群时， 也会为它们新增一个Pod 。 当有节点从集群中移除时，这些Pod也会被回收。删除​

  ​DaemonSet​

  ​将会删除它创建的所有Pod。
• ​

  ​Deployment​

  ​​：一个​

  ​Deployment​

  ​​控制器为​

  ​Pods​

  ​​和​

  ​ReplicaSets​

  ​​提供声明式的更新能力。你负责描述​

  ​Deployment​

  ​​控制器中的目标状态，而​

  ​Deployment​

  ​​控制器以受控速率更改实际状态， 使其变为期望状态。你可以定义​

  ​Deployment​

  ​​控制器创建新的​

  ​ReplicaSet​

  ​​，或删除现有​

  ​Deployment​

  ​​控制器， 并通过新的​

  ​Deployment​

  ​控制器收养其资源。

DNS

虽然其他插件不是严格要求的，但是几乎所有Kubernetes集群都应该有集群DNS，因为很多示例都需要DNS服务。

集群DNS是一个DNS服务器，和你环境中的其他DNS服务器一起工作，它为Kubernetes服务提供DNS记录。

由Kubernetes启动的容器自动将此DNS服务器包含在其DNS搜索列表中。

Web UI (Dashboard)

Dashboard是一个Kubernetes集群通用的、基于​

​Web​

​的用户界面。它允许用户管理集群中运行的应用程序以及集群本身并进行故障排除。

Container Resource Monitoring

Cluster-level Logging

官网原文

• ​​Kubernetes Components​​