kubernates 组件（第二集）

Posted 2022-06-08 技术能量站

1. kubernates 组件概述

部署 Kubernetes 应用时，实际上是在一个kubernates集群上完成的。

一个 Kubernetes 集群由一组工作机器组成，称为节点，运行容器化应用程序，每个集群至少有一个工作节点。

• 工作节点托管作为应用程序工作负载组件的 pod；
• 控制平面管理集群中的工作节点和pod；

在生产环境中，控制平面通常跨多台计算机运行，集群通常运行多个节点，从而提供容错性和高可用性。
本文档概述了完整且正常工作的 Kubernetes 集群所需的各种组件。

2. kubernates 集群组件

2.1 控制面板组件

控制平面的组件对集群做出全局决策（例如，调度），以及检测和响应集群事件（例如，启动一个新的 Pod 部署的replicas字段不满意时）。

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

有关跨多台机器运行的示例控制平面设置，请参阅 使用 kubeadm 创建高可用性集群。

2.2 kube-apiserver

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

Kubernetes API 服务器的主要实现是kube-apiserver。kube-apiserver 旨在水平扩展——也就是说，它通过部署更多实例来扩展。您可以运行多个 kube-apiserver 实例并平衡这些实例之间的流量。

2.3 etcd

一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后备存储。
如果您的 Kubernetes 集群使用 etcd 作为其后备存储，请确保您为这些数据制定了 备份计划。
关于etcd 更深入的信息可以在etcd官网文档深入研究

2.4 kube-scheduler

监视新创建的控制平面组件，pod 没有分配 节点时选择一个节点让它们运行。
调度决策考虑的因素包括：

• 个人和集体资源要求
• 硬件/软件/策略约束
• 亲和性和反亲和性规范
• 数据局部性
• 工作负载间干扰
• 截止日期

2.5 kube-controller-manager

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

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

• 节点控制器：负责在节点宕机时进行通知和响应。
• 作业控制器：监视代表一次性任务的作业对象，然后创建 Pod 以运行这些任务以完成。
• Endpoints 控制器：填充 Endpoints 对象（即加入 Services & Pods）。
• 服务帐户和令牌控制器：为新命名空间创建默认帐户和 API 访问令牌。

2.6 cloud-controller-manager

一个 Kubernetes控制平面嵌入云特定控制逻辑的组件。云控制器管理器允许您将集群链接到云提供商的 API，并将与该云平台交互的组件与仅与您的集群交互的组件分开。

cloud-controller-manager 仅运行特定于您的云提供商的控制器。如果您在自己的场所运行 Kubernetes，或者在您自己 PC 内的学习环境中运行 Kubernetes，则集群没有云控制器管理器。

与 kube-controller-manager 一样，cloud-controller-manager 将几个逻辑上独立的控制循环组合成一个二进制文件，您可以将其作为单个进程运行。您可以水平扩展（运行多个副本）以提高性能或帮助容忍故障。

以下控制器可以具有云提供商依赖项：

• 节点控制器：用于检查云提供商以确定节点停止响应后是否已在云中删除
• 路由控制器：用于在底层云基础设施中设置路由
• 服务控制器：用于创建、更新和删除云提供商负载均衡器

3. Node 节点组件

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

3.1 kubelet

运行在每个代理上的代理节点在集群中。它确保容器正在运行pod。

kubelet 采用一组通过各种机制提供的 PodSpec，并确保这些 PodSpec 中描述的容器运行且健康。kubelet 不管理不是由 Kubernetes 创建的容器

3.2 kube-proxy

kube-proxy 是一个网络代理，运行在每个 节点在您的集群中，实现 Kubernetes 的一部分 服务概念。

kube-proxy 在节点上维护网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。

kube-proxy 使用操作系统包过滤层（如果有并且可用）。否则，kube-proxy 会自行转发流量。

3.3 Container runtime

Container runtime 是负责运行容器的软件。
Kubernetes 支持容器运行时，例如 容器化,CRI-O，以及Kubernetes CRI（容器运行时接口）的任何其他实现。

3.4 Addons(插件)

插件使用 Kubernetes 资源 (守护程序集, 部署等）来实现集群功能。因为这些提供集群级别的功能，所以插件的命名空间资源属于kube-system命名空间。

选定的插件如下所述；有关可用插件的扩展列表，请参阅插件。

3.5 DNS

Kubernetes 为服务和 Pod 创建 DNS 记录。您可以使用一致的 DNS 名称而不是 IP 地址请求服务。

虽然其他插件不是严格要求的，但所有 Kubernetes 集群都应该有集群 DNS，因为许多示例都依赖它。

除了您环境中的其他 DNS 服务器之外，集群 DNS 是一个 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录。

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

3.6 Web UI(Dashboard)

Dashboard 是一个基于 Web 的 Kubernetes 用户界面。您可以使用 Dashboard 将容器化应用程序部署到 Kubernetes 集群、对容器化应用程序进行故障排除以及管理集群资源。您可以使用 Dashboard 了解集群上运行的应用程序的概览，​​以及创建或修改单个 Kubernetes 资源（例如 Deployment、Jobs、DaemonSet 等）。例如，您可以使用部署向导扩展部署、启动滚动更新、重新启动 pod 或部署新应用程序。

Dashboard是用于 Kubernetes 集群的通用、基于 Web 的 UI。它允许用户对集群中运行的应用程序以及集群本身进行管理和故障排除。

仪表板还提供有关集群中 Kubernetes 资源状态以及可能发生的任何错误的信息。

3.7 Container Resource Monitoring

Container Resource Monitoring在中央数据库中记录有关容器的通用时间序列指标，并提供用于浏览该数据的 UI。

要扩展应用程序并提供可靠的服务，您需要了解应用程序在部署时的行为方式。您可以通过检查容器、 pod、 服务和整个集群的特征来检查 Kubernetes 集群中的应用程序性能。Kubernetes 在每个级别提供有关应用程序资源使用情况的详细信息。此信息使您可以评估应用程序的性能以及可以消除哪些瓶颈以提高整体性能。

3.8 Cluster-level Logging

集群级别的日志机制负责将容器日志保存到具有搜索/浏览界面的中央日志存储中。

应用程序日志可以帮助您了解应用程序内部发生的情况。这些日志对于调试问题和监控集群活动特别有用。大多数现代应用程序都有某种日志记录机制。同样，容器引擎旨在支持日志记录。容器化应用程序最简单和最常用的日志记录方法是写入标准输出和标准错误流。

但是，容器引擎或运行时提供的本机功能通常不足以提供完整的日志记录解决方案。例如，如果容器崩溃、Pod 被驱逐或节点死亡，您可能希望访问应用程序的日志。

在集群中，日志应该具有独立于节点、Pod 或容器的独立存储和生命周期。这个概念称为集群级日志记录。
集群级日志架构需要一个单独的后端来存储、分析和查询日志。Kubernetes 不提供日志数据的原生存储解决方案。相反，有许多与 Kubernetes 集成的日志记录解决方案。以下部分描述了如何处理和存储节点上的日志。

4. 总结

通过上面我可以知道，不同组件作用也不同：

• kube-apiserver：所有服务的统一入口
• controllermanager：由 kube-controller-manager 和 cloud-controller-manager 组成，是 Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态，维持副本期望的数目。
• kube-scheduler：负责接收任务，选择合适的节点分配任务（任务调度）。
• etcd：键值对数据存储，存储k8s所有重要信息（数据持久化）
• kubelet：直接跟容器引擎交互实现容器生命周期的管理
• kube-proxy：负责写入规则至 iptables、ipvs 实现服务的映射访问
• DNS：可以为集群中的svc创建一个域名IP的对应关系解析
• dashboard：给k8s集群提供一个B/S 结构访问体系
• ingress controller：官方只能实现四层代理，ingress 可以实现七层代理
• federation：提供一个可以跨集群中心多k8s统一管理功能
• prometheus：提供k8s的监控能力
• ELK：提供k8s 集群日志统一分析介入平台

最后说明一点，高可用集群副本数最好是 >= 3的奇数个。你知道为什么吗？

开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系